Java TCP可靠传输(1)
TCP 可靠传输
一. 确认应答
由发送方填充，再由接收方在序号的基础上+1，填充到确认序号中，来表示已经接收到前面发送的，表明下一个从哪个位置发送。
二. 超时重传
数据在网络上传输时会经过很多网络设备，如果其中一个设备出现问题，这个请求会发生超时。
1. 发送超时
主机B未接收到数据，主机A在达到一定时间间隔后，重新发送一次数据。
2. 接收方收到了数据，返回应答的时候超时
主机B接收到了数据，但ACK应答时丢包。
所以主机A不知道是发送丢包还是应答丢包。于是等待一段时间间隔后，重新发送一次数据。
主机B会根据序号来判断出再次接收到了相同的数据，直接舍弃新发来的数据，重新进行ACK应答。
三. 连接管理
在发送方和接收方建立连接时，确认双方的收发能力
1. 初次建立时，三次握手
当ACK和SYN统一的返回主机A时，就形成了三次握手。
1.主机A发送SYN请求，生成一个随机数据填充在序号区域
2.主机B接收到主机A发来的SYN请求后，在序号的基本上+1，把结果填充成确认序号中，并把ACK标志位置为1，表示要进行应答 同时也生成一个随机数据填充在序号区域，并把SYN标志位置为1，表示自己发送一个SYN同步请求
3.主机接收到主机B发来的ACK+SYN请求时，首先判断ACK，表示主机B有应答能力，再去判断SYN，在序号的基础上+1，把结果填充在确认序号中，把ACK标志位置为1
4.主机B接收到主机A发来的ACK，表示主机A有应答能力，网络验证完成，建立连接成功
2. 断开连接时，四次挥手
保证发送与接收方有效（安全）地断开连接
四次挥手能不能变成三次挥手？（第二次的ACK能不能与第三步的FIN合并在一起？）
大概率不能合并因为：
- 发起的角色不同，（ACK）一个是操作系统，（FIN）一个是应用程序；
- 发起的时机不同，ACK是应答比较及时，FIN要回收一些资源之后才触发。
四. 滑动窗口
对每一个发送的数据段，都要给一个ACK确认应答，收到ACK之后再发送下一个数据段。
这样做的缺点就是性能较差，尤其是数据往返的时间较长的时候。
为了提升效率，改为批量发送。
接收到应答之后把缓冲区中管理的已发送的数据移出，并把后续要发送的数据加入缓冲区
1.发送方批量发送，把正在发送的数据加入到缓冲区，同时记录最大字节数
2.根据当前窗口的大小发送报文
3.接收方收到报文之后，返回一个ACK(确认序号)
4.发送方接收到一个ACK之后，把缓冲区的数据删除一组，然后再加入一组新的数据到缓冲区，继续发送
窗口越大，数据吞吐量越高
1. 情况一 数据包已经抵达，ACK丢失
TCP传输数据的过程中，如果收到了6001的确认序号，那么就可以证明前面的全部传输成功。
2. 情况二 数据包直接丢失
丢失了一个数据包，中间少了一个序号，导致字节流的连续编号，后续只要接收到数据包，都会在确认序号区域填充缺失部分的序号。
当有数据缺失的时候，对于后续正常接收的数据被缓存起来。当缺失数据重新发来时，接收方会按数据顺序把数据包组织好，再ACK最新的确认信号。