计算机网络_运输层

运输层

1. 运输层概述

通信的真正实体是位于通信两端主机的进程，运输层协议又称为端到端协议

1）任务

如何为运行在不同主机上的应用进程提供直接的通信服务

运输层向高层用户屏蔽了下面网络核心的细节，它使应用进程看见的就好像是在两个运输层实体之间有一条端对端的逻辑通信信道

2）种类

面向连接的TCP

面向无连接的UDP

2. 运输层端口号、复用和分用的概念

1）端口号

作用

为了使得运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。

运行在计算机的进程使用进程标识符PID来标志。

TCP/IP体系的运输层使用端口号开区分应用层的不用应用进程

• 端口号使用16比特表示，取值范围0~65535
• 端口号只具有本地意义，即端口号知识为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的

2）发送方的复用和接收方的分用

复用：发送方不用的应用进程都可以使用同一个运输层协议传送数据（加上适当的头部

分用：接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程

3）TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

3. ★UDP和TCP的对比（面试重点）

1）UDP

• 面向无连接
• 支持单播、多播以及广播，即支持一对一、一对多和多对多交互通信
• UDP面向应用报文
• 向上层提供无连接不可靠传输服务（适用于IP电话、视频会议等实时应用
• 不适用流量控制和拥塞控制
• 首部开销小，仅8字节

2）TCP

• 需要三报文握手建立连接，基于TCP连接的可靠信道
• 仅支持单播
• TCP面向字节流
• 向上层提供面向连接的可靠传输服务（适用于要求可靠传输的应用，例如文件传输
• 首部最小20字节，最大60字节

3）对比

a. 是否支持多播广播

b. 面向内容

c. 应用方向

TCP应用场景
效率要求相对低，但对准确行要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。 例如：文件传输、接受邮件、远程登录。

UDP应用场景
效率要求相对高，对准确行要求相对低的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）

d. 报文首部大小

4. TCP报文段的首部格式

1）TCP特点

• 为了实现可靠传输，TCP采用了面向字节流的方式。
• 但TCP再发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之称为TCP报文段后进行发送
  • 一个TCP报文段由首部和数据载荷两部分构成
  • TCP的全部功能都体现再它首部中各字段的作用。

2）源端口和目的端口

源端口

占16比特，写入源端口号，用来标识发送该TCP报文段的应用进程

目的端口

占16比特，写入目的端口号，用来标识接收该TCP报文段的应用进程

示例

3）序号、确认号和ACK

序号

占32比特，取值范围[0,2³²-1],序号增加到最后一个后，下一个序号就又回到0。指出本TCP报文段所发送的数据的第一个字节的序号

确认号

占32比特，取值范围[0,2³²-1]，确认号增加到最后一个后，下一个确认号就又回到0。指出期望收到对方下一个TCP报文段的第一个数据字节的序号，同时也是对之前收到的所有数据的确认。

若确认号=n，则表明到序号n-1位置的所有数据都已正确接收，期望接收序号为n的数据。

确定标志位

取值为1时确认号字段才有效；取值为0时确认号字段无效。

TCP规定，在连接建立后所有传送的TCP报文都必须吧ACK置1

4）数据偏移

数据偏移

占4比特，并以4字节为单位

用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远

这个字段实际上是指出了TCP报文段的首部长度

首部固定长度为20字节，因此数据偏移字段的最小值为(0101)2

首部最大长度为20字节，因此数据偏移字段的最大值为(1111)2

示例

5）保留

保留

占4比特，保留为今后使用，但目前应置0

6）窗口

窗口

占16比特，以字节为单位。

指出发送本报文段的一方的接收窗口。

窗口值作为接收方让发送方设置其发送窗口的依据。

这是以接收方的接收能力来控制发送方的发送能能力，称为流量控制。

7）校验和

校验和

占16比特，检查范围包括TCP报文段的首部和数据载荷两部分。

在计算校验和时，要在TCP报文段的前面加上12字节的伪首部。

8）同步标志位SYN、终止标志位FIN和复位标志位RST

SYN

在TCP连接建立时用来同步序号

SYN示例

FIN

用来释放TCP连接

FIN示例

RST

用来复位TCP连接

当RST=1时，表明TCP连接出现了异常，必须释放连接，然后再重新建立连接。

RST置1时还用来拒绝一个非法的报文段或拒绝打开一个TCP连接。

9）推送标志PSH

PSH

接收方的TCP收到该标志位为1的报文段会尽快上交应用进程，而不必等待接收缓存都填满后再向上交付

10）紧急标志位URG和紧急指针

URG

取值为1是紧急指针字段有效；取值为0时紧急指针字段无效

紧急指针

占16比特，以字节为单位，用来指明紧急数据的长度

当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后时普通数据

11）扩展首部——选项

最大报文段长度MSS选项

