Concepts

Comment choisir entre TCP, Vision et QUIC

Choisissez le mode adapté au réseau et au trafic applicatif, avec des chemins TCP et UDP distincts derrière une même entrée SOCKS5.

Version concernée 1.0.0-alphaTraduit

Vue d’ensemble

Distinguez d’abord deux questions : l’application envoie-t-elle du TCP ou de l’UDP ? Umbra utilise-t-il TCP ou QUIC pour acheminer ce trafic au serveur ? Le type de trafic applicatif et le transport extérieur sont deux choses différentes. transport sélectionne le transport extérieur principal ; udp_transport permet de choisir séparément celui des requêtes UDP et, s’il est omis, reprend la valeur de transport.

Choisir selon vos besoins

Besoin ou condition réseauPoint de départÀ prendre en compte
Établir d’abord la connexion, ou contourner un filtrage d’UDP par le réseautransport = "tcp"Ouvrez le port TCP sur le serveur ; mux est activé par défaut
Réutiliser une connexion existante pour plusieurs requêtes TCP simultanéesTCP + mux = trueLes flux partagent le TCP extérieur ; les pertes de paquets peuvent toujours affecter les autres flux
Réduire le double chiffrement du trafic éligible, principalement HTTPSTCP + mux = falseUtilise des connexions Vision dédiées ; tous les trafics TLS ne peuvent pas bénéficier du transfert direct
Subir des réinitialisations TCP RST fréquentes alors qu’UDP est accessibletransport = "quic"QUIC doit être disponible aux deux extrémités ; UDP peut lui aussi être limité ou bloqué
Garder TCP sur Vision et acheminer UDP séparément par QUICTCP + udp_transport = "quic" + mux = falseActivez les écoutes TCP et UDP sur le même serveur

Aucun mode n’est le plus rapide sur tous les réseaux. Vérifiez d’abord la connectivité, puis comparez la latence, la stabilité et le débit de vos applications réelles ; ne modifiez pas plusieurs paramètres à la fois. Ces choix n’entraînent ni détection automatique du réseau ni changement automatique de transport.

Multiplexage TCP

transport = "tcp"
mux = true

Plusieurs requêtes partagent une connexion extérieure chiffrée, ce qui réduit les besoins de rétablissement de connexions. La version actuelle ajuste les fenêtres selon la consommation réelle de trafic et le temps aller-retour, dans les limites d’un budget mémoire. Ce mode peut convenir aux requêtes simultanées, mais il ne supprime pas le blocage en tête de ligne au niveau du transport TCP.

Le mux adaptatif exige des versions compatibles aux deux extrémités ; lors du passage à 1.0.0-alpha, mettez à jour le client et le serveur ensemble. Les paramètres de ressources figurent dans la référence de configuration.

TCP / Vision dédié

transport = "tcp"
mux = false

Pour le trafic TLS 1.3 interne éligible, une fois la frontière de transfert négociée de manière authentifiée, les enregistrements TLS déjà chiffrés peuvent être transmis sans poursuivre le chiffrement TLS extérieur ni l’encapsulation supplémentaire. Le trafic non TLS ou TLS non pris en charge reste chiffré : activer Vision ne transmet pas les données applicatives en clair.

Vision utilise des entrées-sorties en espace utilisateur, pas le zéro copie du noyau. La réduction des traitements redondants est un avantage du mécanisme, pas un gain de vitesse mesuré face à la concurrence. Continuez à utiliser HTTPS au niveau applicatif.

QUIC

transport = "quic"

QUIC fonctionne sur UDP. Il permet d’éviter l’injection de TCP RST ainsi que le blocage en tête de ligne entre différents flux QUIC dû aux retransmissions de la couche transport ; au sein d’un même flux fiable, la livraison reste ordonnée, et tous les flux partagent la capacité du chemin et le contrôle de congestion. Le serveur doit activer udp_listen, ouvrir le port UDP dans le pare-feu et pouvoir joindre le véritable site QUIC de repli configuré.

Quinn BBR est actuellement utilisé par défaut ; cubic et new-reno sont également disponibles. Ces réglages concernent QUIC et ne modifient pas le contrôle de congestion TCP de Linux. Si le réseau limite UDP, QUIC n’est pas un substitut fiable à TCP.

TCP / Vision + QUIC UDP

Ajoutez à votre configuration client complète :

transport = "tcp"
udp_transport = "quic"
mux = false
socks_listen = "127.0.0.1:1080"

Sur le même serveur, configurez simultanément :

listen = "0.0.0.0:443"
udp_listen = "0.0.0.0:443"

Ces extraits sont à intégrer à une configuration complète : ils ne remplacent ni les clés, ni le véritable site de destination, ni les autres champs obligatoires. Un client, un serveur et un point d’entrée SOCKS5 local suffisent pour ces deux chemins. Dans un client de type Clash, udp: true autorise simplement les requêtes UDP ; il ne force pas les requêtes TCP ordinaires à passer par QUIC.

Remplissage et stratégie d’écriture TCP

Le remplissage par défaut ajoute des données de longueur aléatoire au début de la connexion, puis en réduit la fréquence. Il vise à perturber l’identification directe de la négociation interne à partir de la longueur des enregistrements. Il consomme de la bande passante supplémentaire et ne promet pas d’effacer toutes les caractéristiques du trafic. Conservez généralement padding_scheme = "default" et ne le modifiez que sur la base de tests précis.

tcp_evasion = "segment" ne fait que découper le ClientHello en écritures applicatives ordonnées ; il ne garantit pas les limites des paquets TCP effectivement émis par le système d’exploitation. En cas de problème de compatibilité, vous pouvez tester off. Geneva DSL n’est pas pris en charge actuellement et ne doit pas être déployé comme une fonctionnalité disponible.

Pour continuer

Sur cette page