Qt Contributors Summit 2019 - Qt 6 Network Overview

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, {[Issue|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 the amount of work/changes needed

QNetworkAccessManager's defaults

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. We also have connection monitor class (ATM forDarwin, 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 in QNetworkRequest in QNAM). Check how many complaints we have, next if this amount is limited (as expected) remove QFtp in Qt > 6.0 completely.

Certificate management/X509

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

QtNetwork use it? Example QTBUG-76499, QTBUG-76876 (note: not sure why the latter one was mentioned, it is more about Raw Public Key, supported ATM only by GnuTLS and TinyDTLS).

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

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.