传输层协议要素 PPT讲稿.ppt

《传输层协议要素 PPT讲稿.ppt》由会员分享，可在线阅读，更多相关《传输层协议要素 PPT讲稿.ppt（82页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、传输层协议要素 第1页，共82页，编辑于2022年，星期五本章主要内容z传输层的功能z传输层协议要素zInternet的传输层：y用户数据报协议（UDP）y传输控制协议（TCP）yBerkeley Sockets第2页，共82页，编辑于2022年，星期五1 传输层的功能z传输层提供进程进程的数据交付服务：y为运行在不同主机上的应用进程提供逻辑通信功能，使得从应用程序看来这些主机是直接相连的。z传输实体y传输层上实现传输服务的硬件或软件。y传输实体可能位于操作系统内核、单独的用户进程内、应用程序库中或网络接口卡上。第3页，共82页，编辑于2022年，星期五网络层、传输层和应用层的关系第4页，共8

2、2页，编辑于2022年，星期五设置传输层的两个目的z为端系统上运行的多个进程提供多路复用和解多路复用的功能：y多路复用（multiplex）：在源主机上，多个进程的数据被封装在不同的数据包中送入网络；y解多路复用（demultiplex）：在目的主机上，从数据包中取出的数据被交给相应的进程处理。z为应用进程提供所需的数据传输服务：y面向连接的服务y无连接服务第5页，共82页，编辑于2022年，星期五传输层服务接口z传输服务原语（transport service primitives）：y传输层向应用程序提供的一组操作，以方便应用程序调用传输层服务。y在TCP/IP协议栈中，传输层服务接口称为

3、套接字（socket），是目前网络应用编程接口的工业标准。第6页，共82页，编辑于2022年，星期五2 传输层协议要素z传输层协议要解决的主要问题：y编址：一个进程必须显式指出它要与之通信的另一个进程。y建立连接和释放连接：由于数据包在穿过通信子网时会丢失、重传、失序，这使得可靠地建立和释放传输连接非常困难。y流量控制和存储管理。第7页，共82页，编辑于2022年，星期五2.1 传输层编址z为指明将数据包交给哪个进程处理，每个进程需要一个标识。z在网络环境中标识进程的方法是为每个进程指定一个传输地址，源进程向目的进程的传输地址发送消息，目的进程在自己的传输地址上接收消息。z传输地址是传输层通信

4、的端点，其一般性的术语称为传输服务访问点（transport service access point，TSAP）。第8页，共82页，编辑于2022年，星期五TSAP、NSAP和传输实体的关系每个TSAP上绑定一个应用进程，应用进程通过各自的TSAP调用传输层服务。传输实体通过本地的NSAP调用网络层服务，与远程的对等传输实体通信。第9页，共82页，编辑于2022年，星期五举例第10页，共82页，编辑于2022年，星期五源进程如何获知目的进程的TSAP？z在客户-服务器模式中，客户进程如何知道服务器进程的TSAP？y常用的标准服务：使用众所周知的地址y不常用的服务：使用进程服务员y需要特殊硬件

5、的服务：使用目录服务zTSAP只是一种抽象，通常可由一个消息队列实现。第11页，共82页，编辑于2022年，星期五进程服务员的使用第12页，共82页，编辑于2022年，星期五2.2 建立传输连接z当应用程序要求传输层保持消息发送顺序时，传输层必须提供面向连接的服务。z所谓建立连接，就是在收发两端为通信过程分配好资源，并初始化相关的数据结构。z在一个不可靠的网络中可靠地建立传输连接是一件困难的事情。第13页，共82页，编辑于2022年，星期五问题之一：过时消息的干扰z重复的连接请求及响应消息对正常的连接建立过程产生干扰。z解决办法之一：y给每个连接指定一个连接标识，每个主机记录已用过的连接标识。

6、y资源消耗大，不可靠。z解决办法之二：y限制每个数据包的寿命。第14页，共82页，编辑于2022年，星期五问题之二：起始序号的选取z主机崩溃后可能丢失所有的状态信息，包括每个连接上要分配的下一个TPDU序号。主机恢复工作后，新连接上的TPDU序号可能和过时连接上的序号相同，产生混淆。z解决办法之一：y主机重启后至少等待时间T再建立连接，确保崩溃前的分组均已消失。z解决办法之二：基于时钟的起始序号选取算法y每个主机使用一个时钟，以二进制计数器的形式工作，每隔T计数器加1。当一个连接建立时，以计数器当前值的最低k位（TPDU的序号长度）作为起始的TPDU序号。y该方法确保连接的起始序号随时间单调增

7、长。第15页，共82页，编辑于2022年，星期五问题之三：序号的增长速度z主机发送速度过快或过慢，都会导致主机崩溃前后的序号空间发生重叠。z解决办法：y选取较小的T，确保发送序号的增长速度不会超过起始序号的增长速度。y选择较长的TPDU序号，确保序号回绕的时间远大于T。第16页，共82页，编辑于2022年，星期五第17页，共82页，编辑于2022年，星期五问题之四：如何可靠地传递起始序号？可靠建立传输连接的三次握手算法第18页，共82页，编辑于2022年，星期五2.3 释放传输连接z不对称释放：任何一方释放连接，连接即被释放（即分配给连接的资源被回收）。第19页，共82页，编辑于2022年，星

8、期五释放传输连接（续）z对称释放：y一条传输连接被看成是两个方向上的单工连接，一方释放连接只是表示它数据发完了，但它仍可以在另一个方向上接收数据。y两个方向均释放连接，连接才能被释放。第20页，共82页，编辑于2022年，星期五两军问题第21页，共82页，编辑于2022年，星期五三次握手法释放连接第22页，共82页，编辑于2022年，星期五三次握手法释放连接（续）第23页，共82页，编辑于2022年，星期五三次握手法释放连接（续）z正常释放：y主动方发出DR，响应方收到一次DR。z异常：y主动方发出DR，响应方从未收到DR，形成半开的连接。z异常处理：y引入不活动定时器，定时器超时（长时间未收

9、到数据）后自动释放连接。y引入哑TPDU，处理长时间没有数据发送的情形。第24页，共82页，编辑于2022年，星期五2.4 流量控制z流量控制是一种由接收端控制发送速度的反馈机制，通常采用滑动窗口机制实现。z数据链路层和传输层上的滑动窗口机制：y数据链路层上的滑动窗口机制采用固定缓冲区分配策略（缓冲区大小及数量都固定），这在传输层上做不到。y数据链路层上发送端和接收端都必须缓存，而在传输层上有多种缓存方案可供选择。第25页，共82页，编辑于2022年，星期五传输层上的缓存策略z发送方缓存还是接收方缓存？y若通信子网是不可靠的，发送方一般必须缓存，而接收方可以选择：x缓存：长时间、大数据量的通信

10、业务，如文件传输x不缓存：低速且数据量较小的交互式会话应用y若通信子网是可靠的，视接收方为连接预留的缓冲空间大小，发送方可以选择：x缓存：若接收方没有预留足够的缓冲空间x不缓存：若接收方预留了足够的缓冲空间第26页，共82页，编辑于2022年，星期五缓冲区分配方案z各种缓冲区分配方案：y以TPDU为单位还是以连接为单位分配？y缓冲区大小固定还是可变？y缓冲区静态分配还是动态分配？z动态缓冲区分配：y发送端可以向接收端请求需要的缓冲区数量。y接收端可以根据实际情况分配并动态调整预留的缓冲空间，并显式通知发送端。第27页，共82页，编辑于2022年，星期五动态缓冲区分配示例第28页，共82页，编辑

11、于2022年，星期五3 用户数据报协议UDP第29页，共82页，编辑于2022年，星期五UDP的服务zUDP的主要作用是向应用程序提供使用IP服务的接口，并利用端口号解复用多个应用进程。zUDP只提供检错功能，不负责出错重传和流量控制等功能。zUDP提供的是一种不可靠、无连接的服务。zUDP的优点：y延迟小：不需要建立连接y资源占用少：不需要维护状态y通信开销小、包头开销小第30页，共82页，编辑于2022年，星期五UDP的应用之一：远程过程调用RPCzRPC（remote procedure call）的基本思想y允许调用远程计算机上的过程，并使这种调用看起来象本地调用一样，方便客户-服务器

