传输层协议要素

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

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

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

4、源进程向目的进程的传输地址发送消息，目的进程在自己的传输地址上接收消息。传输地址是传输层通信的端点，其一般性的术语称为传输服务访问点（transport service access point，TSAP）。第8页，共82页，2022年，5月20日，15点54分，星期一TSAP、NSAP和传输实体的关系每个TSAP上绑定一个应用进程，应用进程通过各自的TSAP调用传输层服务。传输实体通过本地的NSAP调用网络层服务，与远程的对等传输实体通信。第9页，共82页，2022年，5月20日，15点54分，星期一举例第10页，共82页，2022年，5月20日，15点54分，星期一源进程如何获知目的进程的

5、TSAP？在客户-服务器模式中，客户进程如何知道服务器进程的TSAP？常用的标准服务：使用众所周知的地址不常用的服务：使用进程服务员需要特殊硬件的服务：使用目录服务TSAP只是一种抽象，通常可由一个消息队列实现。第11页，共82页，2022年，5月20日，15点54分，星期一进程服务员的使用第12页，共82页，2022年，5月20日，15点54分，星期一2.2 建立传输连接当应用程序要求传输层保持消息发送顺序时，传输层必须提供面向连接的服务。所谓建立连接，就是在收发两端为通信过程分配好资源，并初始化相关的数据结构。在一个不可靠的网络中可靠地建立传输连接是一件困难的事情。第13页，共82页，20

6、22年，5月20日，15点54分，星期一问题之一：过时消息的干扰重复的连接请求及响应消息对正常的连接建立过程产生干扰。解决办法之一：给每个连接指定一个连接标识，每个主机记录已用过的连接标识。资源消耗大，不可靠。解决办法之二：限制每个数据包的寿命。第14页，共82页，2022年，5月20日，15点54分，星期一问题之二：起始序号的选取主机崩溃后可能丢失所有的状态信息，包括每个连接上要分配的下一个TPDU序号。主机恢复工作后，新连接上的TPDU序号可能和过时连接上的序号相同，产生混淆。解决办法之一：主机重启后至少等待时间T再建立连接，确保崩溃前的分组均已消失。解决办法之二：基于时钟的起始序号选取算

7、法每个主机使用一个时钟，以二进制计数器的形式工作，每隔T计数器加1。当一个连接建立时，以计数器当前值的最低k位（TPDU的序号长度）作为起始的TPDU序号。该方法确保连接的起始序号随时间单调增长。第15页，共82页，2022年，5月20日，15点54分，星期一问题之三：序号的增长速度主机发送速度过快或过慢，都会导致主机崩溃前后的序号空间发生重叠。解决办法：选取较小的T，确保发送序号的增长速度不会超过起始序号的增长速度。选择较长的TPDU序号，确保序号回绕的时间远大于T。第16页，共82页，2022年，5月20日，15点54分，星期一第17页，共82页，2022年，5月20日，15点54分，星期

8、一问题之四：如何可靠地传递起始序号？可靠建立传输连接的三次握手算法第18页，共82页，2022年，5月20日，15点54分，星期一2.3 释放传输连接不对称释放：任何一方释放连接，连接即被释放（即分配给连接的资源被回收）。第19页，共82页，2022年，5月20日，15点54分，星期一释放传输连接（续）对称释放：一条传输连接被看成是两个方向上的单工连接，一方释放连接只是表示它数据发完了，但它仍可以在另一个方向上接收数据。两个方向均释放连接，连接才能被释放。第20页，共82页，2022年，5月20日，15点54分，星期一两军问题第21页，共82页，2022年，5月20日，15点54分，星期一三次

9、握手法释放连接第22页，共82页，2022年，5月20日，15点54分，星期一三次握手法释放连接（续）第23页，共82页，2022年，5月20日，15点54分，星期一三次握手法释放连接（续）正常释放：主动方发出DR，响应方收到一次DR。异常：主动方发出DR，响应方从未收到DR，形成半开的连接。异常处理：引入不活动定时器，定时器超时（长时间未收到数据）后自动释放连接。引入哑TPDU，处理长时间没有数据发送的情形。第24页，共82页，2022年，5月20日，15点54分，星期一2.4 流量控制流量控制是一种由接收端控制发送速度的反馈机制，通常采用滑动窗口机制实现。 数据链路层和传输层上的滑动窗口机

