我的服务传输大量数据,带宽明明很充足、网络也不差,可吞吐量就是上不去、尤其每次新建连接的前期慢得明显,排查半天才发现 TCP 有个慢启动机制、新连接的发送窗口是从很小一点点试探着爬上来的深度复盘

这是一次让我对"一个新建立的东西,往往不在它的最佳状态、需要时间预热"有了刻骨认知的事故。我有个服务要在节点之间传输大量数据(同步文件、推送批量数据)。我观察到一个奇怪的现象:带宽明明很充足(测速能跑满)、网络延迟也不高,可我的实际传输吞吐量就是上不去,达不到带宽的理论值。更明显的是,每次新建一条连接去传,前期都慢得肉眼可见,要过一会儿才"提上速";而我的传输模式恰恰是频繁建新连接传一小批就关,于是每条连接几乎都在"慢吞吞的前期"就结束了,整体吞吐惨不忍睹。

我一开始以为是带宽不够、是对端处理慢、是我代码缓冲区小,逐一排查都不对——带宽测速能满、对端很闲、缓冲也够大。直到我抓包,盯着一条新连接的发送速率曲线看,才恍然大悟:这条连接刚建立时,发送速率非常低,然后呈指数往上爬,爬了好一阵才接近带宽上限。我去查 TCP 的行为,真相浮出水面:TCP 有一个叫"慢启动(slow start)"的机制——一条新连接刚建立时,发送方并不知道这条网络路径到底能承受多大的发送速率,所以它不敢一上来就猛发,而是从一个很小的初始拥塞窗口开始,每收到确认就把窗口扩大(指数增长),一点点试探着加速,直到逼近网络的承载上限。也就是说,每一条新连接,前期都要经历这个"从慢到快的预热爬升"过程;而我频繁新建短连接,等于每次都把这个预热重新来一遍、还没爬到高速就关了——自然永远跑不满带宽。

故障现场:新连接发送速率从很低指数爬升,短连接没爬到顶就结束

我把抓包看到的现象还原出来,问题一目了然:

# 抓包看一条新 TCP 连接的发送速率随时间变化:
连接建立 → 初期发送速率很低(初始拥塞窗口很小, 一次只发几个包)
  ↓ 每个 RTT, 收到 ACK, 拥塞窗口翻倍(指数增长)
  ↓ 速率快速爬升...
  ↓ 经过若干个 RTT, 窗口爬到足够大, 才逼近带宽上限
达到稳定高速

# 关键: "爬升到高速"需要时间(若干个 RTT), 这就是【慢启动预热】
#   带宽再大, 新连接前期也跑不快——它还没"试探"出这条路能跑多快

# 我的传输模式: 频繁新建短连接, 传一小批就关
连接1: [慢启动爬升中...] 传完关闭   ← 几乎全程在低速预热期
连接2: [又从头慢启动...] 传完关闭   ← 又重新预热一遍
连接3: [再从头慢启动...] 传完关闭   ← 永远在预热, 从没享受到高速
→ 每条连接都没爬到高速就结束, 整体吞吐远低于带宽 ✗

# 对比: 一条长连接持续传大量数据
长连接: [慢启动爬升] → [到达高速后一直高速传输...........]   ← 预热一次, 长期高速 ✓

看着那条"从低速指数爬升"的速率曲线,我才彻底明白:一条 TCP 连接,并不是一建立就处于"满速"状态;它需要通过慢启动逐步试探、预热,才能爬升到这条网络路径真正能支撑的高速。这个"预热"是有成本的(要花若干个 RTT)。而我频繁新建短连接的模式,让每一次传输都从"冷启动"开始、还没预热完就结束,等于反复支付预热成本、却从不享受预热之后的高速。带宽充足毫无意义——因为我的连接根本没"跑起来"就停了。我以为新连接和老连接一样能立刻全速跑,其实每条新连接都是个"需要热身"的新手,而我总在它刚热身、还没进入状态时就让它下场了。

第一件事:搞懂慢启动——连接是有状态的,需要预热才能达到最佳

冷静下来,我去把"TCP 慢启动与拥塞控制"这一课认真补了,才明白这个"新连接总慢"的根源:

【为什么新 TCP 连接前期慢——慢启动】

问题: 一条新连接刚建立, 发送方【不知道】这条路径能承受多大速率
  (带宽多少、中间会不会拥塞、对端能收多快, 都未知)
  - 如果一上来就猛发, 可能瞬间压垮网络/对端 → 大量丢包、更糟

