TCP incast（多對一同步壅塞崩潰）
想像一位老師問三十名學生一個問題，並要他們在同一瞬間交答案。三十隻手同時把紙塞向一個小小的收件盒；它滿出來、紙掉到地上，老師只好等每張掉落的重寫。因為大家都同步了，這個堵塞比答案陸續交來糟得多。TCP incast 就是資料中心內這種一模一樣的堆積：許多伺服器在同一時刻都回覆同一個請求者，把交換器緩衝區塞爆，觸發傳輸量的崩潰。
具體來說，incast 來自一個常見的資料中心型態：一個請求被分散給許多伺服器（一次分散式儲存讀取、一個切分到多個分片的搜尋查詢、一次 MapReduce 洗牌），而它們幾乎同時把回應送回單一請求者。這許多同步的資料流匯聚到同一個交換器埠——通往請求者的最後一跳——瞬間塞爆它又小又快的緩衝區，於是封包被丟棄。每個傳送者接著得等一個 TCP 重送逾時（RTO）才察覺遺失。殘酷之處在於：資料中心的往返時間以微秒計，但最小 RTO 常大上數百倍（歷史上約 200 毫秒），於是一個小小的緩衝區溢位，就以資料中心的標準把整個傳輸卡上一個永恆般的時間，總傳輸量因此崩潰——儘管網路大多是閒置的。
為什麼重要：incast 是資料中心的招牌病徵，肇因於多對一同步突發、淺薄的交換器緩衝區、以及為廣域網際網路調校的 TCP 遺失復原三者之間的錯配。各種緩解措施攻擊不同部分：降低最小 RTO、改用細粒度（微秒級）計時器；讓應用程式錯開或限制同時回應者的數量；使用更大或更聰明的緩衝區；以及採用像 DCTCP 這種以延遲為重的壅塞控制，在緩衝區溢位「之前」就對早期壅塞訊號（ECN 標記）反應。誠實的說法是：與其說 incast 是 TCP 的臭蟲，不如說是 TCP 的廣域假設與資料中心極小 RTT 及同步工作負載相撞的結果。
一個儲存用戶端要讀一個切分在 40 台伺服器上的檔案，並同時向全部 40 台索取。它們的回應一起抵達用戶端機架頂端交換器的埠、塞爆它的緩衝區，數個封包被丟。每台受影響的伺服器現在得等整整一個 RTO——比方說 200 毫秒——才重送，儘管實際往返遠不到一毫秒。這一次讀取耗時極久，網路卻幾乎是空的。
同步的多對一回應塞爆一個緩衝區；隨之而來的是一段 RTO 卡頓。
incast 並非肇因於頻寬不足——網路大多是閒置的。它的肇因是同步突發塞爆淺薄緩衝區，加上一個粗糙的 RTO，其值是資料中心微秒級 RTT 的數百倍。修正手段針對的是同步、緩衝區與計時器——而不是連結速度。