> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Le protocole composable permet de configurer plus souplement l'accès TCP au serveur ClickHouse. # protocole composable

## Vue d’ensemble

Les protocoles composables permettent une configuration plus souple de l’accès TCP au serveur ClickHouse. Cette configuration peut coexister avec la configuration classique ou la remplacer.

## Configuration des protocoles composables

Les protocoles composables peuvent être configurés dans un fichier de configuration XML. La section `protocols` du fichier de configuration XML correspond à la section des protocoles : ```xml theme={null} ```

### Configuration des couches de protocole

Vous pouvez définir des couches de protocole à l’aide de modules de base. Par exemple, pour définir une couche HTTP, vous pouvez ajouter un nouveau module de base dans la section `protocols` : ```xml theme={null} http ``` Les modules peuvent être configurés comme suit : * `plain_http` - nom auquel une autre couche peut faire référence * `type` - indique le gestionnaire de protocole qui sera instancié pour traiter les données. Il peut prendre les gestionnaires de protocole prédéfinis suivants : * `tcp` - gestionnaire du protocole natif ClickHouse * `http` - gestionnaire du protocole HTTP ClickHouse * `tls` - couche de chiffrement TLS * `proxy1` - couche PROXYv1 * `mysql` - gestionnaire du protocole de compatibilité MySQL * `postgres` - gestionnaire du protocole de compatibilité PostgreSQL * `prometheus` - gestionnaire du protocole Prometheus * `interserver` - gestionnaire interserver ClickHouse Le gestionnaire de protocole `gRPC` n'est pas implémenté pour `protocole composable`

### Configuration des points de terminaison

Les points de terminaison (ports d’écoute) sont indiqués par les balises facultatives `` et ``. Par exemple, pour configurer un point de terminaison sur la couche HTTP ajoutée précédemment, nous pourrions modifier notre configuration comme suit : ```xml theme={null} http 127.0.0.1 8123 ``` Si la balise `` est absente, le `` de la configuration racine est utilisé.

### Configuration des séquences de couches

Les séquences de couches sont définies à l’aide de la balise ``, en faisant référence à un autre module. Par exemple, pour configurer une couche TLS au-dessus de notre module plain\_http, nous pourrions modifier davantage notre configuration comme suit : ```xml theme={null} http tls plain_http 127.0.0.1 8443 ```

### Associer des points de terminaison à des couches

Des points de terminaison peuvent être associés à n’importe quelle couche. Par exemple, nous pouvons définir des points de terminaison pour HTTP (port 8123) et HTTPS (port 8443) : ```xml theme={null} http 127.0.0.1 8123 tls plain_http 127.0.0.1 8443 ```

### Définir des points de terminaison supplémentaires

Des points de terminaison supplémentaires peuvent être définis en faisant référence à n’importe quel module et en omettant la balise ``. Par exemple, nous pouvons définir le point de terminaison `another_http` pour le module `plain_http` comme suit : ```xml theme={null} http 127.0.0.1 8123 tls plain_http 127.0.0.1 8443 plain_http 127.0.0.1 8223 ```

### Gestionnaires HTTP personnalisés par point de terminaison

Par défaut, toutes les entrées de protocole `type=http` partagent la même configuration ``. Vous pouvez remplacer ce comportement en ajoutant une balise `` qui pointe vers une autre section de configuration. Cela permet à chaque port HTTP d'utiliser un ensemble différent de règles de routage HTTP. Par exemple, pour exécuter une API HTTP alternative sur le port 8124 avec ses propres gestionnaires : ```xml theme={null} http 127.0.0.1 8123 http 127.0.0.1 8124 http_handlers_alt /custom predefined_query_handler SELECT 'custom_endpoint' ``` Dans cet exemple, les requêtes vers le port 8123 utilisent les règles standard de ``, tandis que les requêtes vers le port 8124 utilisent les règles de ``. Si `` est omis, le point de terminaison revient à `` par défaut. La section des handlers personnalisés suit le même format que [``](/fr/reference/settings/server-settings/settings/http#http_handlers). Les modifications apportées à la section des handlers personnalisés sont détectées lors du rechargement de la config, et le point de terminaison correspondant est automatiquement redémarré.

### Utilisateur de session par défaut par point de terminaison

Lorsqu’un client se connecte sans spécifier de nom d’utilisateur (par exemple, une requête HTTP sans le paramètre `user`, ou un paquet `Hello` du protocole natif avec un nom d’utilisateur vide), le serveur l’authentifie en tant qu’utilisateur de session par défaut : le [paramètre du serveur](/fr/reference/settings/server-settings/settings) `default_session_user`, dont la valeur par défaut est `default`. La balise `` surcharge ce paramètre pour un point de terminaison donné. Cela permet à différents ports d’écoute de servir différents utilisateurs anonymes : ```xml theme={null} http 127.0.0.1 8123 plain_http 127.0.0.1 8124 readonly_user ``` Dans cet exemple, les requêtes sans informations d'identification sur le port 8123 sont authentifiées en tant qu' utilisateur de session `default` configuré globalement, tandis que celles sur le port 8124 sont authentifiées en tant que `readonly_user`. Un client qui fournit explicitement un nom d'utilisateur n'est pas concerné. Le tag est recherché du module du point de terminaison vers les modules (`impl`) référencés, et la valeur la plus proche du point de terminaison l'emporte. Il s'applique aux gestionnaires de protocole `tcp`, `http`, `mysql` et `postgres`, ainsi qu'aux gestionnaires `prometheus` qui authentifient les requêtes (`remote_write`, `remote_read`, `query` et `api_v1`) ; les points de terminaison d'exposition des métriques (y compris les points de terminaison Keeper dédiés aux métriques uniquement) sont servis sans authentification et ignorent ce paramètre. Les gestionnaires avec un utilisateur fixe (la clé `user` dans `handler` d'une règle `http_handlers`, ou la clé `user` dans `handler` d'une règle `prometheus.handlers`) s'authentifient avec l'utilisateur configuré et ignorent également ce paramètre : en particulier, un `default_session_user` vide ne les rejette pas. Ce paramètre ne peut pas être utilisé avec le protocole `interserver` : les connexions interserveur sont authentifiées à l'aide du secret du cluster et de l'utilisateur initial, et n'utilisent jamais l'utilisateur de session `default`.

### Spécification de paramètres supplémentaires pour la couche

Certains modules peuvent inclure des paramètres de couche supplémentaires. Par exemple, la couche TLS permet de spécifier un fichier de clé privée (`privateKeyFile`) et un fichier de certificat (`certificateFile`) comme suit : ```xml theme={null} http 127.0.0.1 8123 tls plain_http 127.0.0.1 8443 another_server.key another_server.crt ```