cms网站后台管理系统营销型网站内容
TCP协议如何实现可靠传输？确保接收方收到数据？
需要依靠几个结构：
以字节为单位的滑动窗口
这其中包括发送方的发送窗口和接收方的接收窗口
下面的描述，我们指定A为发送端口，B为接收端口
TCP的可靠传输就是靠着滑动窗口实现的
下面我将对：
什么是滑动窗口
如何实现可靠传输？
传输过程怎样变化？
等待。。。
目录
一、什么是滑动窗口？
二、滑动窗口如何工作？
1、发送窗口
1）发送窗口的特点
2）发送窗口后沿的变化
3）发送窗口前沿的变化
2、接收窗口
二、窗口和TCP缓存
1、发送窗口和发送缓存
2、接收窗口和接收缓存
3、注意事项-TCP规则
三、超时重传时间的选择
1、超时重传时间的困难
2、如何选取超时重传时间？
四、选择确认SACK
一、什么是滑动窗口？
以发送窗口为例：
就是一个数据范围，形象的比喻为窗口
这个窗口内部的所有字节都可以发送
后沿前的数据表示：已经确认发送的数据，因而不需要保留
前沿前的数据表示：不能发送发送的数据，因为接收窗口没有那么多的缓存
如图：（注意，窗口方向，以还没有发送方向为前方）
二、滑动窗口如何工作？
为实现可靠传输
需要在发送方和接收方各自设置一个窗口
发送方的叫做发送窗口
接收方的叫做接收窗口
1、发送窗口
1）发送窗口的特点
1、数据保留
没有确认收到的，但是已经发送的数据需要保留，以便超时重传
发送窗口越大，表明可以发送更多的数据，有更高的传输效率
2、发送窗口根据接收窗口构造
B向A发送的确认报文包括B的接收窗口大小，放在TCP首部的窗口字段
同时包括已经确认接收的确认号n
确认号一般采用累计确认，表示n前面的数据已经全部接收，n和n以后的数据没有接收
确认报文 = B窗口值 + 确认号
发送窗口的可用窗口表示：可以发送但未发送的数据
2）发送窗口后沿的变化
1、不动：没有接收到确认报文
2、前移：收到确认报文
3、不可能后移，因为确认不可撤销
3）发送窗口前沿的变化
1、不动：没有收到新的确认，同时对方通知的窗口大小不变
或者说到确认，但是窗口缩小，后沿前移，但是前沿不动
2、向前：一对方窗口变大。二收到确认且对方窗口不变或变大
3、后移：对方窗口缩小，A不得不跟着缩小
描述一个发送窗口的状态需要三个指针，如图：
p1分割确认发送和未确认发送
p2分割未确认发送和可发送但未发送
p3分割可发送但未发送和不可发送
2、接收窗口
接收窗口和发送窗口结构一样，但是管理的数据意义不同
窗口内部的数据是可以接收的数据
前沿之前：不可以接收的数据，缓存不够
后沿之后：已经确认提交主机的数据
中间还分两部分：未发送确认的数据 和 可以接收但是没有到的数据
B向A发送的确认号只对目前接收到的有序数据的最大序号，注意，是有序
当A的可用窗口为0时（窗口内的数据全部发送完，可发送但未发生的数据为0）
A只能等待B的确认报文才能进行更新
如果A没有接收到B的确认报文
并且时间超过了超时计时器
A就要重发所有未确认收到的数据
二、窗口和TCP缓存
1、发送窗口和发送缓存
发送窗口一般只是TCP发送缓存的一部分
TCP发送缓存包括：发送窗口的数据 + 被应用程序写入TCP缓存的数据
如图：
2、接收窗口和接收缓存
接收窗口也只是TCP接收缓存的一部分
TCP接收缓存包括：接收窗口的数据 + 按序到达的，但是没有被程序读取的数据；没有
（其中，接收窗口还包括未按序到达的数据）
如图：
对于接收方：
如果接收的数据分组有错，丢弃
接收应用进程不能及时读取数据，接收缓存就会存满，使得接收窗口为0
否则，能够及时读取，接收窗口就可以增大，但是不能超过接收缓存
3、注意事项-TCP规则
1、TCP要求A的发送窗口根据B的接收窗口构造
但是不一定A的发送窗口就和B的接收窗口一样大，可能小
设计拥塞和流量控制
2、TCP对没有按序到达数据没有明确规定
但是会进行缓存，当缺少的序列到达，再上传上层应用程序
3、TCP要求接收方有累计确认的功能
接收方可以在发送数据时顺带确认号，但是双方通信一般不会双向交互
接收方不应该太晚发送确认报文，否则就会触发超时重传
4、TCP是全双工通信
因此通信双方都用有发送和接收两个窗口
三、超时重传时间的选择
1、超时重传时间的困难
如果B发送给A的确认丢失，如果A一直等待，就会出现死锁问题
因此，在A发送数据结束的同时，会设置超时重传时间
一旦超过这个时间没有接收到对方的确认报文
则认为数据没有到达，重新发送数据
但是，什么时候重传？重传的时间取多久？
一般是比往返时间RTT时间大一些
可以往返时间RTT很难确定
因为每一个数据报文的往返时间是不固定的
上一次可能经过1个路由器就到了
这一次可能经过1000个路由器才到
其中每个网络段的传输速度还不一样
例如，虽然经过了1000个路由器，但是速度很快，畅通无阻
有些经过了1个路由器，可是却堵的要死
怎么办？
很难取舍
2、如何选取超时重传时间？
根据新的RTT时间进行自适应更新
共有三个公式，对应三个参数：
第一个公式：每次收到一个新的RTT时间，对其进行重新计算，得到新的RTTs
（第一次的RTTs 等于当前的RTT，因为没有旧数据，他是第一个）
公式如下：a=1/8
第二个公式：计算RTT的加权平均值——RTTD
（第一次传输的RTTD取RTT的1/2）
公式如下：β=1/4
第三个公式：计算最终超时重传时间RTO
公式如下：
RTTs -> RTTD -> RTO
上述的公式似乎已经可以解决重传时间了
但是，设想一种场景：
A发送了数据1，可是到了重传时间，依旧没有收到确认1
此时，A就要重发
注意，此时A并没有收到任何的确认报文
但是，A对B发送了两次同样的数据1
于是，这就会产生两个一模一样的确认报文！
因为这两个报文都是对数据1的确认。
好了，现在麻烦来了：
A如何判断现在收到的这个确认报文
是对原来数据的确认，还是对重传数据的确认?
很明显，如果把重传确认认成了对原来数据的确认，计算出的RTO重传时间就会偏小
反之则偏大
同时，如果后期的数据也和上述的一样，
重传时间有越来越大和越来越小的1可能
怎么办？
修正。
怎么修正？
Karn算法规定：只要数据重传，则采用其往返时间
可是，问题又来了？
不采用新的往返时间，如何更新重传时间呢？
大佬就是大佬，
于是Karn再次修正：你不重传吗，好，你了不起，你niu批！
只要重传，就把重传时间增大，一般是2倍
当没有重传，再按照上述公式计算
四、选择确认SACK
这个协议解决如果数据没有按需到达怎么办？
例如：
0 1 3 4 5都到了
就是你2没有
怎么说？
举个例子，如图：
1001-1500没有收到
3001-3500没有收到
怎么办？
1、TCP首部选项增加SACK选项
2、选项中记录不连续块的边界
以通知发送方，我哪到哪没有传，例如1000-1500没有传
注意：
选项长度最大为40字节
而一个边界序号是4个字节
因此，最多只能记录4个不连续块
4 个不连续块有8个边界序号，每个边界序号4字节，共32字节
还需要两个字节，一个指明SACK选项，一个指明选项长度
共34字节
注意：SACk文档没有指明发送方要如何相应SACK报文
也就是说，发送方收到SACK报文后，他都不知道该怎么办
因此，大多数的实现依旧是从确认号开始全部重传
我：啊？？？那你SACK干了个什么？
抽象
