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
 

 https://datatracker.ietf.org/doc/rfc9220/

this might be interesting too... it's basically reworking websockets to work over QUIC transports (which is UDP @ChipTuner @Michael J  ) 

 yeah, it's basically the same as TCP except, mostly, the rigmerole of handshake and disconnect, and that you can send either binary or text frames, everything else is optional... maintaining a ping to detect loss of connection is application level, but conventional 

 yes, and there is a framing scheme for text vs binary