企业官网建设流程全解析

先讲个真实经历。有次上线一个消息推送服务，压测时服务端每秒钟往外吐上千条小报文，客户端那边反馈数据老是“收到但不全”，抓包一看，一半报文根本就没到对端，或者到了但对端没读出来。排查到最后，问题根源其实就一句话：选错协议了，而且压根没搞明白TCP和UDP在发送接收流程上到底差在哪。很多人面试能倒背“TCP面向连接、UDP面向无连接”，但真到写代码、调bug的时候，这两种协议在收发路径上完全不同的处理细节，才是真正决定成败的地方。

这篇内容我把TCP和UDP从应用层调用到内核缓冲、再到对端接收的整个发送接收流程拆开讲，对比它们在建立连接、发送数据、接收数据、异常处理四个环节的差异，同时穿插一些实际踩坑和选型建议。写这东西的初衷，就是希望你看完之后，不只记住“TCP可靠、UDP快”这种结论，而是能自己在项目里判断该用谁，出了问题知道往哪查，拿到抓包结果能看出门道。适合正在写网络程序的后端开发者、客户端开发，以及刚接触socket编程但对内网传输机制还有点含糊的朋友。

1. TCP和UDP到底是在哪一步开始分道扬镳的

很多人对TCP和UDP的第一印象是“一个可靠一个不可靠”，但可靠不可靠只是结果，真正的原因要从设计目标说起。

1.1 设计哲学决定了后面所有差异

TCP的设计目标是在不可靠的信道上实现可靠的字节流传输。它把一个应用层消息当成一串连续字节，这串字节从发送端流到接收端，中间可能被拆成多个数据段，可能经过网络拥塞、丢包、乱序，但TCP保证对端最终恢复出和发送端完全一致的字节顺序。为了实现这个保证，TCP必须维护连接状态、序列号、确认号、重传计时器、拥塞窗口……这一整套机制，本质上都是在为“可靠”买单。

UDP的设计目标刚好相反：在IP层之上提供一个极轻量的传输接口。它不承诺送达、不保证顺序、不维护连接状态，应用层交给它一个完整报文，它尽量丢到网络上，剩下的事不再过问。正因为不做任何可靠性工作，UDP才有低延迟、低开销、无连接的特点，才能支撑实时音视频、游戏同步、DNS查询这类场景。

你可以这样理解：TCP像是一个负责人的快递员，每一件包裹都要签收确认，丢了他会重新送；UDP像是一个扔纸飞机的孩子，扔出去就完事，飞没飞到不管。两种思路没有绝对优劣，关键是匹配需求。

1.2 核心差异快速对照表

先把收发链路上最关键的区别列成一张表，后面每一部分再展开细讲。这张表建议你收藏，排查问题的时候拿不准了翻出来对一下。

这张表里最核心的其实是“数据组织方式”这一行——TCP的字节流、UDP的数据报，这决定了send、recv的调用方式，也决定了粘包/半包、报文截断这些经典问题为什么只在各自协议下出现。

2. 连接建立与释放的流程差异：一次握手和一炷香的区别

发送接收流程的第一个分岔点从建连就开始了。TCP在正式传业务数据之前要先搞一次三次握手，UDP直接上来就发数据。

2.1 TCP三次握手到底在握手什么

三次握手不是走过场，它完成了三件事：确认双方收发能力正常、同步初始序列号、协商一些参数。

流程是这样的：

1. 客户端调用connect，发出一个SYN段，里面带一个客户端初始序列号，假设是X，同时把SYN标志位置1。
2. 服务端收到SYN后，如果accept队列还能放得下，就会回一个SYN+ACK段，里面带上服务端初始序列号Y，同时把确认号设为X+1，表示“你的SYN我收到了，下次你要发的数据从这个序号开始”。
3. 客户端收到SYN+ACK后，再回一个ACK段，确认号设为Y+1。此时connect返回，客户端进入ESTABLISHED状态；服务端在收到这个ACK后也进入ESTABLISHED状态。

注意一个容易被忽略的点：第三步的ACK发出后，客户端就已经认为连接建好了，但服务端要等收到这个ACK才算完。如果这个ACK在网络里丢了，服务端会超时重发SYN+ACK，客户端收到重复的SYN+ACK后会再补发一次ACK。很多人在抓包时看到“Retransmission”以为是数据传输出问题，其实可能只是建连时的ACK被丢了。

三次握手还有一个重要副作用：它会占用一个往返时间（RTT）。也就是说，TCP在传输第一个字节之前，至少要等一个完整的网络往返。对于跨地域调度、跨洋请求这类场景，光建连就可能吃掉几十毫秒甚至上百毫秒。UDP完全没有这一步，所以UDP在某些低延迟场景下赢在建连这一下。

2.2 TCP四次挥手与TIME_WAIT这个老熟人

传输结束后，TCP要四次挥手关闭连接。标准流程是：

1. 主动关闭方发送FIN段，进入FIN_WAIT_1。
2. 对端收到FIN后回ACK，进入CLOSE_WAIT状态，主动关闭方收到ACK后进入FIN_WAIT_2。
3. 对端应用层调用close后，发送自己的FIN段，进入LAST_ACK。
4. 主动关闭方收到FIN后回ACK，进入TIME_WAIT，等待2个最大报文段生命期（2MSL）后才完全关闭。

不少人在高并发服务器上遇到过TIME_WAIT大量堆积的问题。TIME_WAIT存在的意义是：防止最后一次ACK丢失导致对端重发FIN时，主动关闭方已经关闭端口而返回RST，进而干扰新连接。2MSL的等待确保网络中所有属于这个连接的迟到的报文都已被丢弃。

实操上，如果服务器上有大量TIME_WAIT，常见的处理是调整内核参数允许复用TIME_WAIT端口，或者在应用层设计上由服务端主动断开以减少TIME_WAIT落在服务器侧。但我要提醒一句：不要为了图省事随便把TIME_WAIT改成0，那会让整个系统在高压下出现数据错乱，属于“面试题背多了容易手滑”的操作。

UDP没有连接状态，自然也没有挥手流程。通信结束后，两端只需要停掉socket就行，没有任何握手确认。

2.3 UDP为什么不需要连接状态

UDP的“无连接”不是懒，而是它有明确的已知前提：不需要保证有序、不需要确认送达、报文自带完整目的地。所以它可以在无状态的情况下，为每个报文独立寻址并转发。

这就带来一个显著差异：TCP的连接是有成本上限的。一个服务器能支撑的并发TCP连接数受内存、文件描述符、内核的连接表限制，连接数上去后CPU也会因为维护大量连接状态而吃紧。UDP服务器的“连接数”在概念上被弱化了，一台UDP服务器理论上能同时为成千上万个远端地址提供收发服务，只要到达每个地址的报文字段里有足够信息让应用区分是谁发来的。

很多高并发、低延迟场景选UDP，一个很重要的原因就是省掉了连接管理这个全局瓶颈。服务端不需要维护连接池，客户端也不需要处理连接中断、重连、keepalive这些问题。当然，无状态也是一把双刃剑：服务端无法感知某个客户端“掉线”了，如果应用需要对端在线状态，得自己在应用层做心跳。

3. 发送侧流程拆解：send和sendto背后各自发生了什么

发送侧是TCP和UDP差异最集中的地方。同样是应用层调用一个接口发数据，内核里干的事完全不是一回事。

3.1 TCP发送路径：缓冲区、分片、滑动窗口

TCP的发送流程可以梳理成这样几个环节：

应用层调用send/write后，数据首先被拷贝进内核的TCP发送缓冲区。这个拷贝动作本身是有代价的，如果你的应用大量发送大数据块，用户态到内核态的拷贝会成为瓶颈之一。

TCP发送缓冲区里的数据并不是立刻、整块地发出去。TCP要根据当前发送窗口大小、路径MTU、Nagle算法等因素，把缓冲区的字节流切成一个个不超过MSS（最大报文段大小）的段，每个段都打上序列号。这里的序列号是字节号——假设你一次性send了3000字节，而MSS是1460，TCP可能切成两个段：第一个段携带第1到1460字节，第二个段携带第1461到2920字节，剩余80字节留在缓冲区等下轮发送。

然后，每发出去一个段，这段数据就留在发送缓冲区里等待ACK。收到ACK后，对应的字节才会从缓冲区移除。如果超时没收到ACK，TCP会重传；如果收到重复ACK，触发快速重传，也会重传。

