第4讲 传输层之二 本讲目的: 本讲概述: Internet传输层的实现和实例 面向连接的传输: TCP TCP拥塞控制 拥塞控制原则

Presentation on theme: "第4讲 传输层之二 本讲目的: 本讲概述: Internet传输层的实现和实例 面向连接的传输: TCP TCP拥塞控制 拥塞控制原则"— Presentation transcript:

1 第4讲 传输层之二 本讲目的: 本讲概述: Internet传输层的实现和实例 面向连接的传输: TCP TCP拥塞控制 拥塞控制原则
第4讲 传输层之二 本讲目的: Internet传输层的实现和实例 本讲概述: 面向连接的传输: TCP 可靠传输 流量控制 连接管理 TCP拥塞控制 拥塞控制原则 第4讲 传输层之二

2 TCP: 概述 RFCs: 793, 1122, 1323, 2018, 2581 点对点: 全双工数据传输: 可靠, 按序的字节流 :
一个发送方, 一个接收方 可靠, 按序的字节流 : 无 “报文边界”，无结构但有顺序 流水式控制: TCP的拥塞和流量控制，设置窗口大小 发送& 接收缓存 全双工数据传输: 在同一连接上双向传输 MSS: maximum segment size（最大段字节数-1500,536,512） 面向连接: 握手过程 (交换控制信息) 在交换数据前初始化收发双方的状态,“三次握手” 流量控制: 发送方的发送速度不得超过接收方的处理速度 第4讲 传输层之二

3 acknowledgement number
TCP 段格式(p238) source port # dest port # 32 bits 应用数据 (可变长度) sequence number acknowledgement number rcvr window size ptr urgent data checksum F S R P A U head len not used Options (可变长度-MSS) URG: urgent data （一般不用） 按发送数据的字节计算 (不是按段数!) ACK: ACK # valid PSH: push data now (一般不用) # bytes 接收方愿意接受的 RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 第4讲 传输层之二

4 TCP seq. #’s 和 ACKs Seq. #’s: 该数据段第一个字节在（整个报文）字节流中 “编号” ACKs:
A: TCP 没有定义, - 由程序设计者决定 Host A Host B User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time 简单的 telnet 场景 第4讲 传输层之二

5 TCP: 可靠数据传输 简化的发送方, 假设 单向数据传输 无流量, 拥塞控制 wait for event
event: data received from application above 简化的发送方, 假设 单向数据传输 无流量, 拥塞控制 create, send segment wait for event wait for event event: timer timeout for segment with seq # y retransmit segment event: ACK received, with ACK # y ACK processing 第4讲 传输层之二

6 TCP: 可靠数据传输 简化的 TCP 发送方 00 sendbase = initial_sequence number
01 nextseqnum = initial_sequence number 02 loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number nextseqnum start timer for segment nextseqnum pass segment to IP nextseqnum = nextseqnum + length(data) event: timer timeout for segment with sequence number y retransmit segment with sequence number y compue new timeout interval for segment y restart timer for sequence number y event: ACK received, with ACK field value of y if (y > sendbase) { /* cumulative ACK of all data up to y */ cancel all timers for segments with sequence numbers < y sendbase = y } else { /* a duplicate ACK for already ACKed segment */ increment number of duplicate ACKs received for y if (number of duplicate ACKS received for y == 3) { /* TCP fast retransmit */ resend segment with sequence number y restart timer for segment y } } /* end of loop forever */ TCP: 可靠数据传输 简化的 TCP 发送方 第4讲 传输层之二

7 TCP ACK 规则 [RFC 1122, RFC 2581] TCP 接收方的动作 事件 有序数据段到达, 没有缺失的段,
所有其他数据段已经 ACKed 有一个延迟 ACK 等待 失序数据段到达 seq. # 高于预期值 测到间隔 到达的数据段部分或全部填满了缺失的段 TCP 接收方的动作 延迟 ACK. 等待 500ms 看是否还有数据段到达. 如果没有, 发送ACK 立即发送一个 积欠的 ACK 发送重复的 ACK, 说明 seq. # 为下一个期望的字节 立即 ACK，如果数据段处于缺失的段的较低端 第4讲 传输层之二

8 TCP: 重传场景 X loss time time 过早超时, 丢失 ACK 场景 积欠 ACKs Host A Host A
Seq=92, 8 bytes data ACK=100 loss timeout time 丢失 ACK 场景 Host B X Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 Seq=100 timeout ACK=120 Seq=92, 8 bytes data ACK=120 time 过早超时, 积欠 ACKs 第4讲 传输层之二

