Implement TCP FastOpen (TFO) RFC7413 #840
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…server_t, struct query -> ares_query_t
|
Hello, this update broken my vcpkg build on CentOS 7, which has an old kernel version that does not support TCP_FASTOPEN_CONNECT. Is it possible to get this working for these kind of older kernels? Thanks. |
Member
Author
already fixed in 4abdf7d |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a client and server have previously communicated. The SYN packet will also contain the initial data packet from the client to the server. This means there should be virtually no slowdown over UDP when both sides support TCP FastOpen, which is unfortunately not always the case. For instance,
1.1.1.1appears to support TFO, however8.8.8.8does not.This implementation supports Linux, Android, FreeBSD, MacOS, and iOS. While Windows does have support for TCP FastOpen it does so via completion APIs only, and that can't be used with polling APIs like used by every other OS. We could implement it in the future if desired for those using
ARES_OPT_EVENT_THREAD, but it would probably require adopting IOCP completely on Windows.Sysctls are required to be set appropriately:
net.ipv4.tcp_fastopen:1= client only (typically default)2= server only3= client and servernet.inet.tcp.fastopen1= client only2= server only3= client and server (typically default)net.inet.tcp.fastopen.server_enable(boolean) andnet.inet.tcp.fastopen.client_enable(boolean)This feature is always-on, when running on an OS with the capability enabled. Though some middleboxes have impacted end-to-end TFO and caused connectivity errors, all modern OSs perform automatic blackholing of IPs that have issues with TFO. It is not expected this to cause any issues in the modern day implementations.
This will also help with improving latency for future DoT and DoH implementations.
Authored-By: Brad House (@bradh352)