【计算机网络】传输层

最新推荐文章于 2023-05-02 07:30:00 发布

果果果酱

最新推荐文章于 2023-05-02 07:30:00 发布

阅读量609

点赞数

分类专栏：计算机基础

本文链接：https://blog.csdn.net/m0_37728010/article/details/95723637

版权

计算机基础专栏收录该内容

6 篇文章 0 订阅

订阅专栏

传输层

1 传输层协议概述
2 用户数据报协议UDP
- 2.1 UDP概述
- 2.2 UDP的首部格式
3 传输控制协议TCP概述
- 3.1 TCP最主要特点
- 3.2 TCP的连接
4 可靠传输的工作原理
5 TCP报文段的首部格式
6 TCP可靠传输的实现
7 TCP的流量控制
- 7.1 利用滑动窗口实现流量控制
- 7.2 必须考虑传输效率*
8 TCP的拥塞控制
9 TCP传输连接管理

1 传输层协议概述

1.1 进程之间的通信

从通信和信息的处理的角度看，传输层向它上面的应用提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。

当网络的边缘部分中的两个主机使用网络中的核心部分的功能进行端到端的通信时，只有主机的协议栈才有传输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。

从传输的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。

传输层提供应应用进程间的逻辑通信。逻辑通信的意思是：传输层之间的通信好像是沿水平方向传送数据。但事实上这两个传输层之间并没有一条水平方向的物理连接。要传输的数据是经过多个层次传送的。

传输层和网络层区别：

传输层为应用进程之间提供端到端的逻辑通信；
网络层为主机之间提供逻辑通信。

传输层会对收到的报文会进行差错检测。在网络层，IP数据报仅对首部进行检错，而不检查数据部分。

传输层向高层用户屏蔽了下面网络核心的细节，它使应用进程看见的就是好像在两个传输层实体之间有一条端到端的逻辑通信信道，但这条逻辑通信信道对上层的表现却因传输层使用不同的协议有很大的差别。

1.2 传输层的两个重要协议

根据应用程序的不同需求，有两种面向连接的传输协议：

面向连接的TCP（Transmission Control Protocol，用户数据报协议）
无连接的UDP（User Datagram Protocol，用户数据报服务）

使用TCP时，尽管下面的网络是不可靠的（只提供仅最大努力服务），但是传输层之间的逻辑通信信道就相当于一条全双工的可靠信道；

但使用UDP时，传输层之间的逻辑通信信道仍然是不可靠信道。

使用TCP时，传输层在通信时对等层之间传送的数据单位叫做 “TCP报文段” ；使用UDP时，叫做 “UDP用户数据报”。

1.3 传输层的端口

传输层重要功能——复用和分用。
复用（multiplexing）：把发送方不同的应用进程都可以使用用一个运输层协议传送数据（需要加上适当的首部），即应用层的所有的应用进程都可通过传输层送到IP层；
分用（demultiplexing）：接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程，即IP层收到数据后必须交付给指明的应用进程。

在传输层中，使用协议端口号，简称端口，来标识单个计算机中的进程。也就是说：虽然通信的终点是应用进程，但只要把传送的报文交到目的主机的某一个合适的目的端口，最后交付给目的进程的工作就由TCP来完成。
注意：在协议栈层间的抽象的协议端口是软件端口，与路由器和交换机上的硬件端口是不同的。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程和传输实体进行层间交互的一种地址。

TCP/IP的传输层用一个16位的端口号来标志一个端口。端口号只有本地意义，只是为了标志本计算机应用层中的各个进程在和传输层交互时的层间接口。在因特网不同计算机中，相同的端口号时没有关联的。

因特网上的计算机通信是客户-服务器方式。客户在发起通信请求时，必须先知道对方服务器的IP地址和端口号。因此端口号分为两大类：

服务器端使用的端口号，再分为两类：
- 熟知端口号（系统端口号）：0~1023
- 登记端口号（1024~49151）
客户端使用的端口号
仅在用户进程运行时才动态选择，因此又叫短暂端口号。数值49152~65535

在这里插入图片描述
FTP(File Transfer Protocol, 文件传输协议)：21
TELNET(远程终端协议)：23
SMTP(Simple Mail Transfer Protocol, 简单邮件传输协议)：25
DNS(Domain Name System, 网域名称系统)：53
TFTP(Trivial File Transfer Protocol, TFTP, 小型文件传输协议)：69
HTTP(HyperText Transfer Protocol, 超文本传输协议)：80
SNMP(Simple Network Management Protocol, 简单网络管理协议)：161
SNMP(trap)：162
HTTPS：443

