计算机网络第五章(运输层)

第五章 运输层

5.1 概述

​ 之前课程所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。
​ 但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。
​ 如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

进程Ap1与Ap4之间进行基于网络的通信，进程Ap2与Ap3之间进行基于网络的通信。在运输层使用不同的端口，来对应不同的应用进程。然后通过网络层及其下层来传输应用层报文。接收方的运输层通过不同的端口，将收到的应用层报文，交付给应用层中相应的应用进程。这里端口并不是指看得见、摸得着的物理端口，而是指用来区分不同应用进程的标识

“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据。但事实上，这两条数据并没有一条水平方向的物理连接，要传送的数据是沿着图中上下多次的虚线方向传送的。

​ 运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等)，它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
​ 根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP，这两种协议就是本章要讨论的主要内容。

总结

5.2 运输层端口号、复用与分用的概念

​ 运行在计算机上的进程使用进程标识符PID来标志。
​ 因特网上的计算机并不是使用统一的操作系统，不同的操作系统(windows，Linux，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.1 发送方的复用和接收方的分用

多个进程（这里一个端口表示一个进程） 利用一个运输层协议（或者称为运输层接口）发送数据称为 复用

多个进程（这里一个端口表示一个进程） 利用一个运输层协议（或者称为运输层接口）接收时叫做 分用

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

5.2.3 运输层传输流程

浏览器输入域名，回车浏览,然后用户PC中的DNS客户端进程会发送一个DNS查询请求报文,DNS查询请求报文需要使用运输层的UDP协议,首部中的源端口字段的值，在短暂端口号49151~65535中挑选一个未被占用的，用来表示DNS客户端进程,首部中的目的端口字段的值：53，是DNS服务器端进程所使用的熟知端口号。

之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器

DNS服务器收到该IP数据报后，从中解封出UDP用户数据报,UDP首部中的目的端口号为53，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程,DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址,之后，会给用户PC发送DNS响应报文，DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报,其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报，目的端口的值设置为49152，这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号

将UDP用户数据报封装在IP数据报中，通过以太网发送给用户PC

用户PC收到该数据报后，从中解封出UDP用户数据报。UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户PC中的DNS客户端进程，DNS客户端进程解析DNS响应报文的内容，就可知道自己之前所请求的Web服务器的域名对应的IP地址。

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文。

5.3 用户数据报协议UDP和传输控制协议TCP的对比

UDP (User Datagram Protocol)和 TCP(Transmission Control Protocol) 是TCP/IP体系结构运输层中的两个重要协议

当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。

当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条不可靠信道。

5.3.1 通信时间

使用UDP协议的通信双方，可以随时发送数据。使用TCP协议通信的双方，在进行数据传输之前，必须使用’三报文握手’来建立连接，进行数据传输，数据传输结束后需要’四报文挥手’释放连接。

5.3.2 可否发送多播

UDP支持单播、多播和广播。TCP协议只支持点对点单播。

5.3.3 应用报文的处理

UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。换句话说，UDP是面向应用报文的

TCP 发送方 会把应用进程交付下来的数据块看作是一连串无结构的字节流，TCP并不知道这些待传送的字节流的含义，并将他们编号，存储在自己的发送缓存中，TCP会根据发送策略，提取一定量的字节来构建TCP报文并发送。

TCP接收方 一方面从所接受到的TCP报文段中，取出数据载荷部分并存储在接收缓存中;一方面将接收缓存中的一些字节交付给应用进程；TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块，具有对应大小的关系（例如，发送方应用进程交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块，就把收到的字节流交付给了上层的应用进程，但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样)；接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据；TCP是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

5.3.4 可靠服务与不可靠服务

UDP向上层提供无连接不可靠传输服务。仅仅丢弃产生误码、丢失的数据报.适用于（IP电话、视频会议等实时应用）

TCP向上层提供面向连接的可靠传输服务。适用于要求可靠传输的应用，如文件传输

5.3.5 UDP数据报的首部与TCP报文段的首部

UDP数据报由首部和数据载荷两部分构成。其首部仅有四个字段。每个字段长度为两个字节。由于UDP不提供可靠传输服务，仅在网际层的基础上添加了用于区分应用进程的端口。

TCP数据报由首部和数据载荷两部分构成。其首部最小长度为20字节，最大长度为40字节。

5.4 TCP的流量控制

一般来说，我们总是希望数据传输得更快一些。

• 但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。

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

