3
查看SecureSocket的文檔時，我看到方法secure/connect/secureServer中有一個參數，名爲supportedProtocols。SecureSocket支持哪些協議？
- 這是什麼？
- 有什麼可能的值？
- 訂單重要嗎？
A
回答
3
這是什麼？
協議列表，該客戶端支持安全通信
可能是什麼值？用斜線分開的協議和版本的
名稱（例如
"http/1.1"）的命令是重要的？
是的。
TLS具有稱爲ALPN的延伸，其中（顧名思義）用於協商的應用層協議被用於安全：優先以降序
一些解釋設置通訊。
在ALPN協議使用上面指定的格式來標識。
SecureSocket implements 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.
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方法是將協議標識符從字符串編碼爲字節的方法。
希望這有助於！
3
歷史未加密的應用協議，通常被分配自己的端口（例如爲80http，25爲smtp）。
ALPN：現在大多數流量都是通過安全傳輸協議TLS進行加密的。任何應用協議都可以使用它。與其爲應用協議使用新的端口號，不同的解決方案是可用的：TLS支持稱爲ALPN（應用級協議協商）的擴展，其允許客戶機/服務器告訴對等體它們支持哪些協議以及他們喜歡什麼（可能後退到由端口號推導的協議 - 這對於向後兼容性是很好的）
（注意：還有一個稱爲NPN的前驅TLS擴展「Next Protocol Negotiation」，它服務於類似的目的，但它不推薦用於各種原因）
最常見的情況是http/2：服務器偵聽端口443和女士說話http/1.1，http/2，比如說spdy。瀏覽器將建立到服務器端口443的TCP連接，讓服務器知道它支持哪些協議。然後，服務器將選擇要說的協議（基於客戶端發送的列表以及服務器應用程序支持的內容）。爲了向後兼容，如果沒有協議協商，客戶端/瀏覽器將退回到http/1.1。
Negogiation &優先有3種情況：
客戶機或服務器不支持ALPN擴展：無協議是negogiated
客戶端和服務器支持ALPN但沒有共同的協議：沒有協議被標記
客戶端和服務器支持ALPN，並且有一個或多個協議都支持：採用具有最高優先級的協議。
飛鏢支持：飛鏢增加了對ALPN前一段時間，並通過可選的命名supportedProtocols參數暴露了它
- SecureSocket.conect爲服務器部分 客戶端部分
- SecureServer.bind
一旦建立TLS連接，兩端將能夠通過SecureSocket.selectedProtocol看到negogiated協議。如果對方不支持ALPN TLS擴展或者沒有公共協議，則selectedProtocol將是null。
supportedProtocols中的協議是以減少的優先級指定的（列表中的第一個將在服務器/客戶端之間通用）。
ALPN標識符協議標識符可以是什麼沒有真正的限制。您的應用程序可以使用自己的。雖然公共協議，通常的RFC將推薦使用哪些標識符，例如RFC 7540指定在section 3.1：
「的字符串‘H2’標識了HTTP/2使用傳輸層安全協議（TLS）」
自己檢查：如果您非常好奇，可以使用網絡數據包檢查器（如wireshark的較新版本）檢查TLS流量並查看提供的ALPN協議。