TCP报文段数据载荷部分的最大长度

窗口扩大选项

为了扩大窗口（提高吞吐率）

时间戳选项

• 用来计算往返时间RTT
• 用于处理序号超范围的情况，又称为防止序号绕回PAWS

选择确认选项

12）扩展首部——填充

填充

由于选项的长度可变，因此使用填充来确保报文段首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为单位的）

5. 可靠传输

1）基本概念

有线链路和无线链路

• 有线链路的误码率比较低，为了减少开销，并不要求数据链路层向上提供可靠传输服务。即使出现了误码，可靠传输的问题由其上层处理
• 无线链路易受干扰，误码率比较高，因此要求数据链路层必须向上层提供可靠传输服务

传输差错

• 比特差错
• 分组丢失
• 分组失序
• 分组重复

2）可靠传输的实现机制 停止-等待协议SW

协议设计

• 超时重传
  • 为了解决接收方收不到数据就不会发送ACK或NAK，发送方就会一直处于等待接收方ACK或NAK的状态的问题
  • 发送方发完一个数据分组时，启动一个超时计时器，若到了超时计时器所设置的重传时间而发送方仍收不到接收方的任何ACK或NAK，则重传原来的数据分组
  • 一般将重传时间选为略大于“从发送方到接收方的平均往返时间”
• 数据分组
  • 为了让接收方能够判断所收到的数据分组是否是重复的
  • 由于停止-等待协议的停等特性，只需1个比特编号就够了，即标号0和1
• ACK分组
  • 为了让发送方能够判断所受到的ACK分组是否是重复的，需要给ACK分组编号
  • 所用比特数量与数据分组编号所用比特数量一样

信道利用率

缺点

• 当往返时延RTT远大于数据帧发送时Td时（例如使用卫星链路），信道利用率非常低
• 若出现重传，则对于传送有用的数据信息来说，信道利用率还要降低

为了克服SW协议信道利用率很低的缺点，就产生了另外两种协议，即GBN和SR协议

3）可靠传输的实现机制 回退N帧协议GBN

• 采用流水线传输可提高信道利用率

  

发送方

• 发送窗口尺寸W_T的取值范围是1<W_T<=2ⁿ-1其中，n是构成分组序号的比特数量
  • W_T=1,停止-等待协议
  • W_T > 2ⁿ -1 接收方无法分辨新、旧数据分组
• 发送方可在未收到接收方确认分组的情况下，将序号落在发送窗口内的多个数据分组全部发送出去
• 发送方只有收到对已发送数据分组的确认时，发送窗口才能向前相应滑动
• 发送方收到多个重复确认时，可在重传计时器超时前尽早开始重传，由具体实现决定
• 发送方发送窗口内某个已发送的数据分组产生超时重发时，其后续在发送窗口内且已发送的数据分组也必须全部重传，这就是回退N帧协议名称的由来

接收方

• 接收方的接收窗口尺寸W_R的取值范围时W_R = 1，因此接收方只能按序接收数据分组
• 接收方只接受序号落在接收窗口内且无误码的数据分组，并且将接收窗口向前滑动一个位置，与此同时给发送方发回相应的确认分组。为了减少开销，接收方不一定每收到一个按序到达且无误码的数据分组就给发回一个确认分组
  • 而是可以在连续收到好几个按序到达且无误码的数据分组后（由具体实现决定），才针对最后一个数据分组发送确认分组，这称为累积确认
  • 或者可以在自己有数据分组要发送时才对之前按序接收且无误码的数据分组进行捎带确认
• 接收方收到未按序到达的数据分组，除丢弃外，还需对最近按序接收的数据分组进行确认。

缺点

由于回退N帧协议的特性，当通信线路质量不好时，其信道利用率并不比停止-等待协议高。

4）可靠传输的实现机制 选择重传协议SR

基于回退N帧协议GBN

• 对于GBN，一个数据分组的误码就会导致其后续多个数据分组不能被接收方按序接收而丢弃。这必然会造成发送方对这些数据分组的超时重传，显然这是对通信资源的极大浪费。
• 为了进一步提高新能，可设法只重传出现误码的数据分组。
• 接收窗口的尺寸W_R不应再等于1（而应大于1），以便接收方先收下失序到达但无误码并且序号落在接收窗口内的那些数据分组，等到所缺分组收齐后再一并送交上层。这就是选择重传协议。

发送方

• 发送窗口尺寸W_T的取值范围时 1 < W_T <= 2^n-1,其中，n是构成分组序号的比特数量
  • W_T = 1 与停止-等待协议相同
  • W_T > 2^n-1 接收方无法分辨新、旧数据分组
• 发送方可再未收到接收方确认分组的情况下，将序号落在发送窗口内的多个数据分组全部发送出去
• 发送方只有按序收到对已发送数据分组的确认时，发送窗口才能向前相应华东；若收到未按序到达的确认分组时，对其进行记录，以防止相应数据分组的超时重发，但发送窗口不能向前滑动。

接收方

• 接收窗口尺寸W_R的取值范围时 1 < W_R <= W_T
  • W_R = 1 与停止-等待协议相同
  • W_R > W_T 无意义
• 接收方可接收未按序到达但没有误码并且序号落在接收窗口内的数据分组
  • 为了使发送方仅重传出现差错的分组，接收方不能再采用累计确认，而需要对每个正确接收到的数据分组进行逐一确认
• 接收方只有再按序接收数据分组后，接收窗口才能向前相应滑动。

6. TCP可靠传输的实现

以字节为单位的滑动窗口来实现可靠传输

1）过程

1. 建立连接

   

2. 发送报文

   

3. 接收方发送确认报文

4. 发送方确定窗口

5. 发送方发送报文

   

6. 接收方接收报文

   

2）状态指针

3）特点

• 虽然接发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大
  • 网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的。
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸
• 对于不按序到达的数据应如何处理，TCP并无明确规定
  • TCP通常对不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以zai自己有数据要发送时把确认信息顺便捎带上
  • 接收方不应过分推迟发送消息，否则会导致发送方不必要的超时重传。
  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时再两个方向上发送数据
• TCP的通信时全双工通信。通信中的每一方都在发送和接收报文端。因此，每一方都有自己的发送窗口和接收窗口。

7. TCP超时重传时间的选择

1）超时重传时间的选择

• 超时重传时间RTO过小会导致不必要的重传，使网络负荷增大。
• 超时重传时间RTO过大会导致网络空闲时间增大，降低了传输效率。
• 超时重传时间RTO应略大于往返时间RTT

2）超时重传时间的计算

RTO = RTT_S + 4 x RTT_D

对于超时重传时间的选择

报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

8. TCP的流量控制

1）流量控制

让发送方的发送速率不要太快，要让接收方来得及接收

2）实现方式

利用滑动窗口机制

9. TCP的拥塞控制

1）拥塞

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变换。这种情况就叫做拥塞。

在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

2）拥塞控制算法

a. 前提假定条件

1. 数据是单方向传送，而另一个方向只传送确认
2. 接收方总是有足够大的缓存空间，因而发送方发送窗口的大小由网络的拥塞程度来决定
3. 以最大报文段MSS的个数为讨论问题的单位，而不是以字节为单位。

b. 状态描述

• 发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。
  • 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞，拥塞窗口就减少一些，
  • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传）
• 发送方将拥塞窗口作为发送窗口swnd，即swnd=cwnd
• 维护一个慢开始门限搜索ssthresh状态变量：
  • 当cwnd < ssthresh时，使用慢开始算法；
  • 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法
  • 当cwnd = ssthresh时，即可使用慢开始算法，也可使用拥塞避免算法

c. 慢开始和拥塞避免

重传计时器超时

判断网络很可能出现了拥塞，进行了以下工作：

1. 将ssthresh值更新为发生拥塞时cwnd值的一半
2. 将cwnd值减少为1，并重新开始执行慢开始算法

e. 快重传

• 有时，个别报文段会再网络中丢失，但实际上网络并未发生拥塞
  • 这将导致发送发超时传送，并误认为网络发生了拥塞
  • 发送方把拥塞窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率

采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失

• 所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传
  • 要求接收方不要等待自己发送数据时才进行捎带确认，而是立即发送确认
  • 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
  • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。
  • 对于个别丢失的报文段，发送方不会出现超时传送，也就不会误认为出现了拥塞（进而降低拥塞窗口cwnd为1）。使用快重传可以使整个网络的吞吐量提高约20%。

f. 快恢复

发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法；

• 发送方也将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半；开始执行拥塞避免算法
• 也有快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh + 3。
  • 既然发送方收到3个重复的确认，就表明3个数据报文段已经离开了网络；
  • 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中；
  • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当地把拥塞窗口扩大些。

10. TCP的运输连接管理（面试重点）

1）TCP运输连接三阶段

1. 建立TCP连接
2. 数据传送
3. 释放TCP连接

2）连接建立要解决的三个问题

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

3）★TCP的连接建立

前提：服务器端需要监听端口，初始状态是LISTEN

a. 一握手

客户端发送TCP连接请求

• 发送一个SYN同步包，
• 发送之后状态变成SYN-SENT
  

b. 二握手

服务器发送针对TCP连接请求的确认

• 服务器端收到SYN后，同意建立连接，发送一个ACK响应，同时也会给客户端发送一个SYN包
• 发送完成后状态变成SYN-RCVD
  

c. 三握手

客户端发送针对TCP连接请求的确认的确认

