三、运输层

主要内容：

1. 运输层和网络层之间的关系；
2. 两个实体怎样才能在一种会丢失或损坏数据的介质上可靠通信；
3. 控制运输层的传输速率以避免网络中的堵塞，或从堵塞中恢复过来；

1. 概述和运输层服务

运输层为运行在两个不同主机上的应用程序之间提供了逻辑通信；

1.1 运输层和网络层的关系

运输层运行于网络层之上，运输层为两个不同主机上的进程提供逻辑通信；而网络层则提供了两个主机之间的逻辑通信；（在应用层的角度，运输层是相当于在一个主机中负责各个程序数据的分发和传输，具有运输功能，而实际运输层是将要运输的数据传输到网络层，由网络层进行端到端的传输）

1.2运输层概述

将运输层传输的报文称为报文段（segment）

• 网络层有一个协议为IP协议，为主机之间提供了逻辑通信
  • IP协议的服务模型是尽力而为交付服务，它不做任何传输保证，所以IP为不可靠协议
• 运输层TCP和UDP的服务模型：
  • 运输层基本服务：将两个端系统间IP的交付服务扩展为运行在两个端系统上进程之间的交付服务，这种服务被称为多路复用和多路分解

2.多路复用与多路分解

进程有一个或多个套接字，它相当于进程向网络传递数据和从网络接收数据的门户；
每个套接字都有唯一的标识符；

• 将接收到的报文中的数据交付到正确的套接字的工作称为多路分解
• 从源主机不同的套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文段传递到网络层的工作称为多路复用
• 多路复用的要求：
  • 套接字有唯一标识符（即端口号）
  • 每个报文段有特殊字段（源端口号和目的端口号字段）来指示该报文段所要交付的套接字。
• 运输层是怎样实现多路分解服务的：
  • 主机上的每个套接字被分配一个端口号，当报文段到达时，运输层检查报文段中的端口号，并将其定向到相应的套接字，然后报文段中的数据通过套接字进入其所连接的进程；

3.无连接运输UDP

运输层的协议至少必须提供多路分解和多路复用的服务；

• UDP协议提供的服务：
  • 基本的多路分解和多路复用服务
  • 轻型的差错检验
• UDP特点：
  • UDP为无连接的运输层协议
  • 不可靠传输
• UDP使用例子：
  • DNS服务
• 为什么部分应用更使用UDP：
  • 应用层能更好的控制要发送的数据和时间 ：因为TCP的拥塞机制在链路拥塞时会遏制数据发送方，可能会造成较长的时延，对实时性的应用不是很友好；所以在部分可以容忍一些数据丢失，且需要高实时性的应用适用于UDP；
  • 无需建立连接：TCP传输需要进行三次握手建立连接，而UDP不需要。简单来说就是UDP方便快捷
  • 无连接状态：无连接，则无需维护连接的状态，而TCP需要维护连接的状态
• 分组首部开销小： TCP首部有20字节开销，UDP只需要8字节的开销

3.1 UDP报文结构

UDP报文段结构.png

• 长度：指明包括首部在内的UDP报文段长度（单位：字节）
• 校验和：提供差错检测功能

4.可靠数据传输的原理

可靠数据传输服务要保证数据相当于在一条可靠的信道传输，传输的数据不会受到损坏和丢失，而且是按顺序进行传输；实现这种服务是可靠数据传输协议（TCP）的责任，但是由于事实上可靠数据传输协议的下层协议（IP协议）是不可靠的，因此这项任务是比较困难的。

可靠数据传输服务模型与实现.png

4.1 构造可靠数据传输协议

由简单到复杂的构造一个可靠的传输协议

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

• 情况：完全可靠传输信道
• 结论：完全可靠的信道传输，不需要接收方反馈等，协议本身已经是微不足道的，即协议只需要提供多路复用和多路分解服务即为可靠数据传输协议。

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

• 情况：
  • 底层为不可靠的传输信道，数据在传输过程中可能受损
  • 接收方按照发送数据的顺序来接收数据
• 解决方法：
  • 差错检测：检测接收到的数据是否出现比特差错
  • 接收方反馈： 接收方需要反馈是否接收到发送的数据
  • 重传： 接收到有差错的分组，发送方将重传

因为发送方发送完一个数据报之后需要等待接收方的确认消息（ACK）或者是NAK（数据损坏等），这个时候发送方不会发送一块新数据，它需要等到确认接收方已经正确接收消息为止。由于这种行为，类似于rdt2.0的协议被称为停等协议（stop-and-wait）