2 用户数据报协议UDP

2.1 UDP概述

UDP协议只在IP的数据报服务之上增加了复用和分用功能以及差错检测功能。

UDP的主要特点（6点）:

UDP是无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延；
UDP使用尽最大努力交付：不保证可靠交付；
UDP是面向报文的：发送方的UDP对应用程序交下来的报文，在添加首部后就在向下交付给IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界，即UDP一次交付一个完整的报文。所以应用程序必须选测合适大小的报文，报文太长，UDP交付给IP层之后，IP在传送时可能要进行分片，这会降低IP层的效率；报文太短，则IP数据报的首部的相对长度太大，也会降低IP层的效率。
UDP没有拥塞控制：因此网络出现的拥塞不会是源主机的发送速率降低，适用于要求源主机以恒定的速率发送数据的实时应用（如：IP电话，实时视频会议等），允许在网络发生拥塞的时候丢失一些数据，但不允许数据有太大的时延。但是不适用拥塞控制功能的UDP有可能会使网络产生严重的拥塞问题。
UDP支持一对一、一对多、多对多的交互通信。
UDP的首部只有8B，开销比TCP小。

2.2 UDP的首部格式

在这里插入图片描述
UDP用户数据报有两个字段：首部字段和数据字段。
首部字段只有8个字节，由4个字段组成，每个字段的长度都是2B：

源端口：在需要对方回信时选用，不需要时可使用全0；
目的端口：在终点交付报文时必须使用到；
长度：UDP用户数据报的长度，最小为8（仅首部）；
检验和：检测UDP用户数据报在传输中是否有错。

当传输层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点——应用程序。如果端口号不正确，则由ICMP发送”端口不可达“差错报文给发送方。

UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和的时候，要在UDP用户数据报之前增加一个12B的伪首部。伪首部既不向下传送也不向上提交，仅仅为了计算检验和。
伪首部的各字段内容如下：

1~4B：源IP地址
5~8B：目的IP地址
9B：0
10B：17，UDP协议字段值为17
11~12B：UDP长度

UDP计算校验和的方法和计算IP数据报首部校验和的方法相似，但是UDP是把首部和数据部分一起都检验。
在这里插入图片描述

检验时：

发送方先把全零字段放入检验和字段；
把伪首部以及UDP用具数据报看成是由许多16B的子串接起来的；（如果不整，则填入0）；
用二进制反码计算出这些16位字的和，再将此和的二进制反码写入检验和字段；
发送UDP数据报；
接收方将接受到的UDP数据报连通伪首部一起，按照二进制反码求这些16位字的和。无差错则应为全1。若出错则丢弃这个数据报。

这种差错检验能力不强，但是简单，处理起来较快。

3 传输控制协议TCP概述

3.1 TCP最主要特点

TCP协议最主要的5个特点：

TCP是面向连接的传输层协议；
每一条TCP连接只能有两个端点，每一条TCP连接只能是一对一的；
TCP提供可靠交付，即TCP连接传送的数据无差错、无丢失、无重复，且按序到达；
TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接受缓存，用来临时存放双向通信的数据；
面向字节流。TCP中的 “流” 指的是流入进程或从进程流出的字节序列。“面向字节流” 的含义是：虽然应用程序和TCP的交互式一次一个数据块（大小不等），但TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。

TCP连接是一条虚连接而不是一条真正的物理连接。TCP报文段先要传送到IP层，加上IP首部后，再传送到数据链路层。加上数据链路层的首部和尾部后，才离开主机发送到物理链路。

TCP不关心应用进程一次把多长的报文发送到TCP的缓存中。TCP会根据对方给出的窗口值和当前网络拥塞的程度决定一个报文段应包含多少个字节。（长的可以分割，短的可以拼接）。

3.2 TCP的连接

TCP连接是由协议软件所提供的一种抽象。
TCP连接的端点是 套接字（Socket） 或称作插口。（不是主机！不是进程！不是端口！）。端口号拼接到IP地址即构成了套接字。所以
$套接字 s o c k e t : = (I P 地址：端口号)$

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定，即：
$TCP连接 ::= \{socket1,socket2\} = \{(IP1: port1), (IP2: port2)\}$

