TCP協議解析

阿新 • • 發佈：2019-02-07

TCP是一個巨複雜的協議，因為它要解決很多問題，而這些問題又帶出了很多子問題和陰暗面。所以學習TCP本身是個比較痛苦的過程，但對於學習的過程卻能讓人有很多收穫。關於TCP這個協議的細節，我還是推薦你去看W.Richard Stevens的《TCP/IP詳解卷1：協議》（當然，你也可以去讀一下RFC793以及後面N多的RFC）。另外，本文我會使用英文術語，這樣方便你通過這些英文關鍵詞來查詢相關的技術文件。

之所以想寫這篇文章，目的有三個，

一個是想鍛鍊一下自己是否可以用簡單的篇幅把這麼複雜的TCP協議描清楚的能力。
另一個是覺得現在的好多程式設計師基本上不會認認真真地讀本書，喜歡快餐文化，所以，希望這篇快餐文章可以讓你對TCP這個古典技術有所瞭解，並能體會到軟體設計中的種種難處。並且你可以從中有一些軟體設計上的收穫。
最重要的希望這些基礎知識可以讓你搞清很多以前一些似是而非的東西，並且你能意識到基礎的重要。

所以，本文不會面面俱到，只是對TCP協議、演算法和原理的科普。

我本來只想寫一個篇幅的文章的，但是TCP真的很複雜，比C++複雜多了，這30多年來，各種優化變種爭論和修改。所以，寫著寫著就發現只有砍成兩部分。

上半部分中，主要向你介紹TCP協議的定義和丟包時的重傳機制。
下半部分中，重點介紹TCP的流迭、擁塞處理。

廢話少說，首先，我們需要知道TCP在網路OSI的七層模型中的第四層——Transport層，IP在第三層——Network層，ARP在第二層——Data Link層。在第二層上的資料，我們叫Frame，在第三層上的資料叫Packet，第四層的資料叫Segment。

首先，我們需要知道，我們程式的資料首先會打到TCP的Segment中，然後TCP的Segment會打到IP的Packet中，然後再打到乙太網Ethernet的Frame中，傳到對端後，各個層解析自己的協議，然後把資料交給更高層的協議處理。

TCP頭格式

接下來，我們來看一下TCP頭的格式

TCP頭格式

你需要注意這麼幾點：

TCP的包是沒有IP地址的，那是IP層上的事，但是有源埠和目標埠。
一個TCP連線需要四個元組來表示是同一個連線（src_ip, src_port, dst_ip, dst_port）準確說是五元組，還有一個是協議。但因為這裡只是說TCP協議，所以，這裡我只說四元組。
注意上圖中的四個非常重要的東西：
- Sequence Number是包的序號，用來解決網路包亂序（reordering）問題。
- Acknowledgement Number就是ACK——用於確認收到，用來解決不丟包的問題。
- Window又叫Advertised-Window，也就是著名的滑動視窗（Sliding Window），用於解決流控的。
- TCP Flag ，也就是包的型別，主要是用於操控TCP的狀態機的。

關於其它的東西，可以參看下面的圖示

TCP的狀態機

其實，網路上的傳輸是沒有連線的，包括TCP也是一樣的。而TCP所謂的“連線”，其實只不過是在通訊的雙方維護一個“連線狀態”，讓它看上去好像有連線一樣。所以，TCP的狀態變換是非常重要的。

下面是：“TCP協議的狀態機” 和 “TCP建立連結”、“TCP斷開連結”、“傳輸資料” 的對照圖，我把兩個圖並排放在一起，這樣方便在你對照著看。另外，下面這兩個圖非常非常的重要，你一定要記牢。（吐個槽：看到這樣複雜的狀態機，就知道這個協議有多複雜，複雜的東西總是有很多坑爹的事情，所以TCP協議其實也挺坑爹的）

很多人會問，為什麼建立連結要3次握手，斷開連結需要4次揮手？

