运输层总结

曾经终败给现在 2024-04-08 08:20 178阅读 0赞

#### 运输层 ####

*  一. 概述
 *   *   *  1.1 运输层的任务
         *  1.2 "端到端" 通信
         *  1.3 端口号
         *  1.4 运输层的功能
 *  二. UDP和TCP
 *   *   *  2.1 主要区别
         *  2.2 首部格式
 *  二. TCP的流量控制
 *  三. TCP的可靠传输
 *  四. TCP的拥塞控制
 *  五. TCP的连接与释放
 *  六. TCP报文段的首部格式

## 一. 概述 ##

计算机网络体系结构中的物理层、数据链路层、网络层 共同解决了将主机通过【异构网络互联】所面临的问题，实现了**主机到主机的通信**；

但实际上在计算机网络中进行**通信的实体**是位于两端主机中的**进程**！

#### 1.1 运输层的任务 ####

为【运行在不同主机】的**进程**提供的逻辑通信服务，运输层协议又称端到端协议 ；

#### 1.2 “端到端” 通信 ####

运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑，路由选择协议等），看上去是**端到端**的逻辑通信 ；  
![在这里插入图片描述][28603d18a6e64f108e206cf1439d4b96.png]

#### 1.3 端口号 ####

TCP/IP体系的运输层使用端口号来区分不同的应用进程；  
端口号使用16比特，取值范围0~65535 （2^16）；

**熟知端口号**： FTP使用21/20，HTTP使用**80**，DNS使用**53**，DHCP 67/68

**注意：**  
端口号只具有本地意义！不同计算机的端口号之间没有联系

#### 1.4 运输层的功能 ####

**功能1**： 为运行在【不同主机上】的**进程**之间提供了**逻辑通信**；  
**功能2**： **复用和分用**

**复用**（从上到下）：不管是UDP封装成的UDP数据报还TCP协议封装成的TCP报文段，在【网络层】都需要使用IP协议封装成**IP数据报**！

**分用**（从下到上）：接收方收到**IP数据报**进行IP分用，若**协议字段**为**17**则将数据载荷部分交给运输层的UDP，**6**则交给TCP ；剥离数据报的头部根据**端口号**将数据传到对应的**进程** ；

## 二. UDP和TCP ##

#### 2.1 主要区别 ####

![在这里插入图片描述][e207941838b240728ede9cfa00bf31f1.png]

1.  UDP是**无连接**的，发送之前不需要建立连接，可以单播、多播、广播  
    TCP是**面向连接**的（点对点通信），发送之前需要先建立连接（三次握手）
2.  UDP提供最大努力交付，**不保证可靠传输**，通过首部中校验和字段的值来检查出误码，然后直接丢弃；  
    TCP**提供可靠传输**服务，即无差错、不丢失、不重复
3.  UDP是面向**报文**的，对应用层传下来的**报文既不合并也不拆分，保留报文的边界**；  
    TCP是面向**字节流**的，将**发送的数据块**视为**一串无结构的字节流**，每次发送**提取一部分字节封装一个TCP报文段**，即TCP不保证接收方收到的数据块与发送方的数据库大小相同。
4.  UDP的逻辑信道是不可靠信道，TCP则是全双工可靠信道
5.  UDP适用于实时IP电话、视频会议的场景，**时延小**； TCP适用于**文件传输**

#### 2.2 首部格式 ####

**UDP首部格**：  
![在这里插入图片描述][2472631bdd2046449c2c6951aeeda0c9.png]  
UDP首部仅8个字节，由于**不提供可靠传输**，仅在IP数据报的基础上增加了端口号、长度、校验和；

**TCP首部格**：  
![在这里插入图片描述][7dd20c292eb441138e6df11735f9872b.png]

TCP要实现可靠传输、流量控制、拥塞控制等服务最小长度为20字节，最大60字节

## 二. TCP的流量控制 ##

[TCP的流量控制][TCP]

**实现方式**： TCP的流量控制通过**滑动窗口机制**来实现，数据接收端可根据自己的接收缓存情况，随时动态地调整 **`rwnd`**，以使发送方调整传输窗口大小；

**注意**：

1.  **滑动窗口**概念不仅存在于【链路层】，也存在于【传输层】，两者有不同的协议，但基本原理是相近的。其中一个重要区别是，一个是针对于**帧**的传送，另一个是**字节数据**的传送；
2.  链路层的滑动窗口大小一般不变，而传输层的滑动窗口大小会随着 接收方的**rwnd**而变化；
3.  TCP是面向**字节流**的，将**发送的数据块**视为一连串无结构的字节流，每次发送**提取一部分字节构建一个TCP报文段**，即TCP不保证接收方收到的数据块与发送方的数据库大小相同。这是TCP实现可靠传输、流量控制、拥塞控制的基础；

**过程：**  
假设A要向B发送数据，【主机建立TCP连接时】，B告诉A接收窗口**rwnd** 的大小假设为300  
假设A发送的每个TCP报文段可携带100个字节数据，每个小格子是100个字节数据的序号

1.  A **将窗口内的数据封装成TCP报文段** 发送（在发送数据后,便立刻创建一个该报文段的**重传计时器**），凡是没有收到确认的数据都会保留在发送**缓存**，以便在超时重传时使用
2.  B会对接收到的报文段进行**累计确认**，最后返回**确认报文段**；  
    确认位ACK=1（在建立连接后ACK都为1），ack=201（确认号为接收方期待发送方发送的下一个报文数据的第一个字节的序号）， B根据缓存大小返回 **`rwnd`** 接收窗口，接收方会根据负载情况及时调整rwnd大小，以此实现流量控制；
3.  A收到B发送的确认报文段：  
    ① **A会根据 `rwnd` 调整滑动窗口大小**，  
    ② 并删除【发生缓存中】已经被确认的数据报 ，  
    ③ 则撤销已被确认的报文的**重传计时器**；
    
    假设A发送的数据报中途丢失，该报文段的重传计时器超时后，则A重发报文段，直到B返回确认报文段；

## 三. TCP的可靠传输 ##

[TCP的可靠传输][TCP 1]

**实现：** TCP的可靠传输也是通过以字节为单位的**滑动窗口**来实现；  
即发送方在构造字节的发送窗口时，仅考虑接收方的接收窗口 **`rwnd`**，（假设不考虑拥塞窗口）；

**注意：**  
1.链路层的滑动窗口大小一般是**固定**的，在传输中不会改变，而TCP可靠传输使用的滑动窗口会根据接收方发送的接受窗口大小和拥塞窗口大小动态调整；  
2.接收方只对**按序到达的数据中的最高序号**给出确认；

**过程：**  
![在这里插入图片描述][e2394cb101ac49ea80e5d43ba73a373b.png]  
**发送方**：

1.  主机【建立TCP连接时】，B告诉A接收窗口**rwnd** 的大小，发送方会根据rwnd来调整发送窗口的大小。
2.  发送方将窗口内的数据都封装成**报文段**发送出去，凡是没有收到确认的数据都会**保留在发送缓存**，以便在超时重传时使用； 而在【发送缓存中】 已收到确认报文的数据会中被**删除**，并将**窗口前移**（后沿前移）；
3.  窗口的后沿：不可向后移动；收到新的报文确认，**后沿前移**  
    窗口的前沿：会**不断前移**；也可能不动，如还未收到新的确认报文或者窗口缩小；但前沿**不可后移**（会出错）

**接收方**：  
只对按序到达的报文段的最高序号给出确认；

1.  如果有**不按序到达**的，**暂存在接收缓存**中；  
    若使用**快重传算法**，则接收方每次收到不按序到达的数据都会发出对之前按序到达的最高序号的**重复确认**，发送方收到3次重复确认后立即重传确认报文段的下一个报文段；
2.  接收方收到**按序到达的报文段**会**交付**给应用进程，**接收窗口前移**，同时**发送确认报文段**；

**其他保证可靠传输的机制：**  
1.发送方的 **超时重传计时器**  
2.流量控制  
3.拥塞控制  
4.TCP首部的**校验和**字段

## 四. TCP的拥塞控制 ##

![在这里插入图片描述][01817ec622424fa29ccf56ebbd8f38ac.png]

**拥塞**： 若对网络中某一个资源的需求超过了该资源所能提供的可用部分，网络性能就要降低。  
**轻度拥塞状态**： 网络的吞吐量明显小于理想的吞吐量时  
**进入拥塞状态**： 若出现拥塞而不控制，整个网络的**吞吐量**将随**输入负荷**的增大而下降 ↓  
**死锁**： 吞吐量为0时，网络将无法工作

**实现方式**： 发送方（**主动**）维护一个 **`cwnd`** 拥塞窗口，窗口大小随网络的拥塞程度动态变化；  
区别rwnd由接收方发给发送方，发送方是被动的；

**90年之前：慢开始算法+避免拥塞算法**  
拥塞控制过程： （拥塞窗口**cwnd**会随网络拥塞程度，以及拥塞控制算法而动态变化）  
![在这里插入图片描述][9a98ffe90577441b86358ddcfb0f50ad.png]

1.  在建立TCP连接时，使用慢开始算法，拥塞窗口**cwnd**值被设置为**1**，这里假设**慢开始门限值ssthresh**=16 ;
2.  当 cwnd < ssthresh 执行**慢开始算法**时，发送方每收到一个对新报文段的确认，拥塞窗口**cwnd按指数增长**，继续开始下一轮的传输
3.  当 cwrd ≥ ssthresh，改用**拥塞避免算法**，拥塞窗口cwnd每次**线性增加1**，限制吞吐量
    
    **缺点**：当报文段丢失，则会超时重传，被判断为可能**出现拥塞**；  
    ①慢开始门限**ssthresh减半**  
    ②拥塞窗口**cwnd重置为1**，重新开始**慢开始算法**  
    （当个别报文段丢失时，该算法可能导致 传输被误认为发生了网络拥塞，因而降低传输效率，因此产生**快重传算法** ）

**90年之后：快重传+会恢复**（针对报文丢失）  
**快重传算法：**  
原因： 有时个别报文段丢失，而网络并没有发生拥塞，这将导致发送方超时重传，并误认为发生了网络拥塞，因而降低传输效率  
**采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失**

**概念**： 快重传就是使发送方尽快重传，而不是等重传计时器超时再重传

**实现**：  
发送方要立即对报文段进行确认  
收到不按序到达的报文段时，要发出对已收到报文段的重复确认，  
**一旦接收方收到3个连续的重复确认**，在【重传计时器超时之前】**立即重传接收方接收的报文段的下一个报文段**！以避免因为超时重传而误认为是网络拥塞；

**快重传控制过程：**

1.  发送方发送1、2号报文段，接收方1、2号报文段进行确认
2.  发送方发送的3号报文段丢失，然后又发送了4号报文段，
3.  接收方收到了不按序到达的报文段（4号），立即发回对2号报文段（有序到达的最高位）的重复确认，表示接收方应收到3号但没有收到，
4.  发送方继续发送5、6号报文段，接收方收到后发现不是按序到达的报文段，两次发回对2号报文段的重复确认
5.  发送方收到3次对2号的重复确认，立即重传3号报文段，接收方收到后发回6号的确认报文段，表示6及之前的报文段都接收了，发送方收到后撤回3-6号的重传计时器，这样就不会造成3号的超时重传，就不会误认为拥塞而使cwnd=1及ssthresh减半，从而避免了降低传输效率；

**快恢复算法**：  
一旦**发送方**收到3个连续的重复确认，就知道是丢失了个别报文段而不是拥塞，就可以执行快恢复算法：  
①发送方将慢开始门限值ssthresh和拥塞窗口cwnd都调整为当前窗口的**一半**，  
②然后执行**避免拥塞算法**，即**cwnd**线性增加；

由于跳过了慢开始算法直接执行**拥塞避免算法**，所以叫快恢复；

## 五. TCP的连接与释放 ##

[TCP的连接与释放][TCP 2]

## 六. TCP报文段的首部格式 ##

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

一个TCP报文段同样由**首部**和**数据载荷**两部分构成；  
![在这里插入图片描述][1fa036814f144c879f0b54ef6ea1c0f5.png]  
**首部字段**：

**确认号ack**：期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前手打收到的所有数据的确认  
只有ACK=1时，ack才有效  
ACK=0时，ack无效

**窗口字段**：rwnd窗口值作为接收方让发送方设置其发送窗口的一句

**校验和**：用来检查范围包括TCP报文段的首部和数据载荷两部分

**确认位ACK**：TCP规定，在建立连接后所有传送的TCP报文段的ACK=1  
**同步位SYN**：连接请求和连接请求的确认时，SYN=1  
**终止位FIN**：用来是释放一个连接  
**复位标志位RST**：表示TCP连接出现了严重差错，必须释放连接，再重新连接  
**推送位PSH**：接收方的TCP收到PSH=1的报文段会尽快上交应用进程（接收方发送）  
**紧急位URG**：URG=1时，接收方收到后立即上传紧急数据（发送方发送）

**填充字段**：确保首部能被4整除；

[28603d18a6e64f108e206cf1439d4b96.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/2f06dfc22f844c919cfde2e6e7549668.png
[e207941838b240728ede9cfa00bf31f1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/f812af7df1454aedafe39a3fa29c23e4.png
[2472631bdd2046449c2c6951aeeda0c9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/02ac08117ec74bd6bbee89321566f3a7.png
[7dd20c292eb441138e6df11735f9872b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/08d715e359cc4f5ba52367b8e973ed9d.png
[TCP]: https://blog.csdn.net/Swofford/article/details/125118982
[TCP 1]: https://blog.csdn.net/Swofford/article/details/125148546
[e2394cb101ac49ea80e5d43ba73a373b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/9066d02eb93d49829943f246e0d5d3c7.png
[01817ec622424fa29ccf56ebbd8f38ac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/1f74b8b6864547c4859cbc5b7cbc665f.png
[9a98ffe90577441b86358ddcfb0f50ad.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/075b2fb764d04c609a2130553b96c34a.png
[TCP 2]: https://blog.csdn.net/Swofford/article/details/125166924
[1fa036814f144c879f0b54ef6ea1c0f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/f0713f0cb2d54b7c89b026b371e2efc4.png