TCP 的策略——慢启动(slow start):
  - 从一个很小的【初始拥塞窗口】开始(只发几个包)
  - 每收到 ACK(每个 RTT), 就把拥塞窗口【翻倍】(指数增长)
  - 这样"由小到大、试探着"加速, 直到逼近网络承载上限或开始丢包
  → 即: 新连接需要【若干个 RTT 的预热】, 才能爬到高速

关键影响:
  - 单条长连接: 预热一次, 之后长期享受高速 → 高效
  - 频繁短连接: 每条都从头慢启动, 没爬到高速就关 → 永远在低速预热期
    带宽再大也跑不满, 因为连接"没热起来"就结束了
  - 高 RTT(跨地域)下慢启动更明显(每爬一级要一个 RTT, RTT 越大爬越慢)

正解方向(让连接"热起来"并复用这份热度):
  - 连接复用/长连接(keep-alive、连接池): 别频繁建新连接,
    让连接预热一次后被反复使用, 摊薄预热成本、长期高速
  - HTTP/2 多路复用: 一条连接上跑多个请求, 共享同一份"预热"
  - 大传输用持久连接、别拆成大量短连接
  - 内核可调初始拥塞窗口(initcwnd)等, 但治本还是复用连接

这一下点醒了我:我把 TCP 连接当成了一个"一建立就处于最佳状态、能立刻全速"的东西,可它其实是有状态的——它需要通过慢启动预热,逐步摸清这条路能跑多快,才能进入高速状态。这个"预热到最佳状态"是需要时间和过程的;而我频繁推倒重建连接,等于让每条连接都停留在"尚未预热好"的初始低效状态,从没让它真正发挥出来。不是网络慢、带宽小,是我反复使用"没热起来的新连接",而一条连接最高效的时候,恰恰是它预热完、被持续使用的时候——这正是我从来没给它的机会。

第二件事:正解——用长连接/连接复用,让连接预热一次后长期高速

找到根因,正解就清晰了:别频繁新建短连接、让每次传输都从慢启动冷启动;改用长连接/连接复用(keep-alive、连接池、HTTP/2 多路复用),让一条连接预热一次后被反复使用,把慢启动的预热成本摊薄、长期享受预热后的高速。大块数据用持久连接传,别拆成大量短连接。

// 错误: 每次传输新建连接, 传完就关 → 每次都从慢启动冷启动, 永远跑不满
for batch in batches:
    conn = newConnection()      // 新连接, 拥塞窗口从最小开始预热
    conn.send(batch)            // 还没爬到高速就传完了
    conn.close()                // 关掉, 下次又得从头预热 ✗

// 正解1: 复用一条长连接(或连接池), 预热一次, 长期高速
conn = pool.get()               // 复用已"热"的连接(已经历过慢启动)
for batch in batches:
    conn.send(batch)            // 连接已在高速状态, 持续传输 ✓
pool.put(conn)                  // 用完归还, 保持其"热度"供下次复用

// 正解2: HTTP keep-alive / HTTP/2 多路复用
//   - keep-alive: 一条 TCP 连接连续处理多个请求, 共享同一份预热
//   - HTTP/2: 一条连接上并行多个流, 一份预热服务多个请求

// 正解3: 大数据传输用单条持久连接, 别拆成大量小连接
//   一次大文件传输 > 开 100 条连接各传一小段(各自慢启动)

// 辅助(治标): 内核可调大初始拥塞窗口 initcwnd, 让新连接起步快些
//   sysctl 调 net.ipv4.tcp_*; 但治本仍是"复用连接、别频繁重建"

这套做法的精髓,是把"连接"当成一个需要预热、且预热后状态宝贵的资源来对待:让它预热一次,然后反复复用这份来之不易的"热度",而不是每次都推倒重来、反复支付预热成本却从不享受成果。连接池、keep-alive、HTTP/2 多路复用,本质都是"让一条已经热起来的连接,服务尽可能多的传输"。不是去消除慢启动(它是必要的拥塞保护),而是别让每次传输都重新经历它——预热一次,长期受益。

【关于慢启动 / 连接预热, 几条原则】

1. 新 TCP 连接前期慢是慢启动: 窗口从小指数爬升, 需若干 RTT 预热到高速

2. 频繁短连接 = 每次冷启动, 没爬到高速就关, 带宽再大也跑不满

3. 治本: 长连接/连接池/keep-alive/HTTP-2 复用, 预热一次长期高速

4. 大数据传输用单条持久连接, 别拆成大量短连接各自慢启动

5. 高 RTT(跨地域)下慢启动影响更大, 连接复用收益更明显

6. initcwnd 等内核参数可让起步快些(治标), 治本仍是复用连接

