We as developers have been into development of several web applications. We develop it day and night to meet the timelines and finally deliver it. The web application then gets deployed on the production servers and bingo, we are done! But have we ever wondered how does the web work behind the scene and allows our application to work butter smooth? We are aware of how to develop a web application in PHP or Java or .Net or any other programming language, but most of us probably don’t know how a browser interacts with the server where our application has been deployed, and how does the server respond with the response object back to the browser.
I am hereby describing the sequence of events involved starting from the request sent through the browser to the response that is received from the server back to the browser. This is something that every web developer must know.
Before I do so, it would be better to get familiar to some of the basic components of the web:
Client – Client is a networked device, which interacts with the user via some web interface, based on inputs of whose, a request is sent to some other systems, where the requests get processed and in turn generates a response. Most common example of a client can be a web browser that has now become a part of our daily life. Other examples include email client applications which may be Thunderbird, Outlook, etc. and chat applications such as Skype.
Server – Server is also a networked device, which waits to receive the request from a client system, has the capability to process this request accordingly based on the application code deployed onto it, and generate a response.
URL – The full form of URL is Uniform Resource Locator, which points to either a resource on the server or a mechanism to retrieve the resource (such as in Spring based applications in Java, where the URL points to the respective controller method, which in turn returns the model and view as response back to the browser). The URL is parsed as protocol://server/request-URI by the browser, which means that if I hit a URL http://jcombat.com/contact-us, http is the protocol that is to be used to access a resource on the network, jcombat.com points to the server system on the same network and contact-us becomes the Request URI, which finally identifies a particular resource on that server.
If you have understood how a URL works and how is it able to retrieve a particular resource from the server, you might be wondering how does then multiple websites on the same shared server work? Now that all the websites share the same server system, it’s quite possible that the ‘Contact Us’ page of two websites might be having the same Request URI. For instance, let’s assume there is a website http://abc.com on the same server where http://jcombat.com is hosted, and their URL for the ‘Contact Us’ page is http://abc.com/contact-us and http://jcombat.com/contact-us respectively. You could note that both the URLs have the same Request-URI, as well as both the domains point to the same server. From the incoming request, server must know where exactly to look for the resource (Contact Us page), under which domain directory, and it gracefully does know it! But how? We will know the answer when we come across HTTP Request.
HTTP – TCP (Transmission Control Protocol) is a protocol that provides a reliable link between a server and a client. Any data interaction between the server and client is broken down into smaller bits/packets that get re-assembled at the destination to form the original data that was sent. Any packet lost during transmission is re-transmitted. TCP itself rides on top of another protocol namely IP (Internet Protocol), which is responsible for providing unique addresses(IP address) to the network devices ensuring proper communication between the sender and receiver.
HTTP stands for Hyper Text Transfer Protocol, which in turn rides on top of TCP/IP. HTTP defines the rules for message format and the actions, web browsers and web servers should take in response to various commands. For example, when a URL is entered into the browser, it actually sends an HTTP command to fetch a particular resource directly from the web server or alternatively map to some mechanism to retrieve the resource (such as request mappings in Spring based application controllers). Since HTTP is a stateless protocol, to respond intelligently to such HTTP commands is possible through various server side programming/scripting languages such as Java, PHP, etc. Without the use of any additional server side technology, HTTP commands could be as dumb to retrieve only the static resources from the web server.
There are several shortcomings in the current HTTP version 1.1, to list a few:
- HTTP version 1 allows only request to be processed at a time.
- With a constraint to process single request at a time, multiple connections can be made to the HTTP server via multithreading to reduce the page load time, which will help us load multiple images at the same time. Servers are always ready to accept multiple connections from the same client, however it depends on the application logic to prevent the same. Multiple connections must be very carefully handled since it might pose security risks.
- Multiple connections to the server from the same source leads to repetitive headers being sent, consequently leading to larger data packets.
HTTPS (Hyper Text Transfer Protocol Secured) on the other hand is the secured version of HTTP, where the data is encrypted during transmission and gets decrypted at the destination. The additional effort of encryption and decryption makes the HTTPS connections comparatively slower than the normal HTTP ones.
With this, I hope you are clear on the basic components now. Moving ahead, probably you might already be aware of the client server model. However, I will try briefing it. Kindly navigate to the next page to continue reading.