第4讲 传输层之二.ppt

上传人:eveningprove235 文档编号:373639 上传时间:2018-10-05 格式:PPT 页数:32 大小:436KB
下载 相关 举报
第4讲 传输层之二.ppt_第1页
第1页 / 共32页
第4讲 传输层之二.ppt_第2页
第2页 / 共32页
第4讲 传输层之二.ppt_第3页
第3页 / 共32页
第4讲 传输层之二.ppt_第4页
第4页 / 共32页
第4讲 传输层之二.ppt_第5页
第5页 / 共32页
亲,该文档总共32页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、第4讲 传输层之二,4-1,第4讲 传输层之二,本讲目的: Internet传输层的实现和实例,本讲概述:面向连接的传输: TCP 可靠传输 流量控制 连接管理 TCP拥塞控制 拥塞控制原则,第4讲 传输层之二,4-2,TCP: 概述 RFCs: 793, 1122, 1323, 2018, 2581,全双工数据传输: 在同一连接上双向传输 MSS: maximum segment size(最大段字节数-1500,536,512) 面向连接: 握手过程 (交换控制信息) 在交换数据前初始化收发双方的状态,“三次握手” 流量控制: 发送方的发送速度不得超过接收方的处理速度,点对点: 一个发送方

2、, 一个接收方 可靠, 按序的字节流 : 无 “报文边界”,无结构但有顺序 流水式控制: TCP的拥塞和流量控制,设置窗口大小 发送& 接收缓存,第4讲 传输层之二,4-3,TCP 段格式(p238),URG: urgent data (一般不用),ACK: ACK # valid,PSH: push data now (一般不用),RST, SYN, FIN: connection estab (setup, teardown commands),# bytes 接收方愿意接受的,按发送数据的字节计算 (不是按段数!),Internet checksum (as in UDP),第4讲 传输

3、层之二,4-4,TCP seq. #s 和 ACKs,Seq. #s: 该数据段第一个字节在(整个报文)字节流中 “编号” ACKs: seq #为预期从对方发来的“下一个”字节的编号 积累的 ACK Q: 接收方如何接受失序的数据段 A: TCP 没有定义, - 由程序设计者决定,Host A,Host B,Seq=42, ACK=79, data = C,Seq=79, ACK=43, data = C,Seq=43, ACK=80,User types C,host ACKs receipt of echoed C,host ACKs receipt of C, echoes back

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

5、数据传输,00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = ne

6、xtseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compue new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y sendbase) /* cumulative ACK o

7、f all data up to y */ 16 cancel all timers for segments with sequence numbers y 17 sendbase = y 18 19 else /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y = 3) 22 /* TCP fast retransmit */ 23 resend s

8、egment with sequence number y 24 restart timer for segment y 25 26 /* end of loop forever */,简化的 TCP 发送方,第4讲 传输层之二,4-7,TCP ACK 规则 RFC 1122, RFC 2581,事件有序数据段到达, 没有缺失的段, 所有其他数据段已经 ACKed有序数据段到达, 没有缺失的段, 有一个延迟 ACK 等待失序数据段到达 seq. # 高于预期值 测到间隔到达的数据段部分或全部填满了缺失的段,TCP 接收方的动作延迟 ACK. 等待 500ms 看是否还有数据段到达. 如果没有,

9、 发送ACK立即发送一个 积欠的 ACK 发送重复的 ACK, 说明 seq. # 为下一个期望的字节立即 ACK,如果数据段处于缺失的段的较低端,第4讲 传输层之二,4-8,TCP: 重传场景,Host A,Seq=100, 20 bytes data,ACK=100,Seq=92 timeout,过早超时, 积欠 ACKs,Host B,Seq=92, 8 bytes data,ACK=120,Seq=92, 8 bytes data,Seq=100 timeout,ACK=120,第4讲 传输层之二,4-9,TCP 流量控制,接收端: 显式通知发送端 (动态变化中的) 自由缓存空间 Rc

10、vWindow TCP 数据段的字段 发送端: 需要保存已经发送, unACKed 数据可少于最近收到的RcvWindow,发送端不可发送的太多、太快以至于使得接收端的缓存溢出,接收端缓存,RcvBuffer = 接收端的 TCP 缓存大小RcvWindow = 缓存中空闲的部分,第4讲 传输层之二,4-10,TCP 交互的往返时间(RTT)和超时,Q: 如何设置 TCP 超时的值? 应较RTT长一点 注意: RTT 会变哟! 太短了: 过早出现超时 造成不必要的重传 太长了: 减缓了对数据段丢失的反应,Q: 如何估算 RTT? SampleRTT: 对数据段发送到收到ACK 回应的时间进行测

11、量 忽略重传, 积欠 ACKed 数据段 SampleRTT 是会变化的, 要使得估算的 RTT “更平滑” 使用若干新近的测量结果, 而不仅仅是最近一次的 SampleRTT,第4讲 传输层之二,4-11,TCP RTT 和超时 (p246),EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT,指数加权移动平均(EWMA) 给定样本的影响随指数形式快速递减 X的典型量值: 0.125或1/8,设置超时 EstimtedRTT 加上 “安全边际(safety margin)” 如果 EstimatedRTT变化较大 - 加大安全边际,Timeout

12、= EstimatedRTT + 4*Deviation,Deviation(偏差) = (1-x)*Deviation +x*|SampleRTT-EstimatedRTT|,第4讲 传输层之二,4-12,TCP 连接管理,回顾: TCP 收发双方在数据交换开始之前需要建立连接 初始化 TCP变量: seq. #s 缓存, 流量控制信息 (e.g. RcvWindow) 客户端: 连接的发起者Socket clientSocket = new Socket(“hostname“,“port number“); -JAVA 服务器: 接受客户端的连接Socket connectionSocke

13、t = 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讲 传输层之二,4-13,TCP 连接管理 (续),关闭连接: 客户端关闭插口: clientSocket.clo

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

15、d wait,closed,第4讲 传输层之二,4-15,TCP 连接管理 (续),TCP 客户端实例的生命周期,TCP 服务进程的生命周期,第4讲 传输层之二,4-16,拥塞控制原理,拥塞: 非正式的说法: “过多信源以过快的速率发送了过多的数据、导致网络穷于应付” 不同于流量控制! 后果: 丢失数据分组 (路由器缓存溢出) 长时间的延迟 (在路由器的缓存中排队) 在网络发展的技术中的a top-10 problem!,第4讲 传输层之二,4-17,缘由/代价-拥塞问题:场景1,两个发送端, 两个接收端 一个路由器, 有限缓存 无重传机制,发生拥塞时的延迟 可达到的最大吞吐量,第4讲 传输层

16、之二,4-18,缘由/代价-拥塞问题: 场景 2,一个路由器, 有限 缓存 发送端重传丢失的分组,第4讲 传输层之二,4-19,缘由/代价-拥塞问题: 场景 2,设计期望: (goodput) “完美的” 重传仅仅是在分组丢失时: 重传被延迟的 (而不是丢失的)分组造成大量无意义的 (比起完美的情况) 对同样的,拥塞的“代价” : 在给定的 “goodput”下需要做更多的工作(重传) 不必要的重传: 链路上充斥着分组的多个拷贝,第4讲 传输层之二,4-20,缘由/代价-拥塞问题: 场景 3,四个发送端 多步跳路径 超时/重传,Q: 当 和 增加时发生了什么?,第4讲 传输层之二,4-21,缘

17、由/代价-拥塞问题 : 场景 3,另一种拥塞的“代价”: 当分组被丢弃时, 所有“上游”信道为该分组所作的工作统统被浪费了!,第4讲 传输层之二,4-22,拥塞问题的解决方案,端对端的拥塞控制: 没有来自网络的反馈信息 对拥塞问题的了解来自于对数据丢失和延迟的推断 有 TCP来解决,网络辅助的拥塞控制: 路由器向端系统提供反馈 一个比特位的说明 (SNA, DECNet, TCP/IP ECN, ATM) 显式告知发送方所应采用的数据速率,两大类拥塞控制的办法:,第4讲 传输层之二,4-23,案例研究: ATM ABR 拥塞控制,ABR: available bit rate(可用数据速率):

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

19、发送端的发送速率可以在路径上得到最低程度的支持 数据信元的EFCI 位: 在拥塞的交换机中被设成 1 如果在RM信元之前的数据信元的EFCI置1, 发送端将在返回的 RM的RM信元中将CI置1,第4讲 传输层之二,4-25,TCP 拥塞控制,端到端的控制 (无需网络协助) 传输速率限制由建立在数据段之上的拥塞窗口尺寸Congwin决定:,w=数据段数量, 每个具有 MSS字节,在一个 RTT周期内发送:,Congwin,第4讲 传输层之二,4-26,TCP 拥塞控制:,两个 “阶段” slow start(慢启动) congestion avoidance(拥塞避免)重要变量: Congwin

20、 threshold: 定义两个慢启动之间,拥塞控制阶段的门限值,“刺探” 可用带宽: 理想情况: 全速传输 (Congwin 越大越好) 没有数据丢失 增加 Congwin 直到出现数据丢失 (拥塞) 数据丢失: 减小 Congwin, 然后重新开始进行刺探(增加Congwin),第4讲 传输层之二,4-27,TCP Slowstart(慢启动),窗口尺寸按指数递增 (每隔 RTT) (不算太慢!) 丢失事件: 超时(Tahoe TCP) 和/或三次重复 ACKs (Reno TCP),initialize: Congwin = 1 for (each segment ACKed)Congw

21、in+ until (loss event ORCongWin threshold),Host A,one segment,RTT,Host B,two segments,four segments,第4讲 传输层之二,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后,TC

22、P Reno 将跳过 slowstart (快速恢复 ) 在此阶段,Congwin以线性方式增长,发生超时,门限值减半,第4讲 传输层之二,4-29,TCP 拥塞避免策略: AIMD: additive increase(加法形式增加); multiplicative decrease(倍数形式减少) 每个RTT将窗口尺寸加1 当发生数据丢失时用2除窗口尺寸,AIMD,第4讲 传输层之二,4-30,TCP 公平性,公平性目标: 如果 N TCP 会话共享瓶颈链路, 每个应该分得 1/N 链路传输能力,TCP connection 1,bottleneck router capacity R,T

23、CP connection 2,第4讲 传输层之二,4-31,为什么说TCP是公平的?,两个竞争性的会话: 当吞吐量增加时,加法的结果斜率为 1 而成倍递减则会等比减少连接的吞吐量,R,R,同等的带宽共享,连接 1 的吞吐量,连接 2 的吞吐量,congestion avoidance: additive increase,loss: decrease window by factor of 2,拥塞避免: 加法形式增加窗口尺寸,丢包: 以2为除数减小窗口来进行,带宽的 充分使用,第4讲 传输层之二,4-32,第4讲: 小结,传输层服务原理: 复用/分用 可靠数据传输 流量控制 拥塞控制 因特网传输层的实现和实例 UDP TCP,下一步: 离开网络的“边缘” (应用/ 传输层) 进入网络的 “核心”,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 教学课件 > 大学教育

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1