Re: HTTP/2.0 Magic

Don't know. I looked a little bit into isolating different servers, but from what I initially saw, many servers are all over the map; it seems to have more to do with configuration / handlers installed / middleboxes in front than just the server software.


On 21/02/2013, at 6:15 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 21/02/2013 7:12 p.m., Mark Nottingham wrote:
>> So, I decided to explore this a bit more.
>> 
>> I have a list of about 760,000 IP addresses running Web servers, so I put together a quick script to see how they reacted to various magic strings.
>> 
>> For the source, see:
>>   https://github.com/http2/http2-probe
>> 
>> Below are my notes from some preliminary experimentation today.
>> 
>> Just sending FOO\n\n to ~760,000 servers gives:
>> 
>> FOO\n\n
>>  641481 CLOSE
>>   85855 CONN_ERR
>>   35148 TIMEOUT
>> 
>> "CLOSE" means that the server closed the connection; "CONN_ERR" was various connection errors,
>> and "TIMEOUT" means it hangs (5 seconds, in this case).
>> 
>> Let's try adding \r before the \n (all of the following runs are on the TIMEOUTs above).
>> 
>> FOO\r\n\r\n
>>    1602 CLOSE
>>     303 CONN_ERR
>>   33243 TIMEOUT
>> 
>> A bit of help. What if we give it HTTP syntax?
>> 
>> FOO * HTTP/2.0\r\n\r\n
>>   30082 CLOSE
>>     396 CONN_ERR
>>    4670 TIMEOUT
>> 
>> Much better. What if we add Connection: close?
>> 
>> FOO * HTTP/2.0\r\nConnection: close\r\n\r\n
>>   30310 CLOSE
>>     337 CONN_ERR
>>    4501 TIMEOUT
>> 
>> Not significantly better. What if we do Content-Length: 0 instead?
>> 
>> FOO * HTTP/2.0\r\nContent-Length: 0\r\n\r\n
>>   30072 CLOSE
>>     369 CONN_ERR
>>    4707 TIMEOUT
>> 
>> Not helping. What if we add a second "request"?
>>   FOO * HTTP/2.0\r\n\r\nBAR * HTTP/2.0\r\n\r\n
>>   31212 CLOSE
>>     306 CONN_ERR
>>    3630 TIMEOUT
>> 
>> Significantly better. Can we save the \r?
>> 
>> FOO * HTTP/2.0\n\nBAR * HTTP/2.0\n\n
>>   27101 CLOSE
>>     312 CONN_ERR
>>    7735 TIMEOUT
>> 
>> Ouch. Does it need the full second request, or just some bits?
>> 
>> FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n
>>   31132 CLOSE
>>     427 CONN_ERR
>>    3589 TIMEOUT
>>    Not bad; our best candidate. About 175 out of the 3589 remaining TIMEOUTs on the do send some text (most often, a HTTP status code), but that's not the majority; most of them well and truly hang.
>> 
>> The distribution of latency on CLOSE (factoring out the round trip) is very heavy towards 0; see  the list at the end (some are negative because of jitter; connect time is used to estimate latency). Note the bumps at 1 and 3 seconds; I suspect these are timeouts in some load balancer or other middlebox, because their Server headers are pretty diverse.
>> 
>> Just to see, what if we truncate the first one too?
>> 
>> FOO\r\n\r\nBAR\r\n\r\n
>>    1042 CLOSE
>>      86 CONN_ERR
>>   11766 TIMEOUT
>>   Nope (stopped run when this became obvious). What about some binary?
>> 
>> \xff * HTTP/2.0\r\n\r\n\xff\r\n\r\n
>>   30271 CLOSE
>>     342 CONN_ERR
>>    4535 TIMEOUT
>>    Huh. Not as good as text.
> 
> 
> Couple of questions.
> How do the TIMEOUT failure sets compare to each other?
> are they all the same servers or do some respond badly to one form and CLOSE quickly on others?
> Is there any consistency in identifiable software doing TIMEOUT on any particular magic?
> 
> 
> Amos
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 21 February 2013 07:19:52 UTC