Unity客户端面试网络篇：TCP/UDP、HTTP、Socket及同步机制全解析

Unity客户端面试里，网络这一块的比例不算特别高，但几乎每轮都会碰见。尤其是初级岗位，不会一上来就问分布式架构、拥塞控制那些深水区，反而喜欢从最基础的TCP/UDP、HTTP/HTTPS、Socket、客户端收发消息流程这些点入手，一层层往下问。这篇面经就是给准备Unity客户端岗位的初级开发者准备的，把网络方向常考的东西、答题思路，以及我自己参与面试时见过的典型翻车现场，一起梳理一遍。

先说清楚一个事情：初级岗位的网络面试，考的不是你要能独立写出一套网络库，而是考察你有没有“网络意识”。什么叫网络意识？就是你写一个登录功能，不只是调一个接口，而是清楚这条消息从客户端出发，经过了哪些层，到服务端后怎么被处理，返回时又走了什么链路；出了问题，你大概知道往哪个方向排查。这个意识，比背多少协议细节都重要。

1. 网络面试到底在考什么：先搞懂出题人的意图

1.1 初级岗位的网络能力模型

很多人在准备阶段容易走偏，一上来就死磕TCP的拥塞控制算法、TCP BBR、QUIC协议这些进阶内容，结果面试官问了个“Unity里怎么发一个HTTP请求”，反而答得支支吾吾。初级岗位的网络能力模型，其实可以拆成三层：

第一层是协议基础，包括TCP/UDP的区别、三次握手四次挥手、HTTP/HTTPS的基本语义、Socket概念。这是面试的“入场券”，不需要你背到RFC级别，但核心机制必须说清楚。

第二层是Unity引擎内的网络API使用经验，比如UnityWebRequest、AsyncOperation、协程和回调、JsonUtility等。对应届生或者经验浅的候选人，面试官最想确认的是你真的在项目里用过这些API，而不是只看了教程。

第三层是游戏特有的网络概念，比如状态同步、帧同步、断线重连、消息协议设计。这一层初级岗位不会问得太深，但至少你要能说出“帧同步和状态同步有什么区别”这种级别的内容。

所以建议按这个顺序去准备：先把协议基础打牢，再整理自己做过的Unity网络功能，最后了解一下游戏同步的基本概念。别反过来。

1.2 面试官的考察路径与常见套路

我自己参与面试时，问网络相关问题通常有一个固定路径：先问一个宽泛的，比如“客户端和服务端通信，底层有哪些方式”，然后根据你的回答沿着某个点往下追。你要是主动提到TCP，我就会顺势问“TCP为什么可靠”；你要是提到“用了HTTP”，我就会问“HTTP和TCP是什么关系”。整个过程很像剥洋葱，一层一层往里钻。

这种方式让你很难靠背题过关。因为同一个问题，只要你换个项目背景、换个数据量，答案就可能不一样。比如“如果玩家点击攻击，客户端怎么把这个消息发给其他玩家”，你光说“发个UDP不就行了”是不够的，面试官会追问：丢包怎么办？要不要服务器校验？其他玩家是收到原始输入还是收到结算结果？

所以这块的准备重点，不是去背一份标准答案列表，而是把网络的知识织成一张网：知道协议之间的关系，知道每一个机制解决的是什么问题，知道在Unity里写代码时有哪些坑。下面我会按这个思路，把常考的内容一块一块拆开讲。

2. 必须吃透的基础协议：TCP/UDP/HTTP/HTTPS

2.1 TCP三次握手与四次挥手：不只是背状态

三次握手几乎是必考题，这个没什么争议。但很多人的回答停留在“客户端发SYN，服务器回SYN+ACK，客户端再回ACK”这个层面，能把这个说清楚其实已经可以及格了。问题是面试官通常会加一句：“为什么需要三次，两次不行吗？”

这个问题才是真正的分水岭。两次握手最大的问题在于，客户端第一次发的SYN报文如果因为网络延迟被卡了很久，客户端超时重传，服务器收到重传的SYN后回了SYN+ACK，这时候旧的SYN又到了服务器，服务器会再回一个SYN+ACK，认为连接建立了。如果只是两次握手，服务器就会为这条“死连接”资源白白等着。而三次握手因为客户端收到SYN+ACK后还需要再回一次ACK，服务器只有在收到这个ACK后才算建立连接，旧的那个SYN+ACK没有对应ACK，服务器就知道这个连接不用建立了。

用生活化的例子讲，两次握手就像你给对方发了一条微信“今晚吃饭吗”，对方回了“好”，你以为约上了，但可能你的消息其实发了两遍，第一遍是延迟了很久才到的旧消息，对方回的是那个旧消息，你以为他答应的是你现在这顿，实际上他已经吃完了。三次握手等于对方回“好”之后，你还得再确认一下“好的，那就今晚”，对方看到这个确认才真正去订位。

四次挥手也比很多人以为的要复杂。主动关闭方发FIN，被动方回ACK，然后被动方进入CLOSE_WAIT状态，这时候被动方还可以继续发数据，发完后再发FIN，主动方回ACK，最后主动方进入TIME_WAIT状态等待2MSL。面试里容易漏掉的点是：被动方的ACK和FIN是分开的，不能合并成一次。原因是TCP是全双工的，两个方向的数据通道要分别关闭。就好比两个人打电话，一个人说“我说完了，你还有要说的吗”，对方说“知道了”，但对方可能还有话要说，等他说完了，才会说“我也说完了”。如果不区分这两个方向，就可能把对方还没说完的话给掐断。

TIME_WAIT这个状态也值得主动提一句，它能保证最后一个ACK如果丢了，被动方重发FIN时主动方还能响应，同时让旧连接的延迟报文在网络中消失，不至于干扰新连接。在Unity客户端里，TIME_WAIT一般不是问题，但如果你用同一端口频繁重连，偶尔会遇到端口被占用的报错，这背后就是TIME_WAIT在起作用。

2.2 TCP的可靠性机制：不是一句话就能带过的

面试官问“TCP为什么比UDP可靠”，你要是只答“TCP有重传机制”，分数不会高。一个更好的回答结构是把可靠性拆成几个机制来讲：

一是确认应答与序号。TCP把数据切成一个个报文段，每个字节都有序号，接收方收到后会回ACK确认。发送方如果在规定时间内没收到ACK，就会认为报文丢了或者出错，触发重传。这是可靠性的地基。

二是超时重传与快速重传。超时重传是等到超时时间到了还没收到ACK就重发；快速重传是接收方收到乱序数据时，会立刻重复发送对缺失数据的ACK，发送方连续收到三个相同ACK后不等超时立刻重传。

三是流量控制。接收方在自己的窗口字段里告诉发送方“我还能接收多少数据”，发送方据此调整发送速率，避免把接收方缓冲区撑爆。这个在面试里可以说得稍微细一点：滑动窗口是接收方和发送方各自维护的一个区间，窗口大小会动态变化。

四是拥塞控制。虽然初级岗位不太会深挖，但提一句“TCP会根据网络拥塞状态调整发送速率，有慢启动、拥塞避免、快重传、快恢复几个阶段”就足够了。注意别把流量控制和拥塞控制搞混：流量控制是端到端的，解决“接收方来不及处理”的问题；拥塞控制是全局的，解决“网络中间设备处理不过来”的问题。

要特别提醒的是，TCP的可靠性是“传输层”的可靠，不等于“应用层”的可靠。面试官经常在后面加一个问题：“所以客户端发了条登录消息，就一定能登录成功吗？”答案是不能。因为TCP只能保证消息正确到达对端的内核缓冲区，不保证对端应用层一定处理成功。如果服务端进程崩了、数据库写失败了、或者服务器返回了“密码错误”，TCP层面看起来依然“可靠”。这就要在应用层再做一层ack和超时重试。

2.3 UDP与TCP怎么选：游戏里的真实场景

TCP和UDP的选择问题是初级岗位的高频题，也是能看出候选人有没有项目经验的地方。

TCP适合对完整性要求高、实时性要求低的场景。登录注册、商城购买、背包数据、排行榜、活动配置这些都不会用UDP，因为丢了任何一条数据都是事故。比如你买了一件装备，这条消息丢了，玩家会直接炸毛。

UDP适合对实时性要求高、允许少量丢失的场景。比如玩家位置同步、技能释放、子弹轨迹、操作指令这类高频信息。这里要纠正一个很多人常犯的错误：UDP并不代表“一定会丢包”，而是“丢了也不负责”。在同一个局域网里，UDP丢包率其实很低，但在公网跨地域环境下，丢包和乱序就明显了。

如果你面试时能主动说出下面这句话，会很加分：“网络协议的选择不是非黑即白的，实际项目里经常是TCP和UDP混用，甚至会在UDP之上自己实现一套可靠机制，比如给消息编号、加ack、做重传和排序，这就是常说的可靠UDP。”

不同品类游戏的选型也不一样。MMORPG里的移动同步，早期很多用TCP，但因为TCP的队头阻塞问题，在弱网环境下体验会很差，所以后来很多游戏改用UDP或者KCP这类基于UDP的可靠协议。FPS和MOBA对延迟极其敏感，基本都会走UDP。卡牌、SLG、休闲游戏，如果实时性要求不高，直接用TCP甚至HTTP就够了。回答的时候结合具体游戏类型去说，会显得你是有思考的。

2.4 HTTP/HTTPS与Unity侧的常见使用

HTTP在Unity客户端开发里主要用来做非实时通信：登录、注册、拉取公告、上传战绩、获取活动配置等。Unity里最常用的类是UnityWebRequest，它比老的WWW类功能更全，可以处理Get、Post、Put、Delete等请求，还支持下载文件、上传表单、设置请求头。

面试官如果问HTTP和TCP的关系，你要能说清楚：HTTP是应用层协议，它依赖TCP作为传输层。也就是建立连接、可靠传输这些事是TCP干的，HTTP只是规定了“请求和响应的格式”。打个比方，TCP是高速公路和货车，HTTP是货车上贴的快递单，规定了从哪寄、寄给谁、里面装了什么类型的东西。

状态码这一块也建议记熟几个常见的：200表示成功，201表示创建成功，400表示客户端请求参数错误，401表示未认证，403表示无权限，404表示资源不存在，500表示服务器内部错误，502表示网关错误。UnityWebRequest里经常会出现一个现象：请求明明返回了500，但Unity那边没有抛异常，只是isDone变成true，需要通过responseCode去判断。这个细节很多人踩过坑，可以拿去面试里当自己的经验讲。

HTTPS多了一层SSL/TLS加密，面试里问到概率不小。核心机制是：客户端先拿到服务器的证书，用CA公钥验证证书合法性，然后通过非对称加密协商出一个对称加密密钥，后续通信全部用这个对称密钥加密。这个过程叫TLS握手。在Unity里，如果你用UnityWebRequest发HTTPS请求，证书校验失败时会直接报错，Android平台上还经常遇到证书信任问题，解决办法一般是让服务器配上完整证书链，或者把用到的公钥证书打进客户端。

3. Unity客户端网络编程的实操要点

3.1 从Socket到上层业务：网络层怎么做分层

面试时如果聊到“你在项目里怎么用Socket”，一个能让面试官点头的回答是：我平时不会在业务代码里直接写Socket，而是把网络层拆成几层来做。这个回答能体现你的工程意识。

常见分层大概是这样的：