滑动窗口是TCP发送侧最核心的流量控制机制。接收端在每一个ACK里都会带上自己的接收窗口大小（rwnd），告诉发送端“我还有多少空间，你最多还能发多少字节”。发送端还会维护一个拥塞窗口（cwnd），两者取小值作为实际可发送的窗口上限。窗口越大，网络里允许的在途数据越多，单连接吞吐越大。实测中，如果你发现TCP吞吐上不去，先看这两个窗口，很多时候是某个中间链路设备的缓存太小把窗口压死了。

下面是一个TCP发送路径的关键步骤汇总：

1. 应用层send，数据拷贝进内核发送缓冲区。
2. TCP按MSS和窗口大小把字节流分片为数据段。
3. 每段分配序列号，记录起始字节编号。
4. 根据Nagle算法决定是否立即发送：小报文可能要攒一下，为了把多个小包合并成一个大包再发。
5. 已发送未确认的数据保留在发送缓冲区并启动重传计时器。
6. 收到ACK后确认对应序列号，释放缓冲区空间，继续发下一批。

这段流程里有个典型的“坑”——Nagle算法和延迟确认（Delayed ACK）相互作用，可能导致某些小报文发送出现高达40ms的额外延迟。所以很多做实时交互的项目都会在TCP连接上设置TCP_NODELAY，把Nagle关掉。关掉后小报文立即发送，但代价是网络里可能出现大量小包，加重网络拥塞。具体要不要关，要看你的报文是不是真的对延迟敏感。

3.2 UDP发送路径：sendto一次一个报文

UDP的发送流程简单到让你觉得不真实：

调用sendto时，应用层传入一个完整的报文（通常是一个缓冲区，包含数据部分、目标地址和端口）。内核拿到这份数据后，直接把它封装成UDP报文，加上UDP头——源端口、目的端口、长度、校验和，然后交给IP层。IP层再给它加上IP头、查路由表，通过网卡发出去。全程没有任何分片等待、没有确认机制、没有重传，发送完就完事，sendto返回值只代表数据被内核接收并交给IP层，不代表对端收到了。

有几个UDP发送侧的细节值得注意：

第一，UDP报文的长度有限制。以太网环境下，UDP载荷的常见上限是1472字节（1500 MTU减去20字节IP头和8字节UDP头），超过这个数就会有IP分片风险。实测中，分片报文在公网上丢包概率会显著上升，因为在某些路径上中间设备会直接丢弃分片。如果你要传大报文，最好在应用层做分片，或者使用足够大的发送缓冲区，同时精确计算路径MTU。

第二，sendto系统调用本身是有开销的。一次sendto通常触发一次系统调用和一次数据拷贝，吞吐极高时这个开销会被放大。一些高性能网络程序为了降低系统调用次数，会使用sendmmsg批量发送多个报文，一次系统调用发一批包，实测在转发大量小包时能明显提升吞吐。

第三，UDP没有“半包”的概念。你sendto一个1500字节的报文，对端recvfrom拿到的就是完整1500字节，要么全到，要么全不来。这个特性在协议设计上是好事，你不需要像TCP那样处理半包粘包，但也意味着一旦载荷超过接收缓冲限制，超出的部分会被直接丢弃——这和TCP将多余数据留在缓冲区内是完全不同的处理方式。

3.3 发送时机与缓冲策略的差异化影响

TCP的发送时机受Nagle算法和窗口共同控制。默认情况下，小包可能被延迟合并，大包可能被窗口挡住。UDP则完全没有这层控制，sendto之后数据即刻进入IP层排队发送。

举个例子：假设你要以每10毫秒一个、每个20字节的频率发送控制报文。用TCP默认配置跑，抓包可能看到多个20字节的小包被合并成一个大包一次性发出，接收方拿到时已经攒了好几条消息。很多初学者在这种场景下会开始怀疑“TCP是不是丢消息了”——其实没有丢，是合并了。而用UDP跑同样的逻辑，每10毫秒一个20字节报文会原模原样地到达接收端（当然也可能原模原样地丢失，这是另外一个问题）。

发送缓冲区的策略也完全相反：TCP发送缓冲区在未收到ACK前，数据会一直占用；UDP发送缓冲区则像一个即时倾倒的容器，sendto后数据就交给IP层，缓冲区立即空出来。所以UDP的“发送成功”其实非常廉价——它压根没有保障。

4. 接收侧流程拆解：字节流与数据报的本质矛盾

