Qt Contributors Summit 2019 - Qt 6 Network Overview

Qt Network team’s plan of work for Qt 6

https://bugreports.qt.io/browse/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 (WIP for OpenSSL, more research needed for other backends)
• New API needed to enable work with session tickets on a server side (somehow provide access to STEK?)

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, we also have connection monitor (Darwin, Windows) who's intent was to make QNAM more

reliable. Proposal:

• Remove bearer management
• Add requested features afterwards
• WIP: Connection Monitoring (as it's done (?) for Darwin and Windows)

Connections cache in QNetworkAccessManager

Cache we have in QHttpNetworkConnection. Overly simplistic and optimistic, as a result in case a cached connection (aka socket) becomes defunct, QNAM may later try to

re-use this connection/socket. This may result in requests never finishing or taking a significant time before an error noted. So this cache needs something like Connection Monitor.

Also (was not mentioned during the session, but just to make the picture here complete) - we now have an API in QNAM which can set the timeout for requests.

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 significantly refactored (the JIRA task will be linked later).

Removing QFTP backend in QNetworkAccessManager

Out 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 6.0

(check the scheme in QNetworkRequest in QNAM and return an error). 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

Qt Network use it? Example QTBUG-76499, QTBUG-76876 (this one is about Raw Public Key, supported atm only by GnuTLS and TinyDTLS). It's a lot of work, but might be better than duplicating

less work again and again (as it's happening now).

QUIC and HTTP3

Short discussion with a 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

How to test

• Current testserver is probably not the best option
• Use docker images
• Windows is not ready for nested virtualization
• However, might be worth considering run the network test containers on one machine and then have the Windows VMs connect to this one.