TCP協(xié)議簡單了解

TCP（Transmission Control Protocol，傳輸控制協(xié)議），它是最常用傳輸層協(xié)議，也是最穩(wěn)定傳輸層協(xié)議，很多上層應(yīng)用都是依賴于TCP進(jìn)程傳輸數(shù)據(jù)。

TCP 屬于傳輸層協(xié)議，它為應(yīng)用層提供了可靠的字節(jié)流服務(wù)。在網(wǎng)絡(luò)協(xié)議棧中對它的描述要比對其它協(xié)議的描述復(fù)雜的多，這也導(dǎo)致了lwip中很大一部分代碼都是用于描述TCP協(xié)議的。

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

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

TCP一旦發(fā)現(xiàn)傳輸出錯就會重新傳輸數(shù)據(jù)包，直到所有數(shù)據(jù)安全、正確地傳送到目的地，再遞交到應(yīng)用層。

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

TCP協(xié)議的特性

面向連接

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

正面確認(rèn)

當(dāng)TCP協(xié)議發(fā)出一個TCP報(bào)文段后，它啟動一個定時器，等待目的端主機(jī) 確認(rèn)收到這個報(bào)文段，如果不能及時收到一個確認(rèn)，將重發(fā)這個報(bào)文段。一個完整的TCP傳輸必須有兩個端的主機(jī)進(jìn)行數(shù)據(jù)的交互，接收方在接收到數(shù)據(jù)之后必須正面進(jìn)行確認(rèn)，向發(fā)送方報(bào)告接收的結(jié)果。

因?yàn)門CP協(xié)議依賴的是IP層的服務(wù)，IP數(shù)據(jù)報(bào)的傳輸是無連接、不可靠的，因此它要通過確認(rèn)來知道接收方確實(shí)已經(jīng)收到數(shù)據(jù)了。

數(shù)據(jù)分割

應(yīng)用數(shù)據(jù)會被分割成TCP協(xié)議認(rèn)為最適合發(fā)送的報(bào)文段，這些其實(shí)是動態(tài)調(diào)整的， TCP協(xié)議只能是盡可能發(fā)送最大報(bào)文段（MSS）以保證數(shù)據(jù)傳輸?shù)乃俾省?/p>

數(shù)據(jù)緩沖

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

發(fā)送方在將數(shù)據(jù)發(fā)送出去后并不會 立即刪除數(shù)據(jù)，而是讓數(shù)據(jù)依舊保存在緩沖區(qū)中（實(shí)際上是使用鏈表維護(hù)的），因?yàn)榘l(fā)送出去的數(shù)據(jù)不一定能被接收方正確接收，它需要等待到接收方的確認(rèn)再將數(shù)據(jù)刪除。

同樣的，在接收方也需要有同樣的緩沖機(jī)制，因?yàn)?TCP協(xié)議是以字節(jié)流發(fā)送數(shù)據(jù)的，這些數(shù)據(jù)可能會分割成多個 TCP報(bào)文段，而且在網(wǎng)絡(luò)中傳輸?shù)母鱾€ TCP報(bào)文段到達(dá)目標(biāo)主機(jī)的時間可能是不一樣的，這就導(dǎo)致數(shù)據(jù)失序，接收方需要把這些數(shù)據(jù)報(bào)組裝成完整且有序的數(shù)據(jù)，然后再遞交到應(yīng)用層中，在這之前的數(shù)據(jù)都會被緩存。此外還有可能導(dǎo)致接收方接收到重復(fù)的數(shù)據(jù)，因?yàn)镮P數(shù)據(jù)報(bào)會可能發(fā)生重復(fù)，這就必須在接收方將重復(fù)的數(shù)據(jù)剔除。

全雙工通信

在 TCP連接建立后，任何一個主機(jī)都可以向另一個主機(jī)發(fā)送數(shù)據(jù)，數(shù)據(jù)是雙向流通的。在實(shí)際情況中，很大一部分的 TCP的確認(rèn)是通過 捎帶的方式來實(shí)現(xiàn)，即接收方把確認(rèn)信息放到發(fā)送給發(fā)送方的報(bào)文段中，不必單獨(dú)為確認(rèn)信息申請一個報(bào)文。

當(dāng)然斷開連接也是一樣的，任意一方都可以主動斷開，不過對于服務(wù)器來說，應(yīng)用程序一般不會主動斷開 TCP連接，這其實(shí)是有點(diǎn) 貪婪思想了，不到萬不得已，都不會主動斷開連接。

流量控制

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

TCP協(xié)議通過讓維護(hù)一個接收窗口的變量來提供流量控制，它是接收方用于給發(fā)送方一個指示：我還能接收多少數(shù)據(jù)，接收方會將此窗口值放在 TCP 報(bào)文的首部中的窗口字段，然后通過確認(rèn)報(bào)文發(fā)送給發(fā)送方，這個窗口的值的大小是在發(fā)送數(shù)據(jù)的時候動態(tài)調(diào)整的。

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

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

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

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

擁塞控制

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

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

簡單來說就是：發(fā)送方開始時發(fā)送一個報(bào)文段，然后等待 ACK。當(dāng)收到該 ACK時，擁塞窗口從 1增加為 2，即可以發(fā)送兩個報(bào)文段。當(dāng)收到這兩個報(bào)文段的 ACK時，擁塞窗口就增加為 4，這是一種指數(shù)增加的關(guān)系。

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