太原市网站建设_网站建设公司_H5网站_seo优化

3.4可靠数据传输(RDT)原理

3.4.1 构造可靠数据传输协议

1. rdt1.0：完全可靠信道的可靠数据传输

2. rdt2：具有比特差错信道的可靠数据传输

   1. 假设数据包比特可能损坏

   2. 机制

      • 差错检测

        • 校验和，附加位

      • 接收方反馈

        • 积极反馈(ACK)，消极反馈(NAK)

      • 重传

        • 自动重传请求(ARQ)

   3. 分析

      1. 发送方有停等(stop-and-wait)协议

      2. 问题：无法处理ACK/NAK损坏

         • ACK损坏，误以为重传，导致重复包

         • NAK损坏，误以为成功，导致丢包

   4. 解决ACK损坏

      rdt2.1：含序号字段(sequence number)

      • 添加字段，存放即将发送数据包的序号

        • 接收方检查序号，连续两个数据包序号一样，则丢弃重复包

      • ACK也携带序号

        • 发送方检查ACK序号，若和发送的数据包序号不一样，则重传

   5. 解决NAK损坏

      rdt2.2：用重复ACK替代NAK

      • 接受方期望packet 1，但损坏，接受方发送ACK 0

      • 发送方接受到重复的ACK 0(上一次也是ACK 0)，知道packet 1未正确到达，进行重传

3. rdt3.0：具有比特差错的丢包信道的可靠数据传输

   1. 机制

      • 交替位协议

      • 停等协议

      • 新引入：发送方超时重传

   2. 问题：停等协议效率低

      • T_total = T_transmit + RTT，RTT >> T_transmit

      • T_transmit是发送方把数据包全部推入链路的时间，RTT是接下来数据包从发送方到接收方，发送方再收到ACK的时间

3.4.2 流水线可靠数据传输协议

1. 允许连续发送多个包，显著提高信道利用率

2. 解决流水线差错恢复

   • 回退N步(Go-Back-N，GBN)

   • 选择重传(Select Repeat，SR)

3.4.3 GBN

1. 发送方

   1. 滑动窗口(sliding-window)协议

      • 发送方​​维护一个​​发送窗口​​，表示​​允许连续发送但未确认的包的最大数量​​

      • 每当收到一个ACK，窗口向前滑动相应长度，有空闲才允许发送新包

   2. 累积确认(cumulative acknowledgement)

      • 接收方只按顺序确认最后一个连续正确的接收包

      • 如收到packet 1、2、3，返回ACK 3

      • 包丢失发送方需重传确认序号后面的包

      • 如收到1、3，2丢失时，返回的是ACK 1，需要重传2、3

   3. 超时重传

      接收方收到1、2、3，但没有返回任何ACK，发送方要重传1、2、3

2. 接收方

   丢弃乱序包

3.4.4 SR

1. 发送方

   • 滑动窗口协议

   • 超时重传

     • 每个分组有自己的逻辑定时器，仅重传该包

2. 接收方

   • 单独确认每个正确接受的包

   • 缓存乱序包，等待缺失包

3.5面向连接的运输：TCP

3.5.1 TCP连接

1. 点对点(point-to-point)或端到端

   单个发送方与单个接收方之间的连接

2. 发送buffer和接收buffer

3. 面向连接

   三次握手建立连接

4. 全双工服务(full-duflex service)

   支持双向数据传输

5. 可靠有序字节流(rdt)

   • 无消息边界，应用层自行分割消息

   • 最大报文段大小(MSS)

6. 流水线(Pipeling)

   流量控制和拥塞控制有滑动窗口协议

7. 流量控制(flow controlled)

   防止发送方速率过快

8. 拥塞控制(congestion controll)

   避免网络过载

3.5.2 TCP报文段结构

1. 报文段结构

   好多呀，看书吧

2. Telnet

   1. Seq代表当前的消息，ACK代表等待的消息

   2. 流程(假设C和S起始序号分别是42和79)

      1. 发：Seq=42, ACK=79, data=‘C’

         发送序号为42的消息，等待序号为79的消息

      2. 接：Seq=79, ACK=43, data=‘C’

         发送序号为79的消息，等待序号为43的消息

      3. 发：Seq=43, ACK=80

3.5.3 往返时间的估计与超时

问题

1. 估计RTT

   • 综合考虑近期多次RTT测量结果

   • ⭐EstimatedRTT = (1 - α) * EstimatedRTT + α * SampleRTT

     • EstimatedRTT的新值由以前的EstimatedRTT值和当前SampleRTT值加权

     • α=0.125，E(0)=S(0)

   • ⭐DevRTT = (1 - β) * DevRTT + β * |SampleRTT - EstimatedRTT|

     • Dev：Deviation，偏差

     • β=0.25

2. 设置和管理重传超时间隔

   ⭐TimeoutInterval = EstimatedRTT + 4 * DevRTT

3.5.4 可靠数据传输

1. TCP在IP不可靠的服务之上建立rdt服务

   • 流水线

   • 累计确认

   • 缓存无序段

   • 重传

     • 3次冗余ACK重传

     • 超时重传