對於建立連結的3次握手，主要是要初始化Sequence Number 的初始值。通訊的雙方要互相通知對方自己的初始化的Sequence Number（縮寫為ISN：Inital Sequence Number）——所以叫SYN，全稱Synchronize Sequence Numbers。也就上圖中的 x 和 y。這個號要作為以後的資料通訊的序號，以保證應用層接收到的資料不會因為網路上的傳輸的問題而亂序（TCP會用這個序號來拼接資料）。

對於4次揮手，其實你仔細看是2次，因為TCP是全雙工的，所以，傳送方和接收方都需要Fin和Ack。只不過，有一方是被動的，所以看上去就成了所謂的4次揮手。如果兩邊同時斷連線，那就會就進入到CLOSING狀態，然後到達TIME_WAIT狀態。下圖是雙方同時斷連線的示意圖（你同樣可以對照著TCP狀態機看）：

兩端同時斷連線

另外，有幾個事情需要注意一下：

關於建立連線時SYN超時。試想一下，如果server端接到了clien發的SYN後回了SYN-ACK後 client掉線了，server端沒有收到client回來的ACK，那麼，這個連線處於一箇中間狀態，即沒成功，也沒失敗。於是，server端如果在一定時間內沒有收到的TCP會重發SYN-ACK。在Linux下，預設重試次數為5次，重試的間隔時間從1s開始每次都翻售，5次的重試時間間隔為 1s, 2s, 4s, 8s, 16s，總共31s，第5次發出後還要等32s都知道第5次也超時了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才會把斷開這個連線。

關於SYN Flood攻擊。一些惡意的人就為此製造了SYN Flood攻擊——給伺服器發了一個SYN後，就下線了，於是伺服器需要預設等63s才會斷開連線，這樣，攻擊者就可以把伺服器的syn連線的佇列耗盡，讓正常的連線請求不能處理。於是，Linux下給了一個叫tcp_syncookies的引數來應對這個事——當SYN佇列滿了後，TCP會通過源地址埠、目標地址埠和時間戳打造出一個特別的Sequence Number發回去（又叫cookie），如果是攻擊者則不會有響應，如果是正常連線，則會把這個 SYN Cookie發回來，然後服務端可以通過cookie建連線（即使你不在SYN佇列中）。請注意，請先千萬別用tcp_syncookies來處理正常的大負載的連線的情況。因為，synccookies是妥協版的TCP協議，並不嚴謹。對於正常的請求，你應該調整三個TCP引數可供你選擇，第一個是：tcp_synack_retries 可以用他來減少重試次數；第二個是：tcp_max_syn_backlog，可以增大SYN連線數；第三個是：tcp_abort_on_overflow 處理不過來乾脆就直接拒絕連線了。

關於ISN的初始化。ISN是不能hard code的，不然會出問題的——比如：如果連線建好後始終用1來做ISN，如果client發了30個segment過去，但是網路斷了，於是 client重連，又用了1做ISN，但是之前連線的那些包到了，於是就被當成了新連線的包，此時，client的Sequence Number 可能是3，而Server端認為client端的這個號是30了。全亂了。RFC793中說，ISN會和一個假的時鐘綁在一起，這個時鐘會在每4微秒對ISN做加一操作，直到超過2^32，又從0開始。這樣，一個ISN的週期大約是4.55個小時。因為，我們假設我們的TCP Segment在網路上的存活時間不會超過Maximum Segment Lifetime（縮寫為MSL），所以，只要MSL的值小於4.55小時，那麼，我們就不會重用到ISN。

關於 MSL 和 TIME_WAIT。通過上面的ISN的描述，相信你也知道MSL是怎麼來的了。我們注意到，在TCP的狀態圖中，從TIME_WAIT狀態到CLOSED狀態，有一個超時設定，這個超時設定是 2*MSL（RFC793定義了MSL為2分鐘，Linux設定成了30s）為什麼要這有TIME_WAIT？為什麼不直接給轉成CLOSED狀態呢？主要有兩個原因：1）TIME_WAIT確保有足夠的時間讓對端收到了ACK，如果被動關閉的那方沒有收到Ack，就會觸發被動端重發Fin，一來一去正好2個 MSL，2）有足夠的時間讓這個連線不會跟後面的連線混在一起（你要知道，有些自做主張的路由器會快取IP資料包，如果連線被重用了，那麼這些延遲收到的包就有可能會跟新連線混在一起）。你可以看看這篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems》

