TLS 錯誤啟動/早期數據
應用程序使用此類機制的頻率。支持 TLS 的這些功能是否真正需要？
瀏覽器供應商推動減少延遲。在他們的測量中，TLS 握手的初始延遲似乎足夠大，足以損害感知的使用者體驗。確實，完整的 TCP 握手 + TLS 握手可能具有很大的延遲（三個往返行程，這可能會增加相當長的時間，特別是在考慮通過地球靜止衛星的連結時）。
舊理論認為 TLS 握手延遲無關緊要，因為您可以保持連接打開，因此您只需支付一次費用。但是，現代 Web 使用者不會像使用本地應用程序那樣使用 Web 站點。他會從一個站點跳到另一個站點。此外，Web 站點現在是複雜的腳本組合，這些腳本可以從其他伺服器載入其他腳本，並且所有延遲都會加起來。
這導致瀏覽器供應商探索其他策略，包括 TLS 的錯誤啟動/早期數據，以減少延遲。在Google，他們甚至決定通過將QUIC定義為使用 UDP 來代替TCP 三次握手。
您可能會注意到以上所有內容都是關於 Web 瀏覽器的。應用程序的要求變化很大，具體取決於上下文。現代網路結合了許多短暫的連接和不耐煩的人類使用者，這可能解釋了對減少延遲的追求。
當然，這些修改並不是純粹的優化問題。例如，對於 TLS “錯誤啟動”，客戶端在驗證
Finished來自伺服器的消息之前發送其數據：此時，客戶端無法保證它一直在與預期的伺服器(*)通信；它只知道它發送的內容對於假伺服器是無法理解的。TLS 1.3 的“0-RTT”特性天生就容易受到重放攻擊，很難知道何時可以安全使用 0-RTT。TLS 1.3 draft 23, section E.5提供了一些指導，但（通常）使用術語“冪等”而不對其進行定義，這讓讀者有點不知所措。
可以預料，當 TLS 1.3 最終部署到某些特定的 Web 瀏覽器和伺服器之外時，0-RTT 將在不安全的上下文中被啟動，因為開發人員和管理員只想要“更快的速度”。