網路是很抽象的，但是在wireshark裡面卻又是相對直觀的。這裡我們列舉了5個問題來進一步直觀地學習TCP協議，並且從中瞭解分析網路效能的一般方法。

問題一：關於子網掩碼和閘道器

伺服器A和B的網路配置如下：
A：
IP address： 192.168.26.129
Subnet mask: 255.255.255.0
Default gateway: 192.168.26.2
B:
IP address： 192.168.26.3
Subnet mask: 255.255.255.224
Default gateway: 192.168.26.2
B的子網掩碼本應該是255.255
 
.255.0，被不小心配成了255.255.255.224，它們還能正常通訊嗎？

運用我們學過的網路知識，子網掩碼是用來判斷任意兩臺計算機的IP地址是否屬於同一子網路的依據。最為簡單的理解就是兩臺計算機各自的IP地址與子網掩碼進行“與”運算後，如果得出的結果是相同的，則說明這兩臺計算機是處於同一個子網路上的，可以進行直接的通訊，就這麼簡單。

在B上ping A，由於在B看來B_IP&B_mask的結果和A_IP&B_mask的結果不一致，也就是A和B不屬於同一個子網。因為跨子網通訊需要預設閘道器的轉發，所以B要先通過ARP廣播查詢預設閘道器192.168.26.2的MAC地址，之後預設閘道器再把包轉發給A。由於在A看來A_IP&A_mask和B_IP&A_mask的結果一致，也就是A和B屬於同一個子網，所以B可以直接收到A發出的ARP廣播，不需要預設閘道器的參與。之後由於A和B都已經知道對方的MAC地址，不必再發送ARP廣播，直接就是ping請求和ping回覆了。

通訊過程如下圖：

問題二：關於MTU

我們都知道網路分層的基本概念，如果我們現在有一個比較大的寫操作，比如8192位元組，那麼TCP層是不是簡單的加上TCP頭就可以交給網路層了呢？很顯然答案是否定的，因為網路對包的大小有限制，其最大稱為MTU，即“最大傳輸單元”。大多數網路的MTU是1500位元組，但也有些網路啟用了巨幀(Jumbo Frame)，能達到9000位元組，一個8192位元組的包進入巨幀網路不會有問題，但到了1500位元組的網路中就會被丟棄或者切分。被丟棄意味著傳輸徹底失敗，因為重傳的包還會被丟棄，而被切分則意味著傳輸效率降低。

由於這個原因，TCP不想簡單的將8192位元組的資料一口氣傳給網路層，而是根據雙方的MTU決定每次傳多少。知道自己的MTU容易，那麼對方的MTU是如何獲取的呢？如圖，TCP三次握手的時候，雙方都會把自己的MSS告訴對方，MSS+TCP頭和IP頭的長度，就得到MTU了。而且發包的大小是由MTU較小的一方決定的。

另外，如果網路路徑上存在著一個MTU小於1500的裝置，這個包還是可能被丟棄或者切分，所以這個方案並不完美，但是至今沒有更好的辦法。

在這裡我還要說一個我實習時候遇到的關於MTU的一個問題，兩臺主機通過OVS網橋使用vxlan協議傳輸資料，但是傳輸大資料時速度很慢，不到正常值的1/10。後來發現vxlan會對所有經過OVS網橋的資料包進行一個封包操作，也就是會在頭部增加幾個位元組。這樣資料包在經過設定為MTU 1500的裝置時就會發生丟棄或者切分，從而導致這個問題。將裝置的MTU 適當調小之後恢復正常。如果沒有深入地瞭解MTU並且使用wireshark或者tcpdump抓包的話，是很難發現這個問題的。

問題三：經常聽說“TCP Window Scale”這個概念，他究竟和接收視窗有何關係？

TCP剛發明的時候，全世界的網路頻寬都很小，所以最大接收視窗被定義為65535位元組。隨著硬體的革命性進步，65535位元組已經成為效能瓶頸了。1992年的RFC中提出了一個解決方案，就是在三次握手的時候，把自己的Window Scale資訊告知對方，作用就是向對方宣告一個Shift count，我們把它作為2的指數，再乘以TCP頭中定義的接收視窗，就得到真正的TCP接收視窗了。

如下圖：192.168.1.108告訴14.215.177.37說它的Shift count是8。2的8次方是256，這就意味著以後192.168.1.108宣告的接收視窗要乘以256才是真正的視窗值。

如下，192.168.1.108宣告自己的接收視窗是183，183*256=66048，所以wireshark就顯示Win=66048了。注意：如果抓包的時候沒有抓到三次握手，那麼wireshark就不知道如何計算，所以有時候我們會很莫名的看到一些極小的接收視窗值。還有些時候是防火牆識別不了Window Scale，因此對方無法獲得Shift count，最終導致嚴重的效能問題。

問題四：關於TCP重傳

想必大家都看過計算機網路方面的教材，但是捫心自問，除了記住概念，你又是否真的瞭解TCP滑動視窗和重傳的設計呢？

