知識點 - tcp協議建立連接 為什麽是三次握手 而 斷開連接需要四次？
阿新 • • 發佈：2018-02-27
重新 小寫 term 新的 請求 syn 完成後 字段 防止 在談及TCP建立連接和釋放連接過程，先來簡單認識一下TCP報文段首部格式的的幾個名詞（這裏只是簡單說明，具體請查看相關教程）
序列號seq：占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。
確認號ack：占4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；因此當前報文段最後一個字節的編號+1即為確認號。
確認ACK：占1位，僅當ACK=1時，確認號字段才有效。ACK=0時，確認號無效
終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接 PS：ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麽是1，要麽是0；ack、seq小寫的單詞表示序號。
2）主機B收到請求後，會發回連接確認數據包。（其中確認報文段中，標識位SYN=1，ACK=1，表示這是一個TCP連接響應數據報文，並含主機B的初始序列號seq(B)=y，以及主機B對主機A初始序列號的確認號ack(B)=seq(A)+1=x+1）
3）第三次，主機A收到主機B的確認報文後，還需作出確認，即發送一個序列號seq(A)=x+1；確認號為ack(A)=y+1的報文；
（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連接的過程如下： 1） 關閉客戶端到服務器的連接：首先客戶端A發送一個FIN，用來關閉客戶到服務器的數據傳送，然後等待服務器的確認。其中終止標誌位FIN=1，序列號seq=u 2） 服務器收到這個FIN，它發回一個ACK，確認號ack為收到的序號加1。
3） 關閉服務器到客戶端的連接：也是發送一個FIN給客戶端。
4） 客戶段收到FIN後，並發回一個ACK報文確認，並將確認序號seq設置為收到序號加1。 首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
主機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狀態。
序列號seq：占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。確認號ack：占4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；因此當前報文段最後一個字節的編號+1即為確認號。
確認ACK：占1位，僅當ACK=1時，確認號字段才有效。ACK=0時，確認號無效
終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接 PS：ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麽是1，要麽是0；ack、seq小寫的單詞表示序號。
三次握手：
A:“餵，你聽得到嗎？”A->SYN_SEND
B:“我聽得到呀，你聽得到我嗎？”應答與請求同時發出 B->SYN_RCVD | A->ESTABLISHED
A:“我能聽到你，今天balabala……”B->ESTABLISHED
四次揮手：
A:“餵，我不說了。”A->FIN_WAIT1
B:“我知道了。等下，上一句還沒說完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了，說完了，我也不說了。”B->LAST_ACK
A:”我知道了。”A->TIME_WAIT | B->CLOSED
一、TCP建立連接三次握手 （1）、三次握手的過程 1）主機A向主機B發送TCP連接請求數據包，其中包含主機A的初始序列號seq(A)=x。（其中報文中同步標誌位SYN=1，ACK=0，表示這是一個TCP連接請求數據報文；序號seq=x，表明傳輸數據時的第一個數據字節的序號是x）；
2）主機B收到請求後，會發回連接確認數據包。（其中確認報文段中，標識位SYN=1，ACK=1，表示這是一個TCP連接響應數據報文，並含主機B的初始序列號seq(B)=y，以及主機B對主機A初始序列號的確認號ack(B)=seq(A)+1=x+1）
3）第三次，主機A收到主機B的確認報文後，還需作出確認，即發送一個序列號seq(A)=x+1；確認號為ack(A)=y+1的報文；
（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連接的過程如下： 1） 關閉客戶端到服務器的連接：首先客戶端A發送一個FIN，用來關閉客戶到服務器的數據傳送，然後等待服務器的確認。其中終止標誌位FIN=1，序列號seq=u 2） 服務器收到這個FIN，它發回一個ACK，確認號ack為收到的序號加1。
3） 關閉服務器到客戶端的連接：也是發送一個FIN給客戶端。
4） 客戶段收到FIN後，並發回一個ACK報文確認，並將確認序號seq設置為收到序號加1。 首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
主機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狀態。
知識點 - tcp協議建立連接 為什麽是三次握手 而 斷開連接需要四次？