计算机网络精编教程-原理与实践 课件 第4章 端到端的通信

端到端的通信第4章计算机网络体系结构运输层网络层应用层数据链路层物理层54321五层协议的体系结构计算机网络体系结构面向通信的功能用户功能计算机网络体系结构

4.1端到端的概述4.2UDP4.3TCP4.4TCP与UDP的区别端到端的通信4.1.1端系统与网络层4.1.2端口的概念4.1.3监听端口概念4.1端到端的概念4.1.1端系统与网络层端到端通信的概念：在现实的网络购物中，卖方通过物流公司，将货物从卖方通信地址送达到买方通信地址。从计算机网络体系结构上看，网络层的作用范围是从一个IP地址到另一个IP地址，解决了主机到主机间的通信问题，类似物流公司的作用范围是在两个通信地址之间，解决了异地货物转运的问题。驿站A驿站B物流端到端的通信：运输层协议的作用范围网络互联：IP协议的作用范围端系统之间通信“主机A和主机B进行通信”实际上是指：“运行在主机A上的某个程序和运行在主机B上的另一个程序进行通信”。端到端的通信是进程之间的通信。即“主机A的某个进程和主机B上的另一个进程进行通信”。简称为“计算机之间通信”。计算机网络体系结构应用层网络购物进程买家与卖家（很多对）运输层协议驿站使用的买家与卖家的手机号码网络层协议买家与卖家通信地址网络层与运输层的关系的例子驿站卖家买家运输层的作用“逻辑通信”的意思是“好像是这样通信，但事实上并非真的这样通信”。从IP层来说，通信的两端是两台主机。但“两台主机之间的通信”这种说法还不够清楚。严格地讲，两台主机进行通信就是两台主机中的应用进程互相通信。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。主机A主机B路由器1路由器2LAN2WANLAN1AP1AP2AP3AP4网络层和运输层的作用不同主机A主机B路由器1路由器2LAN2WANLAN1AP1AP2AP3AP4应用进程应用进程端口端口AP1AP45432154321网络层和运输层有明显的区别运输层提供应用进程间的逻辑通信321321网络层网络层协议IP的作用范围运输层协议TCP和UDP的作用范围AP3AP2网络层是为主机之间提供逻辑通信；运输层为应用进程之间提供端到端的逻辑通信。基于端口的复用和分用功能应用层运输层网络层TCP报文段UDP用户数据报应用进程

IP复用

TCP报文段UDP用户数据报

应用进程端口端口TCP分用UDP分用IP分用IP数据报IP数据报发送方接收方UDP复用TCP复用屏蔽作用运输层向高层用户屏蔽了下面网络核心的细节，它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。互联网应用进程AP应用进程AP逻辑通信信道两种不同的运输协议逻辑通信信道对上层的表现却因运输层使用的不同协议而有很大的差别。当运输层采用面向连接的TCP

协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。当运输层采用无连接的UDP

协议时，这种逻辑通信信道是一条不可靠信道。？应用层运输层接收进程全双工可靠信道数据使用面向连接的协议，如TCP。使用无连接的协议，如UDP。不可靠信道发送进程数据接收进程发送进程数据数据4.1.1端口的概念在互连网络中，全网采用了一个统一的、抽象的、用于区别不同系统中进程的标识，该标识就是端口（port）。通过端口，不同系统间的进程能够相互间接识别：源进程通过源端口发送数据，而接收进程通过目的端口接收数据。端口号(protocolportnumber)解决这个问题的方法就是在运输层使用协议端口号

(protocolportnumber)，或通常简称为端口

(port)。虽然通信的终点是应用进程，可以把端口想象是通信的终点，因为我们只要把要传送的报文交到目的主机的某一个合适的目的端口。708090192.168.10.2:80端口号软件端口与硬件端口两个不同的概念。在协议栈层间的抽象的协议端口是软件端口。路由器或交换机上的端口是硬件端口。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。与各种网络接口物理硬件ICMPIPARP各种应用层协议(HTTP,FTP,SMTP等)TCP,UDPTCP/IP运输层端口端口用一个16位端口号进行标志，允许有65,535个不同的端口号。端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在互联网中，不同计算机的相同端口号是没有联系的。708090P2P1P3192.168.1.7:80708090P2P1P3192.168.10.2:80端口TCP/IP运输层端口端口用一个16位端口号进行标志，允许有65,535个不同的端口号。端口号只具有本地意义，即端口号只是为了标志本计算机应用层中的各进程。在互联网中，不同计算机的相同端口号是没有联系的。由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的端口号（为了找到对方计算机中的应用进程），而且还要知道对方的IP地址（为了找到对方的计算机）。服务器端使用的端口

端口5880080

Web服务器Web浏览器数据8058800数据8058800运输层运输层两大类端口服务器端使用的端口号熟知端口，数值一般为0~1023。登记端口号，数值为1024~49151，为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在IANA登记，以防止重复。客户端使用的端口号又称为短暂端口号，数值为49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。两大类、三种类型的端口01023102449,15149,15265,535服务器端使用的端口号客户端使用的端口号熟知端口（IANA负责分配）登记端口短暂端口4.1.3端口监听的概念对于互连网络中的服务器程序而言，服务器程序使用的端口，被称为服务器监听的端口。在互联网世界中，有很多著名的程序，提供着各种不同的服务，例如：著名的超文本传输协议HTTP，使用的端口是80UDPTCPIPHTTP:80端口常用的熟知端口UDPTCPIPSMTPFTPTelnetRPCDNSSNMPTFTP53161692523HTTP80HTTPS443SNMP(trap)2120162111部分服务器程序使用的端口部分服务器程序使用的端口4.2.3UDP报文格式4.2.1UDP概述4.2UDP协议4.2.2UDP的特点4.2.1UDP概述用户数据报协议（UserDatagramProtocol，UDP）在RFC768中被定义，UDP

较为简单，除实现了运输层多路复用与分用以及差错检测功能之外，没有在IP协议之上增加任何改进的功能，如果应用进程选择使用运输层的UDP协议，则几乎是直接采用IP协议运输层网络层首部UDP数据部分IP数据报UDP概述UDP只在IP的数据报服务之上增加了很少一点的功能：复用和分用的功能差错检测的功能UDP协议的主要特点UDP是无连接的，发送数据之前不需要建立连接，，因此减少了开销和发送数据之前的时延。UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。UDP是面向报文的。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。UDP一次交付一个完整的报文。UDP的主要特点UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的，很适合多媒体通信的要求。UDP支持一对一、一对多、多对一和多对多的交互通信。UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。UDP的主要特点UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很适合多媒体通信的要求。UDP支持一对一、一对多、多对一和多对多的交互通信。UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。应用层报文UDP首部IP首部发送方应用层报文UDP首部IP首部接收方4.2.1面向报文的UDP协议面向报文的UDP发送方UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。报文UDP数据UDP首部IP数据IP首部IP数据帧首部报文UDP数据UDP首部IP数据IP首部IP数据帧首部面向报文的UDP接收方UDP对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后IP层在传送时可能要进行分片，这会降低IP层的效率。若报文太短，UDP把它交给IP层后会使IP数据报的首部的相对长度太大，这也降低了IP层的效率。报文UDP数据UDP首部IP数据IP首部IP数据帧首部UDP是面向报文的IP数据报的数据部分IP首部IP层UDP首部UDP用户数据报的数据部分运输层应用层报文应用层4.2.3UDP报文格式16用户数据报UDP格式：SourcePort，源端口、DestinationPort，目的端口、Length，长度、Checksum，校验和Source

PortDestinationLengthChecksumDataoctets31Source

Port16位Destination16位Length16位Checksum16位0标识源主机中发送数据的应用进程用于标识目的主机接收数据的应用进程指明UDP用户数据报的总长度检测UDP报文在端到端的传输过程中是否出错UDP基于端口的分用当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交给最后的终点——应用进程。IP层UDP数据报到达端口2端口3端口1UDP分用请注意，虽然在UDP之间的通信要用到端口号，但由于UDP的通信是无连接的，因此不需要使用套接字来建立连接。UDP基于端口的分用当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交给最后的终点——应用进程。IP层UDP数据报到达端口2端口3端口1UDP分用请注意，虽然在UDP之间的通信要用到端口号，但由于UDP的通信是无连接的，因此不需要使用套接字来建立连接。用户数据报UDP有两个字段：数据字段和首部字段。首部字段有8个字节，由4个字段组成，每个字段都是2个字节。伪首部源端口目的端口长度检验和数据首部UDP长度源IP地址目的IP地址017IP数据报字节44112122222字节发送在前数据首部UDP用户数据报在计算检验和时，临时把12字节的“伪首部”和UDP用户数据报连接在一起。伪首部仅仅是为了计算检验和。伪首部源端口目的端口长度检验和数据首部UDP长度源IP地址目的IP地址017IP数据报字节44112122222字节发送在前数据首部UDP用户数据报计算UDP检验和的例子1001100100010011→153.19→391870000100001101000→8.104→21521010101100000011→171.3→43790000111000001011→14.11→35950000000000010001→170000000000001111→150000010000111111→10870000000000001101→130000000000001111→150000000000000000→0（检验和）0101010001000101→数据(21573)0101001101010100→数据(21332)0100100101001110→数据(18766)0100011100000000→数据(18176)和0（填充）1001011011101101→求和得出的结果0110100100010010→检验和按二进制反码运算求和将得出的结果求反码04112字节伪首部8字节UDP首部7字节数据填充UDP的检验和是把首部和数据部分一起都检验。全0171510871315全0数据数据数据数据数据数据数据全04.3.5TCP发送报文段的时机4.3.1TCP协议概述4.3.4TCP的报文段传输格式4.3.3TCP的可靠传输4.3TCP协议4.3.2TCP连接概念4.3.12TCP计时器4.3.11TCP连接管理模型4.3.10TCP连接管理4.3.6TCP超时重传的时间4.3.9

主动队列管理AQM4.3.8TCP拥塞控制4.3TCP协议4.3.7TCP流量控制

TCP网络层是不可靠的，端到端的UDP协议也仅仅是在网络层的基础上，增加了多路复用/分用功能，它也是不可靠的。互连网络中的很多应用都有可靠且按序交付的要求，例如，邮件传输、文件传输等应用。UDP

没有提供这些功能，要实现可靠的、按序交付等功能，端到端的传输需要使用

TCP

协议。运输层网络层首部TCP数据部分IP数据报4.3.1TCP协议概述TCP是面向连接的运输层协议，在无连接的、不可靠的IP网络服务基础之上提供可靠交付的服务。为此，在IP的数据报服务基础之上，增加了保证可靠性的一系列措施。TCP提供了网络拥塞控制机制，它通过限制TCP发送数据的速度，来防止TCP将过多的数据注入到网络中而引起网络拥塞（发送到网络中的数据，超过了网络所能容纳的数据量）流量控制与拥塞控制的区别4.3.1TCP协议概述TCP是面向字节流的，应用程序将交付的数据按字节进行编号后交付给TCP，每一个TCP连接就是一个字节流，而不是消息流（应用层报文），端到端的TCP之间不会保留消息的边界。TCP协议存在发送时延（不是立即移交给网络层）等待合适的“时机”发送。4.3.1TCP面向字节流概念Program>_212019字节流18|17|16|15|14TCPProgram>_012字节流5|4TCP3TCP连接

13|12|11|H10|9|H8|7|6|H把字节发送缓存加上TCP首部构成TCP报文段发送TCP报文段去除TCP首部从接收缓存读取字节发送方应用程序接收方应用程序4.3.2TCP连接的概念TCP协议的所有功能基础是TCP连接，那么什么是TCP连接呢？一条TCP连接仅有两个端点，即TCP连接是点到点的。IP

地址标识了互连网络中的一台主机，而端口标识了主机中运行的进程TCP的两个端点通过三次握手的方式来建立TCP连接，通过三次握手，通信双方可以相互协商可靠传输所需要的参数。在TCP连接建立的基础上，通信双方开始传输字节流，当所有字节流传输完成，通信双方通过四次挥手来释放TCP连接。4超时重传6可靠传输5无效的重复确认1滑动窗口算法3选择确认4.3.2TCP可靠传输2有效的重复确认滑动窗口算法滑动窗口算法滑动窗口算法是

TCP协议的核心算法，讨论该算法的前提条件是，网络容量无限大，不可能出现拥塞的情况，IP分组的丢失不是因网络拥塞而丢失的，即源端不限量地向网络注入数据，网络层均可以转发（只要IP分组不出错）面向字节流TCP中的“流”(stream)指的是流入或流出进程的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交下来的数据看成仅仅是一连串无结构的字节流。TCP面向流的概念TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。131211H109H768HTCP面向流的概念768H

发送TCP报文段发送方接收方把字节写入发送缓存从接收缓存读取字节应用进程应用进程1230181716151419202145131211H109H加上TCP首部构成TCP报文段TCPTCP字节流字节流H表示TCP报文段的首部x表示序号为x的数据字节TCP连接TCP字节流和窗口....2122232425262728293031323334….....2526272829303132333435363738….....2122232425262728293031323334….<SWS字节流出字节流入LARLBS字节流出字节流入<SWSLARLBS字节流入<SWS字节流出LARLBS....2526272829303132333435363738….字节流出字节流入<SWSLBSLAR有效重复确认接收方TCP对于收到的失序的字节，需要重复发送已经收到的连续字节的确认当收到序号是

24

的字节时，需要发送确认信息ackN=23，告知发送方序号小于

23

字节全部收到，期望收到序号是23的字节当接收方再次收到失序的

26字节时，确认信息ackN=23又被发送一次

