王道考研计算机网络笔记第五章：传输层

系统管理员 2023-01-01 07:58 186阅读 0赞

> 本文基于`2019 王道考研 计算机网络`: [2019 王道考研 计算机网络][2019 _]  
> **个人笔记总结**  
> **第一章**：[王道考研 计算机网络笔记 第一章：概述&计算机网络体系结构][Link 1]  
> **第二章：**[王道考研 计算机网络笔记 第二章：物理层][Link 2]
> 
> **第三章：**[王道考研 计算机网络笔记 第三章：数据链路层][Link 3]  
> **第四章：**[王道考研 计算机网络笔记 第四章：网络层][Link 4]  
> 后续章节将陆续更新…

### 第五章 ###

*  一、传输层概述
 *   *  1. 功能
     *  2. 传输层两个协议
     *  3. 传输层的寻址与端口
 *  二、UDP协议
 *   *  1. 概述
     *  2. UDP首部格式
     *  3. UDP校验
 *  三、TCP协议
 *   *  1. 特点
     *  2. TCP报文段首部格式
     *  3. TCP连接管理（三次握手）
     *  4. TCP连接释放（四次握手）
     *  5. TCP可靠传输
     *   *  1. 校验
         *  2. 序号
         *  3. 确认
         *  4. 重传
     *  6. TCP流量控制
     *  7. TCP拥塞控制
     *   *  1. 慢开始&拥塞避免
         *  2. 快重传&快恢复

> **第五章大纲**：
> 
> ![image-20201227000305724][]

# 一、传输层概述 #

> **传输层是只有主机才有的层次，也就是在端系统的两个主机之间才有传输层**，如下图所示
> 
> ![image-20201125232511005][]

## 1. 功能 ##

![image-20201226202430129][]

1.  **传输层提供进程和进程之间的逻辑通信**；
    
    网络层为主机间的通信提供服务，但是仅仅将数据传送到主机并没有通信结束，只有将数据送交到具体的进程或者进程中具体的线程才能实现通信的过程；因此网络层的通信并未完成，需要传输层实现进程与进程之间的逻辑通信；逻辑就是表示表面是进程之间的通信，但实际上是从上至下封装，再从下至上解封装的过程
2.  **复用和分用**
    
    复用：发送方不同的应用进程，比如qq微信，都可以使用同一个传输层的协议来传送数据
    
    分用：接收方在传输层解封装后，能将数据送交给对应正确的进程
3.  **传输层对收到的报文进行差错检测**
    
    网络层有首部校验和，但只是校验首部，没有校验数据部分，因此就需要传输层实现对数据的检错，而网络层的数据部分就是传输层的报文段，因此传输层对这个报文段进行了差错检测，网络层就不需要对数据部分进行差错检测，检测IP数据报的头部即可
4.  **传输层并不一定实现可靠传输**，因为有两种协议TCP、UDP

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

## 2. 传输层两个协议 ##

![image-20201226203214441][]

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

## 3. 传输层的寻址与端口 ##

![image-20201226204613021][]  
**常见的应用程序端口号**：  
![image-20201226204735525][]

# 二、UDP协议 #

> **无连接不可靠**的服务

## 1. 概述 ##

![7c81658d7b41b38df53ad5f9b6e442c6.png][]

**注意**：

*  **应用层给UDP多长的报文，UDP就会照样发送一整个完整的报文给网络层**；
    
    因此当报文长度过大时，网络层就需要对其进行分片，又因为接下来要传给链路层有MTU的限制，降低了网络层的效率；如果应用层报文很小时，网络层IP数据报数据部分就会很小，相对于IP首部小很多，同样会降低网络层效率，因为首部附加信息相比来说应该尽可能小
 *  UDP适用于实时应用的原因：实时应用要求延迟很低，丢一点数据不影响

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

## 2. UDP首部格式 ##

![image-20201226210747727][]

