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合并在一起？）
大概率不能合并因为：

1. 发起的角色不同，（ACK）一个是操作系统，（FIN）一个是应用程序；
2. 发起的时机不同，ACK是应答比较及时，FIN要回收一些资源之后才触发。

四. 滑动窗口

对每一个发送的数据段，都要给一个ACK确认应答，收到ACK之后再发送下一个数据段。
这样做的缺点就是性能较差，尤其是数据往返的时间较长的时候。
为了提升效率，改为批量发送。

接收到应答之后把缓冲区中管理的已发送的数据移出，并把后续要发送的数据加入缓冲区

1.发送方批量发送，把正在发送的数据加入到缓冲区，同时记录最大字节数
2.根据当前窗口的大小发送报文
3.接收方收到报文之后，返回一个ACK(确认序号)
4.发送方接收到一个ACK之后，把缓冲区的数据删除一组，然后再加入一组新的数据到缓冲区，继续发送

窗口越大，数据吞吐量越高

1. 情况一 数据包已经抵达，ACK丢失

TCP传输数据的过程中，如果收到了6001的确认序号，那么就可以证明前面的全部传输成功。

2. 情况二 数据包直接丢失

丢失了一个数据包，中间少了一个序号，导致字节流的连续编号，后续只要接收到数据包，都会在确认序号区域填充缺失部分的序号。
当有数据缺失的时候，对于后续正常接收的数据被缓存起来。当缺失数据重新发来时，接收方会按数据顺序把数据包组织好，再ACK最新的确认信号。