注意：

同一个IP地址可以有多个不同的TCP连接；
同一个端口号也可以出现在多个不同的TCP连接中。

4 可靠传输的工作原理

4.1 可靠传输

理想的传输条件的两个特点：

传输信道不产生差错；
不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

TCP把数据是叫交给IP层处理的，但是IP层只能尽最大努力交付，所以要是要一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接受方来不及处理收到数据时，及时告诉返送发适当降低发送数据的速度。

4.2 停止等待协议

4.2.1 ARP协议

TCP协议是全双工通信，为了方便理解，仅考虑A （发送方） 发送数据，B （接收方） 接收数据的情况。传输的单元称为分组。
“停止等待” 就是没发送问一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

1. 无差错情况
A发送分组M1，发送完就暂停发送，等待B的确认。B收到M1就向A发送确认。A收到对M1的确认之后，再发送下一个分组M2……

2. 出现差错
出现差错是指A发送分组的过程中出现错误：

B接受到了分组Mn，但检测到Mn在传输过程中出了差错，就直接丢弃Mn。
B没有接受到分组Mn，即Mn在发送过程中丢失

以上两种请款B都不会发送确认信息，A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组，即 “超时重传”。

要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前受到了对方的确认就撤销已设置的超时计时器。

注意：

A在发送完一个分组后，必须暂时保留已发送的分组的副本。只要在收到相应的确认之后才能清楚暂时保留的分组副本。
分组和确认分组都必须进行编号；
超时计时器设置的重传时间应该比数据在分组传输的平均往返时间更长一些。

3. 确认丢失和确认迟到
A. 确认丢失
即B收到了分组Mn，但发送的确认丢失了。则A在超时重传时间内没有收到确认，就重新发送Mn分组。B再次受到Mn分组之后：
step1：丢弃这个重复的分组Mn；
step2：向A发送确认。

B. 确认迟到
即B收到了分组Mn，但发送的确认在超时计时到期前还没有到达A，则A重新到发送nB收送之再发确认。这样A就可能会受到重复的确认，处理如下：直接丢弃重复的确认。

有了以上的确认重传机制，即可在不可靠的通信。
上述的这种可靠的传输协议常称为 ARQ（Automatic Repeat reQuest，自动重传请求）。意思是重传的请求是自发进行的，接收方不需要请求发送方重传某个出错的分组。

4.2.2 信道利用率

停止等待协议

优点：简单
缺点：信道利用率太低；

信道利用率U
$U = TD / (T_D+RTT+T_A)$

其中：

$T_D$ ：发送方发送分组需要的时间；
$T_A$ ：接收方发送确认需要的时间；
$R T T$ ：往返时间。

当往返时间RTT远大于分组发送时间TD时，信道的利用率就会非常低。
若出现重传，则对传送有用的数据信息来说，信道的利用率就还要低。

4.3 连续ARQ协议

连续ARQ协议，发送方需要维持一个长度为 $n$ 的窗口，意义是：位于发送窗口内的n个分组都可以连续发送出去，而不需要等待对方的确认，这样，信道利用率就提高了。

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个窗口的位置。但是接收方一般采用累积确认的方法，即接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组之后，对按序到达的最后一个分组发送确认，就表示：到这个分组为止的所有分组都已正确收到了。

5 TCP报文段的首部格式

在这里插入图片描述
源端口 / 目的端口（2B）
和UDP类似，TCP的分用复用 功能也是通过端口实现的；

序号(4B)
序号范围为 $0,2^{32}-1]$ ，共 $2^{32}$ 个。序号使用 $\rm{mod} 2^{32}$ 运算。因为在TCP连接中传送的字节流中的每一个字节都按序号编号，则首部中的序号字段的值指的是本报文段所发送的数据的第一个字节的序号。

确认号(4B)
是期望收到对方下一个报文的第一个数据字节的序号。记住：若确认号为N，则表明：到序号N-1位置的所有数据都已正确收到。

数据偏移(4bit)
实际上就是TCP报文段的首部长度。指出TCP报文段的数据起始处距离TTCP报文段的起始处有多远。因为是4bit，所以4B*2^4=60B即TCP首部的最大长度（4B是一个字节的长度）。

