envoy como http 2 front proxy - permitindo http 2 para envoy (aka h2)
O enviado de fora da caixa não está configurado para configurar conexões com clientes conectados a ele com o novo HTTP/2.
HTTP/2 é otimizado para a web moderna, com cabeçalhos binários, etc. - maior velocidade.
Como o envoy é capaz de falar HTTP/2 para os clientes, não é preciso ser muito esperto para configurar o serviço.
E a configuração é realmente fácil...também. Você apenas acrescenta um na linha de texto_comum_tls_contexto do seu ouvinte:
alpn_protocols: ["h2,http/1.1" ]
É isso mesmo. (As citações devem ser citações normais, caso o WordPress as estrague)
ALPN significa Negociação do Protocolo da Camada de Aplicação - é aparentemente necessário para que o HTTP/2 funcione.
Por padrão, o filtro http_connection_manager envoy irá suportar ambos HTTP1 e HTTP2 no modo AUTO.
Ao adicionar os protocolos alpn, você permite que essa funcionalidade seja realmente utilizada.
Meu enviado.yaml para sua referência
Eu vou reproduzir todo o meu enviado.yaml para que se veja o contexto em que a linha tem de ser colocada:
estática_recursos:
Ouvintes:
- morada:
endereço_da_cova:
morada: 0.0.0.0
port_value: 80
filter_chains:
- filtros:
- nome: envoy.http_connection_manager
configurar:
codec_type: auto
stat_prefix: ingresso_http
route_config:
virtual_hosts:
- nome: backend
domínios: [“*”]
rotas:
- ...partida: Prefixo: “/” }
redireccionar:
path_redirect: "/"
https_redirect: true
http_filters:
- nome: envoy.router
configurar: {}
- morada:
endereço_da_cova:
morada: 0.0.0.0
port_value: 443
filter_chains:
- tls_context:
texto_comum_tls_context:
tls_certificates:
- cadeia_cade certificado: { nome do ficheiro: "/etc/example-com.crt" }
private_key: { filename: "/etc/example-com.key" }
alpn_protocols: ["h2,http/1.1" ]
filtros:
- nome: envoy.http_connection_manager
configurar:
stat_prefix: ingresso_https
route_config:
virtual_hosts:
- nome: backend
domínios: [“*”]
rotas:
- ...partida: Prefixo: “/” }
rota: { cluster: target_taxgod }
http_filters:
- nome: envoy.router
configurar: {}
grupos:
- nome: target_taxgod
connect_timeout: 0.25s
tipo: strict_dns
lb_policy: round_robin
anfitriões:
- endereço_da_cova:
endereço: taxgod
port_value: 3000
administração:
access_log_path: "/tmp/envoy.log"
morada:
endereço_da_cova:
morada: 0.0.0.0
port_value: 9901
Este enviado.yaml ouve na porta 80 e na porta 443. Os pedidos HTTP para a porta 80 são redirecionados para a porta 443. Todo o tráfego é enviado para um container "taxgod" na mesma rede de docas. Consulte este artigo por mim para obter detalhes.
Por favor, não espere que a cópia colada a tudo isto funcione - o WordPress infelizmente é demasiado inteligente para o seu próprio bem, por vezes, e mexe em todo o tipo de caracteres e formatação de código.
Referências:
- https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation
- https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/network/http_connection_manager/v2/http_connection_manager.proto#enum-config-filter-network-http-connection-manager-v2-httpconnectionmanager-codectype
- https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/ssl.html?highlight=common
- https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto.html?highlight=common#auth-commontlscontext -> Consegui a informação de como configurar o alpn corretamente (onde colocá-lo no arquivo de configuração, e o que colocar dentro dele) a partir daqui
- https://github.com/envoyproxy/envoy/issues/3394 -> isto fez-me começar na direcção certa. Eu nunca tinha ouvido falar da ALPN antes de ler isto.