Qt Contributors Summit 2019 - Qt 6 Network Overview: Difference between revisions
No edit summary |
(Formatting, cleanup.) |
||
| (14 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:QtCS2019]] | [[Category:QtCS2019]] | ||
= Qt Network team’s plan of work for Qt 6 = | |||
{{Issue|QTBUG-75638}} is the parent item to track | |||
QNetworkAccessManager - protocol removal | == QNetworkAccessManager - protocol removal == | ||
* SPDY was removed | * '''SPDY''' was removed and now it is superseded by '''HTTP/2'''. | ||
Clean up in QSsl | == Clean up in QSsl == | ||
* | * We got rid of a stale '''OpenSSL''' backend - only '''1.1''' and following will be supported | ||
* Completely | * 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) | |||
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, {{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 ( | * 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 | == 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 | |||
== QNetworkAccessManager's defaults == | |||
Change '''default redirect policies''' (WIP). Enable '''HSTS''' by default (this requires re-thinking the current '''HSTS store''') | |||
Removing bearer management | == 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: | Proposal: | ||
* Remove bearer management | * Remove bearer management | ||
| Line 40: | Line 43: | ||
* 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 | == Connections cache in QNetworkAccessManager == | ||
Proposal to move WebSocket | 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. | |||
== 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 {{Issue|QTBUG-76499}}, {{Issue|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 == | |||
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. | |||
Latest revision as of 13:17, 25 November 2019
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
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 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.
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
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.