【计算机网络】第五章 运输层

5.1 运输层的概述

• 之前介绍的计算机网络体系结构中的物理层、数据链路层以及网络层，它们共同解决了将主机通过异构网络互连起来所面临的问题，实现了额主机到主机的通信。
• 但实际上在计算机网络中进行通信的真正实体使位于通信两端主机中的进程。
• 如何为运行在不同主机的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。
  
  运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑，所采用的路由选择协议等），它使应用进程看见的就好像是两个运输层实体有一条端到端的逻辑通信信道。
  根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP，这两种协议就是本章要讨论的主要内容。
  小结：
  

5.2 运输层端口号、复用与分用的改变

5.2.1 端口号

• 运行在计算机上的进程使用进程标识符PID来标志
• 因特网上的计算机并不是使用同意的操作系统，不同的操作系统（Linux、Windows、Mac OS）又使用不同格式的进程标识符
• 为了使运行不同操作系统的计算机应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识
• TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程
  • 端口号使用16比特表示，取值范围0~65535
    • 熟知端口号：0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用程序，例如：FTP使用21/20，HTTP使用80，DNS使用53.
    • 登记端口号：1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复，例如：Microsoft RDP微软远程桌面使用的端口使3389
    • 短暂端口号：49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户端进程以后使用
  • 端口号只具有本地意义，即端口号知识为了标识本计算机应用层的各进程，在因特网中，不同计算机中的相同端口是没有联系的。

5.2.2 复用与分用

• 发送方的复用和接收方的分用：
  如图所示，这是收发双方的应用进程。发送方的某些应用进程所发送的不同应用报文，在运输层使用UDP协议进行封装，这称为UDP复用；而另一些应用进程所发送的不同的应用报文，在运输层使用TCP协议进行封装，这称为TCP复用。
  运输层通过端口号来区分不同的应用进程，不管使用运输层的UDP协议封装成的UDP用户数据报，还是使用运输层的TCP协议封装成的TCP报文段，在网络层都要使用IP协议封装成IP数据报，这成为IP复用。IP数据报首部中协议字段的值来表明IP数据报的数据载荷部分封装的时何种协议数据单元。取值为6，表示封装的是TCP报文段；取值为17，表示封装的是UDP用户数据报；
  接收方的网络层收到IP数据报后进行IP分用，若IP数据报首部中协议字段的值为17，则把IP数据报的数据载荷部分所封装的UDP用户数据报上交运输层的UDP；若协议字段值为6，则把IP数据报的数据载荷部分所封装的TCP报文段上交运输层的TCP。运输层对UDP用户数据段进行UDP分用，对TCP报文段进行TCP分用。就是根据端口号将他们交给上层对应的应用进程。
  
  YCP/IP体系的应用层常用协议所使用的运输层熟知端口号
  
  举例：
  在用户PC中使用网页浏览器来访问Web服务器的内容，在网页浏览器的地址栏中输入Web服务器的域名，用户PC中的DNS客户端进程会发送一个DNC查询请求报文，其内容为：“域名www.porttest.com所对应的IP地址是什么”，DNS查询请求报文需要使用运输层的UDP协议封装成UDP用户数据报，其首部中的源端口字段的值在短暂端口号中挑选一个未被占用的，用来表示DNS客户端进程。目的端口号设置为53，这是DNS服务器端进程所使用的熟知端口号。
  之后将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器。DNS服务器端收到该数据报后，从中解封出UDP用户数据报。UDP首部中的目的端口号为53，这表明应该将UDP用户数据报的数据载荷部分，也就是DNS查询请求报文交付给服务器中的DNS服务器端进程。DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址。之后会给用户PC发送DNS响应报文，其内容为：“域名www.porttest.com所对应的IP地址是192.168.0.3”。
  用户PC收到该数据报，从中解封出UDP用户数据报，通过端口号交付给用户PC中的DNS客户端进程。DNS客户端进程解析DNS响应报文的内容，就可知道自己之前请求的Web服务器的域名所对应的IP地址为…。
  然后向Web服务器发送HTTP请求报文了。

5.3 UDP与TCP的对比

• UDP和TCP是TCP/IP体系结构运输层的两个重要协议
  
• 应用层的协议需要使用到TCP提供的服务或UDP提供的服务
• 用户数据报协议UDP（User Datagram Protocol）和传输控制协议TCP（Transmission Control Protocol）
  使用UDP协议的通信双方，可以随时发送数据。
  使用TCP协议的通信双方，在数据传输之前，必须使用“三报文握手”来建立TCP连接。TCP建立连接成功后才能进行数据传输。数据传输结束后，必须使用“四报文挥手”来释放TCP连接。
• 三报文握手和四报文挥手属于TCP的连接管理，其过程比较复杂，后续介绍
• 这里所谓的连接是指逻辑连接关系，而不是物理连接
• 综上，UDP是无连接的，TCP是面向连接的
  
• UDP支持单播、多播、广播，TCP仅支持单播
  
  对比两个协议对应用报文的处理：
• UDP会直接给应用层报文添加一个UDP首部，使之称为UDP用户数据报，然后进行发送；接收方的UDP收到该UDP用户数据报后，去掉UDP首部，也就是对UDP对应用程序交下来的报文既不拆分也不合并，而是保留这些报文的边界，换句话说，UDP是面向应用报文的
• 发送方的TCP会把应用进程交付下来的数据块，仅仅看作是一连串的、无结构的字节流。TCP并不知道这些待传送的字节流的含义，仅将他们编号，并存储在自己的发送缓存中，TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送；接收方的TCP，一方面从所接收到的TCP报文段中，取出数据载荷部分并存储在接受缓存中，一方面将接受缓存的一些字节交付给应用进程，TCP不保证接收方应用进程，所受到的数据块与发送方的应用进程所发出的数据块具有对应大小的关系—不保证一次性传完，所以要求应用进程有处理这种乱序、多次传输后还能拼接完整的能力
  也就是说，TCP是面向字节流的（这正是TCP实现可靠传输、流量控制以及拥塞控制的基础）

TCP/IP体系结构的网际层，向其上层提供的是无连接不可靠的传输服务。

• 当运输层使用UDP时，向其上层提供的也是无连接不可靠的传输服务，发送方给接收方发送UDP用户数据报，若传输过程中用户数据受到干扰而产生误码，接收方UDP可以通过该数据报首部中的校验和字段的值，检查出产生误码的情况，如果误码或者在路上被路由器丢弃，则仅仅是丢弃该数据报，其他什么也不做
• IP数据报在传输过程中出现丢失或误码的问题，但使用TCP协议就不会出现误码，丢失，乱序以及重复传输等传输差错。
  
  对比UDP用户数据报的首部与TCP报文段的首部
• 一个UDP用户数据报由首部和数据载荷两部分构成。其首部格式如图所示，UDP仅仅在网际层的基础上，添加了区分应用进程的端口。
• 一个TCP报文段由首部和数据载荷两部分构成，其首部格式如图所示，这比UDP用户数据报的首部复杂得多，因为TCP要实现可靠传输、流量控制，、拥塞控制等服务
  
  小结：
  

5.4 TCP的流量控制

• 一般来说，我们总是希望数据传输得更快一些。
  • 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。
• 所谓流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
• 利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
  举例说明：
  
  已发送的字节数据若重传计时器超市，他们会被重传。
  

零窗口探测报文也有重传计时器。

5.5 TCP的拥塞控制

• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞（congestion）
  • 在计算机网络中的链路容量（即带块）、交换节点中的缓存和处理机等，都是网络的资源。
• 若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
  
• TCP的四种拥塞控制算法：慢开始、拥塞避免、快重传、快恢复。
  • 慢开始算法：拥塞窗口值按指数增长（），它是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢；
  • 拥塞避免算法：拥塞窗口值只能线性加1，并非完全避免拥塞，而是指拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
  • 快恢复算法：
  • 快重传算法：
    下面介绍这四种算法的基本原理，假定如下条件：
    （1）数据是单方向传送的，而另一个方向只传送确认。
    （2）接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定
    （3）以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。
    
    
    
    
