• event-driven architectures (EDA)

• response cannot be sent without request
• server cannot initiate the communication

• using transfer-encoding header in HTTP 1.1
• using End of File in HTTP 1.0
  (server omits content-lenght in the response)

					function checkUpdates(url) {
						var xhr = new XHMLHttpRequest();
						xhr.open('GET', url);
						xhr.onload = function() { ... };
						xhr.send()
					}
					
				  setInterval(function() { checkUpdates('/updates', 60000)});

• When new data is available, data is returend
• When no data is available, the response is empty
• Simple to implement but very inefficient

• Each XHR reqquest is a standalone HTTP request
• HTTP incurs ~850 bytes of overhead for request/response headers
• For example, 10 000 clients, each polling with 60 seconds interval:
• (850 bytes x 8 bits x 10000)/60 seconds = 1.13 Mbps
• Server process 167 requests per second at a rate of 1.13 Mbps throughput
• Message latency
• Depends on the interval, maximum is 60 seconds
• Decreasing the interval will put more overhead on the server

• server responds when an event or a timeout occurs
• saves computing resources at the server as well as network resources
• can be applied over HTTP persistent and non-persistent communication

• Better message latency when interval is not constant
• concurrent requests processing at the server
• Too many messages may result in worse results that XHR polling

• IETF defines
• W3C defines

• a new protocol
• browsers, web servers, and proxy servers need to support it
• a layer on top of TCP
• bi-directional communication between client and servers
• low-latency apps without HTTP overhead
• Web origin-based security model for browsers
• same origin policy, cross-origin resource sharing
• support multiple server-side endpoints

• WebSocket can be used over non-HTTP connections outside of browsers

• TLS and ALPN
• HTTP/1.1 connection upgrade

• server accepts the request and responds as follows

						HTTP/1.1 101 Switching Protocols
						Upgrade: websocket
						Connection: Upgrade
						Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
						Sec-WebSocket-Protocol: chat

• 101 Switching Protocols – status code for a successful upgrade
• Sec-WebSocket-Protocol – a sub-protocol that the server selected from the list of protocols in the request
• Sec-WebSocket-Accept – a key to prove it has received a client WebSocket handshake request
• Formula to compute Sec-WebSocket-Accept

						Sec-WebSocket-Accept = Base64Encode(SHA-1(Sec-WebSocket-Key + 
						  "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))

• SHA-1 – hashing function
• Base64Encode – Base64 encoding function
• "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" – magic number

• socket between the client and the "resource" at the server is established
• client and the server can both read and write from/to the socket
• No HTTP headers overhead

• Data transmitted in TCP packets (see RFC6455: )
• Contains payload length, closing frame, ping, pong, type of data (text/binary), etc. and payload (message data)

                          0                   1                   2                   3
					      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
					     +-+-+-+-+-------+-+-------------+-------------------------------+
					     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
					     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
					     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
					     | |1|2|3|       |K|             |                               |
					     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
					     |     Extended payload length continued, if payload len == 127  |
					     + - - - - - - - - - - - - - - - +-------------------------------+
					     |                               |Masking-key, if MASK set to 1  |
					     +-------------------------------+-------------------------------+
					     | Masking-key (continued)       |          Payload Data         |
					     +-------------------------------- - - - - - - - - - - - - - - - +
					     :                     Payload Data continued ...                :
					     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
					     |                     Payload Data continued ...                |
					     +---------------------------------------------------------------+							
						

• The smallest unit of communication, composed of a header and a paylod
• Payload carries all or part of a message

• A sequence of frames that map to a logical application message
• Messages decomposition into frames is done by client and server framing code
• Application is unaware of frames but only application messages

• FIN – indication whether the frame is final in the message
• opcode – type of frame: (text, binary, control frame, ping, pong)
• Mask bit indicates if the payload is masked (from client to server only)
• Payload length
• Masking key contains 32-bit key to mask the payload (if mask bit is set)
• Payload application data

• Second request needs to wait for the first request to finish
• See HTTP Pipelining in AM1 for more details

• Large messages can cause the head of line blocking on the client
• Messages can be split into more frames
• But frames cannot be interleaved

• You should:
• split large message into multiple application messages
• monitor amount of messages in the client's buffer
• send data when buffer is empty

• Problem with HTTP/1.x due to a restricted number of connections per origin

• clients to utilize WebSocket, supported by all modern browsers
• Hides complexity of WebSocket protocol for the developer

					// ws is a new URL schema for WebSocket protocol; 'chat' is a sub-protocol
					var connection = new WebSocket('ws://server.example.org/chat', 'chat');

					// When the connection is open, send some data to the server
					connection.onopen = function () {
					  // connection.protocol contains sub-protocol selected by the server
					  console.log('subprotocol is: ' + connection.protocol); 
					  connection.send('data'); 
					};
					
					// Log errors
					connection.onerror = function (error) {
					  console.log('WebSocket Error ' + error);
					};
					
					// Log messages from the server
					connection.onmessage = function (e) {
					  console.log('Server: ' + e.data);
					};
					
					...
					
					// closes the connection
					connection.close()

          var ws = new WebSocket('wss://example.com/socket');

          ws.onopen = function () {
            subscribeToApplicationUpdates(function(evt) { 
              if (ws.bufferedAmount == 0) 
                ws.send(evt.data); 
            });
          };          
        

• A call to send is asynchronous
• Multiple calls to send will fill the client buffer

• intermediaries are configured to timeout idle HTTP connections quickly
• This can be a problem for long-lived WebSocket connections

• Client's network, some networks may block WebSocket traffic
• We need a fallback strategy
• Proxies on the external network
• TLS may help, tunneling over secure end-to-end connection, WebSocket traffic can bypass intermediaries

• For example, set tunnel timeout to 1 hour on HAProxy

					defaults http
						timeout connect 30s
						timeout client  30s
						timeout server  30s
						timeout tunnel  1h