TCP总结

tcp协议头部格式

确认应答机制

两种超时重传

发送数据时已经发生丢包

ack丢包

连接管理机制

三次握手

客户端向服务端发送SYN，申请建立客户端到服务端的连接
服务端返回ACK（第一次SYN的应答）和SYN，申请建立服务端到客户端的连接
客户端收到数据，状态置为ESTABLISHED，表示客户端到服务端连接建立完成，并且发送ACK（第二次SYN的应答），服务端收到数据，状态置为ESTABLISHED，表示服务端到客户端的连接建立完成
三次握手主要是为了检查当前网络的情况是否满足可靠运输的基本条件，同时也是在检测双方发送和接收数据的能力是否正常 

四次挥手

客户端发送FIN到服务端，申请关闭客户端到服务端的连接
服务端收到FIN状态置为CLOSE_WAIT，并返回ACK应答（这个动作是系统实现TCP协议栈默认执行的，不需要程序来调用代码）
服务端发送FIN到客户端，申请关闭服务端到客户端的连接（程序手动调用socket.close发送）
客户端收到FIN返回ACK应答，并进入TIME_WAIT时间等待状态，客户端等待一段时间后，状态置为CLOSED，服务端收到应答后，状态置为CLOSED

为什么服务端不将ACK和FIN合并一起发送，形成三次挥手呢？
答：主要是ACK和FIN的发送时机不同，ACK是操作系统内核响应的（立即执行），而此时服务端还可能在继续发送数据，待处理完数据后由程序调用close方法后才发送FIN

为什么客户端要等待一段时间状态才置为CLOSED，而不之间将状态置为CLOSED？
答：如果客户端给服务端的ACK丢包后，服务端得重新给和客户端发送FIN，此时客户端得给服务端应答，所以此时状态不能置为CLOSED，得等待一段时间（2MSL，MSL为网络上任意两点传输的最大时间）确保服务端收到客户端的应答 

流量控制

利用滑动窗口来提高利用效率

数据已经收到，返回的ACK应答丢包

发送数据的时候就已经丢包

当1001~2000这段报文丢失后，发送端一直会收到1001这样的ACK
如果发送端主机连续三次收到相同的ACK如1001应答，那发送端主机就会重新发送1001~2000数据。此时，接收端收到1001~2000数据后，再次返回的ACK应答就是7001了，因为2001~7000数据都已经接收到了，被放到接收端操作系统内核的接收缓冲区了---快重传机制