哈哈！TCP泄露了操作系統信息···
大家好，我是軒轅。
前幾天，我在讀者群里提了一個問題：
這一下，大家總算停止了灌水(這群人都不用上班的，天天劃水摸魚)，開始討論起這個問題來。
有的說通過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重傳的知識也是很有意義的。
好了，以上就是今天的分享了，寫作不易，大家看完給個三連支持呀~
本文轉載自微信公眾號「編程技術宇宙」，可以通過以下二維碼關注。轉載本文請聯系編程技術宇宙公眾號。
