计算机网络 传输层.ppt

2020/3/25 CN-Chapter8 31 8.4.2 TCP 的流量控制 ? 拥塞控制的步骤： – 初始的拥塞窗口置 1 ，慢启动的门限窗口置 64 。 – 若发送端收到所有发出报文段的确认，就在 下一次发送时将拥塞窗口加倍。拥塞窗口从 1 开始，按指数规律增长。假定增长到 64 时 出现了超时。于是将 64 的一半， 32 作为新的 门限窗口值，同时，拥塞窗口再次变为 1 。 如下图中的起点。 2020/3/25 CN-Chapter8 32 8.4.2 TCP 的流量控制 2020/3/25 CN-Chapter8 33 8.4.2 TCP 的流量控制 – 拥塞窗口从 1 开始按指数规律增长，直到门 限 32 。然后只将拥塞窗口加 1 ，使拥塞窗口 按照线性规律增长。图中假定增长到 40 时， 又出现超时。这时门限变为 20 ，拥塞窗口又 降为 1 。当按指数规律增长到 20 时，改为每 次加 1 。 2020/3/25 CN-Chapter8 34 8.4.2 TCP 的流量控制 ? 总结： – 慢启动 slow start （其实一点也不慢）：指每 次出现超时，拥塞窗口降到 1 ，然后使报文 段慢慢注入到网络。 – 加速递减：每出现一次超时，就将门限窗口 值减半。当超时频繁出现，门限值很快减下 来。 – 拥塞避免：当拥塞窗口增大到门限值时，将 拥塞窗口的指数增长降低为线性增长，避免 网络再次出现拥塞。 2020/3/25 CN-Chapter8 35 8.4.3 TCP 的重发机制 ? 可靠性（差错处理）是通过 超时重发 +ACK 来保障。 ? 超时时间设置为大于往返时延即可。 ? 往返时延：从数据发出到收到对方的确 认所经过的时间。 ? 问题 ： Internet 的异构环境，往返延迟变 化很大。如何设置定时器的重发时间？ 2020/3/25 CN-Chapter8 36 8.4.3 TCP 的重发机制 2020/3/25 CN-Chapter8 37 8.4.3 TCP 的重发机制 ? 方案：自适应算法 – 记录每一个报文段的往返时间。将各个报文 段的往返时延样本加权平均，就得出报文段 的 平均往返时延 T ： T ＝ ? ( 旧的往返时延 ) ＋ (1 ?? )( 新的往返时延 ) – 0 ??? 1 ，典型值为 7/8 。 – 定时器设置的重发时间应略大于上面得出的 平均往返时延： 重发时间＝ ? ( 平均往返时延 T) – ? 1 ，典型地取 2 。 2020/3/25 CN-Chapter8 38 8.4.3 TCP 的重发机制 ? 但是还有问题：重发带来的往返时间计 算混淆。 – 发送出一个报文段后，重发时间到了，还没 有收到确认。于是重发此报文段，后来收到 了确认报文段。问题是：如何判定此报文段 是对原来的报文段的确认，还是对重发的报 文段的确认？ – 不知道。猜测错误导致严重的 T 值估计问题。 – 解决方法 ：对重发的数据段不修正其 T 值。 2020/3/25 CN-Chapter8 39 8.4.3 TCP 的重发机制 ? 但还不够： – 当报文段的时延突然增大很多时，在原来的 重发时间内，不会收到确认报文段，于是就 重发报文段。但根据上面的方法，不考虑重 发的报文段的往返时延样本。这样，重发时 间就无法更新。 2020/3/25 CN-Chapter8 40 8.4.3 TCP 的重发机制 ? 因此完整的解决方法是 (karn) ： – 正常情况： 重发时间＝ ? （平均往返时延） – 当出现重发情况时： 报文段每重发一次，就将重发时间增大一些： 新的重发时间＝ ? （旧的重发时间） ? 典型值为 2 。 2020/3/25 CN-Chapter8 41 8.4.4 TCP 报文段的格式 ? TCP 连接上的每个字节均有它自己的 32 位序列号。 ? 发送和接收方 TCP 实体以报文段 (segment) 的形式交换数据。 ? 一个报文段包含一个头（固定的 20 字节 ＋可选部分）和数据（ 0 －多个字节）。 ? 每个报文段必须适合 IP 的负荷能力，不 能超过 64K 字节；同时受每个网络的最大 传送单位 MTU 限制。 2020/3/25 CN-Chapter8 42 8.4.4 TCP 报文段的格式 2020/3/25 CN-Chapter8 43 8.4.4 TCP 报文段的格式 ? 源端口和目的端口； ? 序号：所发送的数据部分第一个字节的 序号； ? 确认序号：期望收到对方下次发送的数 据的第一个字节的序号； ? 数据偏移：报文段首部的长度； ? 保留字段： ? 紧急比特 URG(URGent) ：当 URG=1 时， 表明此报文段应尽快传送； 2020/3/25 CN