TCP协议的三次握手与四次挥手

网上有很多类似的博客，但是都觉得说的不够细致，甚至有错误，因此这里个人总结一下。

TCP连接的建立：三次握手

1.TCP首部的几个标志位

下面列出6个标志比特中的4个：

标志	字符缩写	标志位功能描述
S	SYN	同步序号的标志，只有SYN为1的时候，TCP报文中才能携带序号信息。因此很多解释的文章中会将序号段称为SYN段，但是要注意，SYN只是类似一个开关的东西，他并不是序号本身。另外，SYN有效（即SYN==1），说明要开始建立连接
F	FIN	FIN如果有效，则代表发送方完成了数据的发送
R	RST	复位连接
P	PSH	尽可能快的将数据送往接收进程

2.建立连接的过程

先来个图：



现在就上面两个图来解释一下一些疑问：

首先是，seq，也就是序号，它的产生问题。即序号选择问题：

以下引自《TCP/IP协议详解：卷一》：

在4.4BSD（和多数的伯克利的实现版）中，系统初始化时初始的发送序号（即SEQ）被初始化为1，这种方法违背 了Host Requirements RFC。这个变量每0.5s增加64000，并每隔9.5h又回到0（对应这个计数器每8ms加1，而不是每4ms加一）。另外，每次建立一个连接后，这个变量将增加64000。

连接建立的超时问题。

对应上图，我们不仅要思考这样一个问题，如果客户端发送了SYN之后，服务器不予理会，客户端会如何处理，下面就是该问题的解释：（下面还是以《TCP/IP协议详解：卷一》为参考）：BSD版的TCP软件采用500ms的定时器，第一次超时时间为5.5秒到6秒之间，后面的超时时间几乎准确的为24秒。

三次握手的过程都干些什么？

首先，客户端在发送第一个SYN段的时候（因为SYN有效，即SYN==1意味着开始建立连接，所以我们将客户端发送的这个报文成为SYN段（有些地方称为SYN包，只是称呼不同而已），注意不要跟SYN标志位搞混了），会在报文中指定要连接的服务器的端口号、滑动窗口长度和开始的序号SEQ（有些地方叫ISN）。然后，服务器收到请求包，通过检查SYN为1，认为这是一个初始化连接的请求，就会回应这个SYN，同时发送自己的SYN段（即服务器对客户端的回应包），此时需要SYN标志位要置位，并且要在回应包中通告初始序列号和滑动窗口大小等等信息。最后,客户端不在发送SYN置位的报文，只是发送ACK确定报文即可。

如果只是2次握手会发生什么情况？

这也是一个面试经常问到的问题，首先对于这个问题，我认为有两种理解方式：一是TCP协议设计成2次握手建立连接的方式；二是还是3次握手才建立连接，不过在建立过程中只是发生了2次握手。

首先对于第一种理解方式，网上有各种解释，比如说，如果只是握手2次，当第二次握手的时候，假设因为延迟客户端没有收到ACK，那么客户端会认为没有成功建立连接，而服务器端会认为成功建立连接，这样会导致客户端重复发送SYN包，而服务器端却开始传送数据包，从而导致死锁问题。对于这种解释，却有这样一个悖论，那就是，客户端没有收到ACK，那么它会认为连接未建立，从而忽略服务器发来的任何数据分组，只是等待ACK的到来，同时，服务器发出的分组没有被客户端接收，那么它会重复发送分组，这样就产生了所谓的死锁问题。

对于这个问题，网上有一个校评：服务器重复发送分组，客户端重复发送SYN，那么服务器端收到SYN之后，自然会发送确认分组，这样就不会形成死锁。从而产生了一个悖论。详细点击这里

还有另外一种从性能方面分析的解释：我们应该知道，现在我们正常的服务器建立socket通信进程是在第三次ACK之后，如果TCP协议被设计成2次握手就建立连接，即2次握手就建立socket通信进程，那么当客户端没有收到服务器的ACK，他会超时重发，而此时服务器端已经花费资源建立好socket通信进程，然后等到又收到客户端超时重发的SYN时，就可能会拒绝这次重发请求，这样一方面可能导致连接建立失败，另一方面肯定会导致服务器端资源的浪费。详细点击这里

其次，对于第二种理解，很好解释，因为服务器接到SYN之后，会从监听状态进入RCVD状态，同时启动计时器，在一定时间之后，服务器如果没有收到ACK，那么会重发SYN+ACK并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout。

参照：



图片地址：无影的博客。

2.四次挥手断开连接

图示（TCP连接终止时对应的状态）：



2MSL（报文段最大生存时间）等待状态：

当TCP执行一个主动关闭时，并发回最后一个ACK，该连接必须在Time_wait状态停留的时间为2倍的MSL，这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时会重发最后的FIN）。因此也把 TIME_WAIT 状态称为2MSL状态。