第3讲 传输层协议及应用.ppt

《第3讲 传输层协议及应用.ppt》由会员分享，可在线阅读，更多相关《第3讲 传输层协议及应用.ppt（37页珍藏版）》请在麦多课文档分享上搜索。

1、1,第3讲 传输层协议及应用,本讲目的: 理解传输层服务的原理: 复用/分用 可靠数据传输 流量控制 拥塞控制 Internet传输层的实现和实例 教科书参考 第3章,本讲概述: 传输层的服务 复用/分用 无连接的传输: UDP 传输控制协议:TCP,2,传输层与网络层的关系,因特网中的传输层充当“收发室”的角色 因特网中的网络层充当“邮递业务”的角色 两个层次之间的任务可以互换，但是在实现成本上可能存在巨大差别,3,传输服务和协议,提供运行在不同主机中进程间的逻辑通信 传输协议仅运行在端系统中 传输 vs. 网络层服务 : 网络层: 在端系统间进行通信 传输层: 在进程间进行通信 依赖并加强

2、了网络层的服务,4,传输层协议,Internet 传输服务: 可靠, 按序点对点递交 (TCP) 拥塞控制 流量控制 连接建立 不可靠的 (“尽力而为”), 无序的点对点或广播递交: UDP 不能提供的服务: 实时性 带宽承诺 可靠的广播通信,5,P2,应用层对传输协议的复用/分用,segment （段）- 传输层实体间交换数据的单位 TPDU: 传输层数据单元,receiver,H,t,分用: 将接收到的段传递给正确的应用层进程,segment,segment,M,P1,P3,P4,segment header,application-layer data,6,应用层对传输协议的复用/分用,

3、复用/分用: 基于发送方, 接收方的端口号, IP 地址 源, 目的端口 #s 存在于每个段中 用于特定应用的常用端口号（well-known port number）：01023,从多个应用进程获取数据, 用首部(便于随后的分用)封装数据,源端口 #,宿端口 #,32 bits,应用层数据 (报文),其他首部字段,TCP/UDP 段格式,7,复用/分用: 举例,主机 A,服务器 B,端口的使用: 简单的 telnet 应用,Web客户端 主机 A,Web 服务器 B,Web客户端 主机 C,端口的使用: Web 服务器,8,UDP: 用户数据报协议 RFC 768,“最简约的” Intern

4、et 传输协议 “尽力而为的” 服务, UDP 数据段可以: 丢失 应用数据不按序到达 无连接: 在UDP收发双方之间, 无需握手信号 每个 UDP 数据段的操作都互相独立,为什么需要 UDP? 无需建立连接 (会增加延迟) 简单: 在收发双方之间没有连接状态 段首较短 无拥塞控制: UDP 可按需要随时发送,9,UDP: (续),经常为流媒体应用使用 允许数据丢失 对传输速率敏感 其他 UDP用途 : DNS SNMP 若需要通过 UDP进行可靠传输:在应用层增加可靠性措施 在应用程序中-专门的出错恢复机制!,源端口 #,宿端口 #,32 bits,应用层数据 (报文),UDP 数据报格式,

5、length,checksum,长度, UDP 段的字节数, 包括首部,10,UDP 校验和（checksum）,发送方: 将段的内容看作一串16位整数 checksum: 作段内容的加法(补码和) 发送方将补码和放入 UDP checksum 字段,接收方: 对接收到的段内容进行补码和计算 检查计算结果是否与收到的校验和相等: NO 查出错误 YES 没查出错误. 但是仍有可能存在错误?,目标: 检测传输段中的“错误” (e.g., 位错),11,TCP概述 RFCs: 793, 1122, 1323, 2018, 2581,全双工数据传输: 在同一连接上双向传输 MSS: maximum

6、segment size（最大段字节数-1500,536,512） 面向连接: 握手过程 (交换控制信息) 在交换数据前初始化收发双方的状态,“三次握手” 流量控制: 发送方的发送速度不得超过接收方的处理速度,点对点: 一个发送方, 一个接收方 可靠, 按序的字节流 : 无 “报文边界”，无结构但有顺序 流水式控制: TCP的拥塞和流量控制，设置窗口大小 发送& 接收缓存,12,TCP 段格式(p80),URG: urgent data （一般不用）,ACK: ACK # valid,PSH: push data now (一般不用),RST, SYN, FIN: connection est

7、ab (setup, teardown commands),# bytes 接收方愿意接受的,按发送数据的字节计算 (不是按段数!),Internet checksum (as in UDP),13,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,Se

8、q=43, ACK=80,User types C,host ACKs receipt of echoed C,host ACKs receipt of C, echoes back C,简单的 telnet 场景,14,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

9、 segment,retransmit segment,ACK processing,单向数据传输 无流量, 拥塞控制,15,TCP: 可靠数据传输,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

10、 timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + 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 rece

