tcp連線管理機制
在正常情況下，tcp要經過三次握手建立連線，四次揮手斷開連線
完整過程
三次握手建立連線
服務端狀態變化
客戶端狀態轉化
為什麼是三次握手，兩次為什麼不可以
如果只有兩次握手，那麼可能會導致客戶端傳送給服務端的失效請求被服務端接收，從而導致錯誤。
失效的請求：客戶端向服務端傳送連線請求，但是由於網路擁堵或者其他原因導致連線沒到達伺服器端，這時tcp啟動超時重傳機制，再次向伺服器端傳送連線請求，此時之前發出的連線請求就是失效的請求。
客戶端向服務端傳送連線請求，然後等待伺服器應答進入進入established狀態，服務端收到客戶端的連線請求之後就進入established。如果客戶端發出的連線請求由於網路擁堵導致服務端遲遲沒有收到，於是等不到訊息的客戶端再次傳送連線請求，這時服務端正確收到請求，向客戶端傳送確認應答，進入established狀態，客戶端收到確認應答後進入established狀態，然後進行資料讀寫，讀寫成功之後，關閉連線；此時客戶端上一次傳送的連線請求姍姍來遲，這時依舊服務端正確接收請求，向客戶端傳送確認應答，而此時客戶端已經關閉了。服務端就會一直在等待，會浪費服務端的資源。
資料讀寫階段
四次揮手斷開連線
服務端狀態轉化
客戶端狀態轉化
為什麼主動斷開連線的一方（客戶端）要先進入time_wait狀態，等待2msl才進入closed狀態
因為要保證服務端能夠收到收到客戶端的確認應答。
如果客戶端在傳送確認應答之後就進入closed狀態，如果確認應答丟包，服務端再次傳送斷開請求，這時客戶端已經關閉了，那麼伺服器就會無法正常關閉。
為什麼時間是2msl呢
因為msl是tcp報文最大生存時間，因此time_wait持續存在2msl的話，可以保證兩個傳輸方向上尚未被接受的或者遲到的報文都消失，（否則伺服器立刻重啟，可能會接收到遲到的資料，這個遲到的資料可能是錯誤的），同時也在理論上保障最後乙個報文可靠到達，如果最後乙個確認應答的包丟失，那麼服務端會再次傳送斷開連線請求，這是雖然客戶端程序不在了，但是tcp連線還在，依舊可以重發最後乙個確認應答的包。
TCP三次握手和四次揮
一 tcp報文格式 在了解三次握手和四次揮手之前，首先要知道tcp報文內部包含了哪些東西。報文主要段的含義 序號 seq 用來標記資料段的順序，確保tcp傳輸有序。ack 確認 確認序號標誌，ack 1表示確認號字段有效，ack 0表示確認序號無效。syn 同步 連線請求序號標誌，用於建立連線。sy...
三次握手和四次揮手 TCP三次握手和四次揮手的理解
相比較於udp傳輸協議，tcp傳輸協議被認為是安全可靠的，這是由於tcp協議的三次握手和四次揮手保證了資料傳輸的安全性。tcp報文格式簡介 要了解tcp協議的三次握手和四次揮手，需要先了解在tcp協議中請求和響應的資料報報文格式。在報文中有幾個值得注意的字段 1 序號 seq序號，佔32位，用來標識...
TCP 三次握手 四次握手
http常見狀態碼 200 ok 伺服器成功處理了請求 301 302 moved permanently 重定向 response中應該包含乙個location url,說明資源現在所處的位置 304 not modified 未修改 客戶的快取資源是最新的，要客戶端使用快取 404 not fo...