Протокол WebSocket получил свой номер RFC и опубликован в официальной библиотеке IETF как RFC 6455. Это означает, что черновик спецификаций признан вполне удачным, в целом стабильным и подходящим для стандартизации. Его дальнейшую судьбу будет отслеживать организация IETF, и впереди у потенциального стандарта — два этапа. После «предложенного стандарта» будут рассмотрены улучшения, которые представит сообщество, затем документ RFC может получить статус «драфта» (чернового стандарта) и, в конце концов, может быть признан как полноценный Стандарт Интернета (STD) — из нескольких тысяч кандидатов до такого статуса дожили всего 72.

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

С помощью WebSocket можно создавать интерактивные браузерные веб-приложения, которые постоянно обмениваются данными с сервером, но при этом не нуждаются в открытии нескольких HTTP-соединений, как XMLHttpRequest или <iframe>’ы.

В качестве авторов RFC 6455 указаны Ян Фетте из Google Security Team и Алексей Мельников (isode.com).

Искал интересную тему, заслуживающую внимания, чтобы получить инвайт на Хаброхабре и вот нашёл. Такой особенный случай мне пришлось недавно реализовать.

Постановка задачи: Получить доступ к узлам удалённой сети.

Здесь мы будем говорить о двух сетях, которые нужно объединить, одну из которых я буду называть «моя офисная сеть», а другую «удалённая сеть».
Системный администратор удалённой сети отказывается вносить наименьшие изменения, для подключения и единственное что можно сделать — это поместить своё оборудование в удалённой сети. Выход в интернет из этой сетиv4 производится через шлюз, который натит в мир. Нужно построить тоннель, между двумя офисами, чтобы узлы моей офисной сети могли получать доступ к узлам удалённой сети, при минимальных изменениях c обеих сторон.

Для выполнения задачи объединения двух сетей и построения виртуального тоннеля нужно использовать Virtual Private Network. В ходе поиска подходящего варианта подключения, для себя разделил VPN на два вида: клиент-серверный вариант и равноправный. В следующих моментах заключается принципиальное отличие:

• В равноправном VPN, использующем глобальную сеть интернет, нужно иметь один реальный IP адрес, для каждого из узлов (минимум 2-ва узла). Здесь соединение может быть инициировано каждой из сторон (именно поэтому я так и обозвал его, равноправный), их может быть больше двух.
• В клиент-серверном варианте, использующем глобальную сеть интернет, нужен только один реальный IP адрес, для сервера. Соединение здесь происходит по требованию клиента, сервер всегда ожидает, клиентов может быть больше одного.

Примечание1: В обоих вариантах должно соблюдается одно из условий (для клиент-серверного варианта, только для сервера):

• A. VPN peer, должен находится непосредственно на шлюзе (должно быть установлено дополнительное ПО, или устройство должно быть способно устанавливать нужный тип VPN соединений).
• B. Если же нет возможности запустить VPN peer непосредственно на шлюзе, нужно его сконфигурировать так, чтобы он смог пропускать порт на другое устройство, настроенное как VPN peer.

1 апреля, комиссия IETF выпустила две спцификации:

• Соглашение о компоновке трех буквенных аббривиатур по первым буквам из трех-словных терминов.
  RFC 5513 IANA Considerations for Three Letter Acronyms
• Экспериментальный протокол IPv6 через социальные сети.
  RFC 5514 IPv6 over Social Networks (IPoSN)