TCP的accept發(fā)生在三次握手的哪個(gè)階段？

如下圖connect和accept的關(guān)系：

accept過(guò)程發(fā)生在三次握手之后，三次握手完成后，客戶端和服務(wù)器就建立了tcp連接并可以進(jìn)行數(shù)據(jù)交互了。

這時(shí)可以調(diào)用accept函數(shù)獲得此連接。

connect返回了可以認(rèn)為連接成功了嗎？

connect返回成功后，三次握手就已經(jīng)完成了。

已完成的鏈接會(huì)被放入一個(gè)隊(duì)列中，accept的作用就是從已連接隊(duì)列中取出優(yōu)先級(jí)最高的一個(gè)鏈接，并將它綁定給一個(gè)新的fd，服務(wù)端就可以通過(guò)這個(gè)新的fd來(lái)recv和send數(shù)據(jù)了。

三次握手過(guò)程中可以攜帶數(shù)據(jù)么？

第三次握手的時(shí)候，可以攜帶。前兩次握手不能攜帶數(shù)據(jù)。

如果前兩次握手能夠攜帶數(shù)據(jù)，那么一旦有人想攻擊服務(wù)器，那么他只需要在第一次握手中的 SYN 報(bào)文中放大量數(shù)據(jù)，那么服務(wù)器勢(shì)必會(huì)消耗更多的時(shí)間和內(nèi)存空間去處理這些數(shù)據(jù)，增大了服務(wù)器被攻擊的風(fēng)險(xiǎn)。

第三次握手的時(shí)候，客戶端已經(jīng)處于ESTABLISHED狀態(tài)，并且已經(jīng)能夠確認(rèn)服務(wù)器的接收、發(fā)送能力正常，這個(gè)時(shí)候相對(duì)安全了，可以攜帶數(shù)據(jù)。

等待2MSL的意義，如果不等待會(huì)怎樣？

如果不等待，客戶端直接跑路，當(dāng)服務(wù)端還有很多數(shù)據(jù)包要給客戶端發(fā)，且還在路上的時(shí)候，若客戶端的端口此時(shí)剛好被新的應(yīng)用占用，那么就接收到了無(wú)用數(shù)據(jù)包，造成數(shù)據(jù)包混亂。所以，最保險(xiǎn)的做法是等服務(wù)器發(fā)來(lái)的數(shù)據(jù)包都死翹翹再啟動(dòng)新的應(yīng)用。

那，照這樣說(shuō)一個(gè) MSL 不就不夠了嗎，為什么要等待 2 MSL?

• 1 個(gè) MSL 確保四次揮手中主動(dòng)關(guān)閉方最后的 ACK 報(bào)文最終能達(dá)到對(duì)端
• 1 個(gè) MSL 確保對(duì)端沒有收到 ACK 重傳的 FIN 報(bào)文可以到達(dá)

這就是等待 2MSL 的意義。

SYN Flood 攻擊

SYN Flood 攻擊原理

SYN Flood 屬于典型的 DoS/DDoS 攻擊。其攻擊的原理很簡(jiǎn)單，就是用客戶端在短時(shí)間內(nèi)偽造大量不存在的 IP 地址，并向服務(wù)端瘋狂發(fā)送SYN。對(duì)于服務(wù)端而言，會(huì)產(chǎn)生兩個(gè)危險(xiǎn)的后果:

1. 處理大量的SYN包并返回對(duì)應(yīng)ACK, 勢(shì)必有大量連接處于SYN_RCVD狀態(tài)，從而占滿整個(gè)半連接隊(duì)列，無(wú)法處理正常的請(qǐng)求。
2. 由于是不存在的 IP，服務(wù)端長(zhǎng)時(shí)間收不到客戶端的ACK，會(huì)導(dǎo)致服務(wù)端不斷重發(fā)數(shù)據(jù)，直到耗盡服務(wù)端的資源。

如何應(yīng)對(duì) SYN Flood 攻擊？