*  `源端口号`可有可无，如果发送的数据报需要接收回复，就添上；如果不需要收到回复，则可以设置全0
 *  `目的端口号`一定要有
 *  `UDP长度`是指整个UDP数据报的长度 = 首部字段 + 数据字段
 *  `UDP检验和`检测整个UDP数据报是否有错，也就是首部字段+数据字段，如果出错，直接丢弃；

有一种特殊的出错情况：分用时，也就是网络层交给传输层的数据报找各自所对应的应用进程，如果找不到对应的目的进程，则会丢弃该数据报，返回发送方ICMP“发送不可达”报文

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

## 3. UDP校验 ##

> `伪首部`只有在校验时出现，其他情况不会出现，长度为12个字节

![image-20201226211011651][]

> **如何利用伪首部进行校验？**

**发送端**：

*  校验：添加12字节**伪首部**
 *  每行为4个字节，此时**UDP首部检验和**部分全0，**数据字段**不足填充0保证每行4个字节
 *  每一行（4字节）拆成左右2字节，用二进制表示，然后将全部的2字节相加求和
 *  求和结果取反，将结果填入**UDP首部校验和**字段
 *  去伪首部，发送数据

**接受端**：

*  校验：同样添加12字节**伪首部**
 *  同发送端一样，每一行（4字节）拆成左右2字节，用二进制表示，然后将全部的2字节相加求和；此时与发送端不同的是校验和不再是0，而是上述填充的结果
 *  判断结果，如果全1则无差错；否则丢弃数据报，或者不丢弃交给应用层并附上出错警告

![image-20201226213843141][]

# 三、TCP协议 #

> **有连接不可靠**的服务

## 1. 特点 ##

![image-20201226214338267][]

1.  **面向连接**：使用TCP前必须先建立连接，传送数据完毕后再释放连接；虚连接表示表面上看上去是两个进程之间直接通信，但实际物理线路上需要从上而下封装再从下而上解封装
2.  **每一个TCP连接只有两个端点，也就是每一个TCP连接都是点对点、一对一的**。所以TCP协议无法广播、多播
3.  **TCP提供可靠交付的服务，不丢不重，按序到达**
4.  **TCP提供全双工通信**。两方可以同时发数据也可以同时接收数据，所以TCP连接的两端都会设置`发送缓存`和`接收缓存`
5.  **TCP面向字节流**：`流`是流入进程或从进程中流出的字节序列，虽然应用进程和TCP的交互是一次发送一个数据块，但是TCP会把交下来的数据仅仅看成一连串的`无结构字节流`

![image-20201226214318006][]

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

## 2. TCP报文段首部格式 ##

![image-20201226221033168][]  
![image-20201230234350159][]  
**六个控制位**：  
![image-20201226215739427][]  
`URG`和`PSH`区别图示：

*  URG是从发送缓存中插队优先发送
 *  PSH是从接收缓存中出来上交应用层

![image-20201226215651189][]

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

## 3. TCP连接管理（三次握手） ##

![image-20201226222202981][]  
![image-20201226221528564][]  
**第一次握手**：客户端A向服务器B发送连接请求

*  `SYN`=1：客户端A向服务器B发送连接请求报文
 *  `seq`=x(随机)：因为还没有数据，序号位随机产生

**第二次握手**：服务其B收到来自客户端A的连接请求报文段，同意A建立连接，返回连接确认

*  `SYN`=1：服务其B返回连接接收报文
 *  `ACK`=1：连接建立之后的ACK必须都置为1
 *  `seq`=y(随机)：因为还没有数据，序号位随机产生
 *  `ack`=x+1：与ACK成对出现，表示期待对方发送的第一个字节序号，之前客户端A发送的连接请求报文没有数据部分，即序号x标志着前面发的连接请求报文，所以服务端B想要收到的是序号为x+1的数据

**第三次握手**：客户端A收到了来自服务器B的连接接收报文，要返回一个确认的确认

