Вебсокеты: боевое применение

Example¶

Here’s a WebSocket server example. It reads a name from the client and sends a
message.

#!/usr/bin/env python

import asyncio
import websockets

@asyncio.coroutine
def hello(websocket, path):
    name = yield from websocket.recv()
    print("< {}".format(name))
    greeting = "Hello {}!".format(name)
    yield from websocket.send(greeting)
    print("> {}".format(greeting))

start_server = websockets.serve(hello, 'localhost', 8765)

asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

Here’s a corresponding client example.

#!/usr/bin/env python

import asyncio
import websockets

@asyncio.coroutine
def hello():
    websocket = yield from websockets.connect('ws://localhost:8765/')
    name = input("What's your name? ")
    yield from websocket.send(name)
    print("> {}".format(name))
    greeting = yield from websocket.recv()
    print("< {}".format(greeting))
    yield from websocket.close()

asyncio.get_event_loop().run_until_complete(hello())

Note

On the server side, the handler coroutine is executed once for
each WebSocket connection. The connection is automatically closed when the
handler returns.

You will almost always want to process several messages during the
lifetime of a connection. Therefore you must write a loop. Here are the
recommended patterns to exit cleanly when the connection drops, either
because the other side closed it or for any other reason.

For receiving messages and passing them to a coroutine:

@asyncio.coroutine
def handler(websocket, path):
    while True
        message = yield from websocket.recv()
        if message is None
            break
        yield from consumer(message)

returns
when the connection is closed. In other words, marks the end of
the message stream. The handler coroutine should check for that case and
return when it happens.

For getting messages from a coroutine and sending them:

@asyncio.coroutine
def handler(websocket, path):
    while True
        message = yield from producer()
        if not websocket.open
            break
        yield from websocket.send(message)

fails with an
exception when it’s called on a closed connection. Therefore the handler
coroutine should check that the connection is still open before attempting
to write and return otherwise.

Of course, you can combine the two patterns shown above to read and write
messages on the same connection:

@asyncio.coroutine
def handler(websocket, path):
    while True
        listener_task = asyncio.ensure_future(websocket.recv())
        producer_task = asyncio.ensure_future(producer())
        done, pending = yield from asyncio.wait(
            listener_task, producer_task],
            return_when=asyncio.FIRST_COMPLETED)

        if listener_task in done
            message = listener_task.result()
            if message is None
                break
            yield from consumer(message)
        else
            listener_task.cancel()

        if producer_task in done
            message = producer_task.result()
            if not websocket.open
                break
            yield from websocket.send(message)
        else
            producer_task.cancel()

(This code looks convoluted. If you know a more straightforward solution,
please let me know about it!)

Browser-based example¶

Here’s an example of how to run a WebSocket server and connect from a browser.

Run this script in a console:

#!/usr/bin/env python

# WS server that sends messages at random intervals

import asyncio
import datetime
import random
import websockets

async def time(websocket, path):
    while True
        now = datetime.datetime.utcnow().isoformat() + "Z"
        await websocket.send(now)
        await asyncio.sleep(random.random() * 3)

start_server = websockets.serve(time, "127.0.0.1", 5678)

asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

Then open this HTML file in a browser.

Бизнес-кейс

Чтобы быстро добавлять новые виджеты в биржевое приложение и подключать их без перераспределения всей платформы, нужно, чтобы они были автономными и управляли своим собственным механизмом ввода-вывода данных.

Виджеты никак не связаны друг с другом. В идеале они все должны быть подписаны на какую-либо конечную точку API и начинать получать данные от нее.

Но при этом число подключений будет увеличиваться с ростом количества виджетов. Поэтому необходимо установить ограничение для браузеров по количеству одновременно обрабатываемых HTTP-запросов.

Данные, которые получат виджеты, в основном состоят из чисел и обновлений для этих чисел: первоначальный ответ содержит 10 акций со значениями их котировок.

Также данные должны включать в себя возможность добавления / удаления торгуемых акций, а также обновление текущих котировок. Мы передаем небольшое количество JSON-строк для каждого обновления так быстро, как это возможно.

HTTP / 2 обеспечивает мультиплексирование запросов, поступающих от одного домена. То есть, мы можем получить одно соединение для нескольких ответов.

Начнем с изучения различных вариантов получения данных и посмотрим, что может дать каждый из них.

