Qt Contributors Summit 2019 - Qt 6 Network Overview

From Qt Wiki
Revision as of 12:20, 25 November 2019 by Timur Pocheptsov (talk | contribs) (Section about X509 API.)
Jump to navigation Jump to search


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, now superseded by HTTP/2.

Clean up in QSsl

  • Got rid of a stale OpenSSL backend - only 1.1 and following will be supported
  • Completely remove all the code related to (previously deprecated 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)
  • 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 (apparently not in Qt 6, due to amount of work/changes needed)

  • 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.

QNetworkAccessmanager

  • Change default redirect policies (WIP)
  • Enable HSTS by default (this would require re-thinking the current HSTS store)

Removing bearer management

  • There has been complaints about it (crashes, high CPU load - depends on a platform)
  • Radio interfaces as bearer are not best option
  • Bearer management is a legacy from S60

Proposal:

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

Connections cache in QNetworkAccessManager (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 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 QNAM and return error). 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

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).

Retrieved from "https://wiki.qt.io/index.php?title=Qt_Contributors_Summit_2019_-_Qt_6_Network_Overview&oldid=36516"