UDP et QUIC via les proxys

Un proxy peut réussir une vérification web tout en étant incapable de transporter le trafic dont votre programme a besoin. Par exemple, un jeu peut permettre de se connecter par le proxy, mais échouer à échanger les mises à jour de la partie. Un site web peut s’ouvrir normalement alors que le navigateur utilise HTTP/2 au lieu de HTTP/3. Ces opérations sollicitent des fonctions réseau différentes.

Pour le choix plus général du protocole, consultez Proxys SOCKS ou HTTP. Cet article explique comment UDP atteint une destination par un proxy, ce que QUIC exige de ce trajet et comment vérifier que votre application utilise le transport et l’IP de sortie prévus.

Rôle d’UDP, de QUIC et de HTTP/3

TCP fournit un flux ordonné d’octets. Si des données sont perdues, il organise leur retransmission et ne remet pas les octets suivants à l’application tant que le manque n’est pas comblé. UDP envoie des messages distincts, appelés datagrammes. UDP ne garantit lui-même ni la livraison, ni l’ordre, ni la protection contre les doublons ; le logiciel qui l’utilise décide comment gérer ces situations.

Les applications peuvent ainsi choisir différents comportements. Une application vocale peut écarter un paquet audio arrivé trop tard pour être lu. Un jeu peut préférer une mise à jour de position récente à une ancienne. Un échange DNS peut se résumer à une courte question et à sa réponse. Le transport réel dépend du programme : ces exemples ne signifient pas que tous les appels, jeux ou requêtes DNS utilisent UDP.

QUIC est un protocole de transport fondé sur UDP. Il ajoute l’établissement de connexion, la récupération des données perdues, le contrôle de congestion et des flux fiables. Un fichier transféré sur un flux QUIC fiable peut arriver complet et dans l’ordre. Le fait que ses paquets circulent dans des datagrammes UDP ne supprime pas la fiabilité apportée par QUIC.

QUIC permet aussi à plusieurs flux de partager une connexion. Lorsque des données d’un flux sont perdues, les autres flux dont les données sont arrivées peuvent continuer. Cela peut réduire l’attente par rapport au transport de tous les flux sur une même connexion TCP ordonnée. Le résultat dépend toujours du trajet, de la perte de paquets, du serveur et du client ; choisir QUIC ne garantit pas à lui seul une application plus rapide.

HTTP/3 transporte HTTP sur QUIC. HTTP/1.1 et HTTP/2 utilisent normalement TCP. Les trois peuvent servir un site HTTPS : https:// dans l’adresse n’identifie donc pas la version HTTP et ne confirme pas l’utilisation d’UDP.

Le chiffrement est une propriété distincte. UDP ne chiffre pas les données. QUIC utilise TLS 1.3 pour établir la protection du trafic applicatif. Une application UDP ordinaire peut utiliser un autre mécanisme de sécurité ou transmettre sa charge utile sans chiffrement ; la faire passer par un proxy n’ajoute pas automatiquement cette protection.

Comment SOCKS5 transporte UDP

SOCKS5 définit un relais UDP : un service qui accepte les datagrammes du client, envoie leurs charges utiles à la destination et renvoie les réponses. Le client organise d’abord cette transmission en TCP. La connexion de contrôle et le trajet des datagrammes existent ensuite côte à côte.

1. Le client se connecte au serveur SOCKS5 en TCP et termine la procédure d’authentification convenue.
2. Il demande UDP ASSOCIATE. Si le proxy accepte, la réponse fournit l’adresse et le port UDP du relais.
3. Le client envoie des datagrammes au relais avec un en-tête SOCKS identifiant la destination. Le relais retire cet en-tête avant de transmettre la charge utile. Pour les réponses, il ajoute un en-tête SOCKS avant de renvoyer le datagramme au client.
4. Le client garde la connexion de contrôle TCP ouverte pendant l’utilisation du relais. La fermer met fin à la transmission UDP organisée par cette connexion. Ce lien entre la connexion de contrôle et la transmission UDP s’appelle une association UDP.

