众所周知，tcp握手三次建立连接，但断开连接需要挥手四次。 为什么需要挥手4次？ 另外，是否需要wait1和wait2这样多的wait状态？ 这是因为在建立连接时，发送和接收都是“纯”的，而客户端发送syn时，服务器不需要发送任何数据，只要发送synack即可，反之，连接终止的握手则不是由于tcp是全双工的，连接终止必须由一方开始，因此当一方开始连接终止的握手时，另一方可能正在向终止的握手开始方发送数据。 fin的ack可以带走这个数据，也可以用其他方法发送ack。 接收fin的过程可能原本就不在接收或发送中。 在这种情况下，接收方的ack一定是从协议栈发送的。 但是，必须让APP知道对方正在关闭tcp的消息后，APP才能决定怎么办。 因此，不能期待fin的ack中一定会有其他的fin。 以套接字实现为例，在建立连接时，客户端的connect始终在中，服务器端有处于侦听状态的套接字等待从客户端接收syn消息，但要终止连接，客户端和服务器端必须完全
是主动发送fin，还是被动接收fin后发送fin，tcp连接关闭时两端的状态机会发生切换，主动发送fin的一侧在发送fin后进入等待1状态，接着从对方发送ack 在等待2中，从对方接收到fin时，进入time-wait状态。 之所以有等待2和时间等待，是因为对方接收到fin和关闭连接之间存在时间差，最后一次ack可能会丢失，fin可能会重新发送给对方。 在某些情况下，对方的发送缓冲区中的数据可能尚未发送，或者对方可能会重新发送fin。 在任何情况下，tcp的可靠性在此时都无法充分发挥，因此只能减少时间，当然也可以将超时时间同时设置为等待时间和等待时间状态。 超时时间过后，连接将断开并回收资源。
最后，说明连接断开阶段的问题。 客户端主动断开后经过一系列阶段最终进入time-wait，服务器发送到客户端的序列号之一是s数据d临时存储在中间路由器上，客户端的time-wait超时时，客户端仍然相同此时，客户端正在尝试接收序列号为s的数据。 是不是很混乱？ 如果此临时保存的数据是服务器因上次未从客户端接收到最后一次ack而重新发送的fin数据包，则客户端会认为服务器已断开。 因此，它还解释了为什么需要时间等待，并且在客户端启动连接时会随机生成序列号。