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)的后果:
- 處理大量的SYN包并返回對(duì)應(yīng)ACK, 勢(shì)必有大量連接處于SYN_RCVD狀態(tài),從而占滿整個(gè)半連接隊(duì)列,無(wú)法處理正常的請(qǐng)求。
- 由于是不存在的 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ì)頭阻塞
- TCP隊(duì)頭阻塞
TCP數(shù)據(jù)包是有序傳輸,中間一個(gè)數(shù)據(jù)包丟失,會(huì)等待該數(shù)據(jù)包重傳,造成后面的數(shù)據(jù)包的阻塞。(停止等待)
- 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):
- 會(huì)造成隊(duì)頭阻塞,前一個(gè)響應(yīng)未及時(shí)返回,后面的響應(yīng)被阻塞
- 請(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ì)頭阻塞的方法:
- 并發(fā)TCP連接(瀏覽器一個(gè)域名采用6-8個(gè)TCP連接,并發(fā)HTTP請(qǐng)求)
- 域名分片(多個(gè)域名,可以建立更多的TCP連接,從而提高HTTP請(qǐng)求的并發(fā))
- 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ù)。
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
8873瀏覽量
84979 -
ACK
+關(guān)注
關(guān)注
0文章
28瀏覽量
11121 -
UDP
+關(guān)注
關(guān)注
0文章
318瀏覽量
33839 -
函數(shù)
+關(guān)注
關(guān)注
3文章
4263瀏覽量
62249
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論