2. 改进

   1. 超时间隔加倍

      • 每次超时事件发生时，超时间隔翻倍

      • 意味着此时网络拥塞

      • 接收ACK后重新估计超时间隔

   2. 快速重传

      1. 用于解决报文段丢失

      2. 发送方接收到3个冗余ACK(duplicate ACK)后，立即重传

         • 为什么不是2次：2次可能是短暂乱序但没丢包

         • 3次概率很低

      3. 发送ACK的机制

         1. 报文段按序到达，且无待确认报文段

            稍等一会

            • 若没有新报文段就发送ACK

            • 若有新报文段就发送累计ACK

         2. 报文段按序到达，且有待确认报文段

            立即发送累计ACK

         3. 收到乱序报文段

            立即发送冗余ACK

         4. 收到报文段，补全空缺

            立即发送ACK

3.5.5 流量控制

1. 变量

   1. LastByteRead

      接收方从buffer读取的最后一个字节编号

   2. LastByteRcvd

      Last Byte Received，已存入buffer的最后一个字节的编号

   3. RcvBuffer

      ​​Receive Buffer Size​

   4. rwnd

      Receive Window(接收窗口)，接收方当前可用buffer空间

2. 不允许buffer溢出

   • LastByteRcvd-LastByteRead≤RcvBuffer

   • buffer中未被读取的数据量≤buffer大小

3. 设置rwnd

   • rwnd=RcvBuffer-[LastByteRcvd-LastByteRead]

   • 可用的buffer空间

3.5.6 TCP连接管理

1. 三次握手

   1. 建立连接：初始化TCP变量，seq，buffers，流量控制信息

   2. 流程

      1. Client发送TCP SYN报文段

         • SYN=1，seq=x

         • 无app数据

         • 进入SYN_SENT状态

      2. Server回应SYNACK报文段

         • SYN=1，seq=y， ack=x+1

         • 无app数据，server分配buffers

         • 进入SYN_RCVD状态

      3. Client回应ACK报文段

         • SYN=0，seq=x+1，ack=y+1

         • 可携带数据

         • 双方进入ESTABLISHED状态

   3. 为什么不能两报文握手（没有最后一个）

      当TCP连接请求1滞留，会重发请求2进行连接。若1在两者结束连接后到达，又会令服务器进入连接状态，并发送确认，但客户已关闭，不会回应，浪费服务器进程主机资源。

2. 四报文挥手

   1. 四报文挥手可由任意一方发起

   2. 流程

      1. 主动方发送FIN报文段

         • 进入FIN_WAIT_1状态

      2. 被动方发送ACK确认报文段

         • 进入CLOSE_WAIT状态

         • 主动方进入FIN_WAIT_2状态

      3. 被动方发送FIN响应报文段

         • 进入LAST_ACK状态

      4. 主动方回复最终ACK

         • 进入TIME_WAIT状态

   3. 为什么需要四次挥手

      TCP连接是双向的，客户端和服务端各自需要​​独立关闭​​自己的数据流

      1. 第一次挥手​​：客户端声明“我没有数据要发了”（FIN）。

      2. ​​第二次挥手​​：服务端仅确认客户端的FIN，但​​此时服务端可能仍有数据要发送​​。

      3. 第三次挥手​​：服务端发完剩余数据后，发送自己的FIN。

      4. 第四次挥手​​：客户端确认服务端的FIN，连接彻底关闭。

   4. Timed wait

      • 四报文挥手后被动方进入关闭状态，主动方经过2MSL的等待才关闭

      • 等待的必要性：若第四步丢失，未到达被动方，而主动方不等待就直接关闭，被动方就会不断发送确认

3.6 拥塞控制方法

3.6.1 端到端拥塞控制

1. 网络层不为运输层提供显式支持

2. 端系统通过观察网络的丢包、时延等推断拥塞

3.6.2 网络辅助的拥塞控制

路由器向端系统提供显示反馈

• 一个比特指示拥塞状况

• 明确最大发送速率

3.7 TCP拥塞控制

3.7.1 拥塞判断

1. 超时

2. 3个冗余ACK

3.7.2 拥塞窗口(cwnd)

1. 限制发送方能向网络中发送流量的速率

2. LastByteSent - LastByteAcked ≤ min{cwnd, rwnd}

3. 限制了在途数据量

3.7.3 慢启动阈值(slow start threshold，ssthresh)

3.7.4 拥塞控制方法

1. 加性增加

   cwnd每RTT增加1MSS

2. 乘性减少

   丢包后cwnd变为一半

3.7.5 TCP发送速率

1. TCP发送速率 ≈ cwnd / RTT bytes/sec

2. 发送方每经过一个RTT可以填满cwnd

3.7.6 拥塞控制算法

1. 慢启动

   1. 从1开始，cwnd每个传输轮次(一个RTT)翻倍

   2. 结束指数增长的情况

      • 发生超时丢包

        • 回到开始状态，cwnd = 1

        • ssthresh = cwnd / 2

      • 达到ssthresh

        • 进入拥塞避免算法

      • 收到3个冗余ACK

        • 快重传并快恢复

2. 拥塞避免

   • cwnd 每个 RTT 只加 1 MSS

   • 接近历史拥塞点时需谨慎，避免再次触发丢包

3. 快重传

   • 情况：并没有超时而是部分报文段丢失时

   • 启用：发送方收到3个冗余ACK，立即重传丢失报文段

4. 快恢复

   • ssthresh变为一半

   • cwnd = ssthresh + 3

   • 然后执行拥塞避免算法

3.7.7 发送方的拥塞窗口

发送方将拥塞窗口作为发送窗口 swnd，swnd = cwnd

3.7.8 慢启动阈值

• cwnd < ssthresh：慢开始算法

• cwnd = ssthresh：都可以

• cwnd > ssthresh：拥塞避免算法