TCP有關的資料和書籍，網上搜索恐怕汗牛充棟，我寫這篇博客也是爲了學習鞏固，參考了《計算機網絡》和goole的很多博客，畢竟站在巨人的肩膀上才能看的更高走的更遠。

1.TCP協議

TCP協議屬於TCP/IP協議中的傳輸層協議，有以下幾個特點。

TCP是面向連接的運輸層協議。
每一條TCP連接只能點對點
TCP提供可靠交付的服務
TCP提供全雙工通訊
面向字節流。

TCP是面向連接的傳輸層協議

TCP在傳輸數據前必須讓接受方和發送方建立連接，然後才能傳輸數據，當傳輸完成後，要將該連接釋放。就像打電話。

每一條TCP連接只能點對點

每一條TCP通過端口號來連接受方和發送方。

TCP提供可靠交付的服務(重點)

發送方通過TCP連接發送的數據，可靠，無差錯，有序的發送到接受方。

TCP提供全雙工通信

TCP運行通信雙方在任何時候發送數據，TCP連接的兩端都設有發送緩衝和接收緩存，用來臨時存放雙向通訊的數據。

TCP面向字節流

雖然應用程序使用TCP協議發送數據，一次發送一個大小不等的數據塊，但是TCP只是把應用程序發送的數據塊當成無結構的字節流，TCP不保證發送方的數據塊和接受方接受的數據快大小對應，例如發送方發了10個數據塊，但是接受方只用了4個數據塊就把收到的字節流發給上層的應用程序（有的童學可能覺得這和TCP的安全可靠矛盾，這樣豈不是丟了6個數據塊，肯定不可能的，雖然數據塊的個數不同，但是TCP發送的字節流是一樣的）

1.TCP報文首部的格式

圖片來源《計算機網絡第七版》謝希仁
首部各字段意義如下

源端口和目的端口號：各佔2個字節，分別寫入源端口號和目的端口號。
序號：佔4比特位，範圍[0，2^32-1]，序號最大後+1，編號又回到0，進行mod2 ^32操作。TCP是面向字節流的，對於TCP連接的字節流的每一個字節都按順序編號。整個字節流的初始序號必須在連接時建立。首部的序號字段表示本報文段所發送的數據的第一個字節的序號。
確認號：佔4比特位，請問收到的對方下一個報文段的第一個數據字節的序號。
若確認號爲N，則表明：到序號N-1的字節已經成功收到。
數據偏移：4比特位，指出TCP報文段的數據起始到TCP報文段的起始的距離，實際上指的是首部長度，數據偏移的單位是4字節，最大能夠表示的值是15，因此TCP最大的首部長度爲60字節。
保留：佔6比特位，爲以後做準備，當前置爲0.
URG：URG=1時，表示系統有緊急數據，和緊急指針配合使用。
ACK: ACK=1時，確認號字段有效，TCP規定，在連接建立後的所有傳輸的報文段必須把ACK置爲1.
PSH：PSH=1時，表示一端的應用進程希望在鍵入一個命令後立刻收到對方的響應。接受方收到PSH=1的報文，就儘快地交付交付給接收應用程序，而不是等緩存都填滿後向上交付。
復位RST：RST=1，表示TCP中產生了嚴重的差錯，必須釋放連接，然後重新建立運輸連接。
SYN：SYN=1，作用建立連接時同步序號的，若對方同樣連接則，返回的報文SYN和ACK置爲1，具體在三次握手，四次揮手中詳細討論。
FIN：FIN=1，表示此報文段的發送方的數據已經發送完畢，要求釋放運輸連接。
窗口：佔2字節。值爲[0,2^16-1]之間，窗口指的是發送本報文段的接收窗口，告訴對方本報文段首部的確認號算起，可以接受的最大數據量。窗口字段明確指出了允許對方發送的數據量，經常動態變化，
校驗和：佔2字節，校驗首部和數據兩部分。
緊急指針：佔兩字節，指出本報文段中的緊急數據的字節數。
選項：長度可變，最長40字節，開始的選項只有MSS，最大報文段長度，表示每一個TCP報文的數據字段的最大長度。
MSS：和接受窗口沒關係，如果選擇較小的MSS會導致網絡的利用率變低，如果MSS過高，在IP層傳輸時就有可能分解成多個短數據報片段，增大開銷。MSS的默認值爲536.
SACK：選擇確認，能夠傳輸缺少的數據而不重傳已經正確達到接受方的數據，在後面我們還會講。
窗口擴大：爲了擴大窗口，TCP首部的窗口字節長度爲16，窗口擴大佔3個字節，其中一個字節是S，新的窗口值爲16+S，移位符的最大值爲14，當連接的某一端不需要擴大窗口，可發送S=0的選項，使其窗口大小返回0.
時間戳：佔10字節主要是時間戳值字段和時間戳回送回答字段。，用於計算往返時間，發送方把發送報文的當前時間放到時間戳中，接受方接受到後，把時間戳複製到確認報文的時間戳中，因此發送方可以計算出RTT。，還可以防止序號繞回的情況PAWS，每一個字節都有一個序號，當使用1.5M/s的速率發送報文段是，六小時後會有序號重複，可以用時間戳區分兩個相同序號的字節。

以上就是TCP報文的報頭看起來枯燥乏味，但是是TCP協議的基礎，我們需要爛熟於心，才能理解TCP協議的實現細節。

2.可靠傳輸的工作原理

1.停止等待協議

TCP協議的通訊雙方即是發送方又是接受方，爲了討論方便，我們只考慮A發送數據B接受數據並返回應答的情況，A爲發送方，B爲接受方，發送的數據單元都稱爲分組，“停止等待”就是每發送完一個分組就停止發送，等待對方的確認，收到確認後再發送下一個數據單元。
下面是理想狀態下的無差錯情況，縱軸爲時間。

A發送分組M1給B，B收到後發送M2給A確認收到，A收到M2後再將下一個分組M3發給B，以此類推，這種機制叫做確認應答機制。
出現差錯情況

上圖是出現查重的情況，B在收到錯誤的報文M1後，將其丟棄並且不通知A，或者M1因爲網絡問題沒有傳輸至B，這兩種情況下B不發送任何信息，A只要超過一定的時間沒有收到B的確認分組，就會認爲前面發送的報文丟失了，會重新發送前面的分組，這種機制叫做超時重傳。
爲了實現這種機制，需要在每一個發送分組後設置一個超時計時器，在時間範圍內，收到對方的確認，就撤銷該計時器。
需要注意以下幾點

A發送完一個分組後，必須暫時保留已發送的分組的副本，只有收到確認後才能清除。
分組和確認分組必須進行編號，這樣才能區分發送的哪個分組得到確認，哪個分組沒有收到確認。
超時計時器設置的超時時間應該比數據在分組傳輸的平均往返時間多一些。有兩方面考慮，假設超時時間過長，顯然會降低通訊效率，但是超時時間短，會導致不必要的重傳，浪費網絡資源，對於超時重傳的時間選擇並不簡單，甚至可以說是TCP最複雜的問題只一。

下面是另一種情況，B對A發送的確認丟失了，A在超時計時器的時間內沒有收到確認，A會在時間到期後重傳M1，B收到了這個重複的確認M1，會做兩件事情

丟棄這個重複的M1，不向上級交付。
向A發送確認，雖然之前已經發送過一次，但是A又發送了一次M1，說明A沒有收到M1的確認。

下面是另一種可能的情況，B對A的應答遲到了，因此A會收到重複的確認，對重複確認的處理非常簡單，收下後就丟棄，在此之前B仍會收到重複的M1，和上面的操作一樣，丟棄重複的M1，向A發送確認。

通常A總能受到對方發出的確認，如果A不斷重複發分組卻收不到確認，說明網絡太差了。
上面的這種協議稱爲自動重傳請求ARQ，意思是重傳的請求是自動的，使用重傳和確認機制就能在不可靠的網絡上實現可靠的傳輸。

超時重傳的時間選擇

TCP採用自適應算法，它記錄一個報文段從發出的時間到收到的確認的響應的時間，這兩個時間的差值就是報文段的往返事件RTT。TCP保留一個RTT的加權平均往返時間RTTs。每當第一次測量RTT樣本，RTTs就是該RTT樣本，但是以後每次重新測量一個RTT樣本就，重新計算一次RTTs。

a建議取1/8，即0.125用這種方法算出的RTTs比測量出的RTT值更加平滑。
因此超時計數器的超時重傳時間RTO應該略大於上面計算出的平均往返時間RTTs，公式如下

RTTd是RTT的偏差的加權平均值，用以下公式計算，第一次測量時，RTTd爲測量的RTT的一半，B推薦爲1/4.即0.25。

