用TCP連線分析TUXEDO的WS模式

Abstract: 關於中介軟體，有一個很有名的定義是：平臺+通訊。這一點在TUXEDO上面得到了很好的體現，因為它提供了執行和開發的平臺，以及多種的通訊方式。在這多種通訊方式中，使用最頻繁的是WS（workstation）方式。WS方式使用的是TCP連線，為了對WS方式有更多的瞭解，我們結合TCP連線的知識對這種方式進行了一個比較深入的分析。

名詞說明:

WSC: WorkStation Client               WSL: WorkStation Listener

WSH: WorkStation Handler            Server: 小寫表示伺服器端的服務處理程式

 

TCP連線是一種C/S模式的，即server端公開自己的IP和埠號，client通過這兩個引數與之建立連線，客戶端使用的埠一般是OS臨時分配的。

TCP server端一般有兩種模式，一種是iterative(重複)的，一種concurrent（併發）的。前面一種是一個server的程式（應用層）來處理client的請求，處理完了之後繼續接受請求來處理，當server正在處理的過程中，新來的請求得不到處理，只有等待。後面一種是請求到來的時候，server 程式通常會新開一個程式來處理這個請求，自己繼續監聽公開埠的連線請求。

在TUXEO這種事務處理系統中，會經常有大量的請求，故第一種模式肯定是不行的，第二種模式雖然可以達到同時處理不同請求的目的，但是由於每次要開新的程式，系統的開銷很大，也會影響效能。實際中，TUXEDO的Workstation方式採用了另一種方法來實現多請求的併發處理。下面我們進行詳細的說明。

以下是ubb中關於WSL的配置引數：

WSL              SRVGRP=Group1 SRVID=200

                     CLOPT="-A -t -- -n //ip（伺服器IP，在此隱去）:4050 -m 2 -M 10 -x 10"

其中ip:4050就是TUXEDO伺服器的WSL的監聽地址，只有一個WSL程式。-m引數指定的是啟動時WSH的個數，-M為最大個數（使用者數大於m*x時系統會自動啟動更多的WSH），-x為每個WSH可以多道處理請求的最大數目，可以理解為WSH的請求緩衝區可以存放十個請求。這樣我們上面的配置在啟動後可以處理同時20個併發請求，最大可以處理100個。

根據這個配置和相關引數的解釋，我們就可以知道TUXEDO採用的處理模式了，TUXEDO在上面TCP的第二種方式之上進行了改進。監聽程式還是隻有一個(WSL)，但是事先已經起了多個處理請求的程式(WSH)，每個WSH又可以處理多個請求，這樣就保證了大量的請求能同時得到處理，也省去了臨時開服務程式的開銷。

為了很好的理解整個工作過程，我們首先來看一下WSC連上來的時候的一些步驟。

圖1： WSC連線的工作示意圖（摘自TUXEDO文件：ADCF04-WS

http://e-docs.bea.com/tuxedo/tux80/atmi/adwsc4.htm）

 

上圖很清晰的說明了連線的過程。

這裡還需要理解是WSH和server程式之間的關係。因為大家知道，真正處理client請求的是server程式，所有的業務處理，以及和資料庫相關的操作都是在server程式中完成的，這也是我們TUXEDO應用開發主要做的部分。我的理解是WSH可以看成是WSC在本地的一個代理。WSH收到WSC的請求資料,放在緩衝區，然後發給server程式來處理，因為在同一臺機器上，一般採用本地程式間通訊的機制，效率比較高。Server處理完後將結果返回給WSH，WSH再將結果返回給WSC，這個過程中WSH和WSC是保持著TCP連線的，而server程式並不直接和WSC打交道。

       以上的過程也可以參考下圖：

圖2： WS方式的連線步驟和相關模組說明圖

 

需要解釋的是WSH和server之間的粗線箭頭。因為WSH和server直接是多對多的關係，每個WSH可以把請求發給多個server，每個server也可以接受多個WSH發來的請求。

還有一個問題就是TCP應用是和機器的物理埠繫結的，既然WSL和WSH都要和WSC進行TCP通訊，而且很可能是同時的，那麼就必須使用不同的埠。這個我們在後面會進行相關的說明。為了簡便起見，我將server和WSC都實現在同一臺機器上，因為是WS方式，同樣會進行TCP連線，和兩臺機器之前的情況是一樣的，但是資料流會採用迴環（loopback）裝置，但不影響我們對問題的說明。

結合上面的WSL設定，我們在Windows的工作管理員中看到一個WSL程式和兩個WSH程式。

下面我們結合TCP的知識來說明WS方式中的連線動作。為便於資料的說明，這裡給出一個TCP狀態的變遷圖。限於篇幅，這裡不作解釋，請大家參考相關的書籍。

                                        

圖3：TCP狀態變遷圖

 

下面是在Windows command視窗用netstat看到的輸出，並給出相關的解釋說明。

圖4：netstat輸出1，關於WSC和WSL連線

 

輸出的前面兩行是處在TIME_WAIT狀態的連線，是之前試驗留下的連線，要等到兩個MSL(Maximum Segment Lifetime)的時間後結束。

