1 / 37

第 3 讲 传输层协议及应用

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

juro
Download Presentation

第 3 讲 传输层协议及应用

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. 本讲目的: 理解传输层服务的原理: 复用/分用 可靠数据传输 流量控制 拥塞控制 Internet传输层的实现和实例 教科书参考 第3章 本讲概述: 传输层的服务 复用/分用 无连接的传输: UDP 传输控制协议:TCP 第3讲传输层协议及应用

  2. 传输层与网络层的关系 • 因特网中的传输层充当“收发室”的角色 • 因特网中的网络层充当“邮递业务”的角色 • 两个层次之间的任务可以互换，但是在实现成本上可能存在巨大差别

  3. 提供运行在不同主机中进程间的逻辑通信 传输协议仅运行在端系统中 传输 vs. 网络层服务 : 网络层:在端系统间进行通信 传输层:在进程间进行通信 依赖并加强了网络层的服务 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport 传输服务和协议

  4. Internet 传输服务: 可靠, 按序点对点递交 (TCP) 拥塞控制 流量控制 连接建立 不可靠的 (“尽力而为”), 无序的点对点或广播递交: UDP 不能提供的服务: 实时性 带宽承诺 可靠的广播通信 application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport 传输层协议

  5. segment （段）- 传输层实体间交换数据的单位 TPDU: 传输层数据单元 M M M M application transport network application transport network application transport network H n 应用层对传输协议的复用/分用 分用:将接收到的段传递给正确的应用层进程 receiver P3 P4 application-layer data segment header P1 P2 segment H t M segment

  6. 复用/分用: 基于发送方, 接收方的端口号, IP 地址 源, 目的端口 #s 存在于每个段中 用于特定应用的常用端口号（well-known port number）：0～1023 复用: 应用层对传输协议的复用/分用 从多个应用进程获取数据, 用首部(便于随后的分用)封装数据 32 bits 源端口# 宿端口# 其他首部字段 应用层数据 (报文) TCP/UDP 段格式

  7. Source IP: C Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: A Dest IP: B source port: x dest. port: 80 source port:23 dest. port: x source port: x dest. port: 23 复用/分用: 举例 Web客户端 主机 C 服务器 B 主机 A 端口的使用: 简单的 telnet 应用 Web 服务器 B Web客户端 主机 A 端口的使用: Web 服务器

  8. “最简约的”Internet 传输协议 “尽力而为的” 服务, UDP 数据段可以: 丢失 应用数据不按序到达 无连接: 在UDP收发双方之间, 无需握手信号 每个 UDP 数据段的操作都互相独立 为什么需要 UDP? 无需建立连接 (会增加延迟) 简单: 在收发双方之间没有连接状态 段首较短 无拥塞控制: UDP 可按需要随时发送 UDP: 用户数据报协议 [RFC 768]

  9. 经常为流媒体应用使用 允许数据丢失 对传输速率敏感 其他 UDP用途 : DNS SNMP 若需要通过 UDP进行可靠传输:在应用层增加可靠性措施 在应用程序中-专门的出错恢复机制! UDP: (续) 32 bits 源端口 # 宿端口 # 长度, UDP 段的字节数, 包括首部 checksum length 应用层数据 (报文) UDP 数据报格式

  10. 发送方: 将段的内容看作一串16位整数 checksum: 作段内容的加法(补码和) 发送方将补码和放入 UDP checksum 字段 接收方: 对接收到的段内容进行补码和计算 检查计算结果是否与收到的校验和相等: NO –查出错误 YES –没查出错误. 但是仍有可能存在错误? UDP 校验和（checksum） 目标:检测传输段中的“错误”(e.g., 位错)

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

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

  13. Seq. #’s: 该数据段第一个字节在（整个报文）字节流中 “编号” ACKs: seq #为预期从对方发来的“下一个”字节的编号 积累的 ACK Q:接收方如何接受失序的数据段 A: TCP 没有定义, - 由程序设计者决定 time TCP seq. #’s 和 ACKs Host B Host A 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 简单的 telnet 场景

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

  15. TCP: 可靠数据传输 00sendbase = 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 = 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 received, 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 duplicate 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 规则 TCP 接收方的动作 延迟 ACK. 等待 500ms 看是否还有数据段到达. 如果没有, 发送ACK 立即发送一个 积欠的 ACK 发送重复的 ACK, 说明 seq. # 为下一个期望的字节 立即 ACK，如果数据段处于缺失的段的较低端 事件 有序数据段到达, 没有缺失的段, 所有其他数据段已经 ACKed 有序数据段到达, 没有缺失的段, 有一个延迟 ACK 等待 失序数据段到达 seq. # 高于预期值 测到间隔 到达的数据段部分或全部填满了缺失的段

  17. Host A Host B Seq=92, 8 bytes data ACK=100 timeout X loss Seq=92, 8 bytes data ACK=100 time time 丢失 ACK 场景 TCP: 重传场景 Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 ACK=120 Seq=100 timeout Seq=92, 8 bytes data ACK=120 过早超时, 积欠 ACKs

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

  19. 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 接收到的连接承诺 分配缓存 TCP 连接管理

  20. 关闭连接: 客户端关闭插口:clientSocket.close(); Step 1:客户端 发送 TCP FIN 控制段给服务器 Step 2:服务器 收到 FIN, 用 ACK应答. 关闭连接, 发送 FIN. client server close FIN ACK close FIN ACK timed wait closed TCP 连接管理 (续)

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

  22. TCP 连接管理 (续) TCP 服务进程的生命周期 TCP 客户端实例的生命周期

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

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

  25. 四个发送端 多步跳路径 超时/重传 l l in in 缘由/代价-拥塞问题: 场景 2 Q:当 和 增加时发生了什么?

  26. 缘由/代价-拥塞问题 : 场景 2 拥塞的“代价”: • 当分组被丢弃时, 所有“上游”信道为该分组所作的工作统统被浪费了!

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

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

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

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

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

  32. 窗口尺寸按指数递增 (每隔 RTT) (不算太慢!) 丢失事件: 超时(Tahoe TCP) 和/或三次重复 ACKs (Reno TCP) Slowstart 算法 time TCP Slowstart（慢启动） Host A Host B one segment RTT initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) 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以线性方式增长，发生超时，门限值减半

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

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

More Related