-
Notifications
You must be signed in to change notification settings - Fork 8k
New issue
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
feat(gin): support both http/2 and http/3 using quic-go/quic-go #3973
base: master
Are you sure you want to change the base?
Conversation
…ections in parallel using RunTLSAndQUIC - Bump github.com/quic-go/quic-go from v0.43.1 to v0.44.0 and dependencies - Created new func RunTLSAndQUIC to run both TLS/TCP and QUIC in parallel Signed-off-by: Diana Moore <dmoore@xn4p4lm.com>
- Added new test for RunTLSAndQUIC - Added support for HTTP/3 with future tests Signed-off-by: Diana Moore <dmoore@xn4p4lm.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3973 +/- ##
==========================================
- Coverage 99.21% 99.05% -0.16%
==========================================
Files 42 44 +2
Lines 3182 2759 -423
==========================================
- Hits 3157 2733 -424
+ Misses 17 15 -2
- Partials 8 11 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
// both TLS/TCP and QUIC connections in parallel requests. | ||
// It is a shortcut for http3.ListenAndServe(addr, certFile, keyFile, router) | ||
// Note: this method will block the calling goroutine indefinitely unless an error happens. | ||
func (engine *Engine) RunTLSAndQUIC(addr, certFile, keyFile string) (err error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should keep RunQUIC
func and replace http3.ListenAndServeQUIC
with http3.ListenAndServeTLS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might be a good alternative, but could there be any situations where you would only want to provide just QUIC?
I could see a potential for for mobile first applications with high retry and latency requirements.
cc @marten-seemann for visibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using http3.ListenAndServerTLS
is fine, if you don't need a lot of control over the HTTP(/3) server spawned.
Most importantly:
- It doesn't allow you to configure the server in any way (see https://quic-go.net/docs/http3/server/)
- It doesn't allow you to cleanly shut down the server
If you want more control, you can initialize a http3.Server
, which exposes a bunch of configuration options, and a Close
method.
53c1160
e67f1e9
Latency Testing using
RunTLSAndQUIC
(this is not perfect or real world):Using
RunTLSAndQUIC
:Using
RunQUIC
:master
Signed-off-by: Diana Moore dmoore@xn4p4lm.com