参考文章

Why do we need a 3-way handshake? Why not just 2-way

https://blog.csdn.net/qq_36903042/article/details/102656641

https://blog.csdn.net/qq_36903042/article/details/102513465

大部分网络博客的错误解读

首先需要声明的是，百度搜索到的大部分网络博客关于这个问题的解答都是不清晰或者不准确的。讨论这个问题的大部分博客都会引用《计算机网络》的内容：

防止已失效的连接请求又传送到服务器端，因而产生错误

不幸的是，这种解释是不准确的， TCP 采用三次握手的原因其实非常简单，远没有大部分博客所描述的那样云山雾绕。

为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤

如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认

先修知识

TCP 通信流程

TCP 的通信流程

上图中的每一个箭头都代表着一次 TCP数据包的发送

需要注意的是，上图中出现的 ACK = x +1 的写法很容易让人误以为数据包中的 ACK 域的数据值被填成了 y+1 。 ACK = x+1 的实际含义是：
- TCP 包的 ACK 标志位（1 bit）被置成了 1
- TCP 包的确认号（acknowledgement number ）的值为 x+1
类似的， TCP 数据包中的 SYN 标志位，也容易与序号（sequence number）混淆，这点需要读者注意

TCP 数据包结构图

为什么 TCP 需要握手这个操作

在解答为什么 TCP 需要三次握手，而不是两次之前，首先需要回答的问题是:

为什么需要握手这个操作，能不能不握手？

如果读者对比一下 UDP 的通信流程和 TCP 的通信流程，可以发现，在 UDP 协议中，是没有握手这个操作的。

这里就引出了 TCP 与 UDP 的一个基本区别， TCP 是可靠通信协议，而 UDP 是不可靠通信协议。

TCP 的可靠性含义：接收方收到的数据是完整，有序，无差错的。
UDP 不可靠性含义：接收方接收到的数据可能存在部分丢失，顺序也不一定能保证。

UDP 和 TCP 协议都是基于同样的互联网基础设施，且都基于 IP 协议实现，互联网基础设施中对于数据包的发送过程是会发生丢包现象的，为什么 TCP 就可以实现可靠传输，而 UDP 不行？

TCP 协议为了实现可靠传输，通信双方需要判断自己已经发送的数据包是否都被接收方收到，如果没收到，就需要重发。为了实现这个需求，很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。

发送方在发送数据包（假设大小为 10 byte）时，同时送上一个序号( 假设为 500)，那么接收方收到这个数据包以后，就可以回复一个确认号（510 = 500 + 10）告诉发送方 “我已经收到了你的数据包，你可以发送下一个数据包，序号从 510 开始” 。

这样发送方就可以知道哪些数据被接收到，哪些数据没被接收到，需要重发。

为什么需要三次握手，而非两次

正如上文所描述的，为了实现可靠传输，发送方和接收方始终需要同步( SYNchronize )序号。需要注意的是，序号并不是从 0 开始的，而是由发送方随机选择的初始序列号 ( Initial Sequence Number, ISN )开始。由于 TCP 是一个双向通信协议，通信双方都有能力发送信息，并接收响应。因此，通信双方都需要随机产生一个初始的序列号，并且把这个起始值告诉对方。

于是，这个过程就变成了下面这样。

下面这个流程图描述的和上面一样，但是更加清楚的展示了 TCP 数据包标志位，以及数据域的命名来源。

AliceBobSYN =1 ， seq = xSYNchronize with my Initial Sequence Number of xSYN =1, ACK = 1, seq = y , ack = x+1I received your ISN, I ACKnowledge that I am ready for [x+1]SYNchronize with my Initial Sequence Number of yACK =1 , seq = x+1, ack = y+1I received your syn, I ACKnowledge that I am ready for [y+1]AliceBob

题外话

有一位读者关注到了三次握手中，序列号变化的问题，让笔者临时想起了曾经困扰自己的一个问题

为什么三次握手最后一次握手中，在上面的示意图中回复的 seq = x+1 。

答案：（此处感谢 “楚天千里清秋” 的提醒，进行了修正）

acknowledgement number 的作用是向对方表示，我期待收到的下一个序号。如果你向对方回复了 ack = 31, 代表着你已经收到了序号截止到30的数据，期待的下一个数据起点是 31 。

TCP 协议规定SYN报文虽然不携带数据，但是也要消耗1个序列号，所以前两次握手客户端和服务端都需要向对方回复 x+1 或 y+1 。

值得注意的是，如上图所说，最后一次握手在默认不携带数据的情况下，由于SYN 不是 1 ，是不消耗序列号的。所以三次握手结束后， 客户端下一个发送的报文中 seq 依旧是 x+1，示意图如下

注意到，上图第四步发送的 seq 和第三次握手的 seq 是一样的，体现了最后一次握手，默认不消耗序列号的特点。

TCP握手过程(正解版)相关推荐

pythonsocket中tcp通信接收不到数据_TCP 为什么三次握手而不是两次握手（正解版）...
先说结论为了实现可靠数据传输, TCP 协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的. 三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已 ...
TCP 为什么三次握手而不是两次握手（正解版）
参考文章 Why do we need a 3-way handshake? Why not just 2-way 大部分网络博客的错误解读首先需要声明的是, 百度搜索到的大部分网络博客关于这个问题 ...
TCP协议：三次握手过程详解
本文通过图来梳理TCP-IP协议相关知识.TCP通信过程包括三个步骤:建立TCP连接通道,传输数据,断开TCP连接通道.如图1所示,给出了TCP通信过程的示意图. 上图主要包括三部分:建立连接.传输数 ...
TLS/SSL 工作原理及握手过程详解
目录前言 TLS/SSL 基础概念密钥协商过程中存在的问题及解决办法 TLS/SSL 握手过程前言本文是对 HTTPS 安全基础.TLS/SSL 工作原理及握手过程的总结.第一部分介绍为 HT ...
当连接一个 IP 不存在的主机时，TCP握手过程是怎样的？
最近前同事去字节跳动面试,被问到了下面这个问题: 连接一个 IP 不存在的主机时,握手过程是怎样的? 连接一个 IP 地址存在但端口号不存在的主机时,握手过程又是怎样的呢? 这让我回想起曾经也被面试官 ...
java socket 握手_TCP建立连接三次握手过程详解(wireshark截图、java socket源码)
TCP(Transmission Control Protocol传输控制协议)是一种面向连接的.可靠的.基于字节流的传输层通信协议. 三次握手协议建立连接图握手过程步骤如下(配wireshark分 ...
HTTPS篇之SSL握手过程详解
由于最近接触到的一个项目数据有些敏感,所以需要通过加密算法保证数据的安全性.由于公司之前有一套自定义传输协议并且有配套的公共代码导致客户端人员不太愿意使用 WWS 协议.且之前的协议没有协议层的数据加 ...
TCP 三次握手过程详解
TCP(Transmission Control Protocol) 传输控制协议 TCP:面向连接的,可靠的,基于字节流的传输层通信协议 TCP(传输层)位于IP层(网络层)之上,应用层之下,不同的 ...
TCP通信过程详解以及tcp长连接和短连接
1. TCP连接当网络通信时采用TCP协议时,在真正的读写操作之前,server与client之间必须建立一个连接,当读写操作完成后,双方不再需要这个连接时它们可以释放这个连接,连接的建立是需要三 ...

TCP握手过程(正解版)

参考文章

大部分网络博客的错误解读

先修知识

TCP 通信流程

为什么 TCP 需要握手这个操作

为什么需要三次握手，而非两次

题外话

TCP握手过程(正解版)相关推荐

最新文章

热门文章