1. TCP簡介

傳輸控制協(xié)議（TCP，Transmission Control Protocol）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

1.1 TCP報頭

1、源/目的端口號: 表示數(shù)據(jù)是從哪個進(jìn)程來, 到哪個進(jìn)程去

2、6位標(biāo)志位:

• URG: 緊急指針是否有效
• ACK: 確認(rèn)號是否有效
• PSH: 提示接收端應(yīng)用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走
• RST: 對方要求重新建立連接; 我們把攜帶RST標(biāo)識的稱為復(fù)位報文段
• SYN: 請求建立連接; 我們把攜帶SYN標(biāo)識的稱為同步報文段
• FIN: 通知對方, 本端要關(guān)閉了, 我們稱攜帶FIN標(biāo)識的為結(jié)束報文段

3、16位校驗(yàn)和: 發(fā)送端填充, CRC校驗(yàn). 接收端校驗(yàn)不通過, 則認(rèn)為數(shù)據(jù)有問題. 此處的檢驗(yàn)和不光包含TCP首部, 也包含TCP數(shù)據(jù)部分.

4、16位緊急指針: 標(biāo)識哪部分?jǐn)?shù)據(jù)是緊急數(shù)據(jù)

對于TCP報頭主要講解幾個重要部分：

4位首部長度，首部，和選項(xiàng)之間的關(guān)系：

• 4位TCP報頭長度: 表示該TCP頭部有多少個32位bit(有多少個4字節(jié)); 所以TCP頭部最大長度是15 * 4 = 60（15即1111）。但是四位首部長度不可以是0，即最小首部長度是20，如果長度比20大，則將多出來的長度填到選項(xiàng)中，以保證報頭和有效數(shù)據(jù)的分離。所以他們之間的關(guān)系就是：選項(xiàng)是對超過首部長度的補(bǔ)充，而根據(jù)四位首部長度可以計(jì)算出報頭總長度大小。（0<=選項(xiàng)<=40）。

32位序號和32位確認(rèn)序號分別是干嘛的？

• 首先TCP是基于確認(rèn)應(yīng)答機(jī)制的，即主機(jī)A給主機(jī)B發(fā)送了一則消息，當(dāng)收到主機(jī)B的確認(rèn)信息以后，才保證主機(jī)A發(fā)的信息主機(jī)B收到了，這里就可以提出可靠性的概念，可靠性又可以分為相對可靠性和絕對可靠性，網(wǎng)絡(luò)傳輸數(shù)據(jù)是無法保證絕對可靠的，因?yàn)榭傆幸粭l最新的消息沒有被確認(rèn)。
• 32位序號即主機(jī)A對主機(jī)B發(fā)送消息時由于是面向字節(jié)流的，會將原始報文進(jìn)行分割，則分割的時候就需要對報文進(jìn)行編上序號，以保證在網(wǎng)絡(luò)中傳輸時將順序打亂時主機(jī)B可以按照序號讀到正確的報文順序，（按序到達(dá)）。32位確認(rèn)序號則是主機(jī)B收到來自主機(jī)A的100號消息時，則要給主機(jī)A返回應(yīng)答消息101，代表前100已經(jīng)收到，下次發(fā)送從101號開始發(fā)。即確認(rèn)應(yīng)答機(jī)制。保證雙方有序正常通信。

2. 確認(rèn)應(yīng)答機(jī)制

TCP通過肯定的確認(rèn)應(yīng)答（ACK）實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。當(dāng)發(fā)送端將數(shù)據(jù)發(fā)出之后會等待對短的確認(rèn)應(yīng)答。如果有確認(rèn)應(yīng)答，說明數(shù)據(jù)已經(jīng)成功到達(dá)對端，反之，則數(shù)據(jù)丟失的可能性很大

TCP將每個字節(jié)的數(shù)據(jù)都進(jìn)行了編號. 即為序列號。

每一個ACK都帶有對應(yīng)的確認(rèn)序列號, 意思是告訴發(fā)送者, 我已經(jīng)收到了哪些數(shù)據(jù); 下一次你從哪里開始發(fā)。

3. 超時重傳機(jī)制

重發(fā)超時是指在重發(fā)數(shù)據(jù)之前，等待確認(rèn)應(yīng)答到來的那個特定時間間隔。如果超過了這個時間仍未收到確認(rèn)應(yīng)答，發(fā)送端將進(jìn)行數(shù)據(jù)重發(fā)。

情況一：丟包

