Before jumping into networking infrastructure, it’s essential to understand how services like the web run. One of the most significant concepts is how HTTP works in a client-server model.
So what is this client-server model?
When we talk about the web, there are clients and servers. Any web server sends responses to clients who have requested things. Clients can be computers, bots, and programs.
HTTP is the foundation of all of this. HTTP is a stateless protocol (but it rides on stateful protocols like TCP). HTTP is text-based, which means it can also be effortless. We can also see all of the data we transfer if we do something like a packet capture in our network with Wireshark.
The Client-Server Header Exchange
First, the client sends a request to the server. The right is known as “GET”. The path requested is shown, which is the URI. Finally, the HTTP version is in the client HTTP request.
Get us just one of many methods used by HTTP. There are others like POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. These all do different things. The post is used for sending data. Delete is… well, for deleting.
Anyway, the server then sends an HTTP response with the protocol version and status code message, usually 200/ok. Within the response, we have the requested material, the HTTP page; usually, there’s HTML in there.
Other status codes for HTTP are:
2xx – SUCCESS
3xx – REDIRECT (301 and 302 are very common)
4xx – CLIENT ERROR
5xx- SERVER ERROR (504 is very common)
Websites that configure URL shortening use 3xx HTTP responses, usually 302. This then forces the client to perform a secondary request, written in the HTTP payload, to the server.
Another example is if a client sends a bad request with missing data or broken data, then the server would answer with a 400 BAD request.
Back to the header information. Headers also allow client and servers to include other important information. Request and responders can both include HTTP headers to change the type of data sent. For example a request can change the URI path, hostname, user-agent, accepting content type, and accepting encoding (compressed gzip).
The response from the server can include additional information in the headers. The status code, server type, content-type, and content-length. Then of course the actual HTTP body, and that’s just touching the surface!
That’s the basic model of the HTTP client-server request-response.