保留(6bit)
目前置为0；

URG紧急
当URG置为1时，发送应用程序就告诉发送方的TCP又紧急数据要传送，于是发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍然是普通数据。与紧急字段指针配合使用。

ACK确认
仅当ACK=1时，确认号字段才有效。TCP规定在连接建立后所有传送的报文段都必须把ACK置1。

PSH推送(push)
发送方把PSH置1，并立即创建一个报文段发送出去。接收方收到一个PSH=1的报文段，就尽快地交付（推）给接受应用进程。不必等到接受缓存填满止呕再向上交付。

RST复位(Reset)
当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后在重新建立传输连接。

SYN同步(Sybchromization)
在连接建立时用来同步序号。SYN=1表示这是一个连接请求或连接接收报文。当SYN=1&&ACK=0时，表明这是一个连接请求报文段。若对方同意建立连接，则应在响应的报文段中使用SYN=1 & ACK=1。

终止FIN(Finis)
当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放传输连接。

窗口
窗口字段明确指出了现在允许对方发送的数据量。窗口值是作为接收方让发送方设置其发送窗口的依据。窗口值是经常在动态变化着。

检验和
和UDP一样，需要加上12B的伪首部，检验范围包括首部和数据两个部分，检验方法也和UDP检验一样。

紧急指针
仅在URG=1时才有意义。它指出本报文段中的紧急数据的字节数。即指出了紧急数据的末尾在报文段中的位置。注意，即使窗口值为0也可以发送紧急数据。

选项
最长可使用40B。

MSS 最大报文段长度
MSS时每一个TCP报文段中的数据字段的最大长度。MSS应该尽可能大一些，只要在IP层传输时不要再分片就行，这样可以提高网络的利用率。MSS默认人为536B.
窗口扩大(3B)
原来的窗口字段长度最大为16B，对于包含卫星通道的网络，传播时延和带宽都很大，需要更大的窗口值以获得更高的吞吐率。
时间戳(10B)
有两个功能：
1.迎来计算往返时间RTT；
2.用于处理TCP序超过 $2^32$ 的情况，也称防止序号绕回（PAWS)。

6 TCP可靠传输的实现

6.1 以字节为单位的滑动窗口

假设数据传输只在一个方向上进行，即A发送数据，B给出确认。

TCP的滑动窗口时以字节为单位的。
假设A收到了B发来的确认报文段，其中窗口是20B，确认号为n，则A构造出自己的发送窗口。
A的发送窗口表示：在没有收到B的确认的情况下，A可以把窗口内的数据都发送出去。凡是发送过的数据，在未收到确认之前，都应该暂时保留，以便在超时重传时使用。
发送窗口里的序号表示允许发送的序号。窗口越大，发送方就可以再收到对方确认之前连续发送很多的数据，因而可能获得更高的传输效率。但是接收方必须来得及处理这些收到的数据。

发送窗口移动的方向设置为前。

发送窗口的后沿：
后沿的后面部分表示已经发送且已收到了确认。这些数据无需保留；发送窗口的后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）。

发送窗口的前沿：
前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。发送窗口前沿通常是不断向前移动的，但是也有可能不动：case1-没有收到新的确认，对方通知的窗口大小也没有改变；case2-收到了新的确认，后沿向前移动了α位，但是窗口被通知缩小了α位，则前沿保持不变。（前沿有可能会后缩，但是TCP强烈不赞成这样做）。

发送窗口的位置由窗口的前沿和后沿的位置共同确认。
在这里插入图片描述

发送窗口的状态需要三个指针来描述：P1，P2和P3。指针都指向字节的序号。
小于P1的是已经发送并受到确认的部分；大于等于P3是不允许发送的部分。

P3-P1=A的发送窗口（通知窗口）
P2-P1=已发送但尚未收到确认的字节数；
P3-P2=允许发送但是尚未发送的字节数（可用窗口/有效窗口）

窗口和缓存的关系
首先明确两点：

缓存空间和序号空间都是有限的，并且都是循环使用的；
实际上缓存和窗口中的字节数是非常大的。

发送缓存用来暂时存放：

发送应用程序传送给发送方TCP准备发送的数据；
TCP已发送出但尚未收到确认的数据

发送窗口通常只是发送缓存的一部分，发送缓存和发送窗口的后沿是重合的。

