壅塞崩潰（congestion collapse）
想像驚慌人群中的一道窄門。越多人往前擠，就卡得越死，最後幾乎沒人能通過，儘管每個人都使盡全力推。壅塞崩潰（congestion collapse）就是網路版的那道窄門：一種被提交的負載極大、但實際送達的有用工作量卻趨近於零的狀態，因為網路忙著搬運那些其實永遠不會抵達的流量。
機制是這樣的。當路由器超載，它們的緩衝區塞滿，便開始丟棄封包。遺失封包的傳送端會重送——但如果傳送端不放慢，它只是往本已堵死的網路裡塞進更多封包，引發更多丟棄、更多重送。那些勉強擠過去的封包往往來得太晚，在它們的傳送端早已放棄並重送之後才到，於是網路把寶貴的容量花在送達一份份終將被丟掉的重複副本上。連結 100% 忙碌，卻幾乎送不出任何新的、有用的資料。這並非假設：1986 年 10 月，早期網際網路上柏克萊各據點之間的一段，從正常的 32 kbps 崩跌到約 40 bps——足足下降千倍——正是這件事促使 Van Jacobson 發明了 TCP 至今仍在使用的慢啟動與壅塞避免演算法。
解藥正是壅塞控制：傳送端必須把遺失當成放慢的信號，而不是更快重送的理由。現代 TCP 的加法增大／乘法減小行為、慢啟動、以及帶退避的計時器，全都是為了讓網路遠離這個陷阱而存在。今天崩潰之所以罕見，正是因為幾乎每個傳送端都遵守那些規則——這也是為什麼一群無視規則的傳送端（某些攻擊，或寫得很糟的軟體）至今仍然危險。
假設每個傳送端都用固定逾時、對任何未被確認的封包就重送、從不放慢。一個小小的超載造成幾次丟棄；大家都重送；多出來的封包造成更多丟棄；大家又再重送。幾秒之內，連結就被那些大多已經過時的資料的重送所塞滿，而有效傳輸量（goodput，真正送達的有用位元組）即使在線路全速運轉下也直墜谷底。
連結可以完全忙碌卻幾乎送不出任何有用的東西——負載與有效傳輸量之間的那道落差，正是崩潰的特徵。
壅塞崩潰指的是有用傳輸量崩潰，而不是連結變得閒置——線路自始至終都是滿載的。要把它和單純的「慢」區分開：崩潰是一種病態的回饋迴圈，本來放慢就能解決，大家卻反而加速。