如果说发送侧的分歧已经很大，接收侧的分歧就是鸿沟了。TCP的接收者面对的是连续字节流，UDP的接收者面对的是一个个完整报文，这个差异直接催生了TCP世界里的粘包问题，和UDP世界里的截断问题。

4.1 TCP接收：按序重组和那个著名的粘包问题

TCP接收路径是发送路径的逆过程：

数据段到达网卡后进入内核的TCP接收缓冲区。因为网络传输存在乱序可能，同一个连接的多个段可能以非顺序到达。TCP依靠每个段的序列号（精确到字节）对数据进行排序，将不连续的数据暂存在乱序队列，等前面的字节补齐后再送入已排序队列，同时更新接收窗口，并向发送端返回ACK——ACK里带的序号表示“我已经连续收到了哪个字节位置”。

应用层调用read/recv时，就是从已排序的接收缓冲区里取走连续字节。这里有一个让无数人挠头的特性：read并不保证一次拿到发送端send的那条完整消息。假设发送端send了100字节，接收端第一次read可能只拿到40字节，第二次又拿到60字节，也可能一次拿到120字节——如果刚好有两个消息在缓冲区里挨着。

这就是粘包问题的根源：TCP是字节流，没有消息边界。接收端不知道哪几个字节属于一条完整消息。解决思路一般有三种：

1. 定长消息：每条消息固定长度，接收端按长度切分。最简单，但消息体变长时浪费带宽。
2. 分隔符：消息之间用特殊字符分隔，比如JSON里常见的换行符。实现容易，要注意消息体里如果包含分隔符需要转义。
3. 长度前缀（TLV）：每条消息头部先放4字节长度，接收端先读4字节得到长度，再按长度读完整消息。这是工程上最常用的方案，序列化库和RPC框架基本都是这么干的。

我在实际项目中踩过的坑是：用TCP传输时，接收端如果没按消息边界做处理，高并发下数据一定会错乱。排查粘包问题的时候，不要傻乎乎地盯着代码看，直接看抓包里的数据排列，一眼就能看出哪几个字节拼在一起是完整包。

4.2 UDP接收：边界保留和一次一报文的刚性约束

UDP接收路径比TCP简单得多：报文到达网卡后，内核根据UDP头里的目的端口找到对应的socket，把整个报文放入该socket的接收队列。应用层调用recvfrom，从队列头部取出一个完整报文。每次recvfrom对应一个sendto，不多不少。

这个设计天然规避了粘包问题。但代价是：如果应用层一次性需要处理超过单个报文上限的数据，就必须自己做应用层重组。比如在UDP之上实现可靠协议，发送端把一个大对象拆成多个UDP报文，每个报文里放一个偏移量和总长度，接收端收集齐所有分片后按偏移量组装。这是完全在应用层重新实现一个面向报文的“TCP”，复杂度和难度都上一个台阶。

另一个值得注意的问题是报文截断。recvfrom调用时如果传入的接收缓冲区小于报文长度，多余的字节会被内核直接丢弃，这就是UDP报文的截断行为。TCP不会出现这种情况——TCP按字节读取，缓冲区不够就下次再读；UDP则一次性把整个报文丢给你，拿不下就丢。所以用UDP接收数据时，接收缓冲区一定要开得足够大，最好按你预期最大报文长度去分配。

有几个项目的接收逻辑设计建议：

• 接收缓冲区的长度设置成比预期最大报文大一些，留出安全余量。
• 使用recvmsg替代recvfrom，可以批量接收、附带辅助数据，也方便控制缓冲区。
• 如果需要高吞吐接收大量小报文，可以考虑recvmmsg批量接收，一次系统调用取多个报文，能明显降低系统调用开销。

4.3 缓冲区耗尽时，两个协议的表现完全不同

当接收方处理不过来时，TCP和UDP的“失败模式”有明显的不同。

TCP接收缓冲区写满时，发送端的窗口会降为0，发送端停止发送，数据滞留在发送缓冲区。此时应用层看到的典型现象是写操作阻塞，或者吞吐骤降，但不会丢数据——前提是发送端没有设置超时强制关闭。这是一种“优雅的积压”，用背压（backpressure）机制把压力传导回了发送端。

UDP接收缓冲区写满时，新到的报文会被内核直接丢弃，发送端毫不知情。应用层看到的现象是：接收端没有处理某些报文，但没有任何报错日志。如果你在UDP接收端做消息计数，会发现计数比预期少，这就是丢包了。UDP的丢包在接收侧的表现最为隐蔽，因为没有任何机制通知你丢了。

