Programmation réseau avec Qt
Le module « Qt Network » propose des classes permettant d'écrire des clients et des serveurs TCP/IP. Il offre des classes de bas niveau telles que « QTcpSocket », « QTcpServer » et « QUdpSocket », qui représentent des concepts réseau de bas niveau, ainsi que des classes de haut niveau telles que « QNetworkRequest », « QNetworkReply » et « QNetworkAccessManager » pour effectuer des opérations réseau à l'aide de protocoles courants.
Qt Network fournit également une API pour le protocole TLS (Transport Layer Security) et des fonctions de sécurité utilisant un backend TLS natif, la boîte à outils OpenSSL ou tout plugin TLS approprié. Reportez-vous aux classes SSL (Secure Sockets Layer) pour plus d'informations.
Classes Qt pour la programmation réseau
La Qt Network C++ Classes page contient une liste des classes C++ disponibles dans « Qt Network ».
Opérations réseau de haut niveau pour HTTP
L’API d’accès au réseau est un ensemble de classes permettant d’effectuer des opérations réseau courantes. L’API fournit une couche d’abstraction par rapport aux opérations et protocoles spécifiques utilisés (par exemple, la récupération et l’envoi de données via HTTP), et n’expose que les classes, fonctions et signaux correspondant à des concepts généraux ou de haut niveau.
Les requêtes réseau sont représentées par la classe ` QNetworkRequest `, qui sert également de conteneur général pour les informations associées à une requête, telles que les informations d’en-tête et le chiffrement utilisé. L’URL spécifiée lors de la création d’un objet `Request` détermine le protocole utilisé pour la requête. Actuellement, les URL HTTP et celles des fichiers locaux sont prises en charge pour le téléchargement et l’envoi de fichiers.
La coordination des opérations réseau est assurée par la classe ` QNetworkAccessManager `. Une fois qu'une requête a été créée, cette classe est utilisée pour la transmettre et émettre des signaux afin de rendre compte de sa progression. Le gestionnaire coordonne également l'utilisation de ` cookies ` pour stocker des données sur le client, les requêtes d'authentification et l'utilisation de proxys.
Les réponses aux requêtes réseau sont représentées par la classe ` QNetworkReply ` ; celles-ci sont créées par ` QNetworkAccessManager ` lorsqu’une requête est transmise. Les signaux fournis par ` QNetworkReply ` peuvent être utilisés pour surveiller chaque réponse individuellement ; les développeurs peuvent également choisir d’utiliser à cette fin les signaux du gestionnaire et de ne pas conserver de références aux réponses. Comme ` QNetworkReply ` est une sous-classe de ` QIODevice`, les réponses peuvent être traitées de manière synchrone ou asynchrone, c’est-à-dire sous forme d’opérations bloquantes ou non bloquantes.
Chaque application ou bibliothèque peut créer une ou plusieurs instances de ` QNetworkAccessManager ` pour gérer les communications réseau.
Utilisation de TCP avec QTcpSocket et QTcpServer
TCP (Transmission Control Protocol) est un protocole réseau de bas niveau utilisé par la plupart des protocoles Internet, notamment HTTP et FTP, pour le transfert de données. Il s'agit d'un protocole de transport fiable, orienté flux et orienté connexion. Il est particulièrement bien adapté à la transmission continue de données.

La classe ` QTcpSocket ` fournit une interface pour TCP. Vous pouvez utiliser ` QTcpSocket ` pour implémenter des protocoles réseau standard tels que POP3, SMTP et NNTP, ainsi que des protocoles personnalisés.
Une connexion TCP doit être établie vers un hôte distant et un port avant que tout transfert de données puisse commencer. Une fois la connexion établie, l’adresse IP et le port du pair sont accessibles via ` QTcpSocket::peerAddress()` et ` QTcpSocket::peerPort()`. À tout moment, le pair peut fermer la connexion, ce qui interrompt immédiatement le transfert de données.
QTcpSocket fonctionne de manière asynchrone et émet des signaux pour signaler les changements d’état et les erreurs, tout comme QNetworkAccessManager. Il s’appuie sur la boucle d’événements pour détecter les données entrantes et pour vider automatiquement les données sortantes. Vous pouvez écrire des données dans le socket à l’aide de QTcpSocket::write(), et lire des données à l’aide de QTcpSocket::read(). QTcpSocket représente deux flux de données indépendants : un pour la lecture et un pour l’écriture.
Comme QTcpSocket hérite de QIODevice, vous pouvez l’utiliser avec QTextStream et QDataStream. Lors de la lecture à partir d’un QTcpSocket, vous devez vous assurer qu’il y a suffisamment de données disponibles en appelant au préalable QTcpSocket::bytesAvailable().
Si vous devez gérer des connexions TCP entrantes (par exemple, dans une application serveur), utilisez la classe QTcpServer. Appelez QTcpServer::listen() pour configurer le serveur, puis connectez-vous au signal QTcpServer::newConnection(), qui est émis une fois pour chaque client qui se connecte. Dans votre slot, appelez QTcpServer::nextPendingConnection() pour accepter la connexion et utilisez le QTcpSocket renvoyé pour communiquer avec le client.
Bien que la plupart de ses fonctions fonctionnent de manière asynchrone, il est possible d’utiliser QTcpSocket de manière synchrone (c’est-à-dire en mode bloquant). Pour obtenir un comportement bloquant, appelez les fonctions waitFor...() d’ QTcpSocket; celles-ci suspendent le thread appelant jusqu’à ce qu’un signal soit émis. Par exemple, après avoir appelé la fonction non bloquante QTcpSocket::connectToHost(), appelez QTcpSocket::waitForConnected() pour bloquer le thread jusqu’à ce que le signal connected() soit émis.
Les sockets synchrones permettent souvent d’obtenir un code dont le flux de contrôle est plus simple. Le principal inconvénient de l’approche waitFor...() réside dans le fait que les événements ne sont pas traités tant qu’une fonction waitFor...() est bloquée. Si elle est utilisée dans le thread de l’interface graphique, cela peut entraîner le gel de l’interface utilisateur de l’application. C'est pourquoi nous vous recommandons d'utiliser les sockets synchrones uniquement dans des threads autres que ceux de l'interface graphique. Lorsqu'il est utilisé de manière synchrone, QTcpSocket ne nécessite pas de boucle d'événements.
Les exemples « Fortune Client » et « Fortune Server » montrent comment utiliser QTcpSocket et QTcpServer pour écrire des applications client-serveur TCP. Voir également « Fortune Client bloquant » pour un exemple d’utilisation d’une fonction QTcpSocket synchrone dans un thread distinct (sans boucle d’événements), et « Fortune Server multithread » pour un exemple de serveur TCP multithread avec un thread par client actif.
Utilisation d’UDP avec QUdpSocket
UDP (User Datagram Protocol) est un protocole léger, non fiable, orienté datagrammes et sans connexion. Il peut être utilisé lorsque la fiabilité n’est pas un critère essentiel. Par exemple, un serveur indiquant l’heure pourrait opter pour UDP. Si un datagramme contenant l’heure est perdu, le client peut simplement envoyer une nouvelle requête.