12、应用软件的编写。zRPC的实现y客户进程绑定到一个客户桩（client stub），服务器进程绑定到一个服务器桩（server stub）；y客户进程调用客户桩，参数通过压栈的方式传递；y客户桩将参数封装成一个消息，执行一个系统调用发送消息；y内核通过调用传输层服务将消息发送到服务器桩；y服务器桩用传过来的参数调用服务器例程，将返回的结果封装到一个消息中，执行一个系统调用将消息发送给客户桩；y客户桩将结果返回给客户进程。第31页，共82页，编辑于2022年，星期五RPC执行过程第32页，共82页，编辑于2022年，星期五UDP的应用之二：实时多媒体传输z多媒体通信要求实时和按顺序交付数据，但能

13、容忍少量数据丢失。z从本质上说，TCP和UDP都不适合多媒体通信：yTCP：可保证顺序，但实时性不好（差错控制，拥塞控制）。yUDP：实时性好，但不保证顺序。z目前的解决方案是在UDP上面再运行一个RTP（Real Time Protocol），解决包序维持等问题。第33页，共82页，编辑于2022年，星期五RTP的位置第34页，共82页，编辑于2022年，星期五RTP头The RTP header.第35页，共82页，编辑于2022年，星期五4 传输控制协议TCPzTCP提供的服务zTCP协议yTCP段结构yTCP连接的建立和释放yTCP 流量控制yTCP拥塞控制z无线TCP第36页，共82

14、页，编辑于2022年，星期五4.1 TCP提供的服务zTCP协议被设计为在不可靠的网络中提供可靠的、有序的字节流服务。zUDP提供的是数据报服务：y应用程序的每一次输出被封装到一个UDP包中传输；每收到一个UDP包，接收端从包中取出数据交给应用程序。因此，UDP保留报文的边界。zTCP提供的是字节流服务：y应用程序的每一次输出被不加区分地放入发送缓冲区中，TCP实体将缓冲区中的数据划分成不超过64KB的段，每一段封装在一个IP包中传输。y接收端从收到的TCP段中取出数据，按字节顺序不加区分地放入接收缓冲区中，在适当的时候交给应用程序。因此，TCP不保留报文的边界。第37页，共82页，编辑于20

15、22年，星期五TCP不保留报文的边界(a)Four 512-byte segments sent as separate IP datagrams.(b)The 2048 bytes of data delivered to the application in a single READ CALL.第38页，共82页，编辑于2022年，星期五TCP服务模型zTCP使用连接进行通信。z每条TCP连接有两个端点（称套接口，socket）：y每个套接口使用一对整数来标识，其中host是主机的IP地址，port是该主机上TCP的端口号（TSAP）。y如 和 唯一标识一条TCP连接。z由于TCP使用两

16、个端点来识别连接，因此一个套接口可以用于多个连接，如服务器进程可以在一个套接口上同时为很多客户进程服务。zTCP连接是全双工的，数据可以在两个方向上同时传输。zTCP连接是点到点的，即每条连接只能有两个端点，所以TCP不支持多播或广播。第39页，共82页，编辑于2022年，星期五端口与服务z小于1024的端口号称为众所周知的端口号，保留给标准服务使用。zUNIX使用一个Internet守护进程inetd监听连接请求：y系统启动时只有inetd在多个端口上监听连接请求。y当对某个服务的连接请求到来时，inetd创建该服务的一个守护进程为客户服务。yinetd从一个配置文件中获悉它要监听的端口号，

17、因此管理员可以让系统在繁忙的端口（如80）上使用永久的守护进程，而让inetd监听其余的端口。第40页，共82页，编辑于2022年，星期五4.2 TCP协议zTCP的传输单元称为段（segment）。zTCP段的组成：y20字节的固定头y（可能的）选项头y零个或多个数据字节（每个字节都有一个32比特的序号）zTCP使用滑动窗口协议传输数据。第41页，共82页，编辑于2022年，星期五（1）TCP段结构第42页，共82页，编辑于2022年，星期五TCP伪头结构第43页，共82页，编辑于2022年，星期五Maximum Segment Size（MSS）zMSS指TCP段允许携带的最大载荷长度，受

18、IP包数据域长度的限制：y若IP包的最大长度为L，则MSS=L20（IP固定头）20（TCP固定头）z为避免数据报分片和重组的开销，也有人提出基于路径MTU设置MSS：yMSS=MTU 40y以太网的MTU为1500，所以常见的MSS=1460字节第44页，共82页，编辑于2022年，星期五重要的TCP选项zMSS：y建立连接时，每个主机可以声明自己能够接受的MSS。y该选项缺省为536字节（所有路由器实现必须支持576字节的IP包）。z窗口比例因子（window scale）：y建立连接时，双方可以协商一个窗口比例因子。y实际接收窗口大小=window size*2window scale。

19、z选择重传：y最初的TCP实现采用go back n滑动窗口协议。y后来引入NAK，允许接收端在选项中指明要重发的段。第45页，共82页，编辑于2022年，星期五（2）建立和释放TCP连接zTCP使用三次握手建立连接：yH1发送SYN=1、ACK=0的TCP段，给出自己的起始连接序号x。yH2发送SYN=1、ACK=1的TCP段，给出自己的起始连接序号y，并对x进行确认。yH1发送SYN=0、ACK=1的TCP段，对y进行确认。z起始序号采用基于时钟的方法确定，T=4s。第46页，共82页，编辑于2022年，星期五释放TCP连接zTCP采用对称释放法释放连接：yH1发送FIN=1的TCP段；y

20、H2发送确认，一个方向的连接释放。yH2发送FIN=1的TCP段；yH1发送确认，另一个方向的连接释放。y中间两个TCP段也可以合成一个。第47页，共82页，编辑于2022年，星期五SYN-Flood攻击zTCP实现的问题：y服务器在收到SYN段后，发送SYN+ACK段；y若未收到ACK段，服务器超时后重试；y服务器等待一段时间（称SYN超时）后丢弃未完成的连接，SYN超时的典型值为30秒120秒。z SYN-Flood攻击：y攻击者采用伪造的源IP地址，向服务器发送大量的SYN段，并且不会发出第三个ACK段。y服务器为维护一个非常大的半连接表而消耗很多的资源，并导致请求队列溢出，无法处理正常

21、客户的连接请求。第48页，共82页，编辑于2022年，星期五端口扫描z扫描程序利用与目标机器建立或释放TCP连接过程中获得的响应消息来收集信息。z典型的TCP端口扫描过程如下：y发送端向目标端口发送TCP连接请求（SYN=1）。y若收到SYN=1、ACK=1的TCP段，表明该目标端口上有服务在监听，否则表明没有服务在运行。y发送端向目标端口发送释放连接的请求（FIN=1）。z缺点：y扫描行为被日志记录y大多数防火墙会过滤由外部主动发起的TCP连接请求第49页，共82页，编辑于2022年，星期五TCP半程扫描zTCP半程扫描过程如下：y向目标端口发送SYN段y若收到SYN+ACK段，表明有服务在

22、监听y发送RST=1的TCP段（复位连接）z优点：y不会被日志记录（不是一个完整的TCP连接过程）z缺点：y仍然可能被防火墙过滤第50页，共82页，编辑于2022年，星期五FIN扫描zFIN扫描过程如下：y发送端向目标端口发送释放连接的请求（FIN=1）。y若收到ACK=1、RST=1的TCP段，表明目标端口上没有服务在监听；若没有响应表明有服务在监听。（RFC 973的规定）z优点：y防火墙不会过滤z缺点：y有些系统的实现不符合RFC 973规定，如在Microsoft的TCP实现中，总是返回ACK=1、RST=1的TCP段。第51页，共82页，编辑于2022年，星期五（3）TCP的流量控制

23、zTCP使用滑动窗口协议进行数据传输：y发送方每发送一个段后，启动一个定时器；y接收方收到后返回一个包含确认序号的段，确认序号指出接收方准备接收的下一个字节序号；y发送方定时器超时后重发这个段。zTCP采用可变长度的滑动窗口进行流量控制：y接收方在返回给发送方的段中报告接收窗口的大小（TCP头中的window size域），该字段表示发送方从确认序号开始可以发送的字节数。第52页，共82页，编辑于2022年，星期五可变长滑动窗口示例z当窗口为0时一般必须停止发送，但以下两种情况例外：y可以发送紧急数据，例如终止在远端计算机上的运行进程。y可以发送一个1字节的段，以触发一个包含接收窗口大小的响应

24、。第53页，共82页，编辑于2022年，星期五零窗口通告和坚持定时器z当发送端收到零窗口通告时，启动一个坚持定时器（persistence timer）。z定时器超时后，发送端发送一个零窗口探测报文段（序号为上一个段中最后一个字节的序号）。z接收端在响应的报文段中通告当前窗口大小。z若发送端仍然收到零窗口通告，重新启动定时器。第54页，共82页，编辑于2022年，星期五传输效率的考虑z发送端：yTCP并不要求发送端在收到应用程序的数据后就立即发送。y发送端可以将数据存放在发送缓冲区中，等累积到一定数量之后再组成TCP段发送，以提高传输效率。z接收端：yTCP也不要求接收端在收到数据后立即发送确

25、认。y接收端可以推迟一小段时间，以便将确认捎带在一个返回的数据段中。第55页，共82页，编辑于2022年，星期五糊涂窗口综合症（silly window syndrome）z接收方不断发送具有微小增量窗口的通告，引起发送方不断发送小数据分组，导致大量带宽浪费。z当收发双方的处理速度严重失衡时会出现这种现象。第56页，共82页，编辑于2022年，星期五接收方启发式策略z接收端避免糊涂窗口综合症的策略：y通告零窗口之后，仅当窗口大小显著增加之后才发送更新的窗口通告。y显著增加：窗口大小达到缓冲区空间的一半或者一个MSS，取两者的最小值。z实现该策略的两种手段：yTCP对收到的报文段进行确认，但要等

26、到窗口大小满足以上策略要求时再通告新的窗口大小。y当窗口大小不满足以上策略时，推迟发送确认。（TCP标准推荐采用推迟确认）第57页，共82页，编辑于2022年，星期五推迟确认z推迟确认的优点：y能够降低通信量。z推迟确认的缺点：y当确认延迟太大时，会导致不必要的重传。yTCP使用确认的到达时间来估计往返时间，推迟确认造成估计值的混乱。zTCP标准规定：y推迟确认的时间限度最多为500ms。y接收方至少每隔一个报文段使用正常方式进行确认。第58页，共82页，编辑于2022年，星期五发送方启发式策略z发送方避免糊涂窗口综合症的策略：y发送方应积聚足够多的数据，以防止发送太短的报文段。z发送方TCP

27、应该等待多长时间？y如等待时间不够，报文段会太短。y如等待时间过久，应用程序的时延会太长。更重要的是，TCP不知道应用程序会不会在最近的将来生成更多的数据。第59页，共82页，编辑于2022年，星期五Nagle算法zNagle算法：y当应用数据到来时，组成一个TCP段发送（那怕只有一个字节）。y在收到确认之前，后续到来的数据放到缓冲区中，等到数据足以填满一个最大长度的段，或上一次传输的确认到来（取两者的最小时间），用一个TCP段将缓存的字节全部发走。zNagle算法的优点：y适应不同的网络延时、不同的MSS以及不同应用程序速度的组合情况。y常规情况下不会降低网络的吞吐量。第60页，共82页，编

28、辑于2022年，星期五流量控制的总结z接收端使用显式的窗口通告来通知可用的缓存空间大小。z接收端在发送了零窗口通告后，仅当窗口大小显著增加后，才发送更新的窗口通告。z发送端使用Nagle算法确定发送时机，并使用接收窗口来限制发送的数据量。第61页，共82页，编辑于2022年，星期五（4）TCP拥塞控制zTCP拥塞控制的基本思想是让每一个发送方根据自己感知的网络拥塞程度来调整发送速度：y如果发送方感觉到从它到目的节点的路径上没什么拥塞，就增加发送速度；y如果感觉到有拥塞，就降低发送速度。z问题：y发送方如何知道从它到目的节点的路径上发生了拥塞？y当发送方检测到拥塞时，采用什么算法来调整发送速率？

