TCP協議目前是事實上的網絡基礎。許多更高層的應用協議HTTP,FTP都基于TCP。

TCP協議的學習可以說枯燥無比，尤其是學生階段，根本不知道用在什么地方，根本不知道重要性是什么。事實上是，基于目前的網絡發(fā)展和分布式發(fā)展，TCP簡直就是基礎中的基礎。許多網絡的問題，配置，防御乃至架構，都涉及到TCP的具體應用及機制。

[[265370]]

以下是我總結的TCP學習過程

1. 了解學習TCP協議的重要性和必要性，了解TCP協議為什么被發(fā)展出來

推薦這個問題下的各個回答：TCP/IP 協議到底在講什么?

https://www.zhihu.com/question/51074319

2. 學習TCP協議的三次握手以及四次揮手，重點了解為什么要三次握手，為什么要四次揮手，在整個過程中狀態(tài)是如何變遷的。(經典的狀態(tài)圖以及握手揮手圖)

a.為什么要三次握手?不是一次，兩次或者四次。我們來論證一下，如果只有一次會發(fā)生什么情況，a向b發(fā)起連接請求，假設b沒收到，則b其實完全不知道a發(fā)起了請求，而a也完全不知道b收沒收到，所以一次握手是不可靠的;如果兩次握手呢，a向b發(fā)起連接請求，b收到a的請求給a回復一個請求，假設此時a收到了b的回復，a知道了b已經ready了，可b完全不知道a是否ready，有可能a并沒有收到b的請求，也有可能收到了，但這些b都完全不知道，所以只是單向的建立了連接;如果是四次握手呢，其實第2次讓a知道b ready了，第三次讓b知道a也ready了，第四次完全就是多余了，會浪費網絡資源。

b.為什么要四次揮手?不是3次?實際上兩邊連接完全可以分開看，用2次揮手斷開其中一邊連接，用另外2次揮手斷開另一邊的連接，最終完成整個連接關閉。之所以這樣設計，是因為有可能某一邊數據還未傳輸完，連接還未關閉。因為TCP被設計為全雙工協議，可以任何一邊單向發(fā)送數據。

1. 握手及揮手過程

2. TCP的狀態(tài)轉換圖

3. 學習TCP協議是如何保持可靠性設計的。

主要目的是用來參考，以便在其他通信場合時用作架構和設計的參考

1).包應答序列號及包重組。

面臨的問題：網絡傳輸中，會出現數據的破壞，丟包，重復，分片混亂等問題。

本質上，要想保證傳輸的可靠性，則需要對傳輸的內容進行驗證。

a. 對于網絡數據的破壞(比如宇宙射線影響偷笑導致發(fā)射火箭的數據中某一位從0變?yōu)?)，采取的策略是丟棄重新發(fā)送，以確保不會出現致命的錯誤。TCP在自身協議中單獨劃了一塊checksum用于這種校驗，校驗算法本質上是將整塊數據通過某個函數映射到16位的校驗位上(比如用字符相加的和來校驗)

b. 對于數據傳輸正確，但是分片亂序，重復等問題，或是丟包，采取的策略并非丟棄而是自行進行包重組。

考慮兩種情況：一是某個包缺少了，導致整個數據中間缺了一段1000字節(jié)，那么如何通知到對方自己少了哪一段數據;另一種情況是由于網絡或者重發(fā)機制的原因導致某一個包收到多次，如何把多余的包都排除掉，僅保留已有數據。

TCP在設計時候充分考慮這點，其中SYN和ACK就是用來確保這個過程的，SYN發(fā)送的是字節(jié)順序，ACK則應答收到的字節(jié)序加1。這樣，無論是發(fā)送方還是接收方，都可以準確的維護一張發(fā)送接收字節(jié)的列表。從而可以知道對方還需要哪些字節(jié)，或自己已經接收了哪些字節(jié)。

2).重發(fā)機制

a. 超時重發(fā)

為了保證數據一定被接收到，就必須妥善處理超時，對于超時沒得到響應，則需要重新發(fā)送。

首先將數據拷貝到發(fā)送緩沖區(qū)，每個包在發(fā)送時都會啟動一個定時器，如果定時器超時前收到了對方應答，則發(fā)送成功，清除緩沖區(qū)，否則重傳數據包，直到達上線。

TCP在每次發(fā)包時都會計算往返時間極其偏差，通過這個記錄可以大致判斷雙方的網絡情況從而確定超時時間。通常剛開始超時時間較長(如6s)，而后可能到0.5s這樣較小的時間。

b. 高速重發(fā)

比起超時才重新發(fā)送，TCP還設計了更為巧妙的方式來做重發(fā)。稱為快速重發(fā)。即目標主機在確認時總是確認缺失包，當發(fā)送方發(fā)現連續(xù)收到3個同樣的ack時，則表明該包已經丟了，需要快速重新發(fā)送，這樣能否避免要等到超時才能重發(fā)。

更多可以參考這里

https://wizardforcel.gitbooks.io/network-basic/content/8.html

3).流量控制(滑動窗口)

a. 滑動窗口協議

滑動窗口本質上是為了在通信過程中同步收發(fā)雙方的速率。通過發(fā)送端的發(fā)送窗口和接收端的接收窗口來保證發(fā)送的可靠性，同時協調發(fā)送的速度。

對于發(fā)送端來說，整個窗口分為下面四段，一是已經發(fā)送也收到確認回復的;二是已經發(fā)送但尚未收到回復的;三是還沒有發(fā)送但即將發(fā)送的(接收方有空間，只是發(fā)送方尚未發(fā)送而已);四是沒發(fā)送，但是接收方已經沒空間的

同理，對于接收方來說，整個窗口分為三段，一是已經接收并且已經回復ACK的;二是已經接收的;三是為接收也沒準備接收的

而所謂的滑動，則是將窗口從上一次收到的連續(xù)ACK的位置整個劃到下一次收到連續(xù)ACK的位置而已。注意連續(xù)二字，不連續(xù)則不能算作已經接收完畢。

b. 滑動窗口的收縮與擴張

滑動窗口最牛逼的地方在于動態(tài)的調整收發(fā)雙方的窗口大小，以便使得收發(fā)雙方通信同步而不僅僅是對于發(fā)送接收字節(jié)的管理。

在TCP協議中，有16個字節(jié)專門用來放window大小，是接收端主機向發(fā)送方主機通知自己可以接納的數據大小，而發(fā)送方會根據該窗口數據發(fā)送不超過這個限度的數據。接收方可以根據自己的處理能力不斷的增大或者縮小這個值，而發(fā)送方主機則只要保持與之同步即可。

當收縮到最小(即0窗口)時，按照約定發(fā)送方不能再給接收方發(fā)送數據了，那豈不是陷入死局，大家從此斷開?實際上發(fā)送方會一段時間后重試，如果還不行拉長一段時間后再重試，直到達到重試次數上線。

4).擁塞控制

擁塞控制的起因是，作為TCP本身雖然已經有了各種校驗和檢測方法保證通信雙方能否互相通信并且能夠同步雙方的情況了。但是它還忽略了一個關鍵因素—網絡狀況。網絡是通路，如果這個通路太擁擠，應該適當減少發(fā)送，而如果這個通路比較寬松，則可以適當增加發(fā)送。

TCP的擁塞控制包括：慢啟動，擁塞避免，擁塞發(fā)生，快速恢復。

慢啟動每次將擁塞窗口的大小設置為1個數據段，之后每次收到確認應答則擁塞窗口加1

由于這很容易造成指數級的增長放大，于是又引入一個慢啟動閾值的概念，即當tcp通信開始時，網絡吞吐會急劇上升，當到達一個閾值之后，則開始下降然后緩慢上升。