HTTP/3 原理實戰

来源:https://www.cnblogs.com/88223100/archive/2022/12/19/HTTP3-Principle-Practice.html
-Advertisement-
Play Games

2015 年 HTTP/2 標準發表後,大多數主流瀏覽器也於當年年底支持該標準。此後,憑藉著多路復用、頭部壓縮、伺服器推送等優勢,HTTP/2 得到了越來越多開發者的青睞。不知不覺的 HTTP 已經發展到了第三代,鵝廠也緊跟技術潮流,很多項目也在逐漸使用 HTTP/3。本文基於興趣部落接入 HTTP... ...


 

 

2015 年 HTTP/2 標準發表後,大多數主流瀏覽器也於當年年底支持該標準。此後,憑藉著多路復用、頭部壓縮、伺服器推送等優勢,HTTP/2 得到了越來越多開發者的青睞。不知不覺的 HTTP 已經發展到了第三代,鵝廠也緊跟技術潮流,很多項目也在逐漸使用 HTTP/3。本文基於興趣部落接入 HTTP/3 的實踐,聊一聊 HTTP/3 的原理以及業務接入的方式。

1. HTTP/3 原理

1.1 HTTP 歷史

在介紹 HTTP/3 之前,我們先簡單看下 HTTP 的歷史,瞭解下 HTTP/3 出現的背景。

隨著網路技術的發展,1999 年設計的 HTTP/1.1 已經不能滿足需求,所以 Google 在 2009 年設計了基於 TCP 的 SPDY,後來 SPDY 的開發組推動 SPDY 成為正式標準,不過最終沒能通過。不過 SPDY 的開發組全程參與了 HTTP/2 的制定過程,參考了 SPDY 的很多設計,所以我們一般認為 SPDY 就是 HTTP/2 的前身。無論 SPDY 還是 HTTP/2,都是基於 TCP 的,TCP 與 UDP 相比效率上存在天然的劣勢,所以 2013 年 Google 開發了基於 UDP 的名為 QUIC 的傳輸層協議,QUIC 全稱 Quick UDP Internet Connections,希望它能替代 TCP,使得網頁傳輸更加高效。後經提議,互聯網工程任務組正式將基於 QUIC 協議的 HTTP (HTTP over QUIC)重命名為 HTTP/3。

1.2 QUIC 協議概覽

TCP 一直是傳輸層中舉足輕重的協議,而 UDP 則默默無聞,在面試中問到 TCP 和 UDP 的區別時,有關 UDP 的回答常常寥寥幾語,長期以來 UDP 給人的印象就是一個很快但不可靠的傳輸層協議。但有時候從另一個角度看,缺點可能也是優點。QUIC(Quick UDP Internet Connections,快速 UDP 網路連接) 基於 UDP,正是看中了 UDP 的速度與效率。同時 QUIC 也整合了 TCP、TLS 和 HTTP/2 的優點,並加以優化。用一張圖可以清晰地表示他們之間的關係。

那 QUIC 和 HTTP/3 什麼關係呢?QUIC 是用來替代 TCP、SSL/TLS 的傳輸層協議,在傳輸層之上還有應用層,我們熟知的應用層協議有 HTTP、FTP、IMAP 等,這些協議理論上都可以運行在 QUIC 之上,其中運行在 QUIC 之上的 HTTP 協議被稱為 HTTP/3,這就是”HTTP over QUIC 即 HTTP/3“的含義。

因此想要瞭解 HTTP/3,QUIC 是繞不過去的,下麵主要通過幾個重要的特性讓大家對 QUIC 有更深的理解。

1.3 零 RTT 建立連接

用一張圖可以形象地看出 HTTP/2 和 HTTP/3 建立連接的差別。

