你们好，最近小艾特发现有诸多的小伙伴们对于tcp三次握手过程分析，tcp三次握手过程这个问题都颇为感兴趣的，今天小活为大家梳理了下，一起往下看看吧。

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.发送方发送连接请求，带有SYN的6位符号和自己的序列号(此时不是指字节偏移量，因为不传输数据)，比如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、 直到实际收到“OK”消息，连接才完成。连续三次，如果发送方没有等待你的回复确认，就不会真正接通，会重试确认请求。

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

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

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

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

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

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

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

62、 因此需要四次。

以上就是tcp三次握手过程这篇文章的一些介绍，希望对大家有所帮助。