课程议题

1. 课程议题 传 输 层

2. 提供不同主机上运行的程序进程之间的逻辑通信提供不同主机上运行的程序进程之间的逻辑通信 传输协议运行在端点系统 发送方: 把报文分成段, 传到网络层 接收方: 把段重新组成报文, 传到应用层 不止一个传输协议可以应用 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 传输服务和协议

3. 网络层:主机之间的逻辑通信 传输层:进程之间的逻辑通信 依赖, 增强, 网络层服务 家庭类比: 12 个小孩发送字母给12个小孩 进程 = 小孩 程序报文 = 信封里的字母 主机 = 房子 传输协议 = Ann和Bill 网络层协议 = 邮局服务 传输 vs. 网络层

4. 可信, 按序传输 (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 Internet 传输层协议

5. application application application transport transport transport P4 P2 P1 P1 P3 network network network link link link physical physical physical 在发送主机复用: 在接收主机解复用: host 3 host 2 host 1 复用/解复用 把收到的段传输给合适的socket 把数据从多个socket集合在一 起, 用报头封装数据 (随后用于 解复用) = socket = process

6. 主机收到 IP数据报 每个数据报有源IP地址, 目标IP地址 每个数据报携带1个传输层的段 每个段有源地址,目标端口号 (回忆: 特定应用的熟知端口号) 主机使用IP地址和端口号把段指向合适的socket 解复用是怎么工作的 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format

7. 用端口号创建socket: DatagramSocket mySocket1 = new DatagramSocket(99111); DatagramSocket mySocket2 = new DatagramSocket(99222); UDP socket标识为二元组: (目标IP地址, 目标端口号) 当主机收到UDP报文段: 检查报文段中的目标端口号 用端口号定向UDP报文段到 socket 有不同源IP地址和/或源端口号的数据报定向到同一个socket 无连接解复用

8. P2 P1 P1 P3 SP: 9157 client IP: A DP: 6428 Client IP:B server IP: C SP: 5775 SP: 6428 SP: 6428 DP: 6428 DP: 9157 DP: 5775 无连接解复用 (续) DatagramSocket serverSocket = new DatagramSocket(6428); SP 提供 “返回地址”

9. TCP socket标识为四元组: 源IP地址 源端口号 目标IP地址 目标端口号 接收主机使用全部四个值 把报文段定向到适当的 socket 服务器主机可能支持多个同时的TCP sockets: 每个socket标识为它自己的 四元组 Web服务器上每个连接的客户有不同的socket 非持久HTTP 中每个请求都有不同的socket 面向连接的解复用

10. SP: 5775 SP: 9157 P1 P1 P2 P4 P3 P6 P5 client IP: A DP: 80 DP: 80 面向连接的解复用(续) S-IP: B D-IP:C SP: 9157 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C

11. SP: 5775 SP: 9157 P1 P1 P2 P3 client IP: A DP: 80 DP: 80 面向连接的解复用: Threaded Web Server P4 S-IP: B D-IP:C SP: 9157 DP: 80 Client IP:B server IP: C S-IP: A S-IP: B D-IP:C D-IP:C

12. “没有虚饰,”“不加渲染”Internet 传输协议 “尽最大努力”的服务, UDP 报文段可能: 丢失 无序传输到应用 无连接: UDP 发送者和接收者之间没有握手 每个UDP段独立于其他处理 为什么有UDP? 没有连接建立 (可能增加时延) 简单: 发送者，接收者没有连接状态 段报头比较小 没有拥塞控制: UDP能尽可能地快 UDP: User Datagram Protocol [RFC 768]

13. 常用于流媒体应用 允许丢失 速度敏感 其他UDP应用 DNS SNMP UDP的可信传输 :在应用层增加可靠性 特定应用程序的错误 恢复! UDP: 更多 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format

14. 发送者: 把报段内容作为16位整数序列 检验和: 报文内容加起来(1’s complement sum) 发送者把检验和的值放入UDP检验和字段 Receiver: 计算收到的报文的检验和 检查计算出的检验和是否与检验和字段里的值相等 : 不相等 –检测到错误 相等 –没有检测到错误. 但也许尽管如此还是有错误?稍后了解更多 …. UDP 检验和 目标:在传输的报段中检测“错误”(e.g., flipped bits)

15. Internet 检验和的例子 • 注意 • 加数的时候, 最高位的进位需要加到结果中 • 例如: 两个16位的数相加 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 wraparound sum checksum

16. 在应用层，传输层和链路层重要 网络方面的话题中重要性排前10! 不可靠信道的特征决定可靠数据传输协议的复杂性(rdt) 可靠数据传输的原理

17. rdt_send():从上层调用, (e.g., 应用层.). 把数据传输到接收者的上层 deliver_data():rdt调用， 数据向上传输 udt_send():rdt调用,在不可信的信道中传输包给接收者 rdt_rcv():当包到达接收端的信道时被调用 可靠数据传输: 开始 send side receive side

18. 我们将: 开发发送者, 接收者端的可靠数据传输协议 (rdt) 只考虑单向数据传输 但控制信息将是双向的! 使用有限状态机 (FSM) 表示发送者, 接收者 event state 1 state 2 actions 可靠数据传输: 开始 event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event

19. 潜在的信道非常可靠 没有bit错误 没有分组丢失 给发送者和接收者分离FSMs : 发送者发送数据到潜在的信道 接收者从潜在的信道读取数据 Rdt1.0: 在可靠信道上的可靠传输 rdt_send(data) rdt_rcv(packet) Wait for call from below Wait for call from above extract (packet,data) deliver_data(data) packet = make_pkt(data) udt_send(packet) sender receiver

20. 信道可能丢失包中的比特 检验和以检测比特错误 问题: 如何修复错误: 确认帧 (ACKs):接收者明确告诉发送者收到的pkt没有问题 否认帧 (NAKs):接收者明确告诉发送者pkt有错误 发送者收到 NAK后转发 pkt rdt2.0中的新机制(超越rdt1.0): 错误检测 接收者反馈: 控制消息 (ACK,NAK) 接收者->发送者 Rdt2.0: 有bit错误的信道

21. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) Wait for call from below rdt2.0: FSM 表示 rdt_send(data) receiver snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) L sender rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

22. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) rdt2.0: 无错误操作 rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

23. Wait for ACK or NAK rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(NAK) rdt2.0: 错误的情况 rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) Wait for call from above udt_send(sndpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) Wait for call from below L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK)

24. 如果 ACK/NAK 被破坏怎么办? 发送者不知道接收者发生了什么事情! 不能仅仅重传: 也许可以复制 处理复制品: 发送者增加每个pkt的 序列号 如果 ACK/NAK 出问题，发送者转发当前的pkt 接收者丢弃 (不发送) 复制的 pkt 停下来等一等 rdt2.0 有一个致命的缺点! 发送者发送一个分组, 等待接收者响应

25. Wait for ACK or NAK 0 Wait for call 1 from above Wait for ACK or NAK 1 rdt2.1: 发送者, 处理错误的ACK/NAKs rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) Wait for call 0 from above udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) L L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) udt_send(sndpkt)

26. Wait for 0 from below Wait for 1 from below rdt2.1: 接收者, 处理错误的 ACK/NAKs rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt)

27. 发送者: 给pkt增加序号 两个序号 (0,1) 就足够了. 为什么? 必须检查是否收到的 ACK/NAK 被破坏 twice as many states 状态必须 “记住”“当前的”pkt序号为0还是1 接收者: 必须检查收到的包是否为复制的 状态指示0或1是否为期望的pkt序号 注意: 接收者不能知道它的最近的ACK/NAK 是否被发送者正常收到了 rdt2.1: 讨论

28. rdt2.1有相同的功能, 只使用ACKs instead of NAK, 接收者为最近正常收到的pkt发送ACK 接收者必须明确包含pkt的被确认的序号 发送者复制的ACK 导致和NAK相同的动作: 转发当前的 pkt rdt2.2: a NAK-free protocol

29. Wait for call 0 from above Wait for ACK 0 Wait for 0 from below rdt2.2: 发送者, 接收者片段 rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) udt_send(sndpkt) sender FSM fragment rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || has_seq1(rcvpkt)) L receiver FSM fragment udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt)

30. 新的假设: 信道也可能丢失分组 (数据或ACKs) 检验和, seq. #, ACKs, 转发是有帮助的, 但是不够 方法:发送者在“合理的”时间内等待 ACK 如果在这段时间内没有收到ACK就重传 如果pkt (或者ACK) 只是延迟了 (没有丢失): 重传会带来重复, 但使用序号已经处理了这个问题 接收者必须指定被确认的 pkt的序号 需要倒计时计时器 rdt3.0: 带错误和丢失的信道

