F5會話處理流程描述參數說明及QA201X0120

1、.f5 會話處理流程（參數說明）及q&a一. tcp狀態(tài)轉換圖1、建立連接協(xié)議（三次握手） （1）客戶端發(fā)送一個帶syn標志的tcp報文到服務器。這是三次握手過程中的報文1。 （2） 服務器端回應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ack標志和syn標志。因此它表示對剛才客戶端syn報文的回應；同時又標志syn給客戶端，詢問客戶端是否準備好進行數據通訊。 （3） 客戶必須再次回應服務段一個ack報文，這是報文段3。2、連接終止協(xié)議（四次握手）精品. 由于tcp連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發(fā)送任務

2、后就能發(fā)送一個fin來終止這個方向的連接。收到一個 fin只意味著這一方向上沒有數據流動，一個tcp連接在收到一個fin后仍能發(fā)送數據。首先進行關閉的一方將執(zhí)行主動關閉，而另一方執(zhí)行被動關閉。（1） tcp客戶端發(fā)送一個fin，用來關閉客戶到服務器的數據傳送。（2） 服務器收到這個fin，它發(fā)回一個ack，確認序號為收到的序號加1。和syn一樣，一個fin將占用一個序號。（3） 服務器關閉客戶端的連接，發(fā)送一個fin給客戶端。（4） 客戶段發(fā)回ack報文確認，并將確認序號設置為收到序號加1。3、連接狀態(tài)說明closed: 這個沒什么好說的了，表示初始狀態(tài)。list

3、en: 這個也是非常容易理解的一個狀態(tài)，表示服務器端的某個socket處于監(jiān)聽狀態(tài)，可以接受連接了。syn_rcvd: 這個狀態(tài)表示接受到了syn報文，在正常情況下，這個狀態(tài)是服務器端的socket在建立tcp連接時的三次握手會話過程中的一個中間狀態(tài)，很短暫，基本上用netstat你是很難看到這種狀態(tài)的，除非你特意寫了一個客戶端測試程序，故意將三次tcp握手過程中最后一個ack報文不予發(fā)送。因此這種狀態(tài)時，當收到客戶端的ack報文后，它會進入到established狀態(tài)。syn_sent: 這個狀態(tài)與syn_rcvd遙想呼應，當客戶端socket執(zhí)行connect

4、連接時，它首先發(fā)送syn報文，因此也隨即它會進入到了syn_sent狀態(tài)，并等待服務端的發(fā)送三次握手中的第2個報文。syn_sent狀態(tài)表示客戶端已發(fā)送syn報文。established：這個容易理解了，表示連接已經建立了。fin_wait_1: 這個狀態(tài)要好好解釋一下，其實fin_wait_1和fin_wait_2狀態(tài)的真正含義都是表示等待對方的fin報文。而這兩種狀態(tài)的區(qū)別是：fin_wait_1狀態(tài)實際上是當socket在established狀態(tài)時，它想主動關閉連接，向對方發(fā)送了fin報文，此時該socket即進入到fin_wait_1狀態(tài)。而當對方回應ack報文后，則進入到

5、精品.fin_wait_2狀態(tài)，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ack報文，所以fin_wait_1狀態(tài)一般是比較難見到的，而fin_wait_2狀態(tài)還有時常?？梢杂胣etstat看到。fin_wait_2：上面已經詳細解釋了這種狀態(tài)，實際上fin_wait_2狀態(tài)下的socket，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你，稍后再關閉連接。time_wait: 表示收到了對方的fin報文，并發(fā)送出了ack報文，就等2msl后即可回到closed可用狀態(tài)了。如果fin_wait_1狀態(tài)下，收到了對方同時帶fin標

6、志和ack標志的報文時，可以直接進入到time_wait狀態(tài)，而無須經過fin_wait_2狀態(tài)。closing: 這種狀態(tài)比較特殊，實際情況中應該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當你發(fā)送fin報文后，按理來說是應該先收到（或同時收到）對方的ack報文，再收到對方的fin報文。但是closing狀態(tài)表示你發(fā)送fin報文后，并沒有收到對方的ack報文，反而卻也收到了對方的fin報文。什么情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個socket的話，那么就出現了雙方同時發(fā)送fin報文的情況，也即會出現closing狀態(tài)，表

7、示雙方都正在關閉socket連接。close_wait: 這種狀態(tài)的含義其實是表示在等待關閉。怎么理解呢？當對方close一個socket后發(fā)送fin報文給自己，你系統(tǒng)毫無疑問地會回應一個ack報文給對方，此時則進入到close_wait狀態(tài)。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發(fā)送給對方，如果沒有的話，那么你也就可以close這個socket，發(fā)送fin報文給對方，也即關閉連接。所以你在close_wait狀態(tài)下，需要完成的事情是等待你去關閉連接。last_ack: 這個狀態(tài)還是比較容易好理解的，它是被動關閉一方在發(fā)送fin報文后，最后等待對方的ack

