计算机网络-3

1、 运输层1第3章 运输层Transport Layer 计算机网络：自顶向下方法 (原书第四版)陈鸣译，机械工业出版社，2010年Computer Networking: A Top Down Approach , 4rd edition. Jim Kurose, Keith RossAddison-Wesley, July 2008. 运输层2第3章:运输层目标: r理解运输层服务依据的原理:m复用/分解m可靠数据传输m流量控制m拥塞控制r学习因特网中的运输层协议：mUDP: 无连接传输mTCP: 面向连接传输mTCP 拥塞控制 运输层3第3章 要点r3.1 运输层服务r3.2 复用与分解r

2、3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控制的原则r3.7 TCP拥塞控制m机制mTCP吞吐量mTCP公平性m时延模型 运输层43.1运输服务和协议r为运行在不同主机上的应用进程之间提供逻辑通信r应用层使用其逻辑功能，不需考虑物理设施P124r运输协议运行在端系统中m发送方：将应用报文划分为段，传向网络层m接收方：将段重新装配为报文，传向应用层r路由器？运行在网络层P124r可供应用程序使用的运输协议不止一个m因特网：TCP和UDP应用层运输层

3、网络层数据链路层物理层网络层数据链路层物理层应用层运输层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层逻辑端到端传输 运输层53.1.1运输层 vs. 网络层r网络层: 主机间的逻辑通信r运输层: 进程间的逻辑通信m依赖并强化网络层服务家庭类比:12个孩子向12个孩子发信r进程 = 孩子r应用报文= 信封中的信r主机 = 家庭r运输协议 = Ann和Billr网络层协议= 邮政服务 运输层6因特网运输层协议P126r可靠的、按序的交付 (TCP)m拥塞控制m流量控制m连接建立r不可靠、不按序交付: UDPm“尽力而为”IP的不提供

4、不必要服务的扩展r网络层IP协议：为主机之间提供尽力而为的交付服务，不可靠的r网络层的主机之间的交付扩展为运输层主机进程之间的交互：多路复用与多路分解应用层运输层网络层数据链路层物理层网络层数据链路层物理层应用层运输层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层逻辑端到端传输 运输层7第3章 要点r3.1 运输层服务r3.2 复用与分解r3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控

5、制的原则r3.7 TCP拥塞控制m机制mTCP吞吐量mTCP公平性m时延模型 运输层83.2 Internet 层的复用与分解运输层运输层网络层WEBFTPTELNETTELNET如何实现交付给不同的应用层进程？ 运输层93.2 复用/分解(类比家庭收信/发信)= 进程= 套接字 将接收到的报文段分解交付 给正确的套接字在接收主机分解：从多个套接字收集数据，用首部封装数据(以后用于分解 )生成报文段，传递到网络层在发送主机复用:应用层运输层网络层链路层物理层P1应用层运输层网络层链路层物理层应用层运输层network链路层物理层P2P3P4P1主机1主机2主机3端口r套接字有唯一标识符r每个报

6、文段用端口号指示要交付的套接字r端口号：16bitr0-65535r周知端口号（默认保留）：0-1023 运输层10 运输层113.2分解工作过程r主机接收IP数据报m每个数据报有源IP地址, 目标IP地址m每个数据报承载1个运输层的段m每个段具有源、目的端口号 源端口 #目的端口 #32 bits应用数据(报文)其他首部字段TCP/UDP 段格式 运输层123.2分解工作过程r主机上的每个套接字被分配一个端口号，当报文段到达主机时，运输层检查报文段中的目的端口号，并将其定向到相应的套接字。套接字完成数据到应用程序的交互。源端口 #目的端口 #32 bits应用数据(报文)其他首部字段TCP/

7、UDP 段格式 运输层133.2.1无连接分解P130r生成具有端口号的套接字:DatagramSocket mySocket1 = new DatagramSocket(99111);DatagramSocket mySocket2 = new DatagramSocket(99222);rUDP套接字由二元组标识 :r当主机接收UDP段时:m在段中检查目的地端口号m将UDP段定向到具有该端口号的套接字过程：发送方创建运输层报文段，包括数据、源端口号，目的端口号，和其它值，传递到网络层封装为IP数据报，尽力而为交付给接收方。接收方检查目的端口号，并将该报文段传递给端口号所标识的套接字。r具有

8、不同源IP+PORT，但具有相同IP+PORT的数据将交给相同的套接字？ 运输层143.2.1无连接分解(续)DatagramSocket serverSocket = new DatagramSocket(6428);客户机客户机IP:BP2客户机 IP: AP1P1P3服务器IP: CSP: 6428DP: 9157SP: 9157DP: 6428SP: 6428DP: 5775SP: 5775DP: 6428SP提供了“返回地址” 运输层153.2.2面向连接分解P130rTCP套接字由四元组标识: m源IP地址m源端口号m目的IP地址m目的端口号r接收主机使用这四个值来将段定向到适当的

9、套接字r具有不同源IP+PORT，但具有相同IP+PORT的数据将交给相同的套接字？ 运输层163.2.2面向连接分解 (续)客户机IP:BP1客户机 IP: AP1P2P4服务器IP: CP5P6P3SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80D-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: B 运输层173.2.2面向连接分解-服务器P131r服务器主机可能支持许多并行的TCP套接字：m每个套接字由其自己的四元组标识rWeb服务器对每个连接的客户机分配不同的套接字m非持久HTTP将为每个请求分配不同的套接字 运输层183.2

10、.2面向连接分解: 多线程Web服务器P132客户机IP:BP1客户机 IP: AP1P2P4服务器IP: CP5P6P3SP: 9157DP: 80S-IP: AD-IP:CSP: 9157DP: 80D-IP:CS-IP: BSP: 5775DP: 80D-IP:CS-IP: BP2线程进程 运输层19第3章 要点r3.1 运输层服务r3.2 复用与分解r3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控制的原则r3.7 TCP拥塞控制m机制mTC

11、P吞吐量mTCP公平性m时延模型 运输层203.3UDPr完成哪些工作？m多路复用/多路分解m轻量级的差错检测r工作过程？发送方-接收方m在UDP发送方和接收方之间无握手m每个UDP段的处理独立于其他段rDNS?P133r“没有不必要的,” “基本要素” 互联网传输协议r“尽力而为”服务，UDP段可能：m丢包m对应用程序交付失序 运输层213.3UDP: 用户数据报协议 RFC 768为何要有 UDP协议?r直接通过应用层控制要发送的数据和发送时间r无需创建连接(它将增加时延)r简单：在发送方、接收方无连接状态r段首部长度小r无拥塞控制: UDP能够尽可能快地传输r图3-6流行的应用层协议与运

12、输层协议 运输层223.3.1UDP报文段r常用于流式多媒体应用m丢包容忍m速率敏感r其他UDP应用mDNSmSNMPr经UDP的可靠传输 : 在应用层增加可靠性m应用程序使用特定的差错恢复！源端口#目的端口#32 bits应用数据(报文)UDP 段格式长度检查和UDP段的长度，包括首部，以字节计 运输层233.3.2UDP检验和发送方:r将段内容处理为16比特整数序列r检验和: 段内容的加法(反码和)r发送方将检验和放入UDP检验和字段接收方:r计算接收的段的检验和r核对计算的检验和是否等于检验和字段的值:mNO 检测到差错mYES 无差错检测到。虽然如此，还可能有差错吗？详情见后目的: 在

13、传输的段中检测“差错” (如比特翻转) 运输层24互联网检查和例子sumchecksumwraparoundreceiver1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 11 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1r注意m当数字作加法时，最高位进比特位的进位需要加到结果中r例子: 两个16-bi

14、t整数相加 运输层25第3章 要点r3.1 运输层服务r3.2 复用与分解r3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控制的原则r3.7 TCP拥塞控制m机制mTCP吞吐量mTCP公平性m时延模型 运输层26Principles of Reliable data transferr在应用层、运输层、数据链路层非常重要m是网络主题中的最重要的10个之一!r不可靠信道的特点决定了可靠数据传输 协议 (rdt) 的复杂性 运输层27Principles

15、 of Reliable data transferr在应用层、运输层、数据链路层非常重要m是网络主题中的最重要的10个之一!r不可靠信道的特点决定了可靠数据传输 协议 (rdt) 的复杂性 运输层28Principles of Reliable data transferr在应用层、运输层、数据链路层非常重要m是网络主题中的最重要的10个之一!r不可靠信道的特点决定了可靠数据传输 协议 (rdt) 的复杂性 运输层29可靠数据传输: 基本概念发送方接收方rdt_send(): called from above, (e.g., by app.). Passed data to deliver

16、 to receiver upper layerudt_send(): called by rdt,to transfer packet over unreliable channel to receiverrdt_rcv(): called when packet arrives on rcv-side of channeldeliver_data(): called by rdt to deliver data to upper 运输层30可靠数据传输: 基本概念我们将:r逐步加强发送方，接收方的可靠数据传输协议 (rdt) 侧m仅考虑单向数据传输m但控制信息是双流动的r使用有限状态机 (

17、FSM)来定义发送方和接收方状态1状态2引起状态变迁的事件状态变迁所采取的行动状态: 当位于这个“状态时”，下个状态惟一地由下个事件决定事件动作 运输层31第3章 要点r3.1 运输层服务r3.2 复用与分解r3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控制的原则r3.7 TCP拥塞控制m机制mTCP吞吐量mTCP公平性m时延模型3.4 可靠数据传输服务模型 运输层32可靠数据传输？无损坏、无丢失、有序P136 运输层333.4.1 Rdt1.0:

18、 经可靠信道的可靠传输r底层信道非常可靠m无比特差错m无分组丢失r单独的发送方、接收方的FSM(P138):m发送方将数据发向底层信道m接收方从底层信道读取数据Wait for call from abovepacket = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)Wait for call from belowrdt_rcv(packet)发送方接收方 运输层3 Rdt1.0: 经可靠信道的可靠传输r由于底层信道完全可靠，传输层中接收方不需要提供任何反

19、馈信息给发送方，因为不会发生任何差错！而且，在rdt1.0中，假定接收方接收数据的速率和发送方发送数据的速率一样快。因此，接收方没有必要请求发送方放慢发送速度。Wait for call from abovepacket = make_pkt(data)udt_send(packet)rdt_send(data)extract (packet,data)deliver_data(data)Wait for call from belowrdt_rcv(packet)发送方接收方 运输层3 Rdt2.0: 具有比特差错的信道r底层信道可能翻转分级中的某些位m校验和可以检测位错误r

20、the question: 如何从错误中恢复（语音通话）:m肯定确认acknowledgements (ACKs): receiver explicitly tells sender that pkt received OKm否定确认negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errorsmAQR自动重传请求协议：发送方在收到NAK时重传分组。r在 rdt2.0中新的机制中新的机制 (beyond rdt1.0):merror detection差错检测m接收方反馈: contr

21、ol msgs (ACK,NAK) 从接收方-发送方m重传 运输层3 rdt2.0: FSM规格参数 等待来自上面的调用sndpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_se

22、nd(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt) 等待ACK 或NAK 等待来自下面的调用发送方接收方rdt_send(data)L发送方发送一个分组，然后等待接收方响应停止等待 运输层37rdt2.0: 无差错时的操作 等待来自上面的调用sndpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) &

23、; isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt) 等待 ACK 或NAK 等待来自下面的调用rdt_send(data)L发送方发送一个分组，然后等待接收方响应停止等待 运输层38rdt2.0: 有差错时的情况 等待来自上面的调用sndpkt = make_pkt(data, checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_se

24、nd(ACK)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt)rdt_rcv(rcvpkt) & isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt) & isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt) & corrupt(rcvpkt)等待ACK 或NAK 等待来自下面的调用rdt_send(data)L发送方发送一个分组，然后等待接收方响应停止等待 运输层3 rdt2.0有重大的缺陷!如果ACK/NAK受损，将会出现何种情况？r发送方无法知道接收方

25、是否正确接收了上一次发送的分组数据！应该怎样纠正ACK或NAK分组中的差错？处理受损方法？处理受损方法？r口述消息的问话。接收方的ok，发送方不确定，问你说什么？然而你说什么产生差错，接收方无法判断下一步动作。r增加校验和比特。r重传当前数据分组。重传可能导致冗余，接收方不知道这次的分组是重传还是新数据，因为接收方不知道发送方有没有收到自己的ACK 运输层40 rdt2.0有重大的缺陷!如果ACK/NAK受损，将会出现何种情况？r发送方不知道在接收方发生 了什么情况！r不能只是重传：重传可能导致冗余处理冗余: r发送方对每个分组增加序列号r如果ACK/NAK受损，发送方重传当前的

26、分组r接收方丢弃(不再向上交付)冗余分组 运输层41rdt2.1: 发送方, 处理受损的ACK/NAK等待来自上层的调用0sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)等待 ACK 或 NAK 0udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt) &

27、 notcorrupt(rcvpkt) & isACK(rcvpkt) udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt) 等待来自上层的调用1等待 ACK 或NAK 1LL 运输层42rdt2.1: 接收方,处理受损的ACK/NAK等待来自下层的调用0sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)

28、& not corrupt(rcvpkt) & has_seq0(rcvpkt)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)等待来自下层的调用1rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq0(rcvpkt) extract(rcvpkt,data)deliver_da

29、ta(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq1(rcvpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)sndpkt = make_

30、pkt(NAK, chksum)udt_send(sndpkt) 运输层43rdt2.1: 讨论发送方:r序号seq # 加入分组中r两个序号seq. #s (0,1) 将够用r必须检查收到的ACK/NAK是否受损 r状态增加一倍m状态必须“记住”是否“当前的”分组具有0或1序号接收方:r必须检查接收到的分组是否是冗余的m状态指示0或1是否是所期待的分组序号seq #r注意: 接收方不能知道是否它的最后的ACK/NAK在发送方已经接收OK 运输层44如果接收方收到无序信号时发送NAK？习题6，P191 运输层45rdt2.2: 一种无NAK的协议r与rdt2.1一样的功能，仅使用ACKr代替N

31、AK,接收方对最后正确接收的分组发送ACKm接收方必须明确地指明被确认分组的序号r在发送方冗余的ACK导致如同NAK相同的动作：重传当前分组解决无序分组的问题，使用应答序号 运输层46rdt2.2: 发送方, 接收方片段等待来自上层的调用0sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) | isACK(rcvpkt,1) )rdt_rcv(rcvpkt) & notcorrupt(rcvpkt

32、) & isACK(rcvpkt,0) 等待ACK0发送方FSM片段等待来自下层的调用0rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) & (corrupt(rcvpkt) | has_seq1(rcvpkt)udt_send(sndpkt)接收方FSM片段Lrdt2.2 发送方 运输层47rdt2.

33、2 接收方 运输层48 运输层4 rdt3.0: 具有差错和丢包的信道新假设: 下面的信道也能丢失分组(数据或ACK)m检查和、序号、重传将是有帮助的，但不充分发送方发送数据后，数据丢失或者接收方对该分组的ACK发生了丢失，该怎么办？方法: 发送方等待ACK一段“合理的”时间r如在这段时间没有收到ACK则重传r如果分组(或ACK)只是延迟(没有丢失)：m重传将是冗余的，但序号的使用已经处理了该情况m接收方必须定义被确认的分组序号r需要倒计时定时器 运输层50rdt3.0发送方sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)

34、start_timerrdt_send(data)等待 ACK0rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,1) )等待来自上面的调用1sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0) rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,0) )rd

35、t_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,1) stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt) 等待来自上面的调用0等待 ACK1Lrdt_rcv(rcvpkt)LLL错误失序超时重发 运输层51rdt3.0 运行情况无丢包时的运行 分组丢失发送方发送方接收方接收方 运输层52rdt3.0运行情况ACK丢失 过早超时 发送方发送方接收方接收方 运输层53rdt3.

36、0的性能rrdt3.0能够工作，但性能不太好r例子: 假设东海岸与西海岸通信： 经1 Gbps链路, 15 ms端到端传播时延, 1KB分组:Ttransmit=8kb/pkt10*9 b/sec= 8 usmU sender: 利用率 发送方用于发送时间的比率m每30 msec 1KB 分组 - 经1 Gbps 链路有267kb/sec 吞吐量m网络协议限制了物理资源的使用! U sender = .008 30.008 = 0.00027 L / R RTT + L / R = L (packet length in bits)R (transmission rate, bps)= 运输层

37、54rdt3.0: 停等协议的运行传输分组的第一个比特, t = 0发送方接收方RTT 传输分组的最后一个比特, t = L / R分组第一个比特到达传输最后一个比特到达,发送ACKACK 到达，发送下一个分组, t = RTT + L / R U sender = .008 30.008 = 0.00027 L / R RTT + L / R = 运输层553.4.2 流水线协议: 增加利用率传输第一个分组比特传输第一个分组比特, t = 0发送者接收者RTT 传输最后一个比特传输最后一个比特, t = L / R第一个分组比特到达第一个分组比特到达分组最后一个比特到达分组最后一个比特到达,

38、发送发送 ACKACK 到达到达, 发送下一个分组发送下一个分组, t = RTT + L / R第二个分组最后比特到达第二个分组最后比特到达,发送发送ACK第三个分组最后比特到达第三个分组最后比特到达,发送发送ACK U sender = .024 30.008 = 0.0008 microseconds 3 * L / R RTT + L / R = 利用率增加利用率增加3倍倍! 运输层563.4.2 流水线协议流水线: 发送方允许发送多个、“传输中的”,还没有应答的报文段m序号的范围必须增加m发送方和/或接收方设有缓冲r流水线协议的两种形式: 回退回退N帧法（帧法（go-Back-N）,

39、 选择性重传（选择性重传（S-R）, 运输层573.4.3 Go-Back-N发送方发送方（基序号（基序号&下一个序号下一个序号P147）r在分组首部需要K比特序号，2k=Nr“窗口”最大为N, 允许N个连续的没有应答分组Base(基序号)：最早的未确认分组的序号Nextseqnum(下一个序号):下一个待发送分组的序号3.4.3 Go-Back-N发送方 运输层58r发送前，检查窗口是否已满。r累积确认ACK(n): 确认所有（包括序号n）的分组 - “累计ACK”r对每个传输中的分组的用同一个计时器，是最早的已发送但未被确认的分组所使用的定时器。ltimeout(n):若超时，重传

40、窗口中已发送但未被确认的分组 运输层59GBN: 发送方扩展的 FSM等待等待start_timerudt_send(sndpktbase)udt_send(sndpktbase+1)udt_send(sndpktnextseqnum-1)timeoutrdt_send(data) if (nextseqnum base+N) sndpktnextseqnum = make_pkt(nextseqnum,data,chksum) udt_send(sndpktnextseqnum) if (base = nextseqnum) start_timer nextseqnum+ else refu

41、se_data(data)base = getacknum(rcvpkt)+1If (base = nextseqnum) stop_timer else start_timerrdt_rcv(rcvpkt) & notcorrupt(rcvpkt) base=1nextseqnum=1rdt_rcv(rcvpkt) & corrupt(rcvpkt) L三个事件：1、上层的调用2、收到ACK3、超时事件GBN: 发送方扩展的 FSM 运输层60r发送条件：base+ nextseqnum 没有接收缓冲区!m重新确认具有按序的分组rdt_rcv(rcvpkt) & no

42、tcurrupt(rcvpkt) & hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum+udt_send(sndpkt)defaultexpectedseqnum=1Sndpkt=make_pkt(expectedseqnum ,ACK,chksum)L等等待待 运输层62GBN 操作发送方接收方 运输层633.4.4选择性重传（Selective

43、 Repeat）GBN改善了信道效率，但仍然有不必要重传问题由于单个分组差错可能引起GBN的大量重传-只重传丢失或错误的单个分组r接收方分别确认所有正确接收的报文段m需要缓存分组, 以便最后按序交付给上层r发送方只需要重传没有收到ACK的分组m发送方定时器对每个没有确认的分组计时r发送窗口mN个连续的序号m也需要限制已发送但尚未应答分组的序号 运输层643.4.4选择性重传上层传来数据上层传来数据 :r如果数据序号在发送窗口内，则打包发送，否则将数据缓存或返还给上层timeout(n):r每个分组拥有自己的定时器，重传分组k时， 重启其计时器ACK(n) ：在在sendbase,sendbas

44、e+N:r标记分组 n 已经收到r如果n 是最小未收到应答的分组，向前滑动窗口base指针到下一个未确认序号发送方分组分组n在在 rcvbase, rcvbase+N-1r发送 ACK(n)r失序: 缓存r按序: 交付 (也交付所有缓存的按序分组),向前滑动窗口到下一个未收到报文段的序号分组分组n在在rcvbase-N,rcvbase-1r即使已正确接收过该分组，但还是需要再次发送ACK(n)其他其他: r忽略 接收方 运输层65选择性重传: 发送方, 接收方窗口a. 发送方看到的序号b. 接收方看到的序号已经确认可用，还未发送发送，还未确认不可用可接受（窗口内） 失序(已缓存)但未被确认 可

45、接受（窗口内）期待，还未收到 不可用 窗口长度N窗口长度N 运输层66选择重传的操作 运输层67选择重传: 困难的问题例子:r序号: 0, 1, 2, 3r窗口长度 = 3r接收方：在(a)和(b)两种情况下接收方没有发现差别!r在 (a)中不正确地将冗余分组当作新分组，但在(b)中，对于接收方而言，收到分组和（a）中是不同的，是一个新的分组问题: 序号长度与窗口长度有什么关系?回答：窗口长度小于等于序号空间的一半 运输层68Window SizerIf the sequence number is m bits,r Go-back-NmSending window=2m-1r Selecti

46、ve repeatmReceiving window=Sending window=2m-1 运输层69可靠数据传输机制及用途总结机制用途和说明检验和用于检测在一个传输分组中的比特错误。定时器用于检测超时/重传一个分组，可能因为该分组（或其ACK）在信道中丢失了。由于当一个分组被时延但未丢失（过早超时），或当一个分组已被接收方收到但从接收方到发送方的ACK丢失时，可能产生超时事件，所以接收方可能会收到一个分组的多个冗余拷贝。序号用于为发送的数据分组进行按序编号。所接收分组的序号间的空隙可使接收方检测出丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余拷贝。确认接收方用于告诉发送方一个

47、分组或一组分组已被正确地接收到了。确认报文通常携带着被确认的分组或多个分组的序号。确认可以是逐个的或累积的，这取决于协议。否定确认接收方用于告诉发送方某个分组未被正确地接收。否定确认报文通常携带着未被正确接收的分组的序号。窗口、流水线发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但未被确认，发送方的利用率可在停等操作模式的基础上得到增加。我们很快将会看到，窗口长度可根据接收方接收和缓存报文的能力或网络中的拥塞程度，或两者情况来进行设置。 运输层70第3章 要点r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控制的原

