TCP

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

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

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

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

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

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

第三次握手的時(shí)候，可以攜帶。前兩次握手不能攜帶數(shù)據(jù)。如果前兩次握手能夠攜帶數(shù)據(jù)，那么一旦有人想攻擊服務(wù)器，那么他只需要在第一次握手中的 SYN 報(bào)文中放大量數(shù)據(jù)，那么服務(wù)器勢必會(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í)候相對安全了，可以攜帶數(shù)據(jù)。

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

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

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

• 1 個(gè) MSL 確保對端沒有收到 ACK 重傳的 FIN 報(bào)文可以到達(dá)

這就是等待 2MSL 的意義。

SYN Flood 攻擊

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

• 處理大量的SYN包并返回對應(yīng)ACK, 勢必有大量連接處于SYN_RCVD狀態(tài)，從而占滿整個(gè)半連接隊(duì)列，無法處理正常的請求。

• 由于是不存在的 IP，服務(wù)端長時(shí)間收不到客戶端的ACK，會(huì)導(dǎo)致服務(wù)端不斷重發(fā)數(shù)據(jù)，直到耗盡服務(wù)端的資源。

（2）如何應(yīng)對 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 合法之后才分配連接資源。

（3）TCP Fast Open

注意: 客戶端最后握手的 ACK 不一定要等到服務(wù)端的 HTTP 響應(yīng)到達(dá)才發(fā)送，兩個(gè)過程沒有任何關(guān)系。第一次握手時(shí)server會(huì)計(jì)算出cookie傳給客戶端并緩存，之后的握手客戶端會(huì)攜帶cookie進(jìn)行SYN。如果cookie不合法直接丟棄，如果合法，就可以直接發(fā)送http響應(yīng)。（4）TFO 的優(yōu)勢TFO 的優(yōu)勢并不在與首輪三次握手，而在于后面的握手，在拿到客戶端的 Cookie 并驗(yàn)證通過以后，可以直接返回 HTTP 響應(yīng)，充分利用了1 個(gè)RTT(Round-Trip Time，往返時(shí)延)的時(shí)間提前進(jìn)行數(shù)據(jù)傳輸，積累起來還是一個(gè)比較大的優(yōu)勢。

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

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

假設(shè)在第 6 次的時(shí)候，之前還滯留在網(wǎng)路中的包回來了，那么就有兩個(gè)序列號(hào)為1 ~ 2的數(shù)據(jù)包了，怎么區(qū)分誰是誰呢？這個(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é)。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ? ?

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

（1）Nagle 算法試想一個(gè)場景，發(fā)送端不停地給接收端發(fā)很小的包，一次只發(fā) 1 個(gè)字節(jié)，那么發(fā) 1 千個(gè)字節(jié)需要發(fā) 1000 次。這種頻繁的發(fā)送是存在問題的，不光是傳輸?shù)臅r(shí)延消耗，發(fā)送和確認(rèn)本身也是需要耗時(shí)的，頻繁的發(fā)送接收帶來了巨大的時(shí)延。而避免小包的頻繁發(fā)送，這就是 Nagle 算法要做的事情。具體來說，Nagle 算法的規(guī)則如下：

• 當(dāng)?shù)谝淮伟l(fā)送數(shù)據(jù)時(shí)不用等待，就算是 1byte 的小包也立即發(fā)送。

• 后面發(fā)送滿足下面條件之一就可以發(fā)了:數(shù)據(jù)包大小達(dá)到最大段大小(Max Segment Size, 即 MSS)之前所有包的 ACK 都已接收到

（2）延遲確認(rèn)試想這樣一個(gè)場景，當(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ì)超過200ms。不過需要主要的是，有一些場景是不能延遲確認(rèn)的，收到了就要馬上回復(fù):

• 接收到了大于一個(gè) frame 的報(bào)文，且需要調(diào)整窗口大小

• TCP 處于 quickack 模式（通過tcp_in_quickack_mode設(shè)置）

• 發(fā)現(xiàn)了亂序包

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

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

TCP keepalive

• 在雙方長時(shí)間未通訊時(shí)，如何得知對方還活著？如何得知這個(gè)TCP連接是健康且具有通訊能力的？

• TCP的?；顧C(jī)制就是用來解決此類問題的

• 保活機(jī)制默認(rèn)是關(guān)閉的，TCP連接的任何一方都可打開此功能。

• 若對端正常存活，且連接有效，對端必然能收到探測報(bào)文并進(jìn)行響應(yīng)。此時(shí)，發(fā)送端收到響應(yīng)報(bào)文則證明TCP連接正常，重置保活時(shí)間計(jì)數(shù)器即可。

• 若由于網(wǎng)絡(luò)原因或其他原因?qū)е拢l(fā)送端無法正常收到?；钐綔y報(bào)文的響應(yīng)。那么在一定探測時(shí)間間隔（tcp_keepalive_intvl）后，將繼續(xù)發(fā)送保活探測報(bào)文。直到收到對端的響應(yīng)，或者達(dá)到配置的探測循環(huán)次數(shù)上限（tcp_keepalive_probes）都沒有收到對端響應(yīng)，這時(shí)對端會(huì)被認(rèn)為不可達(dá)，TCP連接隨存在但已失效，需要將連接做中斷處理。

HTTP keep-alive

• keep-alive機(jī)制：若開啟后，在一次http請求中，服務(wù)器進(jìn)行響應(yīng)后，不再直接斷開TCP連接，而是將TCP連接維持一段時(shí)間。在這段時(shí)間內(nèi)，如果同一客戶端再次向服務(wù)端發(fā)起http請求，便可以復(fù)用此TCP連接，向服務(wù)端發(fā)起請求，并重置timeout時(shí)間計(jì)數(shù)器，在接下來一段時(shí)間內(nèi)還可以繼續(xù)復(fù)用。這樣無疑省略了反復(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采用長連接(Connection:keep-alive)，可以在一個(gè)TCP請求上，發(fā)送多個(gè)http請求。有非管道化和管道化，兩種方式。非管道化，完全串行執(zhí)行，請求->響應(yīng)->請求->響應(yīng)…，后一個(gè)請求必須在前一個(gè)響應(yīng)之后發(fā)送。管道化，請求可以并行發(fā)出，但是響應(yīng)必須串行返回。后一個(gè)響應(yīng)必須在前一個(gè)響應(yīng)之后。原因是，沒有序號(hào)標(biāo)明順序，只能串行接收。管道化請求的致命弱點(diǎn):

• 會(huì)造成隊(duì)頭阻塞，前一個(gè)響應(yīng)未及時(shí)返回，后面的響應(yīng)被阻塞

• 請求必須是冪等請求，不能修改資源。因?yàn)椋馔庵袛鄷r(shí)候，客戶端需要把未收到響應(yīng)的請求重發(fā)，非冪等請求，會(huì)造成資源破壞。

由于這個(gè)原因，目前大部分瀏覽器和Web服務(wù)器，都關(guān)閉了管道化，采用非管道化模式。無論是非管道化還是管道化，都會(huì)造成隊(duì)頭阻塞(請求阻塞)。解決http隊(duì)頭阻塞的方法：1. 并發(fā)TCP連接（瀏覽器一個(gè)域名采用6-8個(gè)TCP連接，并發(fā)HTTP請求）2. 域名分片（多個(gè)域名，可以建立更多的TCP連接，從而提高HTTP請求的并發(fā)）3. HTTP2方式http2使用一個(gè)域名單一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è)計(jì)。

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

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

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

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

原文作者：一起學(xué)嵌入式