接收缓存用来暂时存放

按需到达的，但尚未被接受应用程序的读取的数据；
未按序到达的数据

接收窗口最大不会超过接收缓存的大小。根据接受应用程序读取数据的速度来调整接收窗口的大小。

强调三点：

虽然A的发送窗口时根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样的大；
TCP通常对不按序达到的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，在按序交付给上层的应用程序。
TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。TCP规定，确认推迟的时间不应超过0.5秒。

6.2 超时重传时间的选择

超时重传时间

太短：会引起很多报文段的不必要的重传，使网络负荷增大；
太长：会使网络空闲时间增大，降低了传输效率。

TCP采用一种自适应算法来设置超时计时器的超时重传时间往返时间RTT。
$报文段的 R T T = 受到相应确认的时间 - 发出一个报文段的时间$
加权平均往返时间RTTs（平滑往返时间）：
$新的 R T T s = (1 - α) \times (旧 R T T s) + α \times (新 R T T 样本)$
$α$ 的推荐值为 $1 / 8$ 。

超时计时器设置的超时重传时间RTO(RetrainsmissionTime-Out)应大于RTTs：
$RTO=RTTs+4×RTT_D$

其中 $RTT_D$ 是RTT的偏差的加权平均值，与 $R T T s$ 和新的RTT样本之差有关。
$新RTT_D = β× (旧RTT_D)+ (1-β) × |RTTs - 新RTT样本|$
$β$ 推荐值为 $1 / 4$ 。

Karn提出算法：在计算加权平均RTTs时，只要报文段重传了，就不采用其往返时间样本。这样得出的RTTs和RTO较准确。

修正的Karm算法：报文每重传一次，就把超时重传时间RTO增大一些。典型的做法时取新的重传时间为2倍的旧的重传时间。实际证明这种策略更合理。

6.3 选择确认SACK*

若收到的报文无差错，但是没有按序到达，则可以值传送缺少的数据，而不必重传已经正确到达接收方的数据。

7 TCP的流量控制

7.1 利用滑动窗口实现流量控制

流量控制的原因：
数据传输得越快，网络的利用率就越高，但是如果发送的速度太快，接收端来不及接收处理就会导致数据丢失，所以要进行流量控制。

流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
发送方的发送窗口不能超过接收方给出的接受窗口rwnd的数值。在TCP中窗口的单位是字节，不是报文段。
注意： 在接收端的接收缓存满时，发送端不能发送新的数据，但是如果有需要超时重传的数据，仍然可以发送。

TCP为每个连接设有一个持续计时器。只要TCP连接的一方受到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1B的数据），而对方就在确认这个探测报文段中给出现在的窗口值。如果窗口仍然为0，那么受到这个报文段的一方就重新设置持续计时器。如果窗口不为0，那么死锁的僵局就可以打破了。

7.2 必须考虑传输效率*

【1】如何控制TCP发送报文段的时机？
Nagle算法：若发送应用进程把要发送的数据逐个字节的送到TCP的发送缓存，则发送方就把第一个数据字节此案发送出去，把后面到达的数据字节都缓存起来。当发送方受到对第一个数据字符的确认后，再把缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较慢时，用这样的方法可明显地减少所用的网络带宽。Nagle算法还规定，当到达的数据以送到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

【2】针对“糊涂窗口综合征”的解决方法？
可以让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文，或者等到接收缓存已有一半空闲时间。只要出现这两种情况之一，接收方就发送确认报文，并向发送方通知当前的窗口大小。此外发送方也不要发送太小的报文段，而是把数据累积成足够大的报文段，或达到接收方缓存的空间的一半大小。

8 TCP的拥塞控制

根据TCP的流量控制可知：发送端的发送窗口大小一定不会超过接收方给出的接收窗口的大小rwnd。

在拥塞控制中，发送方还要维持一个拥塞窗口cwnd，拥塞窗口的大小是动态变化的。在不考虑接收方接受能力的条件下，发送方让自己的发送窗口等于拥塞窗口。

所以综合流量控制和拥塞控制，发送窗口的大小的上限值应取为 $\rm{min}\{rwnd, cwnd\}$ 。

8.1 拥塞控制的一般原理

拥塞是指当对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变差，即出现了拥塞。此时整个网络的吞吐量将随输入负荷的增大而下降。