48、则r3.7 TCP拥塞控制m机制mTCP吞吐量mTCP公平性m时延模型r3.1 运输层服务r3.2 复用与分解r3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议 运输层713.5 TCP概述 RFCs: 793, 1122, 1323, 2018, 2581r全双工数据全双工数据:m同一连接上的双向数据流mMSS: 最大报文段长度mMTU:最大传输单元r面向连接面向连接: m在进行数据交换前，初始化发送方与接收方状态，进行握手(交换控制信息),r点到点点到点:m一个发送方, 一个接收方m连接状态与端系统有关，不为路由器所知 r三次握手三次握手r

49、发送和接收缓存发送和接收缓存r最大传输单元：最大传输单元：MTUr最大报文段长：最大报文段长：MSS 运输层723.5 TCP概述 RFCs: 793, 1122, 1323, 2018, 2581r流量控制流量控制:m发送方不能淹没接收方r拥塞控制拥塞控制:m抑止发送方速率来防止过分占用网络资源r可靠、有序的字节流可靠、有序的字节流:m没有 “报文边界”r流水线流水线:mTCP拥塞和流量控制设置滑动窗口协议socketdoorTCPsend bufferTCPreceive buffersocketdoorsegmentapplicationwrites dataapplicationrea

50、ds data 运输层733.5.2TCP 报文段结构源端口 #目的端口 #32 bits应用层数据 (变长)序号确认号接收窗口紧急数据指针检查和FSRPAU首部长度未用选项 (变长)URG: 紧急数据 (一般不用)ACK: ACK 序号有效PSH: 立即提交数据(一般不用)RST, SYN, FIN:连接建立(建立和拆连)接收方允许的字节数对数据字节计数(并非对报文段计数!)因特网检查和(同 UDP一样) 运输层74TCP数据段头及说明数据开始可选项（0个或更多个32位字）紧急指针校验和窗口大小码位保留段头长度确认号序号目的端口源端口1 6 3 1840TCP头头 端口：每个端口对应一个应用

51、程序端口：每个端口对应一个应用程序 序号：发送的字节序号序号：发送的字节序号 确认号：接收到的字节序号确认号：接收到的字节序号 段头长度：段头中包含多少个段头长度：段头中包含多少个32位字位字 运输层75TCP数据段头及说明（续）r保留：以备扩展之用 r码位：URG： 紧急指针有效ACK： 确认号有效PSH：请求接收方，数据一到，立即送往应用程序RST：复位由于主机崩溃或其他原因而出现的错误的连接SYN： 用于建立连接FIN：用于断开连接r窗口：接收方窗口大小URGACKPSHRSTSYNFIN 运输层76TCP数据段头及说明（续）r校验和：包括报头、数据和伪段头r紧急指针：当前序号到紧急位置

52、的偏移量r选项字段：用于提供一种增加额外设置的方法，如连接建立时，双方说明最大的负载能力r数据：真正要传输的数据0481 6 3 1源IP地址目的IP地址00000000协议 = 6TCP数据段长度 包括在包括在TCP校验和中的伪头校验和中的伪头 运输层77常用的选项字段r最大数据段长度MSS目的站可接收的最大的数据段长度，这个值在0到65535之间，默认值是536字节r窗口扩大因子n（n 更大的安全余量r首先估算EstimatedRTT与SampleRTT之间差值有多大 : TimeoutInterval = EstimatedRTT + 4*DevRTTDevRTT = (1- )*Dev

53、RTT + *|SampleRTT-EstimatedRTT|(典型地, = 0.25) 然后估算超时值然后估算超时值P161: 运输层85第3章 要点r3.5 面向连接的传输: TCPm报文段结构m可靠数据传输m流量控制m连接管理r3.6 拥塞控制的原则r3.7 TCP拥塞控制m机制mTCP吞吐量mTCP公平性m时延模型r3.1 运输层服务r3.2 复用与分解r3.3 无连接传输: UDPr3.4 可靠数据传输的原则mrdt1mrdt2mrdt3m流水线协议 运输层863.5.4 TCP 可靠数据传输rTCP在IP不可靠服务的基础上创建可靠数据传输服务r流水线发送报文段r累计确认rTCP使用