Le relais peut utiliser une adresse ou un port différents du point de connexion TCP saisi dans les paramètres proxy. Envoyer de l’UDP brut à ce point de connexion habituel n’effectue pas l’échange SOCKS5. Un client qui implémente uniquement CONNECT peut utiliser SOCKS5 pour TCP, mais ne dispose pas de la procédure nécessaire ici. SOCKS4 ne définit pas cette fonction de relais UDP.

Cela explique un cas courant de réussite partielle : un pare-feu autorise la connexion TCP et l’authentification, mais bloque les datagrammes vers le relais négocié. Le mot de passe fonctionne ; l’application ne reçoit toujours aucune réponse UDP. Les deux parties du trajet doivent être disponibles.

Un proxy HTTP peut-il transmettre UDP ?

Une requête HTTP CONNECT ordinaire demande au proxy d’ouvrir une connexion TCP à la destination et de transporter un flux d’octets. Elle n’établit pas de transmission UDP. Utiliser TLS pour la connexion à un proxy HTTPS protège cette connexion sans changer le type de tunnel demandé.

HTTP dispose d’un mécanisme supplémentaire de tunnellisation UDP, généralement appelé CONNECT-UDP et développé dans le cadre de MASQUE. Avec un client et un serveur compatibles, le client demande un tunnel vers une destination UDP. Le proxy transmet les datagrammes à cette destination et ramène les réponses. Cela nécessite une prise en charge explicite des deux côtés.

Sur la connexion entre client et proxy, les datagrammes HTTP peuvent être transportés dans des trames QUIC DATAGRAM si HTTP/3 et les extensions requises sont pris en charge. Ils peuvent aussi être transportés dans des capsules : des messages encadrés dans un flux HTTP fiable, y compris HTTP/2 sur TCP. Dans ce cas, le proxy envoie toujours de l’UDP à la destination, même si la première partie du trajet utilise TCP.

Ce choix influe sur les délais. Si la connexion TCP perd des données, les octets suivants peuvent attendre leur récupération, ce qui retarde les datagrammes qu’ils contiennent. Le tunnel peut fonctionner tout en étant inadapté à une charge de travail en temps réel donnée. Saisir simplement une adresse proxy http:// dans un programme n’active aucun de ces mécanismes UDP supplémentaires.

Quelle connexion utilise QUIC ?

L’expression « proxy QUIC » doit être replacée dans son contexte. Elle peut désigner le transport utilisé pour atteindre le proxy ou la connexion de l’application à la destination. Ce sont deux parties distinctes de l’échange.

Dans un relais UDP ordinaire, le proxy n’a pas besoin de terminer la connexion QUIC de l’application. Il transmet les paquets tandis que l’application et la destination restent les extrémités de cet échange chiffré. Le proxy sait toujours où il transmet le trafic et peut en observer le volume et les horaires.

Pourquoi la prise en charge par l’application compte

Un programme doit implémenter la méthode de transmission proposée par le service. Une case SOCKS5 ne vous indique pas s’il prend en charge UDP ASSOCIATE. De même, un programme peut prendre en charge HTTP/3 pour les connexions directes tout en ne proposant que des connexions proxy TCP.

Chrome en fournit un exemple concret : sa prise en charge native de SOCKS5 fait passer les requêtes URL fondées sur TCP par le proxy et ne relaie pas UDP via SOCKS5. Charger une page avec ce paramètre ne permet pas de tester le relais UDP du service. Cette limite concerne ce mode client précis ; d’autres clients ou logiciels de routage externes peuvent avoir des possibilités différentes.

Vérifiez aussi le périmètre du paramètre. La connexion au compte, les téléchargements de fichiers, la voix et les échanges du jeu peuvent utiliser des composants réseau différents au sein d’une même application. Un proxy configuré pour les requêtes web peut ne couvrir que certains d’entre eux. Un paramètre proxy système dépend aussi du respect de ce paramètre par chaque programme.

Un programme qui redirige le trafic d’une autre application peut envoyer son UDP par un proxy, à condition de prendre en charge UDP et la méthode de transmission du service. Rediriger TCP seul ne suffit pas. Si le programme utilise une interface réseau virtuelle, ses règles de routage déterminent le trafic qui y entre. Testez la combinaison complète : l’application, le programme de routage et le point de connexion proxy.

Repli, échec et connexion directe

Lorsque le trajet requis est indisponible, le résultat dépend des possibilités et des règles de l’application. Trois résultats peuvent sembler similaires si la seule question est de savoir si quelque chose s’est ouvert :

Le passage à une version HTTP fondée sur TCP s’appelle un repli. Il peut préserver une navigation normale lorsque QUIC est indisponible. Le client ouvre une autre connexion ; QUIC lui-même ne se transforme pas en TCP. Désactiver QUIC peut donc aider une application web à utiliser un trajet TCP disponible, mais ne peut pas fournir UDP à une fonction qui l’exige.

Aller directement à la destination est une décision de routage. L’UDP non pris en charge n’est pas systématiquement envoyé directement : le logiciel peut s’arrêter, essayer un autre transport ou suivre une règle de contournement configurée. Si tout le trafic de la tâche doit passer par le proxy, utilisez un mode qui s’arrête lorsque ce trajet échoue et vérifiez son comportement lorsque le proxy est indisponible.

Pourquoi UDP peut cesser de fonctionner après l’établissement

Règles de port et trajet de retour

Le port TCP 443 et le port UDP 443 appartiennent à des transports différents. Autoriser l’un n’ouvre pas l’autre. Pour SOCKS5, le client doit atteindre le point de connexion du relais UDP renvoyé ; le relais doit aussi être autorisé à atteindre le port UDP de la destination. HTTP/3 peut utiliser d’autres ports que 443 ; vérifiez donc le point de connexion réellement utilisé par l’application.

Les réponses doivent revenir par le relais, le pare-feu et tout équipement NAT, qui traduit les adresses et souvent les ports entre les réseaux. Un datagramme envoyé ne prouve pas à lui seul que ce trajet de retour fonctionne. Un changement de réseau peut modifier l’IP publique du client ou l’association de ports. Les relais SOCKS5 doivent refuser les datagrammes provenant d’une IP source différente de celle enregistrée pour cette association UDP ; un changement d’adresse peut donc nécessiter une nouvelle association.

Pauses et expiration de l’état

Les relais et les équipements NAT conservent des enregistrements temporaires pour les échanges UDP. Ces enregistrements peuvent expirer pendant une pause. Un appel ou une session peut fonctionner au début, puis perdre son trajet UDP jusqu’à ce que le client le rétablisse. Conserver la même IP de sortie ne l’empêche pas : l’état nécessaire pour transmettre UDP et l’attribution d’IP du service sont deux choses distinctes.

Taille des datagrammes et MTU

La MTU est la taille maximale d’un paquet IP qu’une liaison réseau peut transporter sans fragmentation. La taille utilisable sur un trajet est limitée par la plus petite de ces limites, appelée MTU du chemin. Les en-têtes IP, UDP et les en-têtes de tunnel supplémentaires occupent tous de la place dans le paquet. Un petit message de test peut passer alors que de plus grands datagrammes sont supprimés ; l’application doit donc tenir compte du trajet complet et de ses en-têtes supplémentaires.

Un trajet QUIC doit transporter au moins 1 200 octets de charge utile UDP, sans compter les en-têtes IP et UDP. Le client complète les datagrammes UDP contenant ses paquets QUIC Initial jusqu’à atteindre au moins cette taille de charge utile. Les en-têtes proxy sur la partie entre client et proxy demandent de la place supplémentaire. Il ne s’agit pas de recommander une MTU d’interface de 1 200 : cela explique pourquoi une petite requête DNS et sa réponse peuvent fonctionner alors que la négociation QUIC, plus volumineuse, ne passe pas.