上面的公式已經夠複雜了，但是我們的任務還沒完，假如我們發送了一個報文段，在超時時間範圍內沒有收到確認，因此我們重新發送了一個報文段，之後收到了一個確認應答，問題在於如何判定此確認報文是對先發送的報文進行確認，還是對後發送的報文進行確認。
無論怎麼判斷都可能產生差錯，因此，TCP規定**報文段每重傳一次，就把超時重傳時間RTO增大一下，典型做法是取新的RTO爲舊的兩倍，當不發生重傳時，使用上面的公式進行計算。**實際證明，這種規定比較合理。

我們介紹完了停止等待進制的基本情況，但是這個機制的最大優點是簡單，缺點是信道利用率太低了，假設A和B減有一條直通的信道來傳送分組。

假設A發送分組的時間是TD,TD等於分組長度除數據率，再假定分組到B後，B處理分組的時間可以忽略不記，B發送確認的時間需要TA，因此信道利用率U計算公式如下.

計算出的信道利用率是十分低下的，爲了提高效率，發送方可以不使用低效率的停止等待協議，而是採用流水線傳輸，所謂的流水線傳輸就是發送方一次發送多個分組，使得信道上一直有數據一直傳輸。

當使用流水線傳輸就要使用連續ARQ協議和滑動窗口協議。

2.連續ARQ協議

下圖表示發送方維持的發送窗口，它的意義爲：位於發送窗口的5個分組都可以連續發出去，而不需要等待對方的確認。這樣，信道利用率就提高了。

橫座標爲時間座標。連續ARQ協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個單位。
接受方一般通過累計確認的方法，也就是收到幾個分組後對按序到達的最後一個分組發送確認，表示之前的分組都已經正確收到了。
累計確認優點爲：容易實現，即使確認丟失也不必重傳，缺點是不能向發送方反映接受方已經接受的所有的分組信息。
例如，如果發送方發送前五個分組，中間第三個分組丟失，接受方只能對前兩個分組發送確認，發送方無法找到後三個分組的下落，只能把後三個分組重新發一次，這種機制叫做Go-back-N（回退N），表示需要重傳已經發生過的N個分組，當通信信號質量不好時，ARQ協議會帶來負面影響。

3.滑動窗口協議

在ARQ協議中，我們已經說了發送窗口。如下

發送窗口後沿的後面表示已經發生且收到確認，發生窗口的前沿的前面表示沒有發生的數據。發送窗口由前後沿共同確定。
發送窗口的前沿可能**向後收縮，這代表窗口變小，但是TCP強烈建議不要這麼做。**因爲可能發送方在收到這個通知前，已經發生了窗口的許多數據，可能會產生很多錯誤。
以一次發送爲例子。

假定A發送了31-41的數據，窗口位置沒改變，描述一個發送窗口的狀態需要三個指針：P1,P2,P3.指針都指向字節序號，意義如下

p3-p1 = A的發送窗口
p2-p1 = 發送但未收到確認的窗口
p3-p2 = 允許發送但未發送的數據
在圖5-16中，B收到了32和33的數據，31沒有收到，B只對按序收到的數據的最高序號給予確認，因此B發出的確認報文段仍爲31.

假設B收到了31數據，並且把31-33的數據交給主機，B刪除這些數據，接着把接受窗口向前移動3個單位，向A發送確認報文號爲34，AA收到B的確認號後就把發送窗口向後滑動3個單位，P2不動，可以看到A的可用窗口增大了。

A繼續發完42-53的數據後，P2和P3進行重合，由於A的發送窗口已滿，停止發送數據。如果因爲網絡的某些原因，A沒有收到B的確認報文，超過超時計數器的時間後會想ARQ機制的回退重傳進制一樣重新，發送報文。

窗口和緩存的關係

下方是緩衝和窗口的邏輯關係。

在這之前要明確兩點

緩衝空間和序號空間是有限的，會循環使用。因此比起條，畫出環更符合情況
圖中的發送程序和接受程序很想我們編程時的write，read函數，但是事實上，這些函數只不過把數據拷到了系統緩存中，剩下的由協議棧來實現。

發送緩衝用來暫時存放

發送應用程序發給TCP準備發送的數據。
TCP已經發生但是沒有收到確認的數據。
發送窗口只是發送緩衝的一部分，已經被確認的數據應當從發送緩衝中刪除，發送後沿和緩存是重合的。

接受緩存用來暫時存放