11、ived, with ACK field value of y 15 if (y sendbase) /* cumulative ACK of 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 dupli

12、cate ACKS received for y = 3) 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 26 /* end of loop forever */,简化的 TCP 发送方,16,TCP ACK 规则,事件有序数据段到达, 没有缺失的段, 所有其他数据段已经 ACKed有序数据段到达, 没有缺失的段, 有一个延迟 ACK 等待失序数据段到达 seq. # 高于预期值 测到间隔到达的数据段部分或全部填满了缺失的段,TCP

13、接收方的动作延迟 ACK. 等待 500ms 看是否还有数据段到达. 如果没有, 发送ACK立即发送一个 积欠的 ACK 发送重复的 ACK, 说明 seq. # 为下一个期望的字节立即 ACK，如果数据段处于缺失的段的较低端,17,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,18,TCP 流量控制,接收端: 显式通知发送端

14、(动态变化中的) 自由缓存空间 RcvWindow TCP 数据段的字段 发送端: 需要保存已经发送, unACKed 数据可少于最近收到的RcvWindow,发送端不可发送的太多、太快以至于使得接收端的缓存溢出,接收端缓存,RcvBuffer = 接收端的 TCP 缓存大小RcvWindow = 缓存中空闲的部分,19,TCP 连接管理,TCP 收发双方在数据交换开始之前需要建立连接 初始化 TCP变量: seq. #s 缓存, 流量控制信息 (e.g. RcvWindow) 客户端: 连接的发起者Socket clientSocket = new Socket(“hostname“,“po

15、rt 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 接收到的连接承诺 分配缓存,20,TC

16、P 连接管理 (续),关闭连接: 客户端关闭插口: clientSocket.close(); Step 1: 客户端 发送 TCP FIN 控制段给服务器 Step 2: 服务器 收到 FIN, 用 ACK应答. 关闭连接, 发送 FIN.,21,TCP 连接管理 (续),Step 3: 客户端 收到 FIN, 用 ACK进行应答. 随着对接收到的FIN发送ACK-同时进入 “timed wait（计时等待）” Step 4: 服务器, 接收 ACK. 连接关闭. 注意: 稍加修改,即可管理同时发生的多个FINs.,client,FIN,server,ACK,ACK,FIN,closing,

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

18、端 多步跳路径 超时/重传,Q: 当 和 增加时发生了什么?,26,缘由/代价-拥塞问题 : 场景 2,拥塞的“代价”: 当分组被丢弃时, 所有“上游”信道为该分组所作的工作统统被浪费了!,27,拥塞问题的解决方案,端对端的拥塞控制: 没有来自网络的反馈信息 对拥塞问题的了解来自于对数据丢失和延迟的推断 由 TCP来解决,网络辅助的拥塞控制: 路由器向端系统提供反馈 用一比特位说明 (SNA, DECNet, TCP/IP ECN, ATM) 显式告知发送方所应采用的数据速率,两大类拥塞控制的办法:,28,案例研究: ATM ABR 拥塞控制,ABR: available bit rate（可

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

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

21、门限值,“刺探” 可用带宽: 理想情况: 全速传输 (Congwin 越大越好) 没有数据丢失 增加 Congwin 直到出现数据丢失 (拥塞) 数据丢失: 减小 Congwin, 然后重新开始进行刺探(增加Congwin),32,TCP Slowstart（慢启动）,窗口尺寸按指数递增 (每隔 RTT) (不算太慢!) 丢失事件: 超时(Tahoe TCP) 和/或三次重复 ACKs (Reno TCP),initialize: Congwin = 1 for (each segment ACKed)Congwin+ until (loss event ORCongWin threshold

22、),Host A,one segment,RTT,Host B,two segments,four segments,33,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以线性方式增长，发生超时

23、，门限值减半,34,TCP 拥塞避免策略: AIMD: additive increase（加法形式增加）； multiplicative decrease（倍数形式减少） 每个RTT将窗口尺寸加1 当发生数据丢失时用2除窗口尺寸,AIMD,教科书：p90-91,35,TCP 公平性,公平性目标: 如果 N TCP 会话共享瓶颈链路, 每个应该分得 1/N 链路传输能力,TCP connection 1,bottleneck router capacity R,TCP connection 2,36,为什么说TCP是公平的?,两个竞争性的会话: 当吞吐量增加时，加法的结果斜率为 1 而成倍递减则会等比减少连接的吞吐量,R,R,同等的带宽共享,连接 1 的吞吐量,连接 2 的吞吐量,congestion avoidance: additive increase,loss: decrease window by factor of 2,拥塞避免: 加法形式增加窗口尺寸,丢包: 以2为除数减小窗口来进行,带宽的 充分使用,37,本讲小结,传输层服务原理: 复用/分用 可靠数据传输 流量控制 拥塞控制 因特网传输层的实现和实例 UDP TCP,下一步: 离开网络的“边缘” (应用/ 传输层) 进入网络的 “核心”,