Learn the concepts underlying all WebSocket applications, including the WebSocket handshake, persistence, and communication patterns.

What Are WebSockets?

The main feature of a WebSocket connection is that they allow continuous and bidirectional communication between a server and a client. In addition to the client sending data to the server, the server can also send data directly to the client – and this can happen without interruption! 

For example, in the stock tracking application from the previous exercise, the server can continuously send the client the most up-to-date stock prices without the client requesting them.

In addition to enabling uninterrupted communication between a client and a server, WebSocket connections also enable a communication pattern called _broadcasting_.  Broadcasting is when a server sends the same message to many connected clients at once. 

In some cases, the server may send a broadcast message to all connected users but often the server will choose only a subset of clients to broadcast a message to, such as in a chatroom application. For example, when a client’s message is sent to the server, the server can broadcast the message to all other connected clients. If the application supports smaller chat rooms, the server can determine which room the "sender" is in, and broadcast their message only to the other clients in the same room. 

To summarize, WebSocket connections enable the three following communication patterns:
* client to server
* server to client
* server to many clients (broadcasting)

A client sends a post to the server. The server broadcasts the post out to multiple clients who can each respond with a "like". The server then sends a message to the original client with the updates to their post.

WebSocket Communication Patterns

Imagine that your favorite basketball team is playing but you can’t watch the game live. You're trying to follow the score on your phone but you can only get the live score by manually pressing a button to request new data. Needless to say, this isn't a great user experience. Not only is pressing a button to get the latest score annoying, each request will take some time to process meaning that the score may have already changed by the time you get a response!

This is how an application using an HTTP connection might work and demonstrates the problem that _WebSocket connections_ are here to solve. While plain old HTTP connections require the client to make a new request to the server in order to get new data, WebSocket connections require just a single request that establishes continuous, bidirectional communication enabling real-time updates of data shared between a client and a server. 

A WebSocket connection is the solution that allows you to track the score of a basketball game in real-time, send and receive instant messages in an online chatroom, and play fast-paced multiplayer video games in your browser.

This lesson covers the core concepts of WebSockets while the next lesson will cover building a WebSockets application. In this lesson, you will learn how WebSockets:

* Benefit specific kinds of applications
* Have various modes of communication
* Are built upon the foundation of an HTTP request
* Create a persistent connection
* Allow for bidirectional communication
* Are superior to earlier attempts to mimic real-time updates
* Are initiated with something called a “handshake”
* Can be made more secure using the `wss://` protocol and HTTPS

