

The former is more accurate because, while they are protocols in the sense that they must follow a precise set of rules for establishing communication and enclosing transmitted data, the standard takes no position on how the data payload is arranged within the outer message envelope. You may have heard WebSockets referred to as both a "transport" and a "protocol" at the same time.

They also take into account the fact that the internet has additional security concerns that must be addressed to protect both users and service providers. This was great in the early days of the internet because we were mostly dealing with text documents and maybe a few other assets. Open a connection, explain your request, receive a response, and then shut the connection. This is because the web was constructed on the HTTP protocol, which was created solely as a request-response system. The "real-time" web existed before WebSockets, but it was difficult to produce, usually slower, and delivered through hacking existing web technologies that weren't built for real-time applications. WebSockets was first described in 2008, and browser support has been widespread since roughly 2010.

The goal is to give web application developers an as-close-to-raw-as-possible TCP (Transport Control Protocol) communication layer while also introducing a few abstractions to remove some of the friction that would otherwise exist around how the web works. WebSockets are a thin transport layer that sits on top of the TCP/IP stack on a device.
