①面向連線。tcp提供客戶端與伺服器端的連線。
②tcp的連線是點對點的。
③可靠性。
④有序性。tcp通過給所傳送的資料的每乙個位元組關聯序列號進行排序，通過tcp連線傳輸的資料，無差錯，不丟失，不重複。
⑤面向位元組流，並且提供流量控制。tcp總是告訴對方它能接收多少位元組的資料（視窗）。
⑥全雙工。既可以傳送資料也可以接收資料。
三次握手是為了防止客戶端已經失效的連線請求再次傳送到伺服器端。
如果兩次握手，預設伺服器端b發出確認報文段，連線就建立完成。
客戶端a第一次傳送連線請求，如果沒有正常到達伺服器端b，即出現請求報文段丟失或者請求報文段滯留情況。
如果請求報文段丟失，客戶端a沒有收到伺服器端b的確認，此時重新發出連線請求，對於伺服器端b來說，只收到第二次傳送的連線請求，發出確認報文段，連線建立。
如果a第一次傳送的請求報文段滯留，a沒有收到b的確認重新發出連線，b收到a第二次發出的請求報文段並確認連線建立，而a第一次傳送的請求報文段延誤到連線釋放後的某個時間再次到達b，b收到這個已失效的連線請求後誤以為a又一次發出連線請求，b再次發出確認報文段，同意建立連線。而此時a並沒有發出連線請求，b會一直等待a傳送資料，導致伺服器端資源浪費。所以第二次握手的訊息也需要確認。在滯留的情況下，如果三次握手，b對已失效的請求報文段發出確認後會等待a發出確認，b沒有收到a的確認就知道a沒有發出連線請求。
三次握手既保證了客戶端收到了建立請求的訊息，也保證了服務端請求訊息的確認。
四次揮手：
第一次揮手：客戶端向伺服器端發出釋放連線報文段
第二次揮手：伺服器端向客戶端發出確認報文段
第三次揮手：伺服器端向客戶端發出釋放連線報文段
第四次揮手：客戶端向伺服器端發出確認報文段
詳細描述見圖：
問題2：為什麼客戶端在發出確認報文段後沒有直接進入close狀態而是等待2msl(msl:報文最長存活時間)/為什麼又time-wait狀態？
為了避免以下情況：
①確認報文端丟失，b沒有收到a發出的確認報文段。
b沒有收到確認報文段，超時重傳連線釋放報文段（第三次揮手），如果客戶端a發出確認報文段後直接進入close狀態，對於b重傳的連線釋放報文段不會發出確認，會導致b無法正常進入close狀態；而a等待2msl可以在等待的時間理收到b重傳的報文段並重傳一次確認，b正常關閉。即客戶端需要等待2msl確保客戶端發出的確認報文段能夠到達伺服器端，伺服器端可以正常關閉。
②避免網路中存在已失效的報文。a傳送完確認報文段後，經過2msl可以使本連線持續時間內所產生的所有報文段從網路中消失，不影響下一次連線。
問題3：為什麼tcp的揮手需要四次？
tcp是全雙工的連線，既可以是資料傳送方也可以是資料接收方，必須兩端同時斷開連線連線才真正的關閉，如上圖，經歷兩次揮手後，a關閉連線後，b仍然可以給a傳送資料，連線處於半關閉狀態，只有兩端都斷開連線，連線才真正關閉。
①檢驗和
②序列號
③確認應答
④超時重傳
⑤連線管理
⑥流量控制/滑動視窗
⑦擁塞控制
tcp傳輸時將每個位元組的資料都進行了編號，這就是序列號。首部中的序號欄位指的是報文段鎖傳送的資料的第乙個位元組的序號。序列號可以保證資料有序性，如果傳輸的資料丟失或重複可以立即知道。
tcp是全雙工連線。全雙工通訊的雙方既是傳送方也是接收方，無論哪一方傳送訊息都需要對方傳送確認報文端確認收到，保證對方接收到資料。
正常的情況下，a傳送資料b接收資料並確認，資料正常傳輸。
如果a傳送的資料在傳輸過程中丟失或者b接收資料時檢測出現問題，b不會給a傳送確認報文段，超時重傳機制設定乙個超時計時器，a如果在超時計時器到期前沒有收到b的確認，就認為之前傳輸的資料丟失重新傳送。
三次握手建立連線和四次揮手斷開連線保證了tcp的全雙工通訊（詳細見上面描述）。
傳送視窗：
p1之前：已傳送並收留到確認，不需要再保留。
p1-p2：已傳送但未收到確認，暫時保留，便於超時重傳。
p2-p3：可用視窗，允許傳送但未傳送。
p3之後：不允許傳送。
接收視窗：
b只對按序收到的資料中最高序號做出確認，未按序收到的資料暫存在接收視窗中。
傳送方資料傳送的太快會導致接收方的結束緩衝區很快的填充滿了。此時如果傳送端仍舊傳送資料，那麼接下來傳送的資料都會丟包。需要利用滑動視窗機制進行流量控制。接收端會在確認應答傳送ack報文時，將自己的即時視窗大小填入，並跟隨ack報文一起傳送過去。傳送方的視窗不能超過接收方給出的接收視窗大小。而傳送方根據ack報文裡的視窗大小的值的改變進而改變自己的傳送速度。如果接收到視窗大小的值為0，那麼傳送方將停止傳送資料。
持續計時器：如下圖，b向a發出零視窗的報文，a啟動持續計時器，一段時間後b的接收快取又有了儲存空間，a在持續計時器到期後向b發出零視窗探測報文端，b在確認時給出當前的視窗大小。
擁塞控制的四種演算法
慢開始：
在開始傳送資料時，先把擁塞視窗（cwnd）設定為乙個最大報文段mss的數值，傳送方在開始只傳送乙個報文段探測網路的擁塞情況，cwnd沒有超過慢開始門限值（ssthresh）時，在收到乙個對新的報文段（不包括重傳）的確認後將擁塞視窗增加至多乙個mss的數值。當cwnd超過慢開始門限值（ssthresh）時，開始執行擁塞避免演算法。
擁塞避免：
每經過乙個傳輸倫茨所經歷的時間（往返時間rtt），就將傳送方的擁塞視窗cwnd加1，而不是加倍。
快重傳：
接收方每次接收到乙個失序的報文段後就立即發出重複確認，傳送方能夠盡早知道有報文段沒有到達接收方。傳送方只要一連收到三個重複確認就應當立即重傳，不需要等待重傳計時器到期。
快恢復：
當傳送方連續收到三個重複確認時，將慢開始門限減半
TCP 傳輸控制協議
推薦 tcp ip 簡直是程式設計師的福音 tcp 協議是 面向連線的，可靠的，流傳輸，協議。流 是指 不間斷 的資料結構，可以想象成排水管道中的水流。當應用程式採用 tcp 傳送訊息的時候，雖然可以保證傳送的順序，但是還是猶如沒有任何間隔的資料流，傳送給接收端。可以這麼理解 在傳送端，應用程式傳送...
TCP傳輸控制協議
tcp是網際網路中的傳輸層協議，使用三次握手協議建立連線。當主動方發出syn連線請求後，等待對方回答syn ack 1 並最終對對方的 syn 執行 ack 確認。這種建立連線的方法可以防止產生錯誤的連線，tcp使用的流量控制協議是可變大小的滑動視窗協議 tcp三次握手的過程如下 客戶端傳送syn ...
tcp傳輸控制協議
tcp服務 tcp是面向連線的，提供可靠的服務，對資料有校驗機制。tcp的首部 其格式如下 如上tcp的報文是tcp的首部和tcp的資料。tcp的首部是有源埠和目的埠，這個值和ip首部的源ip和目的ip構成了tcp唯一確定的乙個連線。序號是用來標示從tcp發端向tcp收端傳送的資料位元組。當建立乙個...