TCP(Transmission Control Protocol)　傳輸控制協議

TCP是主機對主機層的傳輸控制協議，提供可靠的連接服務，采用三次握手確認建立一個連接:

位碼即tcp標志位,有6種標示:

SYN(synchronous建立聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼)

TCP報文頭部

TCP建立連接

如上圖所示 TCP建立連接的過程。 A是主動打開服務的,B是被動打開服務的

1.B的TCP服務器進程先創建傳輸控制塊TCB（Transmission Control Block 存儲了每個連接中的一些重要信息，如：TCP連接表，到發送和接收緩存的指針，到重傳隊列的指針，當前的發送和接受序號，等）,準備接收客戶進程的連接請求，然后服務器進程就處于LISTEN狀態,等待客戶的連接請求.如有,就做出響應.

A的TCP客戶進程也是先創建傳輸控制塊,然后向B發出連接請求報文段,這時候首部中的同步位SYN=1,同時選擇一個初始序號 seq=x。TCP規定,SYN報文段(SYN=1的報文段) 不能攜帶數據,但要消耗一個序號.這時,TCP客戶進程進入SYN-SENT狀態.

2.B收到連接請求報文段后,如同意建立連接,則向A發送確認.在確認報文段中,應把SYN和ACK位都置1,確認號是ack=x+1，同時也為自己選擇一個初始序號seq=y。這個報文段也不能攜帶數據,同樣要消耗一個序號.這時TCP服務器進程進入SYN-RCVD(同步收到)狀態.

3.TCP客戶進程收到B的確認后,還要向B給出確認。確認報文段的ACK置1，確認號ack=y+1，而自己的序號seq=x+1。TCP的標準規定，ACK報文段可以攜帶數據。但如果不攜帶數據則不消耗序號，這種情況下，下一個數據報文段的序號仍是seq=x+1。這時，TCP連接已經建立，A進入ESTABLISHED（已建立連接）狀態。

當B收到A的確認后，也進入ESTABLISHED狀態。

為什么要有第三次確認?

這主要是為了防止已失效的連接請求報文段突然又傳送到了B,因而產生錯誤.

假設沒有客戶端的第三次確認。A發送連接請求，但連接請求丟失而未收到B的確認，于是A重新發出了一次請求連接，后來B收到了請求，發出確認建立了連接，在完成通信后連接釋放，成功完成一次通信。A雖發送了兩次連接請求,但第一次丟失,第二次成功,所以此時不存在已失效的連接請求報文。現假設A第一次發送的連接請求報文因為網絡問題長時間滯留了，到第二次通信完成釋放連接后才到達B,這就是一個已失效的報文,但此時B以為是A的又一次連接請求,于是發出了確認,若沒有第三次確認,連接就成功建立了。由于A現在并沒有發出建立請求,所以B回復的確認A不理睬,所以不與B進行通信,然而B就一直等著A發數據給他,就這樣,B傻乎乎的等了很久,白白浪費了自己的青春(B的資源)。

TCP釋放連接

1.數據傳輸結束后，通信雙方都可釋放連接。現在A,B都處于ESTABLISHED狀態。A先發送連接釋放報文段，并停止在發送數據，主動關閉TCP連接。A把連接釋放報文段首部離得FIN置1，其序號seq=u，u等于前面已發送的數據的最后一個字節的序號加1.這是A進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。TCP規定，FIN報文段即使不攜帶數據，也消耗一個序號。

2.B收到連接釋放報文段后即發出確認，確認號是ack=u+1,而這個報文段自己的序號是v，等于B前面已發送的數據的最后一個字節的序號加1.然后B進入CLOSE-WAIT(關閉等待)狀態。至此A->B的連接就釋放了，這時TCP連接處于半關閉（half-close）狀態，即A已經沒有數據要發送了，但B若發送數據，A仍然接收。

3.A收到B的確認后，就進入FIN-WAIT-2(終止等待2)狀態，等待B發出的連接釋放報文段。若B已經沒有數據要發給A，其應用進程就通知TCP釋放連接。這時B發出的連接釋放報文段必須使FIN=1.假定B的序號是w（在半關閉狀態B可能又發送了一些數據）。B還必須從夫上次已發送過的確認號ack=u+1。這時B進入LAST-ACK狀態，等待A確認。

4.A在收到B的連接釋放報文段后，必須對此發出確認。在確認報文段中把ACK置1，確認號ack=w+1，自己的序號為seq=u+1（前面發送的FIN報文段要消耗一個序號）。然后進入TIME-WAIT（時間等待）狀態。現在TCP連接還沒有釋放掉。必須經過時間等待計時器（TIME-WAIT timer）設置的時間2MSL后，A才進入到CLOSED狀態。（MSL：Maximum Segment Lifetime 最長報文段壽命）

為什么在TIME-WAIT要等待呢？

1.為了保證A發送的最后一個ACK報文段能夠到達B。這個ACK報文段可能丟失，因而使處在LAST-ACK狀態的B收不到確認。B會超時重傳FIN+ACK報文段，A就能在2MSL時間內收到這個重傳的FIN+ACK報文段，接著A重傳一次確認，重啟計時器。最好，AB都正常進入到CLOSED狀態。如果A在TIME-WAIT狀態不等待一段時間，而是再犯送完ACK報文后立即釋放連接，那么就無法收到B重傳的FIN+ACK報文段，因而也不會在發送一次確認報文。這樣，B就無法按照正常步驟進入CLOSED狀態。

2.防止 已失效的連接請求報文出現在本連接中。

轉載自：http://blog.chinaunix.net/uid-26413668-id-3376762.html