自己理解的TCP三次握手-编程知识

自己理解的TCP三次握手

news/2024/9/21 3:17:09/文章来源:https://www.cnblogs.com/seamount3/p/18299441

### TCP 三次握手过程是怎样的？

TCP的建立连接是通过三次握手来进行的。三次握手的过程如下图：

说实话这个很好理解,我称之为N字型

首先我们理解到建立连接是一个虚的概念了对吧?那么我们来设计一个可靠的TCP,首先建立连接是必须的吧?相当于我们打电话,总要先说一句喂---wei?(面向连接正是这个意思!)

那么这里顺便谈谈他们很爱问的一个问题

为什么是三次握手？不是两次、四次？

首先你(客户端)要和我(服务端)打电话,我们再要说出内容时,都需要先确定下,网络如何?对方能否听到吧?

而上图中蓝色的SYN相当于就是问候服务器能否听到,然后服务器的ACK对应的就是我能听到,

而这里我们说的"我能听到"在现实中映射到TCP中就代表着ACK而且是SYN,因为接下来对方会回复你说"好"或者说"原本要和你说的内容"也即是绿色的ACK

然后两次的话,是必然不可行的,双方都确认对方能接收信息才能说这个连接建立成功,那么能准确证明两个不行吗?首先要双方都确认必然要2SYN和2ACK,那么很明显两个ACK的分配,要么(1,1),要么(2,0)这里2,0可以顺序相反,(2,0)意味着单方发出两个ACK必然不行!(1,1)意味着双方都发ack,那么必然在时间上有交错,因为同时发的话,这个ack就没用了,ack有用的前提是收到syn后再发,同时时间交错则也只能保障单次ack生效,在前发的ack无效

所以证毕,至少三次握手

那么四次可行吗?肯定可以啊,不谈那些不太荒唐的,你把server的ack和syn拆分后就可以了,只不过比较浪费带宽

到此如果要实现上述功能我们只需要SYN和ACK便够了,那么又为何带上SeqNum呢?以及ACK的时候要对应的+1呢?仅仅是说对暗号的情况吗?因为我们计算机会维持多个tcp连接,通过这个来知道他对应的是哪个连接吗?是的,但是仅此而已吗?

所以更深层上三次握手还能实现其他功能:

三次握手才可以阻止重复历史连接的初始化（主要原因）
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

阻止历史连接的初始化

下面是小林的解释,我来用我自己的话,来让自己更好地了解,首先情况是服务端seqNum为90的这个报文发送后,重启了那么又重新想向服务端建立连接,所以发了个新的seqNum为100,如果90的报文仍然到达了服务端,那么服务端会再发送90对应的90+1的ACK+SYN,那么这时你客户端不就可以确认了吗?你就会弄一个RST位为1的报文,给服务端,效果类似说"打错了",然后之后100的服务端会再发送100+1,

同理我们这个"N"的下一个折角处也是可以防止服务端重启后,这个SYN+ACK导致的历史链接的问题

三次握手避免历史连接

然后值得注意的一点是,如果服务端收到客户端报文的顺序是：「旧 SYN 报文」->「新 SYN 报文」

那么服务端并不是说同样地给这个返回RST,因为谁是挑战者不好说!对他来讲90可能是新的也可能是旧的,100同样,所以他采用的是认定先来的

所以他返回的是ChangeACK报文给客户端,这个 ack 报文并不是确认收到「新 SYN 报文」的，而是上一次的 ack 确认号，也就是91（90+1）。说白了,解玲还需系铃人,所以这个RST报文只能由他们的原先发送者确认是否结束

同步双方初始序列号

接收方可以去除重复的数据；
接收方可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中，哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。