• 主機(jī)A發(fā)送數(shù)據(jù)給B之后, 可能因?yàn)榫W(wǎng)絡(luò)擁堵等原因, 數(shù)據(jù)無法到達(dá)主機(jī)B;
• 如果主機(jī)A在一個特定時間間隔內(nèi)沒有收到B發(fā)來的確認(rèn)應(yīng)答, 就會進(jìn)行重發(fā)。

情況二：ACK丟失

• 主機(jī)B會收到很多重復(fù)數(shù)據(jù). 那么TCP協(xié)議需要能夠識別出那些包是重復(fù)的包, 并且把重復(fù)的丟棄掉.這時候我們可以利用前面提到的序列號, 就可以很容易做到去重的效果.

4. 連接管理機(jī)制

連接管理機(jī)制主要是講三次握手和四次揮手，在之前的博文中已經(jīng)有詳細(xì)的講解。

這里主要講面試高頻問題：

三次握手：

一次，兩次，四次或者更多次握手行不行？

• 一次兩次不行，比如給服務(wù)器發(fā)送大量請求，會被攻擊（洪水攻擊）。三次握手，是對通信信道的驗(yàn)證，讓客戶端和服務(wù)器都驗(yàn)證了接受和發(fā)送能力正常，用最小成本驗(yàn)證全雙工。第一次和第二次握手丟失，不用擔(dān)心，因?yàn)殡p方都不會確立連接，最擔(dān)心第三次握手丟失，客戶端認(rèn)為握手成功。四次握手，如果最后一次握手失敗，最擔(dān)心，服務(wù)器認(rèn)為握手成功， 不管幾次握手，都擔(dān)心最后一次。最擔(dān)心最后一次握手丟失，應(yīng)該讓客戶端背鍋，免得服務(wù)器是一對多的，有大量的無用連接，而浪費(fèi)資源。讓服務(wù)器不要出現(xiàn)連接建立誤判的情況，減少服務(wù)器的資源浪費(fèi)。肯定不會用偶數(shù)次，更多奇數(shù)次是可以的，但是要最小成本。

TCP的三次握手是否都可以攜帶數(shù)據(jù)？

• 帶SYN的是不可以攜帶數(shù)據(jù)的第一次和第二次是不可以攜帶數(shù)據(jù)的，但是第三次是可以攜帶數(shù)據(jù)的。
• 假如第一次握手可以攜帶數(shù)據(jù)的話，那對于服務(wù)器太危險，如果惡意攻擊服務(wù)器，每次都在第一次握手中的SYN報文中放入大量數(shù)據(jù)。而且頻繁重復(fù)發(fā)SYN報文，服務(wù)器會花費(fèi)很多的時間和內(nèi)存空間去接收這些報文。
• 第三次握手，此時客戶端已經(jīng)處于ESTABLISHED狀態(tài)。對于客戶端來說，他已經(jīng)建立起連接了，并且已經(jīng)知道服務(wù)器的接收和發(fā)送能力是正常的。所以也就可以攜帶數(shù)據(jù)了。

TCP三次握手失敗，服務(wù)端會如何處理?

握手失敗的原因有兩種：

• 第一種是服務(wù)端沒有收到SYN，則什么都不做。
• 第二種是服務(wù)端回復(fù)了SYN+ACK后，長時間沒有收到ACK響應(yīng)。server端發(fā)送了SYN+ACK報文后就會啟動一個定時器，等待client返回的ACK報文。如果第三次握手失敗的話client給server返回了ACK報文，server并不能收到這個ACK報文。那么server端就會啟動超時重傳機(jī)制，超過規(guī)定時間后重新發(fā)送SYN+ACK，重傳次數(shù)根據(jù)/proc/sys/net/ipv4/tcp_synack_retries來指定，默認(rèn)是5次。如果重傳指定次數(shù)到了后，仍然未收到ACK應(yīng)答，那么一段時間后，server自動關(guān)閉這個連接。但是client認(rèn)為這個連接已經(jīng)建立，如果client端向server寫數(shù)據(jù)，server端將以RST包響應(yīng)。

什么是半連接隊(duì)列？

• 服務(wù)器第一次收到客戶端的SYN之后，就會處于SYN_RECD狀態(tài)，此時雙方還沒有完全建立連接。服務(wù)器會把這種狀態(tài)下的請求連接放在一個隊(duì)列里，我們把這種隊(duì)列稱之為半連接隊(duì)列。當(dāng)然還有一個全連接隊(duì)列，就是已經(jīng)完成三次握手，建立起來連接的就會放在全連接隊(duì)列中，如果隊(duì)列滿了就有可能出現(xiàn)丟包現(xiàn)象。

四次揮手：

當(dāng)客戶端想要斷開連接時，并不是徹底和服務(wù)器斷開了，是指應(yīng)用層不會發(fā)數(shù)據(jù)了。客戶端有四次狀態(tài)，服務(wù)器有三次狀態(tài)。

為什么握手是三次，而揮手時需要四次呢？

• 其實(shí)在TCP握手的時候，接收端將SYN包和ACK確認(rèn)包合并到一個包中發(fā)送的，所以減少了一次包的發(fā)送。對于四次揮手，由于TCP是全雙工通信，主動關(guān)閉方發(fā)送FIN請求不代表完全斷開連接，只能表示主動關(guān)閉方不再發(fā)送數(shù)據(jù)了。而接收方可能還要發(fā)送數(shù)據(jù)，就不能立即關(guān)閉服務(wù)器端到客戶端的數(shù)據(jù)通道，所以就不能將服務(wù)端的FIN包和對客戶端的ACK包合并發(fā)送，只能先確認(rèn)ACK，等服務(wù)器無需發(fā)送數(shù)據(jù)時在發(fā)送FIN包，所以四次揮手時需要四次數(shù)據(jù)包的交互。

CLOSE_WAIT狀態(tài)詳談：

• 出現(xiàn)CLOSE_WAIT，說明Server端沒有發(fā)起close()操作，這基本上是用戶server端程序的問題了；通常情況下，Server都是等待Client訪問，如果Client退出請求關(guān)閉連接，server端自覺close()對應(yīng)的連接，當(dāng)服務(wù)器接受到來自客戶端FIN的斷開請求時，服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)，并發(fā)送ACK，直到服務(wù)器想要斷開連接時，發(fā)送FIN和ACK斷開請求，并轉(zhuǎn)變?yōu)長AST_ACK狀態(tài)，如果用netstat查看有大量的CLOSE_WAIT狀態(tài)說明服務(wù)器代碼有BUG。
• 對于服務(wù)器上出現(xiàn)大量的 CLOSE_WAIT 狀態(tài), 原因就是服務(wù)器沒有正確的關(guān)閉 socket, 導(dǎo)致四次揮手沒有正確完成. 這是一個 BUG. 只需要加上對應(yīng)的 close 即可解決問題

TIME_WAIT狀態(tài)詳談：

• 首先調(diào)用close()發(fā)起主動關(guān)閉的一方，在發(fā)送最后一個ACK之后會進(jìn)入time_wait的狀態(tài)，也就說該發(fā)送方會保持2MSL時間之后才會回到初始狀態(tài)。MSL指的是是數(shù)據(jù)包在網(wǎng)絡(luò)中的最大生存時間。
• 確保最后一個確認(rèn)報文能夠到達(dá)。進(jìn)而盡快釋放服務(wù)器的資源。如果沒能到達(dá)，服務(wù)端就會會重發(fā)FIN請求釋放連接。等待一段時間沒有收到重發(fā)就說明服務(wù)的已經(jīng)CLOSE了。如果有重發(fā)，則客戶端再發(fā)送一次ACK信號。
• 等待一段時間是為了讓本連接持續(xù)時間內(nèi)所產(chǎn)生的所有報文都從網(wǎng)絡(luò)中消失，使得下一個新的連接不會出現(xiàn)舊的連接請求報文。
• 如果沒有TIME_WAIT的話，假設(shè)連接1已經(jīng)斷開，然而其被動方最后重發(fā)的那個FIN(或者FIN之前發(fā)送的任何TCP分段)還在網(wǎng)絡(luò)上，然而連接2重用了連接1的所有的5元素(源IP，目的IP，TCP，源端口，目的端口)，剛剛將建立好連接，連接1遲到的FIN到達(dá)了，這個FIN將以比較低但是確實(shí)可能的概率終止掉連接2

解決TIME_WAIT狀態(tài)引起的bind失敗的方法：

在server的TCP連接沒有完全斷開之前不允許重新監(jiān)聽, 某些情況下可能是不合理的

• 服務(wù)器需要處理非常大量的客戶端的連接(每個連接的生存時間可能很短, 但是每秒都有很大數(shù)量的客戶端來請求).
• 這個時候如果由服務(wù)器端主動關(guān)閉連接(比如某些客戶端不活躍, 就需要被服務(wù)器端主動清理掉), 就會產(chǎn)生大量TIME_WAIT連接.
• 由于我們的請求量很大, 就可能導(dǎo)致TIME_WAIT的連接數(shù)很多, 每個連接都會占用一個通信五元組(源ip,源端口, 目的ip, 目的端口, 協(xié)議). 其中服務(wù)器的ip和端口和協(xié)議是固定的. 如果新來的客戶端連接的ip和端口號和TIME_WAIT占用的鏈接重復(fù)了, 就會出現(xiàn)問題.

使用setsockopt()設(shè)置socket描述符的選項(xiàng)SO_REUSEADDR為1, 表示允許創(chuàng)建端口號相同但I(xiàn)P地址不同的多個socket描述符：

5. 滑動窗口

如果出現(xiàn)了丟包, 那么該如何進(jìn)行重傳呢?

分兩種情況討論:

1、數(shù)據(jù)包已經(jīng)收到, 確認(rèn)應(yīng)答ACK丟了：

2、數(shù)據(jù)包丟失：

6. 流量控制

那么接收端如何把窗口大小告訴發(fā)送端呢?

• TCP首部中, 有一個16位窗口大小字段, 就存放了窗口大小的信息;16位數(shù)字最大表示65536, 那么TCP窗口最大就是65536字節(jié)么?
• 實(shí)際上, TCP首部40字節(jié)選項(xiàng)中還包含了一個窗口擴(kuò)大因子M, 實(shí)際窗口大小是窗口字段的值左移 M 位(左移一位相當(dāng)于乘以2).

7. 擁塞控制

如果網(wǎng)絡(luò)上的延時突然增加，那么TCP對這個事作出的應(yīng)對只有重傳數(shù)據(jù)，但是重傳會導(dǎo)致網(wǎng)絡(luò)的負(fù)擔(dān)更重，于是會導(dǎo)致更大的延遲以及更多的丟包，于是這個情況就會進(jìn)入惡性循環(huán)被不斷地放大。試想一下，如果一個網(wǎng)絡(luò)內(nèi)有成千上萬的TCP連接都這么行事，那么馬上就會形成“網(wǎng)絡(luò)風(fēng)暴”，TCP這個協(xié)議就會拖垮整個網(wǎng)絡(luò)。所以TCP不能忽略網(wǎng)絡(luò)上發(fā)生的事情，而無腦地一個勁地重發(fā)數(shù)據(jù)，對網(wǎng)絡(luò)造成更大的傷害。對此TCP的設(shè)計(jì)理念是：TCP不是一個自私的協(xié)議，當(dāng)擁塞發(fā)生的時候，要做自我犧牲。就像交通阻塞一樣，每個車都應(yīng)該把路讓出來，而不要再去搶路了。

少量丟包, 僅僅是觸發(fā)超時重傳; 大量丟包, 認(rèn)為網(wǎng)絡(luò)擁塞;

當(dāng)TCP通信開始后, 網(wǎng)絡(luò)吞吐量會逐漸上升; 隨著網(wǎng)絡(luò)發(fā)生擁堵, 吞吐量會立刻下降;

擁塞控制, 歸根結(jié)底是TCP協(xié)議想盡可能快的把數(shù)據(jù)傳輸給對方, 但是又要避免給網(wǎng)絡(luò)造成太大壓力的折中方案。

8. 延遲應(yīng)答

我們知道TCP中，有確認(rèn)應(yīng)答機(jī)制以保證數(shù)據(jù)的可靠傳輸。但是是不是接受方接受到數(shù)據(jù)就立即返回ACK應(yīng)答呢？如果是這樣，這時候的緩沖區(qū)中接收區(qū)的數(shù)據(jù)還沒能夠處理，緩存區(qū)的剩余大小就是窗口大小。但是如果我們延遲一會，等待緩存區(qū)中數(shù)據(jù)被處理，那么剩余的緩存區(qū)就會大些——這就是延時應(yīng)答。

ps:假設(shè)接收端緩存區(qū)大小為1M，一次接收到了500K的數(shù)據(jù)，現(xiàn)在緩存區(qū)中剩余大小為500。但如果我們延時一段時間，等待接受方處理了該緩存區(qū)中的數(shù)據(jù)，處理以后接受窗口變大，那么我們的剩余大小就為1M了（即：窗口大?。?/p>

窗口越大, 網(wǎng)絡(luò)吞吐量就越大, 傳輸效率就越高. 我們的目標(biāo)是在保證網(wǎng)絡(luò)不擁塞的情況下盡量提高傳輸效率。

等待的時間

• 每個操作系統(tǒng)中設(shè)置的等待時間是不一樣的。（200ms）

是不是所有的包都可以延時應(yīng)答？

