TCP 協議有擁塞控制策略， 網路為什麼還會發生擁塞崩潰？
我們單位一個電影伺服器對外網開放下載以後，經常到外網就直接不通了（是真的崩潰了，路由器都ping不通，所有的外網網站都打不開），我懷疑是外網下電影的人太多流量太大導致的，外網也是自己人，沒有網路攻擊什麼的，我把到外網的出口路由器的網線拔掉7、8秒後又插上，到外網的網路就會恢復正常。這種現象是不是網路擁塞導致的網路崩潰？如果是，那麼TCP協議既然有擁塞控制策略，為什麼還會發生擁塞崩潰？還有這種現象該如何避免？
TCP的擁塞控制策略是：假如TCP源端發現超時或收到3個相同ACK副本時，即認為網路發生了擁塞（主要因為由傳輸引起的數據包損壞和丟失的概率很小（&<&<1%））。此時就進入擁塞避免階段。慢啟動閾值（ssthresh）被設置為當前擁塞窗口大小的一半；假如超時，擁塞窗口被置1。假如cwnd&>ssthresh，TCP就執行擁塞避免演算法，此時，cwnd在每次收到一個ACK時只增加1/cwnd個數據包，這樣，在一個RTT內，cwnd將增加1，所以在擁塞避免階段，cwnd不是呈指數增長，而是線性增長。 資料引用:TCP協議的擁塞控制策略及改進
我覺得這個擁塞控制策略很好呀，為什麼還能夠擁塞到這個程度？
TCP流量控制、擁塞控制機制是只對TCP流量起作用，對其他的流量 UDP/ICMP/GRE/ESP/multicast 起不到約束作用，丟棄對於他們來說，該發多少還是多少，我行我素。一般視頻、音頻都是用UDP來實時傳輸的，帶寬需求也大，很容易把帶寬擠滿，把路由器的出口隊列塞滿。
對於TCP很多session來說，他們是競爭關係，帶寬充足時，發送速率翻倍向上增長，使自己的TCP連接速率最大化，等到擁塞時，發現不行了，速率開始指數下降，在下降的過程中，總有一些TCP session 受到的影響比較小，或者它的流量本來就比較少，沒有受到丟包的影響，在別人發送速率下降的時候，而它卻啟動了速率上升的機制，恰恰填滿了別的TCP session 留下的帶寬的空白，於是網路出口的帶寬一直是100%，出口的隊列也一直是滿的。擁塞控制只是針對TCP的，只是一種自我約束。像UDP等協議就不會遵守擁塞控制。而現在的迅雷、在線視頻、網遊等佔用帶寬的罪魁禍首大量使用UDP協議，都是一窩蜂地作死發數據，哪來的擁塞控制。
舉個例子，大家在排隊買東西，UDP就是插隊者，不停地往前擠。而TCP就是謙謙君子，一旦發現人多，就自覺地往後退（擁塞控制），看見有人插隊也不做聲。於是，你猜結局如何？
擁塞控制只對單線程的
在雙線程情況下
單線程擁塞了 另一條馬上就補上了
線程越多補的速度也就越快。
謝邀。
其實我在這方面經驗並不多，僅從理論上分析一下，不準確之處歡迎指正。
我覺得這個和TCP協議的擁塞控制關係不大。就像王丹的答案中說的，TCP的擁塞控制主要針對單條TCP連接的傳輸速率控制。而現在你們面對的問題更多的是和並發連接數以及總傳輸速率有關係。而且ping發送的ICMP數據包是在網路層（IP協議那層），在傳輸層（TCP協議那層）的下面，不受TCP擁塞控制策略控制。
我覺得你應該檢查一下路由器的負載和緩存使用情況。
如圖，當緩存已滿的時候，新到達的數據包便會被丟棄。
所以，當數據包到達速率lambda &>= 連接帶寬R的時候，平均隊列遲延便會接近無限高。
而當外網網線被拔出之後，大量緩存中數據包發送失敗，依照緩存策略，可能被清除出緩存，所以再次連接網線之後網路恢復正常。
至於為什麼設計有擁塞控制策略的網路還會擁塞到這個程度，是因為互聯網被設計為分組交換（packet switching），而不是電路交換（circuit switching）。所以如何給影音流之類的應用提供帶寬保證仍然是未解決的問題。
references:- James F. Kurose, Keith W. Ross: Computer Networking: A Top-Down Approach, 6e
tcp流控是每個流自己控制的，而控制啟動到起作用有時延。你終端降速以後，5跳以外的路由器要等會兒才感受到流量降低。
流太多，每個終端到某個特定路由器的遠近距離不同。
於是導致了測不準，測得路由器上當前不擁塞，但當你的包到達路由器的時候卻偏偏擁塞了。反之亦然。
統計學分析會給出更恰當的模型，但短時發生擁塞是不可避免的題主講的這種情況很可能是因為路由器支持nat的會話數達到上限或者會話太多了cpu忙不過來導致的
這就好比是在問：「為什麼我們有道路交通法規，還會出現塞車？」--情況1、只是你守交規，但是有別人不守規則，比如UDP就是不做擁塞控制的。情況2、車多到一定程度，擁塞控制也避免不了堵車，IP網路本來就是儘力而為的，所以有時候「臣妾實在做不到啊」，比如鏈路利用率100%，NAT session數滿了等等。
因為目前大部分的TCP擁塞演算法都有問題。假設網路上只有TCP流量，TCP的擁塞演算法是讓它的發送窗口逐漸增長，發送的數據越來越多，超過網路的容量後丟包，超時重傳，降低擁塞窗口，然後又逐漸增長，不斷循環，形成醜陋的鋸齒狀。總結來說，大部分TCP的擁塞演算法通過製造擁塞來感受擁塞。
TCP的擁塞控制主要是針對TCP的，但是網路中的數據還有很多非TCP協議的。另當介面帶寬被佔滿以後，任何的擁塞控制都不生效了！
TCP只是會話過程中自我約束了，網路的buffer是萬惡之源。但是誰也免不了惡的，所以加速啊、多連接、多線程下這些就是守規矩的作惡。
因為協議不是只有tcp
你把路修的再寬看看會不會堵車?
推薦閱讀：
※TCP/IP: 在廣域網（外網）上傳輸數據時會用到ARP協議嗎？
※tcp 的可靠性到底指的是什麼？
※ospf處在哪個tcp/ip的層次，是不是傳輸層，網上說tcp/ip不夠嚴謹，那麼對於osi呢？
※IP報文的目的IP地址是私有IP地址，網路層如何處理的？
※智能DNS解析？