第五章：传输层

5.1 运输层协议概述

理解运输层的功能，与网络层通信有何区别

运输层的功能

• 屏蔽作用：

  运输层向高层用户屏蔽了下面网络核心细节（如网络拓扑、所采用的路由协议等），使使用进程看见的就好像是两个运输实体之间有一条端到端的逻辑通信信道。

• 可靠信道与不可靠信道

  运输层通过全双工可靠信道，使用面向连接的协议，如 TCP。
  运输层使用不可靠信道，无连接的协议，如 UDP。

运输层的两个主要协议

1. 用户数据报协议 UDP（User Datagram Protocol）
2. 传输控制协议 TCP（Transmission Control Protocol）

运输层与网络层的区别

运输层提供应用进程之间的逻辑通信；
网络层为主机之间的通信提供服务；
运输层为应用进程之间的通信提供服务；

UDP与TCP的相同之处与不同之处

• TCP 传送的数据单位协议是 TCP报文段（segment）
• UDP 传送的数据单位 协议是 UDP 报文或者用户数据报；

• UDP

  面向无连接的；
  收到 UDP 报文后，不需要给出任何确认；
  不提供可靠交付，尽最大努力交付，但是是一种有效的工作方式。

• TCP

  提供可靠的、面向连接的运算服务；
  不提供广播或者多播服务；
  开销较多；

• 使用 UDP 和 TCP 的典序应用和应用层协议

【图】协议

软件端口和硬件端口

• 软件端口
  协议栈层间的抽象的协议端口；
  是应用层的各种协议进程与运输实体进行层间交互的地点；
  不同系统实现端口的方法可以不同；
• 硬件端口
  不同硬件设备进行交互的接口；

TCP / IP 运输层端口的标志

端口用一个 16位端口号进行标志，允许有 65535 个不同的端口号；
端口号只有本地意义，只是为了标志本计算机应用层中的各层中的进程；
在互联网中，不同计算机的相同端口号没有联系；

• 在计算机中需要进行相互通信，不仅必须知道对方端口号，而且还要知道对方 IP 地址。

【图、常用的熟知端口】

5.2 用户数据协议 UDP

5.2.1 UDP 概述

UDP 在 IP 数据报服务至上增加了一些协议功能：

1. 复用和分用；
2. 差错检验；

UDP 的主要特点

1. 无连接
   发送数据不需要建立连接
2. 使用尽最大努力交付
   即不保证可靠交付
3. 面向报文
   UDP 一次传送和交付一个完整的报文；
4. 没用拥塞控制
   网络出现的拥塞不会使源主机的发送速率降低。很适合多媒体通信的要求。
5. 支持一对一、一对多、多对一、多对多的交互通信
6. 首部开销小，只有 8 个字节；

UDP 通信的特点：简单方便，但不可靠；

【图、UDP 是面向报文的】

UDP 通信和端口的关系

复用：将 UDP 用户数据报组装成不同的 IP 数据报，发送到互联网。
分用：根据 UDP 用户数据报首部中的目的端口号，将数据报文分别传送到相应的端口，以便应用进程从端口读取数据；

【图、UDP 通信和端口号的关系】

5.2.2 UDP 首部格式

传输控制协议 TCP 概述

5.3.1 TCP 最主要的特点

TCP 是面向连接的运输层协议，无连接的，不可靠的 IP 网络服务基础之上提供可靠交付的服务。增加了保证可靠性的一系列措施。

• TCP 是面向连接的运输层协议；
• 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）；
• TCP 提供可靠交付；
• TCP 提供全双工通信；
• 面向字节流
  1. TCP 中的流指的是流入或流出程序的字节流；
  2. 面向字节流：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成是一串无结构的字节流。

TCP 不保证接收方应用程序接收到的数据块和发送方应用程序发出的数据块具有对应大小的关系；
但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样；

【TCP 面向流的概念】

• TCP 不关心应用进程一次把多长的报文发送到 TCP 缓存；
• TCP 根据对方给出的窗口值和当前网络拥塞程度来决定一个报文段应包含多少个字节，形成 TCP 报文段。

5.3.2 TCP 的连接

TCP 连接的端点：套接字 (socket) 或插口。
TCP 连接就是由协议软件所提供的一种抽象。
TCP 连接的端点是抽象的套接字，即（IP 地址：端口号）。
同一个 IP 地址可以有多个不同的 TCP 连接。
同一个端口号也可以出现在多个不同的 TCP 连接中。

【图、套接字 (socket)】

5.4 可靠传输工作原理

• 传输信道不产生差错。
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

在理想传输条件下，不需要采取任何措施就能够实现可靠传输。但实际网络都不具备理想传输条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

5.4.1 停止等待协议

无差错情况

每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
全双工通信的双方既是发送方也是接收方。
假设仅考虑 A 发送数据，而 B 接收数据并发送确认。因此 A 叫做发送方，而 B 叫做接收方。

【图、无差错情况】

出现差错

• 分组出错
  B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）。
• 分组丢失
  M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。
  在这两种情况下，B 都不会发送任何信息。

超时重传

A 为每一个已发送的分组设置一个超时计时器。
A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。
若 A 在超时计时器规定时间内没有收到 B 的确认，就认为分组错误或丢失，就重发该分组。

确认丢失和确认迟到

• 确认丢失

1. 若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内将不会收到确认，因此 A 在超时计时器到期后重传 M1。
2. 假定 B 正确收到了 A 重传的分组 M1。这时 B 应采取两个行动：
   (1) 丢弃这个重复的分组 M1，不向上层交付。
   (2) 向 A 发送确认。

• 确认迟到
  B 对分组 M1 的确认迟到了，因此 A 在超时计时器到期后重传 M1。
  B 会收到重复的 M1，丢弃重复的 M1，并重传确认分组。
  A 会收到重复的确认。对重复的确认的处理：丢弃。

信道利用率太低

提高传输效率：流水线传输

流水线传输：在收到确认之前，发送方连续发出多个分组。
由于信道上一直有数据不间断地传送，
流水线传输可获得很高的信道利用率。
连续 ARQ 协议和滑动窗口协议采用流水线传输方式。

5.4.2 连续 ARQ 协议

• 发送窗口：
  发送方维持一个发送窗口，位于发送窗口内的分组都可被连续发送出去，而不需要等待对方的确认。
• 发送窗口滑动：
  发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
• 累积确认：
  接收方对按序到达的最后一个分组发送确认，表示：到这个分组为止的所有分组都已正确收到了。

累计确认

优点：容易实现，即使确认丢失也不必重传
缺点：不能向发送方反映出接收方已经正确收到的所有分组信息；

连续 ARQ 协议采用 Go-back-N（回退N）。
Go-back-N（回退N）：表示需要再退回来重传已发送过的 N 个分组。
当通信线路质量不好时，连续 ARQ 协议会带来负面的影响。

5.5 TCP 报文段的首部格式

【图、TCP 报文段的首部格式】

5.6 TCP 可靠传输的实现

以字节为单位的滑动窗口

TCP 使用流水线传输和滑动窗口协议实现高效、可靠的传输。
TCP 的滑动窗口是以字节为单位的。
发送方 A 和接收方 B 分别维持一个发送窗口和一个接收窗口。
发送窗口：在没有收到确认的情况下，发送方可以连续把窗口内的数据全部发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
接收窗口：只允许接收落入窗口内的数据。

需要强调三点

第一，发送窗口是根据接收窗口设置的，但在同一时刻，发送窗口并不总是和接收窗口一样大（因为有一定的时间滞后）。
第二，TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
第三，TCP 要求接收方必须有累积确认的功能，以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，捎带确认实际上并不经常发生。

超时重传时间的选择

选择确认 SACK

TCP 的流量控制

5.7.1 利用滑动窗口实现流量控制

流量控制 (flow control) ：让发送方的发送速率不要太快，使接收方来得及接收。
利用滑动窗口机制可以很方便地在 TCP 连接上实现对发送方的流量控制。

【图1、利用可变窗口进行流量控制举例】

【图2、利用可变窗口进行流量控制举例】

5.7.2 TCP 的传输效率

5.8 TCP 的拥塞控制

5.8.1 拥塞控制的一般原理

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。这种现象称为拥塞 (congestion)。
最坏结果：系统崩溃。

拥塞控制

防止过多的数据注入到网络中，避免网络中的路由器或链路过载。
是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。

流量控制

抑制发送端发送数据的速率，以使接收端来得及接收。
点对点通信量的控制，是个端到端的问题。

拥塞控制的一般原理

拥塞控制的前提：网络能够承受现有的网络负荷。
实践证明，拥塞控制是很难设计的，因为它是一个动态问题。
分组的丢失是网络发生拥塞的征兆，而不是原因。
在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

开环控制

在设计网络时，事先考虑周全，力求工作时不发生拥塞。
思路：力争避免发生拥塞。
但一旦整个系统运行起来，就不再中途进行改正了。

闭环控制

基于反馈环路的概念。
根据网络当前运行状态采取相应控制措施。
思路：在发生拥塞后，采取措施进行控制，消除拥塞。

闭环控制措施

1. 监测
   监测网络系统，检测拥塞在何时、何处发生。
2. 传送
   将拥塞发生的信息传送到可采取行动的地方。
3. 调整
   调整网络系统的运行以解决出现的问题。

5.8.2 TCP 的拥塞控制方法

TCP 采用基于滑动窗口的方法进行拥塞控制，属于闭环控制方法。
TCP 发送方维持一个拥塞窗口 cwnd (Congestion Window)
拥塞窗口的大小取决于网络的拥塞程度，并且是动态变化的。
发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
发送窗口大小不仅取决于接收方窗口，还取决于网络的拥塞状况。
真正的发送窗口值：

真正的发送窗口值 = Min (接收方通知的窗口值，拥塞窗口值)

TCP 拥塞控制算法

四种拥塞控制算法（ RFC 5681）：

慢开始 (slow-start)

目的：探测网络的负载能力或拥塞程度。
算法：由小到大逐渐增大注入到网络中的数据字节，即：由小到大逐渐增大拥塞窗口数值。

拥塞窗口 cwnd

初始值：2 种设置方法。
1 至 2 个最大报文段 MSS （旧标准）
2 至 4 个最大报文段 MSS（RFC 5681）

慢开始门限 ssthresh

防止拥塞窗口增长过大引起网络拥塞。
拥塞窗口 cwnd 增大：在每收到一个对新的报文段的确认，就把拥塞窗口增加最多一个发送方的最大报文段 SMSS (Sender Maximum Segment Size) 的数值。

防止拥塞窗口 cwnd 增长过大引起网络拥塞。
用法：
当 cwnd < ssthresh 时，使用慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法，改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。

拥塞避免 (congestion avoidance)

目的：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。
拥塞窗口 cwnd 增大：每经过一个往返时间 RTT（不管在此期间收到了多少确认），发送方的拥塞窗口 cwnd = cwnd + 1。
具有加法增大 AI (Additive Increase) 特点：使拥塞窗口 cwnd 按线性规律缓慢增长。

拥塞避免并非完全避免拥塞，而是让拥塞窗口增长得缓慢些，使网络不容易出现拥塞。

当网络出现拥塞时

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）：
ssthresh = max (cwnd/2，2)
cwnd = 1
执行慢开始算法
目的：迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

【图、慢开始和拥塞避免算法的实现举例】

快重传 (fast retransmit)

目的：让发送方尽早知道发生了个别报文段的丢失。
发送方只要连续收到三个重复的确认，就立即进行重传（即“快重传”），这样就不会出现超时。
使用快重传可以使整个网络的吞吐量提高约 20%。
快重传算法要求接收方立即发送确认，即使收到了失序的报文段，也要立即发出对已收到的报文段的重复确认。

快重传并非取消重传计时器，而是在某些情况下可以更早地（更快地）重传丢失的报文段。

快恢复 (fast recovery)

当发送端收到连续三个重复的确认时，不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：
慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
乘法减小 MD (Multiplicative Decrease) 拥塞窗口。
新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
执行拥塞避免算法，使拥塞窗口缓慢地线性增大（加法增大 AI）

二者合在一起就是所谓的 AIMD 算法，使 TCP 性能有明显改进

5.8.3 主动队列管理 AQM

TCP 拥塞控制和网络层采取的策略有密切联系。
例如：
若路由器对某些分组的处理时间特别长，就可能引起发送方 TCP 超时，对这些报文段进行重传。
重传会使 TCP 连接的发送端认为在网络中发生了拥塞，但实际上网络并没有发生拥塞。
对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。

5.9 TCP 的运输连接管理

5.9.1 TCP 的连接建立

TCP 是面向连接的协议。
TCP 连接有三个阶段：
连接建立
数据传送
连接释放
TCP 的连接管理就是使 TCP 连接的建立和释放都能正常地进行。

TCP 建立连接的过程叫做握手。
采用三报文握手：在客户和服务器之间交换三个 TCP 报文段，以防止已失效的连接请求报文段突然又传送到了，因而产生 TCP 连接建立错误。

【图1】

【图2】

【图3】

5.9.2 TCP 的连接释放

TCP 连接释放过程比较复杂。
数据传输结束后，通信的双方都可释放连接。
TCP 连接释放过程是四报文握手。

必须等待 2MSL 的时间

第一，保证发送的最后一个 ACK 报文段能够到达 B。
第二，防止“已失效的连接请求报文段”出现在本连接中。

5.9.3 TCP 的有限状态机

可靠传输的原理

可靠传输的实现；

滑动窗口

超时重传

流量控制

拥塞控制

区别 swnd = Min[rwnd, cwnd]

理解拥塞控制的四种经典算法

理解 TCP 的拥塞窗口 cwnd 、传输轮次以及二者之间的关系

理解图 5-25 中拥塞控制算法及其中参数含义、设置

TCP 建立连接“三报文握手”过程以及原理，学会画图、且理解文字含义

为什么客户端在 TIME-WAIT 状态下必须等待 2MSL 的时间