1. TCP簡(jiǎn)介

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

1.1 TCP報(bào)頭

1、源/目的端口號(hào): 表示數(shù)據(jù)是從哪個(gè)進(jìn)程來(lái), 到哪個(gè)進(jìn)程去

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

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

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

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

對(duì)于TCP報(bào)頭主要講解幾個(gè)重要部分：

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

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

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

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

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

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

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

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

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

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

情況一：丟包

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

情況二：ACK丟失

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

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

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

這里主要講面試高頻問(wèn)題：

三次握手：

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

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

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

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

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

握手失敗的原因有兩種：

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

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

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

四次揮手：

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

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

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

CLOSE_WAIT狀態(tài)詳談：

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

TIME_WAIT狀態(tài)詳談：

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

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

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

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

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

5. 滑動(dòng)窗口

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

分兩種情況討論:

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

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

6. 流量控制

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

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

7. 擁塞控制

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

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

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

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

8. 延遲應(yīng)答

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

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

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

等待的時(shí)間

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

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

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

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

9. 捎帶應(yīng)答

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

10. 面向字節(jié)流

11.粘包問(wèn)題

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

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

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

思考: 對(duì)于UDP協(xié)議來(lái)說(shuō), 是否也存在 “粘包問(wèn)題” 呢?

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

12. TCP異常情況

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

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

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

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

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

14. TCP小結(jié)

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

可靠性:

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

提高性能:

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

其他:

1. 定時(shí)器(超時(shí)重傳定時(shí)器, 保活定時(shí)器, TIME_WAIT定時(shí)器等。