8、報文。當收到ack報文后，也即可以進入到closed可用狀態(tài)了。精品.二. f5 tcp 連接管理及參數說明1. f5 tcp建立過程及相關參數說明如圖：standard vs/tcp profile的連接建立過程如圖：standard vs/tcp/http profile(七層應用)的連接建立過程2. f5 tcp rst過程及tcp porfile中reset on timeout選項 f5 vs 收到任何一方會話中發(fā)送的rst包，f5 vs行為為立即轉發(fā)，并清除f5中本會話連接。 精品.tcp porfile中reset on timeout選項,意為當f5 vs中的會話超出idle

9、超時時間值后， f5 vs將向客戶端、服務器同時發(fā)rst，并刪除自身vs中會話鏈接。此項默認值為啟用狀態(tài)。 3. f5 tcp關閉過程及相關參數說明下圖是客戶端主動發(fā)起關閉應用時的tcp連接關閉過程以及f5設備相應狀態(tài)，總體上在這種情況下，f5會首先通過四次握手先關閉服務器端tcp連接，再關閉客戶端連接具體如下圖所示：下圖是服務器端主動發(fā)起關閉應用時的tcp連接關閉過程以及f5設備相應狀態(tài)，總體上在這種情況下，f5會首先通過四次握手先關閉客戶端tcp連接，再關閉服務器端連接具體如下圖所示：精品.針對以上參數，f5設備上相關的配置項time wait2000 (缺省)optionsspecify

10、: user specified amount of time (in milliseconds) that a tcp connection remains in the time-wait state before entering the closed statethis setting specifies the length of time (in milliseconds) that a tcp connection remains in the time-wait state before entering the closed state.精品.immediate: this

11、option specifies that the system closes the connection immediately after the connection enters the time-wait state indefinite: this option specifies that tcp connections can remain in the time-wait state indefinitelyfin wait5 (default)options:specify: user specified amount of time (in seconds) that

12、a tcp connection is in the fin-wait or closing state before closingimmediate: this option specifies that the tcp connection closes immediately after entering the fin-wait or closing stateindefinite: this option specifies that tcp connections in the fin-wait or closing state do not quitthis setting s

13、pecifies the length of time (in seconds) that a tcp connection is in the fin-wait or closing state before closing.close wait5 (default)options:specify: user specified amount of time (in seconds) that a tcp connection remains in the last-ack state before quittingimmediate: this option specifies that

14、the tcp connection closes immediately after entering the last-ack stateindefinite: this option specifies that tcp connection in the last-ack state do not close until they meet the maximum retransmissions timeout.this setting specifies the length of time (in seconds) that a tcp connection remains in

15、the last-ack state before quitting.三. f5 standard vs/tcp profile / standard vs/tcp/http profile(七層應用) 時間值及行為產品 ：f5 big ip 8400(os:9.3.1)tcp-idle-timeoutsyn-timeoutrstfin-waitclose-waittime-waitpersistencestandard vs/tcp profile / standard vs/tcp/http profile(七層應用) 300s與 tcp idle-timeout相同 0秒5秒5秒2s60

