TCP報文段首部格式
- 序列號seq: 占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號后，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。
- 確認號ack: 占4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文攜帶數據的第一個字節的編號；而確認號指的是期望收到下一個字節的編號；因此當前報文段最后一個自己的編號+1即為確認號。
- 確認ACK：占1位，僅當ACK=1時，確認號字段才有效。當ACK=0，確認號無效
- 同步SYN: 連接建立時用于同步序號。當SYN=1,ACK=0時表示:這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1,ACK=1,因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標志位只有在TCP建立連接時才會被置1，握手完成后SYN標志位被置0。
- 終止FIN: 用來釋放一個連接。FIN=1表示，此報文段的發送方的數據已經發送完畢，并要求釋放運輸連接。
TCP建立連接三次握手
（1）三次握手的過程
- 主機A向主機B發送TCP連接請求數據包，其中包含主機A的初始序列號seq(A)=x。（其中報文中同步標志位SYN=1,ACK=0,表示這是一個TCP連接請求數據報文；序號seq=x,表明傳輸數據時的第一個數據字節的序號是x）；
- 主機B收到請求后，會發回連接確認數據包。（其中確認報文段中，標識位SYN=1,ACK=1,表示這是一個TCP連接相應數據報文，并含有主機B的初始序列號seq(B)=y,以及主機B對主機A初始序列號的確認號ack(B)=seq(A)+1=x+1）
-
第三次，主機A收到主機B的確認報文后，還需作出確認，即發送一個序列號seq(A)=x+1;確認號為ack(A)=y+1的報文。
image.png
（2）為什么需要第三次握手？
還要再發送一次確認是為了，防止已失效的連接請求報文段突然又傳到了B，因而產生錯誤。
已失效的報文段：正常情況下：A發出連接請求，但因為丟失了，故而不能收到B的確認。于是A重新發出請求，然后收到確認，建立連接，數據傳輸完畢后，釋放連接，A發了2個，一個丟掉，一個到達，沒有“已失效的報文段”。
但是，某種情況下，A的第一個的某個節點滯留了，延誤到達，本來這是一個早已失效的報文段，但是在A發送第二個，并且得到B的回應，建立了連接以后，這個報文段竟然到達了，于是B就認為，A又發送了一個新的請求，于是發送確認報文段，同意簡歷連接，假若沒有三次的握手，那么這個連接就建立起來了（有一個請求和一個回應），此時，A收到B的確認，但A知道自己沒有發送建立連接的請求，因此不會理睬B的這個確認，于是呢，A也不會發送任何數據，而B呢確認為新的連接建立了起來，一直等待A發送數據給自己，此時B的資源就被白白浪費了。于是采用三次握手的話，A就不發送確認，那么B由于收不到確認，也就知道沒有必要建立連接。
簡而言之：第三次握手，主機A發送一次確認是為了防止：如果客戶端遲遲沒有收到服務器返回的確認報文，這時它會放棄連接，重新啟動一條連接請求；但問題是：服務器不知道客戶端沒收到，所以它會收到兩個連接請求，白白浪費了一條連接開銷。
TCP釋放連接四次揮手
（1）四次揮手過程
假設主機A為客戶端，主機B為服務器，其釋放TCP連接的過程如下：
- 關閉客戶端到服務器的連接：首先客戶端A發送一個FIN，用來關閉客戶到服務器的數據傳送，然后等待服務器的確認。其中終止標志位FIN=1，序列號seq=u;
- 服務器收到這個FIN，它發回一個ACK，確認號ack收到的序號加1；
- 關閉服務器到客戶端的連接：也就是發送一個FIN給客戶端
-
客戶端收到FIN后，并發回一個ACK報文確認，并將確認序號sql設置為收到序號加1
首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
image.png
主機A發送FIN后，進入終止等待狀態，服務器B收到主機A連接釋放報文段后，就立即給主機A發送確認，然后服務器B就進入close-wait狀態，此時TCP服務器進程就通知高層應用進程，因而從A到B的連接就釋放了。此時是“半關閉”狀態。即A不可以發送給B，但是B可以發送給A。
此時，若B沒有數據報要發送給A了，其應用進程就通知TCP釋放連接，然后發送給A連接釋放報文段，并等待確認。A發送確認后，進入time-wait，注意，此時TCP連接還沒有釋放掉，然后經過時間等待計時器設置的2MSL后，A才進入到close狀態。
（2）為什么要等待2MSL呢？
MSL即Maximum Segment Lifetime，也就是最大報文生存時間，它是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。引用《TCP/IP詳解》中的話：“它（MSL）是任何報文段被丟棄前在網絡內的最長時間”。RFC 793中規定MSL為2min，實際應用中常用的是30s、1min和2min等。
TCP的TIME_WAIT狀態需要等待2MSL，當TCP的一端發起主動關閉，在發出最后一個ACK包后，即3次揮手完成后發送了第四次揮手的ACK包后就進入了TIME_WAIT狀態，必須在此狀態上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最后一個ACK包對方沒收到，那么對方在超時后將重發第三次揮手的FIN包，主動關閉端接到重發的FIN包后可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的端口不能使用，要等到2MSL時間結束才可繼續使用。當連接處于2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置SO_REUESADDR選項達到不必等待2MSL時間結束再使用此端口。
概括原因如下： - 為了保證A發送的最后一個ACK報文段能夠到達B。即最后這個確認報文段很有可能丟失，那么B會超時重傳，然后A再一次確認，同時啟動2MSL計時器，如此下去。如果沒有等待時間，發送完確認報文段就立即釋放連接的話，B就無法重傳了（連接已被釋放，任何數據都不能重傳了），因而也就收不到確認，就無法按步驟進入CLOSE狀態，即必須受到確認才能close。
- 防止“已失效的連接請求報文段”出現在連接中。經過2MSL，那些在這個連接持續的時間內，產生的所有報文段就可以都從網絡中消失。即在這個連接釋放的過程中會有一些無效的報文段停滯在某個節點，但是呢，經過2MSL這些無效報文段就肯定可以發送到目的地，不會滯留在網絡中。這可以看出：B結束TCP連接的時間比A早一點，因為B受到確認就斷開連接了，而A還得等待2MSL。
（2）為什么TCP釋放連接需要四次？
TCP建立連接需要進行三次握手，而斷開連接要進行四次。這是由于TCP的半關閉造成的。因為TCP連接是全雙工的（即數據可在兩個方向上同時傳遞），所以進行關閉時每個方向上都要單獨進行關閉。這個單方向的關閉就叫半關閉。當一方完成它的數據發送任務，就發送一個FIN來向另一方通告將要終止這個方向的連接。
注意： - 發送了FIN只是表示這端不能繼續發送數據（應用層不能再調用send發送），但是還可以接受數據。收到一個FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍然能發送數據，比如：如主機A收到主機B的FIN斷開TCP連接請求，只是表示主機B已經發送完數據，主機A收到FIN后作出應答，并終止這個方向的數據傳輸，此時處于半關閉狀態。但是主機A仍然可以發送數據，只有當主機A發送完數據后并發送FIN給主機B時，主機B才停止這個方向的數據傳輸，并關閉TCP連接。
- 在很多時候，TCP連接的斷開都會有TCP層自動關閉。
