作者 | 軒轅之風O
來源 | 編程技術宇宙(id:xuanyuancoding)
前幾天,我在讀者群里提了一個問題:
這一下,大家總算停止了灌水(這群人都不用上班的,天天划水摸魚),開始討論起這個問題來。
有的說通過User-Agent可以看,我直接給了一個狗頭。
然後發現不對勁,改口說可以通過HTTP響應的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。
於是我進一步提高了難度,如果連Web服務也沒有,只有一個TCP Server呢?
這時又有人說:可以通過ping這個IP,查看ICMP報文中的TTL值,如果是xxx就是xx系統,如果是yyy就是yy系統···(不過有些情況下也不是太準確)
從TCP重傳說起
今天想跟大家探討的是另外一種方法,這個方法的思路來源於前幾天被刪掉的那篇文章。就是日本網絡環境下訪問不了極客時間的問題,當時抓包看到的情況是這個圖的樣子:
看到了伺服器後面在不斷的嘗試重發了嗎?當時我就想到了一個問題:
伺服器到底會重傳好多次呢?
眾所周知,TCP是一種面向連接的、可靠的、基於字節流的傳輸層通信協議。
其中,可靠性的一個重要體現就是它的超時重傳機制。
TCP的通信中有一個確認機制,我發給你了數據,你得告訴我你收到沒,這樣雙方才能繼續通信下去,這個確認機制是通過序列號SEQ和確認號ACK來實現的。
簡單來說,當發送方給接收方發送了一個報文,而接收方在規定的時間裡沒有給出應答,那發送方將認為有必要重發。
那具體最多重發多少次呢?關於這一點,RFC中關於TCP的文檔並未明確規定出來,只是給了一些在總超時時間上的參考,這就導致不同的作業系統在實現這一機制的時候可能會有一些差異。於是我進一步想到了另一個問題:
會不會不同作業系統重傳次數不一樣,這樣就能通過這一點來判斷作業系統了呢?
然後我翻看了《TCP/IP詳解·卷1》,試圖在裡面尋找答案,果然,這本神書從來沒有讓我失望過:
這一段說了個什麼事情呢?大意是說RFC標準中建議有兩個參數R1和R2來控制重傳的次數,Linux中,這倆參數可以這樣看:
cat /proc/sys/net/ipv4/tcp_retries1
cat /proc/sys/net/ipv4/tcp_retries2
tcp_retries1
默認值是3,TCP_retries2
默認值是15。
但需要特別注意的是,並不是最多重傳3次或者15次,Linux內部有一套算法,這兩個值是算法中非常重要的參數,而不是重傳次數本身。具體的重傳次數還與RTO
有關係,具體的算法有興趣的朋友可以看看這篇文章:聊一聊重傳次數(http://perthcharles.github.io/2015/09/07/wiki-tcp-retries/)
總體來說,在Linux上重傳的次數不是一個固定值,而是不同的連接根據tcp_retries2
和RTO
計算出來的一個動態值,不固定。
而在Windows上,也有一個變量來控制重傳次數,可以在註冊表中設定它:
鍵值路徑:
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
鍵值名:
TcpMaxDataRetransmissions
默認值:5
我手裡有一份Windows XP的源碼,在實現協議棧的驅動tcpip.sys
的部分中,也印證了這個信息:
不過就目前的信息來看,由於Linux的重傳次數是不固定的,還沒法用這個重傳次數來判斷作業系統。
TCP之SYN+ACK的重傳
就在我想要放棄的時候,我再一次品讀《TCP/IP詳解·卷1》中的那段話,發現另一個信息:TCP的重傳在建立連接階段和數據傳輸階段是不一樣的!
上面說到的重傳次數限制,是針對的是TCP連接已經建立完成,在數據傳輸過程中發生超時重傳後的重傳次數情況描述。
而在TCP建立連接的過程中,也就是三次握手的過程中,發生超時重傳,它的次數限定是有另外一套約定的。
Linux:
在Linux中,另外還有兩個參數來限定建立連接階段的重傳次數:
cat /proc/sys/net/ipv4/tcp_SYN_retries
cat /proc/sys/net/ipv4/tcp_synack_retries
tcp_syn_retries
限定作為客戶端的時候發起TCP連接,最多重傳SYN的次數,Linux3.10中默認是6,Linux2.6中是5。
tcp_synack_retries
限定作為服務端的時候收到SYN後,最多重傳SYN+ACK的次數,默認是5
重點來關注這個tcp_synack_retries
,它指的就是TCP的三次握手中,服務端回復了第二次握手包,但客戶端一直沒發來第三次握手包時,服務端會重發的次數。
我們知道正常情況下,TCP的三次握手是這個樣子的:
但如果客戶端不給服務端發起第三個包,那服務端就會重發它的第二次握手包,情況就會變成下面這樣:
所以,這個tcp_synack_retries
實際上規定的就是上面這種情況下,服務端會重傳SYN+ACK的次數。
為了進一步驗證,我使用Python寫了一段代碼,用來手動發送TCP報文,裡面使用的發包庫是scapy。
下面的這段代碼,我向目標IP的指定埠只發送了一個SYN包,:
def tcp_syn_test(ip, port):
# 第一次握手,發送SYN包
# 請求埠和初始序列號隨機生成
# 使用sr1發送而不用send發送,因為sr1會接收返回的內容
ans = sr1(IP(dst=ip) / TCP(dport=port, sport=RandShort, seq=RandInt, flags='S'), verbose=False)
用上面這段代碼,向一台Linux的伺服器發送,抓包來看一下:
實際驗證,伺服器確實重傳了5次SYN+ACK報文。
一台伺服器說明不了問題,我又多找了幾個,結果都是5次。
再來看一下Linux的源碼中關於這個次數的定義:
接下來看一下Windows上的情況。
Windows
前面說過,在註冊表HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
目錄下有一個叫TcpMaxDataRetransmissions
的參數可以用來控制數據重傳次數,不過那是限定的數據傳輸階段的重傳次數。
根據MSDN
上的介紹,除了這個參數,還有另一個參數用來限制上面SYN+ACK重傳的次數,它就是TcpMaxConnectResponseRetransmissions
。
而且有趣的是,和Linux上的默認值不一樣,Windows上的默認值是2。
這就有意思了,通過這一點,就能把Windows和Linux區分開來。
我趕緊用虛擬機中的XP上跑了一個nginx,測試了一下:
果然是2次,隨後我又換了一個Windows Server 2008,依舊是2次。
為了進一步驗證,我通過註冊表把這個值設定成了4:
再來試一下:
重傳次數果然變成了4次了。
接下來在手中的Windows XP源碼中去印證這個信息:
果然,不管是從實驗還是從源碼中都得到了同一個結論:
Linux上,SYN+ACK默認重傳5次。
Windows上,SYN+ACK默認重傳2次。
總結
如果一個IP開啟了基於TCP的服務,不管是不是HTTP服務,都可以通過向其發送SYN包,觀察其回應來判斷對方是一個Linux作業系統還是一個Windows作業系統。
當然,這種方法的局限性還是挺大的。
首先,本文只介紹了一些默認的情況,但TCP的重傳次數是可以更改的,如果網絡管理員更改了這個數值,判斷的結果就不準確了。
其次,對於有些網絡伺服器開啟了防DDoS功能,測試發現,其根本不會重傳SYN+ACK包,比如我用百度的IP測試就得到了這樣的結果。
最後,沒有測試其他作業系統上的情況,比如Unix和MAC OSX,為什麼呢?
因此,文中介紹的這種方法只能作為一種輔助手段,僅供參考,大家能順便了解一些關於TCP重傳的知識也是很有意義的。