Hello, I’m Xuanyuan.

The other day, I asked readers a question:

This time, we finally stopped irrigation (this group of people do not have to go to work, everyday paddling fish), began to discuss this problem.

Some people say you can see it through the user-agent, I just gave it to a dog head.

If you see something like this in the Server field of the HTTP response, you must be on 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-power-by: ASP.NET Date: Fri, 23 Jul 2021 06:02:38 GMT content-length: 1375Copy the code

Others say that you can judge by the URL path, if case sensitive is Linux, insensitive is Windows.

So I made it even harder. What if there was no Web service, just a TCP Server?

You can ping the IP address to check the TTL value in the ICMP packet. If it is XXX, it is XX, if it is YYy, it is YY.

Start with TCP relegend

What I want to discuss with you today is another method, which is based on the idea of the article that was deleted a few days ago. The problem is that geek time is not accessible on the Internet in Japan, and this is what packet capture looks like:

See how the server is constantly trying to resend? And one question came to mind:

How many times does the server retransmit?

As we all know, TCP is a connection-oriented, reliable, byte stream-based transport layer communication protocol.

Among them, an important embodiment of reliability is its timeout retransmission mechanism.

There is a confirmation mechanism in TCP communication. After I send you the data, you have to tell me whether you have received it, so that the two parties can continue the communication. This confirmation mechanism is realized by serial number SEQ and confirmation number ACK.

Simply put, when a sender sends a message to a receiver and the receiver does not respond within a specified period of time, the sender considers it necessary to resend it.

What’s the maximum number of times? The DOCUMENTATION for TCP in the RFC is not explicit at this point, but gives some reference to the total timeout duration, which may result in differences between operating systems when implementing this mechanism. And then I came up with another question:

Will different operating systems have different retransmission times, so that you can judge the operating system by this point?

Then I looked at the TCP/IP Details, Volume 1, trying to find the answer, and sure enough, it never failed me:

What does this paragraph say? The RFC standard recommends two parameters, R1 and R2, to control the number of retransmissions. In Linux, these parameters can be seen as:

cat /proc/sys/net/ipv4/tcp_retries1
cat /proc/sys/net/ipv4/tcp_retries2
Copy the code

The default value of tcp_retries1 is 3 and the default value of tcp_retries2 is 15.

However, it is important to note that it is not a maximum of 3 or 15 passes. Linux has an internal algorithm, and these two values are important parameters in the algorithm, not the number of repasses per se. Specific retransmission times also has relationship with RTO, interested friends can look at the specific algorithm: this article talk about the retransmission times (perthcharles. Making. IO / 2015/09/07 /…).

In general, the number of retransmissions on Linux is not a fixed value, but rather a dynamic value calculated by different connections based on tcp_retries2 and RTO, which is not fixed.

On Windows, there is also a variable to control the number of retransmissions, which can be set in the registry:

Key path: registry key HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Parameters key name: TcpMaxDataRetransmissions default: 5Copy the code

I have a copy of the Windows XP source code in my hand, and this information is also confirmed in the part of the implementation of the stack driver tcpIP.sys:

However, from the current information, since the number of retransmissions in Linux is not fixed, it is not possible to use this number of retransmissions to determine the operating system.

TCP SYN+ACK retransmission

Just when I was about to give up, I read the passage in “TCP/IP Details · Volume 1” again, and found another message: TCP retransmission is not the same at the connection stage and the data transfer stage!

The preceding retransmission limit refers to the number of retransmission times after the TCP connection is established and the timeout retransmission occurs during the data transmission.

There is a different set of conventions for how many times a timeout retransmission can occur during a TCP connection establishment, i.e., a three-way handshake.

Linux:

In Linux, there are two additional parameters that limit the number of retransmissions during connection establishment:

cat /proc/sys/net/ipv4/tcp_syn_retries
cat /proc/sys/net/ipv4/tcp_synack_retries
Copy the code

Tcp_syn_retries specifies the maximum number of times a TCP connection can be initiated as a client. The default is 6 for Linux3.10 and 5 for Linux2.6.

Tcp_synack_retries Specifies the maximum number of SYN+ACK attempts after receiving a SYN from the server. The default is 5

Focus on tcp_synack_retries. This is the number of times a server retries a three-way TCP handshake if it replies with the second but never gets the third.

We know that a TCP three-way handshake normally looks like this:

But if the client does not send the third packet to the server, the server will resend its second handshake, and the situation will look like this:

Tcp_synack_retries specifies how many times the server retries its SYN+ACK.

To further verify, I wrote a piece of code in Python to manually send TCP packets using the sending library SCAPY, which I had previously written about in an article: Programming to Prisons, Rely on it! .

In this code, I send only one SYN packet to the specified port of the destination IP address:

def tcp_syn_test(ip, port): The first handshake is used to send a SYN packet. The first handshake is used to send a SYN packet. Ans = sr1(IP(DST = IP)/TCP(dport=port, sport=RandShort(), seq=RandInt(), flags='S'), verbose=False)Copy the code

Using the above code, send to a Linux server, capture the packet to see:

The server retransmitted the SYN+ACK packet for five times.

One server didn’t explain the problem, so I looked for several more, all of them five times.

Take a look at the definition of this number in the Linux source code:

Let’s take a look at Windows.

Windows

Said earlier, in the information in registry key HKLM \ System \ CurrentControlSet \ Services \ registry Tcpip \ Parameters have a directory called TcpMaxDataRetransmissions Parameters can be used to control data retransmission times, But that’s a limited number of retransmissions during the data transmission phase.

According to the MSDN is introduced, in addition to the parameters, and the other parameters are used to restrict the SYN + ACK retransmission times, it is TcpMaxConnectResponseRetransmissions.

And interestingly, unlike the default on Linux, the default on Windows is 2.

That’s interesting, because that’s how you differentiate Windows from Linux.

I quickly ran nginx on XP in the virtual machine and tested it:

Sure enough, it was 2 times, and then I switched to a Windows Server 2008, again 2 times.

To further verify, I set the value to 4 through the registry:

Try it again:

That’s four retransmissions.

Next, verify this information in the Windows XP source code in hand:

Sure enough, both the experiments and the source code led to the same conclusion:

On Linux, SYN+ACK is retransmitted five times by default. On Windows, SYN+ACK is retransmitted twice by default.

conclusion

If a TCP-based service is enabled for an IP address, whether it is an HTTP service or not, you can send a SYN packet to the IP address and observe the response to determine whether the IP address is a Linux or Windows operating system.

Of course, the limitations of this approach are considerable.

First, this article only covers the default cases, but the TCP retransmission count can be changed, and if the network administrator changes this number, the results will be inaccurate.

Secondly, for some network servers with anti-ddos function enabled, the test found that they would not retransmit SYN+ACK packets at all. For example, I used Baidu’s IP test to get such a result.

Finally, we didn’t test it on other operating systems, such as Unix and MAC OSX. Why?

Therefore, this method introduced in the article can only be used as an auxiliary means, only for reference, you can incidentally understand some knowledge about TCP retransmission is also very meaningful.

Ok, above is today’s share, writing is not easy, everyone read to a three consecutive support ah ~