關於TIME_WAIT數量太多。從上面的描述我們可以知道，TIME_WAIT是個很重要的狀態，但是如果在大併發的短連結下，TIME_WAIT 就會太多，這也會消耗很多系統資源。只要搜一下，你就會發現，十有八九的處理方式都是教你設定兩個引數，一個叫tcp_tw_reuse，另一個叫tcp_tw_recycle的引數，這兩個引數預設值都是被關閉的，後者recyle比前者resue更為激進，resue要溫柔一些。另外，如果使用tcp_tw_reuse，必需設定tcp_timestamps=1，否則無效。這裡，你一定要注意，開啟這兩個引數會有比較大的坑——可能會讓TCP連接出一些詭異的問題（因為如上述一樣，如果不等待超時重用連線的話，新的連線可能會建不上。正如官方文件上說的一樣“It should not be changed without advice/request of technical experts”）。

關於tcp_tw_reuse。官方文件上說tcp_tw_reuse 加上tcp_timestamps（又叫PAWS, for Protection Against Wrapped Sequence Numbers）可以保證協議的角度上的安全，但是你需要tcp_timestamps在兩邊都被開啟（你可以讀一下tcp_twsk_unique的原始碼）。我個人估計還是有一些場景會有問題。

關於tcp_tw_recycle。如果是tcp_tw_recycle被打開了話，會假設對端開啟了 tcp_timestamps，然後會去比較時間戳，如果時間戳變大了，就可以重用。但是，如果對端是一個NAT網路的話（如：一個公司只用一個IP出公網）或是對端的IP被另一臺重用了，這個事就複雜了。建連結的SYN可能就被直接丟掉了（你可能會看到connection time out的錯誤）（如果你想觀摩一下Linux的核心程式碼，請參看原始碼 tcp_timewait_state_process）。

關於tcp_max_tw_buckets。這個是控制併發的TIME_WAIT的數量，預設值是180000，如果超限，那麼，系統會把多的給destory掉，然後在日誌裡打一個警告（如：time wait bucket table overflow），官網文件說這個引數是用來對抗DDoS攻擊的。也說的預設值180000並不小。這個還是需要根據實際情況考慮。

Again，使用tcp_tw_reuse和tcp_tw_recycle來解決TIME_WAIT的問題是非常非常危險的，因為這兩個引數違反了TCP協議（RFC 1122）

其實，TIME_WAIT表示的是你主動斷連線，所以，這就是所謂的“不作死不會死”。試想，如果讓對端斷連線，那麼這個破問題就是對方的了，呵呵。另外，如果你的伺服器是於HTTP伺服器，那麼設定一個HTTP的KeepAlive有多重要（瀏覽器會重用一個TCP連線來處理多個HTTP請求），然後讓客戶端去斷連結（你要小心，瀏覽器可能會非常貪婪，他們不到萬不得已不會主動斷連線）。

資料傳輸中的Sequence Number

下圖是我從Wireshark中截了個我在訪問coolshell.cn時的有資料傳輸的圖給你看一下，SeqNum是怎麼變的。（使用Wireshark選單中的Statistics ->Flow Graph… ）

你可以看到，SeqNum的增加是和傳輸的位元組數相關的。上圖中，三次握手後，來了兩個Len:1440的包，而第二個包的SeqNum就成了1441。然後第一個ACK回的是1441，表示第一個1440收到了。

注意：如果你用Wireshark抓包程式看3次握手，你會發現SeqNum總是為0，不是這樣的，Wireshark為了顯示更友好，使用了Relative SeqNum——相對序號，你只要在右鍵選單中的protocol preference 中取消掉就可以看到“Absolute SeqNum”了