第三件事:其他"新建的东西没预热、不在最佳状态"的同类坑

顺着"新建的东西需要预热、频繁重建享受不到预热成果"这条线,我把同类的坑都梳理了一遍,它们都源于"反复使用没'热'起来的东西":

第一个,JVM/JIT 冷启动慢。JVM 刚启动时代码还没被 JIT 编译成机器码、跑得慢,要运行一阵"预热"后才达到峰值性能。频繁重启、或只测冷启动,就看不到真实性能。

第二个,缓存冷启动(cache cold)。缓存刚启动是空的,大量请求穿透到后端,要"预热"(预加载热点数据)后命中率才高。冷启动直接上线容易压垮后端。

第三个,连接池/线程池没预热。池子初始没有空闲连接/线程,首批请求要现建,慢;可配置最小空闲数预创建,让它"热"着待命。

第四个,Serverless 冷启动。函数实例冷启动要加载运行时、初始化,首次调用慢;靠预留实例/保活来避免每次都冷启动。

第四件事:频繁短连接 vs 复用长连接,一张表对照

我把"频繁新建短连接"和"复用长连接"在慢启动影响下的差别整理成一张表,这是我现在设计数据传输时的依据:

这张表让我看清:频繁短连接让每次传输都困在慢启动的低速预热期、还每次都付握手开销;复用长连接则让连接预热一次后长期高速,把带宽真正用起来。数据量越大、传输越频繁、RTT 越高,连接复用相对于频繁短连接的优势就越悬殊。持续/大块的数据传输,几乎总该用复用的长连接。

第五件事:我对"新连接传输"的几个想当然

这次事故,本质是我把"连接一建立就能全速"当成了理所当然。把这些想当然列出来,每一条都值得警惕:

第六件事:做数据传输、排查吞吐时,我现在的自检习惯

现在每当我做数据传输、或排查"带宽够却吞吐上不去",我都会先按这张图问自己:

这张图的精髓,是"吞吐上不去先看是不是频繁新建短连接、每次都困在慢启动预热期;改成复用让连接热起来"。设计就大/持续传输用长连接、连接池、keep-alive、HTTP-2 复用、排查就看吞吐低是不是因为连接没预热好就被反复重建。这套习惯,让我从"新连接就能全速"变成了"连接要预热、预热好的连接要复用"——核心始终是:TCP 有慢启动机制:新连接刚建立时发送方不知道路径能承受多大速率、不敢猛发,从很小的初始拥塞窗口开始、每个 RTT 翻倍指数爬升、需若干 RTT 预热才逼近带宽上限;频繁新建短连接让每次传输都从慢启动冷启动、没爬到高速就关,带宽再大也跑不满;正解是用长连接/连接池/keep-alive/HTTP-2 多路复用让连接预热一次后被反复使用、大块传输用单条持久连接,把慢启动的预热成本摊薄、长期享受高速。

我立下的几条规矩

这场"带宽够却吞吐上不去"的事故,换来了我做数据传输时,刻进骨子里的几条铁律:

1. 新 TCP 连接前期慢是慢启动:拥塞窗口从很小开始、每 RTT 翻倍、要预热若干 RTT 才到高速。
2. 频繁新建短连接 = 每次冷启动,没爬到高速就关,带宽再大也跑不满。
3. 连接是有状态的:预热过的老连接比新连接快得多;别把新旧连接当一样的。
4. 治本:用长连接/连接池/keep-alive/HTTP-2 复用,让连接预热一次后被反复使用、长期高速。
5. 大块/持续数据传输用单条持久连接,别拆成大量短连接各自慢启动。
6. 高 RTT(跨地域)下慢启动影响更大,连接复用收益更明显;initcwnd 调优是治标。
7. 推而广之:JVM/JIT、缓存、连接池、Serverless 都有冷启动/预热;频繁重建就享受不到预热成果。

附:我现在传输大量数据固定用的"复用连接"骨架

这是我现在做大量/持续数据传输时固定套的"复用连接"骨架——把这次踩坑的教训(别频繁建短连接、让连接预热一次后长期复用)固化成了一套配置和写法,让传输再不会困在慢启动的低速期:

// 全局共享一个带连接池的 HTTP client(连接预热一次, 反复复用)
var sharedClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 100,          // 对同一目标保留足够空闲连接复用
        IdleConnTimeout:     90 * time.Second,
        ForceAttemptHTTP2:   true,          // 启用 HTTP/2 多路复用, 一连接多请求共享预热
    },
}

