HTTP et SOCKS5 au niveau du protocole : CONNECT, ATYP, ce que voit l'intermédiaire et comment choisir

Si vous avez déjà ouvert votre espace client chez un fournisseur de proxy, vous connaissez ce tableau : une même adresse, un même identifiant, et à côté, deux ports. L'un étiqueté HTTP, l'autre SOCKS5. Beaucoup choisissent au hasard ou par habitude. Pourtant, derrière ces deux lignes se cachent deux protocoles différents, structurés différemment au niveau des octets, qui voient votre trafic différemment et se comportent différemment dans les clients réels. Ce guide décortique la différence jusqu'au dernier octet et se termine par des tableaux de choix pratiques.

Introduction : pourquoi un même proxy est proposé en deux modes, et ce n'est pas du marketing

Commençons par répondre honnêtement à la question du titre. Quand Proxeon vous donne une adresse avec deux ports, il s'agit de la même machine, de la même IP sortante et du même compte. La différence ne réside pas dans la destination du trafic. Elle réside dans la langue que votre client parle au serveur proxy sur le premier segment du chemin : de votre application jusqu'à l'intermédiaire.

Le proxy HTTP parle le langage HTTP. Il reçoit les requêtes HTTP, les lit, comprend ce que vous voulez obtenir, et va lui-même chercher la ressource. Il sait mettre en cache, ajouter des en-têtes, répondre avec des codes de statut. Pour tout ce qui n'est pas HTTP, il dispose d'un tour de passe-passe universel : la méthode CONNECT, qui le transforme en simple tuyau.

SOCKS5 ignore totalement ce qu'est HTTP. C'est un protocole de niveau session : le client dit « connecte-moi à tel hôte et tel port », le proxy ouvre une connexion TCP et, à partir de ce moment, se contente de faire passer les octets dans les deux sens. Peu lui importe ce qu'il y a à l'intérieur : TLS, IMAP, SSH, un protocole de base de données ou votre propre format binaire.

Pourquoi ne pas se contenter d'un seul mode ? Parce que leur compatibilité diffère. La moitié des logiciels d'entreprise et de bureau ne savent utiliser qu'un proxy HTTP via les paramètres système. Une bonne partie des bibliothèques réseau et pratiquement tout le trafic non-web se sentent plus à l'aise en SOCKS5. Proposer les deux modes sur une même IP signifie que vous choisissez l'outil en fonction du client, et non que vous adaptez le client à l'outil.

Ce que vous allez apprendre dans cet article :

• à quoi ressemble une requête vers un proxy HTTP au niveau texte et en quoi elle diffère d'une requête normale vers un site ;
• ce que le proxy voit et peut modifier exactement en mode HTTP transparent ;
• comment fonctionne la méthode CONNECT et ce qui reste visible à l'intermédiaire après l'établissement du tunnel ;
• la poignée de main SOCKS5 octet par octet, les schémas d'authentification et les trois types d'adresses ATYP ;
• pourquoi le choix entre domaine et IP dans une requête SOCKS5 influence la géolocalisation et la confidentialité DNS ;
• une comparaison sur les protocoles non-HTTP, l'UDP, les surcoûts, la mise en cache et la journalisation ;
• un tableau « tâche, protocole, pourquoi » et une analyse de compatibilité dans les clients et bibliothèques populaires.

La mécanique de la commande UDP ASSOCIATE et la différence entre les schémas socks5 et socks5h dans curl et Python ne sont pas détaillées ici : ces sujets font l'objet d'articles séparés sur le blog Proxeon, avec des liens aux endroits appropriés.

Les bases : où se situe le proxy dans la pile réseau

Pour que notre discussion sur les protocoles ait du sens, mettons-nous d'accord sur les termes. Ils sont peu nombreux.

Trois acteurs et deux connexions