TCP重傳機制

TCP要保證所有的資料包都可以到達，所以，必需要有重傳機制。

注意，接收端給傳送端的Ack確認只會確認最後一個連續的包，比如，傳送端發了1,2,3,4,5一共五份資料，接收端收到了1，2，於是回ack 3，然後收到了4（注意此時3沒收到），此時的TCP會怎麼辦？我們要知道，因為正如前面所說的，SeqNum和Ack是以位元組數為單位，所以ack的時候，不能跳著確認，只能確認最大的連續收到的包，不然，傳送端就以為之前的都收到了。

超時重傳機制

一種是不回ack，一直等待3，當傳送方發現收不到3的ack超時後，會重傳3。一旦接收方收到3後，ack回傳4——意味著3和4都收到了。

但是，這種方式會有比較嚴重的問題，那就是因為要死等3，所以會導致4和5即便已經收到了，而傳送方也完全不知道發生了什麼事，因為沒有收到Ack，所以，傳送方可能會悲觀地認為也丟了，所以有可能也會導致4和5的重傳。

對此有兩種選擇：

一種是僅重傳timeout的包。也就是第3份資料。
另一種是重傳timeout後所有的資料，也就是第3，4，5這三份資料。

這兩種方式有好也有不好。第一種會節省頻寬，但是慢，第二種會快一點，但是會浪費頻寬，也可能會有無用功。但總體來說都不好。因為都在等timeout，timeout可能會很長（在下篇會說TCP是怎麼動態地計算出timeout的）

快速重傳機制

於是，TCP引入了一種叫Fast Retransmit 的演算法，不以時間驅動，而以資料驅動重傳。也就是說，如果，包沒有連續到達，就ack最後那個可能被丟了的包，如果傳送方連續收到3次相同的ack，就重傳。Fast Retransmit的好處是不用等timeout了再重傳。

比如：如果傳送方發出了1，2，3，4，5份資料，第一份先到送了，於是就ack回2，結果2因為某些原因沒收到，3到達了，於是還是ack回2，後面的4和5都到了，但是還是ack回2，因為2還是沒有收到，於是傳送端收到了三個ack=2的確認，知道了2還沒有到，於是就馬上重轉2。然後，接收端收到了2，此時因為3，4，5都收到了，於是ack回6。示意圖如下：

Fast Retransmit只解決了一個問題，就是timeout的問題，它依然面臨一個艱難的選擇，就是重轉之前的一個還是重灌所有的問題。對於上面的示例來說，是重傳#2呢還是重傳#2，#3，#4，#5呢？因為傳送端並不清楚這連續的3個ack(2)是誰傳回來的？也許傳送端發了20份數據，是#6，#10，#20傳來的呢。這樣，傳送端很有可能要重傳從2到20的這堆資料（這就是某些TCP的實際的實現）。可見，這是一把雙刃劍。

SACK 方法

另外一種更好的方式叫：Selective Acknowledgment (SACK)（參看RFC 2018），這種方式需要在TCP頭裡加一個SACK的東西，ACK還是Fast Retransmit的ACK，SACK則是彙報收到的資料碎版。參看下圖：

這樣，在傳送端就可以根據回傳的SACK來知道哪些資料到了，哪些沒有到。於是就優化了Fast Retransmit的演算法。當然，這個協議需要兩邊都支援。在 Linux下，可以通過tcp_sack引數開啟這個功能（Linux 2.4後預設開啟）。

這裡還需要注意一個問題——接收方Reneging，所謂Reneging的意思就是接收方有權把已經報給傳送端SACK裡的資料給丟了。這樣幹是不被鼓勵的，因為這個事會把問題複雜化了，但是，接收方這麼做可能會有些極端情況，比如要把記憶體給別的更重要的東西。所以，傳送方也不能完全依賴SACK，還是要依賴ACK，並維護Time-Out，如果後續的ACK沒有增長，那麼還是要把SACK的東西重傳，另外，接收端這邊永遠不能把SACK的包標記為Ack。