• 客户端收到server的ACK之后，状态变成ESTABLISHED
• 返回ACK给服务器端
• 服务器端收到之后状态也变成ESTABLISHER，连接建立完成

f. ★问题

为什么不可以两次握手？一定要三次吗？

不多余，这是为了防止已失效的连接请求报文段突然又传到了TCP服务器，因而导致错误。

反例：

TCP在第一次发送请求后，请求滞留在网络中。
在这期间，TCP发出新的连接请求，并完成一个数据传输，关闭网络。
而连接释放之后，滞留的连接请求传送到服务器端，服务器发送针对TCP连接请求的确认。
客户端一直不理睬，仍未关闭状态，造成资源浪费。

4）★TCP的连接释放

a. 一挥手

客户发送一个TCP请求终止报文段

• 客户端向服务器端发送FIN包
• 进入 FIN_WAIT_1状态，表明客户端没有数据要发送了

FIN=1和ACK=1,表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认，
seq=u表示TCP客户进程之前已传送过的、数据的最后一个字节的序号加1，
ack=v表明TCP客户端进程之前已收到的数据的最后一个字节的序号加1

TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号

b. 二挥手

服务器发送一个普通的TCP确认报文段并进入关闭等待状态

• 服务器端收到之后返回ACK包
• 进入CLOSE_WAIT等待关闭的状态，因为服务器端可能还有没有发送完的数据
• 客户端收到报文后，进入FIN_WAIT_2状态，等待TCP服务器进程发出的TCP连接释放报文段。

ACK=1 表明为是一个普通的TCP确认报文段
seq=v 表明TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，与挥手1中的ack=v对应
ack=u+1 表明对挥手1的seq=u的确认

c. 三挥手

TCP服务器进程发送TCP连接释放报文段并进入最后确认状态。

• 等到服务器端发送完数据后，服务器端向客户端发送FIN，进入LAST-ACK状态

FIN=1和ACK=1,表明这是一个TCP连接释放报文段，同时也对之前收到的报文进行确认
seq=w，表示在半关闭状态下，TCP服务器进程可能又发送了一些数据
ack=u+1，是对之前收到的TCP连接释放报文段的重复确认

TCP客户端收到TCP服务器的释放报文段后，必须针对该报文段发送普通的TCP确认报文段。

之后进入时间等待状态

d. 四挥手

TCP客户端向TCP服务器端发送确认报文段

• 客户端收到ACK后，进入TIME_WAITz的状态
• 向服务器发送ACK
• 服务器收到后直接进入CLOSER状态，连接关闭
• 客户端等待2MSL的时间后，进入CLOSED状态

ACK=1，表明这是一个普通的TCP确认报文段
seq=u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但是要消耗掉一个序号
ack=w+1,是对TCP服务器报文段的确认，TCP服务器进程收到该报文段后就进入关闭状态。而TCP客户进程还要金国2MSL（最长报文段寿命）后才能进入关闭状态。

e.★TCP保活计时器

（面试题:如果已经建立了连接，但是客户端突然出现故障了怎么办？）

针对问题：TCP双方建立了连接，TCP客户进程所在的主机突然出现了故障，显然TCP服务器进程以后就不能再收到TCP客户进程发来的数据。因此，应当有措施使TCP服务器进程不要再白白等待下去。

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

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

g.★问题

1. TCP客户端为什么不直接进入关闭状态？可以不进入时间等待状态吗？

时间等待状态主要解决丢包问题。

时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。

示例：

进入关闭状态后，如果客户端发送的确认报文段丢失了，这必然会造成TCP服务器进程对之前所发送的TCP连接释放报文段的超时重传，并仍然处于最后的确认状态。

重传的报文再次发送到客户端，由于TCP客户进程属于关闭状态，因此不理睬该报文段。这必然会造成TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态而无法进入关闭状态。

2. 为什么TCP连接的时候是3次，关闭的时候却是4次？

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。**而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。**而服务端收到客户端的FIN报文后只能先灰度客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文（所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次）。

3. TIME_WAIT过多会出现什么问题?

对于网站来说，这样的time_wait略显偏高, 也就是说大量的关闭操作在等待2个MSL后结束，正常我们的tcp 端口是65535个，如果并发再高一些，可能会大量的socket不能及时被释放，从而导致性能下降，

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

所以我们可以通过linux内核进行一些网络调整比如，开启socket重用和快速回收

4. CLOSE_WAIT 过多会出现什么问题？

CLOSE_WAIT 过多导致服务器资源占用，客户端在 FIN_WAIT_2 状态超时大约 60s，自动进入 CLOSED状态， 影响不大。但是服务端在 CLOSE_WAIT 的超时时间默认为 43200秒，所以大量的 CLOSE_WAIT 积压可能造成服务器无法分配出资源给新的连接。一般这种情况都是由于服务器没有调用 close 造成的。程序员应该主动检查代码。