TCP传输协议与UDP传输协议的特点与分析

传输层协议位于OSI七层模型的第四层，是通信系统中负责端到端的数据传输的关键层次。它提供了进程间的逻辑通信，确保数据从源端准确无误地传输到目的端。传输层的主要功能包括错误检测、流量控制、拥塞控制和多路复用等。

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

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

2.1 UDP传输协议

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

2.1.1 UDP传输过程

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

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

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

2.1.2  UDP报文格式

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

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

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

2.1.3  UDP总结

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

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

2.2 TCP传输协议

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

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

2.2.1 TCP报文格式

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

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

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

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

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

A向B发送数据：

• 1）下一次B发送给A的情况：

• 确认号：B要保证全部接收到A发送的信息，那么下一次发送给A报文中的确认号应该是201+100=301，代表A发送过来的0-300的数据B都接收了；
  
• 序列号：由于A发送给B的确认号为800，代表0-799的数据A都正常接收了，因此B下一次给A发送的序号为800
  

• 2）上一次B发送给A的情况：

• 确认号：由于A报文中的序号是201，因此B上一次给A发送的确认号为201，代表B接收到了A的0~200的数据，下次A直接给B发送201位置的数据即可；
  
• 序列号：A的确认号为800，代表B上一次发送给A的序号+数据长度=800，因此B上一次发送给A的序列号 = 800 - 数据长度
  

B向A发送数据：

若确认号=n，则表明，序号n-1为止的所有数据都已正确接收，期望接收序号为n以及之后的数据；

本次的序列号 = 上次的确认号

本次的确认号 = 上次的序列号 + 数据载荷的长度

• 数据偏移：占4个比特，用来指出数据载荷部分的起始处距离报文的起始处有多远；也就是TCP首部的长度。需要注意的是数据偏移以4个字节为1个单位；
  
• 填充：由于选项的长度可变，因此用来填充的确认报文首部能被4整除（因为数据偏移字段，也就是首部长度字段，是以4字节为1个单位的）；
  

如图：

• 保留字段：占6个比特，保留为今后使用，但目前为0；
  
• 窗口：占2个字节，16个比特；用于流量控制和拥塞控制，表示当前接收缓冲区的大小。在计算机网络中，通常是用接收方的接收能力的大小来控制发送方的数据发送量。TCP连接的一端根据缓冲区大小确定自己的接收窗口值，告诉对方，使对方可以确定发送数据的字节数。
  
• 校验和：占2个字节，16比特；检查报文的首部和数据载荷两部分，底层依赖于具体的校验算法；
  
• 紧急指针：占2个字节，16比特；用来指明紧急数据的长度；当发送端有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据
  
• 选项：附加一些额外的首部信息；
  
• 标志位：

• ACK(确认)：取值为1时确认号字段才有效；取值为0时确认号字段无效，一般情况下都为1；
  
• SYN(同步)：在连接建立时用来同步序号
  
• FIN(终止)：为1时表明发送端数据发送完毕要求释放连接
  
• RST(复位)：用于复位TCP连接，值为1时说明连接出现了异常，必须释放连接，然后再重新建立连接，有时RST置1还用来拒绝一个非法的报文段或拒绝打开一个TCP连接；
  
• PSH(推送)：为1时接收方应尽快将这个报文交给应用层，而不必等到接受缓存都填满后再向上交付
  
• URG(紧急)：为1时表明紧急指针字段有效，取值为0时紧急字段无效；
  

2.2.2 三次握手

1） 三次握手的原理

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

简单的过程如下图所示：

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

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

原理图如下：

• 第一次握手：
  

首先客户端使用向服务端发送TCP连接请求（此报文不携带载荷，只有首部），本次请求中SYN标记为1，表明本次是一个连接请求。序号标记为x，作为本次TCP连接的客户端起始序号值；

Tips：在TCP协议中规定，SYN标记为1的报文不可以携带数据，但还是要消耗掉一个序号

• 第二次握手：
  

服务端接收到客户端的请求后，如果确定建立连接，则向客户端发送一个确认报文。该报文SYN标记为1，表明本次是一个连接请求。ACK标记为1，表明本次是一个确认请求。

综合本次请求的含义为：连接确认请求，即服务端收到客户端请求之后，来与客户端建立连接，表明同意与客户端建立本次TCP连接；

本次请求序号标记为y，作为本次TCP连接服务端的起始序号值。确认号为x+1，这是对上一次请求初始序号x的确认。

• 第三次握手：
  

客户端再次向服务端发送确认报文，该报文中ACK标记为1，表明本次是一个确认报文。

本次确认报文的序号为x+1，这是因为第一次TCP报文的序号为x，并且不携带数据，因此本次序号为x+1

本次确认报文的确认号为y+1，这是针对服务端请求初始序号y的确认。

2） 为什么要三次握手

在三次握手中，为什么客户端最后还需要发送一个确认报文呢？难道在服务端响应确认报文之后不能确定TCP连接已经建立成功吗？

即：为什么要三次握手而不是"两次握手"呢？

我们观察下图：

①客户端发送TCP连接请求到服务端，想要建立连接，但由于本次请求超时了

②客户端再次发送一个新的TCP连接请求到服务端

③服务端接收到客户端刚刚发送的TCP连接请求，开始做出回应

④客户端接收到服务端的回应，连接建立成功

⑤过了一段时间后，客户端像服务端发送断开连接请求（进入四次挥手过程，暂时不讨论）

⑥服务端与客户端断开连接后，突然收到之前客户端发送的超时请求，但服务端还以为是客户端刚发送的连接请求，因此对该请求进行确认

⑦由于是"两次握手"，并不需要等到客户端对本次连接做出回应，本次连接就建立成功了。这无疑是浪费了服务端的连接资源

因此"三次握手"主要是为了防止失效的连接请求报文突然又传送到了服务端而造成错误；

2.2.3 四次挥手

1） 四次握手的原理

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

原理图如下：

【第一次挥手】

客户端向服务端发送连接释放报文。

• FIN标记为1：表明本次为连接释放报文
  
• ACK标记为1：对之前收到的报文进行确认
  
• 序号标记为u：u为之前服务端接收到客户端的最后一个数据+1
  
• 确认号标记为v：v为客户端接收到服务端的最后一个数据+1
  

Tips：TCP规定，释放连接报文（FIN标记为1的报文）即使不携带数据也要消耗一个序号；

【第二次挥手】

服务端接收到来自客户端的连接释放报文，由于服务端有可能正在该向客户端发送其他数据（还有数据未发送完），因此服务端不能立即发送释放连接报文，而是先向客户端发送一个确认报文表明连接释放报文已经被成功接收；

• ACK标记为1：对之前发送的连接释放报文进行确认
  
• 序号为v：从上一次确认号的数据位置开始发送数据
  
• 确认号为u+1：是对上一次连接释放报文中序号u的确认
  

【第三次挥手】

服务端确认自身没有数据要发送客户端或者已经将数据全部发送完毕之后，开始发送连接释放报文给客户端，代表确认连接断开；

• FIN标记为1：表明本次是一个连接释放报文，服务端与客户端断开TCP连接
  
• ACK标记为1：对之前收到的报文进行确认
  
• 序号为w：是对之前序号u的补充，因为期间服务端有可能发送了很多数据到客户端
  
• 确认号为u+1：说明客户端在此期间并没有发送数据到服务端
  

【第四次挥手】

客户端接收到来自服务端的连接释放报文开始回复服务端的响应，服务端接收到响应后服务端的TCP连接释放；但客户端进入2MSL时间等待窗口，时间窗口到达后，客户端关闭TCP连接；

• ACK标记为1：表明是对服务端报文的确认
  
• 序号为u+1：从上一次确认号的位置开始发送
  
• 确认号为w+1：是对服务端发送的连接释放报文的确认
  

MSL（Maximum Segment Lifetime）：报文最大生存时间，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。RFC793建议为2分钟，对于当前的网络环境，TCP允许不同的实现使用更小的MSL值；

2） 为什么要四次握手

• 为什么服务端收到客户端的连接释放报文报文后不直接发送连接释放报文来关闭TCP连接，从而变成三次握手？
  

服务端刚收到来自客户端的连接释放报文后，有可能还再向此客户端发送数据，必须等到服务端发送完毕后再发送连接释放报文给客户端。因此这一步的"握手"并不能省略。

• 为什么客户端接收到了服务端的连接释放报文后不能直接关闭TCP连接，从而变成三次握手？
  

如果少了最后一步的客户端确认动作，那么服务端无法得知客户端是否接收到服务端的连接释放报文。并且在客户端发送完最后一次确认报文给服务对后客户端的TCP连接进入2MSL时间等待窗口，这是因为有可能客户端发送的确认报文超时了，此时服务端必定会要求客户端重传，因此客户端不能在发送确认报文完毕后就立即释放TCP连接，而是要进入一个时间等待窗口。

2.2.4 TCP总结

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

2.3 UDP和TCP小结

实际上，在网络传输时是必定会有数据的损耗（丢失），影响数据的丢失有非常多的原因的，我们要保障不是说在传输过程中要分毫无差的传输给对方，而是如果传输过程中有数据的丢失，那么必须要感知到。

在传输层中比较著名的协议存在TCP和UDP协议，其中著名的应用层协议HTTP的传输层协议就是TCP。其特点：

• TCP：TCP的功能大部分都体现在其首部报文中，TCP的首部报文内容丰富，包括确认号，序号，标志位，校验和等等.....在使用TCP协议传输数据时客户端会在报文中体现数据的序号以及确认号，服务器在响应客户的时候也会携带确认号和序列化，客户端在解析报文时根据确认号来确定自己发送的数据服务器端接收到多少，然后也会携带本次的确认号给服务器，服务端再重新完成这个过程，来保障TCP传输无误。

• 特点：

• 1）可靠连接：TCP在传递过程中，必须要先建立一个物理的socket通道，所以在连接建立时必须要判断对方是存在。
  
• 2）安全性高：TCP在传输过程中会进行确认号、序列号的对比，如果传输过程中发现数据有误，会根据一定的策略重复发送，最终达到数据的可靠新投递。
  
• 3）传输效率低：

• 1）必须要先建立可靠传递，才能够进行服务传送，如果并发量高，这一部分性能损耗很严重。
  
• 2）要保障可靠性传递，就必须在传输过程遇到差错时重新发送，这一部分损耗了性能，如果是UDP不会在乎丢失部分的数据
  
• 3）TCP报文本身的问题，由于TCP的功能丰富，TCP的首部报文中肯定要比UDP的报文内容多，占用的空间多，在传递同等量的数据中TCP往往要传递更长时间才能完成传递。
  

• 三次握手：简单的流程是客户端发送请求到服务端，服务端响应客户端，最终由客户端来决定是否要建立本次连接。

• 原理：为什么要三次握手：因为在客户端建立连接时，有一部分连接发送给客户端，服务端可能在处理其他任务，并不能及时响应，此时客户端会重新去发送请求服务器端，假设本次服务端接收到请求并建立一次新的TCP连接，但同时之前的请求也会在一定的被处理，此时如果是两次握手的话就会建立太多的不必要的连接，因此必须三次握手。
  

• 四次挥手：简单的流程是客户端向服务端发送断开连接请求，服务端接收到之后先立即响应客户端，然后客户端得到请求后会进入一个MSL等待窗口，此时实际上是在等待服务端内部的资源的关闭，因为服务端释放一个连接资源并不是可以立即释放，这涉及到操作系统的一些调用。等到服务端完全释放连接资源之后，服务端会再次响应客户端，完成连接释放。

• 原理：为什么要四次回收：因为服务端在接收到客户端的断开连接之后，处理连接资源的释放是需要一定时间的，此时服务端又不能不响应客户端（会造成连接占用超时问题），因此服务端即使没有释放连接资源也会响应给客户端，等到服务端真正将连接资源释放完毕后，再次向客户端响应连接断开请求，客户端得到请求之后，最终告知服务端连接资源释放完毕。
  

• TCP报文：

• 序列号：用于发送端标识数据发送的序号
  
• 确认号：用于接收端响应接收到已接收的数据实际位置
  
• 标志位：用于标识本次报文中一些特定的情况
  

• UPD：UDP在于提升传输效率，在传递数据前不需要有任何的准备工作，也不需要判断接收方是否存在，直接将数据封装成一个合格的UDP保卫即可发送，接收端在接到UDP报文后会读取UDP报文中的载荷数据直接使用，并不会对数据的完整性进行检查，要求发送端重发等。另外由于UDP报文的结构简单，相对于TCP报文来说，存储效率高，在传输同等量的数据时，UDP效率会明显高于TCP。

• 特点：

• 1）不可靠连接：UDP在传输数据前不需要做任何的准备工作，不需要建立任何的逻辑通道，即使接收端不存也可以成功发送，效率高。
  
• 2）安全性低：在进行网络传递时，不可避免的会产生一些网络抖动等问题，会造成接收一方实际上没有完整的接收到发送端所发送的数据，对于UDP来说，这部分丢失的数据并不会对发送端要求进行重发，而是快速的进行下一步操作，传输速度快。
  
• 3）传输效率高：TCP报文和UDP报文都含有首部和载荷，载荷才是我们本次真正要传递的数据，在TCP报文中，首部占用过多的存储空间（最多60字节），而UDP报文中首部只占用8个字节，在传输同等量的数据时，TCP协议会降低传输效率。
  

• UDP报文：

• 1）源端口：发送端的端口
  
• 2）目的端口：接收端的端口