计算机网络-运输层

zoeil

已于 2023-10-09 19:13:52 修改

阅读量4.9k

点赞数

分类专栏：计算机网络文章标签：计算机网络网络服务器

于 2023-07-08 08:30:00 首次发布

本文链接：https://blog.csdn.net/m0_62946761/article/details/131488269

版权

计算机网络专栏收录该内容

7 篇文章 4 订阅

订阅专栏

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

一、运输层概述

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

但实际上在网络中进行通信的真正实体是位于通信两端主机中的进程。

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

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

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

（一）端口号

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

因特网上的计算机并不是使用统一的操作系统，不同的操作系统 (windows，Linux，Mac OS)又使用不同格式的进程标识符
为了使运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识
TCP/IP体系的运输层使用端口号来区分应用层的不同应用进程

端口号使用16比特表示，取值范围0~65535
- 熟知端口号:0~1023，IANA把这些端口号指派给了TCP/IP体系中最重要的一些应用协议，例如:FTP使用21/20，HTTP使用80，DNS使用53，HTTPS使用443。
- 登记端口号:1024~49151，为没有熟知端口号的应用程序使用。使用这类端口号必须在IANA按照规定的手续登记，以防止重复。例如: Microsoft RDP 微软远程桌面使用的端口是3389。
- 短暂端口号:49152~65535，留给客户进程选择暂时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用。
端口号只具有本地意义，即端口号只是为了标识本计算机应用层中的各进程，在因特网中，不同计算机中的相同端口号是没有联系的

（二）发送方的复用和接收方的分用

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

【举例】

用户访问www.porttest.com需要知道其IP，此时通过向DNS服务器发送数据报获取IP，数据报的的源端口选取短暂端口号49152，是主机选取的用来表示发送该报文段的浏览器进程。目标端口为DNS协议的监听端口53，查询请求的内容为域名www.porttest.com的IP地址是什么？DNS服务器接收到数据报后，给用户返回一个DNS响应结果，源端口为53，目的端口为用户那边选取的短暂端口号49152，响应的内容就是查询的www.porttest.com的IP地址

然后就可以愉快的访问该web服务器进行通信了，数据报的源端口就是用户主机开启的端口49152，目标端口就是http的监听端口80.

三、UDP和TCP的区别

UDP和TCP是TCP/IP体系结构运输层中的两个重要协议

对比图

四、TCP的流量控制

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

TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。

如下图中，B对A进行了三次流量控制。当发送窗口被调控为0时，A就不能发送了。需要等B发送调整窗口的报文。rwnd就是B的接收窗口大小。

如果B对A的窗口调整报文丢失，A在等待B的调整，B在等待A的信息，会造成死锁局面。事实上，当A的滑动窗口被调控为0时，会启动持续计时器，在此期间如果B未发送调整报文，那么计时器时间到A就会发送一个1字节的零窗口探测报文。

TCP协议规定，即使接收窗口为0，也必须接收零窗口探测报文段，确认报文段，以及携带有紧急数据的报文段。当零窗口探测报文也丢失了怎么办？事实上，零窗口探测报文也有自己的计时器。计时器时间到，会重传零窗口探测报文。

五、TCP的拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏这种情况就叫做拥塞(congestion)。
在计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等，都是网络的资源。

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

假定如下条件下面介绍四种拥塞控制算法的基本原理

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

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。

拥塞窗口cwnd的维护原则: 只要网络没有出现拥塞，拥塞窗口就再增大一些; 但只要网络出现拥塞，拥塞窗口就减少一些

判断出现网络拥塞的依据:没有按时收到应当到达的确认报文 (即发生超时重传)

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd.

维护一个慢开始门限ssthresh状态变量:

当cwnd<ssthresh时，使用慢开始算法:
当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法
当cwnd=ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法

慢开始算法，cwnd从1开始，每次成倍增长，1-2-4-8，当到达慢开始门限ssthresh时，转用拥塞避免算法，此时cwnd的增长为每次+1.即第一次发送报文段0，接收到报文段确认后，第二次发送报文段1-2，接收到报文段确认后，第三次发送报文段3-6。。。当达到慢开始门限8后，每次cwnd只增加1

