计算机网络第五章——运输层

运输层的概述

之前文章所介绍的计算机网络体系结构中的物理层，数据链路层以及网络层，他们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。

运输层的任务

如何为运行在不同主机上的应用进程提供直接的通信服务，运输层协议又称为端到端协议，如图所示运输层的作用范围是应用进程到应用进程，也称为端到端。

（AP指的是应用进程，进程是操作系统资源分配的基本单位）

局域网1上的主机与局域网2上的主机，通过互联的广域网进行通信，网络层的作用范围是主机到主机，但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。

运输层和网络层的不同

由上图可知：

• 网络层解决的问题是，将数据从一台主机送到另一台主机，因此网络层解决的是主机到主机的问题。
• 传输层从上方进程拿到数据后，该数据贯穿网络协议栈进行封装和解包，最终到达对方传输层，此时对方传输层也会将数据向上交给对应的进程，因此传输层解决的是进程到进程的问题。

运输层的具体工作流程

如图：

假设AP1与AP4之间进行基于网络的通信，AP2与AP3之间进行基于网络的通信，在运输层需要不同的端口来对应不同的应用进程，然后通过网络层及其下层来传输应用层报文。

需要注意的是这里的端口并不是指看得见摸得着的物理端口，而是指用来区分不同应用进程的标识符。为了简单起见，在学习和研究运输层时，我们可以简单的认为，运输层直接为应用进程间的逻辑通信提供服务。逻辑通信的意思是运输层之间的通信好像是沿水平方向传送数据，但事实上这两个运输层之间并没有一条水平方向的物理连接，要传送的数据是沿着图中上下多次的虚线方向传送的，运输层向高层用户屏蔽了下面网络核心的细节，如网络拓扑所采用的路由选择协议等，它是应用层看见的，就好像是在两个运输层实体之间，有一条端到端的逻辑通信信道，根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输层协议，面向连接的TCP协议和无连接的UDP协议。这两种协议就是本章中要讨论的主要内容。

运输层端口号

在计算机网络结构体系中，端口号用来区分系统内的不同应用进程。

发送方的复用、接收方的分用的概念

应用层报文是网络中交换与传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，其长短很不一致，长度不限且可变。

如下图是应用报文发送接收的过程：

• UDP复用：发送方的某些应用进程所发送的不同应用报文，在运输层使用UDP协议进行封装

• TCP复用：另一些应用进程做发送的不同应用报文，在运输层使用TCP协议进行封装

• IP复用：运输层使用端口号来区分不同的应用进程。不管是使用运输层的UDP协议，封装成的UDP用户数据报，还是使用TCP协议封装成的TCP报文段，在网络层都需要使用IP协议封装成IP数据报

接收方收到IP数据报后，进行IP分用，若IP数据报首部装协议字段的值为17，则把IP数据报的数据载荷部分所封装的UDP，用户数据报上交运输层的UDP

若IP数据报首部协议字段的值为6，则把IP数据报的数据载荷部分所封装的TCP报文段，上交运输层的TCP。

• UDP分用 和 TCP分用

运输层对UDP用户数据报进行UDP分用，对TCP报文段进行TCP分用，也就是根据端口号将它们交付给上层相应的应用进程。
 

运输层熟知端口号

下面我们给出TCP/IP体系的应用层常用协议所使用的运输层熟知端口号：

不管在运输层使用UDP还是TCP协议，在网络层都需要使用IP协议，IP数据报首部中协议字段的值，表明了IP数据报数据载荷部分封装的是何种协议数据单元。

UDP协议 和 TCP协议 的对比

如上图，TCP协议 （ 传输控制协议 ）和 UDP协议（ 用户数据报协议 ）是TCP/IP体系结构运输层中非常重要的两个协议，TCP/IP体系结构应用层中的某些协议，‍‍有的需要使用运输层的TCP提供的服务，而另一些协议需要使用运输层的UDP提供的服务。

UDP协议 和 TCP协议 的对比：

1.通信 连接方式不同

如上图，

• 使用UDP协议的通信双方‍‍可以随时发送数据。

• 使用TCP协议的通信双方‍‍在进行数据传输之前，必须使用三报文握手来建立TCP连接，TCP连接建立成功后‍‍才能进行数据传输结束后，必须使用四报文挥手来释放TCP连接。‍‍

• 需要注意的是这里所谓的连接是指逻辑连接关系，‍‍而不是物理连接。‍‍

综上所述，UDP是无连接的，而TCP是面向连接的。

2.支持的通信方式（对象个数）不同

• 这是某个局域网上的需要UDP协议进行通信的4台主机，其中任何一台主机‍‍都可向其他三台主机发送广播，也可以向某个多播组发送多播，‍‍还可以向某台主机发送单播，也就是说UDP支持单播多播以及广播。‍‍换句话说，UDP支持一对一，一对多以及一对全的通信。‍‍
• 再来看使用TCP协议的情况，使用TCP协议的通信双方在进行数据传输之前，‍‍必须使用三报文握手来建立TCP连接，TCP连接建立成功后，通信双方之间‍‍就好像有一条可靠的通信信道，通信双方使用这条基于TCP连接的可靠信道进行通信，很显然‍‍ TCP仅支持单播，也就是一对一的通信。
   

3.对应用报文的处理不同

• UDP协议是面向应用报文的，其拿到数据报后，只是添加或删除一个UDP首部

• TCP协议是面向字节流的，发送方的TCP‍‍把应用进程交付下来的数据块，仅仅看作是一连串的无结构的字节流，‍‍TCP并不知道这些待传送的字节流的含义，仅将他们编号并存储在自己的发送缓存中。‍‍TCP根据发送策略，从发送缓存中提取一定数量的字节，构建TCP报文段并发送‍‍。接收方的TCP，‍‍一方面从所接收到的TCP报文段中取出数据载荷部分并存储在接收缓存中，一方面将接收缓存中的一些字节交付给应用进程，‍‍TCP不保证接收方应用进程所收到的数据块与发送方应用进程和发出的数据块‍‍具有对应大小的关系。例如发送方应用进程交给发送方的TCP，共10个数据块，‍‍但接收方的TCP可能只用了4个数据块，就把收到的字节流交付给了上层的应用进程，‍‍但接收方应用进程收到的字节流‍‍必须和发送方应用进程发出的字节流完全一样。‍‍当然接收方的应用进程‍‍必须有能力识别收到的字节流，把它还原成有意义的应用层数据，也就是说‍‍ TCP是面向自字节流的，这正是TCP实现可靠传输，流量控制以及拥塞控制的基础。
   

4.传输服务不同

• 对于UDP用户数据报出现的误码和丢失等问题，UDP并不关心。‍‍基于UDP的这个特点，‍‍UDP适用于实时应用，例如IP电话、视频会议等。
• 尽管网际层中的IP协议向上层提供的是无连接不可靠的传输服务，也就是说‍‍ IP数据报可能在传输过程中出现丢失或误码，但只要运输层使用TCP协议，‍‍就可向其上层提供面向连接的可靠传输服务。我们可将其想象成使用TCP协议的收发双方，‍‍基于TCP连接的可靠性到进行数据传输，不会出现误码‍‍丢失、乱序以及重复等传输差错。TCP适用于要求可靠传输的应用，‍‍例如文件传输。‍‍
   

5.UDP用户数据报的首部与TCP报文段的首部不同

总结：

TCP的流量控制

• 一般来说我们总是希望数据传输的更快一些
• 但如果发送方把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失
• 所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收
• 利用滑动窗口机制，可以很方便的在TCP连接上实现对发送方的流量控制

举例：

主机A与主机B建立TCP连接，A给B发送数据，B对A流量控制。