Dans tout schéma avec proxy, il y a trois parties : le client (votre navigateur, script, logiciel de messagerie), le serveur proxy (l'intermédiaire) et le serveur cible (origine). Entre eux, deux connexions TCP indépendantes. La première : du client vers le proxy. La seconde : du proxy vers le serveur cible. Le serveur cible ne voit que la seconde connexion et, par conséquent, uniquement l'adresse IP du proxy.

Tout ce que nous abordons dans cet article concerne exclusivement la première connexion. C'est là que réside la différence entre HTTP et SOCKS5. La seconde connexion est structurée de la même manière dans les deux cas : un simple TCP du proxy vers l'hôte cible.

Les niveaux du modèle et pourquoi c'est important

Une analogie utile : imaginez un service de livraison. Un proxy HTTP en mode transparent ressemble à un livreur qui ouvre votre colis, lit l'adresse et le contenu, le réemballe si nécessaire et peut même répondre lui-même s'il a une copie en stock. SOCKS5 ressemble à un livreur à qui vous donnez l'adresse et remettez le colis scellé. Il ne sait pas et ne veut pas savoir ce qu'il y a dedans.

En termes de modèle réseau, le proxy HTTP opère au niveau applicatif : il comprend la sémantique de la requête. SOCKS5 opère au niveau session : il manipule les notions d'« hôte », de « port », de « connexion » et ne monte pas plus haut.

Où s'effectue la résolution de noms

Un concept distinct qui traverse tout le propos : la résolution DNS. Quand vous accédez à example.com, quelqu'un doit transformer le nom en adresse IP. Cela peut être fait par votre client localement, ou par le proxy de son côté. Cela détermine quelle infrastructure DNS vous utilisez, quelle réponse régionale vous obtenez d'un CDN, et si les informations sur les domaines visités fuient dans le réseau local. Retenez ce point, il reviendra dans la section HTTP et dans la section SOCKS5.

Authentification

Tant le proxy HTTP que SOCKS5 savent vérifier identifiant et mot de passe, mais le font différemment. HTTP utilise l'en-tête Proxy-Authorization et le code de réponse 407. SOCKS5 utilise un sous-protocole distinct avec le numéro de méthode 0x02. Il existe aussi une alternative indépendante du protocole : l'autorisation par adresse IP du client, où le proxy accepte tous ceux qui viennent d'une adresse préalablement autorisée. Chez Proxeon, les deux options sont disponibles, et le choix entre elles influence la facilité de connexion des clients qui ne savent pas transmettre d'identifiants.

Proxy HTTP : requête avec URI absolue, ce que le proxy voit et peut modifier

Une requête HTTP normale vers un site ressemble à ceci :

GET /catalog/items?page=2 HTTP/1.1
Host: shop.example

Notez que dans la ligne de requête figure uniquement le chemin. L'hôte est transmis dans un en-tête séparé. Ce format s'appelle origin-form. Quand le client sait qu'il communique non pas avec le site mais avec le proxy, il change de format pour absolute-form : l'URI complète est placée dans la ligne de requête.

GET http://shop.example/catalog/items?page=2 HTTP/1.1
Host: shop.example
Proxy-Authorization: Basic dXNlcjpwYXNz
User-Agent: my-parser/1.0
Accept: text/html

Pourquoi dupliquer l'hôte ? Historiquement, la forme absolue est apparue avant l'en-tête Host et était le seul moyen d'indiquer au proxy où aller. Le standard HTTP/1.1 moderne exige que le proxy sache accepter la forme absolue, et que les clients s'adressant à un proxy utilisent précisément celle-ci. L'en-tête Host est conservé pour la compatibilité et pour le serveur cible, à qui le proxy transmettra la requête en origin-form.

Ce que le proxy HTTP voit

En mode transparent (sans chiffrement entre le client et le site cible), le proxy voit absolument tout ce qui figure dans la requête et la réponse :

• la méthode, l'URL complète, y compris les paramètres de requête ;
• tous les en-têtes de requête : User-Agent, Cookie, Authorization, Referer ;
• le corps de la requête dans son intégralité : formulaires, JSON, fichiers uploadés ;
• le statut de la réponse, les en-têtes de réponse et le corps de la réponse.

Ce n'est pas un effet secondaire. C'est une caractéristique fondamentale de l'architecture : pour transmettre une requête, le proxy doit la parser. Et puisqu'il l'a parsée, il peut en faire ce qu'il veut.

Ce que le proxy HTTP peut modifier

Le standard divise les en-têtes en de bout en bout (end-to-end) et hop-by-hop (de saut en saut). Les en-têtes hop-by-hop concernent une connexion spécifique et doivent être supprimés par le proxy avant transmission. Il s'agit de Connection, Keep-Alive, Proxy-Authorization, Proxy-Authenticate, TE, Trailer, Transfer-Encoding, Upgrade. C'est pourquoi votre identifiant et mot de passe proxy ne partent pas vers le site cible : l'en-tête Proxy-Authorization est retiré au niveau du proxy conformément au standard.

Au-delà du nettoyage obligatoire, le proxy peut :

• ajouter l'en-tête Via avec son nom et la version du protocole ; le standard l'exige, mais en pratique les proxy anonymes l'omettent ;
• ajouter X-Forwarded-For avec l'IP réelle du client ; c'est ce que font les proxy d'entreprise, et ce qu'un proxy acheté pour travailler avec des ressources externes ne doit jamais faire ;
• servir une réponse depuis son cache sans contacter le serveur cible, si la réponse est marquée comme cachable ;
• modifier l'encodage du corps, ajouter ou retirer la compression, réécrire les liens dans le HTML ;
• rejeter la requête avec sa propre réponse, par exemple 403 ou 407.

La réponse 407 Proxy Authentication Required mérite une mention spéciale. Si le proxy exige une authentification et que le client ne l'a pas fournie, le proxy répond avec le code 407 et l'en-tête Proxy-Authenticate, où il énumère les schémas pris en charge. Les bons clients répètent alors la requête avec Proxy-Authorization. Les mauvais affichent une erreur incompréhensible à l'utilisateur. D'où le problème typique de configuration : l'application « ne voit pas le proxy », alors qu'en réalité elle ne sait simplement pas traiter un 407.

Mise en pratique

La façon la plus simple de voir tout cela de ses propres yeux : curl avec l'option -v.

curl -v -x http://user:pass@gate.proxeon.net:8080 http://httpbin.org/get

Dans la sortie, vous verrez une ligne du type GET http://httpbin.org/get HTTP/1.1 et l'en-tête Proxy-Authorization. C'est ça, la forme absolue.

La même requête à la main via un socket en Python, pour qu'il ne reste aucune magie :

import socket, base64

creds = base64.b64encode(b"user:pass").decode()
req = (
"GET http://httpbin.org/get HTTP/1.1\r\n"
"Host: httpbin.org\r\n"
f"Proxy-Authorization: Basic {creds}\r\n"
"Connection: close\r\n\r\n"
)
s = socket.create_connection(("gate.proxeon.net", 8080))
s.sendall(req.encode())
print(s.recv(65535).decode(errors="replace"))

Ici, aucune bibliothèque proxy. Juste un socket et une chaîne correctement composée. Le proxy HTTP en mode transparent est si simple qu'on peut l'écrire en une soirée, et c'est à la fois sa force et sa faiblesse.

Où le nom est résolu en mode HTTP

Dans la forme absolue, le client transmet le nom d'hôte au proxy tel quel. C'est le proxy qui effectue la résolution. Le client n'a pas besoin de connaître l'adresse IP du serveur cible, et aucune requête DNS locale n'est effectuée. C'est pratique, mais cela nous mène à la limitation principale : le schéma décrit ne fonctionne que pour HTTP non chiffré. Pour HTTPS, la forme absolue est inutile, car la connexion TLS doit être établie entre le client et le serveur cible, et le proxy ne peut pas s'interposer sans casser le certificat. C'est pour cela que CONNECT a été inventé.

La méthode CONNECT : transformer un proxy HTTP en tunnel TCP

CONNECT est une méthode HTTP qui demande au proxy non pas de transmettre la requête, mais d'établir une connexion TCP avec l'hôte et le port indiqués, puis de devenir un tuyau transparent. La requête ressemble à ceci :

CONNECT shop.example:443 HTTP/1.1
Host: shop.example:443
Proxy-Authorization: Basic dXNlcjpwYXNz
Proxy-Connection: Keep-Alive

Notez le format de la cible : uniquement l'hôte et le port, sans schéma ni chemin. C'est l'authority-form de la requête, le troisième format après origin-form et absolute-form.

Si le proxy est d'accord, il répond :

HTTP/1.1 200 Connection established

Le texte après le code peut être quelconque, les clients se basent uniquement sur le 2xx. À partir de ce moment, HTTP s'arrête. Tout ce que le client écrit dans le socket, le proxy le transmet octet par octet au serveur cible, et inversement. Le client commence la poignée de main TLS directement dans ce socket, comme s'il était connecté directement au serveur.

Ce que l'intermédiaire voit après CONNECT

C'est là que ça devient intéressant. Le proxy, qui était omniscient il y a un instant, devient brutalement aveugle. Après un CONNECT réussi, le proxy sait :

• le nom d'hôte et le port de la ligne CONNECT ; c'est la seule information sémantique qu'il a obtenue ;
• l'heure d'établissement et de fermeture de la connexion ;
• le volume d'octets transmis dans les deux sens ;
• le contenu du TLS ClientHello, s'il y a du TLS dans le tunnel : le SNI (nom du serveur), la liste des chiffrements pris en charge, les extensions y sont transmis en clair ; l'extension moderne Encrypted Client Hello masque aussi le SNI, mais son support n'est pas encore généralisé ;
• rien du niveau HTTP : ni URL, ni en-têtes, ni cookies, ni corps.

Autrement dit, après CONNECT, le proxy HTTP voit exactement autant qu'un SOCKS5. Hôte, port, timings, volumes. La différence de visibilité entre les deux protocoles n'existe que pour le trafic HTTP non chiffré, et celui-ci est devenu très rare dans les tâches réelles en 2026.

CONNECT n'est pas obligé de mener à HTTPS

Une erreur de raisonnement courante : CONNECT ne sert qu'à HTTPS. En réalité, le standard ne limite pas le contenu du tunnel. Via CONNECT, on peut établir une connexion avec un serveur IMAP sur le port 993, avec SSH sur le port 22, avec n'importe quel service TCP. La seule question est de savoir si la configuration du proxy l'autorise. Beaucoup de proxy HTTP publics et d'entreprise n'autorisent CONNECT que vers les ports 443 et parfois 80, pour prévenir les abus. Proxeon autorise CONNECT vers des ports arbitraires, mais si votre logiciel sait faire du SOCKS5, pour les protocoles non-HTTP, ce dernier reste un choix plus naturel, comme expliqué plus bas.

Exemple : TLS via CONNECT à la main

L'utilitaire openssl sait traverser un proxy HTTP tout seul :

openssl s_client -proxy gate.proxeon.net:8080 -connect shop.example:443 -servername shop.example

Et voici à quoi cela ressemble en Python avec la bibliothèque standard, sans dépendances externes :

import http.client, ssl

conn = http.client.HTTPSConnection("gate.proxeon.net", 8080,
 context=ssl.create_default_context())
conn.set_tunnel("shop.example", 443,
headers={"Proxy-Authorization": "Basic dXNlcjpwYXNz"})
conn.request("GET", "/")
resp = conn.getresponse()
print(resp.status, resp.getheader("server"))

La méthode set_tunnel fait exactement ce qui est décrit ci-dessus : envoie CONNECT, attend le 200, puis enveloppe le socket dans TLS. Notez que le contexte TLS vérifie le certificat de shop.example, et non celui du proxy. Le proxy, dans ce schéma, ne peut pas substituer le certificat sans provoquer une erreur chez le client.

CONNECT dans HTTP/2 et HTTP/3

Dans HTTP/2, la méthode CONNECT est conservée, mais fonctionne à l'intérieur d'une seule connexion multiplexée : chaque tunnel est un flux séparé. Cela permet de maintenir des dizaines de tunnels via une seule connexion TCP vers le proxy et d'économiser sur les poignées de main. Le CONNECT étendu (avec le pseudo-en-tête :protocol) est utilisé pour WebSocket sur HTTP/2. Dans HTTP/3 basé sur QUIC, la spécification CONNECT-UDP est apparue, qui permet formellement de tunnelliser de l'UDP via un proxy HTTP. Cependant, dans les bibliothèques client, c'est encore exotique, et en pratique, si vous avez besoin d'UDP via un proxy, vous vous tournerez vers SOCKS5.

Ce que CONNECT ne sait pas faire

• Mettre en cache : le contenu du tunnel est opaque.
• Modifier les en-têtes : ils sont simplement invisibles.
• Multiplexer plusieurs hôtes cibles via un seul tunnel en HTTP/1.1 : un CONNECT égale une connexion TCP.
• Transmettre de l'UDP en HTTP/1.1 et HTTP/2.

SOCKS5 : poignée de main, authentification et ATYP

SOCKS5 est décrit dans la RFC 1928, et son schéma d'authentification par identifiant et mot de passe dans la RFC 1929. Les deux spécifications tiennent en quelques pages, et c'est l'un des avantages du protocole : le mettre en œuvre de zéro n'est pas compliqué, donc les implémentations sont nombreuses et divergent rarement dans leur interprétation.

SOCKS5 est un protocole binaire. Pas de texte, uniquement des octets de structure fixe. Examinons l'échange complet pour la commande CONNECT.

Étape 1 : salutation et choix de la méthode d'authentification

Le client envoie la version et la liste des méthodes d'authentification qu'il prend en charge :

05 02 00 02
VER=5 NMETHODS=2 METHODS: 00 (sans authentification), 02 (login/mot de passe)

Le serveur choisit une méthode et répond avec deux octets :

05 02
VER=5 METHOD=02 (le serveur exige login/mot de passe)

Si le serveur répond 05 FF, cela signifie « aucune des méthodes proposées ne convient », et le client doit fermer la connexion. C'est exactement à quoi ressemble, au niveau des octets, la situation où vous avez oublié de spécifier un mot de passe alors que le proxy Proxeon est configuré pour l'authentification par identifiant.

Étape 2 : authentification selon la RFC 1929

Si la méthode 02 est choisie, le client envoie :

01 04 75 73 65 72 04 70 61 73 73
VER=1 ULEN=4 UNAME="user" PLEN=4 PASSWD="pass"

Notez que la version du sous-protocole est ici 01, et non 05. C'est une source fréquente d'erreurs dans les clients maison. Le serveur répond :

01 00
VER=1 STATUS=00 (succès ; toute autre valeur signifie un refus)

L'identifiant et le mot de passe sont transmis en clair. Si le réseau entre vous et le proxy n'est pas de confiance, il faut en tenir compte. En pratique, la connexion au proxy passe généralement par le propre canal du fournisseur, et la question se règle au niveau du transport ou par un remplacement par l'autorisation par IP.

Étape 3 : requête de connexion

Maintenant, le message le plus important :

05 01 00 03 0C 73 68 6F 70 2E 65 78 61 6D 70 6C 65 01 BB
VER=5 CMD=01 (CONNECT) RSV=00 ATYP=03 (domaine)
LEN=12 ADDR="shop.example" PORT=0x01BB (443)

Le champ CMD prend trois valeurs : 01 CONNECT (connexion TCP sortante), 02 BIND (attente d'une connexion entrante, pratiquement inutilisé), 03 UDP ASSOCIATE (création d'un relais UDP). La mécanique d'UDP ASSOCIATE et ses pièges sont détaillés dans un article séparé sur l'UDP dans SOCKS5, ici notons simplement : c'est le seul des deux protocoles à disposer d'UDP de manière standard.

ATYP : domaine contre IP

Le champ ATYP détermine sous quelle forme le client a transmis l'adresse de destination :

• 0x01 IPv4 : les 4 octets suivants sont l'adresse ;
• 0x03 nom de domaine : un octet de longueur, puis le nom sans zéro terminal ;
• 0x04 IPv6 : les 16 octets suivants sont l'adresse.

Cela semble un détail technique. En réalité, c'est l'une des décisions les plus importantes que prend le client, et voici pourquoi.

Si le client utilise ATYP=0x01 ou 0x04, cela signifie qu'il a lui-même effectué la résolution DNS avant d'envoyer la requête. Votre machine a interrogé son serveur DNS, obtenu l'adresse et transmis au proxy un IP déjà prêt. Conséquences :

• la requête DNS est passée par votre réseau local et est visible par votre fournisseur d'accès ou votre administrateur ;
• vous avez obtenu l'IP que le DNS a attribuée pour votre région ; pour les sites derrière un CDN, cela signifie que le proxy, situé dans un autre pays, s'adressera à un serveur edge « étranger », ce qui ralentit la connexion et peut paraître anormal ;
• si votre machine n'a pas d'IPv6, vous n'obtiendrez jamais d'enregistrement AAAA et n'utiliserez pas la route IPv6 du proxy, même si elle existe ;
• si le DNS de votre réseau se comporte de manière non standard, le proxy recevra une adresse erronée, et vous chercherez longtemps la cause.

Si le client utilise ATYP=0x03, c'est le proxy qui effectue la résolution. Il utilise sa propre infrastructure DNS, obtient une adresse pertinente pour sa localisation, et votre réseau local ne voit pas quels domaines vous visitez. Pour les tâches à contrainte géographique, c'est critique : l'intérêt d'un proxy dans un pays donné est partiellement perdu si le serveur cible est choisi par le DNS de votre réseau domestique.

Comment forcer le client à transmettre le domaine ? Cela dépend du client. Dans curl et les bibliothèques Python, c'est le choix du schéma socks5 contre socks5h qui en décide, et c'est le sujet d'une analyse séparée. Ici, il est important de comprendre la raison : la lettre h signifie « hostname » et active ATYP=0x03. Sans elle, la bibliothèque résout le nom localement.

Étape 4 : réponse du serveur

05 00 00 01 C0 A8 01 0A 1F 90
VER=5 REP=00 (succès) RSV=00 ATYP=01 BND.ADDR=192.168.1.10 BND.PORT=8080

Le champ REP contient le code de résultat. Il est utile de les connaître par cœur pour le débogage :

• 00 succès ;
• 01 erreur générale du serveur ;
• 02 connexion interdite par les règles ;
• 03 réseau inaccessible ;
• 04 hôte inaccessible ;
• 05 connexion refusée par le serveur cible ;
• 06 TTL expiré ;
• 07 commande non prise en charge ;
• 08 type d'adresse non pris en charge.

Le code 08 se rencontre sur les implémentations anciennes ou simplifiées qui ne prennent pas en charge ATYP=0x03 ou IPv6. Proxeon prend en charge les trois types d'adresses.

Pourquoi SOCKS5 n'analyse pas le contenu

Après la réponse REP=00, le protocole SOCKS5 est terminé. Tout ce que le client écrit ensuite, le proxy le transfère dans la connexion cible sans analyse. Ce n'est pas une limitation d'implémentation, mais une propriété du design. SOCKS5 n'a ni la notion de « requête », ni celle d'« en-tête ». Il ne sait pas ce qu'est HTTP, IMAP ou TLS. On lui a donné une adresse et un port, il a connecté deux tuyaux.

Plusieurs conséquences pratiques en découlent :

• SOCKS5 ne peut pas mettre en cache : il ne comprend pas où se termine une réponse et où commence la suivante ;
• SOCKS5 ne peut pas ajouter d'en-têtes ni substituer du contenu ; au maximum, il peut fermer la connexion ;
• SOCKS5 ne peut pas filtrer par URL, seulement par hôte et port ;
• SOCKS5 fonctionne aussi bien avec n'importe quel protocole TCP, y compris celui que vous avez inventé hier.

Poignée de main SOCKS5 complète en Python

import socket, struct

def socks5_connect(proxy, user, pwd, host, port):
s = socket.create_connection(proxy)
s.sendall(b"\x05\x02\x00\x02")
ver, method = s.recv(2)
if method == 0x02:
u, p = user.encode(), pwd.encode()
s.sendall(b"\x01" + bytes([len(u)]) + u + bytes([len(p)]) + p)
if s.recv(2)[1] != 0:
raise RuntimeError("auth failed")
elif method != 0x00:
raise RuntimeError("no acceptable auth method")
h = host.encode()
s.sendall(b"\x05\x01\x00\x03" + bytes([len(h)]) + h + struct.pack("!H", port))
reply = s.recv(4)
if reply[1] != 0:
raise RuntimeError(f"connect failed, REP={reply[1]}")
atyp = reply[3]
s.recv({1: 4, 4: 16}.get(atyp, 0) if atyp != 3 else s.recv(1)[0])
s.recv(2)
return s

sock = socks5_connect(("gate.proxeon.net", 1080), "user", "pass", "shop.example", 443)
# дальше sock можно обернуть в ssl.wrap_socket или передать любому протоколу

Trente lignes, et vous avez un client SOCKS5 fonctionnel qui transmet le domaine (ATYP=0x03) et laisse la résolution au serveur proxy. C'est cette simplicité qui fait de SOCKS5 le standard de facto pour l'accès programmé.

Comparaison par critères : où chacun gagne

Maintenant que la mécanique des deux protocoles est décortiquée jusqu'aux octets, la comparaison cesse d'être un débat de goûts et devient une liste de différences mesurables.

Protocoles non-HTTP

SOCKS5 fonctionne nativement avec n'importe quel protocole TCP : commande CONNECT, hôte, port, terminé. Le proxy HTTP peut aussi via CONNECT, mais avec des réserves : le client doit savoir envoyer CONNECT pour du trafic non-HTTP (les clients mail savent le faire, la plupart des outils CLI non), et le proxy doit autoriser le port requis. Gagnant : SOCKS5.

UDP

SOCKS5 dispose d'UDP ASSOCIATE. Le proxy HTTP dans les versions 1.1 et 2 n'a rien, et CONNECT-UDP de HTTP/3 n'est pratiquement pas pris en charge par les clients. Si la tâche implique des requêtes DNS directes, QUIC, des protocoles vocaux, du trafic de jeu, il n'y a pas de choix. Gagnant : SOCKS5, avec la réserve que tout serveur SOCKS5 n'active pas UDP, vérifiez dans la documentation du forfait.

Surcoût à l'établissement de connexion

Comptons en aller-retours (RTT) entre le client et le proxy, en plus de la poignée de main TCP elle-même :

• Proxy HTTP, mode transparent, sans autorisation : 0 RTT supplémentaire, la requête part immédiatement ;
• HTTP CONNECT avec autorisation dans la première requête : 1 RTT (CONNECT, réponse 200) ;
• SOCKS5 sans autorisation : 2 RTT (salutation, requête) ;
• SOCKS5 avec identifiant et mot de passe : 3 RTT (salutation, authentification, requête).

En octets, la différence s'inverse : une poignée de main SOCKS5 complète avec autorisation tient en environ 40 octets, tandis qu'un CONNECT avec en-têtes Host, Proxy-Authorization et User-Agent occupe facilement 150 et plus. Mais dans les tâches réelles, c'est le RTT qui décide, pas les octets. Avec une latence vers le proxy de 50 ms, SOCKS5 avec autorisation ajoute 150 ms à chaque nouvelle connexion contre 50 ms pour CONNECT. Si le client réutilise les connexions (keep-alive, pools), c'est un coût ponctuel. Si chaque requête ouvre un nouveau socket, la différence s'accumule. Gagnant en RTT : HTTP. Moyen de réduire l'écart pour SOCKS5 : l'autorisation par IP, qui supprime un RTT.

Mise en cache

Uniquement le proxy HTTP en mode transparent. Ni CONNECT, ni SOCKS5. De plus, il ne peut mettre en cache que du trafic non chiffré, qui est rare aujourd'hui, donc ce critère est passé de décisif à niche. Il reste pertinent pour les systèmes de build internes, les miroirs de paquets, les requêtes répétées vers des API sans TLS dans un périmètre de confiance. Gagnant : HTTP, mais avec un champ d'application étroit.

Journalisation

Ce point est souvent mal compris. Que peut enregistrer le proxy dans chaque mode ?

• HTTP transparent : URL complète, méthode, en-têtes, éventuellement le corps ; statut de la réponse ; volumes.
• HTTP CONNECT : hôte et port de la ligne CONNECT ; heure ; volumes ; éventuellement le SNI du ClientHello.
• SOCKS5 avec ATYP=0x03 : nom de domaine et port ; heure ; volumes ; éventuellement le SNI.
• SOCKS5 avec ATYP=0x01/0x04 : uniquement IP et port ; le proxy ne connaît pas le domaine ; heure ; volumes ; SNI.

Pour le trafic chiffré, CONNECT et SOCKS5 offrent à l'intermédiaire une visibilité identique. La différence n'apparaît que là où le client SOCKS5 transmet une IP au lieu d'un domaine, et le proxy en sait alors encore moins. Mais le serveur cible reçoit alors la requête depuis la « mauvaise » région, voir la section sur ATYP. Match nul, avec des nuances.

Diagnostic des erreurs

Le proxy HTTP répond avec des codes lisibles : 407 signale l'authentification, 403 l'interdiction, 502 l'inaccessibilité de la cible, 504 le délai d'attente. Certaines implémentations ajoutent un corps explicatif. SOCKS5 répond avec un seul octet REP, et toutes les bibliothèques ne le traduisent pas en message compréhensible. En débogage dans un environnement inconnu, le proxy HTTP est plus simple à diagnostiquer. Gagnant : HTTP.

Multiplexage

Un proxy HTTP/2 permet de faire passer de nombreux tunnels CONNECT via une seule connexion. SOCKS5 exige une connexion TCP distincte par cible. Pour les clients avec des centaines de connexions parallèles, cela réduit sensiblement la charge sur la pile réseau et le proxy. Mais la prise en charge de HTTP/2 vers le proxy dans les clients est encore fragmentaire. Gagnant potentiel : HTTP, égalité de fait.

Possibilité d'intervention dans le trafic

Le proxy HTTP en mode transparent peut tout modifier. En mode CONNECT et en SOCKS5, il ne peut que rompre la connexion. Pour un client qui veut des garanties d'invariance du trafic, le mieux est SOCKS5 ou CONNECT avec TLS à l'intérieur. Gagnant en prévisibilité : SOCKS5.

Authentification

Les deux savent gérer identifiant et mot de passe. HTTP prend en outre en charge les schémas Digest, NTLM, Negotiate, ce qui compte en environnement d'entreprise. SOCKS5 a formellement une méthode GSSAPI, mais dans les proxy commerciaux elle est quasi inexistante. Pour travailler avec un service comme Proxeon, cela n'a pas d'importance : on y utilise Basic ou une liste blanche d'IP.

Que choisir selon la tâche : le tableau

Rassemblons les conclusions en un outil de travail. Le tableau part du principe que les deux modes sont disponibles sur une même IP, comme chez Proxeon, et que la seule question est quel port indiquer.

Algorithme de choix en quatre étapes

1. Déterminez le protocole à l'intérieur. Si ce n'est ni HTTP ni HTTPS, prenez SOCKS5 sans hésiter.
2. Vérifiez ce que sait faire le client. Ouvrez sa documentation avec les mots-clés socks5, proxy, CONNECT. Si SOCKS5 est absent ou sans autorisation, le choix est fait pour vous.
3. Décidez où le domaine doit être résolu. Si la région compte (CDN, contenu géodépendant, surveillance), prenez SOCKS5 avec transmission du domaine ou HTTP CONNECT : dans les deux cas, c'est le proxy qui résout.
4. Évaluez le profil des connexions. Beaucoup de connexions courtes sans pool : regardez le RTT de la poignée de main, choisissez HTTP CONNECT ou activez l'autorisation par IP.

Compatibilité dans les clients et bibliothèques populaires

La théorie s'arrête là où commencent les clients réels. Voici une analyse du comportement des outils les plus courants en 2026. Vérifiez les versions à jour : le comportement change à chaque release.

curl

Prend tout en charge. Schémas dans le paramètre -x ou variables d'environnement : http://, https:// (TLS jusqu'au proxy lui-même), socks4://, socks4a://, socks5://, socks5h://. La différence entre socks5 et socks5h est décrite dans un article séparé, ici retenez : pour une résolution côté proxy, il faut socks5h.

curl -x socks5h://user:pass@gate.proxeon.net:1080 https://shop.example/
curl -x http://user:pass@gate.proxeon.net:8080 https://shop.example/

Les variables d'environnement http_proxy, https_proxy, all_proxy sont lues automatiquement ; all_proxy accepte aussi les schémas SOCKS.

wget

Uniquement proxy HTTP. SOCKS n'est pris en charge sous aucune forme. Si vous avez besoin de wget via SOCKS5, il faudra un proxyficateur système.

Python : requests

Proxy HTTP natif. Pour SOCKS5, il faut le paquet supplémentaire PySocks (installé via requests[socks]).

import requests

proxies = {
"http": "socks5h://user:pass@gate.proxeon.net:1080",
"https": "socks5h://user:pass@gate.proxeon.net:1080",
}
r = requests.get("https://shop.example/api/items", proxies=proxies, timeout=15)
print(r.status_code, r.headers.get("cf-ray"))

Pour HTTPS via un proxy HTTP, requests utilise automatiquement CONNECT. Pour HTTP via un proxy HTTP, la forme absolue est utilisée.

Python : httpx

Proxy HTTP natif, SOCKS5 via le paquet socksio (httpx[socks]). Le schéma socks5:// dans httpx transmet le domaine au serveur proxy. Prend en charge l'async, ce qui le rend pratique pour les tâches parallèles.

