TCP協議圖文詳解
一.TCP協議簡介
TCP是TCP/IP體系中非常複雜的一個協議，TCP最主要的特點有：
1.TCP是面向連線的運輸層協議。應用程式在使用TCP協議之前，必須先建立TCP連線。在傳遞資料完畢後，必須釋放已建立的TCP連線。
2.每一條TCP連線只能有兩個端點，只能說點對點的。
3.TCP提供可靠交付的服務，通過TCP連線傳送的資料，無差錯，不丟失，不重複，並且按序到達。
4.TCP提供全雙工通訊。TCP允許通訊雙方的應用程序在任何時候都能傳送資料。TCP連線的兩端都設有傳送快取和接收快取，用來臨時存放雙向通訊的資料。
5.面向位元組流。TCP中的“流”指的是流入到程序或從程序流出的位元組序列。“面向位元組流”的含義是：雖然應用程式和TCP的互動是一次一個資料塊(大小不等)，但TCP把應用程式交下來的資料看成僅僅是一連串的無結構的位元組流。TCP並不知道所傳送的位元組流的含義。TCP不保證接收方應用程式所收到的資料塊和傳送方應用程式所發出的資料塊具有對應大小的關係。但接收方應用程式收到的位元組流必須和傳送方應用程式發出的位元組流完全一樣。當然，接收方的應用程式必須有能力識別收到的位元組流，把它還原成有意義的應用層資料。
TCP報文段先要傳到IP層，加上IP首部後，再傳送到資料鏈路層。再加上資料鏈路層的首部和尾部，才離開主機發送到物理鏈路。
a.TCP和UDP在傳送報文時所採用的方式完全不同。TCP並不關心應用程式一次把多長的報文傳送到TCP快取中，而是根據對方給出的視窗值和當前網路擁塞的程度來決定一個報文段應包含多少個位元組（UDP傳送的報文長度是應用程式給出的）。
b.如果應用程式傳送到TCP快取的資料塊太大，TCP就可以把它劃分短一些再傳。TCP也可以等待積累有足夠多的位元組後再構建成報文段傳送出去。
二：TCP包頭格式
TCP協議重定解決的問題：
順序問題，穩重不亂；丟包問題，承諾靠譜；連線維護，有始有終；流量控制，把握分寸；擁塞控制，知進知退。
TCP把連線作為最基本的抽象，每個TCP連線有兩個端點。TCP連線的埠叫做套接字，埠號拼接到IP地址即構成了套接字（如：192.3.4.5：80）。
1.源埠號和目標埠號是不可少的，這一點和UDP是一樣的，如果沒有這兩個埠號，資料就不知道應該傳送給哪個應用。
2.包的序號：為了解決亂序的問題
3.確認序號：發出去的包應該有確認，如果沒有收到就應該重新發送，直到送達，這個可以解決不丟包的問題
4.狀態位：ACK是回覆，RST是重新連線，FIN是結束連線。
三：TCP連線三次握手
1.一開始，客戶端和服務端都處於CLOSED狀態
2.先是服務端主動監聽某個埠，處於LISTEN狀態
3.客戶端主動發起連線SYN，之後處於SYN-SENT狀態
4.服務端收到發起的連線，返回SYN，並且ACK客戶端的SYN，之後處於SYN-RCVD狀態
5.客戶端收到服務端傳送的SYN和ACK之後，傳送ACK的ACK，之後處於ESTABLISHED狀態。
6.服務端收到ACK的ACK之後，處於ESTABLISHED狀態。
四：TCP連線釋放四次揮手
1.當前A和B都處於ESTAB-LISHED狀態。
2.A的應用程序先向其TCP發出連線釋放報文段，並停止再發送資料，主動關閉TCP連線。
3.B收到連線釋放報文段後即發出確認，然後B進入CLOSE-WAIT(關閉等待)狀態。TCP伺服器程序這時應通知高層應用程序，因而從A到B這個方向的連線就釋放了，這時TCP連線處於半關閉狀態，即A已經沒有資料傳送了。
從B到A這個方向的連線並未關閉，這個狀態可能會持續一些時間。
4.A收到來自B的確認後，就進入FIN-WAIT-2(終止等待2)狀態，等待B發出的連線釋放報文端。
5.若B已經沒有向A傳送的資料，B發出連線釋放訊號，這時B進入LAST-ACK(最後確認)狀態等待A的確認。
6.A再收到B的連線釋放訊息後，必須對此發出確認，然後進入TIME-WAIT（時間等待）狀態。請注意，現在TCP連線還沒有釋放掉，必須經過時間等待計時器（TIME－WAIT timer）設定的時間2MSL後，A才進入CLOSED狀態。
7。B收到A發出的確認訊息後，進入CLOSED狀態。
五：TCP狀態機
一.以位元組為單位的滑動視窗
在TCP裡，接收端(B)會給傳送端(A)報一個視窗的大小，叫Advertised window。
1.在沒有收到B的確認情況下，A可以連續把視窗內的資料都發送出去。凡是已經發送過的資料，在
未收到確認之前都必須暫時保留，以便在超時重傳時使用。
2.傳送窗口裡面的序號表示允許傳送的序號。顯然，視窗越大，傳送方就可以在收到對方確認之前連續
傳送更多資料，因而可能獲得更高的傳輸效率。但接收方必須來得及處理這些收到的資料。
3.傳送視窗後沿的後面部分表示已傳送且已收到確認。這些資料顯然不需要再保留了。
4.傳送視窗前沿的前面部分表示不允許傳送的，應為接收方都沒有為這部分資料保留臨時存放的快取空間。
5.傳送視窗後沿的變化情況有兩種：不動（沒有收到新的確認）和前移（收到了新的確認）
6.傳送視窗前沿的變化情況有兩種：不斷向前移或可能不動（沒收到新的確認）
二.超時重傳時間的選擇
TCP的傳送方在規定時間內沒有收到確認就要重傳已傳送的報文段。這種重傳的概念很簡單，但重傳時間的選擇
確是TCP最複雜的問題之一。TCP採用了一種自適應演算法，它記錄一個報文段發出的時間，以及收到相應的確認的時間
這兩個時間之差就是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間。超時重傳時間RTO略大於加權平均往返時間。
三：選擇確認SACK
如果收到的報文段無差錯，只是未按序號，中間還缺少一些序號的資料，那麼能否設法只傳送缺少的資料而不重傳已經正確到達接收方的資料？
答案是可以的，選擇確認就是一種可行的處理方法。
如果要使用選項確認SACK，那麼在建立TCP連線時，就要在TCP首部的選項中加上“允許SACK”的選項，而雙方必須都事先商定好。如果使用選擇確認，
那麼原來首部中的“確認號欄位”的用法仍然不變。SACK文件並沒有明確傳送方應當怎麼響應SACK.因此大多數的實現還是重傳所有未被確認的資料塊。
四：TCP的流量控制
一般說來，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的過快，接收方就可能來不及接收，這會造成資料的丟失。所謂流量控制就是讓傳送方的傳送速率不要太快，要讓接收方來得及接收。
五：TCP的擁塞控制
在計算機網路中的鏈路容量，交換節點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能
就要變壞。這種情況就叫做擁塞。
擁塞控制方法：
1.慢開始和擁塞避免
2.快重傳和快恢復
3.隨機早期檢測
Linux公社的RSS地址 ： ofollow,noindex" target="_blank">https://www.linuxidc.com/rssFeed.aspx
本文永久更新連結地址： https://www.linuxidc.com/Linux/2018-09/154367.htm