【電腦網路】TCP關閉串連問題及注意

TCP狀態：
LISTEN：偵聽來自遠方的TCP連接埠的串連請求
SYN-SENT：再發送串連請求後等待匹配的串連請求
SYN-RECEIVED：再收到和發送一個串連請求後等待對方對串連請求的確認
ESTABLISHED：代表一個開啟的串連
FIN-WAIT-1：等待遠程TCP串連插斷要求，或先前的串連插斷要求的確認
FIN-WAIT-2：從遠程TCP等待串連插斷要求
CLOSE-WA IT：等待從本機使用者發來的串連插斷要求
CLOSING：等待遠程TCP對串連中斷的確認
LAST-ACK：等待原來的發向遠程TCP的串連插斷要求的確認
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到串連插斷要求的確認
CLOSED：沒有任何串連狀態

要分析這個原因那就得從關閉串連程的四次握手，有時也會是三向交握，說起。如所示：

 

大家都知道tcp正常的關閉串連要經過四次握手。如下所示：

在這四次握手狀態中，有一個特別要注意的狀態TIME_WAIT。這個狀態是主動關閉方在收到被關閉方的FIN後會處於並長期（2個MSL時間，根據具體的實現不同，這個值會不同，在RFC
1122建議MSL=2分鐘，但在Berkeley的實現上使用的值為30s,具體可以看www.rfc.net,要是沒有耐心去看英文的可以看這個網站www.cnpaf.net裡面有協議說明以及相應的源碼，java源碼中我沒有發現這個值，我只能追蹤到PlainSocketImpl.java這個類，再往下就是本地介面調用了，因此它是依賴本地作業系統的實現）處於的一個狀態。也就是大約1-4分鐘，然後由作業系統自動回收並將TCP串連設為CLOSED初始狀態。如所示：

         

TCP是一個連線導向的協議，所以在串連雙方發送資料之前，都需要首先建立一條串連。這和前面講到的協議完全不同。前面講的所有協議都只是發送資料而已，大多數都不關心發送的資料是不是送到，UDP尤其明顯，從編程的角度來說，UDP編程也要簡單的多----UDP都不用考慮資料分區。
書中用telnet登陸退出來解釋TCP協議串連的建立和中止的過程，可以看到，TCP串連的建立可以簡單的稱為三向交握，而串連的中止則可以叫做四次握手。
1.串連的建立
        在建立串連的時候，用戶端首先向伺服器申請開啟某一個連接埠(用SYN段等於1的TCP報文)，然後伺服器端發回一個ACK報文通知用戶端請求報文收到，用戶端收到確認報文以後再次發出確認報文確認剛才伺服器端發出的確認報文（繞口麼），至此，串連的建立完成。這就叫做三向交握。如果打算讓雙方都做好準備的話，一定要發送三次報文，而且只需要三次報文就可以了。
       可以想見，如果再加上TCP的逾時重傳機制，那麼TCP就完全可以保證一個資料包被送到目的地。
2.結束串連
       TCP有一個特別的概念叫做half-close，這個概念是說，TCP的串連是全雙工系統（可以同時發送和接收）串連，因此在關閉串連的時候，必須關閉傳和送兩個方向上的串連。客戶機給伺服器一個FIN為1的TCP報文，然後伺服器返回給用戶端一個確認ACK報文，並且發送一個FIN報文，當客戶機回複ACK報文後（四次握手），串連就結束了。
3.最大報文長度
      在建立串連的時候，通訊的雙方要互相確認對方的最大報文長度(MSS)，以便通訊。一般這個SYN長度是MTU減去固定IP首部和TCP首部長度。對於一個乙太網路，一般可以達到1460位元組。當然如果對於非本地的IP，這個MSS可能就只有536位元組，而且，如果中間的傳輸網路的MSS更佳的小的話，這個值還會變得更小。
4.TCP的狀態遷移圖
       書P182頁給出了TCP的狀態圖，這是一個看起來比較複雜的狀態遷移圖，因為它包含了兩個部分---伺服器的狀態遷移和用戶端的狀態遷移，如果從某一個角度出發來看這個圖，就會清晰許多，這裡面的伺服器和用戶端都不是絕對的，發送資料的就是用戶端，接受資料的就是伺服器。
4.1.用戶端應用程式的狀態遷移圖
     用戶端的狀態可以用如下的流程來表示：
             CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
以上流程是在程式正常的情況下應該有的流程，從書中的圖中可以看到，在建立串連時，當用戶端收到SYN報文的ACK以後，用戶端就開啟了資料互動地串連。而結束串連則通常是用戶端主動結束的，用戶端結束應用程式以後，需要經曆FIN_WAIT_1，FIN_WAIT_2等狀態，這些狀態的遷移就是前面提到的結束串連的四次握手。
4.2.伺服器的狀態遷移圖
       伺服器的狀態可以用如下的流程來表示：
                         CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
      在建立串連的時候，伺服器端是在第三向交握之後才進入資料互動狀態，而關閉串連則是在關閉串連的第二次握手以後（注意不是第四次）。而關閉以後還要等待用戶端給出最後的ACK包才能進入初始的狀態。
4.3.其他狀態遷移
      書中的圖還有一些其他的狀態遷移，這些狀態遷移針對伺服器和用戶端兩方面的總結如下

LISTEN->SYN_SENT，對於這個解釋就很簡單了，伺服器有時候也要開啟串連的嘛。
SYN_SENT->SYN收到，伺服器和用戶端在SYN_SENT狀態下如果收到SYN資料報，則都需要發送SYN的ACK資料報並把自己的狀態調整到SYN收到狀態，準備進入ESTABLISHED
SYN_SENT->CLOSED，在發送逾時的情況下，會返回到CLOSED狀態。
SYN_收到->LISTEN，如果受到RST包，會返回到LISTEN狀態。
SYN_收到->FIN_WAIT_1，這個遷移是說，可以不用到ESTABLISHED狀態，而可以直接跳轉到FIN_WAIT_1狀態並等待關閉。
4.4.2MSL等待狀態
        書中給的圖裡面，有一個TIME_WAIT等待狀態，這個狀態又叫做2MSL狀態，說的是在TIME_WAIT2發送了最後一個ACK資料報以後，要進入TIME_WAIT狀態，這個狀態是防止最後一次握手的資料報沒有傳送到對方那裡而準備的（注意這不是四次握手，這是第四次握手的保險狀態）。這個狀態在很大程度上保證了雙方都可以正常結束，但是，問題也來了。
由於插口的2MSL狀態（插口是IP和連接埠對的意思，socket），使得應用程式在2MSL時間內是無法再次使用同一個插口的，對於客戶程式還好一些，但是對於服務程式，例如httpd，它總是要使用同一個連接埠來進行服務，而在2MSL時間內，啟動httpd就會出現錯誤（插口被使用）。為了避免這個錯誤，伺服器給出了一個平靜時間的概念，這是說在2MSL時間內，雖然可以重新啟動伺服器，但是這個伺服器還是要平靜的等待2MSL時間的過去才能進行下一次串連。
4.5.FIN_WAIT_2狀態
       這就是著名的半關閉的狀態了，這是在關閉串連時，用戶端和伺服器兩次握手之後的狀態。在這個狀態下，應用程式還有接受資料的能力，但是已經無法發送資料，但是也有一種可能是，用戶端一直處於FIN_WAIT_2狀態，而伺服器則一直處於WAIT_CLOSE狀態，而直到應用程式層來決定關閉這個狀態。
5.RST，同時開啟和同時關閉
         RST是另一種關閉串連的方式，應用程式應該可以判斷RST包的真實性，即是否為異常中止。而同時開啟和同時關閉則是兩種特殊的TCP狀態，發生的機率很小。
6.TCP伺服器設計
       前面曾經講述過UDP的伺服器設計，可以發現UDP的伺服器完全不需要所謂的並發機制，它只要建立一個資料輸入隊列就可以。但是TCP不同，TCP伺服器對於每一個串連都需要建立一個獨立的進程（或者是輕量級的，線程），來保證對話的獨立性。所以TCP伺服器是並發的。而且TCP還需要配備一個呼入串連請求隊列（UDP伺服器也同樣不需要），來為每一個串連請求建立對話進程，這也就是為什麼各種TCP伺服器都有一個最大串連數的原因。而根據源主機的IP和連接埠號碼碼，伺服器可以很輕鬆的區別出不同的會話，來進行資料的分發。