We’ve been using IE 8 for just over two weeks and wanted to run through some of the significant differences that will affect anyone involved in web development, debugging or performance tuning.

#1 : IE 8 Opens More Connections Per Host Name

As we previously mentioned in Blocked time and IE8, the default number of concurrent connections per host name has been increased in IE 8. In earlier versions of IE only a maximum of two connections would simultaneously download content from a single host name (e.g. www.microsoft.com ). Here’s an example using HttpWatch and IE 7:

The limit of only two active connections would often cause requests to be queued up in IE until a connection became available. In HttpWatch, this is known as the Blocked time and is shown as a gray bar in the time chart.

Increasing the number of active connections to six (the same as Firefox 3.0) allows for much greater concurrently and drastically reduces the amount of blocked time experienced on most web pages:

If you are concerned about your web site’s performance make sure that you also check it in IE 7 as it may be substantially different from IE 8.

#2 : IE 8 Has a New Process Model

IE 8 has a new feature known as Loosely Coupled IE (LCIE) that uses separate instances of the iexplore.exe process to provide enhanced isolation and reliability. The IE frame window and tabs run in a separate processese, so that if one tab crashes you will not lose the whole of your browser session:

IE 8 will even attempt to re-start and re-open an individual tab if a problem occurs. Pop-up windows are treated in a similar way and will placed in separate processes if possible.

One advantage of this model is that it allows tabs for both protected mode and non-protected mode web sites to be loaded into the same top level window. In IE 7, a separate frame window was created if you attempted to open tabs with different protection levels.

Initially, each new tab and pop-up window gets its own process but as the number of tabs grows the number of processes is capped. Once the cap is reached, new tabs will share existing processes with other tabs. By default, the upper limit on the number of processes is based on the amount of physical memory available to Windows.

In previous versions of IE, clicking on the blue ‘e’ icon on the start menu would create a new IE frame window in a separate instance of the iexplore.exe process. In IE 8 this behaviour has been changed in an attempt to reduce the number of processes allocated to IE. It now uses a technique, known as Frame Merging, that creates an IE frame window using the existing IE frame process, if one exists.

If you really want separate IE frame processes you can do this by supplying -nomerge in the IE command line:

iexplore.exe -nomerge

#3 : All IE 8 Tabs, Windows and Pop-ups Belong To The Same Browser Session

Session level cookies used to be maintained at the process level by older versions of IE. This meant that every time you clicked on the IE icon and started a new IE process you also started a new browser session, allowing you to login into multiple accounts (e.g. multiple GMail accounts) simultaneously.

IE 8 does not create a new session for every process, because there could be multiple tabs or pop-up windows in different processes that need to share the same session level cookies. Instead, the browser session is now maintained by the process that contains the main frame window.

The default use of Frame Merging in IE 8 prevents the creation of multiple frame processes, so all windows and tabs will belong to the same session. This is identical to the behavior you get in Firefox using a single default profile.

But what if you need to log into a web site simultaneously using two or more login accounts ?

To create a new session you just have to ensure that a new IE 8 frame process is created. There are two ways to do this:

1. Start IE 8 using the -nomerge command line flag as shown above
2. Use File->New Session. This creates a new frame window process and browser session

#4 : The IE 8 Process Model is Configurable

The IE team has documented a single registry value that controls the new process model. If you create a DWORD value called TabProcGrowth in:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main

you can control how many browser processes are used by IE 8:

The three most useful values for this setting are:

1. TabProcGrowth = <absent> – this is the default setting allowing IE 8 to control how many processes are used based on the amount of physical memory installed
2. TabProcGrowth = 0 – a value of zero means use the same process for all tabs, frames and pop-up windows in each browser session. This makes IE 8 behave just like IE 7 on Windows XP. There’s no frame merging and clicking on the IE icon creates a new instance of iexplore.exe in a separate browser session. Protected mode on Vista is not available with this setting because the IE frame and tabs can only operate at different integrity levels if they are in separate processes. This setting may be useful if you are debugging an IE add-on or if you have automated tests that rely on the IE 7 process model.
3. TabProcGrowth = 1 – this means use one process for all the tabs and pop-ups in a browser session and one process for the IE 8 frame window. Frame merging occurs with this setting and protected mode is supported on Vista. You may want to use TabProcGrowth = 1 where you want to keep tabs and pop-ups in one process but still allow the use of protected mode.

