Qt是一個跨平臺框架，通常用作圖形工具包，它不僅創建CLI應用程序中非常有用。而且它也可以在三種主要的臺式機操作系統以及移動操作系統（如Symbian，Nokia Belle，Meego Harmattan，MeeGo或BB10）以及嵌入式設備，Android（Necessitas）和iOS的端口上運行。現在我們為你提供了免費的試用版。趕快點擊下載Qt最新試用版吧>>

點擊獲取更多文章教程

在本文中，我們想告訴您Qt Network模塊在Qt 6中的一些最新更新和更改。以及一些潛在的發展

QNetworkAccessBackend是一個抽象基類，用于與我們的緩存，文件和ftp后端接口。我們已經在Qt中使用QNetworkAccessBackend已有一段時間了，但是不可能以任何合理的方式在Qt網絡外部使用。對于Qt 6，我們計劃將ftp后端移出Qt Network，并作為插件單獨分發。為此，我們使QNetworkAccessBackend在外部使用起來更加友好，并使QNetworkAccessManager能夠在運行時加載這些插件。與我們的某些其他插件接口一樣，它沒有Qt本身具有的嚴格的向后兼容性保證，并且需要鏈接到QtNetworkPrivate才能使用它。

我們希望能夠專門化各種后端的行為。例如，非網絡后端不需要我們為目標URL準備代理列表。為此，我們添加了三個不同的枚舉，每個枚舉中都有一些值：

• TargetType
• 安全功能
• IO功能

其中，僅需要“ TargetType”指定后端支持的目標是聯網的還是本地的。

如果某些功能無法使用，則某些功能可能無法啟用。一個這樣的例子是IO功能“ZeroCopy”，它啟用函數readPointer（）和advanceReadPointer（）。如果未啟用，則不會調用這兩個函數。擁有這個特性系統的主要思想是我們可以在不破壞任何現有代碼的情況下進行這些改進。新代碼必須選擇使用新功能。不過，重申一下：我們不能保證網絡訪問后端插件與使用Qt的應用程序具有相同的向后兼容性。

要實現網絡訪問后端插件，您需要實現一個從QNetworkAccessBackendFactory繼承的類。如果支持所請求的方案，則此類將完成創建后端的工作。您還需要創建一個從QNetworkAccessBackend繼承的類，并覆蓋所有純虛函數以及'read（）'或'readPointer（）'和'advanceReadPointer（）'（如果您的類支持'ZeroCopy'功能） 。對于現有用途，QNetworkAccessCacheBackend和QNetworkAccessFileBackend均已更新為使用新接口，盡管它們直接編譯為Qt而不是作為插件分發。

在Qt 6中，我們放棄了SPDY支持。SPDY是具有開放規范的實驗性協議，主要由Google開發。SPDY成為HTTP / 2協議的前身和原型。

在維持與HTTP / 1.1的兼容性（例如與方法，狀態代碼，URI和大多數標頭字段）的兼容性的同時，HTTP / 2還添加了：

• HTTP標頭的數據壓縮
• 通過單個TCP連接多路復用多個請求
• HTTP / 2服務器推送
• 允許客戶端和服務器選擇HTTP / 2或HTTP / 1.1的協商機制

在Qt 6之前，必須通過設置以下屬性之一來手動啟用HTTP / 2協議：

• QNetworkRequest :: Http2AllowedAttribute
• QNetworkRequest :: Http2DirectAttribute，

例如：

request.setAttribute(QNetworkRequest::Http2AllowedAttribute, true);

對于“ Http2AllowedAttribute”，QNetworkAccessManager對“ https”方案使用應用程序層協議協商，對“ http”方案使用協議升級頭“ h2c”。如果您事先知道服務器以所謂的“直接”模式支持HTTP / 2，而無需協議協商，則第二個屬性很有用。

在Qt 6中，默認情況下啟用HTTP / 2支持：這意味著屬性'Http2AllowedAttribute'設置為'true'。如果無法協商HTTP / 2，則QNetworkAccessManager將回退到HTTP / 1.1。如果您的應用程序只能使用HTTP / 1.1，則可以為新的網絡請求將屬性'Http2AllowedAttribute'設置為'false'：

request.setAttribute(QNetworkRequest::Http2AllowedAttribute, false);

此“默認啟用”規則有一個例外：

  QNetworkAccessManager::connectToHostEncrypted(host, port, configuration);  

使用此功能，應用程序可以預連接到服務器，而無需發送任何請求。如果我們要在這樣的連接上啟用HTTP / 2，則該連接對于希望使用HTTP / 1.1并通過使用請求屬性禁用HTTP / 2的應用程序將毫無用處。通過在“配置”參數中設置所需的協議列表，可以顯式啟用HTTP / 2，例如：

auto tlsConfig = QSslConfiguration::defaultConfiguration();
tlsConfig.setAllowedNextProtocols({QSslConfiguration::ALPNProtocolHTTP2});
manager.connectToHostEncrypted(host, port, tlsConfig);

默認重定向策略已更改

另一個可能影響您的網絡代碼的更改是QNetworkAccessManager在Qt 6中使用的默認重定向策略。該策略API最初是在Qt 5中引入的，其思想是在Qt 6中切換為默認的自動重定向處理。

QNetworkAccessManager支持幾種重定向策略，由枚舉QNetworkRequest :: RedirectPolicy描述。這些政策是：

• ManualRedirectPolicy
• NoLessSafeRedirectPolicy
• SameOriginRedirectPolicy
• UserVerifiedRedirectPolicy

從Qt 6開始，QNetworkAccessManager發出請求時將使用的默認重定向策略是QNetworkRequest :: NoLessSafeRedirectPolicy（該策略禁止從“ https”重定向到“ http”）。

如果您有一個應用程序，該應用程序依賴于連接到QNetworkReply :: redirected（）的插槽來處理重定向，則必須使用Qt 6將策略設置為QNetworkRequest :: ManualRedirectPolicy：

req.setAttribute(RedirectPolicyAttribute, ManualRedirectPolicy);

承載管理已刪除

承載管理是對過去支持漫游和管理某些設備上的連接所需的機器的名稱。它還可以選擇連接到internet時使用的設備網絡接口。今天，這種情況已不再，因為操作系統通常會自行處理漫游，并會自動選擇最佳的網絡接口來發送數據，通常不會為應用程序提供影響這些選擇的方法（或不方便的方式）。
盡管QNetworkManager提供了api來選擇要使用的接口或配置正在使用的接口，但這一新的現實意味著當前沒有支持的平臺為Qt提供可靠的方式來完成請求。在隨后的Wifi請求被觸發后，可能會導致網絡中的各種Qt請求保持高流量，從而導致網絡在短時間內保持高流量。
考慮到新的現實也使得承載管理在很大程度上是多余的，我們決定是時候讓Qt網絡的這一部分退役了。
一個仍然有用的特性是能夠檢查連接并獲得連接更改的通知。到目前為止，在qt6.0中還沒有找到替代品，盡管我們已經收集了一些用例，并希望在接下來的小版本中有一個替代品來替代這個功能。如果您有特定的用例，您希望看到涵蓋的內容，或者您想跟蹤這個任務的進度，那么請轉到QTBUG-86966。

QSslSocket

在Qt 6中，QSslSocket接收了一個附加的API，提供有關作為TLS協議的一部分接收或發送的警報消息的信息。：以下面為例：

• QSsl::AlertLevel describes how serious problem is
• QSsl::AlertType indicates the type of problem

QSslSocket中有兩個新信號：

• QSslSocket :: alertSent（）
• QSslSocket :: alertReceived（）

如果可能，這些信號還會報告問題的文本描述（如果由TLS庫提供）。

與TLS握手相關的另一項更改是能夠在握手仍在進行時盡早報告握手期間遇到的錯誤的功能。這些錯誤直接從驗證回調中報告。QSslConfiguration有一個新的getter和setter：

• bool QSslConfiguration :: handshakeMustInterruptOnError（）const;
• void QSslConfiguration :: setHandshakeMustInterruptOnError（）const;

QSslSocket有一個新信號：

• void handshakeInterruptedOnError（）;

和一個錯誤的函數必須忽略：

• void continueInterruptedHandshake（）;

如果不忽略錯誤，則底層TLS庫將向對等方發送警報消息。

對于使用QNetworkAccessManager的應用程序，此API有點底層，并且沒有太大的意義。但是，如果直接使用QSslSocket，則對于調試目的或實現某些錯誤或警告處理邏輯時，它可能非常方便。目前，此更改適用于我們的OpenSSL后端；我們使用的其他TLS庫沒有必需的API或未提供我們所需的完整信息。

好吧，這一部分并不是關于qt6已經具備的。這也是關于未來可能的發展。到目前為止，qt6支持TLS協議的最新版本，即1.3，這要歸功于我們的OpenSSL后端（qt5也支持tls1.3）。我們正致力于在Schannel后端啟用tls1.3。不幸的是，SecureTransport被Apple棄用，沒有可用的TLS庫作為替代，只有一些構建在BoringSSL之上的更高級別的框架（請注意這一點的諷刺?。?。這意味著，對于我們的達爾文用戶，我們將在未來提供另一種選擇。以QNetworkAccessManager為例，在蘋果的NSUrlSession等類之上實現的一個新的QNetworkAccessBackend非常方便（包括tls1.3和實驗性的HTTP/3支持）。

如果這篇文章沒能滿足你的需求、點擊獲取更多文章教程！現在立刻下載Qt免費試用吧！更多Qt類開發工具QtitanRibbon、QtitanChart、QtitanNavigation、QtitanDocking、QtitanDataGrid在線訂購現直降1000元，歡迎咨詢慧都獲取更多優惠>>