注意：SACK會消費傳送方的資源，試想，如果一個攻擊者給資料傳送方發一堆SACK的選項，這會導致傳送方開始要重傳甚至遍歷已經發出的資料，這會消耗很多傳送端的資源。詳細的東西請參看《TCP SACK的效能權衡》

Duplicate SACK – 重複收到資料的問題

Duplicate SACK又稱D-SACK，其主要使用了SACK來告訴傳送方有哪些資料被重複接收了。RFC-2833 裡有詳細描述和示例。下面舉幾個例子（來源於RFC-2833）

D-SACK使用了SACK的第一個段來做標誌，

如果SACK的第一個段的範圍被ACK所覆蓋，那麼就是D-SACK

如果SACK的第一個段的範圍被SACK的第二個段覆蓋，那麼就是D-SACK

示例一：ACK丟包

下面的示例中，丟了兩個ACK，所以，傳送端重傳了第一個資料包（3000-3499），於是接收端發現重複收到，於是回了一個 SACK=3000-3500，因為ACK都到了4000意味著收到了4000之前的所有資料，所以這個SACK就是D-SACK——旨在告訴傳送端我收到了重複的資料，而且我們的傳送端還知道，資料包沒有丟，丟的是ACK包。

TransmittedReceived ACK Sent
SegmentSegment(Including SACK Blocks)
3000-34993000-34993500(ACK dropped)
3500-39993500-39994000(ACK dropped)
3000-34993000-34994000, SACK=3000-3500
---------

示例二，網路延誤

下面的示例中，網路包（1000-1499）被網路給延誤了，導致傳送方沒有收到ACK，而後面到達的三個包觸發了“Fast Retransmit演算法”，所以重傳，但重傳時，被延誤的包又到了，所以，回了一個SACK=1000-1500，因為ACK已到了3000，所以，這個SACK是D-SACK——標識收到了重複的包。

這個案例下，傳送端知道之前因為“Fast Retransmit演算法”觸發的重傳不是因為發出去的包丟了，也不是因為迴應的ACK包丟了，而是因為網路延時了。

TransmittedReceived ACK Sent
SegmentSegment(Including SACK Blocks)
500-999500-9991000
1000-1499(delayed)
1500-19991500-19991000, SACK=1500-2000
2000-24992000-24991000, SACK=1500-2500
2500-29992500-29991000, SACK=1500-3000
1000-14991000-14993000
1000-14993000, SACK=1000-1500
---------

可見，引入了D-SACK，有這麼幾個好處：

1）可以讓傳送方知道，是發出去的包丟了，還是回來的ACK包丟了。

2）是不是自己的timeout太小了，導致重傳。

3）網路上出現了先發的包後到的情況（又稱reordering）

4）網路上是不是把我的資料包給複製了。

知道這些東西可以很好得幫助TCP瞭解網路情況，從而可以更好的做網路上的流控。

Linux下的tcp_dsack引數用於開啟這個功能（Linux 2.4後預設開啟）。

TCP的RTT演算法

從前面的TCP重傳機制我們知道Timeout的設定對於重傳非常重要。

設長了，重發就慢，丟了老半天才重發，沒有效率，效能差；
設短了，會導致可能並沒有丟就重發。於是重發的就快，會增加網路擁塞，導致更多的超時，更多的超時導致更多的重發。

而且，這個超時時間在不同的網路的情況下，根本沒有辦法設定一個死的值。只能動態地設定。為了動態地設定，TCP引入了RTT——Round Trip Time，也就是一個數據包從發出去到回來的時間。這樣傳送端就大約知道需要多少的時間，從而可以方便地設定Timeout—— RTO（Retransmission TimeOut），以讓我們的重傳機制更高效。聽起來似乎很簡單，好像就是在傳送端發包時記下t0，然後接收端再把這個ack回來時再記一個t1，於是RTT = t1 – t0。沒那麼簡單，這只是一個取樣，不能代表普遍情況。