有效重复确认Byteseq=22发送方接收方ackN=23Byteseq=25Byteseq=24ackN=23Byteseq=26ackN=23tt收到失序字节需要重复确认已收到的连续字节....2122232425262728293031323334….....2526272829303132333435363738….<RWS字节流出字节流入LBRLAB字节流出字节流入<RWSTCP选择确认接收方能够准确的确认已经收到了哪些不连续的字节块，不只是确认按序收到的最高的字节序号LBRLAB发送选择确认之后的接收滑动窗口接收方收到两个连续的字节块TCP超时重传TCP的超时重传是保证可靠传输的另一个基本要素之一。当发送方将一个TCP报文段发送出去之后，便会启动一个重传计时器。当计时到时还没收到接收方回送的对该TCP报文段的确认信息，发送方将重传这一TCP报文段注意，超时可能是由以下几方面的原因造成的（网络层以下都是不可靠的）1、网络拥塞2、IP分组在传输过程中出现了错误而被丢弃3、IP分组在传输过程中超时错误4、IP分组封装成帧，帧在直连网络中交换时出错，帧被丢弃5、接收方主机失联的情况TCP无效的重复确认Byteseq=22发送方接收方Byteseq=22ackN=23Byteseq=23tt第一次收到ackN=23{第二次收到ackN=23否则丢弃无效的重复确认ackN=23ackN=23第一次发送ackN=23丢弃重复数据第二次发送ackN=23Byteseq=22

无效的重复确认TCP可靠传输TCP

采用滑动窗口、序号、确认和重传机制，在不可靠的网络上的实现了可靠的传输，即端到端的TCP协议，为应用进程提供了无差错、不丢失、不重复且按序的数据传输服务，最终实现了接收方能够准确无误地收到发送方传输的所有数据。TCP面向流的概念

端口…TCP…TCP接收缓存发送缓存报文段…报文段报文段端口发送端接收端向发送缓存写入数据块从接收缓存读取数据块应用进程应用进程

TCP不关心应用进程一次把多长的报文发送到TCP缓存。TCP对连续的字节流进行分段，形成TCP报文段。4.3.3TCP报文段的格式TCP是以TCP报文段来传输有序字节的，每个TCP报文封装的有序字节的数量是不尽相同的，即TCP的发送方和接收方以报文段作为数据传输单位和IP协议类似，TCP报文段的首部格式也由固定20字节和可选的40字节组成，最小的TCP报文段首部长度是20字节，最大的TCP报文段首部长度是60字节注意：1、TCP报文段首部长度必须是4字节的整数倍，2.首部长度不足4字节整数倍时，选项部分需要填充TCP首部20字节的固定首部DestinationPortDataOffsetChecksumSourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFIN32位SYNRSTPSHACKURGOptionsandPaddingUpto40BytesTCP报文段的格式位081624314.3.3TCP报文段的首部格式TCP首部的最小长度是20字节。DataTCP首部20字节固定首部DestinationPortDataOffsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill源端口和目的端口字段——各占2字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。位08162431TCP首部20字节固定首部DestinationPortDataoffsetChecksumOption(variablelength)

SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill序号字段——占4字节。TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。位08162431现有5000个字节的数据。假设报文段的最大数据长度为1000个字节，初始序号为1001。报文段1序号=1001（数据字节序号：1001~2000）报文段2序号=2001（数据字节序号：2001~3000）报文段3序号=3001（数据字节序号：3001~4000）报文段4序号=4001（数据字节序号：4001~5000）报文段5序号=5001（数据字节序号：5001~6000）TCP首部20字节固定首部DestinationPortDataoffsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWIndowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFiII确认号字段——占4字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。位08162431TCP首部20字节固定首部DestinationPortDATaoffsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsvdFINSYNRSTPSHACKURGFill数据偏移（即首部长度）——占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。“数据偏移”的单位是32位字（以4字节为计算单位）。位08162431TCP首部20字节固定首部DestinationPortDATaoffsetChecksumOption(variablelength)SourcePortDestinationPortUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill保留字段——占6位，保留为今后使用，但目前应置为0。位08162431TCP首部20字节固定首部DestinationPortDATaoffsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill紧急URG——当URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。位08162431TCP首部20字节固定首部DestinationPortDataoffsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill确认ACK——只有当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。位08162431TCP首部20字节固定首部SourcePortDataoffsetChecksumOption(variablelength)SourcePortSequenceNumberWindowWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill推送PSH(PuSH)——接收TCP收到PSH=1的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。位08162431TCP首部20字节固定首部DestinationPortdataoffsetWindowOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill复位RST(ReSeT)——当RST=1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。位08162431TCP首部20字节固定首部DestinationPortDataoffsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsvrdFINSYNRSTPSHACKURGFiII同步SYN——同步SYN=1表示这是一个连接请求或连接接受报文。位08162431TCP首部20字节固定首部DestinationPortDataChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill终止FIN(FINish)——用来释放一个连接。FIN=1表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。位08162431TCP首部20字节固定首部DestinationPortDataChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill窗口字段——占2字节，用来让对方设置发送窗口的依据，单位为字节。位08162431TCP首部20字节固定首部DestinationPortDataChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFiII检验和——占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。位08162431在计算检验和时，临时把12字节的“伪首部”和TCP报文段连接在一起。伪首部仅仅是为了计算检验和。TCP首部伪首部数据首部TCP总长度源IP地址目的IP地址06IP数据报字节4411212字节发送在前数据首部TCP报文段TCP首部20字节固定首部DestinationPortDataChecksumOption(variablelengt）SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill紧急指针字段——占16位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。位08162431TCP首部20字节固定首部目的端口DataChecksumOption(variablelength)源端口序号UrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFill选项字段——长度可变。TCP最初只规定了一种选项，即最大报文段长度MSS。MSS告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。”位08162431MSS(MaximumSegmentSize)是TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以，MSS是“TCP报文段长度减去TCP首部长度”。为什么要规定MSS？MSS与接收窗口值没有关系。若选择较小的MSS长度，网络的利用率就降低。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传。这些也都会使开销增大。因此，MSS应尽可能大些，只要在IP层传输时不需要再分片就行。但最佳的MSS是很难确定的。TCP首部20字节固定首部DestinationPortData

offsetChecksumOption(variablelength)SourcePortSequenceNumberUrgentPointerWindowAcknowledgmentNumberRsrvdFINSYNRSTPSHACKURGFiII填充字段——这是为了使整个首部长度是4字节的整数倍。位081624311触发机制3几个需要注意的情况4.3.2TCP发送报文的时机2TCP的发送和接收缓存4.3.4TCP的发送报文段的时机TCP是面向连接和面向字节的，TCP应用进程只要将字节写入（write）TCP连接即完成数据发送任务，而接收方从TCP连接中读（read）字节即完成数据接收任务。在发送方，TCP收集发送应用进程发送的字节并存入TCP的发送缓存，等到收集到足够多的字节之后，发送方的TCP才将这些字节封装成一个TCP报文段发送给接收方的TCP。接收方将TCP报文段的字节存入接收缓存，当接收方的应用进程空闲时便从TCP的接收缓存中读取字节1、TCP的发送与接收缓存Program>_字节流发送缓存TCPProgram>_字节流接收缓存TCPTCP连接

分段|H分段|H分段H把字节写入发送缓存加上TCP首部构成TCP报文段发送TCP报文段从接收缓存读取字节发送方应用程序接收方应用程序触发机制在发送端TCP不关心应用进程一次将多少字节写入TCP缓存（不考虑缓存大小的情况下），它只关心什么时候应该将TCP发送缓存中的字节封装成一个TCP报文段移送给网络层（发送TCP报文段），即TCP发送一个TCP报文段的触发机制是什么（这说明TCP存在推迟发送数据的情况）三种触发机制：第一种触发机制：发送进程明确告诉TCP，应该立即将字节发送出去第二种机制：TCP维持一个阈值变量，即最大报文段长度MSS。第三种机制：TCP维持一个触发发送TCP报文段的计时器，当计时器到时，便将发送缓存中的数据封装成一个TCP报文段移送给网络层，当然，封装的数据不能超过MSS字节TCP的发送和接收缓存TCP双方都维护了一个发送窗口（SWS）和接收窗口（RWS），在不考虑网络容量的情况下，TCP的SWS小于等于对方的RWS。TCP的窗口是TCP缓存中的一块存储空间，TCP缓存的大小是由端系统中的操作系统指定的。TCP的发送缓存与发送窗口TCP的接收缓存与接收窗口在TCP的发送方，发送应用进程将字节写入发送缓存，等待进入发送窗口。发送窗口中保存了已经发送的、还未收到确认的字节，以及可发送还未发送的（等待发送）的字节。那些收到确认的字节被从发送缓存中删除。TCP的收缓存与接收窗口几个需要注意的情况1、在不考虑网络容量的情况下，发送窗口的大小受对方的接收窗口大小的限制2、接收方对于不连续字节块的处理，TCP没有给出明确的规定，为了避免不必要的重传，操作系统在实现TCP协议时，将这些不连续的字节块暂时存放在接收窗口中，待缺失字节到来之后再一并递交给应用进程3、TCP要求实现累积确认4、如果接收方收到一连串的、具有最大MSS的TCP报文段，则每间隔一个TCP报文段就需要发送一个确认报文。触发机制在发送端TCP不关心应用进程一次将多少字节写入TCP缓存（不考虑缓存大小的情况下），它只关心什么时候应该将TCP发送缓存中的字节封装成一个TCP报文段移送给网络层（发送TCP报文段），即TCP发送一个TCP报文段的触发机制是什么（这说明TCP存在推迟发送数据的情况）三种触发机制：第一种触发机制：发送进程明确告诉TCP，应该立即将字节发送出去第二种机制：TCP维持一个阈值变量，即最大报文段长度MSS。第三种机制：TCP维持一个触发发送TCP报文段的计时器，当计时器到时，便将发送缓存中的数据封装成一个TCP报文段移送给网络层，当然，封装的数据不能超过MSS字节3PTO计时器的管理1测量RTT4.3.5TCP超时重传2PTO的计算概述超时重传RTO（RetransmissionTimeOut）在RFC6298中被定义，它是TCP可靠传输的基本要素之一。发送方对每一个发送出去的TCP报文段，均设置一个RTO，如果在RTO时间内，发送方没有收到接收方对该TCP报文段的确认，发送方必须重传这个TCP报文段。显然，RTO时间的选择非常重要，如果RTO设置的太小，TCP报文段还未到达接收方，发送方又重传了TCP报文段。如果RTO设置太大，接收方需要等待较长时间才能收到重传的、已经丢失的TCP报文段。

1、测量RTT每发送一个TCP报文，TCP都会计算RTT。如果在同一个TCP连接上，同一时刻发送了多个TCP报文段，则只计算其中一个RTT，那些TCP报文段均使用这一个RTT。对于双方都支持TCP时间戳选项的主机而言，RTT的测量较为容易，发送方将发送TCP报文段的时间写入时间戳选项中，接收方在发送的确认TCP报文段中回送该时间戳，发送方通过收到确认报文的时间与确认报文中回送的时间戳之差，就能计算得到RTT

2、计算RTO如前所述，TCP初始化超时重传时间是1秒，为了计算当前需要使用的RTO，TCP需要维护两个状态变量：SRTT（smoothedround-triptime，平滑往返时间）和RTTVAR（round-triptimevariation，往返时延偏差）。另外，假设时钟粒度是

G秒。当第一次测得的RTT是

R，TCP进行如下初始化：SRTT=RRTTVAR=R/2RTO=SRTT＋max(G,K×RTTVAR)加权平均往返时间TCP保留了RTT的一个加权平均往返时间RTTS（这又称为平滑的往返时间）。第一次测量到RTT样本时，RTTS

值就取为所测量到的RTT样本值。以后每测量到一个新的RTT样本，就按下式重新计算一次RTTS：式中，0

1。若

很接近于零，表示RTT值更新较慢。若选择

接近于1，则表示RTT值更新较快。RFC6298推荐的

值为1/8，即0.125。新的RTTS

(1

)

(旧的RTTS)+

(新的RTT样本)(5-4)超时重传时间RTORTO(RetransmissionTime-Out)应略大于上面得出的加权平均往返时间RTTS。RFC6298建议使用下式计算RTO：RTTD

是RTT的偏差的加权平均值。RFC6298建议这样计算RTTD

。第一次测量时，RTTD值取为测量到的RTT样本值的一半。在以后的测量中，则使用下式计算加权平均的RTTD

：

是个小于1的系数，其推荐值是1/4，即0.25。RTO=RTTS+4

RTTD(5-5)新的RTTD

=(1

)

(旧的RTTD)+

RTTS

新的RTT样本

(5-6)往返时延的方差很大由于TCP的下层是一个互联网环境，IP数据报所选择的路由变化很大。因而运输层的往返时间(RTT)的方差也很大。时间数据链路层运输层T1T2T3往返时间的概率分布3糊涂窗口综合证1概述4.3.6TCP流量控制2流量控制方法概述由于TCP是全双工的，因此在一个TCP连接的两个端点A和B均会为该连接设置接收缓存。应用进程并不会立即读取刚刚写入接收缓存中的数据，或许会等待一段时间再去读取缓存中的数据。如果应用进程读取数据的速度较慢，而发送的数据多且快，这些数据最终会导致接收缓存溢出。为了避免上述情况的发生，TCP为应用进程提供了流量控制服务（flowcontrolservice），该服务为TCP的两个端点提供速度匹配服务，即发送方发送数据的速率与接收方应用进程读取速率相匹配，也就是发送方发送数据的速率是受接收方应用进程读取数据的速率所限制4.3.5TCP超时重传时间重传机制是TCP中最重要和最复杂的问题之一。TCP每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到但还没有收到确认，就要重传这一报文段。重传时间的选择是TCP最复杂的问题之一。往返时延的方差很大由于TCP的下层是一个互联网环境，IP数据报所选择的路由变化很大。因而运输层的往返时间(RTT)的方差也很大。时间数据链路层运输层T1T2T3往返时间的概率分布流量控制方法TCP的发送方以接收方可用的接收缓存大小，来限制自己发送数据的量，从而实现端到端的流量控制。假设B为TCP设置的接收缓存的大小是RcvBuffer，定义以下两个变量：LastByteRead：B的应用进程已经读取的最后一个字节的编号。LastByteRcvd：B从网络中接收并已经写入到接收缓存的数据流中的最后一个字节的编号。显然，为了保证B的接收缓存不会溢出，以下式子必须成立：

LastByteRcvd-LastByteRead≤RcvBufferB的接收窗口就是B可用的接收缓存，因此：rwnd=RcvBuffer一[LastByteRcvd-LastByteRead]TCP超时重传时间设置如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。加权平均往返时间TCP保留了RTT的一个加权平均往返时间RTTS（这又称为平滑的往返时间）。第一次测量到RTT样本时，RTTS

值就取为所测量到的RTT样本值。以后每测量到一个新的RTT样本，就按下式重新计算一次RTTS：式中，0

1。若

很接近于零，表示RTT值更新较慢。若选择

接近于1，则表示RTT值更新较快。RFC6298推荐的

值为1/8，即0.125。新的RTTS

(1

)

(旧的RTTS)+

(新的RTT样本)(5-4)超时重传时间RTORTO(RetransmissionTime-Out)应略大于上面得出的加权平均往返时间RTTS。RFC6298建议使用下式计算RTO：RTTD

是RTT的偏差的加权平均值。RFC6298建议这样计算RTTD

。第一次测量时，RTTD值取为测量到的RTT样本值的一半。在以后的测量中，则使用下式计算加权平均的RTTD

：

是个小于1的系数，其推荐值是1/4，即0.25。RTO=RTTS+4

RTTD(5-5)新的RTTD

=(1

)

(旧的RTTD)+

RTTS

新的RTT样本

(5-6)往返时间(RTT)的测量相当复杂TCP报文段1没有收到确认。重传（即报文段2）后，收到了确认报文段ACK。如何判定此确认报文段是对原来的报文段1的确认，还是对重传的报文段2的确认？往返时间RTT?发送一个TCP报文段超时重传TCP报文段收到ACK时间12往返时间RTT?是对哪一个报文段的确认？利用滑动窗口实现流量控制一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。流量控制

(flowcontrol)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。利用滑动窗口机制可以很方便地在TCP连接上实现流量控制。利用可变窗口进行流量控制举例A向B发送数据。在连接建立时，B告诉A：“我的接收窗口rwnd=400（字节）”。seq=0,DATAseq=200,DATAseq=400,DATAseq=300DATAseq=100,DATAseq=200,DATAseq=500,DATAACK=1,ack=200,rwnd=300ACK=1,ack=600,rwnd=0ACK=1,ack=500,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为止的数据都收到了）丢失！可能发生死锁B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwnd=400的报文段。但这个报文段在传送过程中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。为了解决这个问题，TCP为每一个连接设有一个持续计时器(persistencetimer)。持续计时器为了解决这个问题，TCP为每一个连接设有一个持续计时器

(persistencetimer)。只要TCP连接的一方收到对方的零窗口通知，就启动该持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。若窗口不是零，则死锁的僵局就可以打破了。必须考虑传输效率可以用不同的机制来控制TCP报文段的发送时机:第一种机制是TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去。第二种机制是由发送方的应用进程指明要求发送报文段，即TCP支持的推送

(push)操作。第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。糊涂窗口综合症糊涂窗口综合症：每次仅发送一个字节或很少几个字节的数据时