建设一下网站要求提供源码网站发布到ftp
目录
一. 前言
二. 滑动窗口
三. 丢包现象
1）ACK报文丢失
2）数据丢失
四. 总结
一. 前言
TCP最核心的机制就是可靠传输 ，确认应答，超时重传，连接管理这些都保证了可靠传输，得到了可靠传输，但是传输效率降低了
单位时间内，传输的数据量变少了
- 由于确定应答机制，发送方每发送一次数据，接收方就要返回一个ACK，收到ACK之后才会发送下一次数据，将大部分的时间都浪费在了等待ACK中
所以我们希望在可靠传输的基础上，减少等待的时间，从而提高效率
二. 滑动窗口
我们引入滑动窗口的机制，就可以保证在可靠传输的基础上，提高效率（减少等待时间）
核心思想就是批量传输
发送一个数据之后，不等了，再发一个，连续发送一定的数据之后，统一等ACK
把多次请求的等待时间，使用同一份时间来等，减少了总的等待时间
滑动窗口
- 连续发送一定量的数据，这个一定量的数据由滑动窗口来规定，连续发送一个窗口的数据，就必须停下来等待ACK
- 如上图，连续发送三份数据（一个窗口数据），那么就会收到对应的三个ACK报文
- 如果一直等待，直到收到最后一个ACK再往后移动三份，这样显然效率不高，但是如果收到第一份数据的ACK，那么就往后滑动一位，同时发送数据，一直这样循环
由于每次移动一个位置，窗口移动的速度很快，类似于滑动的效果，所有叫滑动窗口
三. 丢包现象
整个TCP最重要的就是可靠性，如果出现丢包现象，滑动窗口如何解决？
1）ACK报文丢失
ACK报文的含义：
- 这个序号之前的数据，我都收到了
- 下一次从这个序号开始
如果出现ACK报文丢失情况，不用管，不会对可靠性造成影响 （不需要重传）
2）数据丢失
如果出现数据丢失情况，则必须要重传
- 如果在传输过程中，出现数据丢失的情况，返回的ACK报文中的序号是下一次需要发送的起始位置，如果接收的不是想要的，会一直索要想要序号的数据，一直发送想要序号的ACK确认报文
- 这里的连续索要是为了给没有收到的数据留有等待时间，这个数据没有到，可能是因为路上“堵”了，如果连续发送三次，依然没有到达，很有可能就是丢了，需要重发
- 发送方多次收到索要相同的数据，那么就会认为丢包，则会进行重发
- 在主机2中，存有缓冲区，会把已经收到的数据放在缓冲区中，如果得到了自己一直索要的数据，那么会直接取当前连续序号的最大值
在上述的重传过程，整体的效率非常快，针对性很强，缺失哪个就重传哪个，已经收到的数据，也不需要重新发送，整体的效率没有额外损失，这样的重传机制，被称为快速重传
四. 总结
- 确认应答是TCP可靠传输的主要原因，超时重传是对确认应答的补充
- 在滑动窗口中，同样存在确认应答机制，只是将一个一个确认，变成了批量确认
- 如果短时间内数据很少，滑动窗口根本滑不起来，就变成了确认应答
如果短时间内传输大量数据，则传输方式为滑动窗口，依靠快速重传保证可靠性
如果传输数据不多，那主要是发送一个数据，返回一个应答，这种模式的确认应答，主要依靠超时重传保证可靠性
点赞的宝子今晚自动触发「躺赢锦鲤」buff！