29、y发送方如何限制发送速率？第62页，共82页，编辑于2022年，星期五如何检测拥塞？zTCP利用段的超时事件来检测拥塞，即当发送端发送的某个段发生了超时，就认为网络中出现了拥塞。z采用这种假设的原因是：y对于端系统而言，拥塞表现为确认不能按时到达。y对于固定（有线）网络而言，超时大多是由拥塞造成的。第63页，共82页，编辑于2022年，星期五如何限制发送速率？zTCP使用拥塞窗口和发送窗口一起限制发送速率：y接收窗口反映接收端的缓冲能力y拥塞窗口反映网络当前的处理能力y发送窗口等于接收窗口和拥塞窗口的较小值第64页，共82页，编辑于2022年，星期五如何调整发送速率？zTCP拥塞控制算法包括三

30、个部分：y加性增/乘性减原则y慢启动算法y快速重传和快速恢复机制第65页，共82页，编辑于2022年，星期五加性增/乘性减（AIMD）z乘性减（multiplicative decrease）：y每发生一次超时，就将当前拥塞窗口减半（最小不低于1个MSS）。y因此，当发送端持续出现超时时，拥塞窗口按指数递减，以显著减少通信量。z加性增（additive increase）：y当拥塞窗口内的段都在预定的时间内被确认（没有超时发生）时，拥塞窗口增大一个MSS。y在实际操作时，每当收到一个确认，就在拥塞窗口上加一个增量。y若拥塞窗口用CongWin表示，则每次收到一个确认后，拥塞窗口的增量按如下公式

31、计算：=MSS（MSS/CongWin）。第66页，共82页，编辑于2022年，星期五慢启动（slow start）z在刚建立的TCP连接上，发送端以一个MSS作为拥塞窗口的初始值。z每当收到一个确认，就将拥塞窗口增加1个MSS，直至发生超时。z因此，初始阶段拥塞窗口是按指数增长的。第67页，共82页，编辑于2022年，星期五慢启动在两种情况下使用z连接刚建立的时候z超时后重新启动数据传输的时候，因为这时通常有一个较大的接收窗口：y当一个TCP段丢失后，接收端在某个时间点后不再发送确认（零窗口通告除外），也不再接收新的数据。y发送端在发送完规定数量的数据段后停下来等待确认，至超时发生；这期间没

32、有数据发送。y在此期间，接收方应用程序可能取走大部分甚至全部的数据，并通告一个较大的接收窗口。第68页，共82页，编辑于2022年，星期五拥塞避免1）发生超时时，将当前拥塞窗口的一半作为拥塞阈值。2）将拥塞窗口初始化为1个MSS，使用慢启动发送。3）当拥塞窗口达到阈值时，按照加性增继续增加拥塞窗口（称拥塞避免），直至发生超时，回到1）。4）若在拥塞窗口达到阈值前就发生了超时，回到1）。第69页，共82页，编辑于2022年，星期五快速重传z试图区分是单纯的段丢失还是拥塞，并加快丢失段的重发：y接收方对于每个到达的TCP段都要给予响应。y对于未按正常顺序到达的段，接收并缓存，然后发送一个重复确认（

33、将上一次发过的确认信息再发一次）。y发送方在收到3个重复确认后开始重传丢失的段。y接收方收到重传的数据段后，对已正确接收的数据发送累积确认。y若发送方在收到3个重复确认前发生超时，按超时事件处理。第70页，共82页，编辑于2022年，星期五快速恢复z发送端在收到3个重复确认后进入拥塞避免阶段（而不是慢启动阶段）。z具体来说，y当发送端收到少于3个重复确认时，拥塞窗口和拥塞阈值均不变。y当收到第3个重复确认时，将拥塞阈值设为拥塞窗口的一半，并令拥塞窗口等于拥塞阈值，此后拥塞窗口按线性增长。第71页，共82页，编辑于2022年，星期五TCP拥塞控制算法的仿真结果第72页，共82页，编辑于2022年

