Java面试知识总结(一)-- 网络基础

根据慕课网视频和一些其他社区别的博主的总结进行的二次总结。这个过程为的是加深印象。

网络基础相关

OSI 七层协议

1. 物理层

定义了机器之间通信标准:网线类型,接口类型,各种介质的传输数率。这一层传输比特流(二进制数据),进行数模转换和模数转换。

2. 数据链路层

定义如何格式化数据进行传输,如何控制对物理介质的访问。采用差错控制与流量控制方法,确保数据传输的可靠性。在这一层的数据是帧,工作的设备是网卡、网桥、交换机。

3. 网络层

将网络地址翻译成对应物理地址(封装和解析),通过路由选择算法为通信子网选择最适当的传输路径(发送方->接受方),以及实现拥塞控制、网络互连等功能。这一层的数据是数据包,工作的设备有路由器、交换机、防火墙。IP协议。

4. 传输层*

保证海量文件传输数据的准确性,传输层定义了传输数据的协议和端口号,用来对数据进行分割,传输,重组。传输层向高层屏蔽了下层数据通信的细节。在这一层工作的协议有TCP和UDP等。

5. 会话层

建立和保证应用程序之间的通信。使应用程序自动收发包和寻址。

6. 表示层

对接收的数据进行解释、加密、解密、压缩、解压缩等,即把计算机能够识别的内容转换成人能够识别的内容(图片、声音、文字等)。

7. 应用层

基于网络构建具体应用,用户可以自己规定各个应用间消息传输的形式,例如FTP上传文件下载服务、Telnet服务、HTTP服务、DNS服务、SNMP邮件服务等。

TCP/IP

是OSI的实现。四层模型。不仅仅是TCP和IP协议,是一系列网络协议的总称(协议簇),如:HTTP, FTP, SMTP, DNS, UDP等等。
?注重实现协议应该开发哪种程序。
TCP/IP协议从应用层到物理层至上而下再至下而上处理数据头部。

应用层

对应七层协议的会话,表示,应用

传输层

对应七层协议的传输

网络层

对应七层协议的网络

链路层

对应七层协议的物理,数据链路

TCP报文头部结构

面试知识总结(一)-- 网络基础
由图可知,TCP报文头部至少需要20字节长度。

源端口,目标端口

标识出目标端口,目标IP,源端口,源IP,就可以确定一个连接的唯一性。IP层处理两个IP元组,而TCP层处理其余两个元组。这两个端口长度分别为两字节。

序列号

报文段第一个字节的序列号。占用四个字节。一次通信过程中,第一次序号值被初始化为一个随机值ISN,后续的序号值将在此基础上加上该报文段所携带数据的第一个字节在整个字节流中的偏移X,即ISN+X。

确认号

ACK,四个字节。作为收到另一方发送的报文后的响应。值是收到对方的序号值+1。告知对方下一个期望接收的序列号,小于ACK的所有字节已经全部收到。

头部长度

4bits,表示tcp头部有多少个32bits字。4bits最多表示15个数,所以头部最大可以表示1532bits,即154bytes,四字节。

八位标志位

常见的标记位有SYN,ACK,FIN,RST,PSH
含义?

窗口大小

两字节。是TCP流量控制的一个手段,这里说的窗口是指接收通告窗口,它告诉对方本端的tcp接收缓冲区还能容纳多少字节的数据,这样对方就可以控制发送数据的速度。

校验和

占用两个字节,防止传输过程中数据包有损坏,如果遇到校验和有差错的报文,TCP 直接丢弃之,等待重传。

紧急指针

它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。发送紧急数据时会用到。

可选项

最后一个选项字段是可变长的可选信息,最多包含40字节的数据。典型的tcp头部选项结构:

面试知识总结(一)-- 网络基础
常用的可选项有以下几个:

  • TimeStamp: TCP 时间戳,后面详细介绍。
  • MSS: 指的是 TCP 允许的从对方接收的最大报文段。
  • SACK: 选择确认选项。
  • Window Scale: 窗口缩放选项。

TCP 三次握手

IP无连接通信协议,不会占用两个正在通信计算机的通信线路。通过IP协议,数据被分割为小的独立的包,进行传输,但是无法保证数据包传输的可靠性,所以需要TCP保证传输的准确性。

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。

三次握手过程:

  • 服务端开启某个端口,进入LISTEN状态,开始监听。
  • 客户端主动发起连接,发送连接请求报文SYN,完成后进入SYN-SENT状态
  • 服务端接收到信息,发送回SYN和确认报文ACK,进入SYN-RCVD状态;如果服务端未发送确认信息,则客户端重传包。
  • 客户端接收到返回的信息,将ACK发送给服务端,进入ESTABLISHED状态,建立连接。

为什么不是两次?

如果第一次握手时客户端发送的报文滞留在网络没有到达客户端,那么客户端将重传报文从而建立连接。过程结束后,滞留的包到达服务端,此时服务端只需回传接收到的包就可以默认建立连接,但是之前客户端已经通过重传建立过连接了,从而造成了资源的浪费。

为什么不是四次

三次握手已经可以确定建立连接了,四次虽然可以,但是没有必要。如果是将服务端的SYN和ACK报文拆分成两次发送,这和一次的效果是相同的,也没有必要。

SYN Flood 攻击

首先我们需要明白什么是半连接队列和全连接队列。
服务端建立监听之后,收到客户端发送的SYN包,进入SYN-RCVD状态,并向客户端发送ACK。此时这个连接被推入SYN队列,就是半连接队列
当第三次握手时客户端发返回给服务端ACK,两端建立连接,等待被具体应用取走前,进入TCP维护队列,就是全连接队列

  • 问题产生:
    SYN Flood 攻击就是客户端伪造大量不存在的IP地址,向服务端不断发送SYN报文。随后服务端返回ACK,大量连接处于半连接队列,造成服务端无法正常处理连接请求。
    又由于伪造的IP地址不存在,服务端长时间收不到客户端的ACK,使其不断重发数据,会耗尽服务端资源。

  • 解决办法:

    • 增加SYN,即增加半连接队列的容量
    • 减少SYN+ACK重试次数,避免大量超时重发
    • 利用 SYN Cookie 技术,在服务端接收到SYN后不立即分配连接资源,而是根据这个SYN计算出一个Cookie,连同第二次握手回复给客户端,在客户端回复ACK的时候带上这个Cookie值,服务端验证 Cookie 合法之后才分配连接资源。

TCP 四次挥手

断开一个TCP连接时的整个流程。

  • 假设客户端主动关闭,客户端向服务端发出FIN报文,进入FIN-WAIT-1状态。此时客户端半关闭状态,只能接收报文。
  • 服务端收到FIN报文,向客户端发送ACK确认,进入CLOSED-WAIT状态。客户端收到报文,进入FIN-WAIT-2状态。
  • 服务端发送FIN报文,进入LAST-ACK状态
  • 客户端收到服务端发来的FIN后,自己变成了TIME-WAIT状态,然后发送 ACK 给服务端。收到ACK后,服务端关闭。
  • 此后客户端需要等待2个MSL(Maximum Segment Lifetime,报文最大生存时间),在这段时间内如果客户端没有收到服务端的重发请求,那么表示 ACK 成功到达,挥手结束,否则客户端重发 ACK。

为什么最后有TIME-WAIT状态

  • 保证有足够时间让被动关闭端收到ACK
    • 1 MSL 确保发送的ACK有足够时间到被关闭端
    • 1 MSL 确保如果规定时间内对端未收到ACK,有足够时间重传FIN
  • 避免新旧连接混在一起

为什么四次挥手断开连接

因为服务端在接收到FIN, 往往不会立即返回FIN, 必须等到服务端所有的报文都发送完毕了,才能发FIN。因此先发一个ACK表示已经收到客户端的FIN,延迟一段时间才发FIN。这就造成了四次挥手。

如果是三次挥手会有什么问题?

出现大量CLOSED-WAIT状态的原因?

UDP

  • 一个面向无连接的传输协议。
  • 不维护连接状态,支持同时向多个客户端传输相同消息
  • 数据包包头8字节,较小
  • 吞吐量只受限于数据生成速率,传输速率和机器性能
  • 不保证可靠交付,无需维持复杂的链接状态表
  • 面向报文,不对应用程序提供的报文信息进行拆分或合并

TCP 和 UDP 区别

  • 面向连接 vs 无连接
  • 可靠性:TCP可靠,丢包重传;UDP不可靠。
  • 有序性:TCP利用序列号保证了数据的有序性(数据到达会排序)
  • 速度:TCP创建连接,速率较慢;UDP较快
  • TCP 流模式,UDP报文模式

TCP 的流量控制

简单说就是通过接收端缓存区大小,控制发送端的发送。如果接收端缓存区已满,发送端就无法进行发送。

TCP 的滑动窗口

  • 保证TCP可靠性
  • 保证TCP流控特性
  • 分为两个窗口,接受窗口和发送窗口

发送窗口

面试知识总结(一)-- 网络基础

面试知识总结(一)-- 网络基础

已发送未确认窗口和未发送可发送的窗口决定了发送窗口的大小。而接收窗口的大小取决于发送端已发送未确认窗口的大小。

接收窗口

面试知识总结(一)-- 网络基础

待发送端已发送但未确认的数据被确认后,接收窗口会进行移动,形成滑动窗口。只有收到ACK确认后,窗口才会滑动,一定时间内未确认的数据将会重传,从而保证了TCP连接的可靠性。

流量控制的过程

  • 通过三次挥手后,发送端和接收端建立连接,并初始化窗口大小为200个字节。

  • 此时发送端给接收端发送100个字节的数据,那么SND.NXT指针会右移100字节,使可用窗口减少100字节。

  • 接收端接收了100字节,由于处理能力有限,一次最多只能处理40字节,剩余的60字节留在了缓冲区。这样,接收端接收窗口需要缩小60字节变成140字节,保证未来能处理这60字节的缓冲区数据。

  • 接收端收到发送端数据给发送端返回的ACK报文首部会带上窗口大小的数据,于是发送端也相应调整窗口大小为140字节。发送端此时已发送已确认的数据为40字节,所以SND.UNA右移40字节。

HTTP相关

报文结构

HTTP报文结构:起始行 + 头部 + 空行 + 实体

起始行

  • 请求报文起始行:方法 + 路径 + HTTP版本
  • 相应报文起始行:HTTP版本 + 状态码 + 原因
  • 每个部分用空格间隔,最后一个部分换行符

请求头/响应头

在起始行后,是请求头和响应头。
格式要求:

  • 字段名不区分大小写
  • 字段名不允许出现空格,不可以出现下划线_
  • 字段名后面必须紧接着:

空行

  • 用来区分头部和实体

实体

  • 具体数据

请求方法

  • GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE

GET, POST 区别

  • 缓存角度:GET会被浏览器主动缓存下来,POST不会
  • 编码角度:GET进行URL编码,只接受ASCII码,POST没有限制
  • 参数角度:GET放在URL中,不安全;POST放在请求体中,适合传输敏感信息
  • 幂等性角度:GET幂等,POST不是(执行相同操作,结果也相同)
  • TCP传输时,GET直接将报文发送完成,POST分两次发送,第一次发送头部信息,如果TCP响应100,那么继续发送实体部分

URI 统一资源标识符码

使用ASCII,所有非ASCII码通过转化为16进制字节值加%的编码形式进行识别。

在浏览器地址栏键入URL,按下回车后经历的流程

  • DNS解析
    -
  • TCP连接,三次握手
  • 发送HTTP请求
  • 服务器处理请求返回HTTP响应报文
  • 浏览器渲染界面
  • 结束连接,四次挥手

HTTP状态码

  • 1xx: 协议处理的中间状态,需要继续处理
    • 100 Switching Protocols:在HTTP升级为WebSocket的时候,如果服务器同意变更,就会发送状态码 101。
  • 2xx: 请求成功
    • 200 OK:在响应体中放有数据
    • 204 NO CONTENT
    • 206 PARTIAL
  • 3xx: 重定向,资源位置发生变动,需要重新请求
    • 301 Moved Permanently即永久重定向,对应着302 Found,即临时重定向
    • 304 Not Modified: 当协商缓存命中时会返回这个状态码。
  • 4xx: 客户端错误,请求报文有误
    • 400 Bad Request: 客户端请求语法错误
    • 403 Forbidden:服务器收到请求,但拒绝服务
    • 404 Not Found: 请求的服务器资源不存在
  • 5xx: 服务端错误
    • 500 Internal Server Error:服务器发送不可预知的错误
    • 503 Server Unavailable:服务器无法响应服务

Cookie 和 Session 的区别

Cookie

  • 客户端发送第一次请求时,由服务端发送给客户端的特殊信息,以文本形式存在客户端
  • 客户端再次请求时,会携带Cookie信息回传到服务器
  • 服务器通过解析,获取客户端的状态。

Session

  • 服务器的机制,在服务器上保存的信息
  • 客户端发送请求时,服务器解析客户端数据是否包含session id,若没有则为其生成

实现方式

  • 通过Cookie:在Cookie信息中携带Session id
  • 通过URL回写:???

区别

  • Cookie存放在客户端浏览器上,Session数据存放在客户端上
  • Session更安全
  • 使用Cookie可以减轻浏览器负担

HTTP 和 HTTPS 的区别

  • HTTPS需要申请CA证书
  • HTTPS有SSL加密传输;HTTP明文
  • 端口号不同:443;80
  • HTTPS = HTTP + 加密 + 认证 + 完整性保护,更安全

Socket

  • 是对TCP/IP协议的抽象,是操作系统对外开放的抽象。
  • 通信流程:

Java面试知识总结(一)-- 网络基础

本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!