• 數(shù)量限制：每隔兩個包就應(yīng)答一次
• 時間限制：超過最大延時時間就應(yīng)答一次（200ms）

具體的數(shù)量和超時時間, 依操作系統(tǒng)不同也有差異; 一般N取2, 超時時間取200ms;

9. 捎帶應(yīng)答

捎帶應(yīng)答是指在同一個TCP包中即發(fā)送數(shù)據(jù)又發(fā)送確認(rèn)應(yīng)答的一種機(jī)制。由此，網(wǎng)絡(luò)的利用率會提高，計(jì)算機(jī)的負(fù)荷也會減輕。不過，確認(rèn)應(yīng)答必須等到應(yīng)用處理完數(shù)據(jù)并將作為回執(zhí)的數(shù)據(jù)返回為止，才能進(jìn)行捎帶應(yīng)答。

10. 面向字節(jié)流

11.粘包問題

• 首先要明確, 粘包問題中的 “包” , 是指的應(yīng)用層的數(shù)據(jù)包.
• 在TCP的協(xié)議頭中, 沒有如同UDP一樣的 “報文長度” 這樣的字段, 但是有一個序號這樣的字段.
• 站在傳輸層的角度, TCP是一個一個報文過來的. 按照序號排好序放在緩沖區(qū)中.
• 站在應(yīng)用層的角度, 看到的只是一串連續(xù)的字節(jié)數(shù)據(jù).
• 那么應(yīng)用程序看到了這么一連串的字節(jié)數(shù)據(jù), 就不知道從哪個部分開始到哪個部分, 是一個完整的應(yīng)用層數(shù)據(jù)包.

那么如何避免粘包問題呢? 歸根結(jié)底就是一句話, 明確兩個包之間的邊界.

• 對于定長的包, 保證每次都按固定大小讀取即可; 例如上面的Request結(jié)構(gòu), 是固定大小的, 那么就從緩沖區(qū)從頭開始按sizeof(Request)依次讀取即可;
• 對于變長的包, 可以在包頭的位置, 約定一個包總長度的字段, 從而就知道了包的結(jié)束位置;
• 對于變長的包, 還可以在包和包之間使用明確的分隔符(應(yīng)用層協(xié)議, 是程序猿自己來定的, 只要保證分隔符不和正文沖突即可);

思考: 對于UDP協(xié)議來說, 是否也存在 “粘包問題” 呢?

• 對于UDP, 如果還沒有上層交付數(shù)據(jù), UDP的報文長度仍然在. 同時, UDP是一個一個把數(shù)據(jù)交付給應(yīng)用層. 就有很明確的數(shù)據(jù)邊界.
• 站在應(yīng)用層的站在應(yīng)用層的角度, 使用UDP的時候, 要么收到完整的UDP報文, 要么不收. 不會出現(xiàn)"半個"的情況

12. TCP異常情況

• 進(jìn)程終止: 進(jìn)程終止會釋放文件描述符, 仍然可以發(fā)送FIN. 和正常關(guān)閉沒有什么區(qū)別.
• 機(jī)器重啟: 和進(jìn)程終止的情況相同.
• 機(jī)器掉電/網(wǎng)線斷開: 接收端認(rèn)為連接還在, 一旦接收端有寫入操作, 接收端發(fā)現(xiàn)連接已經(jīng)不在了, 就會進(jìn)行reset. 即使沒有寫入操作, TCP自己也內(nèi)置了一個?；疃〞r器, 會定期詢問對方是否還在. 如果對方不在, 也會把連接釋放.

另外, 應(yīng)用層的某些協(xié)議, 也有一些這樣的檢測機(jī)制. 例如HTTP長連接中, 也會定期檢測對方的狀態(tài). 例如QQ, 在QQ斷線之后, 也會定期嘗試重新連接。

13. 基于TCP應(yīng)用層協(xié)議

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP

也包括自己寫TCP程序時自定義的應(yīng)用層協(xié)議。

14. TCP小結(jié)

為什么TCP這么復(fù)雜? 因?yàn)橐ＷC可靠性, 同時又盡可能的提高性能.

可靠性:

1. 校驗(yàn)和
2. 序列號(按序到達(dá))
3. 確認(rèn)應(yīng)答
4. 超時重發(fā)
5. 連接管理
6. 流量控制
7. 擁塞控制

提高性能:

1. 滑動窗口
2. 快速重傳
3. 延遲應(yīng)答
4. 捎帶應(yīng)答

其他:

1. 定時器(超時重傳定時器, ?；疃〞r器, TIME_WAIT定時器等。