31. Wait for ACK0 Wait for ACK1 Wait for call 1 from above Wait for call 0from above rdt3.0 发送者 rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer L rdt_rcv(rcvpkt) L timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) stop_timer stop_timer timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_send(data) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer L

32. rdt3.0 运转

33. rdt3.0 运转

34. rdt3.0 能运转, 但性能下降 例子: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: rdt3.0的性能 L (packet length in bits) 8kb/pkt T = = = 8 microsec transmit R (transmission rate, bps) 10**9 b/sec • U sender: utilization– fraction of time sender busy sending • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • 网络协议限制使用物理资源!

35. rdt3.0: 停止等待 操作 sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R

36. 管道化:发送者允许多个, “正在传输中的”, 仍然需要确认的pkts 序号的范围必须增加 在发送者和/或接收者之间缓冲 两个常见的管道协议: 后退N, 选择重传 管道协议

37. 管道化: 增加利用率 sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3!

38. 发送者: 在pkt首部有k比特的序号 “窗口” 最大为 N, 允许连续的未确认pkt 后退N • ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” • 可能收到重复的ACKs (见接收者) • 每个正在发送的分组用同一个定时器 • timeout(n):重传pkt n 和窗口中更高序号的pkt

39. Wait GBN: 发送者扩展 FSM rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) L base=1 nextseqnum=1 timeout start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) … udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer

40. 只有ACK: 总是发送为正常收到的最高序号的pkt发送 ACK 可能产生重复的 ACK 只需要记住 expectedseqnum 无序的 pkt: 丢弃 (不缓冲) -> 没有接收者的缓冲! 重新确认最高序号的 pkt GBN: 接收者 FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) L Wait extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum)

41. GBN 运转

42. 接收者个别地 确认所有正常收到的pkt 根据需要为最终有序传输到更高层的pkt缓冲 发送者仅仅重发没有收到确认帧的pkt 发送者为每个没有确认的pkt计时 发送窗口 N个连续的序号 也需要限制已发送但尚未应答分组的序号 选择重传

43. 选择重传: 发送, 接收窗口

44. data from above : 如果窗口中有下一个可用序号, 发送 pkt timeout(n): 重发 pkt n, 重新开始计时 ACK(n) in [sendbase,sendbase+N]: 标记 pkt n 为已收到 if n smallest unACKed pkt, advance window base to next unACKed seq # 接收方 发送方 选择重传 pkt n in [rcvbase, rcvbase+N-1] • 发送ACK(n) • 无序: 缓冲 • in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-N,rcvbase-1] • ACK(n) otherwise: • 忽略

45. 选择重传的运转

46. 例子: 序号: 0, 1, 2, 3 窗口 size=3 两种情况在接收方看来没有区别! (a)中错误地把重复数据当作新数据传输 Q:序号范围和窗口尺寸之间有什么关系? 选择重传:困境

47. 全双工数据: 在同一连接中双向数据流 MSS: maximum segment size 面向连接: 握手(交换控制消息)数据交换前初始化发送者和接收者的状态 流量控制: 发送方不会覆没接收方 点到点: 一个发送者, 一个接收者 可靠的, 有序的字节流: 没有 “报文边界” 管道的: TCP 拥塞和流量控制设置窗口大小 发送& 接收缓冲 TCP: 概述 RFCs: 793, 1122, 1323, 2018, 2581

48. 32 bits source port # dest port # sequence number acknowledgement number head len not used Receive window U A P R S F checksum Urg data pnter Options (variable length) application data (variable length) TCP 报文段结构 URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

49. 序号: 在报文段数据的第一个字节的字节流 “数字” ACKs: 另一方期望的下一字节的序号 累计的ACK Q:接收方如何处理无序的报文段 A: TCP没有说明, 取决于实现者 time TCP 序号和ACK 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 simple telnet scenario

50. Q:如何设置TCP 超时的值? 比 RTT长 但是RTT会变化 太短: 超时设置太早 不必要的重发 太长: 对报文段的丢失反应太慢 Q:如何估计 RTT? SampleRTT:度量时间从报文段发送直到收到ACK 忽略重发 SampleRTT会有变化, 想要“更平滑地”估算 RTT 取最近的几个时间度量的平均值, 而不仅仅是当前的 SampleRTT TCP 往返时延和超时