Specifying a number greater than 1 sets an upper limited on the maximum number of tab processes to use per frame window process.

#5 : Compatibility Workarounds for IE 8

The new, improved, implementation of standards mode in IE 8 means that some sites that used to work in IE 7 may no longer display correctly. Ideally, every site will update their HTML to make it work correctly in IE 8, but an IE 7 emulation option has been provided as a work-around. It can be triggered by a number of different mechanisms:

1. Microsoft maintains a list of web sites that don’t work well with IE 8 based on feedback from users. The IE 7 emulation mode is automatically enabled for thousands site that are in this list, including popular sites such as amazon.com, ebay.com, google.com and even microsoft.com!
2. A web site developer can indicate that their site requires the compatibility mode by adding this meta tag to their HTML:
   
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

   Or by using a response header:

   X-UA-Compatible: IE=EmulateIE7

   Microsoft uses the meta tag on the Microsoft home page and the use of the response header on the MSDN site is shown below in HttpWatch:

   

3. If a user spots a problem they can click on the compatibility mode button in IE 8:
   

   This button doesn’t appear if the site has already specified IE 7 emulation.

Microsoft’s extensive use of IE 7 emulation indicates just how much work is required on a large site to fix up the HTML for IE 8 standards mode and still keep it working with IE 7.

#6 : New Built-in Developer Tools for IE 8

Some excellent developer tools are now built into IE 8. You no longer need to separately install the Web Developer Toolbar used by IE 7. These tools include:

• ‘View Source’ now opens a window with HTML syntax coloring and line numbers instead of the Notepad window used in previous versions.
• A Firebug -like DOM viewer that shows which CSS styles have been applied to an HTML element
• A Javascript Profiler and Console

#7: How to Use HttpWatch with IE 8

The only real difference you will see in HttpWatch with IE 8 is caused by the new process model.

HttpWatch records traffic at the process level. Therefore, in IE 8 it will maintain a separate log for each tab and pop-up process. Generally, this is not an issue as you normally only want to see the traffic for a single tab or window. If you really need to record across multiple tabs or pop-up windows there are two approaches you can use:

1. Change the IE 8 process model so that only one process is used for tabs and windows (i.e. set TabProcGrowth to 0 or 1 ). HttpWatch will then record all the traffic in one log file.
2. If you don’t want to change the process model, you could separately view and save HttpWatch log files from each tab and pop-up window. If a window doesn’t have a toolbar you can open HttpWatch using the Shift+F2 keyboard shortcut

You’ll also find that HttpWatch shortcut keys will not work in the IE 8 location bar or search field. We plan to fix that in a future update, but in the meantime you can work around it by putting the keyboard focus into the web page itself before using the shortcut key.

An often overlooked aspect of web performance tuning is the effect of using the HTTPS protocol to create a secure web site. As applications move from the desktop onto the web, the need for security and privacy means that HTTPS is now heavily used by web sites that need to be responsive enough for every day use.

The tips shown below may help you to avoid some of the common performance and development problems encountered on sites using HTTPS:

Tip #1: Use Keep-Alive Connections

Whenever a browser accesses a web site it must create one or more TCP connections. That can be in lengthy operation even with normal unsecured HTTP.  The use of Keep-Alive connections reduces this overhead by reusing TCP connections for multiple HTTP requests. The screen shot below from HttpWatch shows the TCP connection time over HTTP is approximately 130 milliseconds for our web site when it is accessed from the UK:

Using HTTPS, the lack of Keep-Alive connections can lead to an even larger degradation in performance because an SSL connection also has to be setup once the TCP connection has been made. This requires several roundtrips between the browser and web server to allow them to agree on an encryption key (often referred to as the SSL session key) . The corresponding connection time to the same server using HTTPS is nearly four times longer as it includes the HTTPS overhead:

If a HTTPS connection is re-used the overhead of the both the TCP connection and SSL handshake are avoided.

Some web browsers and servers now allow the re-use of these SSL session keys across connections, but you may not always have control over the web server configuration or the type of browser used.

Tip #2: Avoid Mixed Content Warnings

In a previous blog post we talked about the confusing and annoying dialog that is displayed by default if a secure page uses any HTTP resources:

To stop this warning dialog interrupting the page download you need to ensure that everything on the page is accessed over HTTPS. It doesn’t have to be from the same site but it must use HTTPS. For example, the addition of HTTPS support allows the Google Ajax libraries to be safely loaded from secure pages.

Tip #3: Use Persistent Caching For Static Content

If you follow Tip #2 then everything that your page needs, including images, CSS and Javascript, will be accessed over HTTPS. You would normally want to persistently cache static content like this for as long as possible to reduce load on the web site and improve performance when a user revisits your site.

Of course, you wouldn’t want to cache anything on the disk that was specific to the user (e.g. HTML page with account details or a pie chart of their monthly spending). On most pages though, nearly all of the non-HTML content can be safely stored, shared and re-used.

There seems to be some confusion over whether caching is possible with HTTPS. For example, Google say this about Gmail over HTTPS:

You may find that Gmail is considerably slower over the HTTPS connection, because browsers do not cache these pages and must reload the code that makes Gmail work each time you change screens.

Although, 37Signals acknowledge that in-memory caching is possible, they say that persistent caching is not possible:

The problem is that browsers don’t like caching SSL content. So when you have an image or a style sheet on SSL, it’ll generally only be kept in memory and may even be scrubbed from there if the user is low on RAM (though you can kinda get around that).

Even when you do your best to limit the number of style sheets and javascript files and gzip them for delivery, it’s still mighty inefficient and slow to serve them over SSL every single time the user comes back to your site. Even when nothing changed. HTTP caching was supposed to help you with that, but over SSL it’s almost all for naught.

In reality, persistent caching is possible with HTTPS using both IE and Firefox.

Using HttpWatch you can see if content is loaded from the cache by looking for (Cache) in the Result column or by looking for the blue Cache Read block in the time chart. Here is an example of visiting https://www.httpwatch.com with a primed cache in IE. You can see that all the static resources are reloaded directly from the cache without a round trip to the web server:

If you try this in Firefox 3.0 without adjusting your response headers you will see this instead:

The ‘200’ values in the Result column indicate that the static content is being reloaded even though the site was previously visited and a valid Expires setting was used. Unless you specify otherwise, Firefox will put HTTPS resources into the in-memory cache so that they can only be re-used within a browser session. When Firefox closes the contents of the in-memory cache is lost.

The about:cache page in Firefox confirms that these files are stored using the in-memory cache:

To allow persistent caching of secure content in Firefox you need to set the Cache-Control response header to Public:

This value moves HTTPS based content into the persistent Firefox disk cache and in the case of https://www.httpwatch.com it more than halves the page load time due to the decrease in network round trips and TCP/SSL connections:

The Public cache setting is normally used to indicate that the content is not per user and can be safely stored in shared caches such as HTTP proxies. With HTTPS this is meaningless as proxies are unable to see the contents of HTTPS requests. So Firefox cleverly uses this header to control whether the content is stored persistently to the disk.

This feature was only added in Firefox version 3.0 so it won’t work with older versions. Fortunately, the take up version 3.0 is reported to be much faster than IE 6 to 7.

Tip #4: Use an HTTPS Aware Sniffer

