三次握手四次挥手什么意思（三次握手四次挥手）

大家好，小活来为大家解答以上问题。三次握手四次挥手什么意思，三次握手四次挥手很多人还不知道，现在让我们一起来看看吧！

1、 TCP和UDP协议的区别；

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

3、 2.TCP协议可靠，UDP协议不可靠。可靠性是指数据从A发送到B，是否能保证数据真正到达B.TCP协议使用超时重传和数据确认来确保数据包被正确发送到目的地。

4、 然而，UDP协议不能保证数据从发送方正确传输到目的地。如果数据在传输过程中丢失或者目的地通过数据检查发现数据错误，UDP协议只是通知应用程序传输失败。

5、 对于TCP协议，超时重传，数据确认等等都需要应用自己处理。

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

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

8、 5.当发送方多次执行写操作时，TCP模块会先将这些数据放入TCP发送缓冲区。当TCP模块真正开始发送数据时，这些在发送缓冲区中等待发送的数据可能会被封装成一个或多个TCP报文段发送出去。因此，

9、 TCP模块发送的TCP段数量和应用程序执行的写操作数量之间没有固定的关系。类似地，当接收端接收到一个或多个TCP数据段时，

10、 TCP模块将这些数据按照序列号依次放入TCP接收缓冲区(见下面的TCP头结构)，通知应用程序读取数据。

11、 接收器可以选择从缓冲区读取数据一次或多次(取决于用户指定的应用程序读取缓冲区的大小)。因此，接收方读取数据的次数与发送方发送的消息段数之间没有固定的数量关系。综上所述，即对于TCP连接，

12、 发送方执行的写操作次数和接收方执行的读操作次数之间没有数据关系，这也是基于流媒体服务的一个特性。对于UDP服务，每次发送方进行写操作，都会封装成UDP数据报发送。

13、 同时，接收方必须根据传输进行读取，否则会丢包。所以对于UDP连接，发送方写的二次数据和读的次数是一致的，这也是基于数据报的服务的特点。

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

15、 TCP报头结构

16、 16位的源端口号和目的端口号很好理解，不需要我过多解释。

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

18、 那么序列号就是ISN 100。

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

20、 6位标志，包括：

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

22、 确认标志：确认标志。带有ACK标志的TCP数据段通常称为确认数据段。

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

24、 RST符号：表示需要对方重新建立连接。带有RST标志的TCP报文段通常被称为复位报文段。

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

26、 FIN标志：结束标志，通常称为TCP段，以FIN标志作为结束段。

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

28、 16 位窗口大小：表示当前TCP 接收缓冲区还能容纳多少字节的数据，这样发送方就可以控制发送数据的速度，它是TCP 流量控制的一个手段。

29、 16 位校验和：验证数据是否损坏，通过CRC 算法检验。这个校验不仅包括TCP 头部，也包括数据部分。

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

31、 TCP 头部选项：可变长的可选信息，这部分最多包含40 字节，因为TCP 头部最长是60 字节，所以固定部分占20 字节。这里不做详细介绍，可以参考《Linux高性能编程》 3.2.2

32、 先来解释三次握手过程：

33、 1、发送端发送连接请求，6位标志为SYN，同时带上自己的序号（此时由于不传输数据，所以不表示字节的偏移量），比如是223。

34、 2、接收端接到请求，表示同意连接，发送同意响应，带上SYN + ACK 标志位，同时将确认序号为224（发送端序号加1），并带上自己的序号（此时同样由于不传输数据，所以不表示字节的偏移量），

35、 比如是521。

36、 3、发送端接收到确认信息，再发回给接收端，表示我已接受到你的确认信息，此时标志仍为ACK，确认序号为522。

37、 接着我们来看看四次挥手过程：

38、 1、发送方发送关闭请求，标志位为：FIN，同时也会带上自己的序号（此时同样由于不传输数据，所以不表示字节的偏移量）。

39、 2、接收方接到请求后，回复确认：ACK，同时确认序号为请求序号加1。

40、 3、接收方也决定关闭连接，发送关闭通知，标志位为FIN，同时还会带上第2步中的确认信息，即ACK，以及确认序号和自己的序号。

41、 4、发送方回复确认信息：ACK，接收方序号加1。

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

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

44、 发送方：我要连你了。

45、 接收方：好的。

46、 接收方：我准备好了，你连吧。

47、 发送方：好的。

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

49、 再来，我们解释为什么不是两次。其实也比较好理解，我们知道TCP 是全双工通信的，同时也是可靠的，连接和关闭都是两边都要执行才算真正的完成，同时还需要确保两端都已经执行了连接或者关闭。如果只有两次，

50、 过程是这样的：

51、 发送方：我要连你了。

52、 接收方：好的。

53、 很明显，接收方并不知道也不能保证发送方一定接收到“好的” 这条信息，一旦接收方真的没有收到这条信息，就会出现接收收“单方面连接”的情况，这个时候发送方就会一直重试发送连接请求，

54、 直到真正收到“好的” 这条信息之后才算连接完成。而对于三次，如果发送方没有等待到你回复确认，它是不会真正处于连接状态的，它会重试确认请求。

55、 涉及到的问题：为什么需要四次握手，不是三次？

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

57、 发送方：我不再给你发送数据了。

58、 接收方：好的，我也不给你发了。

59、 发送方：好的，拜拜。

60、 这是因为当接收方收到关闭请求后，它能立马响应的就是确认关闭，它这里确认的是接收方的关闭，即发送方不再发数据给接收方了，但他还是可以接收接收方发给他的数据。

61、 而接收方是否需要关闭“发送数据给发送方”这条通道，取决于操作系统。操作系统也有可能sleep 个几秒再关闭，如果合并成三次，就可能造成接收方不能及时收到确认请求，可能造成超时重试等情况。

62、 因此需要四次。

本文到此结束，希望对大家有所帮助。

免责声明：本文由用户上传，如有侵权请联系删除！