网络延迟基础：看不见的信号“红灯”
做SDK调优，很多人一头扎进代码里找问题。但我得说，有一半的延时其实都出在你根本没注意到的网络层面。你想想看，你代码写得再快，数据包在路上堵了，有啥用？
我记得刚接手一个海外支付SDK的时候，用户总说“付款按钮点了没反应”。查了半天，本地调试一切正常。最后抓包一看，好家伙，每次调用光TCP握手就要200多毫秒。这个痛让我养成了一个习惯：任何SDK优化，第一步都是先看清网络链路。
TCP 三次握手——每次连接都绕不开的“寒暄”
简单来说，你的SDK要和服务器通信，得先打个招呼确认“听得见吗？”。这个招呼要来回三趟，所以叫三次握手。在现代网络上，光这个步骤少说也要几十毫秒。
我个人习惯是先搞清楚服务部署在哪儿。如果跨了地域，握手这部分延迟基本跑不掉。你想想看，北京到纽约的RTT（往返延迟）几百毫秒，光握手就去了大半。
| 握手阶段 | 说明 | 典型延迟消耗（跨域场景） |
|---|---|---|
| SYN | 客户端发起同步请求 | 0.5 RTT |
| SYN-ACK | 服务器响应并确认 | 1.0 RTT |
| ACK | 客户端最终确认 | 0.5 RTT |
| 合计 | 三次握手完成 | 约 1.5 RTT |
关键结论：每次新的TCP连接建立，至少消耗1.5倍RTT。如果你的SDK每次调用都重建连接，这部分延迟你根本躲不掉。
我在项目中遇到过一个典型场景：我们有个API网关，SDK每次请求都创建一个新连接。后来发现，每次握手就要浪费30-50毫秒。换成连接池复用后，系统整体延迟直接砍了一半。说白了，TCP握手的优化核心就是——能复用就别新建。
DNS 解析——第一步就可能踩坑
说起来你可能不信，很多线上事故都是从DNS开始的。你的SDK要去调一个接口，第一步就是要知道那个域名对应什么IP地址。这个过程叫DNS解析。
为什么会慢？因为这一问一答也可能绕很远。本地DNS缓存没有命中？那就得去递归查询，一层层往上找，中间还可能跨运营商。
实用技巧：SDK初始化阶段提前解析关键域名，把结果缓存到内存里。或者用IP直连，跳过DNS环节。
我曾经吃过一次大亏：有款海外发行的游戏，用户登录一直超时。查了半天，原因就是当地的DNS解析器响应非常慢，每次解析要花300毫秒以上。后来我们把域名预解析做成了初始化第一步，把解析结果缓存24小时。效果立竿见影。
另外还要注意一个坑——DNS解析可能触发TCP Fallback。默认情况下，DNS走UDP，但一旦响应长度超过512字节，就得切到TCP。这一切，又多了一次TCP握手。我建议你检查下自己的域名，如果解析结果太大，就精简一下记录。
网络拥塞——越挤越慢的“早高峰”
好，现在你的TCP连接建好了，数据也发出去了。但中间的路由器、交换机可不是什么都管你。它们有自己的流量管理机制，一旦发现数据太多了，就开始丢包或者标记为“慢点发”。
你的SDK调用，说白了就是参与了一场网络赛车。跑着跑着，如果发现前面堵车了，TCP协议会主动降速，控制窗口收缩。这个控制过程本身就需要时间，而且经常表现出来就是请求不稳定，忽快忽慢。
我记得有一次线上告警，一个SDK接口的P99延迟从100毫秒飙到了1.2秒。抓包一看，根本不是服务器慢，而是中间某个公网链路发生了TCP拥塞，重传率高达8%。后来换了一条运营商线路，问题就解决了。所以我的建议是：监控要抓到TCP层，不然你永远不知道是代码慢还是网慢。
丢包重传——越丢越慢的恶性循环
这是最让人头疼的一种情况。数据包在路上丢了，TCP又没有收到确认（ACK），那就得重传。一重传，时间上就多等了一个超时周期。
丢包重传有两种典型场景：
- 超时重传（RTO）：等了好一会儿没收到ACK，就认为丢了。这个“好一会儿”通常是几百毫秒起步。
- 快速重传：连续收到3个相同的ACK，说明中间丢了包。这个更快，大约1个RTT就能触发。
避坑指南：我曾经在弱网环境下跑过压测，发现一旦丢包率超过2%，整个调用的延迟就失控了。原因就是超时重传反复叠加。所以如果你的SDK要在移动端或者边缘网络下用，一定要做应用层的重传保护和超时管理，别完全依赖TCP。
你想想看，如果一个数据包重传了两次，那你的请求时间就变成了：TCP握手（1.5RTT）+ 传输（0.5RTT）+ 重传（1.5RTT）= 3.5RTT。这还不算网络拥塞导致的额外抖动。
所以，理解这些网络延迟的根源，你才能说清楚“为什么我的SDK在某些场景下就是慢”。这些不是纸上谈兵，是我踩过的坑一个一个试出来的。下一环节，我们就来聊聊怎么用工具和指标把这些隐藏的问题抓出来。