彻底搞定TCP和UDP！

爱被打了一巴掌 2022-09-04 05:41 158阅读 0赞

# 一、网络协议 #

网络协议如同人与人之间相互交流是需要遵循一定的规则（如语言）一样，计算机之间能够进行相互通信是因为它们都共同遵守一定的规则，即网络协议。

OSI参考模型和TCP/IP模型在不同的层次中有许多不同的网络协议，如图所示：

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

我们今天主要讨论的是传输层的协议，即考虑应用程序之间的逻辑通信。简单来说就是数据该如何发送给其他机器；

# 二、UDP #

UDP（User Datagram Protocol）：用户数据报协议；**UDP是面向无连接的通信协议**，即在数据传输时，数据的发送端和接收端不建立逻辑连接。简单来说，当一台计算机向另外一台计算机发送数据时，发送端不会确认接收端是否存在，就会发出数据，同样接收端在收到数据时，也不会向发送端反馈是否收到数据。

## 2.1 UDP传输过程 ##

UDP是面向报文传递数据的；在UDP传输过程中，分别为发送端和接受端；

发送端使用UDP发送数据时，首先将其包裹成一个UDP报文（包含数据与首部格式）通过网络将其发送给接收端；接受端接收到UDP报文后，首先去掉其首部，将数据部分交给应用程序进行解析；

> 需要注意的是，UDP不保证数据传递的可靠性，在传递过程中可能出现丢包等情况，另外，即使接收方不存在报文依旧被发送出去（丢包）。但正是因为UDP不需要花费额外的资源来建立可靠的连接，因此**UDP传输速度快，资源消耗小**；

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 1]

## 2.2 UDP报文格式 ##

一个完整的UDP报文包含首部和载荷（数据）两部分，首部由 4 个 16 位（2 字节）长的字段，共8个字节组成，分别说明该报文的源端口、目的端口、报文长度和校验值。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 2]

UDP 报文中每个字段的含义如下：

*  **源端口**：发送端所使用应用程序的UDP端口，接受端的应用程序理由这个字段的值作为响应的目的地址；这个字段是可选的，所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号，则把这个字段设置为 0。这样，接收端的应用程序就不能发送响应了。
 *  **目的端口**：接收端计算机上 UDP 软件使用的端口。
 *  **长度**：表示 UDP 数据报长度，单位：字节；包含 UDP 报文头+UDP 数据长度。因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8。
 *  **校验值**：可以检验数据在传输过程中是否被损坏。

## 2.3 UDP总结 ##

由于使用UDP协议消耗资源小，通信效率高；因此一般用于实时性要求比较高的场合如：音频、视频的传输等；例如视频会议都使用UDP协议，如果出现了网络丢包情况也只是造成卡帧现象，对整体影响不大

但是在使用UDP协议传送数据时，由于UDP的面向无连接性，不能保证数据的完整性，因此在传输重要数据时不建议使用UDP协议。UDP的交换过程如下图所示。

# 三、TCP #

TCP（Transmission Control Protocol）：传输控制协议；**TCP协议是面向连接的通信协议**；即传输数据之前，在发送端和接收端建立逻辑连接，然后再传输数据，它提供了两台计算机之间可靠无差错的数据传输。

在TCP连接中必须要明确**客户端**（发送端）与**服务器端**（接收端），由客户端向服务端发出连接请求，每次连接的创建都需要经过“三次握手”；

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 3]

## 3.1 TCP报文格式 ##

一个完整的TCP报文同样也是由首部和数据载荷组成；TCP的全部功能都体现在它首部中各字段的作用。

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

*  **源端口**：占2个字节，16个比特；表示发送该报文的应用程序端口号，用于接收端的响应；
 *  **目的端口号**：占2个字节，16个比特；标识接受该TCP报文的应用程序端口号；
 *  **序号**：数据载荷中的数据都是有顺序的，序号用于标识发送端向接收端发送的数据字节流的位置；

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

> 序号占4个字节，32个比特位，取值范围`2^32-1`，序号增加到最后一个时，下一个序列号又回到0；

*  **确认号**：期望收到对方下一个TCP报文序号的起始位置，同时也是对之前收到的数据进行确认；

> 确认号和序号一样，占4个字节，32个比特位，取值范围`2^32-1`，确认号增加到最后一个时，下一个确认号又回到0；

A向B发送数据：

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

B向A发送数据：

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

> 若确认号=n，则表明，序号n-1为止的所有数据都已正确接收，期望接收序号为n的数据；
> 
>  *  本次的序列号：上次的确认号
>  *  本次的确认号：上次的序列号+1

*  **数据偏移**：占4个比特，用来指出数据载荷部分的起始处距离报文的起始处有多远；也就是TCP首部的长度。**需要注意的是数据偏移以4个字节为单位；**

如图：

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

*  **保留字段**：占6个比特，保留为今后使用，但目前为0；
 *  **窗口：** 占2个字节，16个比特；用于流量控制和拥塞控制，表示当前接收缓冲区的大小。在计算机网络中，通常是用接收方的接收能力的大小来控制发送方的数据发送量。TCP连接的一端根据缓冲区大小确定自己的接收窗口值，告诉对方，使对方可以确定发送数据的字节数。
 *  **校验和**：占2个字节，16比特；检查报文的首部和数据载荷两部分，底层依赖于具体的校验算法；
 *  **紧急指针**：占2个字节，16比特；用来指明紧急数据的长度；当发送端有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据
 *  **选项**：附加一些额外的首部信息；
 *  **填充**：由于选项的长度可变，因此用来填充的确认报文首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为单位的）；
 *  **标志位**：
    
     *  **ACK(确认)**：取值为1时确认号字段才有效；取值为0时确认号字段无效，一般情况下都为1；
     *  **SYN(同步)**：在连接建立时用来同步序号
     *  **FIN(终止)**：为1时表明发送端数据发送完毕要求释放连接
     *  **RST(复位)**：用于复位TCP连接，值为1时说明连接出现了异常，必须释放连接，然后再重新建立连接，有时RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接；
     *  **PSH(推送)**：为1时接收方应尽快将这个报文交给应用层，而不必等到接受缓存都填满后再向上交付
     *  **URG(紧急)**：为1时表明紧急指针字段有效，取值为0时紧急字段无效；

## 3.2 三次握手 ##

由于TCP是基于可靠通信的，在发送数据之前必须建立可靠的连接；TCP建立连接的过程分为三个步骤，我们称为"三次握手"；

简单的过程如下图所示：

*  1）第一次握手：发送端向接收端端发出连接请求，等待接受的响应。
 *  2）第二次握手，接收端向发送端响应，通知发送端收到了连接请求。
 *  3）第三次握手，客户端再次向服务器端发送确认信息，确认连接。整个交互过程如下图所示。

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

我们结合TCP报文原理来具体分析一下三次握手的详细流程：

原理图如下：

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

*  1）**第一次握手**：首先A使用TCP连接向B发送报文（此报文不携带载荷，只有首部），报文中的SYN记为1（如果发送失败，重新发送记为2），序号记为x
 *  2）**第二次握手**：B接受到A发送的报文后，给A发送一个确认报文（该报文也仅有首部），报文中SYN和ACK都取值为1，用于标志这是一个确认报文段；同时此次响应的序号记为y，确认号为上一次序号x加1的值，表示已经成功接收到x+1之前的所有内容，下一次开始接受x+1之后的数据（包含x+1的数据）；
 *  3）**第三次握手**：A再次向B发送TCP确认，序号为x+1，代表发送序号x之后的数据；确认号为y+1，代表已经接收了来自B的响应的全部数据；

## 3.3 四次挥手 ##

TCP建立连接时需要"三次握手"，断开连接时则需要"四次挥手"；

原理图如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 11]

*  1）A向B发送连接释放请求，标记FIN=1（表示需要断开连接）；序号记为u（u为之前已发送的最后一个字节数据的序号+1），确认号记为v（v为之前已接受的最后一个字节数据的序号+1）
 *  2）B收到A发送的断开连接请求后开始响应，标记序号为v，确认号为u+1（代表已经成功接收A发送的数据，接下来开始接受u+1及之后序号的数据）
 *  3）主机B如果仍有数据需要传输依旧可以传输，如果B没有数据需要发送时，需给A发送连接释放报文。标记FIN=1，序号为w（同理，此时w是B之前已发送最后一个字节数的序号+1），确认号为u+1；
 *  4）A接收到B发送的连接释放报文后，最终给B发送一个TCP确认报文，代表确定接受到B需要连接断开。序号为u+1，确认号为w+1（代表B发送的数据以及全部接受完毕）

## 3.4 TCP总结 ##

使用TCP协议传输数据时，必须要建立可靠连接（三次握手），当连接关闭时还需要四次挥手，对性能损耗较大，如果频繁的创建和关闭TCP连接性能势必会有很大影响。但是由于TCP的可靠传输，对一些数据完整性要求较高的场合比较适用，如文件上传下载等；

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/1f2bc6503d30416d88459982a2190532.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20220829/ee05b52e066f43c2bbd33897b380153c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20220829/a971035604df4b31a5cc94a625e9ff5d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20220829/fd8c78ed91894fe9ae2ee10d4c142d09.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20220829/93f55dc194a04b16bf9e06f50d3b7087.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20220829/a5a046df1d814ea081b19898392899de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20220829/8ec32ef9f5b54b0b9614e3fa4a0b08b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20220829/145df3a0d3f140039c2da65c5c2f7fec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20220829/eab4ac18be374de4827b1c3530c18b1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20220829/bd84dc81dd424fe19ba6d41d8fee777f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20220829/5482823caadd458a9918046bb03c5b1c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0JiMTUwNzAwNDc3NDg_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20220829/2fae4e9c4f3f46ab812dc610e8d6a16b.png