必须跟你说点事《TCP 三次握手》

第一次获取的信息往往是印象最深刻的。但是这有一个问题，如果你看到的第一手资料是错误的。后期更正很难，前期费尽周折的去按照这个思路理解，理解通了。结果某天发现不是很准确，这种情况很让人苦恼。

最近在看TCP三次握手，就是这样的一个故事。
很多人在白话解释三次握手时，说是为了更好的沟通。比如下面这位：

第三次对话：

甲刚和乙打了个招呼，突然老婆喊他，“你个死鬼，打个酱油咋这么半天，看我回家咋收拾你”，甲是个妻管严，听完吓得二话不说就跑回家了，把乙自己晾那了。乙心想：这什么人啊，得，我也回家吧，沟通失败。说明甲无法做出应答的情况下沟通失败。

如果甲也做出了正确的应答：我也吃了。那么第三次对话成功，两人已经建立起了顺畅的沟通渠道，接下来开始持续的聊天。

通过第二次和第三次的对话证明了甲能够听懂乙说的话，并且能做出正确的应答。

可见，两个人进行有效的语言沟通，这三次对话的过程是必须的。

同理对于TCP为什么需要进行三次握手我们可以一样的理解：

为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

反正我按照这个思路是看不懂的。

从最官方，也就是教材上看到的来说，正确的解释应该是这样的：

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”
这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。 在Google
Groups的TopLanguage中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是,
信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值.
所以三次握手不是TCP本身的要求, 而是为了满足”在不可靠信道上可靠地传输信息”这一需求所导致的. 请注意这里的本质需求,信道不可靠,
数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的,
即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息,
那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。

翻译过来就是一下场景：

A-B: 开门 syn
B-A: OK.(ack)你现在还在等我开门吗？(syn)
A-B: 废话，快打开吧。(ack) （此时B才打开连接）
A进门了: 开始交谈。  （然后A开始向B发送数据）

这样，就解决了以下延时造成的资源浪费问题。

A-B: 开门(syn)
B-A: OK,(ack)你现在还在等我开门吗？(syn)
A-B: 不说话。(A无反应，B意识到听到A说开门是一天前的事了)
B: 开毛线们，不开了。(既然是一天前的事了，那现在开门等于浪费资源，不开了)

也就是说，三次握手是认为网络传输是不可信的。
这是为了解决这样的场景：A请求B连接的数据包延时发送，等到B接收的时候A已经不想连接了。如果只有两次握手，那么B把listen打开就是浪费资源。A不想连接的网络表现为：B发来syn询问，A不理，记住，是不理，而不是发送FIN标志。
这里就有一个问题：B如何确保他的询问是发送到A了。当收到A的ack时，表明B发送成功了，此时也打开了连接。如果没有收到A的反应，那么会重新发送。重新发送的次数在系统中有默认的次数限制。
这一点，在百度百科中说的很明白。

未连接队列
在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于
Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

Backlog参数 表示内核为相应套接字排队的最大连接个数。SYN-ACK重传次数

三次握手协议
服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。

参考资料

• 三次握手，百度百科
• TCP连接建立过程中为什么需要“三次握手”
• 简析TCP的三次握手与四次分手