We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
根據文章所提及
Currently deployed technology does not allow us to make any guarantees about delays or reliability of the network
在現有連線遵循 TCP 的狀況下,確實會有超時以及不如預期的 delay 等狀況影響 RTT ,但 TCP 無法很有效率地改善此問題。因此 Google 在 2013 年發表了一個新的傳輸協議 QUIC (後來改名為 HTTP/3 ), 在 UDP 的基礎之上建立了更考靠的傳輸協議,詳情可以看這 -> HTTP/3 傳輸協議 - QUIC 原理簡介,內文解釋了如何 improved congestion control (增進網路壅塞控管), forward error correction (前向錯誤更正) 等 TCP 會有的 issue
在這樣的情況下,可以認定 HTTP/3 可以使 network 變的更可靠。想知道大家還有沒有知道如使用 HTTP/3 的方式能使 network 更可靠些?
The text was updated successfully, but these errors were encountered:
其實可靠感覺也有很多面向,例如 HTTP/3 應該也不會讓「封包遺失」這件事發生的機會降低,不過它在重傳上不管效能還是機制都比前一代好上許多就是了
Sorry, something went wrong.
https://blog.cloudflare.com/http3-the-past-present-and-future/
No branches or pull requests
根據文章所提及
在現有連線遵循 TCP 的狀況下,確實會有超時以及不如預期的 delay 等狀況影響 RTT ,但 TCP 無法很有效率地改善此問題。因此 Google 在 2013 年發表了一個新的傳輸協議 QUIC (後來改名為 HTTP/3 ), 在 UDP 的基礎之上建立了更考靠的傳輸協議,詳情可以看這 -> HTTP/3 傳輸協議 - QUIC 原理簡介,內文解釋了如何 improved congestion control (增進網路壅塞控管), forward error correction (前向錯誤更正) 等 TCP 會有的 issue
在這樣的情況下,可以認定 HTTP/3 可以使 network 變的更可靠。想知道大家還有沒有知道如使用 HTTP/3 的方式能使 network 更可靠些?
The text was updated successfully, but these errors were encountered: