TCP三次握手和四次揮手

tcp標誌位,有6種表示:syn(synchronous建立聯機) ack(acknowledgement 確認) psh(push傳送) fin(finish結束) rst(reset重置) urg(urgent緊急)

2種號碼：sequence number(順序號碼) acknowledge number(確認號碼)

第一次握手：client將標誌位syn置為1，隨機產生乙個值seq=j，並將該資料報傳送給server，client進入syn_sent狀態，等待server確認。

第二次握手：server收到資料報後由標誌位syn=1知道client請求建立連線，server將標誌位syn和ack都置為1，ack=j+1，隨機產生乙個值seq=k，並將該資料報傳送給client以確認連線請求，server進入syn_rcvd狀態。

第三次握手：client收到確認後，檢查ack是否為j+1，ack是否為1，如果正確則將標誌位ack置為1，ack=k+1，並將該資料報傳送給server，server檢查ack是否為k+1，ack是否為1，如果正確則連線建立成功，client和server進入established狀態，完成三次握手

可能a傳送的已經失效的連線i請求報文端突然又傳送到了b。如果不採用三次握手，b發出確認就建立了新連線。a並沒有發出建立連線的請求，不會理睬b的確認，也不會向b傳送資料，b卻以為新的運輸連線已經建立，並一直等待a發來的資料。b的許多資源就這樣浪費了。採用三次握手就不會發生這種現象。

泛洪攻擊syn flood

syn flood利用了tcp協議三次握手的過程來達到攻擊的目的。三次握手的第三步中如果伺服器沒有收到客戶端的ack報文，服務端一般會進行重試，也就是再次傳送syn+ack報文給客戶端，並且一直處於syn_recv狀態，將客戶端加入等待列表。重發一般會進行3~5次，大約每隔30秒左右會輪詢一遍等待佇列，重試所有客戶端；另一方面，服務端在發出syn+ack報文後，會預分配一部分資源給即將建立的tcp連線，這個資源在等待重試期間一直保留，伺服器資源有限，可以維護的等待佇列超過極限後就不再接收新的syn報文，也就是拒絕建立新的tcp連線。

攻擊者偽造大量的ip位址給伺服器傳送syn報文，但是由於偽造的ip位址幾乎不可能存在，也就不可能從客戶端得到任何回應，服務端將維護乙個非常大的半連線等待列表，並且不斷對這個列表中的ip位址進行遍歷和重試，占用了大量的系統資源。伺服器資源有限，大量的惡意客戶端資訊佔滿了伺服器的的等待佇列，導致伺服器不再接收新的syn請求，正常使用者無法完成三次握手與伺服器進行通訊。

資料傳輸結束後，通訊的雙方都可釋放連線。

第一次揮手：client傳送乙個fin，用來關閉client到server的資料傳送，其序號seq=u，它等於前面已經傳送過的資料的最後乙個位元組序號加1。這時client進入fin_wait_1狀態。tcp規定，fin報文段即使不攜帶資料，它也消耗掉乙個序號。

fin=1，seq=u a進入fin-wait-1狀態

第二次揮手：server收到fin後，傳送乙個ack給client，確認序號為收到序號+1（與syn相同，乙個fin占用乙個序號），server進入close_wait狀態。tcp伺服器程序這時應通知高層應用程序，因此從客戶端到伺服器端這個方向的連線就釋放了，這時的tcp連線處於半關閉half-close狀態，即客戶端a已經沒有資料要傳送了，但伺服器端b若傳送資料，客戶端a仍要接收。也就是說，從b到a這個方向的連線並未關閉，這個狀態可能會持續一些時間。

a收到來自b的確認後，就進入fin-wait-2狀態，等待b發出的連線釋放報文段。

ack=1，seq=v，ack=u+1，b進入close-wait狀態，a進入fin-wait-2狀態。

第三次揮手：若b已經沒有要想a傳送的資料，其應用程序就通知tcp釋放連線。這時b發出的連線釋放報文段必須使fin=1。現假定b的序號為w（在半關閉狀態b可能又傳送了一些資料）。b還必須重複上次已傳送過的確認號ack=u+1。這時b就進入last-ack（最後確認）狀態，等待a的確認。

a傳送：fin=1，ack=1，seq=w，ack=u+1 b進入last-ack狀態。

第四次揮手：client收到fin後，必須對此發出確認。在確認報文段中把ack置1，確認號ack=w+1，而自己的序號是seq=u+1（根據tcp標準，前面傳送過的fin報文段要消耗乙個序號）。然後進入到time-wait（時間等待）狀態。請注意，現在tcp連線還沒有釋放掉，必須經過時間等待計時器time-wait timer設定的時間2msl後，a才進入到closed狀態。時間msl叫做最長報文段壽命。

為什麼a在time-wait狀態必須等待2msl的時間呢？

第一，為了保證a傳送的最後乙個ack報文段能夠到達b。這個ack報文段有可能丟失，因而使處在last-ack狀態的b收不到已傳送的fin+ack報文段的確認。b會超時重傳這個fin+ack報文段，而a就能在2msl時間內收到這個重傳的fin+ack報文段，接著a重傳一次確認，重新啟動2msl計時器。最後，a和b都正常進入到closed狀態。如果a在time-wait狀態不等待一段時間，而是在傳送完ack報文段後立即釋放連線，那麼就無法收到b重傳的fin+ack報文段，因而也不會再傳送一次確認報文段。這樣，b就無法按照正常步驟進入closed狀態。

第二，防止「已失效的連線請求報文段」出現在本連線中。a在傳送完最後乙個ack報文段後，再經過時間2msl，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣就可以使下乙個新的連線中不會出現這種舊的連線請求報文。

整理自《計算機網路》第6版

TCP三次握手和四次揮手

tcp 四次揮手 TCP的三次握手和四次揮手

TCP三次握手和四次揮手

TCP三次握手和四次揮手

相關推薦