计算机网络传输层

传输层1主要内容24.1传输层的基本概念传输层的作用传输层与应用层、网络层之间的关系网络环境中应用进程标识、端口、套接字多路复用与多路分解4.2传输层协议的特点与比较4.3UDP协议UDP协议的主要特点UDP报文格式UDP校验和的基本概念与计算示例UDP协议适用的范围4.4TCP协议TCP协议的主要特点TCP报文格式可靠传输的工作原理停等式(stop-and-wait）ARQ，回退N帧（go-back-n）ARQ，选择性重传（selectiverepeat）ARQTCP可靠通信的具体实现TCP序号和确认号以字节为单位的滑动窗口超时重传时间的选择选择确认SACKTCP的流量控制TCP的拥塞控制TCP的运输连接管理4.1传输层的基本概念4面向信息处理应用层运输层网络层应用层数据链路层物理层面向通信用户功能网络功能是整个网络体系结构中关键的一层。只有主机的协议栈才有运输层。传输层的基本功能计算机网络本质的活动是实现分布在不同地理位置的联网主机之间的进程通信，以实现各种网络服务功能；传输层的主要作用就是要实现分布式进程通信。传输层的作用主机A主机B路由器1路由器2AP1LAN2WANAP2AP3AP4LAN1IP协议的作用范围运输层协议TCP和UDP的作用范围IP协议能够把源主机发送出的分组按照首部中的目的地址送交到目的主机，那么为什么还需要再设置一个运输层呢？对IP层来说，通信的两端是两个主机，是“两个主机之间的通信”；计算机网络的本质是什么？主机间的进程通信实现应用层的各种网络服务功能运输层的作用6如何理解端到端的通信？运输协议运行在端系统中发送方：将应用报文划分为段，传向网络层接收方：将段重新装配为报文，传向应用层“端-端”进程通信服务的基本概念7运输层提供应用进程间的逻辑通信；真正进行通信的实体是在主机中的进程；通信的真正端点并不是主机而是主机中的进程；；什么是端到端/endtoend（或进程到进程/processtoprocess）通信？什么是点到点通信？TCP就是用来建立这种端到端连接的一个具体协议。端到端是传输层的比如你要将数据从A传送到E，中间可能经过A->B->C->D->E,对于传输层来说他并不知道b,c,d的存在，他只认为我的报文数据是从a直接到e的，这就叫做端到端。总之，一句话概括就是端到端是由无数的点到点实现和组成的。好像是沿水平方向传送数据，但之间并没有物理连接，是沿虚线方向经过多个层次传送的。传输层与应用层、网络层之间的关系传输层之间传输的报文称为传输协议数据单元（TPDU）；TPDU有效载荷是应用层的数据；传输层在有效载荷TPDU之前加上TPDU头，就形成了TPDU传输协议数据单元。9运输层vs.网络层网络层:

主机间的逻辑通信运输层:

进程间的逻辑通信依赖、强化网络层服务家庭类比:12个孩子向12个孩子发信进程=孩子应用报文=信封中的信主机=家庭运输协议=Ann和Bill网络层协议=邮政服务在Internet上，各个数据包根据其目的主机的ip地址来进行互联网络中的路由选择。可见，把数据包顺利的传送到目的主机是没有问题的。问题出在哪里呢?我们知道大多数操作系统都支持多程序（进程）同时运行，那么目的主机应该把接收到的数据包传送给众多同时运行的进程中的哪一个呢？显然这个问题有待解决，端口机制便由此被引入进来。端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。网络环境中应用进程标识11网络上的计算机中运行的任何网络应用程序都有一个或多个端口号与之对应。传输层寻址是通过端口实现的端口号：每个应用层实体通过自己特定的端口和运输层实体进行数据交换（即对运输层实体的复用/分用）。为了区分不同应用层实体的端口，给每个应用层实体的端口赋予了一个唯一的标号，即端口号。端口号是一个16位的地址，取0~65535之间的整数端口号分为两类：熟知端口：被限制使用专门分配给一些最常用的服务器进程:如HTTP、FTP、SMTP等。注册端口号：用户根据需要可以在IANA注册。（IANA(TheInternetAssignedNumbersAuthority，互联网数字分配机构)是负责协调一些使Internet正常运作的机构。）临时端口：随时分配给请求通信的客户进程。端口号只具有本地意义，不同计算机中，相同的端口号是没有关联的。熟知端口号的分配方法UDP的熟知端口号的分配13端口号服务进程说明53domain域名服务67/68DHCP动态主机配置协议69TFTP简单文件传送协议111RPC远程过程调用123NTP网络时间协议161/162SNMP简单网络管理协议520RIP路由信息协议TCP的熟知端口号的分配14端口号服务进程说明20FTP文件传输协议（数据连接）21FTP文件传输协议（控制连接）23TELNET网络虚拟终端协议25SMTP简单邮件传输协议80HTTP超文本传输协议119NNTP网络新闻传输协议179BGP边界路由协议端口的使用本地操作系统会给那些有需求的进程分配协议端口（protocolport，即我们常说的端口），每个协议端口由一个正整数标识，如：80，139，445，等等。当目的主机接收到数据包后，将根据报文首部的目的端口号，把数据发送到相应端口，而与此端口相对应的那个进程将会领取数据并等待下一组数据的到来。不光接受数据包的进程需要开启它自己的端口，发送数据包的进程也需要开启端口，这样，数据包中将会标识有源端口，以便接受方能顺利的回传数据包到这个端口。端口使用举例主机A服务器Bsourceport:xdest.port:23sourceport:23dest.port:x端口的使用:简单的telnet应用Web客户端主机AWeb服务器BWeb客户端主机CSourceIP:CDest.IP:Bsourceport:ydest.port:80SourceIP:CDest.IP:Bsourceport:xdest.port:80端口的使用:Web服务器SourceIP:ADestIP:Bsourceport:xdest.port:80….….….….主页1主页2Web服务器BWeb客户端主机ASourceIP:CDest.IP:Bsourceport:ydest.port:80SourceIP:CDest.IP:Bsourceport:xdest.port:80端口的使用:Web服务器….….….….考虑：1.同一主机多个应用进程，发往同一个目的端口？？？2.不同的主机随即源端口相同，发往同一目的端口？？？Web客户端主机ASourceIP:ADestIP:Bsourceport:xdest.port:80TCP使用“连接”（而不仅仅是“端口”）作为最基本的标识。一个TCP连接由它的两个端点来标识。这样的端点就叫做“插口”，或“套接字”。插口/套接字/Socket每个主机（可用IP地址唯一标识）都可以独立分配自己的端口号，因此为了在通信时不至于发生混乱，就必须把端口号和IP地址结合在一起使用，用于区别同时通信的多个主机中的多个进程。插口/Socket，是因特网中某一个通信端点的标识，它由IP地址（32位）和端口号（16位）构成。服务器套接字地址唯一地定义服务器应用程序；客户机套接字地址唯一地定义客户机应用程序；由于套接字是建立网络应用程序的可编程接口，因此套接字又称为应用程序编程接口（API）。运输层实际上并没有直接将数据交付给进程，而是通过一个中间的套接字来传递不同的网络系统，不同的传输层协议；不同的传输层协议之间不能通信；网络中一个进程的全网唯一的标识需要用一个三元组表示协议、本地地址、本地端口号一个完整的进程通信标识需要用一个五元组表示协议、本地地址、本地端口号、远程地址、远程端口号连接一的客户端套接字是3:500服务器端的套接字是5:25图中标识连接1的五元组是（TCP,3:500,5:25）传输层的多路复用与多路分解22复用/分解应用层运输层网络层链路层物理层P1应用层运输层网络层链路层物理层应用层运输层network链路层物理层P2P3P4P1主机1主机2主机3=进程=套接字从多个套接字收集数据，用首部封装数据(以后用于分解)在发送主机复用:将接收到的段交付给正确的套接字在接收主机分解：多路复用/分解——运输层支持一台主机上多个进程通过一个单一的网络接口实现数据发送/接收操作发送端AP1AP2AP3AP4AP5AP6接收端传输信道传输信道多路复用/多路分解的实现要保证复用/分用的进程都有唯一的标识（套接字标识符）每个报文段要有特定的字段指示所要交付的套接字分解工作过程1.无连接分解生成具有端口号的套接字:DatagramSocketmySocket1=newDatagramSocket(99111);DatagramSocketmySocket2=newDatagramSocket(99222);UDP套接字由二元组标识:(目的地IP地址,目的地端口号)当主机接收UDP段时:在段中检查目的地端口号将UDP段定向到具有该端口号的套接字具有不同源IP地址和/或源端口号的IP数据报定向到相同的套接字无连接分解DatagramSocket

serverSocket=newDatagramSocket(6428);客户机IP:BP2客户机IP:AP1P1P3服务器IP:CSP:6428DP:9157SP:9157DP:6428SP:6428DP:5775SP:5775DP:6428SP提供了“返回地址”2.面向连接分解TCP套接字由四元组标识:源IP地址源端口号目的IP地址目的端口号接收主机使用这四个值来将段定向到适当的套接字服务器主机可能支持许多并行的TCP套接字：每个套接字由其自己的四元组标识Web服务器对每个连接的客户机具有不同的套接字非持久HTTP将为每个请求具有不同的套接字P1客户机IP:AP1P2P4服务器IP:CSP:9157DP:80SP:9157DP:80P5P6P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B客户机IP:BP1客户机IP:AP1P2服务器IP:CSP:9157DP:80SP:9157DP:80P4P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B高性能web服务器：同一端口建立多个连接，每个连接创建一个新的线程同一端口建立多个连接，每个连接产生一个新的进程。连接套接字与进程间并非总是一一对应4.2传输层协议的特点与比较TCP/IP的运输层有两个不同的协议：(1)用户数据报协议UDP (UserDatagramProtocol)(2)传输控制协议TCP (TransmissionControlProtocol)1.TCP与UDP协议的比较特征/描述TCPUDP一般描述允许应用程序可靠地发送数据，功能齐全简单、高速，只负责将应用层与网络层衔接起来面向连接或无连接面向连接，在TPDU传输之前需要建立TCP连接无连接，在TPDU传输之前不需要建立UDP连接与应用层的数据接口基于字节流，应用层不需要规定特定的数据格式基于报文，应用层需要将数据分成包来传送可靠性与确认可靠报文传输，对所有的数据均要确认不可靠，不需要对传输的数据确认，尽力而为地交付重传自动重传丢失的数据不负责检查是否丢失数据和重传开销高于UDP很低传输速率低于UDP很高适用的数据量从少量到几个GB的数据从少量到几百个字节的数据适用的应用类型对数据传输可靠性要求较高的应用，例如文件与报文传输发送数量比较少、对数据传输可靠性要求较低的应用，例如IP电话、视频会议、多播与广播302.TCP、UDP协议与应用层协议的关系应用数据丢失带宽时间敏感文件传输不能丢失弹性不电子邮件不能丢失弹性不Web文档不能丢失弹性不即时讯息不能丢失弹性是和不是实时音频视频容忍丢失音频（几kb/s-1Mb/s）是，100ms视频（10kb/s-5Mb/s）交互式游戏容忍丢失几kb/s-1Mb/s是，100ms一些因特网应用在可靠性、带宽及时间方面的要求32SMTPHTTPTelnetFTPDNSRIPDHCPIP电话流媒体如果设计一个只提供必要服务的最简化的运输层协议，你打算怎样做？4.3UDP协议考虑使用一个无所事事的运输层协议发送方将来自应用进程的报文直接交给网络层。接收方将来自网络层的报文直接交给应用进程。正如前一节所学运输层必须做一点儿事，而不是什么都不做！至少必须提供一个多路复用/多路分解服务，在网络层与正确的应用进程之间传递数据。1.UDP协议的主要特点：34只提供多路复用/分解功能及一些简单的差错检查。应用程序几乎是直接与IP打交道“尽力而为”服务，UDP段可能：丢包对应用程序交付失序无连接:在UDP发送方和接收方之间无握手每个UDP段的处理独立于其他段面向报文的传输层协议为何要有UDP协议?应用层能够更好地控制要发送的数据和发送时间；无需建立连接(它将增加时延)；不维护连接状况；分组首部开销小；无拥塞控制:UDP能够尽可能快地传输常用于流式多媒体应用丢包容忍速率敏感经UDP的可靠传输:在应用层增加可靠性应用程序特定的差错恢复！缺乏拥塞控制会导致UDP发送方和接收方之间的高丢包率，并挤垮TCP会话；需要拥塞控制来预防网络进入一种低效状态；提出新的机制执行自适应拥塞机制2.UDP报文格式UDP报文有固定8字节的报头。36应用层数据占用了UDP报文段的数据字段。UDP报头主要字段：端口号端口号字段包括源端口号和目的端口号；端口号字段长度为16位（2个字节）；源端口号表示发送端进程端口号，目的端口号表示接收端进程端口号；如果源进程是客户端，则源端口号是分配的临时端口号；服务器使用的是熟知端口号。37长度长度字段长度也是16位（2字节），它定义了包括报头在内的用户数据报的总长度；用户数据报的长度最大为65535字节，最小是8字节；如果长度字段是8字节，那么说明该用户数据报只有报头，而没有数据。38校验和UDP校验和用来检验整个用户数据报（包括报头）在传输中是否出现差错。有错就丢弃。UDP校验和包括三个部分：伪报头（pseudoheader）、UDP报头与应用层数据。39链路中或路由器中噪声干扰伪首部源端口目的端口长度检验和数据首部UDP长度源IP地址目的IP地址017IP数据报字节44112122222字节发送在前数据首部UDP用户数据报3.UDP校验和的基本概念与计算示例在计算检验和时，临时把“伪首部”和UDP用户数据报连接在一起。伪首部既不向下传送也不向上提交，仅仅是为了计算检验和。协议号填充字段不包括伪报头校验和计算方法把首部和数据部分一起都检验发送方:先把全零放入检验和字段将段内容（伪首部和UDP数据报）处理为16bit整数序列数据部分不是16bit整数倍要需要填写一个全零字节（但此字节不发送）；计算检查和:段内容的加法(反码和)发送方将检查和放入UDP检查和字段接收方:所有段内容（伪首部和UDP数据报）二进制求和计算16位的和结果全为1，说明数据传输正确，丢弃伪报头和填充，接收！如果出现零，则有差错，接收方应丢弃（也可以交给应用层，但附上出现了差错的警告）伪首部源端口目的端口长度检验和UDP长度源IP地址目的IP地址017字节44112122222字节注意当数字作加法时，最高位进比特位的进位需要加到结果中例子:两个16-bit整数相加111100110011001101110101010101010111011101110111011

11

101110111011110010100010001000011回卷和检查和发送端计算UDP校验和的例子43算法简单，处理快，但检错能力不强4.UDP协议适用的范围确定应用程序在传输层是否采用UDP协议的原则：系统对性能的要求高于对数据完整性的要求；需要“简短快捷”的数据交换；需要多播和广播的应用；

UDP协议是一种适用于实时语音与视频传输的传输层协议。444.4TCP协议4.4.1TCP协议的主要特点支持面向连接的传输服务应用程序在使用TCP传送数据之前，必须在源进程端口与目的进程端口之间建立一条传输连接；每个TCP连接唯一地用双方套接字来标识；每个TCP连接为通信双方的一次进程通信提供服务。45支持字节流的传输流（stream）指的是流入到进程或从进程流出的字节序列。TCP把应用层数据看成是无结构字节流，不知道字节流的含义。TCP根据接收方给出的窗口大小和网络拥塞程度来决定一个报文段应包括多少个字节。（UDP报文长度是应用层给出的）因此接收端应用程序数据字节的起始与终结位置必须由应用程序自己确定。46TCP协议

支持字节

流传输

示意图47发送和接收缓冲区由于通信的双方都设置有发送和接收缓冲区，应用程序将要发送的数据字节提交给发送缓冲区，数据字节的实际发送过程由TCP协议来控制；接收端在接收到数据字节之后也将它存放到接收缓冲区，高层应用程序在它合适的时间到缓冲区中读取数据。支持全双工服务TCP允许通信双方的应用程序在任何时候都可以发送数据；流量控制发送方不能淹没接收方拥塞控制抑止发送方速率来防止过分占用网络资源49支持同时建立多个并发的TCP连接根据应用程序的需要，TCP协议支持一个服务器与多个客户端同时建立多个TCP连接；也支持一个客户端与多个服务器同时建立多个TCP连接；50支持可靠传输服务TCP是一种可靠的传输服务协议，它使用确认机制检查数据是否安全和完整地到达，并且提供拥塞控制功能；TCP支持可靠数据通信的关键是对发送和接收的数据进行跟踪、确认与重传；传输层传输的可靠性是建立在网络层基础上，同时也就会受到它们的限制。51总结TCP协议的特点是：面向连接面向字节流支持全双工支持并发连接提供确认重传与拥塞控制524.4.2TCP报文格式TCP报头长度为20～60字节，其中固定部分长度为20字节；选项部分长度可变，最多为40字节。53TCP报头包括的主要字段：端口号端口号字段包括源端口号与目的端口号；每个端口号字段长度为16位（2字节），分别表示发送该报文段的应用进程的源端口号与接收进程的目的端口号。序号序号字段长度为32位（4个字节），序号范围在0～（232-1），即0～4284967295；序号增加到232-1后，下一个序号又回到0；为发送字节流中的每个字节都按顺序编号；起始序号必须在连接建立时设置；序号字段值是本报文段所发送的数据的第一个字节的序号54确认号确认号字段长度为32位（4字节）；确认号表示一个进程已经正确接收序号为N的字节，要求发送方下一个应该发送序号为N+1的字节的报文段。可对4GB的数据进行编号。在一般情况下可保证数据当序号重复使用时，旧序号的数据早已通过网络到达终点了。报头长度报头长度字段的长度为4位;TCP报头长度是以4字节为一个单元来计算的，实际报头长度是在20～60字节，因此这个字段的值是在5至15之间。55控制字段控制字段定义了6种不同的控制位或标志位;控制字段将在TCP的连接建立和终止、流量控制，以及数据传送中发挥作用。56标志说明SYN在连接时对序号进行同步。ACK确认字段的值有效。当ACK=1时，确认号才有效。FIN终止连接RST连接必须复位。TCP连接出现严重差错要重新建立连接。还可用来拒绝一个非法报文段或拒绝打开一个链接。URG紧急指针字段的值有效。有紧急数据尽快传送，插入到报文段最前面，与紧急指针配合使用。PSH将数据推向前，希望立即收到对方响应。接收方收到后尽快交付给接收应用进程。窗口大小窗口字段长度为16位;窗口的长度值是在0～65535之间；窗口字段值指示对方最多可以发送的字节数，作为发送方确定发送窗口的依据。明确指出了从被确认的字节算起可以发送的数据量。窗口字段值是动态变化的。窗口值为0也是合法的。表示接收方暂时不能接收数据，发送方要停止发送。57校验和计算校验和与UDP校验和的方法相同；TCP校验和同样需要伪报头，唯一不同的是协议字段的值是6。紧急指针紧急指针字段的长度为16位，只有当紧急标志URG=1时，这个字段才有效，这时的报文段中包括紧急数据；指出了紧急数据的末尾在报文段中的位置。TCP软件要在优先处理完紧急数据之后才能够恢复正常操作。注意，即使窗口为零时也可以发送紧急数据。伪首部UDP长度源IP地址目的IP地址06字节4411212字节TCP最大段长度（MSS）理解MSS时需要注意以下几个问题：TCP报文段的最大长度与窗口长度的概念不同。设置窗口大小是通知发送方下一次可以连续传输的字节数；最大段长度MSS是在构成一个TCP报文段时最多可以在报文的数据字段中放置的数据字节数量；MSS值的确定与每次传输的窗口大小无关；MSS是TCP报文中数据部分的最大长度，不包括报头长度。59MSS值的选择应该考虑的因素：MSS值太小——协议开销TCP报文的长度等于报头部分加上数据部分，选择MSS值太小会增大协议开销所占的比例。MSS值太大——IP分片如果MSS值选择得比较大，受到IP分组长度的限制，较长的报文段在IP层将会被分片传输；分片的结果同样会增加网络层的开销和传输出错的概率。IP分组经历的路径是动态变化的，因此这条路径不需要分片的MSS，如果该走另一条路径就可能需要分片。最佳的MSS是很难确定的。60MSS值的设定在建立TCP连接的时候，双方把自己能够支持的MSS写入这一字段中，以后按照这个值传送数据。（不是协商，只是通知对方）TCP允许连接的双方可以选择使用不同的MSS值。若主机未填写，则默认的MSS值为536字节。61窗口扩大选项首部中窗口字段16位，最大为64K字节。对于卫星信道的网络，要获得高吞吐率需要更大的窗口；其中有一个字节表示移位值S。新窗口值等于16+S。移位值允许使用的最大值是14。相当于窗口增大到216+14双方建立连接时协商。当不再需要扩大时，可发送S=0时间戳占10个字节，主要是时间戳值字段（4个字节）和时间戳回送回答字段（4个字节）；计算往返时间RTT。发送方在发送时把当前时间值放入时间戳字段，接收方在确认报文段时把时间戳字段值复制到时间戳回送回答字段。发送方收到确认后，可以准确计算出RTT。用于处理TCP序号超过的232情况，称为防止序号绕回。当使用高速网络时发送序号很可能被重复使用，为了是接收方能够把新的报文段和迟到报文段区分开，可以加上时间戳。0050/源端口：8005A6/目的端口：1446A3853DB7/发送序号：2743418295C7FBC12C/确认序号：33551649727012/01110000000100100111/首部长度：7*4=28字节000000/保留：010010/标志位：URG/ACK/PSH/RST/SYN/FINACK：1SYN：116D0/窗口大小：58402A32/校验和：108020000/紧急指针：0020405B401010402/选项字段：

MSS：05B4=1460字节05A6/源端口：14460050/目的端口：80C7FBC12C/发送序号：3355164972A3853DB8/确认序号：27434182965010/01010000000100000101/首部长度：5*4=20字节000000/保留：010000/标志位：URG/ACK/PSH/RST/SYN/FINACK：1FFFF/窗口大小：655356DC6/校验和：281020000/紧急指针：04.4.3可靠传输的工作原理理想的传输条件有以下两个特点：传输信道不产生差错。不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。需要可靠传输协议做到：出现差错时让发送方重传出现差错的数据；接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。只讨论可靠传输的一般原理，并不具体针对某一层！！！发送方如何知道发送成功还是失败？分组丢失或迟到怎么办？已经发送的分组可以马上丢弃么？如何区分重传分组或新的分组？如何区分对哪个分组的确认？否定确认是否可以不用？Rdt1.0超时计时器的重传时间设置多长比较合适？肯定确认(acknowledgement)否定确认(negativeacknowledgement)每发送完一个分组后启动计时器应当比数据在分组传输的平均往返时间更长一些对发送分组和确认分组编号必须暂时保留已发送的分组的副本，只有收到确认后才能清除超时自动重传，通常只使用肯定确认m0ack0m1m1×m1ack1m0ack0ack0×m0m0丢弃ack0timeouttimeout

m1超时重传

m0超时重传Rdt1.0——停等协议（StopandWait）停等协议的主要问题是什么？传输效率低1Gb/s带宽,15ms端到端传播时延,1K字节分组信道利用率万分之2.7；吞吐量33kB/s

网络协议限制了物理资源的使用!TDRTTATD+RTTB分组确认tt分组确认TD=8kb/pkt10**9b/sec=8msL(packetlengthinbits)R(transmissionrate,bps)=如何解决？可以在等待确认的时间内允许发送方连续发送，而不必等待确认分组的到达可以在等待确认的时间内允许发送方连续发送，这种技术被称为流水线或管道化技术（Pipelining）Rdt2.0——回退N帧协议（GO-Back-N，GBN）连续发送的数据中有一个被损坏了或丢失了，怎么办？等待重传B分组ttAACK接收方如何处理后续到达的正确分组呢？丢弃并且不发送确认，从出错的分组开始全部重传GBN累积确认（CumulativeAcknowledge）在分组n超时定时器到期之前收到对更高序号分组k的确认，则可认为n到k之间所有的分组都已经收到。可以不必对每个分组都逐个确认，可以等待若干个分组按序到达后发送一个确认对某个分组的确认丢失了，也不会因为确认丢失而重传这个分组例题：采用回退N帧协议，发送方已经发送了0-7序号的分组，计时器超时，只收到0，3序号的确认分组，问需要重发哪几个分组？需要重发4、5、6、7m0m1m2m3m0m1m0m1m2m2m3m3m1

×m2丢弃m3丢弃m1m1m2m2m3m3ack0timeouttimeoutack3m1超时重传累积确认Go-Back-Nack2ack2

×GBN协议的主要问题是什么？一个分组的差错可能引起大量正确接收（但失序）的分组重传如何解决？仅重传那些出错的分组Rdt3.0——选择性重传协议（Selectiverepeat，SR）接收方将正确的分组接收缓存起来而不管其是否有序，直到所有丢失分组都被收到，才可以将一批分组按序交付给上层。发送方只重传出错的分组m0m1m2m3m0m1m0m1m2m2m3m3m1

×m1m1ack0timeouttimeoutack3m1超时重传ack2ack1计时取消接收方缓冲区溢出，数据丢失如何解决？必须进行流量控制保证数据的完整性流水线技术对可靠数据传输带来哪些影响？发送方如何确定哪些分组是可以发送的？维持一个发送窗口（sendingwindow）窗口内的分组可以发送接收方如何确定哪些分组是可以接收？维持一个接收窗口（receivingwindow）窗口内的分组可以接收允许发送但尚未发送不允许发送已发送并收到确认A的发送窗口01234567891617181920已发送但未收到确认151011121314允许接收不允许接收已发送并交付主机B的接收窗口01234567891617181920未按序收到151011121314如何使用窗口控制流量？滑动窗口012345678901234567890123456789012345678901234567890123456789×0123456789012340123456789012345678901234567891340123456789×13GBN协议——窗口示意图0timeouttimeout0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567892401234567890123456789012345678901234567890123456789012345678901234567890123456789×01234567890123456789012345678901234567890123450123456789012345678901234567892012345678913SR协议——窗口示意图00123456789452timeouttimeout可靠数据传输机制及用途总结机制用途和说明检验和用于检测在一个传输分组中的比特错误。定时器用于检测超时/重传一个分组，可能因为该分组（或其ACK）在信道中丢失了。由于当一个分组被时延但未丢失（过早超时），或当一个分组已被接收方收到但从接收方到发送方的ACK丢失时，可能产生超时事件，所以接收方可能会收到一个分组的多个冗余拷贝。序号用于为从发送方流向接收方的数据分组按顺序编号。所接收分组的序号间的空隙可使该接收方检测出丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余拷贝。确认接收方用于告诉发送方一个分组或一组分组已被正确地接收到了。确认报文通常携带着被确认的分组或多个分组的序号。确认可以是逐个的或累积的，这取决于协议。否定确认接收方用于告诉发送方某个分组未被正确地接收。否定确认报文通常携带着未被正确接收的分组的序号。（通常并不发送否定确认）窗口、流水线发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但未被确认，发送方的利用率可在停等操作模式的基础上得到增加。我们很快将会看到，窗口长度可根据接收方接收和缓存报文的能力或网络中的拥塞程度，或两者情况来进行设置。4.4.4TCP可靠通信的具体实现

TCP的可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段。TCP连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。

TCP两端的四个窗口经常处于动态变化之中。TCP连接的往返时间RTT也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。1.TCP序号和确认号序号:报文段中第1个数据字节在字节流中的位置编号确认号:期望从对方收到下一个字节的序号累计应答问题：接收方如何处理失序报文段？回答：TCP规范没有说明，由实现者自行选择实现:抛弃/缓存主机A主机BSeq=42,ACK=79,data=‘C’Seq=79,ACK=43,data=‘C’Seq=43,ACK=80用户键入‘C’主机对接收到的‘C’回显给出确认主机对收到的‘C’给出确认,

回显‘C’时间简单的telnet情况捎带确认注意：TCP确认针对流中的字节而不是段。累计的含义表示，如果某一方使用5643作为确认号，那么它就已经收到了一直到5642和这以前的所有字节。应当注意的是，这并不表示这一方已经收到了5642个字节，因为第一个字节的编号不一定从0开始。累计确认的优点：变长段方式下不会产生二义性确认丢失后不一定导致重传累计确认的缺点：发送方不能获得关于所有成功的段传输的信息，假如前面尚有数据未得到确认，尚有数据未得到确认，则后面的所有成功传输的段也得不到确认。

考虑：假设主机A通过TCP连接向主机B连续发送两个TCP报文段。第一个报文段的发送序号为90，第二个报文段的发送序号为110.1.第一个报文段中有多少数据？2.假设第一个报文段丢失第二个报文段到达主机B。那么主机B发送给A的确认报文中，确认序号应该是多少？字节流传输的状态分类2.以字节为单位的滑动窗口SendandackedSendandnotackedWaitingtobesentNotintheWindows前移不允许发送已发送并收到确认A的发送窗口=20允许发送的序号26272829303132333435363738394041424344454647484950515253545556B期望收到的序号前沿后沿前移收缩根据B给出的窗口值A构造出自己的发送窗口TCP标准强烈不赞成发送窗口前沿向后收缩不允许发送已发送并收到确认A的发送窗口位置不变允许发送但尚未发送262728293031323334353637383940414243444546474849505152535455已发送但未收到确认56P1P2P3不允许接收已发送确认并交付主机B的接收窗口允许接收26272829303132333435363738394041424344454647484950515253545556未按序收到可用窗口A发送了11个字节的数据P3–P1=A的发送窗口（又称为通知窗口）P2–P1=已发送但尚未收到确认的字节数P3–P2=允许发送但尚未发送的字节数（又称为可用窗口）允许发送但尚未发送A的发送窗口向前滑动262728293031323334353637383940414243444546474849505152535455已发送并收到确认不允许发送已发送但未收到确认56P1P2P3允许接收B的接收窗口向前滑动262728293031323334353637383940414243444546474849505152535455已发送确认并交付主机不允许接收56未按序收到A收到新的确认号，发送窗口向前滑动先存下，等待缺少的数据的到达不允许发送已发送并收到确认A的发送窗口已满，有效窗口为零262728293031323334353637383940414243444546474849505152535455已发送但未收到确认56P1P2P3A的发送窗口内的序号都已用完，但还没有再收到确认，必须停止发送。缓存和窗口的关系发送方的应用进程把字节流写入TCP的发送缓存，接收方的应用进程从TCP的就收缓存中读取字节流。要明确两点：缓存空间和序号空间都是有限的，并循环使用；实际上缓存缓存或窗口中的字节数是非常大的。发送缓存最后被确认的字节发送应用程序发送缓存最后发送的字节发送窗口已发送TCP序号增大最后写入的字节发送缓存用来暂时存放：1.发送应用程序传送给发送方TCP准备发送的数据；2.TCP已经发送出但尚未收到确认的数据。接收缓存接收应用程序已收到接收窗口TCP接收缓存下一个读取的字节序号增大下一个期望收到的字节（确认号）按序到达的未按序到达的接收缓存用来暂时存放：1.按序到达的、但尚未被接收应用程序读取的数据；2.未按需到达的数据；需要强调三点A的发送窗口并不总是和B的接收窗口一样大（因为有一定的时间滞后）。发送方根据自身的状况，根据接收到的窗口信息发送字节流，不一定要发送整个窗口大小的数据。TCP标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。接收方可以在合适的时候发送确认，在自己有数据要发送时把确认信息捎带上。接收方不应过分推迟发送确认，会导致不必要的重传，TCP规定推迟时间不应超过05秒。若收到具有最大长度的报文段，则必须每隔一个报文段就要发送一个确认。捎带确认实际上并不经常发生，大多数应用程序不同时在两个方向上发送数据。3.超时重传时间的选择重传机制是TCP中最重要和最复杂的问题之一。TCP每发送一个报文段，就对这个报文段设置一次重传计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。重传计时器重传计时器用来处理报文确认与等待重传时间；重传计时器的工作过程：95设定重传计时器的时间值需要注意的几个问题设定重传计时器适当的时间值对于协议至关重要。一个主机同时与其他两个主机建立两条TCP连接，那么它就需要分别为每个TCP连接启动一个重传计时器，不可能对不同的TCP连接使用一个重传计时器；由于互联网在不同时间段的用户数量、流量与传输延迟变化也很大，因此即使是相同的两个主机在不同时间建立的TCP连接，并且完成同样的Web访问操作，客户端与服务器端之间的报文传输延迟也不会相同。在互联网环境中为TCP连接确定合适的重传定时器数值是很困难的，必然要选择使用一种动态的自适应重传方法。RFC2988“计算TCP重传定时器”文档详细讨论了这个问题。96计算重传时间的方法——加权平均往返时间TCP保留了RTT的一个加权平均往返时间

RTTS（这又称为平滑的往返时间）。第一次测量到RTT样本时，RTTS值就取为所测量到的RTT样本值。以后每测量到一个新的RTT样本，就按下式重新计算一次RTTS：新的RTTS

(1

)(旧的RTTS)

(新的RTT样本)式中，0

1。若很接近于零，表示RTT值更新较慢。若选择接近于1，则表示RTT值更新较快。RFC2988推荐的值为1/8，即0.125。超时重传时间RTO(RetransmissionTime-Out)RTO应略大于上面得出的加权平均往返时间RTTS。对于每个TCP连接都要维持一个RTT变量，它是当前到达目的结点在最佳估计往返延时值。自适应重传定时基于往返时间（RTT），计算重传时间的公式为：

Timeout=β×RTT其中，β为一个大于1的常数加权因子；RTT为估算的往返时间；往返时间RTT?往返时间的测量相当复杂TCP报文段1没有收到确认。重传（即报文段2）后，收到了确认报文段ACK。如何判定此确认报文段是对原来的报文段1的确认，还是对重传的报文段2的确认？发送一个TCP报文段超时重传TCP报文段收到ACK时间12往返时间RTT?是对哪一个报文段的确认？Karn

算法在计算平均往返时间RTT时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均平均往返时间RTTS

和超时重传时间RTO就较准确。报文段每重传一次，就把RTO增大一些：新的RTO

(旧的RTO)系数的典型值是2。当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延RTT和超时重传时间RTO的数值。实践证明，这种策略较为合理。修正的Karn

算法讨论：α决定RTT对延迟变化的反应速度；当α接近1时，短暂的延迟变化对RTT不起作用；当α接近0时，RTT将紧紧跟随延迟变化。β因子很难确定；当β接近1时，TCP能迅速检测报文丢失，及时重传，减少等待时间，但是可能引起很多重传报文；当β太大时，重传报文减少，但是等待确认的时间太长；作为折衷，TCP推荐β=2；以往返时间（RTT）为基础的重传超时可以是动态的。因此，使用最多的是设重传时间为RTT的两倍。102已知：收到了3个连接的确认报文段，它们比相应的数据报文段发送时间分别滞后26ms、32ms与24ms。假设：α=0.9。求：新的估计往返延时值为多少？

解：从题意中可以找出以下的已知条件：α=0.9，旧RTT=30ms，M1=26ms，M2=32ms，M3=24ms。根据公式可以计算出：RTT1=0.9×30+（1-0.9）×26≈29.6（ms）RTT2=0.9×29.6+（1-0.9）×32≈29.8（ms）RTT3=0.9×29.8+（1-0.9）×24≈29.3（ms）答案：新的往返延时估计值分别为29.6（ms）、

29.8（ms）与29.3（ms）。1034.选择确认SACK(SelectiveACK)接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。110001501300035014500确认号=1001L1=1501L2=3501R1=3001R1=4501接收到的字节流序号不连续……连续的字节流………第一个字节块第二个字节块

和前后字节不连续的每一个字节块都有两个边界：左边界和右边界。图中用四个指针标记这些边界。第一个字节块的左边界L1=1501，但右边界R1=3001。左边界指出字节块的第一个字节的序号，但右边界减1才是字节块中的最后一个序号。第二个字节块的左边界L2=3501，而右边界R2=4501。RFC2018的规定如果要使用选择确认，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。由于首部选项的长度最多只有40字节，而指明一个边界就要用掉4字节，因此在选项中最多只能指明4个字节块的边界信息。另外还需要两个字节1个字节指明“SACK”选项。1个字节指明这个选项占用多少个字节。4.4.5TCP的流量控制

1利用滑动窗口实现流量控制一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。流量控制(flowcontrol)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在TCP连接上实现流量控制。seq=1,DATAseq=201,DATAseq=401,DATAseq=301,DATAseq=101,DATAseq=201,DATAseq=501,DATAACK=1,ack=201,rwnd=300ACK=1,ack=601,rwnd=0ACK=1,ack=501,rwnd=100AB允许A发送序号201至500共300字节A发送了序号101至200，还能发送200字节A发送了序号301至400，还能再发送100字节新数据A发送了序号1至100，还能发送300字节A发送了序号401至500，不能再发送新数据了A超时重传旧的数据，但不能发送新的数据允许A发送序号501至600共100字节A发送了序号501至600，不能再发送了不允许A再发送（到序号600为止的数据都收到了）丢失！流量控制举例A向B发送数据。在连接建立时，

B告诉A：“我的接收窗口rwnd=400（字节）”。seq=1,DATAseq=201,DATAseq=401,DATAseq=301,DATAseq=101,DATAseq=201,DATAseq=501,DATAACK=1,ack=201,rwnd=300ACK=1,ack=601,rwnd=0ACK=1,ack=501,rwnd=100B丢失！持续计时器

(persistencetimer)。假定接收端的TCP通告窗口大小为零。发送方的TCP就停止传送报文，直到接收端的TCP发送确认并通告一个非零的窗口大小，这个确认可能会丢失。对方的TCP都在永远地等待着对方，这就可能出现了死锁；为了防止死锁，TCP为每个连接使用一个坚持计时器(或持续计时器)。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。坚持计时器的值设置为重传时间值，这个值增大到门限值通常设定为60秒。

2必须考虑传输效率如何控制发送方TCP报文段的发送时机:第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。第二种机制是由发送方的应用进程指明要求发送报文段，即TCP支持的推送(push)操作。第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。如何控制接收方确认报文段的发送时机：糊涂窗口综合症：接收方发送只有1B的窗口更新报文。接收要等待一段时间，使得接收缓存已有足够空间容纳一个最大报文段，或缓存已有一半的空闲的空间。4.4.6TCP的拥塞控制

1.拥塞控制的一般原理在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生拥塞(congestion)。出现资源拥塞的条件：对资源需求的总和>可用资源若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。拥塞控制与流量控制的关系拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。拥塞控制所起的作用提供的负载吞吐量理想的拥塞控制实际的拥塞控制0死锁（吞吐量=0）无拥塞控制拥塞轻度拥塞提供的负载：代表单位时间内输入给网络的分组数目，也称为输入负载或网络负载。吞吐量：代表单位时间内从网络输出的分组数目。吞吐量达到饱和（输入的某些分组被丢弃了）（吞吐量未达到饱和时就有输入的分组被丢弃了）（吞吐量随提供的负载的增大而下降）拥塞控制的一般原理拥塞控制是很难设计的，因为它是一个动态的（而不是静态的）问题。当前网络正朝着高速化的方向发展，这很容易出现缓存不够大而造成分组的丢失。但分组的丢失是网络发生拥塞的征兆而不是原因。开环控制和闭环控制开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。闭环控制是基于反馈环路的概念。属于闭环控制的有以下几种措施：监测网络系统以便检测到拥塞在何时、何处发生。将拥塞发生的信息传送到可采取行动的地方。调整网络系统的运行以解决出现的问题。2.几种拥塞控制方法

慢开始和拥塞避免发送方维持一个叫做拥塞窗口cwnd(congestionwindow)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。慢开始算法的原理在主机刚刚开始发送报文段时可先设置拥塞窗口cwnd=1，即设置为一个最大报文段MSS的数值。在每收到一个对新的报文段的确认后，将拥塞窗口加1，即增加一个MSS的数值。用这样的方法逐步增大发送端的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。发送方接收方发送M1

确认M1发送M2~M3

确认M2~M3发送M4~M7

确认M4~M7cwnd=1cwnd=2cwnd=4发送M8~M15cwnd=8…tt发送方每收到一个对新报文段的确认（重传的不算在内）就使cwnd

加1。轮次1轮次2轮次3传输轮次

(transmissionround)使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd

就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。“传输轮次”更加强调：把拥塞窗口cwnd

所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。例如，拥塞窗口cwnd=4，这时的往返时间RTT就是发送方连续发送4个报文段，并收到这4个报文段的确认，总共经历的时间。设置慢开始门限状态变量ssthresh慢开始门限ssthresh

的用法如下：当cwnd<ssthresh

时，使用慢开始算法。当cwnd>ssthresh

时，停止使用慢开始算法而改用拥塞避免算法。当cwnd=ssthresh

时，既可使用慢开始算法，也可使用拥塞避免算法。拥塞避免算法的思路是让拥塞窗口cwnd

缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd

加1，而不是加倍，使拥塞窗口cwnd

按线性规律缓慢增长。当网络出现拥塞时无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限ssthresh

设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd

重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。2216慢开始和拥塞避免算法的实现举例当TCP连接进行初始化时，将拥塞窗口置为1。图中的窗口单位不使用字节而使用报文段。慢开始门限的初始值设置为16个报文段，即ssthresh=16。“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开始慢开始慢开始拥塞避免“加法增大”拥塞避免“加法增大”传输轮次慢开始和拥塞避免算法的实现举例发送端的发送窗口不能超过拥塞窗口cwnd

和接收端窗口rwnd

中的最小值。我们假定接收端窗口足够大，因此现在发送窗口的数值等于拥塞窗口的数值。2216“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开始慢开始慢开始拥塞避免“加法增大”拥塞避免“加法增大”传输轮次慢开始和拥塞避免算法的实现举例在执行慢开始算法时，拥塞窗口cwnd

的初始值为1，发送第一个报文段M0。

2216“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开始慢开始拥塞避免“加法增大”拥塞避免“加法增大”传输轮次慢开始和拥塞避免算法的实现举例发送端每收到一个确认，就把cwnd

加1。于是发送端可以接着发送M1和M2两个报文段。2216“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开始慢开始慢开始拥塞避免“加法增大”拥塞避免“加法增大”传输轮次慢开始和拥塞避免算法的实现举例接收端共发回两个确认。发送端每收到一个对新报文段的确认，就把发送端的cwnd

加1。现在cwnd

从2增大到4，并可接着发送后面的4个报文段。2216“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开始慢开始慢开始拥塞避免“加法增大”拥塞避免“加法增大”传输轮次慢开始和拥塞避免算法的实现举例发送端每收到一个对新报文段的确认，就把发送端的拥塞窗口加1，因此拥塞窗口cwnd

随着传输轮次按指数规律增长。2216“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开始慢开始慢开始拥塞避免“加法增大”拥塞避免“加法增大”传输轮次慢开始和拥塞避免算法的实现举例当拥塞窗口cwnd

增长到慢开始门限值ssthresh

时（即当cwnd=16时），就改为执行拥塞避免算法，拥塞窗口按线性规律增长。2216“乘法减小”24681012141618200048122024拥塞窗口cwnd新的ssthresh

值网络拥塞指数规律增长ssthresh

的初始值慢开