*  `SYN`=0：SYN只有在连接请求和连接接受时才是1
 *  `ACK`=1：连接建立之后的ACK必须都置为1
 *  `seq`=x+1：客户端A发送的报文段的第一个字节就是x+1，之前已经发送了序号为x的数据
 *  `ack`=y+1：前面服务器B发送了序号为y的连接接收报文，所以此时客户端A期待收到序号服务器B发送序号y+1的数据

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

上述第二次握手和第三次握手，服务器和客户端分别为TCP连接的过程分配了缓存和变量，就会导致一下**SYN洪泛攻击**的问题  
![image-20201226222832149][]

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

## 4. TCP连接释放（四次握手） ##

![image-20201226223000413][]  
![image-20201226223519663][]

**第一次挥手**：客户端发送连接释放，停止发送数据，主动关闭TCP连接

*  `FIN`=1：客户端A请求释放连接
 *  `seq`=u：表示请求释放连接报文段第一个字节序号，但是这个报文通常没有数据，所以该序号标识这个连接释放报文段

**第二次挥手**：服务器收到客户端的连接释放请求，返回对释放连接的确认，客户端到服务端连接半关闭

*  `ACK`=1：连接建立之后的ACK必须都置为1，此时连接还没完全释放
 *  `seq`=v：发了好多数据，这里只是用v指代一下
 *  `ack`=u+1：期待收到客户端A发送的第一个字节序号为u+1的报文段

此时客户端A收到服务器B发来的连接释放确认报文段不需要回复，因为客户端A已经结束通话，只需要等待服务器B告诉它服务器也结束，此时服务器B还可以发送数据

**第三次挥手**：服务器发送完数据，发送连接释放报文段，主动关闭TCP连接

*  `FIN`=1：服务器B发送连接释放报文，此时连接还没完全释放
 *  `ACK`=1：连接建立之后的ACK必须都置为1
 *  `seq`=w：发了好多数据，这里只是用w指代一下
 *  `ack`=u+1：之前客户端A说发送的是第一个字节序号为u的数据，所以此时服务器B希望收到首字节为u+1的数据，但由于不发数据了，所以第二段第三段的ack都是u+1

**第四次挥手**：客户端A收到来自服务器B的连接释放报文，返回一个确认报文

*  `ACK`=1：连接建立之后的ACK必须都置为1，此时连接还没完全释放
 *  `seq`=u+1：之前发的数据时第u位数据，B也要第u+1位数据，所以我发第u+1位数据
 *  `ack`=w+1：之前发送方(B)说发送的是第w位数据，所以我(A)要的是w+1位数据

此时TCP连接不是立马结束，而是等待2MSL之后，TCP连接才彻底释放，主要原因是防止客户端返回的确认报文丢失，给2MSL时间，如果丢失，则服务端重传连接释放报文段，A在2MSL之内收到重传的报文段，A在重新返回确认，也重新启动2MSL计时器

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

## 5. TCP可靠传输 ##

> 网络层提供最大努力交付，是不可靠传输；因此需要上一层传输层担起可靠传输的职责；传输层有UDP、TCP两大协议；其中UDP不可靠，TCP可靠，因此网络层不能可靠传输的话，传输层就可以通过使用TCP协议保证可靠传输；如果传输层使用的UDP协议，就需要再最上一层应用层实现可靠传输

**TCP一共有四种实现可靠传输的机制**：`校验`、`序号`、`确认`、`重传`

### 1. 校验 ###

> 与UDP校验一样，在发送方和接收方增加一个**伪首部**，通过使用二进制反码求和的计算方法，判断有没有出错

![image-20201226225018512][]

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

### 2. 序号 ###

> **TCP协议面向字节流**，因此TCP以字节为单位进行传输，会给每个字节编上序号；
> 
> 实际发送的时候以报文段为单位，将一些字节合在一起组成报文段

![image-20201226224317704][]  
**总结**：

*  一个字节占一个序号
 *  序号字段指的是一个报文段第一个字节的序号

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

### 3. 确认 ###

> 有了序号机制保证了数据能够有序的提交给应用层，基于序号机制也就有了确认和重传机制

*  发送方给接收方发送123字节组成的第一个报文段，接收方收到后存储在TCP缓存中，然后选择合适的时间将缓存中的报文段提交给应用层；此时发送方TCP缓存中仍会存在123报文段，为了保证报文段丢失能够重传

![image-20201226224448369][]

*  接收方收到报文段后会返回一个确认报文段，可采用累积确认/稍带确认（接收方要发送数据给发送方携带确认信息）的方式；假如发送方发送一个只有确认功能的报文段，则报文段首部的确认号为4，表示已经收到123字节报文段，希望收到4字节开始的报文端；发送方收到确认报文段后，就会将123字节报文段从TCP缓存中移除；
 *  此时假设发送方继续发送456报文段以及78报文段，如果456报文段中途丢失；这是接收方就会采用累计确认的方法：返回的确认报文段首部确认号仍为4，但78报文段还会正常接收

![image-20201226224542143][]

### 4. 重传 ###

> 确认机制和重传机制密切相关：如果报文段按序完整到达，接收方就会返回确认告诉发送方接下来要发送哪一个报文段；如果没有按序到达，接收方就会返回确认报文指示发送方应该重传哪一个报文段

**TCP采用自适应算法，动态改变重传时间RTTs**

*  发送一个报文段时，RTTs=第一个报文段的RTT，也就是第一个报文段从发送到收到确认的时间
 *  发送第二个报文段时，RTTs根据第一个报文段的RTT和第二个报文段的RTT算出，作为现在的重传时间
 *  发送第三个报文段时，RTTs根据第一、二、三报文段的RTT算出，作为新的的重传时间

由此可见，RTTs取决于发送的每个报文端的RTT，这样的自适应算法能够很好的照顾到每个报文段，使超时重传时间不过长也不过短。

> 超时重传要一直在超时重传时间内等，直到超过时间还未确认才会重传，这个等待的时间可能会很久，那么如何能够在超时事件发生前知道发送方有没有丢掉报文段？尽快重传呢？于是有了**冗余ACK**的方式

![image-20201226224923719][]

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

## 6. TCP流量控制 ##

> TCP使用**滑动窗口机制**实现流量控制

*  接收窗口`rwnd`
 *  拥塞窗口`cwnd`

发送窗口取决于`rwnd`和`cwnd`的最小值  
![image-20201226225553472][]  
![image-20201226235015023][]

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

## 7. TCP拥塞控制 ##

![image-20201226235254745][]  
拥塞控制有四种算法，通常**两两组合使用**  
![image-20201226235622855][]

### 1. 慢开始&拥塞避免 ###

纵坐标`cwnd`：代表拥塞窗口大小，单位代表一个报文段，长度是一个最大报文段长度MSS，因此纵坐标为几就表示几个MSS

横坐标`传输轮次`：一个传输轮次代表发送了一批报文段并收到确认的时间，也就是一个RTT

*  起始时，拥塞窗口大小`cwnd`=1，表示一个MSS，**慢开始**就是表示起始只注入了一个报文段
 *  然后拥塞窗口大小`cwnd`每经过一个传输轮次以**2的指数形式增长**，`ssthresh`是是慢开始门限，代表此时注入的报文段就比较多了，接下来可能发生拥塞，需要开始慢速增加了，进入到**拥塞避免**阶段。
 *  之后一段都是**线性增长，加法增大**，每一个传输轮次次增加1，直至达到网络拥塞状态
 *  到达网络拥塞后，瞬间将`cwnd`设置为1，同时调整原来的`ssthresh`的值到之前达到网络拥塞状态的1/2（这里是24降到12），然后重复以上步骤

![image-20201227000048834][]

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

### 2. 快重传&快恢复 ###

同的**慢开始&拥塞避免**的起始步骤类似，都是先指数增长再转变为线性增长。不同点：

