# UDP 和 TCP 有什么区别

# 1. UDP

# 1.1 UDP 的特点

• 沟通简单，不需要大量的数据结构，处理逻辑和包头字段
• 轻信他人。它不会建立连接，但是会监听这个地方，谁都可以传给它数据，它也可以传给任何人数据，甚至可以同时传给多个人数据。
• 愣头青，做事不懂变通。不会根据网络的情况进行拥塞控制，无论是否丢包，它该怎么发还是怎么发

因为 UDP 是"小孩子"，所以处理的是一些没那么难的项目，并且就算失败的也能接收。基于这些特点的话，UDP 可以使用在如下场景中

# 1.2 UDP 的主要应用场景

• 需要资源少，网络情况稳定的内网，或者对于丢包不敏感的应用，比如 DHCP 就是基于 UDP 协议的。
• 不需要一对一沟通，建立连接，而是可以广播的应用。因为它不面向连接，所以可以做到一对多，承担广播或者多播的协议。
• 需要处理速度快，可以容忍丢包，但是即使网络拥塞，也毫不退缩，一往无前的时候

# 1.3 基于 UDP` 的几个例子

• 直播。直播对实时性的要求比较高，宁可丢包，也不要卡顿的，所以很多直播应用都基于 UDP 实现了自己的视频传输协议
• 实时游戏。游戏的特点也是实时性比较高，在这种情况下，采用自定义的可靠的 UDP 协议，自定义重传策略，能够把产生的延迟降到最低，减少网络问题对游戏造成的影响
• 物联网。一方面，物联网领域中断资源少，很可能知识个很小的嵌入式系统，而维护 TCP 协议的代价太大了；另一方面，物联网对实时性的要求也特别高。比如 Google 旗下的 Nest 简历 Thread Group，推出了物联网通信协议 Thread，就是基于 UDP 协议的

# 2 TCP

首先是 TCP 的包头格式

TCP 的包头有哪些内容，分别有什么用

• 首先，源端口和目标端口是不可少的。
• 接下来是包的序号。主要是为了解决乱序问题。不编好号怎么知道哪个先来，哪个后到
• 确认序号。发出去的包应该有确认，这样能知道对方是否收到，如果没收到就应该重新发送，这个解决的是不丢包的问题
• 状态位。SYN 是发起一个链接，ACK 是回复，RST 是重新连接，FIN 是结束连接。因为 TCP 是面向连接的，因此需要双方维护连接的状态，这些状态位的包会引起双方的状态变更
• 窗口大小，TCP 要做流量控制，需要通信双方各声明一个窗口，标识自己当前的处理能力。

# 2.1 TCP 的三次握手

所有的问题，首先都要建立连接，所以首先是连接维护的问题

TCP 的建立连接称为三次握手，可以简单理解为下面这种情况

A：您好，我是 A B：您好 A，我是 B A：您好 B

至于为什么是三次握手我这里就不细讲了，可以看其他人的博客，总结的话就是通信双方全都有来有回

对于 A 来说它发出请求，并收到了 B 的响应，对于 B 来说它响应了 A 的请求，并且也接收到了响应。

TCP 的三次握手除了建立连接外，主要还是为了沟通 TCP 包的序号问题。

A 告诉 B，我发起的包的序号是从哪个号开始的，B 同样也告诉 A，B 发起的 包的序号是从哪个号开始的。

双方建立连接之后需要共同维护一个状态机，在建立连接的过程中，双方的状态变化时序图如下所示

这是网上经常见到的一张图，刚开始的时候，客户端和服务器都处于 CLOSED 状态，先是服务端主动监听某个端口，处于 LISTEN 状态。然后客户端主动发起连接 SYN，之后处于 SYN-SENT 状态。服务端接收了发起的连接，返回 SYN，并且 ACK ( 确认 ) 客户端的 SYN，之后处于 SYN-SENT 状态。客户端接收到服务端发送的 SYN 和 ACK 之后，发送 ACK 的 ACK，之后就处于 ESTAVLISHED 状态，因为它一发一收成功了。服务端收到 ACK 的 ACK 之后，也处于 ESTABLISHED 状态，因为它也一发一收了。

# 2.2 TCP 四次挥手

说完建立连接，再说下断开连接，也被称为四次挥手，可以简单理解如下

A：小可爱，来盘王者荣耀啊 B：啊，等下哈，我在敷面膜~ 这个时候，A 需要等待，即不再发送数据，但是 B
可能还有未发送完的数据，所以需要等待 B 也主动关闭。 B：我敷好啦，来，邀请我吧 A：好的，带你灰~

这样整个连接就关闭了，当然上面只是正常的状态，也有些非正常的状态（比如 A 说完不玩了，直接跑路，B 发起的结束得不到 A 的回答，不知道该怎么办或则 B 直接跑路 A 不知道该怎么办），TCP 协议专门设计了几个状态来处理这些非正常状态

断开的时候，当 A 说不玩了，就进入 ``FIN_WAIT_1 的状态，B 收到 A 不玩了的消息后，进入 CLOSE_WAIT 的状态。

A 收到 B 说知道了，就进入 ``FIN_WAIT_2 的状态，如果 B 直接跑路，则 A 永远处与这个状态。TCP 协议里面并没有对这个状态的处理，但 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间。

如果 B 没有跑路，A 接收到 B 的不玩了请求之后，从 ``FIN_WAIT_2 状态结束，按说 A 可以跑路了，但是如果 B 没有接收到 A 跑路的 ACK 呢，就再也接收不到了，所以这时候 A 需要等待一段时间，因为如果 B 没接收到 A 的 ACK 的话会重新发送给 A，所以 A 的等待时间需要足够长。

# 3. UDP 和 TCP 的区别

• TCP协议在传送数据段的时候要给段标号；UDP协议不需要
• TCP协议可靠；UDP协议不可靠
  • TCP 是面向字节流的，UDP 是基于数据报的
  • TCP 保证数据正确性，UDP 可能丢包
  • TCP 保证数据顺序，UDP 不保证
• TCP协议是面向连接（如打电话要先拨号建立连接）；UDP协议采用无连接
  • 通过 TCP 连接传输的数据无差错，不丢失，不重复，且按顺序到达。
  • TCP 报文头里面的序号能使 TCP 的数据按序到达
  • 报文头里面的确认序号能保证不丢包，累计确认及超时重传机制
  • TCP 拥有流量控制及拥塞控制的机制
• TCP协议负载较高，采用虚电路；UDP采用无连接
• TCP协议的发送方要确认接收方是否收到数据段（3 次握手协议）,而 UDP 不会
• TCP协议采用窗口技术和流控制

什么是面向连接，什么是面向无连接

在互通之前，面向连接的协议会先建立连接，如 TCP 有三次握手，而 UDP 不会

TCP 为什么是可靠连接

• 通过 TCP 连接传输的数据无差错，不丢失，不重复，且按顺序到达。
• TCP 报文头里面的序号能使 TCP 的数据按序到达
• 报文头里面的确认序号能保证不丢包，累计确认及超时重传机制
• TCP 拥有流量控制及拥塞控制的机制

TCP 的顺序问题，丢包问题，流量控制都是通过滑动窗口来解决的，拥塞控制时通过拥塞窗口来解决的

# 总结

# 最后

文中若有不准确或错误的地方，欢迎指出，有兴趣可以的关注下Github，一起学习呀~~