三次握手四次挥手（三次握手四次挥手过程）

大家好,今天就和大牛一起来看看这个问题吧 。三次握手四次挥手过程，三次握手四次挥手很多人还不知道，现在让我们一起来看看吧！

1、 TCP和UDP协议的区别：

2、 1.Home两者都是传输层的协议，所谓的“传输层”为两台主机提供端到端的通信，也就是从A-B。

3、 2.TCP协议可靠，UDP协议不可靠。即可靠性是指数据是否从A发送到B，能否保证数据真正到达B，TCP使用超时重传和数据确认来保证数据包正确发送到目的地，而UDP不能保证数据从发送方正确发送到目的地。如果数据在传输过程中丢失或目的地通过数据检查发现数据错误，UDP只是通知应用程序传输失败。对于TCP拥有的超时重传和数据确认，应用需要自己处理这些逻辑。

4、 3.TCP是面向连接的，而UDP是无连接的。这个也很好理解，因为TCP连接需要“三次握手，四次挥手”。

5、 4.TCP服务是基于流的，而UDP是基于数据报的。基于流的数据没有边界(长度)限制。对于基于数据报的服务，每个UDP数据报都有一个长度，接收方必须以该长度为最小单位一次读出其所有内容。

6、 5.当发送方多次执行写操作时，TCP模块会先将这些数据放入TCP发送缓冲区。当TCP模块实际开始发送数据时，发送缓冲区中等待发送的数据可能被封装成一个或多个TCP段并发送出去。因此，TCP模块发送的TCP段的数量和应用程序执行的写操作的数量之间没有固定的数字关系。同样，当接收端接收到一个或多个TCP段时，TCP模块将这些数据按照序列号依次放入TCP接收缓冲区(序列号描述见下面的TCP头结构)，通知应用程序读取数据。接收器可以选择从缓冲区读取数据一次或多次(取决于用户指定的应用程序读取缓冲区的大小)。所以接收方读取数据的次数和发送方发送的段数之间没有固定的数量关系。综上所述，对于TCP连接，发送方执行的写操作次数和接收方执行的读操作次数之间没有数据关系，这也是基于流的服务的特点。对于UDP服务，每次发送方进行写操作，都会封装成UDP数据报发送。同时，接收方必须根据发送的数据进行读取，否则会丢包。因此，对于UDP连接，发送方写入辅助数据的次数与其读取的次数相同，这也是基于数据报的服务的特点。

7、 6.TCP连接是一对一的，所以基于广播或组播的应用不能使用TCP，而UDP非常适合广播和组播。

8、 TCP报头结构

9、 16位源端口号和目的端口号。这个很好理解，就不多解释了。

10、 32位序列号：这个序列号是生成的随机值ISN加上该段携带的数据在整个字节流中的第一个字节的偏移量。例如，如果TCP段发送的数据是字节流中的第100 ~ 200个字节，则序列号为ISN 100。

11、 4位报头长度：标识TCP报头中有多少个32位字，因为是4位，也就是TCP报头最大可以代表15，也就是TCP报头最大可以代表60个字节。也就是说，它是用来记录标题的最大长度。

12、 6位标志位，包括：

13、 URG标志：指示紧急指针是否有效。

14、 ACK标志：确认标志。通常，携带ACK标志的TCP数据段称为确认数据段。

15、 PSH标志：它提示接收方程序应该立即从TCP接收缓冲区中读取数据，为接收后续数据腾出空间(如果不读取，数据将一直在缓冲区中)。

16、 RST:表示需要另一方重新建立连接。通常，携带RST标志的TCP段被称为复位段。

17、 SYN标志：表示请求连接。通常，带有SYN标志的TCP段称为同步段。

18、 FIN标志：结束标志，带有FIN标志的TCP段通常称为结束段。

19、 这些标志表示当前请求的目的，即做什么。

20、 16位窗口大小：表示当前TCP接收缓冲区可以容纳多少字节的数据，以便发送方控制发送数据的速度。这是TCP流量控制的一种方式。

21、 16位校验和：验证数据是否损坏，通过CRC算法进行校验。这种检查不仅包括TCP报头，还包括数据部分。

22、 16位紧急指针：正偏移量，当与序列号字段的值相加时，指示最后一个紧急数据的下一个字节的序列号。TCP的紧急指针是发送方向接收方发送紧急数据的方法。

23、 TCP报头选项：可变长度的可选信息。这部分最多包含40个字节。因为TCP头最多60个字节，固定部分占了20个字节。详情请参考《Linux高性能编程》 3.2.2。

24、 让我们先解释一下三次握手的过程：

25、 1.发送方发送一个连接请求。6位标志是SYN，同时携带自己的序列号(此时因为没有数据传输，所以不表示字节偏移量)，比如223。

26、 2.收到请求后，接收方同意连接，发送同意响应，并接受SYN ACK标志位。同时确认序列号为224(发送方序列号加1)，取自己的序列号(此时因为没有传输数据，所以不表示字节偏移量)，比如521。

27、 3.发件人收到确认信息，发回给收件人，表示我已经收到你的确认信息。此时标志仍然是ACK，确认序列号为522。

28、 那么我们来看看四波过程：

29、 1.发送方发送一个close请求，带有标志位FIN和自己的序列号(此时不传输数据，所以不表示字节偏移量)。

30、 2.接收方收到请求后会回复确认：ACK，确认序列号就是请求序列号加1。

31、 3.接收方也决定关闭连接，发送关闭通知，带有标志位FIN，还会带来步骤2中的确认信息，即ACK，确认序列号和自己的序列号。

32、 4.发送方回复确认消息：ACK，接收方序列号加1。

33、 问题涉及到：为什么是三次握手，而不是四次或两次？

34、 首先解释一下为什么不是四次。四次的过程是这样的：

35、 发件人：我会联系你的。

36、 接收器：好的。

37、 接收器：我准备好了，请连接。

38、 发件人：好的。

39、 显然，接收方已经准备好连接，并且同意可以合并连接，这样可以提高连接的效率。

40、 还是那句话，我们来解释一下为什么不是两次。其实很好理解。我们知道TCP是全双工通信，它也是可靠的。连接和闭合必须在两侧进行才能真正完成。同时，有必要确保双方已经执行了连接或关闭。如果只有两次，过程是这样的：

41、 发件人：我会联系你的。

42、 接收器：好的。

43、 显然，接收者不知道也不能保证发送者会收到“好”的消息。一旦接收者真的收不到这条消息，接收者和接收者之间就会出现“单边连接”。此时，发送方将尝试再次发送连接请求，直到在连接完成之前实际收到“好”消息。连续三次，如果发送方没有等待你的回复确认，就不会真正接通，会重试确认请求。

44、 问题涉及：为什么你需要四次握手而不是三次？

45、 三次的过程是这样的：

46、 发件人：我不会再给你发数据了。

47、 收件人：好的，我也不给你发了。

48、 发件人：好的，再见。

49、 这是因为当接收器接收到关机请求时，它的立即响应是确认关机。这里确认的是接收方的关机，即发送方不再向接收方发送数据，但仍能接收接收方发送给他的数据。接收方是否需要关闭“向发送方发送数据”的通道取决于操作系统。操作系统也可能在睡眠几秒钟后关闭。如果合并为三次，接收方可能无法及时收到确认请求，导致超时重试。所以需要四次。

这篇文章到此就结束，希望能帮助到大家。