Протокол ws: Написание клиентских приложений с помощью вебсокетов

Содержание

Протоколы WS-* — gRPC для разработчиков WCF

12/15/2020
Чтение занимает 2 мин

В этой статье

Одним из реальных преимуществ работы с Windows Communication Foundation (WCF) было поддержка множества существующих протоколов WS- * Standard.One of the real benefits of working with Windows Communication Foundation (WCF) was that it supported many of the existing WS-* standard protocols. В этом разделе кратко рассматривается, как gRPC управляет одними и теми же WS- * Protocols, и обсуждаются возможности, доступные при отсутствии альтернативы.This section will briefly cover how gRPC manages the same WS-* protocols and discuss what options are available when there’s no alternative.

Службы SOAP предоставляют документы схемы языка описания веб-служб (WSDL) со сведениями, такими как форматы данных, операции или варианты обмена данными.SOAP services expose Web Services Description Language (WSDL) schema documents with information such as data formats, operations, or communication options. Эту схему можно использовать для создания клиентского кода.You can use this schema to generate the client code.

gRPC лучше всего подходит, когда серверы и клиенты создаются из одних и тех же .proto файлов, но дополнительное расширение серверного отражения предоставляет способ предоставления динамической информации с работающего сервера.gRPC works best when servers and clients are generated from the same

.proto files, but a Server Reflection optional extension does provide a way to expose dynamic information from a running server. Дополнительные сведения см. в разделе пакет NuGet GRPC. Reflection и статья о серверном отражении GRPC C# .For more information, see the Grpc.

Reflection NuGet package and the gRPC C# Server Reflection article.

Протокол WS-Discovery используется для нахождение служб в локальной сети.The WS-Discovery protocol is used to locate services on a local network. службы gRPC находятся в DNS или реестре службы, например Consul или ZooKeeper.gRPC services are located through DNS or a service registry such as Consul or ZooKeeper.

Безопасность: WS-Security, WS-Federation, шифрование XML и т. д.Security: WS-Security, WS-Federation, XML Encryption, and so on

Сведения о безопасности, проверке подлинности и авторизации более подробно описаны в главе 6.Security, authentication, and authorization are covered in much more detail in chapter 6. Но стоит отметить, что, в отличие от WCF, gRPC не поддерживает шифрование WS-Security, WS-Federation или XML.But it’s worth noting here that, unlike WCF, gRPC doesn’t support WS-Security, WS-Federation, or XML Encryption. Несмотря на это, gRPC обеспечивает отличную безопасность.Even so, gRPC provides excellent security.

Весь сетевой трафик gRPC автоматически шифруется при использовании HTTP/2 через TLS.All gRPC network traffic is automatically encrypted when it’s using HTTP/2 over TLS. Сертификаты X509 можно использовать для взаимной проверки подлинности клиента или сервера.You can use X509 certificates for mutual client/server authentication.

WS-ReliableMessagingWS-ReliableMessaging

gRPC не предоставляет эквивалент WS-ReliableMessaging.gRPC does not provide an equivalent to WS-ReliableMessaging. Семантика повторных попыток должна обрабатываться в коде, возможно, с такой библиотекой, как Polly.Retry semantics should be handled in code, possibly with a library like Polly. При работе в Kubernetes или аналогичных средах оркестрации сети служб также могут помочь обеспечить надежный обмен сообщениями между службами.When you’re running in Kubernetes or similar orchestration environments, service meshes can also help to provide reliable messaging between services.

WS-Transaction, WS-CoordinationWS-Transaction, WS-Coordination

Реализация распределенных транзакций в WCF использует Microsoft координатор распределенных транзакций (MSDTC). WCF’s implementation of distributed transactions uses Microsoft Distributed Transaction Coordinator (MSDTC). Он работает с диспетчерами ресурсов, которые специально поддерживают такие службы, как SQL Server, MSMQ или файловые системы Windows.It works with resource managers that specifically support it, like SQL Server, MSMQ, or Windows file systems. В современных микрослужбах нет эквивалента, часть из-за широкого спектра используемых технологий.There’s no equivalent yet in the modern microservices world, in part due to the wider range of technologies in use. Обсуждение транзакций см. в приложении а.For a discussion of transactions, see Appendix A.

HP Web Jetadmin — Порты | Служба поддержки HP®

69	UDP	Ввод	Входящий порт TFTP. HP Web Jetadmin использует этот порт в качестве места хранения образов микропрограммного обеспечения при обновлении микропрограммного обеспечения HP Jetdirect. С помощью SNMP HP Web Jetadmin указывает HP Jetdirect получить микропрограммное обеспечение через этот порт.
80	TCP	Вывод	HP Web Jetadmin использует этот порт для определения связи со встроенным веб-сервером HP на устройстве и получения образов микропрограммного обеспечения из Интернета.
161	UDP	Вывод	SNMP. HP Web Jetadmin и другие приложения управления используют SNMP для связи с устройствами и управления ими. Этот порт принтера используется приложением HP Web Jetadmin для отправки команд Set и Get агенту SNMP.
427	UDP	Ввод	Прослушивание SLP. Подключенные к HP Jetdirect устройства используют протокол SLP, чтобы объявить о себе. При включении функции пассивного обнаружения SLP в HP Web Jetadmin устройства отправляют многоадресные пакеты в этот порт на сервере HP Web Jetadmin.
443	TCP	Исходящий	HTTPS. Службы HP Web Jetadmin и HPWSProAdapter отправляют конфигурации устройств и запросы через этот порт по протоколу HTTPS. HPWSProAdapter использует этот порт для взаимодействия с устройствами, которые не поддерживают веб-службы и настроены для перенаправления всего сетевого трафика через HTTPS.
843	TCP	Вывод	HP Web Jetadmin использует этот порт для настройки некоторых параметров, таких как факс и отправка цифровых материалов, на отдельных моделях многофункциональных устройств HP.
1433	UDP	Вывод	Microsoft SQL Server По умолчанию HP Web Jetadmin устанавливает базу данных SQL Server на одном узле. Кроме того, можно настроить HP Web Jetadmin для связи с базой данных SQL Server на другом узле. HP Web Jetadmin использует этот порт для упрощения связи с удаленной базой данных SQL Server.
2493	UDP	Ввод/вывод	Монитор сборки. Это порт сервера HP Web Jetadmin, который оставляется открытым. Другие серверы HP Web Jetadmin используют этот порт для обнаружения работающих экземпляров HP Web Jetadmin.
3702²	UDP	Вывод	WS-Discovery. HP Web Jetadmin использует этот порт для выполнения обнаружения Web Service Discovery на более новых устройствах HP.
3910², 3911	TCP	Вывод	WS-Discovery. HP Web Jetadmin использует этот порт для получения сведений о веб-службах (Web Services) устройства во время обнаружения. HP Web Jetadmin использует эти сведения для установления путей соединения WS, которые необходимы для управления устройствами. HP Web Jetadmin использует порт 3910 для получения запросов печати, а порт 3911 — для получения статуса принтера.
4088	TCP	Ввод	Удаленная связь. HP Web Jetadmin использует этот порт как основной канал связи между запущенным клиентом HP Web Jetadmin и его соответствующим сервером HP Web Jetadmin.
4089	TCP	Ввод	Уведомление клиента о событиях. HP Web Jetadmin использует этот порт для передачи сведений об изменениях с сервера HP Web Jetadmin клиенту. При этом клиент получает обновления с сервера через интерфейс удаленной связи. В предыдущих выпусках HP Web Jetadmin этот порт назначался операционной системой Windows.
7627²	TCP	Вывод	Веб-службы (HTTPS): HP Web Jetadmin использует этот порт для взаимодействия с устройствами HP FutureSmart и более ранними лазерными устройствами для некоторых операций, таких как OXPd. Для устройств, которые не поддерживают веб-службы, служба HPWSProAdapter выступает в качестве шлюза между HP Web Jetadmin и устройствами. Служба HPWSProAdapter получает запросы веб-служб от HP Web Jetadmin и затем передает преобразованные запросы на устройства через порт 8080 (незащищенное соединение, пароль встроенного веб-сервера HP не задан на устройствах) или порт 443 (защищенное соединение, пароль встроенного веб-сервера HP задан на устройствах).
8000	UDP	Вывод	Прослушивание обнаружения HP Web Jetadmin. HP Web Jetadmin использует этот порт на удаленных узлах IP для обнаружения более ранних версий программного обеспечения HP Web Jetadmin.
8000	TCP	Ввод	Веб-сервер: HP Web Jetadmin обеспечивает прослушивание HTTP для первоначального запуска клиента и содержимого онлайн-справки.
8050	TCP	Ввод	Обратный вызов событий устройства (HTTPS). Более новые устройства HP используют протокол WS-Eventing для передачи данных управления.
8080	TCP	Вывод	HPWSProAdapter. HPWSProAdapter использует этот порт для взаимодействия с устройствами, которые не поддерживают веб-службы и не настроены для перенаправления всего сетевого трафика через HTTPS. HP Web Jetadmin отправляет через этот порт конфигурации устройств и запросы.
8140	TCP	Ввод	Веб-службы OXPm (HTTP). Это порт связи для открытой платформы расширяемости HP (управление).
8143	TCP	Ввод	Веб-службы OXPm (HTTPS). Это безопасный порт связи для открытой платформы расширяемости HP (управление).
8443	TCP	Ввод	Безопасный веб-сервер (HTTPS). HP Web Jetadmin обеспечивает безопасное прослушивание HTTP для первоначального запуска клиента, содержимого справки и операций по передаче файлов устройств.
9100	TCP	Вывод	Обновление микропрограммного обеспечения принтера и операция с тестовым файлом. HP Web Jetadmin использует этот порт принтера для передачи файлов микропрограммного обеспечения принтера, файлов с тестовыми заданиями и файлов конфигурации PJL.
27892	UDP	Ввод	Прослушиватель ловушек. HP Web Jetadmin использует этот порт для предупреждений на базе SNMP и сборов данных пользователем.
27893	UDP	Ввод	Прослушиватель пакетов WS Hello HP Web Jetadmin осуществляет мониторинг этого порта для получения входящих пакетов WS Hello, которые отправляет ПО Прокси-агент HP WS Pro, установленное на хостах предприятия. Когда приложение HP Web Jetadmin находит пакет, оно пытается определить, присутствуют ли какие-либо обнаруживаемые принтеры на отправляющем хосте. Дополнительные сведения см. в разделе Файл информации Readme прокси-агентов HP Web Jetadmin 10.4. Этот документ доступен на странице поддержки HP Web Jetadmin (на английском языке).
59113	TCP	Вывод	Microsoft SQL Server По умолчанию HP Web Jetadmin устанавливает базу данных SQL Server на одном узле. Кроме того, можно настроить HP Web Jetadmin для связи с базой данных SQL Server на другом узле. HP Web Jetadmin использует этот порт для упрощения связи с удаленной базой данных SQL Server.

CLEARWAY INTEGRATION — Технологии

ADFS (Active Directory Federation Services) — это функция, представленная на Windows Server, которая обеспечивает решение идентификации доступа. Она дает возможность клиентам на базе браузеров, которые находятся внутри или за пределами локальной сети, получать доступ по технологии Single-Sign-On (SSO) к веб приложениям. В ADFS это достигается благодаря защищенному обмену цифровыми удостоверениями и правами (или «утверждениями», Claims) между партнерами, связанными федеративными отношениями.

Службы ADFS тесно интегрированы с Active Directory. ADFS извлекает атрибуты пользователей из Active Directory, а также проверяет подлинность пользователей в Active Directory. Кроме того, ADFS поддерживает встроенную проверку подлинности Windows.

В качестве стандарта для взаимодействия компонентов федерации, прикладных подсистем (проверяющих сторон) и клиентских приложений выбрана спецификация WS-Federation, входящая в составе стека протоколов WS-*, разработанного промышленным консорциумом при участии Microsoft, и базирующаяся на других протоколах данного стека, таких как WS-Security.

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

Служба федерации ADFS является компонентом серверной платформы Microsoft Windows Server, реализующим Сервис маркеров доступа (Security Token Service, STS) в соответствии со спецификацией WS-Trust, WS-Federation. Сервис маркеров доступа (СМД) использует службу каталога Active Directory для аутентификации пользователей и хранения информации о них.

Основными операциями, выполняемыми СМД, являются:

Первоначальная аутентификация пользователя
Выпуск маркера доступа (Issue)
Проверка маркера доступа (Validate)
Обновление маркера доступа (Renew)
Аннулирование маркера доступа (Cancel)

Маркер доступа выпускается СМД по факту успешной аутентификации пользователя. Маркер доступа однозначно связан с пользователем и достоверно идентифицирует пользователя приложения, являясь, одновременно, унифицированным форматом для передачи данных о пользователе в приложение. В качестве информации для подтверждения своей идентичности пользователь может использовать:

имя пользователя и пароль;
сертификат пользователя.

Маркер доступа соответствует спецификации SAML (SAML Token), которая базируется на XML и определяет синтаксис и структуру маркера. Данный формат является расширяемым, что позволяет формировать содержание маркера в соответствии с требованиями приложения, к которому осуществляется доступ. Маркер доступа зашифрован и подписан Сервисом маркеров доступа, которым он выпущен, для обеспечения подлинности маркера и целостности и конфиденциальности передаваемых в маркере данных. Срок действия маркера и область применения ограничены. Маркер доступа содержит информацию о пользователе в форме набора утверждений (Claims), которые используются приложением для создания контекста пользователя (в том числе для целей авторизации и персонификации). Приложение, или проверяющая сторона в ADFS (Relying Party, RP) — это прикладная система (веб-приложение или веб-сервис), которая использует внешний сервис аутентификации, доверяя ему аутентификацию пользователей, и является потребителем маркеров доступа, выдаваемых пользователям, успешно прошедшим аутентификацию СМД. Проверяющая сторона использует маркер доступа, включаемый в запрос пользователя к приложению, для создания контекста пользователя. Для проверяющих сторон, расположенных в одном домене безопасности, т.е. имеющих отношения доверия с общим Сервисом маркеров доступа, обеспечивается единая точка регистрации (Single Sign-on, SSO).

В процессе доступа к веб-приложению пересылаются следующие сообщения, относящиеся к ADFS:

Пользователь браузера пытается обратиться к приложению Web-сервера. Агент ADFS обнаруживает, что пользователь не прошел проверку подлинности в ADFS, и отсылает его на сервер федерации поставщика ресурсов.
На данном этапе, известном как обнаружение домашней области, пользователь браузера предоставляет информацию о своем домене серверу федерации поставщика ресурсов. Домашний домен — место, в котором определено и обслуживается удостоверение пользователя, иными словами, поставщик удостоверения пользователя. При первом подключении пользователя к веб-приложению пользователь предоставляет такие сведения, как имя поставщика удостоверения или адрес электронной почты. При последующих запросах сервер федерации поставщика ресурсов отыскивает эти данные в cookie-файле, переданном пользователем. В зависимости от данных, переданных в процессе обнаружения домашней области, сервер федерации поставщика ресурсов перенаправляет браузер пользователя на сервер федерации поставщика удостоверения для проверки подлинности.
Пользователь браузера проходит проверку подлинности в сервере федерации своего поставщика аутентификации с использованием своей учетной записи AD и соответствующих учетных данных.
Сервер федерации поставщика аутентификации проверяет учетные данные пользователя в AD. Если проверка завершается успешно, то сервер генерирует cookie-файл аутентификации и маркер безопасности ADFS.
Сервер федерации поставщика аутентификации формирует маркер безопасности и перенаправляет браузер пользователя вместе с маркером безопасности и cookie-файлом аутентификации на сервер федерации поставщика ресурсов.
Сервер федерации поставщика ресурсов преобразует заявку в маркере безопасности в набор заявок, распознаваемых веб-приложением, размещенным в поставщике ресурсов, и вставляет их в новый маркер безопасности. Этот процесс известен как преобразование заявки. Сервер федерации также генерирует cookie-файл аутентификации и перенаправляет пользователя браузера (вместе с новым маркером безопасности и cookie-файлом аутентификации) в агент ADFS Веб-приложения. Агент проверяет cookie-файл аутентификации, извлекает заявку из маркера безопасности и передает ее в веб-приложение.
Веб-приложение интерпретирует заявки в ходе проверки подлинности и передает соответствующие веб-материалы в браузер пользователя.

Многие компании заинтересованы в возможности обмениваться данными с доверенными внешними пользователями через Интернет. Клиентам удобно обращаться к ресурсам с использованием собственных учетных записей, не создавая учетных записей в чужой системе. Однако необходимо, чтобы доступ получали только проверенные пользователи.

Active Directory во многих организациях служит в качестве основной службы для хранения учетных данных и проверки подлинности. С помощью Active Directory доверие лесов может быть создано между двумя и более лесами для обеспечения доступа к ресурсам, расположенным в разных производственных подразделениях или организациях.

Однако в ряде случаев доверие лесов не является приемлемым типом отношений. Например, может потребоваться ограничить доступ к ресурсам, расположенным в разных организациях, только небольшим подмножеством пользователей, закрыв его для остальных членов леса. Именно в этих случаях ADFS является отличной заменой доверительным отношениям Active Directory.

Получить дополнительную информацию по описанной технологии и особенностях внедрения Вы можете здесь.

Проксирование WebSocket

Для превращения соединения между клиентом и сервером из HTTP/1.1 в WebSocket используется доступный в HTTP/1.1 механизм смены протокола.

Но есть сложность: поскольку “Upgrade” является hop-by-hop заголовком, то он не передаётся от клиента к проксируемому серверу. При прямом проксировании клиенты могут использовать метод CONNECT, чтобы обойти эту проблему. Однако при обратном проксировании такой подход не работает, так как клиент ничего о проксирующем сервере не знает, и требуется специальная обработка на проксирующем сервере.

Начиная с версии 1.3.13 в nginx предусмотрен особый режим работы, который позволяет установить туннель между клиентом и проксируемым сервером, если проксируемый сервер вернул ответ с кодом 101 (Switching Protocols), и клиент попросил сменить протокол с помощью заголовка “Upgrade” в запросе.

Как уже отмечалось выше, hop-by-hop заголовки, включая “Upgrade” и “Connection”, не передаются от клиента к проксируемому серверу, поэтому, для того чтобы проксируемый сервер узнал о намерении клиента сменить протокол на WebSocket, эти заголовки следует передать явно:

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Более сложный пример, в котором значение поля “Connection” в заголовке запроса к проксируемому серверу зависит от наличия поля “Upgrade” в заголовке запроса клиента:

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        . ..

        location /chat/ {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }

По умолчанию соединение будет закрыто, если с проксируемого сервера данные не передавались в течение 60 секунд. Этот таймаут можно увеличить при помощи директивы proxy_read_timeout. Кроме того, на проксируемом сервере можно настроить периодическую отправку WebSocket ping-фреймов для сброса таймаута и проверки работоспособности соединения.

Практика ИБ. Централизованный сбор логов с Windows-устройств

Руслан Рахметов, Security Vision

Коллеги, в предыдущей статье мы обсудили инвентаризацию ИТ-активов и кратко рассмотрели простейшие способы сбора технической информации с устройств. Разумеется, кроме сведений о самих активах, в целях решения задач информационной безопасности следует собирать и журналы аудита с контролируемых устройств. В данной статье мы рассмотрим централизованный сбор логов с Windows-устройств посредством использования штатного функционала Windows Event Forwarding и пересылку собранных событий в SIEM-систему (на примере IBM QRadar). Приступим!

Для начала следует напомнить читателям о том, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Microsoft предлагает использовать также бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Можно также пользоваться и веб-версией рекомендаций по настройке аудита.