Délai, pertes et charge

Pour un appel ou un jeu, le délai de livraison peut compter autant que la livraison elle-même. Un délai variable, la perte de paquets et les limites de nombre de paquets par seconde peuvent dégrader un relais UDP qui fonctionne par ailleurs. La bande passante seule ne décrit pas ces conditions. Un proxy ajoute une partie au trajet ; il peut améliorer ou dégrader les performances selon les réseaux et la charge de travail.

Comment vérifier UDP et HTTP/3 par un proxy

Testez l’application que vous comptez utiliser, ou un client qui implémente la même méthode de transmission. Un test utile vérifie la réponse, le transport et l’adresse de sortie pour un même échange.

1. Choisissez une destination qui répond au trafic requis. Utilisez le serveur réel de l’application ou un répondeur UDP contrôlé. Pour HTTP/3, choisissez une destination dont la prise en charge est connue. Le silence d’un port UDP arbitraire ne vous indique pas quelle partie a échoué.
2. Confirmez que le relais ou le tunnel a été accepté. Avec SOCKS5, examinez le résultat de UDP ASSOCIATE, ainsi que l’adresse et le port de relais renvoyés. Avec un tunnel HTTP UDP, confirmez son acceptation. L’authentification seule ne couvre pas cette étape.
3. Menez à terme une requête et sa réponse. Un répondeur contrôlé peut renvoyer un identifiant de requête et enregistrer l’IP source qu’il a vue. Cela vérifie la sortie utilisée pour cet échange UDP. Une vérification d’IP web séparée ne couvre que sa propre requête.
4. Pour HTTP/3, confirmez le protocole utilisé dans l’échange avec la destination. Recherchez HTTP/3 ou h3 dans le journal de connexion du client ou du serveur, avec une preuve du trajet proxy. Si le client de test possède un mode exclusivement HTTP/3, il peut révéler un échec que le repli automatique masquerait autrement.
5. Répétez le test dans les conditions pertinentes : tailles réalistes de datagrammes, trafic soutenu et pause suivie d’activité. Si le trafic direct est interdit pour la tâche, testez aussi ce qui se passe lorsque le proxy est indisponible. Conservez la version du client et les paramètres de connexion avec le résultat.

Une capture de paquets peut aider à identifier le trajet. La transmission UDP SOCKS5 standard envoie les datagrammes au relais négocié. Un tunnel HTTP UDP peut en revanche utiliser une connexion TCP extérieure ; l’absence d’UDP sur cette première partie du trajet ne suffit donc pas à prouver un échec.

Le DNS distant et ping testent des choses différentes. Un proxy peut résoudre un nom d’hôte pour une connexion TCP sans relayer le trafic UDP de l’application. La commande ping ordinaire utilise ICMP. Aucun de ces tests ne remplace une requête UDP et sa réponse observées sur le trajet proxy prévu.

Quand choisir la prise en charge d’UDP

Partez du trafic requis par votre tâche. Le travail sur des sites web et des API qui fonctionne en HTTP/1.1 ou HTTP/2 peut être entièrement couvert par un proxy exclusivement TCP. Les tests HTTP/3, les médias UDP et d’autres fonctions dépendantes d’UDP exigent un relais ou un tunnel adapté, ainsi qu’un client capable de l’utiliser.

Demandez au service quelle méthode de transmission UDP et quelle configuration client sont prises en charge. Vérifiez ensuite les destinations et ports autorisés, les limites de taille des datagrammes, le comportement en cas d’inactivité et les limites de trafic ou de nombre de paquets par seconde pertinentes pour la charge de travail. Si TCP et UDP doivent utiliser la même IP de sortie ou la même localisation, vérifiez cette exigence dans l’application réelle. Un compte commun ou une vérification web réussie ne prouve pas un comportement de sortie identique.