计算机网络4————运输层

旧城等待， 2022-03-25 17:58 539阅读 0赞

# 计算机网络4————运输层 #

### 文章目录 ###

*  计算机网络4————运输层
 *   *   *  一.概述
         *   *  1.运输层功能
             *  2.运输层的两个主要协议
         *  二.端口号和套接字
         *   *  1.端口
             *  2.套接字
         *  三.无连接运输协议UDP
         *   *  1.UDP概述
             *  2.UDP特点
             *  3.UDP数据报格式
             *  4.UDP的应用
         *  四.面向连接运输协议TCP
         *   *  1.TCP的特点
             *  2.面向字节流
             *  3.TCP报文段首部格式
         *  五.可靠数据传输原理
         *   *  1.概述
             *  2.停止等待
             *  3.流水线传输
             *  4.回退N步
             *  5.选择重传
         *  六.TCP的可靠传输和流量控制
         *   *  1.可靠传输
             *  2.流量控制
             *  3.流量控制的示例
             *  4.持续计时器
         *  七.TCP的连接管理
         *   *  1.概述
             *  2.TCP的三次握手
             *  3.TCP的四次挥手
             *  4.TCP的状态机
             *  5.TCP的保活计时器
             *  6.TCP的数据等待计时器
             *  7.三握四挥中的一些问题
         *  八.TCP的拥塞控制
         *   *  1.概述
             *  2.拥塞控制方法
             *  3.慢启动
             *  4.拥塞避免
             *  5.快重传
             *  6.快恢复
             *  7.示例
         *  九.参考资料

### 一.概述 ###

我们先简单回顾下前面三层的主要作用

*  物理层：透明传输比特流
 *  数据链路层：在两个相邻结点(主机和路由器，两个路由器)之间透明传数据。
 *  网络层：完成网络中不同端系统之间的数据传输。网络层主要解决的关键问题——路由选择。

接下来我们来看下网络层的上一层，运输层

#### 1.运输层功能 ####

运输层的主要功能实际上就是提供了两个主机中的应用进程相互通信的功能。应用进程之间的通信又称为端到端通信。

*  从通信和信息处理的角度，运输层向它上面的应用层提供服务，它属于面向通信部分的最高层，同是也是属于用户功能的最底层.
 *  运输层向高层用户屏蔽了下面的网络核心的细节（如网络拓扑，所采用的路由协议）
 *  它使应用进程看见的就是好像两个运输层实体之间有一条端到端的  
    ![在这里插入图片描述][2019012215185571.png]

#### 2.运输层的两个主要协议 ####

TCP/IP的运输层有两个不同的协议

*  传输控制协议TCP
    
     *  面向连接服务
     *  可靠数据传送服务
     *  拥塞控制服务
     *  传输的数据单位是TCP报文段
 *  用户数据报协议UDP
    
     *  无连接高效率
     *  传输的单位是UDP或者用户数据报  
        ![在这里插入图片描述][20190122152702167.png]

### 二.端口号和套接字 ###

#### 1.端口 ####

在互联网中，通过IP地址可以标识一台主机，那么如何在一台主机内，找到一个进程呢。这个就是依靠的端口号。

**a.端口相关**

*  每一个端口有一个端口号，以区分不同的端口
 *  利用全局唯一的IP地址标识主机，用本地唯一的端口号来标识这台主机的进程
 *  为了区别是TCP还是UDP服务，还要指明运输层协议
 *  进程通过系统调用与某端口建立关联后，相应的应用进程交付给运输层的数据也要通过该端口输出，而运输层交付给该端口的数据都被相应的应用进程所接收。
 *  为了能够描述两个进程的管理，需要一个五元组来进行描述（运输层协议，本地主机IP地址，本地端口号，远程主机IP地址，远程端口号）

**b.运输层多路复用和多路分用**

*  多路复用：指多个应用进程基于同一个运输层协议发送数据
 *  多路分用：指由一个运输层协议将报文中的数据交付给不同的应用进程
 *  上述两种都是通过端口实现的  
    ![在这里插入图片描述][20190122175826776.png]

**c.端口类别**

*  周知端口号，范围0-1023，也称为“常用端口”或“保留端口”，有INAN统一分配，作为公共应用服务的端口，并将分配结果公布于众。![在这里插入图片描述][20190122181449268.png]
 *  注册端口号，范围1024~49151，被保留用作商业性开发，厂商需要向IANA注册，以避免重复。
 *  临时端口号，范围49152~65535，也称为“动态端口”或“自由端口”。本地系统随机分配，不能在IANA注册。

#### 2.套接字 ####

在大多数操作系统中，使用的是系统调用（System call）的机制在应用程序和操作系统之间传递控制权，而系统调用接口实际上就是应用进程的控制权和操作系统的控制权进行转换的一个接口，即应用编程接口API。  
![在这里插入图片描述][20190122185406891.png]同样的，操作系统也给应用程序提供了两套TCP/IP的API

*  Berkeley UNIX操作系统定义了一种API，称为套接字接口（socket interface）
 *  微软公司在其操作系统中采用了套接字API，形成了一个稍有不同的API，并称为Windows Socket，简称为WinSock

**Socket通信的大致过程**

*  当应用进程需要使用网络进行通信是就发出系统调用，请求操作系统为其创建“套接字”，以便把网络通信所需要的系统资源分配给应用进程。
 *  操作系统为这些资源的总和用一个套接字描述符的号码来表示，并把此号码返回给应用进程，应用进程所进行的网络操作都必须使用这个号码
 *  通信完毕后，应用进程通过一个关闭套接字的系统调用，通知操作系统回收与该“号码”相关的所有资源  
    ![在这里插入图片描述][20190122190251503.png]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70]

### 三.无连接运输协议UDP ###

#### 1.UDP概述 ####

*  UDP和IP协议一样提供无连接服务，它在IP的数据报服务之上增加了进程通信能力
 *  UDP的运行环境应该是高可靠性的网络
 *  如果运行在不可靠的网络上，则UDP之上的应用程序必须解决报文损坏，丢失，重复，失序等可靠性问题。

#### 2.UDP特点 ####

*  UDP是无连接的，即发送数据之前不需要建立连接
 *  UDP使用尽最大努力交付，即不保证可靠交付。无需维持复杂的连接状态表。
 *  UDP没有拥塞控制，因此网络拥塞不会使源主机的发送速率降低，允许拥塞造成的丢失，不允许大时延
 *  UDP是面向报文的
    
     *  发送方UDP对应用层交下来的报文 ，既不合并，也不拆分，而是保留这些报文的边界
     *  应用层发送给UDP多长的报文，UDP就照样发送，即一次发送一个报文
     *  接收方UDP对IP层上交的UDP用户数据报，在除去首部后，就原封不动的交付给上层的应用进程，一次交付一个完整的报文。
     *  应用程序必须选择合适大小的报文
 *  UDP支持一对一，一对多，多对一，多对多的交互通信
 *  UDP首部固定8字节，开销少，处理时延小

#### 3.UDP数据报格式 ####

UDP的首部字节有8字节，有4个字段组成，每个字段都是两个字节。  
![在这里插入图片描述][20190122192603677.png]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 1]

#### 4.UDP的应用 ####

*  流媒体
 *  实时游戏
 *  物联网
 *  4g网络的GTP-U协议
 *  QUIC

### 四.面向连接运输协议TCP ###

#### 1.TCP的特点 ####

*  TCP是面向连接的运输层协议，即在数据传输之前必须建立连接，即在两个通信的TCP进程之间互相确认对方是否存在，并且处于活动状态，同时为两个进程之间的通信协商一些参数，并预留资源。
 *  每一条TCP连接只能有两个端点，也就是说，TCP只能点对点使用
 *  TCP提供全双工通信
 *  TCP是面向字节流的

#### 2.面向字节流 ####

*  字节流是指，流入进程或进程流出的字节序列
 *  TCP协议把应用层报文看出一连串无结构的字节流。将其分解为多个TCP报文段进行传输，在目的站在重新装配这些段，必要的时候重新发送没有收到的端。
 *  TCP不保证接收进程收到的数据块和发送进程发送的数据块具有对应的大小关系
 *  TCP保证接收进程收到的字节流和发送进程发送的字节流一致。  
    ![在这里插入图片描述][201901222106297.png]

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

下图TCP报文首部  
![在这里插入图片描述][20190122210759646.png]

