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

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

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

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

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

10.52.127.108為客戶端地址

10.0.1.112為VIP

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

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

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

訪問(wèn)流程：

1) 10.52.127.108訪問(wèn)10.0.1.112

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

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

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

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

10.0.76.2為客戶端地址

10.0.1.113為VIP

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

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

訪問(wèn)流程跟抓包1相同。

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

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

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

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

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

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

抓包1：

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

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

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

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

我們?cè)俜治鲎グ?：

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

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

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

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

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

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

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

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

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

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

以上僅僅是猜測(cè)，因?yàn)闆]有以上兩個(gè)廠家的資深工程師的深度參與，無(wú)法最終定位結(jié)果，所以該問(wèn)題成為了一個(gè)疑案。