总的来说就是，A是用滑动窗口机制来发送数据，B会根据自身情况通知A，然后A会调整窗口大小。

这边建议还是看视频更好理解。

小结：

TCP的拥塞控制

TCP的4种拥塞控制算法：

• 慢开始
• 拥塞避免
• 快重传
• 快恢复

我们来举例说明TCP这4种拥塞控制算法的基本原理，为了集中精力讨论拥塞控制，我们假定如下条件：

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

假设这是TCP的发送方和接收方，发送方给接收方发送TCP数据报文段，接收方收到后给发送方发送TCP确认报文段：
 

慢开始、拥塞避免

慢开始：有个ssthresh值（峰值），在达到ssthresh之前，发送方每接收一个接收方发来的确认报文，cwnd会呈2的倍数增加（1，2，4，8...）；拥塞避免：当到达ssthresh后，发送方每接收一个接收方发来的确认报文，cwnd只会增加1（1，2，3，4...），当发送方没有按时收到应当到达的确认报文时（即发送超时重传--“当发送方发送数据包后,会启动一个重传计时器,等待接收方返回确认报文。如果在计时器超时之前仍未收到确认报文,发送方会认为数据包丢失,触发超时重传。”），判断网络很可能出现了拥塞，ssthresh会减少到发生拥塞时cwnd的一半，cwnd减少到1，并重新开始慢开始。

快重传算法、快恢复算法

有的时候，如果个别报文段在网络中丢失了并且网络中没有拥塞，就会导致发送方误认为网络拥塞而导致了超时重传，就会减少ssthresh和cwnd的值，降低网络的吞吐量。

快重传算法

可以让发送方尽早知道“发生了个别报文段的丢失”。所谓快重传是发送方尽快进行重传，而不是等超时重传计时器超时再重传

这就要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，
即使收到了失序的报文段，也要立即发送确认报文，对已收到的报文段的重复确认，
发送方一旦收到三个连续的重复确认，就将相应的报文段（指的是丢失的报文段）立即重传，而不是等该报文段（丢失报文段）的重传计时器超时再重传。

快恢复算法

当数据在网络中发生丢失时，由于还有部分数据还在互联网中向接收方流动，TCP协议并不想突然执行慢启动（cwnd设置为1）减少数据流的发送，这样由于网络的短暂波动影响了整条链路的数据发送。

快速重传算法用一句话描述：当收到3个重复报文的ack时，TCP不等待重传超时时间，立即重传该数据包

快速恢复算法用一句话描述：当发现有报文丢失时，并不会立刻进入慢启动状态，而是通过很巧妙的方法，即保证的在数据重传过程中的拥塞避免，又能在数据确认时的快速恢复

TCP超时重传时间的选择

我们都知道，发送方每发送一个TCP数据报文段就会启动一个重传计时器，其重传计时器的时间也叫超时重传时间RTO。由于网络中路由器的速率以及每条网络路径的带宽不同，我们很难统一RTO的大小，而RTO过大或过小都会导致下图问题：

所以，我们只能根据实际情况动态的确定RTO的大小，以下给出公式：

注意⚠️：若出现超时重传，则不采用上述公式计算RTO，而是将新RTO的值取为旧RTO值的两倍。

TCP可靠传输的实现

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

TCP 是每发送一个数据，就需要等待对方进行ACK确认应答，这显然会极大的影响传输的速率。在发送数据的时候，最好的方式是一下将所有的数据全部发送出去，然后一起确认。于是就引入了窗口的概念，这个所谓的窗口实际上是操作系统开辟的一个缓存空间，发送方在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答后，此时数据就可以从缓存区清除，同样接收方接收数据后也是放在这个缓存区中的，那么接收方缓存区还能接收多少数据，这个就是决定窗口大小的因素，如果发送方的数据超过接收方缓存区的大小，那会造成接收方数据溢出，这就会导致数据丢失。所以，通常窗口的大小是由接收方的窗口大小来决定的。发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

