3.3　網絡傳輸優化

這里從兩方面來進行優化，具體如下。

1. TCP三次握手優化

上文在介紹步驟2時提到，初始化網絡連接會經過TCP三次握手，而眾多傳輸協議都基于TCP網絡傳輸，因此進行Web網絡傳輸優化，TCP是其中重要的環節。建立一次TCP連接需要進行三次握手，三次握手給TCP帶來了很大的延遲，那是否可以減少握手的次數呢？

當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。如果沒有三次握手，有可能會出現一些已經失效的請求包突然又傳到服務端的情況，服務端認為這是客戶端發起的一次新的連接，于是發出確認包，表示同意建立連接，而客戶端并不會有響應，導致服務器空等，白白浪費服務器資源或造成死鎖。

• 長連接：HTTP 1.1引入了長連接，通過在請求頭中加入Connection: keep-alive，來告訴請求響應完畢后不要關閉連接。不過HTTP長連接也是有限制的，服務器通常會設置keep-alive超時時間和最大請求數，如果請求超時或者超過最大請求數，服務器會主動關閉連接。
• TFO（TCP快速打開）：用于三次握手過程，它通過握手開始時的SYN包中的TFO cookie（一個TCP選項）來驗證一個之前連接過的客戶端。如果驗證成功，它可以在三次握手最終的ACK包收到之前就開始發送數據。
• 流量控制：傳輸數據時，如果發送方傳輸的數據量超過了接收方的處理能力，那么接收方會出現丟包。為了避免出現此類問題，流量控制要求數據傳輸雙方在每次交互時聲明各自的接收窗口rwnd的大小，以表明自己最大能保存多少數據。
• 慢啟動：流量控制可以避免發送方過載接收方，但是卻無法避免過載網絡，這是因為接收窗口rwnd只反映了服務器個體的情況，卻無法反映網絡整體的情況。為了避免出現過載網絡的問題，慢啟動引入了擁塞窗口cwnd的概念，用來表示發送方在得到接收方確認前，最大允許傳輸的未經確認的數據。與rwnd不同的是，cwnd只是發送方的一個內部參數，無須通知接收方，其初始值往往比較小，然后隨著數據包被接收方確認，窗口會成倍擴大。

注意，慢啟動的過程中，隨著cwnd的增加，可能會出現網絡過載，其外在表現就是丟包，一旦出現此類問題，cwnd的大小會迅速衰減，以便網絡能夠緩過來。網絡中實際傳輸的未經確認的數據大小取決于rwnd和cwnd中的較小值。那么，如何調整rwnd到合理值？

當遇到過網絡傳輸速度過慢的問題，例如“百兆網路”，最大傳輸數據理論值至少10MB，但實際可能只有1MB，存在的最大問題是接收窗口rwnd設置不合理。實際上接收窗口rwnd的合理值取決于BDP的大小，也就是帶寬和延遲的乘積。假設寬帶100Mbps，延遲100ms，計算過程如下：

BDP=100Mbps * 100ms =（100 / 8）*（100 / 1000）= 1.25MB

如果想最大限制提升吞吐量，接收窗口“rwnd”的大小需要大于1.25MB。那如何調整cwnd到合理值？

cwnd的初始值取決于MSS的大小，計算方法為min(4 * MSS, max(2 * MSS, 4380))，以太網標準的MSS大小通常是1460，所以cwnd的初始值是3MSS。當我們瀏覽視頻或者下載軟件的時候，cwnd初始值的影響并不明顯，這是因為傳輸的數據量比較大，時間比較長，相比之下，即便慢啟動階段cwnd初始值比較小，也會在相對短的時間內加速到滿窗口。當我們瀏覽網頁時，情況就不一樣了，這是因為傳輸的數據量比較小，時間比較短，相比之下，如果慢啟動階段cwnd初始值比較小，那么很可能還沒來得及加速到滿窗口，通信就結束了。

2. 網絡傳輸優化

關于網絡傳輸優化，可以從以下幾個方面考慮：

• 利用瀏覽器緩存，盡量不請求服務器端；
• 特殊情況須向服務器端發送請求以獲取數據時，可以精簡傳輸內容；
• 利用Gzip壓縮傳輸內容，客戶端接收壓縮的內容后由瀏覽器解壓，以提高寬帶利用率；
• 減少cookie、session傳遞。

3.4　本章小結

本章主要講述了分布式環境中網絡及網絡傳輸的過程。在網絡傳輸過程中協議是基礎，其中TCP/IP協議起了非常重要的作用。TCP協議能確保數據穩定傳輸，并且能監控傳輸過程中是否會出現數據失真、數據丟失等情況。若傳輸過程中出現問題，TCP協議會自動請求重新傳輸數據，并重組數據報。

在數據傳輸過程中，傳輸協議有自己的技術標準。OSI是一個開放的通信系統互連參考模型，通過它的7層結構可以讓網絡傳輸變得穩定。通過有效的網絡優化手段（TCP三次握手、精簡傳輸內容、瀏覽器緩存等），能讓網絡傳輸變得更高效。