• 增加 SYN 連接，也就是增加半連接隊(duì)列的容量。
• 減少 SYN + ACK 重試次數(shù)，避免大量的超時(shí)重發(fā)。
• 利用 SYN Cookie 技術(shù)，在服務(wù)端接收到SYN后不立即分配連接資源，而是根據(jù)這個(gè)SYN計(jì)算出一個(gè)Cookie，連同第二次握手回復(fù)給客戶端，在客戶端回復(fù)ACK的時(shí)候帶上這個(gè)Cookie值，服務(wù)端驗(yàn)證 Cookie 合法之后才分配連接資源。

TCP Fast Open

注意: 客戶端最后握手的 ACK 不一定要等到服務(wù)端的 HTTP 響應(yīng)到達(dá)才發(fā)送，兩個(gè)過(guò)程沒有任何關(guān)系。

第一次握手時(shí)server會(huì)計(jì)算出cookie傳給客戶端并緩存，之后的握手客戶端會(huì)攜帶cookie進(jìn)行SYN。

如果cookie不合法直接丟棄，如果合法，就可以直接發(fā)送http響應(yīng)。

TFO 的優(yōu)勢(shì)

TFO 的優(yōu)勢(shì)并不在與首輪三次握手，而在于后面的握手，在拿到客戶端的 Cookie 并驗(yàn)證通過(guò)以后，可以直接返回 HTTP 響應(yīng)，充分利用了1 個(gè)RTT(Round-Trip Time，往返時(shí)延)的時(shí)間提前進(jìn)行數(shù)據(jù)傳輸，積累起來(lái)還是一個(gè)比較大的優(yōu)勢(shì)。

序列號(hào)回繞怎么辦？

現(xiàn)在我們來(lái)模擬一下這個(gè)問題。

序列號(hào)的范圍其實(shí)是在0 ~ 2 ^ 32 - 1, 為了方便演示，我們縮小一下這個(gè)區(qū)間，假設(shè)范圍是 0 ~ 4，那么到達(dá) 4 的時(shí)候會(huì)回到 0。

假設(shè)在第 6 次的時(shí)候，之前還滯留在網(wǎng)路中的包回來(lái)了，那么就有兩個(gè)序列號(hào)為1 ~ 2的數(shù)據(jù)包了，怎么區(qū)分誰(shuí)是誰(shuí)呢？這個(gè)時(shí)候就產(chǎn)生了序列號(hào)回繞的問題。

那么用 timestamp 就能很好地解決這個(gè)問題，因?yàn)槊看伟l(fā)包的時(shí)候都是將發(fā)包機(jī)器當(dāng)時(shí)的內(nèi)核時(shí)間記錄在報(bào)文中，那么兩次發(fā)包序列號(hào)即使相同，時(shí)間戳也不可能相同，這樣就能夠區(qū)分開兩個(gè)數(shù)據(jù)包了。

附：

timestamp是 TCP 報(bào)文首部的一個(gè)可選項(xiàng)，一共占 10 個(gè)字節(jié)，格式如下:

kind(1 字節(jié)) + length(1 字節(jié)) + info(8 個(gè)字節(jié))

其中 kind = 8， length = 10， info 有兩部分構(gòu)成: timestamp和timestamp echo，各占 4 個(gè)字節(jié)。

能不能說(shuō)說(shuō) Nagle 算法和延遲確認(rèn)？

Nagle 算法

試想一個(gè)場(chǎng)景，發(fā)送端不停地給接收端發(fā)很小的包，一次只發(fā) 1 個(gè)字節(jié)，那么發(fā) 1 千個(gè)字節(jié)需要發(fā) 1000 次。這種頻繁的發(fā)送是存在問題的，不光是傳輸?shù)臅r(shí)延消耗，發(fā)送和確認(rèn)本身也是需要耗時(shí)的，頻繁的發(fā)送接收帶來(lái)了巨大的時(shí)延。

而避免小包的頻繁發(fā)送，這就是 Nagle 算法要做的事情。

具體來(lái)說(shuō)，Nagle 算法的規(guī)則如下:

• 當(dāng)?shù)谝淮伟l(fā)送數(shù)據(jù)時(shí)不用等待，就算是 1byte 的小包也立即發(fā)送
• 后面發(fā)送滿足下面條件之一就可以發(fā)了:
• 數(shù)據(jù)包大小達(dá)到最大段大小(Max Segment Size, 即 MSS)
• 之前所有包的 ACK 都已接收到

延遲確認(rèn)

試想這樣一個(gè)場(chǎng)景，當(dāng)我收到了發(fā)送端的一個(gè)包，然后在極短的時(shí)間內(nèi)又接收到了第二個(gè)包，那我是一個(gè)個(gè)地回復(fù)，還是稍微等一下，把兩個(gè)包的 ACK 合并后一起回復(fù)呢？

延遲確認(rèn)(delayed ack)所做的事情，就是后者，稍稍延遲，然后合并 ACK，最后才回復(fù)給發(fā)送端。TCP 要求這個(gè)延遲的時(shí)延必須小于500ms，一般操作系統(tǒng)實(shí)現(xiàn)都不會(huì)超過(guò)200ms。

不過(guò)需要主要的是，有一些場(chǎng)景是不能延遲確認(rèn)的，收到了就要馬上回復(fù):

• 接收到了大于一個(gè) frame 的報(bào)文，且需要調(diào)整窗口大小
• TCP 處于 quickack 模式（通過(guò)tcp_in_quickack_mode設(shè)置）
• 發(fā)現(xiàn)了亂序包

兩者一起使用會(huì)怎樣？

前者意味著延遲發(fā)，后者意味著延遲接收，會(huì)造成更大的延遲，產(chǎn)生性能問題。

TCP的Keep Alive和HTTP的Keep Alive的區(qū)別

TCP keepalive

• 在雙方長(zhǎng)時(shí)間未通訊時(shí)，如何得知對(duì)方還活著？如何得知這個(gè)TCP連接是健康且具有通訊能力的？
• TCP的?；顧C(jī)制就是用來(lái)解決此類問題的
• 保活機(jī)制默認(rèn)是關(guān)閉的，TCP連接的任何一方都可打開此功能。
• 若對(duì)端正常存活，且連接有效，對(duì)端必然能收到探測(cè)報(bào)文并進(jìn)行響應(yīng)。此時(shí)，發(fā)送端收到響應(yīng)報(bào)文則證明TCP連接正常，重置保活時(shí)間計(jì)數(shù)器即可。
• 若由于網(wǎng)絡(luò)原因或其他原因?qū)е拢l(fā)送端無(wú)法正常收到?；钐綔y(cè)報(bào)文的響應(yīng)。那么在一定探測(cè)時(shí)間間隔（tcp_keepalive_intvl）后，將繼續(xù)發(fā)送保活探測(cè)報(bào)文。直到收到對(duì)端的響應(yīng)，或者達(dá)到配置的探測(cè)循環(huán)次數(shù)上限（tcp_keepalive_probes）都沒有收到對(duì)端響應(yīng)，這時(shí)對(duì)端會(huì)被認(rèn)為不可達(dá)，TCP連接隨存在但已失效，需要將連接做中斷處理。

HTTP keep-alive

• keep-alive機(jī)制：若開啟后，在一次http請(qǐng)求中，服務(wù)器進(jìn)行響應(yīng)后，不再直接斷開TCP連接，而是將TCP連接維持一段時(shí)間。在這段時(shí)間內(nèi)，如果同一客戶端再次向服務(wù)端發(fā)起http請(qǐng)求，便可以復(fù)用此TCP連接，向服務(wù)端發(fā)起請(qǐng)求，并重置timeout時(shí)間計(jì)數(shù)器，在接下來(lái)一段時(shí)間內(nèi)還可以繼續(xù)復(fù)用。這樣無(wú)疑省略了反復(fù)創(chuàng)建和銷毀TCP連接的損耗。

TCP隊(duì)頭阻塞和HTTP隊(duì)頭阻塞

1. TCP隊(duì)頭阻塞

TCP數(shù)據(jù)包是有序傳輸，中間一個(gè)數(shù)據(jù)包丟失，會(huì)等待該數(shù)據(jù)包重傳，造成后面的數(shù)據(jù)包的阻塞。（停止等待）

