Interview questions and answers

1.IIS Fundamentals

Internet Information Services (IIS) is Microsoft's suite of applications for the Internet. With support for the web, File Transfer Protocol (FTP), Network News Transfer Protocol (NNTP), and Simple Mail Transfer Protocol (SMTP) for e-mail, IIS is much more than just a web server. Because it is fully integrated at the operating system level, it integrates well with Microsoft .NET applications, and it allows organizations to add Internet capabilities that weave directly into the rest of their infrastructure.
As the Internet becomes more prevalent in our daily lives, the infrastructure behind it becomes more complicated, and the knowledge of how to support that infrastructure becomes more valuable. This chapter will introduce you to Windows Server 2003 (WS03) and the features of IIS 6. It also covers the metabase (which holds all the configuration information for IIS) and the architecture of IIS 6. Let's get started.
About Windows Server 2003

IIS 6 is the latest version of Microsoft's web server, and it's packaged with Windows Server 2003, which comes in four flavors: Web Server, Standard Server, Enterprise Server, and Datacenter Server.
Web Server is a limited functionality version. It gives you everything you need to run a web server, including network load balancing, but it can't act as a domain controller. It also can't act as a certificate authority and issue certificates. The upside? Lower price.
Standard Server is your garden-variety server operating system. It offers the standard functionality and is the version most people run.
Enterprise Server gives you everything Standard Server does, plus the ability to make a four-node cluster network configuration. In addition, if the hardware supports it, you can add memory while the server is running. Enterprise Server also allows you to cluster servers together for fault tolerance, rather than just balancing traffic across servers. Enterprise Server will also be released in a 64-bit edition.
Datacenter Server, the big dog of the family, supports the most processors and the most RAM, all at a greater cost. It also offers Microsoft's Datacenter support program. Datacenter Server includes support for up to eight-node clusters. Like Enterprise Server, Datacenter Server will be released in a 64-bit edition.
Hardware Support in Windows 2003

Difference in IIS 6, IIS 7.x and IIS 8 with regards to SSL

The big draw of a more expensive version is its hardware support. The following table details the hardware supported by each version of WS03; as you can see, the more expensive the version, the more memory and processors it can support.

here were lot of differences with regards to SSL moving from IIS 6 to IIS 7.x and then to IIS 8. IIS 6 in itself was a breaking change, however there were lot of limitations and they were addressed in higher versions. I will try to pen down as I remember them and will update the blog if I come across other changes. Before I proceed further, for readers who are not familiar with IIS and Windows versions, this is a small info to set the stage: IIS 6 (Windows Server 2003 and Windows XP 64 bit only) IIS 7 (Windows Server 2008 and Windows Vista) IIS 7.5 (Windows Server 2008 R2 and Windows 7) IIS 8 (Windows Server 2012 and Windows 8)  

I will be addressing both IIS 7 and IIS 7.5 as IIS 7.x.

Differences from architectural perspective:

One major difference between IIS 6 and the IIS 7.x was the way they would handle incoming HTTPS requests. Lets discuss how HTTPS requests were handled in IIS 6 before we proceed any further.

Taking the above architecture into consideration this is how the IIS 6 request flow looks like:

HTTPS requests comes into SSL Queue within HTTP.SYS, which is in the KERNEL Mode.

The encrypted requests is then sent to a USER Mode process called LSASS.exe for decryption. The request is decrypted using SChannel.dll loaded inside the lsass.exe process.

The decrypted request is not sent back to the HTTP.SYS In the Kernel Mode.

This is now placed in the corresponding Application Pool queue and then routed to corresponding worker process in USER Mode based upon which w3wp.exe a application pool queue corresponds too.

The w3wp.exe generates the response and sends it back to the HTTP.SYS in the KERNEL Mode.

This response is again sent to the Lsass.exe process in the user mode for encryption.

After encryption, lsass.exe sends it back to the HTTP.SYS in the KERNEL mode.

The encrypted response is sent back to the client. 

PROBLEM 1:

During the course of the entire processing of request, there were several context switches (Whenever there is a flow of control from KERNEL MODE to USER MODE or vice versa, it is referred as a CONTEXT SWITCH).

There were 6 context switches in the above flow, out of which 4 context switches happened for encrypting and decrypting of request and response.

Context switching induces additional overhead and delays the processing of requests. This impacts the performance as this happens for every HTTPS request-response cycle.

These 4 context switches could have been avoided if the encryption and decryption happened in the KERNEL Mode. This was addressed in IIS 7 and the same was retained in later versions.

PROBLEM 2:

Another problem is the problem with host headers. Host Headers were never defined in the original SSL Specification, as they were part of the HTTP RFCand defined there. The TCP Layer never defined the Host headers for obvious reasons. Due to this, a major problem emerged & made SSL applications not scalable.

Due to the unavailability of the Host Header in the TCP layer, the incoming encrypted HTTPS request provided only IP+Port as information to HTTP.SYS. In IIS the problem was addressed by allowing only one SERVER CERTIFICATE (Certificate Hash) per IP+PORT binding. The SSL Host Header was mostly irrelevant unless the Server Certificate was either a Wild Card Certificate or a SAN Certificate.

This problem was later addressed by the IEEE by introducing Subject Name Indication (SNI). Here the host header was made available in the Client Hello,sent by the client to the serer during the initiation of the SSL Handshake.

This was implemented in IIS 8. However, it has its own set of limitations.