弱網環境下的表現不同
GRPC是基於HTTP/2.0協議開發的，HTTP/2.0透過以下舉措在效能方面有極大的提升：
- 引出了Stream 概念，多個 Stream 可以複用在一條 TCP 連線，解決了HTTP/1.1的隊頭阻塞問題（在一條TCP連線上服務端對多個請求的響應只能一個一個同步的響應，即使多個請求是併發的）
- 開發了HPACK演算法壓縮頭部解決http/1.1的頭部巨大且重複的問題
- 將 HTTP/1 的文字格式改成二進位制格式傳輸資料，極大提高了 HTTP 傳輸效率
- 伺服器主動推送
但此時HTTP2依然存在隊頭阻塞問題，不過此時的隊頭阻塞問題存在於TCP層。當發生網路丟包時，由於TCP的機制，服務端需要等丟的包重傳成功後，才會再接收此次TCP連線之後的資料包。而此時，所有的請求都會被阻塞住直到丟包重傳成功。
為了解決TCP層面的隊頭阻塞，HTTP/3.0將傳輸層的tcp協議換成了udp協議，如果發生丟包，只會中斷一個資料流，而不是像http2一樣中斷了所有的資料流，解決了在弱網丟包環境下的隊頭阻塞問題。
通訊連線建立的不同
- 快速握手：grpc基於http2，而http2是基於tcp協議的，因此需要透過握手建立連線，而http3是基於udp協議的，意味著http3建立連線的速度是很快的。
- 連線遷移：http3中的連線使用一個隨機數，稱作Connection ID 來確認通訊雙方的連線建立與否。因此在網路切換場景下，http3是可以做到連線無痕遷移的，使用者在切換網路時不會對應用的延遲有任何感知。而http2是基於tcp的，當切網時，基於tcp的應用會首先無法正常連線，等連線超時後重新建立tcp連線，而重新握手也是需要時間的。
資料傳輸上的不同
-
傳輸的資料都是二進位制幀的結構，但http3的二進位制幀會比http2的二進位制幀更簡潔一點。
-
http3頭部壓縮演算法在http2的基礎上做了改進，http2的靜態表有61項請求頭，http3擴充套件到了91項。
結論
基於弱網環境下http3的表現以及連線遷移的特性，http3會很適合用在移動端進行資料通訊。
在連線已建立以及網路狀態良好的情況下，由於http2與http3都是基於stream的，資料都是二進位制幀的結構，對連線可以多路複用的，在資料傳輸速度上面，雖然http3在頭部壓縮演算法方面做了相應的改進，但對於都是多路複用的通訊場景，在網路通暢的情況下應該區別不大。
