全稱
傳輸控制協議，Transmission Control Protocol
特點
- T C P提供一種面向連線的、可靠的位元組流服務
- 面向連線意味著兩個使用T C P的應用（通常是一個客戶和一個伺服器，C/S）在彼此交換資料之前必須先建立一個T C P連線
- 一個T C P連線中，僅有兩方進行彼此通訊
可靠性（檢錯、應答確認、資料錯誤處理）
- 應用資料被分割成T C P認為最適合傳送的資料塊
- 當T C P發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段
- 當T C P收到發自T C P連線另一端的資料，它將傳送一個確認。這個確認不是立即傳送，通常將推遲幾分之一秒
- T C P將保持它首部和資料的檢驗和。這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯， T C P將丟棄這個報文段和不確認收到此報文段（希望發端超時並重發）
- 如果必要， T C P將對收到的資料進行重新排序，將收到的資料以正確的順序交給應用層（IP層資料資料失序的影響）
- T C P的接收端必須丟棄重複的資料（IP層資料重複的影響）
- T C P還能提供流量控制。T C P連線的每一方都有固定大小的緩衝空間，C P的接收端只允許另一端傳送接收端緩衝區所能接納的資料。這將防止較快主機致使較慢主機的緩衝區溢位
位元組流服務（ byte stream service）
兩個應用程式通過T C P連線交換8 bit位元組構成的位元組流。T C P不在位元組流中插入記錄識別符號
TCP結構
- 唯一的TCP連線，每個T C P段都包含源端和目的端的埠號，用於尋找發端和收端應用程式。這兩個值加上I P首部中的源端I P地址和目的端I P地址唯一確定一個T C P連線。（有時，一個I P地址和一個埠號也稱為一個插口（ s o c k e t））
- 序號用來標識從T C P發端向T C P收端傳送的資料位元組流，它表示在這個報文段中的的第一個資料位元組（序號是32 bit的無符號數，序號到達23 2－1後又從0開始）
- U R G 緊急指標（ u rgent pointer）有效（見2 0 . 8節）。 A C K 確認序號有效。 P S H 接收方應該儘快將這個報文段交給應用層。 R S T 重建連線。 S Y N 同步序號用來發起一個連線。這個標誌和下一個標誌將在第1 8章介紹。 F I N 發端完成傳送任務。
- T C P的流量控制由連線的每一端通過宣告的視窗大小來提供。視窗大小為位元組數，起始 於確認序號欄位指明的值，這個值是接收端正期望接收的位元組。視窗大小是一個16 bit欄位，因而視窗大小最大為6 5 5 3 5位元組
- 檢驗和覆蓋了整個的T C P報文段： T C P首部和T C P資料。這是一個強制性的欄位，一定是由發端計算和儲存，並由收端進行驗證
TCP連線的建立與終止
- 傳說中的三次握手（建立）
- 請求端（通常稱為客戶）傳送一個S Y N段指明客戶打算連線的伺服器的埠，以及初始序號（I S N，在這個例子中為1 4 1 5 5 3 1 5 2 1）。這個S Y N段為報文段1。
- 伺服器發回包含伺服器的初始序號的S Y N報文段（報文段2）作為應答。同時，將確認序號設定為客戶的I S N加1以對客戶的S Y N報文段進行確認。一個S Y N將佔用一個序號。
- 客戶必須將確認序號設定為伺服器的I S N加1以對伺服器的S Y N報文段進行確認（報文段3）。
- 傳說中的四次握手（終止）
？為什麼多了一次，不對稱？
原因是，由T C P的半關閉（h a l f - c l o s e）造成的，本來是全雙工通訊（兩邊都能傳送和接收），而進行FIN傳送（接收到這個表示沒有資料了）
半關閉：T C P提供了連線的一端在結束它的傳送後還能接收來自另一端資料的能力
TCP連線超時
所謂超時，得有個參考時間吧，當然也得有個計時器件！ 一般新連線最長請求時長是75秒
TCP半關閉
作用就是，"我已經完成了資料傳送，因此傳送一個檔案結束（ F I N）給另一端，但我還想接收另一端發來的資料，直到它給我發來檔案結束（F I N）"
握手的狀態來自那裡？
TCP資料流
組成：塊資料（使用者資料） + 互動資料
互動資料（傳送一個字元為例）
-
互動資料總是以小於最大報文段長度的分組傳送
-
經受的時延確認
- 機理：通常T C P在接收到資料時並不立即傳送A C K；相反，它推遲傳送，以便將A C K與需要沿該方向傳送的資料一起傳送（有時稱這種現象為資料捎帶A C K）。絕大多數實現採用的時延為200 ms，也就是說，T C P將以最大200 ms 的時延等待是否有資料一起傳送。
- 目的：減少報文段的數目
-
用於這個處理的演算法：N a g l e演算法（廣域網環境下）
- 要求一個T C P連線上最多隻能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能傳送其他的小分組。相反， T C P收集這些少量的分組，並在確認到來時以一個分組的方式發出去。
- 該演算法的優越之處在於它是自適應的：確認到達得越快，資料也就發 送得越快
塊資料
- 使用的控制協議：滑動視窗協議的另一種形式的流量控制方法。
- 允許傳送方在停止並等待確認前可以連續傳送多個分組。由於傳送方不必每發一個分組就停下來等待確認，因此該協議可以加速資料的傳輸
- 視窗的變化（協議）
- 稱視窗左邊沿向右邊沿靠近為視窗合攏。這種現象發生在資料被髮送和確認時。
- 當視窗右邊沿向右移動時將允許傳送更多的資料，我們稱之為視窗張開。這種現象發生在另一端的接收程式讀取已經確認的資料並釋放了T C P的接收快取時。
- 當右邊沿向左移動時，我們稱之為視窗收縮。Host Requirements RFC強烈建議不要使用這種方式。但T C P必須能夠在某一端產生這種情況時進行處理。
- 變化的小例
- 傳送方不必傳送一個全視窗大小的資料
- 來自接收方的一個報文段確認資料並把視窗向右邊滑動。這是因為視窗的大小是相對於確認序號
- 正如從報文段7到報文段8中變化的那樣，視窗的大小可以減小，但是視窗的右邊沿卻不能夠向左移動
- 接收方在傳送一個A C K前不必等待視窗被填滿 ......