2020春招面试总结(一)：计算机网络知识点

一、三次握手和四次挥手

1. "三次握手"的详解+图解
   所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：
   
   握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：
   1）首先客户端向服务器端发送一段TCP报文，其中：
   • 标记位为SYN，表示“请求建立新连接”
   • 序号为Seq=X（X一般为1）
   • 随后客户端进入SYN-SENT阶段。

   ---

   (2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：
   • 标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
   • 序号为Seq=y；
   • 确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。

   ---

   （3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：
   • 标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
   • 序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
   • 确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
   • 随后客户端进入ESTABLISHED阶段。

   ---

       服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。
       在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。
       此后客户端和服务器端进行正常的数据传输。这就是“三次握手”的过程。

        为什么要进行第三次握手?
       为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

       由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。

       如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

       客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，

       服务器端是不知道客户端有没有接收到服务器端返回的信息的。

2. "四次挥手"详解
   所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解：
   
   挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：
   1）首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：
      * 标记位为FIN，表示“请求释放连接“；
      * 序号为Seq=U；
      * 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
   注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。
   
   （2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：
   
      * 标记位为ACK，表示“接收到客户端发送的释放连接的请求”；
      * 序号为Seq=V；
      * 确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
      * 随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段。
   
   前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

   （3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

      * 标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
      * 序号为Seq=W；
      * 确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。
      * 随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。
   
   （4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

      * 标记位为ACK，表示“接收到服务器准备好释放连接的信号”。
      * 序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。
      * 确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。
      * 随后客户端开始在TIME-WAIT阶段等待2MSL

         为什么“握手”是三次，“挥手”却要四次?
         建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
         释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

         谈谈 TIME_WAIT 的作用
         1.如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
         否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
         所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因

         2.等待一段时间还为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接
不会出现旧的连接请求报文。（报文在互联网里面存活的时间是有限的，旧的报文会影响下一次的
连接）

         TIME_WAIT 过多会出现什么问题，怎么解决？
         如果在 高并发，多短链接情景下，TIME_WAIT 就会过多，导致端口被持续占用，用户连接不
上服务器
         可以通过调整内核参数解决： vi /etc/sysctl.conf 加入以下内容设置：net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1

• reuse 是表示是否允许重新应用处于 TIME-WAIT 状态的 socket 用于新的 TCP 连接
• recyse 是加速TIME-WAIT sockets回收

         TIME_WAIT 状态是主动关闭连接的一方（Client）出现的，不要轻易去使用上边两个参数。
先看看是不是可以在应用层面重用TCP连接来尽量避免这个问题（ 比如 HTTP 的 KeepAlive技术）

二、TCP和UDP的区别

1. TCP 面向连接，传输数据之前要需要建立会话。UDP 是无连接的。
2. TCP 提供可靠传输，保证数据不丢包、不重复且按顺序到达；UDP 只尽努力交付，不保证可靠交
   付3. TCP 是面向字节流的；UDP 面向报文。
3. TCP 只支持点到点通信；UDP 支持一对一、一对多、多对多的交互通信。
4. TCP 首部开销大 20 字节，UDP 首部开销小 8 字节。

三、GET 和POST 的区别

1. GET用于获取数据，POST用于提交数据;
2. GET的参数长度有限制（不同的浏览器和服务器限制不同），POST没有限制
3. GET把参数包含在URL中，POST通过封装参数到请求体中发送；
4. GET请求只能进行URL编码，而POST支持多种编码方式。
5. GET可以发送的参数只能是ASCII类型，POST没有限制，甚至可以传输二进制。
6. GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息;
7. GET刷新无害，而POST会再次提交数据

四、说一下长链接

• HTTP 是无状态的，所以长链接指的不是 http，而是 TCP 长链接
• 为什么需要长链接：
  • 主要是为了复用 TCP 连接，避免每一次 http 请求都要重新建立一次 TCP 连接，浪费资源。
  • 举例：访问一个页面需要 N 个资源，会发起 N 个 http 请求。以前的短连接会发出多个 TCP
    连接，现在只需要一个 TCP 长链接就可以完成这 N 个 http 资源请求。
• 长轮询与短轮询
  • 其实都是客户端不断的去访问服务器某些资源，不同的是服务端的反应
  • 短轮询时代：服务端收到请求后处理完毕就断开
  • 长轮询时代：服务端收到请求后如果没有查到需要的资源，会将连接挂起，直到得到数据或
    超时

五、OSI 七层模型和其他模型

• OSI （7层）：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
• TCP/IP 分层（4层）：网络接口层、 网际层、运输层、 应用层。
• 五层协议 （5层）：物理层、数据链路层、网络层、运输层、 应用层。

六、IP 与 MAC 的区别

• ip 工作在网络层、mac 工作在链路层
• ip 32位、mac 48位
• IP 地址可以随便改、mac 改不了，固化在硬件里面
• 路由表里面没有 MAC 地址

七、常用端口

• HTTP 80
• HTTPS 443
• FTP 20（数据口） 、 21（连接口）
• SSH 22
• Telnet 23
• SMTP 25（简单邮件传输服务。负责发）
• POP3 110 （邮局协议3。负责收，客户端操作不同步到服务器上。用户从服务器上读取后就删除）
• IMAP 143 （交互式邮件存取协议。负责收，客户端操作同步到服务器上。支持多设备）
• SOCKS 1080 DNS 53（使用 UDP 发送，当字节大于 512 的时候改为 TCP）
• DHCP 67（接收）、68（发送）

端口号的范围:

• 熟知端口号：0 ~ 1023（分配给 TCP/IP 最重要的应用程序）
• 登记端口号：1024 ~ 49151（熟知端口没有涉及到的协议在这里分配，但是必须向 IANA 登
  记）
• 客户端端口号：49152 ~ 65535
  （在TCP、UDP协议的开头，会分别有16位来存储源端口号和目标端口号，所以端口个数是2^16- 1=65535个。）

八、同步传输与异步的区别

同步传输方式中发送方和接收方的时钟是统一的、字符与字符间的传输是同步无间隔的。 异步传输方式并不要求发送方和接收方的时钟完全一样，字符与字符间的传输是异步的。 区别点：

1. 异步传输是面向字符的传输，而同步传输是面向比特的传输
2. 异步传输通过字符起始和停止码抓住再同步的机会，而同步传输则是在数据中抽取同步信息。
3. 异步传输对时序的要求较低，同步传输往往通过特定的时钟线路协调时序。
4. 异步传输相对于同步传输效率较低。

九、分类 IP 地址范围

• A类网络的IP地址范围为：1.0.0.0－127.255.255.255
• B类网络的IP地址范围为：128.0.0.0－191.255.255.255
• C类网络的IP地址范围为：192.0.0.0－223.255.255.255

十、TCP 粘包与拆包

TCP 拆包、粘包：TCP 数据包发送到接收端的时候可能存在多个包一起接收，这就叫粘包。也存在一个
数据包被分为好几次接收，这就叫拆包。 发生的原因：

1. 要发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包
2. 待发送数据大于最大报文长度，TCP 在传输前将进行拆包
3. 待发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发
   生粘包
4. 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包

解决办法：
* 发送端给每个数据包添加包首部，首部里面包含该数据包的大小
* 发送端将每个数据包封装为固定长度（不够的补0）
* 给发送的数据包添加首尾分界符

十一、TCP 如何保证可靠传输

1. 超时重传
2. 差错校验
3. 流量控制（为了让接收方能来得及接收）
4. 拥塞控制（为了降低整个网络的拥塞程度）
   1. 慢开始
   2. 拥塞避免
   3. 快重传
   4. 快恢复
5. 滑动窗口与数据包编号排序

十二、简述 TCP 滑动窗口

简介：
窗口是缓存的一部分，用来暂时存放字节流。

发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个【按序到达】的字节进行确认，例如接收窗口已经收到的字节为{31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

作用：

1. 实现了 TCP 的可靠性：对发送的数据进行编号与确认以及超时重传
2. 流量控制：窗口大小随链路情况不断变化

TCP 窗口其他特点：

1. 有两个窗口，一个发送、一个接收。
2. 全双工通信
3. 第一次接受方窗口大小是由链路带宽决定的
4. 当窗口过大时，会导致不必要的数据来拥塞我们的链路，但是窗口太小时，会造成很大的延时

十三、TCP 拥塞处理

1. 慢开始
2. 拥塞避免
3. 快重传
4. 快恢复

十四、DNS 查询流程

（分为迭代、递归查询）
查询方式：

1. 主机向本地域名服务器查询：递归方式
2. 本地域名服务器向根域名服务器查询：迭代方式

递归：本机向本地域名服务器找某地址的IP，本地域名没找到就请求根域名，根域名找到对应的顶级，顶级 下去再找二级。。最后二级返回给顶级，顶级返回结果给根域名服务器，根在把结果返回给本机

迭代：本机问本地，本地问根（根把对应的顶级告诉本地）由本地再问顶级（顶级把对应的二级告诉本 地），由本地再问二级。。最后本地直接获得要查询的结果（不是层层返回结果），本地再把结果返回给本 机

注意，本机访问指定的域名服务器后，本地域名服务器一开始就要访问 根域名服务器

十五、Http 请求和响应报文

1.请求报文

• 请求行：由 请求方法 、 URL 和 HTTP协议版本 3个字段组成
• 请求头：（键值对）主要含：产生请求的浏览求类型，客户端可以接受的语言、编码，要访问的主机，请求报文的长度
• 请求空行：表示请求头发送结束了
• 请求体：具体的请求参数

2.响应报文

• 响应行：http 协议的版本，http 状态码，http 响应描述
• 响应头：返回时间、服务器型号、缓存过期时间等
• 响应空行：通知响应头发送结束
• 响应体：主要是 HTML或者Json等前端需要的数据

十六、怎么解决 Http 无状态

• session + cookie
• url 重写
• 隐藏表单
• 使用浏览器本地存储
• JWT 鉴权机制

十七、HTTP 1.0、1.1、2.0 的区别

HTTP 1.0：

1. 无状态、无连接。每次通信之后立刻断开连接，导致需要反复建立 TCP 连接
2. 由于 HTTP1.0 规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不 到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。

HTTP 1.1

1. TCP 可以复用了 keep-alive
2. 为了修补（不是修复）1.0 时代请求阻塞的问题，1.1 支持请求管道化，也就是不需要等待上一个请 求响应了再发送下一个请求。1.1 的做法就是把这个请求队列放到服务端上，服务端还是先处理第一个请 求，再处理第二个请求（所以我说它是修补，不是修复，要是服务端的请求处理的很慢的话，还是会阻塞后面的请求。所以这个技 术没有推广起来）
3. 明文传输。通过抓包工具可以截获报文，可以看到传输的数据。即使加密了也能看到乱码，反正可以看 到文字
4. 还是没有解决无状态连接

现阶段的浏览器之所以使用 1.1 加载数据不慢，除了网速快以外，还有一个原因就是浏览器运行开多个 TCP 同时执行 HTTP 请求，Chrome 浏览器默认支持 6 个 TCP 同时请求数据

HTTP 2.0

1. 主要优点有采用二进制帧封装，传输变成多路复用，流量控制算法优化，服务器端推送，首部压缩，优 先级等特点
2. 不管对同一个域名访问多少文件，所有的请求都是通过一个 TCP 连接并发完成。当然这里面一定存在 请求的优先级排序以及流量控制（滑动窗口）
3. 服务器给建立连接的客户端主动发送数据，无需客户端确认请求