Qt Contributors Summit 2019 - Qt 6 Network Overview: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Section about X509 API.)
No edit summary
Line 1: Line 1:
[[Category:QtCS2019]]
[[Category:QtCS2019]]


=== Qt Network team’s plan of work for Qt 6 ===
= Qt Network team’s plan of work for Qt 6 =


https://bugreports.qt.io/browse/QTBUG-75638 is the parent item to track
https://bugreports.qt.io/browse/QTBUG-75638 is the parent item to track


QNetworkAccessManager - protocol removal
== QNetworkAccessManager - protocol removal ==
* SPDY was removed, now superseded by HTTP/2.
* SPDY was removed and now it is superseded by HTTP/2.


Clean up in QSsl
== Clean up in QSsl ==
* Got rid of a stale OpenSSL backend - only 1.1 and following will be supported
* We 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)
* Completely removing all the code related to (previously disabled in 5.13) SSL v2 and SSL v3 (WIP)


New TLS backend
== 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)
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
== 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)
* 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)
* 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?)
* 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)
== 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.  
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.
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
== QNetworkAccessmanager's defaults ==
 
Change default redirect policies (WIP). Enable HSTS by default (this requires re-thinking the current HSTS store)
* 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


== 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:
Proposal:
* Remove bearer management
* Remove bearer management
Line 40: Line 37:
* WIP: Connection Monitoring  (as it's done (?) for Darwin and Windows)
* WIP: Connection Monitoring  (as it's done (?) for Darwin and Windows)


Connections cache in QNetworkAccessManager (in QHttpNetworkConnection).
== Connections cache in QNetworkAccessManager ==
 
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
Cache we have in QHttpNetworkConnection. Overly simplistic and optimistic, as a result in case a cached connection (aka socket) becomes defunct,
taking a significant time before an error noted. So this cache needs something like Connection Monitor.
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.  
Also (was not mentioned during the session, but just to make the picture  
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.


here complete) - we now have
== Proposal to move WebSocket module to QtNetwork ==
an API in QNAM which can set the timeout for requests.
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).


Proposal to move WebSocket module to QtNetwork
== Removing QFTP backend in QNetworkAccessManager ==
* Not sure why if this module should be in QtNetwork
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?
* 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.
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.


== 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
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


Line 68: Line 58:


less work again and again (as it's happening now).
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

Revision as of 12:31, 25 November 2019


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

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