在學習tcp之前，讓我們把它的特性總結一遍：
16位視窗大小：即接收緩衝區剩餘空間的大小
16位校驗和：傳送端填充, crc校驗. 接收端校驗不通過, 則認為資料有問題.此處的檢驗和不光包含tcp首部, 也 包含tcp資料部分.
tcp將每個位元組的資料都進行了編號，即為序列號。
每乙個ack都帶著對應的確認序列號，意思是告訴傳送至，我們已經接收到哪些資料，下一次你應該從**開始發。
但是，主機a未收到b發來的確認應答，也可能因為ack丟失了因此主機b會收到很多重新資料，那麼tcp協議需要能夠識別出那些包是重複的包，並且把重複的丟棄掉。
這時候我們可以利用前面提到的序列號，就可以很容易做到去重的效果。
那麼，如果超時的時間如何確定？
tcp為了保證無論在任何環境下都能比較高效能的通訊，因此會動態的計算最大超時時間
在正常情況下，tcp要經過三次握手建立連線，四次揮手斷開連線（建立連線前先呼叫socket，建立檔案描述符，然後accept -> 伺服器端把鏈結開啟）
服務端狀態轉換：
客戶端狀態轉換：
time_wait的原因是確保伺服器收到了ack；
先關閉客戶端，後關閉伺服器
tcp協議規定,主動關閉連線的一方要處於time_ wait狀態,等待兩個msl的時間後才能回到closed狀態.
想一想, 為什麼是time_wait的時間是2msl?msl是tcp報文的大生存時間, 因此time_wait持續存在2msl的話 就能保證在兩個傳輸方向上的尚未被接收或遲到的報文段都已經消失 (否則伺服器立刻重啟, 可能會收到 來自上乙個程序的遲到的資料, 但是這種資料很可能是錯誤的);
對每乙個傳送的資料段, 都要給乙個ack確認應答. 收到ack後再傳送下乙個資料段. 這樣做有乙個比較大的缺點,就是效能較差. 尤其是資料往返的時間較長的時候.
既然這樣一發一收的方式效能較低, 那麼我們一次傳送多條資料, 就可以大大的提高效能(其實是將多個段的等待時 間重疊在一起了).
傳輸層 TCP協議
1 序號 在乙個tcp連線中傳送的位元組流中的每乙個位元組都按順序編號，本欄位表示本報文段所傳送資料的第乙個位元組的序號。2 確認號 期望收到對方下乙個報文段的第乙個資料位元組的序號。若確認號為n，則證明到序號n 1為止的所有資料都已正確收到。即採用累計確認 3 資料偏移 首部長度 tcp 報文段的...
傳輸層TCP協議
面向連線，可靠傳輸，面向位元組流 tcp協議 面向連線 accept 獲取新連線 1.當呼叫accept之後，核心就會為新連線建立乙個套接字描述符，服務端使用該套接字描述符進行和客戶端進行資料通訊 2.連線建立之後，雙方都可以傳送資料 確認msg1 確認的行為是傳輸層tcp協議的行為，不是應用層的行...
傳輸層協議TCP
部分埠號 第二次握手 伺服器應用程序被動開啟。若同意客戶端的請求，則發回確認報文，其首部中 syn 1,ack 1,ack x 1,seq y。第三次握手 客戶端收到確認報文之後，通知上層應用程序連線已建立，並向伺服器發出確認報文，其首部 ack 1,ack y 1。當伺服器收到客戶端的確認報文之後...