Qt Contributors Summit 2019 - Qt 6 Network Overview
- 1 Qt Network team’s plan of work for Qt 6
- 1.1 QNetworkAccessManager - protocol removal
- 1.2 Clean up in QSsl
- 1.3 New TLS backend
- 1.4 New possible features and improvements in QSsl
- 1.5 A better design for QSslSocket
- 1.6 QNetworkAccessManager's defaults
- 1.7 Removing bearer management
- 1.8 Connections cache in QNetworkAccessManager
- 1.9 Proposal to move WebSocket module to QtNetwork
- 1.10 Removing QFTP backend in QNetworkAccessManager
- 1.11 Certificate management/X509
- 1.12 QUIC and HTTP3
- 1.13 QIODevice and zero copy
- 1.14 Network test server
Qt Network team’s plan of work for Qt 6
QTBUG-75638 is the parent item to track
QNetworkAccessManager - protocol removal
- SPDY was removed and now it is superseded by HTTP/2.
Clean up in QSsl
- We got rid of a stale OpenSSL backend - only 1.1 and following will be supported
- Completely removing all the code related to (previously disabled in 5.13) SSL v2 and SSL v3 (WIP)
New TLS backend
A new TLS back-end was contributed recently, using mbedTLS. We will get it in Qt 6 most probably, but requires quite some work (not in a „ready“ shape yet)
New possible features and improvements in QSsl
- We want to avoid temporary buffers, especially in OpenSSL case (would require something similar to what QDtlsOpenssl does). Needs research/benchmarking.
- Trying to make handshake less rough, allowing the underlying TLS library to send proper alert messages, QTBUG-68419 (WIP for OpenSSL, more research needed for other backends)
- New API needed to enable work with session tickets on a server side (where we allegedly create quite some number of QSslSockets for incoming connections)
A better design for QSslSocket
It's QTcpSocket (a subclass of), which also has a 'plainSocket' (which is QTcpSocket), would be nice to make things straighter. Could be similar to QDtls, which is not QUdpSocket
at all, but works with QUdpSocket. Apparently not in Qt 6, due to amount of work/changes needed
Change default redirect policies (WIP). Enable HSTS by default (this requires re-thinking the current HSTS store)
Removing bearer management
There has been complaints about it: crashes, high CPU load, etc (different problems on all platforms). Bearer management is a legacy from S60. We have network
interface classes that can be used as a replacement/workaround for a part of these tasks requiring bearer. We also have connection monitor class (ATM for Darwin, Windows) who's intent is to make QNAM more
reliable and who can solve other tasks that previously required the bearer manager. Proposal:
- Remove bearer management
- Add requested features afterwards
- WIP: Connection Monitoring (as it's done (?) for Darwin and Windows)
Connections cache in QNetworkAccessManager
We have this cache in QHttpNetworkConnection. Overly simplistic and optimistic, as a result in case a cached connection (aka socket) becomes defunct (you switched off your wifi), QNAM may later try to
re-use this connection/socket. This may further result in requests never finishing or taking a significant time before an error noted. So this cache needs something like Connection Monitor.
Proposal to move WebSocket module to QtNetwork
Not sure why if this module should be in QtNetwork. Currently the module is not actively maintained (so having it in QtNetwork probably would make things better). For Qt6, moving
it into QtNetwork or not, needs to be refactored (the JIRA task will be linked later).
Removing QFTP backend in QNetworkAccessManager
Our implementation is outdated and probably incomplete. The code is quite old (was a public API in Qt 4?) There are still public users, but how many? Proposal: Disable it in Qt 6.0
(testing the scheme of a network request in QNAM). Check how many complaints we have, next if this amount is limited (as expected) remove QFtp in Qt > 6.0 completely.
More and more projects need to do certificate management etc . For example, KNX, OpcUA, CoAP (?). Can we find an abstraction for this? And potentially move that into a separate module and have
Having an API for certificate management is a lot of work, but might be better than duplicating
less work again and again (as it's happening now).
QUIC and HTTP3
Conclusion: wait for it to stabilise, but keep on the radar.
QIODevice and zero copy
The discussion of this topic needs to move to QtCS core session as no time left.
Network test server
- Current test-server is probably not the best option
- Use docker images
- Windows is not ready for nested virtualisation
- However, might be worth considering run the network test containers on one machine and then have the Windows VMs connect to this one.