滑动窗口并不是固定的，它主要是根据接收方的接收情况，动态去调整窗口大小，然后来控制发送方的数据流量。

并且，接收方 发送给 发送方 的确认报文段中携带着接收方的窗口大小以及已经接收到的数据报文段的序号ack。

补充：

小结：

TCP的运输连接管理

TCP是面向连接的协议，它基于运输连接来传送TCP报文段，

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

TCP运输连接有以下三个阶段，

1. 第一个阶段是建立TCP连接，也就是通过三报文握手来建立TCP连接。
2. 第二个阶段是数据传送，也就是基于已建立的TCP连接，进行可靠的数据传输。
3. 第三个阶段是释放连接，也就是在数据传输结束后，还要通过四报文挥手来释放TCP连接。

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

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

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

TCP的连接（三报文握手）

具体过程：

• 这是两台要基于TCP进行通信的主机，其中一台主机中的某个应用进程，主动发起TCP连接，建立称为TCP客户。另一台主机被动等待TCP连接建立的应用进程，称为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客户进程主动发起的，因此称为主动打开连接。
   

SYN表示synchronization，原意是同步的意思。打开就意味着客户端想和服务端进行数据的同步，在同步以后(也就是三次握手之后)，客户端和服务端就可以互相发送消息。
seq表示sequence，原意为序号。需要这个seq是因为应用程序可能连续发送多个序号给服务器，有了seq就可以有依据判断哪些是累赘信息，ack搭配seq用于确认数据是否准确，是否正常通信。并且这个seq序号是随机生成的，作为初始值来进行后续的判断依据，保证了通道唯一性

• TCP服务器进程收到TCP连接请求报文段后。如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态。该报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段。序号字段seq被设置了一个初始值Y，作为TCP服务器进程所选择的初始序号，确认号字段ack的值被设置成了X+1，这是对TCP客户进程所选择的初始序号的确认。请注意这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号
   

ACK表示Acknowledgment，原意为确认。当ACK和SYN一起开启表示确认同步
小写的ack表示的确认序号，也就是说光有自己的序号seq还不够，还要有确认序号ack，这个ack是根据客户端的序号+1得到的，这样客户端在收到号码后-1就知道是不是自己发送的TCP报文了

• TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已建立状态。该报文段首部中的确认位ACK被设置为1，表明这是一个普通的TCP确认报文段，序号字段seq被设置为X+1，这是因为 TCP客户进程发送的第一个TCP报文段的序号为X并且不携带数据，因此第二个报文段的序号为X+1。请注意TCP规定，普通的TCP确认报文段可以携带数据，但如果不携带数据则不消耗序号。在这种情况下，所发送的下一个数据报文段的序号仍是X+1，确认号字段ack被设置为Y+1，这是对TCP服务器进程所选择的初始序号的确认。
   
• TCP服务器进程收到该确认报文段后也进入连接已建立状态。现在TCP双方都进入了连接已建立状态，他们可以基于已建立好的TCP连接进行可靠的数据传输了。

为什么用的是三报文握手而不是两报文握手？

为了防止已失效的连接请求报文段突然又传送到TCP服务器而导致错误

TCP的连接释放(4次挥手)

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

具体流程：

那么 TCP客户进程在发送完最后一个确认报文段后，为什么不直接进入关闭状态，而是要进入时间等待状态，两倍MSL后才进入关闭状态，这是否有必要呢？

来看这种情况，TCP服务器进程发送TCP连接释放报文段后进入最后确认状态，TCP客户进程收到该报文段后，发送普通的TCP确认报文段，并进入关闭状态，而不是时间等待状态。然而该TCP确认报文段丢失了，这必然会造成TCP服务器进程，对之前所发送的TCP连接释放报文段的超时重传，并仍处于最后确认状态。重传的TCP连接释放报文段到达TCP客户进程，由于TCP客户进程属于关闭状态，因此不理睬该报文段，这必然会造成 TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态，而无法进入关闭状态。

