解決“通”或“不通”這類功能性問題，其實很好解決。解決網頁打開“很慢”、“慢”、“正常”、“快”之類的性能問題，有時并不那麼容易。

通過題主的描述可以獲得以下事實：

• 網絡的連通性沒有問題，否則也無法Ping通服務器
• 域名解析也沒有問題，否則也無法訪問網頁
• 服務器應該工作正常，否則也無法訪問
• 網絡是暢通的，否則Ping的延遲不可能正常

既然網絡看起來是好的，為何訪問網頁慢呢？

根據多年的從業經驗，我的推測是：

MTU問題

局域網出口網關，可能由于PPPoE撥号，在正常的用戶IP報文頭前又增添了8個字節的PPPoE頭，使得用戶1500字節的IP報文，變成了1508字節。

由于出口網關WAN接口的MTU = 1500。很顯然1508字節的IP報文 > WAN接口的MTU，網關需要将1508字節的IP報文，分成2片，每片都要小于等于1500字節，才能通行。

分片（Fragment）會消耗網關的硬件資源、軟件資源，如果網關是使用純軟件來進行分片，那效率是非常低下的，會造成延遲的增大。

當分片到達服務器時，服務器要組織硬件、軟件來将分片進行重組（Reassemble），重組成最原始的1500字節（此時PPPoE頭已經不存在了），這在一定程度上增加了處理延遲。

如果服務器沒有采用網卡硬件加速重組，而是由TCP/IP協議棧（純軟件）進行重組，又是一個令人難以忍受的漫長。

還沒有完，等服務器返程的IP報文（1500字節），到達局域網所在的接入網絡時，又需要增添8字節的PPPoE頭，IP報文又一次膨脹為1508字節，同樣需要分片，這又一次增加了處理延遲。

當分片到達題主的主機時，同樣需要進行重組，這又一次增加了處理延遲。

一來一回共增加了四次處理延遲，訪問網頁自然會慢。

還沒有完，還沒有考慮到有丢包的情況發生。如果2個分片有1個分片傳輸過程中丢了，源主機需要重傳整個IP報文，而重傳的IP報文一樣需要分片。在這種情況下，不但有TCP 超時重傳的延遲，還有分片的延遲。

這無疑是雪上加霜，讓本來很糟的情況，變得更加糟糕。

這還沒有完，分片到達服務器/主機時，由于其孿生兄弟還沒有到達，需要暫時呆在緩存裡等待孿生兄弟的到來，才能重組，對嗎？

在網絡丢包嚴重時，孿生兄弟可能永遠都無法到達（丢了），呆在緩沖區的分片需要等待一段時間才能删除。要命了，會有茫茫多的分片不斷到達緩沖區，并快速占滿緩存空間。

有讀者會問，為什麼它們賴着不走啊？

因為孿生兄弟（分片）還沒有到達！

再有分片到達時，沒有緩存可以用了，怎麼辦？ 丢！

TCP如何修複這些丢包？

超時重傳！

超時重傳又增加了延遲！

說了那麼多，其實就是一個意思，一旦分片了，就做好網絡變慢的思想準備！

上文的觀點，不是憑空的推測，而是多年實驗室實驗研究的結論。

如何證明是MTU造成的問題？

隻要把主機的MTU從标準的1500修改成1492或更小，然後再次訪問網頁，和其它主機對比一下便知。

如何系統性地解決這個問題？

一般商用的路由器，為了避免分片，會部署一個Feature : “TCP Adjust-MSS”,用于動态修改用戶TCP報文的MSS值，隻要将将MSS值減小8個字節，以抵消PPPoE頭帶來的長度增加。

如果題主的網關路由器支持這個功能，打開這個功能。如果不支持，需要升級路由器。或将局域網的主機MTU都改小8個字節。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!