9 TCP 流量控制 流量控制 接收端: 显式通知发送端 (动态变化中的) 自由缓存空间 RcvWindow TCP 数据段的字段
发送端: 需要保存已经发送, unACKed 数据可少于最近收到的RcvWindow 发送端不可发送的太多、太快以至于使得接收端的缓存溢出 RcvBuffer = 接收端的 TCP 缓存大小 RcvWindow = 缓存中空闲的部分 接收端缓存 第4讲 传输层之二

10 TCP 交互的往返时间（RTT）和超时 Q: 如何估算 RTT? Q: 如何设置 TCP 超时的值?
太短了: 过早出现超时 造成不必要的重传 太长了: 减缓了对数据段丢失的反应 Q: 如何估算 RTT? SampleRTT: 对数据段发送到收到ACK 回应的时间进行测量 忽略重传, 积欠 ACKed 数据段 SampleRTT 是会变化的, 要使得估算的 RTT “更平滑” 使用若干新近的测量结果, 而不仅仅是最近一次的 SampleRTT 第4讲 传输层之二

11 TCP RTT 和超时 (p246) 设置超时 EstimtedRTT 加上 “安全边际(safety margin)”
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT 指数加权移动平均（EWMA） 给定样本的影响随指数形式快速递减 X的典型量值: 0.125或1/8 设置超时 EstimtedRTT 加上 “安全边际(safety margin)” 如果 EstimatedRTT变化较大 -> 加大安全边际 Timeout = EstimatedRTT + 4*Deviation Deviation(偏差) = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT| 第4讲 传输层之二

12 TCP 连接管理 (建立连接)三次握手: 回顾: TCP 收发双方在数据交换开始之前需要建立连接 初始化 TCP变量: seq. #s
缓存, 流量控制信息 (e.g. RcvWindow) 客户端: 连接的发起者 Socket clientSocket = new Socket("hostname","port number"); -JAVA 服务器: 接受客户端的连接 Socket connectionSocket = welcomeSocket.accept(); (建立连接)三次握手: Step 1: 客户端的end system向服 务器发送 TCP SYN 控制数据段 定义并初始化 seq # Step 2: 服务器的end system接收 SYN, 用SYNACK控制数据段回 答 ACKs 接收到的 SYN 分配缓存 定义 server-> receiver 初始化 seq. # Step 3:客户端的end system向服务器发送ACK ACKs 接收到的连接承诺 第4讲 传输层之二

13 TCP 连接管理 (续) 关闭连接: Step 1: 客户端 end system 发送 TCP FIN 控制段给服 务器
客户端关闭插口: clientSocket.close(); Step 1: 客户端 end system 发送 TCP FIN 控制段给服 务器 Step 2: 服务器 收到 FIN, 用 ACK应答. 关闭连接, 发 送 FIN. client FIN server ACK close closed timed wait 第4讲 传输层之二

14 TCP 连接管理 (续) Step 3: 客户端 收到 FIN, 用 ACK进行应答. Step 4: 服务器, 接收 ACK. 连接关闭.
随着对接收到的FIN发送 ACK-同时进入 “timed wait（计时等待）” Step 4: 服务器, 接收 ACK. 连接关闭. 注意: 稍加修改,即可管理同 时发生的多个FINs. client server closing FIN ACK closing FIN ACK timed wait closed closed 第4讲 传输层之二

15 TCP 连接管理 (续) TCP 服务进程的生命周期 TCP 客户端实例的生命周期 第4讲 传输层之二

16 拥塞控制原理 拥塞: 非正式的说法: “过多信源以过快的速率发送了过多的数据、导致网络穷于应付” 不同于流量控制! 后果:
丢失数据分组 (路由器缓存溢出) 长时间的延迟 (在路由器的缓存中排队) 在网络发展的技术中的a top-10 problem! 第4讲 传输层之二

17 缘由/代价-拥塞问题:场景1 两个发送端, 两个接收端 一个路由器, 有限缓存 无重传机制 发生拥塞时的延迟 可达到的最大吞吐量
第4讲 传输层之二

18 缘由/代价-拥塞问题: 场景 2 一个路由器, 有限 缓存 发送端重传丢失的分组 第4讲 传输层之二

19 缘由/代价-拥塞问题: 场景 2 l l l l > 设计期望: (goodput) = “完美的” 重传仅仅是在分组丢失时: out
in out = 设计期望: (goodput) “完美的” 重传仅仅是在分组丢失时: 重传被延迟的 (而不是丢失的)分组造成大量无意义的 (比起完美的情况) 对同样的 l in out > l in l out 拥塞的“代价” : 在给定的 “goodput”下需要做更多的工作(重传) 不必要的重传: 链路上充斥着分组的多个拷贝 第4讲 传输层之二

20 缘由/代价-拥塞问题: 场景 3 l l Q: 当 和 增加时发生了什么? 四个发送端 多步跳路径 超时/重传 in in
第4讲 传输层之二