import httpx, asyncio

async def main():
async with httpx.AsyncClient(proxy="socks5://user:pass@gate.proxeon.net:1080") as c:
r = await c.get("https://shop.example/")
print(r.status_code)

asyncio.run(main())

Python : aiohttp

Proxy HTTP natif. SOCKS5 via le paquet aiohttp-socks avec la classe ProxyConnector, dont le paramètre rdns contrôle le lieu de résolution.

Node.js : fetch et undici

Le fetch intégré de Node.js utilise undici, qui dispose de ProxyAgent pour le proxy HTTP. Pour SOCKS5, on utilise un agent séparé de l'écosystème, par exemple socks-proxy-agent pour les modules http/https.

import { ProxyAgent, fetch } from "undici";

const agent = new ProxyAgent({
 uri: "http://gate.proxeon.net:8080",
 token: "Basic " + Buffer.from("user:pass").toString("base64"),
});
const res = await fetch("https://shop.example/", { dispatcher: agent });
console.log(res.status);

Go

Le net/http standard prend en charge le proxy HTTP via Transport.Proxy et les variables d'environnement. Depuis Go 1.13, le schéma socks5:// dans HTTP_PROXY est également accepté par la bibliothèque standard. Pour un contrôle fin, on utilise le paquet golang.org/x/net/proxy.