当cwnd为24也就是发送报文段171-194时，出现了部分报文段丢失，此时部分报文段未接收到确认报文，重传计时器结束后发送方判断出现了网络拥塞，进行以下工作：

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

然后又继续之前的流程

“慢开始”是指一开始向网络注入的报文段少，并不是指拥塞窗口cwnd增长速度慢;
“拥塞避免”并非指完全能够避免拥塞，而是指在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法(TCP Tahoe版本)

1990年又增加了两个新的拥塞控制算法(改进TCP的性能)，这就是快重传和快恢复(TCP Reno版本)

有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞

这将导致发送方超时重传，并误认为网络发生了拥塞;
发送方把拥寨窗口cwnd又设置为最小值1，并错误地启动慢开始算法，因而降低了传输效率

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

所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传.

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

六、TCP超时重传问题的选择

超时重传时间RTO的选择是TCP复杂的问题之一。

如果RTO过小，会引起不必要的重传报文段。如果过大，会使网络的空闲时间增大，降低了传输效率。

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

以下两种情况都会影响RTO和RTT的计算

① 源主机若误将确认当作是对原报文段的确认:所计算出的RTTs和RTO就会偏大，降低了传输效率

② 源主机若误将确认当作是对重传报文段的确认:所计算出的RTTs和RTO就会偏小，导致报文段没必要的重传，增大网络负荷;

针对出现超时重传时无法测准往返时间RTT的问题，Karn提出了一个算法: 在计算加权平均往返时间RTTs时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTs，进而超时重传时间RTO也不会重新计算。
这又引起了新的问题。设想出现这样的情况:报文段的时延突然增大了很多，并目之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Karn算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。这会导致报文段反复被重传。
因此，要对Karn算法进行修正。方法是: 报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是将新RTO的值取为旧RTO值的2倍。

七、TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口

那么如何描述窗口的滑动状态呢？

使用三个指针P1，P2，P3分别指向相应的字节序号

小于P1的是已发送并已收到确认的部分;
大于等于P3的是不允许发送的部分;
P3 - P1 = 发送窗口的尺寸:
P2 - P1 = 已发送但尚未收到确认的字节数
P3 - P2 = 允许发送当前尚未发送的字节数 (又称为可用窗口或有效窗口)

虽然发送方的发送窗口是根据接收方的接收窗口设置的，但在同一时刻，发送方的发送窗口并不总是和接收方的接收窗口一样大。

网络传送窗口值需要经历一定的时间滞后，并且这个时间还是不确定的
发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

对于不按序到达的数据应如何处理，TCP并无明确规定。

如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利因为发送方会重复传送较多的数据。
TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

TCP要求接收方必须有累积确认和捎带确认机制，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。

接收方不应过分推迟发送确认，否则会导致发送方不必要的超时重传，这反而浪费了网络的资源
TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认[RFC 1122]。
捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。

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客户主动发起的，因此称为主动打开连接，TCP服务器进程收到TCP连接请求报文段后，如果同意连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接受状态，该报文段首部中的同步位SYN和确认位ACK都设置为1，表明这是一个TCP连接请求确认报文段，序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号，确认位字段ack的值被设置成了x+1，这是对TCP客户端进程所选择的初始序号的确认。

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

TCP客户端接收到服务端的TCP连接请求确认报文段后，还要向TCP服务端发送一个普通的TCP确认报文段，并进入连接已建立状态，该报文段首部中的ACK字段被设置为1，表明这是一个普通的TCP确认报文段，序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据。

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

在这个情况下，所发送的下一个数据报文段的序号仍为x+1，确认段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认。TCP服务器进程收到该确认报文段后也进入连接已建立状态。至此，TCP双端可以根据已建立好的连接进行可靠的数据传输了。

问题：为什么TCP客户进程最后还要发送一个普通的TCP确认报文段呢？这是否多余？

即：能否使用两报文握手连接？

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

