我在 Azure 中執行多個虛擬機器。 VM 在具有 NSG 的子網路中運作。 NIC 不使用 NSG，我們不使用加速網路。
我注意到，當一台虛擬機器使用TCP 與同一子網路的另一台虛擬機器通訊時，SYN 封包中的MSS 值會減少42。同一網路的另一台虛擬機，則其他虛擬機將捕獲 MSS=834 的 TCP SYN：
客戶：
18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1418,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
伺服器:
18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [S], seq 3092614737, win 17520, options [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], length 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: Flags [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731 ecr 2936204423,nop,wscale 7], length 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: Flags [.], ack 1, win 137, options [nop,nop,TS val 2936204425 ecr 390195731], length 0
我們正在使用多個NVA，並且我們的SYN 封包經過多個躍點，我們實際上看到MSS 減少了多次，我們最初測量到減少了84，在某些情況下我們還測量到減少了138 （實際上不是42），這意味著我們的網路效率降低了 10% 以上。
我花了一些時間研究各種網路設備如何與 MSS 搭配使用。在大多數情況下，MSS 透過固定為靜態值或路徑 MTU 來設定為固定量。 PaloAlto 將使用與網路介面的 MTU（固定值）相關的「調整」。 Arista 將允許您為入口或出口流量設定上限值，同樣是絕對值。一些防火牆供應商（例如 PaloAlto）會在 DoS 攻擊和 SYN cookie 啟動的情況下減少 MSS，但在這種情況下，MSS 將是 8 個可能值之一。
我相信這種MSS -= 42機制破壞了TCP：如果客戶端支援巨型幀並發送8860的MSS，Azure中的伺服器收到8876，它本身回复1330，但客戶端收到1246，客戶端將同意數據包應該有1246位元組有效負載，而伺服器將發送 1330 位元組的有效負載。
最大的問題是我們存在流量「偶然」運行的情況。在快速路由端，夾緊沒有正確完成，但由於這裡和那裡的 -42，MSS 實際上被減少到「適合」的值，直到封包的路由方式發生一些輕微的變化，並且您發現突然發現某處配置錯誤。
知道如何解釋這種減少嗎？我相信這種行為沒有記錄在任何地方。
編輯
剛剛讀書RFC879
MSS可以在資料流的每個方向上完全獨立地使用。結果可能是兩個方向上的最大尺寸完全不同。
所以根據 RFC，它看起來是合法的。仍然是一個奇怪的行為。
答案1
與實體網路相反，SDN 網路會消耗額外的「位元組」來封裝標頭 (GRE)。可見的IP是CA（客戶位址），但也有PA（提供者位址），需要在雲端提供者中進行路由。因此，您將看到可用的 MSS 減少，因為雲端供應商在基礎架構中應用了額外的 TCP 限制以實現後端路由。