第三個是當前WSC到WSL的連線，這裡地址顯示的主機名和埠號。由於WSC和WSL的連線建立時間極短，我們沒能看到WSC和WSL連線的ESTABLISHED狀態，看到的是進入FIN_WAIT_2狀態（從WSC角度）和CLOSE_WAIT狀態(從WSL角度)的連線。這個狀態表明WSC發起了active close,傳送了FIN並收到ACK，但是還沒有收到WSL的FIN結束請求，連線處於half-close狀態。CLOSE_WAIT表示WSL收到WSC的FIN請求，併發回ACK，與上面的WSC的FIN_WAIT_2狀態正好對應。

在上圖的第二個netstat輸出中，我們就可以看到使用埠號1544的WSC連線進入到TIME_WAIT狀態了，與前面兩個連線一樣。

 

圖5：netstat輸出1，關於WSC和WSH連線

 

在上面的圖4中，我們說明了WSC和WSL的連線。現在我們來看一下WSC和WSH的連線。由於呼叫的是TOUPPER服務，請求的處理時間極短，所以在圖4中沒有看到WSC和WSH的連線。為了觀察到這個連線，特意在tpinit和tpterm之間加入了一個函式呼叫sleep(10)，讓WSC睡眠10s，這樣連線就被保持了，在這個過程中，我們用netstat看到了上面的輸出。

大家知道在TCP連線中，一般client使用的埠號都是OS臨時分配的，通常是順序使用的。但是這裡除了我們指定的4050埠（WSL）和單調增長的15XX WSC埠外，還有一個3212埠，這個就是WSH使用的埠。筆者經過多次反覆的上述試驗，發現在ESTABLISHED狀態的連線中SERVER端的埠號都是3212和下圖中的3213，因而推測這就是我們的兩個WSH分別使用的埠。

從上圖，我們分析出的連線過程是，WSC先和WSL建立連線，然後WSC從WSL處得到WSH的埠號，和WSH建立連線，來完成事務處理。由於WSL是唯一的，要被多個WSC使用，所以WSC和WSL的連線是非常短暫的。這與圖1中的過程是吻合的，但是我們沒有能看到STEP2中WSL和WSH通訊的過程。

 

圖6：netstat輸出1，關於WSC和WSH連線特性

 

       根據圖4和圖5，我們詳細分析了兩個連線的過程。下面我們分析一下圖6的輸出。

WSC通過埠1548和WSL建立連線後，很快進入TIME_WAIT,如圖6的第一個netstat的第五行（只計TCP行）連線所示。第六行和第七行，WSC用埠1549和WSH（埠3213）建立連線，由於上面提到的sleep(10)而處於ESTABLISHED狀態。由於WSC和WSL的連線是要延時關閉的，結合前後輸出我們可以確認上述1549埠是被1548埠的WSC使用的。這就是說WSC和WSH建立連線會採用一個新的埠，這是由於TCP的性質決定的。在很多的TCP實現中，處在2MSL等待狀態的埠是不能馬上被使用的，所以WSC必須使用一個新的埠1549來和WSH連線。

       下面我們來看看另一個有趣的地方。前面說到WSC和WSL的連線很快進入到TIME_WAIT的狀態，那麼WSC和WSH的連線是否也是這樣的呢？從圖6的第二個netstat結果中，我們發現不是這樣的。因為1549和3213的連線“不見”了，而並沒有進入其他TCP狀態轉換圖中的狀態。而這時1548的連線還處在TIME_WAIT狀態中，表明還沒有完成Windows 版TCP/IP實現的2MSL時間。後面的使用1550埠的其它連線也已經建立了，唯獨其中的1549連線完全的結束了。這就說明WSC和WSH的連線採用的是結束後立即終止的方法。這樣做的好處是可以很快的釋放埠，避免client的主機埠被耗盡，特別是在請求發起很多的時候。我們知道主機的埠號在0－65535之間，而且很多是被保留，WSC無法使用的。

       經過上面的分析，相信大家對TUXEDO的WS方式的連線過程有了一個比較清晰的認識。WS方式是實際中使用最多的方式，對這種方式的理解有助於我們的應用開發和對相關係統狀況的分析和故障的檢查。以上假設大家有相關的TUXEDO開發經驗，能完成TOUPPER的WS版的配置和實現即可，另外還要求對TCP協議有相關的瞭解。希望對大家學習TUXEDO或者網路知識有幫助。對以上的過程還可以進行更細緻的分析，例如捕獲相關的資料包，監聽埠等。這裡有一些是我自己的理解，也希望大家批評指正。

 

後記：

以上是最近在深入學習網路方面的知識，對TCP/IP有了更深的認識和了解之後，結合自己之前在TUXEDO方 面的工作和實踐，並做了相關的試驗而分析出的一些看法和理解。我覺得這是一個很好的方式：結合正在使用的軟體來學習網路的原理，也參考這些原理來理解實際 的過程。而不僅僅是記得那些協議和規定，或者開發只知其然，不知其所以然的應用。協議和軟體一樣是在不斷髮展的，借用參考資料中Larry Peterson的一句話就是我們更重要的是要去理解為什麼協議要這樣實現。

 

 

參考資料：

1．  TUXEDO  e-docs 官方文件。

2．  TCP/IP Illustrated V1: The Protocols    W. Richard Stevens

3．  Computer Networks: A System Approach(2^nd) Larry Peterson & Bruce Davie

 

 

    2003.11 HUST, Wuhan
轉自：http://blog.csdn.net/rockyqiu2002/archive/2004/08/21/80859.aspx