16、分(自定義）四. f5 vs 異常場景行為及計時器的使用 精品.場景產品 ：f5 big ip 8400(os:9.3.1)tcp-idle-timeoutsyn-timeoutrstfin-waitclose-waittime-waitpersistencestandard vs/tcp profile / standard vs/tcp/http profile(七層應用) 300s與 tcp idle-timeout相同 0秒5秒5秒2s60分(自定義）場景行為 &超時后行為雙向發(fā)rst雙向發(fā)rst雙向發(fā)rst雙向發(fā)rst雙向發(fā)rst根據負載均衡算法，重新分發(fā)1異常情況下：客戶端

17、發(fā)syn-> f5 syn_ack后，客戶端不再發(fā)ack包，f5對此會話如何處理（對客戶端）？自身對本會話如何處理？f5 此時對會話的響應所使用的計時器是那個，時間值是多少，即synwait timeout是多少？這種情況f5會進入半連接狀態(tài),一直等到idle timeout超時(缺省設置為300s),該計時器在tcp profile中可定義.不刷新不刷新2針對tmos 9.3.1版本中,后臺server全部down掉的情況下,客戶端對f5vs 進行建鏈請求，f5 vs完成tcp 三次握手后，立即向客戶端發(fā)送rst包，此時，客戶端同時向f5發(fā)http get請求，這時，f5對客戶端后面這

18、個http get 請求，其行為是什么？是否發(fā)reset包?（應用系統(tǒng)故障時，抓包，未看到后面的f5發(fā)的rst包）1、f5在發(fā)出第一個reset后，會立即清除自身的連接。2、對于f5后續(xù)收到http get 請求，因沒有匹配的session,f5會將該包丟棄.在9.3.1版本中，不再發(fā)reset.不刷新精品.3正常狀態(tài)下（f5 vs、member服務器正常），客戶端發(fā)rst包，f5的如何處理響應，對自身會話如何處理，計時器用那個，時間是多少？同樣，如服務器端發(fā)rst包，f5如何處理響應，對自身會話如何處理，計時器用那個，時間是多少？ 如后續(xù)在此會話上，仍有相同的數據請求到達f5 vs，f5如何

19、處理響應 ，對自身會話如何處理，計時器用那個，時間是多少無論是客戶端還是服務器端發(fā)送reset給f5的vs,f5會立即清除相關的連接，沒有相關聯的計時器4正常狀態(tài)下，在tcp profile中選擇reset on timeout后， f5到了tcp-idletimeout 后主動向服務器端、客戶端同時發(fā)rst并立即拆除session。此時，如后續(xù)客戶端有數據請求包到f5 vs，而f5此時已清除了session，那么f5如何響應客戶端的請求，是發(fā)rst包給客戶端，還是新建或直接丟棄？計時器使用那個？如果是新的連接（syn 請求），重新建立連接；如果是其它狀態(tài)的包，由于沒有匹配的session,f

20、5會將該包丟棄。并且f5 向請求方（客戶端）發(fā)rst。5正常狀態(tài)下（f5 vs、member服務器正常），客戶端與f5 vs之間、f5與member(ser)均已完成建鏈，此時，后臺member服務器服務port down/up,存在兩種情況：(f5 的poolmember monitor interval 5s timeout 16s） a. 如member 的服務port 在16s內（含）一直為down狀態(tài) 客戶端后續(xù)數據請求包，f5如何處理響應？f5 vs本身對此session的如何處理？f5在是否會直接將后續(xù)請求包直接發(fā)給其他member? 還是f5vs 保持與客戶端當前會話，f5與其

21、也member建鏈，然后，再將其轉發(fā)至新vs member中？還是f5會強制客戶端重新建鏈，重新分配會話到其他member.f5會清除原有session。強制客戶端重新建鏈，重新分配會話到其他member.f5處理方法 （雙向發(fā)rst包，對客戶端、服務器），對自身session 行為：立即清除。精品.6b . 如pool member 的服務port 在16s內（含）恢復up服務狀態(tài) 客戶端后續(xù)數據請求包，f5如何處理響應？f5 vs本身對此session的如何處理？廠商回復： f5會視作服務器正常，處理數據包行為沒有改變。7f5 vs 為standar 類型，vs中的member 全down

22、后，vs對外仍提供會話建鏈，屬f5正常機制（vs屬性），非版本區(qū)別？廠商回復：正常機制，所有版本都是這種方式精品.8f5 vs 收到fin （首個fin包，不區(qū)分服務器、客戶端） 后，轉發(fā)給另一端（服務器或客戶端），進行fin wait 1狀態(tài)，并進入5s的超時計時。如首個fin的ack包未能在5s內收到 ，f5的行為是什么？以什么行為向pcserver拆鏈,即 f5設備vs 在fin-time out的動作行為。廠商回復： f5設備在fin time out 后如果在tcp profile中選擇reset on timeout后,會觸發(fā)向客戶端和服務器端同時發(fā)送reset數據包,同時刪除相關

23、連接表,如果不選擇reset on timeout ,f5設備只清除本地相關連接表,不做其它動作處理.9 f5 收到第一個fin包(不管clientserver)， fin timeout進入5秒超時計時，此值非絕對值，即如后續(xù)有包匹配session，即觸發(fā)timer 重新計時 ? 這種機制是否對close wait 計時器同等生效？ 如close wait計時器與 fin wait計時器刷新機制不一致，那么下面情況下，f5對會話的處理響應行為是什么？ 等待中，數據包匹配，刷新重新計時等待中，數據包匹配，刷新重新計時等待中，數據包匹配，刷新重新計時10 以客戶端發(fā)起fin為例，當f5收到cli

24、ent fin后，進入close wait狀態(tài)，并開始計時器倒計時，如f5與server之間的兩個fin過程超出5s時或仍有數據傳送，f5將會在close wait計時器倒計時5s后，根據上面的第一點的行為（選擇reset on timeout),是否進行reset雙向拆鏈。廠商回復：無論是在close-wait,還是last-ack狀態(tài)下都會進行5s倒計時。超過該時間設定，reset on timeout拆連接。五. f5 q &a場景： 硬件： f5 big-ip ltm 8400軟件 ： 9.3.1 37.1vs type : 主機virtual serverprofile :

25、standard vs/tcp profile / standard vs/tcp/http profile(七層應用) 1、關于f5 vs建立tcp會話時的tcp  syn 包的處理行為q&a    上面的截取的客戶端與f5的tcp建鏈過程： 1）、正常情況下，f5的與客戶端的完成三次握手的建鏈時間是多少（client syn-> f5 syn_ackclient ack)？ 廠商回復：這個要根據網絡的具體情況(延時,帶寬等)而異,附件是我的一個正常訪問的數據抓包,可以參考一下.精品.2）、異常情況下：客戶端發(fā)syn->

26、f5 syn_ack后，客戶端不再發(fā)ack包，f5對此會話如何處理（對客戶端）？自身對本會話如何處理？f5 此時對會話的響應所使用的計時器是那個，時間值是多少，即synwait timeout是多少？廠商回復：這種情況f5會進入半連接狀態(tài),一直等到idle timeout超時(缺省設置為300s),該計時器在tcp profile中可定義. 2、關于f5 vs對會話中tcp  rst數據包的處理行為 1)  針對tmos 9.3.1版本中,后臺server全部down掉的情況下,客戶端對f5vs 進行建鏈請求，f5 vs完成tcp 三次握手后，