先說一個誤區，很多人把window size（也就是win=）誤認為是傳送視窗，其實這不是傳送視窗，而是在向對方宣告自己的接收視窗。如果接收方處理資料的速度跟不上接收資料的速度，快取就會被佔滿，從而導致接收視窗為0，對方接收到win=0的資訊後，就會將自己的傳送視窗限制為0，不會再發送資料。

另外，傳送視窗除了受接收方的接收視窗影響之外，還受到網路的影響（也就是我們常說的擁塞視窗），其中限制的更嚴的因素起到決定作用。
網路之所以能限制傳送視窗，是因為他一口氣收到太多資料時就會擁塞，擁塞的結果是丟包，這是傳送方最忌憚的。

接下來我們開看看擁塞視窗如何維護：
1. 連線剛建立的時候，傳送方對網路狀況一無所知，TCP採用慢啟動(指數增長)+擁塞避免(線性增長)的方式來試探擁塞點。如果之前發生過擁塞，就把該擁塞點作為參考依據，如果從來沒有擁塞過就可以取相對較大的值，比如和最大接收視窗相等。
2. 那麼擁塞之後會發生什麼情況呢？
對傳送方來說，就是發出去的包不像往常一樣得到確認了。不過收不到確認也可能是網路延遲所致，所以傳送方決定等待一小段時間再去判斷，如果遲遲收不到，就認定包已經丟失了，需要重傳，這個過程稱為超時重傳。從發出原始包到重傳該包的這段時間稱為RTO。那麼重傳之後的擁塞視窗是否需要調整呢？很顯然是非常有必要的，為了不給擁塞的網路雪上加霜，RFC建議把擁塞視窗降到1個MSS，然後再次進入慢啟動。那麼這一次從慢啟動過渡到擁塞避免的臨界視窗值就有參考依據了。RFC 5681認為應該是發生擁塞時沒被確認的資料量的1/2，但是不能小於2個MSS。不難想象，超時重傳對傳輸效能有嚴重影響。原因之一是在RTO階段不能傳資料，相當於浪費了一段時間；原因之二是擁塞視窗的急劇減小，使得傳輸速率受到影響。所以，即使是萬分之一的超時重傳對效能的影響也非同小可。

有時候擁塞很輕微，只有少量的包丟失，還有些偶然因素，比如校驗碼不對的時候會導致單個丟包。這兩種丟包的症狀和嚴重擁塞時的不一樣，因為後續有包能夠正常到達。當後續的包到達接收方時，接收方會發現其Seq號比期望的大，所以它每收到一個包就Ack一次期望的Seq號，以此提醒傳送方重傳。當傳送方收到3個或以上重複確認(Dup Ack)時，就意識到響應的包已經丟了，從而立即重傳它，這個過程稱為快速重傳。
為什麼要規定湊滿3個呢？這是因為網路包有時候會亂序，亂序的包一樣會觸發重複的Ack，但是為了亂序而重傳沒有必要。由於一般亂序的距離不會相差太大，比如2號包也許會跑到4號包後面，但是不太可能跑到6號包後面，所以限定成3個或以上可以在很大程度上避免因亂序而觸發快速重傳。

那麼快重傳情況下的臨界視窗值如何設定呢？RFC 5681認為臨界視窗值應該設為發生發生擁塞時還沒被確認的資料量的1/2（但是不能小於2個MSS）。然後將擁塞視窗設定為臨界視窗值加3個MSS，繼續保留在擁塞避免階段。這個過程成為快速恢復。

問題五：延遲確認與Nagle演算法

傳送視窗一般隻影響大塊的資料傳輸，比如讀寫大檔案。而頻繁互動的小塊資料不太在乎傳送視窗的大小，因為發包量本來就小。日常場景中比如用ssh客戶端連線linux伺服器，隨便輸入一些字元，在網路上就互動了很多小塊的資料了。其實這種方式是很低效的，因為TCP頭和IP頭至少40位元組，而攜帶的資料卻只有幾個字元。

延遲確認就是處理這種互動式場景的一種策略。原理是這樣的：如果收到一個包之後暫時沒有資料要發給對方，那就延遲一段時間(windows上預設200ms)再確認。這樣在這段時間內如果恰好有資料要傳送，那就可以在一個包裡傳送了。它減少了部分確認包，減輕了網路負擔。

還是ssh客戶端的場景，一個RTT內傳送的字元仍然會被逐個打成小包傳送，能不能把在一個RTT內生成的小資料收集起來，合併成一個大包呢？Nagle演算法實現的就是這個功能。原理是：在發出去的資料還沒有被確認之前，假如又有小資料生成，那就把小資料收集起來，湊滿一個MSS或者等收到確認後再發送。

注意：在某些場合，延遲確認和Nagle演算法一起使用甚至會降低效能。具體的案例會在下一篇文章中介紹。

參考資料

《wireshark網路分析就是這麼簡單》
《計算機網路》謝希仁
RFC文件