当TCP连接的端点只要迟迟不能收到对方的确认信息，就猜想当前网络中的某处可能发生了拥塞，但此时并不知道拥塞到底发生在网络的何处，也不知道发生拥塞的原因。
在这里插入图片描述
理想的拥塞控制下，当吞吐量没有饱和的时候，网络的吞吐量等于提供的负载；当达到某一限制的时候，由于网络资源受限，吞吐量不再增长保持为水平线，即吞吐量达到饱和。

在无拥塞控制的情况下，随着负载的增大，网络的吞吐量的增长速率逐渐减小，即部分输入分组已经倍丢弃了。当网络的吞吐量明显小于理想的吞吐量时，网络进入轻度拥塞状态。当负载继续增加达到某个数值的时候，网络的吞吐量反而反而随负载的增加而下降，这是网络就进入了拥塞状态。当提供的负载继续增大到某一个数值的时候，网络的吞吐量就下降到0，网路无法再工作，进入死锁状态。

拥塞控制和流量控制的区别：
拥塞控制是为了防止更多的数据流入网络中，这样可以是网络中的路由器或链路不至过载。拥塞控制的前提是网络能够承受现有的网络负载。拥塞控制是一个全局性的过程，在设计拥塞控制策略时，必须全面衡量得失。
流量控制往往是指点对点信息量的控制，是个端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便接收端来得及接收。

拥塞控制从大的方面看，可以分为开环控制和闭环控制两种方法。
开环控制方法就是在设计网络时先考虑周到，力求网络在工作时不发生拥塞，但一旦真个系统运行起来，就不再中途进行改正了。
闭环控制是基于反馈环路的概念。又以下几种措施：

检测网络系统以便检测到用在何时、何处发生；
把拥塞发生的信息传送到可采取行动的地方；
调整网络系统的运行以解决出现的问题。

8.2 几种拥塞控制的方法

根据TCP的流量控制可知：发送端的发送窗口大小一定不会超过接收方给出的接收窗口的大小rwnd。
在拥塞控制中，发送方还要维持一个拥塞窗口cwnd，拥塞窗口的大小是动态变化的。在不考虑接收方接受能力的条件下，发送方让自己的发送窗口等于拥塞窗口。
所以综合流量控制和拥塞控制，发送窗口的大小的上限值应取为 $\rm{min}\{rwnd, cwnd\}。$

介绍下面几种拥塞控制方法时不考虑流量控制。

8.2.1 慢开始和拥塞避免

慢开始算法思路：当主机开始发送数据时，如果立即把大量的数据字节注入到网络，那么就有可能引起网路拥塞，因为现在并不清楚网络的负荷情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。
通常，先把cwnd设为一个最大报文段MSS的数值。每收到一个对新的报文段的确认之后，把cwnd增大到2MSS。每经过一个传输轮次，cwnd就加倍。
传输轮次：一个传输轮次所经历的时间就是往返时间RTT。它强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。

由于是指数增长，为了防止cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh。ssthresh的初始值常设为16个报文段的长度。

当cwnd<ssthresh时：使用慢开始算法；
当cwnd>ssthreshh时，停止使用慢开始算法，而改用拥塞避免算法；
当cwnd=ssthresh时，两种算法都可以使用。

拥塞避免算法的思路就是让cwnd缓慢地增大，即每经过一个RTT就把发送方的cwnd加1MSS，称为**“加法增大”。这样，cwnd按线性**规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
在这里插入图片描述

无论是慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限ssthresh设置为出现拥塞时发送方窗口值的一半（但不能小于2），又称为**“乘法减小”。然后重现把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的**就是迅速减小主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

8.2.2 快重传和快恢复

快重传算法首先要求接收方每收到一个失序的报文段后立即发出重复确认（为的是让发送方及早知道有报文段没有到达对方）而不要等待自己发送数据时才进行捎带确认。
而发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待为其设置的重传计时器到期。

由于发送方尽早重传为被确认的报文段，因此采用快重传后可以使整个网络的吞吐量提高20%。
与快重传配合使用的还有快恢复算法，其过程有两个要点：

当发送方连续收到三个重复确认时，就执行**“乘法减小”**算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。但是注意：⚠接下去不执行慢开始算法。
由于发送方现在认为网络很可能没有发生拥塞（否则不可能连续收到好几条确认报文），于是与慢开始不同之处在于现在不执行慢开始算法，而是执行完“乘法减半”算法之后，把cwnd设为减半后的sstresh，然后开始执行拥塞避免算法（加法增大）。

