网站建设案例机构,旅游类网站设计方案,忘记网站后台用户名,洪栾单页网站建设TCP协议如何实现可靠传输#xff1f;确保接收方收到数据#xff1f; 需要依靠几个结构#xff1a; 以字节为单位的滑动窗口 这其中包括发送方的发送窗口和接收方的接收窗口 下面的描述#xff0c;我们指定A为发送端口#xff0c;B为接收端口 TCP的可靠传输就是靠着滑动窗口… 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因为没有旧数据他是第一个 公式如下a1/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干了个什么
抽象
