Proxys SOCKS ou HTTP : différences, vitesse et choix du protocole
Les proxys HTTP et SOCKS relient une application à une destination par un intermédiaire. Pour un navigateur, un outil de collecte web ou un client API, un proxy HTTP avec CONNECT constitue un point de départ pratique. SOCKS5 est utile lorsque l’application attend SOCKS, utilise d’autres protocoles TCP ou prend en charge la transmission UDP. Les deux peuvent acheminer du trafic vers des sites HTTPS.
Le protocole détermine comment le programme communique avec le proxy. L’origine de l’IP de sortie, la rotation et l’accès partagé ou dédié sont des choix distincts, expliqués dans le guide des types de proxys et du choix d’une configuration. Passer de HTTP à SOCKS ne modifie pas en soi ces caractéristiques.
Comment HTTP et SOCKS gèrent une connexion
Transmission HTTP : le proxy traite une requête web
Pour une requête HTTP ordinaire non chiffrée, le client envoie au proxy l’URL de destination, la méthode et les en-têtes. Le proxy traite cette requête et obtient la réponse de la destination. Il peut appliquer des règles HTTP, modifier les en-têtes ou utiliser un cache s’il est configuré pour cela. Ce sont des fonctions possibles d’un proxy HTTP ; un service ne les active pas nécessairement toutes.
SOCKS5 : le proxy ouvre une connexion pour l’application
Le client convient d’une méthode d’authentification, s’authentifie si nécessaire, puis fournit une adresse et un port de destination. Le proxy établit alors la connexion TCP demandée et relaie les octets de l’application. Le même mécanisme peut transporter HTTPS, SSH ou un autre protocole applicatif TCP pris en charge. Le proxy n’a pas besoin d’interpréter les requêtes HTTP pour les transmettre.
HTTPS via CONNECT : les deux approches se rapprochent
Lorsqu’il ouvre un site HTTPS par un proxy HTTP classique, le client envoie normalement une requête CONNECT. Une fois le tunnel accepté par le proxy, le client y établit une connexion TLS avec le site. Le proxy relaie les données chiffrées. SOCKS5 peut relayer le même échange TLS après sa propre phase d’établissement.
Cela compte pour comparer la vitesse et la confidentialité : un proxy HTTP transportant HTTPS dans un tunnel n’analyse pas chaque requête de page chiffrée. Les deux types relaient le trafic protégé. La séquence et la distinction entre transmission HTTP et tunnellisation sont expliquées dans Proxys HTTP et HTTPS.
HTTP et SOCKS5 en un coup d’œil
La comparaison ci-dessous porte sur SOCKS5. Les anciennes versions SOCKS4 et SOCKS4a ont moins de possibilités et sont surtout pertinentes lorsqu’un logiciel existant les exige.
| Fonction | Proxy HTTP / HTTPS | Proxy SOCKS5 |
|---|---|---|
| Requêtes web | Transmission HTTP ; HTTPS utilise généralement un tunnel CONNECT. | L’application envoie HTTP ou HTTPS par la connexion établie. |
| Autres applications TCP | Possibles via CONNECT si le client le prend en charge et si le port de destination est autorisé. | Adapté aux applications prenant en charge SOCKS ; les règles du service restent applicables. |
| DNS de la destination | Le proxy peut résoudre le nom d’hôte fourni dans la requête ou comme cible de CONNECT. | Le client peut envoyer un nom d’hôte à résoudre à distance ou le résoudre d’abord localement. |
| Protection jusqu’au proxy | Un proxy HTTPS utilise TLS sur cette connexion. Un proxy HTTP simple ne le fait pas. | Les modes ordinaires sans authentification et avec nom d’utilisateur et mot de passe ne chiffrent pas cette connexion. |
| Contrôle d’accès | Méthodes d’authentification HTTP et/ou règles d’accès du service, comme une liste d’IP autorisées. | Méthodes d’authentification négociées et/ou règles d’accès du service, comme une liste d’IP autorisées. |
| UDP | Un tunnel CONNECT ordinaire ne suffit pas. UDP nécessite un mécanisme de tunnellisation supplémentaire pris en charge. | Prévu par le protocole, mais doit être implémenté par le client et le service. |
| Performances | Pour un nouveau tunnel HTTPS, l’établissement peut demander moins d’allers-retours. La vitesse de transfert dépend aussi de l’implémentation et du trajet réseau. | Comporte ses propres échanges d’établissement. L’absence d’analyse HTTP ne garantit pas des transferts HTTPS plus rapides. |
Quel est le plus rapide : HTTP ou SOCKS5 ?
Une nouvelle connexion HTTPS peut être prête plus vite via HTTP CONNECT, car l’établissement habituel demande moins d’échanges avec le proxy. La comparaison ci-dessous précise les hypothèses qui expliquent cet écart. Une fois un tunnel ouvert, un téléchargement long ou des requêtes ultérieures peuvent le réutiliser. Aucun protocole ne possède un avantage constant en vitesse de transfert soutenu.
Nouvelles connexions : comptez les échanges
Comptez les messages d’établissement une fois la connexion TCP au proxy prête, chaque requête attendant sa réponse. Cette comparaison n’utilise pas de couche TLS jusqu’au proxy. L’authentification HTTP est soit inutile, soit réussie avec les identifiants inclus dans la première requête CONNECT.
| Méthode de connexion | Échanges avant que le tunnel soit prêt |
|---|---|
HTTP CONNECT | 1 : la requête CONNECT et sa réponse de réussite. |
| SOCKS5 sans authentification du protocole | 2 : la sélection de la méthode, puis la demande de connexion et sa réponse. |
| SOCKS5 avec nom d’utilisateur et mot de passe | 3 : la sélection de la méthode, la vérification du nom d’utilisateur et du mot de passe, puis la demande de connexion et sa réponse. |
Dans ces hypothèses, SOCKS5 ajoute donc un aller-retour entre le client et le proxy sans authentification, ou deux avec l’authentification standard par nom d’utilisateur et mot de passe. Un aller-retour, ou RTT, est le temps nécessaire pour qu’un message atteigne le proxy et que sa réponse revienne. Avec un RTT d’exemple de 50 ms, ces échanges supplémentaires représentent environ 50 ou 100 ms. Il s’agit d’une estimation tirée de la séquence du protocole, pas d’une mesure des performances d’un service de proxys ni du temps total d’une requête.
Les deux méthodes exigent aussi que le proxy se connecte à la destination et que le client termine l’établissement TLS avec le site. Le temps DNS, le traitement et la congestion peuvent varier. Un défi d’authentification HTTP ajoute des échanges ; TLS jusqu’à un proxy HTTPS ajoute sa propre phase d’établissement. Ces cas doivent être inclus dans la comparaison des configurations réelles.
Connexions réutilisées : l’écart initial se répartit entre les requêtes
Un pool de connexions garde des connexions adaptées disponibles pour les requêtes suivantes. Réutiliser une connexion HTTPS évite de répéter l’établissement TCP, la négociation avec le proxy et la négociation TLS avec le site pour chaque requête. Si le client et la destination prennent en charge HTTP/2, plusieurs flux de requêtes peuvent partager une même connexion établie. Cela peut fonctionner dans un tunnel HTTP CONNECT comme dans une connexion SOCKS5 ; le proxy n’a pas besoin d’analyser les messages HTTP/2 à l’intérieur de TLS.
Créer un nouvel objet client HTTP pour chaque URL peut supprimer son pool de connexions. Ici, réutiliser un client signifie conserver l’objet logiciel et ses connexions, et non demander au proxy de maintenir une IP de sortie. Lorsqu’un lot contacte régulièrement les mêmes hôtes, la réutilisation de ces connexions peut économiser plus de travail d’établissement qu’un changement de protocole proxy. De nouvelles destinations, des connexions fermées et des paramètres proxy modifiés peuvent tout de même exiger de nouveaux tunnels.
Transferts volumineux : examinez la bande passante disponible
Une fois le tunnel établi, la vitesse de téléchargement dépend du trajet réseau, de la perte de paquets, de la bande passante disponible, de la charge du proxy et des limites du service. Relayer HTTPS via CONNECT est déjà une opération de transmission d’octets. Présenter SOCKS5 comme plus rapide parce qu’il « ne lit pas HTTP » ne tient pas compte de ce cas.
Pour HTTP non chiffré, un cache ou un traitement du contenu configuré peut modifier le résultat. Une réponse en cache représente une charge de travail différente du téléchargement du même contenu depuis le serveur d’origine. Une comparaison équitable doit tenir compte de cette différence.
Quel protocole utiliser pour un script web à grande échelle ?
Un script web continue d’émettre des requêtes HTTP lorsqu’il utilise SOCKS5 ; l’option proxy change la façon dont il atteint le serveur. Pour un nouveau script qui récupère des pages web ou appelle des API HTTPS, commencez par un client HTTP éprouvé et HTTP CONNECT, sauf si une exigence précise vous oriente ailleurs. Gardez le choix du proxy dans la configuration afin de tester SOCKS5 avec la même logique de requêtes. Choisissez une bibliothèque prenant en charge les deux si cette comparaison compte pour le projet.
| Charge de travail | Point de départ pratique |
|---|---|
| Nombreuses requêtes courtes, souvent vers de nouveaux hôtes | Essayez d’abord HTTP CONNECT. Sa négociation plus courte peut être utile lorsque les nouveaux tunnels sont fréquents. Mesurez les requêtes complètes réussies. |
| Nombreuses requêtes vers un petit ensemble d’API ou de sites | Utilisez un client persistant, un pool de connexions et HTTP/2 lorsque c’est pris en charge. Comparez HTTP et SOCKS5 après avoir vérifié la réutilisation. |
| Fichiers volumineux ou sessions TCP de longue durée | Choisissez le protocole bien pris en charge et testez le débit soutenu ainsi que les interruptions. Le temps d’établissement représente une part plus faible du travail. |
| Autres protocoles TCP ou fonction UDP nécessaire | Envisagez SOCKS5 si l’application prend en charge le mode requis. Si UDP est indispensable, vérifiez que l’application et le service peuvent échanger des datagrammes par le proxy. |
HTTP comme SOCKS5 peuvent être utilisés par des logiciels asynchrones. Le protocole proxy ne détermine pas si les requêtes s’exécutent simultanément. Vérifiez que la bibliothèque cliente peut utiliser le mode proxy choisi pour des requêtes concurrentes, conserver son pool de connexions et limiter le nombre d’opérations en cours. Augmentez la concurrence en surveillant le travail accompli et les erreurs : une fois la limite du proxy, du réseau ou de la destination atteinte, davantage de connexions peut entraîner des files d’attente plus longues et davantage de nouvelles tentatives.
Comment comparer la vitesse avant de passer à l’échelle
- Utilisez le même programme, les mêmes requêtes de destination, les mêmes tailles de réponse et le même niveau de concurrence. Si possible, comparez des points de connexion de protocoles utilisant la même IP de sortie et le même trajet ; sinon, gardez une région de sortie et des limites de service comparables, et notez la différence.
- Exécutez une série avec de nouvelles connexions et une autre avec la réutilisation habituelle du pool après une phase de démarrage. Gardez le même comportement DNS, la même protection TLS, la même authentification, la même version HTTP et la même politique de nouvelles tentatives, ou documentez les raisons des différences.
- Mesurez le nombre d’opérations terminées avec succès par seconde et le temps du lot entier, nouvelles tentatives comprises. Notez aussi le temps de réalisation médian et le 95e percentile, les expirations et les opérations échouées. Le 95e percentile indique le temps dans lequel 95% des opérations mesurées sont terminées.
- Pour les téléchargements, notez les octets utiles reçus par seconde. Pour les requêtes courtes, distinguez l’établissement de la connexion, le temps jusqu’au premier octet et le temps de réponse complet. Le temps jusqu’au premier octet inclut aussi l’attente de génération de la réponse par la destination.
- Répétez les exécutions en alternant les deux configurations et vérifiez le trajet proxy prévu. Si un test utilise un autre pool de sorties ou se rabat sur une connexion directe, son résultat n’isole pas l’effet du protocole proxy.
Choisissez la configuration qui accomplit le travail réel le plus vite avec un taux d’erreur acceptable. Un échec d’authentification rapide ou une réponse incomplète ne constitue pas un débit utile. Si les performances sont similaires, privilégiez la configuration la plus simple à prendre en charge dans l’application choisie.
Pourquoi la prise en charge par l’application passe en premier
Un champ intitulé « proxy » ne garantit pas tous les protocoles ni toutes les méthodes d’authentification. Par exemple, la prise en charge native de SOCKS5 dans Chrome permet les requêtes TCP, mais n’implémente ni l’authentification SOCKS5 par nom d’utilisateur et mot de passe ni la transmission UDP. Un service SOCKS5 doté de ces fonctions ne peut pas les rendre utilisables par un mode de navigateur qui ne les prend pas en charge.
Pour SSH, le transfert de fichiers ou une autre application TCP, une prise en charge native de SOCKS peut être pratique. HTTP CONNECT peut aussi transporter d’autres protocoles TCP, à condition que le programme sache créer le tunnel et que le proxy autorise le port de destination. « Proxy HTTP » ne signifie donc pas toujours « trafic web uniquement ».
Les paramètres proxy du navigateur ne couvrent pas non plus automatiquement un autre programme ou toutes les fonctions du navigateur. Les adaptateurs externes ont leur propre périmètre et leurs propres restrictions. Les différences entre versions et la négociation sont traitées dans Proxys SOCKS5 et SOCKS4.
Qui résout le nom d’hôte de la destination ?
Avec SOCKS5, l’application peut résoudre la destination localement et envoyer une adresse IP, ou envoyer un nom d’hôte que le proxy résoudra. Dans curl, socks5:// sélectionne la résolution locale de la destination, tandis que socks5h:// demande sa résolution par le proxy. La lettre supplémentaire sélectionne un comportement du client ; elle ne crée pas un nouveau protocole SOCKS.
Les proxys HTTP peuvent aussi résoudre les noms de destination reçus dans les URL ou les requêtes CONNECT. La résolution DNS distante de la destination est donc disponible avec les deux protocoles. Une résolution effectuée du côté du proxy peut renvoyer une autre adresse de serveur et évite une résolution locale pour cette destination. Le client peut tout de même devoir résoudre le nom d’hôte du proxy, et les autres applications conservent leurs propres paramètres DNS. Choisissez le comportement DNS dans le client au lieu de le déduire du protocole proxy.
Quelle connexion est chiffrée ?
Distinguez la protection du contenu du site et celle de la connexion au proxy. Un site HTTPS maintient normalement les données applicatives chiffrées entre le client et le site à travers l’un ou l’autre type de tunnel. Cela suppose une validation normale des certificats et aucune interception TLS configurée.
Un proxy HTTPS ajoute TLS entre le client et le proxy. Il protège la requête au proxy et les identifiants sur cette partie du trajet. Dans une adresse proxy, https:// désigne normalement cette connexion protégée. Un paramètre décrit seulement comme « proxy pour les sites HTTPS » peut en revanche désigner un proxy HTTP simple prenant en charge CONNECT.
Les identifiants HTTP Basic envoyés à un proxy HTTP simple et l’échange SOCKS5 standard de nom d’utilisateur et mot de passe sont lisibles par une personne capable d’observer ce trajet réseau non protégé. La connexion TLS ultérieure au site web ne protège pas rétroactivement les identifiants du proxy. SOCKS5 ordinaire nécessite un transport sécurisé distinct lorsque cette protection est requise.
Le proxy reste une extrémité de sa propre connexion TLS et connaît la destination à laquelle on lui demande de se connecter. Si la destination finale utilise HTTP simple, TLS jusqu’au proxy ne chiffre pas la connexion HTTP qui suit. De même, la transmission SOCKS ne masque pas le contenu en clair simplement parce que le proxy n’a pas besoin de l’analyser.
UDP ou HTTP/3 modifient-ils le choix ?
Pour une application qui a réellement besoin d’UDP, SOCKS5 définit UDP ASSOCIATE. Le client et le service doivent l’implémenter, et le trajet réseau doit acheminer les datagrammes. HTTP CONNECT ordinaire transporte un tunnel TCP. La transmission UDP fondée sur HTTP est possible avec des mécanismes supplémentaires comme CONNECT-UDP, mais les deux extrémités doivent les implémenter.
HTTP/3 utilise QUIC sur UDP. Le chargement réussi d’une page HTTPS par un proxy ne prouve pas que HTTP/3 fonctionne : le client peut avoir utilisé HTTP/2 ou HTTP/1.1 sur TCP. Ce repli peut convenir à un script web ; il ne peut pas remplacer UDP pour une fonction qui exige des datagrammes. Consultez UDP et QUIC via les proxys pour les trajets de transmission et leurs limites.
SOCKS masque-t-il mieux le client ?
Pour la transmission HTTP non chiffrée, un proxy peut ajouter un en-tête comme Forwarded contenant des informations sur le client d’origine. Un tunnel HTTPS CONNECT classique ne peut pas insérer cet en-tête dans la requête chiffrée sans terminer la connexion TLS du site. SOCKS5 n’ajoute pas non plus automatiquement d’en-têtes HTTP.
Aucun des deux protocoles ne constitue pour autant une garantie d’anonymat ou d’acceptation par un site web. L’opérateur du proxy peut observer les métadonnées de connexion, tandis que la destination peut reconnaître un compte, des cookies ou le comportement de l’application. La réputation de l’IP de sortie et le nombre d’utilisateurs qui la partagent sont des facteurs distincts. Passer de HTTP à SOCKS sur le même service ne supprime pas automatiquement les blocages et ne réinitialise pas une session web.
Comment arrêter votre choix
Commencez par les protocoles et les méthodes d’accès pris en charge par l’application. Pour l’automatisation web ordinaire, HTTP CONNECT est un bon premier choix ; pour une application conçue autour de SOCKS ou d’un mode UDP pris en charge, SOCKS5 peut mieux convenir. Choisissez ensuite le comportement DNS et la protection jusqu’au proxy nécessaires, puis comparez les performances avec la charge de travail réelle.
Utilisez le vrai nom d’hôte et le vrai port du service pour le protocole sélectionné. Remplacer http:// par socks5:// dans une configuration n’active pas SOCKS sur un serveur qui ne le propose pas. Avant de passer à l’échelle, vérifiez que les requêtes sortent par le proxy prévu et qu’une défaillance du proxy ne déclenche pas silencieusement une connexion directe indésirable.