Разумеется, рекомендуемые в «лучших практиках» настройки аудита следует привести в соответствие конкретной инфраструктуре: например, будет нецелесообразно включать аудит платформы фильтрации (т. е. встроенного брандмауэра Windows) в случае, если в компании применяется другое наложенное хостовое СЗИ с функционалом межсетевого экранирования. Не стоит забывать и о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Итак, настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и централизованного их хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т. н. «подписок» на определенные события (набор XPath-выражений для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull / Collector initiated), так и отправлены самим источником (режим Push / Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push на коллекторе служба WinRM слушает входящие соединения, а на клиентах-источниках WinRM не находится в режиме прослушивания и только периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальных атак на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» («Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled»), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы сборщика событий Windows. При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» («Windows Remote Management (WS-Management)»), при этом TCP:5985 не начинает слушаться.

4. Проверить состояние службы WinRM можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» («Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management»).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers ( «Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» («Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…») и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» («Subscriptions»). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Source Computer Initiated» (это означает предпочтительный режим Push). Нажимаем на кнопку «Select Computer Groups», выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Select Events» и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>

<Query Path=»Security»>

<Select Path=»Security»>*</Select>

</Query>

</QueryList>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На коллекторе в eventvwr.msc в разделе «Подписки» можно будет увидеть приходящие события с источников и список самих источников.

9. Далее, решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему (возьмем для примера SIEM security систему IBM QRadar (Курадар)). Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый («Managed») режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en—US (где SubscriptionName — имя подписки, заданное в п. 7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM Q Radar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника «Microsoft Security Event Log», в поле «Target Destination» в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box «Forwarded Events»).

После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.

Как создавать веб-сокеты в Python | by Iuliia Averianova | NOP::Nuances of Programming

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

Мы научимся настраивать собственный веб-сокет на Python, используя WebSockets API, который делает возможным двусторонний интерактивный сеанс связи между клиентом и сервером. С веб-сокетами вы можете отправлять и получать сообщения в режиме отслеживания событий без необходимости все время запрашивать данные у сервера, что уменьшает накладные расходы и позволяет передавать данные с сервера и на сервер в режиме реального времени.

Для работы с веб-сокетами требуется Python версии 3.6.1 и выше.

API в Python легко установить следующей командой:

pip install websockets

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

Я не буду затрагивать тему безопасности, и весь код будет на Python. Этого достаточно для понимания всеми, кто немного знаком с языком или с программированием в целом. Таким образом, в дальнейшем вам будет проще написать consumer, producer или даже сервер на другом языке или для фронтенд приложения.

Я надеюсь, что приведенные примеры будут вам полезны, и призываю разработчиков попробовать веб-сокеты хотя бы раз в своей карьере — они потрясающие. Это больше, чем REST, знаете ли!

Простой consumer сообщений

Итак, начнем с сопрограммы consumer, представленной выше. Я объясню каждую строку кода, чтобы вы смогли полностью понять, что происходит. Коротко: мы подключаемся к веб-сокету, указанному конкретным URL. Каждое сообщение, созданное сервером веб-сокета, логируется.

Три самые важные строки я объясню детально, но, если вас не интересует синтаксис, можете смело пропустить эту часть.

async/await — это просто специальный синтаксис для комфортной работы с промисами. Промис — не более чем объект, представляющий собой возможную передачу или сбой асинхронной операции.

Вместо передачи обратных вызовов в функцию вы можете присоединить обратные вызовы к этому возвращенному объекту.

В Python async гарантирует, что функция вернет промис и обернет в него не-промисы. В процессе вызова await может выполняться другой, не имеющий отношения к процессу, код.

websocket_resource_url = f"ws://{host}:{port}"

URL ресурса веб-сокета использует собственную схему, начинающуюся с ws (или wss для безопасного подключения). Далее следует имя хоста и номер порта (например, ws://websocket.example.com:8400). Здесь я использовал f-строку для создания URL ресурса. Синтаксис такой же, как при использовании str.format(), но f-строка по умолчанию добавлена в Python 3.6 и делает форматирование строкового литерала менее многословным.

async with websockets.connect(websocket_resource_url) as ws:

Следующая строка открывает соединение с веб-сокетом, используя websockets.connect. Ожидание соединения вызывает WebSocketClientProtocol, который затем используется для отправки и получения сообщений. Эта строка использует async with, который работает с асинхронным контекстным менеджером. Соединение закрывается при выходе из контекста.

Имейте в виду: иногда я использую аббревиатуру для веб-сокетов (ws), чтобы сделать код более читаемым в статье, но всегда пишу имя полностью в рабочем коде (Например, ws можно прочесть как веб-сайт или веб-сервер. Этого следует избегать хорошему разработчику. В конце концов код должен читаться как хорошая книга).

async for message in websocket:

async for — это что-то вроде синхронного цикла for, позволяющего асинхронное восприятие.

Асинхронный IO позволяет выполнять перебор асинхронного итератора: вы можете вызывать асинхронный код на любом этапе перебора, в то время как обычный цикл for этого не позволяет. В этой строке кода веб-сокет — producer сообщений.

Для запуска этого простого consumer’а просто укажите имя хоста и порт, он запустится в постоянном режиме. Предельно просто. Не беспокойтесь, если нет цикла событий. asyncio создаст новый цикл и установит в качестве текущего.

Этот пример кода будет принимать сообщения от ws://localhost:4000. Если сервер не запущен, он выдаст ошибку 404 Not Found.

Приведу пример producer’а, выдающего только одно значение. И он даже проще, чем comsumer:

Простой producer

Код выше говорит сам за себя. Мы подключаемся к веб-сокету так же, как делали это ранее с consumer’ом. Получаем сообщение от сервера и ждем ответ. Когда мы получаем сообщение от сервера, узнаем, что сообщение было доставлено.

Теперь нам нужен только способ выполнить эту сопрограмму-отправитель только один раз.

loop = asyncio.get_event_loop()
loop.run_until_complete(produce(message='hi', host='localhost', port=4000))

Конечно, у Python есть решение. Мы можем просто использовать цикл обработки событий так же, как мы делали это с consumer. Единственное отличие будет в том, что он будет запущен, пока мы не получим ответ от сервера. После получения ответа задача завершится.

В Python 3.7 стало еще лучше — теперь можно использовать функцию run для выполнения сопрограмм.

asyncio.run(produce(message='hi', host='localhost', port=4000))

Для этого случая я написал серверный класс, который объединяет весь функционал сервера. Этот сервер рассылает сообщения, отправленные producer’ом, всем слушающим consumer’ам.

Сервер создается и определяет сопрограмму обработчика веб-сокета. Функция веб-сокета serve — это обёртка вокруг метода create_server() цикла обработки событий. Он создает и запускает сервер с create_server() и принимает обработчик веб-сокета в качестве аргумента.

Когда бы ни подключался клиент, сервер принимает соединение, создает WebSocketServerProtocol, осуществляет открывающее “рукопожатие” и передает обработчику соединения, определенному обработчиком веб-сокета. Как только обработчик заканчивает работу, нормально или с исключением, сервер выполняет закрывающее “рукопожатие” и закрывает соединение.

Все готово! Как только мы запустим сервер, он просто будет выполнять сопрограмму ws_handler, определенную в классе сервера (об этом выше) каждый раз, когда producer отправляет что-то. Затем он доставит сообщение всем подключенным клиентам.

Последняя часть кода — самая длинная, оставайтесь с нами, мы почти закончили.

Класс сервера, синхронизирующий сообщения с подключенными клиентами

ws_handler регистрирует клиентa, отправляет сообщение подключенным клиентам и, наконец, закрывает соединение. Consumer остается подключенным, в то время как producer отменяет собственную регистрацию. Сопрограмма distribute будет отправлять каждое сообщение в веб-сокете всем клиентам в списке подключенных клиентов.

Если существует несколько подключенных клиентов, выполнится следующий фрагмент кода. asyncio.wait гарантирует, что мы продолжим только после того, как каждому клиенту будет отправлено сообщение.

Вот несколько ключевых преимуществ веб-сокетов в сравнении с моделью длинного опроса HTTP:

Информация может передаваться в обе стороны в любое время в течение срока действия веб-сокет соединения.
Клиент и сервер постоянно соединены — данные могут отправляться клиентам все время без необходимости получать запрос.
Довольно просто работать с веб-сокетами в Python. Пример с синхронизацией сообщений был реализован без написания большого количества кода. Выполнить эффективно ту же задачу с длинным опросом HTTP было бы значительно сложнее.

Устранение проблем интерфейса и неполадок портов коммутатора

Содержание

Устранение неполадок Gigabit Ethernet
Сравнение подключенного и неподключенного состояний

Устранение неполадок Gigabit Ethernet

Если устройство А подключено к устройству Б через соединение Gigabit, которое не удается активировать, выполните следующую процедуру.

Пошаговая процедура

Убедитесь, что на устройствах А и Б используются одинаковые конвертеры GBIC: коротковолновые (SX), длинноволновые (LX), дальней связи (LH), с растянутыми волнами (ZX) или медная неэкранированная витая пара (TX). Для установления соединения на обоих устройствах должны использоваться конвертеры GBIC одного типа. Конвертер SX GBIC необходимо подключать к конвертеру SX GBIC. Конвертер SX GBIC не может быть связан с конвертером LX GBIC. Дополнительные сведения можно получить в выполняющей абонентское обслуживание компьютеров организации или в документе Примечание по установке переходного соединительного кабеля.

Проверьте соответствие расстояния и типа кабеля, подключенного к конвертеру GBIC, по приведенной ниже таблице.

Спецификации кабелей портов 1000BASE-T и 1000BASE-X

GBIC	Длина волны (нм)	Тип меди/волокна	Внутренний диаметр¹(микроны)	Удельная полоса пропускания (МГц/км)	Длина кабеля²
WS-G5483 1000Base — T (медный)		Категория 5 UTP Категория Категория 5e UTP 6 UTP			328 футов (100 м)
WS-G5484 1000BASE-SX³	850	MMF	62. 5 62.5 50.0 50.0	160 200 400 500	220 м 275 м 500 м 550 м
WS-G5486 1000BASE-LX/LH	1310	MMF⁴ SMF	62.5 50.0 50. 0 8.3/9/10	500 400 500 —	550 м 550 м 550 м 10 км
WS-G5487 1000BASE-ZX⁵	1550	MMF SMF⁶	8.3/9/10 8.3/9/10		43,5 мили (70 км)⁷ 62,1 мили (100 км)

Числа, приведенные для многомодового оптоволоконного кабеля, относятся к диаметру сердцевины. Для одномодового оптоволоконного кабеля, 8,3 микрон относятся к диаметру сердцевины. Значения в 9 и 10 микрон относятся к диаметру волнового поля, который является диаметром несущей свет части оптоволокна. Эта область состоит из сердцевины оптоволокна и небольшой части окружающего оптического покрытия. Диаметр волнового поля является функцией диаметра сердцевины, длины волны лазера, разницы показателей преломления сердцевины и оптического покрытия.
Длина зависит от потерь в оптоволокне. Многослойность и нестандартность оптоволоконного кабеля приводят к уменьшению дальности прокладки кабеля.
Использовать только вместе с многомодовым волокном.
При использовании конвертера LX/LH GBIC с многомодовым волокном диаметром 62,5 микрона необходимо установить переходной соединительный кабель (CAB-GELX-625 или эквивалентный) между конвертером GBIC и многомодовым кабелем на концах передачи и приема данного соединения. Переходной соединительный кабель требуется для соединений на расстояниях менее 328 футов (100 м) или более 984 футов (300 м). Переходной соединительный кабель предотвращает перегрузку приемника в случае короткого многомодового волокна и снижает задержку сигнала при дифференциальном включении в случае длинного многомодового волокна. Дополнительные сведения см. в документе Примечание по установке переходного соединительного кабеля.
Использовать только вместе с одномодовым волокном.
Одномодовый оптоволоконный кабель со смещенной дисперсией.
Для конвертеров ZX GBIC минимальная дальность соединения (при наличии на каждом конце соединения аттенюаторов на 8 дБ) составляет 10 км (6,2 мили). Без аттенюаторов минимальная дальность соединения равна 40 км (24,9 мили).

Если у любого из устройств есть несколько портов Gigabit, соедините эти порты между собой. Это позволяет проверить каждое устройство и убедиться, что интерфейс Gigabit функционирует правильно. Например, есть коммутатор с двумя портами Gigabit. Подключите один порт Gigabit к другому. Активно ли данное соединение? Если да, то данные порты функционируют правильно. STP блокирует данный порт и предотвращает возникновение петель (приемный порт один (RX) соединяется с передающим портом два (TX), а порт один TX — с портом два RX).
Если произошел сбой одного соединения или не удалось выполнить шаг 3 с разъемами SC, закольцуйте порт на себя (порт один RX соединяется с портом один TX). Активен ли данный порт? Если нет, обратитесь в центр технической поддержки (TAC), так как, возможно, это неисправный порт.
Если шаги 3 и 4 успешны, но соединение между устройствами А и Б не удается установить, закольцуйте порты с помощью кабеля, соединяющего два устройства. Проверьте исправность кабелей.
Убедитесь, что каждое устройство поддерживает спецификацию 802. 3z для автоматического согласования Gigabit. В интерфейсе Gigabit Ethernet есть процедура автоматического согласования, обеспечивающая более широкие возможности, чем та, которая используется в 10/100 Ethernet (спецификация автоматического согласования Gigabit: IEEE Std 802.3z-1998). При включении согласования соединений система выполняет автоматическое согласование дуплексного режима, режима управления потоком и сведений об удаленных ошибках. Следует либо включить, либо отключить согласование сразу на обоих концах соединения. На обоих концах соединения необходимо задать одно и то же значение, иначе соединение установить не удастся. Проблемы могут возникнуть при подключении к устройствам, произведенным до ратификации стандарта IEEE 802.3z. Если любое из устройств не поддерживает автоматическое согласование Gigabit, отключите автоматическое согласование Gigabit. Это вызовет принудительную активацию соединения.

Предупреждение: При отключении автоматического согласования скрываются сбросы соединений и проблемы на физическом уровне. Отключение автоматического согласования требуется, только если используются конечные устройства, не поддерживающие стандарт IEEE 802.3z (например старые сетевые платы Gigabit). Отключать автоматическое согласование между коммутаторами следует только в случае крайней необходимости, так как при этом проблемы физического уровня могут остаться необнаруженными, что ведет к образованию петель STP. В качестве альтернативы убедитесь, что у вас выполнена легализация ПО, обратитесь к поставщику и обновите свое программное и аппаратное обеспечение до поддержки автоматического согласования IEEE 802.3z Gigabit.

Об устранении неполадки, описанной в сообщении об ошибке: %SYS-4-PORT_GBICBADEEPROM: / %SYS-4-PORT_GBICNOTSUPP, см. в документе Распространенные сообщения об ошибках CatOS на коммутаторах серии Catalyst 6000/6500.

Системные требования к GigabitEthernet, конвертерам интерфейса Gigabit (GBIC), неплотному спектральному мультиплексированию (CWDM) и подключаемым модулям малого форм-фактора (SFP) см . в следующих документах.

Системные требования для реализации Gigabit Ethernet на коммутаторах Catalyst
Матрица совместимости коммутатора — конвертера интерфейса Catalyst GigaStack Gigabit
Матрица совместимости модулей приемопередатчиков Cisco Gigabit Ethernet
Документация по GBIC, SFP и CWDM

Сведения об общей конфигурации и устранении неполадок см. в документе Настройка и устранение неполадок автоматического согласования Ethernet 10/100/1000 MB в полудуплексном и дуплексном режимах.

Сравнение подключенного и неподключенного состояний

На большинстве коммутаторов Cisco порт по умолчанию находится в неподключенном состоянии. Это означает, что в данный момент он ни к чему не подключен, однако соединение будет установлено в случае надежного подключения к другому действующему устройству. При подключении исправного кабеля к двум портам коммутатора в неподключенном состоянии, индикатор соединения для обоих портов начинает гореть зеленым цветом, а состояние портов должно отображать установленные подключения. Это означает, что данный порт активен на уровне 1 (L1).

Для CatOS можно использовать команду show port , чтобы проверить, находится ли порт в подключенном или неподключенном состоянии, либо в другом состоянии, которое может вызвать сбой подключения, например, disabled (отключен) или errdisable (отключен из-за ошибки).

Switch> (enable) sh port status 3/1   Port  Name                 Status     Vlan       Duplex Speed Type

----- -------------------- ---------- ---------- ------ ----- ------------

    3/1                       disabled   1            auto  auto 10/100BaseTX

!--- The show port status {mod/port} command show the port is disabled.

!--- Use the set port enable {mod/port}command to try and re-enable it.

Для Cisco IOS можно использовать команду show interfaces чтобы убедиться, что интерфейс — «up, line protocol is up (connected)». Первое «up» относится к состоянию физического уровня интерфейса. Сообщение «line protocol up» показывает состояние уровня канала передачи данных для данного интерфейса и означает, что интерфейс может отправлять и принимать запросы keepalive.

Router#show interfaces fastEthernet 6/1 FastEthernet6/1 is down, line protocol is down (notconnect)

!--- The interface is down and line protocol is down.

!--- Reasons: In this case,

!--- 1) A cable is not properly connected or not connected at all to this port.

!--- 2) The connected cable is faulty.

!--- 3) Other end of the cable is not connected to an active port or device.