34、，星期五（5）TCP重传定时器zTCP主要使用超时来触发重传：yTCP实体每发送一个TCP段，就启动一个重传定时器，定时器超时后重发该段。z重传定时器的值对TCP的性能影响很大：y该值设置太大，导致较长的端到端延迟。y该值设置太小，导致许多不必要的重传；更为严重的是会启动拥塞控制机制，导致发送速率急剧下降。z问题：y重传定时器的值（超时间隔）设为多长合适？第73页，共82页，编辑于2022年，星期五Round Trip Time（RTT）z直观上考虑，超时间隔应与TCP段的平均来回时间及方差有关。z来回时间的估算：yTCP对每条连接维护一个变量RTT，这是对来回时间的估计值。y在发送了一个段后

35、启动重传定时器，若在超时前得到确认，终止定时器，计算出当前的来回时间M。y根据以下公式修正RTT值，其中是比例因子：RTT=*RTT+(1-)*M 第74页，共82页，编辑于2022年，星期五RTT的平均偏差zTCP实体维护另一个变量D，它是来回时间的测量值与估计值之间的偏差。z当得到RTT的最新估计值M之后，用以下公式修正D：D=*D+(1-)*|RTT-M|z设置新的超时间隔：timeout=RTT+4*D。第75页，共82页，编辑于2022年，星期五TCP确认的二义性z估计RTT的问题：yTCP是对接收到的数据而不是对携带数据的报文段进行确认，因此TCP的确认是有二义性的。z解决方法：y

36、忽略有二义性的确认，只对一次发送成功的报文段测量来回时间，并据此更新RTT估计值；当TCP重传一个段时，停止测量来回时间。第76页，共82页，编辑于2022年，星期五定时器补偿z简单忽略重传报文段的问题：y重传意味着实际的RTT增大，从而超时间隔偏 小了。y若不更新RTT，也不会更新超时间隔，就会形成反复重传的局面。z解决方法：y采用定时器补偿策略，发送方每重传一个报文段，就增加超时间隔倍，的典型值为2。y若连续发生超时事件，超时间隔呈指数增长（至一个规定的上限值）。第77页，共82页，编辑于2022年，星期五Karn算法zKarn算法结合使用RTT估计值和定时器补偿策略确定超时间隔：y使用R

37、TT估计值计算初始的超时间隔。y若发生超时，每次重传时对定时器进行补偿，直到成功传输一个报文段为止。y若某个报文段没有重传就被确认，重新计算RTT估计值，并设定相应的超时间隔。第78页，共82页，编辑于2022年，星期五4.3 无线网络中的TCPzTCP使用超时作为拥塞出现的标志是否合理？y在有线网络中，丢包大部分由拥塞引起。y在无线网络中，丢包大部分由传输出错引起。z发送端在超时后减小发送速度是否合理？y在有线网络中，超时主要由拥塞引起，应立即减小发送速度。y在无线网络中，超时主要由传输出错引起，应尽快重发出错的数据。第79页，共82页，编辑于2022年，星期五TCP穿越有线和无线网络z间接

38、TCP：y将一条TCP连接分为两条独立的连接，中继站在两条连接间双向复制分组。y优点：可以在不同的连接上采用不同的拥塞控制算法。y缺点：破坏了TCP的端到端语义。第80页，共82页，编辑于2022年，星期五5 套接字（Socket）z套接字最初作为UNIX操作系统的一部分被开发，定义了应用程序调用传输层服务的API。z套接字应用了UNIX操作系统的“打开-读-写-关闭”的I/O操作模式：y应用请求操作系统创建一个用于通信的套接字，系统返回一个整数描述字标识这个套接字。y应用调用底层过程在网络上收发数据时，必须将该描述字作为一个参数。y通信结束时，应用请求操作系统关闭套接字。第81页，共82页，编辑于2022年，星期五课外练习z作业y16，17，28，30，31，32第82页，共82页，编辑于2022年，星期五