21 缘由/代价-拥塞问题 : 场景 3 另一种拥塞的“代价”: 当分组被丢弃时, 所有“上游”信道为该分组所作的工作统统被浪费了!
第4讲 传输层之二

22 拥塞问题的解决方案 两大类拥塞控制的办法: 端对端的拥塞控制: 网络辅助的拥塞控制: 没有来自网络的反馈信息 路由器向端系统提供反馈
对拥塞问题的了解来自于对数据丢失和延迟的推断 有 TCP来解决 网络辅助的拥塞控制: 路由器向端系统提供反馈 一个比特位的说明 (SNA, DECNet, TCP/IP ECN, ATM) 显式告知发送方所应采用的数据速率 第4讲 传输层之二

23 案例研究: ATM ABR 拥塞控制 ABR: available bit rate（可用数据速率）:
“弹性服务” 如果发送方的路径“欠负载” 发送端应该把带宽用足 如果发送端路径拥塞: 发送端将其数据速率约束到最小承诺速率 RM (resource management) cells（资源管理信元）: 由发送端发送, 掺和在数据信元一起 在 RM 信元中的数据位由交换机设定 (“网络辅助”) NI bit: 不得增加发送速率 (轻微拥塞) CI bit: 拥塞指示 RM信元由接收端返回给发送端, 所有数据位保持原样 第4讲 传输层之二

24 案例研究: ATM ABR 拥塞控制 在RM信元中有2字节的 ER (explicit rate) 字段
发送端的发送速率可以在路径上得到最低程度的支持 数据信元的EFCI 位: 在拥塞的交换机中被设成 1 如果在RM信元之前的数据信元的EFCI置1, 发送端将在返回的 RM的RM信元中将CI置1 第4讲 传输层之二

25 TCP 拥塞控制 w=数据段数量, 每个具有 MSS字节,在一个 RTT周期内发送: 端到端的控制 (无需网络协助)
传输速率限制由建立在数据段之上的拥塞窗口尺寸Congwin决定: Congwin w=数据段数量, 每个具有 MSS字节,在一个 RTT周期内发送: 吞吐量 = w * MSS RTT Bytes/sec 第4讲 传输层之二

26 TCP 拥塞控制: “刺探” 可用带宽: 两个 “阶段” 重要变量: 理想情况: 全速传输 (Congwin 越大越好) 没有数据丢失
数据丢失: 减小 Congwin, 然后重新开始进行刺探(增加Congwin) 两个 “阶段” slow start（慢启动） congestion avoidance（拥塞避免） 重要变量: Congwin threshold: 定义两个慢启动之间，拥塞控制阶段的门限值 第4讲 传输层之二

27 TCP Slowstart（慢启动） Slowstart 算法 initialize: Congwin = 1
Host A Host B Slowstart 算法 one segment initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) RTT two segments four segments 窗口尺寸按指数递增 (每隔 RTT) (不算太慢!) 丢失事件: 超时(Tahoe TCP) 和/或三次重复 ACKs (Reno TCP) time 第4讲 传输层之二

28 TCP 拥塞避免 拥塞避免 /* slowstart is over */ /* Congwin > threshold */
Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: 在出现三次重复的ACK后，TCP Reno 将跳过 slowstart (快速恢复 ) 在此阶段，Congwin以线性方式增长，发生超时，门限值减半 第4讲 传输层之二

29 AIMD TCP 拥塞避免策略: AIMD: 每个RTT将窗口尺寸加1 当发生数据丢失时用2除窗口尺寸
additive increase（加法形式增加）； multiplicative decrease（倍数形式减少） 每个RTT将窗口尺寸加1 当发生数据丢失时用2除窗口尺寸 第4讲 传输层之二

30 TCP 公平性 公平性目标: 如果 N TCP 会话共享瓶颈链路, 每个应该分得 1/N 链路传输能力 TCP connection 1
bottleneck router capacity R TCP connection 2 第4讲 传输层之二

31 为什么说TCP是公平的? 两个竞争性的会话: 当吞吐量增加时，加法的结果斜率为 1 而成倍递减则会等比减少连接的吞吐量 R R
带宽的 充分使用 R 同等的带宽共享 丢包: 以2为除数减小窗口来进行 拥塞避免: 加法形式增加窗口尺寸 连接 2 的吞吐量 loss: decrease window by factor of 2 congestion avoidance: additive increase 连接 1 的吞吐量 R 第4讲 传输层之二

32 第4讲: 小结 下一步: 传输层服务原理: 离开网络的“边缘” (应用/ 传输层) 进入网络的 “核心” 复用/分用 可靠数据传输 流量控制
拥塞控制 因特网传输层的实现和实例 UDP TCP 下一步: 离开网络的“边缘” (应用/ 传输层) 进入网络的 “核心” 第4讲 传输层之二