TCP的三路握手和四路挥手及其临界条件（结合系统调用）

一、TCP的三路握手：

其实这张图已经说得很清楚了，客户端应用程序调用connect导致TCP发送一个SYN报文段，服务器端有一个监听套接字，该监听套接字收到SYN后，在待连接套接字

队列中插入一项，然后发送SYN和对客户端确认的ACK(注意到ACK序列号总是目前等待接受的序列号相同，SYN占一个字节，所以在SYN的序列号J的基础上加1得到

ACK的序列号，如果是其他数据报文段，那么报文段实际长度为多少，确认序列号就在该报文段的序列号基础上加多少)。客户端接收到该SYN+ACK以后,connect就

成功返回，同时向服务端发送ACK。服务端接收到客户端发送的者三路握手中最后一个ACK之后，就将该连接从待连接套接字队列移到已连接套接字队列，等待accept

从已连接套接字队列中取出。注意到accept总是从对连接套接字队列执行pop操作，因此accept得到的总是三路握手已完成，连接已建立的套接字，可以说即使不调用

accept，这个已连接的套接字也已经存在于系统中。那么如果客户端在三路握手完成之后，accept调用之前crash掉怎么办，有些系统对accept之前crash掉的连接在

内核层面已经解决，所以accept不会看到这种状态的出现，另一些对已经crash掉的连接调用accept则返回ECONNABORT错误，因此，最保险的做法是检查

ECONNABORT错误，如果检查到该错误，直接进行下一次accept就行。

二、TCP的四路挥手：

从这个图可以看到客户端调用close，导致TCP发送FIN主动发起结束连接的第一次挥手，同时进入FIN_WAIT1状态，服务器端接收到这个FIN之后发送ACK同时

进入到CLOSE_WAIT状态，客户端接受到服务器对自己发送的FIN确认之后进入FIN_WAIT2状态，直到服务器程序也调用close导致TCP发送FIN，服务器进入

LAST_ACK状态，客户端接收到这个FIN之后，发送对服务器端ACK的确认，同时进入TIME_WAIT状态。注意到由于TCP的延迟确认机制，如果服务器接收到

客户端的FIN后，及时调用close，会使得对客户端的确认ACK和服务器自己的FIN同时发送，四路握手变为三路。首先看这个TIME_WAIT状态的必要性，第一，

假定客户端发送给服务器的最后一个ACK丢包（这是完全有可能的），此时服务器会不断重传最后一个FIN，而客户端已经没有关于这个连接的任何信息，因此

会导致服务器处于错误状态。第二，如果客户端另一个进程马上占用掉刚刚关闭的套接字端口号，此时服务器在上一个连接中发送的数据由于网络拥塞发生延时，

刚好到达该端口，被新的连接读取，就会出现串话现象。因此，这个TIME_WAIT状态一般持续2MSL时长，以保证上一个连接的所有报文都已发送完毕。和连接

操作永远是由客户端来主动发起的不同，主动关闭操作也可以由服务器来进行(例如WEB服务器)，因此当服务器应当避免TIME_WAIT的出现，或者缩短TIME_WAIT

的时延，因为每一个TIME_WAIT都是没有释放资源的连接，此状态过多会导致服务器资源消耗严重，而且由于服务器必要时需要极短时间内重启，TIME_WAIT也

会使得服务器的短时间内重启失败。

三、TCP连接中的一些临界情况：

(1)A,B两个主机上的进程a,b已经通过TCP建立连接c，然后拔掉B主机的网线，此时a进程会处于何种状态？

如果拔掉B的网线后a进程永远不通过c连接对b进程发送数据，那么a进程就永远不会知道这件事的发生，A主机上为a,b两个进程建立的连接将会永远存在，这就好像

a,b两个人只能通过有线电话联系，突然有一天连接到b的电话线断了，那么只要a不给b打电话，他就永远不知道b的电话线断了。这里有一个服务器编程中需要注意的

问题是，如果服务器程序一直只是监听客户端的请求并作出回复，那么如果客户端在连接建立之后出现这种断网、断电等情况，服务器将永远不会觉察到客户端挂掉的

状态，为挂掉的客户端建立的连接c将会永远存在(存在的连接是要耗费资源的)。那么如果a进程通过c给b进程发送数据呢？这时候TCP发送该数据，由于收不到b的确认，因此不断重传直到超时，(或者收到某个中间路由器回复的目的不可达），此时TCP就知道b已经挂了，就可以通知应用程序处理这个事件。这也是TCP中KEEPALIVE存在的意

义（如果一个连接上较长时间没有接受和发送数据，设置了KEEPALIVE选项的TCP会发送保活报文段，收到确认就当什么事儿也没有，如果超时或者收到destion 

unreachable，就通知应用程序处理该事件。那么如果拔掉网线后马上连接，而且保证此时a，b两个进程没有互相发送数据，会发生什么？答案是一切正常，就好像

a,b两个人的断掉的时候互相之间没有打过电话，等到他们打电话时，电话线已经被电信部门修好了，那么a，b就永远不知道电话线断掉的这个事情。

(2)A,B两个主机上的进程a,b已经通过TCP建立连接c，b进程一直在忙别的事情（比如阻塞在别的IO上面)，在此期间a进程调用了close，会发生什么？

如果b进程在忙完别的事情后马上读取c连接上的数据，那么读到FIN并调用close正常关闭连接。如果b进程还要往c连接上写数据会发送什么？第一次写数据是可以

正常进行的，因为TCP是双向连接，因此b接收到a的FIN会认为a不会再发送数据，但并不以为着不能向a写数据，a进程接收到b发送来的（非期望的）数据后，会给

b进程发送一个RST，只要b进程的下一次写操作发生在接收到a的RST之前，写操作一直会正常进行。知道接收到a的RST之后，在对a进行写操作，会返回返回EPIPE错误，

同时出发SIG_PIPE信号（默认终止进程），因此服务器程序一般要忽略SIG_PIPE信号，并对EPIPE错误进行处理。

（3）A,B两个主机上的进程a,b已经通过TCP建立连接c,此时B主机突然断电宕机，然后马上重启（假定b程序是开机自动启动的服务器程序），此时a进程往b进程写数据

会发生什么？由于B的宕机，b进程不会再crash时给a发送FIN，所以a进程在给b进程写数据之前是不会感知到这一现象，等到B主机接收到a进程发来的数据时（这是可以

的，因为B主机已经重启），b进程由于crash导致关于a，b之间的连接c的任何信息都已不存在，所以B主机找不到这样一个连接，因此会让a进程重新连接，a进程返回

ECONNREST错误。

四、TCP连接的状态转换图：