10、制：数据链路层上的滑动窗口机制采用固定缓冲区分配策略（缓冲区大小及数量都固定），这在传输层上做不到。数据链路层上发送端和接收端都必须缓存，而在传输层上有多种缓存方案可供选择。第25页，共82页，2022年，5月20日，15点54分，星期一传输层上的缓存策略发送方缓存还是接收方缓存？若通信子网是不可靠的，发送方一般必须缓存，而接收方可以选择：缓存：长时间、大数据量的通信业务，如文件传输不缓存：低速且数据量较小的交互式会话应用若通信子网是可靠的，视接收方为连接预留的缓冲空间大小，发送方可以选择：缓存：若接收方没有预留足够的缓冲空间不缓存：若接收方预留了足够的缓冲空间第26页，共82页，2022年，

11、5月20日，15点54分，星期一缓冲区分配方案各种缓冲区分配方案：以TPDU为单位还是以连接为单位分配？缓冲区大小固定还是可变？缓冲区静态分配还是动态分配？动态缓冲区分配：发送端可以向接收端请求需要的缓冲区数量。接收端可以根据实际情况分配并动态调整预留的缓冲空间，并显式通知发送端。第27页，共82页，2022年，5月20日，15点54分，星期一动态缓冲区分配示例第28页，共82页，2022年，5月20日，15点54分，星期一3 用户数据报协议UDP第29页，共82页，2022年，5月20日，15点54分，星期一UDP的服务UDP的主要作用是向应用程序提供使用IP服务的接口，并利用端口号解复用多

12、个应用进程。UDP只提供检错功能，不负责出错重传和流量控制等功能。UDP提供的是一种不可靠、无连接的服务。UDP的优点：延迟小：不需要建立连接资源占用少：不需要维护状态通信开销小、包头开销小第30页，共82页，2022年，5月20日，15点54分，星期一UDP的应用之一：远程过程调用RPCRPC（remote procedure call）的基本思想允许调用远程计算机上的过程，并使这种调用看起来象本地调用一样，方便客户-服务器应用软件的编写。RPC的实现客户进程绑定到一个客户桩（client stub），服务器进程绑定到一个服务器桩（server stub）；客户进程调用客户桩，参数通过压栈的

13、方式传递；客户桩将参数封装成一个消息，执行一个系统调用发送消息；内核通过调用传输层服务将消息发送到服务器桩；服务器桩用传过来的参数调用服务器例程，将返回的结果封装到一个消息中，执行一个系统调用将消息发送给客户桩；客户桩将结果返回给客户进程。第31页，共82页，2022年，5月20日，15点54分，星期一RPC执行过程第32页，共82页，2022年，5月20日，15点54分，星期一UDP的应用之二：实时多媒体传输多媒体通信要求实时和按顺序交付数据，但能容忍少量数据丢失。从本质上说，TCP和UDP都不适合多媒体通信：TCP：可保证顺序，但实时性不好（差错控制，拥塞控制）。UDP：实时性好，但不保证

14、顺序。目前的解决方案是在UDP上面再运行一个RTP（Real Time Protocol），解决包序维持等问题。第33页，共82页，2022年，5月20日，15点54分，星期一RTP的位置第34页，共82页，2022年，5月20日，15点54分，星期一RTP头The RTP header.第35页，共82页，2022年，5月20日，15点54分，星期一4 传输控制协议TCPTCP提供的服务TCP协议TCP段结构TCP连接的建立和释放TCP 流量控制TCP拥塞控制无线TCP第36页，共82页，2022年，5月20日，15点54分，星期一4.1 TCP提供的服务TCP协议被设计为在不可靠的网络中提

15、供可靠的、有序的字节流服务。UDP提供的是数据报服务：应用程序的每一次输出被封装到一个UDP包中传输；每收到一个UDP包，接收端从包中取出数据交给应用程序。因此，UDP保留报文的边界。TCP提供的是字节流服务：应用程序的每一次输出被不加区分地放入发送缓冲区中，TCP实体将缓冲区中的数据划分成不超过64KB的段，每一段封装在一个IP包中传输。接收端从收到的TCP段中取出数据，按字节顺序不加区分地放入接收缓冲区中，在适当的时候交给应用程序。因此，TCP不保留报文的边界。第37页，共82页，2022年，5月20日，15点54分，星期一TCP不保留报文的边界(a) Four 512-byte segm

