小白的福音—秒懂UDP协议&TCP协议

---

ForeWord

---

本文介绍了UDP\TCP协议的基础知识，主要内容有：

1. UDP\TCP协议在TCP/IP协议栈中的位置和作用
2. UDP\TCP协议数据段格式
3. TCP协议如何保证数据传输的可靠性

tips：全文阅读需5min

小伙伴们燥起来(づ｡◕ᴗᴗ◕｡)づ

---

TCP/IP协议栈

---

TCP/IP⽹网络协议栈分为应⽤用层(Application)、传输层(Transport)、⽹网络层(Network)和链路层 (Link)四层：

其中，传输层及其以下的机制由内核提供，应用层由用户进程提供。

   应用程序对通讯数据的含义进行解释，而传输层及其以下处理通讯的细节。从而将数据从一台计算机通过⼀定的路径发送到另一台计算机。

这就是两台计算机通过TCP/IP协议栈进行通讯的过程，当然还有很多细节。

此过程中，TCP&UDP协议在传输层发挥作用。上层协议根据TCP数据段首部或UDP首部的“端口号”字段确定应该将应用层数据交给哪个用户进程，完成数据传输。

TCP协议

一种面向连接的、可靠的协议。

有点像打电话。双方拿起电话互通身份之后就建立了连接，然后说话就行了。这边说的话那边保证听得到，并且是按说话的顺序听到的，说完话挂机断开连接。

   也就是说TCP传输的双方需要⾸先建立连接，之后由TCP协议保证数据收发的可靠性。丢失的数据包自动重发，上层应用程序收到的总是可靠的数据流。通讯之后关闭连接。

UDP协议

UDP协议不面向连接，也不保证可靠性。

有点像寄信，写好信放到邮筒里。既不能保证信件在邮递过程中不会丢失，也不能保证信件是按顺序寄到目的地的。

   所以，使用UDP协议的应用程序需要自己完成丢包重发、消息排序等工作。

---

数据段格式

---

不同的协议层对数据包有不同的称谓，在传输层叫做段(segment)，在网络层叫做数据报(datagram)。在链路层叫做帧(frame)。

接下来详细介绍UDP和TCP协议的数据段格式。

1. UDP协议

盗图不可耻。。。

举个例子，分析⼀帧基于UDP的TFTP协议帧：

1. 源端口号0x05d4(1492)是客户端的端口号，目的端口号0x0045(69)是TFTP服务的well-known端口号。
2. UDP报长度为0x003f，即63字节。包括UDP首部和UDP层payload的长度。
3. UDP首部和UDP层payload的校验和为0xac40。

一般的网络通信都是像TFTP协议这样，通信的双方分别是客户端和服务器。客户端主动发起请求 (上面的例子就是客户端发起的请求帧)。而服务器被动地等待、接收和应答请求。

客户端的IP地址和端口号唯一标识了该主机上的TFTP客户端进程，服务器的IP地址和端口号唯一标识了该主机上的TFTP服务进程。

关于这一点，博主也用了博客来总结，详情戳这里

前面提过，UDP协议不⾯向连接，也不保证传输的可靠性。这一点主要体现在：

1. 无法判别数据的失败传输

   发送端的UDP协议层只管把应用层传来的数据封装成段交给IP协议层就算完成任务了，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息。  

2. 无法保证数据接收顺序

   接收端的UDP协议层只管把收到的数据根据端口号交给相应的应用程序就算完成任务了，如果发送端发来多个数据包并且在网络上经过不同的路由，到达接收端时顺序已经错乱了，UDP协议层也不保证按发送时的顺序交给应用层。 

3. 丢包问题

   通常接收端的UDP协议层将收到的数据放在一个固定大小的缓冲区中等待应用程序来提取和处理，如果应用程序提取和处理的速度很慢，而发送端发送的速度很快。就会丢失数据包,UDP协议层并不报告这种错误。

因此，使用UDP协议的应用程序必须考虑到这些可能的问题并实现适当的解决方案。

例如等待应答、超时重发、为数据包编号、流量控制等。一般使用UDP协议的应用程序实现都比较简单，只是发送一些对可靠性要求不高的消息，而不发送大量的数据。

例如，基于UDP的TFTP 协议一般只用于传送小文件，而基于tcp的协议适⽤于各种文件的传输。

2. TCP协议

下⾯面 看TCP协议如何⽤用⾯面向连接的服务来代替应⽤用程序解决传输的可靠性问 题。

不要问我为什么图是斜的，我也不知道(￣.￣)。。。

和UDP协议一样，TCP的数据段中也有源端口号和目的端口号，通讯的双方由IP地址和端口号标识。

1. 32位序号、32位确认序号、窗口大小均是保证数据传输可靠性的机制。
2. 4位首部长度表示TCP协议头的长度，以4字节为单位。因此TCP协议头最长可以是4x15=60字节，如果没有选项字段,TCP协议头最短20字节。
3. URG、ACK、PSH、RST、SYN、FIN是六个控制位，用于保证传输可靠性。
4. 16位检验和将TCP协议头和数据都也用于保证传输可靠性。

---

TCP协议的可靠性

---

上边说过，TCP保证数据传输的可靠性，那它是怎么保证的呢？故事很长，你准备好听我说了么<(▰˘◡˘▰)>

1. TCP是面向连接的，并且是全双工的

   事实上，TCP协议为应用层提供了全双工(full-duplex)的服务，双方都可以主动甚至同时给对方发送数据。

如果通讯过程只能采用一问一答的方式，收和发两个方向不能同时传输，在同一时间只允许一个方向的数据传输,则称为”半双工(half-duplex)”

2. TCP基于请求应答机制

   在数据传输时，请求方请求数据时附上自己报文序号，应答方在应答时附上确认序号，防止数据丢失。所以最新一条数据无法保证可靠性，只有确认过的消息才能保证

3. 丢包重查

   基于请求应答机制，数据丢失可以及时发现，从而进行丢包重查。

4. 保证数据按序到达

   同样基于请求应答机制，数据可以按时到达。

5. 6个控制位

   上边TCP协议的数据段中，给出了6个控制位，它们也保证了数据传输的可靠性。具体待博主后续介绍。

6. 定时器

   TCP协议维护了各种定时器，用来保证双方通信的可靠性。

比如防止过多闲置链接的“保活定时器”，还有防止接收方缓冲区虽满，但迟迟不读取数据，导致占用链接资源的“超时重查定时器”（超时后将此链接重置（关闭））。

还有很多定时器，博主将在后续博文中总结，敬请期待。

7. 流量控制

     数据传输中，发送与接收速度不一致时，可以扔掉多余数据。因为有丢包重查。但多次丢包重查操作也会浪费资源。所以为了协调速度，应该以缓冲区大小为标志。每次数据传输时接收方将自己的缓冲区大小告知发送方，防止其在接收缓冲区已满的情况下再发送数据。

这就是流量控制。

TCP数据段中的——16位窗口大小就是这里的接收缓冲区大小，它也叫做滑动窗口。滑动窗口的大小永远是自己能接收数据的缓冲区大小。这样就保证了数据进可能少的丢包。

数据通讯中滑动窗口如何发挥作用，博主也会在后续博文中详细介绍。小伙伴们不要心急哟~

8. 网络拥堵避免算法

     除了滑动窗口，TCP还实现了网络拥堵避免算法，进一步避免了大量数据丢包。

至于算法是怎么样的，博主就不在这里介绍了，感兴趣的小伙伴可以自行百度ヾ(◍°∇°◍)ﾉﾞ

9. TCP是面向连接的

    TCP的面向连接主要体现在3次握手、4次挥手上。这可是个很重要的问题，当然要另写博文详细介绍啦。我们再约~

---

注意：虽说TCP协议与UDP协议相比，保证了数据传输的可靠性，但两者没有谁好谁坏的问题，只是适用场景不同。

---

The End

---

本文只是介绍了TCP/UDP协议最基础的概念知识，在实际问题中，比较关心的还是TCP协议的通信细节。

博主在文中也留下了很多的伏笔，比如TCP协议中3次握手4次挥手、滑动窗口机制等，这些方面博主将在后续博文中介绍。敬请期待。

点个赞再走吧，小主~٩(๑>◡<๑)۶