Tls
為什麼 TLS 使用帶內握手信號
TLS 使用握手協議來計算會話密鑰，以供以後使用以保護大量應用程序數據傳輸。握手協議和應用協議使用相同的傳輸層埠。
IPSec 將 IKE 用於兩個端點之間的密鑰協議。這裡的密鑰協商協議使用一個單獨的基於 UDP 的傳輸通道。來自應用程序的數據不通過此 UDP 埠發送。
在某種程度上，IPSec 使用帶外握手，而 TLS 使用帶內握手。
為什麼 TLS 設計者選擇為握手和應用協議使用相同的傳輸層埠？如果類似 TLS 的安全協議被設計為執行握手和應用程序協議以在不同的傳輸層埠上執行，這會產生什麼影響？
IPSec 將 IKE 用於兩個端點之間的密鑰協議。這裡的密鑰協商協議使用一個單獨的基於 UDP 的傳輸通道。來自應用程序的數據不通過此 UDP 埠發送。
實際上，我在這裡看到兩個錯誤的陳述
- IPsec 並不總是使用 IKE 來進行密鑰協商。很多時候確實如此，但是在現實世界的實現中，IPsec 與其他一些協議一起使用。
- 即使 IPsec 和 IKE 一起使用，有時它們使用相同的 UDP 埠。如果他們使用的是 NAT-T（RFC 3947、3948），那麼所有流量（IKE 和 IPsec）都將通過同一個埠。
但是，要解決您的問題：
為什麼 TLS 設計者選擇為握手和應用協議使用相同的傳輸層埠？
我不是 Eric Rescorla，但我懷疑他們從未真正考慮過使用兩個獨立埠進行控制和數據的可能性。如果他們有，他們會立即發現，對他們來說，使用一個埠更好，因為 a) 它為他們簡化了事情，b) 他們沒有理由不這樣做。
至於簡化的，一方面，控制記錄中關於他們正在談論的數據通道沒有歧義。此外，TLS 假設同向流動的記錄是按順序傳遞的，因此他們不必擔心發出控制記錄，然後是數據記錄，數據記錄先到達的情況。如果他們使用不同的 TLS 埠，這將是一個需要解決的可能性。
如果類似 TLS 的安全協議被設計為執行握手和應用程序協議以在不同的傳輸層埠上執行，這會產生什麼影響？
需要注意我上面提到的問題（不是太難），他們還必須擔心中間設備（防火牆、NAT 設備）對這兩個不明顯連接的 TCP 流的關係感到困惑。