*  源端口 目的端口：发送进程和接收进程的端口号
 *  序号字段：占32比特，TCP连接中传送的数据流中的每一个字节都编上一个序号，“序号”字段的值是本报文段的数据部分的第一个字节的序号。
 *  确认号字段：占32比特，是期望收到对方的下一个报文段的数据部分的第一个字节序号。（确认号 = n，表明到序号n-1为止的所有数据都已经正确收到）
 *  数据偏移字段：占4比特，它指出TCP报文但的数据起始处距离TCP报文段的起始处有多远。
 *  保留字段：占6比特，保留为今后使用，目前置为0
 *  URG：紧急比特，当URG = 1，表明紧急指针字段有效，它告诉系统此报文段有紧急数据，应尽快传送
 *  ACK：确认比特，当ACK = 1时，确认号字段才有效，否则无效
 *  PSH：推送比特，TCP接受方收到推送比特为1的报文段，就会尽快将数据交付给应用进程，而不再等到整个缓存都填满了在向上交付
 *  PST：复位 比特，当RST = 1时，表明TCP连接中出现的严重差错，必须释放连接，然后在重新建立运输连接，同时也用于拒绝非法的TCP报文段或者拒绝连接请求
 *  SYN：同步比特，当SYN = 1时，表明这是一个连接请求或者连接接收的报文
 *  FIN：终止比特，当FIN = 1时，表明这是一个释放请求或者释放请求接收的报文
 *  窗口字段：占两字节，窗口是指发送本报文段的一方的接收窗口（RWin），是让对方设置发送窗口的依据，单位为字节。窗口字段明确指出现在允许对方发送的数据量，窗口值是经常在动态变化着。
 *  检验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，也要在TCP报文段的前面加上12字节的伪首部。  
    ![在这里插入图片描述][20190123181426337.png]
 *  紧急指针：占16比特，紧急指针指出本报文段中紧急数据有多少字节（紧急数据放在报文段数据的最前面）
 *  选项，TCP的选项包含很多项，简单列举其中几项
    
     *  MSS选项，最大报文段长度，占，它出现在SYN标志为1的TCP报文中，即在TCP连接建立阶段，MSS = TCP报文段长度-TCP首部长度
     *  窗口扩大因子，占3字节，其中有一个字节表示窗口扩大因子S，把窗口值向左移动S为后获得实际的窗口大小，即 实 际 窗 口 值 = 首 部 中 定 义 的 窗 口 值 × 2 s 实际窗口值 = 首部中定义的窗口值 \\times2^s 实际窗口值=首部中定义的窗口值×2s![在这里插入图片描述][2019012318471894.png]
     *  时间戳选项,占10字节，其中最主要的字段是时间戳值和时间戳回送应答字段
        
         *  ![在这里插入图片描述][20190123190047793.png]
         *  功能1：用于计算往返时间RTT，RTT = t2（收到确认） - t1（发送报文段）
         *  功能2：用于防止序号绕回，用时间戳和序号的组合来标识一个报文段

### 五.可靠数据传输原理 ###

#### 1.概述 ####

可靠传输是指将物理层不可靠的信道变成逻辑上可靠的信道。有了可靠传输的支持，向上交付的数据都可以认为是无差错的，不丢失，无重复，不失序的。

可靠传输并不是特指某一层才能实现，在任意一次都可以实现，比如运输层和数据链路层都可以实现。  
![在这里插入图片描述][20190123220838173.png]接下来我们看如何实现一个可靠传输协议。

首先是最简单的停止等待协议开始。

#### 2.停止等待 ####

理想状况下的数据传输：  
![在这里插入图片描述][20190123221514970.png]但是很显然，理想中的情况并不存在，所以我们一个个分析它会出现的问题。

**问题1：实际环境主机处理速度不匹配（接收方和发送方）将导致缓存溢出**  
解决思路：引入确认反馈进制调节发送速度。即只有发送方收到接收方的确认消息，发送方才会发送一个数据包。  
![在这里插入图片描述][20190123222442886.png]**问题2：实际信道质量不能保证，数据可能出错**  
解决思路：出错是返回NAK，肯定确认ACK  
![在这里插入图片描述][20190123223527172.png]**问题3：实际信道质量不能保证，数据有可能丢失**  
解决思路：因此超时重传机制，即当一定时间内为接收到ACK，重新发送该数据包  
![在这里插入图片描述][20190123223615977.png]在此基础上，对SW1进行简化，当使用超时重传时，发送错误时，不需要发送NAK，直接丢弃数据包

**问题4：确认丢失导致分组重复接收**  
解决思路：给分组编“发送序号”  
![在这里插入图片描述][20190123224032468.png]**问题5.确认的迟到，导致确认重复接收**  
解决方法：给“确认”编号  
![在这里插入图片描述][20190123224153137.png]**总结**  
![在这里插入图片描述][20190123224502408.png]  
停止等待协议的要点

*  差错检验
 *  接收方的确认
 *  定时器和重传
 *  发送报文序号
 *  应答报文序号

停止等待协议的缺点

*  传播时延大
 *  信道带宽高
 *  数据短时，信道利用率低

解决方法

