Fatal编程技术网
  • http/
  • Http SecureSocket中支持哪些协议？

Http SecureSocket中支持哪些协议？

http websocket dart

Http SecureSocket中支持哪些协议？,http,websocket,dart,Http,Websocket,Dart,查看的文档时，我看到方法secure/connect/secureServer中有一个参数称为supportedProtocols 这是什么 可能的价值是什么 订单重要吗 历史上未加密的应用程序协议通常分配自己的端口（例如http的80，smtp的25） ALPN：如今，大多数流量都是通过TLS加密的，TLS是一种安全的传输协议。任何应用程序协议都可以使用它。没有为应用程序协议使用新的端口号，而是提供了一种不同的解决方案：TLS支持称为ALPN（应用程序级协议协商）的扩展，该扩展允许客户端/服

查看的文档时，我看到方法
secure
/
connect
/
secureServer
中有一个参数称为
supportedProtocols

  • 这是什么
  • 可能的价值是什么
  • 订单重要吗
历史上未加密的应用程序协议通常分配自己的端口（例如
http
的
80
，
smtp的
25
）

ALPN：如今，大多数流量都是通过TLS加密的，TLS是一种安全的传输协议。任何应用程序协议都可以使用它。没有为应用程序协议使用新的端口号，而是提供了一种不同的解决方案：TLS支持称为ALPN（应用程序级协议协商）的扩展，该扩展允许客户端/服务器告诉对等方他们支持哪些协议以及他们喜欢什么（可能有一个由端口号推断出的协议的回退——这对向后兼容性很好）

（旁注：还有一个称为NPN“下一个协议协商”的前体TLS扩展，用于类似目的，但由于各种原因被弃用）

最常见的用例是http/2：服务器在端口
443
上侦听，并提供讲话
http/1.1
，
http/2
，比如说
spdy
。浏览器将建立到服务器端口
443
的TCP连接，让服务器知道它支持哪些协议。然后服务器将选择哪个协议otocol说话（基于客户端发送的列表和服务器应用程序支持的内容）。为了向后兼容，如果没有协商协议，客户端/浏览器将退回到http/1.1

谈判和优先权有3种情况：

  • 客户端或服务器不支持ALPN扩展：未协商任何协议

  • 客户端和服务器支持ALPN，但没有通用协议：没有协议

  • 客户端和服务器支持ALPN，并且有一个或多个协议都支持：采用具有最高优先级的协议

Dart支持：Dart不久前添加了对ALPN的支持，并通过名为
supportedProtocols
的可选参数将其公开给

  • 客户部分
  • 对于服务器部分
一旦建立TLS连接，两端将能够通过查看协商的协议。如果对等方不支持ALPN TLS扩展或没有公共协议，则
selectedProtocol
将
null

supportedProtocols
中的协议以递减优先顺序指定（将选择列表中服务器/客户端之间通用的第一个协议）

ALPN标识符协议标识符没有实际限制。您的应用程序可以使用自己的标识符。尽管对于公共协议，RFC通常会建议使用哪些标识符，例如，在：

字符串“h2”标识HTTP/2使用传输层安全性（TLS）的协议

自己检查它：如果您非常好奇，您可以使用网络数据包检查器（如较新版本的）来检查TLS流量，并查看提供了哪些ALPN协议

  • 这是什么？

    客户端支持安全通信的协议列表

  • 可能的值是什么？

    用斜杠分隔的协议和版本的名称（例如
    “http/1.1”
    ）

  • 订单重要吗？

    是的。优先级是按降序设置的

    • 一些解释：

    TLS
    有一个扩展名为
    ALPN
    ，它（顾名思义）用于协商用于安全通信的应用层协议

    在
    ALPN
    中，使用上面指定的格式识别协议

    SecureSocket
    实现
    TLS
    ，因此必须接收要在
    ALPN
    阶段使用的协议列表参数

    除非您的服务器和客户端正在实现自定义通信协议，否则我建议您只使用
    “http/1.1”

    更多信息：

    我可以在Dart源中找到的传递给
    SecureServer
    的协议列表的唯一文档位于
    SecurityContext.\u protocolstolengtencoding
    （
    io/security\u context.Dart:190
    ）：

    以及：

    “标识序列”是以ASCII字节表示的协议标识符。它是在协商阶段通过套接字发送的原始数据

    有趣的事实：在Dart中，
    SecurityContext.\u protocolstolengtencoding
    方法将协议标识符从字符串编码为字节

    希望这有帮助

    /// 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.

    "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. 

    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