2. HTTP隊(duì)頭阻塞

http隊(duì)頭阻塞和TCP隊(duì)頭阻塞完全不是一回事。

http1.x采用長(zhǎng)連接(Connection:keep-alive)，可以在一個(gè)TCP請(qǐng)求上，發(fā)送多個(gè)http請(qǐng)求。

有非管道化和管道化，兩種方式。

非管道化，完全串行執(zhí)行，請(qǐng)求->響應(yīng)->請(qǐng)求->響應(yīng)…，后一個(gè)請(qǐng)求必須在前一個(gè)響應(yīng)之后發(fā)送。

管道化，請(qǐng)求可以并行發(fā)出，但是響應(yīng)必須串行返回。后一個(gè)響應(yīng)必須在前一個(gè)響應(yīng)之后。原因是，沒有序號(hào)標(biāo)明順序，只能串行接收。

管道化請(qǐng)求的致命弱點(diǎn):

1. 會(huì)造成隊(duì)頭阻塞，前一個(gè)響應(yīng)未及時(shí)返回，后面的響應(yīng)被阻塞
2. 請(qǐng)求必須是冪等請(qǐng)求，不能修改資源。因?yàn)?，意外中斷時(shí)候，客戶端需要把未收到響應(yīng)的請(qǐng)求重發(fā)，非冪等請(qǐng)求，會(huì)造成資源破壞。

由于這個(gè)原因，目前大部分瀏覽器和Web服務(wù)器，都關(guān)閉了管道化，采用非管道化模式。

無(wú)論是非管道化還是管道化，都會(huì)造成隊(duì)頭阻塞(請(qǐng)求阻塞)。

解決http隊(duì)頭阻塞的方法：

1. 并發(fā)TCP連接（瀏覽器一個(gè)域名采用6-8個(gè)TCP連接，并發(fā)HTTP請(qǐng)求）
2. 域名分片（多個(gè)域名，可以建立更多的TCP連接，從而提高HTTP請(qǐng)求的并發(fā)）
3. HTTP2方式

http2使用一個(gè)域名單一TCP連接發(fā)送請(qǐng)求，請(qǐng)求包被二進(jìn)制分幀**（多路復(fù)用）**不同請(qǐng)求可以互相穿插，避免了http層面的請(qǐng)求隊(duì)頭阻塞。但是不能避免TCP層面的隊(duì)頭阻塞。

UDP

UDP如何實(shí)現(xiàn)可靠傳輸？

傳輸層無(wú)法保證數(shù)據(jù)的可靠傳輸，只能通過(guò)應(yīng)用層來(lái)實(shí)現(xiàn)了。

實(shí)現(xiàn)的方式可以參照tcp可靠性傳輸?shù)姆绞剑皇菍?shí)現(xiàn)不在傳輸層，實(shí)現(xiàn)轉(zhuǎn)移到了應(yīng)用層。

最簡(jiǎn)單的方式是在應(yīng)用層模仿傳輸層TCP的可靠性傳輸。

下面不考慮擁塞處理，可靠UDP的簡(jiǎn)單設(shè)計(jì)。

1、添加seq/ack機(jī)制，確保數(shù)據(jù)發(fā)送到對(duì)端

2、添加發(fā)送和接收緩沖區(qū)，主要是用戶超時(shí)重傳。

3、添加超時(shí)重傳機(jī)制。

詳細(xì)說(shuō)明：送端發(fā)送數(shù)據(jù)時(shí)，生成一個(gè)隨機(jī)seq=x，然后每一片按照數(shù)據(jù)大小分配seq。數(shù)據(jù)到達(dá)接收端后接收端放入緩存，并發(fā)送一個(gè)ack=x的包，表示對(duì)方已經(jīng)收到了數(shù)據(jù)。發(fā)送端收到了ack包后，刪除緩沖區(qū)對(duì)應(yīng)的數(shù)據(jù)。時(shí)間到后，定時(shí)任務(wù)檢查是否需要重傳數(shù)據(jù)。