參考鏈結
參考鏈結
三次握手
四次揮手
在完成三次握手的第三步之前分配 tcp 快取 和 變數，
使得tcp易於受到syn洪氾的拒絕服務攻擊。
linuxtcp的連線控制塊
tcp服務端在接收到syn報文時，會為該連線先分配乙個tcp_request_sock，
三次握手完成之後，再分配乙個完整的tcp_sock。
第三次握手是為了防止失效的連線請求到達伺服器，讓伺服器錯誤開啟連線。
客戶端傳送的連線請求如果在網路中滯留，那麼就會隔很長一段時間才能收到伺服器端發回的連線確認。客戶端等待乙個超時重傳時間之後，就會重新請求連線。但是這個滯留的連線請求最後還是會到達伺服器，如果不進行三次握手，那麼伺服器就會開啟兩個連線。如果有第三次握手，客戶端會忽略伺服器之後傳送的對滯留連線請求的連線確認，不進行第三次握手，因此就不會再次開啟連線。若只是兩次握手，則伺服器在傳送允許連線的報文段之後，就認為 tcp 連線已經建立了，如果此時允許連線的報文段丟失之後， 客戶端便無法確認伺服器接收到了請求連線報文段， 也就無法確認連線已經建立，也就沒辦法知道伺服器的seq和ack。在這種情況下， 客戶端認為連線還未建立成功，將忽略伺服器發來的任何資料分組，只等待允許連線的應答分組。而伺服器在發出的分組超時後，重**送同樣的分組。這樣就就會白白浪費伺服器資源。
當然不是。握手成功只能保證在握手的這個時刻雙方的連線是暢通的，握手之後的網路情況的變化是無法預知的。比如客戶端回發確認連線的報文段之後，它就認為連線確立並等待服務端傳送資料，但此時服務端可能因為網路原因關閉了tcp連線，那麼客戶端就只能等待tcp連線超時自動關閉了。
我的部落格鏈結
客戶端傳送了 fin 請求連線釋放報文之後，伺服器收到了這個報文，就進入了 close-wait 狀態。這個狀態是為了讓伺服器端傳送還未傳送完畢的資料，傳送完畢之後，伺服器會傳送 fin 釋放連線報文。
time_wait
客戶端接收到伺服器端的 fin 報文後進入此狀態，此時並不是直接進入 closed 狀態，還需要等待乙個時間計時器設定的時間 2msl。這麼做有兩個理由：
tcp還設有乙個保活計時器，顯然，客戶端如果出現故障，伺服器不能一直等下去，白白浪費資源。伺服器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設定為2小時，若兩小時還沒有收到客戶端的任何資料，伺服器就會傳送乙個探測報文段，以後每隔75秒鐘傳送一次。若一連傳送10個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連線。
參考鏈結
msl是maximum segment lifetime的英文縮寫，可譯為「最長報文段壽命」，它是任何報文在網路上存在的最長的最長時間，超過這個時間報文將被丟棄。
參考鏈結
客戶端接收到伺服器端的 fin 報文後進入此狀態，此時並不是直接進入 closed 狀態，還需要等待乙個時間計時器設定的時間 2msl。這麼做有兩個理由：
計算機網路（四），TCP三次握手
1.三次握手詳情 2.為什麼需要三次握手才能建立連線 3.首次握手的隱患 syn超時的問題 4.建立連線之後，client出現故障 1 一開始，客戶端和伺服器端都處於關閉狀態 closed 然後開啟服務，服務端這個時候處於監聽狀態 listen 2 客戶端傳送乙個連線請求報文，裡面syn等於1，se...
計算機網路之tcp三次握手
客戶端與伺服器之間資料的傳送和返回的過程當中需要建立乙個叫tcp connection的東西 由於tcp不存在連線的概念，只存在請求和響應，請求和響應都是資料報，它們之間都是經過由tcp建立的乙個從客戶端發起，伺服器接收的類似連線的通道，這個連線可以一直保持，http請求是在這個連線的基礎上傳送的 ...
計算機網路 三次握手
假設a為客戶端，b為服務端。首先b處於listen 監聽 狀態，等待客戶的連線請求。a向b傳送連線請求報文，syn 1,ack 0 選擇乙個初始的序號x b收到連線請求，如果同意建立連線，則向a傳送連線確認報文，syn 1,ack 1 確認號為1，同時也選擇乙個初始的序號y。a收到b的連線確認序號後...