tcp 握手後向公網發送包，與mss大小不符合，丟失問題？

12-28

客戶端PC在連接到阿里雲伺服器，抓包發現在tcp握手時，客戶端mss大小為1452，伺服器mss大小為1460。在伺服器用tcpdump抓取，提示客戶端發送第一個包丟失，收到了第二個包，並且第一個數據包大小為1460。按照tcp協議，握手後不應該發送大小為1460的包啊。

戲說一下這個通信的全過程，客戶端為愛妃，伺服器端為皇上。

愛妃：皇上，臣妾的尺寸是1452，請求寵幸
皇上：愛妃，朕的尺寸是1460，寵幸儂好啦
愛妃：多謝皇上恩典

愛妃與皇上知道彼此的尺寸，理應選擇min(1452，1460）中較小的1452，才會和諧融洽，但很顯然他們沒有那麼做，這個已經失去了MSS存在的意義。

愛妃抱著僥倖的心理，既然皇上儂告訴老娘可以發送1460的尺寸，於是就發了，可惜的是這個禮物沒有到達對方，為何？被丟了，那愛妃如何知道丟了呢？因為皇帝抱怨了（第五個就是抱怨包，當皇帝發現序列號大的包先到，而序列號小的還沒有到，就會抱怨），愛妃意識到還是老老實實用1452 （這裡有可能是開啟了PMTUD，路由器發消息給愛妃），這個適合自己的尺寸比較好，於是重傳，重傳成功。

接下來皇上開始表演了，皇上竟然使用1537，皇上為何那麼大？那是因為皇上的MTU 遠遠大於1500，可能9000都不止，至於為何對愛妃謊稱只有1460，那是因為使用預設值1460，其實遠遠不止，否則這裡的1537 長度不切割不會發出去。

但這個1537長的禮物從皇帝傳給愛妃的路徑上會遭遇到 MTU = 1500 / 1492 的小路徑，一定會分片的，可以在愛妃側抓包驗證，但皇上就顧不了那麼多了，自己爽就好！

這個是tplink路由器問題。使用ppoe撥號上網，導致tplink路由器上的mtu大小為1492，client機器上的mtu大小為1500，server機器mtu大小為1500。client握手發出的mss為1460，本身沒有什麼問題，但經過tplink路由器後，mss的大小被修改為1452。握手後，伺服器一邊知道的mss信息為(client:1452,server:1460)，客戶端一邊知道的mss信息(client:1460,server:1460)。
從客戶端和伺服器兩邊抓包來看，客戶端第一次發了個大小為1460的包，tplink路由器未能發送，導致丟失。
至於server邊能抓到大小為1537的包，因為開啟了網卡LSO功能，操作系統優化性能，不分包，直接交給網卡處理，抓包工具抓取的是操作系統下發給網卡的包，真正網卡的分包通過client邊驗證過