What are WebSockets? How is it different from HTTP?
Summary
TLDRThis video script provides an insightful comparison between the HTTP and WebSocket protocols, two widely used internet protocols. The host, Mehul, begins by introducing HTTP, explaining how it establishes a TCP connection between the client and server to facilitate data transfer in a single direction. He then contrasts this with WebSockets, which enable bidirectional communication, allowing both client and server to exchange data seamlessly. The script highlights the stateless nature of HTTP, making it suitable for horizontal scaling, while WebSockets maintain a stateful connection, potentially limiting scalability. However, solutions like AWS API Gateway are mentioned as a way to address this issue. Overall, the script aims to help viewers understand the fundamental differences between these protocols and their respective strengths and use cases.
Takeaways
- 📡 HTTP (Hypertext Transfer Protocol) is the primary protocol used for browsing the internet, including websites like Google and Facebook.
- 📈 HTTP is stateless, meaning each request from a client to a server must include all necessary information, allowing for easier scalability and horizontal scaling.
- 📯 TCP (Transmission Control Protocol) establishes a duplex (two-way) connection between the client and server, forming the basis for HTTP communication.
- 💻 WebSockets provide a two-way communication channel over a single TCP connection, allowing for real-time data exchange between the client and server.
- 📊 WebSockets start with an HTTP request to upgrade the connection, transitioning from a stateless to a stateful connection, enabling continuous data flow.
- 🗣️ The duplex nature of WebSockets allows both the client and server to send data at any time, similar to a phone call, unlike the request-response model of HTTP.
- 🔧 WebSockets are inherently faster and more efficient for real-time applications because they eliminate the overhead of repeatedly establishing connections.
- 🛠 WebSockets face scalability challenges due to their long-lived, stateful connections, which bind clients to specific servers.
- 📚 Solutions like AWS API Gateway offer ways to address scalability issues with WebSockets, enabling the use of multiple servers to manage connections.
- 📌 Both HTTP and WebSockets have their pros and cons, and the choice between them depends on the specific needs of the application.
Q & A
What is the primary function of the HTTP protocol on the internet?
-HTTP is used for browsing websites and transferring data over the internet, which includes accessing web pages that start with HTTP or HTTPS.
How does the TCP connection relate to HTTP communication?
-After DNS resolution, the browser establishes a TCP connection between the user's computer and the server. This duplex connection is foundational for HTTP communication, facilitating the exchange of requests and responses.
Why is HTTP considered a stateless protocol?
-HTTP is considered stateless because it doesn't maintain any information about previous requests. Each request is treated independently, requiring all necessary data to be sent with each request.
How does HTTP's stateless nature benefit scalability?
-The stateless nature of HTTP simplifies horizontal scaling by allowing multiple servers to handle requests independently, without needing to maintain state information about clients.
What makes WebSockets different from HTTP?
-WebSockets allow for a two-way communication channel between the client and server, akin to a phone call, enabling both parties to send messages at any time without establishing new connections for each exchange.
How are WebSockets initiated over the TCP/IP stack?
-WebSockets start with an HTTP request to upgrade the connection to a WebSocket. Once the server agrees, the connection is upgraded, allowing for a persistent, two-way communication channel.
What are the implications of WebSockets being stateful?
-Because WebSockets maintain a stateful connection, they do not inherently support horizontal scaling as easily as HTTP does. A single server must manage the connection for each client, which can limit scalability.
Why might HTTP be considered slower than WebSockets?
-HTTP can be slower because each request and response includes overhead, such as HTTP headers, and requires establishing a new connection each time, whereas WebSockets maintain a continuous connection, reducing overhead.
How do WebSockets achieve scalability despite being stateful?
-Solutions like AWS API Gateway help address scalability challenges with WebSockets by managing connections and distributing messages, thus enabling scalable real-time applications.
What is the significance of HTTP's request-response pattern?
-HTTP's request-response pattern is designed for single-direction communication, where the client sends a request and the server responds, making it well-suited for traditional web applications.
Outlines
🌐 HTTP vs WebSocket: A Primer on Internet Protocols
In this video, the host introduces the topic of HTTP and WebSocket protocols, explaining how HTTP is used for browsing websites and how it establishes a TCP connection between the client and server. The client sends a GET request with headers, and the server responds with the requested document, closing the connection afterwards. HTTP is stateless, meaning the client must include all necessary headers like cookies and authentication for each request. This statelessness enables horizontal scaling with multiple servers handling requests. In contrast, WebSockets establish a persistent, dual-channel connection upgraded from an initial HTTP request. This allows bidirectional communication, similar to a phone call, but sacrifices the scalability advantages of stateless HTTP.
⚖️ The Trade-offs: WebSocket Scalability and Performance
The video continues by contrasting the differences between HTTP and WebSockets. While HTTP is like sending a letter and closing the connection after each transaction, WebSockets maintain a stateful, long-running connection akin to a phone call. This statefulness means the client doesn't need to re-authenticate for every message, but it also limits horizontal scalability as a single server must handle all messages from a client. However, solutions like AWS API Gateway can help address scaling issues with WebSockets. The video also notes that WebSockets are generally faster than HTTP since they don't transfer as much data per message. Ultimately, the choice depends on the specific use case: HTTP is stateless and scales better, while WebSockets offer persistent, low-latency communication at the cost of reduced scalability.
Mindmap
Keywords
💡HTTP
💡WebSocket
💡TCP
💡Stateless
💡Stateful
💡Scalability
💡Horizontal Scaling
💡Real-time Communication
💡DNS Resolution
💡Headers
Highlights
HTTP is the protocol used for browsing websites, starting with http or https.
When you enter a website URL, the browser establishes a TCP connection with the server after DNS resolution.
HTTP communication is one-way, with either the client sending a request or the server responding.
HTTP is stateless, requiring the client to specify headers like cookies and authentication for each request.
The stateless nature of HTTP simplifies horizontal scaling by allowing multiple servers to handle requests.
WebSockets operate like TCP, with dual communication between the client and server.
WebSockets establish a long-running, stateful connection after an initial HTTP upgrade request.
WebSockets allow both the client and server to send messages at any time, unlike the one-way nature of HTTP.
The stateful connection in WebSockets makes horizontal scaling more challenging as a single server handles a client.
Solutions like AWS API Gateway can address scalability issues with WebSockets.
HTTP is slower than WebSockets due to the overhead of transferring data with each request.
WebSockets are faster due to the long-living connection, but HTTP and WebSockets have different use cases.
The choice between HTTP and WebSockets depends on the specific requirements of the application.
The video aims to provide an understanding of the differences between HTTP and WebSockets.
The video encourages viewers to like, subscribe, and provide feedback in the comments.
Transcripts
hey everyone welcome back my name is
mehul and in this video we'll be taking
a look at http vs websocket very two
popular protocols which you use on the
internet all the time without realizing
also if you're new here make sure you
like and subscribe to the channel i'm
creating a lot of interactive and
awesome content here at goddamn and even
at codedam.com platform so if you want
to stay in touch make sure you subscribe
and hit the bell icon let's go so http
is the protocol which you always use
when you're browsing websites like
google facebook code damn code dumps
learning path and basically anything
which you browse on the internet which
starts with http or https that is done
using http protocol so let's see what
exactly happens when you write
google.com and press enter
on the http front it's not on the dns
front on the http front so
when you write http google.com what
happens is that the first thing which
your browser does is that it establishes
after the dns resolution and the ip
address has been figured out is that it
establishes a tcp connection between
your computer which you have here and
the server which is owned by google
right so this tcp connection is also
called as layer 4 protocol the tcp
protocol is called layer 4 in the osi
model and these are just some layers of
how the networking stack works physical
layer then you know it goes on top and
top and there are more and more
abstractions we are not going to get
into that but what you have to
understand is that this connection is
duplex so tcp connection is duplex and
after some handshakes once it's
established then what http does is that
http in this case
your computer right here
says the standard things which you see
get
slash and you know this is the path for
example get slash abc and then the http
headers and this is sent to your server
your server receives this part inside of
tcp packet and responds with the correct
document and that is it that is all http
does right it just does this part
particular communication and then closes
off so what http does is that it only
allows communication in a single
direction so either the client speaks
and the server response or the server
speaks and the client response tcp on
the other hand is inherently a two-way
communication where both client and
server can speak at the same time now
you might think that why is that
limitation for http it seems like a
limitation right if you're going up the
stack and you're kind of like losing the
access to the to the functionality of
both the people talking to each other
there's a good reason for this this is
because http as a protocol is stateless
so this protocol is stateless that means
every single time every single time
if client wants to send something to the
server the client has to specify all the
headers that is the cookie header the
authentication header whatever headers
it wants and it has to send all of them
to the server why this is a good thing
because this allows http to stay
stateless that means you can have
multiple servers at the back end
handling different requests right so it
simplifies your architecture of scaling
a lot horizontal scaling a lot right
because now you can have a million
clients here requesting the same page
and this all the backend has to do is
add more servers in order to serve these
individual requests why because after
every single http request that http
connection gets closed tcp connection is
open if you have a keeper live header
but let's just assume for the sake of
simplicity that this connection gets
closed and the next time the next
request arrives the next request is made
by the client this connection
might establish to some other server
right and because this is stateless the
other server exactly knows what the
client wants websockets however behave
in a slightly different way because they
actually operate much more like
how tcp works in terms of dual
communication so of course websockets
also works on tcp layer 4 communication
layer 4 protocol and on top of this
sometimes what you will see is that the
initial request which the server sends
is an http request to a websocket
endpoint the client sends this request
the server says that hey
we can have a connection
upgraded to websocket it also asks like
can the connection be upgraded to
websocket it says yep i can upgrade that
connection to websocket and once that is
done this connection is it's not exactly
dropped but it's upgraded to our
websocket connection and this websocket
connection right here is awesome why
because this actually is a dual channel
established between the client and the
server so how you can imagine this you
can imagine this in the following way
that this
has
actually called you know i'm just trying
to draw a simple mobile phone this has
actually called this
server right here so both of them are
now on a phone call where they pretty
much can say whatever they want to each
other
any time of the day how does this differ
from pc uh from your http that differs
in the sense that your http connection
is more like sending a letter which
probably the symbols would for later
also would seem seem the same but i'm
just writing an l here so you send a
letter once then the server reads it
then the server responds with another
letter and that's it the connection then
closes right for the next time the
client has to again initiate the
connection or the server can as well if
it knows the ip then in that case server
becomes the client but you get the idea
so this is just like a one-time
transaction which is happening here but
a major fault which you will observe
here is that we lose that scalability
aspect which we talked in the last video
right because now if this client starts
sending a thousand messages then only
this server has to handle it why because
they are on a phone call right so it
cannot really drop the connection
because if it do that then it pretty
much will
you know just drop the connection here
and the client will see that hey the
connection has been lost and the state
has been lost for the most part because
because this is a single connection now
this connection is stateful that means
it's not that on every single message
this client has to tell who the client
is right that authentication phase only
happens when there is a handshake going
on for the very first time after the
handshake is complete
this is a stateful connection to put
this thing in another way your client
establishes a tcp connection once that
is established then your client
establishes an http connection and tries
to upgrade the socket to upgrade the
connection to websocket once that has
happened then this connection is
upgraded to a stateful connection right
here right now it can send some messages
it can send some messages at any single
time this has the drawback that you
cannot use multiple servers to handle
multiple messages because this channel
is already established and it's long
running right this problem does not
happen in case of http because you can
have multiple servers and all it is
doing is just handling this one single
request and that's it then it's closed
then for the next request another
channel opens up right and then that
happens so it seems like websockets is
fundamentally not horizontally scalable
because you will always have this
problem where a server is stuck with a
client right and that is partly true but
there are very interesting solutions
like aws api gateway which allows you to
address certain problems and we will
definitely see how we can scale
websocket connections in some further
videos but i hope this gave you an
understanding of how websockets differ
from http there are some obvious
differences as well for example http is
definitely slower because you are
transferring a lot more data in every
single request compared to websockets
websockets are long living therefore
they are obviously faster as well
because it's like on a phone call this
is more like
sending a letter or maybe like you know
just giving a ring and then or sending a
text message for example but yeah i mean
both have their own pros and cons right
so it's it's not like one is perfect for
a single job it depends on what you want
to do so yeah that's pretty much it for
websockets versus http let me know in
the comments what you think about this
video and this video format in general i
hope this video was able to provide you
some value if it did make sure you like
and subscribe thank you so much for
watching and i'm gonna see you in the
next video
[Music]
you
Ver Más Videos Relacionados
![](https://i.ytimg.com/vi/sUEq35F-ELY/hq720.jpg)
Polling vs WebSockets vs Socket.IO (Simple Explanation) - Chat App Part11
![](https://i.ytimg.com/vi/zh-S5M_7LXs/hq720.jpg)
[HINDI] Networking Basics | Part #54 | Application Layer | File Transfer Protocol (FTP)
![](https://i.ytimg.com/vi/uwoD5YsGACg/hq720.jpg)
TCP vs UDP Comparison
![](https://i.ytimg.com/vi/MB46hfk9bLw/hqdefault.jpg?sqp=-oaymwEXCJADEOABSFryq4qpAwkIARUAAIhCGAE=&rs=AOn4CLArBIVZrmP7_BFHZ2atDiovgMm4fg)
Understanding Protocols, Ports and Sockets | Intro to Computer Networks Course Preview
![](https://i.ytimg.com/vi/i53Gi_K3o7I/hq720.jpg)
20 System Design Concepts Explained in 10 Minutes
![](https://i.ytimg.com/vi/Bz5S86jmXQQ/hq720.jpg?v=6064580e)
Asp.Net Core Web API Client/Server Application | Visual Studio 2019
5.0 / 5 (0 votes)