經典演算法

RFC793 中定義的經典演算法是這樣的：

1）首先，先採樣RTT，記下最近好幾次的RTT值。

2）然後做平滑計算SRTT（ Smoothed RTT）。公式為：（其中的 α 取值在0.8 到 0.9之間，這個演算法英文叫Exponential weighted moving average，中文叫：加權移動平均）

SRTT = ( α * SRTT ) + ((1- α) * RTT)

3）開始計算RTO。公式如下：

RTO = min [ UBOUND, max [ LBOUND, (β * SRTT) ] ]

其中：

UBOUND是最大的timeout時間，上限值
LBOUND是最小的timeout時間，下限值
β 值一般在1.3到2.0之間。

Karn / Partridge 演算法

但是上面的這個演算法在重傳的時候會出有一個終極問題——你是用第一次發資料的時間和ack回來的時間做RTT樣本值，還是用重傳的時間和ACK回來的時間做RTT樣本值？

這個問題無論你選那頭都是按下葫蘆起了瓢。如下圖所示：

情況（a）是ack沒回來，所以重傳。如果你計算第一次傳送和ACK的時間，那麼，明顯算大了。
情況（b）是ack回來慢了，但是導致了重傳，但剛重傳不一會兒，之前ACK就回來了。如果你是算重傳的時間和ACK回來的時間的差，就會算短了。

所以1987年的時候，搞了一個叫Karn / Partridge Algorithm，這個演算法的最大特點是——忽略重傳，不把重傳的RTT做取樣（你看，你不需要去解決不存在的問題）。

但是，這樣一來，又會引發一個大BUG——如果在某一時間，網路閃動，突然變慢了，產生了比較大的延時，這個延時導致要重轉所有的包（因為之前的RTO很小），於是，因為重轉的不算，所以，RTO就不會被更新，這是一個災難。於是Karn演算法用了一個取巧的方式——只要一發生重傳，就對現有的RTO值翻倍（這就是所謂的 Exponential backoff），很明顯，這種死規矩對於一個需要估計比較準確的RTT也不靠譜。

Jacobson / Karels 演算法

前面兩種演算法用的都是“加權移動平均”，這種方法最大的毛病就是如果RTT有一個大的波動的話，很難被發現，因為被平滑掉了。所以，1988年，又有人推出來了一個新的演算法，這個演算法叫Jacobson / Karels Algorithm（參看RFC6289）。這個演算法引入了最新的RTT的取樣和平滑過的SRTT的差距做因子來計算。公式如下：（其中的DevRTT是Deviation RTT的意思）

SRTT = SRTT + α (RTT – SRTT) —— 計算平滑RTT

DevRTT = (1-β)*DevRTT + β*(|RTT-SRTT|) ——計算平滑RTT和真實的差距（加權移動平均）

RTO= µ * SRTT + ∂ *DevRTT —— 神一樣的公式

（其中：在Linux下，α = 0.125，β = 0.25， μ = 1，∂ = 4 ——這就是演算法中的“調得一手好引數”，nobody knows why, it just works…）最後的這個演算法在被用在今天的TCP協議中（Linux的原始碼在：tcp_rtt_estimator）。

TCP滑動視窗

需要說明一下，如果你不瞭解TCP的滑動視窗這個事，你等於不瞭解TCP協議。我們都知道，TCP必需要解決的可靠傳輸以及包亂序（reordering）的問題，所以，TCP必需要知道網路實際的資料處理頻寬或是資料處理速度，這樣才不會引起網路擁塞，導致丟包。

所以，TCP引入了一些技術和設計來做網路流控，Sliding Window是其中一個技術。前面我們說過，TCP頭裡有一個欄位叫Window，又叫Advertised-Window，這個欄位是接收端告訴傳送端自己還有多少緩衝區可以接收資料。於是傳送端就可以根據這個接收端的處理能力來發送資料，而不會導致接收端處理不過來。為了說明滑動視窗，我們需要先看一下TCP緩衝區的一些資料結構：

上圖中，我們可以看到：

接收端LastByteRead指向了TCP緩衝區中讀到的位置，NextByteExpected指向的地方是收到的連續包的最後一個位置，LastByteRcved指向的是收到的包的最後一個位置，我們可以看到中間有些資料還沒有到達，所以有資料空白區。
傳送端的LastByteAcked指向了被接收端Ack過的位置（表示成功傳送確認），LastByteSent表示發出去了，但還沒有收到成功確認的Ack，LastByteWritten指向的是上層應用正在寫的地方。

於是：

接收端在給傳送端回ACK中會彙報自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;
而傳送方會根據這個視窗來控制傳送資料的大小，以保證接收方可以處理。

下面我們來看一下發送方的滑動視窗示意圖：

上圖中分成了四個部分，分別是：（其中那個黑模型就是滑動視窗）

#1已收到ack確認的資料。
#2發還沒收到ack的。
#3在視窗中還沒有發出的（接收方還有空間）。
#4視窗以外的資料（接收方沒空間）

下面是個滑動後的示意圖（收到36的ack，併發出了46-51的位元組）：

下面我們來看一個接受端控制傳送端的圖示：

Zero Window

上圖，我們可以看到一個處理緩慢的Server（接收端）是怎麼把Client（傳送端）的 TCP Sliding Window給降成0的。此時，你一定會問，如果Window變成0了，TCP會怎麼樣？是不是傳送端就不發資料了？是的，傳送端就不發資料了，你可以想像成“Window Closed”，那你一定還會問，如果傳送端不發資料了，接收方一會兒Window size 可用了，怎麼通知傳送端呢？

解決這個問題，TCP使用了Zero Window Probe技術，縮寫為ZWP，也就是說，傳送端在視窗變成0後，會發ZWP的包給接收方，讓接收方來ack他的Window尺寸，一般這個值會設定成3 次，第次大約30-60秒（不同的實現可能會不一樣）。如果3次過後還是0的話，有的TCP實現就會發RST把連結斷了。

注意：只要有等待的地方都可能出現DDoS攻擊，Zero Window也不例外，一些攻擊者會在和HTTP建好鏈發完GET請求後，就把Window設定為0，然後服務端就只能等待進行ZWP，於是攻擊者會併發大量的這樣的請求，把伺服器端的資源耗盡。（關於這方面的攻擊，大家可以移步看一下Wikipedia的SockStress詞條）

另外，Wireshark中，你可以使用tcp.analysis.zero_window來過濾包，然後使用右鍵選單裡的follow TCP stream，你可以看到ZeroWindowProbe及ZeroWindowProbeAck的包。

Silly Window Syndrome

Silly Window Syndrome翻譯成中文就是“糊塗視窗綜合症”。正如你上面看到的一樣，如果我們的接收方太忙了，來不及取走Receive Windows裡的資料，那麼，就會導致傳送方越來越小。到最後，如果接收方騰出幾個位元組並告訴傳送方現在有幾個位元組的window，而我們的傳送方會義無反顧地傳送這幾個位元組。

要知道，我們的TCP+IP頭有40個位元組，為了幾個位元組，要達上這麼大的開銷，這太不經濟了。

另外，你需要知道網路上有個MTU，對於乙太網來說，MTU是1500位元組，除去TCP+IP頭的40個位元組，真正的資料傳輸可以有1460，這就是所謂的MSS（Max Segment Size）注意，TCP的RFC定義這個MSS的預設值是536，這是因為IP裝置都得最少接收576尺寸的大小（實際上來說576是撥號的網路的MTU，而576減去IP頭的20個位元組就是536）。

如果你的網路包可以塞滿MTU，那麼你可以用滿整個頻寬，如果不能，那麼你就會浪費頻寬。（大於MTU的包有兩種結局，一種