按序到達，但是沒有被接收應用讀取的數據
沒有按序到達的數據。
如果收到的分組有差錯，則要被丟棄，如果接收應用程序來不及讀取數據，緩存最終會被填滿，使得接收窗口變成0。

最後我們還要強調一下幾點。

A的發送窗口和B的接收窗口不一定相同，因爲通過網絡傳輸窗口值需要一定的時間，另外還可能根據擁塞情況減少自己的發送窗口數值。
對於不按序到達的數據如何處理，TCP沒有規定，但是通常TCO對不按序到達的數據先放到接收窗口，等到字節流所缺少的字節收到後，再按序交付給上層的應用程序
TCO要求接收方必須要有累積確認的功能，這樣可以減少開銷。接收方再合適的時候發送確認，也可以在字節有數據要發送的時候把確認信息順便累積確認捎帶，但是不應該過分推遲發送確認，TCP規定退出發送的時間不應該超過0.5秒，否則會導致發送方不必要的重傳。

TCP流量控制

爲什麼要進行流量控制，原因是假如發送方發送的數據過塊，就接收端就可能來不及接收數據，造成數據的丟失，所謂流量控制就是讓發送方的發送速率不要太快，讓接受方來不及接收。
下圖說明如何用滑動窗口進行流量控制。

可以看到B和A之間通過rwnd的值進行流量控制，rwnd代表當前緩衝區能接收的字節量，發送方的發送窗口不能超過接受方給出的接收窗口的數值。
考慮一種情況，假設第三次B向A發送了rwnd=0的報文後，等到一段時間，B又向A發送一段rwnd=400的報文，很可惜，這個報文在網絡中丟失，因此，A一直在等待B發送的報文，B也一直在等待A發送的報文，陷入相互死鎖的狀態。
爲了解決這個問題，TCP爲每一個連接設置了一個持續計數器。只要TCP連接的一方收到對方的零窗口通知，就啓動，當時間到了，就發送一個零窗口探測報文段，對方給出收到零窗口探測報文時的窗口值，如果窗口表示零，那麼死局就可以打破了。

TCP的擁塞控制

擁塞現象是指到達通信子網中某一部分的分組數量過多，使得該部分網絡來不及處理，以致引起這部分乃至整個網絡性能下降的現象，嚴重時甚至會導致網絡通信業務陷入停頓，即出現死鎖現象。

從上面的定義看出，TCP的阻塞控制和TCP的流量控制有一定的相似處。
網絡阻塞往往由許多的因素引起的，對網絡的某一資源的需求超過了該資源的提供量，說人話就是，需求那麼多，我想去試試。

有的人說，解決擁塞問題爲什麼要TCP去控制，直接把網絡中的資源變多不就行了麼。比如將路由器中的節點緩存容量變大，這樣就能緩存更多的資源。但是你想沒想過雖然節點緩存變大了，但是路由器處理數據包的速度並未發生變化，所以大量的數據就要進行排隊，這時超時重傳就會發生，導致的結果是節點排隊的數據越來越來，直到路由器再也處理不過來就發生了死鎖。又有人說將路由器處理效率提高不久可以了，這確實是一個辦法，但是即便你提高了處理速度，此時網絡傳輸的瓶頸又會被轉移到其他部分，這有點像木桶原理，決定事物好壞的上限永遠和事物的短板緊密相連。
流量控制關注的是端到端的控制，阻塞控制是一個全局性的過程，防止過多的數據注入網絡。

下圖是有關網絡的數據吞吐量與造成的負載。

從上面可以看到，理想狀態下，在吞吐量飽和之前，網絡吞吐量應該等於提供的負載，45%的斜線，超過某個界限後，由於資源受限，吞吐量不再增長而是保持水平線，但是在實際情況下，當吞吐量未到飽和時，已經存在丟包現象了，網絡就進入了輕度阻塞的狀態。
原理上說，阻塞控制就是從兩方面入手，增加資源，減少需求，但是不能盲目的操作，就像前面的例子一樣。
事實上，擁塞控制很難設計，因爲這是一個動態的問題，從大的方面有開環控制和閉環控制，開環時在設計網絡時首先講有關的因素考慮到，力圖工作時不產生阻塞，一旦允許起來，就不中途改正。
閉環控制基於反饋環路的概念，檢測擁塞發生的時間地點，把擁塞發送的信息傳送到可採取行動的地方。調整網絡系統的允許以解決出現的問題。
下面我們來介紹TCP具體的擁塞控制方法

TCP具體的擁塞控制方法

TCP進行阻塞控制的方法一共有四種慢開始，擁塞避免，快重傳，快恢復

1.慢開始

在這裏我們引入一個新概念擁塞窗口cwnd，擁塞窗口的大小取決於網絡的擁塞程度，動態變化，發送方讓自己發送窗口等於擁塞窗口。
控制擁塞窗口的原則爲：只要網絡沒有出現擁塞，擁塞窗口就可以再增大，提高網絡的利用率，只要網絡受到阻塞，擁塞窗口就會變小，緩解網絡出現的阻塞。
發送方怎麼判斷是否發生擁塞？
當網絡發送擁塞，就會產生丟包，網絡就可能發生擁塞，，其他原因產生的丟包的概率極小，因此，對於發送方來說超時就是判斷網絡產生擁塞的原因。
慢開始的思路是這樣的，開始時從小到大逐漸增加發送窗口，也就是從小到大增加擁塞窗口數值。
具體的操作爲，開始發送報文段時，先把初始擁塞窗口cwnd設置爲2到4個SMSS（最大報文段），並且有如下規定。

SMSS>2190 cwnd = 2*SMSS,不能超過兩個報文段
SMSS=2190 cwnd = 3*SMSS,不能超過三個報文段
SMSS<2190 cwnd = 4*SMSS,不能超過四個報文段
滿開始規定，沒收到一個新的報文段確認後，就可以把擁塞窗口增加一個SMSS的數值。
下面用例子來說明。

我們從上面可以看出cwnd，每次發送後都會翻倍，1-2-4-8-…，指數級增長。

所以我們要特別指出慢開始的“慢”不是指速率，而是指TCP開始發送報文段時先設置cwnd=1，然後再逐漸增大cwnd，這比一開始就傳入大量的數據要“慢”的多。
爲了防止cwnd增長過快，引起網絡擁塞，需要設置一個值慢開始門限，來確定當前使用的算法。
比較cwnd和慢開始門限的大小，如果cwnd相對較小使用慢開始算法，否則使用擁塞避免算法。

2.擁塞避免

擁塞避免的思路是讓擁塞窗口緩慢增大，每經過一個往返時間，把發送方的擁塞窗口cwnd+1.以下面爲例。

本例中門限值爲16，cwnd值爲1，在點1之前，用慢開始算法，cwnd成指數增加，到了點1，使用擁塞避免算法，每次輪次後cwnd+1，到了點2，發現超時，說明產生了擁塞，於是調整門限值爲擁塞的cwnd/2=12，cwnd=1，到了點3新的門限值，再次由慢開始，變成了擁塞算法。
到了點4有了新的情況，發送方收到了3個相同的ACK，這是因爲TCP的快重傳算法，需要執行快恢復算法，調整門限值爲當前值/2=8，同時設置cwnd=8，執行擁塞算法。

3.快重傳和快恢復

採用快重傳算法，可以讓發送方儘早發現個別報文段的丟失，快重傳要求不能自己發送數據時捎帶應答，而是立即應答，即使是別的報文段也要應答之前收到的報文段，具體如下。

根據，快重傳規定，接收方只要收到三個重複的確認，就要立刻重傳缺失的文件。
有的同學想問，既然有了這麼方便的快重傳，還要超時重傳幹什麼？假設有一種極端情況，因爲網絡問題，接收端一直收不到對面發出的確認。所以超時重傳是快重傳的最後底線。
快恢復算法有的是將當前門限值/2，並且讓cwnd = 當前門限值，有的則是讓擁塞窗口cwnd+3.
綜上所述，TCP擁塞控制的流程圖如下

所以擁塞避免有兩條路可走，超時重傳+慢開始，快重傳+快恢復。

總結

TCP是傳輸層的協議，五大特點。
TCP可靠傳輸的工作原理是停止等待協議，連續ARQ協議，滑動窗口協議。
TCP報文組成
TCP的流量控制
TCP的擁塞控制。

上面是TCP協議的重點，希望讀者每個知識點都能記住，這裏特別推薦謝希仁老師的《計算機網絡》，上面的大部分知識，和所有的圖都來自該書中。
對於TCP三次握手和四次揮手，因爲特別重要，因此需要再開一個博客來說明，希望看這篇博客的讀者能和我共同進步。

[網絡]——TCP協議分析