所以，UDP应用的监控方式必须和TCP不同。TCP你盯连接状态、吞吐、重传率就可以，UDP你得上应用层序号——每条报文带一个自增序号，接收端看到序号跳变就知道丢了。这是所有在UDP之上做可靠传输协议的通用前提。

5. 传输过程中的可靠性与异常处理差异

发送和接收的核心流程讲清了，接下来看传输过程中，数据在网络上飞的时候，两个协议各自的处理方式，以及这些差异在真实网络中的表现。

5.1 TCP确认重传和拥塞控制如何影响“手感”

TCP的可靠性靠的是确认重传机制。发送端每个已发送数据段都保留一个副本并启动计时器，如果超时还没收到对应ACK，就重传这个段。如果收到三个重复ACK，则立即重传，不必等超时——这称为快速重传。此外还有选择性确认（SACK），告诉发送端“我已经收到了哪些不连续的数据”，避免不必要的重传。

除了可靠性，TCP还会根据网络拥塞动态调整发送速率。慢启动从一个小拥塞窗口开始，没丢包就指数增长；发生丢包时，拥塞窗口减半或归1，触发拥塞避免。这带来的直接后果是：新建的连接吞吐是慢慢爬上去的，不会一上来就满速。如果你在做突发大数据量传输，前一两秒可能感受不到满带宽，这就是拥塞控制在起作用，而不是网卡慢。

从应用层的“体感”来说，TCP会提供“确定感”：发送端能知道数据有没有被确认（通过ACK或者阻塞），接收端不用担心中间丢数据。代价是延迟波动大——拥塞、重传、排队都会让某一跳变慢，整个流跟着慢下来。

我的实际体会是：TCP的传输链路像一条高速公路，有红绿灯管制（拥塞控制）、有监控探头（确认重传），车再多也不会乱，但高峰期一定限速。UDP则像郊外野路，没有管制没有监控，路况好时你飙车飞快，出了事也没人管。

5.2 UDP的尽力而为与上层补偿

UDP没有任何可靠性机制，但它带来的是“极简转发”的高性能。它的异常模式也很明确：丢包、乱序、重复。注意——网络上不仅会丢包，还会出现乱序到达和重复包。UDP应用必须自己面对这些情况。

乱序怎么办？应用层处理方案是使用序号字段，数据到达后先暂存缓冲区，按序号重组。重复怎么办？用去重机制，常见的做法是给报文一个唯一ID，接收端维护一个最近收到的ID集合，重复的直接丢弃。丢包怎么办？这要分场景看：对于音视频，丢几个包通常无伤大雅，播放端做插值就行；对于需要在UDP上传输可靠消息的场景，就得在应用层做ACK和重传——这基本就是重新实现TCP的一部分功能了。

很多团队在UDP之上重造可靠传输轮子时，会把序列号、ACK、重传、拥塞控制重新写一遍。这样做换来的收益是：可以按应用需求定制策略，比如把重传只用于关键消息、对非关键消息不做重传，或者采用更激进的拥塞控制策略。但代价是实现复杂度高、调试难、Bug多。做这个选择前，最好先问自己一句：这个需求，TCP真的满足不了吗？

5.3 典型故障现象对照：从抓包到定位

掌握收发流程的差异后，在排查问题时你能更快缩小范围。这里列几个典型故障现场，都是我实际遇到过或同事踩过坑后总结的：

1. TCP传输大文件，速度刚开始很慢，后来才慢慢变快——这通常是慢启动的正常表现，如果一直慢看看是不是拥塞窗口或接收窗口被链路压低了。
2. TCP频繁出现“Connection reset by peer”错误——通常是某一端对已关闭连接继续发送数据，或者对端在TIME_WAIT期间收到新数据返回RST。
3. TCP服务大量TIME_WAIT——一般是短连接多且主动关闭方集中在一侧，考虑连接复用或用长连接。
4. UDP高流量时接收端丢包率猛增——优先看接收缓冲区大小、应用读取线程数、系统中断与网卡队列。很多人一上来怀疑网络，实际就是内核缓冲区太小加应用线程处理不过来的问题。
5. UDP报文“到了但是乱序”——网络路由天然会乱序，应用必须用序处理。别问为什么，问就是网络的锅。
6. 客户端反馈“消息时有时无”——TCP下大概率是粘包半包没处理好，UDP下大概率是丢包没感知。