• Мы собираемся использовать NGINX для балансировки нагрузки и реализации прокси, чтобы скрыть все конечные точки за одним и тем же доменом.
• Мы хотим эффективно использовать сетевой трафик и потребление заряда батареи пользовательского устройства.

Opening handshake

Before starting the exchange of messages, the client and server negotiate the parameters of the establishing connection. WebSocket reuses the existing HTTP Upgrade mechanism with custom Sec-WebSocket-* headers to perform the connection negotiation.

An example of an HTTP to WebSocket upgrade request:

GET /socket HTTP/1.1Host: server.comConnection: UpgradeUpgrade: websocket Origin: http://example.comSec-WebSocket-Version: 8, 13Sec-WebSocket-Key: 7c0RT+Z1px24ypyYfnPNbw==Sec-WebSocket-Protocol: v10.stomp, v11.stomp, v12.stompSec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

An example of an HTTP to WebSocket upgrade response:

HTTP/1.1 101 Switching Protocols Connection: UpgradeUpgrade: websocketAccess-Control-Allow-Origin: http://example.comSec-WebSocket-Accept: O1a/o0MeFzoDgn+kCKR91UkYDO4=Sec-WebSocket-Protocol: v12.stompSec-WebSocket-Extensions: permessage-deflate;client_max_window_bits=15

The opening handshake consists of the following parts: protocol upgrade, origin policies negotiation, protocol negotiation, subprotocol negotiation, extensions negotiation.

To pass the protocol upgrade:

• the client sends a request with the Connection and Upgrade headers
• the server confirms the protocol upgrade with 101 Switching Protocols response line and the same Connection and Upgrade headers

To pass the origin policies negotiation:

• the client sends the Origin header (scheme, host name, port number)
• the server confirms that the client from this origin is allowed to access the resource via the Access-Control-Allow-Origin header

To pass the protocol negotiation:

• the client sends the Sec-WebSocket-Version (a list of protocol versions, 13 for RFC 6455) and Sec-WebSocket-Key (an auto-generated key) headers
• the server confirms the protocol by returning the Sec-WebSocket-Accept header

Base64       .getEncoder()       .encodeToString(               MessageDigest                       .getInstance("SHA-1")                       .digest((secWebSocketKey + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11")                               .getBytes(StandardCharsets.UTF_8)));

To pass subprotocol negotiation:

• the client sends a list of subprotocols via the Sec-WebSocket-Protocol header
• the server select one of the subprotocols via the Sec-WebSocket-Protocol header (if the server does not support any subprotocol, then the connection is canceled)

To pass the extensions negotiation:

• the client sends a list of extensions via the Sec-WebSocket-Extensions header
• the server confirms one or more extensions via the Sec-WebSocket-Extensions header (if the server does not support some extensions, then the connection proceeds without them)

After a successful handshake, the client and the server switch from text HTTP protocol to binary WebSocket message framing and can perform full-duplex communication.

Рукопожатие

Для того, чтобы клиент смог установить соединение с сервером, по протоколу WebSocket, нужно перевести http сервер в этот режим работы. Чтобы это сделать, нужно отправить GET запрос со специальными заголовками. Но чтобы понять, какие заголовки отправляются на сервер из браузера, при попытки установить сокетное соединение, не будем сразу смотреть в спецификацию к протоколу, а начнем писать сервер и увидем эти заголовки в консоли. Для начала напишем http сервер, который будет принимать любой запрос и выводить в консоль заголовки этого запроса. Код я буду писать на typescript и запускать с помощью ts-node.

Сервер будет запущен на порту 8080. Теперь откроем консоль разработчика в браузере и напишем следующий код.

При создании объекта класса WebSocket, браузер попытается подключиться к серверу. У полученного объекта можно посмотреть текущее состояние подключения с помощью свойства readyState. Это свойство может принимать одно из четырех значений:

• — установка соединения
• 1 — соединение установлено. Данные можно передавать
• 2 — соединение находится в процессе закрытия
• 3 — соединение закрыто

В консоли с запущенным сервером получим следующее:

• sec-websocket-version версия проткола. На текущий момент это 13я версия
• sec-websocket-extensions список расширений протокола, которые хочет использовать клиент. В данном случае, это сжатие сообщений
• sec-websocket-protocol в этом заголовки клиент может передать список подпротоколов, на которых клиент хочет общаться с сервером. При этом сервер, если поддерживает эти подпротоколы, должен выбрать один из переданных и отправить его название в заголовках ответа. Подпротокол — это формат данных, в котором будут отправляться и приниматься сообщения.
• sec-websocket-key самый важный заголовок для установки подключения. В нем передаётся случайный ключ. Этот ключ должен быть уникальным для каждого рукопожатия.

Чтобы клиент понял, что сервер успешно перешел на нужный протокол, сервер должен ответить кодом 101, а в ответе должен быть заголовок sec-websocket-accept, значение которого сервер должен сформировать, используя заголовок sec-websocket-key следующим образом:

1. Добавить к заголовку sec-websocket-key константу 258EAFA5-E914-47DA-95CA-C5AB0DC85B11
2. Получить хеш sha-1 полученного объединенного значения
3. Перевести полученный хеш в строку в кодировке base64

Так же сервер должен передать в заголовках ответа заголовки Upgrade: WebSocket и Connection: Upgrade. Звучит не сложно, давайте реализуем. Для генерации загловка sec-websocket-key нам потребуется встроеный в node.js модуль crypto. Необходимо в начале импортировать его.

А затем изменить конструктор класса SocketServer

У http сервера Node.js есть специальное событие на upgrade соединения, используем его. Перезапустив сокет сервер с этими изменениями и снова попытавшись создать соединение в браузере, мы получим объект сокета, который будет в состоянии 1. Мы успешно создали соединение с нашим сервером и завершили первый этап. Переёдем ко второму.

Краткая история веб-приложений реального времени

Интернет был построен на представлении о том, что забота браузера– запрос данных с сервера, а забота сервера – обслуживание этих запросов. Эта парадигма не подвергалась сомнению несколько лет. Но с появлением AJAX в 2005 году многие начали работать над созданием двунаправленных соединений.

Веб-приложения значительно увеличивались в размере. Сдерживающим фактором для их роста была традиционная модель HTTP. Чтобы преодолеть это, были созданы несколько стратегий, позволяющих серверам «проталкивать» (push) данные клиенту. Одной из наиболее популярных стала стратегия «длинного опроса». Она подразумевает поддержание HTTP- соединения открытым до тех пор,пока у сервера есть данные для отправки клиенту.

Но все эти технологии приводят к перегрузке HTTP. Каждый раз, когда вы делаете запрос HTTP, набор заголовков и cookie передаются на сервер. Они накапливаются в большие массивы информации, которые нужно передать. Это увеличивает время ожидания, что может быть критично для равномерной работы приложения.

Чтобы решить данную проблему, нужен был способ создания постоянного соединения с минимальными задержками, которое могло бы поддерживать транзакции, инициированные как клиентом, так и сервером. Это как раз то, что предоставляют веб-сокеты.

Synchronization example¶

A WebSocket server can receive events from clients, process them to update the
application state, and synchronize the resulting state across clients.

Here’s an example where any client can increment or decrement a counter.
Updates are propagated to all connected clients.

The concurrency model of guarantees that updates are
serialized.

Run this script in a console:

#!/usr/bin/env python

# WS server example that synchronizes state across clients

import asyncio
import json
import logging
import websockets

logging.basicConfig()

STATE = {"value" }

USERS = set()


def state_event():
    return json.dumps({"type" "state", **STATE})


def users_event():
    return json.dumps({"type" "users", "count" len(USERS)})


async def notify_state():
    if USERS  # asyncio.wait doesn't accept an empty list
        message = state_event()
        await asyncio.wait()


async def notify_users():
    if USERS  # asyncio.wait doesn't accept an empty list
        message = users_event()
        await asyncio.wait()


async def register(websocket):
    USERS.add(websocket)
    await notify_users()


async def unregister(websocket):
    USERS.remove(websocket)
    await notify_users()


async def counter(websocket, path):
    # register(websocket) sends user_event() to websocket
    await register(websocket)
    try
        await websocket.send(state_event())
        async for message in websocket
            data = json.loads(message)
            if data"action" == "minus"
                STATE"value" -= 1
                await notify_state()
            elif data"action" == "plus"
                STATE"value" += 1
                await notify_state()
            else
                logging.error("unsupported event: %s", data)
    finally
        await unregister(websocket)


start_server = websockets.serve(counter, "localhost", 6789)

asyncio.get_event_loop().run_until_complete(start_server)
asyncio.get_event_loop().run_forever()

Then open this HTML file in several browsers.

A simple example

To open a websocket connection, we need to create using the special protocol in the url:

There’s also encrypted protocol. It’s like HTTPS for websockets.

Always prefer

The protocol is not only encrypted, but also more reliable.

That’s because data is not encrypted, visible for any intermediary. Old proxy servers do not know about WebSocket, they may see “strange” headers and abort the connection.

On the other hand, is WebSocket over TLS, (same as HTTPS is HTTP over TLS), the transport security layer encrypts the data at sender and decrypts at the receiver. So data packets are passed encrypted through proxies. They can’t see what’s inside and let them through.

Once the socket is created, we should listen to events on it. There are totally 4 events:

• – connection established,
• – data received,
• – websocket error,
• – connection closed.

…And if we’d like to send something, then will do that.

Here’s an example:

For demo purposes, there’s a small server server.js written in Node.js, for the example above, running. It responds with “Hello from server, John”, then waits 5 seconds and closes the connection.

So you’ll see events → → .

That’s actually it, we can talk WebSocket already. Quite simple, isn’t it?

Now let’s talk more in-depth.

Реализация клиента на Javascript

Протокол веб-сокет создан уже давно (приобрёл статус RFC в 11.12.2011) и поддерживается большинством браузеров.
Чтобы узнать поддерживает ли ваш браузер веб-сокеты перейдите по .

Работа в браузерах с вебсокетам проходит в несколько этапов:

• Установка соединения или рукопожатие (handshake).
• Создание обработчиков событий: onopen (соединение создано), onclose(соединение закрыто), onmessage (пришло сообщение от сервера), onerror (ошибка при работе веб-сокетов).
• Отправка сообщений (фреймов) на сервер.

Тестировать веб-сокеты мы будем на сервере websocket.org «ws://echo.websocket.org», который будет принимать от нас сообщения и отвечать на них повторением сообщением.
Этот сайт как раз существует, что лучше понять веб-сокеты, он понимает кросс-доменные запросы, поэтому страницу с JavaScript будем размещать у себя на локальном компьютере.

Этап. Рукопожатие

Чтобы создать соединение по веб-сокету достаточно создать объект WebSocket, в котором указывается урл для подключения.

Используйте протокол «ws://», если нужно не шифрованное соединение или протокол «wss://» для шифрованного соединения.

Этап. Создание обработчиков событий.

После того как мы создали объект WebSocket необходимо повесить функции-обработчики на события.

Если нужно повесить несколько функций на событие используем методы «addEventListener» и «removeEventListener». Пример:

Этап. Отправка сообщений на сервер

По веб-сокету сообщения отправляются в виде строки. Пример отправки простого текстового сообщения.

Обработка приходящих данных лежит уже на стороне сервера. Чаще для удобства работы по вебсокету отправляют JSON данные серилизованные в строку и обрабатывают приходящие данные как строка в JSON-e. Пример использования:

Удобный способ отправки сообщений по веб-сокету служит протокол «JSON-RPC» (ссылка). Это очень простой протокол, который облегчит взаимодействие браузера и сервера. Пример использования JSON RPC:

Параметры json-rpc объекта:

• jsonrpc — версия протокола, может быть «2.0» или «1.0»
• id — идентификатор запроса. Используется для идентификации ответа от сервера по своем запросу. Т.е. если отправить два запроса, то ответ от сервера по каждому запросу прийдёт в разное время, для этого и нужен id. На сервере необходимо учитывать этот параметр и в ответ прислать именно нужный id.
• method — наименование метода, любая строка, к примеру «get», «hello», «set» и др.
• params — параметры связанные с этим методом, тип переменной может быть любой, всё зависит от сервера.

Чтобы закрыть соединение используем метод close().

Все определения WSS

Акроним	Определение
WSS	Web Security Suite
WSS	Web Services симпозиум
WSS	Windaroo Государственная школа
WSS	WindowsSoundSystem
WSS	Woongoolba Государственная школа
WSS	Worongary Государственная школа
WSS	Безопасность веб-служб
WSS	Безопасность системы водоснабжения
WSS	Ван станции наборы
WSS	Веб службы Планировщик
WSS	Веб-самообслуживания
WSS	Вес воспринимая систему
WSS	Вестсайдская история
WSS	Взвешенный сигнал подпространство
WSS	Воде и санитарным услугам
WSS	Водоснабжение и санитария
WSS	Войны экономия штамп
WSS	Всемирная встреча на высшем уровне
WSS	Выбор состояния ожидания
WSS	Датчик скорости колеса
WSS	Длина волны селективный выключатель
WSS	Еженедельного статистического приложения
WSS	Западная Государственная школа
WSS	Мир общество позвоночника
WSS	Моделирование Спутниковое WDS
WSS	Ну стимуляции услуги
WSS	Оптовая доставка система
WSS	Оружие системы моделирования
WSS	Почему так грустно
WSS	Рабочая станция-сервер
WSS	Сайт для хранения оружия
WSS	Самообслуживание на рабочем месте
WSS	Сварные специальные разделы
WSS	Свинг западного общества
WSS	Секция стандартизации оружия
WSS	Сервер подписки Погода
WSS	Синдром морщинистой кожи
WSS	Система беспроводного абонента
WSS	Система поддержки вафельные
WSS	Система поддержки войны/оружие
WSS	Система программного обеспечения рабочих станций
WSS	Системы Уолл-стрит
WSS	Системы веб-хранилища
WSS	Службы Windows Sharepoint Services
WSS	Смарт-стандарты работы
WSS	Смотреть станции стандартов
WSS	Средневзвешенная склоне спектральной
WSS	Стандарта сервера приложений WebSphere
WSS	Уайт Салфер Спрингс
WSS	Уивер — синдром Смит
WSS	Уинстон-Сейлем круизной железнодорожная компания
WSS	Услуги во всем мире ценных бумаг
WSS	Что она сказала
WSS	Широкий космических систем
WSS	Широкий экран сигнализации
WSS	Широком смысле стационарные
WSS	Широкополосные стерео сигнала
WSS	Эскадрилья Погода

Что означает WSS в тексте

В общем, WSS является аббревиатурой или аббревиатурой, которая определяется простым языком. Эта страница иллюстрирует, как WSS используется в обмена сообщениями и чат-форумах, в дополнение к социальным сетям, таким как VK, Instagram, Whatsapp и Snapchat. Из приведенной выше таблицы, вы можете просмотреть все значения WSS: некоторые из них образовательные термины, другие медицинские термины, и даже компьютерные термины. Если вы знаете другое определение WSS, пожалуйста, свяжитесь с нами. Мы включим его во время следующего обновления нашей базы данных. Пожалуйста, имейте в информации, что некоторые из наших сокращений и их определения создаются нашими посетителями. Поэтому ваше предложение о новых аббревиатур приветствуется! В качестве возврата мы перевели аббревиатуру WSS на испанский, французский, китайский, португальский, русский и т.д. Далее можно прокрутить вниз и щелкнуть в меню языка, чтобы найти значения WSS на других 42 языках.

Node.js WebSocket Example

Writing socket code is fun, but when you’re trying to implement it in a web browser, it’s kind of complicated. This issue has been addressed by all major browsers in their action to support the WebSocket protocol out of the box! This way, web pages that use sockets can load really fast because the front end libraries for handling the protocol are already in the browser applications. No need to fetch big JS libraries whenever a user visits your real-time app web page.

Node.js WebSocket Server

Let’s swap out our Node.js socket server code for WebSocket server code! This way, we will be able to easily serve our web browser users. We’ll go over some vanilla JS for WebSockets that can be implemented in something like a React.js application.

This code uses the Node.js native “http” library and a 3rd party WebSocket NPM package to create a WebSocket server. It has the same functionality as the socket script we wrote earlier. This time, we are using the official WebSocket protocol to bi-directionally send our data between client and server.

// Node.js WebSocket server script
const http = require('http');
const WebSocketServer = require('websocket').server;

const server = http.createServer();
server.listen(9898);

const wsServer = new WebSocketServer({
    httpServer: server
});

wsServer.on('request', function(request) {
    const connection = request.accept(null, request.origin);

    connection.on('message', function(message) {
      console.log('Received Message:', message.utf8Data);
      connection.sendUTF('Hi this is WebSocket server!');
    });
    connection.on('close', function(reasonCode, description) {
        console.log('Client has disconnected.');
    });
});

Node.js WebSocket Browser Client

Next, we have our HTML file that loads up in client web browsers. Notice that the WebSocket class in the browser JS has no declaration. This is because modern browsers give developers automatic access to this class in their front-end JavaScript!

<!DOCTYPE html>
<html>
<head>
  <title>WebSocket Playground</title>
</head>
<body>

</body>
<script>

const ws = new WebSocket('ws://localhost:9898/');

ws.onopen = function() {
    console.log('WebSocket Client Connected');
    ws.send('Hi this is web client.');
};

ws.onmessage = function(e) {
  console.log("Received: '" + e.data + "'");
};

</script>
</html>

We can get our fun client-server handshake example going fast! Here’s what the output for the server script and the web browser JS console look like:

Метод первый, напрямую использовать Workerman для открытия SSL

Готов к работе:

1. Версия Workerman не ниже 3.3.7

2. PHP устанавливает расширение openssl

3. Сертификат (файл pem / crt и файл ключа) был подан и помещен в любой каталог на диске.

Код:

С помощью приведенного выше кода Workerman отслеживает протокол wss, а клиент может подключаться к workerman через протокол wss для реализации безопасного обмена мгновенными сообщениями.

тест

Откройте браузер Chrome, нажмите F12, чтобы открыть консоль отладки, введите в столбце Console (или поместите следующий код на страницу html для запуска с js)

нота:

1. Если не запускается, порт 443 обычно занят. Переключитесь на другой порт

Обратите внимание, что после перехода на другой порт клиенту необходимо указать номер порта при подключении. Адрес при подключении клиента похож на wss: //domain.com: xxx, xxx — номер порта

Если вы должны использовать порт 443, используйте второй метод для реализации wss в качестве прокси.

2. К порту wss можно получить доступ только через протокол wss, а ws не может получить доступ к порту wss.

3. Сертификат обычно привязан к имени домена, поэтому при тестировании клиента используйте для подключения имя домена вместо ip.

4. Если вы не можете получить доступ, проверьте брандмауэр сервера.

5. Для этого метода требуется версия PHP> = 5.6, поскольку апплет WeChat требует tls1.2, а версии ниже PHP5.6 не поддерживают tls1.2.

Summary

WebSocket is a modern way to have persistent browser-server connections.

• WebSockets don’t have cross-origin limitations.
• They are well-supported in browsers.
• Can send/receive strings and binary data.

The API is simple.

Methods:

• ,
• .

Events:

• ,
• ,
• ,
• .

WebSocket by itself does not include reconnection, authentication and many other high-level mechanisms. So there are client/server libraries for that, and it’s also possible to implement these capabilities manually.

Sometimes, to integrate WebSocket into existing project, people run WebSocket server in parallel with the main HTTP-server, and they share a single database. Requests to WebSocket use , a subdomain that leads to WebSocket server, while goes to the main HTTP-server.

Surely, other ways of integration are also possible.

The WebSocket Protocol

The WebSocket protocol was designed to work well with the existing Web infrastructure. As part of this design principle, the protocol specification defines that the WebSocket connection starts its life as an HTTP connection, guaranteeing full backwards compatibility with the pre-WebSocket world. The protocol switch from HTTP to WebSocket is referred to as a the WebSocket handshake.

GET ws://echo.websocket.org/?encoding=text HTTP/1.1
Origin: http://websocket.org
Cookie: __utma=99as
Connection: Upgrade
Host: echo.websocket.org
Sec-WebSocket-Key: uRovscZjNol/umbTt5uKmw==
Upgrade: websocket
Sec-WebSocket-Version: 13

If the server understands the WebSocket protocol, it agrees to the protocol switch through the Upgrade header.

HTTP/1.1 101 WebSocket Protocol Handshake
Date: Fri, 10 Feb 2012 17:38:18 GMT
Connection: Upgrade
Server: Kaazing Gateway
Upgrade: WebSocket
Access-Control-Allow-Origin: http://websocket.org
Access-Control-Allow-Credentials: true
Sec-WebSocket-Accept: rLHCkw/SKsO9GAH/ZSFhBATDKrU=
Access-Control-Allow-Headers: content-type

At this point the HTTP connection breaks down and is replaced by the WebSocket connection over the same underlying TCP/IP connection. The WebSocket connection uses the same ports as HTTP (80) and HTTPS (443), by default.

Changelog¶

2.6

• Added and attributes on protocols.
• Closed open connections with code 1001 when a server shuts down.
• Avoided TCP fragmentation of small frames.

2.5

• Improved documentation.
• Provided access to handshake request and response HTTP headers.
• Allowed customizing handshake request and response HTTP headers.
• Supported running on a non-default event loop.
• Returned a 403 error code instead of 400 when the request Origin isn’t
  allowed.
• Cancelling no
  longer drops the next message.
• Clarified that the closing handshake can be initiated by the client.
• Set the close status code and reason more consistently.
• Strengthened connection termination by simplifying the implementation.
• Improved tests, added tox configuration, and enforced 100% branch coverage.