一、网络协议

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

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

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

二、UDP

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

2.1 UDP传输过程

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

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

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

2.2 UDP报文格式

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

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

3.1 TCP报文格式

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

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

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

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

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

A向B发送数据：

B向A发送数据：

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

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

本次的确认号：上次的序列号+1

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

如图：

保留字段：占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）第三次握手，客户端再次向服务器端发送确认信息，确认连接。整个交互过程如下图所示。

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

原理图如下：

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建立连接时需要”三次握手”，断开连接时则需要”四次挥手”；

原理图如下：

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发送的数据以及全部接受完毕）