16、ents sent as separate IP datagrams.(b) The 2048 bytes of data delivered to the application in a single READ CALL.第38页，共82页，2022年，5月20日，15点54分，星期一TCP服务模型TCP使用连接进行通信。每条TCP连接有两个端点（称套接口，socket）：每个套接口使用一对整数来标识，其中host是主机的IP地址，port是该主机上TCP的端口号（TSAP）。如 和 唯一标识一条TCP连接。由于TCP使用两个端点来识别连接，因此一个套接口可以用于多个连接，如服务器进程可以

17、在一个套接口上同时为很多客户进程服务。TCP连接是全双工的，数据可以在两个方向上同时传输。TCP连接是点到点的，即每条连接只能有两个端点，所以TCP不支持多播或广播。第39页，共82页，2022年，5月20日，15点54分，星期一端口与服务小于1024的端口号称为众所周知的端口号，保留给标准服务使用。UNIX使用一个Internet守护进程inetd监听连接请求：系统启动时只有inetd在多个端口上监听连接请求。当对某个服务的连接请求到来时，inetd创建该服务的一个守护进程为客户服务。inetd从一个配置文件中获悉它要监听的端口号，因此管理员可以让系统在繁忙的端口（如80）上使用永久的守护进

18、程，而让inetd监听其余的端口。第40页，共82页，2022年，5月20日，15点54分，星期一4.2 TCP协议TCP的传输单元称为段（segment）。TCP段的组成：20字节的固定头（可能的）选项头零个或多个数据字节（每个字节都有一个32比特的序号）TCP使用滑动窗口协议传输数据。第41页，共82页，2022年，5月20日，15点54分，星期一（1）TCP段结构第42页，共82页，2022年，5月20日，15点54分，星期一TCP伪头结构第43页，共82页，2022年，5月20日，15点54分，星期一Maximum Segment Size（MSS）MSS指TCP段允许携带的最大载荷长

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

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

21、称释放法释放连接：H1发送FIN=1的TCP段；H2发送确认，一个方向的连接释放。H2发送FIN=1的TCP段；H1发送确认，另一个方向的连接释放。中间两个TCP段也可以合成一个。第47页，共82页，2022年，5月20日，15点54分，星期一SYN-Flood攻击TCP实现的问题： 服务器在收到SYN段后，发送SYN+ACK段；若未收到ACK段，服务器超时后重试；服务器等待一段时间（称SYN超时）后丢弃未完成的连接，SYN超时的典型值为30秒120秒。 SYN-Flood攻击：攻击者采用伪造的源IP地址，向服务器发送大量的SYN段，并且不会发出第三个ACK段。服务器为维护一个非常大的半连接表

22、而消耗很多的资源，并导致请求队列溢出，无法处理正常客户的连接请求。第48页，共82页，2022年，5月20日，15点54分，星期一端口扫描扫描程序利用与目标机器建立或释放TCP连接过程中获得的响应消息来收集信息。典型的TCP端口扫描过程如下：发送端向目标端口发送TCP连接请求（SYN=1）。若收到SYN=1、ACK=1的TCP段，表明该目标端口上有服务在监听，否则表明没有服务在运行。发送端向目标端口发送释放连接的请求（FIN=1）。 缺点：扫描行为被日志记录大多数防火墙会过滤由外部主动发起的TCP连接请求第49页，共82页，2022年，5月20日，15点54分，星期一TCP半程扫描TCP半程扫

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

24、。第51页，共82页，2022年，5月20日，15点54分，星期一（3）TCP的流量控制TCP使用滑动窗口协议进行数据传输：发送方每发送一个段后，启动一个定时器；接收方收到后返回一个包含确认序号的段，确认序号指出接收方准备接收的下一个字节序号；发送方定时器超时后重发这个段。TCP采用可变长度的滑动窗口进行流量控制：接收方在返回给发送方的段中报告接收窗口的大小（TCP头中的window size域），该字段表示发送方从确认序号开始可以发送的字节数。第52页，共82页，2022年，5月20日，15点54分，星期一可变长滑动窗口示例当窗口为0时一般必须停止发送，但以下两种情况例外：可以发送紧急数据，

