Watch the full YouTube video here
HTTP and Web Sockets are two protocols that we regularly use as a developer. In this blog, let's understand and compare both.
What is HTTP protocol?
For beginners, HTTP stands for HyperText Transfer Protocol. It is a protocol that allows the fetching of resources, such as HTML documents. It is the foundation of any data exchange on the Web, and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. ‌
More on HTTP here
How HTTP works?
So when you want to visit google.com and type the URL in the address bar, the HTTP first establishes a TCP Connection to Google's Server.
TCP is the fourth layer protocol as per the Open Systems Interconnection Model (OSI Model). OSI Model is how we depict the network model.
TCP is a connection-oriented and reliable full-duplex protocol supporting a pair of byte streams, one for each direction. Before exchanging data, a TCP connection must be established. The TCP connection is established by performing TCP Handshake. After the handshake is done, the client (i.e. your computer) sends a GET request inside a TCP Packet to Google's Server asking the HTML Document and the required resources to show the Google Homepage to you.
HTTP is a single way communication. The client requests and the server responds or vice versa, whereas TCP communication is two ways. Here the client and the server can speak simultaneously. That is it. That's all that HTTP does.
HTTP is a stateless protocol
As we move up the OSI Model stack, you might wonder why HTTP does not have a two-way response like TCP. You might have just found out the reason. Yes, HTTP is a stateless protocol that means an HTTP server need not keep track of any state information. So, at any time, a client can send any valid command. The server will not relate this command to any previous or future commands.
You might be wondering what good does this do to us. How is it beneficial to the client or the server? As HTTP is a stateless protocol, it always has to send request headers with HTTP requests. Because of this, the server architecture becomes highly scalable because many servers can respond to far many clients and share the load of requests between them.
How do Web Sockets work?
However, Web Sockets works differently when compared to HTTP. Web Sockets works somewhat similar to how TCP works on the grounds of dual communication. Like HTTP, Web Sockets also work with the help of TCP. When the client first sends a Web Socket request, it sends an HTTP request and asks the server if the connection can be upgraded to Web Socket.
‌If the server accepts the request, then only the HTTP connection is upgraded to Web Socket. Now the dual channel is established between the client and the server.
Difference between HTTP & Web Sockets
Web Sockets are like a phone call. Once established, data can be shared either way. While in HTTP, it is more like sharing letters between each other, and when the server replies with its letter, the connection ends. To request it again, a new connection must be established before data can be shared or requested. Here HTTP is like a one-time transaction.
Scalability Problem
While using the Web Sockets, if the client sends, e.g., 10,000 requests to the server at a particular point in time, the server may not process all the requests as Web Sockets are stateful in nature. HTTP requests are stateless, so their sent requests can be processed by multiple servers and sent back faster when compared to Web Sockets here.
Web Sockets is a stateful connection
As mentioned earlier, Web Sockets are stateful in nature. They don't need to establish the connection before responding or requesting. So Web Sockets always has to maintain a state to determine the requests and responses stream. While this makes the mutual transfer of data seamless, sheer amounts of data cannot be transferred at a particular time. So while using web sockets, the server cannot be scaled horizontally. As a result, it can only process a certain amount of requests. While web sockets have the advantage of seamless transaction data, it comes at the cost of scalability.
This scalability problem can be partly addressed with the help of AWS API Gateway.
Conclusion
Web Sockets and HTTP come with both advantages and disadvantages of their own. ‌
‌Web Sockets are mostly used when setting up a stream, video chat, and other messaging and constant communication tasks. While HTTP is used to manage the sheer amount of requests.
Hope you were finally able to understand the difference between the two. By now, you'll know abstract working and use cases of both HTTP and Web Sockets.
Top comments (0)