// 错误: 每批数据新建 client/连接 → 每次都从慢启动冷启动
func pushBad(batches [][]byte) {
    for _, b := range batches {
        c := &http.Client{}                 // 新连接, 慢启动重来
        c.Post(url, "application/octet-stream", bytes.NewReader(b))
    }
}

// 正解: 复用 sharedClient, 连接池里的连接已"热", 长期高速
func pushGood(batches [][]byte) {
    for _, b := range batches {
        resp, _ := sharedClient.Post(url, "application/octet-stream", bytes.NewReader(b))
        if resp != nil {
            io.Copy(io.Discard, resp.Body)  // 读完 body, 连接才能回池复用(关键!)
            resp.Body.Close()               // 这里是"归还到池", 不是真关
        }
    }
}

// 大文件: 用一条持久连接流式传, 别拆成大量小连接各自慢启动
// 跨地域(高 RTT)更要复用; 必要时配合内核 initcwnd 调大初始窗口(治标)

这套骨架把我这次的教训钉死在了配置里:全局共享一个带连接池、启用 HTTP/2 的 client,让连接预热一次后被反复复用;每个响应都读完 body 再关,确保连接能回池继续用(而不是被丢弃重建);大文件用一条持久连接流式传。有了它,我的传输不再是"一群刚起步、还没热起来就被叫停的新手",而是"一条预热完毕、持续全速奔跑的老将"——那条曾经怎么也上不去的吞吐曲线,终于能稳稳贴着带宽上限跑了。把"珍惜并复用预热好的连接"这个道理,沉淀成一份默认就对的连接池配置,是我对这次事故最实在的交代。

写在最后

回头看,这场由"频繁短连接困在慢启动"引发的"带宽够却吞吐上不去"事故,真正教给我的,远不止"改用长连接"这一个技巧。它让我对"很多东西并不是'一建立/一启动就处于最佳状态'的; 它们需要一段'预热、磨合、试探'的过程, 才能逐渐进入高效的状态——而这份来之不易的'状态', 一旦因为我们频繁地'推倒重来'而无法保留、复用, 我们就会永远困在'反复预热、却从不享受预热成果'的低效里",有了一次刻骨的体会。我栽跟头,是因为我把'一个东西的起始状态'当成了'它的常态/最佳状态', 又通过频繁重建, 让它永远停留在那个低效的起始状态——我以为连接一建好就是满速的, 没意识到它要慢启动预热;更要命的是, 我频繁地建了又关、关了又建, 让每条连接都还没预热完就被我丢弃, 于是它们集体停留在"刚起步、最慢"的那一段, 我却纳闷"怎么总跑不快";我反复支付着"预热"的成本, 却从不给任何一条连接"预热完、好好跑一段"的机会。这让我领悟到一个关于"预热、状态保留与复用"的深刻认知:许多事物(连接、系统、缓存、人乃至团队)达到高效状态, 都需要一个'预热/磨合/积累'的过程, 起始状态往往是最低效的; 而这个被预热出来的'高效状态', 是一种有价值、且需要被保留和持续利用的资产;如果我们因为追求'简单'或'干净'而频繁地'推倒重建', 就会不断地丢弃这份预热好的状态、不断地从最低效的起点重新开始——结果是反复支付预热的代价, 却永远享受不到预热之后的高效;所以真正的高效, 往往不在于'每次都用一个全新的、干净的开始', 而在于'让一次预热的成果, 被尽可能长久、尽可能多地复用'——珍惜并复用'已经热起来的状态', 而非反复冷启动。这给了我一种看待"一切'反复创建与销毁某种有状态资源'之事"时的清醒:每当我倾向于"用完就扔、每次都新建一个干净的"时, 要追问"这个东西是一建立就处于最佳状态, 还是需要预热/磨合才能高效?如果需要预热, 那我频繁地重建, 是不是让它永远停在了最低效的起点、反复付着预热的代价却从不受益?"——对那些"需要预热、且预热成果有价值"的资源, 想办法保留并复用它预热好的状态(连接池、缓存保活、实例预留), 而不是图省事反复冷启动;"识别需要预热的资源、保留并复用其预热成果而非反复冷启动", 是榨干性能、也是用好一切'有状态资源'的关键。认清 TCP 慢启动让新连接需预热、频繁短连接困在低速期、复用长连接才能长期高速——这,是我用一次带宽够却吞吐上不去的事故,换来的、关于网络、也关于如何看待预热与复用的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次做大量数据传输、顺手"每次新建个连接传一下"时,先想想"新连接还在慢启动预热呢,我是不是该复用一条热连接?",并果断换上长连接或连接池,那我对着那条"带宽明明够、吞吐就是上不去"的曲线折腾的大半天,就值了。

—— 别看了 · 2026