25、例如终止在远端计算机上的运行进程。可以发送一个1字节的段，以触发一个包含接收窗口大小的响应。第53页，共82页，2022年，5月20日，15点54分，星期一零窗口通告和坚持定时器当发送端收到零窗口通告时，启动一个坚持定时器（persistence timer）。定时器超时后，发送端发送一个零窗口探测报文段（序号为上一个段中最后一个字节的序号）。接收端在响应的报文段中通告当前窗口大小。若发送端仍然收到零窗口通告，重新启动定时器。第54页，共82页，2022年，5月20日，15点54分，星期一传输效率的考虑发送端：TCP并不要求发送端在收到应用程序的数据后就立即发送。发送端可以将数据存放在发送缓冲

26、区中，等累积到一定数量之后再组成TCP段发送，以提高传输效率。接收端：TCP也不要求接收端在收到数据后立即发送确认。接收端可以推迟一小段时间，以便将确认捎带在一个返回的数据段中。第55页，共82页，2022年，5月20日，15点54分，星期一糊涂窗口综合症（silly window syndrome）接收方不断发送具有微小增量窗口的通告，引起发送方不断发送小数据分组，导致大量带宽浪费。当收发双方的处理速度严重失衡时会出现这种现象。第56页，共82页，2022年，5月20日，15点54分，星期一接收方启发式策略接收端避免糊涂窗口综合症的策略：通告零窗口之后，仅当窗口大小显著增加之后才发送更新的窗

27、口通告。显著增加：窗口大小达到缓冲区空间的一半或者一个MSS，取两者的最小值。实现该策略的两种手段：TCP对收到的报文段进行确认，但要等到窗口大小满足以上策略要求时再通告新的窗口大小。当窗口大小不满足以上策略时，推迟发送确认。（TCP标准推荐采用推迟确认）第57页，共82页，2022年，5月20日，15点54分，星期一推迟确认推迟确认的优点：能够降低通信量。推迟确认的缺点：当确认延迟太大时，会导致不必要的重传。TCP使用确认的到达时间来估计往返时间，推迟确认造成估计值的混乱。TCP标准规定：推迟确认的时间限度最多为500ms。接收方至少每隔一个报文段使用正常方式进行确认。第58页，共82页，2

28、022年，5月20日，15点54分，星期一发送方启发式策略发送方避免糊涂窗口综合症的策略：发送方应积聚足够多的数据，以防止发送太短的报文段。发送方TCP应该等待多长时间？如等待时间不够，报文段会太短。如等待时间过久，应用程序的时延会太长。更重要的是，TCP不知道应用程序会不会在最近的将来生成更多的数据。第59页，共82页，2022年，5月20日，15点54分，星期一Nagle算法Nagle算法：当应用数据到来时，组成一个TCP段发送（那怕只有一个字节）。在收到确认之前，后续到来的数据放到缓冲区中，等到数据足以填满一个最大长度的段，或上一次传输的确认到来（取两者的最小时间），用一个TCP段将缓存

29、的字节全部发走。Nagle算法的优点：适应不同的网络延时、不同的MSS以及不同应用程序速度的组合情况。常规情况下不会降低网络的吞吐量。第60页，共82页，2022年，5月20日，15点54分，星期一流量控制的总结接收端使用显式的窗口通告来通知可用的缓存空间大小。接收端在发送了零窗口通告后，仅当窗口大小显著增加后，才发送更新的窗口通告。发送端使用Nagle算法确定发送时机，并使用接收窗口来限制发送的数据量。第61页，共82页，2022年，5月20日，15点54分，星期一（4）TCP拥塞控制TCP拥塞控制的基本思想是让每一个发送方根据自己感知的网络拥塞程度来调整发送速度：如果发送方感觉到从它到目的

30、节点的路径上没什么拥塞，就增加发送速度；如果感觉到有拥塞，就降低发送速度。问题：发送方如何知道从它到目的节点的路径上发生了拥塞？当发送方检测到拥塞时，采用什么算法来调整发送速率？发送方如何限制发送速率？第62页，共82页，2022年，5月20日，15点54分，星期一如何检测拥塞？TCP利用段的超时事件来检测拥塞，即当发送端发送的某个段发生了超时，就认为网络中出现了拥塞。采用这种假设的原因是：对于端系统而言，拥塞表现为确认不能按时到达。对于固定（有线）网络而言，超时大多是由拥塞造成的。第63页，共82页，2022年，5月20日，15点54分，星期一如何限制发送速率？TCP使用拥塞窗口和发送窗口一

