故事發(fā)生背景：客戶業(yè)務(wù)系統(tǒng)是在公網(wǎng)提供WEB服務(wù)的網(wǎng)站，在客戶的網(wǎng)絡(luò)結(jié)構(gòu)中，經(jīng)過SSL安全網(wǎng)關(guān)后經(jīng)過F5 BIGIP-LTM進(jìn)行負(fù)載均衡?？蛻糁笆怯蒘SL安全網(wǎng)關(guān)進(jìn)行業(yè)務(wù)負(fù)載，后來由于其他考量決定采用F5負(fù)載均衡的產(chǎn)品。但是上線F5后出現(xiàn)一個(gè)問題，流量經(jīng)過F5后負(fù)載一直不均衡，流量主要集中在一臺(tái)服務(wù)器節(jié)點(diǎn)上。SSL安全網(wǎng)關(guān)為信安世紀(jì)TLS/SSL卸載設(shè)備。
到達(dá)客戶現(xiàn)象后，開始排查問題，很簡單的思路，負(fù)載不均衡的主要影響因素之一就是F5上面的會(huì)話保持策略，進(jìn)過查看配置后發(fā)現(xiàn)果然是源地址會(huì)話保持，詢問客戶的網(wǎng)絡(luò)工程師后發(fā)現(xiàn)所有的客戶端經(jīng)過SSl安全網(wǎng)關(guān)后都會(huì)被轉(zhuǎn)換成SSL安全網(wǎng)關(guān)的地址。這樣流量經(jīng)過F5后，對(duì)于F5來說都是從一個(gè)客戶端來的，F(xiàn)5上又是采用的源地址會(huì)話保持的策略，所以經(jīng)所謂的“同一個(gè)”客戶端的請(qǐng)求始終保持在一臺(tái)服務(wù)器節(jié)點(diǎn)上；
找到問題后的處理步驟：跟信安世紀(jì)廠家溝通是夠可以不做地址轉(zhuǎn)換，但是信安世紀(jì)廠家不愿意更改源地址透傳，覺得改動(dòng)太大，后來溝通的結(jié)果是讓SSL網(wǎng)關(guān)將客戶端源地址像F5一樣將源地址插入到HTTP X-Forword-For字段中，F(xiàn)5通過irule的策略將流量請(qǐng)求中XFF中的源地址取出來做會(huì)話保持，irules策略：
但是通過irules打出log后看到XFF中的源地址也是同一個(gè)，醉了?？蛻糇钋懊娴腘AT設(shè)備也會(huì)將地址映射為同一個(gè)IP，唉，，只能換種方法了。
第二階段排查，將會(huì)話保持策略更換為cookie的方式。（可能有人會(huì)質(zhì)疑，為什么不在一開始就使用cookie的保持方式，通過地址區(qū)分不開就要通過用戶的cookie的方式，是因?yàn)槲彝轮敖o這個(gè)客戶遠(yuǎn)程過說換成cookie策略后負(fù)載依然不均衡，同時(shí)會(huì)帶來另一個(gè)問題，就是應(yīng)用系統(tǒng)訪問慢。）
此時(shí)更換為cookie的會(huì)話保持策略就需要找到問題根源解決問題，這個(gè)時(shí)候就需要把策略更換別cookie的方式，同時(shí)抓包查找問題。
經(jīng)過抓包分析后發(fā)下一個(gè)問題，客戶的同一個(gè)TCP流中，存在多個(gè)用戶的請(qǐng)求數(shù)據(jù)。造成F5在區(qū)分連接的負(fù)載均衡時(shí)無法發(fā)揮它的強(qiáng)大威力，變成了睜眼瞎。
數(shù)據(jù)包分析如下：
根據(jù)現(xiàn)象分析猜測是由于SSL安全網(wǎng)關(guān)采用了類似F5LTM的oneconnect（連接復(fù)用）功能，讓用戶與SSL安全網(wǎng)關(guān)的人溝通確認(rèn)后，確實(shí)采用了此功能，由于之前用戶沒有F5設(shè)備，服務(wù)器負(fù)載是由SSL來做，所以默認(rèn)的情況下采用了此配置，最后將此功能去掉后發(fā)現(xiàn)F5負(fù)載就變得均衡了。
oneconnect（也叫TCP連接復(fù)用TCP連接復(fù)用（TCP Connection Reuse））功能介紹：
TCP連接復(fù)用技術(shù)通過將前端多個(gè)客戶的HTTP請(qǐng)求復(fù)用到后端與服務(wù)器建立的一個(gè)TCP連接上。這種技術(shù)能夠大大減小服務(wù)器的性能負(fù)載，減少與服務(wù)器之間新建TCP連接所帶來的延時(shí)，并最大限度的降低客戶端對(duì)后端服務(wù)器的并發(fā)連接數(shù)請(qǐng)求，減少服務(wù)器的資源占用。
一般情況下，客戶端在發(fā)送HTTP請(qǐng)求之前需要先與服務(wù)器進(jìn)行TCP三次握手，建立TCP連接，然后發(fā)送HTTP請(qǐng)求。服務(wù)器收到HTTP請(qǐng)求后進(jìn)行處理，并將處理的結(jié)果發(fā)送回客戶端，然后客戶端和服務(wù)器互相發(fā)送FIN并在收到FIN的ACK確認(rèn)后關(guān)閉連接。在這種方式下，一個(gè)簡單的HTTP請(qǐng)求需要十幾個(gè)TCP數(shù)據(jù)包才能處理完成。
采用TCP連接復(fù)用技術(shù)后，客戶端（如：ClientA）與負(fù)載均衡設(shè)備之間進(jìn)行三次握手并發(fā)送HTTP請(qǐng)求。負(fù)載均衡設(shè)備收到請(qǐng)求后，會(huì)檢測服務(wù)器是否存在空閑的長連接，如果不存在，服務(wù)器將建立一個(gè)新連接。當(dāng)HTTP請(qǐng)求響應(yīng)完成后，客戶端則與負(fù)載均衡設(shè)備協(xié)商關(guān)閉連接，而負(fù)載均衡則保持與服務(wù)器之間的這個(gè)連接。當(dāng)有其它客戶端（如：ClientB）需要發(fā)送HTTP請(qǐng)求時(shí)，負(fù)載均衡設(shè)備會(huì)直接向與服務(wù)器之間保持的這個(gè)空閑連接發(fā)送HTTP請(qǐng)求，避免了由于新建TCP連接造成的延時(shí)和服務(wù)器資源耗費(fèi)。
在HTTP 1.0中，客戶端的每一個(gè)HTTP請(qǐng)求都必須通過獨(dú)立的TCP連接進(jìn)行處理，而在HTTP 1.1中，對(duì)這種方式進(jìn)行了改進(jìn)。客戶端可以在一個(gè)TCP連接中發(fā)送多個(gè)HTTP請(qǐng)求，這種技術(shù)叫做HTTP復(fù)用（HTTP Multiplexing）。它與TCP連接復(fù)用最根本的區(qū)別在于，TCP連接復(fù)用是將多個(gè)客戶端的HTTP請(qǐng)求復(fù)用到一個(gè)服務(wù)器端TCP連接上，而HTTP復(fù)用則是一個(gè)客戶端的多個(gè)HTTP請(qǐng)求通過一個(gè)TCP連接進(jìn)行處理。前者是負(fù)載均衡設(shè)備的獨(dú)特功能；而后者是HTTP 1.1協(xié)議所支持的新功能，目前被大多數(shù)瀏覽器所支持。
更多F5技術(shù)支持歡迎聯(lián)系Q：1247951665