package main

import (
"fmt"
"net/http"
"net/url"
)

func main() {
u, _ := url.Parse("socks5://user:pass@gate.proxeon.net:1080")
tr := &http.Transport{Proxy: http.ProxyURL(u)}
client := &http.Client{Transport: tr}
resp, err := client.Get("https://shop.example/")
if err != nil {
panic(err)
}
fmt.Println(resp.Status)
}

En Go, le schéma socks5 transmet le domaine au proxy : aucune résolution locale n'est effectuée.

Java

Proxy HTTP via les propriétés système http.proxyHost, https.proxyHost ou l'objet Proxy avec Type.HTTP. SOCKS via socksProxyHost et Proxy.Type.SOCKS. L'authentification via la classe Authenticator. Depuis JDK 8u111, le schéma Basic pour HTTPS via CONNECT est désactivé par défaut par la propriété jdk.http.auth.tunneling.disabledSchemes, il faut la vider, sinon vous obtiendrez un 407 sans explication. C'est l'une des causes les plus fréquentes d'appels au support.

.NET

HttpClient avec SocketsHttpHandler prend en charge le proxy HTTP via WebProxy. La prise en charge de SOCKS4, SOCKS4a et SOCKS5 est apparue dans .NET 6 et s'active avec la même construction WebProxy avec une adresse du type socks5://host:port.

