這是我參與8月更文挑戰的第4天,活動詳情查看,活動詳情查看: 8月更文挑戰服務器
OK,下面正經地來回答下這個問題,要搞清楚這個問題,首先得了解TCP到底是如何保證可靠傳輸的。markdown
PS:TCP協議中,主動發起請求的一端稱爲『客戶端』,被動鏈接的一端稱爲『服務端』。無論是客戶端仍是服務端,TCP鏈接創建完後都能發送和接收數據。網絡
起初,服務器和客戶端都爲CLOSED狀態。在通訊開始前,雙方都得建立各自的傳輸控制塊(TCB)。 服務器建立完TCB後遍進入LISTEN狀態,此時準備接收客戶端發來的鏈接請求。post
第一次握手spa
客戶端向服務端發送鏈接請求報文段。該報文段的頭部中SYN=1,ACK=0,seq=x。請求發送後,客戶端便進入SYN-SENT狀態。3d
第二次握手code
服務端收到鏈接請求報文段後,若是贊成鏈接,則會發送一個應答:SYN=1,ACK=1,seq=y,ack=x+1。 該應答發送完成後便進入SYN-RCVD狀態。orm
第三次握手資源
當客戶端收到鏈接贊成的應答後,還要向服務端發送一個確認報文段,表示:服務端發來的鏈接贊成應答已經成功收到。 該報文段的頭部爲:ACK=1,seq=x+1,ack=y+1。 客戶端發完這個報文段後便進入ESTABLISHED狀態,服務端收到這個應答後也進入ESTABLISHED狀態,此時鏈接的創建完成!get
防止失效的鏈接請求報文段被服務端接收,從而產生錯誤。
PS:失效的鏈接請求:若客戶端向服務端發送的鏈接請求丟失,客戶端等待應答超時後就會再次發送鏈接請求,此時,上一個鏈接請求就是『失效的』。
若創建鏈接只需兩次握手,客戶端並無太大的變化,仍然須要得到服務端的應答後才進入ESTABLISHED狀態,而服務端在收到鏈接請求後就進入ESTABLISHED狀態。此時若是網絡擁塞,客戶端發送的鏈接請求遲遲到不了服務端,客戶端便超時重發請求,若是服務端正確接收並確認應答,雙方便開始通訊,通訊結束後釋放鏈接。此時,若是那個失效的鏈接請求抵達了服務端,因爲只有兩次握手,服務端收到請求就會進入ESTABLISHED狀態,等待發送數據或主動發送數據。但此時的客戶端早已進入CLOSED狀態,服務端將會一直等待下去,這樣浪費服務端鏈接資源。
TCP鏈接的釋放一共須要四步,所以稱爲『四次揮手』。
咱們知道,TCP鏈接是雙向的,所以在四次揮手中,前兩次揮手用於斷開一個方向的鏈接,後兩次揮手用於斷開另外一方向的鏈接。
若A認爲數據發送完成,則它須要向B發送鏈接釋放請求。該請求只有報文頭,頭中攜帶的主要參數爲: FIN=1,seq=u。此時,A將進入FIN-WAIT-1狀態。
B收到鏈接釋放請求後,會通知相應的應用程序,告訴它A向B這個方向的鏈接已經釋放。此時B進入CLOSE-WAIT狀態,並向A發送鏈接釋放的應答,其報文頭包含: ACK=1,seq=v,ack=u+1。
A收到該應答,進入FIN-WAIT-2狀態,等待B發送鏈接釋放請求。
第二次揮手完成後,A到B方向的鏈接已經釋放,B不會再接收數據,A也不會再發送數據。但B到A方向的鏈接仍然存在,B能夠繼續向A發送數據。
當B向A發完全部數據後,向A發送鏈接釋放請求,請求頭:FIN=1,ACK=1,seq=w,ack=u+1。B便進入LAST-ACK狀態。
A收到釋放請求後,向B發送確認應答,此時A進入TIME-WAIT狀態。該狀態會持續2MSL時間,若該時間段內沒有B的重發請求的話,就進入CLOSED狀態,撤銷TCB。當B收到確認應答後,也便進入CLOSED狀態,撤銷TCB。
爲了保證B能收到A的確認應答。 若A發完確認應答後直接進入CLOSED狀態,那麼若是該應答丟失,B等待超時後就會從新發送鏈接釋放請求,但此時A已經關閉了,不會做出任何響應,所以B永遠沒法正常關閉。