*  在收到3个冗余ack确认后，立即执行快重传算法；`ssthresh`降到现在`cwnd`的一半，再重新线性增长。而不是像**慢开始&拥塞避免**等到网络发生拥塞时，`cwnd`降为1再重新慢开始

![image-20201227000244645][]

[2019 _]: https://www.bilibili.com/video/BV19E411D78Q?p=12
[Link 1]: https://bareth.blog.csdn.net/article/details/110225464
[Link 2]: https://bareth.blog.csdn.net/article/details/110311328
[Link 3]: https://bareth.blog.csdn.net/article/details/111829036
[Link 4]: https://bareth.blog.csdn.net/article/details/111830306
[image-20201227000305724]: /images/20221120/25e0baa922e84d0f8e60767ed461f8bc.png
[image-20201125232511005]: /images/20221120/2eb2a03f71d542d082d1082d9d2b6f15.png
[image-20201226202430129]: /images/20221120/2502ae581c1e43da87a996a71d589b66.png
[image-20201226203214441]: /images/20221120/aa268c2eeab24645b36fa45546ea2d01.png
[image-20201226204613021]: /images/20221120/38375f54e09d49388fcc3532f135854b.png
[image-20201226204735525]: /images/20221120/4a2551094d3c4f61a3d02be7fcb1d31e.png
[7c81658d7b41b38df53ad5f9b6e442c6.png]: /images/20221120/6a1229c2d38c406fa0db6c66967fb09b.png
[image-20201226210747727]: /images/20221120/e96932f67acb44bea840971c38ef746f.png
[image-20201226211011651]: /images/20221120/4adec71c30a648b38161bd645059dd58.png
[image-20201226213843141]: /images/20221120/11242c0ad8ff47f698eb1996ec154134.png
[image-20201226214338267]: /images/20221120/faec41ae358146cbbe79916deb3ce642.png
[image-20201226214318006]: /images/20221120/42ba9eab18fe4a08b9112a504c00c17a.png
[image-20201226221033168]: /images/20221120/540a6923745b42c694ebac6b9c296702.png
[image-20201230234350159]: /images/20221120/eee35d646ea345e9918cc463e0118187.png
[image-20201226215739427]: /images/20221120/e001ff1fa6464e80b237042b9f9d0288.png
[image-20201226215651189]: /images/20221120/749a975498444ba1b68b1c03aeccd966.png
[image-20201226222202981]: /images/20221120/2b776afa25f54a8684714ab735b5f333.png
[image-20201226221528564]: /images/20221120/51b2524647444e148ab7f733a62211ff.png
[image-20201226222832149]: /images/20221120/b91841cd6fdb4258b771355c3cca2bb0.png
[image-20201226223000413]: /images/20221120/7c8873af0a0a48c7b724772d0a4132bd.png
[image-20201226223519663]: /images/20221120/4388397c93ee49759d6015f6d1133c54.png
[image-20201226225018512]: /images/20221120/493a7fc62eeb42bbb7e4b577c824c3d9.png
[image-20201226224317704]: /images/20221120/f696aae25ebc4df6af51d4cc4b411353.png
[image-20201226224448369]: /images/20221120/c09f92272ff8411596dfe4c911550632.png
[image-20201226224542143]: /images/20221120/38d0ae1ee5ef46c38c69705daa9e73a3.png
[image-20201226224923719]: /images/20221120/0d40671630c64f3e9009868ae817147d.png
[image-20201226225553472]: /images/20221120/883af711552744ddad3f8e67dc353db4.png
[image-20201226235015023]: /images/20221120/6e8f2ee9e9ac4d2fb35b62d3707a1381.png
[image-20201226235254745]: /images/20221120/4079b2d8c4524d5d8313cdac40340fbd.png
[image-20201226235622855]: /images/20221120/61541e4ee7cb491ba03f23037cc0e027.png
[image-20201227000048834]: /images/20221120/ce2546edac8942b6a7f802575bbc44ba.png
[image-20201227000244645]: /images/20221120/8eee4a69be0e4a6bb47bd2620034fd22.png