• 连接层：负责Socket的创建、连接、断开、重连，以及心跳包的发送。
• 协议编解码层：负责把业务数据结构序列化成字节流，或者把收到的字节流解析成业务消息。
• 消息派发层：根据消息ID，把不同的消息分发给对应的业务处理模块。
• 业务逻辑层：UI、角色控制、玩法逻辑等，只关心“收到了一个消息”，不关心消息是怎么从网络到达的。

这样分层的好处是，业务层不用关心网络细节，网络层也不用关心业务逻辑。假如你要从TcpClient换成一个自定义网络库，只要协议编解码和派发的接口不变，业务层代码一行都不用改。

用C#写一个最简的TCP客户端，其实代码量不大：

TcpClient client = new TcpClient(); await client.ConnectAsync(ip, port); NetworkStream stream = client.GetStream(); byte[] data = Encoding.UTF8.GetBytes("hello"); await stream.WriteAsync(data, 0, data.Length); byte[] buffer = new byte[1024]; int n = await stream.ReadAsync(buffer, 0, buffer.Length); Debug.Log(Encoding.UTF8.GetString(buffer, 0, n));

这段代码虽然能跑，但如果项目里直接这么写，会被打得很惨。因为接收数据不一定是“发一次收一次”的整齐对应，可能你读到的数据里包含了半条消息、两条消息、甚至半条消息加一条完整消息。这就引出了网络编程里最经典的话题：粘包和拆包。

3.2 粘包拆包问题与消息协议设计

粘包拆包问题，初级面试里出现的频率其实很高。为了防止背题，建议先理解它的成因。

TCP是流式协议，它底层不关心你发了几次数据，只按照接收方的缓冲区大小把字节流切割后往上送。所以可能出现：你两次调用Write分别发送了“你好”和“世界”，服务端一次Read读到的却是“你好世界”，这叫粘包。也可能你一次调用Write发送了一长串数据，服务端分两次Read才读完，这叫拆包，或者说半包。

解决思路通常是“在消息前面加长度头”：每个消息规定一个格式，前4个字节用int表示正文长度，后面是正文。接收方先读4个字节，知道正文有多长，再接着读对应长度的字节，就能精确切出一条完整消息。不够了就继续存着，等下一次再读。

// 发送消息：先把长度写入头部，再拼接正文 byte[] body = Encoding.UTF8.GetBytes(jsonString); byte[] sendBuffer = new byte[body.Length + 4]; byte[] lenBytes = BitConverter.GetBytes(body.Length); Buffer.BlockCopy(lenBytes, 0, sendBuffer, 0, 4); Buffer.BlockCopy(body, 0, sendBuffer, 4, body.Length); stream.Write(sendBuffer, 0, sendBuffer.Length);

接收端用一个临时缓冲区把每次Read到的数据追加进去，然后循环检查：如果缓冲区长度大于4，就读出头部长度，如果缓冲区长度还够一个完整消息，就按长度切出来，交给消息派发层。

这里有个很容易忽略的细节：字节序。C#的BitConverter在Windows上默认是小端序，而很多服务端协议或者通信中间件默认使用大端序（网络字节序）。如果两边没对齐，解析出来的长度会变成一个超大数字或者负数，直接导致断线。所以在设计协议时，一定要约定好字节序。Unity里想省事可以这样写：

int length = System.Net.IPAddress.NetworkToHostOrder(BitConverter.ToInt32(buffer, 0));

再进一步，序列化方案怎么选？最简单的可以用JSON，可读性好，但字节数多、性能差；性能敏感的业务一般用protobuf之类的二进制序列化方案。在面试里这点可以主动提一句：“我在项目里用的是protobuf，配合消息ID做分发，派发层用一个字典注册消息处理函数。”这样就把协议编解码、序列化、消息分发全部串起来了。

3.3 主线程与网络线程：Unity的线程模型

