3. 网络延迟基础：TCP握手、TLS握手与DNS解析优化

网络延迟这东西，说白了就是你的SDK调用在网络上“堵车”了。我在做SDK性能分析时，发现很多团队的优化都盯着业务代码，却忽略了最底层的网络握手开销。你想想看，一个API调用还没发出去，光握手就耗了几百毫秒，后面再怎么优化也都是隔靴搔痒。

这一章我们就来拆解三大网络延迟源头：TCP握手、TLS握手，还有DNS解析。搞清楚它们，你才知道该从哪里下手。

3.1 TCP握手延迟：三次握手的代价

TCP的三次握手，每个做网络开发的都背过。但你真的算过它占了多少时间吗？

一个完整的TCP连接建立，至少需要一个RTT（往返时间）。如果客户端和服务器之间的网络延迟是50ms，那光握手就要100ms（SYN + SYN-ACK/ACK）。更坑的是，SDK通常需要建立多个连接，这个开销是成倍叠加的。

3.1.1 解决思路：连接复用是王道

我建议用连接池来复用TCP连接。常见做法是保持长连接，避免反复握手。HTTP/1.1的Keep-Alive、HTTP/2的多路复用，本质上都是在干这事。

但要注意，长连接不是无限期保持的。我曾经在一个项目中遇到连接泄漏，就是因为连接池没有清理长期空闲的连接，结果文件描述符被耗光了。

3.1.2 TCP快速打开（TFO）

TCP Fast Open是一种优化技术，允许在SYN报文里就直接携带数据。这样能在0-RTT下完成数据发送。不过它在NAT环境下兼容性不太好，我一般只在内部服务间通信时使用。

3.2 TLS握手优化：加密不能牺牲性能

现在大部分SDK都跑在HTTPS上，TLS握手又是额外的开销。而且TLS 1.2之前需要两次RTT才能完成握手，加上TCP的三次握手，总共要3-4个RTT才能发送第一个业务请求。

我记得有一次上线的SDK在弱网环境下响应时间暴涨，排查下来就是TLS握手重试导致的。客户端在移动网络下丢包率高，TLS握手反复失败，用户直接卡住了。

3.2.1 TLS 1.3：0-RTT模式

TLS 1.3把握手压缩到了1-RTT，甚至支持0-RTT。客户端可以在第一个消息里就发送应用数据。不过有个坑：0-RTT有重放攻击风险，不能用在幂等性要求不高的操作上。

协议版本	握手RTT数	安全特性	适合场景
TLS 1.2	2 RTT	高（CA证书校验）	Web网页、首次连接
TLS 1.3（完整）	1 RTT	高（更多加密算法支持）	API调用、移动端SDK
TLS 1.3（0-RTT）	0 RTT	中（存在重放风险）	幂等的查询类请求

3.2.2 会话复用

不管是TLS 1.2还是1.3，会话复用都能显著减少握手开销。服务器端缓存会话ID或会话票据，客户端在后续连接中直接复用。这个减少的RTT非常可观。

3.2.3 证书链优化

TLS握手时，服务器会发送完整证书链。如果证书链太长（比如中间证书有3-4级），握手包就会变大，传输时间增加。更坑的是，客户端需要验证每个证书的签名，这很耗费CPU。

我建议这么做：

• 减少证书层级，尽量控制在两级（根CA + 服务器证书）
• 使用OCSP Stapling，让服务器主动提供证书吊销状态，省去客户端再去查询OCSP服务器的RTT
• 启用HTTP/2的服务器推送，提前推送证书给客户端

3.3 DNS解析优化：你忽略了的第一公里

很多开发者盯着应用层的延迟，却忽略了DNS解析。你想想看，每次SDK初始化时都要去查域名IP，如果DNS解析超时，整个调用链都别想开始。

我见过一个极端案例：客户端依赖公共DNS，结果公网DNS服务器被攻击，解析时间从10ms飙到了3秒，SDK直接废了。

3.3.1 DNS缓存

最简单的优化就是做缓存。系统层面、SDK层面都要做。我记得在iOS上做过统计，系统DNS缓存命中率只有60%左右，剩下的40%都得走网络查询。你可以在SDK里实现一个轻量的DNS缓存，TTL不要完全听服务器的，自己设置一个合理上限（比如300秒）。

3.3.2 DNS预取（Prefetching）

预取是更主动的策略。如果你的SDK知道后面会调用哪些域名，可以在用户操作之前就去解析。比如用户登录后，马上预取首页需要用到的三个域名的IP。

实现方式很简单：

// 伪代码示例：异步DNS预取
void prefetchDomains(char **domains, int count) {
    for (int i = 0; i < count; i++) {
        // 异步调用getaddrinfo
        pthread_t thread;
        pthread_create(&thread, NULL, resolve_thread, domains[i]);
        pthread_detach(thread);
    }
}

3.3.3 使用HTTPDNS避免DNS劫持

传统DNS解析依赖UDP，容易受到中间设备拦截或劫持。我建议使用HTTPDNS，直接通过HTTP请求从可靠服务器获取IP。这样还能实现更精细的流量调度，比如根据客户端所在的地区返回最近的CDN节点。

这里有个取舍：HTTPDNS的第一次查询是同步的，会增加几十毫秒延迟。所以我通常混合使用——本地缓存一个合法的IP列表，HTTPDNS用于更新和校验。

3.4 本章知识结构

下面这张图展示了我个人对网络延迟优化的整体思路。从DNS解析开始，到TCP连接复用，再到TLS握手加速，每一步都可能成为瓶颈。