-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Multipath TCP patches from BZ 69292 #476
Conversation
modules/proxy/mod_proxy_connect.c
Outdated
@@ -244,6 +244,9 @@ static int proxy_connect_handler(request_rec *r, proxy_worker *worker, | |||
* For now we do nothing, ie we get DNS round robin. | |||
* XXX FIXME | |||
*/ | |||
|
|||
/* set the socket protocol to use */ | |||
conf->sock_proto = worker->s->sock_proto; |
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.
This is not thread-safe, maybe ignoring MPTCP in mod_proxy_connect is acceptable for now because ap_proxy_connect_to_backend() has no worker configuration, and moving to ap_proxy_connect_backend() is more work..
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.
I don't mind dropping it in this case, from what I understood, this method is deprecated anyway so it should be replaced with ap_proxy_connect_backend in the future (which does support MPTCP) ?
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.
Yes, I think dropping the changes in mod_proxy_connect and ap_proxy_connect_to_backend() is simpler for now, if one wants to use mod_proxy_connect with MPTCP we can look at how moving to ap_proxy_connect_backend() there.
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.
Dropped those in the latest version available on bugzilla
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension that enables a TCP connection to use different paths. Multipath TCP has been used for several use cases. On smartphones, MPTCP enables seamless handovers between cellular and Wi-Fi networks while preserving established connections. This use-case is what pushed Apple to use MPTCP since 2013 in multiple applications [2]. On dual-stack hosts, Multipath TCP enables the TCP connection to automatically use the best performing path, either IPv4 or IPv6. If one path fails, MPTCP automatically uses the other path. To benefit from MPTCP, both the client and the server have to support it. Multipath TCP is a backward-compatible TCP extension that is enabled by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...). Multipath TCP is included in the Linux kernel since version 5.6 [3]. To use it on Linux, an application must explicitly enable it when creating the socket. No need to change anything else in the application. Adding the possibility to create MPTCP sockets would thus be a really fine addition to httpd, by allowing clients to make use of their different interfaces. This patch introduces the possibilty to connect to backend servers using MPTCP. Note however that these changes are only available on Linux, as IPPROTO_MPTCP is Linux specific for the time being. For proxies, we can connect using MPTCP by passing the "multipathtcp" parameter: ProxyPass "/example" "http://backend.example.com" multipathtcp=On We then store this information in the worker and create sockets appropriately according to this value. Link: https://www.rfc-editor.org/rfc/rfc8684.html [1] Link: https://www.tessares.net/apples-mptcp-story-so-far/ [2] Link: https://www.mptcp.dev [3]
Multipath TCP (MPTCP), standardized in RFC8684 [1], is a TCP extension that enables a TCP connection to use different paths. Multipath TCP has been used for several use cases. On smartphones, MPTCP enables seamless handovers between cellular and Wi-Fi networks while preserving established connections. This use-case is what pushed Apple to use MPTCP since 2013 in multiple applications [2]. On dual-stack hosts, Multipath TCP enables the TCP connection to automatically use the best performing path, either IPv4 or IPv6. If one path fails, MPTCP automatically uses the other path. To benefit from MPTCP, both the client and the server have to support it. Multipath TCP is a backward-compatible TCP extension that is enabled by default on recent Linux distributions (Debian, Ubuntu, Redhat, ...). Multipath TCP is included in the Linux kernel since version 5.6 [3]. To use it on Linux, an application must explicitly enable it when creating the socket. No need to change anything else in the application. Adding the possibility to create MPTCP sockets would thus be a really fine addition to httpd, by allowing clients to make use of their different interfaces. This patch introduces the possibility to listen with MPTCP sockets. Note however that these changes are only available on Linux, as IPPROTO_MPTCP is Linux specific for the time being. To do so, we extended the Listen directive to include a "multipathtcp" option, allowing to create MPTCP sockets instead of regular TCP ones: Listen 80 options=multipathtcp We then store this information in flags for the listen directive and create sockets appropriately according to this value. Link: https://www.rfc-editor.org/rfc/rfc8684.html [1] Link: https://www.tessares.net/apples-mptcp-story-so-far/ [2] Link: https://www.mptcp.dev [3]
We normally bump MMN minor for |
Yes correct. |
No description provided.