哈哈！TCP泄露了操做系統信息···

你們好，我是軒轅。html

前幾天，我在讀者羣裏提了一個問題：nginx

這一下，你們總算中止了灌水（這羣人都不用上班的，每天划水摸魚），開始討論起這個問題來。git

有的說經過User-Agent能夠看，我直接給了一個狗頭。github

而後發現不對勁，改口說能夠經過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系統···（不過有些狀況下也不是太準確）markdown

從TCP重傳提及

今天想跟你們探討的是另一種方法，這個方法的思路來源於前幾天被刪掉的那篇文章。就是日本網絡環境下訪問不了極客時間的問題，當時抓包看到的狀況是這個圖的樣子：網絡

看到了服務器後面在不斷的嘗試重發了嗎？當時我就想到了一個問題：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有關係，具體的算法有興趣的朋友能夠看看這篇文章：聊一聊重傳次數（perthcharles.github.io/2015/09/07/…）

整體來講，在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重傳的知識也是頗有意義的。

好了，以上就是今天的分享了，寫做不易，你們看完給個三連支持呀~