*  大数据，但由于信道的误码率，不能太大
 *  运行同时传输多个数据，即下面要提到的流水线传输

#### 3.流水线传输 ####

流水线传输的要点

*  在发完一个分组后，不是停下了等待确认，而是可以继续在发送多个分组
 *  如果在发送过程中收到接收方的肯定确认，可以继续发送数据
 *  由于信道上一直有数据不间断的传送，这种传输方式可以获得很高的信道利用率
 *  实现流水线技术对实现可靠数据传输的要求
    
     *  必须增加序号范围
     *  发送方和接收方必须缓存多个分组
 *  处理流水线差错的两种基本方式（具体内容下面介绍）
    
     *  回退N步（GBN）
     *  选择重传（SR）

#### 4.回退N步 ####

回退N步思想很简单:当出现差错必须重传时，要回走N个数据，然后在开始重传。  
![在这里插入图片描述][2019012414044956.png]  
存在的问题

*  当未被确认的数据数目太多时，只要出现数据差错，就可能有很多数据要重新发送，浪费了很多时间，增大了开销
 *  为了对所发送出去的大量数据编号，每个数据的发送序号要占用比较多的比特数，有增加了不必要的开销。

解决思路

*  在GBN协议中，限制可以连续发出的最多数据个数（已发出但为确认的数据），作出限制。即滑动窗口
 *  循环重复使用有限的数据序号。

**滑动窗口**

*  发送端设定发送端口，发送端口 W s W\_s Ws表示在还没有收到对方确认信息的情况下，发送端最多可以连续发送数据的个数![在这里插入图片描述][20190124145436205.png]
 *  接受的设定接收窗口，是接收窗口 W R W\_R WR代表可以连续接收的最多数据的个数，窗内是当前欲接收的数据发发送序号，只有当收到的数据的序号和接收的发送序号一致是，才能接收该数据![在这里插入图片描述][20190124145944838.png]
 *  只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才能向前滑动，即接收窗口驱动发送窗口滑动。

**GBN协议小结**

*  GBN协议的接收窗口为1
 *  接收方根据滑动窗口的序号按序接收分组，窗口中的失序分组以及和后面将被丢弃
 *  发送方采用超时重传来重传丢失或者差错分组
 *  接收方采用累积确认的方式，可以不一 一确认。

**GBN协议的缺点**  
在GBN协议中，由于 W R = 1 W\_R = 1 WR=1,造成回退N步问题：出错分组及其后续分组都要重传，不管后续分组是否传输正确，那么有没有办法只重传出现问题（丢失/错误）的数据呢？

解决方法：选择重传协议

#### 5.选择重传 ####

选择重传协议要点：

*  接收窗口 W R > 1 W\_R>1 WR>1,先收下发送序号不连续但仍处在接收窗口的那些数据。等待所缺序号的数据收到后，在一并送给主机。
 *  选择重传协议可避免重复发送那些本来已经正确到达的接收端的数据。
 *  但付出的代价是在接收端要设置具有相当容量的缓存空间。

图示：  
![在这里插入图片描述][20190124172853682.png]

### 六.TCP的可靠传输和流量控制 ###

#### 1.可靠传输 ####

TCP的可靠传输，就是上面我们所说的，选择重传协议，包含序号，确认，超时重传，滑动窗口。不同的是，它的滑动窗口可变。

而加入滑动窗口可变的原因就是我们所说的流量控制。

#### 2.流量控制 ####

流量控制是用于防止发生方发送过快，从而导致接收方无法接收。  
下图是一个数据发送过程的示意图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 2]  
**RWin的确定**  
下图是TCP的接收缓存示意图  
![在这里插入图片描述][20190124183532831.png]

*  接收方设置接收窗口RWin = RcyBuffer - \[LastByteRcvd - LastByteRead\]
 *  若接收应用程序来不及读取收到的数据，接收缓冲区最终会被填满，使得RWin减小为0
 *  若接收应用程序能够及时读取收到的数据，RWin就可以增大，但最终不能超过接受缓存的大小
 *  所以RWin是可变的。

**发送量的确定**  
![在这里插入图片描述][20190124184536538.png]

*  发送量 = LastByteSent - LastByteAcked <=RWin
 *  发送窗口通常只是发送缓存的一部分

发送缓存用来暂时存放：

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

接收缓存用来暂时存放：

*  按序到达的，但尚未被接收应用程序读取的数据
 *  不按时达到的数据

#### 3.流量控制的示例 ####

假设：A是发送方，B是接收方。假定A收到B发来的确认报文段，该报文段的窗户字段是20，确认的字段是31，据此，A构造出自己的发送窗口。

![在这里插入图片描述][20190124191405744.png]A发送了11个字节数据后  
![在这里插入图片描述][20190124191538552.png]假设B收到31号数据，并把31-33的数据交付给主机，然后B删除这些数据，A收到新的人确认号为34号，即31-33被确认，发送窗口滑动。  
![在这里插入图片描述][2019012419192868.png]  
A继续发送42-53号数据，指针P2向前和P3重合，A的发送窗口内的序号都已经用完了，但还是没有再收到确认，必须停止发送。

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

#### 4.持续计时器 ####

当采取可变的RWin来进行流量控制时，就可能会产生下面的问题：

B向A发送了RWin = 0 的报文段后不久，B的接收缓存区又有一些存储空间。于是B向A发送了RWin = 400的报文段，然而这个报文段丢失了，则A一直等待收到B发送的非0窗口。而B一直等待A发送的数据。

解决方法：引入持续计时器

*  只要TCP连接的一方是收到对方的0窗口通知，就启动持续计时器。
 *  若持续计时器设置的时间到期，就发送一个窗口探测报文段
 *  对方收到这个探测报文段时，就会发生确认报文段（其窗口值就是现在的窗口值）
 *  若窗口值始终为0，会周期性发送探测

### 七.TCP的连接管理 ###

#### 1.概述 ####

TCP连接有三个阶段，即：连接建立（三次握手），数据传送（即上文的流量控制），连接释放（四次挥手）。运输连接管理就是使运输连接的建立和释放都可以正常的进行。

这也是为什么TCP称为面向连接的协议原因，也是他是可靠协议的原因。

和连接管理相关的字段：

*  SYN：同步比特，当SYN = 1时，表明这是一个连接请求或者连接接收的报文
 *  ACK：确认比特，当ACK = 1时，确认号字段才有效，否则无效
 *  seq：序号字段：占32比特，TCP连接中传送的数据流中的每一个字节都编上一个序号，“序号”字段的值是本报文段的数据部分的第一个字节的序号。
 *  ack：确认号字段：占32比特，是期望收到对方的下一个报文段的数据部分的第一个字节序号。
 *  FIN：终止比特，当FIN = 1时，表明这是一个释放请求或者释放请求接收的报文

#### 2.TCP的三次握手 ####

**a.连接建立过程中要解决的问题**

*  要是每一方都确知对方的存在。
 *  要允许双方协商一些参数（如最大报文段，最大窗口大小，服务质量等）
 *  能够对运算实体资源（如缓存大小，连接表中的项目等）进行分配。

要完成上述，可以将握手过程简化为下面四次交互

> (1) Client端首先发送一个SYN报，告诉Server端，我要连接，并且我的初始序号为X  
> (2) Server端收到SYN包后，给Clinet回复一个ACK，告诉CLient我收到了  
> (3) 接着Service端也需要告诉Client端自己的初始序列号，于是Service也发送一个SYN包告诉Client我的初始序列化是Y  
> (4) Client收到后，回复给Server一个ACK确认包

整个过长4次交互即可完成，但是上面的2,3即Service的SYN包和ACK包，可以合并成为一个SYN和ACK包一起发送。所以加起来就是3次握手。

**b.第一次握手**  
![在这里插入图片描述][20190124211436910.png]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 3]  
**b.第二次握手**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 4]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 5]  
**c.第三次握手**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 6]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 7]

#### 3.TCP的四次挥手 ####

**a.端断开连接需要解决的问题**

*  回收资源
 *  终止数据传输
 *  peer两端都拆除通信通道

要完成上述，可以将悔手过程也可以简化为下面四次交互

> (1) Client发送一个FIN包来告诉Service我已经没有数据发送给Server了  
> (2) Server收到后回复一个ACK确认包说我知道了  
> (3) 然后Server在自己也没有数据发送给Client后，Service也发送一个FIN包给Client告诉Client我也没有数据发送了  
> (4) Client收到后，就回回复一个ACK确认包说我知道了。

抓包的四次挥手。

![在这里插入图片描述][2019012512054365.png]  
**b.第一次挥手**  
![在这里插入图片描述][201901242120127.png]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 8]  
**c.第二次挥手**  
![在这里插入图片描述][20190125122814551.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 9]**d.第三次挥手**  
![在这里插入图片描述][20190125122924387.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 10]**e.第四次挥手**  
![在这里插入图片描述][20190125123003943.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 11]

#### 4.TCP的状态机 ####

**a.三次握手的状态机**  
![在这里插入图片描述][20190125125601457.png]客户端：ClOSED–>SYN-SENT–>ESTABLISHED  
客户端：CIOSED–>SYN-ECVD–>ESTABLISHED

**b.四次挥手的状态机**  
![在这里插入图片描述][20190125130340402.png]客户端：ESTABLISHED–>FIN-WAIT-1–>FIN-WAIT-2–>TIME-WAIT–>CLOSED  
服务端：ESTABLISHED–>CLOSE-WAIT–>LAST-ACK–>CLOSE

**c.TCP的全部状态机转换**  
![在这里插入图片描述][20190125135812345.png]

#### 5.TCP的保活计时器 ####

原理：  
每当服务器收到客户的信息时，就将Keeplive timer（保活计时器），超时通常设置2两小时，若服务器超过两小时还没有收到来自客户的信息，就发送探测报文，若发送10个探测报文段（每75s发送一个）还没有收到响应，就终止连接。

作用：  
因为TCP是面向连接的，所有就可能出现只连接不传送数据的连接，服务器检测到这种连接之后，并在一定条件释放这种连接

#### 6.TCP的数据等待计时器 ####

时间等待计时器用于链接终止时，即TIME-WAIT阶段，通常时间设置为2MSL

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

目的：  
(1) 如果四次挥手的最后一次挥手，丢失，那么服务器就以为是它的FIN丢失，因而重传。如此此时没有等待计数器，客户端直接进入closed状态，那么此时他就永远无法收到这个重传的FIN报文，服务器也接收不到ACK报文，此时服务器就无法关闭这个链接。2MSL可以使客户端等待足够长的时间，这样就使得如果ACK丢失，客户端也可等下一个FIN的到来。如果在2MSL时间内，一个FIN到达了，客户端就重发一个ACK，并重新启动一个时间等待计时器。

(2)防止旧链接的报文出现在新连接中。如果客户端和服务端关闭了连接，短时间内用打开了一个新的连接，这个新连接就有可能收到旧连接的报文，并解释为新连接的内容。为了避免这个问题，TCP规定新连接必须经过2MSL时间以后才能出现。

MSL

> MSL即报文最大生存时间，指任何报文被丢弃前在网络内的最长时间。

#### 7.三握四挥中的一些问题 ####

**问题1.建立连接一定是3次吗？**  
不一定，在特殊情况下有可能是4次，即通信双方（A和B）同时发起连接。  
A：发送SYN包，状态由ClOSED–>SYN\_SENT  
B（几乎同时）:发送SYN包，状态由ClOSED–>SYN\_SENT  
A:收到B的SYN包，发送SYN-ACK包，状态由CLOSED–>SYN\_RCVD  
B:收到A的SYN包，发送SYN-ACK包，状态由CLOSED–>SYN\_RCVD  
A:收到B的SYN-ACK包，状态由SYN\_RCVD–>ESTABLISHED  
B:收到A的SYN-ACK包，状态由SYN\_RCVD–>ESTABLISHED  
![在这里插入图片描述][20190125165500197.png]

**问题2.断开连接一定是4次吗？**  
不一定：TCP是全双工通信，Client自己已经不会再有数据发送给Server后，就可以发送给Service，这边已经终止Client到对端Server的数据传输。但这个时候对端的Server可能还有数据还需要传输，于是Server还继续向Client继续传输数据。所有这时候至少需要4次挥手。

但是，如果Server收到Client的FIN包之后，在也没有数据发送个Client，那么此时对Client的ACK和FIN包就可以合并成一个包发送过去，此时四次挥手就变为三次了。  
![在这里插入图片描述][SouthEast]

**问题3.TCP如何处理报文丢失问题**  
对于报文的丢失，还是ACK的丢失。TCP都采取超时重传机制，当一定时间内还未收到ACK，不论是ACK丢失还是报文丢失，就重新发送当前报文。

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

#### 1.概述 ####

拥塞：在某段时间内，对网络中某资源的需求超过该资源能提供的可用部分，网络的性能变坏，这种情况叫做拥塞，对这种情况的解决或者缓解，称为拥塞控制。

网络资源：链路带宽容量，交换节点中缓存容量，CPU处理能力

拥塞控制和流量控制区别

拥塞控制

*  涉及所有主机和路由器，以及与降低网络性能有关的所有因素，是针对网络资源受限而设置的，是全局问题。
 *  保证网络能够承受现有的网络负荷
 *  拥塞控制对付的是链路和路由器

流量控制

*  与发送端和接收端亮点之间的通信有关，是针对端系统中资源受限而设置的，是局部问题，基于反馈进行控制。
 *  避免发生端的发送量超出接收端的承受能力
 *  流量控制对付的是主机

#### 2.拥塞控制方法 ####

*  接收窗口RWin：是接收端根据其目前的接收缓存所承诺的最新窗口值，是来自接收端的流量控制。是TCP首部的窗口字段
 *  拥塞窗口CWin：或者称为cwnd，是发送端根据自己估计的网络拥塞程度而设定的窗口值。
 *  发送端控制拥塞窗口的原则是：只有网络没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送过去，但只要网络出现拥塞，拥塞窗口就小一点。以减轻注入到网络中的分组数。
 *  发送窗口的上限值 = Min\[接收窗口,拥塞窗口\]

拥塞控制方法：

*  慢启动
 *  拥塞避免
 *  快重传
 *  快恢复

#### 3.慢启动 ####

慢启动：

*  在主机刚刚开始发送报文段时可先设置拥塞窗口CWin = 1，即设置为一个最大报文段的MSS的数值
 *  在每收到一个对新报文段的确认后，将拥塞窗口CWin+1，即增加一个MSS数值。

换句话说：  
发送拥塞窗口的最大长度的TCP报文段，若都得到确认，则拥塞窗口加倍。

具体过程如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 12]慢启动算法总结:

*  初始的CWin = 1
 *  每收到一个ACK，CWin++，呈线性上升
 *  每一个RTT，CWin = CWin \* 2，呈指数上升
 *  当增长的一个上限值（ssthresh）时，停止增长。

#### 4.拥塞避免 ####

拥塞避免：

*  慢启动不会长久的增加拥塞窗口，当CWin >=ssthresh时，停止使用慢启动算法而改用了拥塞避免算法
 *  拥塞避免算法算法的思路就是让拥塞窗口CWin缓慢的增大。即每经过一个往返时间RTT就把发送方的拥塞窗口CWin+1.

乘法减小：  
乘法减小是指不论在慢启动阶段还是拥塞避免阶段，只要出现一次超时，就把慢启动门限值ssthresh设置为当前的拥塞窗口值乘以0.5.同时将CWin = 1，启动慢启动算法。

#### 5.快重传 ####

快重传：

*  快重传算法首先要求接受方每收到一个失序的报文段后就立即发出重复确认，这样做可以让发送方及时知道有报文段没有到达
 *  发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必等待重传计时器

![在这里插入图片描述][20190125182744482.png]不难看出，快重传并非取消重传计时器，而是在某些情况下，可更早的重传丢失的报文段

#### 6.快恢复 ####

快恢复

*  当发送端收到连续三个重复确认时，就执行“乘法减小” 算法，把慢启动门限ssthresh设置为当前的拥塞窗口值的0.5倍，但接下去不执行慢启动算法
 *  由于发送方现在可能没有发送拥塞，因此现在不执行慢启动算法。而是将当前的CWin 设置为ssthresh减半的数值，然后启动拥塞避免算法。

当发生丢包时，会有两种情况

*  当RTO超时，重传数据包，TCP认为这种情况太糟糕了，反应也很强烈
    
     *  sshthresh = CWin/2
     *  启动慢启动算法
 *  收到三个重复确认时（立即开启重传，而不用等RTO超时）
    
     *  sshthresh = CWin/2
     *  CWin = sshthresh
     *  启动拥塞避免算法

#### 7.示例 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 13]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 14]

### 九.参考资料 ###

《计算机网络：原理和实践》

[2019012215185571.png]: /images/20220325/bbf2190f3f1f471fbbc9daf7a7e35445.png
[20190122152702167.png]: /images/20220325/f9149af2657e426fa9c9796cfdb768f5.png
[20190122175826776.png]: /images/20220325/9f787eb90d864970ac1c93b0a569b325.png
[20190122181449268.png]: /images/20220325/93b59c95fc53430c8ab85d10dd5d7622.png
[20190122185406891.png]: /images/20220325/652b27fb9a344cddaa7034857f1948c5.png
[20190122190251503.png]: https://img-blog.csdnimg.cn/20190122190251503.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70]: /images/20220325/9a0b56542a2b4cce826974f5b4ab6de5.png
[20190122192603677.png]: https://img-blog.csdnimg.cn/20190122192603677.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 1]: /images/20220325/0c0bbb43889648a494ce4966fcb3543b.png
[201901222106297.png]: /images/20220325/6186a39ab6544b8aa6c25556cbdb959d.png
[20190122210759646.png]: /images/20220325/81cb95f12399469b957f8a5f47c77f5b.png
[20190123181426337.png]: /images/20220325/d56c315e65ae4c9bbca78c5852b9602a.png
[2019012318471894.png]: /images/20220325/9e220054f2e94df483abf71b6e528269.png
[20190123190047793.png]: /images/20220325/e350d0d4b18f453ea18a446ae1ba473c.png
[20190123220838173.png]: /images/20220325/a54daea8f394445588bc44489ad805f3.png
[20190123221514970.png]: /images/20220325/b450171faf5b4fb582db19b65870c9b3.png
[20190123222442886.png]: /images/20220325/520911e15aa54c68a3a60da377cb8bd2.png?
[20190123223527172.png]: /images/20220325/469f2116024c4baba615eb216d53bd9e.png
[20190123223615977.png]: /images/20220325/ca0f8ac125504a5bad9da729def1fcd7.png
[20190123224032468.png]: /images/20220325/23d4b5cb711d4480973b4914f9d97bd0.png
[20190123224153137.png]: /images/20220325/d40a26fd5d7046178b94b68356ee2cad.png
[20190123224502408.png]: /images/20220325/c8570367edf24ca0a6f48392788590a0.png
[2019012414044956.png]: /images/20220325/8fc568ff10634fd783b17d8e40832a6d.png
[20190124145436205.png]: /images/20220325/534f5ed4cbe24bb4967732ff6420dca5.png
[20190124145944838.png]: /images/20220325/ae452894e1374cc196b9a4d97a2cc676.png
[20190124172853682.png]: /images/20220325/a9119d1d1fe64543a9043eeca0401ab8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 2]: /images/20220325/670d712ad32543e694548ef3d90fd0d9.png
[20190124183532831.png]: /images/20220325/e7423c49c3e947b5bbaa7b53bc0628a4.png
[20190124184536538.png]: /images/20220325/0ef61e3b329f41bd8f8c582282f5e18a.png
[20190124191405744.png]: /images/20220325/9c9f26746db54ddc9d8c00d313f7e7e6.png
[20190124191538552.png]: /images/20220325/2ef071579a844487b4e870255158c662.png
[2019012419192868.png]: /images/20220325/953d20ba98d1480eb45810daccf6b374.png
[20190124194321786.png]: /images/20220325/ae8acbcf4e5f4bdd9e0477a298e4fe58.png
[20190124211436910.png]: https://img-blog.csdnimg.cn/20190124211436910.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 3]: /images/20220325/3f2de1b697b04a869f2082840acf00c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20190124211637611.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 5]: /images/20220325/785249397cc943d0a0c5a6f0f0d0bcdf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20190124211826441.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 7]: /images/20220325/cbd3dbbc229042e8b1f736673b7501b5.png
[2019012512054365.png]: /images/20220325/93375c6967e0490190d8fee866b93f99.png
[201901242120127.png]: https://img-blog.csdnimg.cn/201901242120127.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 8]: /images/20220325/c474f841986146ceafdf10bc480d5b8e.png
[20190125122814551.png]: /images/20220325/c548aee080c545afa79018a3819aae74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 9]: /images/20220325/b0798d42e31d42d784e0ae6e9167ee04.png
[20190125122924387.png]: /images/20220325/a108098f36964db4867c786c9878b721.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 10]: /images/20220325/7c4375aa042b469eb1dee361eaba9383.png
[20190125123003943.png]: /images/20220325/2fca430f50644dd4960d10ac78615186.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 11]: /images/20220325/57711d403b4048529d980ec906446f9f.png
[20190125125601457.png]: /images/20220325/a33e2a7f50a7455bafbf09a2621e46f2.png
[20190125130340402.png]: /images/20220325/960a89fbf90f46b39659bf86ca4003eb.png
[20190125135812345.png]: /images/20220325/535f7e8de9a940309e77f302d4d15f47.png
[20190125162726801.png]: /images/20220325/fe7ab78ba64e4b79996aa4a674fa9b8a.png
[20190125165500197.png]: /images/20220325/8706628357194bcea5982329a8d2467d.png
[SouthEast]: /images/20220325/41125340b486462395df840a21b0cf28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 12]: /images/20220325/f1056dd3bdc143f88a5521b803a87a83.png
[20190125182744482.png]: /images/20220325/d6744c8dce2d4a7daac7dfa9a079ea0b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 13]: https://img-blog.csdnimg.cn/20190125184016187.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM4NDk5ODU5_size_16_color_FFFFFF_t_70 14]: /images/20220325/0138ffff7523402dbabea264674506d8.png