RFC 6455 - The WebSocket Protocol https://tools.ietf.org/html/rfc6455

1.5. Design Philosophy

   _This section is non-normative._

   The WebSocket Protocol is designed on the principle that there should
   be minimal framing (the only framing that exists is to make the
   protocol frame-based instead of stream-based and to support a
   distinction between Unicode text and binary frames).  It is expected
   that metadata would be layered on top of WebSocket by the application




Fette & Melnikov             Standards Track                    [Page 9]

---

 
RFC 6455                 The WebSocket Protocol            December 2011


   layer, in the same way that metadata is layered on top of TCP by the
   application layer (e.g., HTTP).

   Conceptually, WebSocket is really just a layer on top of TCP that
   does the following:

   o  adds a web origin-based security model for browsers

   o  adds an addressing and protocol naming mechanism to support
      multiple services on one port and multiple host names on one IP
      address

   o  layers a framing mechanism on top of TCP to get back to the IP
      packet mechanism that TCP is built on, but without length limits

   o  includes an additional closing handshake in-band that is designed
      to work in the presence of proxies and other intermediaries

   Other than that, WebSocket adds nothing.  Basically it is intended to
   be as close to just exposing raw TCP to script as possible given the
   constraints of the Web.  It's also designed in such a way that its
   servers can share a port with HTTP servers, by having its handshake
   be a valid HTTP Upgrade request.  One could conceptually use other
   protocols to establish client-server messaging, but the intent of
   WebSockets is to provide a relatively simple protocol that can
   coexist with HTTP and deployed HTTP infrastructure (such as proxies)
   and that is as close to TCP as is safe for use with such
   infrastructure given security considerations, with targeted additions
   to simplify usage and keep simple things simple (such as the addition
   of message semantics).

   The protocol is intended to be extensible; future versions will
   likely introduce additional concepts such as multiplexing.