这一块是Unity面试里很有特色的考点，因为其他不少客户端端技术面试不太会这么强调线程。Unity的API基本只能在主线程调用，而网络收包天然是异步的，要么在子线程里阻塞读，要么在回调里收。如果你直接在子线程里收到消息后去操作GameObject，轻则报错“get_gameObject can only be called from the main thread”，重则偶发性崩溃，特别难排查。

一个标准做法是：收包线程只负责把收到的消息解析成消息对象，然后塞进一个线程安全的队列，主线程在Update里每帧从队列里取消息，再分发给业务逻辑处理。

ConcurrentQueue<BaseMessage> messageQueue = new ConcurrentQueue<BaseMessage>(); // 子线程接收 void OnMessageReceived(BaseMessage msg) { messageQueue.Enqueue(msg); } // 主线程每帧处理 void Update() { while (messageQueue.TryDequeue(out BaseMessage msg)) { Dispatch(msg); } }

C#的ConcurrentQueue内部有锁，但在这种低频率出队操作下性能足够。如果你对性能有更高要求，也可以自己实现环形缓冲或者双缓冲队列，但初级岗位能说出“用ConcurrentQueue暂存，主线程消费”这个方案已经足够了。

关于“网络操作放子线程还是主线程”的问题也常被问到。记住一个结论：阻塞式网络操作（尤其是同步Read）不要放主线程，否则一旦网络卡住或服务端不返回，整个游戏直接卡死；异步API（如UnityWebRequest、async/await封装）在主线程用没问题，因为底层不会阻塞调用线程。

3.4 Unity常用网络方案选型

面试里经常会被问“Unity项目里做网络通信一般有哪些方案”，这时候你可以列一个对比表，展示自己对生态的熟悉程度：

这里有个经验之谈：如果你只是做面试准备，不一定真的要精通所有方案，但是要能说清楚它们之间的大致定位。比如“WebGL平台没有原生TCP Socket，只能用WebSocket或者HTTP轮询”，这句话本身就能体现你对平台差异的认知。再比如“小游戏平台和普通App的网络环境不一样，需要专门考虑并发限制和域名白名单”，这些都是实际项目里会踩的坑。

大厂为什么倾向于自研网络层？从工程角度讲，Control是原因之一：自研协议可以针对自家游戏的同步模式做定制优化，可以做弱网模拟、流量统计、灰度降级；第三方方案一旦出问题，你只能等社区修或者自己魔改，成本反而更高。初级候选人如果能点到这一层，说明你不是只停留在用API的层面。

4. 状态同步与帧同步：游戏网络的两条路线

4.1 状态同步：客户端上报操作，服务器广播状态

状态同步是目前网络游戏最主流的同步方式，尤其是大型多人游戏。它的核心思路是：服务器是权威的，客户端不直接决定游戏世界里的最终状态。客户端做的事情是把操作指令发给服务器，服务器运行完整的游戏逻辑，计算出最新的游戏状态，然后把状态广播给所有相关客户端。

举个例子，玩家A按了一下前进键，客户端不会立刻把自己的坐标改成“往前走了1米”，而是把“按下前进键”这条指令发给服务器。服务器用自己的逻辑算出A的新位置，然后告诉所有客户端：A现在在(10, 20, 30)这个点。其他客户端收到后在本地把这个玩家移动到目标点。

这里有个客户端要做的重要事情：插值和预测。如果没有插值，服务器以10Hz的频率下发位置快照，其他玩家看到的动作就会一卡一卡的；插值就是让本地显示的位置平滑地向目标位置靠近。预测则是客户端在收到服务器状态之前，先用自己的逻辑模拟一下操作结果，让本机玩家操作时不觉得有延迟，等服务器权威状态到达后再做校正。

在面试里，你不需要把预测和校正的算法细节背下来，但能说出“服务器权威，客户端做插值和预测”这个思路就够了，这已经超过了多数初级候选人的水平。

4.2 帧同步：所有客户端跑同一个剧本

