Java EE(15)——网络原理——TCP协议解析一

一.确认应答/(确认)序列号

接收方接收到数据后，向发送方返回一个确认信号(ack)，告诉发送方数据被成功接收。ACK报文段只是作为确认使用的，一般来说不携带应用层数据（载荷），也就是说只有报头部分。但有可能和其他的数据进行合并，这个是后话

另外，TCP将每个字节的数据都进行了编号，叫做序列号，保证数据到达接收方时不会混乱
其次，每个ACK报文也有一个确认序列号，例如ACK（1001），其一是告诉发送方1000之前的数据我以及收到了；其二是让发送方从1001开始发送

问题：当后发的数据（1001~2000）先到达服务器时，ACK是否会返回ACK（2001）？

其实服务器不会返回ACK（2001），因为数据（1~1000）还没到达，也就是说ACK（1001）
都还没返回给客户端，凭什么返回ACK（2001）。
那么此时又引出一个问题，既然ACK（1001）没返回，客户端为什么可以发送数据（1001 ~2000）？
这是因为TCP协议发送数据时，不是一条一条发送的，这个到后面讲滑动窗口时再细讲

二.超时重传

之前便说过，TCP虽然号称可靠传输，但实际上数据不可能100%传输到对端，这光靠代码是无法解决的

遇到上述情况时，会触发TCP的超时重传机制
发送方等待一段时间后，没有收到服务器返回的ACK，那么就会默认该数据丢包了，会再次发送该数据，如果依然没有收到ACK，会再次重发，但每次重发的时间间隔会拉长，达到一定次数后就不再重重发。
如果数据成功达到了，但是ACK丢包了，怎么办？
虽然客户端会重发数据，但是服务器缓冲区会对接收的数据进行检查，相同序列号的数据不会接收的

三.连接管理/状态转换

3.1三次握手

（1）SYN：客户端发起连接请求
（2）ACK：服务器表示你的请求我收到了，但到底要不要连接，ACK无法决定；SYN：服务器决定与服务器建立连接(一般来说服务器不会拒绝连接请求，除非服务器繁忙，所以ACK和SYN一般是同步返回给客户端的)
（3）ACK：客户端告诉服务器，你的ACK+SYN我也收到了
这就是三次挥手建立连接的过程
问题：两次挥手能不能建立连接？四次挥手又那不能？
答案：两次不行，四次多余。
我举例说明，此时张三和李四开黑，因为不在同一个地方，所以要开麦交流，那么在开黑之前需要确定双方的麦克风和听筒都没问题

至于四次握手没必要我上面以及已经说过了，服务器的ACK和SYN是可以合并发送的，能一次发送就不两次

3.2三次握手的状态转换

1.服务器和客户端都没启动

2.服务器启动，客户端为启动

3.服务器和客户端都启动

3.3四次挥手&状态转换

（1）FIN：客户端调用close（也可能是服务器）并发送断连请求
（2）ACK：服务器收到FIN后返回ACK告诉客户端：我收到了你的断连请求，并进入CLOSE_WAIT状态
（3）FIN：服务器进入CLOSE_WAIT状态后需要处理完之前的数据，再调用close并向客户端发送FIN确认断连。然后进入LAST_ACK状态，等待客户端发送最后的ACK
（4）ACK：客户端收到FIN后进入TIME_WAIT状态，同时发送ACK

当服务器收到ACK之后，就进入CLOSED状态彻底关闭连接；
而客户端会等待一段时间后才进入CLOSED状态，为了确保服务器收到ACK

问题：服务器的ACK和FIN能不能合并？
答案是：不能，因为ACK和FIN发送的时间大概率不同步，服务器需要处理完之前的数据才能发送FIN；如果正好处理完毕，ACK和FIN也有可能同步发送。但是一般来说ACK和FIN是不同步的，所以一般叫做四次挥手