Skip to content
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

quic: Don't delay TCP attempt when HTTP/3 status is unknown #37040

Merged
merged 6 commits into from
Nov 8, 2024

Conversation

fredyw
Copy link
Member

@fredyw fredyw commented Nov 7, 2024

Commit Message: When HTTP/3 is not known to work, we should attempt both QUIC and TCP at the same time instead of giving QUIC a head start and delaying the TCP connection attempt.
Additional Description: In Envoy Mobile, the HTTP/3 status will be reset upon network change.
Risk Level: low (runtime guarded and the default is false)
Testing: unit and integration tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: quic, mobile
Optional Runtime guard: envoy.reloadable_features.quic_no_tcp_delay (default is false)

Signed-off-by: Fredy Wijaya <fredyw@google.com>
Copy link

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #37040 was opened by fredyw.

see: more, trace.

Copy link

CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).

🐱

Caused by: #37040 was opened by fredyw.

see: more, trace.

@fredyw fredyw changed the title quic: No TCP delay attempt when HTTP/3 status is unknown quic: Don't delay TCP attempt when HTTP/3 status is unknown Nov 7, 2024
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Signed-off-by: Fredy Wijaya <fredyw@google.com>
@fredyw
Copy link
Member Author

fredyw commented Nov 7, 2024

/retest

@fredyw fredyw marked this pull request as ready for review November 8, 2024 00:10
@fredyw
Copy link
Member Author

fredyw commented Nov 8, 2024

/assign @RyanTheOptimist

RyanTheOptimist
RyanTheOptimist previously approved these changes Nov 8, 2024
// The first request could either be HTTP/2 or HTTP/3 because we no longer give HTTP/3 a head
// start.
ASSERT_GE(protocols.at(0), Http::Protocol::Http2);
// TODO(fredyw): In EngFlow CI, HTTP/3 does not work and will use HTTP/2 instead.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, that's interesting. Any idea why yet?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know yet. I pinged EngFlow in Slack. I suspect UDP is blocked or something even after setting https://docs.engflow.com/re/client/platform-options-reference.html#dockernetwork

source/common/http/http_server_properties_cache_impl.cc Outdated Show resolved Hide resolved
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Signed-off-by: Fredy Wijaya <fredyw@google.com>
@fredyw
Copy link
Member Author

fredyw commented Nov 8, 2024

/retest

@fredyw fredyw merged commit 232c19e into envoyproxy:main Nov 8, 2024
21 checks passed
@fredyw fredyw deleted the no_delay_tcp_attempt branch November 8, 2024 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants