WebSocket - Wikipedia

WebSocket - Wikipedia
Jump to content
From Wikipedia, the free encyclopedia
Computer network protocol
WebSocket
The WebSocket logo
International standard
RFC
6455
WebSockets
IETF
WHATWG
Introduced
December 2011
2011-12
Industry
Computer science
Connector type
TCP
WebSocket
is a computer
communications protocol
, providing a
bidirectional
communication channel over a single
Transmission Control Protocol
(TCP) connection. The protocol was standardized by the
IETF
as
RFC
6455
in 2011. The current specification allowing web applications to use this protocol is known as
WebSockets
It is a living standard maintained by the
WHATWG
and a successor to
The WebSocket API
from the
W3C
WebSocket is distinct from
HTTP
used to serve most webpages. Although they are different,
RFC
6455
states that WebSocket "is designed to work over HTTP ports 443 and 80 as well as to support HTTP proxies and intermediaries", making the WebSocket protocol compatible with HTTP. To achieve compatibility, the WebSocket
handshake
uses the
HTTP Upgrade header
to change from the HTTP protocol to the WebSocket protocol.
The WebSocket protocol enables
full-duplex
interaction between a
web browser
(or other
client
application) and a
web server
with lower overhead than half-duplex alternatives such as HTTP
polling
, facilitating real-time data transfer from and to the server. This is achieved by providing a standardized way for the server to send content to the client without being first requested by the client, and allowing messages to be exchanged while keeping the connection open. In this way, a two-way ongoing conversation can take place between the client and the server. The communications are usually done over TCP
port
number 443 (or 80 in the case of unsecured connections), which is beneficial for environments that block non-web Internet connections using a
firewall
. Additionally, WebSocket enables streams of messages on top of TCP. TCP alone deals with streams of bytes with no inherent concept of a message. Similar two-way browser–server communications have been achieved in non-standardized ways using stopgap technologies such as
Comet
or
Adobe Flash Player
Most browsers support the protocol, including
Google Chrome
Firefox
Microsoft Edge
Internet Explorer
Safari
and
Opera
The WebSocket protocol specification defines
ws
(WebSocket) and
wss
(WebSocket Secure) as two new
uniform resource identifier
(URI) schemes
that are used for unencrypted and encrypted connections respectively. Apart from the scheme name and
fragment
(i.e.
is not supported), the rest of the URI components are defined to use
URI generic syntax
History
edit
WebSocket was first referenced as TCPConnection in the
HTML5
specification, as a placeholder for a TCP-based socket API.
In June 2008, a series of discussions were led by
Michael Carter
that resulted in the first version of the protocol known as WebSocket.
Before WebSocket, port 80 full-duplex communication was attainable using
Comet
channels; however, Comet implementation is nontrivial, and due to the TCP handshake and HTTP header overhead, it is inefficient for small messages. The WebSocket protocol aims to solve these problems without compromising the security assumptions of the web.
The name "WebSocket" was coined by
Ian Hickson
and Michael Carter shortly thereafter through collaboration on the #whatwg IRC chat room,
10
and subsequently authored for inclusion in the HTML5 specification by Ian Hickson. In December 2009, Google Chrome 4 was the first browser to ship full support for the standard, with WebSocket enabled by default.
11
Development of the WebSocket protocol was subsequently moved from the W3C and
WHATWG
group to the IETF in February 2010, and authored for two revisions under Ian Hickson.
12
After the protocol was shipped and enabled by default in multiple browsers, the
RFC
6455
was finalized under Ian Fette in December 2011.
RFC
7692
introduced compression extension to WebSocket using the
DEFLATE
algorithm on a per-message basis.
Web API
edit
A web application (e.g. web browser) may use the
WebSocket
interface to maintain bidirectional communications with a WebSocket server.
13
Client example
edit
In
TypeScript
// Connect to server
const
ws
new
WebSocket
"wss://game.example.com/scoreboard"
);
// Receive ArrayBuffer instead of Blob
ws
binaryType
"arraybuffer"
// Set event listeners
ws
onopen
()
=>
console
log
"Connection opened"
);
ws
send
"Hi server, please send me the score of yesterday's game"
);
};
ws
onmessage
event
MessageEvent
=>
console
log
"Data received"
event
data
);
ws
close
();
// We got the score so we don't need the connection anymore
};
ws
onclose
event
CloseEvent
=>
console
log
"Connection closed"
event
code
event
reason
event
wasClean
);
};
ws
onerror
()
=>
console
log
"Connection closed due to error"
);
};
WebSocket interface
edit
Type
Name
14
Description
Constructor
ws = new
WebSocket
(url [, protocols ])
Start opening handshake
15
url
: A string containing:
Scheme
: must be
ws
wss
http
or
https
Host
Optional
port
: If not specified, 80 is used for
ws
and
http
, and 443 for
wss
and
https
Optional
path
Optional
query
No
fragment
Optional
protocols
: A string or an array of strings used as the value of the
Sec-WebSocket-Protocol
header in the opening handshake.
Exceptions:
SyntaxError
url
parsing
failed.
url
has an invalid scheme.
url
has a fragment.
protocols
has duplicate strings.
Method
ws.
send
(data)
Send data message
16
data
: must be
string
Blob
ArrayBuffer
or
ArrayBufferView
Return:
undefined
Exceptions:
InvalidStateError
ws.readyState
is
CONNECTING
Note: If the data cannot be sent (e.g. because it would need to be buffered but the buffer is full), the connection is closed and the
error
event is fired.
ws.
close
([ code ] [, reason ])
Start
closing handshake
17
Optional
code
: If specified, must be 1000 (
Normal closure
) or in the range 3000 to 4999 (application-defined). Defaults to 1000.
Optional
reason
: If specified, must be a string whose
UTF-8
encoding is up to 123 bytes. Defaults to an empty string.
Return:
undefined
Exceptions:
InvalidAccessError
code
is not 1000 nor is in the range 3000 to 4999.
SyntaxError
: UTF-8-encoded
reason
is longer than 123 bytes.
Note:
If
ws.readyState
is
OPEN
or
CONNECTING
ws.readyState
is set to
CLOSING
and the closing handshake starts.
If
ws.readyState
is
CLOSING
or
CLOSED
, nothing happens (because the closing handshake has already started).
Event
ws.
onopen
= (event) => {}
ws.addEventListener(
"open"
, (event) => {})
Opening handshake succeeded
event
type is
Event
ws.
onmessage
= (event) => {}
ws.addEventListener(
"message"
, (event) => {})
Data message received.
event
type is
MessageEvent
. This event is only fired if
ws.readyState
is
OPEN
18
event.data
is the data received, of type:
string
for text.
Blob
or
ArrayBuffer
for binary (see
ws.binaryType
).
event.origin
is
ws.url
but only with the scheme, host, and port (if any).
ws.
onclose
= (event) => {}
ws.addEventListener(
"close"
, (event) => {})
The underlying
TCP connection closed
event
type is
CloseEvent
19
20
21
22
event.code
status code
(integer).
event.reason
: reason for closing (string).
event.wasClean
true
if the TCP connection was closed after the closing handshake was completed, else
false
Note:
If the received
Close
frame contains a
payload
event.code
and
event.reason
get their value from the payload.
If the received
Close
frame contains
no payload
event.code
is 1005 (
No code received
) and
event.reason
is an empty string.
If
no
Close
frame
was received,
event.code
is 1006 (
Connection closed abnormally
) and
event.reason
is an empty string.
ws.
onerror
= (event) => {}
ws.addEventListener(
"error"
, (event) => {})
Connection closed due to error
event
type is
Event
Attribute
ws.
binaryType
(string)
Type of
event.data
in
ws.onmessage
when a binary data message is received. Initially set to
"blob"
Blob
object). May be changed to
"arraybuffer"
ArrayBuffer
object).
23
Read-only attribute
ws.
url
(string)
URL given to the
WebSocket
constructor
with the following transformations:
If scheme is
http
or
https
, change it to
ws
or
wss
respectively.
ws.
bufferedAmount
(number)
Number of bytes
of application data (UTF-8 text and binary data) that have been
queued using
ws.send()
but not yet transmitted to the network
. It resets to zero once all queued data has been sent. If the connection closes, this value will only increase, with each call to
ws.send()
, and never reset to zero.
24
ws.
protocol
(string)
Protocol accepted by the server
, or an empty string if
protocols
was not specified in the
WebSocket
constructor.
ws.
extensions
(string)
Extensions accepted by the server
ws.
readyState
(number)
Connection state
. It is one of the constants below. Initially set to
CONNECTING
25
Constant
WebSocket.
CONNECTING
= 0
Opening handshake is currently in progress
. The initial state of the connection.
26
27
WebSocket.
OPEN
= 1
Opening handshake succeeded
. The client and server may send messages to each other.
28
29
WebSocket.
CLOSING
= 2
Closing handshake is currently in progress
. Either
ws.close()
was called or a
Close
message was received.
30
31
WebSocket.
CLOSED
= 3
The underlying
TCP connection is closed
32
19
20
Protocol
edit
A diagram describing a connection using WebSocket
Steps:
Opening handshake
HTTP request
and
HTTP response
Frame-based message
exchange: data, ping and pong messages.
Closing handshake
: close message (request then echoed in response).
Opening handshake
edit
The client sends an
HTTP request
method
GET
version
≥ 1.1
) and the server returns an
HTTP response
with
status code 101
Switching Protocols
) on success. HTTP and WebSocket clients can connect to a server using the same port because the opening handshake uses HTTP. Sending additional HTTP headers (that are not in the table below) is allowed. HTTP headers may be sent in any order. After the
Switching Protocols
HTTP response, the opening handshake is complete, the HTTP protocol stops being used, and communication switches to a binary frame-based protocol.
33
34
HTTP headers relevant to the opening handshake
Side
Header
Value
Mandatory
Request
Origin
35
Varies
Yes (for browser clients)
Host
36
Varies
Yes
Sec-WebSocket-Version
37
13
Sec-WebSocket-Key
38
base64
-encode(16 random bytes)
Response
Sec-WebSocket-Accept
39
base64-encode(
SHA1
(Sec-WebSocket-Key +
258EAFA5-E914-47DA-95CA-C5AB0DC85B11
))
Both
Connection
40
41
Upgrade
Upgrade
42
43
websocket
Sec-WebSocket-Protocol
44
The request may contain a comma-separated list of strings (ordered by preference) indicating
application-level protocols
(built on top of WebSocket data messages) the client wishes to use. If the client sends this header, the server response must be one of the values from the list.
No
Sec-WebSocket-Extensions
45
46
47
48
Used to negotiate protocol-level extensions. The client may request extensions to the WebSocket protocol by including a comma-separated list of extensions (ordered by preference). Each extension may have a parameter (e.g. foo=4). The server may accept some or all extensions requested by the client. This field may appear multiple times in the request (logically equivalent to a single occurrence containing all values) and must not appear more than once in the response.
Example request:
34
GET
/chat
HTTP
1.1
Host
server.example.com
Upgrade
websocket
Connection
Upgrade
Sec-WebSocket-Key
dGhlIHNhbXBsZSBub25jZQ==
Origin
Sec-WebSocket-Protocol
chat, superchat
Sec-WebSocket-Version
13
Example response:
34
HTTP
1.1
101
Switching Protocols
Upgrade
websocket
Connection
Upgrade
Sec-WebSocket-Accept
s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol
chat
The following
Python
code generates a random
Sec-WebSocket-Key
import
base64
import
os
base64
b64encode
os
urandom
16
)))
The following Python code calculates
Sec-WebSocket-Accept
using
Sec-WebSocket-Key
from the example request above.
import
base64
import
hashlib
KEY
bytes
"dGhlIHNhbXBsZSBub25jZQ=="
MAGIC
bytes
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
base64
b64encode
hashlib
sha1
KEY
MAGIC
digest
()))
Sec-WebSocket-Key
and
Sec-WebSocket-Accept
are intended to prevent a
caching
proxy
from re-sending a previous WebSocket conversation,
49
and does not provide any authentication, privacy, or integrity.
Though some servers accept a short
Sec-WebSocket-Key
, many modern servers will reject the request with error "invalid Sec-WebSocket-Key header".
Frame-based message
edit
After the opening handshake, the client and server can, at any time, send
data messages
(text or binary) and
control messages
Close
Ping
Pong
) to each other. A message is composed of
one frame if unfragmented
or
at least two frames if fragmented
Fragmentation
splits a message into
two or more frames
. It enables sending messages with initial data available but complete length unknown. Without fragmentation, the whole message must be sent in one frame, so the complete length is needed before the first byte can be sent, which requires a buffer.
50
It was proposed to extend this feature to enable multiplexing several streams simultaneously (e.g. to avoid monopolizing a socket for a single large
payload
), but the protocol extension was never accepted.
51
An
unfragmented message
consists of one frame with
FIN = 1
and
opcode ≠ 0
fragmented message
consists of one frame with
FIN = 0
and
opcode ≠ 0
, followed by zero or more frames with
FIN = 0
and
opcode = 0
, and terminated by one frame with
FIN = 1
and
opcode = 0
Frame structure
edit
Offset
(bits)
Field
52
Size
(bits)
Description
FIN
53
1 =
final frame
of a message.
0 = message is fragmented and this is
not the final frame
RSV1
Reserved. Must be 0
unless defined by an extension. If a non-zero value is received and none of the negotiated extensions defines the meaning of such a non-zero value, the connection must be closed.
54
RSV2
RSV3
Opcode
See
opcodes
below.
Masked
55
1 = frame is masked
(i.e. masking key is present and the payload has been
XORed
with the masking key).
0 = frame is not masked
(i.e. masking key is not present).
See
client-to-server masking
below.
Payload length
56
7, 7+16 or 7+64
Length of the payload
(extension data + application data) in bytes.
0–125
= This is the payload length.
126
= The following 16 bits are the payload length.
127
= The following 64 bits (
MSB
must be 0) are the payload length.
Endianness
is
big-endian
Signedness
is
unsigned
. The
minimum
number of bits must be used to encode the length.
Varies
Masking key
57
0 or 32
Random nonce
. Present if the masked field is 1. The client generates a masking key for every masked frame.
Payload
Extension data
Payload length (bytes)
Must be empty
unless defined by an extension.
Application data
Depends on the opcode
Opcodes
edit
Frame type
58
Opcode
59
Related
Web API
Description
Purpose
Fragmentable
Max. payload length (bytes)
Continuation frame
Non-first frame of a fragmented message.
Message fragmentation
63
− 1
Non-control frame
Text
send()
onmessage
UTF-8-encoded text.
Data message
Yes
Binary
Binary data.
3–7
Reserved
for further non-control frames. May be defined by an extension.
60
Control frame
61
Close
close()
onclose
The WebSocket
closing handshake starts upon either sending or receiving a
Close
frame
62
It may prevent data loss by complementing the
TCP closing handshake
63
No frame can be sent after sending a
Close
frame. If a
Close
frame is received and no prior
Close
frame was sent, a
Close
frame must be sent in response (typically echoing the status code received). The payload is optional, but if present, it must start with a two-byte big-endian unsigned integer
status code
, optionally followed by a UTF-8-encoded reason message not longer than 123 bytes.
64
Protocol state
No
125
Ping
May be used for
latency
measurement
keepalive
and
heartbeat
. Both sides can
send a ping
(with any payload). Whoever receives it must, as soon as is practical,
send back a pong with the same payload
. A pong should be ignored if no prior ping was sent.
65
66
67
Pong
10
11–15
Reserved
for further control frames. May be defined by an extension.
60
Client-to-server masking
edit
client must mask
all frames sent to the server. A
server must not mask
any frames sent to the client.
68
Frame masking applies
XOR between the payload and the masking key
. The following
pseudocode
describes the algorithm used to both mask and unmask a frame.
57
for
from
to
payload_length − 1
payload[i] := payload[i] xor masking_key[i mod 4]
Status codes
edit
Range
69
Allowed in
Close
frame
Code
70
Description
0–999
No
Unused
1000–2999 (Protocol)
Yes
1000
Normal closure.
1001
Going away (e.g. browser tab closed; server going down).
1002
Protocol error.
1003
Unsupported data (e.g. endpoint only understands text but received binary).
No
1004
Reserved for future usage
1005
No code received.
1006
Connection closed abnormally (i.e. closing handshake did not occur).
Yes
1007
Invalid payload data (e.g. non UTF-8 data in a text message).
1008
Policy violated.
1009
Message too big.
1010
Unsupported extension. The client should write the extensions it expected the server to support in the payload.
1011
Internal server error.
No
1015
TLS handshake failure.
3000–3999
Yes
Reserved for libraries, frameworks and applications. Registered directly with
IANA
4000–4999
Private use.
Compression extension
edit
The
permessage-deflate
extension allows data messages to be compressed using the
DEFLATE
algorithm.
For example, during the opening handshake, the client and server may use the following header to enable the extension. The
RSV1
field of the first frame of a data message must be set to indicate the payload data is compressed.
71
Sec-WebSocket-Extensions: permessage-deflate
Server implementation example
edit
In Python.
Note:
recv()
returns up to the amount of bytes requested. For readability, the code ignores that, thus it may fail in non-ideal network conditions.
import
base64
import
hashlib
import
struct
from
typing
import
Optional
from
socket
import
socket
as
Socket
def
handle_websocket_connection
ws
Socket
->
None
# Accept connection
conn
addr
ws
accept
()
# Receive and parse HTTP request
key
Optional
bytes
None
for
line
in
conn
recv
4096
split
\r\n
):
if
line
startswith
"Sec-WebSocket-Key"
):
key
line
split
()[
if
key
is
None
raise
ValueError
"Sec-WebSocket-Key not found"
# Send HTTP response
sec_accept
base64
b64encode
hashlib
sha1
key
"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
digest
())
conn
sendall
\r\n
join
([
"HTTP/1.1 101 Switching Protocols"
"Connection: Upgrade"
"Upgrade: websocket"
"Sec-WebSocket-Accept: "
sec_accept
""
""
])
# Decode and print frames
while
True
byte0
byte1
conn
recv
fin
int
byte0
>>
opcode
int
byte0
0b1111
masked
int
byte1
>>
assert
masked
"The client must mask all frames"
if
opcode
>=
assert
fin
"Control frames are unfragmentable"
# Payload size
payload_size
int
byte1
0b111_1111
if
payload_size
==
126
payload_size
struct
unpack
">H"
conn
recv
))
assert
payload_size
125
"The minimum number of bits must be used"
elif
payload_size
==
127
payload_size
struct
unpack
">Q"
conn
recv
))
assert
payload_size
**
16
"The minimum number of bits must be used"
assert
payload_size
<=
**
63
"The most significant bit must be zero"
if
opcode
>=
assert
payload_size
<=
125
"Control frames must have up to 125 bytes"
# Unmask
masking_key
bytes
conn
recv
payload
bytearray
bytearray
conn
recv
payload_size
))
for
in
range
payload_size
):
payload
payload
masking_key
"Received frame"
FIN
opcode
payload
if
__name__
==
"__main__"
# Accept TCP connection on any interface at port 80
ws
Socket
Socket
()
ws
bind
((
""
80
))
ws
listen
()
handle_websocket_connection
ws
Browser support
edit
A secure version of the WebSocket protocol is implemented in Firefox 6,
72
Safari 6, Google Chrome 14,
73
Opera
12.10 and
Internet Explorer
10.
74
A detailed protocol test suite report
75
lists the conformance of those browsers to specific protocol aspects.
An older, less secure version of the protocol was implemented in Opera 11 and
Safari
5, as well as the mobile version of Safari in
iOS 4.2
76
The BlackBerry Browser in OS7 implements WebSockets.
77
Because of vulnerabilities, it was disabled in Firefox 4 and 5,
78
and Opera 11.
79
Using browser developer tools, developers can inspect the WebSocket handshake as well as the WebSocket frames.
80
Protocol version
Draft date
Internet Explorer
Firefox
81
(PC)
Firefox
(Android)
Chrome
(PC, Mobile)
Safari
(Mac, iOS)
Opera
(PC, Mobile)
Android Browser
hixie-75
February 4, 2010
5.0.0
hixie-76
hybi-00
May 6, 2010
May 23, 2010
4.0
(disabled)
5.0.1
11.00
(disabled)
hybi-07
, v7
April 22, 2011
82
hybi-10
, v8
July 11, 2011
84
14
85
RFC
6455
, v13
December, 2011
10
86
11
11
16
87
12.10
88
4.4
Server implementations
edit
Nginx
has supported WebSockets since 2013, implemented in version 1.3.13
89
including acting as a
reverse proxy
and
load balancer
of WebSocket applications.
90
Apache HTTP Server
has supported WebSockets since July, 2013, implemented in version 2.4.5
91
92
Internet Information Services
added support for WebSockets in version 8 which was released with
Windows Server 2012
93
lighttpd
has supported WebSockets since 2017, implemented in lighttpd 1.4.46.
94
lighttpd mod_proxy can act as a reverse proxy and load balancer of WebSocket applications. lighttpd mod_wstunnel can act as a WebSocket endpoint to transmit arbitrary data, including in
JSON
format, to a backend application. lighttpd supports WebSockets over HTTP/2 since 2022, implemented in lighttpd 1.4.65.
95
Eclipse Mosquitto
This is an
MQTT broker
, but it supports the MQTT over WebSocket. So, it can be considered a type of WebSocket implementation.
ASP.NET Core have support for WebSockets using the
app.UseWebSockets();
middleware.
96
Security considerations
edit
Unlike regular cross-domain HTTP requests, WebSocket requests are not restricted by the
same-origin policy
. Therefore, WebSocket servers must validate the "Origin" header against the expected origins during connection establishment, to avoid cross-site WebSocket hijacking attacks (similar to
cross-site request forgery
), which might be possible when the connection is authenticated with
or HTTP authentication. It is better to use tokens or similar protection mechanisms to authenticate the WebSocket connection when sensitive (private) data is being transferred over the WebSocket.
97
A live example of vulnerability was seen in 2020 in the form of
Cable Haunt
Proxy traversal
edit
WebSocket protocol client implementations try to detect whether the
user agent
is configured to use a proxy when connecting to destination host and port, and if it is, uses
HTTP CONNECT
method to set up a persistent tunnel.
The WebSocket protocol is unaware of proxy servers and firewalls. Some proxy servers are transparent and work fine with WebSocket; others will prevent WebSocket from working correctly, 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 a transparent proxy server without WebSockets support, the connection will likely fail.
98
If an encrypted WebSocket connection is used, then the use of
Transport Layer Security
(TLS) in the WebSocket Secure connection ensures that an
HTTP CONNECT
command is issued when the browser is configured to use an explicit proxy server. This sets up a tunnel, which provides low-level end-to-end TCP communication through the HTTP proxy, between the WebSocket Secure client and the WebSocket server. In the case of transparent proxy servers, the browser is unaware of the proxy server, so no
HTTP CONNECT
is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if WebSocket Secure is used. Using encryption is not free of resource cost, but often provides the highest success rate, since it would be travelling through a secure tunnel.
A mid-2010 draft (version hixie-76) broke compatibility with
reverse proxies
and gateways by including eight bytes of key data after the headers, but not advertising that data in a
Content-Length: 8
header.
99
This data was not forwarded by all intermediates, which could lead to protocol failure. More recent drafts (e.g., hybi-09
100
) put the key data in a
Sec-WebSocket-Key
header, solving this problem.
See also
edit
Comparison of WebSocket implementations
Network socket
Push technology
XMLHttpRequest
Server-sent events
WebRTC
HTTP/2
Internet protocol suite
BOSH
Notes
edit
The
URL parsing algorithm
is described at
The plus sign represents
string concatenation
The specification only explicitly restricts control frames. Thus, all other frames are restricted by the protocol limit of 63 bits for payload length (as the most significant bit must be zero).
Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",
83
requiring extra code to integrate with existing WebSocket-enabled code.
References
edit
"WebSockets Standard"
WHATWG WebSockets
Archived
from the original on 2023-03-12
. Retrieved
2022-05-16
"The WebSocket API"
www.w3.org
Archived
from the original on 2022-06-08
. Retrieved
2022-05-16
Ian Fette; Alexey Melnikov (December 2011).
"Relationship to TCP and HTTP"
RFC 6455 The WebSocket Protocol
IETF
. sec. 1.7.
doi
10.17487/RFC6455
RFC
6455
"Adobe Flash Platform – Sockets"
help.adobe.com
Archived
from the original on 2021-04-18
. Retrieved
2021-07-28
TCP connections require a "client" and a "server". Flash Player can create client sockets.
"The WebSocket API (WebSockets)"
MDN Web Docs
. Mozilla Developer Network. 2023-04-06.
Archived
from the original on 2021-07-28
. Retrieved
2021-07-26
Graham Klyne, ed. (2011-11-14).
"IANA Uniform Resource Identifier (URI) Schemes"
Internet Assigned Numbers Authority
Archived
from the original on 2013-04-25
. Retrieved
2011-12-10
Ian Fette; Alexey Melnikov (December 2011).
"WebSocket URIs"
RFC 6455 The WebSocket Protocol
IETF
. sec. 3.
doi
10.17487/RFC6455
RFC
6455
"HTML 5"
www.w3.org
Archived
from the original on 2016-09-16
. Retrieved
2016-04-17
"[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)"
lists.w3.org
Archived
from the original on 2016-04-27
. Retrieved
2016-04-17
"IRC logs: freenode / #whatwg / 20080618"
krijnhoetmer.nl
Archived
from the original on 2016-08-21
. Retrieved
2016-04-18
"Web Sockets Now Available In Google Chrome"
Chromium Blog
Archived
from the original on 2021-12-09
. Retrieved
2016-04-17
, Ian Hickson (6 May 2010).
"The WebSocket protocol"
Ietf Datatracker
Archived
from the original on 2017-03-17
. Retrieved
2016-04-17
"Introduction"
WHATWG WebSockets
. sec. 1.
"Interface definition"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-10
"new WebSocket(url, protocols)"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-30
"send(data)"
WHATWG WebSockets
. sec. 3.1.
"close(code, reason)"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-10
"When a WebSocket message has been received"
WHATWG WebSockets
. sec. 4.
"When the WebSocket connection is closed; substep 3"
WHATWG WebSockets
. sec. 4.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-13
The WebSocket Connection is Closed
IETF
. sec. 7.1.4.
doi
10.17487/RFC6455
RFC
6455
The WebSocket Connection Close Code
IETF
. sec. 7.1.5.
doi
10.17487/RFC6455
RFC
6455
The WebSocket Connection Close Reason
IETF
. sec. 7.1.6.
doi
10.17487/RFC6455
RFC
6455
"socket.binaryType"
WHATWG WebSockets
. sec. 3.1.
"socket.bufferedAmount"
WHATWG WebSockets
. sec. 3.1.
"ready state"
WHATWG WebSockets
. sec. 3.1.
"CONNECTING"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-13
Client Requirements
IETF
. p. 14. sec. 4.1.
doi
10.17487/RFC6455
RFC
6455
"OPEN"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-10
_The WebSocket Connection is Established_
IETF
. p. 20.
doi
10.17487/RFC6455
RFC
6455
"CLOSING"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-10
The WebSocket Closing Handshake is Started
IETF
. sec. 7.1.3.
doi
10.17487/RFC6455
RFC
6455
"CLOSED"
WHATWG WebSockets
. sec. 3.1.
Archived
from the original on 2023-03-12
. Retrieved
2024-04-10
Opening Handshake
IETF
. sec. 1.3.
doi
10.17487/RFC6455
RFC
6455
Protocol Overview
IETF
. sec. 1.2.
doi
10.17487/RFC6455
RFC
6455
Client requirement 8.
IETF
. p. 18.
doi
10.17487/RFC6455
RFC
6455
Client requirement 4.
IETF
. p. 17.
doi
10.17487/RFC6455
RFC
6455
Client requirement 9.
IETF
. p. 18.
doi
10.17487/RFC6455
RFC
6455
Client requirement 7.
IETF
. p. 18.
doi
10.17487/RFC6455
RFC
6455
Server step 5.4.
IETF
. p. 24.
doi
10.17487/RFC6455
RFC
6455
Client requirement 6.
IETF
. p. 18.
doi
10.17487/RFC6455
RFC
6455
Server step 5.3
IETF
. p. 24.
doi
10.17487/RFC6455
RFC
6455
Client requirement 5.
IETF
. p. 17.
doi
10.17487/RFC6455
RFC
6455
Server step 5.2
IETF
. p. 24.
doi
10.17487/RFC6455
RFC
6455
Client requirement 10.
IETF
. p. 18.
doi
10.17487/RFC6455
RFC
6455
Client requirement 11.
IETF
. p. 19.
doi
10.17487/RFC6455
RFC
6455
Sec-WebSocket-Extensions
IETF
. sec. 11.3.2.
doi
10.17487/RFC6455
RFC
6455
Extensions
IETF
. sec. 9.
doi
10.17487/RFC6455
RFC
6455
Negotiating Extensions
IETF
. sec. 9.1.
doi
10.17487/RFC6455
RFC
6455
"Main Goal of WebSocket protocol"
. IETF.
Archived
from the original on 22 April 2016
. Retrieved
25 July
2015
The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.
Fragmentation
IETF
. sec. 5.4.
doi
10.17487/RFC6455
RFC
6455
John A. Tamplin; Takeshi Yoshino (2013).
A Multiplexing Extension for WebSockets
IETF
. I-D draft-ietf-hybi-websocket-multiplexing.
Base Framing Protocol
IETF
. sec. 5.2.
doi
10.17487/RFC6455
RFC
6455
FIN
IETF
. p. 28.
doi
10.17487/RFC6455
RFC
6455
RSV1, RSV2, RSV3
IETF
. p. 28.
doi
10.17487/RFC6455
RFC
6455
Mask
IETF
. p. 29.
doi
10.17487/RFC6455
RFC
6455
Payload length
IETF
. p. 29.
doi
10.17487/RFC6455
RFC
6455
Client-to-Server Masking
IETF
. sec. 5.3.
doi
10.17487/RFC6455
RFC
6455
frame-opcode
IETF
. p. 31.
doi
10.17487/RFC6455
RFC
6455
Opcode
IETF
. p. 29.
doi
10.17487/RFC6455
RFC
6455
Extensibility
IETF
. sec. 5.8.
doi
10.17487/RFC6455
RFC
6455
Control Frames
IETF
. sec. 5.5.
doi
10.17487/RFC6455
RFC
6455
The WebSocket Closing Handshake is Started
IETF
. sec. 7.1.3.
doi
10.17487/RFC6455
RFC
6455
Closing Handshake
IETF
. sec. 1.4.
doi
10.17487/RFC6455
RFC
6455
Close
IETF
. sec. 5.5.1.
doi
10.17487/RFC6455
RFC
6455
Ping
IETF
. sec. 5.5.2.
doi
10.17487/RFC6455
RFC
6455
Pong
IETF
. sec. 5.5.3.
doi
10.17487/RFC6455
RFC
6455
"Ping and Pong frames"
WHATWG WebSockets
Overview
IETF
. sec. 5.1.
doi
10.17487/RFC6455
RFC
6455
Reserved Status Code Ranges
IETF
. sec. 7.4.2.
doi
10.17487/RFC6455
RFC
6455
Defined Status Codes
IETF
. sec. 7.4.1.
doi
10.17487/RFC6455
RFC
6455
Compression Extensions for WebSocket
IETF
doi
10.17487/RFC7692
RFC
7692
Dirkjan Ochtman (May 27, 2011).
"WebSocket enabled in Firefox 6"
Mozilla.org
. Archived from
the original
on 2012-05-26
. Retrieved
2011-06-30
"Chromium Web Platform Status"
Archived
from the original on 2017-03-04
. Retrieved
2011-08-03
"WebSockets (Windows)"
. Microsoft. 2012-09-28.
Archived
from the original on 2015-03-25
. Retrieved
2012-11-07
"WebSockets Protocol Test Report"
. Tavendo.de. 2011-10-27. Archived from
the original
on 2016-09-22
. Retrieved
2011-12-10
Katie Marsal (November 23, 2010).
"Apple adds accelerometer, WebSockets support to Safari in iOS 4.2"
AppleInsider.com
Archived
from the original on 2011-03-01
. Retrieved
2011-05-09
"Web Sockets API"
BlackBerry
. Archived from
the original
on June 10, 2011
. Retrieved
8 July
2011
Chris Heilmann (December 8, 2010).
"WebSocket disabled in Firefox 4"
Hacks.Mozilla.org
Archived
from the original on 2017-03-06
. Retrieved
2011-05-09
Aleksander Aas (December 10, 2010).
"Regarding WebSocket"
My Opera Blog
. Archived from
the original
on 2010-12-15
. Retrieved
2011-05-09
Wang, Vanessa; Salim, Frank; Moskovits, Peter (February 2013).
"APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools"
The Definitive Guide to HTML5 WebSocket
. Apress.
ISBN
978-1-4302-4740-1
. Archived from
the original
on 31 December 2015
. Retrieved
7 April
2013
"WebSockets (support in Firefox)"
developer.mozilla.org
. Mozilla Foundation. 2011-09-30. Archived from
the original
on 2012-05-26
. Retrieved
2011-12-10
"Bug 640003 - WebSockets - upgrade to ietf-06"
. Mozilla Foundation. 2011-03-08.
Archived
from the original on 2021-04-01
. Retrieved
2011-12-10
"WebSockets - MDN"
developer.mozilla.org
. Mozilla Foundation. 2011-09-30. Archived from
the original
on 2012-05-26
. Retrieved
2011-12-10
"Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)"
. Mozilla Foundation. 2011-07-22.
Archived
from the original on 2021-04-01
. Retrieved
2011-07-28
"Chromium bug 64470"
code.google.com
. 2010-11-25.
Archived
from the original on 2015-12-31
. Retrieved
2011-12-10
"WebSockets in Windows Consumer Preview"
IE Engineering Team
. Microsoft. 2012-03-19.
Archived
from the original on 2015-09-06
. Retrieved
2012-07-23
"WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17"
trac.webkit.org
Archived
from the original on 2012-01-05
. Retrieved
2011-12-10
"A hot Opera 12.50 summer-time snapshot"
. Opera Developer News. 2012-08-03. Archived from
the original
on 2012-08-05
. Retrieved
2012-08-03
"Welcome to nginx!"
nginx.org
. Archived from
the original
on 17 July 2012
. Retrieved
3 February
2022
"Using NGINX as a WebSocket Proxy"
NGINX
. May 17, 2014.
Archived
from the original on October 6, 2019
. Retrieved
November 3,
2019
"Overview of new features in Apache HTTP Server 2.4"
Apache
Archived
from the original on 2020-11-11
. Retrieved
2021-01-26
"Changelog Apache 2.4"
Apache Lounge
Archived
from the original on 2021-01-22
. Retrieved
2021-01-26
"IIS 8.0 WebSocket Protocol Support"
Microsoft Docs
. 28 November 2012.
Archived
from the original on 2020-02-18
. Retrieved
2020-02-18
"Release-1 4 46 - Lighttpd - lighty labs"
Archived
from the original on 2021-01-16
. Retrieved
2020-12-29
"Release-1 4 65 - Lighttpd - lighty labs"
Archived
from the original on 2024-05-03
. Retrieved
2024-05-03
"WebSockets support in ASP.NET Core"
learn.microsoft.com
. Retrieved
2 May
2025
Christian Schneider (August 31, 2013).
"Cross-Site WebSocket Hijacking (CSWSH)"
Web Application Security Blog
Archived
from the original on December 31, 2016
. Retrieved
December 30,
2015
Peter Lubbers (March 16, 2010).
"How HTML5 Web Sockets Interact With Proxy Servers"
Infoq.com
. C4Media Inc.
Archived
from the original on 2016-05-08
. Retrieved
2011-12-10
Willy Tarreau (2010-07-06).
"WebSocket -76 is incompatible with HTTP reverse proxies"
ietf.org
(email). Internet Engineering Task Force.
Archived
from the original on 2016-09-17
. Retrieved
2011-12-10
Ian Fette (June 13, 2011).
"Sec-WebSocket-Key"
The WebSocket protocol, draft hybi-09
IETF
. sec. 11.4
. Retrieved
June 15,
2011
Archived
February 1, 2016, at the
Wayback Machine
External links
edit
IETF Hypertext-Bidirectional (HyBi) working group
RFC
6455
The WebSocket protocol – Proposed Standard published by the IETF HyBi Working Group
The WebSocket protocol
– Internet-Draft published by the IETF HyBi Working Group
The WebSocket protocol
– Original protocol proposal by Ian Hickson
The WebSocket API
Archived
2015-06-07 at the
Wayback Machine
– W3C
Working Draft
specification of the API
The WebSocket API
– W3C
Candidate Recommendation
specification of the API
WebSocket.org
Archived
2018-09-16 at the
Wayback Machine
WebSocket demos, loopback tests, general information and community
Web browsers
Features, standards & protocols
Features
Bookmarks
Extensions
Privacy mode
Web standards
HTML
v5
CSS
DOM
JavaScript
WebAssembly
Web storage
IndexedDB
WebGL
WebGPU
Protocols
HTTP
Encryption
third-party
OCSP
WebRTC
WebSocket
Active
Blink
-based
Proprietary
Google Chrome
Arc
Atlas
Avast
Cốc Cốc
Comet
Comodo
Ecosia
Epic
Huawei
Maxthon
Microsoft Edge
Opera
Mobile
Puffin
QQ
Samsung
Silk
Sleipnir
SRWare
UC
Vivaldi
Whale
Yandex
FOSS
Chromium
Brave
Dooble
Falkon
Otter
Supermium
ungoogled
Gecko
-based
Firefox
Floorp
GNU IceCat
LibreWolf
Midori
Mullvad
SlimBrowser
SeaMonkey
(uses unnamed Gecko
fork
Tor
Waterfox
Zen
Goanna
-based
Basilisk
K-Meleon
Pale Moon
WebKit
-based
Safari
GNOME Web
iCab
Orion
Multi-
engine
360
DuckDuckGo
Konqueror
Lunascape
NetFront
qutebrowser
Other
Dillo
eww
Flow
Ladybird
Links
Lynx
NetSurf
Opera Mini
w3m
Discontinued
Blink
-based
Beaker
Citrio
Flock
Redcore
Rockmelt
SalamWeb
Sputnik
Torch
Gecko
-based
Beonex
Camino
Classilla
Conkeror
Firefox Lite
Galeon
Ghostzilla
IceDragon
Kazehakase
Kylo
Lotus
MicroB
Minimo
Mozilla suite
PirateBrowser
Pogo
Strata
Swiftfox
TenFourFox
Timberwolf
Waterfox Classic
xB
MSHTML
-based
Internet Explorer
AOL
Deepnet
GreenBrowser
MediaBrowser
MSN Explorer
MSN Program Viewer
NeoPlanet
NetCaptor
SpaceTime
ZAC
WebKit
-based
Arora
BOLT
Dolphin
Fluid
Google TV
Iris
Mercury
Nokia Symbian
OmniWeb
Opera Coast
Origyn
QtWeb
Shiira
Steel
surf
Uzbl
WebPositive
xombrero
Other
abaco
Amaya
Arachne
Arena
Blazer
Cake
CM
Deepfish
Edge Legacy
ELinks
Gazelle
HotJava
IBM Home Page Reader
IBM WebExplorer
IBrowse
Internet Explorer for Mac
KidZui
Line Mode
Mosaic
MSN TV
NetPositive
Netscape
Skweezer
Skyfire
ThunderHawk
Vision
WinWAP
WorldWideWeb
List
Comparison
Category
Web interfaces
Server-side
Protocols
HTTP
v2
v3
Encryption
WebDAV
CGI
SCGI
FCGI
AJP
WSRP
WebSocket
Server APIs
C NSAPI
C ASAPI
C ISAPI
COM ASP
Jakarta Servlet
container
CLI OWIN
ASP.NET Handler
Python WSGI
Python ASGI
Ruby Rack
JavaScript JSGI
Perl PSGI
Portlet
container
Apache modules
mod_include
mod_jk
mod_lisp
mod_mono
mod_parrot
mod_perl
mod_php
mod_proxy
mod_python
mod_wsgi
mod_ruby
Phusion Passenger
Topics
Web service
vs.
Web resource
WOA
vs.
ROA
Open API
Webhook
Application server
comparison
Scripting
Client-side
Browser APIs
C NPAPI
LiveConnect
XPConnect
C NPRuntime
C PPAPI
NaCl
ActiveX
BHO
XBAP
Web APIs
WHATWG
Audio
Canvas
DOM
SSE
Video
WebSockets
Web messaging
Web storage
Web worker
XMLHttpRequest
W3C
DOM events
EME
File
Geolocation
IndexedDB
MSE
SVG
WebAssembly
WebAuthn
WebGPU
WebRTC
WebXR
Khronos
WebCL
WebGL
Others
Gears
Web SQL Database
(formerly W3C)
WebUSB
Topics
Ajax
and
Remote scripting
vs.
DHTML
Browser extension
Cross-site scripting
and
CORS
Hydration
Mashup
Persistent data
Web IDL
Scripting
Related topics
Frontend and backend
Microservices
REST
GraphQL
Push technology
Solution stack
Web page
Static
Dynamic
Web standards
Web API security
Web application
Rich
Single-page
Progressive
Web framework
Retrieved from "
Categories
Web standards
Application layer protocols
HTML5
Internet terminology
Network socket
Real-time web
Web development
2011 in computing
Hidden categories:
Webarchive template wayback links
Articles with short description
Short description matches Wikidata
WebSocket
Add topic