資源描述：
《集群的可擴展性及其分布式體系結(jié)構之十》由會員上傳分享，免費在線閱讀，更多相關內(nèi)容在行業(yè)資料-天天文庫。
1、集群的可擴展性及其分布式體系結(jié)構之十TCP粘合技術原理林凡(iamafan@21cn.com)2003年6月09日廈門大學本部分，將對面向內(nèi)容交換的負載平衡中，使用的主要網(wǎng)絡通信技術手段進行分析。其中，關于通信的半工（TCPHandOff）和雙工（TCPSplicing粘合模式）是目前ContentSwitch（面向內(nèi)容交換）集群系統(tǒng)使用的主要技術。傳統(tǒng)的負載平衡技術主要有應用層協(xié)議代理服務器、三層和四層交換等。其中，應用層代理技術，面向特定的應用層協(xié)議，對客戶端和服務器的數(shù)據(jù)流進行轉(zhuǎn)換；三層和四層交換通過識別數(shù)據(jù)報文的有效地址信息進行雙向的映射和調(diào)度。
2、不管采用哪一種技術，其根本模式都是在網(wǎng)絡連接的基礎上進一步對數(shù)據(jù)包進行業(yè)務級分流。1、應用級代理應用級代理廣泛的應用于HTTP代理，HTTP緩存等領域，扮演著當今重要的網(wǎng)絡服務角色。一般的應用層代理都采用應用層連接粘合代理（split-connection），代理服務器位于客戶端和被訪問的服務站點之間，代理服務器透明的將客戶請求和服務器響應進行雙向轉(zhuǎn)換，以協(xié)助雙方完成通信的全過程。從HTTP緩存服務器（眾所周知的Squid）到安全防火墻，代理服務器始終保持了對現(xiàn)有網(wǎng)絡服務協(xié)議的兼容性（主要是HTTP等）以及對現(xiàn)有應用框架的集成性。當用戶提交請求，代理將請
3、求轉(zhuǎn)發(fā)給服務器，對于服務器而言，代理充當了客戶端的角色；當服務器響應請求，代理收到后將數(shù)據(jù)返回客戶端，對于客戶端而言，充當服務端的角色。但是，連接粘合代理存在著幾大致命的問題：首先，代理服務器的性能始終是大規(guī)模通信的瓶頸；其次，由于代理服務器對任何方向上的數(shù)據(jù)都要進行轉(zhuǎn)換，大大增加了通信延遲；最后，代理本質(zhì)上對端到端的傳輸協(xié)議進行了修改，難免會存在傳輸協(xié)議的兼容性問題。因此，在集群應用中，特別是大規(guī)模負載平衡集群系統(tǒng)中很難看到應用級代理的身影。?版權所有?IBM公司?2003商標集群的可擴展性及其分布式體系結(jié)構之十第1頁，共9developerWorks
4、?ibm.com/developerWorks/cn/圖一：應用層代理原理示意圖當客戶端向服務器發(fā)起請求的時候，連接被重定向到代理服務器的指定端口上（例如IE瀏覽器中設定的代理一樣）；代理接收到這一連接請求以后，根據(jù)請求的目標地址和端口，向被訪問的服務器發(fā)出另一個連接請求，并將客戶端發(fā)來的請求轉(zhuǎn)發(fā)到目標服務器上；隨后，代理服務器強制在兩個連接上進行互相轉(zhuǎn)發(fā)請求數(shù)據(jù)和應答數(shù)據(jù)，成為客戶端和服務器之間必經(jīng)之路。因此，代理實現(xiàn)客戶端對服務器的透明訪問。本質(zhì)上，代理將客戶端的請求進行適當?shù)男薷?，重新通過另一個連接發(fā)送到服務器端，反之依然。這樣子的缺點是顯然的：數(shù)
5、據(jù)的雙向拷貝需要經(jīng)由核心的TCP/IP協(xié)議棧到用戶空間，修改后再由用戶空間到TCP/IP層進行處理轉(zhuǎn)發(fā)，頻繁的上下文交換導致代理的效率低下。而代理服務器也不得不維護至少雙倍于請求數(shù)量的連接，這對于代理服務器的內(nèi)存和CPU調(diào)度都有極高的要求。這類的代理服務器大多數(shù)針對特定的應用層協(xié)議進行雙向網(wǎng)絡連接的交換工作，比如特定的HTTP、HTTPS代理，F(xiàn)TP代理等，都要求代理服務器理解對應的高層協(xié)議的通信原語，因此往往通過一個多線程的用戶進程來實現(xiàn)。2、核心級的TCP粘合交換技術―TCPSplicing大多數(shù)的四層交換產(chǎn)品，都是在網(wǎng)絡傳輸協(xié)議層（TCP）進行工作
6、。它們通過轉(zhuǎn)換數(shù)據(jù)包的端口和IP地址信息，將數(shù)據(jù)重新定向到服務節(jié)點上。比如，將HTTP請求定向到WebCache服務器上，或者將請求均勻分配到不同的節(jié)點實現(xiàn)負載平衡。而面向內(nèi)容調(diào)度的提出，要求在四層交換的基礎上進一步識別交換數(shù)據(jù)的內(nèi)容，以實現(xiàn)智能交換和更高的性能。傳統(tǒng)的四層交換，在客戶端發(fā)出第一個Syn包后，均衡器對服務節(jié)點群進行選擇，并將該SYN后續(xù)的報文直接發(fā)往選定的節(jié)點。處理的模式固然簡單并且有效率，但是對于需要解析報文內(nèi)容的交換機而言，需要在連接建立后（SYN開始之后并完成三次握手），才從接下來的報文中獲得負載平衡所需的信息（比如，一個HTTP協(xié)
7、議的Get的請求，在客戶端完成了連接建立的操作之后，均衡器才能獲得具體的Get指令內(nèi)容）。這意味著，均衡器不能僅僅根據(jù)SYN報文的地址和端口信息就做出調(diào)度判斷；而要把調(diào)度的決定延遲到相關業(yè)務數(shù)據(jù)到達的時候進行――整體上講，交換被"延遲"了。于是，原理上，負載均衡器（也就是應用級代理），需要監(jiān)聽客戶端的連接請求，并在客戶端發(fā)出連接的請求之后（從SYN開始），建立客戶端到均衡器之間的連接（通過TCP的三次握手協(xié)議完集群的可擴展性及其分布式體系結(jié)構之十第2頁，共9ibm.com/developerWorks/cn/developerWorks?成）。并在隨后的
8、請求報文中分析數(shù)據(jù)并決定真正被訪問的服務節(jié)點，然后才與服務節(jié)點建立另一個連接，將
