负载均衡故障诊断：一个MSS值引发的疑案
?負載均衡設備位于客戶端和真實服務器之間，一旦訪問發生問題，在客戶經過簡單診斷后，負載均衡設備往往會成為首要被懷疑的對象。客戶一般這樣質疑：為什么我直接訪問服務器沒有問題，通過你的設備訪問就不行了呢？ 質疑的確實有道理，但大多數事情往往不是非一即二這樣簡單，有很多東西都在互相影響，這就使得真相迷霧重重。
某一天接到某客戶報障，說是通過負載均衡設備訪問某一業務的時候，頁面無法打開或者等半天后只打開了部分頁面，而客戶端如果直接訪問服務器，則可以順利打開頁面。
事情很明顯，這中間肯定是有問題存在。登錄負載均衡設備檢查配置和log，并取一些內部診斷信息，沒發現什么錯誤，只剩下唯一的辦法：去客戶現場抓包分析。
于是開始抓包，同時抓回了出現問題的服務的數據包和其他沒有出現問題的服務的數據包。
經過分析，果然有所不同，下面是有問題的抓包內容（抓包1）：
10.52.127.108為客戶端地址
10.0.1.112為VIP
10.0.1.99為真實服務器地址
由于是以旁路方式部署，需要轉換源IP, 10.0.1.123為經過負載均衡設備轉換的客戶端地址（snat地址）
負載均衡的VIP配置為HTTP模式，這表示負載均衡設備是以proxy的方式來處理連接，也就是對每個連接，客戶端先跟負載均衡設備完成一個三次握手，然后負載均衡設備再跟真實服務器完成一個三次握手。
訪問流程：
1) 10.52.127.108訪問10.0.1.112
2) 負載均衡設備與客戶端完成三次握手
3）然后負載均衡設備把源IP: 10.52.127.108轉換成10.0.1.123向服務器10.0.1.99發起連接
4）服務器10.0.1.99與負載均衡設備完成三次握手。
下圖是訪問沒有問題的服務的抓包內容（抓包2）：
10.0.76.2為客戶端地址
10.0.1.113為VIP
10.0.1.104為真實服務器地址
由于是以旁路方式部署，同樣需要把客戶端源IP轉換為 10.0.1.123
訪問流程跟抓包1相同。
仔細比較兩個抓包內容，終于發現了差異出現在MSS值的協商上。
首先我們描述一下Client訪問Server過程中MSS值的協行過程：
1） 客戶端在向服務器發出SYN包的時候，會帶上客戶端設備可以接受的最大MSS值，意思是服務器發送到客戶端的每個包的內容大小都不能大于這個值。
2） 服務器向客戶端回復SYN,ACK包的時候，會比較客戶端發來的MSS值和自己設定的MSS值，取兩者的最小值作為自己可以接受的最大MSS值返回給客戶端，意思是告訴客戶端發送到服務器的每個包的內容大小都不能大于這個值。
3） 在實際的傳輸中，雙方往往會取二者中的最小值作為雙方互相發送的包大小的最大值。
基于以上通信流程我們來分析一下以上的兩個抓包內容：
抓包1：
客戶端發出SYN包，標明自己可接受的最大MSS值為1460,負載均衡設備回應自己可接受的MSS值為1400,協商成功后，雙方交互的包大小不會大于1400。
負載均衡設備向服務器發出自己的可接受MSS值為1380,服務器回應自己可接受的MSS值120,協商成功后，負載均衡設備發給服務器的包就不能大于120了。
問題正是出在最后跟服務器協商出的大小為120的MSS值上。
我們看到客戶端向負載均衡設備發出的第一個請求包大小為905字節，這個包大小不大于1400，所以負載均衡設備接收到了，接著負載均衡設備要把該請求發給選定的服務器10.0.1.99，由于服務器可接收的包不能大于120,所以負載均衡設備只能把客戶端發來的請求包分成八個小包發送給服務器，然后一些不可控制的問題就出現了，客戶端發出請求包后，需要等待應答，但由于負載均衡設備把一個包分解成8個包后，使得負載均衡設備跟服務器之間的交互時間變長，這個過程中客戶端可能會超時重發請求包，而負載均衡設備跟服務器之間那八個小包的處理還可能出現丟包，重傳，重裝等問題。最關鍵是客戶端在該連接的所有請求發完后如果是發送一個RST包來關閉連接，那么即使該連接上還有內容沒傳輸完，該條連接也會關閉，由于一個請求包分成太多的小包傳輸，一旦發生客戶端發出RST包的這種情況，基本上都會導致數據不能傳輸完畢，以上種種原因導致了頁面不能打開或者不能完全打開的現象。
我們再分析抓包2：
客戶端發出SYN包，標明自己可接受的最大MSS值為1460,負載均衡設備回應自己可接受的MSS值為1400,協商成功后，雙方交互的包大小不會大于1400。這一點跟抓包1相同。
負載均衡設備向服務器發出自己的可接受最大MSS值為1380,服務器回應自己可接受的MSS值1380,協商成功后，所以雙方會以1380的MSS值互相通信。
無論是客戶端跟負載均衡設備還是負載均衡設備跟服務器之間，都是一個請求一個應答就能完成交互，不會發生要把包分割的現象，所以不會出現抓包1所出現的問題。
網絡通信中由于MTU的設置不當引發的問題屢見不鮮，比如在存在ADSL設備的情況下，如果把設備的MTU設置成1500, 往往客戶端的訪問會出現問題，這是因為ADSL的PPPoE協議在MTU中占去8個字節，也就是ADSL的MTU最大值最多為1492, 如果客戶端跟服務器設的很大，傳輸的數據包恰好大于1492字節，將導致數據包不能通過。? 在程序設計中，程序所取MSS值往往是本機的MTU-40（TCP和IP頭各占20個字節，MTU一般設成1500）， 所以基本上所有設備所能接受的最大MSS值不可能會大于1500-40=1460, 那么再考慮到網絡中可能會存在PPPoE，×××等設備會占用更多MTU字節，所以各家網絡設備廠商提供的網絡設備會進一步減小MSS值的設置，一般網絡設備設定的MSS值大小為1400左右。
顯然1400字節左右的MSS值是網絡通信中的正常值，所以服務器返回一個120字節的MSS值這是一個不正常的現象，所以問題的根源在于服務器返回的MSS值不合適，那么這個值是誰返回的呢？ 是服務器，也就是說該返回哪個值主動權在于服務器，所以我們診斷問題原因出在服務器上。
接下來的處理需要去檢查服務器為什么返回這個值，跟負載均衡設備無關了。但仍然有追蹤的價值，因為服務器并不是一直返回120這個值，而是有些時候會協商成1380,這時候訪問是正常的，有些時候是返回120，這時候就自然訪問不正常。
客戶的服務器裝的是HP操作系統，應用軟件是Oracle的ebs，在我們把問題定位到了服務器后，客戶也找了HP的工程師來檢查和分析，但無法找出原因。
個人分析問題原因可能出現在如下幾個方面：
1） HP操作系統或者網卡驅動程序關于MTU的定義存在可變值，或者
2） Oracle ebs的底層通信程序在MSS值的協商時，會根據一些條件改變MSS值
以上僅僅是猜測，因為沒有以上兩個廠家的資深工程師的深度參與，無法最終定位結果，所以該問題成為了一個疑案。
各位讀了這篇文章的朋友，如果熟悉HP操作系統和Oracle ebs或者遇到有類似的case，歡迎一起來討論一下。
（wyl）
轉載于:https://blog.51cto.com/virtualadc/692407
總結
以上是生活随笔為你收集整理的负载均衡故障诊断：一个MSS值引发的疑案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux自带iscsi-target使
- 下一篇： 用自己的角度看云