27、立即向客戶端發(fā)送rst包，此時，客戶端同時向f5發(fā)http get請求，這時，f5對客戶端后面這個http get 請求，其行為是什么？是否發(fā)reset包?（應用系統(tǒng)故障時，抓包，未看到后面的f5發(fā)的rst包）。廠商回復： f5對rst后收到http get 請求，因無會話將直接丟棄，在當前9.3.x版本，不會發(fā)rst包.（f5 case ：case number c620307確認）1、f5在發(fā)出第一個reset后，會立即清除自身的連接。2、對于f5后續(xù)收到http get 請求，因沒有匹配的session,f5會將該包丟棄.在9.3.1版本中，不再發(fā)reset. 

28、60;2)正常狀態(tài)下（f5 vs、member服務器正常），客戶端發(fā)rst包，f5的如何處理響應，對自身會話如何處理，計時器用那個，時間是多少？同樣，如服務器端發(fā)rst包，f5如何處理響應，對自身會話如何處理，計時器用那個，時間是多少？   如后續(xù)在此會話上，仍有相同的數據請求到達f5 vs，f5如何處理響應 ，對自身會話如何處理，計時器用那個，時間是多少？廠商回復：無論是客戶端還是服務器端發(fā)送reset給f5的vs,f5會立即清除相關的連接，沒有相關聯的計時器。 3)、正常狀態(tài)下，在tcp profile中選擇reset on timeout后，  f

29、5到了tcp-idletimeout 后主動向服務器端、客戶端同時發(fā)rst并立即拆除session。此時，如后續(xù)客戶端有數據請求包到f5 vs，而f5此時已清除了session，那么f5如何響應客戶端的請求，是發(fā)rst包給客戶端，還是新建或直接丟棄？計時器使用那個？精品.  廠商回復：如果是新的連接（syn 請求），重新建立連接；如果是其它狀態(tài)的包，由于沒有匹配的session,f5會將該包丟棄。 4)、正常狀態(tài)下（f5 vs、member服務器正常），客戶端與f5 vs之間、f5與member(ser)均已完成建鏈，此時，后臺member服務器服務port down/up

30、,存在兩種情況：(f5 的poolmember monitor interval 5s timeout 16s）   a. 如member 的服務port 在16s內（含）一直為down狀態(tài)         客戶端后續(xù)數據請求包，f5如何處理響應？f5 vs本身對此session的如何處理？f5在是否會直接將后續(xù)請求包直接發(fā)給其他member? 還是f5vs 保持與客戶端當前會話，f5與其也member建鏈，然后，再將其轉發(fā)至新vs member中？還是f5會強制客戶端重新建鏈，重新分配會話到其他member.廠商回復：f5會清除原有session。強制客戶端重新建鏈，重新分配會話到其他member.f5處理方法 （雙向發(fā)rst包，對客戶端、服務器），對自身session 行為：立即清除。     b . 如pool member 的服務port 在16s內（含）恢復up服務狀態(tài)      客戶端后續(xù)數據請求包，f5如何處理響應？f5