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

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

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

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

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

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

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

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

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

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

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

等待2MSL的意義，如果不等待會怎樣？

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

那，照這樣說一個 MSL 不就不夠了嗎，為什么要等待 2 MSL?

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

這就是等待 2MSL 的意義。

SYN Flood 攻擊

SYN Flood 攻擊原理

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

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

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

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

TCP Fast Open

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

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

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

TFO 的優(yōu)勢

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

序列號回繞怎么辦？

現(xiàn)在我們來模擬一下這個問題。

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

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

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

附：

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

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

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

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

Nagle 算法

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

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

具體來說，Nagle 算法的規(guī)則如下:

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

延遲確認(rèn)

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

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

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

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

兩者一起使用會怎樣？

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

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

TCP keepalive

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

HTTP keep-alive

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

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

1. TCP隊(duì)頭阻塞

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

2. HTTP隊(duì)頭阻塞

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

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

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

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

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

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

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

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

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

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

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

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

UDP

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

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

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

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

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

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

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

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

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