帧同步的思路和状态同步差别很大。它不要求服务器每个时刻都广播全量状态，而是把游戏逻辑统一切成帧，服务器只管收集所有客户端的操作指令，然后把这些指令按顺序广播给所有人。每个客户端收到指令后，在自己的机器上跑一遍完全相同的游戏逻辑，得到完全相同的游戏画面推进。

帧同步的成立前提是“确定性”。什么意思？就是同样的输入，在不同机器上，用同样的代码和浮点运算，必须得到完全一样的结果。这里面有个坑：不同CPU、不同架构的浮点运算精度可能有细微差别，所以帧同步项目一般会用定点数代替浮点数，或者规定某些运算必须保证跨平台一致。

帧同步常见的应用类型是格斗游戏、RTS、以及一些强对抗性的派对游戏。这类游戏玩家数量不多，但每个玩家对操作反馈的要求极高，手势级别的延迟差异都会被感知。帧同步因为客户端不用等服务器逻辑算完，所以延迟更低；但代价是客户端一旦数据被篡改，画面就完全不可信，所以通常还需要服务器对关键操作做校验。

4.3 对比表与初级岗位怎么答

初级岗位如果被问到“你们游戏项目用了什么同步方案”，回答的时候不要急着抛名词，先说是哪类玩法、玩家数量多少人、延迟要求多高。比如你可以说：“我之前参与的是一个4人合作的轻竞技游戏，因为玩家少、操作反馈要求高，我们选了帧同步方案，客户端跑确定性逻辑，服务器只做指令转发和可靠排序。”然后如果面试官感兴趣，再展开讲里面遇到的问题。

这里特别提醒：不要把自己没做过的项目说得天花乱坠。面试官一句话就能识破：“你这个同步的浮点数精度问题，你们当时怎么解决？”答不上来反而更尴尬。不如承认：“这部分是我初步了解的，我项目里更多是HTTP请求和消息收发，但我在学习帧同步的过程中，理解了确定性和输入指令广播的概念。”这种诚实的态度其实加分。

5. 高频面试题与答题思路实录

5.1 高频问题与参考答案要点

把常见的网络面试题整理成一张表，每题都按“回答主线+加分点”的格式给参考思路。

5.2 追问与深挖：如何展示自己的思考深度

能背下上面的回答主线只能保证“不丢分”，想要“加分”，需要在回答中带出你自己的思考痕迹。这里我举一个典型的追问场景。

面试官问：“TCP为什么可靠？”你答了确认应答和重传。他继续问：“那UDP能做到可靠吗？”如果你直接说“不能”，就掉进坑里了。正确的思路是：UDP本身不做传输层的可靠性保证，但应用层可以实现一套可靠性机制，给它加上序号、ack、超时重传、拥塞控制，这就是可靠UDP，KCP就是典型代表。这个回答展示的是你已经理解了可靠性的本质：不是UDP“不能”，而是TCP把这套机制放在了系统内核里，UDP则需要你自己建。

再比如你提到项目里用了protobuf，面试官可能会问：“为什么不用JSON？”这时候你可以说：项目中有的消息比较高频，每秒钟几十条，JSON的字符串解析开销和字节体积会占掉不少带宽和CPU，protobuf是二进制编码，字段按编号紧凑排列，体积小、解析快。但如果只是登录请求这种低频消息，JSON完全够用，甚至更便于调试。这样回答，面试官看到的是你在“工程权衡”而不是“背书”。

面试里还有一个高频追问套路：“如果玩家在游戏里卡了一下，然后突然恢复，你会怎么设计？”初级岗位常见的错误答法是“重连就行”。稍微好一点的答法是：先做消息缓存，网络恢复后把断线期间的操作补发过去；服务端再判断这些操作是否还有效；无效就要求客户端同步最新状态。再深一层，还要考虑玩家在断线期间其实已经死掉了，那么其他客户端看到这个玩家时会怎么处理。不用把方案讲得多完美，重点是让面试官看到你在思考边界情况，而网络编程大部分坑都出在边界情况里。