• 慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法（TCP Tahoe版本）
• 1990年又增加了两个新的拥塞控制算法（改进TCP的性能），这就是快重传和快恢复（TCP Reno版本）
  • 有时，个别报文段会在网络中丢失，但实际上网络并未发送拥塞。
    • 这将导致发送方超时重传，并误认为网络发生了拥塞；
    • 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率。
      
      解决办法：使用快重传算法
  • 采用快重传算法可以让发送方尽早知道发送了个别报文段的丢失。
  • 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
    • 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认；
    • 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
    • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传
    • 对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1）.
  • 发送方一旦收到3个重复确认，就知道现在知识丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法；
    • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法。
    • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3.
      • 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络；
      • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
      • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口在扩大些

习题：

5.6 TCP超时重传时间的选择

• 超时重传时间的选择是TCP最复杂的问题之一，原因如下：
  
  

解决办法：超时重传时间RTO应略大于往返时间

但也存在以下问题：

所以

• 不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO。
• 利用每次测量得到的RTT样本，计算加权平均往返时间RTTs(又称为平滑的往返时间)。
  
• RFC6298建议使用下式计算超时重传时间RTO

• 发生超时重传后，往返时间RTT的测量就比较复杂
  
• 针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法：在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RRT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。
  • 这又引起了新的问题。设想出现这样的情况：报文段的时延突然增大了很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这就导致报文段反复被重传。
• 因此，要对Karn算法进行修正。方法是：报文段每重传一次，九八超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO的2倍。
  

5.7 TCP可靠传输的实现

• TCP基于以字节为单位的滑动窗口来实现可靠传输
• 
  在这样的系统中，假设发送方收到二了一个来自接收方的确认报文段，如下：
  
  表示在报文段的首部中的窗口字段的值为20，也就是接收方表明自己的接收窗口的尺寸为20字节，确认号字段的值为31，这表明接收方希望收到下一个数据的序号是31，而序号30为止的数据已经全部正确接收了。因此，发送方根据这两个字段的值构造自己的发送窗口（假定网络中不存在拥塞问题），如下图
  
  
  
  
  
  
  
• 虽然发送方的发送窗口时根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。
  • 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸
• 对于不按序到达的数据应如何处理，TCP并无明确规定
  • 如果接收方不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利。因为发送方会重复传送较多的数据。
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• TCP要求接收方必须有累计确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。
  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源。
    TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122].
  • 捎带确认实际上并不会经常发生，因为大多数应用程序很少同时在两个方向上发送数据
• TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚时是哪一方的窗口。

习题：

5.8 TCP的运输连接管理

5.8.1 TCP的连接建立

• TCP是面向连接的协议，它基于运输连接来传送TCP报文段

• TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程

• TCP运输连接有以下三个阶段：

  • （1）建立TCP连接
  • （2）数据传输
  • （3）释放TCP连接
    

• TCP的连接建立要解决以下三个问题：

  • 使TCP双方能够确知对方的存在
  • 使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
  • 使TCP双方能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

• TCP使用“三报文握手”建立连接
  一开始的TCP进程处于关闭状态
  （1）当要开始建立连接前，TCP服务器会创建一个传输控制块，如下，然后进入监听状态
  TCP客户端也会创建一个传输控制块，如下，然后发送TCP连接请求报文段并进入同步已发送状态
  
  TCP连接请求报文段首部中的同步位SYN被设置为1，表示这是一个TCP连接请求报文段。序号字段seq被设置位一个初始值x作为TCP进程所选择的初始序号
  注意：==TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号
  （2）TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，，并进入同步已接收状态。（该报文段首部中的同步位SYN和确认位ACK都设置为1，序号字段被设置为一个初始值y，确认号字段ack的值被设置为x+1–这是对TCP客户进程所选择的初始序号的确认）
  （3）TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态。TCP服务器进程收到该确认报文段后也进入连接已建立状态
  现在，可以基于已建立的TCP连接，进行可靠的数据传输了
  
  针对是否多余？看图理解
  
  总结：
  
  习题：
  
  

5.8.2 TCP的连接释放

• TCP通过“四报文挥手”来释放连接
  （1）假设TCP客户端进程的应用进程通知其主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态。（该报文段首部中的终止位FIN和确认位ACK的值都被设置为1，不仅表明这是一个TCP连接释放报文段，同时对之前收到的报文段进行确认，且seq为u，ack为v）
  （2）TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段，并进入关闭等待状态。（该报文段首部中的确认位ACK的值被设置为1，seq为之前最后一个+1，ack是确认号为TCP连接释放报文段的确认，所以u+1）。这时TCP服务器进程这时应通知高层应用进程：TCP客户端要断开与自己的连接。这是TCP连接属于半关闭状态–TCP客户端没有数据要发送了。但TCP服务器进程仍然可以发送数据到TCP客户进程
  TCP客户进程收到TCP确认报文段后进入终止等待2状态，等待服务器进程发出的TCP连接释放报文段
  （3）若TCP服务器进程以及没有数据要发送了，应用进程就通知其TCP服务器进程释放连接。TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。（该报文段首部中的中执委FIN和确认位ACK都被设置为1，ack还为u+1，seq为w）
  （4）TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态。（该报文段首部中的确认位ACK的值被设置为1，seq=u+1，ack=w+1）
  TCP服务器进程收到报文段后就进入关闭状态，而TCP客户进程要经过2MSL（最长报文段寿命，RFC793建议为2分钟）后才能进去关闭状态。
  
  为什么TCP客户进程需要经过2MSL才进入关闭状态不能马上进入？
  
  （1）可以确保TCP服务端收到最后一个TCP确认报文段而进入关闭状态。
  （2）等待2*MSL时间后，可以使本次连接持续时间内所产生的所有报文段都从网络上消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段。

• TCP保活计时器的作用
  

• TCP服务器进程没收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时）

• 若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时候，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒发送一次，若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户端所在主机出现故障，接着就关闭这个连接

5.9 TCP报文段的首部格式

• 为了实现可靠传输，TCP采用了面向字节流的方式。
• 但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。
  • 一个TCP报文段由首部和数据载荷两部分构成
  • TCP的全部功能都体现在它首部中个字段的作用
    
    TCP报文段的首部格式：
    
• 源端口：占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程。
• 目的端口：占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程
  与TCP实现可靠传输的序号字段：
• 序号：占32比特，取值范围[0,2的32次方-1]，序号增加到最后一个后，下一个序号就又回到0
  
• 确认号：占32比特，取值范围[0,2的32次方-1]，确认号增加到最后一个后，下一个确认号就又回到0.
  
• 确认标志位ACK：取值为1时确认号字段才有效噢噢噢噢；取值为0时确认号字段无效。
  
• 数据偏移：占4比特，并以4字节为单位。
  

• 保留：占6比特，保留为今后使用，但目前应置为0.
• 窗口：占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。
  
• 校验和：占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。在计算校验和时，要在TCP报文段的前面加上12字节的伪首部
• 同步标志位SYN：在TCP连接建立时用来同步序号。
  
• 终止标志位FIN：用来释放TCP连接。
  
• 复位标志位RST：用来复位TCP连接。
• 
• 推送标志位PSH：接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。
• 紧急标志位URG：取值为1时紧急指针字段有效；取值为0时紧急指针字段无效。
• 紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度。
  
• 选项：
  • ==最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度。
  • 窗口扩大选项：为了扩大窗口（提高吞吐率）。
  • 时间戳选项：
    • 用来计算往返时间RTT
    • 用于处理序号超范围的情况，又称为防止序号绕回PAWS。
  • 选择确认选项：用来实现确认功能
• 填充：由于选项的长度可变，因此使用填充来确保报文段首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为单位的）