This is the first in a series of articles explaining how HTTP and web browsers work. HTTP uses a TCP connection to send requests to the webserver to fetch and transmit the requested web page. It is useful to understand how HTTP and TCP work, since web browsers have improved on the time to load web pages over the years. Different browsers handle TCP and HTTP connections differently to load web pages. A TCP connection must be established before any HTTP messages can be sent to start loading a web page onto a web browser. Below describes how a TCP connection works.
A user can open a TCP/IP connection to a server by typing in the URL in the address bar of the web browser. The browser then extracts the server’s host name from the URL (e.g. https://www.google.com). Next, the browser looks up the IP address for the hostname (DNS) and the browser gets the port number. At this point, the browser establishes a TCP connection with the webserver (74.125.239.52 port 80) and sends an HTTP GET Request message to the server. The web server sends an HTTP response back to the browser. Lastly, the browser closes the connection and displays the website.
A close look at the TCP connection shows the TCP sets a special flag each time it responds back. This process is called a TCP Connection Handshake, and involves three steps:
- Client Requests TCP connection: The user sends a small TCP packet (usually 40-60 bytes) to the web server. This packet has a special “SYN” flag set which indicates a connection request.
- Server Accepts TCP connection: If the web server accepts the connection, it sends a TCP packet back to the user with both the “SYN” & “ACK” flags set, meaning it acknowledges that it received the initial “SYN” flag set.
- TCP connection Established: The user receives both “SYN” & “ACK” flags and sends an acknowledgment “ACK” back to the server to complete the connection.
Each TCP flag set contains a sequence number and data-integrity checksum. The receiver of each flag set returns small acknowledgment packets back to the sender when segments have been received intact. If a sender does not receive an acknowledgment within a specified window of time, the sender concludes the packet was destroyed or corrupted. The sender then re-sends the data.
Next, we're going to look at how HTTP interacts during TCP connection.
HTTP Connection
HTTP allows a chain of intermediaries between the user and the webserver. HTTP messages are forwarded, hop by hop from the client, through intermediary devices, to the webserver. HTTP manipulates and optimizes connections for web browsers. The user’s web browser sends an HTTP request header that contains type, version and capabilities of the browser making the request so the webserver returns compatible data as HTTP response header and closes the connection unless there are any instructions.
For example, in the HTTP request, a request is made for an HTML file (typically it contains references to other resources such as images, scripts, stylesheets etc) that must also be loaded in order to fully display the web page. For each resource, the browser must typically repeat many of the previous steps in order to download the resources needed.
To keep the connection open, in the HTTP header request, you can include Keep Alive connection and setup a time to keep the connection open for, at most, 5 more transactions. It must send with all the messages you want to continue the persistence. It closes if there is no included Keep-Alive or the time has been maxed out.
To load all the files to display a whole page, many of the operations must be performed serially from establishing a TCP connection from the beginning (obtaining the IP address using DNS lookup). If there are any delays in any of the steps, it can significantly increase the load time of the web page.
Currently, most modern web browsers will open up to 6 connections per domain name and have 7 domain names per site. With this number of connections, web browsers will need to implement techniques to load the web page faster.
With the HTTP 1.0 browser, you can include Keep-Alive Connection in the HTTP request and set up a time to keep the connection open for, at most, 5 more transactions. It must be sent with all messages in which the persistence is to be kept. It closes when there is no included Keep-Alive or the time has been maxed out.
HTTP/1.1 replaced keep-alive connections to Persistent Connections which are active by default. HTTP/1.1 assumes all connections are persistent and open unless otherwise indicated. Note that not sending Connection: close does not mean the server promises to keep the connection open forever.
In addition, HTTP/1.1 permits optionally another request called Pipelined Connections. Multiple connections, multiple requests can be en-queued before the responses arrive. In a high latency network condition, this helps to reduce the number of network round trips. To close a connection in this type of setting, it is important to use a half close to avoid getting unexpected write errors. Generally, it is safer to close the output channel of your connection since you’re the one sending requests. If you half-close the input channel, you may not know if there is more data to be sent to you. If you close before the data was supposed to be sent, the operating system will issue a TCP “connection reset by peer.” Usually, this error message will cause to erase any buffered data the other side has not read yet.
Mobile Browser Connection
When using a mobile phone to look up web pages, the connection method is the same as using the standard HTTP over TCP/IP connection from a cellular network or wireless LAN. Usually, it takes 1 to 2 seconds to connect to the cell tower. When the web page is actively loading, the radio link is at max power consumption and bandwidth. However, after the radio link is idle for 5 seconds, it cuts down the power consumption in half. From the idle state, it takes 2 seconds to reconnect to the cell tower. Luckily, most of the mobile browsers offer 6 HTTP connections which can be parallel connected for faster loading time.
Here is the table which shows the results from Browserscope:
For example, Android browsers use Chromium’s network stack, the TCP connection’s Keep Alive is set at a 45-second interval to prevent time outs. At the same time, it uses SPDY Ping Frame to detect and close any dead connections and retry the requests over a new connection.
Other articles in this series: