Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Start up Wireshark. Point IE9 to a local, nonroutable IP address. You will see a single TCP SYN packet try to connect to the host.

Now point IE9 to a remote, routable IP address. You will see 2 almost-simultaneous TCP SNY packets go out.

Why would a web browser behave differently when trying to get to a routable IP address?


Edit 1

Here's a wireshark capture of the problem. Wireshark Capture

Pkt 1 is a SYN to a nonroutable IP address. 3 second later it retries. 6 seconds after that it tries again. At Pkt 4 IE9 gave up on the first TCP socket and opened another (the source port changed). There are retries at 3 and 6 seconds later.

Pkt 7 is a SYN to a routable IP address. Pkt 8 is another SYN to the same IP address. This is the second TCP socket (source port is different).


Edit 2 Here's a better picture to see the text: Better image than the first

share|improve this question
3  
I don't suppose you can paste the packet logs or a screenshot and hopefully we can help you a little easier. –  William Hilsum Mar 29 '12 at 20:07
    
I used google.com and 74.125.225.1 to test this I got two TCP SNY packets each time... –  Kyle Mar 29 '12 at 20:44
    
Could be an option probe. For ECN perhaps. Compare the TCP options in both packets. –  Zan Lynx Mar 30 '12 at 3:44
    
@Kyle those are both routable IP addresses. What happens if you open the web page for your local router? –  Robert Mar 30 '12 at 12:25
    
The timestamps in your log are really weird and confusing. Pkt 7 seems to have been sent 44 seconds after Pkt 8. –  Jan Schejbal Feb 24 '13 at 21:06

2 Answers 2

IE uses a zone model, treating web sites differently depending on what zone they belong to. If your non-routable IP is considered part of the intranet zone, it is expected to receive different treatment. This does not only influence security settings; intranet sites may also be rendered using prehistoric rendering standards even if they have a HTML5 doctype. (Note: Your testing IP may or may not be considered intranet, depending on your configuration.)

As sites in a intranet typically have a very low round-trip delay and high reliability, it would make sense to keep less parallel connections open. It is also possible that IE does other things differently (e.g. preparing to load certain resources, fetching favicons, ...).

I could not find any document explicitly stating that any such behavior is different depending on the zone, but that means little when it comes to weird IE behavior. Some of the differences I mentioned are explained here and this document mentions that caching is separate for the zones.

Even if you don't have the intranet zone enabled, I would not be surprised if IE had some special handling for non-routable IP addresses (the pointless "ignore HTML5 doctype if in intranet zone" shows what weird stuff is to be expected from IE).

Also note the weird timestamps in your screenshot. Maybe something is wrong with the capture or your interpretation of it.

TL;DR: Do not use IE. If you do, do not be surprised if it does weird things.

share|improve this answer

You really need to look at the HTTP streams beneath to find out what is going on. If you aren't fetching the same exact HTML document from your local IP and Internet-facing IP then you've introduced additional variables into your investigation here.

Off the top of my head I'd say it's your browser asking for the favicon.ico as well as the index.html from google.com. It'd be two separate HTTP requests. Given AJAX and such Javascript may also be involved.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.