TCP的ACK机制

下面是整个的tcp的三次握手和四次挥手的协议

TCP四次挥手

在客户端先发送一个FIN的包，表示要close()，客户端想和连接断开，发完之后出于FIN_WAIT_1状态下；服务端收到之后就变成CLOSE_WAIT，发送ACK的确认消息，把缓冲区的数据进行发送完成，接着也要发送一个FIN 的包，代表着也要和客户端说“拜拜”。客户端收到FIN的包后变成WAIT_TIME状态。接着发送一个ACK给服务端，服务端收到后就closed了。

重点：客户端收到FIN的包后变成WAIT_TIME状态发送ACK包后，会等待2MSL。为啥会等待2MSL呢？ 1MSL时间内，客户端会不停发送ACK给服务端，对面如果没有响应，证明服务端已经关了。 万一服务端没有收到客户端发送的ACK，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。



ack的定义就是提醒向自己发送数据包的对端，下次发送给我，应该从ack位置的包进行发送。

假设客户端发送data，包的数量是1-100，那么服务端回送的ack则是从101开始。如果服务端回传的超时（或者有存在丢包情况），客户端就会重新发送这个包

TCP窗口滑动

只有在确认收到之后，才可以向后滑动。有了滑动窗口，ACK的机制也就发生了变化。



左侧是以前的机制，即发送完之后给你一个个回复过去；

右侧的话，会有一个delay ack，直到都发完了，才会进行回复，减少了带宽。

发送端窗口win是4096 ，MSS是最大报文大小，后面的报文最大可以存放多少字节