第 5 章传输层

我会带着你远行 2023-01-01 02:57 129阅读 0赞

# 第 5 章 传输层 #

## 1、思维导图 ##

![image-20201229201027507][]

## 2、传输层概述 ##

### 2.1、传输层的功能 ###

> **传输层的层次**

传输层是只有主机（端系统）才有的层次，中间网络设备层次最多到网络层。传输层使用下层（网络层）提供的服务，并为上层（应用层）提供服务

![image-20201229212201856][]

> **传输层的功能**

1.  传输层提供进程和进程之间的逻辑通信（看起来就好像是两个进程连接在了一起），而网络层提供主机之间的逻辑通信（看起来就好像是两个主机连接在了一起）。
2.  复用（发送方不同的应用进程可以使用同一个传输协议进行数据的传输）和分用（接收方的传输层在剥去报文首部后，可以将数据正确交付给指定的进程）
3.  传输层对收到的报文进行差错检测（IP 首部校验和）
4.  传输层的两种协议：TCP 和 UDP

### 2.2、传输层的两个协议 ###

> **打油诗**

传输层有两个好兄弟

大哥TCP和二弟UDP

大哥靠谱，二弟不靠谱

> **TCP 协议**

面向连接的传输控制协议TCP

传送数据之前必须建立连接，数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务，因此不可避免增加了许多开销：确认、流量控制、计时器及连接管理等。

特点：可靠，面向连接，时延大，适用于大文件。

> **UDP协议**

无连接的用户数据报协议UDP

传送数据之前不需要建立连接，收到UDP报文后也不需要给出任何确认。

特点：不可靠，无连接，时延小，适用于小文件。

> **传输层的传输单位**

传输层的传输单位为报文段

### 2.3、传输层的寻址与端口 ###

> **复用与分用**

复用：应用层所有的应用进程都可以通过传输层再传输到网络层。

分用：传输层从网络层收到数据后交付指明的应用进程。

> **如何分辨同一台主机上的不同进程呢？**

可以使用逻辑端口/软件端口，端口是传输层的SAP，标识主机中的应用进程

端口号只有本地意义（在本机内可以唯一标识一个进程即可），在因特网中不同计算机的相同端口是没有联系的。

端口号长度为16bit，能表示65536个不同的端口号。

> **端口号的分类**

按照范围对端口号进行划分

![image-20201229213358195][]

--------------------

常见的端口号

![image-20201229213628244][]

> **套接字**

在网络中采用发送方和接收方的套接字组合来识别端点，套接字唯一标识了网络中的一个主机和它上面的一个进程。

套接字Socket=（主机IP地址，端口号）

## 3、UDP协议 ##

### 3.1、用户数据报协议UDP概述 ###

> **UDP 协议的特点**

UDP只在IP数据报服务之上增加了很少功能，即复用分用和差错检测功能。

UDP的主要特点：

1.  UDP是无连接的，减少开销和发送数据之前的时延。
2.  UDP使用最大努力交付，即不保证可靠交付。
3.  UDP是面向报文的，适合一次性传输少量数据的网络应用（UDP既不合并报文，也不拆分报文；报文太短，通信效率太低，报文太长，容易丢失）。
4.  UDP无拥塞控制，适合很多实时应用。
5.  UDP首部开销小，8B，TCP20B。

--------------------

我们使用的 IP 电话和视频电话一般都使用 UDP 协议，允许部分报文丢失，但绝不允许视频有着比较大的延迟

> **UDP 报文**

应用层给UDP多长的报文，UDP就照样发送，即一次发一个完整报文。但是如果报文太大，到 IP 层会进行分片操作，由于 UDP 提供不可靠交付，如果某一分片丢失，则会导致整个报文无法复原

![image-20201229213935140][]

### 3.2、UDP首部格式 ###

> **UDP报文的说明**

如果不需要接收接收方的回复，那么 16 位源端口号可以全填 0（不告诉接收方我的 IP 地址）

分用时，找不到对应的目的端口号，就丢弃报文，并给发送方发送ICMP“端口不可达”差错报告报文。

![image-20201229214606295][]

### 3.3、UDP校验 ###

> **UDP 伪首部**

伪首部（伪 IP 首部）只有在计算检验和时才出现，不向下传送也不向上递交。

17：封装UDP报文的IP数据报首部协议字段是17。

UDP长度：UDP首部8B+数据部分长度（不包括伪首部）。

![image-20201229215044621][]

> **UDP 校验的例子**

**在发送端**：

1.  填上伪首部
2.  全0填充检验和字段
3.  全0填充数据部分（UDP数据报要看成许多4B的字串接起来）
4.  伪首部+首部+数据部分采用二进制反码求和
5.  把和求反码填入检验和字段
6.  去掉伪首部，发送

**在接收端**：

1.  填上伪首部
2.  伪首部+首部+数据部分采用二进制反码求和（首部中的检验和字段是发送方计算得到的检验和）
3.  结果全为1则无差错，否则丢弃数据报或者交给应用层附上出差错的警告（差错控制交由上层实现）。

![image-20201229215304552][]

## 4、TCP协议特点和TCP报文段 ##

### 4.1、TCP协议的特点 ###

> **TCP协议的特点**

1.  TCP是面向连接（虚连接）的传输层协议。
2.  每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的。
3.  TCP提供可靠交付的服务，无差错、不丢失、不重复、按序到达。
4.  TCP提供全双工通信：
    
    1.  发送缓存：准备发送的数据&已发送但尚未收到确认的数据
    2.  接收缓存按序到达但尚未被接受应用程序读取的数据&不按序到达的数据
5.  TCP面向字节流（流：流入到进程或从进程流出的字节序列）：TCP把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。

### 4.2、TCP报文段首部格式 ###

> **TCP报文段首部格式**

1.  序号：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号。
2.  确认号：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则证明到序号N-1为止的所有数据都已正确收到。
3.  数据偏移（首部长度）：TCP报文段的数据起始处距离TCP报文段的起始处有多远，以4B位单位，即1个数值是4B。
4.  6个控制位
    
    1.  紧急位URG：URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。
    2.  紧急位URG：URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。
    3.  推送位PSH：PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。
    4.  复位RST：RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输链接。
    5.  同步位SYN：SYN=1时，表明是一个连接请求/连接接受报文。
    6.  终止位FIN：FIN=1时，表明此报文段发送方数据已发完，要求释放连接。
5.  窗口：指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。
6.  检验和：检验首部+数据，检验时要加上12B伪首部，第四个字段为6（UDP 为 17，TCP 为 6）。
7.  紧急指针：URG=1时才有意义，指出本报文段中紧急数据的字节数。选项：最大报文段长度MSS、窗口扩大、时间戳、选择确认…
8.  填充：将 TCP 首部长度填充为 4B 的整数倍

![image-20201229220441203][]

## 5、TCP连接管理 ##

### 5.1、TCP三次握手 ###

> **TCP三次握手建立连接**

TCP连接的建立采用客户服务器方式，主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫服务器。 TCP 采用三次握手的方式建立连接

![image-20201229221043076][]

--------------------

> **TCP连接传输三个阶段**

![image-20201229221131978][]

### 5.2、TCP的连接建立 ###

> **TCP的连接建立过程**

假设运行在一台主机（客户）上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接，客户应用进程首先通知客户TCP，他想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接：

**ROUND 1**:

客户端发送连接请求报文段，无应用层数据。SYN=1（表示建立连接），seq=x（随机，表示客户端向服务器端发送的起始字节序号为 x）

**ROUND 2**:

服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。SYN=1（表示建立连接），ACK=1（表示 ack 字段生效），seq=y（随机，表示服务器端向客户端发送的起始字节序号为 y），ack=x+1（表示服务器端在下一次的报文中想要接收到以 x+1 序号起始的字节流）

**ROUND 3**:

客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。SYN=0，ACK=1（表示 ack 字段生效）s，seq=x+1（表示客户端向服务器端发送的起始字节序号为 x+1），ack=y+1（表示客户器端在下一次的报文中想要接收到以 y+1 序号起始的字节流）

![image-20201229221150323][]

--------------------

**SYN 在两种情况下会设置为 1**

1.  连接请求的报文中
2.  连接请求的确认报文中

### 5.3、SYN洪泛攻击 ###

> **SYN洪泛攻击的概念**

SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

解决办法：设置 SYNC cookie

### 5.4、TCP四次挥手 ###

![image-20201229221852591][]

### 5.5、TCP的连接释放 ###

> **TCP的连接释放过程**

参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”（缓存和变量）将被释放。

**ROUND 1**:

客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。FIN=1（表示客户端请求释放连接），seq=u（表示客户端向服务器端发送的起始字节序号为 u）

**ROUND 2**:

服务器端回送一个确认报文段，客户到服务器这个方向的连接就释放了——半关闭状态。ACK=1（表示 ack 字段生效），seq=v（表示服务端向客户器端发送的起始字节序号为 v），ack=u+1（表示服务器端上次接收到的最后一个字节序号为 u）

**ROUND 3**:

服务器端发完数据，就发出连接释放报文段，主动关闭TCP连接。FIN=1（表示服务器端请求释放连接），ACK=1（表示 ack 字段生效），seq=w（表示服务端向客户端发送的起始字节序号为 w），ack=u+1（客户端单方向释放了连接，不会再向服务器端发送数据，因此 ack 还是等于 u+1）

**ROUND 4**:

客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后，连接彻底关闭。ACK=1（表示 ack 字段生效），seq=u+1（表示客户端向服务器端发送的起始字节序号为 v），ack=w+1（表示客户端端上次接收到的最后一个字节序号为 w）

![image-20201229221859468][]

--------------------

**FIN 在两种情况下会设置为 1**

1.  客户端的连接释放请求中
2.  服务器端的连接释放请求中

> **为什么客户端需要等待 2MSL 的时间？**

如果客户端在 ROUND 4 中发送的确认报文段在路上丢失，没有到达服务器端，服务器端在一定时间内没有收到确认就会重传 ROUND3 中的连接释放报文段。如果客户端刚发送完 ROUND4 中的确认报文段就直接关闭连接，那么服务器端就会一直不停地重传 ROUND3 中的连接释放报文段，这样会大大浪费服务器端的资源

如果客户端在 ROUND 4 中发送的确认报文段在路上丢失，没有到达服务器端，那么客户端在 2MSL 时间内还会收到来自服务器重传的连接释放报文段，然后客户端会重传确认报文段，直至服务器端接收成功为止

### 5.6、TCP可靠传输 ###

### 5.7、TCP 可靠传输的实现机制 ###

> **可靠的含义**

传输层：使用TCP实现可靠传输

网络层 提供尽最大努力交付，不可靠传输

可靠的含义：保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。

> **TCP实现可靠传输机制的手段**

1.  校验：与UDP校验一样，增加伪首部
2.  序号
3.  确认
4.  重传

### 5.8、序号、确认、重传 ###

> **序号**

给每个字节编上序号，由字节（不定量）组成报文段。一个字节占一个序号。 序号字段指的是一个报文段第一个字节的序号。

![image-20201229223900166][]

> **确认**

接收方收到数据会返回一个确认报文，报文段首部的确认字段为期望接收到的字节序列的起始编号

![image-20201229223656446][]

> **重传**

确认重传不分家，TCP的发送方在规定的时间内（重传时间 ）没有收到确认就要重传已发送的报文段。即超时重传

![image-20201229223718010][]

--------------------

TCP采用自适应算法，动态改变重传时间RTTs（加权平均往返时间）。TCP传输往返时间是指发送端从发送TCP包开始到接收到它的立即响应所耗费的传输时间

1.  重传时间过小：导致传播时间较长的报文段还没到呢，就要重传，增加网络的负担
2.  重传时间过大：导致网络的空闲时间较多，通信使用率降低

> **冗余ACK（冗余确认）**

每当比期望序号大的失序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号。比如发送方已发送1，2，3，4，5报文段：

接收方收到1，返回给1的确认（确认号为2的第一个字节）  
接收方收到3，仍返回给1的确认（确认号为2的第一个字节）  
接收方收到4，仍返回给1的确认（确认号为2的第一个字节）  
接收方收到5，仍返回给1的确认（确认号为2的第一个字节）

发送方收到3个对于报文段1的冗余ACK ，则认为2报文段丢失，将重传2号报文段（快速重传机制）

## 6、TCP流量控制 ##

### 6.1、TCP 流量控制概念 ###

> **流量控制概念**

流量控制：让发送方慢点（发送方发送速率太快，导致接收方来不及接收，出现严重的丢包现象），要让接收方来得及接收。

TCP利用滑动窗口机制实现流量控制：在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd （接收方设置确认报文段的窗口字段来将rwnd通知给发送方） ，发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。

### 6.2、TCP 流量控制的例子 ###

> **举个栗子**

A向B发送数据，连接建立时，B告诉A：“我的rwnd=400（字节）”，假设每一个报文段100B，报文段序号初始值为1。 以下是流量控制的过程：

![image-20201229225315224][]

--------------------

可以看到，最后主机 B 将 rwnd 设置为 0，不允许主机 A 再发送数据，那么什么时候主机 A 能再发送数据呢？当主机 B 的传输层将缓冲区的数据交付给上层应用之后，会腾出一些缓冲区空间，这时候可以向主机 A 发送报文，并将 rwnd 设置为接收窗口的值。问题来了：这个报文出现丢失该咋办？？？

TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段。接收方收到探测报文段时给出现在的窗口值。若窗口仍然是0，那么发送方就重新设置持续计时器。这样就能保证包含 rwnd 的报文即使丢失也能得到重传

## 7、TCP拥塞控制 ##

### 7.1、TCP拥塞控制概念 ###

> **拥塞控制概念**

出现拥塞的条件：对资源（链路带宽、交换节点的缓存、交换节点的处理机等资源）需求的总和 > 可用资源

网络中有许多资源同时呈现供应不足 → 网络性能变坏 → 网络吞吐量将随输入负荷增大而下降

拥塞控制的目的：防止过多的数据注入到网络中，减轻网络的拥塞情况，这是一种全局性的控制策略。

> **拥塞控制与流量控制**

拥塞控制：当发送方的数据迟迟不能到达接收方，证明网络发生堵塞，可通过主机之间的协调，防止过多的数据注入到网络中

流量控制：为了防止发送方发送速率太快，接受方缓存不够来不及接收而导致数据丢失的问题

### 7.2、[拥塞控制四种算法][Link 1] ###

> **四种算法、两两配对**

1.  慢开始 + 拥塞避免
2.  快重传 + 快恢复

> **案例讲解的假定**

1.  数据单方向传送，而另一个方向只传送确认
2.  接收方总是有足够大的缓存空间，发送窗口=Min\{接收窗口rwnd，拥塞窗口cwnd\}，因而发送窗口大小取决于拥塞程度

> **接收窗口与发送窗口的区别**

1.  接收窗口：接收方根据接受缓存设置的值，并告知给发送方，反映接收方容量。
2.  拥塞窗口：发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

### 7.3、慢开始和拥塞避免 ###

> **慢开始和拥塞避免的流程**

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限（ssthresh）设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如下图：

![image-20201229230755983][]

再次提醒这里只是为了讨论方便而将拥塞窗口大小的单位改为数据报的个数，实际上应当是字节。

### 7.4、快重传和快恢复 ###

> **快重传和快恢复的流程**

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

快重传配合使用的还有快恢复算法，有以下两个要点:

①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。

②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

![image-20201229231047273][]

## 8、本章小结 ##

![image-20201230211505538][]

[image-20201229201027507]: /images/20221120/6b29ff7785034af7910206c74aa3ef59.png
[image-20201229212201856]: /images/20221120/2bbbbdb368cd4e6490debfd26e7c530d.png
[image-20201229213358195]: /images/20221120/86ed3b2004364b8c90fac304c299fb5a.png
[image-20201229213628244]: /images/20221120/bcdc7d4a3d9945a78bace519ad3e4b7d.png
[image-20201229213935140]: /images/20221120/39090218a96c47d9a2f12c15c18d33f5.png
[image-20201229214606295]: /images/20221120/cb87b50870ec4a958f59d8ce18b8b8fa.png
[image-20201229215044621]: /images/20221120/cfda7b2f134e47e6abfe491bd4fd4495.png
[image-20201229215304552]: /images/20221120/077ff28294e6443aa228daa63c929bef.png
[image-20201229220441203]: /images/20221120/3f874f5d462b40f198044b6a3b0cd2e1.png
[image-20201229221043076]: /images/20221120/dba255d0ccae403f825294bd768d2934.png
[image-20201229221131978]: /images/20221120/21f8e03e19634a62b0a90251c1174ba6.png
[image-20201229221150323]: /images/20221120/c667db1a0b7d4a28b270da4743744ce6.png
[image-20201229221852591]: /images/20221120/5743cadadf12470ba77fdabda15b7059.png
[image-20201229221859468]: /images/20221120/214d93a5a0204e42b16060ad4708db21.png
[image-20201229223900166]: https://img-blog.csdnimg.cn/img_convert/cbb1e7c6f259b7e7f8ea4995465b52a9.png
[image-20201229223656446]: https://img-blog.csdnimg.cn/img_convert/1f9102931001e70252160790e9e3f554.png
[image-20201229223718010]: https://img-blog.csdnimg.cn/img_convert/db0cde12979772f64d1102403049eb19.png
[image-20201229225315224]: https://img-blog.csdnimg.cn/img_convert/fae458c0ebae5be00687b8bd80840308.png
[Link 1]: https://blog.csdn.net/sicofield/article/details/9708383
[image-20201229230755983]: https://img-blog.csdnimg.cn/img_convert/421b8f64c5d327bc285a7daf070ad21f.png
[image-20201229231047273]: https://img-blog.csdnimg.cn/img_convert/7fc917c97c52733502950a11b9c99673.png
[image-20201230211505538]: https://img-blog.csdnimg.cn/img_convert/586b165007905c2bd66c588b42800c94.png