从抓包层面看，TCP有丰富的状态信息：序列号、ACK号、窗口、重传标志，你可以看清一条数据流的完整生命周期。UDP抓包只有源端口、目的端口、长度、校验和，你能确定的就是“这个包确实从A发到了B”，至于是否有遗漏、是否有重复，得靠应用层日志和序号字段来判断。

6. 选型实战与踩坑记录

最后落到最实际的问题：我的场景到底该用TCP还是UDP？这里分享一套我实践中总结的决策思路，以及一些踩坑后的复盘。

6.1 什么时候必须用TCP，什么时候该考虑UDP

建议优先选TCP的场景很明确：要求数据不能丢、不能乱、实现要快。比如HTTP接口、数据库连接、文件传输、分布式系统节点通信。这些场景在TCP之上有成熟的库和框架，粘包问题有现成方案，你不需要重复造轮子。

可以考虑UDP的场景包括：实时性要求极高且能容忍一定丢包；消息本身短小且频繁；需要广播或组播（这是UDP独有的能力，TCP根本做不了）；服务端需要同时服务极大数量客户端且不想维持连接状态。典型例子：在线游戏里位置/操作同步、音视频通话、实时监控画面传输、局域网设备发现、DNS查询。

还有一个容易被忽视的考量：如果你的消息大小超过MTU、又不想处理分片，TCP可以自动帮你分片和重组，UDP则需要你主动控制报文大小或者自己做分片。所以即便你倾向UDP，也得先确认报文大小是否可控。

6.2 真实案例复盘：一次选错协议带来的整改

之前做过的某个模拟项目X，最初设计是服务端向客户端推送实时行情，消息很小、频率很高，团队图省事直接选了TCP长连接。上线后遇到两个问题：一是行情更新延迟偶尔飙升，二是客户端多时服务端连接数暴涨。后来排查发现，这些小报文在TCP里触发了Nagle和延迟确认的相互作用，导致正常情况下几毫秒能到的消息，某些时候要等40毫秒；另外每客户端一条长连接，一万个客户端就一万个连接，服务端光维护连接状态和心跳就把CPU吃掉了不少。

整改时，核心消息改成UDP，服务端一个socket搞定所有客户端，客户端用应用层序号检测丢包并请求补发，普通更新消息丢了就直接忽略。改完延迟稳定在1到3毫秒，服务端CPU占用降了一截。这次整改最大的收获是：不是因为TCP不好，而是这个场景的“频繁小消息+海量客户端+容忍极小概率丢包”三个特征，全部指向UDP更合适。如果是一堆大消息或者一点都不能丢的场景，改成UDP纯属自讨苦吃。

6.3 常见问题速查与避坑清单

最后整理一份问题速查表，基本都是项目里容易反复踩的坑：

避坑清单里补几条个人经验：

• 不要在UDP接收端用固定大小缓冲接收所有大小不一的报文，按最大报文预留，否则大报文一到就截断，排查起来很隐晦。
• 不要在UDP应用里不做任何监控就上线，UDP失败无感知，必须靠序号、心跳、丢包率这些业务指标来兜底。
• 不要因为TCP“可靠”就把所有消息都塞进TCP，可靠性最终取决于业务需求，如果一个消息晚到一百毫秒比丢了更糟，那它可能更适合走UDP。
• 如果要自定义可靠UDP协议，先评估工作量，再把TCP源码里的序列号、ACK、超时重传、拥塞控制一个个搬过去——搬不完别生气，这才是常态。

我个人在产品里做过一次混合方案：关键控制指令走TCP（要确认），实时状态数据走UDP（要低延迟），应用层通过统一的会话ID把两路数据关联起来。这个方案避免了单一协议的妥协，比较推荐在复杂业务里尝试——前提是你能把两路数据的对齐和容错想清楚，不然协调难度会比单协议更高。

TCP和UDP的发送接收流程差异，本质上就是“可靠”和“高效”这两种思路在传输链路每一环节的博弈。真正的选型高手，会把每一个差异点都变成自己设计方案里可用的筹码：需要确认就用TCP的ACK，不需要确认就用UDP的轻快，担心丢包就在UDP之上设计自己的重传，担心延迟就在TCP之上关掉Nagle。这样用协议的思路，而不是被协议牵着走，才是熟练掌握网络编程该有的状态。