二、传输协议

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

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小结

• UDP：

• 1）面向无连接，资源消耗小，传输速度高
  
• 2）不保证数据的完整性，可靠性低，安全性低
  
• 3）应用场景，在传输速度要求较高（实时性要求较高）的场景下使用，对数据的完整性没有要求；
  

• TCP：

• 1）面向连接，每次连接都需要三次握手，每次断开连接都需要四次挥手，资源消耗大，传输速度低
  
• 2）保证数据的完整性，可靠性高，安全性高
  
• 3）应用场景，对数据的完整性有要求（可靠投递）