Navigateurs

Les navigateurs Chromium utilisent les paramètres proxy système ou le drapeau --proxy-server. Le proxy HTTP avec autorisation fonctionne : le navigateur affiche une boîte de dialogue de connexion. SOCKS5 via les paramètres système fonctionne sans autorisation, on ne peut pas transmettre d'identifiant et mot de passe. Pour SOCKS5 avec mot de passe, il faut une extension avec l'API proxy ou l'autorisation par IP. Firefox dispose de ses propres paramètres proxy, prend en charge SOCKS5 et l'option « Proxy DNS when using SOCKS v5 », qui active ATYP=0x03. L'autorisation pour SOCKS5 dans Firefox n'est pas non plus prévue nativement.

Clients mail

Thunderbird utilise des paramètres proxy similaires à Firefox et sait faire du SOCKS5 pour IMAP et SMTP. Beaucoup d'autres clients mail de bureau ont leur propre section proxy SOCKS5 dans les paramètres du compte. Via un proxy HTTP, le mail ne fonctionne que si le client sait envoyer CONNECT vers les ports 993 et 465, ce qui est rare.

Proxyficateurs système

Pour les applications sans paramètres proxy propres, il existe des programmes qui interceptent les appels réseau au niveau système et les redirigent vers un proxy SOCKS5 ou HTTP. Pratiquement tous préfèrent SOCKS5 comme transport, précisément parce qu'il est indépendant du protocole interne. Si votre tâche implique un tel outil, préparez le port SOCKS5.

Check-list de compatibilité

• Le client sait-il faire SOCKS5 ? Sait-il transmettre identifiant et mot de passe en SOCKS5 ?
• Le client résout-il le domaine lui-même ou le confie-t-il au proxy ? Y a-t-il un paramètre remote DNS ?
• Le client traite-t-il correctement le 407 et répète-t-il la requête avec autorisation ?
• Le client utilise-t-il CONNECT pour HTTPS ou tente-t-il d'envoyer une URI absolue avec un schéma https (certaines bibliothèques anciennes le font, et cela ne fonctionne pas) ?
• Le client réutilise-t-il les connexions au proxy ou en ouvre-t-il une nouvelle à chaque requête ?

