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

如下圖connect和accept的關系：

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

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

connect返回了可以認為連接成功了嗎？

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

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

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

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

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

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

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

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

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

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

這就是等待 2MSL 的意義。

SYN Flood 攻擊

SYN Flood 攻擊原理

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

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

如何應對 SYN Flood 攻擊？

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

TCP Fast Open

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

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

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

TFO 的優(yōu)勢

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

序列號回繞怎么辦？

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

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

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

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

附：

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

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

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

能不能說說 Nagle 算法和延遲確認？

Nagle 算法

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

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

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

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

延遲確認

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

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

不過需要主要的是，有一些場景是不能延遲確認的，收到了就要馬上回復:

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

兩者一起使用會怎樣？

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

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

TCP keepalive

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

HTTP keep-alive

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

TCP隊頭阻塞和HTTP隊頭阻塞

1. TCP隊頭阻塞

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

2. HTTP隊頭阻塞

http隊頭阻塞和TCP隊頭阻塞完全不是一回事。

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

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

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

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

管道化請求的致命弱點:

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

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

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

解決http隊頭阻塞的方法：

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

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

UDP

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

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

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

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

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

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

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

3、添加超時重傳機制。

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