How do website blockers distinguish browser traffic?

Question

Computer networks

When you try to open Kinozal.tv in any browser, it redirects to the RosKomNadzor stub.
Moscow, provider OnLime, OS X 10.11.2 El Capitan. Google DNS. The browser request goes to the correct address, to CloudFlare - the site name from foreign vps's is also resolved to the same ip. In response, browsers receive a simple redirect to the stub:

If you make a connection not with a browser, but with telnet on port 80, then everything works as expected - the html of the page is returned without any redirects:

This also works if all the same HTTP headers are sent to telnet , which is sent by the browser:

GET / HTTP/1.1
Host: kinozal.tv
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: uid=1234567; pass=XXXXXXXX; __cfduid=abcdefe0171f2defb37070b1428009916; stylet=0
Connection: keep-alive

Although it is better to remove the heading about gzip, otherwise unreadable binary garbage of compressed content falls into the terminal.
So far, the only difference I see is in time: in telnet, it takes a couple of seconds from the moment of connection to the sending of headers, while I manually paste. In the browser, this happens in milliseconds. I should try with curl..
Question: why do telnet requests bypass the blocking mechanism? (how to make browsers imitate telnet in terms of bypassing blocking is also interesting, but it will probably be obvious)
Upd. more subtle difference. Netcat with a 1-second delay ( -i 1) returns the added redirect header in response:

$ echo -ne 'GET / HTTP/1.1\r\nHost: kinozal.tv\r\n\r\n' | nc -i 1 kinozal.tv 80

Without a second delay , with a manually inserted request (as in the telnet version), returns pure html of the page being searched for:

Sounds like a matter of time?

Answer 1

https://habrahabr.ru/post/249433/ here (in UPD) it is described how it works, and most importantly, how to get around it.

Answer 2

The blocker looks at the first packet when the connection is established. The browser sends the headers along with the syn packet. Telnet opens the connection, then the blocker looks at it, does not find the domain and connects to the site, and then the connection goes into the established state and further requests are not processed... Browsers
have an option to quickly open connections - try to disable it via flags.

Answer 3

teach to yuzat torrents?

Answer 4

The answer is obvious: a DNS request for a blocked domain costs an IP substitution for a stub site.