WebSocket is a computer communication protocol, providing a full-duplex communication channel through a single TCP connection. The WebSocket protocol is standardized by IETF as RFC 6455 in 2011, and the WebSocket API on the Web IDL is being standardized by the W3C.
WebSocket is a different TCP protocol than HTTP. Both protocols are located in layer 7 in the OSI model and, thus, rely on TCP on layer 4. Although they are different, RFC 6455 states that WebSocket "is designed to work over HTTP ports 80 and 443 and to support HTTP proxies and intermediaries" making it compatible with the HTTP protocol. To achieve compatibility, WebSocket handshakes use the HTTP Upgrade header to change from the HTTP protocol to the WebSocket protocol.
The WebSocket protocol enables interaction between web clients (such as browsers) and web servers with lower overhead, facilitating real-time data transfer to and from the server. This is made possible by providing a standard way for servers to send content to clients without being asked in advance by clients, and allowing messages to be forwarded back and forth while keeping connections open. In this way, an ongoing two-way conversation can occur between the client and the server. Communication is done through a TCP 80 port number (or 443 in the case of TLS encrypted connections), which is useful for environments that block non-web Internet connections using a firewall. Similar server-browsing server communications have been achieved in a non-standard way using stopgap technologies such as Comet.
The WebSocket protocol is currently supported in most browsers including Google Chrome, Microsoft Edge, Internet Explorer, Firefox, Safari and Opera. WebSocket also requires a web application on the server to support it.
Video WebSocket
Ikhtisar
Unlike HTTP, WebSocket provides full-duplex communication. In addition, WebSocket allows message flow over TCP. TCP itself deals with byte streams with no inherent message concept. Prior to WebSocket, port 80 full-duplex communications can be performed using Comet channels; However, the Comet implementation is not trivial, and because of TCP handshakes and HTTP overhead headers, it is inefficient for small messages. The WebSocket protocol aims to solve this problem without compromising web security assumptions.
WebSocket protocol specifications define ws (WebSocket) and wss (WebSocket Secure) as two new uniform resource identifier (URI) schemes used for unencrypted and encrypted connections. Regardless of the schema and fragment name ( # not supported), the remaining URI components are defined to use generic URI syntax.
Using browser developer tools, developers can check WebSocket handshakes as well as WebSocket frames.
Maps WebSocket
History
WebSocket was first referred to as TCPConnection in the HTML5 specification, as a placeholder for TCP socket-based sockets. In June 2008, a series of discussions led by Michael Carter produced the first version of the protocol known as WebSocket.
The name "WebSocket" was created by Ian Hickson and Michael Carter shortly afterwards through collaboration in the IRC #whatwg chat room, and then written for inclusion in the HTML5 specification by Ian Hickson, and announced on cometdaily blog by Michael Carter. In December 2009, Google Chrome 4 was the first browser to send full support for the standard, with WebSocket enabled by default. The development of the WebSocket protocol was then moved from the W3C and WHATWG groups to the IETF in February 2010, and wrote for two revisions under Ian Hickson.
Once the protocol is sent and enabled by default in some browsers, RFC is completed under Ian Fette in December 2011.
Browser Implementation
The secure version of the WebSocket protocol is implemented in Firefox 6, Safari 6, Google Chrome 14, Opera 12.10 and Internet Explorer 10. A detailed suite of protocol test reports lists the compatibility of those browsers with certain protocol aspects.
Older and less secure protocol versions are implemented in Opera 11 and Safari 5, as well as the mobile version of Safari on iOS 4.2. The BlackBerry browser on OS7 implements WebSockets. Due to the vulnerability, it is disabled in Firefox 4 and 5, and Opera 11.
Protocol handshake
To establish a WebSocket connection, the client sends a WebSocket handshake request, whose server returns a WebSocket handshake response, as shown in the example below.
Client request (same as in HTTP, each line ends with \ r \ n and there should be an additional blank line at the end):
Respons server:
Handshake resembles HTTP in allowing the server to handle HTTP connections as well as WebSocket connections on the same port. Once the connection is established, the communication switches to a two-way binary protocol that is inconsistent with the HTTP protocol.
In addition to the Upgrade header, the client sends a Sec-WebSocket-Key header containing the base64-encoded random bytes, and the server replied with a hash key in the header Sec-WebSocket-Accept . This is meant to prevent proxy caching from re-sending WebSocket conversations before, and not providing any authentication, privacy or integrity. The hashing function adds a fixed string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (a GUID) to the value of the Sec-WebSocket-Key header (which is not decoded from base64) SHA-1 hashing function, and encode the result using base64.
Once the connection is established, the client and server can send WebSocket data or text frames back and forth in full-duplex mode. The data is framed at a minimum, with a small header followed by a payload. The WebSocket transmission is described as a "message", in which one message can optionally be split across multiple data frames. It can be possible to send messages where initial data is available but the full length of the unknown message (send one frame of data after the other until it is finally reached and marked with the FIN bit). With extensions for protocols, this can also be used for multiple multiplexing streams simultaneously (eg to avoid monopolizing the use of sockets for a single large payload).
It is important (from a security perspective) to validate the "Origin" headers during the establishment of server-side connections (against intended origin) to avoid Cross-Site Hijacking CrossSite attacks, which may occur when connections are authenticated with Cookies or HTTP authentication. It is better to use tokens or similar protection mechanisms to authenticate WebSocket connections when sensitive (private) data is being transferred via WebSocket.
Proxy traversal
The WebSocket protocol client implementation tries to detect if the user agent is configured to use a proxy when connecting to the destination host and port and, if it is, uses the HTTP CONNECT method to set the tunnel continuously.
While the WebSocket protocol itself does not know proxy servers and firewalls, it has a HTTP-compatible handshake feature that allows HTTP servers to share standard HTTP and HTTPS (80 and 443) ports with a gateway or WebSocket server. The WebSocket protocol defines aws://and wss://prefix to show WebSocket and WebSocket Secure connections, respectively. Both schemes use HTTP upgrading mechanism to upgrade to WebSocket protocol. Some proxy servers are transparent and work well with WebSocket; others will prevent WebSocket from working properly, causing the connection to fail. In some cases, additional proxy server configuration may be required, and certain proxy servers may need to be upgraded to support WebSocket.
If unencrypted WebSocket traffic flows through an explicit or transparent proxy server without WebSockets support, the connection may fail.
If an encrypted WebSocket connection is used, then the use of Transport Layer Security (TLS) in the WebSocket Secure connection ensures that the CONNECT HTTP command is issued when the browser is configured to use an explicit proxy server. This creates a tunnel, which provides low end to end TCP communications via an HTTP proxy, between a WebSocket Secure client and a WebSocket server. In case the proxy server is transparent, the browser does not know the proxy server, so no HTTP CONNECT is sent. However, since wire traffic is encrypted, a medium-sized transparent proxy server may only allow encrypted traffic, so there is a much better chance that a WebSocket connection will work if WebSocket Secure is used. Using encryption is not cost-free, but it often provides the highest success rate because it will travel through a secure tunnel.
The mid-2010 draft (hixie-76 version) broke compatibility with proxies and reversed gates by entering eight bytes of key data after the header, but not advertising the data in the Content-Length: 8 header. This data is not forwarded by any intermediaries, which may lead to protocol failure. The newer drafts (for example, hybi-09) include key data in the
See also
Note
References
External links
Source of the article : Wikipedia
0 Comments