當(dāng)前位置:首頁 > 公眾號(hào)精選 > 嵌入式微處理器
[導(dǎo)讀]大家好,我是軒轅。前幾天,我在讀者群里提了一個(gè)問題:這一下,大家總算停止了灌水(這群人都不用上班的,天天劃水摸魚),開始討論起這個(gè)問題來了。有人說,通過User-Agent可以看,我直接給了一個(gè)狗頭。然后發(fā)現(xiàn)不對(duì)勁,改口說,可以通過HTTP響應(yīng)的Server字段看,比如看到像這種...

大家好,我是軒轅。前幾天,我在讀者群里提了一個(gè)問題:

這一下,大家總算停止了灌水(這群人都不用上班的,天天劃水摸魚),開始討論起這個(gè)問題來了。

有人說,通過User-Agent可以看,我直接給了一個(gè)狗頭。

然后發(fā)現(xiàn)不對(duì)勁,改口說,可以通過HTTP響應(yīng)的Server字段看,比如看到像這種的,那肯定Windows無疑了:

HTTP/1.1?200?OK
Content-Type:?text/html
Last-Modified:?Fri,?23?Aug?2019?01:02:08?GMT
Accept-Ranges:?bytes
ETag:?"e65855634e59d51:0"
Server:?Microsoft-IIS/8.0
X-Powered-By:?ASP.NET
Date:?Fri,?23?Jul?2021?06:02:38?GMT
Content-Length:?1375
還有人說,可以通過URL路徑來判斷,如果大小寫敏感就是Linux,不敏感就是Windows。

于是,我進(jìn)一步提高了難度,如果連Web服務(wù)也沒有,只有一個(gè)TCP Server呢?

這時(shí)又有人說,可以通過ping這個(gè)IP,查看ICMP報(bào)文中的TTL值,如果是xxx就是xx系統(tǒng),如果是yyy就是yy系統(tǒng)···(不過,有些情況下也不是太準(zhǔn)確)

從TCP重傳說起

今天,想跟大家探討的是另外一種方法。這個(gè)方法的思路來源于前幾天被刪掉的那篇文章。就是日本網(wǎng)絡(luò)環(huán)境下訪問不了極客時(shí)間的問題,當(dāng)時(shí)抓包看到的情況是這樣的:

看到了服務(wù)器后面在不斷的嘗試重發(fā)了嗎?當(dāng)時(shí)我就想到了一個(gè)問題:

服務(wù)器到底會(huì)重傳好多次呢?

眾所周知,TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

其中,可靠性的一個(gè)重要體現(xiàn)就是它的超時(shí)重傳機(jī)制。

TCP的通信中有一個(gè)確認(rèn)機(jī)制,我發(fā)給你了數(shù)據(jù),你得告訴我你收到?jīng)],這樣雙方才能繼續(xù)通信下去,而這個(gè)確認(rèn)機(jī)制是通過序列號(hào)SEQ和確認(rèn)號(hào)ACK來實(shí)現(xiàn)的。

簡單來說,當(dāng)發(fā)送方給接收方發(fā)送了一個(gè)報(bào)文,而接收方在規(guī)定的時(shí)間內(nèi)沒有給出應(yīng)答,那么發(fā)送方將認(rèn)為有必要重發(fā)。

那具體最多重發(fā)多少次呢?關(guān)于這一點(diǎn),RFC中關(guān)于TCP的文檔并未明確規(guī)定出來,只是給了一些在總超時(shí)時(shí)間上的參考,這就導(dǎo)致不同的操作系統(tǒng)在實(shí)現(xiàn)這一機(jī)制的時(shí)候可能會(huì)有一些差異。

于是,我進(jìn)一步想到了另一個(gè)問題:

會(huì)不會(huì)不同操作系統(tǒng)重傳次數(shù)不一樣,這樣就能通過這一點(diǎn)來判斷操作系統(tǒng)了呢?

然后,我翻看了《TCP/IP詳解·卷1》,試圖在里面尋找答案。果然,這本神書從來沒有讓我失望過:

上面這段大意是說RFC標(biāo)準(zhǔn)中建議有兩個(gè)參數(shù)R1和R2來控制重傳的次數(shù),Linux中,這倆參數(shù)可以這樣看:

cat?/proc/sys/net/ipv4/tcp_retries1
cat?/proc/sys/net/ipv4/tcp_retries2
tcp_retries1默認(rèn)值是3,tcp_retries2默認(rèn)值是15。

但需要特別注意的是,并不是最多重傳3次或者15次,Linux內(nèi)部有一套算法,這兩個(gè)值是算法中非常重要的參數(shù),而不是重傳次數(shù)本身。具體的重傳次數(shù)還與RTO有關(guān)系,具體的算法,有興趣的朋友可以看看這篇文章:聊一聊重傳次數(shù)(http://perthcharles.github.io/2015/09/07/wiki-tcp-retries/)

總體來說,在Linux上重傳的次數(shù)不是一個(gè)固定值,而是不同的連接根據(jù)tcp_retries2RTO計(jì)算出來的一個(gè)動(dòng)態(tài)值,不固定。

而在Windows上,也有一個(gè)變量來控制重傳次數(shù),可以在注冊(cè)表中設(shè)定它:

鍵值路徑:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

鍵值名:
TcpMaxDataRetransmissions

默認(rèn)值:5
我手里有一份Windows XP的源碼,在實(shí)現(xiàn)協(xié)議棧的驅(qū)動(dòng)tcpip.sys的部分中,也印證了這個(gè)信息:

從注冊(cè)表中讀取鍵值
沒有讀到的默認(rèn)值
不過,就目前的信息來看,由于Linux的重傳次數(shù)是不固定的,還沒法用這個(gè)重傳次數(shù)來判斷操作系統(tǒng)。

TCP之SYN ACK的重傳

就在我想要放棄的時(shí)候,我再一次品讀了《TCP/IP詳解·卷1》中的那段話,發(fā)現(xiàn)另一個(gè)信息:TCP的重傳在建立連接階段和數(shù)據(jù)傳輸階段是不一樣的!

上面說到的重傳次數(shù)限制,針對(duì)的是TCP連接已經(jīng)建立完成,在數(shù)據(jù)傳輸過程中發(fā)生超時(shí)重傳后的重傳次數(shù)情況描述。

而在TCP建立連接的過程中,也就是三次握手的過程中,發(fā)生超時(shí)重傳,它的次數(shù)限定是有另外一套約定的。

Linux:

在Linux中,另外還有兩個(gè)參數(shù)來限定建立連接階段的重傳次數(shù):

cat?/proc/sys/net/ipv4/tcp_syn_retries
cat?/proc/sys/net/ipv4/tcp_synack_retries
tcp_syn_retries限定作為客戶端的時(shí)候發(fā)起TCP連接,最多重傳SYN的次數(shù),Linux3.10中默認(rèn)是6,Linux2.6中是5。

tcp_synack_retries限定作為服務(wù)端的時(shí)候收到SYN后,最多重傳SYN ACK的次數(shù),默認(rèn)是5。

重點(diǎn)來關(guān)注這個(gè)tcp_synack_retries,它指的就是TCP的三次握手中,服務(wù)端回復(fù)了第二次握手包,但客戶端一直沒發(fā)來第三次握手包時(shí),服務(wù)端會(huì)重發(fā)的次數(shù)。

我們知道,在正常情況下,TCP的三次握手是這個(gè)樣子的:

但是,如果客戶端不給服務(wù)端發(fā)起第三個(gè)包,那么服務(wù)端就會(huì)重發(fā)它的第二次握手包,情況就會(huì)變成下面這樣:

所以,這個(gè)tcp_synack_retries實(shí)際上規(guī)定的就是上面這種情況下,服務(wù)端會(huì)重傳SYN ACK的次數(shù)。

為了進(jìn)一步驗(yàn)證,我使用Python寫了一段代碼,用來手動(dòng)發(fā)送TCP報(bào)文,里面使用的發(fā)包庫是scapy。

下面的這段代碼,我向目標(biāo)IP的指定端口只發(fā)送了一個(gè)SYN包:

def?tcp_syn_test(ip,?port):

????#?第一次握手,發(fā)送SYN包
????#?請(qǐng)求端口和初始序列號(hào)隨機(jī)生成
????#?使用sr1發(fā)送而不用send發(fā)送,因?yàn)閟r1會(huì)接收返回的內(nèi)容
????ans?=?sr1(IP(dst=ip)?/?TCP(dport=port,?sport=RandShort(),?seq=RandInt(),?flags='S'),?verbose=False)
用上面這段代碼,向一臺(tái)Linux的服務(wù)器發(fā)送,抓包來看一下:

實(shí)際驗(yàn)證,服務(wù)器確實(shí)重傳了5次SYN ACK報(bào)文。

一臺(tái)服務(wù)器說明不了問題,我又多找了幾個(gè),結(jié)果都是5次。

再來看一下Linux的源碼中關(guān)于這個(gè)次數(shù)的定義:

接下來,看一下Windows上的情況。

Windows

前面說過,在注冊(cè)表HKLM\System\CurrentControlSet\Services\Tcpip\Parameters目錄下有一個(gè)叫TcpMaxDataRetransmissions的參數(shù),可以用來控制數(shù)據(jù)重傳次數(shù)。不過,那是限定的數(shù)據(jù)傳輸階段的重傳次數(shù)。

根據(jù)MSDN上的介紹,除了這個(gè)參數(shù),還有另一個(gè)參數(shù)用來限制上面SYN ACK重傳的次數(shù),它就是TcpMaxConnectResponseRetransmissions。

而且有趣的是,和Linux上的默認(rèn)值不一樣,Windows上的默認(rèn)值是2。

這就有意思了,通過這一點(diǎn),就能把Windows和Linux區(qū)分開來。

我趕緊用虛擬機(jī)中的XP上跑了一個(gè)nginx,測試了一下:

果然是2次,隨后我又換了一個(gè)Windows Server 2008,依舊是2次。

為了進(jìn)一步驗(yàn)證,我通過注冊(cè)表把這個(gè)值設(shè)定成了4:

再來試一下:

重傳次數(shù)果然變成了4次了。

接下來,在手中的Windows XP源碼中去印證這個(gè)信息:

果然,不管是從實(shí)驗(yàn)還是從源碼中都得到了同一個(gè)結(jié)論:

Linux上,SYN ACK默認(rèn)重傳5次。

Windows上,SYN ACK默認(rèn)重傳2次。

總結(jié)

如果一個(gè)IP開啟了基于TCP的服務(wù),不管是不是HTTP服務(wù),都可以通過向其發(fā)送SYN包,觀察其回應(yīng)來判斷對(duì)方是一個(gè)Linux操作系統(tǒng)還是一個(gè)Windows操作系統(tǒng)。

當(dāng)然,這種方法的局限性還是挺大的。

首先,本文只介紹了一些默認(rèn)的情況,但TCP的重傳次數(shù)是可以更改的,如果網(wǎng)絡(luò)管理員更改了這個(gè)數(shù)值,判斷的結(jié)果就不準(zhǔn)確了。

其次,對(duì)于有些網(wǎng)絡(luò)服務(wù)器開啟了防DDoS功能,測試發(fā)現(xiàn),其根本不會(huì)重傳SYN ACK包,比如我用百度的IP測試就得到了這樣的結(jié)果。

最后,沒有測試其他操作系統(tǒng)上的情況,比如Unix和MAC OSX,為什么呢?

因此,文中介紹的這種方法只能作為一種輔助手段,僅供參考,大家能順便了解一些關(guān)于TCP重傳的知識(shí)也是很有意義的。

好了,以上就是今天的分享了,寫作不易,大家看完給個(gè)三連支持呀~


END
作者:軒轅之風(fēng)O來源:編程技術(shù)宇宙版權(quán)歸原作者所有,如有侵權(quán),請(qǐng)聯(lián)系刪除。
嵌入式ARM

掃描二維碼,關(guān)注更多精彩內(nèi)容

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對(duì)環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢(shì) 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢(shì)...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動(dòng)力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