54、单个重传计时器r重传被下列事件触发:m超时事件m重复ACKr先考虑简化的TCP发送方:m 忽略重复ACKm 忽略流量控制，拥塞控制 运输层87TCP 发送方事件1.从应用层接收数据:r根据序号创建报文段r序号是报文段中第一个数据字节的数据流编号r如果未启动，启动计时器 (考虑计时器用于最早的没有确认的报文段)r超时间隔: TimeOutInterval= EstimatedRTT + 4*DevRTT2.超时:r重传导致超时的报文段r重新启动计时器3.收到确认：r如果确认了先前未被确认的报文段 r更新被确认的报文段序号r如果还有未被确认的报文段，重新启动计时器 运输层88TCP 发送方(简化的

55、) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeou

56、t retransmit not-yet-acknowledged segment with smallest sequence number y start timer event: ACK received, with ACK field value of y if (y SendBase) /* 累计确认到Y */ SendBase = y if (there are currently not-yet-acknowledged segments) start timer /* end of loop forever */ 注释: SendBase-1: 上次累计的已确认字节 运输层89

57、TCP: 重传的情况主机 ASeq=100, 20 bytes dataACK=100时间过早超时的情况主机 BSeq=92, 8 bytes dataACK=120Seq=92, 8 bytes dataSeq=92 超时ACK=120主机 ASeq=92, 8 bytes dataACK=100loss超时丢失确认的情况主机 BXSeq=92, 8 bytes dataACK=100时间Seq=92 超时SendBase= 100SendBase= 120SendBase= 120Sendbase= 100 运输层90TCP 重传情况(续)主机 ASeq=92, 8 bytes dataA

58、CK=100丢包超时累计确认情况主机 BXSeq=100, 20 bytes dataACK=120时间SendBase= 120累积确认避免了第一个报文段的重传加倍超时间隔 运输层91r在收到应用层的数据传输请求和ack后，超时间隔为: TimeOutInterval= EstimatedRTT + 4*DevRTTr若是重传，重新启动计时器：TimeOutInterval=2* TimeOutIntervalm提供了拥塞控制P164快速重传 运输层92r由于重传成倍时间的递增，会增加端端时延，但发送方能在超时事件发生之前通过冗余ACK较好的检测丢包情况r冗余ACK：发送方已收到该ACK，即

59、重复收到对发送的某个报文的确认r接收方：什么情况下发送冗余ACK? 运输层93产生TCP ACK的建议 RFC 1122, RFC 2581接收方事件接收方事件所期望序号的报文段按序到达。所有在期望序号及以前的数据都已经被确认 有期望序号的报文段按序到达。另一个按序报文段等待发送ACK 比期望序号大的失序报文段到达，检测出数据流中的间隔。 部分或者完全填充已接收到数据间隔的报文段到达TCP 接收方行为接收方行为延迟的ACK。对另一个按序报文段的到达最多等待500 ms。如果下一个按序报文段在这个时间间隔内没有到达，则发送一个ACK 立即发送单个累积ACK，以确认两个按序报文段 立即发送冗余AC

60、K，指明下一个期待字节的序号（也就是间隔的低端字节序号） 倘若该报文段起始于间隔的低端，则立即发送ACK 运输层94快速重传r超时间隔常常相对较长:m重传丢失报文段以前有长时延r通过冗余ACK，检测丢失的报文段m发送方经常一个接一个的发送报文段m如果报文段丢失，将会收到很多重复ACKr如果对相同数据，发送方收到3个ACK, 假定被确认的报文段以后的报文段丢失了:m快速重传: 在定时器超时之前重传 运输层95Fast retransmit algorithm:a duplicate ACK for already ACKed segment event: ACK received, with ACK field value of y if (y SendBase) SendBase = y if (there are currently not-yet-acknowledged segments) start timer else /*a duplicate ACK for already ACKed segment*/