負載均衡設(shè)備位于客戶端和真實服務(wù)器之間，一旦訪問發(fā)生問題，在客戶經(jīng)過簡單診斷后，負載均衡設(shè)備往往會成為首要被懷疑的對象。客戶一般這樣質(zhì)疑：為什么我直接訪問服務(wù)器沒有問題，通過你的設(shè)備訪問就不行了呢? 質(zhì)疑的確實有道理，但大多數(shù)事情往往不是非一即二這樣簡單，有很多東西都在互相影響，這就使得真相迷霧重重。

某一天接到某客戶報障，說是通過負載均衡設(shè)備訪問某一業(yè)務(wù)的時候，頁面無法打開或者等半天后只打開了部分頁面，而客戶端如果直接訪問服務(wù)器，則可以順利打開頁面。

事情很明顯，這中間肯定是有問題存在。登錄負載均衡設(shè)備檢查配置和log，并取一些內(nèi)部診斷信息，沒發(fā)現(xiàn)什么錯誤，只剩下唯一的辦法：去客戶現(xiàn)場抓包分析。

于是開始抓包，同時抓回了出現(xiàn)問題的服務(wù)的數(shù)據(jù)包和其他沒有出現(xiàn)問題的服務(wù)的數(shù)據(jù)包。

經(jīng)過分析，果然有所不同，下面是有問題的抓包內(nèi)容(抓包1)：

10.52.127.108為客戶端地址

10.0.1.112為VIP

10.0.1.99為真實服務(wù)器地址

由于是以旁路方式部署，需要轉(zhuǎn)換源IP, 10.0.1.123為經(jīng)過負載均衡設(shè)備轉(zhuǎn)換的客戶端地址(snat地址)

負載均衡的VIP配置為HTTP模式，這表示負載均衡設(shè)備是以proxy的方式來處理連接，也就是對每個連接，客戶端先跟負載均衡設(shè)備完成一個三次握手，然后負載均衡設(shè)備再跟真實服務(wù)器完成一個三次握手。

訪問流程：

1) 10.52.127.108訪問10.0.1.112

2) 負載均衡設(shè)備與客戶端完成三次握手

3)然后負載均衡設(shè)備把源IP: 10.52.127.108轉(zhuǎn)換成10.0.1.123向服務(wù)器10.0.1.99發(fā)起連接

4)服務(wù)器10.0.1.99與負載均衡設(shè)備完成三次握手。

下圖是訪問沒有問題的服務(wù)的抓包內(nèi)容(抓包2)：

10.0.76.2為客戶端地址

10.0.1.113為VIP

10.0.1.104為真實服務(wù)器地址

由于是以旁路方式部署，同樣需要把客戶端源IP轉(zhuǎn)換為 10.0.1.123

訪問流程跟抓包1相同。

仔細比較兩個抓包內(nèi)容，終于發(fā)現(xiàn)了差異出現(xiàn)在MSS值的協(xié)商上。

首先我們描述一下Client訪問Server過程中MSS值的協(xié)行過程：

1) 客戶端在向服務(wù)器發(fā)出SYN包的時候，會帶上客戶端設(shè)備可以接受的最大MSS值，意思是服務(wù)器發(fā)送到客戶端的每個包的內(nèi)容大小都不能大于這個值。

2) 服務(wù)器向客戶端回復(fù)SYN,ACK包的時候，會比較客戶端發(fā)來的MSS值和自己設(shè)定的MSS值，取兩者的最小值作為自己可以接受的最大MSS值返回給客戶端，意思是告訴客戶端發(fā)送到服務(wù)器的每個包的內(nèi)容大小都不能大于這個值。

3) 在實際的傳輸中，雙方往往會取二者中的最小值作為雙方互相發(fā)送的包大小的最大值。

基于以上通信流程我們來分析一下以上的兩個抓包內(nèi)容：

抓包1：

客戶端發(fā)出SYN包，標(biāo)明自己可接受的最大MSS值為1460,負載均衡設(shè)備回應(yīng)自己可接受的MSS值為1400,協(xié)商成功后，雙方交互的包大小不會大于1400。

負載均衡設(shè)備向服務(wù)器發(fā)出自己的可接受MSS值為1380,服務(wù)器回應(yīng)自己可接受的MSS值120,協(xié)商成功后，負載均衡設(shè)備發(fā)給服務(wù)器的包就不能大于120了。

問題正是出在最后跟服務(wù)器協(xié)商出的大小為120的MSS值上。

我們看到客戶端向負載均衡設(shè)備發(fā)出的第一個請求包大小為905字節(jié)，這個包大小不大于1400，所以負載均衡設(shè)備接收到了，接著負載均衡設(shè)備要把該請求發(fā)給選定的服務(wù)器10.0.1.99，由于服務(wù)器可接收的包不能大于120,所以負載均衡設(shè)備只能把客戶端發(fā)來的請求包分成八個小包發(fā)送給服務(wù)器，然后一些不可控制的問題就出現(xiàn)了，客戶端發(fā)出請求包后，需要等待應(yīng)答，但由于負載均衡設(shè)備把一個包分解成8個包后，使得負載均衡設(shè)備跟服務(wù)器之間的交互時間變長，這個過程中客戶端可能會超時重發(fā)請求包，而負載均衡設(shè)備跟服務(wù)器之間那八個小包的處理還可能出現(xiàn)丟包，重傳，重裝等問題。最關(guān)鍵是客戶端在該連接的所有請求發(fā)完后如果是發(fā)送一個RST包來關(guān)閉連接，那么即使該連接上還有內(nèi)容沒傳輸完，該條連接也會關(guān)閉，由于一個請求包分成太多的小包傳輸，一旦發(fā)生客戶端發(fā)出RST包的這種情況，基本上都會導(dǎo)致數(shù)據(jù)不能傳輸完畢，以上種種原因?qū)е铝隧撁娌荒艽蜷_或者不能完全打開的現(xiàn)象。

我們再分析抓包2：

客戶端發(fā)出SYN包，標(biāo)明自己可接受的最大MSS值為1460,負載均衡設(shè)備回應(yīng)自己可接受的MSS值為1400,協(xié)商成功后，雙方交互的包大小不會大于1400。這一點跟抓包1相同。

負載均衡設(shè)備向服務(wù)器發(fā)出自己的可接受最大MSS值為1380,服務(wù)器回應(yīng)自己可接受的MSS值1380,協(xié)商成功后，所以雙方會以1380的MSS值互相通信。

無論是客戶端跟負載均衡設(shè)備還是負載均衡設(shè)備跟服務(wù)器之間，都是一個請求一個應(yīng)答就能完成交互，不會發(fā)生要把包分割的現(xiàn)象，所以不會出現(xiàn)抓包1所出現(xiàn)的問題。

網(wǎng)絡(luò)通信中由于MTU的設(shè)置不當(dāng)引發(fā)的問題屢見不鮮，比如在存在ADSL設(shè)備的情況下，如果把設(shè)備的MTU設(shè)置成1500, 往往客戶端的訪問會出現(xiàn)問題，這是因為ADSL的PPPoE協(xié)議在MTU中占去8個字節(jié)，也就是ADSL的MTU最大值最多為1492, 如果客戶端跟服務(wù)器設(shè)的很大，傳輸?shù)臄?shù)據(jù)包恰好大于1492字節(jié)，將導(dǎo)致數(shù)據(jù)包不能通過。 在程序設(shè)計中，程序所取MSS值往往是本機的MTU-40(TCP和IP頭各占20個字節(jié)，MTU一般設(shè)成1500)， 所以基本上所有設(shè)備所能接受的最大MSS值不可能會大于1500-40=1460, 那么再考慮到網(wǎng)絡(luò)中可能會存在PPPoE，VPN等設(shè)備會占用更多MTU字節(jié)，所以各家網(wǎng)絡(luò)設(shè)備廠商提供的網(wǎng)絡(luò)設(shè)備會進一步減小MSS值的設(shè)置，一般網(wǎng)絡(luò)設(shè)備設(shè)定的MSS值大小為1400左右。

顯然1400字節(jié)左右的MSS值是網(wǎng)絡(luò)通信中的正常值，所以服務(wù)器返回一個120字節(jié)的MSS值這是一個不正常的現(xiàn)象，所以問題的根源在于服務(wù)器返回的MSS值不合適，那么這個值是誰返回的呢? 是服務(wù)器，也就是說該返回哪個值主動權(quán)在于服務(wù)器，所以我們診斷問題原因出在服務(wù)器上。

接下來的處理需要去檢查服務(wù)器為什么返回這個值，跟負載均衡設(shè)備無關(guān)了。但仍然有追蹤的價值，因為服務(wù)器并不是一直返回120這個值，而是有些時候會協(xié)商成1380,這時候訪問是正常的，有些時候是返回120，這時候就自然訪問不正常。

客戶的服務(wù)器裝的是HP操作系統(tǒng)，應(yīng)用軟件是Oracle的ebs，在我們把問題定位到了服務(wù)器后，客戶也找了HP的工程師來檢查和分析，但無法找出原因。

個人分析問題原因可能出現(xiàn)在如下幾個方面：

1) HP操作系統(tǒng)或者網(wǎng)卡驅(qū)動程序關(guān)于MTU的定義存在可變值，或者

2) Oracle ebs的底層通信程序在MSS值的協(xié)商時，會根據(jù)一些條件改變MSS值

以上僅僅是猜測，因為沒有以上兩個廠家的資深工程師的深度參與，無法最終定位結(jié)果，所以該問題成為了一個疑案。