虽然此时rdt2.0看起来可以运行了，但是它有一个致命的错误，即没有考虑到ACK和NAK分组受损

为解决以上问题，TCP采用了一种简单的方法。

1. 在数据分组中添加一个新字段，让发送方对其数据分组进行编号，即将发送的数据分组的序号放在该字段。
2. 假设信道不丢失分组
3. 接收方则可通过数据分组中的序号来判断此次传输是否为一次重传

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

• 情况：
  • 传输过程中数据有可能受损
  • 传输过程中有可能会丢包
• 解决办法：
  • 在rdt2.0（检验和、序号、ACK分组、重传等）的基础上需要解决如何检测丢包和发生丢包后该做什么的问题
  • 发送方可在发送数据分组之后启动一个定时器，如果在倒计时结束后仍然未收到ACK，则进行重传。

4. 流水线可靠数据传输协议

因为rdt3.0 是一个停等协议，这样的话会造成资源的浪费，并且传输的吞吐量与实际传输速率相差甚远。所以使用流水线可靠数据传输协议，允许发送方发送多个分组而无需等待确认。这样同时也带来一些要处理的问题：

1.必须增加序号范围，因为在停等协议中传输发送方一次只发送一个分组，所以分组的编号只需要使用0、1即可，但是流水线则无需发送方等待，可发送多个分组，所以必须要增加序号范围，保证每个分组序号的唯一性。
2.协议的发送方和接收方也许必须缓存多个分组。发送方最低限度应该缓存那些已发送但没有确认的分组。
3.所需序号范围和对缓冲要求取决于数据传输协议处理丢失、损坏、及过度延时的方式。解决流水线差错恢复有两种基本方法：回退N步和选择重传

4.2 回退N步（滑动窗口协议）

概述：在回退N步（Go-Back-N，GBN）协议中，允许发送方发送多个分组而不需要等待，但是它也受限于在流水线中未确认的分组数不能超过某个最大允许数N。
详细情况：

• 发送方：
  • 当上层调用传输层协议发送数据时，首先先查发送窗口是否已满。如果窗口未满，则创建一个分组将其发送。如果窗口已满，发送方著需要将数据返回给上层，隐式的通知上层该窗口已满。
  • 当收到ACK时，对序号为n的分组确认采取累积确认方式，即表明接收方已正确接收到序号n以前的所有分组。
  • 当超时未收到ACK时，则重传所有已发送但未被确认的分组
• 接收方：
  • 如果一个序号为n的分组被正确接收到，并且按序（上次时序号n-1的分组），则接收方为分组n发送一个ACK，并将分组中的数据交付到上层。
  • 在所有其他情况下，接收方都丢弃该分组；并为最近按序接收的分组重新发送ACK。（即累积确认，如果接收到序号为n的分组，则序号为n之前的分组都要被接收，否则丢弃）

4.3 选择重传

虽然GBN协议允许发送方发送多个分组，避免了停等协议信道利用率的问题。但是GBN也有很大的性能问题，尤其时窗口长度和宽带时延都很大的时候，一个分组的差错就有可能引起一大部分的分组重传。（比如一个窗口长度为1000，发送到序号为500的分组时，出现丢包或者数据出错，而500之后的分组都皆已到达，但是还是会丢弃500之后的分组，进行重传）

选择重传：即刨除累积确认，仅对接收错误的分组进行重传。

5.面向连接的传输：TCP

5.1 TCP连接

• TCP是面向连接的
  这是因为在一个应用进程可以开始向另一个另一个进程发送数据之前，这两个进程必须“握手”，即他们必须相互发送某些预备报文段，以建立确保数据传输所需的参数。

• TCP连接既不是一条电路交换中的电路，也不是虚电路，因为其连接状态是完全保留在两个端系统中。
  由于TCP协议只在端系统中运行，而不是在中间的网络元素（路由器和交换机）中运行，所以中间要素不会维持TCP的连接状态，他们看到的只是数据报，而不是连接。

• TCP连接提供的是双全工服务：
  如果一台主机的进程A与另一台主机上的进程B存在一条TCP连接，那么应用层数据就可在进程B流向A的同时，也从进程A流向进程B。

• TCP连接时怎样建立的？
  • 发起连接的进程称为客户机进程，另一个进程称为服务器进程
  • 客户机首先通知客户机运输层，他想与服务器上的一个进程建立连接
  • 进行”三次握手“，连接建立
  • 一旦连接建立两个进程之间就可以相互发送数据了
• 发送数据的情况：
  • 客户机进程通过套接字传递数据流，之后由客户机中运行的TCP控制
  • TCP将这些数据引导到该连接的发送缓存中（发送缓存是在三次握手初期设置的缓存之一）
  • TCP会不时的从发送缓存里取出一块数据
  • TCP将每块客户机数据加一个TCP首部，形成多个TCP报文段
  • 将报文段传送至网络层，网络层将其封装在IP数据包中并发送
  • 当TCP在另一端接收一个报文段后，该报文段的数据就被放入该TCP连接的接收缓存中

• TCP可从缓存中取出并放入报文段中的数据量受限于最大报文段长（MSS，maximum segment size）。
• MSS通常根据最初确定的最大链路层帧长度（最大传输单元，MTU，maximum transmission unit）来设置，MTU常见值为1460字节、536字节、512字节等
• 注意：MSS是指报文段里应用层数据的最大长度，而不是指包括TCP首部的TCP报文段的最大长度。

• TCP连接的组成：
  • 一台主机上的缓存
  • 变量（如MSS）
  • 与一个进程的套接字

5.2 TCP报文段结构

TCP报文结构.png

• 32比特的序号字段和32比特的确认号字段：被用来实现可靠数据传输服务
• 16比特的接收窗口：用于流量控制，该字段用于显示接收方愿意接受的字节数量
• 4比特的首部长度：该字段指示了以32比特的字为单位的TCP首部长度
• 可选与变长的选项字段：该字段用于当发送方与接收方协商最大报文段长度（MSS），或在高速网络下用作窗口调节因子使用。
• 6比特的标志字段：ACK比特用于指示确认字段中的值是有效的，即该报文段包括一个对已被成功接收报文段的确认。RST、SYN、FIN比特用于连接建立和拆除；当PSH比特被设置时，就指示接收方应立即将数据交给上层；UGR比特用来指示报文段里存在着被发送方的上层实体置为”紧急“的数据 ，紧急数据的最后一个字节由16比特的紧急数据指针字段指出。

序号和确认号为TCP首部最重要的两个字段，时可靠传输服务的关键部分；

• 序号和确认号存放什么？
  TCP把数据看成一个无结构的但是有序的字节流，因为序号是建立在传送的字节流之上，而不是建立在传送的报文段序列之上。一个报文段的序号因此是该报文段首字节的字节流编号。 假设现在有主机B的一个进程向主机A的一个进程发送数据，主机A接受到主机B消息后需要发送ACK确认消息已到达，主机A填充进报文段的确认号是主机A期望从主机B收到的下一个字节的序号。

5.3 往返时延的估计与超时

TCP对于报文段的丢失问题采用超时/重传机制，虽然概念简单，但是有很多细节问题需要处理，如超时时间的设置，刚开始如何估计往返时间等问题。

• 估计往返时延：TCP是如何估计发送方与接收方之间的往返时延的？
  • 报文段的样本RTT就是从某报文被发出到对该报文段的确认被收到之间的时间量
  • 大多数TCP的实现仅在某一时刻做一次RTT的测量，而不是每发送一个报文段测量一次。
  • 显然，由于路由器的拥塞和端系统负载的变化，这些报文段的RTT值会随之波动。所以自然要采用RTT取平均值的方法，TCP维持一个RTT的均值(EstimatedRTT)，当获得新的RTT时，采用以下公式计算新的RTT平均值
  • DevRTT：是RTT和EstimatedRTT之间的差值，对应RTT的波动大小

EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * RTT;
DevRTT = (1- 0.25) * DevRTT + 0.25 * |RTT - EstimatedRTT|；

• 设置和管理重传超时时间间隔

假设已经给出Estimated RTT和DevRTT的值，那TCP的超时时间间隔取多少呢？

• 首先超时时间间隔需要大于EstimatedRTT(平均RTT) ，但是也不能大太多，这样会带来很大的传输时延，所以超时时间间隔设置为Estimated RTT加上一定的余量，当RTT的波动比较大的时候，余量就应该大一点；波动小时则小一点；以下为公式：

TimeoutInterval = EstimatedRTT + 4 * DevRTT

5.4 可靠数据传输