The Mechanics of HTTP

HTTP (Hypertext Transfer Protocol) enables the browser and the website (server) to communicate. The HTTP Protocol itself is stateless.

For any communication to take place, there are 4 critical things at play :

-> Sender (Browser)
-> Receiver (Remote Server)
-> Medium &  Transportation (Provided by TCP/IP) More on TCP/IP HERE
-> Actual Message (THE HTTP REQUEST & RESPONSE)

A minimal HTTP Request has 2 lines

HTTP_VERB PATH HTTP_VERSION
Host : xyz.com

The HTTP Verb refers the Method of the request like "GET, POST, HEAD, DELETE, OPTIONS" etc.
The Hosts header refers to the hostname of the target server.

There can be other headers in the request which in turn can be standard headers like User-Agent or a Custom header. Irrespective of the type of header, the format will be similar to the host header. Key Value pair separated by a colon.

The first line of server response if of the following format:

HTTP_VERSION   STATUS_CODE   TEXT_VERSION_OF_THE_STATUS_CODE

The stateful Web Applications work with cookies or custom headers. A Set-Cookie Header is sent from the Server in the HTTP Response

HTTP/1.1 200 OK
Date: Sat, 16 Mar 2019 12:50:41 GMT
Set-Cookie : JSESSIONID=313373133731337

This makes the browser save the cookie, and include it in the subsequent requests.

More on other attributes of Cookies here.

HTTPS

HTTPS is HTTP over TLS, meaning the HTTP Request and the HTTP Response is encrypted and others on the network can not see the data in transit. This helps in multiple ways including protecting private data like credit card information from prying eyes as well as protecting the end user against response tampering.

In case of WiFi, we have a symmetric key or same key. We plug in the same password on the router as well as our devices. However, in case of the Internet We can not directly configure the other end. Here we need a way to exchange the secret password or encryption key securely without letting others know about it. This is where asymmetric cryptography comes into picture. We use asymmetric cryptography to share the common password.

Using Asymmetric encryption, when a client(browser) wants to securely communicate with a server (website), the browser tells the server that it wants to communicate and the server sends the public key of the server. The browser generates a secret-password and encrypts it using the public key of the server. Due to the mathematical properties of the asymmetric cryptography algorithm, the generated cipher text can only be decrypted with the public key of the server. Now this encrypted secret-password is sent to the server and it decrypts the key. Now both ends have the same key and the communicated between them is secure.

One question which might pop in your mind is, why not encrypt the whole of HTTP communication with asymmetric cryptography? That is because there is a overhead involved with asymmetric cryptography, so it is feasible to use symmetric cryptography for the rest of the session.