1 / 55

TCP

TCP. √. 概述 报文格式 连接管理 TCP 的数据传输 流控与拥塞控制 错误控制 (Timer). √. √. √. Congestion Control vs Flow Control. Congestion control is a global issue – involves every router and host within the subnet: keep sender from overrunning network

armani
Download Presentation

TCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP √ • 概述 • 报文格式 • 连接管理 • TCP的数据传输 • 流控与拥塞控制 • 错误控制 (Timer) √ √ √

  2. Congestion Control vs Flow Control • Congestion control is a global issue – involves every router and host within the subnet: keep sender from overrunning network • Flow control – scope is point-to-point; involves just sender and receiver: keep sender from overrunning receiver. 网络 (a) Flow control (b) Congestion control

  3. 流控与阻塞控制 • Flow Control 常用的流量控制方法有：漏桶(leaky bucket)技术、停--等（Stop and Wait ）协议、滑动窗口（Sliding Window）协议、ON/OFF，端-端流量控制等 • Congestion Control 常用的拥塞控制方法有：资源预分配、数据包丢弃、定数拥塞控制法和抑制数据包法。

  4. 理想的拥塞控制 实际的拥塞控制 无拥塞控制 死锁 轻度拥塞 拥塞 拥塞控制 吞吐量 子网的最大 传输容量 吞吐量饱和 网络吞吐量=网络负载 输入负载 0 图 拥塞控制所起的作用

  5. TCP流量控制

  6. 接收方: 明确通知发送方空闲缓存空间 TCP报文段中的接收窗口域 发送方: 保持已发送但未确认的数据少于当前的接收窗口 流控 发送方传输数据不 能太多太快以致于 淹没接收方的缓存 RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer 接收方缓存 TCP流控

  7. 滑动流量控制: 发送方 Packet Received Packet Sent 源端口 目的端口 源端口 目的端口 序列号 序列号 确认号 确认号 首部长度/码元比特 窗口 首部长度/码元比特 接收窗口 校验和 紧急指针 校验和 紧急指针 选项.. 选项.. App write acknowledged sent can be sent outside window

  8. SEQ = 1 SEQ = 101 SEQ = 201 丢失！ ACK = 201, WIN = 300 SEQ = 301 SEQ = 401 SEQ = 201 ACK = 501, WIN = 200 SEQ = 501 ACK = 601, WIN = 0 利用可变窗口进行流量控制举例 主机 A 主机 B A 还能发送 300 字节 A 还能发送 200 字节 允许 A 再发送 300 字节（序号 201 至 500） A 还能发送 200 字节（序号 301 至 500） A 还能发送 100 字节（序号 401 至 500） A 超时重发，但不能发送序号 500 以后的数据 允许 A 再发送 200 字节（序号 501 至 700） A 还能发送 100 字节（序号 501 至 700） 不允许 A 再发送（到序号 600 的数据都已收到） 主机A向主机B发送数据，双方商定的窗口值是400，每一个报文段 为100字节，序号的初始值为1。主机B进行了3次流量控制。

  9. TCP拥塞控制

  10. xi>Xgoal 解决方法:避免用户的发送量超过网络的能力 1 1 User 1 x1 x2 需求 可用容量  User 2   n n xn User n y 拥塞问题 问题:对资源的需求超过了可用资源（ < )

  11. 通信量整形法。把主机向网络输出数据的速率调整到一个固定的平均速率，以使路由器能够以现有资源平稳地处理它。通信量整形法的两个代表是漏桶算法(leaky bucket algorithm)和令牌桶算法(token bucket algorithm)。 拥塞预警法。其原理是:路由器建立一种拥塞预警机制，当轻度拥塞发生时，通知源主机减少发送数据的数量，避免拥塞加剧。ICMP(internet control message protocol)协议的源抑制报文就采用拥塞预警原理。 TCP implements host-based, feedback-based, window-based congestion control. 基于路由器的主动队列管理(AQM)。 拥塞控制的基本方法

  12. 图 基于数据报服务的拥塞控制策略 目的主机 源主机 ICMP Choke Packets 抑制分组 抑制分组 抑制分组 抑制分组 主机收到抑制分组后，逐步减少发送给目的主机的分组数量，一般改变发送窗口或采用漏桶输出率等。 警告!

  13. 轻度拥塞–该点后 吞吐量增长缓慢 延迟增加加快 完全拥塞–该点后 吞吐量快速下降直至零 (拥塞崩溃) 无穷大延迟 对于M/M/1排队模型 延时 = 1/(1 – 利用率) 拥塞: A Close-up View 丢弃报文 轻度拥塞 完全拥塞 吞吐量 拥塞崩溃 负载 延迟 负载

  14. 阻塞控制的目标 控制在悬崖（ cliff ）的左边 阻塞避免的目标 控制在拐点（ knee）的左边 悬崖的右边: 由于拥塞导致崩溃 拥塞控制与拥塞避免 knee cliff Throughput congestion collapse Load

  15. 发生报文丢失时表示发生了拥塞，TCP 发送方通过以下方式检测丢包 传输定时器超时 收到重复的ACK(至少三个) ECN (显式拥塞通知) Packet Dst Src Drop Ack 拥塞检测 Timeout! No Ack = Congestion!

  16. Reduce window  less packets in the network Increase window  more packets in the network Idea: Concept of a congestion window– window is smaller when congestion is larger and vice versa Controlling Congestion

  17. TCP 拥塞控制 • TCP 拥塞控制机制。由发送方实现 • 发送方的发送窗口大小设置如下: 发送窗口 = MIN (流控窗口, 拥塞窗口) 其中 • 流控窗口：由接收方通报(即TCP报头中的窗口字段的值) • 拥塞窗口：由发送端根据网络的反馈来动态调整 • rwnd prevents the sender from overwhelming the receiver and cwnd prevents the data from overwhelming the network.

  18. TCP 拥塞控制 • 发送方有两个附加的参数： • – 拥塞窗口 (cwnd) • 初值是 1 MSS (=maximum segment size) • – 慢启动阀值Slow-start threshhold Value (ssthresh) • 初值设置为接收方通报窗口的大小 • 拥塞控制的两种工作状态: • – 慢启动 (cwnd < ssthresh) • – 阻塞避免 (cwnd >= ssthresh)

  19. 慢启动 • 慢启动：快速增加拥塞窗口 • • 初值: • – cwnd = MSS bytes (=1 segment) • • 每收到一个确认就把cwnd 翻倍 (cwnd++). • 直到cwnd >= ssthresh，进入拥塞避免工作状态。

  20. 目标: 通过慢慢增加拥塞窗口的大小，保持工作在完全拥塞点（cliff)的左边: 如何实现? (AIMD) Additive increase:从一个较粗的估计值 (ssthresh)开始, 缓慢增加cwnd以探测额外的可用带宽 Multicative decrease:一旦发现丢失报文(拥塞发生)立即将拥塞窗口的大小减半. 拥塞避免

  21. Initially: cwnd = 1; ssthresh = infinite; New ack received: if (cwnd < ssthresh) /* Slow Start*/ cwnd = cwnd + +; else /* Congestion Avoidance */ cwnd = cwnd + 1; Timeout: (loss detection) /* Multiplicative decrease */ ssthresh = win/2; cwnd = 1; TCP拥塞控制总结:伪码 while (next < unack + win) transmit next packet; where win = min(cwnd, flow_win); seq # unack next win cwnd:additive increase / multiplicative decrease (AIMD)

  22. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢开始和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 当 TCP 连接进行初始化时，将拥塞窗口置为 1。图中的窗口单位不使用字节而使用报文段。 假定慢启动门限的初始值设置为 16 个报文段， 即 ssthresh = 16。

  23. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动始和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 发送端的发送窗口不能超过拥塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。

  24. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 在执行慢启动算法时，拥塞窗口 cwnd 的初始值为 1，发送第一个报文段 M0。

  25. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 发送端收到 ACK1 （确认 M0，期望收到 M1）后，将 cwnd 从 1 增大到 2，于是发送端可以接着发送 M1 和 M2 两个报文段。

  26. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 接收端发回 ACK2 和 ACK3。发送端每收到一个对新报文段的确认 ACK，就把发送端的拥塞窗口翻倍。现在发送端的 cwnd 从 2 增大到 4，并可发送 M4 ~ M6共 4个报文段。

  27. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 发送端收到一个对新报文段的确认 ACK，再一次把发送端的拥塞窗口翻倍，因此拥塞窗口 cwnd 随着传输次数按指数规律增长。

  28. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 拥塞避免 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 慢启动 拥塞避免 当拥塞窗口 cwnd 增长到慢启动门限值 ssthresh 时（即当 cwnd = 16 时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。

  29. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 假定拥塞窗口的数值增长到 24 时，网络出现超时（表明网络拥塞了）重新开始慢启动。

  30. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 更新后的 ssthresh 值变为 12（即发送窗口数值 24 的一半），拥塞窗口再重新设置为 1，并重新执行慢启动算法,从1开始指数地增加发送量。

  31. 发生超时 线性规律增长 进入拥塞避免 进入拥塞避免 指数规律增长 慢启动和拥塞避免算法的实现举例 拥塞窗口 cwnd 24 20 ssthresh = 16 16 更新后的 ssthresh = 12 12 8 4 传输次数 0 0 2 4 6 8 10 12 14 16 18 20 22 慢启动 拥塞避免 慢启动 拥塞避免 当 cwnd = 12 时改为执行拥塞避免算法，拥塞窗口按按线性规律增长，每经过一个往返时延就增加一个 MSS 的大小。

  32. 拥塞响应 • TCP 采用不同的算法来处理阻塞问题 – Tahoe TCP – 基本算法（前面介绍的方法） – Reno TCP -Tahoe + 快速恢复 – New Reno TCP – 改进的 Reno • 其它的: – SACK TCP – Fack TCP –TCP Vegas

  33. TCP Reno • • Tahoe的问题: 如果一个报文分组丢失了, 直到超时才能被发现----时延大 • • Reno增加了快速重传和快速恢复机制 • • 如果接收到3个重复的确认 • 重发估计已经丢失的报文分组(“快速重传”) • 设置 cwnd = cwnd / 2 • 设置 ssthresh = cwnd • 即，不进入慢启动, 而是直接进入拥塞避免(“快速恢复”)

  34. M1, M2 ACK2, ACK3 M3 丢失！ M4 ACK3 M5 ACK3 M6 ACK3 ACK7 M3 快重传举例 主机 A 主机 B A 发送 M1 和 M2 B 确认 M1和M2 A 发送 M3 但丢失了 A 发送 M4 B 只能再次确认M2(因为 M3没有收到） A 发送 M5 B 发送第二个重复确认ACK3 A 发送 M6 B 发送第三个重复确认ACK3 A 收到了三个重复的确认 ACK3，就立即重传 M3，而不必等待超时重传。

  35. 快速重传后把cwnd设为 ssthresh/2 i.e., 不把 cwnd 重置1 但当RTO（重传超时）时还是要把 cwnd 置 1 快速恢复

  36. 三个重复的ACK后,开始快速重传 避免了代价高昂的超时 不必再次慢启动 在稳定状态, cwnd在最优窗口大小附近振荡 快速重传与快速恢复 cwnd Congestion Avoidance Slow Start Time

  37. 重新组包（repacketization) • TCP 重传时, 报文大小不一定与重发前相同

  38. New Reno • 与 Reno TCP 类似，但在收到新的确认后，修正完善所采取的行动 • New Reno 对 Reno 中“快速恢复”算法进行了补充。它考虑了一个发送窗口内多个报文丢失的情况。在Reno 的“快速恢复”算法中，发送方收到一个不重复的应答后就退出“快速恢复”状态。而在 New Reno 中，只有当所有报文都被应答后才退出“快速恢复”状态。

  39. SACK 也关注一个窗口内多个报文的丢失，它使用“选择性重复”(selective repeat)策略。 SACK TCP通过在TCP报文段头部增加SACK选项，通知另外一方本方的数据接收信息。根据这些信息发送方可以发现多个报文段丢失的现象。避免了之前版本的TCP重传一个窗口内所有数据包的情况，而只是重传那些被丢弃的数据包。 但是SACKTCP需要收发双方都支持SACK选项，如果连接的一方不支持该选项，其工作方式与Reno TCP相同。 SACK

  40. Uses congestion avoidance instead of congestion control Reno: Congestion control React to congestion after it occurs Vegas: Congestion avoidance Predict and avoid congestion before it occurs TCP Vegas

  41. Packet accumulation in the network can be inferred by monitoring RTT and sending rate Observation cwnd Overloaded Router Sending Rate Bottleneck Link Sending Rate = cwnd / RTT

  42. BaseRTT is the minimum of all measured RTTs (commonly the RTT of the first packet) If not overflowing the connection, then ExpectRate = CongestionWindow/BaseRTT Source calculates ActualRate once per RTT Source compares ActualRate with ExpectRate Diff = ExpectedRate - ActualRate if Diff < a increase CongestionWindow linearly else if Diff > b decrease CongestionWindow linearly else leave CongestionWindow unchanged TCP Vegas Congestion Control

  43. 基于路由器的拥塞控制方法 使路由器的队列维持两个参数，即队列长度最小门限 THmin和最大门限 THmax。 RED 对每一个到达的数据报都先计算平均队列长度 LAV。 若平均队列长度小于最小门限 THmin，则将新到达的数据报放入队列进行排队。 若平均队列长度超过最大门限 THmax，则将新到达的数据报丢弃。 若平均队列长度在最小门限 THmin 和最大门限THmax 之间，则按照某一概率 p 将新到达的数据报丢弃。 随机早期丢弃 RED (Random Early Discard) 丢弃 以概率p丢弃 排队 数据报 到达 从队首 发送 最小门限 THmin 平均队列长度 Lav 最大门限 THmin

  44. 丢弃概率p 与THmin 和Thmax 的关系 当 LAV  Thmin 时，丢弃概率 p = 0。 当 LAV Thmax 时，丢弃概率 p = 1。 当 THmin LAV  THmax时，0 p  1 。 例如，按线性规律变化，从 0 变到 pmax。 数据报丢弃概率p 1.0 pmax 平均队列长度 Lav 0 最大门限 THmax 最小门限 THmin

  45. TCP √ • 概述 • 报文格式 • 连接管理 • TCP层的数据传输 • 流控和拥塞控制 • 错误控制 (Timer) √ √ √ √

  46. TCP错误控制 • TCP 实现了回退N帧重传机制 • TCP 为每个连接维持了四个定时器 • TCP 同时进行错误控制和拥塞控制 (TCP假定错误是由拥塞引起的) • TCP 允许加速重发 (快速重传)

  47. TCP使用4个定时器来完成各种功能，其中有： 重发定时器 (retransmission timer) 发送每个段的同时启动此定时器。在时钟超时前，收到该段确认，关闭此定时器。在时钟超时前，没有收到该段确认，重发该段。 问题：超时间隔设为多长合理？？？ 持续定时器 (persistence timer) 用于解决死锁。在发送接收双方由于某种原因（例如丢包）而相互等待，产生死锁时。如果持续定时器超时，发送方向接收方发送一个探测数据，打破死锁。 keepalive timer 当一个连接被长时间闲置时，如果keepalive定时器超时，就发送一个段去检测连接的另一方是否依旧存在。如果没有得到相应，就中止该连接。 TIMED WAIT timer 在取消连接的操作中使用此TIMED WAIT 定时器。时间长度为分组TTL的两倍，以确保当一个连接断开之后，所有被此连接创建的分组都完全消失。 TCP的定时管理

  48. TCP 重发定时器 • – 重发定时器的设定对效率至关重要 • 超时值过小 -> 导致不必要的重传 • 超时值过大 -> 导致过长的等待时间 • – 问题在于网络中的延迟不是固定的 • – 因此, 重传定时器必须能够自适应

  49. Karn 算法 无重传时，TCP根据下列（1），（2）重传时间 TIMEOUT=β*RTT（1） 其中，β>1的常数（TCP推荐β=2） RTT：估算的往返时间，是一个加权平均值。 RTT=α*Old_RTT+（1-α）*New_Round_Trip_Sample (2) 其中，0≤α≤1 常数加权因子 Old_RTT：上一个往返时间估算值。 New_Round_Trip_Sample：实际测出的前一个段的往返时间（样本）。 当发生重传时，用下列公式计算新的重传时间 New_Timeout=γ*Timeout (3) 其中，γ>1，典型值为γ=2，即每重传一次，超时值加倍。

  50. TCP 持续定时器 持续定时器: 促使发送方周期性地询问接收方接收窗口的大小 (即，接收窗口大小探测) • • 假定窗口大小变小为零，启动窗口的确认信息丢失 • 两边都将阻塞（blocked）.

More Related