!--- Note: For gigabit connections, GBICs need to be matched on each

!--- side of the connection.

!--- There are different types of GBICs, depending on the cable and

!--- distances involved: short wavelength (SX),

!--- long-wavelength/long-haul (LX/LH) and extended distance (ZX).

!--- An SX GBIC needs to connect with an SX GBIC;

!--- an SX GBIC does not link with an LX GBIC. Also, some gigabit

!--- connections require conditioning cables,  !--- depending on the lengths involved.

Router#show interfaces fastEthernet 6/1  FastEthernet6/1 is up, line protocol is down (notconnect)

!--- The interface is up (or not in a shutdown state), but line protocol down.

!--- Reason: In this case, the device on the other side of the wire is a

!--- CatOS switch with its port disabled.

Router#sh interfaces fas 6/1 status Port   Name    Status       Vlan    Duplex   Speed  Type Fa6/1

          notconnect    1       auto     auto   10/100BaseTX

!--- The show interfaces card-type [slot/port] status command is the equivalent

!--- of show port status for CatOS.

Если команда show port показывает подключенные порты или команда show interfaces показывает активный протокол линии (подключен), но в выходных данных любой из этих команд наблюдается увеличение ошибок, то совет по устранению неполадки см. в разделе «Основные сведения о выходных данных счетчиков портов и интерфейсов для CatOS и Cisco IOS» или «Распространенные проблемы портов и интерфейсов» данного документа.

HTTP и Websockets: понимание возможностей современных технологий веб-коммуникации | Автор Тилина Эшен Гамаж | Platform Engineer

Однако теперь вы должны понимать, что WebSockets — отличный выбор для обработки долговременной двунаправленной потоковой передачи данных почти в режиме реального времени, тогда как REST отлично подходит для периодической связи. Использование WebSockets требует значительных вложений, поэтому для случайных подключений это перебор.

Webhooks (для связи между серверами)

Если вы хотите получать данные из вашего API об изменении данных, опрос должен быть первым вариантом, который вам приходит в голову.Но когда дело доходит до связи между серверами, неэффективность опросов обходится нам очень дорого (в среднем 98,5% опросов тратятся впустую).

Webhooks — простой способ пересылки данных между серверами без длительных соединений для опроса (Изображение с сайта realtimeapi.io)

Webhooks — спасение от этой проблемы. Здесь помните, что связь обычно происходит между серверами. Сначала узел-отправитель заранее регистрирует URL-адрес обратного вызова в узлах-получателях. Когда событие происходит на стороне отправителя, срабатывает веб-перехватчик и отправляет объект события с новыми данными в виде HTTP-запроса POST на узлы-получатели, используя URL-адреса обратного вызова, зарегистрированные в каждом из них.

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

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

service (Изображение из kloudymail.com)

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

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

✅ HTTP / 1.1 против HTTP / 2: это транспортные протоколы. Возможности мультиплексирования в HTTP / 2 великолепны, но пока поддерживаются не везде. В таких случаях убедитесь, что отказ от HTTP / 2 и HTTP / 1.1 не приведет к беспорядку в вашем приложении. Для передачи данных HTTP / 1.1 по-прежнему остается отличным выбором.

✅ RESTful API: пока что RESTful API подходят для веб-приложений. Но ведутся дискуссии о поиске лучших способов. Примером может служить такая концепция — «Заменить RESTful API на JSON-Pure».Мне нравится идея, на самом деле JSON удобен для разработчиков, и с ним можно творить чудеса. Но знаете, это развивающиеся концепции.

✅ JSON против XML: используйте JSON. Это тенденция, и с ней так удобно иметь дело.

✅ HTTP-опрос: это старый, но отличный выбор для работы с API. Если ваши данные меняются часто или в режиме реального времени, не используйте Short Polling, просто используйте WebSockets, лучшую технологию для работы в реальном времени. Всегда правильно используйте длительный и периодический опрос (с принципами REST).

✅ HTTP Streaming: это хорошо для таких приложений, как новости / каналы социальных сетей, акции / табло, твиты и т. Д. Но на практике люди используют WebSockets, а не HTTP Streaming.

⚠️ HTTP / 2 Server Push отлично подходит для отправки ресурсов клиенту более управляемым способом. Но не все посредники и браузеры это поддерживают. Убедитесь, что вы изящно обрабатываете такие откаты.

⚠️ Отправленные сервером события — это довольно новая технология, которая еще не поддерживается всеми основными браузерами, поэтому это еще не вариант для серьезного веб-приложения корпоративного уровня ( Да, я согласен, что вы можете обмануть эту технологию на работу ).

✅ WebSockets предоставляют расширенный протокол для двунаправленной полнодуплексной связи. Двусторонний канал более привлекателен для таких вещей, как игры, приложения для обмена сообщениями, инструменты для совместной работы, интерактивный опыт (включая микровзаимодействия), а также для случаев, когда вам нужны обновления в реальном времени в обоих направлениях.

✅ Webhooks отличается от всех вышеперечисленных технологий тем, что решает очень специфическую проблему. Если вашим серверам требуется частая и / или двунаправленная связь, выберите WebSockets.Если ваши серверы время от времени обмениваются данными, используйте вызовы REST. Если вашим серверам необходимо однонаправленно обмениваться данными по триггеру события, используйте веб-перехватчики. Не используйте опрос для проверки изменений данных или состояния, это пустая трата времени.

☝️ Прокси и посредники сумасшедшие. Они неожиданно съедят ваши пакеты или тайм-аут. Помните об этом и обращайтесь с этим изящно.

☝️ Используйте защищенные транспортные протоколы (HTTPS или WSS) для управления вашим обменом данными. Тогда посредники будут меньше влиять на ваши связи.И это безопасно, знаете ли.

☝️ Разработчикам нравятся веб-перехватчики. Но убедитесь, что вы применяете его правильно.

☝️ Вам действительно не обязательно всегда использовать новейшие технологии, особенно при создании приложений корпоративного уровня. Убедитесь, что вся инфраструктура поддерживает используемую вами технологию. И если инфраструктура не поддерживает вашу технологию / архитектуру, убедитесь, что она возвращается к технологии, которая работает везде, и все работает изящно с ограниченными возможностями.

Безопасность WebSocket | Центр разработки Heroku

Последнее обновление: 9 апреля 2020 г.

Протокол WebSocket — молодая технология, которая сопряжена с некоторыми рисками. Десятилетия опыта научили веб-сообщество некоторым передовым практикам в отношении безопасности HTTP, но передовые методы безопасности в мире WebSocket не получили прочного признания и продолжают развиваться. Тем не менее, некоторые темы появились, и они описаны в этой статье.

WSS

Вы должны настоятельно предпочесть безопасный протокол wss: // небезопасному транспорту ws: // .Как и HTTPS, WSS (WebSockets через SSL / TLS) зашифрован, что защищает от атак типа «злоумышленник в середине». Разнообразные атаки на WebSockets становятся невозможными, если транспорт защищен.

Конечные точки SSL

Heroku поддерживают WSS, и мы настоятельно рекомендуем вам использовать его.

Избегайте туннелирования

Относительно легко туннелировать произвольные TCP-сервисы через WebSocket. Таким образом, вы могли бы, например, туннелировать соединение с базой данных напрямую через браузер. Однако это очень опасно.Это позволит получить доступ к этим службам злоумышленнику в браузере в случае атаки межсайтового скриптинга, что позволит перерасти XSS-атаку в полное удаленное нарушение.

Мы рекомендуем по возможности избегать туннелирования. Вместо этого разработайте более защищенные и проверенные протоколы поверх WebSockets.

Подтвердить ввод клиента

Соединения

WebSocket легко устанавливаются вне браузера, поэтому вы должны предполагать, что вам нужно иметь дело с произвольными данными.Как и в случае с любыми данными, поступающими от клиента, вы должны тщательно проверять ввод перед их обработкой. Атаки SQL-инъекций через WebSockets так же возможны, как и через HTTP.

Проверить данные сервера

Вы должны относиться с таким же подозрением к данным, возвращаемым с сервера. Всегда обрабатывайте сообщения, полученные на стороне клиента, как данные. Не пытайтесь назначить их напрямую DOM и не оценивать их как код. Если ответ — JSON, всегда используйте JSON.parse () для безопасного анализа данных.

Аутентификация / авторизация

Протокол WebSocket не обрабатывает авторизацию или аутентификацию. Фактически это означает, что WebSocket, открываемый со страницы, находящейся за auth, не получает «автоматически» никакой авторизации; Вам необходимо предпринять шаги к , а также к , чтобы защитить соединение WebSocket.

Это можно сделать различными способами, поскольку WebSockets будет проходить через стандартные заголовки HTTP, обычно используемые для аутентификации. Это означает, что вы можете использовать тот же механизм аутентификации, который вы используете для своих веб-представлений в соединениях WebSocket.

Поскольку вы не можете настраивать заголовки WebSocket из JavaScript, вы ограничены «неявной» аутентификацией (т. Е. Базовой или куки-файлов), отправляемой из браузера. Кроме того, обычно сервер, обрабатывающий WebSockets, полностью отделен от сервера, обрабатывающего «обычные» HTTP-запросы. Это может затруднить или сделать невозможным использование общих заголовков авторизации.

Итак, один из обнаруженных нами паттернов, который, кажется, хорошо решает проблему аутентификации WebSocket, — это система аутентификации на основе «тикетов».В общих чертах это работает так:

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

[Спасибо Армину Ронахеру за то, что первым обратил наше внимание на этот узор.]

Стандарт WebSocket определяет поле заголовка Origin , в котором веб-браузеры устанавливают URL-адрес, с которого исходит запрос WebSocket.Это можно использовать для различения соединений WebSocket с разных хостов или между соединениями, сделанными из браузера и какого-либо другого сетевого клиента. Однако помните, что заголовок Origin по существу носит рекомендательный характер: клиенты, не являющиеся браузерами, могут легко установить для заголовка Origin любое значение и, таким образом, «притвориться» браузером.

Заголовок Origin можно рассматривать как примерно аналог заголовка X-Requested-With , используемого в запросах AJAX. Веб-браузеры отправляют заголовок X-Requested-With: XMLHttpRequest , который можно использовать для различения запросов AJAX, сделанных браузером, и запросов, сделанных напрямую. Однако этот заголовок легко устанавливается клиентами, не являющимися браузерами, и поэтому ему не доверяют как источнику аутентификации.

Таким же образом вы можете использовать заголовок Origin в качестве консультативного механизма — механизма, который помогает различать запросы WebSocket из разных мест и хостов, но вам не следует полагаться на него как на источник аутентификации.

Веб-сокет

— npm

Обзор

Это (в основном) чистая реализация JavaScript протокола WebSocket версий 8 и 13 для Node. В папке «test / scripts» есть несколько примеров клиентских и серверных приложений, реализующих различные протоколы тестирования совместимости.

Полную документацию по API можно прочитать в папке docs.

История изменений

Текущая версия: 1. 0.33 — Выпуск 2020-12-08

Добавлены новые параметры конфигурации в WebSocketServer, позволяющие разработчикам обходить синтаксический анализ расширений WebSocket и файлов cookie HTTP, если они не нужны. (Спасибо, @aetheon)
Добавлено новое событие upgradeError для WebSocketServer, чтобы обеспечить видимость и регистрацию любых ошибок синтаксического анализа, которые могут возникнуть на этапе обновления HTTP. (Спасибо, @aetheon)

Посмотреть полный список изменений

Поддержка браузера

Все текущие браузеры полностью поддерживаются.

Firefox 7-9 (старый) (протокол версии 8)
Firefox 10+ (протокол версии 13)
Chrome 14,15 (старый) (протокол версии 8)
Chrome 16+ (протокол версии 13)
Internet Explorer 10+ (версия протокола 13)
Safari 6+ (протокол версии 13)

Тесты

В наборе тестов Autobahn есть несколько основных разделов тестирования. Я разместил тестовую страницу, на которой показаны результаты тестов Autobahn, запущенных на AutobahnServer 0.4.10, WebSocket-Node 1.0.2, WebSocket-Node 1.0.4 и WS 0.3.4.

(Эти тесты немного устарели на данный момент, так что относитесь к ним с недоверием. Кто-нибудь хочет запустить новые тесты? Я сделаю ссылку на ваш отчет.)

Автобан Тесты

Очень полный набор тестов Autobahn Test Suite используется в большинстве реализаций WebSocket для проверки соответствия спецификациям и совместимости.

Установка

В корне вашего проекта:

  $ npm установить веб-сокет

Тогда в вашем коде:

 var WebSocketServer = require ('websocket').сервер;
var WebSocketClient = require ('websocket'). client;
var WebSocketFrame = require ('websocket'). frame;
var WebSocketRouter = require ('websocket'). router;
var W3CWebSocket = требуется ('веб-сокет'). w3cwebsocket;

Текущие характеристики:

По лицензии Apache, версия 2. 0
Протоколы версий «8» и «13» (от проекта 08 до окончательного RFC) кадрирование и рукопожатие
Может обрабатывать / агрегировать полученные фрагментированные сообщения
Может фрагментировать исходящие сообщения
Маршрутизатор для подключения нескольких приложений к различным комбинациям путей и протоколов
TLS поддерживается для исходящих подключений через WebSocketClient
TLS поддерживается для серверных подключений (используйте https.createServer вместо http.createServer)
- Спасибо pors за подтверждение!
Настройка и анализ файлов cookie
Настраиваемые параметры
- Максимальный размер кадра к получению
- Максимальный совокупный размер полученного сообщения
- Следует ли фрагментировать исходящие сообщения
- Размер фрагментации исходящих сообщений
- Следует ли автоматически отправлять фреймы ping для поддержки активности
- Интервал проверки активности связи
- Следует ли автоматически собирать полученные фрагменты (позволяет приложению напрямую обрабатывать отдельные фрагменты)
- Как долго ждать после отправки кадра закрытия для подтверждения перед закрытием сокета.
W3C WebSocket API для приложений, работающих как на Node, так и в браузерах (через класс W3CWebSocket ).

Известные проблемы / отсутствующие функции:

Нет API для пользовательских расширений протокола.

Пример сервера

Вот небольшой пример, показывающий сервер, который возвращает все, что ему отправлено, будь то utf-8 или двоичный файл.

 #! / Usr / bin / env узел
var WebSocketServer = require ('websocket'). server;
var http = require ('http');

var server = http.createServer (функция (запрос, ответ) {
    console.log ((new Date ()) + 'Полученный запрос для' + request.url);
    response.writeHead (404);
    response.end ();
});
server.listen (8080, function () {
    console.log ((new Date ()) + 'Сервер прослушивает порт 8080');
});

wsServer = новый WebSocketServer ({
    httpServer: сервер,
    // Вы не должны использовать autoAcceptConnections для производства
    // приложения, так как это побеждает стандартную защиту от перекрестного происхождения
    // средства, встроенные в протокол и браузер. Вам следует
    // * всегда * проверяем происхождение соединения и решаем, нужно ли
    // принять это.
    autoAcceptConnections: false
});

function originIsAllowed (origin) {
  // помещаем сюда логику, чтобы определить, разрешено ли указанное происхождение.
  вернуть истину;
}

wsServer.on ('запрос', функция (запрос) {
    if (! originIsAllowed (request.origin)) {
      // Убедитесь, что мы принимаем запросы только из разрешенного источника
      request.reject ();
      console.log ((new Date ()) + 'Соединение из источника' + запрос.origin + 'отклонено.');
      возвращаться;
    }
    
    var connection = request.accept ('эхо-протокол', request.origin);
    console.log ((новая дата ()) + 'Соединение принято.');
    connection.on ('сообщение', функция (сообщение) {
        if (message.type === 'utf8') {
            console.log ('Полученное сообщение:' + message.utf8Data);
            connection.sendUTF (message.utf8Data);
        }
        else if (message.type === 'двоичный') {
            console. log ('Полученное двоичное сообщение' + message.binaryData.длина + байты);
            connection.sendBytes (сообщение.binaryData);
        }
    });
    connection.on ('закрыть', функция (код причины, описание) {
        console.log ((новая дата ()) + 'Peer' + connection.remoteAddress + 'отключен.');
    });
});

Пример клиента

Это простой пример клиента, который распечатывает любые сообщения utf-8, которые он получает на консоли, и периодически отправляет случайное число.

Этот код демонстрирует клиента в Node.js, а не в браузере

 #! / Usr / bin / env узел
var WebSocketClient = require ('websocket'). client;

var client = new WebSocketClient ();

client.on ('connectFailed', function (error) {
    console.log ('Ошибка подключения:' + error.toString ());
});

client.on ('соединение', функция (соединение) {
    console.log («Клиент WebSocket подключен»);
    connection.on ('ошибка', функция (ошибка) {
        console.log («Ошибка подключения:» + error. toString ());
    });
    connection.on ('закрыть', function () {
        консоль.log ('Соединение по эхо-протоколу закрыто');
    });
    connection.on ('сообщение', функция (сообщение) {
        if (message.type === 'utf8') {
            console.log ("Получено: '" + message.utf8Data + "'");
        }
    });
    
    function sendNumber () {
        if (connection.connected) {
            var number = Math.round (Math.random () * 0xFFFFFF);
            connection.sendUTF (число.toString ());
            setTimeout (sendNumber, 1000);
        }
    }
    sendNumber ();
});

client.connect ('ws: // localhost: 8080 /', 'эхо-протокол');

Пример клиента с использованием

W3C WebSocket API

Тот же пример, что и выше, но с использованием W3C WebSocket API.

 var W3CWebSocket = require ('websocket'). W3cwebsocket;

var client = new W3CWebSocket ('ws: // localhost: 8080 /', 'эхо-протокол');

client.onerror = function () {
    console.log ('Ошибка подключения');
};

client. onopen = function () {
    console.log («Клиент WebSocket подключен»);

    function sendNumber () {
        if (client.readyState === client.OPEN) {
            var number = Math.round (Math.random () * 0xFFFFFF);
            client.send (число.toString ());
            setTimeout (sendNumber, 1000);
        }
    }
    sendNumber ();
};

клиент.onclose = function () {
    console.log ('Клиент эхо-протокола закрыт');
};

client.onmessage = function (e) {
    if (typeof e.data === 'строка') {
        console.log ("Получено: '" + e.data + "'");
    }
};

Пример маршрутизатора запроса

Пример использования маршрутизатора запросов см. В libwebsockets-test-server.js в папке test .

Ресурсы

Презентация о состоянии протокола WebSockets, которую я провел 23 июля 2011 года на встрече LA Hacker News.WebSockets: Интернет в реальном времени, поставлено

Краткий обзор протокола websocket — документация noio_ws 0.0.5

Вещи, которые необходимо знать, чтобы написать клиент или сервер websocket

Протокол websocket взаимодействует с фреймами. Фреймы — это заголовок + данные приложения. Заголовок кадра содержит информацию о кадре и данных приложения. Данные приложения — это все, что вы отправляете во фрейме «body».

В своей основной форме протокол websocket имеет три неконтролирующих кадра и три контрольных кадра.Это

Неконтрольные:
- «текст» — означает, что мы отправляем байты в кодировке «utf-8».
- «двоичный» — означает, что мы отправляем необработанные байты
- «продолжить» — означает, что это сообщение является продолжением предыдущего сообщения.
Контроль:
- «закрыть» — говорит, что мы либо хотим закрыть, либо отвечаем на закрытие.
- «ping» — пингует!
- «pong» — понги!

Эти типы кадра обозначаются int в битовой форме, вставленной на полпути к байту в кадре.Тип int называется кодом операции.

Имеется fin бит, который указывает, является ли кадр последним в серии из одного или нескольких кадров.

Чтобы отправить «привет, мир» в кодировке utf-8, мы должны использовать текстовый кадр с битом fin , установленным в 1, сигнализируя, что это единственный кадр в серии, а полезная нагрузка содержит кодировку utf-8. текст.

Чтобы отправить «hello» одним фреймом, а «world» — другим, но сохранить их как часть одной и той же серии, чтобы получатель читал их как одно сообщение, мы отправим «текстовый» фрейм с «hello» и бит fin установлен в 0, а затем кадр «continue» из «world» с битом fin , установленным в 1.