如下图所示，TCP客户端发送一个请求后，因为网络原因在计时器超时后仍没到达服务器，此时触发超时重传，之后服务器接收到了，给客户端发送TCP连接请求的确认，并直接进入连接已建立状态，接着客户端也进入连接已建立状态，双方通信然后释放连接。此时双方处于关闭状态，之后滞留在网络上的连接请求到达服务器，服务器以为客户端请求建立新的连接，然后回了一个确认报文段后又进入了连接已建立状态，可是客户端此时处于关闭状态，所以不理睬，但服务器仍处于连接已建立状态，这会浪费服务器的资源。

（二）TCP的断开连接-“四报文挥手”

现在TCP客户端进程和TCP服务器进程都处于连接已建立状态。假设使用TCP客户进程的应用进程通知其主动关闭TCP连接，TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态。该报文段中的终止位FIN和确认位ACK的值被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的数据报文段进行确认。序号seq字段的值设置为u，它等于客户端之前已传送过的最后一个字节的序号加1.

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

确认号ack等于v，它等于TCP客户进程之前已收到的自己的最后一个序号+1，

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态。该报文段首部中的确认位ACK的值被设置为1，表明这是一个TCP普通的TCP确认报文段，序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过数据的最后一个字节的序号加1，ack设置为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，确认号ack的值设置为w+1，这是对所受到的TCP连接释放报文段的确认。

TCP服务器接收到该确认报文段后就进入关闭状态，而TCP客户进程还要经过2MSL（MSL：最长报文段寿命，RFC793建议为2min）后才能进入关闭状态。对于现在的网络，2min可能太长了，TCP允许不同的实现可根据具体情况使用更小的MSL值

那么，TCP客户进程在发送最后一个报文段后为什么不直接进入关闭状态呢？

答案：客户进程进入时间等待以及2倍MSL再进入关闭状态，可以确保TCP客户进程可以收到最后一个TCP确认报文段而进入关闭状态。另外，TCP客户进程在发送完最后一个TCP确认报文段后，再经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失。

若TCP客户进程发送的最后一个确认报文段丢失，那么会造成TCP服务器对之前发送的TCP连接释放报文段的超时重传，并仍处于最后确认状态，重传的TCP报文段到达TCP客户进程，由于TCP客户进程属于关闭状态，因此不理睬该报文段，这必然会造成TCP服务器进程反复重传TCP连接释放报文段，并一直处于最后确认状态而无法进去关闭状态

TCP中保活计时器的作用

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

九、TCP报文段的首部格式

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

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

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

首部格式如下：

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

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

序号:占32比特，取值范围[0,2^32-1]，序号增加到最后一个后，下一个序号就又回到0。

指出本TCP报文段数据载荷的第一个字节的序号。

确认号:占32比特，取值范围[0,2^32-1]，确认号增加到最后一个后，下一个确认号就又回到0。

指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。若确认号=n，则表明到序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据

确认标志位ACK:取值为1时确认号字段才有效;取值为0时确认号字段无效

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

数据偏移:占4比特，并以4字节为单位
用来指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远，这个字段实际上是指出了TCP报文段的首部长度。

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

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

窗口: 占16比特，以字节为单位。指出发送本报文段的一方的接收窗口

窗口值作为接收方让发送方设置其发送窗口的依据
这是以接收方的接收能为来控制发送方的发送能力，称为流量控制!

发送窗口的大小还取决于拥塞窗口的大小，也就是要在拥塞窗口和接收窗口中取小者

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

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

同步标志位SYN:在TCP连接建立时用来同步序号

终止标志位FIN:用来释放TCP连接。

复位标志位RST: 用来复位TCP连接

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

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

紧急标志位URG:取值为1时紧急指针字段有效;取值为0时紧急指针字段无效。
紧急指针:占16比特，以字节为单位，用来指明紧急数据的长度
当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。

最大报文段长度MSS选项:TCP报文段数据载荷部分的最大长度

窗口扩大选项:为了扩大窗口(提高吞吐率)。

时间戳选项: