Difference Between TCP/IP Socket and WebSocket

TCP/IP sockets and WebSockets both facilitate communication via IP and port numbers and share the characteristic of supporting bidirectional communication.

The differences are as follows:
WebSocket operates on the HTTP layer, whereas TCP/IP sockets operate on a different layer. So, the two concepts are fundamentally distinct and should not be confused.

WebSocket

WebSocket is a technology developed to address the issue of real-time communication in HTTP! Let's briefly examine the characteristics of HTTP, which led to the development of WebSocket.

HTTP Cannot Provide Real-time Communication

To understand the background of WebSocket, we need to look at the characteristics of HTTP.

• Statelessness (Unidirectional)
• Cost of establishing and terminating connections each time
• Request-response structure
• Heavyweight headers -> In cases where a large volume of data needs to be exchanged in real-time, this becomes a significant burden.

HTTP has these characteristics. In other words, due to its unidirectional request-response communication structure, similar to TCP/IP protocol-based sockets where the connection is continually maintained, it cannot perform real-time communication. WebSocket protocol was developed to address this issue.

WebSocket Provides Real-time Communication

• Connection-oriented (Bidirectional)
• Maintains the connection once established
• While the handshake process involves significant header overhead, once the connection is established, only simple messages are exchanged, making it very economical

WebSocket allows real-time communication with these characteristics. WebSocket isn't a replacement for HTTP; it's just one of the protocols commonly used for real-time communication on the web. As mentioned earlier, because it's called WebSocket, it operates on top of the HTTP layer.

When Exactly to Use WebSocket?

It's obvious but used in situations requiring real-time communication. For example:

case 1 | In gaming, where refreshing every time another player takes an action would be very inconvenient
case 2 | During chatting sessions

WebSocket Operation Method

1. First, Shake Hands 🤝 (Handshaking)! An automated negotiation process that dynamically sets variables for an established communication channel between two entities before normal communication on the channel begins

2. Now, let's structure the frame for data insertion! Frame Composition

Since the handshake occurs only during the initial connection over the HTTP protocol, we use HTTP headers.

There's no separate port for WebSocket; it utilizes existing ports (HTTP - 80, HTTPS - 443) to ensure compatibility.

Communication occurs through logical units called frames, which are part of the message exchange.

The exchangeable message types (frames) that can be included in a message are limited to text and binary!

Limitations of WebSocket

WebSocket emerged after HTML5. What if you need to implement services using technologies predating HTML5?

1. Socket.io, SockJS

Socket.io and SockJS are technologies that enable real-time communication similar to WebSocket in services implemented using pre-HTML5 technologies. They facilitate real-time communication.

Ultimately, by identifying the types and versions of browsers and web servers, you can select the most suitable technology to mimic WebSocket functionality!

1. STOMP

WebSocket merely facilitates the exchange of strings and doesn't handle anything beyond that. The interpretation of the exchanged strings is entirely left to the application.
HTTP, on the other hand, is interpretable as it has predefined formats, provided everyone adheres to the agreed-upon conventions. However, WebSocket often employs sub-protocols to specify the format of the messages being exchanged.
One commonly used sub-protocol is STOMP.

STOMP

Similar with Web Socket

Before WebSocket, there were various methods for achieving real-time communication using HTTP.

1. HTTP Polling

Periodically sending requests to the server.

Polling: Checking the state of another program periodically for purposes such as collision avoidance or synchronization, and performing data processing when certain conditions are met.

In real-time communication, it's impossible to predict when communication will occur.

Creates unnecessary requests and connections.

Results in unnecessary waiting time between events since requests are made even when there are no events. This introduces a gap between the event occurrence and receiving the response, leading to ambiguous real-time communication.

1. HTTP Long-Polling Sending a request to the server and keeping the connection open until an event occurs. Upon receiving a response, the connection is closed, and a new request is made.

Long-polling: The client asks the web server if there is any new content. The web server does not respond until new content is available.

Eliminates unnecessary requests (partially addressing the drawback of polling).

Ultimately behaves similarly to polling when a large volume of messages is sent.

1. HTTP Streaming Sending continuous data without closing the connection after sending a request to the server.

It's difficult for the client to send data to the server.

However...

All of these methods use HTTP for communication, which means both the request and response headers are unnecessarily large (a bottleneck when exchanging data quickly).

But... why is HTTP unidirectional communication?

While summarizing this information, I couldn't clearly understand the difference between HTTP, a web protocol, and TCP. This is because HTTP is fundamentally designed to operate on top of TCP/IP. However, when setting up a TCP server using sockets for real-time communication, why does applying the HTTP protocol result in unidirectional communication? I was puzzled by this question. HTTP's characteristics do indeed include unidirectional communication... but why can't a protocol originally based on TCP provide real-time communication?

Why does HTTP, which is built on top of TCP/IP, behave unidirectionally?

After some research, I concluded that it depends on the perspective.

HTTP is built on top of TCP, meaning it exists as a protocol layered on top of TCP, using sockets as endpoints. Despite numerous articles discussing "HTTP vs. socket," HTTP is essentially a protocol that utilizes socket communication. Therefore, HTTP can be considered a method of communication using sockets.

However, communication involves layers. HTTP and sockets are different protocols that operate on different layers. While TCP/IP-based socket communication (TCP communication) starts from the 4th layer, where packets are generated, HTTP communication starts from the 7th layer, where packets are also generated.

Therefore, from the perspective of the 4th layer, both operate as connection-oriented communication. From the perspective of the 7th layer, HTTP is non-connection-oriented, while socket communication is connection-oriented.