因此时间等待状态以及处于该状态两倍MSL的时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态。另外TCP客户进程在发送完最后一个TCP确认报文段后，再经过两倍MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段。以上就是TCP通过4报文挥手释放连接的过程。

最后我们再来看看TCP中饱和计时器的作用。设想这样一种情况，TCP双方已经建立了连接，后来TCP客户进程所在的主机突然出现了故障，显然 TCP服务器进程以后就不能再收到TCP客户进程发来的数据，因此应当有措施使TCP服务器进程，不要再白白等待下去。换句话说，TCP服务器进程应该如何发现这种情况？

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

TCP报文段的格式

接下来我们就来看看TCP报文段的首部格式，TCP报文段的首部格式与IP数据报的首部格式类似，都是由二十字节的固定首部和最大四十字节的扩展首部构成。

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

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

• 序号 如图所示：如图所示，请注意他们是字节数据的序号而不是内容（一段数据被分成多组，字节数据的序号指的是这一组数据的第一个在所有数据中的序号）。

• 确认号 如图所示：

• 确认标志位ACK 如图所示：

• 数据偏移 如图所示：

• 保留：为今后使用，目前为0

• 窗口：该字段指出的是发送本报文段的一方的接收窗口，而其中的 “窗口值” 作为接收方让发送方设置其发送窗口的依据，这是以接收方的接收能力来控制发送方的发送能力，也就是所谓的流量控制，需要注意的是发送窗口的大小还取决于拥塞窗口的大小，也就是应该从接收窗口和拥塞窗口中取小者

• 校验和:用来检查整个TCP报文段在传输过程中是否出现了误码，与UDP类似

• 同步标志位SYN，该标志位在TCP连接建立时用来同步序号：

该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。TCP客户进程发送的TCP连接请求报文段，首部中的同步标志位SYN被置1，表明这是一个TCP连接请求报文段

• 终止标志位FIN，该标志位用来释放TCP连接：

如图所示，TCP通过四报文挥手释放连接的过程，不管是TCP客户进程还是TCP服务器进程，他们所发送的TCP连接释放报文段，首部中的终止标志位FIN都被置1，表明这是TCP连接释放报文段

• 复位标志位RST用来复位TCP连接，当RST等于1时表明TCP连接出现了异常，必须释放连接，然后再重新建立连接，RST置1还可以用来拒绝一个非法的报文段，或拒绝打开一个TCP连接

• 推送标志位PSH用来实现推送操作。当接收方的TCP收到该标志位为1的报文段，会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。

• 紧急标志位URG和紧急指针字段用来实现紧急操作。紧急标志为URG取之为1时，紧急指针字段有效，取值为0时，紧急指针字段无效，紧急指针字段占16比特，以字节为单位，用来指明紧急数据的长度。当发送方有紧急数据时，可将紧急数据插队的发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据，接收方收到紧急标志为1的报文段，会按照紧急指针字段的值，从报文端数据载荷部分取出紧急数据，并直接上交应用进程，而不必在接收缓存中排队。

• 扩展 如图所示:

个人小结：

首先我们要理清楚在真正的通信中，通信的实体是不同主机中的进程，而为了区分一个主机中的进程，我们引入了端口号这一概念，知道这些后，我们接着就可以区分运输层和网络层（端到端 vs 主机到主机），紧接着给出运输层的大致工作流程（这里涉及到了分用和复用），接着介绍了运输层中两个重要的协议：TCP , UDP 。给出了他们两个不同以及概述，接着又详细介绍了TCP的功能（流量控制、拥塞控制、超时重传时间选择、可靠传输的实现），以及最最重要的TCP连接管理（三报文握手--数据传送--四报文挥手）。最后详细介绍了TCP报文段的构成以及其首部各字段作用。

参考：【计算机网络】运输层-CSDN博客