例如：
在这里插入图片描述
假设现在的sstresh=16(单位为数据报)。
A发送M1~M6到B，
B收到M1之后，确认M1；
收到M2之后，确认M2；
接着收到的是M4，B重复确认收到M2；
收到M5，B第二次重复确认收到M2；
收到M6，B第三次重复确认收到M2；
A连续收到了3个对M2的重复确认，立即重传M3。同时将设置sstresh=8，cwnd=8，然后执行拥塞避免算法，先行增大cwnd。

总结：
在这里插入图片描述

9 TCP传输连接管理

9.1 TCP连接建立

假设主机A运行的TCP客户程序，B运行的是TCP服务器程序。
最初两端的TCP进程都处于“CLOSED”状态。
A是主动打开连接，B是被动打开连接的。两端的TCP进程通过三次握手建立TCP连接。
在这里插入图片描述

为什么A还要发送一次确认呢？（为什么是三次握手，而不是两次握手？）
这主要是为了防止已失效的连接请求报文突然又传到了B，因而产生错误。
解释：
A发送连接请求，但是由于连接请求报文在传输过程中丢失了，B没有能及时收到，超时计时器到期了A还没有收到B的确认，就重传请求报文。假设B这次收到了A的请求报文且确认，经过三次握手之后，TCP连接建立。等到数据传输结束之后，连接释放。这种情况下，虽然A发送了两次请求报文，但是第一次丢失了，所以没有产生“失效的连接请求报文”。
但是如果A发送的第一次连接请求报文并未丢失，而是在网络中滞留了，以致延误到连接释放了之后才到达B。此时B并不知道这个报文是失效的，就会给A发出确认报文。但是因为A并没有发出请求，就不会理睬B的确认。因此B收不到A的确认，就不会建立连接。
如果只有两次握手，上述情况发生后，B收到了失效的请求报文就立刻建立新的连接，一直空等A发送数据，B的资源就被白白浪费了。

9.2 TCP连接释放

TCP连接建立之后，客户和服务器都进入ESTABLISHED状态，两者之间可以进行双向的数据传输。
TCP连接释放需要经过“四次挥手”，过程如下：‘
在这里插入图片描述

为什么A在TIME-WAIT状态必须等待2MSL（Maximum Segment Lifetime，报文最大生存时间）的时间呢？

为了保证A发送的最后一个ACK报文段等到达B。B发送完连接释放报文之后进入LAST-ACK状态，无论是因为连接释放报文丢失了，还是A的ACK报文丢失了，B在一定时间内没有收到A的确认，就会从新发送连接释放报文。A就能在等待的2MSL时间内收到这个重传的报文，重新做出确认，再次启动2MSL计时器，知道正常关闭。否则，B无法正常进入CLOSED状态。
经过2MSL时间后，本连接中产生的所有报文段都会从网络中消失，就不会在下一个新的连接中出现已失效的报文段。

TCP计时保活器的作用？
假设客户已主动和服务器建立了TCP连接，但是否后来客户主机突然出了故障，服务器就在了收不到客户发来的消息了，但是此时连接还没有释放，如果一直等待下去就会浪费很多资源，所以使用保活计时器。服务器每收到一次客户的数据，就重新设置保活计时器，时间通常设为两个小时。若两个小时没有收到客户端额数据，服务器就发送一个探测报文段，以后每隔75分钟发送一次，若连续10个探测报文段后仍没有收到客户的相应，服务器就默认客户端出了故障，关闭连接。

9.3 TCP的有限状态机

在这里插入图片描述

果果果酱

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
【计算机网络】传输层

传输层1 传输层协议概述1.1 进程之间的通信1.2 传输层的两个重要协议1.3 传输层的端口2 用户数据报协议UDP2.1 UDP概述2.2 UDP的首部格式3 传输控制协议TCP概述3.1 TCP最主要特点3.2 TCP的连接4 可靠传输的工作原理4.1 可靠传输4.2 停止等待协议4.2.1 ARP协议4.2.2 信道利用率4.3 连续ARQ协议5 TCP报文段的首部格式6 TCP可靠传输的...
复制链接

扫一扫