前言

对于TCP与UDP， 这两个协议都是位于传输层的协议 。

对于传输层，它是TCP/IP协议五层模型中的第四层。它根据第四层网络层提供的层间接口，实现了TCP与UDP两种协议，为第五层应用层提供了应用程序间的通信，它负责数据能够从发送端传输到接收端。其功能包括：格式化信息流；提供可靠传输。为实现后者，传输层协议规定接收端必须发回确认，并且假如分组丢失，必须重新发送。

在计算机中，可能会有多个应用程序进行通信，为了标识这些不同的应用程序，我们加入了端口号来标识它们。

而在TCP/IP协议中, 用"源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信。

一个进程可以绑定多个端口号，但是一个端口号不能被多个进程绑定。

TCP

TCP是一种面向连接的、可靠的、基于字节流的传输控制协议。

根据全称，我们可以得到以下特点：

• 面向连接：在真正的通信之前，必须建立连接。通信结束后，必须断开连接。
• 可靠：确保数据无差错、不丢失、不重复，按序到达。这也是传输控制的目的。
• 字节流：流动所体现的动态性。

要了解TCP的连接，首先要了解TCP报文段的格式。TCP报文段的格式如下：

但是，需要我们关注的是**序号，确认号，以及标志位（SYN，FIN等）**这三个。其他暂时无关紧要。

• 序号：报文段首字节的字节流编号。seq
• 确认号：期望从目标主机收到的下一字节的编号。ACK
• 标志位：SYN----连接建立，FIN----连接断开。

TCP数据交换

TCP客户端与服务端的数据交换是建立在seq(发送序号)，ACK(确认应答)，标志位之上。

举个例子，看下图的数据传输：

1. 客户端发送报文段：数据内容为c。seq = 42代表其为42号报文段（客户端）。ACK = 79代表客户端已经接收到了79之前的所有报文段，并请求服务端发送79号报文段（服务端）。
2. 服务端发送报文段：数据内容为d。seq = 79代表其为79号报文段（服务端）。ACK = 43代表服务端已经接收到了43之前的所有报文段，并请求客户端发送43号报文段（客户端）。
3. 客户端发送报文段：数据内容为e。seq = 43代表其为43号报文段（客户端）。ACK = 80代表客户端已经接收到了80之前的所有报文段，并请求服务端发送80号报文段（服务端）。

我们可以看到，对客户到服务器的数据的确认会被捎带在服务器到客户的报文段中。

同时我们也可以看到一种叫做累计确认的机制。例如，客户端收到了30之前的所有数据，在未收到30前提前收到了31，那么31是不会被确认的，因为30未收到。

TCP的三次握手建立连接

如图，在TCP建立连接时，会有三次报文交换，因此称为三次握手。

首先，服务端已经打开。客户端发起连接。

1. 客户端发送请求报文。SYN置为1，代表此报文为请求连接的报文。seq为client_x，代表序号随机初始化值。
2. 服务端收到客户端发来的请求报文时，为客户端分配缓存和变量。
3. 服务端发送请求报文，携带确认信息。SYN置为1，代表此报文为请求连接的报文。ACK为client_x + 1代表服务端已经确认收到client_x + 1之前的所有数据，期望下次发送client_x + 1号的报文段。seq为serv_x，代表序号随机初始化值。
4. *客户端收到服务端发来的请求报文时，为服务端分配缓存和变量。此时双向通信已基本完成。
5. 客户端发送响应报文。ACK为serv_x + 1代表客户端已经确认收到serv_x + 1之前的所有数据，期望下次发送serv_x + 1号的报文段。seq为client_x + 1，代表此报文序号为client_x + 1。

此时便可以看到三次握手在本质上还是在进行请求与确认。

#问题 为什么是三次握手？能否改成四次或两次？

TCP的三次握手分别代表了请求，回应+请求，回应三个目的，对于第二次，完全可以拆分为两个。 因此，三次握手不一定必须是三次，也可以是四次。

TCP的四次挥手释放连接

有建立连接就会有释放连接，释放时会有四次的交流，因此被称为四次挥手。如图：

请求与应答报文不用再多说了。

#问题 为什么是四次挥手？可不可以是三次？

根据三次握手可以拆分成四次来分析的话，四次挥手应该也可以合并为三次。

但是，当第二次挥手会和第三次合并以后，就不能再进行传输数据，如果说此时服务端还有没传送玩的数据，就会存在数据缺失的问题。

因此，为了应对这种情况的发生，不能合并，第二次挥手完成后，要等数据传输完毕后，再进行第三次挥手。

TCP状态

在一个TCP连接的生命周期内，每个主机上的TCP协议都有不同的状态，这种状态叫TCP状态。如图说明了一系列典型的TCP状态以及之间的变迁过程。

UDP

UDP是无连接，不可靠的用户数据报协议。

根据全称，可以得到以下特点：

• 无连接：只知道对端的IP和端口号就可以发送，不需要实现建立连接。
• 不可靠：没有确认机制， 没有重传机制。如果因为网络故障该段无法发到对方， UDP协议层也不会给应用层返回任何错误信息。
• 面向数据报： 应用层交给UDP多长的报文， UDP原样发送既不会拆分，也不会合并。发多少，另一边就必须收多少，不能循环接收。

总结

\	TCP	UDP
连接	面向连接	无连接
可靠性	可靠的	不可靠
传输效率	稍慢	快
传输方式	流式传输	数据报传输