【Unix网络编程】TCP三次握手，四次挥手，TCP状态转换图以及各个api之间的关系

tcp最重要的就是3次握手和4次挥手，但是我们编程的api和3次握手4次挥手有什么关系，这篇文章带你好好梳理一下

首先先来看看tcp3次握手4次挥手的状态转换图，简单版的详细版的

1、简单版：

三次握手：正常的客户端连接服务器，首先就是发送一个syn的包给服务器表示请求连接服务器，然后服务器回复一个表示服务器已经准备好的ack(客户端syn+1)和一个syn，客户端也回复一个ack表示客户端也准备好了，这时3次握手完成，客户端和服务器进入连接建立的状态，可以进行收发数据

 

四次挥手：当客户端主动关闭连接时，会先发送一个fin给服务器，服务器接收到fin后也发送一个确认号ack给客户端，这是客户端这一端就关闭了（这时客户端就不会收发数据了，能接受服务器发送过来的数据，tcp是全双工的，需要一端一端的关闭），然后服务器处理完业务过后，想要关闭了，也发送一个fin给客户端，客户端收到后发送一个ack给服务器，表示ok，至此，该连接关闭

 

 为什么要进行三次握手，四次挥手呢？

首先要知道我们网络的 发送的报文可能因为网络状况丢失，或者不按时到达

为什么要三次握手，我们假设tcp协议的连接建立是2次握手会怎么样？

假如2次握手连接就已经建立的话，如果在网络中存在一个已经失效的请求报文到达服务器(可能是之前客户端超时重发的) ，那服务器接收到syn后会发送ack给客户端，并且认为连接已经建立，就往客户端发送数据，那这时客户端根本就没有响应，因为连接根本没有建立，只是服务器一厢情愿的认为，服务器就会一直等 ，浪费资源

 为什么要四次挥手呢？

因为关闭连接时，发送fin给对端，只是表示本端不再发送数据了，但是仍然能够接收对端发送来的数据，tcp连接时全双工的，双方都能够发送数据，当发送fin，接收到ack时，只关闭了一端，这时候时半双工状态， 另外一端不再发送数据也要关闭时，再发送fin对端，所以通常要进行4次挥手

在unix网络编程卷1中说到，第一次发送的fin时可能随发送的数据一起发送的。而且服务器回复的ack和fin都出自执行被动关闭的一端，是有可能被合并为一个分节，一次发送的，所以说关闭连接时“通常”是四次挥手

 

2、详细版：

观察详细 状态图的实线部分，就是正常的客户端的状态转换，虚线部分是正常的服务器的状态转换，执行主动关闭连接的 一端(这里指客户端发送fin主动关闭连接)进入time_wait状态，时间长达2MSL(MSL:最长分节生命期maximum segment lifetime，是任何IP数据报能够在网络中存活的最长时间)

为什么会 进入time_wait状态呢？

1）tcp是可靠的全双工连接，需要保证连接正常的终止

 假设最后服务器发送的fin客户端收到了，然后客户端发送给服务器的ack丢失在网络中了，服务器没有接收到最终的ack，触发超时重传机制，重新发送了一个fin给客户端，客户端这时接收到重传的fin，就会重新发送ack给服务器，这个时间段客户端需要维护之前的状态信息，如果客户端不维护之前的状态信息，就是响应一个RST(表示重置)，会被服务器认为这是一个错误，这就是tcp为了保证全双工连接两端都正常关闭的原因

2)tcp允许老的重复的分节在网络中消逝

首先要知道tcp协议中，time_wait状态下的连接不允许重新新建连接，假如客户端程序调用close关闭连接后退出程序，这时客户端处于 time_wait状态，然后立即重启这个客户端(相同的ip和端口，5元组确认一条连接(源、目的IP，源、目的端口，协议))，发送syn给服务器，tcp不允许time_wait下再新建连接，所以这个syn会消亡在网络中(2msl保证包能正常的消逝)

我们在这里假设没有time_wait的状态，关闭了老的连接，立即就建立了一个新的连接，tcp的协议栈是没法区别这是两条连接（因为5元组相同）， 他会认为是同一条连接， 如果老的连接之前的包在网络中姗姗来迟，那会被认为是新的连接的数据包，就会发送给应用层，就会造成混乱的情况，有了time_wait 状态并持续2msl，就会让 某个方向上的分组最多存活msl秒被丢弃， 另一个 方向的应答最多存活msl秒被丢弃，这样就能保证每成功建立一个tcp连接，老的重复分组都已在网络中消逝