31、起限制发送速率：接收窗口反映接收端的缓冲能力拥塞窗口反映网络当前的处理能力发送窗口等于接收窗口和拥塞窗口的较小值第64页，共82页，2022年，5月20日，15点54分，星期一如何调整发送速率？TCP拥塞控制算法包括三个部分：加性增/乘性减原则慢启动算法快速重传和快速恢复机制第65页，共82页，2022年，5月20日，15点54分，星期一加性增/乘性减（AIMD）乘性减（multiplicative decrease）：每发生一次超时，就将当前拥塞窗口减半（最小不低于1个MSS）。因此，当发送端持续出现超时时，拥塞窗口按指数递减，以显著减少通信量。加性增（additive increase）：

32、当拥塞窗口内的段都在预定的时间内被确认（没有超时发生）时，拥塞窗口增大一个MSS。在实际操作时，每当收到一个确认，就在拥塞窗口上加一个增量。若拥塞窗口用CongWin表示，则每次收到一个确认后，拥塞窗口的增量按如下公式计算：= MSS （MSS/CongWin）。 第66页，共82页，2022年，5月20日，15点54分，星期一慢启动（slow start）在刚建立的TCP连接上，发送端以一个MSS作为拥塞窗口的初始值。每当收到一个确认，就将拥塞窗口增加1个MSS，直至发生超时。因此，初始阶段拥塞窗口是按指数增长的。第67页，共82页，2022年，5月20日，15点54分，星期一慢启动在两种情

33、况下使用连接刚建立的时候超时后重新启动数据传输的时候，因为这时通常有一个较大的接收窗口：当一个TCP段丢失后，接收端在某个时间点后不再发送确认（零窗口通告除外），也不再接收新的数据。发送端在发送完规定数量的数据段后停下来等待确认，至超时发生；这期间没有数据发送。在此期间，接收方应用程序可能取走大部分甚至全部的数据，并通告一个较大的接收窗口。第68页，共82页，2022年，5月20日，15点54分，星期一拥塞避免1）发生超时时，将当前拥塞窗口的一半作为拥塞阈值。2）将拥塞窗口初始化为1个MSS，使用慢启动发送。3）当拥塞窗口达到阈值时，按照加性增继续增加拥塞窗口（称拥塞避免） ，直至发生超时，回

34、到1）。4）若在拥塞窗口达到阈值前就发生了超时，回到1）。第69页，共82页，2022年，5月20日，15点54分，星期一快速重传试图区分是单纯的段丢失还是拥塞，并加快丢失段的重发：接收方对于每个到达的TCP段都要给予响应。对于未按正常顺序到达的段，接收并缓存，然后发送一个重复确认（将上一次发过的确认信息再发一次）。发送方在收到3个重复确认后开始重传丢失的段。接收方收到重传的数据段后，对已正确接收的数据发送累积确认。若发送方在收到3个重复确认前发生超时，按超时事件处理。第70页，共82页，2022年，5月20日，15点54分，星期一快速恢复发送端在收到3个重复确认后进入拥塞避免阶段（而不是慢启

35、动阶段）。具体来说，当发送端收到少于3个重复确认时，拥塞窗口和拥塞阈值均不变。当收到第3个重复确认时，将拥塞阈值设为拥塞窗口的一半，并令拥塞窗口等于拥塞阈值，此后拥塞窗口按线性增长。第71页，共82页，2022年，5月20日，15点54分，星期一TCP拥塞控制算法的仿真结果第72页，共82页，2022年，5月20日，15点54分，星期一（5）TCP重传定时器TCP主要使用超时来触发重传：TCP实体每发送一个TCP段，就启动一个重传定时器，定时器超时后重发该段。重传定时器的值对TCP的性能影响很大：该值设置太大，导致较长的端到端延迟。该值设置太小，导致许多不必要的重传；更为严重的是会启动拥塞控制

36、机制，导致发送速率急剧下降。问题：重传定时器的值（超时间隔）设为多长合适？第73页，共82页，2022年，5月20日，15点54分，星期一Round Trip Time（RTT）直观上考虑，超时间隔应与TCP段的平均来回时间及方差有关。来回时间的估算：TCP对每条连接维护一个变量RTT，这是对来回时间的估计值。在发送了一个段后启动重传定时器，若在超时前得到确认，终止定时器，计算出当前的来回时间M。根据以下公式修正RTT值，其中是比例因子： RTT = * RTT + (1-) * M 第74页，共82页，2022年，5月20日，15点54分，星期一RTT的平均偏差TCP实体维护另一个变量D，它是来回时间