TCP協議簡單了解

TCP（Transmission Control Protocol，傳輸控制協議），它是最常用傳輸層協議，也是最穩定傳輸層協議，很多上層應用都是依賴于TCP進程傳輸數據。

TCP 屬于傳輸層協議，它為應用層提供了可靠的字節流服務。在網絡協議棧中對它的描述要比對其它協議的描述復雜的多，這也導致了lwip中很大一部分代碼都是用于描述TCP協議的。

IP包暢游在網絡中，從主機A出發，風塵仆仆趕到主機B，雖然整個過程占用時間都是以毫秒或者秒計算的，但期間風險重重啊，可能發生的情況：IP包在行進中因擁塞而被路由器、交換機拋棄，以至于IP包在傳輸期間可能會被丟掉。但主機A會希望所有的IP包都安全地抵達主機B，這需要一個機制來保障數據能穩定傳輸，于是專家們制定了TCP傳輸協議。

TCP是面向連接的技術。也就是說，基于TCP的兩臺主機，在通信之前要先建立信息交互（IP協議則沒有這種交互），主機之間的設備（路由器）和線路，都僅是只負責處理協議棧模型的下三層（物理層、數據鏈路層和網絡層）的工作。

TCP一旦發現傳輸出錯就會重新傳輸數據包，直到所有數據安全、正確地傳送到目的地，再遞交到應用層。

1. TCP屬于傳輸模型的傳輸層
2. TCP采用數據流的形式傳輸
3. TCP提供可靠地、面向連接和字節流的傳輸層服務

TCP協議的特性

面向連接

TCP是一個面向連接的協議，無論哪一方向另一方發送數據之前，都必須先在雙方之間建立一個連接，否則將無法發送數據，一個TCP連接必須有雙方 IP地址與端口號，而面向連接意味著兩個使用 TCP的應用（通常是一個客戶端和一個服務器端）。就像打電話一樣。

正面確認

當TCP協議發出一個TCP報文段后，它啟動一個定時器，等待目的端主機 確認收到這個報文段，如果不能及時收到一個確認，將重發這個報文段。一個完整的TCP傳輸必須有兩個端的主機進行數據的交互，接收方在接收到數據之后必須正面進行確認，向發送方報告接收的結果。

因為TCP協議依賴的是IP層的服務，IP數據報的傳輸是無連接、不可靠的，因此它要通過確認來知道接收方確實已經收到數據了。

數據分割

應用數據會被分割成TCP協議認為最適合發送的報文段，這些其實是動態調整的， TCP協議只能是盡可能發送最大報文段（MSS）以保證數據傳輸的速率。

數據緩沖

在發送方想要發送數據的時候，由于應用程序的數據大小、類型都是不可預估的，而 TCP提供了緩沖機制來處理這些數據，實際上TCP協議發送數據時，如果數據還未到 TCP報文段合適的大小，這些數據可能會被臨時緩存，知道超時或者等待到數據合適到TCP報文段時才發送出去，這也是大名鼎鼎的 Nagle算法（當然可以禁用它哈哈哈）。這樣就能保證一次傳輸數據的效率并且減少網絡中的流量。

發送方在將數據發送出去后并不會 立即刪除數據，而是讓數據依舊保存在緩沖區中（實際上是使用鏈表維護的），因為發送出去的數據不一定能被接收方正確接收，它需要等待到接收方的確認再將數據刪除。

同樣的，在接收方也需要有同樣的緩沖機制，因為 TCP協議是以字節流發送數據的，這些數據可能會分割成多個 TCP報文段，而且在網絡中傳輸的各個 TCP報文段到達目標主機的時間可能是不一樣的，這就導致數據失序，接收方需要把這些數據報組裝成完整且有序的數據，然后再遞交到應用層中，在這之前的數據都會被緩存。此外還有可能導致接收方接收到重復的數據，因為IP數據報會可能發生重復，這就必須在接收方將重復的數據剔除。

全雙工通信

在 TCP連接建立后，任何一個主機都可以向另一個主機發送數據，數據是雙向流通的。在實際情況中，很大一部分的 TCP的確認是通過 捎帶的方式來實現，即接收方把確認信息放到發送給發送方的報文段中，不必單獨為確認信息申請一個報文。

當然斷開連接也是一樣的，任意一方都可以主動斷開，不過對于服務器來說，應用程序一般不會主動斷開 TCP連接，這其實是有點 貪婪思想了，不到萬不得已，都不會主動斷開連接。

流量控制

一條 TCP連接每一側的主機都設置了緩沖區域，很多時候可能對于接收方來說并不會立即去處理這些數據，如果發送方一直發送數據，就很可能導致接收方來不及處理，就像喂小孩子吃飯那樣，你一直給他塞飯，他根本咽不下是吧，所以 TCP協議就提供了來了控制，消除發送方使接收方緩沖區溢出的可能，流量控制其實是一個速度匹配的服務，讓接收方的處理速度趕得上發送方的發送速度，就像小孩子，吃飯的速度趕得上你喂食的速度，但是小孩子的自身（硬件）是沒法改變的，總不能讓他有我們的吃飯速度對不對，那么只能改變我們喂食的速度了，我們慢一點，小孩子就不會被噎著。

TCP協議通過讓維護一個接收窗口的變量來提供流量控制，它是接收方用于給發送方一個指示：我還能接收多少數據，接收方會將此窗口值放在 TCP 報文的首部中的窗口字段，然后通過確認報文發送給發送方，這個窗口的值的大小是在發送數據的時候動態調整的。

當然，如果接收窗口的大小是 0怎么辦？能想到這個問題的人很牛逼， 留個言我給你點個贊！

簡單來說說協議棧通信的處理無非是兩種方式觸發，要么是事件、要么是時間（定時器），事件觸發就是我在等你連接事件發生，然后我響應，時間觸發就是超時后我再處理，都是比較容易理解的。

回到如果接收窗口的大小是 0怎么辦這個問題，那么接收窗口為0時，發送方應該怎么發送數據呢，總不能不發，也總不能是直接斷開吧，既然這樣子，那應該什么時候發呢？

當發送方收到接收方的報文，報文中指定接收窗口的大小為0，那么這是一個事件，發送方就會啟動一個探測定時器，來探測接收方什么時候能接收數據，而定時器就可以產生超時對吧，每次超時就發送一個字節的數據給接收方，并且記錄超時的次數并且刷新定時器，如果在超時之前收到來自接收方的報文，報文中指定接收窗口的大小不為0，這也是一個事件，那么就關閉探測定時器，然后正常發送數據。當然，如果超時次數到達極限，將終止 tcp連接或者是 reset。

擁塞控制

在局域網中傳輸數據的話，僅使用流量控制就能達到速度匹配的結果，這種理想情況還是非常好的，但是實際情況中，在發送方和接收方之間存在多個路由器和速率較慢的鏈路時，就有可能出現一些問題。一些中間路由器可能緩存IP數據報，并有可能耗盡存儲器的空間，這就導致這些中間路由器不再接收IP數據報并轉發，然后這些報文將被丟棄，而TCP協議發現被丟棄了又會重新發送，這種情況就導致越來越嚴重的問題——擁塞。就像過年時候回家的大塞車。

TCP協議的發展，有越來越多的控制算法來避免這些問題，比如慢啟動算法，擁塞避免，擁塞發生，快速恢復等算法，慢啟動為發送方的TCP增加了另一個窗口：擁塞窗口。當與主機建立 TCP連接時，擁塞窗口被初始化為 1個報文段（即另一端通告的報文段大小）。每收到一個 ACK，擁塞窗口就增加一個報文段（ 注意增加的不是字節而是報文段）。

簡單來說就是：發送方開始時發送一個報文段，然后等待 ACK。當收到該 ACK時，擁塞窗口從 1增加為 2，即可以發送兩個報文段。當收到這兩個報文段的 ACK時，擁塞窗口就增加為 4，這是一種指數增加的關系。

當然啦，我這篇文章還是非常表面地介紹這些知識，更多詳細知識還是得看書！