tcp連線和斷開流程

2021-06-22 18:57:16 字數 1852 閱讀 7703

說起tcp,我們一般都需要知道發起乙個tcp連線和終止乙個tcp連線是所發生的事情,下邊,我將跟大家介紹下tcp的三次握手及四次揮手的過程。

tcp三路握手

(1)伺服器必須準備好接受外來的連線。這通常在呼叫socket,bind,listen這三個函式來完成,我們稱之為被動開啟(passive open)。

(2)客戶通過呼叫socket,connect發起主動開啟(active open)。這導致客戶tcp傳送乙個syn(同步)分節,它告訴伺服器客戶將在待建立的tcp連線中傳送資料的初始序列號。通常syn分節不攜帶資料,其所在的ip資料報只包含有乙個ip首部、乙個tcp首部及可能有的tcp選項。

(3)伺服器必須確認(ack)客戶的syn,同時自己也得傳送乙個syn分節,它含有伺服器將在同一連線中傳送的資料的初始序列號。伺服器在單個分節中傳送syn和對客戶syn的ack(確認)。

(4)客戶必須確認伺服器的syn。

這種交換至少需要三個分組,因此稱之為tcp的三路握手,如圖1:

tcp四路揮手

tcp建立乙個連線需要3個分節,而終止乙個連線一般需要4個分節,所以一般也稱為四路揮手。

(1)某個應用程序首先呼叫close,我們稱為該端執行主動關閉(active close),該端的tcp於是傳送乙個fin分節,表示資料傳送完畢。

(2)接收到這個fin的對端執行被動關閉(passive close)。這個fin由tcp確認。它的接受也作為乙個檔案結束符傳遞給接收端的應用程序(放在已排隊等候該應用程序接受的任何其他資料之後),因為fin的接受意味著接收端應用程序在相應的連線上再無額外資料可接受。

(3)一段時間後,接受到這個檔案結束符的應用程序將呼叫close關閉它的套接字。這導致它的tcp也傳送乙個fin分節。

注:為什麼是需要一段時候後,我的理解是由於接收到的fin分節作為乙個檔案結束符放在已排隊等候應用程序接受的所有資料之後,而應用程序呼叫read讀取資料得等它把這個檔案描述符之前的所有資料讀取完後,才能讀取到該檔案描述符,此時read返回0, 所以此時應用程序才知道對端已關閉了套接字,進而它也呼叫close關閉i套接字。

(4)接受這個最終fin的原傳送端tcp(即執行主動關閉的那一端)確認這個fin。

如圖2展示的這些分組:

tcp連線發起和終止時套接字的狀態

tcp為乙個連線定義了11中狀態,並且tcp規定如何基於當前狀態及在該狀態下所接收的分節從乙個狀態轉換到另乙個狀態。下邊我們通過圖3來展示tcp連線的分組交換情況及tcp套接字的狀態:

一旦建立乙個連線,客戶就構造乙個請求並傳送給伺服器。伺服器處理該請求並傳送乙個應答,需要注意的是,伺服器對客戶請求的確認是伴隨器應答傳送的。這種做法稱為捎帶(piggybacking),它通常在伺服器處理請求並產生應答的時間少於200ms時發生。如果伺服器耗用更長時間,如1s,那麼我們將看到先是確認後是應答。

接下來展示了終止tcp連線時交換的4個分節,從圖中我們可以看到,傳送乙個單分節請求和接受乙個單分節的應答,使用tcp至少需要8個分節的開銷;如果改用udp,那麼只需要交換兩個分組:乙個承載請求,乙個承載應答。不過從tcp切換到udp也失去了tcp提供給應用程序的全部可靠性,迫使應用程序來做可靠性處理。

TCP連線和斷開連線

4.4 tcp資料報結構 帶陰影的幾個字段需要重點說明一下 1 序號 seq sequence number 序號佔32位,用來標識從計算機a傳送到計算機b的資料報的序號,計算機傳送資料時對此進行標記。2 確認號 ack acknowledge number 確認號佔32位,客戶端和伺服器端都可以傳...

Tcp 斷開連線

tcp協議規定,對於已經建立的連線,網路雙方要進行四次握手才能成功斷開連線,如果缺少了其中某個步驟,將會使連線處於假死狀態,連線本身占用的資源不會被釋放。網路伺服器程式要同時管理大量連線,所以很有必要保證無用連線完全斷開,否則大量僵死的連線會浪費許多伺服器資源。在眾多tcp狀態中,最值得注意的狀態有...

TCP的連線和斷開

1.tcp的三次握手連線 l請求端 通常稱為客戶端 傳送乙個syn段指名客戶端打算連線的伺服器的埠,以及初始序號。序號 3662298720確認序號 0 l伺服器端發回包含伺服器的初始序號的 syn段,同時對客戶端的序號進行加1作為應答 序號 1139382973,確認序號 3662298721 l...