举例

假设A、B主机已建立TCP连接，A给B发送数据，B对A进行流量控制。若B告诉A，“接收窗口为400”，则主机A将自己的发送窗口也设置为400，意味着主机A在未收到主机B的确认时，将序号落入发送窗口的数据全部发送出去。

ACK为TCP报文段首部中的标志位，ACK=1表明这是一个TCP确认报文段。ack为TCP报文段首部中的确认号字段，取值201，表示对之前接收数据的累计确认。rwnd是TCP报文段首部中的窗口字段，取值300表示自己接收的窗口大小为300。

主机A收到该累计确认后，将窗口向前滑动，使已发送并收到确认的这些数据的序号移除发送窗口。由于主机B将自己的接收窗口调整为了300，故主机A也将自己的发送窗口调整为300。

上图主机A现在可将发送缓存中序号201~500的字节数据全部删除，因为已经收到了主机B对它们的累计确认。由于主机B将自己的接收窗口调整为了100，故主机A也将自己的发送窗口调整为100。

上图主机A现在可将发送缓存中序号201~500的字节数据全部删除，因为已经收到了主机B对它们的累计确认。由于主机B将自己的接收窗口调整为了0，故主机A也将自己的发送窗口调整为0。

解决方法

上图如果零窗口探测报文在发送过程中如果丢失，还是能打破死锁局面

因为零窗口探测报文段也有重传计时器，重传计时器超时后，零窗口探测报文段会被重传

5.5 TCP拥塞控制

5.5.1 概念

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

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

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

网络拥塞往往是由许多因素引起的。例如：

1. 点缓存的容量太小；
2. 链路的容量不足；
3. 处理机处理的速率太慢；
4. 拥塞本身会进一步加剧拥塞；

拥塞控制的一般原理

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

5.5.2 拥塞控制的算法

TCP的四种拥塞控制算法：慢开始(slow-start)、拥塞避免(congestion avoidance)、快重传(fast retransmit)、快恢复(fast recovery)

5.5.2.1 慢开始和拥塞避免

传输轮次：

• 发送方给接收方发送数据报文段后，接收方给发送方发发回相应的确认报文段
• 一个传输轮次所经历的时间其实就是往返时间，往返时间并非是恒定的数值
• 使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并受到了对已发送的最后一个报文段的确认

拥塞窗口：

• 它会随网络拥塞程度，以及所使用的拥塞控制算法动态变化

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

在TCP双方建立逻辑关系连接时，拥塞窗口的值(cwnd)被设置为1，即传输轮次为0时，拥塞窗口的值为1。慢开始门限的初始值（ssthresh=16），在执行慢开始算法时，发送方每收到一个对新报文段的确认时，就将拥塞窗口值加1，然后开始下一轮次传输

图中swnd是发送窗口,每经过一个传输轮次，拥塞窗口就加倍,窗口大小按指数增加，$2^{n-1}$

拥塞避免（congestion avoidance）

• 思路：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。
• 每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
• 使拥塞窗口 cwnd 按线性规律缓慢增长。
• 在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

若在传输过程中，丢失了部分报文段，会超时重传。将慢开始门限值更新为发送拥塞窗口值的一半，并将拥塞窗口值减小为1，重新开始执行慢开始算法。

完整示意图

5.5.2.2 快重传和快恢复

5.6 TCP超时重传时间的选择

超时重传时间的选择是TCP最复杂的问题。

如果超时重传时间RTO的值设置得比RTT0的值小很多，这会引起报文段不必要的重传，使网络负荷增大

如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率.

因此,超时重传时间RTO的值，应略大于往返时间RTT的值。

5.6.1 RFC6298建议使用下式计算超时重传时间RTO

往返时间RTT的测量比较复杂

当产生重传时，不知道收到的确认是对源报文段的确认还是对重传报文段的确认，因此会产生错误。

5.7 TCP可靠传输的实现

5.8 TCP的运输连接管理

TCP是面向连接的协议，它基于运输连接来传送TCP报文段。
TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

TCP的运输连接管理就是使运输连接的建立和释放都能正常地进行。

5.8.1 TCP的连接和建立

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

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

5.8.1.1 TCP使用“三报文握手”建立连接

主动发起连接建立的应用进程叫做TCP客户 (client)。

被动等待连接建立的应用进程叫做TCP服务器 (server)。

我们将TCP建立连接的过程比喻为“握手”，“握手”需要在TCP客户端和服务器之间交换三个TCP报文段

最初两端的TCP进程都处于关闭状态

一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等；之后，就准备接受TCP客户端进程的连接请求；此时，TCP服务器进程就进入监听状态，等待TCP客户端进程的连接请求

TCP服务器进程是被动等待来自TCP客户端进程的连接请求，因此成为被动打开连接

TCP客户进程也是首先创建传输控制块

由于TCP连接建立是由TCP客户端主动发起的，因此称为主动打开连接

然后，在打算建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态,在TCP连接请求报文段首部中

• 同步位SYN被设置为1，表明这是一个TCP连接请求报文段
• 序号字段seq被设置了一个初始值x，作为TCP客户端进程所选择的初始序号

请注意：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号

TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态

TCP连接请求确认报文段首部中

• 同步位SYN和确认为ACK都设置为1，表明这是一个TCP连接请求确认报文段
• 序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号，
• 确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号（seq）的确认

请注意：这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号

TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已连接状态

普通的TCP确认报文段首部中

• 确认位ACK被设置为1，表明这是一个普通的TCP确认报文段

• 序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，所以TCP客户进程发送的第二个报文段的序号为x+1

• 确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认

请注意：TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号

为什么TCP客户进程最后还要发送一个普通的TCP确认报文段？能否使用“两报文握手”建立连接？

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

5.8.1.2 小结

5.8.2 TCP的连接释放

5.8.2.1 TCP通过“四报文挥手”来释放连接

现在TCP客户进程和TCP服务器进程都处于连接已建立状态

TCP客户进程的应用进程通知其主动关闭TCP连接

TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态

TCP连接释放报文段首部中

- 终止位FIN和确认为ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
- 序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1
- 确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1

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

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态

普通的TCP确认报文段首部中

- 确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段
- 序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，这也与之前收到的TCP连接释放报文段中的确认号匹配
- 确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认

TCP服务器进程应该通知高层应用进程，TCP客户进程要断开与自己的TCP连接

此时，从TCP客户进程到TCP服务器进程这个方向的连接就释放了

这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了

但如果TCP服务器进程还有数据要发送，TCP客户进程仍要接收，也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭.

TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段。

若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接。

由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接。

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

该报文段首部中

- 终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
- 序号seq字段的值为w，这是因为在半关闭状态下，TCP服务器进程可能又发送
- 确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认

TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态

该报文段首部中

- 确认为ACK的值被设置为1，表明这是一个普通的TCP确认报文段
- 序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号
- 确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认

TCP服务器进程收到该报文段后就进入关闭状态，而TCP客户进程还要经过2MSL（最短报文段寿命）后才能进入关闭状态。

TCP客户进程在发送完最后一个确认报文后，为什么不直接进入关闭状态？而是要进入时间等待状态？

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

另外，TCP客户进程在发送完最后一个TCP确认报文段后，在经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段

5.8.2.2 TCP保活计时器的作用

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

5.9 TCP报文段的首部格式

为了实现可靠传输，TCP采用了面向字节流的方式。

但TCP在发送数据时，是从发送缓存取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送。

• 一个TCP报文段由首部和数据载荷两部分构成;
• TCP的全部功能都体现在它首部中各字段的作用。

与IP数据报首部格式相似，都是由20字节的固定首部和最大40字节的扩展首部构成。

5.9.1 序号、确认号和确认标志位

5.9.2 数据偏移、保留、窗口和校验和

5.9.3 同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针

5.9.4 选项和填充

• 一个TCP报文段由首部和数据载荷两部分构成;
• TCP的全部功能都体现在它首部中各字段的作用。

[外链图片转存中…(img-KnOjDUZt-1637154259444)]

与IP数据报首部格式相似，都是由20字节的固定首部和最大40字节的扩展首部构成。

[外链图片转存中…(img-PXjVHWcq-1637154259445)]

5.9.1 序号、确认号和确认标志位

[外链图片转存中…(img-V9s3wfYY-1637154259445)]

5.9.2 数据偏移、保留、窗口和校验和

[外链图片转存中…(img-PTWb9zOP-1637154259446)]

5.9.3 同步标志位、终止标志位、复位标志位、推送标志位、紧急标志位和紧急指针

[外链图片转存中…(img-YCtLBW6H-1637154259446)]

5.9.4 选项和填充

[外链图片转存中…(img-xMkEBL1K-1637154259448)]