TCP-IP协议"三次握手"可靠性分析

       我们知道TCP协议是一种面向连接，通过“三次握手”机制而建立的可靠的传输协议。下面来了解一下“三次握手”机制是如何实现可靠的：

       现实错综复杂的网络，让每一次请求响应都充满了不确定性，而“三次握手”机制也是从请求和响应来实现它的目标的。假设网络正常，我们来看看“三次握手”机制的执行流程：

SYN 是英文同步synchronize的缩写；ACK是英文acknowledgement的缩写。

       从上图可以体会的到，请求的发起方先发送一个编号为0的SYN包到接收方，接收方接收到这个SYN包之后，首先肯定是要通知发送方我已经接受到了你的SYN请求，也就是我们上面说的ACK。但同时按照上面描述的，如果想建立连接，就必须发送SYN，所以，对于接收方，就有两个需要发送的包，亦或是说两个被置不同标识的包，但是很明显，这两个包是可以合并的，所以说，发送方就会发送一个TCP包，这个包里，SYN位和ACK位同时被置上。回到发送方，在接收到这个对端发送来的SYN包之后，同样要回一个ACK包给对端。此时，TCP连接就建立好了，后面的通信中，两端就可以自由的发送数据和消息了

       然而，现实网络往往不如所愿，三次握手过程中每次发的消息，都有可能出现丢失、延迟到达、重复这三种情况，任何一种情况都可能会让建立连接失败。那么，“三次握手”机制是如何实现可靠建立的呢？

       在TCP中，发送消息的时候会启动一个计时器，这个计时器在收到相应回复的时候会重置而重新计时，而如果一直没有收到相应的回复，在计时器到期的时候发送端就会重发消息，这是TCP重传机制里面第一层的保障。

因为TCP发起连接的时候只有三条消息，所以丢失也就三种情况：

第一个SYN消息丢失，即发起者的发起请求丢失了，所以接收者也就不会回送SYN-ACK消息，因为他没有得消息刺激他回应。所以过一段时间后发起者发现自己没有收到回应消息，于是在计时器到期后，发起端会重发SYN消息。如果在经过了几次重传仍然没有成功以后，尝试连接过程就终止了。

第二个SYN-ACK消息丢失，发送端本质上和上一种情况相同。接收者因为确实已经收到了SYN消息并发送了回复消息，所以其计时器已经启动了。在计时器到期之后，接收端会重发SYN-ACK消息，如果几次之后还没有成功，那么接收端会发送RST终止连接。

第三个来自发送端的ACK丢失，接收端本质上会上一种情况相同，最终会发送RST消息终止连接。

在linux的TCP-IP协议的实现中，分别使用两个不同的计时器，在发送端启动是普通的超时计时器，在接收端启动的是SYN-ACK计时器。超时计时器就是在发送端发送SYN的时候开始计时，默认是1秒，如果过了1秒没有收到确认，会再次发送SYN，然后将计时器设置成为2秒，然后依4秒，8秒，16秒，以此类推。当然，在代码中有一个重试上限，在linux上的默认是设置为5次。同样的SYN-ACK计时器在接收端接收到SYN之后发出SYN-ACK消息之后启动，间隔和重试次数和普通计时器都是一致的，当然他会做一些其他的事情所以和普通计时器是有一些区别的。

我们考虑实际中的情况二，发送端发送SYN后未收到SYN-ACK消息，同时启动计时器A，过了一小段时间之后，接收端接收到了SYN消息，启动计时器B，发送SYN-ACK消息，但是这个消息丢失了。1秒钟后，发送端由于A到期，重发SYN，而几乎与此同时接收端也会由于B到期重发SYN-ACK消息。那么问题来了，假设这个时候重发的SYN又一次成功的到达了接收端会怎样？答案很简单，接收端会忽略它，因为seq序号重复了。接收端既不会再一次发送SYN-ACK消息，也不会重置计时器。于是就避免不断重复的重发，造成网络混乱甚至崩溃。

如果用一句话总结的话，就是通过超时计时器和序号的重复检测

       计时器和序号机制，计时器是解决响应超时重新发包(重传机制)，序号机制是指再次发出的数据包标记序号和上一次的数据包是一样的。同样的序号的数据包被接收方接收到后，可以忽略不做任何响应。这两个机制避免不断重发，造成网络混乱甚至崩溃。