翻譯|行業(yè)資訊|編輯:鮑佳佳|2020-10-09 11:59:00.847|閱讀 470 次
概述:在本文中,我們想告訴您Qt Network模塊在Qt 6中的一些最新更新和更改。以及一些潛在的發(fā)展。相信通過(guò)本文的閱讀一定會(huì)對(duì)新版本以及Qt有進(jìn)一步的認(rèn)識(shí)!
# 界面/圖表報(bào)表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
Qt是一個(gè)跨平臺(tái)框架,通常用作圖形工具包,它不僅創(chuàng)建CLI應(yīng)用程序中非常有用。而且它也可以在三種主要的臺(tái)式機(jī)操作系統(tǒng)以及移動(dòng)操作系統(tǒng)(如Symbian,Nokia Belle,Meego Harmattan,MeeGo或BB10)以及嵌入式設(shè)備,Android(Necessitas)和iOS的端口上運(yùn)行。現(xiàn)在我們?yōu)槟闾峁┝嗣赓M(fèi)的試用版。趕快點(diǎn)擊下載Qt最新試用版吧>>
【Qtitan組件集】
在本文中,我們想告訴您Qt Network模塊在Qt 6中的一些最新更新和更改。以及一些潛在的發(fā)展
QNetworkAccessBackendQNetworkAccessBackend是一個(gè)抽象基類,用于與我們的緩存,文件和ftp后端接口。我們已經(jīng)在Qt中使用QNetworkAccessBackend已有一段時(shí)間了,但是不可能以任何合理的方式在Qt網(wǎng)絡(luò)外部使用。對(duì)于Qt 6,我們計(jì)劃將ftp后端移出Qt Network,并作為插件單獨(dú)分發(fā)。為此,我們使QNetworkAccessBackend在外部使用起來(lái)更加友好,并使QNetworkAccessManager能夠在運(yùn)行時(shí)加載這些插件。與我們的某些其他插件接口一樣,它沒(méi)有Qt本身具有的嚴(yán)格的向后兼容性保證,并且需要鏈接到QtNetworkPrivate才能使用它。
我們希望能夠?qū)iT化各種后端的行為。例如,非網(wǎng)絡(luò)后端不需要我們?yōu)槟繕?biāo)URL準(zhǔn)備代理列表。為此,我們添加了三個(gè)不同的枚舉,每個(gè)枚舉中都有一些值:
其中,僅需要“ TargetType”指定后端支持的目標(biāo)是聯(lián)網(wǎng)的還是本地的。
如果某些功能無(wú)法使用,則某些功能可能無(wú)法啟用。一個(gè)這樣的例子是IO功能“ZeroCopy”,它啟用函數(shù)readPointer()和advanceReadPointer()。如果未啟用,則不會(huì)調(diào)用這兩個(gè)函數(shù)。擁有這個(gè)特性系統(tǒng)的主要思想是我們可以在不破壞任何現(xiàn)有代碼的情況下進(jìn)行這些改進(jìn)。新代碼必須選擇使用新功能。不過(guò),重申一下:我們不能保證網(wǎng)絡(luò)訪問(wèn)后端插件與使用Qt的應(yīng)用程序具有相同的向后兼容性。
要實(shí)現(xiàn)網(wǎng)絡(luò)訪問(wèn)后端插件,您需要實(shí)現(xiàn)一個(gè)從QNetworkAccessBackendFactory繼承的類。如果支持所請(qǐng)求的方案,則此類將完成創(chuàng)建后端的工作。您還需要?jiǎng)?chuàng)建一個(gè)從QNetworkAccessBackend繼承的類,并覆蓋所有純虛函數(shù)以及'read()'或'readPointer()'和'advanceReadPointer()'(如果您的類支持'ZeroCopy'功能) 。對(duì)于現(xiàn)有用途,QNetworkAccessCacheBackend和QNetworkAccessFileBackend均已更新為使用新接口,盡管它們直接編譯為Qt而不是作為插件分發(fā)。
通訊協(xié)定在Qt 6中,我們放棄了SPDY支持。SPDY是具有開(kāi)放規(guī)范的實(shí)驗(yàn)性協(xié)議,主要由Google開(kāi)發(fā)。SPDY成為HTTP / 2協(xié)議的前身和原型。
在維持與HTTP / 1.1的兼容性(例如與方法,狀態(tài)代碼,URI和大多數(shù)標(biāo)頭字段)的兼容性的同時(shí),HTTP / 2還添加了:
在Qt 6之前,必須通過(guò)設(shè)置以下屬性之一來(lái)手動(dòng)啟用HTTP / 2協(xié)議:
例如:
request.setAttribute(QNetworkRequest::Http2AllowedAttribute, true);
對(duì)于“ Http2AllowedAttribute”,QNetworkAccessManager對(duì)“ https”方案使用應(yīng)用程序?qū)訁f(xié)議協(xié)商,對(duì)“ http”方案使用協(xié)議升級(jí)頭“ h2c”。如果您事先知道服務(wù)器以所謂的“直接”模式支持HTTP / 2,而無(wú)需協(xié)議協(xié)商,則第二個(gè)屬性很有用。
在Qt 6中,默認(rèn)情況下啟用HTTP / 2支持:這意味著屬性'Http2AllowedAttribute'設(shè)置為'true'。如果無(wú)法協(xié)商HTTP / 2,則QNetworkAccessManager將回退到HTTP / 1.1。如果您的應(yīng)用程序只能使用HTTP / 1.1,則可以為新的網(wǎng)絡(luò)請(qǐng)求將屬性'Http2AllowedAttribute'設(shè)置為'false':
request.setAttribute(QNetworkRequest::Http2AllowedAttribute, false);
此“默認(rèn)啟用”規(guī)則有一個(gè)例外:
QNetworkAccessManager::connectToHostEncrypted(host, port, configuration);
使用此功能,應(yīng)用程序可以預(yù)連接到服務(wù)器,而無(wú)需發(fā)送任何請(qǐng)求。如果我們要在這樣的連接上啟用HTTP / 2,則該連接對(duì)于希望使用HTTP / 1.1并通過(guò)使用請(qǐng)求屬性禁用HTTP / 2的應(yīng)用程序?qū)⒑翢o(wú)用處。通過(guò)在“配置”參數(shù)中設(shè)置所需的協(xié)議列表,可以顯式啟用HTTP / 2,例如:
auto tlsConfig = QSslConfiguration::defaultConfiguration(); tlsConfig.setAllowedNextProtocols({QSslConfiguration::ALPNProtocolHTTP2}); manager.connectToHostEncrypted(host, port, tlsConfig);
默認(rèn)重定向策略已更改
另一個(gè)可能影響您的網(wǎng)絡(luò)代碼的更改是QNetworkAccessManager在Qt 6中使用的默認(rèn)重定向策略。該策略API最初是在Qt 5中引入的,其思想是在Qt 6中切換為默認(rèn)的自動(dòng)重定向處理。
QNetworkAccessManager支持幾種重定向策略,由枚舉QNetworkRequest :: RedirectPolicy描述。這些政策是:
從Qt 6開(kāi)始,QNetworkAccessManager發(fā)出請(qǐng)求時(shí)將使用的默認(rèn)重定向策略是QNetworkRequest :: NoLessSafeRedirectPolicy(該策略禁止從“ https”重定向到“ http”)。
如果您有一個(gè)應(yīng)用程序,該應(yīng)用程序依賴于連接到QNetworkReply :: redirected()的插槽來(lái)處理重定向,則必須使用Qt 6將策略設(shè)置為QNetworkRequest :: ManualRedirectPolicy:
req.setAttribute(RedirectPolicyAttribute, ManualRedirectPolicy);
承載管理已刪除
承載管理是對(duì)過(guò)去支持漫游和管理某些設(shè)備上的連接所需的機(jī)器的名稱。它還可以選擇連接到internet時(shí)使用的設(shè)備網(wǎng)絡(luò)接口。今天,這種情況已不再,因?yàn)椴僮飨到y(tǒng)通常會(huì)自行處理漫游,并會(huì)自動(dòng)選擇最佳的網(wǎng)絡(luò)接口來(lái)發(fā)送數(shù)據(jù),通常不會(huì)為應(yīng)用程序提供影響這些選擇的方法(或不方便的方式)。
盡管QNetworkManager提供了api來(lái)選擇要使用的接口或配置正在使用的接口,但這一新的現(xiàn)實(shí)意味著當(dāng)前沒(méi)有支持的平臺(tái)為Qt提供可靠的方式來(lái)完成請(qǐng)求。在隨后的Wifi請(qǐng)求被觸發(fā)后,可能會(huì)導(dǎo)致網(wǎng)絡(luò)中的各種Qt請(qǐng)求保持高流量,從而導(dǎo)致網(wǎng)絡(luò)在短時(shí)間內(nèi)保持高流量。
考慮到新的現(xiàn)實(shí)也使得承載管理在很大程度上是多余的,我們決定是時(shí)候讓Qt網(wǎng)絡(luò)的這一部分退役了。
一個(gè)仍然有用的特性是能夠檢查連接并獲得連接更改的通知。到目前為止,在qt6.0中還沒(méi)有找到替代品,盡管我們已經(jīng)收集了一些用例,并希望在接下來(lái)的小版本中有一個(gè)替代品來(lái)替代這個(gè)功能。如果您有特定的用例,您希望看到涵蓋的內(nèi)容,或者您想跟蹤這個(gè)任務(wù)的進(jìn)度,那么請(qǐng)轉(zhuǎn)到QTBUG-86966。
QSslSocket
在Qt 6中,QSslSocket接收了一個(gè)附加的API,提供有關(guān)作為TLS協(xié)議的一部分接收或發(fā)送的警報(bào)消息的信息。:以下面為例:
QSslSocket中有兩個(gè)新信號(hào):
如果可能,這些信號(hào)還會(huì)報(bào)告問(wèn)題的文本描述(如果由TLS庫(kù)提供)。
與TLS握手相關(guān)的另一項(xiàng)更改是能夠在握手仍在進(jìn)行時(shí)盡早報(bào)告握手期間遇到的錯(cuò)誤的功能。這些錯(cuò)誤直接從驗(yàn)證回調(diào)中報(bào)告。QSslConfiguration有一個(gè)新的getter和setter:
QSslSocket有一個(gè)新信號(hào):
和一個(gè)錯(cuò)誤的函數(shù)必須忽略:
如果不忽略錯(cuò)誤,則底層TLS庫(kù)將向?qū)Φ确桨l(fā)送警報(bào)消息。
對(duì)于使用QNetworkAccessManager的應(yīng)用程序,此API有點(diǎn)底層,并且沒(méi)有太大的意義。但是,如果直接使用QSslSocket,則對(duì)于調(diào)試目的或?qū)崿F(xiàn)某些錯(cuò)誤或警告處理邏輯時(shí),它可能非常方便。目前,此更改適用于我們的OpenSSL后端;我們使用的其他TLS庫(kù)沒(méi)有必需的API或未提供我們所需的完整信息。
TLS 1.3及更高版本好吧,這一部分并不是關(guān)于qt6已經(jīng)具備的。這也是關(guān)于未來(lái)可能的發(fā)展。到目前為止,qt6支持TLS協(xié)議的最新版本,即1.3,這要?dú)w功于我們的OpenSSL后端(qt5也支持tls1.3)。我們正致力于在Schannel后端啟用tls1.3。不幸的是,SecureTransport被Apple棄用,沒(méi)有可用的TLS庫(kù)作為替代,只有一些構(gòu)建在BoringSSL之上的更高級(jí)別的框架(請(qǐng)注意這一點(diǎn)的諷刺!)。這意味著,對(duì)于我們的達(dá)爾文用戶,我們將在未來(lái)提供另一種選擇。以QNetworkAccessManager為例,在蘋果的NSUrlSession等類之上實(shí)現(xiàn)的一個(gè)新的QNetworkAccessBackend非常方便(包括tls1.3和實(shí)驗(yàn)性的HTTP/3支持)。
如果這篇文章沒(méi)能滿足你的需求、點(diǎn)擊獲取更多文章教程!現(xiàn)在立刻下載Qt免費(fèi)試用吧!更多Qt類開(kāi)發(fā)工具QtitanRibbon、QtitanChart、QtitanNavigation、QtitanDocking、QtitanDataGrid在線訂購(gòu)現(xiàn)直降1000元,歡迎咨詢慧都獲取更多優(yōu)惠>>
本站文章除注明轉(zhuǎn)載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉(zhuǎn)載,但請(qǐng)務(wù)必注明出處、不得修改原文相關(guān)鏈接,如果存在內(nèi)容上的異議請(qǐng)郵件反饋至chenjj@fc6vip.cn
文章轉(zhuǎn)載自: