计算机网络知识点——第3章 运输层

以下内容仅为笔者看书做的笔记，后续可能会有补充。
参考书籍《计算机网络 自顶向下方法.中文第6版》

运输层为运行在不同主机上的应用进程提供直接的通信服务起着至关重要的作用。

3.1 概述和运输层服务

运输层协议为运行在不同主机上的应用程序之间提供了逻辑通信（logic communication）功能。运输层协议是在端系统中而不是在路由器中实现的。

在发送端，运输层将从发送应用程序进程接收到的报文转换成运输层分组，用因特网术语来讲该分组称为运输层报文段（segment）。

在发送端系统中，运输层将这些报文段传递给网络层，网络层将其封装成网络层分组（即数据报）并向目的地发送。在接收端，网络层从数据报中提取运输层报文段，并将该报文段向上交给运输层。

3.1.1 运输层和网络层的关系

运输协议能够提供的服务常常受制于底层网络层协议的服务模型。如果网络层协议无法为主机之间发送的运输层报文段提供时延或带宽保证的话，运输层协议也就无法为进程之间发送的应用程序报文提供时延或带宽保证。

底层网络协议不能再网络层提供相应的服务，运输层协议也能提供某些服务。例如数据安全性和可靠性等。

3.1.2 因特网运输层概述

运输协议：

• UDP（用户数据报协议），它为调用它的应用程序提供了一种不可靠、无连接的服务。
• TCP（传输控制协议），它为调用它的应用程序提供了一种可靠的、面向连接的服务。

此书中，将TCP和UDP的分组统称为报文段，而将数据报保留给网络层分组不容易混淆。

UPD和TCP最基本的责任是，将两个端系统间IP的交付服务扩展为运输层的多路复用（transport-layer multiplexing）与多路分解（demultiplexing）。

TCP为应用程序提供了几种附加服务。

• 可靠数据传输（reliable data transfer）。通过使用流量控制、序号、确认和定时器，正确地、按序地将数据从发送进程交付给接收进程。
• 拥塞控制（congestion control）。提供给整个因特网的服务。防止任何一条TCP连接用过多流量来淹没通信主机之间的链路和交换设备。为每个通过一条拥塞网络链路的连接平等地共享网络链路带宽。这可以通过调节TCP连接的发送端发送进网络的流量速率来做到。

3.2 多路复用与多路分解

将运输层报文段中的数据交付到正确的套接字的工作称为多路分解（demultiplexing）。
在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后报文段传递到网络层，所有这些工作称为多路复用（multiplexing）。

运输层多路复用的要求：
1）套接字有唯一标识符；
2）每个报文段有特殊字段来指示该报文段所要交付到的套接字。

如图，这些特殊字段是源端口号字段（source port number field）和目的端口号字段（destination port number field）。

运输层是怎样能够实现分解服务的：
在主机上的每个套接字能够分配一个端口号，当报文段到达主机时，运输层检查报文段中的目的端口号，并将其定向到相应的套接字。然后报文段中的数据通过套接字进入其所连接的进程。

1. 无连接的多路复用与多路分解

下述事实是重要的：一个UDP套接字是由一个二元组来全面标识的，该二元组包含一个目的IP地址和一个目的端口号。因此，如果两个UDP报文段有不同的源IP地址和/或源端口号，但具有相同的目的IP地址和目的端口号，那么这两个报文段将通过相同的目的进程。

源端口号的用途：在A到B的报文段中，源端口号用作“返回地址”的一部分，即当B需要回发一个报文段给A时，B到A的报文段中的目的端口号便从A到B的报文段中的源端口号中取值。

2. 面向连接的多路复用与多路分解

TCP套接字和UDP套接字之间的一个细微差别是，TCP套接字是由一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）来标识的。

特别与UDP不同的是，两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字，除非TCP报文段携带了初始创建连接的请求。

3.3 无连接运输：UDP

UDP从应用进程得到数据，附加上用于多路复用/分解服务的源和目的端口号字段，以及两个其他的小字段，然后形成的报文段交给网络层。网络层将该运输报文段封装到一个IP数据报中，然后尽力而为地尝试将此报文段交给接收主机。

许多应用更适合UDP，原因主要以下几点：

• 关于何时、发送什么数据的应用层控制更为精细。因为实时应用通常要求最小的发送速率，不希望过分地延迟报文段的传送，且能容忍一些数据丢失，TCP服务模型并不是特别适合这些应用的需要。
• 无需连接建立。UDP不会引入建立连接的时延。
• 无连接状态。
• 分组首部开销小。

既然所有这些应用（例如因特网电话、实时视频会议、流式存储音频与视频）都能容忍少量的分组丢失，因此可靠数据传输对于这些应用的成功并不是至关重要的。TCP的拥塞控制会导致如因特网电话、视频会议之类的实时应用性能变得很差，所以多媒体应用开发人员通常将这些应用运行在UDP之上而不是TCP之上。然而TCP被越来越多地应用于流式媒体传输中。

3.3.1 UDP报文段结构

UDP报文段结构如下图所示

3.3.2 UDP检验和

发送方的UDP对报文段中的所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。得到的结果被放在UDP报文段中的检验和字段。

在既无法确保逐链路的可靠性，又无法确保内存中的差错检测的情况下，如果端到端数据传输服务要提供差错检测，UDP就必须在端到端基础上在运输层提供差错检测

3.4 可靠数据传输原理

3.4.1 构造可靠数据传输协议

1. 经完全可靠信道的可靠数据传输：rdt 1.0

下图显示了rdt 1.0发送方和接收方的有限状态机（Finite-State Machine, FSM）的定义。图中a的FSM定义了发送方的操作，图b中的FSM定义了接收方的操作。

因为是基于完全可靠信道的可靠数据传输，所以接收端不需要提供任何反馈信息给发送方，因为不必担心出现差错。

2. 经具有比特差错信道的可靠数据传输：rdt 2.0

底层信道更为实际的模型是分组中的比特可能受损。在分组的传输、传播或缓存的过程中，这种比特差错通常会出现在网络的物理部件中。但是依然假定所有发送的分组将按其发送的顺序被接收。

这些控制报文使得接收方让发送方知道哪些内容被正确接收，哪些内容接收有误并因此需要重复。在计算机网络环境中，基于这样重传机制的可靠数据传输协议称为自动重传请求（Automatic Repeat reQuest, ARQ）协议。

ARQ协议中还需要另外三种协议功能来处理存在比特差错的情况：

• 差错检测。只需要知道这些技术要求有额外的比特从发送方到接收方，这些比特被汇集在rdt 2.0数据分组的分组检验和字段中。
• 接收方反馈。发送方要了解接收方情况的唯一途径就是让接收方提供明确的反馈信息给发送方。rdt 2.0协议将从接收方向发送方回送ACK与NAK分组，理论上，这些分组只需要一个比特长，如用0表示NAK，用1表示ACK。
• 重传。接收方收到有差错的分组时，发送方将重传该分组文。

下图说明了表示rdt 2.0的FSM，该数据阐述协议采用了差错检测、肯定确认与否定确认。

3. 经具有比特差错的丢包信道的可靠数据传输：rdt 3.0

为了实现基于时间的重传机制，需要一个倒计数定时器（countdown timer），在一个给定的时间量过期后，可中断发送方。因此，发送方需要能做到：①每次发送一个分组（包括第一次分组和重传分组）时，便启动一个定时器。②响应定时器中断（采取适当的动作）。③终止定时器。

下图是rdt3.0发送方，因为分组序号在0和1之间交替，因此rdt3.0有时被称为比特交替协议（alternating-bit protocol）。

在检验和、序号、定时器、肯定和否定确认分组这些技术中，每种机制都在协议的运行中起到了必不可少的作用，至此，我们得到了一个可靠数据传输协议！

3.4.2 流水线可靠数据传输协议

停等协议有着非常低的发送方利用率，为了解决这种性能问题的一个简单方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。

因为许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，故这种技术被称为流水线（pipelining）。

流水线技术对可靠数据传输协议可带来如下影响：

• 必须增加序号范围，因为每个输送中的数组必须有一个唯一的序号，而且也许有多个在输送中未确认的报文。
• 协议的发送方和接收方两端也许必须缓存多个分组。
• 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法：回退N步（Go-Back-N, GBN）和选择重传（Selective Repeat, SR）。

3.4.3 回退N步

那些已被发送但还未确认的分组的许可序号范围可以被看成是一个在序号范围内长度为N的窗口。随着协议的运行，该窗口在序号空间向前滑动，因此，N常被称为窗口长度（window size），GBN协议也常被称为滑动窗口协议（sliding-window protocol）。

下图给出了一个基于ACK、无NAK的GBM协议的发送方和接收方这两端的扩展FSM描述。

GBM发送方必须响应三种类型的事件：

• 上层的调用。在上层调用rdt_send()时，发送方首先检查发送窗口是否已满，即是否有N个已发送但未被确认的分组。
• 收到一个ACK。对序号为n的分组的确认采取==累积确认（cumulative acknowledgment）==的方式，表明接收方已正确接收到序号为n的以前且包括n在内的所有分组。
• 超时事件。如果出现超时，发送方重传所有已发送但未被确认过的分组。

3.4.4 选择重传（SR）

选择重传协议通过让发送方仅重传那些它怀疑在接收方出错（即丢失或受损）的分组而避免了不必要的重传。

SR发送方的事件与动作：

• 从上层收到数据。当从上层接收到数据后，SR发送方检查下一个可用于该分组的序号。
• 超时。定时器再次被用来防止丢失分组。
• 收到ACK。如果收到ACK，倘若该分组序号在窗口内，则SR发送方将那个被确认的分组标记为已接收。如果该分组的序号等于send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。

SR接收方的事件与动作：

• 序号在[rcv_base, rcv_base + N - 1]内的分组被正确接收。
• 序号在[rcv_base - N, rcv_base - 1]内的分组被正确收到。在此情况下，必须产生一个ACK，即使该分组时接收方以前已确认过的分组。
• 其他情况。忽略该分组。

3.5.3 往返时间的估计与超时

1. 估计往返时间

3.7 TCP拥塞控制

TCP所采用的方法是让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率。如果一个TCP发送方感知从它到目的地之间的路径上没有什么拥塞，则TCP发送方增加其发送速率；如果发送方感知沿着该路径有拥塞，则发送方就会降低其发送速率。

（1）TCP发送方如何限制向其连接发送流量的。

TCP连接的每一端都是由一个接受缓存、一个发送缓存和几个变量（LastByteRead、rwnd等）组成。运行在发送方的TCP拥塞控制机制跟踪一个额外的变量，即拥塞窗口（congenstion window）。拥塞窗口表示为cwnd，它对一个TCP发送方能向网络中发送流量的速率进行了限制。
在一个发送方中未被确认的数据量不会超过cwnd与rwnd中的最小值，即
LastByteSent - LastByteAcked ≤ min{cwnd, rwnd}
上面的约束限制了发送方中未被确认的数据量，因此间接地限制了发送方的发送速率。

该发送方的发送速率大概是cwnd/RTT 字节/秒。通过调节cwnd的值，发送方因此能调整它向连接发送数据的速率。

（2）TCP发送方是如何感知在它与目的地之间的路径上出现了拥塞的。

当出现过度的拥塞时，在沿着这条路径上的一台（或多台）路由器的缓存会溢出，引起一个数据包（包含一个TCP报文段）被丢弃。丢弃的数据报接着会引起发送方的丢包事件（要么超时或受到3个冗余ACK），发送方就认为在发送方到接收方的路径上出现了拥塞的指示。

（3）当发送方感知到端到端的拥塞时，采用何种算法来改变其发送速率呢？

TCP使用下列指导性原则回答这些问题：

• 一个丢失的报文段表意味着拥塞，因此当丢失报文段时应当降低TCP发送方的速率。
• 一个确认报文段指示该网络正在向接收方交付发送方的报文段，因此，当对先前未确认报文段的确认到达时，能够增加发送方的速率。
• 带宽探测。TCP调节其传输速率的策略是增加其速率以响应到达的ACK，除非出现丢包事件，此时才减小传输速率。因此，为探测拥塞开始出现的速率，TCP发送方增加它的传输速率，从该速率后退，进而再次开始探测，看看拥塞开始速率是否发生了变化。

---

TCP拥塞控制算法（TCP congestion control algorithm）包括3个主要部分：①慢启动；②拥塞避免；③快速恢复。

1. 慢启动

在慢启动（slow-start）状态，cwnd的值以1个MSS（较小值）开始并且每当传输的报文段首次被确认就增加1个MSS。因此，TCP发送速率起始慢，但在慢启动阶段以指数增长。

何时结束这种指数增长呢？
（1）如果存在一个由超时指示的丢包事件（即拥塞），TCP发送方将cwnd设置为1并重新开始慢启动过程。它还将第二个状态变量的值ssthresh（“慢启动阀值”的速记）设置为cwnd/2，即当检测到拥塞时将ssthresh置为拥塞窗口值的一半。
（2）直接与ssthresh的值相关联。因为当检测到拥塞时ssthresh设为cwnd的值一半，当到达或超过ssthresh的值时，继续使cwnd翻番可能有些鲁莽。因此，当cwnd的值等于ssthresh时，结束慢启动并且TCP转移到拥塞避免模式。
（3）如果检测到3个冗余ACK，这时TCP执行一种快速重传并进入快速恢复状态。

TCP分岔：优化云服务的性能
如果端系统远离数据中心，则RTT将会很大，会由于TCP慢启动潜在地导致低劣的响应时间性能。
缓解问题和改善用户感受到的性能的一个途径是：①部署邻近用户的前端服务器；②在该前端服务器利用TCP分岔来分裂TCP连接。
借助于TCP分岔，客户向邻近前端连接一条TCP连接，并且该前端以非常大的窗口向数据中心维护一条TCP连接。使用这种方法，响应时间大致变为4 * RTT_FE + RTT_BE + 处理时间，其中RTT_FE是客户与前端服务器之间的往返时间，RTT_BE是前端服务器与数据中心（后端服务器）之间的往返时间。