A network sniffer is an invaluable tool for optimizing and debugging any client server application. But if you use a network level tool like Netmon or WireShark you cannot view HTTPS requests without access to the private key that the web site uses to encrypt SSL connections.

Often organizations will not allow the use of private keys outside of a production environment, and even if you have administrative access to your web site, getting the private key and using it to decrypt network traffic is not an easy task.

HttpWatch was originally born out of the frustration of trying to debug secure sites. Viewing HTTPS traffic in HttpWatch is easy as it integrates directly with IE or Firefox, and therefore has access to the unencrypted version of the data that is transmitted over HTTPS.

The free Basic Edition shows high level data and performance time charts for any site, and lower level data for a number of well know sites including Amazon.com, eBay.com, Google.com and HttpWatch.com . For example, you can try it with HTTPS by going to https://www.httpwatch.com .

You can check SSL/TLS configuration our new SSL test tool SSLRobot . It will also look for potential issues with the certificates, ciphers and protocols used by your site. Try it now for free!

One of the most common security vulnerabilities in Windows software is the buffer overrun exploit. It works by feeding a well crafted data stream into a program that uses a stack based buffer without correctly checking the length of the data stream. By writing past the end of the buffer the overwrite can:

1. Store malicious assembler instructions in the stack’s memory pages
2. Change the current function’s return address on the stack so that the malicious instructions are executed instead of the original calling code hwne the function returns.

This technique for injecting code can be used to take control of the current process and possibly the whole PC if the program is running as a user with admin rights.

The problem originates from the fact that Intel’s early x86 processors would enforce the READ and WRITE flags on memory pages; but not the EXECUTE flag that is used for executable code pages. The memory pages used by a program’s stack never have the EXECUTE flag and step 2) above should fail because an attempt is being made to execute READ/WRITE data.

By the time Intel added the NX flag to enforce execution protection, many carelessly written programs relied on being able to execute code in a non-EXECUTE page. So when Microsoft added DEP (Data Execution Protection) in Windows XP SP2, they were unable to turn it on globally because of the large number of third party applications and add-ons that would fail.

Of course, there is one program in particular that would benefit from DEP – Internet Explorer. It’s used by more than half a billion people worldwide and can be subjected to buffer overrun attacks when visiting malicious or hacked web sites. Unfortunately, only a tiny percentage of the IE users around the world have DEP enabled. 

On Windows XP you cannot turn on DEP in Internet Explorer through the user interface, even if you turn on DEP globally like this in the Control panel System applet:

There are certain programs that are always excluded from DEP on Windows XP for compatibility reasons. IE is one of these programs because so many third party add-ons and OCXs failed to work correctly with DEP when Service Pack 2 was released.

Incidentally, HttpWatch works with DEP and is built with the /NXCOMPAT flag to indicate that it can safely be used when DEP is enabled.

On Windows Vista you can enable DEP in IE 7 by using this checkbox:

The checkbox cannot only be modified if you run IE 7 as the administrator:

So why doesn’t everyone do this and why isn’t it the default? That’s because there’s one major non compliant add-on that nearly everyone installs – the Sun Java runtime. When it’s installed and you have DEP enabled, IE 7 raises a DEP error if you visit a site that uses a Java applet:

Sun has acknowledged the problem, but the high priority bug has been open since April 2007:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6545701

Once this has been fixed the way is clear for DEP to be enabled for most IE users on Windows Vista.

In the meantime, IE 7 on Vista still offers much better protection against buffer overruns that Windows XP. That is because of two new features:

• Protected Mode – by default IE 7 runs in a low rights mode even if you are logged in as an administrator. A hijacked instance of IE therfore has limited access to other programs and data on the PC.
• Address Space Layout Randomization (ASLR) – on Windows Vista important system DLLs are placed at random locations in each process. The hacker can no longer rely on system functions being at known locations and would have to make a guess. Any incorrect guess causes the hijacked program to crash preventing continued execution of the malicious code.