网络面试题：TCP与UDP区别及三次握手，四次挥手

一.TCP与UDP

1.1 区别

1. TCP是面向连接的，UDP是面向无连接的
2. TCP保证数据的正确性，UDP可能丢包
3. TCP传输速度慢，UDP传输速度快
4. 每一条TCP的建立是点到点的，而UDP可以点到多，多到多，多对一的交互
5. TCP对系统要求的资源多，UDP则少一点

1.2 面向连接与无连接：

这篇博客详解讲解了面向连接与无连接的区别：戳这里
这里简单讲述一下：

1. 无连接协议中的分组被称为数据报（datagram），每个分组都是独立寻址，并由应用程序发送的。从协议的角度来看，每个数据报都是一个独立的实体，与在两个相同的对等实体之间传送的任何其他数据报都没有关系，这就意味着协议很可能是不可靠的。也就是说，网络会尽最大努力传送每一个数据报，但并不保证数据报不丢失、不延迟或者不错序传输。

2. 另一方面，面向连接的协议则维护了分组之间的状态，使用这种协议的应用程序通常都会进行长期的对话。记住这些状态，协议就可以提供可靠的传输。比如，发送端可以记住哪些数据已经发送出去了但还未被确认，以及数据是什么时候发送的。如果在某段时间间隔内没有收到确认，发送端可以重传数据。接收端可以记住已经收到了哪些数据，并将重复的数据丢弃。如果分组不是按序到达的，接收端可以将其保存下来，直到逻辑上先于它的分组到达为止。

3. 面向连接就像打电话，通了之后先互相问一句能听到吗？当双方都确认能听到之后，再开始交谈。

4. 无连接就像写信，我也不知道你能不能收到，我就是想给你寄信，可能寄了十封信，只到了八封，并且可能到的时间还是乱的。

1.3 理解两者区别：

1. 根据面向连接与无连接的区别，其实我们就可以去很好的理解TCP与UDP的区别，无连接的通信由于不需要建立连接，所以不会保证数据的有序性，正确性，并且同时可以给多个目标地址发送信息。

2. 至于为什么TCP传输速度慢，其实就是因为TCP需要去建立连接，并且要保证数据发送的可靠性，有序性，并且还有重发机制，为了保证数据的正确性，当然需要耗费一定的时间。所以TCP要求的系统资源肯定偏多。

二.TCP三次握手

2.1 三次握手的目的

• 三次握手的目的当然是为了建立连接了，让双方都确认收发正常，建立可靠的连接

2.2 三次握手的过程

• 第一次握手：主机A向主机B发送一个含有同步序列号的标志位的数据段，向主机B请求建立连接，通过这个数据段，A告诉B两件事：我要和你建立连接，你可以用哪个序列号作为起始数据段回应我
• 第二次握手：主机B收到主机A的请求后，返回一个带有确认应答（ACK）和同步序列号（SYN）标志位的数据段响应A，通过这个数据段，B告诉A两件事：我已经收到你的请求，你可以发送数据了，你可以用哪个序列号来回应我
• 第三次握手：主机A收到B的数据段之后，再发送一个确认应答，确认已经收到主机B的数据段：已经建立好连接了，我要开始发送数据了

三次握手简述：

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©。此时客户端处于 SYN_Send状态。
• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD的状态
• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised状态。
• 服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

2.3 为什么需要三次握手

2.3.1 原因一：A和B都要确认双方收发正常

• 第一次握手：A发送了数据段，A什么都确认不了，B可以确认A发送正常
• 第二次握手：B发送了数据段，A可以确认：自己收发正常，对方收发正常
  B可确认：对方发送正常，自己接受正常
• 第三次握手：A发送了数据段，A可以确认：自己收发正常，对方收发正常，B可以确认：对方收发正常，自己收发正常

2.3.2 原因二：A和B都要确认都支持TCP，要建立TCP连接

• 第一次握手：B接受到A的数据段之后，猜测A是要建立TCP请求，但是不确定，因为A可能是随便发送了一个数据包
• 第二次握手：通过ack=J+1，A知道B是支持TCP的，且理解了自己要建立TCP连接的意图。
• 第三次握手：通过ack=K+1，B知道A是支持TCP的，且确实是要建立TCP连接。

三.TCP四次挥手

3.1 四次挥手的作用

其实就是终止连接的作用

3.2 四次挥手的过程

• 第一次挥手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了。（关闭主机1到主机2的数据发送，但是没有接受回应之前还会重复发送）
• 第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求。
• 第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态。（关闭主机2到主机1的数据发送，没有收到相应应答之前还是会重复发送）
• 第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
  
  四次握手简述：
• 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
• 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态。
• 服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

3.2 四次挥手概述

• 第一次挥手：A告诉B，我没有消息要发给你了，我们要关闭连接了
• 第二次挥手：B告诉A，好的，我知道了，我同意关闭
• 第三次挥手：B告诉A，我这边要关闭了，询问一下你
• 第四次挥手：A告诉B，你关吧，当B收到之后就会关闭连接，A在2MSL中没有收到数据就代表正常关闭了。

3.3 为什么要time wait？为什么是2MSL

• 为了保证A发送的最后一个ACK报文能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
• MSL指的是任何IP数据报能够在因特网上存活的最长时间。假设现在一个MSL的时候，接收端需要发送一个应答，这时候，我们也必须等待这个应答的消失，这个应答的消失也是需要一个MSL，所以我们需要等待2MSL。
• 其实就是A发送的最后一个确认应答数据段是可能丢失的，如果丢失了，B就会重新发送之前数据段，那么A就可以重新确认，去关闭连接了。如果没有丢失，那么就在2MSL之后自动关闭。

常见面试题：

1、顺丰面试题：TCP，四次挥手如果改为三次怎么样？
答：最后的确认报文可能丢失，如果丢失了，对方无法收到确认关闭连接的报文，那么就无法关闭连接。
2、大疆面试题：TCP与UDP区别？
答：由于面向连接与无连接的特性，传输速度，数据可靠性，多对多的交互，数据的有序性，对系统资源的需求都是不同的。
3、阿里面试题：TCP和UDP的区别是什么，如果想发送即时消息应该用哪种协议？
答：即时消息当然是用TCP了
4、阿里面试题：TCP的连接建立和断开的过程，如何保证TCP发送的信息是正确的，且保证其先后顺序不被篡改？
5、顺丰面试题：TCP/UDP解释一下？
6、阿里面试题：TCP连接中的三次握手和四次挥手，四次挥手的最后一个ack的作用是什么，为什么要time wait，为什么是2msl。
答：最后一个ack是一个确认报文，对方收到之后就正常关闭连接。自己则等待2msl，如果对方正常关闭，则自己之后正常关闭。MSL指的是任何IP数据报能够在因特网上存活的最长时间，所以来回是2MSL。

本文参照该文撰写：https://blog.csdn.net/weixin_41835916/article/details/81413752