HyperText Transfer Protocol — HTTP

What is HTTP?

• HTTP is one many other protocols at the application layer of the OSI model that defines a standard form of data transfer from one source to another.
• Below is the image of the OSI model, our focus is on the TCP/IP model at the application layer, where we have protocols that the internet uses to communicate or transfer data across different ‘machines’.

network model layer

• as seen from above, HTTP is just one of many other protocols used to transfer data at the application layer level. others like FTP that focus on file transfer, DHCP, exist and are used in different cases. For this blog, we focus on HTTP.
• the world wide web was introduced to the public in early 1990. Basically. it was this new ability to have different ‘machines’ communicate with each other: (communicating meaning exchanging data across an established connection).
• the need to have a standard way of communicating between different machines led to the implementation of data transfer protocol that all communications across the web had to follow.
• the Internet Engineering Task Force formulated guidelines on how to effectively share data using this specific protocol: HTTP — HyperText Transfer Protocol.

How does HTTP work?

• in this protocol, there are two points; one having the source of data to transfer, and the other being the source in need of the data; formally identified as a client and server respectively. Generally, the client requests for data and the server responds with the requested data.
• but for any kind of data to be transferred, there has to be a connection established between the server (serves data) and the client (needs the data).

Establishing Connection:

• server has a unique address referred to as the IP address, and specific port for listening at for any incoming requests. Once the server has its IP address and Port identified, it can then have that information shared with any clients that may need any kind of data from this specific server.
• once the client has the IP & port for the server, a connection is established between the client and server. therefore the exchange of data between the server and client can begin.

Data Exchange

• the protocol defines two key types that the client and server can use when communicating, and these are; request and response types.
• a client, in this case, sends a request to the server, and the server replies with a response Below is the breakdown of the two types.
• for a server to respond appropriately, a client needs to send a request with all necessary fields. here’s an example of what arequest looks like as from a mozilla.org site:

fig 1.0 an http request

a request type has:
1. method: this defines the kind the clients wants from the server. examples of methods include: GET, POST, PUT… etc. for example a GET request fetches data from the server, while a POST request inserts or sends data to a server.

2. path: this specifies the location for what data is needed. for example, a path /teams/arsenal.php would be looking a team called arsenal

3. version: this specifies what version of the protocol the client is using. HTTP/1.0 was the first version. HTTP/1.1 has been the standard version for a while now. and HTTP/2.0 is the most recent version.

4. headers: these contain most of the important information about the server and the expectations of each for the other. there are different types of headers each of which has a specific purpose. from the above fig 1.0, Host: developer.mozilla.org is a header that tells information about the host. a header is defined as a Key: value pair. click here for other types of headers.

5: body: some requests like a POST request have a body or sometimes referred to as a payload. for example, a form type with fields once submitted sends a POST request with a body that contains parameters or key-value pairs for the fields in the form. fig 1.1 below is an example of a POSTrequest with a payload that contains “say=Hi&to=Mom” on line 6.

Fig 1.1 POST request with payload

notice: line 5 shows separation between the headers and start of the body for the request. its standard protocol for requests to have the blank line.

• once a server receives this a request , the protocol expects the server to respond with a response type that looks like below fig 2.0

fig 2.0 http response

a response type has:

1. status code: the protocol has a list of specific code each with its own meaning. in fig 2.0 the code 200 implies the request was successful, here is a list of all other codes and their meaning.
2. status message: each code has appropriate human-readable text that offers a brief description of what the code means. in case of fig 2.0 the message displayed OK corresponds or describes what the code 200means.
3. version: this same as in the request, it helps what version of the protocol the server is using.
4. headers: this also is the same with key-value pairs. and since most responses have bodies, the header type for content-length and content-type normally shows the quantity of data sent back and in what format… respectively.
5. body: this is one of the most important parts of a response . the body contains the details of what the client was requesting. for example if the request was GET /country/list_of_states , this would return a response with a payload or body containing all the states that were requested for that specific country. fig 2.1 below shows a brief description of a response with a body.

fig 2.1 http response with a body

Note:

• in this protocol, request-response cycles are stateless, meaning every request made is absolutely independent of the previous or next ones made to a specific server. this issue is often managed by using cookie sessions, that are defined with the header of a request and/or response. once a request the contains the cookie header type: it notifies the server to keep specific data the would be used in the next request-response cycle for that specific server, thus preserving the state for that server-client connection.
• etags as part of the header are useful in keeping state as well, set by the client to indicate whether the resource hasn’t changed since the last request, thus allowing the client to make conditional requests.

In summary

• the above describes a good summary of how the http protocol works,
  set an address, establish a connection and then let communication and data transfer occur between a client and server using requests and responses cycles.
• it’s important to note that a server can serve several clients, but that introduces concepts of load balancing on the server side that is definitely out of scope for this topic.