--- title: Вибір протоколу description: Інформація про те, як вказати протоколи. weight: 10 keywords: [protocol,protocol sniffing,protocol selection,protocol detection] aliases: - /uk/help/ops/traffic-management/protocol-selection - /uk/help/ops/protocol-selection - /uk/help/tasks/traffic-management/protocol-selection - /uk/docs/ops/traffic-management/protocol-selection owner: istio/wg-networking-maintainers test: n/a --- Istio підтримує проксіювання будь-якого TCP трафіку. Це включає HTTP, HTTPS, gRPC, а також необроблений TCP протоколи. Для надання додаткових можливостей, таких як маршрутизація і розширені метрики, протокол повинен бути визначений. Це можна зробити автоматично або явно вказати. Протоколи, які не базуються на TCP, такі як UDP, не проксіюються. Ці протоколи продовжать працювати як зазвичай, без будь-якого перехоплення з боку проксі Istio, але не можуть використовуватися в компонентах проксі, таких як шлюзи вхідного або вихідного трафіку. ## Автоматичний вибір протоколу {#automatic-protocol-selection} Istio може автоматично виявляти HTTP та HTTP/2 трафік. Якщо протокол не може бути автоматично визначено, трафік буде оброблятися як звичайний TCP трафік. {{< tip >}} Протоколи Server First, такі як MySQL, несумісні з автоматичним вибором протоколу. Див. [Протоколи Server First](/docs/ops/deployment/application-requirements#server-first-protocols) для отримання додаткової інформації. {{< /tip >}} ## Явний вибір протоколу {#explicit-protocol-selection} Протоколи можна вказати вручну в визначенні Сервісу. Це можна налаштувати двома способами: - За допомогою назви порту: `name: [-]`. - У Kubernetes 1.18+ за допомогою поля `appProtocol`: `appProtocol: `. Якщо обидва визначені, `appProtocol` має перевагу над назвою порту. Зверніть увагу, що поведінка у Gateway відрізняється в деяких випадках, оскільки шлюз може термінувати TLS і протокол може бути погоджено. Підтримуються наступні протоколи: | Протокол | Мета Sidecar | Мета Gateway | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `http` | Plaintext HTTP/1.1 трафік | Plaintext HTTP (1.1 або 2) трафік | | `http2` | Plaintext HTTP/2 трафік | Plaintext HTTP (1.1 або 2) трафік | | `https` | Шифровані TLS дані. Оскільки Sidecar не розшифровує TLS трафік, це те ж саме, що і `tls` | Шифрований TLS HTTP (1.1 або 2) трафік | | `tcp` | Непрозорий TCP потік даних | Непрозорий TCP потік даних | | `tls` | Шифровані TLS дані | Шифровані TLS дані | | `grpc`, `grpc-web` | Те ж саме, що і `http2` | Те ж саме, що і `http2` | | | `mongo`, `mysql`, `redis` | Експериментальна підтримка протоколу застосунків. Щоб увімкнути їх, налаштуйте відповідні [змінні середовища](/docs/reference/commands/pilot-discovery/#envvars). Якщо не увімкнено, обробляються як непрозорий TCP потік даних | Експериментальна підтримка протоколу застосунків. Щоб увімкнути їх, налаштуйте відповідні [змінні середовища](/docs/reference/commands/pilot-discovery/#envvars). Якщо не увімкнено, обробляються як непрозорий TCP потік даних | Нижче наведено приклад Сервісу, який визначає порт `https` за допомогою `appProtocol` і порт `http` за допомогою назви: {{< text yaml >}} kind: Service metadata: name: myservice spec: ports: - port: 3306 name: database appProtocol: https - port: 80 name: http-web {{< /text >}} ## Вибір протоколу HTTP gateway {#http-gateway-protocol-selection} На відміну від sidecars, шлюзи стандартно не можуть автоматично визначити конкретний HTTP протокол для використання при пересиланні запитів до бекенд-сервісів. Тому, якщо явний вибір протоколу не використовується для вказання HTTP/1.1 (`http`) або HTTP/2 (`http2` або `grpc`), шлюзи будуть пересилати всі вхідні HTTP запити, використовуючи HTTP/1.1. Замість використання явного вибору протоколу, ви можете інструктувати шлюзи пересилати запити, використовуючи той самий протокол, як і вхідний запит, налаштувавши [`useClientProtocol`](/docs/reference/config/networking/destination-rule/#ConnectionPoolSettings-HTTPSettings) для Сервісу. Зверніть увагу, що використання цієї опції з сервісами, які не підтримують HTTP/2, може бути ризикованим, оскільки HTTPS шлюзи завжди [оголошують](https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation) підтримку для HTTP/1.1 та HTTP/2. Тому навіть коли бекенд сервіс не підтримує HTTP/2, сучасні клієнти часто вибирають його.