计算机网络专题复习（传输层）

秒速五厘米 2023-05-31 15:19 29阅读 0赞

### 文章目录 ###

*  计算机网络专题复习（传输层）
 *   *  一，传输层概述
     *  二，UDP协议
     *   *  1，UDP的主要特点
     *  三，TCP协议
     *   *  1，TCP协议特点
         *  2，TCP报文段首部格式
         *  3，TCP连接管理
         *   *  三次握手
             *  四次挥手
         *  4，TCP可靠传输
         *   *   *  1，序号
                 *  2，确认
                 *  3，超时重传
         *  5，TCP流量和拥塞控制
         *   *  流量控制
             *  拥塞控制
             *   *  1，慢开始
                 *  2，拥塞避免
                 *  3，快重传和快恢复
                 *  4，拥塞控制和流量控制联系

# 计算机网络专题复习（传输层） #

> 作者今年大三，正在准备明年的春招，文章中有写得不对的，希望大家及时指出文章中的错误的地方，欢迎互粉，大家一起努力!

## 一，传输层概述 ##

**传输层的功能：**

*  传输层提供的是进程和进程之间的逻辑通信，网络层提供的主机之间的逻辑通信
 *  进行复用和分用
    
     *  复用：应用层的所有进程都可以通过传输层在传输到网络层
        
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70]
     *  分用：传输层从网络层收到数据后交付给指明的应用层中的应用进程
        
        ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 1]
 *  传输层对收到的报文进行差错检测

## 二，UDP协议 ##

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

### 1，UDP的主要特点 ###

*  **UDP是无连接的**，由于没有维护连接，建立连接和释放连接这些过程，所以可以减少开销和发送数据之前的时延
 *  **UDP使用最大努力交付，即不保证可靠交付**
 *  UDP是面向报文的，适合一次性传输少量数据的网络应用
    
    > 为什么说UDP是面向报文的呢？
    
    对于应用层交付下来的报文，UDP协议不拆分也不合并，添加上UDP首部后就交付给网络层，所以，对于UDP协议要选择合适大小的报文
    
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 2]
    
    > 如果应用层交付下来的报文过大，会怎样？
    
    如果应用层交付下来的报文过大，UDP在添加上首部之后交付给网络层，网络层需要对这个报文分片交付给数据链路层，为什么要分片交付，因为数据链路层有一个MTU的要求，如果IP数据报的长度大于MTU（最大传输单元），这时候就需要对IP数据报进行分片处理后再经由链路层转发，所以，分片发送会降低网络层的交付效率。
    
    > 如果应用层交付下来的报文过小，会怎样？
    
    如果应用层交付下来的报文过小，传送到网络层的时候，IP数据报部分相对于IP首部来说少很多，显得IP首部相对长度太大，这样也会降低网络层的效率（附加信息类如IP首部相对较多，真正数据较少）
 *  **UDP没有拥塞控制**，适合实时应用
 *  **UDP首部相对TCP小**，只有八个字节
    
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 3]

## 三，TCP协议 ##

### 1，TCP协议特点 ###

*  TCP是面向连接的传输层协议
 *  每个TCP连接只能是点对点的连接，所以TCP协议无法用于广播和多播
 *  TCP提供可靠交付的服务，无差错，不丢失，不重复，按序到达
 *  TCP提供全双工通信
 *  TCP是面向字节流的，TCP把应用程序交下来的数据看成是一连串的无结构的字节流

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 4]

> 字段解释

*  **序号：**
    
    在一个TCP连接中传送的每一个字节都是按顺序编号的，序号则表示发送数据的第一个字节的序号
 *  **确认号：**
    
    期望收到对方下一个报文段的第一个字节的序号，若报文段确认号是N，则N - 1 为止的数据正确接收
 *  **数据偏移：**
    
    TCP首部长度
 *  **URG：**
    
    当URG = 1 时，是高优先级的数据，应该尽快发送
 *  **ACK：**
    
    当ACK = 1时，确认号有效，在连接建立后，所有传送报文段的ACK应置为1
 *  **PSH：**
    
    当PSH = 1接收端应该尽快接收，不用等接收缓存满了才接收
 *  **RST：**
    
    当RST = 1需要重新建立连接
 *  **SYN:**
    
    当SYN = 1时，表示这是一个连接请求报文
 *  **FIN：**
    
    当FIN = 1时，表示要求释放连接
 *  **窗口：**
    
    允许对方下次发送的数据量

### 3，TCP连接管理 ###

#### 三次握手 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 5]

> SYN洪泛攻击

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

#### 四次挥手 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 6]

> 为什么A在发送完最后一个确认报文段之后，需要经过2MSL的时间才关闭连接呢？其理由如下：

