При взгляде на документацию SecureSocket, я вижу, что в методах есть параметр secure/connect/secureServer под названием supportedProtocols.Какие поддерживаемые протоколы в SecureSocket?
Что это?
список протоколов, которые клиент поддерживает для безопасной связи
Каковы возможные значения?
Названия протоколов и версий, разделенные косой чертой (например "http/1.1")
ли порядок важно?
Да. Приоритет устанавливается в порядке убывания
Некоторые пояснения:
TLS имеет расширение под названием ALPN, который (как следует из названия) используется для согласования протокола прикладного уровня, которые будут использоваться для безопасного коммуникации.
В протоколах ALPN протоколы идентифицируются с использованием указанного выше формата.
SecureSocket реализует TLS и поэтому должен принять параметр списка протоколов, который будет использоваться на этапе ALPN.
Если ваш сервер и клиент не используют специальный протокол связи, я бы рекомендовал вам использовать только "http/1.1".
Подробнее:
Единственная документация списка протокола, переданного SecureServer я мог бы найти в источниках дротик в SecurityContext._protocolsToLengthEncoding (io/security_context.dart:190):
/// Encodes a set of supported protocols for ALPN/NPN usage.
///
/// The `protocols` list is expected to contain protocols in descending order
/// of preference.
///
/// See RFC 7301 (https://tools.ietf.org/html/rfc7301) for the encoding of
/// `List<String> protocols`:
/// opaque ProtocolName<1..2^8-1>;
///
/// struct {
/// ProtocolName protocol_name_list<2..2^16-1>
/// } ProtocolNameList;
///
/// The encoding of the opaque `ProtocolName<lower..upper>` vector is
/// described in RFC 2246: 4.3 Vectors.
///
/// Note: Even though this encoding scheme would allow a total
/// `ProtocolNameList` length of 65535, this limit cannot be reached. Testing
/// showed that more than ~ 2^14 bytes will fail to negotiate a protocol.
/// We will be conservative and support only messages up to (1<<13)-1 bytes.
Идущий через RFC 7301 (ALPN описание):
"ProtocolNameList" contains the list of protocols advertised by the
client, in descending order of preference. Protocols are named by
IANA-registered, opaque, non-empty byte strings, as described further
in Section 6 ("IANA Considerations") of this document.
И section 6:
Protocol: HTTP/1.1
Identification Sequence:
0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 ("http/1.1")
Reference: [RFC7230]
Protocol: SPDY/1
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
Protocol: SPDY/2
Identification Sequence:
0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
Reference:
http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2
"Идентификация последовательности" является идентификатор протокола в ASCII байт. Это сырые данные, отправленные на этапе согласования через сокет.
Забавный факт: в Dart метод SecurityContext._protocolsToLengthEncoding - это то, что кодирует идентификаторы протокола от строки до байтов.
Надеюсь, это помогло!
Исторически незашифрованные прикладные протоколы, как правило, присваивается свой собственный порт (например 80 для http, 25 для smtp).
ALPN: В настоящее время большая часть трафика зашифровывается через TLS, который является безопасным транспортным протоколом. Любой протокол приложения может использовать его. Вместо использования новых номеров портов для протоколов приложений доступно другое решение: TLS поддерживает расширение, известное как ALPN (протокол протокола на уровне приложений), который позволяет клиенту/серверу сообщать партнеру, какие протоколы они поддерживают и что они предпочитают (возможно, с откатом к протоколу, выведенному номером порта, который отлично подходит для обратной совместимости)
(примечание к стороне: также существовало предшественное расширение TLS, известное как NPN «Next Protocol Negotiation», служащее аналогичной цели, но оно устарела по различным причинам)
Наиболее распространенный вариант использования http/2: Серверы прослушивают порт 443 и fer говорить http/1.1, http/2 и скажем spdy. Браузер сделает TCP-соединение с портом сервера 443 и дайте серверу знать, какие протоколы он поддерживает. Затем сервер будет выбирать, какой протокол говорить (на основе списка, отправленного клиентом, и того, что поддерживает серверное приложение). Для обратной совместимости клиент/браузеры откатываются до http/1.1, если протокол не был согласован.
Negogiation & Приоритет Есть 3 случая:
клиент или сервер не поддерживает расширение ALPN: Никакой протокол не был negogiated
Client и поддержка сервера ALPN, но не имеют общего протокола : Протокол не был подвергнут неоконсервации
Поддержка клиентов и серверов ALPN и один или несколько протоколов поддерживают: Выполняется протокол с наивысшим приоритетом.
поддержка Dart: Dart добавлена поддержка ALPN некоторое время назад и выставляет его с помощью дополнительного имени supportedProtocols параметра
Как только соединение TLS установлено, оба конца смогут увидеть протокол с отрицанием через SecureSocket.selectedProtocol. Если партнер не поддерживает расширение ALPN TLS или не было общего протокола, то selectedProtocol будет null.
Протоколы в supportedProtocols указаны в снижении предпочтений (будет выбран первый из списка, который является общим для сервера/клиента).
Идентификаторы ALPN Нет никаких реальных ограничений на то, что могут быть идентификаторами протокола. Ваше приложение может использовать свое. Хотя для общественных протоколов, как правило, РЛК будет рекомендовать, какие идентификаторы использовать, например RFC 7540 указывает на section 3.1:
«Строка„h2“идентифицирует протокол, где HTTP/2 использует Transport Layer Security (TLS)»
Осмотрите его самостоятельно: Если вам очень любопытно, вы можете использовать инспектор сетевых пакетов, например, более новые версии wireshark, для проверки трафика TLS и просмотра того, какие протоколы ALPN предлагаются.