#2 System Design: Web Protocols

Welcome to the second series of System Design

HTTP and HTTPS

It is a request response application layer protocol designed to connect web traffic through hyper links. It's a widely used protocol by almost everything connected to the internet.

1. POST - Create
2. PUT - Update
3. GET - Read
4. DELETE - Delete.. there's more

The above set of CURD operations leveraged under the idea RESTful API's is very popular and is the backbone or the "glue" to connect micro services.

1. HTTP default port 80

2. HTTPS default port is 443

3. Anytime, you wanted to go shopping or book a flight travel or just browse around watch out for the secure sites https:// the ones that has the green pad lock on

   

4. HTTP is still in use, but it's been largely replaced by HTTPS (Hypertext Transport Protocol Secure), which serves the same purpose but with much better security features.

5. In 2014, Google announced that it would give HTTPS sites a bump in rankings.

6. That, combined with the increasing need for encrypted data transmission, resulted in much of the web over migrating to HTTPS.

TLS Handshake Procedure

HTTPS works on top of TLS (Transport Layer Security) by default.

TLS is a protocol used to encrypt communications in the transport layer, preventing unauthorized entities from listening in on communications. The process for initiating a secure session through TLS is called a TLS handshake. Here's what it looks like.

• The client requests to establish a secure connection with a server, usually by using port 443 which is reserved for TLS connections.

• The client and server agree to use a particular cipher suite (ciphers and hash functions.)

• The server submits a digital certificate which serves as proof of identity. Digital certificates are issued by 3rd party Certificate Authorities (CAs) and effectively vouch for the server.

• If the certificate is accepted by the client, the client will generate a session key which is used to encrypt any information transmitted during the session.That's how we can see the green pad lock on the browser to confirm website's authenticity.

• Once the session key is created, the handshake is finished and the session begins. All data transmitted will now be encrypted.

Web Sockets

WebSocket is a communications protocol, providing full-duplex communication over a single TCP connection.

Real time applications include chats, live streaming, stocks etc

The client(browser) sends a HTTP GET request to the server and server responds with a code 101 to switch to websocket connection where bidirectional communications happen.

Keeping track of clients

Server must keep track of clients' sockets so you don't keep handshaking again with clients who have already completed the handshake. The same client IP address can try to connect multiple times. However, the server can deny them if they attempt too many connections in order to save itself from Denial-of-Service attacks.

WebSocket vs HTTP

Its a newer protocol designed to solve latency issues that arose with 'http' request response communications.

Unlike HTTP, where we sent constant requests to the server for updates, with websockets, updates are sent immediately when they are available.

HTTP was designed to be strictly unidirectional

• The client must always request data from the server, and only one HTTP request can be sent per session.

• Lots of modern applications require longer session times and/or continuous updates from the server.

• Long-polling, a technique that keeps client-server connections open longer, whenever there is an update on the server, push it asap to the client, without wanting the client to ask for it.. It helps, but it doesn't solve the problem, and it's very resource-intensive.

• The WebSocket protocol works similarly to HTTP, but with some improvements (and tradeoffs.) It allows servers to send data to clients in a standardized way without first receiving a request, and it allows for multiple messages to be passed back and forth over the same connection. It's fully compatible with HTTP (and HTTPS), and it's much less computationally demanding than polling.

There are some drawbacks to WebSocket as compared to HTTP, namely:

• WebSocket has no built-in, standardized API semantics like HTTP's status codes or request methods.

• Keeping communications open between each client and server is more resource-intensive and adds complexity.

• It's less widespread, so development can take longer.

• Most WebSocket use cases require real-time data.

• Consider WebSocket vs. HTTP for applications where updates are frequent, and up-to-date information is critical. Think messaging services, gaming, and trading platforms.

Summary:

• At the application layer, "Easy peasy lemon squeezy" you guessed it. Use HTTPS.

• If your application requires two way communications and updates more frequently as it happens on the server, go for websockets.

• If you're designing a service with an API, consider HTTP (HTTPS) over WebSocket as you'll be able to make use of HTTPs standardized request methods and status codes, very important if you're designing a RESTful API.

• At the transport layer, choose TCP or UDP to send package and send the data. TCP if situation demands data accuracy and UDP if rapid transmission is needed (remember the tradeoff here is that there will be errors eg: in a video streaming application