Before taking this course, make sure you are familiar with Node.js and the basics of HTTP connections between clients and servers. If you need to review Node.js, check out the corresponding [Learn Node.js course](https://www.codecademy.com/learn/learn-node-js).

The graph on the right shows a continuously growing line of data. The graph on the left shows data points appearing when the user clicks a button.

Intro: What Are WebSockets?

The wss protocol, like https, uses TLS to secure the TCP connection.

You may notice that some websites (including Codecademy.com) use the `https://` protocol at the beginning of the URI while others use `http://`. So what's the difference? 

[`https://` is the secure version of the `http://` protocol](https://en.wikipedia.org/wiki/HTTPS) and is encrypting using the Transport Layer Security (TLS) protocol. Using an HTTPS server instead of a basic HTTP server safeguards your users from malicious attacks, such as a [Man In The Middle Attack](https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#man-in-the-middle_mitm).

In the last exercise, we learned that during the WebSocket handshake a GET request is sent to the server using a `ws://` URI. Just like the `http://` protocol, `ws://` is an unencrypted protocol. So is there a more secure WebSocket protocol?

Yes! WebSocket connections can also use the TLS protocol to establish a more secure connection by using the `wss://` protocol (notice the extra `s`). Connections using the `wss://` protocol function just like `ws://` ones, except that the initial handshake takes place over HTTPS instead of HTTP. 

Secure WebSocket Connections

So far we've learned about the communication capabilities of WebSocket connections, the benefits of persistent connections, some details about how an HTTP connection can be upgraded to a WebSocket connection during the handshake process, and about secure WebSocket connections using `wss://`. As a final step, let's discuss the applications for which WebSockets can be most beneficial.

WebSockets are the go-to approach for applications that need real-time data. Before WebSockets, many web developers had to rely on abusing the HTTP protocol by repeatedly making HTTP requests in quick succession to simulate continuous streams of data. This resulted in excessive headers, [latency buildup](https://developer.mozilla.org/en-US/docs/Web/Performance/Understanding_latency), and difficulty tracking each client’s current state.

However, WebSockets aren't always the superior solution compared to basic HTTP connections so you should consider carefully if WebSockets are needed for your application. To help, you can ask yourself these two questions:

* Does the application involve multiple users communicating with each other?
* Is the application a window into server-side data that’s constantly changing?

Answering "yes" to either of these questions indicates the need for WebSockets technology. 


WebSockets provide the most benefits over HTTP in multiplayer games, data trackers, social feeds & chat rooms, and collaborative documents.

Apps that Benefit from WebSockets

Congratulations! In this lesson you have built a strong conceptual foundation of what WebSockets are and how they are created. With the growing number of real-time applications, WebSockets introduced an alternative to repetitive HTTP requests in order to build websites with continuous, bidirectional communication. Here’s what else you learned:

* WebSockets allow for bidirectional communication between client and server allowing for a continuous flow of real-time data.
* Common communication patterns involve both client and server bi-directional communication along with broadcasting, which refers to a server being able to communicate with multiple clients.  
* WebSocket connections are persistent giving them the advantage of lower overhead and being stateful compared to a stateless connection protocol like HTTP.
* The foundation for a WebSocket connection begins with an HTTP request and response called a _handshake_ which aims to replace the HTTP protocol with a WebSocket protocol over a single TCP connection.
* A client can initiate a handshake with a special `Upgrade` header. A server can complete the handshake by sending back a response with the `101 Switching Protocols` header.
* WebSockets are ideal for applications dealing with real-time data such as data trackers, multiplayer games, collaborative document editing, and social feeds and chat rooms.
* `wss://` connections function just like `ws://` ones, except that the initial handshake takes place over HTTPS instead of HTTP.  

Now that you have a sense for what a WebSocket connection is and how they are formed we are ready to start building applications with WebSockets!


A table comparing and contrasting the features of WebSocket and HTTP connections

Review

In order for WebSocket connections to achieve bidirectional and continuous communication, there must first exist a _persistent_ connection.

To help us understand this, let's start by refreshing how non-persistent, uni-directional [HTTP](https://www.codecademy.com/articles/http-requests) connections work. HTTP connections follow a _request-response messaging pattern_: 

![title](https://static-assets.codecademy.com/Courses/Learn-WebSocket/concepts/http-request-response.gif)

In the request-response pattern, a client will open a connection to make a request from a server and the server will send back a response. The connection is then immediately closed requiring a new request to be made to fetch more data.

Unlike HTTP connections, WebSocket connections stay open, or _persist_, allowing for clients and servers to continuously send information back and forth until either the client or the server decides to terminate the connection. This is also known as a _publish-subscribe messaging pattern_: the client can "subscribe" to the server and whenever the server "publishes" a message, the subscribers are notified.

This persistent connection provides a few key benefits:
* Only one request-response is needed to establish the connection, greatly reducing the data transmitted along with each request in the form of headers.
*  The WebSocket connection is stateful meaning that state can be maintained on that connection. The server can keep track of the data that has already been sent to the client and vice-versa without relying on cookies or session ids.


WebSocket connections remain open for communication after a "handshake".

Persistent Connection

Where do these persistent WebSocket connections come from? Don’t worry, the answer doesn’t involve storks. WebSockets actually originate from our old friend, HTTP, and something called a _handshake_.

The handshake is essentially an agreement between the client and the server to establish a persistent WebSocket connection and is initiated using a plain old HTTP request! In the header of the request, the client must communicate to the server that it wants to _upgrade_ the connection from HTTP to WebSockets. It does so using an HTTP GET request to a `ws://` URI along with a set of specific headers like in the following example:

```
GET ws://example.com:8080/ HTTP/1.1
Host: localhost:8080
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: q4xkcO32u266gldTuKaSOw==
```

The request from the client will include the following required headers:
* The `Connection` header controls whether or not the network connection stays open after the current transaction finishes. A value of `Upgrade` signals that we want to upgrade the connection to a new protocol.
* The `Upgrade` header specifies the protocol that the client wants to switch to. In this case, the protocol `websocket` is specified.
* The `Sec-WebSocket-Key` header is a one-time random value generated by the client and is used by the server to prove that it received a valid WebSocket opening handshake.
* The `Sec-WebSocket-Version: 13` header specifies the WebSocket protocol version the client wishes to use. The most recent (as of 2021) and only accepted version of the WebSocket protocol is 13. 

> **Note:** When you visit a website that is built using WebSockets, you will still enter `http://` into your browser to make the initial handshake request – the `ws://` protocol is used to establish a WebSocket connection after the initial `http://` request is made.

Once the server receives this request, it can complete the WebSocket handshake by sending a response to the client like so:

```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=
```

Let's break down each of these response headers:
* The `HTTP/1.1 101 Switching Protocols` header indicates that the server is switching to the protocol that the client requested in its `Upgrade` request header
* The `Connection: Upgrade` header confirms that the connection has been upgraded.
* The `Upgrade: websocket` header confirms that the protocol is being upgraded from HTTP to WebSocket 
* The `Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=` header is a key generated based on the `Sec-WebSocket-Key` header in the request and is used to authenticate the handshake.

After the client receives the server response, the HTTP connection is replaced by a WebSocket connection and data can begin flowing freely. An application can now benefit from transferring as much data as desired without:
* Incurring the overhead associated with each client-to-server message having an HTTP header.
* Having to open up a new underlying TCP connection for each client-to-server message.

Upgrade headers are passed between the client and the server to form a handshake. Then, data can flow freely between the client and the server.