6. 面试中容易翻车的细节与避坑经验

6.1 常见翻车点

以下几个问题是我在实际面试场景里经常听到的“致命回答”，单独拎出来说说。

第一，把“HTTP”和“TCP”对立。有人会答“我们用的不是TCP，是HTTP”，这是概念混乱。HTTP是跑在TCP之上的应用层协议，你用了HTTP，本质上也用了TCP。正确说法是：“我们项目的实时通信用了TCP自定义协议，非实时请求用了HTTP。”

第二，聊到可靠UDP就慌。只要你说出“用UDP做实时同步”，面试官极大概率会追问“那丢包怎么办”。如果完全没准备，会当场卡壳。建议提前准备一个简短回答：客户端给每个UDP包编上序号，接收方发现序号跳变就要求重传，收到重复包就丢弃，同时按序号缓冲乱序包，到期后按顺序抛给上层。能把这四句话说清楚，就已经很能打了。

第三，对“心跳包”的理解停留在“保活连接”这四个字。可以再往深一层说：心跳包有两个作用，一是让网络中间设备不要因为空闲断开连接，二是让服务器能快速发现客户端已经离线，从而触发清理逻辑。心跳的间隔要权衡，太频繁浪费带宽，太慢则死连接清理不及时。很多项目会做三级心跳，比如客户端每隔一段时间发一次心跳，连续N次没收到服务端回复就尝试重连，重连失败才真正判定断线。

第四，说“子线程里直接操作Unity对象”，这在上述3.3里已经强调过。如果遇到这种情况，可以坦白：“我知道不能跨线程操作，所以我的网络回调里只把数据放到队列，主线程Update里再处理。”这个回答一出来，面试官基本不会再在这个点上纠缠。

第五，对数字不敏感。面试官问“你们同步频率是多少”“心跳多久一次”，如果支支吾吾或者给出一个离谱的数字，会显得项目经验不实。哪怕不是自己在真实项目里配置的，也要知道常见量级：服务器状态同步一般是10~30Hz，帧同步一般是每帧发送指令，心跳常见的是3~10秒一次。回答时加上“这个数值要根据真实网络环境压测调整”，就很完整了。

6.2 如何准备网络方向的面试：我给实操建议

如果你是零基础或者项目里网络部分写得很少，建议用一到两周时间，按下面这条路走一遍，比刷一百道题都管用。

先做一个最简TCP客户端和服务端。本地起一个监听端口，Unity客户端连上去，发一条自定义协议的消息，服务端收到后原样返回，客户端再解析并显示在屏幕上。这个过程中你会真实遇到粘包、字节序、收到半包不知道怎么处理的问题，把这些记录下来。

然后做一个HTTP请求到公开接口的Demo，用UnityWebRequest发Get和Post，分别处理成功、超时、404、500这几种情况。重点观察responseCode、error、isDone之间的区别。再用抓包工具看一下HTTP请求的报文格式，看看请求头、请求体、响应状态行长什么样。

最后做一个“断线重连”的小功能：客户端每秒检查一次连接状态，断开后尝试重连，重连成功后把断线期间缓存的消息队列补发出去。这个功能能覆盖掉大部分初级网络面试的知识点，包括心跳、超时、状态机、消息队列。

准备过程中可以顺手把每个问题的答案写在自己的笔记里，用“我要去给别人讲明白”的标准去组织语言。面试的时候不要怕被问到不懂的词，哪怕答不上来，也要尽量拆题：“这个点我目前接触不深，但我理解它是解决XXX问题的，我的项目里暂时用的是YYY方案。”这种回答哪怕不完美，也比沉默或者胡编强得多。

我自己带新人的时候，经常说一句话：网络这块知识，面试前突击两天能应付题目，但真正想做好客户端，一定要自己写过一遍才懂。希望这篇面经能帮你把网络这部分的复习范围圈清楚，少走点弯路。