Cas pratiques d'ingénierie

Les chiffres ci-dessous sont typiques des scénarios décrits et servent à comprendre l'ordre de grandeur de l'effet, non comme un résultat garanti.

Cas 1 : surveillance de vitrines depuis différentes régions

Une équipe suivait la disponibilité et les prix sur ses propres vitrines régionales via des proxy de plusieurs pays. Elle utilisait Python et requests avec le schéma socks5://. Périodiquement, les métriques affichaient un « mauvais » prix pour la région, alors que la vitrine fonctionnait correctement. Cause : la bibliothèque résolvait le domaine localement, dans le pays du bureau, et transmettait au proxy une IP déjà prête du serveur edge du CDN. Le proxy d'un autre pays se connectait honnêtement à cette adresse, et le CDN servait le contenu en déterminant la région par son propre nœud, non par l'IP du client. Le remplacement du schéma par socks5h a transféré la résolution au proxy. La part de mesures anormales est tombée pratiquement à zéro, et le temps de réponse médian a diminué d'environ un tiers grâce au fait que le proxy s'est mis à accéder au nœud CDN le plus proche de lui.

Cas 2 : parc de collecteurs de données avec connexions courtes

Un service d'agrégation de prix ouverts effectuait jusqu'à plusieurs centaines de milliers de requêtes par jour via SOCKS5 avec identifiant et mot de passe, en ouvrant une nouvelle connexion à chaque requête. Le profilage a montré que trois RTT de poignée de main par connexion, avec une latence vers le proxy d'environ 40 ms, donnaient 120 ms de surcoût par requête, soit environ un quart du temps total. Deux changements : activation d'un pool de connexions dans le client HTTP et passage à l'autorisation par IP, supprimant un RTT. Le temps total de parcours de la liste a diminué d'environ 30 pour cent sans changer le nombre de proxy. Le protocole a été conservé en SOCKS5, car le passage à HTTP CONNECT aurait apporté moins de gain que le pool.

Cas 3 : boîtes mail et IMAP

Un service support déployait un client mail de bureau pour plusieurs représentations régionales, où chaque boîte devait se connecter au serveur mail via l'IP d'une région spécifique. La première tentative via un proxy HTTP a échoué : le client ne savait pas faire CONNECT pour IMAP. Le passage au port SOCKS5 de Proxeon a résolu le problème en quelques minutes, car le client disposait d'un paramètre SOCKS5 natif pour chaque compte. Aucun logiciel supplémentaire.

Cas 4 : application Java et mystérieux 407

Un intégrateur d'entreprise connectait un service Java à une API externe via un proxy HTTP avec authentification Basic. Le proxy renvoyait systématiquement 407, alors que les identifiants étaient corrects et que curl avec les mêmes paramètres fonctionnait. Cause : depuis une certaine mise à jour du JDK, l'authentification Basic pour les tunnels CONNECT est désactivée par défaut. Un drapeau JVM vidant jdk.http.auth.tunneling.disabledSchemes a résolu le problème. Ici, c'est précisément le fait que le proxy HTTP réponde par un code lisible qui a été utile : le code 407 a immédiatement indiqué la direction de recherche, alors que SOCKS5 dans une situation analogue aurait renvoyé 05 FF, et sans connaissance du protocole, il aurait été plus difficile de comprendre.

Idées reçues fréquentes

• « SOCKS5 est plus sûr que le proxy HTTP. » Pour le trafic chiffré, les deux protocoles offrent à l'intermédiaire une visibilité identique : hôte, port, timings, volumes, SNI. La sécurité du contenu est assurée par TLS, pas par le protocole proxy. La différence n'existe que pour HTTP non chiffré, où le proxy HTTP transparent voit tout.
• « Le proxy HTTP ne fonctionne pas avec HTTPS. » Il fonctionne via CONNECT. C'est un mécanisme standard et omniprésent, c'est ainsi que tous les navigateurs accèdent aux sites HTTPS via des proxy d'entreprise.
• « SOCKS5 est plus rapide parce que binaire. » À l'établissement de connexion, SOCKS5 avec autorisation dépense plus de RTT que HTTP CONNECT. À la transmission de données, les deux n'ajoutent rien : après la poignée de main, c'est un pur tuyau TCP dans les deux cas. La vitesse est déterminée par le canal du proxy, pas par le protocole.
• « CONNECT ne sert qu'au port 443. » Le standard ne limite pas le port. Ce sont les configurations de proxy spécifiques qui imposent des restrictions.
• « SOCKS5 résout toujours le domaine côté proxy. » Seulement si le client transmet ATYP=0x03. Beaucoup de bibliothèques résolvent localement par défaut et transmettent une IP.
• « Le proxy HTTP ajoute toujours X-Forwarded-For et révèle mon IP. » C'est le comportement de configurations d'entreprise spécifiques, pas une propriété du protocole. Les proxy commerciaux n'ajoutent pas ces en-têtes, et en mode CONNECT, il est physiquement impossible de les ajouter.
• « Le proxy voit mon mot de passe proxy en clair, donc aussi celui du site. » Le mot de passe proxy est transmis au proxy et, conformément au standard, n'est pas retransmis plus loin. Le mot de passe du site à l'intérieur du tunnel TLS n'est pas visible par le proxy.
• « Comme SOCKS5 n'analyse pas le contenu, on ne peut pas le restreindre. » Le proxy peut restreindre par hôte cible, port, volume, vitesse et nombre de connexions. Simplement pas par URL.
• « Les ports HTTP et SOCKS5 chez un même fournisseur sont des serveurs différents. » En règle générale, c'est un seul serveur et une seule IP de sortie, seul le protocole en entrée diffère. Chez Proxeon, c'est exactement le cas.
• « Dans le navigateur, SOCKS5 avec mot de passe se configure comme HTTP. » Non, les paramètres système de Chromium et Firefox ne transmettent pas d'identifiants en SOCKS5. Il faut l'autorisation par IP ou une extension.

FAQ

Le site cible peut-il déterminer si je suis passé par un proxy HTTP ou SOCKS5 ?

Non. Le serveur cible ne voit que la seconde connexion, du proxy vers lui, et elle représente dans les deux cas un simple TCP depuis l'adresse IP du proxy. Seule exception : un proxy HTTP transparent qui ajoute des en-têtes Via ou X-Forwarded-For. En mode CONNECT et en SOCKS5, c'est impossible.

Si j'utilise un proxy HTTP pour HTTPS, le proxy peut-il espionner ou substituer le contenu ?

Seulement s'il effectue une interception TLS avec substitution de certificat, et alors votre client verra une erreur de vérification de certificat, à moins que vous n'ayez installé manuellement le certificat racine de confiance de ce proxy. En fonctionnement normal, après CONNECT, le proxy voit un flux chiffré et ne peut ni le lire ni le modifier.

Pourquoi SOCKS5 avec mot de passe ne fonctionne pas dans Chrome, alors que le proxy HTTP avec mot de passe fonctionne ?

L'implémentation de la pile réseau de Chromium prend en charge le dialogue d'authentification pour le proxy HTTP via le mécanisme 407, mais n'implémente pas la méthode 0x02 de la RFC 1929 pour SOCKS5. C'est une décision des développeurs du navigateur, pas une limitation du protocole. Solution : autorisation par adresse IP dans l'espace client Proxeon ou extension gérant le proxy via l'API.

Que faire si le proxy renvoie REP=05 en SOCKS5 ?

Le code 05 signifie que le serveur cible a refusé la connexion TCP : port fermé, service non démarré, ou pare-feu de la cible bloquant l'IP du proxy. Vérifiez que vous avez transmis le bon port, et essayez une autre adresse proxy. Le proxy lui-même fonctionne correctement, le problème est sur la seconde moitié du chemin.

Quelle est la différence entre REP=02 en SOCKS5 et 403 sur un proxy HTTP ?

Sémantiquement, c'est la même chose : le proxy a refusé d'établir la connexion selon ses propres règles. Cela signifie généralement que le port ou l'hôte cible est interdit par la politique du proxy. Le proxy HTTP inclut parfois une explication dans le corps de la réponse 403, SOCKS5 n'a qu'un octet.

Peut-on utiliser le même identifiant et mot de passe pour le port HTTP et le port SOCKS5 ?

Chez Proxeon, oui : le compte est commun, seuls le port et le protocole diffèrent. En changeant de protocole, pas besoin de changer les identifiants.

Comment savoir si mon client résout le domaine localement ou sur le proxy ?

La méthode la plus fiable : lancer une capture de trafic sur votre interface et regarder si une requête DNS vers le domaine cible part avant la connexion au proxy. Plus simple : indiquer temporairement dans le fichier hosts une adresse manifestement erronée pour le domaine cible. Si la requête via le proxy continue de fonctionner, c'est le proxy qui résout. Si elle casse, c'est le client.

Faut-il utiliser HTTP/2 vers le proxy si la bibliothèque le prend en charge ?

Si vous avez beaucoup de connexions parallèles vers différentes cibles et que le client multiplexe réellement les flux CONNECT, le gain sera notable : moins de connexions TCP, moins de poignées de main. Mais la prise en charge de cette possibilité dans les clients et serveurs proxy est encore inégale. Vérifiez la documentation de votre client et demandez si votre forfait prend en charge HTTP/2 en entrée.

Pourquoi dans un proxy HTTP l'URI absolue, alors qu'il y a l'en-tête Host ?

Le standard HTTP/1.1 exige du client qu'il utilise la forme absolue lorsqu'il s'adresse à un proxy, afin que le proxy comprenne sans ambiguïté que la requête doit être transmise, et non traitée localement. L'en-tête Host est conservé parce que le proxy transmettra la requête au serveur cible en origin-form, et Host y est obligatoire. La duplication est le prix de la compatibilité.

Qu'est-ce qui est le plus important pour le scraping : HTTP ou SOCKS5 ?

Pour des cibles HTTPS, il n'y a pas de différence de visibilité, la différence est dans le comportement de la bibliothèque. Si la bibliothèque fonctionne correctement avec SOCKS5 et transmet le domaine, prenez SOCKS5 : il ne risque pas d'intervenir dans les en-têtes et donne une résolution régionale correcte. Si la bibliothèque est capricieuse avec SOCKS5 ou si vous avez beaucoup de connexions courtes sans pool, HTTP CONNECT n'est pas moins bien. Le principal conseil : n'ouvrez pas une nouvelle connexion au proxy à chaque requête, c'est plus coûteux que n'importe quel choix de protocole.

Conclusion

Deux ports dans l'espace client, ce n'est pas une paire marketing « classique et avancé ». Ce sont deux langages de communication avec une même machine. Le proxy HTTP parle le langage des requêtes et des réponses, comprend la sémantique, peut mettre en cache et explique les erreurs avec des codes lisibles, et pour tout ce qu'il ne comprend pas, il a CONNECT, qui le transforme en tunnel TCP. SOCKS5 parle le langage « hôte et port », n'analyse pas le contenu, prend en charge n'importe quel protocole TCP et l'UDP, et permet de contrôler explicitement où le domaine est résolu.

Pour le trafic chiffré, les deux protocoles offrent à l'intermédiaire une visibilité identique. Le choix entre eux est déterminé non par la sécurité, mais par trois choses pratiques : ce que sait faire votre client, quel protocole est à l'intérieur, et où vous voulez résoudre les noms.

Que faire maintenant

1. Déterminez le protocole à l'intérieur de votre tâche. Pas HTTP : SOCKS5 d'emblée.
2. Vérifiez dans la documentation du client la prise en charge de SOCKS5 avec autorisation et l'option de résolution distante.
3. Si vous travaillez avec des ressources géodépendantes, assurez-vous que le domaine part vers le proxy : socks5h, remote DNS, ATYP=0x03 ou HTTP CONNECT.
4. Activez un pool de connexions ou le keep-alive vers le proxy. Cela apportera plus que n'importe quel changement de protocole.
5. Si le client ne sait pas transmettre d'identifiant en SOCKS5, configurez l'autorisation par IP dans l'espace client Proxeon.
6. Pour le débogage, commencez par curl -v : il montrera tout le dialogue avec le proxy et séparera immédiatement le problème client du problème réseau.

Et pour finir. Les deux protocoles sont plus anciens que la plupart des ingénieurs qui les utilisent, et tous deux fonctionnent encore sans changements de principe. C'est un cas rare où la simplicité du design l'a emporté. En comprenant ce qui se passe exactement dans les quarante premiers octets d'une connexion, vous cessez de choisir un port au hasard et vous commencez à choisir un outil.