Details
-
Task
-
Resolution: Done
-
P2: Important
-
None
-
None
-
3d5d8b6c4ff08806934a07df77f9387edc4243df
Description
Introduction
https://datatracker.ietf.org/doc/draft-wing-v6ops-happy-eyeballs-ipv6/?include_text=1 suggests to try IPv4 and IPv6 at nearly the same time and take "whatever works", e.g. whichever connection connects first. There is an algorithm specified there that delays DNS lookups and "learns" which address family to prefer.
We can dumb this down and try the following first.
Assumption
Most relevant in short/mid term is QNetworkAccessManager, the HTTP stack of Qt.
The Q*Socket classes are more the low level network classes of Qt, we can for now assume the user does the proper thing there himself for now.
Current scenario
Per host:port QNetworkAccessManager has a QHttpNetworkConnection object.
Each QHttpNetworkConnection has multiple QHttpNetworkConnectionChannel.
Each QHttpNetworkConnectionChannel has one Q*Socket.
QHostInfo is used by this Q*Socket to do the lookup.
Proposal (simplified)
Do QHostInfo lookup inside QHttpNetworkConnection
When a request needs to be sent, connect 2 QHttpNetworkConnectionChannel, one with the first IPv4 in the DNS result list, one with the first IPv6 in the result list.
(If a connection fails try next IP)
Whichever one is connected first gets the HTTP request sent down.
The other socket will either not connect (e.g. in IPv4 only or IPv6 only case) or also connect (in that case we disconnect it since mixing IPv4 and IPv6 will lead to problems with some websites).
Result
Whatever gets through the actual network path will be connected and HTTP will be sent there.
Attachments
Issue Links
- depends on
-
QTBUG-17084 QNAM HTTP: Only assign request to socket after being connected()/encrypted()
- Closed
- is required for
-
QTBUG-17079 QTcpSocket IPv4/6 connect time optimization
- Reported
- resulted in
-
QTBUG-36890 Not all QNetworkAccessManager::get() calls trigger an error when they should
- Closed