La classe ` QUdpSocket ` vous permet d’envoyer et de recevoir des datagrammes UDP. Elle hérite de ` QAbstractSocket` et partage donc la majeure partie de l’interface de ` QTcpSocket`. La principale différence réside dans le fait que ` QUdpSocket ` transfère les données sous forme de datagrammes plutôt que sous la forme d’un flux continu de données. En bref, un datagramme est un paquet de données de taille limitée (généralement inférieure à 512 octets), contenant l’adresse IP et le port de l’expéditeur et du destinataire du datagramme, en plus des données transférées.
QUdpSocket prend en charge la diffusion IPv4. La diffusion est souvent utilisée pour mettre en œuvre des protocoles de découverte du réseau, par exemple pour déterminer quel hôte du réseau dispose du plus grand espace libre sur son disque dur. Un hôte diffuse un datagramme sur le réseau que tous les autres hôtes reçoivent. Chaque hôte qui reçoit une requête renvoie alors une réponse à l’expéditeur en indiquant son espace libre actuel sur le disque. L’expéditeur attend d’avoir reçu les réponses de tous les hôtes, puis peut choisir le serveur disposant du plus grand espace libre pour stocker les données. Pour diffuser un datagramme, il suffit de l’envoyer à l’adresse spéciale QHostAddress::Broadcast (255.255.255.255), ou à l’adresse de diffusion de votre réseau local.
QUdpSocket::bindLa fonction `()` prépare le socket à accepter les datagrammes entrants, de la même manière que ` QTcpServer::listen()` pour les serveurs TCP. Dès qu’un ou plusieurs datagrammes arrivent, ` QUdpSocket ` émet le signal ` readyRead()`. Appelez la fonction ` QUdpSocket::readDatagram()` pour lire le datagramme.
Les exemples « Broadcast Sender » et « Broadcast Receiver » montrent comment écrire un émetteur UDP et un récepteur UDP à l'aide de Qt.
QUdpSocket prend également en charge la multidiffusion. Les exemples « Multicast Sender » et « Multicast Receiver » montrent comment écrire des clients UDP en multidiffusion.
Résolution des noms d’hôtes à l’aide de QHostInfo
Avant d’établir une connexion réseau, QTcpSocket et QUdpSocket effectuent une recherche de nom, en traduisant le nom d’hôte auquel vous vous connectez en une adresse IP. Cette opération est généralement effectuée à l’aide du protocole DNS (Domain Name Service).
QHostInfo fournit une fonction statique qui vous permet d’effectuer vous-même une telle recherche. En appelant ` QHostInfo::lookupHost()` avec un nom d’hôte, un pointeur ` QObject ` et une signature de slot, ` QHostInfo ` effectuera la recherche de nom et invoquera le slot donné lorsque les résultats seront prêts. La recherche proprement dite est effectuée dans un thread distinct, en utilisant les méthodes propres au système d'exploitation pour effectuer les recherches de noms.
QHostInfo fournit également une fonction statique appelée QHostInfo::fromName() qui prend le nom d’hôte en argument et renvoie les résultats. Dans ce cas, la recherche de nom est effectuée dans le même thread que celui de l’appelant. Cette surcharge est utile pour les applications non-GUI ou pour effectuer des recherches de nom dans un thread distinct, non-GUI. (L’appel de cette fonction dans un thread GUI peut entraîner le gel de votre interface utilisateur pendant que la fonction se bloque au cours de la recherche.)
Prise en charge des proxys réseau
La communication réseau avec Qt peut s’effectuer via des proxys, qui acheminent ou filtrent le trafic réseau entre les connexions locales et distantes.
Les proxys individuels sont représentés par la classe ` QNetworkProxy `, qui sert à décrire et à configurer la connexion à un proxy. Les types de proxys fonctionnant à différents niveaux de communication réseau sont pris en charge : la prise en charge de SOCKS 5 permet la mise en proxy du trafic réseau à un niveau bas, tandis que la mise en proxy HTTP et FTP fonctionne au niveau du protocole. Voir QNetworkProxy::ProxyType pour plus d’informations.
Le proxy peut être activé au cas par cas pour chaque socket ou pour l’ensemble des communications réseau d’une application. Une socket nouvellement ouverte peut être configurée pour utiliser un proxy en appelant sa fonction QAbstractSocket::setProxy() avant qu’elle ne soit connectée. Le proxy à l’échelle de l’application peut être activé pour toutes les connexions de socket ultérieures à l’aide de la fonction QNetworkProxy::setApplicationProxy().
Les fabriques de proxys sont utilisées pour créer des politiques d’utilisation des proxys. La fonction ` QNetworkProxyFactory ` fournit des proxys en fonction de requêtes portant sur des types de proxys spécifiques. Les requêtes elles-mêmes sont encodées dans des objets ` QNetworkProxyQuery `, ce qui permet de sélectionner des proxys en fonction de critères clés, tels que la finalité du proxy (TCP, UDP, serveur TCP, requête URL), le port local, l’hôte et le port distants, ainsi que le protocole utilisé (HTTP, FTP, etc.).
QNetworkProxyFactory::proxyForQuery() permet d'interroger directement l'usine. Une politique de proxy à l'échelle de l'application peut être mise en œuvre en transmettant une usine à QNetworkProxyFactory::setApplicationProxyFactory() et une politique de proxy personnalisée peut être créée en sous-classant QNetworkProxyFactory; voir la documentation de la classe pour plus de détails.
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.