Вы можете отправлять контрольные кадры в середине фрагментированного неконтролирующего кадра, но вы не можете отправлять неконтрольные кадры в середине фрагментированного неконтролирующего кадра.

Вы не можете фрагментировать кадр управления, и длина тела кадра управления не должна превышать 125 байт.

Есть три rsv (зарезервированных) бита, которые могут быть установлены в 1 и по умолчанию равны 0.

Если вы отправляете или получаете кадр закрытия , любой дальнейший полученный материал, не являющийся кадром закрытия , должен быть отброшен.Если вы отправили фрейм close , вы должны дождаться его получения по очереди, а затем можете завершить соединение, и наоборот.

Необязательно понимать все на этой странице, чтобы эффективно написать клиент или сервер websocket. Однако, если вы делаете что-то нетривиальное, вы, вероятно, захотите ознакомиться с приведенным выше материалом и общими концепциями, такими как структура кадра веб-сокета, коды операций, бит fin, биты rsrv, заголовки расширений / подпротоколов.

Любые и все нарушения протокола, независимо от того, насколько они незначительны, должны приводить к (если возможно) немедленной отправке кадра close и (независимо от того, если возможно) закрытию соединения.

На этом заканчивается раздел «вещи, которые вы обязательно должны знать».

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

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

Кадр - это небольшой заголовок с большим количеством битов + «полезная нагрузка». Полезная нагрузка - это любые данные приложения, похожие на тело сообщения http.

Кадр выглядит так:

 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 | код операции | M | Длина полезной нагрузки | Увеличенная длина полезной нагрузки |
| I | S | S | S | (4) | A | (7) | (16/64) |
| N | V | V | V | | S | | (если полезная нагрузка len == 126/127) |
| | 1 | 2 | 3 | | K | | |
+ - + - + - + - + ------- + - + ------------- + - - - - - - - - - - - - - - - +
| Увеличенная длина полезной нагрузки продолжается, если полезная нагрузка len == 127 |
+ - - - - - - - - - - - - - - - + ------------------------------- +
| | Маскирующий ключ, если МАСКА установлена в 1 |
+ ------------------------------- + ----------------- -------------- +
| Маскирующий ключ (продолжение) | Данные полезной нагрузки |
+ -------------------------------- - - - - - - - - - - - - - - - - +
: Данные полезной нагрузки продолжение. ..:
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Данные полезной нагрузки продолжение ... |
+ ------------------------------------------------- -------------- +

Дополнительная информация здесь.

Все, что вам действительно нужно знать, это то, что ваше приложение может включать зарезервированные биты и устанавливать пользовательские коды операций в диапазонах 3-7 для неконтролирующих кадров (текстовые или двоичные данные и т. Д.) И 11-15 для управляющих кадров (пинг / понг). и близко и т. д.).

Эту структуру используют как контрольные, так и неконтролирующие кадры.

Состояние подключения подробно рассматривается в следующем разделе. Это когда происходит вступительное рукопожатие.

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

Управляющие кадры не могут быть фрагментированы (бит FIN всегда должен быть установлен в 1), и если они имеют полезную нагрузку, первые два байта должны быть кодом состояния веб-сокета, а общая длина полезной нагрузки не должна быть больше 125.
Неконтролирующие кадры не могут чередоваться с другими неконтролирующими кадрами. (Если вы отправляете неконтролирующее сообщение по нескольким фреймам, управляющие фреймы могут прерываться в любой момент, однако фреймы, такие как «текст» и «двоичный», не могут.)
Если какая-либо из сторон отправляет кадр, код операции которого указывает закрытие , соединение переходит с открытого на закрытия , и все последующие кадры должны быть отброшены. Сторона, получившая сообщение close , должна ответить соответствующим кадром close , переводя обе стороны в состояние closed и завершая соединение с веб-сокетом.

`Начальное рукопожатие`

Не совсем важно знать подробности всего, что следует далее, поскольку почти все это покрывается утилитами рукопожатия, которые поставляются с noio_ws. Однако, если вы планируете согласовывать расширения или подпротоколы, вы должны быть знакомы со структурой соответствующих заголовков. Утилиты рукопожатия могут выполнять только упрощенную проверку запросов на расширение / подпротокол.

Все соединения websocket начинают свою жизнь как HTTP-запросы GET, запрашивая ресурс websocket по схеме протокола websocket ws: // или wss: // .Они аналогичны http: // и https: // . Это может показаться немного странным, поэтому я повторю еще раз: HTTP-запрос направлен в схему веб-сокетов. Пример URI:

 wss: //echo.websocket.org # здесь мы делаем http-запрос

В запросе должно быть указано:

 * ПОЛУЧИТЬ расположение_ресурсов HTTP / 1.1
* host: some_hostname
* upgrade: websocket # запросить обновление с http до websockets
* connection: upgrade # говорят, что мы ищем соединение для обновления
* sec-websocket-version: 13 # текущая версия протокола websocket
* sec-websocket-key: a_generated_nonce # случайно сгенерированная строка байтов в кодировке b64 от 0 до 255

Дополнительно клиент может также отправить заголовок sec-websocket-extensions и / или заголовок sec-websocket-protocol , чтобы согласовать, какие расширения и подпротоколы использовать (расширение сжатия, подпротокол чата и т. Д.))

Как только клиент отправляет этот запрос, сервер проверяет, что заголовки запроса в порядке (как указано выше) и что декодированный одноразовый номер по основанию 64 имеет длину 16.

Если сервер удовлетворен деталями запроса, он формирует ответ на первую часть рукопожатия.

Это выглядит так:

 * HTTP / 1.1 101 Switching Protocols # запрос клиентов принят
* upgrade: websocket # обновление до протокола websocket
* соединение: обновление # соединение обновляется
* sec-websocket-version: 13 # текущая версия протокола websocket
* sec-weebsocket-accept: response_nonce # Это значение представляет собой строку клиентского nonce * как получено *, объединенную с GUID веб-сокета, который затем кодируется как байты utf-8 и sha1'd.Результирующий дайджест sha1 затем кодируется в base64, и это и есть response_nonce. (Кровавое безумие).

Если предоставлено, сервер может также отправить заголовок sec-websocket-extensions и / или заголовок sec-websocket-protocol с подробным описанием того, какие (если есть) расширения или протоколы он согласен. Если соглашение не достигнуто, сервер закрывает соединение.

Именно в этот момент сервер, если он принимает соединение до сих пор, переходит от обработки клиента как http-клиента к клиенту websocket.

уф!

Как только клиент получит этот ответ, он должен подтвердить этот ответ. О боже, не надо больше 🙁

Клиент проверяет, что код состояния равен 101, и что заголовки в порядке. Это предполагает, что клиент независимо вычисляет response_nonce, с которым сервер ответил, и сравнивает его с response_nonce сервера. Это также может включать в себя принятие или отклонение расширений, согласованных сервером, закрытие соединения, если он считает нужным (хотя было бы необычно отклонить на этом этапе, учитывая, что сервер уже отклонил бы и закрылся, если бы возник конфликт.)

Именно в этот момент клиент, если он принимает ответ от сервера, переходит от обработки соединения как соединения через веб-сокет. Здесь обе стороны могут рассматриваться в «режиме протокола веб-сокета» и могут начать отправку кадров веб-сокета.

Это много всякой ерунды, а? Это чрезвычайно утомительный и жалкий обмен. noio_ws считает это чрезвычайно утомительным и утомительным и ОЧЕНЬ сильно отделяет этот открывающий вздор от использования открытого соединения через веб-сокет.noio_ws предоставляет простые в использовании утилиты квитирования для решения вышеуказанных проблем, однако утилиты , а не , имеют дело с согласованием расширений или подпротоколов, более сложных, чем 'extension_1, extension_2' или 'subprotocol_1, subprotocol_2' .

`WebSocket`

 Опубликован в
2020-02-02
к
Джесси Глик Я рад сообщить, что JEP-222 приземлился в еженедельниках Jenkins,
начиная с 2.217.
Это улучшение обеспечивает экспериментальную поддержку WebSocket для Jenkins,
доступно при подключении входящих агентов или при запуске CLI.Протокол WebSocket обеспечивает двунаправленную потоковую связь через порт HTTP (S).
 Хотя многие пользователи Jenkins могут получить выгоду,
внедрение этой системы было особенно важно для CloudBees
из-за того, как CloudBees Core на современных облачных платформах
(т. е. работает в Kubernetes) настраивает сеть.
Когда администратор хочет подключить входящий внешний агент (ранее известный как «JNLP») к контроллеру Jenkins,
например, виртуальная машина Windows, работающая вне кластера и использующая оболочку службы агента,
до сих пор единственным вариантом было использование специального порта TCP.Этот порт нужно было открыть для внешнего трафика с помощью низкоуровневой конфигурации сети.
Например, пользователи входящего контроллера nginx
потребуется проксировать отдельный внешний порт для каждой службы Jenkins в кластере.
Инструкции для этого сложны, и их трудно устранить.
 Используя WebSocket, входящие агенты теперь могут быть подключены намного проще, когда присутствует обратный прокси:
если порт HTTP (S) уже обслуживает трафик,
большинство прокси разрешают соединения WebSocket без дополнительной настройки.Режим WebSocket можно включить в конфигурации агента,
скоро появится поддержка агентов на основе модулей в плагине Kubernetes.
Вам понадобится агент версии 4. 0 или новее,
который обычно идет в комплекте с Jenkins (скоро появятся образы Docker с этой версией).
 Другой частью Jenkins, которая доставляла неудобства пользователям обратного прокси, был интерфейс командной строки.
Помимо протокола SSH на 22-м порту, который снова было сложно открыть извне,
CLI уже имел возможность использовать транспорт HTTP (S).К сожалению, трюк, использованный для реализации, сбивал с толку некоторые прокси и был не очень портативен.
Jenkins 2.217 предлагает новый режим  -webSocket  CLI, который должен избегать этих проблем;
снова вам нужно будет загрузить новую версию  jenkins-cli.jar , чтобы использовать этот режим.
 Код WebSocket был протестирован на примере реализаций Kubernetes (включая OpenShift),
но вполне вероятно, что некоторые ошибки и ограничения останутся,
а масштабируемость агентов при больших нагрузках сборки еще не тестировалась.Относитесь к этой функции как к бета-версии и сообщите нам, как она работает!
  Джесси Глик  Джесси много лет разрабатывал ядро Jenkins и плагины. Он является соавтором основной инфраструктуры Трубопроводной системы с Косуке.
 404 | Микро Фокус 
 Профессиональные услуги Сформируйте свою стратегию и преобразуйте гибридную ИТ-среду.
 Профессиональные услуги по продуктам
 Аналитика и большие данные Помогите вам внедрить безопасность в цепочку создания стоимости ИТ и наладить сотрудничество между ИТ-операциями, приложениями и группами безопасности.
 Информационная безопасность Помогите вам быстрее реагировать и получить конкурентное преимущество благодаря гибкости предприятия.
 DevOps Ускорьте получение результатов гибридного облака с помощью услуг по консультированию, трансформации и внедрению.
 Консультации по цепочке создания стоимости IT4IT Службы управления приложениями, которые позволяют поручить управление решениями экспертам, разбирающимся в вашей среде.
 Управление доставкой приложений Услуги стратегического консалтинга для разработки вашей программы цифровой трансформации.
 Жизненный цикл мобильного приложения Полнофункциональное моделирование сценариев использования с предварительно созданными интеграциями в портфеле программного обеспечения Micro Focus, демонстрирующее реальные сценарии использования
 Управление гибридным облаком и брокерские услуги Услуги экспертной аналитики безопасности, которые помогут вам быстро спроектировать, развернуть и проверить реализацию технологии безопасности Micro Focus.
 Автоматизация ЦОД Служба интеграции и управления службами, которая оптимизирует доставку, гарантии и управление в условиях нескольких поставщиков.
 Управление операциями Получайте ценные сведения из больших данных с помощью аналитики в реальном времени и ищите неструктурированные данные.
 Управление услугами Получайте ценные сведения из больших данных с помощью аналитики в реальном времени и ищите неструктурированные данные.
 Vertica Получайте ценные сведения из больших данных с помощью аналитики в реальном времени и ищите неструктурированные данные.
 Глобальная аутентификация продукта Мобильные услуги, которые обеспечивают производительность и ускоряют вывод на рынок без ущерба для качества.
 Управляемые службы Получайте ценные сведения из больших данных с помощью аналитики в реальном времени и ищите неструктурированные данные.
 Модельные офисы Комплексные услуги по работе с большими данными для продвижения вашего предприятия.
 Как веб-сокеты HTML5 взаимодействуют с прокси-серверами 
 В связи с недавним бурным ростом реализаций серверов WebSocket возникло множество вопросов о том, как веб-сокеты HTML5 работают с прокси-серверами, межсетевыми экранами и маршрутизаторами с балансировкой нагрузки. Будут ли прокси-серверы автоматически отключать соединения WebSocket? Веб-сокеты HTML5 решают проблемы с брандмауэрами и прокси-сервером лучше, чем Comet? Веб-сокеты - это серебряная пуля в беспрепятственном обходе прокси-сервера? В этой статье я объясню, как веб-сокеты HTML5 взаимодействуют с прокси-серверами, маршрутизаторами с балансировкой нагрузки и межсетевыми экранами. Кроме того, я объясню, как Kaazing WebSocket Gateway и его эмуляция Web Socket могут добавить дополнительную ценность.
 О веб-сокетах и прокси-серверах HTML5 
 Начнем с некоторых основных понятий: что такое веб-сокеты и прокси-серверы HTML5?
 Веб-сокеты HTML5 
 Спецификация веб-сокетов HTML5 определяет API  веб-сокетов , который позволяет веб-страницам использовать протокол  веб-сокетов  для полнодуплексной связи с удаленным хостом.Он представляет интерфейс WebSocket и определяет полнодуплексный канал связи, который работает через единственный сокет через Интернет. Веб-сокеты HTML5 эффективно обеспечивают сокетное соединение через Интернет с минимальными накладными расходами. Это обеспечивает огромное сокращение ненужного сетевого трафика и задержки по сравнению с устаревшими решениями для опроса и длительного опроса (Comet), которые часто используются для передачи данных в реальном времени клиентам или даже для имитации полнодуплексного соединения путем поддержки двух HTTP-соединений.
 Чтобы использовать веб-сокеты HTML5 для подключения веб-клиента к удаленной конечной точке, вы создаете новый экземпляр WebSocket и предоставляете ему URL-адрес, представляющий конечную точку, к которой вы хотите подключиться. В спецификации определены схемы  ws: //  и  wss: //  для обозначения соединений WebSocket и WebSocket Secure соответственно. Соединение WebSocket устанавливается путем обновления протокола HTTP до протокола Web Socket во время первоначального рукопожатия между клиентом и сервером через одно и то же базовое соединение TCP / IP.
 Прокси-серверы 
 Прокси-сервер - это сервер, который действует как посредник между клиентом и другим сервером (например, веб-сервером в Интернете). Прокси-серверы обычно используются для кэширования контента, подключения к Интернету, безопасности и фильтрации корпоративного контента. Обычно между частной сетью и Интернетом устанавливается прокси-сервер. Прокси-серверы могут отслеживать трафик и закрывать соединение, если оно было открыто слишком долго. Проблема с прокси-серверами для веб-приложений, которые имеют долговременное соединение (например, потоковая передача HTTP Comet или веб-сокеты HTML5), очевидна: прокси-серверы HTTP, которые изначально были разработаны для передачи документов, могут выбрать закрытие потоковой передачи или бездействие WebSocket. подключений, потому что они, похоже, пытаются подключиться к неотвечающему HTTP-серверу.Это проблема с долгоживущими соединениями, такими как веб-сокеты. Кроме того, прокси-серверы могут также буферизовать незашифрованные ответы HTTP, тем самым создавая непредсказуемую задержку во время потоковой передачи ответов HTTP.
 Веб-сокеты и прокси-серверы HTML5 
 Давайте посмотрим, как веб-сокеты HTML5 работают с прокси-серверами. Соединения WebSocket используют стандартные порты HTTP (80 и 443), что побудило многих называть его «прокси-сервером и протоколом, дружественным к брандмауэрам». Следовательно, веб-сокеты HTML5 не требуют установки нового оборудования или открытия новых портов в корпоративных сетях - две вещи, которые остановили бы принятие любого нового протокола, не имеющего себе равных.Без каких-либо промежуточных серверов (прокси или обратные прокси-серверы, брандмауэры, маршрутизаторы с балансировкой нагрузки и т. Д.) Между браузером и сервером WebSocket соединение WebSocket может быть установлено гладко, если и сервер, и клиент понимают Web Socket. протокол. Однако в реальных условиях большой сетевой трафик проходит через промежуточные серверы.
 Картинка стоит тысячи слов. На рисунке 1 показана упрощенная топология сети, в которой клиенты используют браузер для доступа к внутренним службам на основе TCP с использованием полнодуплексного соединения HTML5 WebSocket. Некоторые клиенты расположены внутри корпоративной сети, защищены корпоративным брандмауэром и настроены для доступа в Интернет через  явных  или известных прокси-серверов, которые могут обеспечивать кэширование контента и безопасность; в то время как другие клиенты обращаются к серверу WebSocket напрямую через Интернет. В обоих случаях клиентские запросы могут маршрутизироваться через  прозрачных  или неизвестных прокси-серверов (например, прокси-сервер в центре обработки данных или обратный прокси-сервер перед удаленным сервером).Прокси-серверы даже могут иметь свои собственные явные прокси-серверы, увеличивая количество переходов, которые должен совершать трафик WebSocket.
  Рисунок 1. Архитектура веб-сокетов с явными и прозрачными прокси-серверами 
 В отличие от обычного HTTP-трафика, использующего протокол запроса / ответа, соединения WebSocket могут оставаться открытыми в течение длительного времени. Прокси-серверы могут позволить это и изящно справиться с этим, но они также могут бросить вызов гаечному ключу в работе.
 Обновление WebSocket 
 Веб-сокеты HTML5 используют механизм обновления HTTP для обновления до протокола веб-сокетов. Веб-сокеты HTML5 имеют HTTP-совместимое рукопожатие, так что HTTP-серверы могут использовать свои порты HTTP и HTTPS по умолчанию (80 и 443) с сервером WebSocket. Чтобы установить соединение WebSocket, клиент и сервер обновляются с протокола HTTP до протокола Web Socket во время первоначального рукопожатия, как показано в примере 1. После установки кадры данных WebSocket могут быть отправлены туда и обратно между клиентом и сервером в полнодуплексный режим.
   Пример 1 - подтверждение обновления WebSocket  
 от клиента к серверу:
GET / демонстрационный HTTP / 1.1
Обновление: WebSocket
Подключение: Обновление
Хост: example.com
Происхождение: http://example.com
WebSocket-Protocol: образец 
 От сервера к клиенту:
Подтверждение связи протокола веб-сокетов HTTP / 1.1 101
Обновление: WebSocket
Подключение: Обновление
WebSocket-Origin: http://example. com
WebSocket-Location: ws: // example.com / demo
WebSocket-Protocol: образец 
 Незашифрованные соединения WebSocket 
 Сам протокол Web Socket не знает о прокси-серверах и брандмауэрах; он просто определяет подтверждение обновления WebSocket и формат фреймов данных WebSocket. Давайте посмотрим на незашифрованный трафик WebSocket в двух сценариях прокси-сервера (явном и прозрачном).
 Незашифрованные соединения WebSocket и явные прокси-серверы 
 Если браузер настроен на использование явного прокси-сервера, он сначала отправит метод  HTTP CONNECT  этому прокси-серверу при установлении соединения WebSocket.Например, для подключения к серверу  example.com  с использованием схемы  ws: //  (обычно через порт 80) клиент браузера отправляет на прокси-сервер метод  HTTP CONNECT , показанный в примере 2.
   Пример 2 - метод HTTP CONNECT с использованием порта 80  
CONNECT example. com:80 HTTP / 1.1
Хост: example.com 
 Когда явный прокси-сервер разрешает метод  CONNECT , может быть выполнено квитирование обновления соединения WebSocket, и когда это квитирование завершится успешно, трафик WebSocket может начать беспрепятственный поток через прокси-сервер.
 Незашифрованные соединения WebSocket и прозрачные прокси-серверы 
 В случае, если незашифрованный трафик WebSocket проходит через прозрачный прокси-сервер на своем пути к серверу WebSocket, на практике соединение, скорее всего, не удастся, поскольку в этом случае браузер не запускает метод  CONNECT . Когда прокси-сервер пересылает запрос на сервер (WebSocket), ожидается, что он отключит определенные заголовки, включая заголовок Connection. Следовательно, прозрачный прокси-сервер с хорошим поведением практически сразу приведет к сбою подтверждения обновления WebSocket.
 Не все прокси-серверы соответствуют стандарту HTTP в отношении ожидаемого поведения прокси. Например, некоторые прокси-серверы настроены как , а не , чтобы удалить заголовок  Connection: Upgrade  и передать его на сервер WebSocket, который, в свою очередь, отправляет ответ  101 Web Socket Protocol Handshake . Проблемы возникают тогда, когда клиент или сервер начинает посылать первый кадр WebSocket. Поскольку кадр не похож ни на что, на что может рассчитывать прокси-сервер (например, на обычный HTTP-трафик), скорее всего возникнет какое-то исключение, если только прокси-сервер не настроен специально для обработки трафика WebSocket.
 Поэтапное обновление 
 Во время квитирования WebSocket на сервер WebSocket отправляется заголовок  Connection: Upgrade . Если прокси-сервер должен участвовать в механизме обновления, потребуется дополнительная настройка прокси-сервера, поскольку используется пошаговый транспорт; Обновление, отправленное с прокси-сервера в браузер, подходит только для этого одного прыжка, и прокси-сервер должен отправить свой собственный заголовок обновления для обработки следующего прыжка с прокси-сервера на сервер WebSocket (или на еще один промежуточный сервер). Кроме того, прокси-сервер должен прекратить обработку запроса как HTTP.
 Сегодня большинство прозрачных прокси-серверов еще не знакомы с протоколом Web Socket, и эти прокси-серверы не смогут поддерживать протокол Web Socket. Однако в будущем прокси-серверы, вероятно, станут осведомленными о веб-сокетах и смогут правильно обрабатывать и пересылать трафик веб-сокетов.
 Зашифрованные соединения WebSocket 
 Теперь давайте посмотрим на зашифрованный трафик WebSocket в двух сценариях прокси-сервера (явном и прозрачном).
 Зашифрованные соединения WebSocket и явные прокси-серверы 
 Если браузер настроен на использование явного прокси-сервера, он сначала выдаст метод HTTP  CONNECT  этому прокси-серверу при установлении соединения WebSocket. Например, для подключения к серверу  example.com  с использованием схемы  wss: //  (обычно через порт 443) клиент браузера отправляет HTTP  CONNECT  метод, показанный в примере 3, на прокси-сервер.
   Пример 3 - метод HTTP CONNECT с использованием порта 443  
CONNECT example.com:443 HTTP / 1.1
Хост: example.com 
 Когда явный прокси-сервер разрешает метод  CONNECT , отправляется подтверждение TLS, за которым следует подтверждение обновления соединения WebSocket. После успешного установления связи трафик WebSocket может начать беспрепятственно проходить через прокси-сервер. HTTPS (HTTP через TLS) работает точно так же; использование шифрования обычно запускает метод HTTP  CONNECT .
 Зашифрованные соединения WebSocket и прозрачные прокси-серверы 
 В случае прозрачных прокси-серверов браузер не знает о прокси-сервере, поэтому метод HTTP  CONNECT  не отправляется. Однако, поскольку проводной трафик зашифрован, промежуточные прозрачные прокси-серверы могут просто пропускать зашифрованный трафик, поэтому гораздо больше шансов, что соединение WebSocket будет успешным, если используется Web Sockets Secure. Поэтому для подключения к серверу WebSocket всегда лучше использовать Web Sockets Secure с шифрованием TLS, если вы не уверены, что посредников нет.Хотя это дает дополнительное преимущество в виде большей безопасности, шифрование TLS действительно увеличивает потребление ЦП как на клиенте, так и на сервере, хотя обычно это не является значительным увеличением, а с аппаратным ускорением SSL / TLS его можно снизить почти до нуля.
 Подведем итоги. На экране 2 показаны решения, которые принимаются во время установки соединения WebSocket между браузером и сервером WebSocket. На рисунке показаны различные сценарии подключения как в случае WebSocket ( ws: // ), так и в случае WebSocket Secure ( wss: // ) с явными и прозрачными прокси-серверами.
  Рисунок 2 - дерево решений обхода прокси-сервера 
 На рисунке 2 показано, как использование незашифрованных соединений WebSocket с большей вероятностью приведет к сбою во всех топологиях сети, кроме простейших. Все сводится к пониманию сквозной топологии сети, в которой вы развертываете приложение WebSocket. Некоторые прокси-серверы HTTP могут ограничивать порты или разрешать доступ только определенным авторизованным серверам. Сервер WebSocket, который используется в таком сценарии, должен быть добавлен в белый список серверов для успешного подключения.Как правило, решение о том, какой протокол ( ws: //  или  wss: // ) использовать для подключения, должно приниматься заранее разработчиком клиента, а также основываться на характеристиках конфиденциальности проводного трафика WebSocket. . В будущем шлюзы и серверы WebSocket могут даже иметь возможность динамически обновляться до Web Sockets Secure, если обнаруживается неработающий прокси-сервер.
 Шлюз Kaazing WebSocket и прокси-серверы 
 Kaazing WebSocket Gateway поддерживает эмуляцию веб-сокетов, что делает веб-сокеты доступными во всех браузерах, включая те, которые не поддерживают веб-сокеты.Эта эмуляция работает в среде чистого JavaScript, без плагинов, но также включает уникальную технологию Opportunistic Optimization ™ от Kaazing, которая обеспечивает наилучшую возможную среду соединения, независимо от того, поддерживают ли клиенты и промежуточные прокси-серверы новейшие протоколы.
 Например: если Kaazing WebSocket Gateway обнаруживает наличие подключаемого модуля Flash, клиентские библиотеки могут использовать преимущества одиночного (Flash) TCP-сокета, и если прямое подключение невозможно (например, если связь должна проходить через брандмауэр или прокси-сервер HTTP), то клиентские библиотеки по-прежнему могут использовать преимущества среды выполнения Flash, минимизируя профиль памяти клиента.
 Если промежуточные прокси-серверы находятся между Kaazing WebSocket Gateway и клиентом, то используется высокооптимизированное зашифрованное потоковое соединение, и шлюз  с поддержкой прокси-сервера  автоматически перенаправляет HTTP-запрос, чтобы он использовал зашифрованное HTTP (HTTPS) соединение с сделать прокси-сервер независимым от потокового характера нисходящего HTTP-трафика. В производственной среде можно было бы ожидать, что потоковая передача HTTPS может использоваться как наихудший сценарий, к которому можно вернуться.Однако для этого шлюз должен быть настроен с подходящим сертификатом для шифрования TLS. Без этого (это следует рассматривать как ошибку конфигурации) Kaazing вернется к расширенной реализации без потоковой передачи.
 Эмуляция веб-сокетов Kaazing высоко оптимизирована и легко превосходит большинство устаревших решений Comet, поскольку может гарантировать минимальную задержку за счет возврата к потоковой передаче HTTPS благодаря базовой поддержке Kaazing для запросов HTTP и HTTPS между источниками.Обратите внимание, что различные сценарии отката используются только в режиме эмуляции. Одним из основных преимуществ использования Kaazing WebSocket Gateway и его эмуляции веб-сокетов является то, что вы можете кодировать приложения в соответствии со стандартом веб-сокетов HTML5 уже сегодня, и эти приложения будут работать во всех браузерах.
 Маршрутизаторы и брандмауэры с балансировкой нагрузки 
 В этом разделе описывается, как веб-сокеты HTML5 работают с маршрутизаторами балансировки нагрузки и межсетевыми экранами. Кроме того, в нем объясняется, как Kaazing WebSocket Gateway может добавить дополнительную ценность.
 Веб-сокеты HTML5 и маршрутизаторы с балансировкой нагрузки 
 Для этого обсуждения давайте различим два разных типа маршрутизаторов с балансировкой нагрузки:
 Ø  Маршрутизаторы с балансировкой нагрузки TCP (Layer-4)  должны хорошо работать с веб-сокетами HTML5, потому что у них один и тот же профиль подключения: подключайтесь один раз вперед и оставайтесь на связи, а не с профилем запроса-ответа на передачу документов HTTP.
 Ø  Балансировка нагрузки HTTP (Layer-7)  Маршрутизаторы   ожидают HTTP-трафик и могут легко запутаться в трафике обновления WebSocket.По этой причине может потребоваться настроить маршрутизаторы с балансировкой нагрузки уровня 7, чтобы они явно знали трафик WebSocket.
 Веб-сокеты и брандмауэры HTML5 
 Поскольку брандмауэры обычно просто обеспечивают соблюдение правил для отклонения входящего трафика и маршрутизации исходящего трафика (например, через прокси-сервер), обычно нет особых проблем, связанных с трафиком WebSocket.
 Шлюз Kaazing Websocket и маршрутизаторы с балансировкой нагрузки 
 Маршрутизаторы Layer-7 с балансировкой нагрузки могут быть сбиты с толку из-за запросов обновления протокола WebSocket, когда они помещаются на критический путь между браузером и несколькими серверами WebSocket.По этой причине службы, работающие на Kaazing WebSocket Gateway, поддерживают  однорангового балансировщика нагрузки , который позволяет настраивать балансирующий маршрутизатор как одноранговый узел рядом с серверами WebSocket. Таким образом, маршрутизатор с балансировкой нагрузки обрабатывает только начальные клиентские запросы и обнаруживает лучший активный экземпляр шлюза для маршрутизации трафика.
 После того как маршрутизатор с балансировкой нагрузки выбрал экземпляр шлюза, экземпляр шлюза может перенаправить браузер для прямого подключения к этому активному экземпляру шлюза.Это означает, что маршрутизатор с балансировкой нагрузки не мешает реальному трафику WebSocket, сокращая таким образом задержку. Однако в случае аппаратного сбоя или сетевой ошибки клиенты автоматически переподключаются к маршрутизатору с балансировкой нагрузки, который автоматически перенаправляет эти запросы на другой активный экземпляр Kaazing Gateway.
 Комета и прокси-серверы 
 Наконец, давайте посмотрим, как Comet работает с прокси-серверами. Поскольку стандарт Comet как таковой отсутствует, давайте различим два типа реализаций Comet:  с длинным опросом  и  с потоковой передачей .
 Ø  Длинный опрос , при условии, что он реализован надежно, не будет страдать от слишком большого количества проблем с прокси-сервером, потому что он по-прежнему просто использует модель HTTP-запроса и ответа. Однако каждый запрос и ответ несет в себе много ненужных накладных расходов и задержек в HTTP-заголовке. Вот где действительно выделяются веб-сокеты HTML5 - они могут обеспечить сокращение ненужного сетевого трафика до 1000: 1 и уменьшить задержку.
  См. Также : наша оранжевая бумага.   Веб-сокеты - квантовый скачок в масштабируемости для Интернета.   предоставляет подробный анализ значительного сокращения ненужного сетевого трафика, которое веб-сокеты HTML5 обеспечивают по сравнению с устаревшими решениями Comet.
 Ø  Streaming  часто намного более эффективен, чем длинный опрос, потому что он сохраняет ответ открытым на сервере и отправляет клиенту только важные данные по открытому соединению. Однако этот подход страдает от вышеупомянутых проблем с прокси-сервером. Например, прокси-сервер может буферизовать ответ и вызывать задержку. В качестве альтернативы, прокси-сервер может быть настроен на отключение HTTP-соединений, которые остаются открытыми в течение определенного времени. Вот почему в большинстве устаревших решений Comet просто используется длинный опрос.
 Сводка 
 Хотя сам протокол HTML5 Web Socket не знает о прокси-серверах и брандмауэрах, он поддерживает HTTP-совместимое рукопожатие, так что HTTP-серверы могут использовать свои порты HTTP и HTTPS по умолчанию (80 и 443) с сервером WebSocket. Некоторые прокси-серверы безвредны и прекрасно работают с веб-сокетами; другие будут препятствовать правильной работе веб-сокетов, что приведет к сбою соединения. В некоторых случаях может потребоваться дополнительная конфигурация прокси-сервера, а некоторые прокси-серверы могут потребовать обновления для поддержки веб-сокетов.
 Если браузер настроен на использование явного прокси-сервера   (как для зашифрованных, так и для незашифрованных соединений WebSocket), то он сначала выдаст метод HTTP  CONNECT  этому прокси-серверу при установке соединения WebSocket.
 Если используется незашифрованное соединение WebSocket ( ws: // ), то в случае прозрачных прокси-серверов   браузер не знает о прокси-сервере, поэтому HTTP  CONNECT  не отправляется.В результате сегодня на практике соединение почти не будет нарушено.
 Если используется зашифрованное соединение WebSocket Secure ( wss: // ), то в случае прозрачных прокси-серверов браузер не знает о прокси-сервере, поэтому HTTP  CONNECT  не отправляется. Однако, поскольку проводной трафик зашифрован, промежуточные прозрачные прокси-серверы могут просто пропускать зашифрованный трафик, поэтому гораздо больше шансов, что соединение WebSocket будет успешным, если используется зашифрованное соединение WebSocket.
 Kaazing WebSocket Gateway - это высокооптимизированный шлюз WebSocket с поддержкой прокси, который обеспечивает встроенную поддержку WebSocket, а также эмуляцию Web Socket для старых браузеров. Если обнаруживаются промежуточные прокси-серверы, то для нисходящего HTTP-трафика используется оптимизированное зашифрованное потоковое соединение. Это стало возможным благодаря базовой поддержке Kaazing для запросов HTTP и HTTPS из разных источников. В полевых условиях нам удавалось установить соединение WebSocket - собственное или эмулированное - со шлюзом Kaazing WebSocket Gateway в 100% случаев.
 Об авторе 
 Питер Любберс - директор по документации и обучению в Kaazing, где он курирует все аспекты документации и обучения.
No related posts.