Unity网络层剖析（一）—

Unity网络层剖析（一）——TCP与UDP

文章目录

前言
一、TCP
二、UDP
二、如何选择TCP与UDP
总结

前言

这篇文章本应是读书系列中的一章，但由于所有Unity书籍或多或少都会涉及网络部分，而我本人对网络也有一定了解并具备相关经验，因此决定结合多个书本内容、网络上的概念以及自身的经验，分享一些心得体会。
通常来说，Unity属于前端开发，了解如何与后端进行交互即可，因为在Unity项目中，网络处理主要涉及数据的收发。然而，掌握更多的知识在实际应用中会使你更加游刃有余。

一、TCP

日常使用的网络协议为TCP和UDP。TCP全称传输控制协议（TCP，Transmission Control Protocol），是一种面向链接且十分可靠的协议。面向链接就意味着需要确认建立链接后再进行收发数据。我们耳熟能详的是三次握手和四次挥手，不过我想在说这个前先解释一下TCP的协议构成，弄懂她才是弄懂各种规则的前提条件。
协议简单的说就是由很多字节组成，客户端发给服务器端解析，服务器再发给客户端解析，下面就是一个示例（IEC104协议）：

TX：68 0e 04 00 14 00 2d 01 06 00 01 00 02 60 00 01
RX：68 0e 14 00 06 00 2d 01 07 00 01 00 02 60 00 01

我们只需要知道TCP最开始的是报头部分，结构为源端口16位-目标端口16位-序列号（SYN）32位-回应序号（ACK）32位-TCP头长度4位-保留6位-控制代码6位-窗口大小16位-偏移量16位-校验和16位-选项32位（可选）。不同协议的规范不同，比如上面列举的数据开头的68是16进制的写法，用科学计算器换算成10进制就是104，其中ACK是报头的控制位，ACK为1确认收到，0位无效需要重新传递数据；SYN是序列号，当建立连接时将其置为1。而报头后面跟着的才是真正收发的数据。
再回到TCP的连接确认——三次握手：
1、A向B发送请求，是否连接？
2、B向A反馈，ojbk，再确认下。
3、A向B说，确认连接。
TCP的断开连接确认——四次握手：
1、A向B提出分手请求，将FIN置为1发过去
2、B确认连接关闭，将ACK置为1发过去
3、B对A说那我也要和你分手，将FIN置为1发过去，拉黑（关闭连接）
4、A收到B的回复说：好好好，这么玩是吧，也将ACK置为1，拉黑（关闭连接）

二、UDP

UDP全称用户数据报协议（UDP，User Datagram Protocol）,支持无连接的传输协议。其中UDP的包头结构如下。源端口16位-目的端口16位-长度16位-校验和16位。包头总共64位，即8字节。UDP的特点如下：
1、无连接性：不需要建立连接，也就是没有TCP的握手过程，大大减少的传输延迟。发送端只受到带宽之类的影响，接受端将收到的消息放到队列进行按个处理。
2、轻量级：头部字节仅有8个，对带宽和处理开销敏感的应用很适用。
3、无拥塞控制：没有拥塞控制，对实时应用友好，如视频会议、在线游戏等需要低延迟且容忍部分数据丢失的软件。
4、面向报文：无论报文长短都不会处理，保留报文段的边界，添加报头交给网络层（IP层）。
5、不可靠传输：她不确认接收到的数据报，也不进行重传。发生数据丢失、重复、乱序都有可能，需要应用层自行处理。
6、支持广播和多播：可以一对一，也可以一对多。
我们在日常监测服务器或者网络是否通畅时会使用Ping命令，其原理就是发送UDP包，然后通过接受返回包的时间监测延迟。

二、如何选择TCP与UDP

而易见，在带宽允许的情况下，TCP往往是优先选择，因为它能够覆盖UDP的应用场景。就像开车时的自动挡和手动挡相比，手动挡虽然更具技巧性和潜力，但自动挡更为便捷和稳定。
从工作原理上看，TCP在丢包时会重新发送数据包，直到确认接收为止。这种机制确保了数据的可靠传输和顺序性。相反，UDP不关注数据包是否成功到达，允许一定程度的丢失，因此具有更低的延迟和更高的传输效率，但牺牲了可靠性。
由此可见，TCP使用与卡牌游戏、MMO游戏、回合制游戏、文字冒险游戏等。UDP则使用FPS、RTS、MOBA、赛车、体育等游戏。