*  假如第四次挥手失败了，因为丢失而未到达服务器会怎样呢？这样，服务器会一直收不到客户端的回应，也就无法得知客户端是否收到了即将要断开连接的请求。客户端此刻还蒙在鼓里，还在等待服务器继续发送消息。服务器不能判断客户端是否收到，本身就是一个BUG，于是才有的等待2MSL的情况。为了保证客户端最后一次挥手的报文能够到达服务器，若第4次挥手的报文段丢失了，服务器就会超时重传第3次挥手的报文段，所以客户端此时不是直接进入CLOSED，而是保持TIME\_WAIT（等待2MSL就是TIME\_WAIT）。当客户端再次受到服务器因为超时重传而发送的第3次挥手的请求时，客户端就会重新给服务器发送第4次挥手的报文（保证服务器能够受到客户端的回应报文）。最后，客户端、服务器才真正断开连接。说白了，等待2MSL就是为了确保服务器能够受到客户端最后的回应。
 *  如果客户端直接CLOSED，然后又再次向服务器发起一个新连接，谁也不能保证新发起的连接和刚关闭的连接的端口号是不同的，有可能新、老连接的端口号就是一样的。假设新、老连接端口号一致，若老连接的一些数据仍滞留在网络中，这些滞留数据在新连接建立后才到达服务器，鉴于前后端口号一致，TCP协议就默认这些数据属于新连接，于是数据就这样乱成一锅粥了。所以TCP连接还要在TIME\_WAIT状态下等待2MSL，确保所有老连接的数据都在网络中消失！

### 4，TCP可靠传输 ###

> 什么是可靠传输？

可靠传输就是保证接收方进程从缓存中读出的字节流和发送方发出的字节流是完全一样的。

> TCP可靠传输模型？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 7]

> 下面就来说说可靠传输机制实现中的，序号，确认和超时重传

##### 1，序号 #####

TCP是面向字节流的传输协议，所发送的字节流是按序到达，每一个发送的字节流都有一个序号，每次发送的是一个报文段，那么这个报文段的发送序号就是该报文段第一个字节的序号。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 8]

> 在接收方的接收缓存接收到发送序号为1的报文段后又会如何处理呢？

##### 2，确认 #####

在接收方接收缓存接收到发送序号为n的报文段后，会给发送方发送一个确认号，该确认号等于下一次期待收到的发送序号X,这就表示之前X - 1的报文段正确接收

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 9]

> 如果有时候有些报文段由于网络路由没有按序到达，确认号又怎样?

本来应该收到的是序号为3的报文段，但是序号为3的报文段因为网络路由的情况没有按序到达，此时的确认号还是3，表示期待收到发送序号为3的报文段，以保证按序到达

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 10]

> 那如果发送方迟迟没有收到接收方的确认报文段，又会如何处理？

##### 3，超时重传 #####

如果迟迟没有接收到接收方的确认报文段，其实发送方会维护一个超时重传计时器，每次发送方成功发送一个报文段，就会启动超时重传计时器，成功接收到接收方的确认报文段，超时重传计时器就是重置。如果接收方的确认报文段丢失或者没有在规定时间内到达，那么发送方就会重传已发送的报文。

TCP采用一种自适应的算法，动态改变重传时间RTTS（加权平均往返时间）

### 5，TCP流量和拥塞控制 ###

#### 流量控制 ####

> 什么是流量控制？

流量控制就是指防止发送方发送的速率过快导致接收方接受不过来

> 怎样实现流量控制?

TCP使用滑动窗口协议来实现流量控制，滑动窗口类似一个窗口一样的东西，可以告诉发送方可以发送的数据的大小（相当于接收方接收缓存能接收的最大大小），使用滑动窗口，可以一次发送多个数据包，提高了性能，而且还能根据网络和接收方接收情况，调整发送的数据包的大小，让接收方能接收的过来，从而实现流量控制

流量控制过程：

*  接收方可以将自己可以接收的缓冲区的大小放入TCP首部中的窗口字段中，通过确认报文段发送给发送方，告知发送方你应该设置多大的发送窗口，窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要接收端的应答，可以一次连续的发送数据
    
     *  接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端收到这个值后，就会减慢自己的发送速度
     *  如果接收端发现自己的缓冲区满了，就会将窗口的大小设置为0，此时发送端将不再发送数据,但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

> 如果接收方的带有窗口值的确认报文段丢失了，怎么办？

B向A发送零窗口的报文段不久后，B的接收缓存有了些存储空间，这时，B向A发送400字节大小的窗口报文段，但是这个报文段发生了丢失，B一直在等待A发送过来的数据，A也一直在等待B的窗口大小报文段，双方僵持，类似java中的死锁，这就是TCP中的死锁现象？

*  接收方只要接收到发送方的零窗口通知，就启动持续计时器
 *  如果持续计时器的时间到了，原接收方就发送一个零窗口的探测报文
 *  原发送方接收到这个探测报文段后给出当前窗口的大小
 *  若当前窗口的大小 = 0，原发送方就重新设置持续计时器
 *  若当前窗口的大小 ！= 0，死锁将打破，双方不再僵持

#### 拥塞控制 ####

> 什么是拥塞？

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种现象称为拥塞 。  
若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

> 发送方如何知道网络拥塞？

![70][]

> TCP使用四种拥塞控制算法来实现拥塞控制

先明确几个概念：

*  接收窗口 ： 接收方根据接收缓存设置的值，告知发送方反映接收方容量
 *  拥塞窗口 ： 发送方根据自己估算的网络的拥塞程度而设置的窗口值，反映在当前网络情况下的发送容量
 *  发送窗口 = Min\{ 接收窗口，拥塞窗口\}

![img][]

##### 1，慢开始 #####

**算法思路**

*  从小到大的增大发送窗口大小
 *  使用慢开始算法后，每经过一个传输轮次 (transmission round)，窗口 cwnd 就加倍。
 *  一个传输轮次所经历的时间其实就是往返时间 RTT。

**慢开始门限ssthresh**

> 避免拥塞窗口增大过大引发网络拥塞

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

![è¿™é‡Œå†™å›¾ç‰‡æè¿°][70 1]

![è¿™é‡Œå†™å›¾ç‰‡æè¿°][70 2]

##### 2，拥塞避免 #####

> 当到达门限值后改用拥塞避免算法

拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

![è¿™é‡Œå†™å›¾ç‰‡æè¿°][70 3]

拥塞窗口调整为1，门限值减少为原来的一半

![è¿™é‡Œå†™å›¾ç‰‡æè¿°][70 4]

调整结束，开始执行慢开始

##### 3，快重传和快恢复 #####

**快重传算法思路**

*  采用快重传FR (Fast Retransmission) 算法可以让发送方尽早知道发生了个别报文段的丢失。
 *  快重传 算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
 *  发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
 *  不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

**快恢复算法思路**

当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：

(1) 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；

(2) 新拥塞窗口 cwnd = 慢开始门限 ssthresh ；

(3) 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

![åœ¨è¿™é‡Œæ’å¥å›¾ç‰‡æè¿°][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 11]

从上图中

*  初始化慢开始，窗口值为1和门限值
 *  执行慢开始：每经过一个传播轮次，窗口值翻倍
 *  当窗口值 = 门限值，执行拥塞避免算法
 *  窗口值重置为1，门限值 变成原来的一半
 *  当发送端收到连续3个重复的ACK，则执行快重传，立刻重传丢失的报文
 *  执行了快重传判断该网络很可能没有拥塞，因此执行快恢复算法
 *  门限值 = 窗口值 /2 ，新窗口值 = 门限值
 *  开始执行拥塞避免算法，让窗口慢慢增大

##### 4，拥塞控制和流量控制联系 #####

*  拥塞控制  
    拥塞控制通常表示的是一个全局性的过程，它会涉及到网络中所有的主机、  
    所有的路由器和降低网络传输性能的所有因素
 *  流量控制  
    流量控制发生在发送端和接收端之间，只是点到点之间的控制

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70]: /images/20230531/ca2292412f934b05b762ec55355ac561.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 1]: /images/20230531/56def85674a54b43baf821ac9f19f297.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 2]: /images/20230531/859201c1844943ab9448966cae272dc0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 3]: /images/20230531/51661719415b4d6a918e9f42fea26299.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 4]: /images/20230531/349b7169c8034477ae19854479eb26c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 5]: /images/20230531/ca2f286e5dc74be39de8803081812189.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 6]: /images/20230531/0fc782585bff447dbadfb1389e1d64da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 7]: /images/20230531/0ee431adb6874ec48977f240dba981af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 8]: /images/20230531/548386ff1952406fa431e5681912961e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 9]: /images/20230531/d17f34ffa4a44e07b7497d9223aa094f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 10]: /images/20230531/10f5b7f395fc4b33beb87f8e96013014.png
[70]: https://img-blog.csdn.net/20180801101712872?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhbmd6aGFuZ2ppbmc5Nw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[img]: https://img-blog.csdn.net/20130801220438375?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc2ljb2ZpZWxk/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast
[70 1]: https://img-blog.csdn.net/20180808114749982?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhbmd6aGFuZ2ppbmc5Nw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 2]: https://img-blog.csdn.net/20180808123619362?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhbmd6aGFuZ2ppbmc5Nw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 3]: https://img-blog.csdn.net/20180808123806958?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhbmd6aGFuZ2ppbmc5Nw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 4]: https://img-blog.csdn.net/2018080812385281?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rhbmd6aGFuZ2ppbmc5Nw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ_size_16_color_FFFFFF_t_70 11]: https://img-blog.csdnimg.cn/20190624010206664.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTkyMjI4OQ==,size_16,color_FFFFFF,t_70