㈠ HTTP 1.0、1.1、2.0、3.0區別
1.0的HTTP版本，是一種無狀態，無連接的應用層協議。 HTTP1.0規定瀏覽器和伺服器保持短暫的鏈接。
瀏覽器每次請求都需要與伺服器建立一個TCP連接，伺服器處理完成以後立即斷開TCP連接(無連接)，伺服器不跟蹤也每個客戶單，也不記錄過去的請求(無狀態)。
這種無狀態性可以藉助cookie/session機制來做身份認證和狀態記錄。
HTTP1.1繼承了HTTP1.0的簡單，克服了HTTP1.0性能上的問題。
深入理解可參考這篇文章： https://mp.weixin.qq.com/s/a83_NE-ww36FZsy320MQFQ
所有HTTP2.0通信都在一個TCP鏈接上完成，這個鏈接可以承載任意流量的雙向數據流。
每個數據流以消息的形式發送，而消息由一或多個幀組成。這些幀可以亂序發送，然後再根據每個幀頭部的流標識符(Stream_id)重新封裝。
多路復用(連接共享)可能會導致關鍵字被阻塞，HTTP2.0里每個數據流都可以設置優先順序和依賴，優先順序高的數據流會被伺服器優先處理和返回客戶端，數據流還可以依賴其他的子數據流。
可見，HTTP2.0實現了真正的並行傳輸，它能夠在一個TCP上進行任意數量的HTTP請求。而這個強大的功能基於「二進制分幀」的特性。
基於Google的QUIC，HTTP3 背後的主要思想是放棄 TCP，轉而使用正脊基於 UDP 的 QUIC 協議。
與 HTTP2 在技術上允許未加密的通信不同，QUIC 嚴格要求加密後才能建立連接。此外，加密不僅適用於 HTTP 負載，還適用於流經連接的所有數據，從而避免了一大堆安廳李全問題。建立持久連接、協商加密協議，甚至發送第一批數據都被合並到 QUIC 中的單個請求/響應周期中，從而大大減少了連接等待時間。如果客戶端具有本地緩存的密碼參數，則可以通過簡化的握手（0-RTT）重新建立與已知主機的連接。
為了解決傳輸級別的線頭阻塞問題，通過 QUIC 連接傳輸的數據被分為一些流。流是持久性 QUIC 連接中短暫、獨立的「子連接」。每個流都處理自己的錯誤糾正和傳遞保證，但使用連接全局壓縮和加密屬性。每個客戶端發起的 HTTP 請求都在單獨扮清遲的流上運行，因此丟失數據包不會影響其他流/請求的數據傳輸。
㈡ http和https的區別http與TCP/IP區別http/TCP三次握手四次揮手
https, 全稱Hyper Text Transfer Protocol Secure，相比http，多了一個secure，這一個secure是怎麼來的呢？這是由TLS（SSL）提供的，這個又是什麼呢？估計你也不想知道。大概就是一個叫openSSL的library提供的。https和http都屬於冊慎application layer，基於TCP（以及UDP）協議，但是又完全不一樣。TCP用的port是80， https用的是443（值得一提的是，google發明了一個新的協議，叫QUIC，並不基於TCP，用的port也是443， 同樣是用來給https的。谷歌好牛逼啊。）總體來說，https和http類似，但是比http安全。
http預設工作在TCP協議80埠(需要國內備案），用戶訪問網站http://打頭的都是標准http服務，http所封裝的信息都是明文的，通過抓包工具可以分析其信息內容，如果這些信息內容包含你的銀行卡賬號、密碼，你肯定無法接受這種服務，那有沒有可以加密這些敏感信息的服務呢？那就是https！
https是http運行在SSL/TLS之上，SSL/TLS運行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的密鑰用伺服器方的證書進行了非對稱加密。此外客戶端可以驗證伺服器端的身份，如果配置了客戶端驗證，伺服器方也可以驗證客戶端的身份。
https預設工作在tcp協議443埠，它的工作流程一般如以下方式：
1、完成tcp三次同步握手；
2、客戶端驗證伺服器數字證書，通過，進入橘蔽步驟3；
3、DH演算法協商對稱加密演算法的密鑰、hash演算法的密鑰；
4、SSL安全加密隧道協商完成；
5、網頁以加密的方式傳輸，用協商的對稱加密演算法和密鑰加密，保證數據機密性；用協商的hash演算法進行數據完整性保護，保證數據不被篡改。
附：https一般使用的加密與hash演算法如下：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法：AES，RC4，3DES
hash演算法：MD5，SHA1，SHA256
如果https是網銀服務，以上SSL安全隧道成功建立才會要求用戶輸入賬戶信息，賬戶信息是在安全隧道里傳輸，所以不會泄密！
TPC/IP協議是傳輸層協議，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。Web使用HTTP協議作應用層協議，以封裝HTTP 文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。
下面的圖表試圖顯示不同的TCP/IP和其他的協議在最初OSI（Open System Interconnect）模型中的位置：
CA證書是什麼？
CA（Certificate Authority）是負責管理和簽發證書的第三方權威機構，是所有行業和公眾都信任的、認可的。
CA證書，就是CA頒發的證書，可用於驗證網站是否可信（針對HTTPS）、驗證某文件是否可信（是否被篡改）等，也可以用一個證書來證明另一個證書是真實可信，最頂級的證書稱為根證書。除了根證書（自己證明自己是可靠），其它證書都要依靠上一級的證書，來證明自己。
https大致過程：
1、建立伺服器443埠連接 ；
2、SSL握手：隨機數，證書，密鑰，加密演算法；
3、發送加密請求 ；
4、發送加密響應；
5、關閉SSL；
6、關閉TCP.
SSL握手大致過程：
1、客戶端發送隨機數1，支持的加密方法（如RSA公鑰加密）；
2、服務端發送隨機數2，和伺服器公鑰，並確認加密方法；
3、客戶端發送用伺服器公鑰加密的隨機數3；
4、伺服器用私鑰解密這個隨機數3，用加密方法計算生成對稱加密的密鑰給客戶端；
5、接下來的報文都用雙方協定好的加密方法和密鑰，進行加密.
1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發送數據之前不需要建立連接
2、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數圓姿州據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3、TCP面向位元組流，實際上是TCP把數據看成一連串無結構的位元組流（流模式）;UDP是面向報文的（報文模式），UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5、TCP要求系統資源較多，UDP較少。TCP首部開銷20位元組;UDP的首部開銷小，只有8個位元組
SYN：同步序列編號; ACK=1: 確認序號 ; FIN附加標記的報文段（FIN表示英文finish）
一個TCP連接必須要經過三次「對話」才能建立起來，其中的過程非常復雜，只簡單的 描述下這三次對話的簡單過程：主機A向主機B發出連接請求數據包：「我想給你發數據，可以嗎？」，這是第一次對話；主機B向主機A發送同意連接和要求同步 （同步就是兩台主機一個在發送，一個在接收，協調工作）的數據包：「可以，你什麼時候發？」，這是第二次對話；主機A再發出一個數據包確認主機B的要求同 步：「我現在就發，你接著吧！」，這是第三次對話。三次「對話」的目的是使數據包的發送和接收同步，經過三次「對話」之後，主機A才向主機B正式發送數據。
為什麼需要「三次握手」?
在謝希仁著《計算機網路》第四版中講「三次握手」的目的是「 為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤 」。在另一部經典的《計算機網路》一書中講「三次握手」的目的是為了解決「網路中存在延遲的重復分組」的問題。這兩種不一樣的表述其實闡明的是同一個問題。
謝希仁版《計算機網路》中的例子是這樣的，「已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。 本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。 採用「三次握手」的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。」。 主要目的防止server端一直等待，浪費資源。
為什麼需要「四次揮手」？
可能有人會有疑問，在tcp連接握手時為何ACK是和SYN一起發送，這里ACK卻沒有和FIN一起發送呢。原因是 因為tcp是全雙工模式，接收到FIN時意味將沒有數據再發來，但是還是可以繼續發送數據。
握手，揮手過程中各狀態介紹:
3次握手過程狀態：
LISTEN: 這個也是非常容易理解的一個狀態，表示伺服器端的某個SOCKET處於監聽狀態，可以接受連接了。
SYN_SENT : 當客戶端SOCKET執行CONNECT連接時，它首先發送SYN報文，因此也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。（發送端）
SYN_RCVD : 這個狀態與SYN_SENT遙想呼應這個狀態表示接受到了SYN報文，在正常情況下，這個狀態是伺服器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態，很短暫，基本上用netstat你是很難看到這種狀態的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最後一個 ACK報文不予發送。因此這種狀態時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。（伺服器端）
ESTABLISHED ：這個容易理解了，表示連接已經建立了。
4次揮手過程狀態：（可參考下圖）：
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是： FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方回應ACK報文後，則進入到FIN_WAIT_2狀態， 當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）
FIN_WAIT_2： 上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示 半連接 ，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數據需要傳送給你(ACK信息)，稍後再關閉連接。（主動方）
TIME_WAIT: 表示收到了對方的FIN報文，並發送出了ACK報文 ，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）
CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你發送FIN報文後，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你發送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方幾乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連接。
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？ 當對方close一個SOCKET後發送FIN報文給自己，你系統毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數據發送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，發送FIN報文給對方，也即關閉連接。 所以你在 CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連接。 （被動方）
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）
CLOSED: 表示連接中斷。
TCP的具體狀態圖可參考：
㈢ QUIC協議有什麼作用呢
在Google新版的Chrome瀏覽器中，支持QUIC協議，在 Chrome 瀏覽器中打開「實驗性功能」頁面（chrome://flags/），啟用「實驗性 QUIC 協議」和「經由實驗性 QUIC 協議發出的 HTTPS 請求」，重啟瀏覽器後可以正常登陸 Google 相關服務(被薯圓擾DNS污染的除外)。對於被DNS污染的Google服務，還需要設置Hosts的IP，然後通過HTTPS才能訪問。
㈣ 詳解基於UDP的低延時網路傳輸層協議——QUIC
Quic 全稱 quick udp internet connection [1]，「快速 UDP 互聯網連接」，（和英文 quick 諧音，簡稱「快」）是由 Google 提出的使用 udp 進行多路並發傳輸的協議。
Quic 相比現在廣泛應用的 http2+tcp+tls 協議有如下優勢 [2]：
減少了 TCP 三次握手及 TLS 握手時間；
改進的擁塞控制；
避免隊頭阻塞的多路復用；
連接遷移；
前向冗餘糾錯。
從上個世紀 90 年代互聯網開始興起一直到現在，大部分的互聯網流量傳輸磨禪只使用了幾個網路協議。使用 IPv4 進行路由，使用 TCP 進行連接層面的流量控制，使用 SSL/TLS 協議實現傳輸安全，使用 DNS 進行域名解析，使用 HTTP 進行應用數據的傳輸。
而且近三十年來，這幾個協議的發展都非常緩慢。TCP 主要是擁塞控制演算法的改進，SSL/TLS 基本上停留在原地，幾個小版本的改動主要是密碼套件的升級，TLS1.3[3] 是一個飛躍式的變化，但截止到今天，還沒有正式發布。IPv4 雖然有一個大的進步，實現了 IPv6，DNS 也增加了一個安全的 DNSSEC，但和 IPv6 一樣，部署進度較慢。
隨著移動互聯網快速發展以及物聯網的逐步興起，網路交互的場景越來越豐富，困困網路傳輸的內容也越來越龐大，用戶對網路傳輸效率和 WEB 響應速度的要求也越來越高。
一方面是歷史悠久使用廣泛的古老協議，另外一方面用戶的使用場景對傳輸性能的要求又越來越高。
如下幾個由來已久的問題和矛盾就變得越來越突出：
協議歷史悠久導致中間設備僵化；
依賴於操作系統的實現導致協議本身僵化；
建立連接的握手延遲大；
隊頭阻塞。
可能是 TCP 協議使用得太久，也非常可靠。所以我們很多中間設備，包括防火牆、NAT 網關，整流器等出現了一些約定俗成的動作。
比如有些防火牆只允許通過 80 和 443，不放通其他埠。NAT 網關在轉換網路地址時重寫傳輸層的頭部，有可能導致雙方無法使用新的傳輸格式。整流器和中間代理有時候出於安全的需要，會刪除一些它們不認識的選項欄位。
TCP 協議本來是支持埠、選項及特性的增加和修改。但是由於 TCP 協議和知名埠及選項使用的歷史太悠久，中間設備已經依賴於這些潛規則，所以對這些內容的修改很容易遭到中間環節的干擾而失敗。
而這些干擾，也導致很多在 TCP 協議上的優化變得小心謹慎，步履維艱。
TCP 是由操作系統在內核西方棧層面實現的，應用程序只能使用，不能直接修改。雖然應用程序的更新迭代非常快速和簡單。但是 TCP 的迭代卻非常緩慢，原因就是操作系統升級很麻煩。
現在移動終端更加流行，但是移動端部分用戶的操作系統升級依然可能滯後數年時間。PC 端的系統升級滯後得更加嚴重，windows xp 現在還有大量用戶在使用，盡管它已經存在快 20 年。
服務端系統不依賴用戶升級，但是由於操作系統升級涉及到底層軟體和運行庫的更新，所以也比較保守和緩慢。
這也就意味著即使 TCP 有比較好的特性更新，也很難快速推廣。比如 TCP Fast Open。它雖然 2013 年就被提出了，但是 Windows 很多系統版本依然不支持它。 即時通訊聊天軟體開發可以咨詢蔚可汪游念雲。
不管是 HTTP1.0/1.1 還是 HTTPS，HTTP2，都使用了 TCP 進行傳輸。HTTPS 和 HTTP2 還需要使用 TLS 協議來進行安全傳輸。
這就出現了兩個握手延遲：
1）TCP 三次握手導致的 TCP 連接建立的延遲；
2）TLS 完全握手需要至少 2 個 RTT 才能建立，簡化握手需要 1 個 RTT 的握手延遲。
對於很多短連接場景，這樣的握手延遲影響很大，且無法消除。
隊頭阻塞主要是 TCP 協議的可靠性機制引入的。TCP 使用序列號來標識數據的順序，數據必須按照順序處理，如果前面的數據丟失，後面的數據就算到達了也不會通知應用層來處理。
另外 TLS 協議層面也有一個隊頭阻塞，因為 TLS 協議都是按照 record 來處理數據的，如果一個 record 中丟失了數據，也會導致整個 record 無法正確處理。
概括來講，TCP 和 TLS1.2 之前的協議存在著結構性的問題，如果繼續在現有的 TCP、TLS 協議之上實現一個全新的應用層協議，依賴於操作系統、中間設備還有用戶的支持。部署成本非常高，阻力非常大。
所以 QUIC 協議選擇了 UDP，因為 UDP 本身沒有連接的概念，不需要三次握手，優化了連接建立的握手延遲，同時在應用程序層面實現了 TCP 的可靠性，TLS 的安全性和 HTTP2 的並發性，只需要用戶端和服務端的應用程序支持 QUIC 協議，完全避開了操作系統和中間設備的限制。
0RTT 建連可以說是 QUIC 相比 HTTP2 最大的性能優勢。那什麼是 0RTT 建連呢？
這裡面有兩層含義：
傳輸層 0RTT 就能建立連接；
加密層 0RTT 就能建立加密連接。
TCP 的擁塞控制實際上包含了四個演算法：慢啟動，擁塞避免，快速重傳，快速恢復 [22]。
QUIC 協議當前默認使用了 TCP 協議的 Cubic 擁塞控制演算法 [6]，同時也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制演算法。
從擁塞演算法本身來看，QUIC 只是按照 TCP 協議重新實現了一遍，那麼 QUIC 協議到底改進在哪些方面呢？主要有如下幾點。
【可插拔】：
什麼叫可插拔呢？就是能夠非常靈活地生效，變更和停止。體現在如下方面：
1）應用程序層面就能實現不同的擁塞控制演算法，不需要操作系統，不需要內核支持。這是一個飛躍，因為傳統的 TCP
擁塞控制，必須要端到端的網路協議棧支持，才能實現控制效果。而內核和操作系統的部署成本非常高，升級周期很長，這在產品快速迭代，網路爆炸式增長的今天，顯然有點滿足不了需求；
2）即使是單個應用程序的不同連接也能支持配置不同的擁塞控制。就算是一台伺服器，接入的用戶網路環境也千差萬別，結合大數據及人工智慧處理，我們能為各個用戶提供不同的但又更加精準更加有效的擁塞控制。比如 BBR 適合，Cubic 適合；
3）應用程序不需要停機和升級就能實現擁塞控制的變更，我們在服務端只需要修改一下配置，reload 一下，完全不需要停止服務就能實現擁塞控制的切換。
STGW 在配置層面進行了優化，我們可以針對不同業務，不同網路制式，甚至不同的 RTT，使用不同的擁塞控制演算法。
【單調遞增的 Packet Number】：
TCP 為了保證可靠性，使用了基於位元組序號的 Sequence Number 及 Ack 來確認消息的有序到達。
QUIC 同樣是一個可靠的協議，它使用 Packet Number 代替了 TCP 的 sequence number，並且每個 Packet Number 都嚴格遞增，也就是說就算 Packet N 丟失了，重傳的 Packet N 的 Packet Number 已經不是 N，而是一個比 N 大的值。而 TCP 呢，重傳 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不變，也正是由於這個特性，引入了 Tcp 重傳的歧義問題。
QUIC 的流量控制 [22] 類似 HTTP2，即在 Connection 和 Stream 級別提供了兩種流量控制。為什麼需要兩類流量控制呢？主要是因為 QUIC 支持多路復用。
Stream 可以認為就是一條 HTTP 請求。
Connection 可以類比一條 TCP 連接。多路復用意味著在一條 Connetion 上會同時存在多條 Stream。既需要對單個 Stream 進行控制，又需要針對所有 Stream 進行總體控制。
QUIC 實現流量控制的原理比較簡單：
通過 window_update 幀告訴對端自己可以接收的位元組數，這樣發送方就不會發送超過這個數量的數據。
通過 BlockFrame 告訴對端由於流量控制被阻塞了，無法發送數據。
QUIC 的流量控制和 TCP 有點區別，TCP 為了保證可靠性，窗口左邊沿向右滑動時的長度取決於已經確認的位元組數。如果中間出現丟包，就算接收到了更大序號的 Segment，窗口也無法超過這個序列號。
但 QUIC 不同，就算此前有些 packet 沒有接收到，它的滑動只取決於接收到的最大偏移位元組數。
QUIC 的多路復用和 HTTP2 類似。在一條 QUIC 連接上可以並發發送多個 HTTP 請求 (stream)。但是 QUIC 的多路復用相比 HTTP2 有一個很大的優勢。
QUIC 一個連接上的多個 stream 之間沒有依賴。這樣假如 stream2 丟了一個 udp packet，也只會影響 stream2 的處理。不會影響 stream2 之前及之後的 stream 的處理。
這也就在很大程度上緩解甚至消除了隊頭阻塞的影響。
㈤ 更好的 TLS 1.3 協議解析
網路安全篇，面對復雜多變的網路環境，我們需要掌握哪些關於網路安全的相關知識，聊一聊與網路安全相關的：HTTPS、SSL、TLS 等。
《 網路安全 — HTTPS 》
《 網路安全的基石（上）— 加密 》
《 網路安全的基石（下）— 完整性與身份認證 》
《 公鑰信任問題 — 數字證書與 CA 》
《 信任始於握手 — TLS 連接過程詳解 》
《TLS 1.3 特性解析》
《 如何優化 HTTPS 連接 》- 待完善
早在 2013 年，IETF（互聯網工程小組） 就對 TLS 1.2 的過時設計和兩次往返開銷心生不滿，因此開始著手准備新版本的 TLS。同年 8 月由 Eirc Rescorla 提議出新版本 TLS 的 功能願望清單 。在經過一番 辯論 後，最終該提議內容被定義為 TLS 1.3。推動 TLS 1.3 設計的主要問題大概有：
終於在 2018 年 8 月 10 日，歷經 4 年時間，TLS 1.3 最終版本發布了 — RFC-8446 。新的協議使得互聯網變得更快、更安全；隨著 TLS 1.3 的採用率不斷提高，它勢必會長遠影響互聯網的發展；同時盡快將 TLS 1.3 平滑應用到線上環境無疑是勢在必行。
不過在這之前， TLS 1.2 的應用也已經有 10 年（2008 年）的時間了，畢竟歷經了種種考驗，新的協議在推廣和部署上必定會帶來新的挑戰。接下來我們就來看看新版本的 TLS 是如何做的？
由於 TLS 1.1/1.2 等協議已經出現了很多年，很多應用軟體、中間代理（Middlebox）只認老的記錄協議格嫌和蠢式，更新改造很困難，甚至僵化。
可部署性
正式由於這些中間代理/軟體（Middlebox）在新的更改中表現不佳，即使是對 TLS 1.3 協議的細微更改（例如消除冗餘的 ChangeCipherSpec 消息，版本號從 0x03 升級為 0x04），也最終導致了某些設備的連接失敗問題。這也是 TLS 1.3 從草稿到最終發布花費了這么長時間的重要原因之一。
為了保證這些被廣泛部署的「舊設備」能夠繼續使用，TLS 1.3 不得不做出妥協，通過「偽裝」來實現兼容：保持現有的記錄格式不變，使得 TLS 1.3 看上去「像是」 TLS 1.2。
擴展協議
那麼，如何區分是 1.2 還是 1.3 呢？
這里用到一個新的 擴展協議 （Extension Protocol），它有點「補充條款」的意思，通過在記錄末尾添加一系列的「擴展欄位」來增加新的功能，舊版本的 TLS 不認識它可以直接忽略，這就實現了「向後兼容」。
TLS 1.3 正是利用擴展實現了許多重要的功能，比如 「supported_groups」 「key_share」 「signature_algorithms」 「server_name」 等。
在經歷十餘年的實踐中獲得許多寶貴經驗的 TLS 1.2 陸續發現了很多的漏洞和加密演算法的弱點。因此消除潛在的危險設計來糾正以前的錯誤成為 TLS 1.3 的設計目標之一。所以新版本的 TLS 協議里要修補這些不安全的因素。
例如：
固定密鑰交換
經過這樣一番「減肥瘦身」之後，TLS 1.3 的密鑰交換演算法只有 ECDHE 和 DHE 了，關於橢圓曲線（ECC）也被「砍」到只剩 P-256 和 x25519 等 5 種。
首先來說下廢除 RSA 和 DH 密鑰交換演算法的原因：
由於客戶端默認會選擇 ECDHE 而非 RSA 做密鑰交換，這是因為它不具有「 前向安全 」（Forward Secrecy）：「假設有人長期記錄了加密的數據，然後在後續的某個時間段獲得了伺服器的 RSA 私鑰，那麼黑客就能夠使用該私鑰棚碰解密出之前芹陪所有報文的 「Pre-Master」，再計算出會話密鑰，破解所有密文。這便是 今日截獲，明日破解 」
而 ECDHE 演算法在每次握手時都會生成一對臨時公鑰和私鑰，每次通信的秘鑰對都是不同的，也就是「一次一密」，即使黑客花大力氣破解了這一次的會話密鑰，也只是這次通信被攻擊，之前的歷史消息不會受到影響，仍然是安全的。
所以現在主流的伺服器和客戶端在握手階段都已經不再使用 RSA，改用 ECDHE，而 TLS 1.3 在協議里明確廢除了 RSA 和 DH 則在標准層面保證了「前向安全」。
固定密碼
多年以來，密鑰交換機制不是唯一引起安全漏洞的部分，對稱密鑰部分也有相當一部分問題。
同樣，用於對稱加密的演算法在經過「減肥瘦身」之後也只保留了 AES、ChaCha20 ，分組模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要演算法也只能用 SHA 256、SHA 384。
這樣原來眾多的加密演算法、參數組合導緻密碼套件非常復雜，難以選擇。而經過瘦身之後的 TLS 1.3 只剩下 5 個套件，使得客戶端或服務端在選擇密碼套件時變得「更加容易」。然而更重要的是，這些演算法在 TLS 長期的實踐過程中先後已經被證實是構成不安全的因素，從而導致安全漏洞。
修復數字簽名
經過前面的學習，相信你也知道 TLS 另一個重要部分是身份驗證。在每個連接中服務都是用具有公鑰的數字證書向客戶端提供身份認證。在 RSA 加密模式下，伺服器通過解密預主密鑰並通過對話記錄計算 MAC 來證明其對私鑰的所有權。在 Diffie-Hellman 模式下，伺服器使用數字簽名來證明私鑰的所有權。
在 TLS 1.2 和更早的版本中，伺服器的簽名僅涵蓋部分握手。用於協商使用哪種對稱密碼的部分沒有由私鑰簽名。這也導致許多引人注目的漏洞 FREAK ， LogJam 等。而在 TLS 1.3 由於伺服器對整個握手記錄進行簽名，因此可以避免這些情況。
HTTPS 建立連接時除了要做 TCP 握手，還要做 TLS 握手，在 TLS 1.2 中會多花兩個消息往返（2 - RTT），這可能導致幾十毫秒甚至上百毫秒的延遲，在移動網路中延遲還會更嚴重。
1-RTT 模式
密碼套件的大幅度簡化，也就沒有必要再像以前那樣走復雜的的協商流程了。TLS 1.3 壓縮了以前的 「Hello」 協商過程，刪除了 「Key Exchange」 消息，把握手時間減少到了 「1-RTT」，效率提高了一倍。
下面是 TLS 1.3 握手過程的簡圖，注意與前面介紹的 TLS 1.2 對比區別在哪裡。
0-RTT 恢復
除了標準的 「1-RTT」 握手，受 QUIC 協議的啟發，客戶端可以在其第一條消息中將加密的數據發送到伺服器，與未加密的 HTTP 相比，沒有額外的延遲成本。
在 TLS 1.2 中，有兩種恢復連接的方法：會話 ID 和會話 Ticket，而 1.3 則將他們組合在一起形成稱為 PSK（pre-shared key，預共享密鑰）恢復的新模式。
握手分析
目前 Nginx 等 Web 伺服器都能夠很好的支持 TLS 1.3，但是要求底層的 OpenSSL 必須是 1.1.1。因此如果要部署需要先升級你的 OpenSSL 版本。
首先TCP 建立連接之後，瀏覽器首先還是發一個 「 Client Hello 」。
由於 1.3 的消息要兼容 1.2，所以開頭的版本號、支持的密碼套件和隨機數（Client Random）結構都是一樣的（這時的隨機數是 32 個位元組）。
注意 「Client Hello」 里的擴展，「 supported_versions 」 表示這是 TLS 1.3，「 supported_groups 」 是支持的曲線，「 key_share 」是曲線對應的參數。
這有點是像是「有話盡量一口氣說完」，還是按照老規矩進行「打招呼」，我這邊有這些信息，考慮到版本升級，所以附帶了一些信息，可能後面會用到。
伺服器收到 「Client Hello」 同樣返回 「Server Hello」 消息，還是要給出一個 隨機數 （Server Random）和選定密碼套件。
表面上看 Version 和 TLS 1.2 是一樣的，重點是後面的擴展。「 supported_versions 」 里確認使用的是 TLS 1.3，然後在 「 key_share 」 擴展帶上曲線和對應的公鑰參數。
伺服器的回應還是老套路，服務端對客戶端的提供的信息作出選擇，另外服務端還要再附加上幾個參數，這次加密就協商定了。
可以看到相比 TLS 1.2 的握手過程，TLS 1.3 僅用兩條消息就共享了 4 個信息： Client Random 和 Server Random 、 Client Params 和 Server Params 。兩邊就可以各自用 DH 算出 「 Pre-Master 」，再用 HKDF 生成主密鑰 「 Master Secret 」，效率比 TLS 1.2 提高了一大截。
在計算出主密鑰後，伺服器立刻發出 「 Change Cipher Spec 」 消息，比 TLS 1.2 提早進入加密通信，後面的證書等就都是加密的了，減少握手時明文信息泄露。
TLS 1.3 還多了一個 「 Change Cipher Spec 」 消息，伺服器用私鑰把前面的曲線、套件、參數等握手數據加了簽名，作用和 「 Finished 」 消息差不多。但由於是私鑰簽名，所以強化了身份認證和防篡改。
兩個「打招呼」消息之後，客戶端驗證伺服器證書，再發 「Finished」 消息，就正式完成了握手，開始收發 HTTP 報文。
現在已經有很多網站都支持了 TLS 1.3，例如 GitHub ：
今天我們主要介紹了 TLS 1.3 的一些新特性，簡單總結下來主要包含下面幾點：
TLS 1.3 涉及的內容很多，有關它的更詳細信息請去參照 RFC-8446 ，關於這部分大家還有哪些要分享的呢？歡迎您的留言或指正。
網路安全系列專題
擴展閱讀
㈥ 三次握手、七次握手、四次揮手
TCP/IP 傳輸協議的 TCP 協議是面向連接的，也就是傳輸數據之前，必須建立可靠的連接。建立連接的過程中，需交換信息（如選取哪種協議、協議版本等），這個過程稱為 握手 handshaking 。
握手過程中會協商後續通信使用的參數，如傳輸速率、編碼方式、校驗，襪氏以及其他協議選取、硬體支持的功能等。握手是兩個實體之間的通信，但在 TCP/IP 中握手常指 TCP 的三次握手。
TCP 中的數據傳輸、連接建立與終止都由特定控制參數管理，控制參數有以下這些：
建立 TCP 連接需要三次握手：
TCP 連接的雙方通過三次握手確定 TCP 連接的初始序列號、窗口大小以及最大數據段，這樣通信雙方就能利用連接中的初始序列號保證雙方數據段的不重不漏，通過窗口大小控制流量，並使用最大數據段避免 IP 協議對數據包分片。
換個角度看為什麼需要三次握手？客戶端和服務端通信前要進行連接，三次握手就是為了確保自己和對方的收發能力是正常的。
三次握手後，客戶端、服務端才確認了自己的接收、發送能力均是正常的。
HTTP 協議中的數據是明文傳輸的，任何中間人（man-in-the-middle）都可以讀取傳輸的數據，因此 HTTP 是一種不安全的協議。
HTTPS 是 HyperText Transfer Protocol Secure 的縮寫。但 HTTPS 協議自身不告枝散能加密數據，它需要藉助 SSL 或 TLS 協議層進行加密。
HTTP 協議和 TLS 協議都位於 application layer。TCP 三次握手建立連接後，使用 TLS 握手建立安全連接，後續使用協商的加密演算法先對數據進行加密，再通過 HTTP 傳輸。
數據加密後，中間人即使獲得了數據，也無法讀取數據內容，進而避免了中間人攻擊（man-in-the-middle-attack）。
HTTP 協議和 TLS 協議一起使用時，稱為 HTTPS 協議。App 想要使用 TLS 加密通信，只需網址使用 https:// 前綴即可。
要了解 TLS 工作原理，需先了解加密的工作原理，以及各種加密演算法。加密就是將數據從一種格式編碼為另一種格式，編碼時使用一些數學演算法、秘密參數。使用相同演算法、參數，可以解密數據，這個過程中的參數稱為密鑰（key）。
非對稱加密演算法有兩個 key：
最流行的非對稱加密演算法是 RSA 加密演算法，廣泛用於密鑰交換和數字簽名驗證。但現在正逐步遷移至更安全高效的 Diffie-Hellman （縮寫為 D-H）演算法。
非對稱加密演算法通常速度慢，更耗費 CPU，且 key、數據越長，加密、解搭哪密耗費時間也越長。因此，數據量大時不要使用非對稱加密，而應使用對稱加密（symmetric key cryptography），對稱加密速度更快、性能更高。非對稱加密用於傳輸對稱加密密鑰。
對稱加密演算法也稱為共享密鑰加密（shared key），它使用相同的 key 加密、解密。
對稱加密演算法主要用於受信任兩者之間建立加密通道。因為第三方無法獲取對稱密鑰，因此只有建立通道的雙方才可以解密數據。
最流行的對稱加密演算法是 AES（Advanced Encryption Standard 的縮寫，即高級加密標准），
SSL 協議由 Netscape 團隊設計，於1995年發布 SSL 2.0版本，之後發布了 SSL 3.0版本，IETF 已於2015年不推薦使用 SSL 3.0。
目前，TLS 協議已經替代了 SSL 協議，SSL 協議已不再使用。
TLS 是旨在提供安全通信的加密協議，使用 TLS 可以加密與伺服器的所有通信。當前使用最廣的是 TLS 1.2、TLS 1.3。
TLS 1.3 發布於2018年，是對 TLS 1.2 的全面修訂，在性能和安全性方面都有很大提升，並且減少了建立安全連接所需的握手次數。
TLS 1.3 只支持 Diffie-Hellman 非對稱加密演算法，移除了 RSA 演算法。
使用 HTTPS 發送 HTTP 請求時，首先使用三次握手建立可靠的 TCP 連接，之後就通過 TLS 四次握手交換雙方的密鑰。
下面介紹 TLS 1.2 連接建立過程：
TLS 握手的關鍵在於利用通信雙方生成的隨機字元串和服務端的公鑰生成一個雙方經過協商後的密鑰，通信雙方後續使用這個對稱密鑰加密數據，防止中間人監聽和攻擊，保障通信安全。
在 TLS 1.2 中，需要 2-RTT（Round-Trip Time，往返延遲）才能建立 TLS 連接。在 TLS 1.3 中，客戶端不僅發送 ClientHello、支持的協議、加密演算法，還嘗試猜測伺服器將選擇哪種密鑰協商演算法，並為此發送共享密鑰。這樣服務端選取加密演算法後，因為已經有了 client key，可以立即生成 key，進而減少一次 RTT。
建立連接時需要發送三個 packet，但終止連接時需要四個 packet，也稱為四次揮手。因為 TCP 連接是全雙工的，每個方向都必須獨立終止。
終止 TCP 連接的四次揮手：
在第二次揮手時，如果服務端也想終止連接，可以為 FIN 設置不同於客戶端 FIN 的序列號。客戶端收到 FIN 後，發送 ACK，它的 acknowledgement number 為 FIN sequence number 加一。這一過程結束後，服務端與客戶端的連接也終止了，這樣的話整個過程進行了三次揮手。
客戶端想要通過 HTTP 請求訪問服務端時，需要經過三次握手；通過 HTTPS 訪問服務端時，需要額外增加四次握手。
總結一下 HTTP 建立連接、終止連接：
需要注意的是，本文所說的三次握手、七次握手、四次揮手都是基於特定版本的協議，不同版本的協議所需握手次數可能不同。HTTP/3 就是一個例子，它使用基於 UDP 的 QUIC 協議進行握手，將 TCP 和 TLS 握手過程結合起來，握手次數從七次減少到了三次。
參考資料：
歡迎更多指正： https://github.com/pro648/tips
本文地址： https://github.com/pro648/tips/blob/master/sources/三次握手、七次握手、四次揮手.md
㈦ 擁塞演算法
基於包丟失檢測的 Reno、NewReno 或者 cubic 為代表，其主要問題有 Buffer bloat 和長肥管道兩種。和這些演算法不同，bbr 演算法會以時間窗口內的最大帶寬 max_bw 和最小 RTT min_rtt，並以此計算發送速率和擁塞窗口
RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 演算法關於擁塞窗口的核心就是計算 BtlBW 和 RTprop，根據這兩者值計算 BDP
bbr 演算法輸出 pacing_rate 和 cwnd 兩個數據。pacing_rate 決定發包速率，cwnd 為窗口大小
TCP Tahoe 和 Reno
這兩個演算法是根據其第一次加入到4.3BSD的時間回溯命名的，兩個名字對應自其第一次出現時BSD的代號，而代號分別取自太浩湖（Lake Tahoe）和其附近的城市裡諾市
• Tahoe：如果收到三次重復確認——即第四次收到相同確認號的分段確認，並且分段對應包無負載分段和無改變接收窗口——的話，Tahoe演算法則進入快速重傳，將慢啟動閾值改為當前擁塞窗口的一半，將擁塞窗口降為1個MSS，並重新進入慢啟動階段
• Reno：如果收到三次重復確認，Reno演算法則進入快速重傳，只將擁塞窗口減半來跳過慢啟動階段，將慢啟動閾值設為當前新的擁塞窗口值，進入一個稱為「快速恢復」的新設計階段
Fast recovery
是Reno演算法新引入的一個階段，在將丟失的分段重傳後，啟動一個超時定時器，並等待該丟失分段包的分段確認後，再進入擁塞控制階段。如果仍然超時，則回到慢啟動階段
TCP Vegas
至1990年代中期，TCP量度延遲和RTT都是以傳輸緩存中最後一個被傳送的分段包為准。vegas通過度量傳輸緩存中每個傳送分段包來代替只量度一個分段包，通過每次度量的平均值來增加擁塞窗口。該演算法取名自內華達州最大的城市拉斯維加斯。不過由於一些資源公平性原因，該演算法並沒有在彼得森的實驗室之外廣泛部署。一些研究認為該演算法和其他擁塞演算法混合使用，可能會導致性能競爭不及其他演算法。在各種TCP擁塞演算法的比較研究中，Vegas被認為是最平滑的控制演算法，其次為CUBIC
TCP New Reno
TCP New Reno是對TCP Reno中快速恢復階段的重傳進行改善的一種改進演算法，其定義於RFC 6582，覆蓋了原有在RFC 3782和RFC 2582的舊定義。
在Reno的快速恢復中，一旦出現3次重復確認，TCP發送方會重發重復確認對應序列號的分段並設置定時器等待該重發分段包的分段確認包，當該分段確認包收到後，就立即退出快速恢復階段，進入擁塞控制階段，但如果某個導致重復確認的分段包到遇到重復確認期間所發送的分段包存在多個丟失的話，則這些丟失只能等待超時重發，並且導致擁塞窗口多次進入擁塞控制階段而多次下降。而New Reno的快速恢復中，一旦出現3次重復確認，TCP發送方先記下3次重復確認時已發送但未確認的分段的最大序列號，然後重發重復確認對應序列號的分段包。如果只有該重復確認的分段丟失，則接收方接收該重發分段包後，會立即返回最大序列號的分段確認包，從而完成重發；但如果重復確認期間的發送包有多個丟失，接收方在接收該重發分段後，會返回非最大序列號的分段確認包，從而發送方繼續保持重發這些丟失的分段，直到最大序列號的分段確認包的返回，才退出快速恢復階段。
New Reno在低錯誤率時運行效率和「選擇確認」（Selective ACKnowledgement，SACK）相當，在高錯誤率仍優於Reno
TCP Hybla
TCP Hybla旨在消除由於高延遲地面線路或者衛星無線鏈路下導致的RTT過長而對TCP鏈接的影響。它通過對擁塞窗口動態分析來修改，來減少對RTT的性能依賴
TCP BIC 和 CUBIC
TCP BIC（Binary Increase Congestion control）旨在優化高速高延遲網路（即根據RFC 1072所定義的「長肥網路」（long fat network，LFN））的擁塞控制，其擁塞窗口演算法使用二分搜索演算法嘗試找到能長時間保持擁塞窗口最大值的值。Linux內核在2.6.8至2.6.18使用該演算法作為默認TCP擁塞演算法。
CUBIC則是比BIC更溫和和系統化的分支版本，其使用三次函數代替二分演算法作為其擁塞窗口演算法，並且使用函數拐點作為擁塞窗口的設置值。Linux內核在2.6.19後使用該演算法作為默認TCP擁塞演算法
TCP Westwood和Westwood+
TCP Westwood改良自New Reno，不同於以往其他擁塞控制演算法使用丟失來測量，其通過對確認包測量來確定一個「合適的發送速度」，並以此調整擁塞窗口和慢啟動閾值。其改良了慢啟動階段演算法為「敏捷探測（Agile Probing）」，和設計了一種持續探測擁塞窗口的方法來控制進入「敏捷探測」，使鏈接盡可能地使用更多的帶寬。Westwood+使用更長的帶寬估計間隔和優化的濾波器來修正Westwood對ACK壓縮場景對帶寬估計過高的問題。通過以上改良，TCP Westwood系列演算法在有線網路和無線網路的擁塞控制上獲取平衡，尤其研究中針對於無線通信網路上
Compound TCP
復合TCP（Compound TCP）是微軟自己實現的TCP擁塞控制演算法，通過同時維護兩個擁塞窗口，來實現在長肥網路有較好的性能而又不損失公平性。該演算法在Windows Vista和Windows Server 2008開始廣泛部署，並通過補丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一個舊版本的移植實現
TCP PRR
TCP PRR（TCP Proportional Rate Rection ）是旨在恢復期間提高發送數據的准確性。該演算法確保恢復後的擁塞窗口大小盡可能接近慢啟動閾值。在Google進行的測試中，能將平均延遲降低3~10%，恢復的超時減少5%。PRR演算法之後作為Linux內核3.2版本的默認擁塞演算法
TCP BBR
TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google設計，於2016年發布的擁塞演算法。以往大部分擁塞演算法是基於丟包來作為降低傳輸速率的信號，而BBR則基於模型主動探測。該演算法使用網路最近出站數據分組當時的最大帶寬和往返時間來創建網路的顯式模型。數據包傳輸的每個累積或選擇性確認用於生成記錄在數據包傳輸過程和確認返回期間的時間內所傳送數據量的采樣率。該演算法認為隨著網路介面控制器逐漸進入千兆速度時，與緩沖膨脹相關的延遲相比丟包更應該被認為是識別擁塞的主要決定因素，所以基於延遲模型的擁塞控制演算法（如BBR）會有更高的吞吐量和更低的延遲，可以用BBR來替代其他流行的擁塞演算法，例如CUBIC
QUIC Quick UDP Internet Connections
QUIC旨在提供幾乎等同於TCP連接的可靠性，但延遲大大減少。它主要通過兩個理解HTTP流量的行為來實現這一點：
第一個變化是在連接創建期間大大減少開銷。由於大多數HTTP連接都需要TLS，因此QUIC使協商密鑰和支持的協議成為初始握手過程的一部分。 當客戶端打開連接時，伺服器響應的數據包包括將來的數據包加密所需的數據。
QUIC使用UDP協議作為其基礎，不包括丟失恢復。相反，每個QUIC流是單獨控制的，並且在QUIC級別而不是UDP級別重傳丟失的數據。這意味著如果在一個流中發生錯誤，協議棧仍然可以獨立地繼續為其他流提供服務
QUIC包括許多其他更普通的更改，這些更改也可以優化整體延遲和吞吐量
每個數據包是單獨加密的，因此加密數據時不需要等待部分數據包。 在TCP下通常不可能這樣做，其中加密記錄在位元組流中，並且協議棧不知道該流中的更高層邊界。這些可以由運行在更上層的協議進行協商，但QUIC旨在通過單個握手過程完成這些
QUIC的另一個目標是提高網路切換期間的性能，例如當移動設備的用戶從WiFi熱點切換到移動網路時發生的情況。 當這發生在TCP上時，一個冗長的過程開始了：每個現有連接一個接一個地超時，然後根據需要重新創建。期間存在較高延遲，因為新連接需要等待舊連接超時後才會創建。 為解決此問題，QUIC包含一個連接標識符，該標識符唯一地標識客戶端與伺服器之間的連接，而無論源IP地址是什麼。這樣只需發送一個包含此ID的數據包即可重新創建連接，因為即使用戶的IP地址發生變化，原始連接ID仍然有效
QUIC在應用程序空間中實現，而不是在操作系統內核中實現。當數據在應用程序之間移動時，這通常會由於上下文切換而調用額外的開銷。 但是在QUIC下協議棧旨在由單個應用程序使用，每個應用程序使用QUIC在UDP上託管自己的連接
Chromium的網路堆棧同時打開QUIC和傳統TCP連接，並在QUIC連接失敗時以零延遲回退到TCP連接
㈧ quic 協議分析
HTTP 3 ，它來了，QUIC（quick udp internet connection 「快速 UDP 互聯網連接」）正如其名一樣，它就是快。其正在標准化為新一代的互聯網傳輸協議。是由google提出的使用udp進行多路並發的傳輸協議。
QUIC解決了什麼問題呢？從上世紀90年代至今，互聯網一直按照一成不變的塵孫帆模式發展著。使用ipv4進行路由，使用tcp進行連接層面的擁塞控制，並保證其傳輸的可靠性，使用tls層進行安全加密和身份驗證，使用http進行應用的數據傳輸。
這么多年的發展，這些協議只是小部分或者細節上有了改變，tcp提出了幾個新的擁塞控制演算法，tls改變了加密方式，http層進化出了h2。但是互聯網發展至今，網路傳輸的內容越來越大，用戶對傳輸的時延，帶寬提出越來越大的要求。
tcp雖然也在擁塞控制上提出了一些優秀的擁塞控制演算法，如BBR但是限制於其對操作系統內核版本的要求，tcp 的 TFO，windows操作系統又支持不好等。導致想要切換成更高效的協議成本巨大。
這里列出幾個主要的矛盾。
1、協議歷史悠久導致中間設備僵化。
2、依賴於操作系統的實現導致協議本身僵化派雹。
3、建立連接的握手延遲大。
4、隊頭阻塞。
QUIC孕育而生，其拋開了TCP直接採用UDP，如一些擁塞演算法，可靠性保證機制，不再依賴操作系統內核，而是可以自定義。
Quic 相比現在廣泛應用的 http2+tcp+tls 協議有如下優勢：
1、減少了 TCP 三次握手及 TLS 握手時間。
2、改進的擁塞控制。
3、避免隊頭阻塞的多路復用。
4、連接遷移。
5、前向冗餘糾錯。
有些防火牆只允許通過 80 和 443，不放通其他埠。NAT 網關在轉換網路地址時重寫傳輸層的頭部，有可能導致雙方無法使用新的傳輸格式。因為通信協議棧都是固化到操作系統中的，只能通過內核參數進行調整，但是這樣的調整極其有限，如果想要新加協議，只能重新編譯內核。而現實是，可能還有一些Centos5 還作為某些古董公司的線上伺服器。另外，windows xp 可能還是某些事業單位的辦公電腦上裝的操作系統，盡管xp的時代已經過去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows操作系統也有些不支持。
知道一個首次https網站的訪問都要有哪些步驟嗎？dns解析需要1個RTT，TCP三次握手，HTTP 302 跳轉 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2個。解析CA的DNS（因為瀏覽器獲取到證書後，有可能需要發起 OCSP 或者 CRL 請求，查詢證書狀態）再對CA進行TCP握手，OCSP響應。密鑰協商又是RTT。當然這種情況是最極端的，大部分情況下不是所有流程都需要走一遍的。（參考 大型網站的 HTTPS 實踐（二）-- HTTPS 對性能的影響 ）
基於以上的原因，QUIC選擇了UDP。沒有了三次握手，在應用層面完成了傳輸的可靠性，擁塞控制還有TLS的安全性。只要凱余應用軟體的客戶端和服務端支持就行，繞開了操作系統內核版本這個硬骨頭。
在HTTPS over TCP+TLS的時代。HTTPS需要3個RTT，在session 復用的情況下是2個RTT。而QUIC做到了1RTT和會話復用的0RTT。
QUIC的TLS只能使用TLS1.3，這就可以做到PSK的0RTT。
TCP 的擁塞控制實際上包含了四個演算法：慢啟動，擁塞避免，快速重傳，快速恢復。其中TCP中擁塞控制是被編譯進內核中的，如果想要更改就需要改變內核參數，但是想要對已有的擁塞控制演算法進行更改就需要重新編譯內核，Linux 4.9 中引入了基於時延的擁塞控制演算法 BBR，這打破了以往是靠丟包驅動的擁塞控制演算法，但是想要在TCP中使用，就必須升級內核至4.9以上。
QUIC 協議當前默認使用了 TCP 協議的 Cubic 擁塞控制演算法 [6]，同時也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制演算法。
QUIC和TCP的對比
其中α 從 0到 1（RFC 推薦 0.9），越大越平滑
如 UBOUND為1分鍾，LBOUND為 1 秒鍾， β從 1.3 到 2 之間
對於QUIC
參考： 科普：QUIC協議原理分析 羅成
㈨ quic 協議總結
client和server協商過程:
1. 客戶端發送CHLO到服務端
2. 服務端回送的REJ信息給客戶端，同時攜帶上原地址標識信息和服務端證書信息
3. 客戶端再次發送CHLO到服務端
擁塞控制：
QUIC參考TCP的CUBIC擁塞控制演算法，並在試探嘗試其他擁塞控制演算法
試探嘗試新的擁塞控制演算法：例如每個數據包的轉發(包括原始數據包和重傳包)都攜帶一個新的sequece序列化，這樣可以避免TCP的重傳模糊問題
QUIC-ACK會攜帶上接收數據包的時間以及發送ack的時間，這樣有利於計算往返時延
QUIC-ACK相比TCP的SACK，跟容易實現包的重組，當有包丟失或者
FEC
通過FEC可以從一組FEC報文組中恢復網路傳輸中丟失的數據包，具體優化方案由發送端決定
連接復用
QUIC連接通過一個64位的連接標識符標識，該標識符由客戶端產生。
QUIC的連接建立將版本協商與加密和傳輸握手交織在一起以減少連接建立延遲。我們將在下面首先描述版本協商。
連接建立延遲
靈活的擁塞控制
多路復用而不存在隊首阻塞
認證和加密的首部和載荷
流和連接的流量控制
連接遷移
QUIC採用了兩級密鑰機制：初始密鑰和會話密鑰。初次連接時不加密，並協商初始密鑰。初始密鑰協商完畢後會
馬上再協商會話密鑰，這樣可以保證密鑰的前向安全性，之後可以在通信的過程中就實現對密鑰的更新。接收方意
識到有新的密鑰要更新時，會嘗試用新舊兩種密鑰對數據進行解密，直到成功才會正式更新密鑰，否則會一直保留
舊密鑰有效。
QUIC在握手過程中使用Diffie-Hellman演算法協商初始密鑰，初始密鑰依賴於伺服器存儲的一組配置參數，該參數
會周期性的更新。初始密鑰協商成功後，伺服器會提供一個臨時隨機數，雙方根據這個數再生成會話密鑰。
0-RTT握手過程
QUIC握手的過程是需要一次數據交互，0-RTT時延即可完成握手過程中的密鑰協商，比TLS相比效率提高了5倍，且具有更高的安全性。
QUIC在握手過程中使用Diffie-Hellman演算法協商初始密鑰，初始密鑰依賴於伺服器存儲的一組配置參數，該參數會周期性的更新。
初始密鑰協商成功後，伺服器會提供一個臨時隨機數，雙方根據這個數再生成會話密鑰。
具體握手過程如下：
(1) 客戶端判斷本地是否已有伺服器的全部配置參數，如果有則直接跳轉到(5)，否則繼續
(2) 客戶端向伺服器發送inchoate client hello(CHLO)消息，請求伺服器傳輸配置參數
(3) 伺服器收到CHLO，回復rejection(REJ)消息，其中包含伺服器的部分配置參數
(4) 客戶端收到REJ，提取並存儲伺服器配置參數，跳回到(1)
穗備 (5) 客戶端向伺服器發送full client hello消息，開始正式握手，消息中包括客戶端選擇的公開數。此時客戶端根據獲取的伺服器配置參數和自己選擇的公開數，可以計算出初始猜悶毀密鑰。
(6) 伺服器收到full client hello，如果不同意連接就回復REJ，同(3)；如果同意連接，根據客戶端的公開數計算出初始密鑰，回罩裂復server hello(SHLO)消息，SHLO用初始密鑰加密，並且其中包含伺服器選擇的一個臨時公開數。
(7) 客戶端收到伺服器的回復，如果是REJ則情況同(4)；如果是SHLO，則嘗試用初始密鑰解密，提取出臨時公開數
(8) 客戶端和伺服器根據臨時公開數和初始密鑰，各自基於SHA-256演算法推導出會話密鑰
(9) 雙方更換為使用會話密鑰通信，初始密鑰此時已無用，QUIC握手過程完畢。之後會話密鑰更新的流程與以上過程類似，只是數據包中的某些欄位略有不同。
QUIC包含三種報文包類型：
協商Package、公用復位package、普通幀信息Package
Version Negotiation Packets and Public Reset Packets, and regular packets containing frames.
如果客戶端的版本不被伺服器接受，則將導致1-RTT的延遲。伺服器將發送一個版本協商包給客戶端。這個包將設置版本標記，並將包含伺服器支持的版本的集合。
當客戶端從伺服器收到一個版本協商包，它將選擇一個可接受的協議版本並使用這個版本重發所有包。
為了避免流ID沖突，流 ID 必須是偶數，如果流是由伺服器初始化的話，如果流由客戶端初始化則必須為奇數。
0不是一個有效的流 ID。流 1 被保留用來加密握手，它應該是第一個客戶端初始化的流。當基於QUIC使用HTTP/2時，
流 3 被保留來為其它流傳輸壓縮的首部，以確保首部的處理和傳送可靠且有序。
各種幀格式參考:QUICWireLayoutSpecification.pdf
官方參考地址:https://www.chromium.org/quic
㈩ 互聯網基礎資源技術協議的安全發展趨勢
文 中國互聯網路信息中心 姚 健康
一、國際互聯網工程任務組是互聯網技術協議發展大本營
互聯網的發展改變了世界。互聯網運行的核心技術標准和核心技術協議主要來自國際互聯網工程任務組（IETF）。IETF 創立於 1986 年初，是負責制訂互聯網方面技術標準的重要組織，主要任務是負責互聯網相關技術標準的研發和制定，超過90% 的互聯網技術標准由其制定。IETF 通過技術標準的制定，保障了互聯網的長期穩定運行。IETF大量的技術性工作均由其內部的各種工作組（WG）承擔和完成。這些工作組依據各項不同類別的研究課題而組建。在成立工作組之前，IETF 通常會先設立興趣小組（BOF）開展工作組籌備工作。籌備工作完成後，經過 IETF 高層研究認可，可正式成立工作組。IETF 匯聚了全球頂尖的互聯網技術工程師，每年舉行三次會議，參會規模均在千人以上。
互聯網架構委員會（IAB）成立於 1983 年，是 IETF 的最高管理機構，由包括 IETF 主席在內的 13 名委員組成。IAB 的主要職責之一是負責互聯網協議體系結構的監管，把握互聯網技術的長期演進方向，保護互聯網的長期發展，負責確定互聯網標準的制訂規則，指導互頌激聯網技術標準的編輯出版，負責互聯網的編號管理，並協調與其他國際標准化組織的工作。
IETF 將工作組分類為不同的領域，每個領域由幾個領域主任（Area Director）負責管理。領域主任組成互聯網工程指導委員會（IESG），具體領域如下。
一是應用和實時研究領域（Applications andReal-Time Area）。該領域主要研究應用層相關的標准，也包括實時相關的網路協議。
二是通用研究領域（General Area）。該研究領域用於包括不適合放在其他研究領域的研究內容。
三是網際互聯研究領域（Internet Area）。網際互聯研究領域主要研究 IP 數據包如何在不同的網路環境中進行傳輸。
四是運營管理研究領域（Operations andManagement Area）。該研究領域主要涉及互聯網的運營與管理方面的內容。隨著互聯網的快速發展與普及，對網路的運營與管理提出了更高的要求，因此，該研究領域也越來越受到重視。
五是路由研究領域（Routing Area）。該研究領域主要負責制訂如何在網路中確定傳輸路徑以將IP 數據包路由到目的地的相關標准。
六是安全研究領域（Security Area）。該研究領域主要負責研究 IP 網路中的授權、認證、審計等與私密性保護有關的協議與標准。互聯網的安全性越來越受到人們的重視，因此，該領域也成為IETF 中最活躍的研究領域之一。
七是傳輸研究領域（Transport Area）。該領域主要負責研究特殊類型或特殊用途的數據包在網路中的端到端的傳輸方式。
在上述領域，除了安全研究領域專門研究安全技術以外，其他領域也會涉及安全問題。如何提高互聯網技術協議的安全是 IETF 長期研究的重點議題。
二、互聯網基礎資源技術協議利用公鑰信任鏈加強安全
IETF 互聯網基礎資源技術協議從默認信任數據轉向保障數據來源可信、數據完整和防篡改等方向發展。
（一）域名系統協議利用公鑰信任鏈加強安全
域名系統協議（DNS）是互聯網的啟答核心協議，是一種將域名映射為某些預定義類型資源記錄（如IP 地址）的分布式互聯網服務系統。作為一種互聯網應用層的資源定址基礎服務，域名服務是其他互聯網路應用服務的基礎。常見的互聯網路應用服務如網頁遠程訪問服務、電子郵件服務、文件遠程訪問服務等一般都以域名服務為基礎，實現資源的定址和定位。
DNSSEC 協議是一個針對 DNS 協議的安全擴展，它通過給 DNS 的應答消息添加基於非對稱加密演算法的數字簽名，保證數據未經篡改且來源正確；再通過域名體系自下而上逐級向父域提交自己公共密鑰，實現整個域野旁襪名體系的逐級安全認證。DNSSEC 為 DNS 數據提供了三方面的安全保障：一是數據來源驗證，保證 DNS 應答消息來自被授權的權威伺服器；二是數據完整性驗證，保證 DNS 應答消息在傳輸途中未經篡改；三是否定存在驗證，當用戶請求一個不存在的域名時，DNS伺服器也能夠給出包含數字簽名的否定應答消息，以保證這個否定應答的可靠性。
綜上所述，DNSSEC 本質上是在域名系統樹型授權體系的基礎上，再建立一套基於密碼學手段的簽名/驗證體系，也就是信任鏈體系，通過信任鏈上的逐級安全驗證，確保 DNS 查詢結果的真實可靠性、數據完整性和非否認性。
互聯網名稱與數字管理機構（ICANN）一直在全球推進 DNSSEC 的部署，2010 年 7 月，ICANN 正式用 DNSSEC 簽署根域。為了更好地管理根密鑰，ICANN 制訂了根密鑰管理計劃。該計劃在全球選擇信任社區代表（TCR），負責生成管理根密鑰。ICANN 一共選出 21 名 TCR 和一些後備TCR，所有的候選人都是來自互聯網社區的個人。其中 14 名 TCR 是密碼管理員（CO），美國東海岸和西海岸各 7 名，負責參與生成根密鑰。另外 7名 TCR 是恢復密鑰持有人（RKSH），負責硬體安全模塊（HSM）內容的備份和管理，用於緊急狀態時候恢復 HSM 工作狀態。2010 年 6 月，在美國弗吉尼亞州的庫爾佩珀（Culpeper）召開了全球第一次 DNSSEC 根密鑰生成儀式會議。
ICANN 有兩套完全相同的 HSM，分別放在美國東海岸和西海岸，用於根密鑰的生成。啟動HSM 的密鑰由 CO 保管。根密鑰生成儀式，輪流在東西海岸進行。如果 HSM 出現問題或者根密鑰出現緊急情況，需要 RKSH 赴美恢復 HSM，重新恢復根秘鑰。根據 ICANN 制定的根密鑰管理規則，沒有 TCR 的參與，ICANN 是無法生成根密鑰的。通過 TCR 的參與生成和管理根密鑰，使 ICANN 的根密鑰生成管理更加透明，形成了全球參與根密鑰生成管理的局面。
DNSSEC 機制利用公鑰信任鏈機制構建了可信的域名查詢體系，全球根伺服器中的互聯網頂級域名數據需要利用根秘鑰進行簽名，保證數據的安全可信。DNSSEC 只是保證了 DNS 數據的可信性，但是，並沒有對 DNS 數據本身進行加密。
（二）資源公鑰基礎設施協議通過公鑰信任鏈應對路由通告偽造問題
作為支撐互聯互通的互聯網基礎設施，域名系統和域間路由系統對互聯網的安全有著至關重要的影響。由於邊界網關協議（BGP）缺乏對路由通告內容真實性的保證，因此黑客的蓄意攻擊以及錯誤的網路參數配置都可以導致路由劫持現象的發生。路由劫持對互聯網的正常運行影響極大，可能導致大面積的網路癱瘓。於是，IETF 提出了資源公鑰基礎設施（RPKI）協議。RPKI 的概念最早便誕生於描述安全邊界網關協議（S-BGP）方案的論文中。S-BGP 提出了一種附加簽名的 BGP 消息格式，用以驗證路由通告中 IP 地址前綴和傳播路徑上自治域（AS）號的綁定關系，從而避免路由劫持。基於這樣的設計，數字證書和簽名機制被引入BGP 范疇，並利用了公鑰基礎設施（PKI）。為驗證路由通告簽名者所持有的公鑰，該簽名者的 IP地址分配上級為其簽發證書，一方面，驗證其公鑰，另一方面，驗證該實體對某個 IP 地址前綴的所有權。基於 IP 地址資源分配關系而形成的公鑰證書體系，RPKI 的基本框架就此形成。
RPKI 體系由三大關鍵模塊組成：基礎資源公鑰證書體系（RPKI）、數字簽名對象、儲存 RPKI簽名對象的分布式 RPKI 資料庫。這三大模塊能夠確保一個實體驗證誰是某個 IP 地址或者 AS 號碼的合法持有者。RPKI 可以使 IP 地址的合法持有者授權某個 AS 作為該地址的路由源，並進行驗證。這種可以驗證的授權，可以用來構建更加安全的路由表過濾項。
為了推動 RPKI 的部署，RPKI 架構充分利用了現有的技術和實踐。RPKI 的結構可與現有的資源分配體系對應，可以看作是目前資源管理組織運行模式的自然技術延伸，而且現有的資源分配和回收方式在這套新體系中都有明確地相關定義。
（三）傳輸服務協議通過公鑰信任鏈應對域名證書偽造和客戶端認證問題
互聯網上用於安全認證的證書一般由被稱為認證機構（CA）頒發。然而，CA 模型比較容易受攻擊，在互聯網上受信任的 CA 有成千上萬個，這些 CA 在理論上可以頒發任何一個證書。一個 CA可能存在惡意頒發或者錯誤頒發不屬於互聯網域名使用者的證書，從而形成中間人攻擊，造成互聯網安全的隱患。IETF 在 RFC6698 技術標准中提出了基於 DNS 的名字實體認證協議（DANE）技術，DANE 可以通過稱為傳輸層安全認證（TLSA）的DNS 資源記錄進行域名證書的認證和頒發，使只有控制域名的實際控制人才能頒發相應域名的安全證書，保證了 TLS 證書的安全。DANE 使用 DNSSEC基礎設施存儲和簽署密鑰，以及 TLS 使用的證書。DANE 提供了將公鑰綁定到 DNS 域名的機制。由於管理公鑰數據和管理DNS 域名的實體是同一個，減少了利用域名進行中間人攻擊的機會。與域名關聯的密鑰只能由該父級域名密鑰簽名與關聯。例如，「example.cn」鑰匙只能由「cn」的密鑰簽名，「cn」的密鑰只能由 DNS 根鑰匙簽名。任何域名的簽名密鑰都可以通過使用標准 DNSSEC 協議查詢和分發簽名密鑰，通過 DANE 可以部署用戶自簽名證書。原本自簽名證書被認為是不安全的，但是通過DNSSEC 的加持，針對域名自有域名的自簽名證書在 DANE 里可以安全使用。
2021 年，IETF 又成立了網路客戶端 DANE 認證（DANCE）工作組，利用 DANE 加強網路客戶端相關協議的安全。目前，相關技術標准正在制定過程中。各種傳輸服務協議可以通過 DANE 機制中的公鑰信任鏈應對域名證書偽造和客戶端認證問題，使通信更加安全。
三、互聯網基礎資源技術協議向保護隱私化發展
2013 年的斯諾登事件爆發後，IETF 的最高技術管理機構 IAB 組織了專門的技術研討會，研討如何加強互聯網的隱私保護，防止中間人進行竊聽和信息截取。IAB 認為，IETF 的技術協議需要全面加強端到端的加密，以避免中間人攻擊。此後，IETF 的各項協議都加強了安全的考慮，以保護用戶的隱私不被中間人截取，推動互聯網協議向保護隱私化發展。
（一）互聯網傳輸協議向快速安全連接QUIC 協議演進
快速 UDP 互聯網連接（Quick UDP InternetConnection，QUIC）協議是以谷歌開發和部署的網路協議為基礎進行研究的基礎傳輸協議，並被IETF 進行了標准化工作。谷歌認為傳輸控制協議（TCP）存在諸多問題，想設計一種新的傳輸協議，在 2012 年提出基於 UDP 進行設計的思路，並在2013 年 8 月發布的 Chromium 版本 29 中首次公開。QUIC 是眾多對 TCP 進行完善的傳輸層網路協議之一。QUIC 協議於 2021 年 5 月正式發布，並編號為RFC9000。
QUIC 可以被認為是數據報傳輸應用程序。使用 QUIC 的應用程序協議使用 UDP 埠 443 發送和接收數據包。QUIC 很好地解決了當今傳輸層和應用層面臨的各種需求，包括處理更多的連接，具有更好的安全性和低延遲性。QUIC 基於 UDP 傳輸，融合了包括 TCP、安全傳輸層協議（TLS）、超文本傳輸協議第 2 版（HTTP/2）等協議的特性，使傳輸協議更加高效。QUIC 的一個主要目標就是減少連接延遲，當客戶端第一次連接伺服器時，QUIC 只需要 1 次往返時延（RTT）的延遲就可以建立可靠安全的連接，相對於 TCP+TLS 的 1 3次 RTT，前者要更加快捷。之後，客戶端可以在本地緩存加密的認證信息，當再次與伺服器建立連接時，可以實現 0 RTT 的延遲。QUIC 同時重復使用了 HTTP/2 協議的多路復用功能，而且利用 UDP 成功避免了 HTTP/2 的隊頭阻塞問題。
（二）DNS 傳輸協議向保護用戶隱私方向發展
由於 DNS 的明文設計，因此用戶查詢域名DNS 數據會泄露用戶的行為，同時，第三方伺服器會收集用戶的查詢日誌，DNS 隱私保護方面的技術發展主要包括 2 個方面。
一是查詢最小化機制。即遞歸解析器每次只發送必要的查詢信息，不向根和頂級伺服器暴露完整的域名。同時，有研究者提出，將每次真實的查詢混淆在多個虛擬查詢中，及伺服器主動進行熱點域名廣播等方法，用來緩解用戶隱私泄露的風險。
二是基於 HTTPS 的 DNS（DoH）和基於 TCP的 DNS（DoT）機制，分別利用 HTTPS、TCP 技術，實現 DNS 的加密，二者的底層都是基於 TLS。目前，二者已相繼發布為 IETF RFC 技術標准。IETF 成立DNS 隱私傳輸交換工作組，專門研究 DNS 隱私保護相關的課題，基於 QUIC 的 DNS（DoQ）也在該工作組推動過程中。另一方面，HTTP-over-QUIC已被命名為 HTTP/3。DoH/DoT 發布為正式標准後，IETF 隱私相關的議題主要集中在對具有加密技術的解析器的自動發現及遞歸到權威解析器的隱私加密機制研究方面。
（三）傳輸層安全協議進行擴展以支持更隱私化技術
TLS 1.3 是 IETF 制定的 TLS 新標准。TLS 用於保護 Web（以及更多其他領域），提供加密並確保每個 HTTPS 網站和應用程序編程介面（API）的真實性。TLS 1.3 所屬的 RFC 8446 標准在 2018 年發布，這是該協議的第一次重大改革，帶來了重大的安全性和性能改進。TLS 1.3 基於更早的 TLS 1.2，但與 TLS 1.2 也有較大的 區 別， 例 如，TLS1.3 可以減少協議握手的延遲時間，提高抗攻擊性，設計將密鑰協商和認證演算法從密碼包中分離出來，移除脆弱和較少使用的演算法，例如移除信息摘要演算法 （MD5）和安全散列演算法（SHA-224）的支持等。TLS1.3 將大部分傳輸信息進行了加密處理，但是 TLS 1.3 提供的伺服器名字指示信息（SNI）並未在發送客戶端問候（ClientHello）會話時加密。第三方可以輕松獲取 TLS 1.3 雙方交換信息時的伺服器名字指示信息。IETF 目前正在推動如何把伺服器名字指示信息（SNI）也進行加密的技術（ECH）。如果 ECH技術部署後，通信雙方的伺服器名字指示信息（SNI）將進行加密，第三方很難獲知 SNI 信息，使雙方通信更加隱私化。
四、互聯網基礎資源技術協議向全面安全可信發展
互聯網已經融入了生活和工作的方方面面，互聯網傳輸的數據越來越重要。互聯網基礎資源技術協議的數據從明文傳輸方式，逐步過渡到認證明文數據的來源可靠性、完整性和防篡改性，並對部分核心數據進行了加密，對有些協議參數也進行了加密。通過簽名、信任鏈和加密等方式保證了互聯網數據傳輸的可靠性和安全性，減少了中間人獲取隱私信息的可能。基於上述分析，可以有以下判斷。
一是 QUIC 協議展現了比 TCP 協議更好的性能，互聯網的 TCP 協議有可能被 QUIC 協議逐步取代。在未來十年，QUIC 協議將逐步蠶食 TCP 協議的領地，更多的應用程序將基於 QUIC 協議傳輸而不是 TCP 協議。
二 是 TLS 1.3 協議正在逐步得到部署，逐步取代舊版本的協議，如果未來配合ECH 技術的部署，使互聯網的端到端傳輸更加安全可靠，但是這項技術可能導致利用伺服器名字指示信息（SNI）進行安全策略管理的防火牆的部分功能失效。
三是 RPKI 由於存在信任鏈和信任錨的安全管理問題，短期內很難得到大規模部署。如果 RPKI操作不當，證書錯誤配置或者惡意撤銷也會引發一系列的安全問題。
四是自從互聯網全球域名根區部署 DNSSEC技術十多年以來，由於技術部署投入和帶來的收益不成正比，因此目前部署率不是很高。在下一個十年，如果沒有關鍵應用的支持，DNSSEC 也很難進行大規模普及應用。
（本文刊登於《中國信息安全》雜志2022年第4期）