TCP協(xié)議目前是事實(shí)上的網(wǎng)絡(luò)基礎(chǔ)。許多更高層的應(yīng)用協(xié)議HTTP,FTP都基于TCP。

TCP協(xié)議的學(xué)習(xí)可以說(shuō)枯燥無(wú)比，尤其是學(xué)生階段，根本不知道用在什么地方，根本不知道重要性是什么。事實(shí)上是，基于目前的網(wǎng)絡(luò)發(fā)展和分布式發(fā)展，TCP簡(jiǎn)直就是基礎(chǔ)中的基礎(chǔ)。許多網(wǎng)絡(luò)的問(wèn)題，配置，防御乃至架構(gòu)，都涉及到TCP的具體應(yīng)用及機(jī)制。

[[265370]]

以下是我總結(jié)的TCP學(xué)習(xí)過(guò)程

1. 了解學(xué)習(xí)TCP協(xié)議的重要性和必要性，了解TCP協(xié)議為什么被發(fā)展出來(lái)

推薦這個(gè)問(wèn)題下的各個(gè)回答：TCP/IP 協(xié)議到底在講什么?

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

2. 學(xué)習(xí)TCP協(xié)議的三次握手以及四次揮手，重點(diǎn)了解為什么要三次握手，為什么要四次揮手，在整個(gè)過(guò)程中狀態(tài)是如何變遷的。(經(jīng)典的狀態(tài)圖以及握手揮手圖)

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

b.為什么要四次揮手?不是3次?實(shí)際上兩邊連接完全可以分開看，用2次揮手?jǐn)嚅_其中一邊連接，用另外2次揮手?jǐn)嚅_另一邊的連接，最終完成整個(gè)連接關(guān)閉。之所以這樣設(shè)計(jì)，是因?yàn)橛锌赡苣骋贿厰?shù)據(jù)還未傳輸完，連接還未關(guān)閉。因?yàn)門CP被設(shè)計(jì)為全雙工協(xié)議，可以任何一邊單向發(fā)送數(shù)據(jù)。

1. 握手及揮手過(guò)程

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

3. 學(xué)習(xí)TCP協(xié)議是如何保持可靠性設(shè)計(jì)的。

主要目的是用來(lái)參考，以便在其他通信場(chǎng)合時(shí)用作架構(gòu)和設(shè)計(jì)的參考

1).包應(yīng)答序列號(hào)及包重組。

面臨的問(wèn)題：網(wǎng)絡(luò)傳輸中，會(huì)出現(xiàn)數(shù)據(jù)的破壞，丟包，重復(fù)，分片混亂等問(wèn)題。

本質(zhì)上，要想保證傳輸?shù)目煽啃裕瑒t需要對(duì)傳輸?shù)膬?nèi)容進(jìn)行驗(yàn)證。

a. 對(duì)于網(wǎng)絡(luò)數(shù)據(jù)的破壞(比如宇宙射線影響偷笑導(dǎo)致發(fā)射火箭的數(shù)據(jù)中某一位從0變?yōu)?)，采取的策略是丟棄重新發(fā)送，以確保不會(huì)出現(xiàn)致命的錯(cuò)誤。TCP在自身協(xié)議中單獨(dú)劃了一塊checksum用于這種校驗(yàn)，校驗(yàn)算法本質(zhì)上是將整塊數(shù)據(jù)通過(guò)某個(gè)函數(shù)映射到16位的校驗(yàn)位上(比如用字符相加的和來(lái)校驗(yàn))

b. 對(duì)于數(shù)據(jù)傳輸正確，但是分片亂序，重復(fù)等問(wèn)題，或是丟包，采取的策略并非丟棄而是自行進(jìn)行包重組。

考慮兩種情況：一是某個(gè)包缺少了，導(dǎo)致整個(gè)數(shù)據(jù)中間缺了一段1000字節(jié)，那么如何通知到對(duì)方自己少了哪一段數(shù)據(jù);另一種情況是由于網(wǎng)絡(luò)或者重發(fā)機(jī)制的原因?qū)е履骋粋€(gè)包收到多次，如何把多余的包都排除掉，僅保留已有數(shù)據(jù)。

TCP在設(shè)計(jì)時(shí)候充分考慮這點(diǎn)，其中SYN和ACK就是用來(lái)確保這個(gè)過(guò)程的，SYN發(fā)送的是字節(jié)順序，ACK則應(yīng)答收到的字節(jié)序加1。這樣，無(wú)論是發(fā)送方還是接收方，都可以準(zhǔn)確的維護(hù)一張發(fā)送接收字節(jié)的列表。從而可以知道對(duì)方還需要哪些字節(jié)，或自己已經(jīng)接收了哪些字節(jié)。

2).重發(fā)機(jī)制

a. 超時(shí)重發(fā)

為了保證數(shù)據(jù)一定被接收到，就必須妥善處理超時(shí)，對(duì)于超時(shí)沒(méi)得到響應(yīng)，則需要重新發(fā)送。

首先將數(shù)據(jù)拷貝到發(fā)送緩沖區(qū)，每個(gè)包在發(fā)送時(shí)都會(huì)啟動(dòng)一個(gè)定時(shí)器，如果定時(shí)器超時(shí)前收到了對(duì)方應(yīng)答，則發(fā)送成功，清除緩沖區(qū)，否則重傳數(shù)據(jù)包，直到達(dá)上線。

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

b. 高速重發(fā)

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

更多可以參考這里

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

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

a. 滑動(dòng)窗口協(xié)議

滑動(dòng)窗口本質(zhì)上是為了在通信過(guò)程中同步收發(fā)雙方的速率。通過(guò)發(fā)送端的發(fā)送窗口和接收端的接收窗口來(lái)保證發(fā)送的可靠性，同時(shí)協(xié)調(diào)發(fā)送的速度。

對(duì)于發(fā)送端來(lái)說(shuō)，整個(gè)窗口分為下面四段，一是已經(jīng)發(fā)送也收到確認(rèn)回復(fù)的;二是已經(jīng)發(fā)送但尚未收到回復(fù)的;三是還沒(méi)有發(fā)送但即將發(fā)送的(接收方有空間，只是發(fā)送方尚未發(fā)送而已);四是沒(méi)發(fā)送，但是接收方已經(jīng)沒(méi)空間的

同理，對(duì)于接收方來(lái)說(shuō)，整個(gè)窗口分為三段，一是已經(jīng)接收并且已經(jīng)回復(fù)ACK的;二是已經(jīng)接收的;三是為接收也沒(méi)準(zhǔn)備接收的

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

b. 滑動(dòng)窗口的收縮與擴(kuò)張

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

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

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

4).擁塞控制

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

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

慢啟動(dòng)每次將擁塞窗口的大小設(shè)置為1個(gè)數(shù)據(jù)段，之后每次收到確認(rèn)應(yīng)答則擁塞窗口加1

由于這很容易造成指數(shù)級(jí)的增長(zhǎng)放大，于是又引入一個(gè)慢啟動(dòng)閾值的概念，即當(dāng)tcp通信開始時(shí)，網(wǎng)絡(luò)吞吐會(huì)急劇上升，當(dāng)?shù)竭_(dá)一個(gè)閾值之后，則開始下降然后緩慢上升。