HTTP/2 的連接需要 3 RTT,如果考慮會話復用,即把第一次握手算出來的對稱密鑰緩存起來,那麼也需要 2 RTT,更進一步的,如果 TLS 升級到 1.3,那麼 HTTP/2 連接需要 2 RTT,考慮會話復用則需要 1 RTT。有人會說 HTTP/2 不一定需要 HTTPS,握手過程還可以簡化。這沒毛病,HTTP/2 的標準的確不需要基於 HTTPS,但實際上所有瀏覽器的實現都要求 HTTP/2 必須基於 HTTPS,所以 HTTP/2 的加密連接必不可少。而 HTTP/3 首次連接只需要 1 RTT,後面的連接更是只需 0 RTT,意味著客戶端發給服務端的第一個包就帶有請求數據,這一點 HTTP/2 難以望其項背。那這背後是什麼原理呢?我們具體看下 QUIC 的連接過程。

Step1:首次連接時,客戶端發送 Inchoate Client Hello 給服務端,用於請求連接;

Step2:服務端生成 g、p、a,根據 g、p 和 a 算出 A,然後將 g、p、A 放到 Server Config 中再發送 Rejection 消息給客戶端;

Step3:客戶端接收到 g、p、A 後,自己再生成 b,根據 g、p、b 算出 B,根據 A、p、b 算出初始密鑰 K。B 和 K 算好後,客戶端會用 K 加密 HTTP 數據,連同 B 一起發送給服務端;

Step4:服務端接收到 B 後,根據 a、p、B 生成與客戶端同樣的密鑰,再用這密鑰解密收到的 HTTP 數據。為了進一步的安全(前向安全性),服務端會更新自己的隨機數 a 和公鑰,再生成新的密鑰 S,然後把公鑰通過 Server Hello 發送給客戶端。連同 Server Hello 消息,還有 HTTP 返回數據;

Step5:客戶端收到 Server Hello 後,生成與服務端一致的新密鑰 S,後面的傳輸都使用 S 加密。

這樣,QUIC 從請求連接到正式接發 HTTP 數據一共花了 1 RTT,這 1 個 RTT 主要是為了獲取 Server Config,後面的連接如果客戶端緩存了 Server Config,那麼就可以直接發送 HTTP 數據,實現 0 RTT 建立連接。

這裡使用的是 DH 密鑰交換演算法,DH 演算法的核心就是服務端生成 a、g、p 3 個隨機數,a 自己持有,g 和 p 要傳輸給客戶端,而客戶端會生成 b 這 1 個隨機數,通過 DH 演算法客戶端和服務端可以算出同樣的密鑰。在這過程中 a 和 b 並不參與網路傳輸,安全性大大提高。因為 p 和 g 是大數,所以即使在網路中傳輸的 p、g、A、B 都被劫持,那麼靠現在的電腦算力也沒法破解密鑰。

1.4 連接遷移

TCP 連接基於四元組(源 IP、源埠、目的 IP、目的埠),切換網路時至少會有一個因素髮生變化,導致連接發生變化。當連接發生變化時,如果還使用原來的 TCP 連接,則會導致連接失敗,就得等原來的連接超時後重新建立連接,所以我們有時候發現切換到一個新網路時,即使新網路狀況良好,但內容還是需要載入很久。如果實現得好,當檢測到網路變化時立刻建立新的 TCP 連接,即使這樣,建立新的連接還是需要幾百毫秒的時間。

QUIC 的連接不受四元組的影響,當這四個元素髮生變化時,原連接依然維持。那這是怎麼做到的呢?道理很簡單,QUIC 連接不以四元組作為標識,而是使用一個 64 位的隨機數,這個隨機數被稱為 Connection ID,即使 IP 或者埠發生變化,只要 Connection ID 沒有變化,那麼連接依然可以維持。

1.5 隊頭阻塞/多路復用

HTTP/1.1 和 HTTP/2 都存在隊頭阻塞問題(Head of line blocking),那什麼是隊頭阻塞呢?

TCP 是個面向連接的協議,即發送請求後需要收到 ACK 消息,以確認對方已接收到數據。如果每次請求都要在收到上次請求的 ACK 消息後再請求,那麼效率無疑很低。後來 HTTP/1.1 提出了 Pipelining 技術,允許一個 TCP 連接同時發送多個請求,這樣就大大提升了傳輸效率。

在這個背景下,下麵就來談 HTTP/1.1 的隊頭阻塞。下圖中,一個 TCP 連接同時傳輸 10 個請求,其中第 1、2、3 個請求已被客戶端接收,但第 4 個請求丟失,那麼後面第 5 - 10 個請求都被阻塞,需要等第 4 個請求處理完畢才能被處理,這樣就浪費了帶寬資源。

因此,HTTP 一般又允許每個主機建立 6 個 TCP 連接,這樣可以更加充分地利用帶寬資源,但每個連接中隊頭阻塞的問題還是存在。

HTTP/2 的多路復用解決了上述的隊頭阻塞問題。不像 HTTP/1.1 中只有上一個請求的所有數據包被傳輸完畢下一個請求的數據包才可以被傳輸,HTTP/2 中每個請求都被拆分成多個 Frame 通過一條 TCP 連接同時被傳輸,這樣即使一個請求被阻塞,也不會影響其他的請求。如下圖所示,不同顏色代表不同的請求,相同顏色的色塊代表請求被切分的 Frame。

事情還沒完,HTTP/2 雖然可以解決“請求”這個粒度的阻塞,但 HTTP/2 的基礎 TCP 協議本身卻也存在著隊頭阻塞的問題。HTTP/2 的每個請求都會被拆分成多個 Frame,不同請求的 Frame 組合成 Stream,Stream 是 TCP 上的邏輯傳輸單元,這樣 HTTP/2 就達到了一條連接同時發送多條請求的目標,這就是多路復用的原理。我們看一個例子,在一條 TCP 連接上同時發送 4 個 Stream,其中 Stream1 已正確送達,Stream2 中的第 3 個 Frame 丟失,TCP 處理數據時有嚴格的前後順序,先發送的 Frame 要先被處理,這樣就會要求發送方重新發送第 3 個 Frame,Stream3 和 Stream4 雖然已到達但卻不能被處理,那麼這時整條連接都被阻塞。

不僅如此,由於 HTTP/2 必須使用 HTTPS,而 HTTPS 使用的 TLS 協議也存在隊頭阻塞問題。TLS 基於 Record 組織數據,將一堆數據放在一起(即一個 Record)加密,加密完後又拆分成多個 TCP 包傳輸。一般每個 Record 16K,包含 12 個 TCP 包,這樣如果 12 個 TCP 包中有任何一個包丟失,那麼整個 Record 都無法解密。

隊頭阻塞會導致 HTTP/2 在更容易丟包的弱網路環境下比 HTTP/1.1 更慢!

那 QUIC 是如何解決隊頭阻塞問題的呢?主要有兩點。

  • QUIC 的傳輸單元是 Packet,加密單元也是 Packet,整個加密、傳輸、解密都基於 Packet,這樣就能避免 TLS 的隊頭阻塞問題;
  • QUIC 基於 UDP,UDP 的數據包在接收端沒有處理順序,即使中間丟失一個包,也不會阻塞整條連接,其他的資源會被正常處理。

1.6 擁塞控制

擁塞控制的目的是避免過多的數據一下子涌入網路,導致網路超出最大負荷。QUIC 的擁塞控制與 TCP 類似,併在此基礎上做了改進。所以我們先簡單介紹下 TCP 的擁塞控制。

TCP 擁塞控制由 4 個核心演算法組成:慢啟動、擁塞避免、快速重傳和快速恢復,理解了這 4 個演算法,對 TCP 的擁塞控制也就有了大概瞭解。

  • 慢啟動:發送方向接收方發送 1 個單位的數據,收到對方確認後會發送 2 個單位的數據,然後依次是 4 個、8 個……呈指數級增長,這個過程就是在不斷試探網路的擁塞程度,超出閾值則會導致網路擁塞;
  • 擁塞避免:指數增長不可能是無限的,到達某個限制(慢啟動閾值)之後,指數增長變為線性增長;
  • 快速重傳:發送方每一次發送時都會設置一個超時計時器,超時後即認為丟失,需要重發;
  • 快速恢復:在上面快速重傳的基礎上,發送方重新發送數據時,也會啟動一個超時定時器,如果收到確認消息則進入擁塞避免階段,如果仍然超時,則回到慢啟動階段。

QUIC 重新實現了 TCP 協議的 Cubic 演算法進行擁塞控制,併在此基礎上做了不少改進。下麵介紹一些 QUIC 改進的擁塞控制的特性。

1.6.1 熱插拔

TCP 中如果要修改擁塞控制策略,需要在系統層面進行操作。QUIC 修改擁塞控制策略只需要在應用層操作,並且 QUIC 會根據不同的網路環境、用戶來動態選擇擁塞控制演算法。

1.6.2 前向糾錯 FEC

QUIC 使用前向糾錯(FEC,Forward Error Correction)技術增加協議的容錯性。一段數據被切分為 10 個包後,依次對每個包進行異或運算,運算結果會作為 FEC 包與數據包一起被傳輸,如果不幸在傳輸過程中有一個數據包丟失,那麼就可以根據剩餘 9 個包以及 FEC 包推算出丟失的那個包的數據,這樣就大大增加了協議的容錯性。

這是符合現階段網路技術的一種方案,現階段帶寬已經不是網路傳輸的瓶頸,往返時間才是,所以新的網路傳輸協議可以適當增加數據冗餘,減少重傳操作。

1.6.3 單調遞增的 Packet Number

TCP 為了保證可靠性,使用 Sequence Number 和 ACK 來確認消息是否有序到達,但這樣的設計存在缺陷。

超時發生後客戶端發起重傳,後來接收到了 ACK 確認消息,但因為原始請求和重傳請求接收到的 ACK 消息一樣,所以客戶端就鬱悶了,不知道這個 ACK 對應的是原始請求還是重傳請求。如果客戶端認為是原始請求的 ACK,但實際上是左圖的情形,則計算的採樣 RTT 偏大;如果客戶端認為是重傳請求的 ACK,但實際上是右圖的情形,又會導致採樣 RTT 偏小。圖中有幾個術語,RTO 是指超時重傳時間(Retransmission TimeOut),跟我們熟悉的 RTT(Round Trip Time,往返時間)很長得很像。採樣 RTT 會影響 RTO 計算,超時時間的準確把握很重要,長了短了都不合適。

QUIC 解決了上面的歧義問題。與 Sequence Number 不同的是,Packet Number 嚴格單調遞增,如果 Packet N 丟失了,那麼重傳時 Packet 的標識不會是 N,而是比 N 大的數字,比如 N + M,這樣發送方接收到確認消息時就能方便地知道 ACK 對應的是原始請求還是重傳請求。

1.6.4 ACK Delay

TCP 計算 RTT 時沒有考慮接收方接收到數據到發送確認消息之間的延遲,如下圖所示,這段延遲即 ACK Delay。QUIC 考慮了這段延遲,使得 RTT 的計算更加準確。

1.6.5 更多的 ACK 塊

一般來說,接收方收到發送方的消息後都應該發送一個 ACK 回覆,表示收到了數據。但每收到一個數據就返回一個 ACK 回覆太麻煩,所以一般不會立即回覆,而是接收到多個數據後再回覆,TCP SACK 最多提供 3 個 ACK block。但有些場景下,比如下載,只需要伺服器返回數據就好,但按照 TCP 的設計,每收到 3 個數據包就要“禮貌性”地返回一個 ACK。而 QUIC 最多可以捎帶 256 個 ACK block。在丟包率比較嚴重的網路下,更多的 ACK block 可以減少重傳量,提升網路效率。

1.7 流量控制

TCP 會對每個 TCP 連接進行流量控制,流量控制的意思是讓發送方不要發送太快,要讓接收方來得及接收,不然會導致數據溢出而丟失,TCP 的流量控制主要通過滑動視窗來實現的。可以看出,擁塞控制主要是控制發送方的發送策略,但沒有考慮到接收方的接收能力,流量控制是對這部分能力的補齊。

QUIC 只需要建立一條連接,在這條連接上同時傳輸多條 Stream,好比有一條道路,兩頭分別有一個倉庫,道路中有很多車輛運送物資。QUIC 的流量控制有兩個級別:連接級別(Connection Level)和 Stream 級別(Stream Level),好比既要控制這條路的總流量,不要一下子很多車輛涌進來,貨物來不及處理,也不能一個車輛一下子運送很多貨物,這樣貨物也來不及處理。

那 QUIC 是怎麼實現流量控制的呢?我們先看單條 Stream 的流量控制。Stream 還沒傳輸數據時,接收視窗(flow control receive window)就是最大接收視窗(flow control receive window),隨著接收方接收到數據後,接收視窗不斷縮小。在接收到的數據中,有的數據已被處理,而有的數據還沒來得及被處理。如下圖所示,藍色塊表示已處理數據,黃色塊表示未處理數據,這部分數據的到來,使得 Stream 的接收視窗縮小。

隨著數據不斷被處理,接收方就有能力處理更多數據。當滿足 (flow control receive offset - consumed bytes) < (max receive window / 2) 時,接收方會發送 WINDOW_UPDATE frame 告訴發送方你可以再多發送些數據過來。這時 flow control receive offset 就會偏移,接收視窗增大,發送方可以發送更多數據到接收方。

Stream 級別對防止接收端接收過多數據作用有限,更需要藉助 Connection 級別的流量控制。理解了 Stream 流量那麼也很好理解 Connection 流控。Stream 中,接收視窗(flow control receive window) = 最大接收視窗(max receive window) - 已接收數據(highest received byte offset) ,而對 Connection 來說:接收視窗 = Stream1 接收視窗 + Stream2 接收視窗 + ... + StreamN 接收視窗 。

2. HTTP/3 實踐

2.1 X5 內核與 STGW

X5 內核是騰訊開發的適用於安卓系統的瀏覽器內核,為瞭解決傳統安卓系統瀏覽器內核適配成本高、不安全、不穩定等問題而開發的統一的瀏覽器內核。STGW 是 Secure Tencent Gateway 的縮寫,意思是騰訊安全雲網關。兩者早在前兩年便支持了 QUIC 協議。

那作為運行在 X5 上的業務,我們該如何接入 QUIC 呢?得益於 X5 和 STGW,業務在接入 QUIC 時所需要做的改動非常小,只需要兩步。

Step 1. 在 STGW 上開啟白名單,允許業務功能變數名稱接入 QUIC 協議;

Step 2. 業務資源的 Response Header 添加 alt-svc 屬性,示例:alt-svc: quic=":443"; ma=2592000; v="44,43,39"。

接入 QUIC 時,STGW 的優勢非常明顯,由 STGW 與支持 QUIC 的客戶端(這裡是 X5)進行通信,而業務後臺與 STGW 仍然使用 HTTP/1.1 通信,QUIC 所需要的 Server Config 等緩存信息也都是由 STGW 維護。

2.2 協商升級與競速

業務功能變數名稱加入了 STGW 的白名單,業務資源的 Response Header 也添加了 alt-svc 屬性,那 QUIC 是如何建立連接的呢?這裡有個關鍵的步驟:協商升級。客戶端不確定伺服器是否支持 QUIC,如果貿然地請求建立 QUIC 連接可能會失敗,所以需要經歷協商升級過程才能決定是否使用 QUIC。

首次請求時,客戶端會使用 HTTP/1.1 或者 HTTP/2,如果伺服器支持 QUIC,則在響應的數據中返回 alt-svc 頭部,告訴客戶端下次請求可以走 QUIC。alt-svc 主要包含以下信息:

  • quic:監聽的埠;
  • ma:有效時間,單位是秒,承諾在這段時間內都支持 QUIC;
  • 版本號:QUIC 的迭代很快,這裡列出所有支持的版本號。

確認伺服器支持 QUIC 之後,客戶端向服務端同時發起 QUIC 連接和 TCP 連接,比較兩個連接的速度,然後選擇較快的協議,這個過程叫“競速”,一般都是 QUIC 獲勝。

2.3 QUIC 性能表現

QUIC 建立連接的成功率在 90% 以上,競速成功率也接近 90%,0 RTT 率在 55% 左右。

使用 QUIC 協議時頁面首屏耗時要比非 QUIC 協議減少 10%。

從資源獲取的不同階段看,QUIC 協議在連接階段節省的時間比較明顯。

從頁面首屏區間占比圖中可以看出,使用了 QUIC 協議後,首屏耗時在 1 秒內的占比提升明顯,大約在 12% 左右。

3. 總結

QUIC 丟掉了 TCP、TLS 的包袱,基於 UDP,並對 TCP、TLS、HTTP/2 的經驗加以借鑒、改進,實現了一個安全高效可靠的 HTTP 通信協議。憑藉著 0 RTT 建立連接、平滑的連接遷移、基本消除了隊頭阻塞、改進的擁塞控制和流量控制等優秀的特性,QUIC 在絕大多數場景下獲得了比 HTTP/2 更好的效果。

一周前,微軟宣佈開源自己的內部 QUIC 庫 -- MsQuic,將全面推薦 QUIC 協議替換 TCP/IP 協議。

HTTP/3 未來可期。

作者:billpchen

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/HTTP3-Principle-Practice.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 華為運動健康服務(HUAWEI Health Kit)提供原子化數據開放,用戶數據被授權獲取後,應用可通過介面訪問運動健康數據,對相關數據進行增、刪、改、查等操作。這篇文章彙總了申請開通Health Kit測試許可權的常見問題,並給出了詳細解答,希望為開發者提供相關參考。 (1) 申請Health K ...
  • 本文簡介 點贊 + 關註 + 收藏 = 學會了 作為一隻前端,只懂 Vue、React 感覺已經和大家拉不開距離了。 可視化、機器學習等領域 JS 都有涉及到,而可視化方面已經被很多領域用到,比如大屏項目。 可視化領域相關的技術有 canvas 和 SVG ,而這兩個東東是遲早要接觸的了。 在我接觸 ...
  • 本章將繼續和大家分享Vue的一些基礎知識。話不多說,下麵我們直接上代碼: 本文內容大部分摘自Vue的官網:https://v2.cn.vuejs.org/v2/guide/ 一、計算屬性 示例如下: <!DOCTYPE html> <html lang="en"> <head> <meta char ...
  • 這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助 前言: 該篇文章用到的主要技術:vue3、three.js 我們先看看成品效果: 高清大圖預覽(會有些慢): 座機小圖預覽: 廢話不多說,直接進入正題 Three.js的基礎知識 想象一下,在一個虛擬的3D世界中都需要什麼?首先,要有一個 ...
  • 在七牛雲校園黑客馬拉松中,一款設計優秀、邏輯清晰的白板作品脫穎而出,獲得第二名的好成績,這就是來自鄭州大學Since團隊的White Rose白板,以下是他們的設計和架構分享。 一、前言 White Rose是參加七牛雲hackathon比賽的作品,賽題的主要內容是開發一個「多人協作白板」,旨在鼓勵 ...
  • 一、ES2015中有四種相等演算法1. 抽象(非嚴格)相等比較。(==)2. 嚴格相等比較。( )3. 同值。(Object.is())4. 同值零。二、JavaScript提供三種不同的值比較操作1. 嚴格相等比較,使用 比較符號。(在兩者進行比較時,不會執行類型轉換)2. 抽象相等比較,使用 == ...
  • 假設,我們有這樣一張 Gif 圖: 利用 CSS,我們嘗試來搞一些事情。 圖片的 Glitch Art 風 在這篇文章中 --CSS 故障藝術,我們介紹了利用混合模式製作一種暈眩感覺的視覺效果。有點類似於抖音的 LOGO。 像是這樣: 假設,我們有這樣一張圖: 只需要一個標簽即可 <div clas ...
  • 案例介紹 歡迎來到我的小院,我是霍大俠,恭喜你今天又要進步一點點了!我們來用JavaScript編程實戰案例,做一個表情評價程式。用戶打星進行評價,表情會根據具體星星數量發生變化。 案例演示 點擊星星可以進行滿意程度評價,星星數量變換表情也會隨之變換。 源碼學習 進入核心代碼學習,我們先來看HTML ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...