AutorLuo Cheng
Editor | Xiaozhi
Ao acessar sites e aplicativos, vários problemas de desempenho são frequentemente encontrados. Por exemplo, carregamento lento de página da web, placa de vídeo, erros de rede, etc., um dos principais fatores de influência é o protocolo de rede. Este artigo apresentará sistematicamente os problemas de TCP, UDP, HTTP1.1, HTTPS (incluindo o protocolo TLS1.3 mais recente), SPDY, HTTP2 e outros protocolos e como obter velocidade de acesso por meio da otimização do protocolo de rede em cenários específicos.
Nota: Este artigo foi compilado a partir do discurso proferido por Luo Cheng, engenheiro sênior do Departamento de Infraestrutura da Tencent TEG, na ArchSummit 2017 Shenzhen Station.
Prefácio: O Problema da Otimização do Desempenho WEB
Quando se trata de otimização de desempenho WEB, isso significa que encontramos muitos problemas de desempenho.
Conforme mostrado na figura acima, ao ver esta linha de palavras, acredito que muitas cenas aparecerão em sua mente, como não conseguir acessar a rede, ou a página estar carregando, ou o conteúdo pode ter ficado travado em 99% Não é possível carregar, incluindo congelamento de vídeo, vídeo curto e transmissão ao vivo e recarregamento de wifi para rede 4G, qual é o principal motivo de tantos problemas na web?
Vou listá-los brevemente e resumi-los nas duas situações a seguir.
O tamanho da página diretamente relacionado à página e o número de tipos de elementos na página, ou seja, quanto maior a página, mais elementos e interações dinâmicas mais frequentes, o desempenho correspondente pode ser mais afetado. O problema de otimização de página também é o principal campo de batalha da otimização de front-end.
O ambiente de rede e a configuração do terminal, incluindo o desempenho do hardware do telefone celular do usuário e a versão do sistema operacional do software, também terão impacto no desempenho. Esses dois estão relacionados principalmente à configuração de operadores e usuários, e também é uma parte da qual é difícil para nós exercermos influência.
Protocolo de rede
Hoje, vou me concentrar em protocolos de rede. O protocolo de rede é um fator muito importante, muito crítico, mas facilmente esquecido. Então, quando se trata de protocolos de rede, quais protocolos de rede encontraremos ou usaremos?
Em seguida, usarei o protocolo HTTP2 de próxima geração da Internet mais popular como exemplo para apresentá-lo brevemente.
Conforme mostrado na figura acima, a pilha de protocolos pela qual as solicitações da WEB precisam passar. O lado esquerdo da figura é o lado do cliente e o lado direito é o data center ou lado do servidor.
Depois que a solicitação for enviada do cliente, ela passará primeiro pelo protocolo HTTP1.1. Então, por que o título é uma solicitação HTTP2, mas se refere a HTTP1.1? Isso ocorre porque, embora o HTTP2 seja um protocolo totalmente novo, ele ainda usa a maior parte da semântica do HTTP1.1. Por exemplo, solicitações GET e solicitações POST usam a semântica do HTTP 1.1. Para páginas ou JavaScript, ainda usamos a semântica HTTP 1.1. A próxima camada do HTTP1.1 é o HTTP2. O HTTP2 usa uma nova semântica de controle de quadro. Em outras palavras, o quadro HTTP2 encapsula a semântica do HTTP1.1, como solicitações GET, que são encapsuladas usando HEADERS HTTP2; o corpo das solicitações POST Dados é encapsulado usando o quadro de dados HTTP2. Em seguida, ele atinge o protocolo TLS, a camada de criptografia de transmissão, então por que há criptografia aqui?
A principal razão é que o protocolo HTTP2 RFC7540 estipula que existem duas implementações de HTTP2, uma é H2, que impõe o uso de TLS para criptografia; a outra é H2C, onde C é claro, o que significa texto simples e não requer criptografia. Embora o protocolo diga isso, todas as implementações convencionais, incluindo todos os navegadores, todos os sistemas operacionais, até agora usam criptografia TLS. Ou seja, se você usa HTTP2, deve usar a criptografia TLS, para que encontre problemas de TLS no processo. Em seguida, desça para a camada TCP e, em seguida, desça para a camada de rede IP, bem como para a Ethernet, camada física da rede da operadora e, em seguida, para o protocolo do servidor à direita. As portas de ambos os lados podem ser consideradas simétricas, portanto não serão introduzidas.
Com tantos acordos, a quais devemos prestar atenção? Ou mais especificamente, para a maioria dos nossos desenvolvedores de aplicações WEB, em quais devemos prestar atenção? A parte acima da linha pontilhada branca na figura acima é a parte que o cliente pode influenciar ou otimizar, ou seja, a parte proposto no protocolo, incluindo os protocolos TCP, TLS e, ainda por cima, HTTP. É claro que os protocolos que precisamos otimizar, então vou analisar quais problemas eles terão.
Desempenho HTTP1.1
Problemas de desempenho com HTTP 1.1
Vamos começar com HTTP1.1, o protocolo mais usado e mais antigo.
Os alunos que estão em contato com o desenvolvimento web sabem que o maior problema de desempenho do HTTP1.1 é a serialização de link único. Quando há várias solicitações em um link TCP. Como mostrado na FIG. Os pedidos só podem ser enviados um após o outro, que é o seu maior problema.
O segundo problema é que o cabeçalho não é compactado. O cabeçalho, principalmente quando a solicitação HTTP Cookie e Host, possuem o mesmo modelo de navegador, se cada solicitação carrega a mesma informação, obviamente ela se repete. Isso é redundante, desperdiça largura de banda e afeta a velocidade de acesso do usuário devido a um problema de desempenho. porque? Como a largura de banda de uplink e downlink da rede da operadora é seriamente assimétrica, é provável que a largura de banda de uplink seja de apenas 1/10 ou até menos de 1/10 da largura de banda de downlink. então seu uplink pode ser apenas 100K Mesmo dezenas de K. Se o tamanho médio do cabeçalho for 1500 bytes, pode haver dez cabeçalhos de saída por vez e isso afetará o desempenho do acesso do usuário no nível da largura de banda. Portanto, no ambiente de rede móvel de 3G e 4G, o problema do cabeçalho não compactado é mais importante.
Otimização de HTTP1.1
Existem muitos métodos de otimização e estratégias de otimização, e eles são muito eficazes.
Em geral, a direção de otimização do HTTP1.1 é principalmente de dois pontos.
O primeiro ponto é aumentar o número de conexões simultâneas; o segundo ponto é reduzir o número de solicitações de saída. Conforme mostrado na figura acima, seja um único nome de domínio com várias conexões TCP ou fragmentação de nome de domínio, o uso de vários nomes de domínio é para aumentar o número de conexões simultâneas. Observe que as conexões simultâneas não são solicitações simultâneas. Porque o HTTP1.1 tenta implementar solicitações simultâneas em um único link, mas falha. Como pipelining, pois possui bloqueio de cabeça de linha. Portanto, ele só pode melhorar o desempenho de acesso do usuário aumentando o número de conexões simultâneas. Além disso, existem outras estratégias de otimização, incluindo cache, CSS Sprite, data uri, inlining de imagem, etc. Sua essência é reduzir o número de solicitações, ou seja, retornar várias respostas em uma única resposta, reduzindo assim o número de solicitações.
As estratégias e meios de otimização HTTP1.1 acima alcançaram resultados muito bons na era HTTP1.1 e também são eficazes.
HTTPS/HTTP2 acelera a obsolescência do HTTP1.1
Com a tendência crescente de HTTPS em todo o site, o lançamento oficial do HTTP2 tornou-se gradualmente popular e a estratégia de otimização do HTTP1.1 tornou-se inválida. Por que você diz isso?
Uma das características ou desvantagens do desempenho do HTTPS é que o custo da conexão é muito alto. Se o HTTP1.1 usar o método de aumentar as conexões simultâneas para melhorar o desempenho, devido ao seu alto custo de conexão, o custo da conexão simultânea também será alto, o que reduzirá o desempenho.
Um recurso do HTTP2 é que ele suporta multiplexação. Várias solicitações são permitidas em um link, permitindo solicitações simultâneas. Que o HTTP1.1 reduza o número de solicitações é um pouco redundante, pelo contrário, pode reduzir a taxa de acertos e o desempenho do cache.
Portanto, a partir deste nível, a estratégia de otimização do http1.1 pode não funcionar e causar efeitos colaterais.
Comparação de HTTP e HTTPS
Custos de conexão HTTP vs HTTPS
Em seguida, apresentarei brevemente por que o custo de conexão do HTTPS é alto? Do nível de protocolo, onde é alto o custo de conexão?
Conforme mostrado na figura acima, a figura à esquerda é o processo de solicitação ou custo de um HTTP1.1. A solicitação HTTP1.1 é muito simples, você só precisa estabelecer uma conexão TCP e, em seguida, enviar a solicitação e a resposta HTTP para concluir. O processo total requer apenas dois RTTs para implementar uma solicitação HTTP.
A imagem à direita é uma solicitação HTTPS. Primeiro, o HTTPS estabelece uma conexão TCP por meio de um handshake de três vias e, em seguida, envia uma solicitação HTTP1.1. Por que os dados HTTP1.1 estão aqui? Porque se os usuários forem solicitados a inserir o URL ativamente, a maioria dos usuários não inserirá HTTPS ativamente. Por exemplo, ao visitar Tencent.com, eles não inserirão https://www.qq.com, mas inserirão www.qq.com ou Para forçar o usuário a utilizar HTTPS, será retornado um redirecionamento 302. Em relação ao redirecionamento 302, a porta utilizada pelo HTTPS é 443, e a porta utilizada pelo HTTP é 80; uma nova conexão TCP deve ser restabelecida para o nova porta, para que haja mais uma conexão TCP O processo de estabelecimento, após o estabelecimento da conexão TCP, inicia-se a fase de handshake TLS.
O handshake TLS tem dois estágios. O primeiro estágio do handshake completo é negociar a versão do protocolo, conjunto de criptografia, solicitar certificado e verificar o certificado. Depois que o cliente obtém o certificado, mesmo que a assinatura do certificado esteja correta, o o tempo do certificado ainda é válido, mas o certificado ainda precisa ser verificado.É necessário consultar o status do certificado, pois pode haver casos de revogação ativa do certificado, a chave do certificado também pode vazar ou a CA ser atacada. Consultar o status do certificado é OCSP, verificar o status do certificado online, consultar o status do certificado precisa resolver o DNS de três pontos de uma CA e precisa estabelecer uma conexão TCP e, em seguida, precisa estabelecer uma resposta de solicitação incluindo OCSP, concluída por meio de HTTP request, três handshake, sem problemas com o status Depois disso, inicia-se a segunda fase do handshake completo TLS, negociando a chave simétrica, ou seja, o cálculo de troca de chave assimétrica; após a conclusão, todo o processo TLS é negociado e o HTTP dados criptografados são enviados. Até agora, chegou ao nono RTT, que é 7 RTTs a mais que http1.1 Qual é o conceito?
HTTPS não otimizado é significativamente mais lento que HTTP
Conforme mostrado na figura acima, o RTT médio no melhor ambiente de rede wifi é de 70 milissegundos, 7 RTTs são 490 milissegundos, 4G é 100 milissegundos, 3G é 200 milissegundos e 7 RTTs são mais de um segundo. E esta é apenas uma requisição, uma página geralmente tem muitas requisições, podendo haver dependências entre requisições, resultando em bloqueio. Nesse caso, é muito normal que uma página demore alguns segundos a mais, e o consumo de tempo é apenas o tempo da rede; e devido às disposições do protocolo, ela deve realizar interação de rede, incluindo muitas outras demoradas, como Falando em cálculos demorados, como verificação de certificado, cálculo de chave e criptografia e descriptografia de conteúdo simétrico, já que o desempenho do terminal móvel é relativamente fraco, é normal que centenas de milissegundos sejam adicionados a esse nível de cálculo .
Após a análise acima, podemos tirar uma conclusão básica de que o HTTPS não otimizado é muito mais lento que o HTTP, então o HTTPS é apenas lento, o que significa lento?
Para encontrar o motivo da lentidão ou encontrar o gargalo de desempenho, analisamos apenas a teoria do protocolo de rede acima. De fato, no ambiente experimental, no ambiente real de negócios e no cenário do usuário, ainda é tão lento ?Onde está?
Para tanto, realizamos dois níveis de análise.
Teste simulado off-line
O primeiro é o teste de simulação offline. O teste de simulação offline é voltado principalmente para o terminal móvel, porque o desempenho dos telefones celulares no terminal móvel é cada vez mais tráfego, e todos eles estão inclinados para o terminal móvel. O terminal móvel tem duas características: primeiro, a tela do celular é relativamente pequena e não é conveniente para visualizar dados ou visualizar o desempenho da página e logs de depuração. Em segundo lugar, não é conveniente executar scripts de análise de dados e scripts de controle. Então, conectamos o celular e o PC usando USB e controlamos o navegador no celular através do protocolo de depuração remota para visitar repetidamente as diferentes páginas que construímos. Deve haver muitos elementos envolvidos na página, e existem diferentes tipos.
Portanto, nosso teste de simulação offline deve ser automatizado, é ineficiente implementá-lo manualmente e não pode testar tantas páginas e cenários. E preste atenção nos dados ano a ano e mês a mês. Se não, mesmo que cem dados sejam obtidos no teste, mil dados não podem explicar o problema, porque há muitos erros de dados , e dados periódicos ano a ano e mês a mês exigem mais de 10.000 dados. Achei que poderia ter algum significado descritivo.
Outro grande erro é o WIFI. Mesmo no InterContinental Hotel, no Tencent Building ou no Netac Building, o wifi usado geralmente apresenta instabilidade na rede, o que tem um enorme impacto nos dados e na análise do protocolo, porque o protocolo provavelmente será apenas uma TI, então centenas de milissegundos No ambiente de rede instável, é fácil causar problemas para interferir na conclusão. Portanto, para eliminar esses erros, muitas vezes conectamos o celular e o PC com USB, ignorando o wifi e usando a rede cabeada diretamente, pois a rede cabeada é muito mais estável que a sem fio, principalmente a wi-fi.
Em relação às ferramentas, é o controle de tráfego, porque o ambiente de rede dos nossos usuários reais é muito diferente. IP diferente, largura de banda diferente, taxa de perda de pacote diferente, então usamos essa ferramenta para simular o ambiente de simulação no laboratório. Os dados de simulação offline obviamente não podem representar o desempenho do nosso negócio real.
Coleta de dados de velocidade de negócios online
A segunda parte é analisar os dados online.
A solução de coleta de dados no lado do servidor tem duas vantagens.
O primeiro ponto é que ele pode coletar dados que não podem ser coletados pelo cliente e coletar informações de nível inferior e informações comerciais. Conforme mostrado na figura acima, o lado esquerdo é o cliente, ou seja, um celular, STW ou um balanceador de carga, e o lado direito é o servidor de negócios. Em relação às informações de negócios, o tempo total de processamento do negócio pode ser obtido através da interação entre o LB e o servidor de negócios, que não está disponível para o cliente. O segundo ponto é sobre as informações do protocolo, incluindo o RTT do TCP, se o TCP está conectado multiplexado, se o TLS SESSION está multiplexado, versão do protocolo TLS, conjunto de cifras, tempo de handshake e tempo de cálculo de troca de chave assimétrica, taxa de compressão de cabeçalho HTTP2, etc. não está disponível para os clientes.
Algumas informações podem ser coletadas pelo cliente, mas o custo de desenvolvimento do cliente é muito alto, pois existem diferentes versões do Android, como IOS e Windows, que precisam ser desenvolvidas para diferentes sistemas operacionais, enquanto o servidor só precisa ser desenvolvido uma vez. Os dados são colocados no COOKIE e devolvidos ao cliente. O cliente pode obter as informações através de JS ou páginas comuns. Após obter as informações, as informações relacionadas ao protocolo são combinadas em um único dado e relatadas ao plataforma de dados para análise.
Então, com tantos dados, como nossa plataforma de dados pode analisá-los?
Análise de dados multidimensionais
Conforme mostrado na figura acima, devido à enorme quantidade de dados, apenas alguns são interceptados para análise. O lado esquerdo é a dimensão de dados, por exemplo, TCP-reuse significa reutilização de conexão TCP, TLS1.2 significa que a versão do protocolo TLS é 1.2; o lado direito são os indicadores de monitoramento relacionados ao desempenho do usuário, como tempo de carregamento inicial, atividade da página tempo, tempo de processamento do negócio, etc. Dimensões, essas dimensões também podem ser combinadas entre si e resultam em trezentas ou quatrocentas dimensões. Conforme mostrado na figura acima, qual é o primeiro tempo de tela do navegador Tencent X de cinco núcleos usando HTTP2 na rede 4G e usando o protocolo TLS1.2 e usando ECDHE sem multiplexar a sessão TLS? Através da comparação multidimensional, podemos facilmente distinguir os fatores de sua lentidão. O X5 está tanto em 4G, então quanto está abaixo de 3G e quanto está em wifi? Através da comparação abrangente multidimensional, podemos ver onde está o gargalo da superfície.
Portanto, o objetivo final da análise de dados multidimensionais é encontrar gargalos de desempenho e direções de otimização de velocidade.Então, quais são as direções de otimização?
Direção de otimização de velocidade de acesso WEB
Existem três direções de otimização. O primeiro protocolo; o segundo recurso; o terceiro comportamento do usuário.
acordo
Otimização de velocidade TCP
Então, como otimizar o nível de protocolo? A camada inferior do protocolo é o TCP, e o problema de desempenho mais óbvio do TCP é que ele requer três handshakes para estabelecer uma conexão TCP e, em seguida, envia os dados da camada de aplicação.Em comparação com os handshakes comuns, um RTT é desperdiçado. O lado esquerdo da imagem acima é um aperto de mão normal. Cada conexão TCP precisa estabelecer um handshake, e enviar pacotes SYN sem nenhum dado de grupo de movimento, RTT é desperdiçado.
TFO é TCP FAST OPEN. Os dados da camada de aplicação são enviados ao mesmo tempo que o pacote SYN é enviado, porém, sua premissa é que o pacote SYN precisa ser enviado quando o handshake e a conexão forem estabelecidos pela primeira vez. A diferença é que quando o servidor retornar SYN+ACK, ele retornará um COOKIE. Após isso, o usuário inicia uma conexão TCP, e ao enviar um pacote SYN, ele trará este cookie, podendo então trazer diretamente os dados HTTP. Em outras palavras, os dados da camada de aplicação são enviados junto com o pacote SYN, reduzindo o impacto de um RTT no desempenho. O desempenho do TCP FAST OPEN é um ganho de dados, descobrimos que os dados de 80 pontos melhoraram em quase cem milissegundos. No entanto, sua desvantagem é que requer suporte ao sistema operacional, requer IOS9+ ou linux kervel3.7+ e não suporta sistemas Windows. Outra otimização é o controle de congestionamento, que aumenta as três janelas de congestionamento para dez.
Em geral, há espaço limitado para otimização de velocidade no nível do protocolo TCP, porque o custo de otimização é muito alto, e onde está o alto? Precisa do suporte do sistema operacional e do kernel. Se for apenas uma atualização do lado do servidor, nós suportamos e desenvolvemos, e seu custo pode ser controlado, mas o mais importante é atualizar o sistema operacional do usuário, o software pilha de protocolos no vasto equipamento de rede ou atualizações do sistema operacional, e a pressão para implantar nesse nível é muito alta. Portanto, o custo de otimização no nível TCP é muito alto.
Otimização de velocidade TLS - reutilização de sessão
TLS é a camada de criptografia, e o maior problema com a camada de criptografia é o handshake completo. Em relação ao handshake completo, os alunos que estiveram em contato devem conhecer muito bem o ID da sessão, e não apresentarei seu processo.
Aqui, compartilho principalmente dois pontos. Como mostrado acima. O primeiro ponto, referente à otimização do IOS Qzone, o tempo de handshake através do id de sessão pode ser aumentado em cerca de 50%; o segundo ponto, embora o mecanismo de ticket de sessão seja mais avançado, pois não exige que o servidor forneça cache para fornecer armazenamento de memória, enviar tickets, o servidor Confira. O ID de sessão precisa fornecer memória para armazenamento e, em seguida, descobrir se o cache de sessão foi atingido.Como o IOS não suporta tickets de sessão, todos devem prestar atenção para melhorar a taxa de acertos de cache do ID de sessão do IOS por meio do cache de sessão distribuído. Em muitos cenários, não há como simplificar o handshake. Por exemplo, o usuário abre o APP pela primeira vez, abre o navegador, ou o usuário sai e reinicia o navegador, ou fecha a página do navegador e reabre. Como resultado, o handshake simplificado do cache de sessão não pode ser alcançado, porque os tickets de sessão são todos baseados na memória, não armazenados no disco rígido.
Otimização de velocidade TLS - Início falso
O método otimizado para o handshake completo é o false start, ou seja, a preempção. Semelhante à ideia do TFO, conforme mostrado no lado esquerdo da figura acima é um handshake comum, e dois handshakes de quatro vias RTT de TLS devem ser executados para estabelecer uma conexão e enviar dados da camada de aplicativo. false start é quando o clientKeyExchange não é trocado, ou seja, os dados da camada de aplicação são enviados juntos no segundo estágio do handshake completo, o que aumenta o RTT em um. Então, como habilitar o início falso? Na verdade, o cliente basicamente o suporta agora. Se o servidor quiser habilitá-lo, ele precisa configurar o algoritmo que suporta criptografia PFS (perfect forward cipher). Por exemplo, os algoritmos ECDHE e DHE podem ser configurados primeiro, e o o tempo de aperto de mão será de 30% de aumento.
Otimização de velocidade TLS - Grampeamento OCSP
Grampeamento OCSP. Alguns dos cenários que acabamos de mencionar são a revogação ativa do certificado, por isso é necessário verificar o status do certificado, pois em alguns casos, basta verificar a assinatura do certificado e verificar o certificado não consegue encontrar o status do certificado, é necessário Mais inspeção em tempo real. Nosso certificado é emitido por 3 anos, pode haver problemas no meio da escola, então ele fará inspeções periódicas.
Seu processo comum é semelhante: quando o cliente hello obtém o certificado, os 3 RTTs adicionados no processo precisam ir ao site da CA para solicitar o status e o conteúdo do OCSP. Como mostrado na figura acima, o lado direito é OCSP Stapling. Seu processo é equivalente ao proxy do servidor implementando a função de emissão de status de certificado da CA. Ele solicita o conteúdo OCSP do site da CA antecipadamente e o salva no servidor local O conteúdo é devolvido ao cliente e, em seguida, o cliente verifica o conteúdo. Ele não precisa interagir diretamente com o site da CA, então parece que o OCSP Stapling reduz três RTTs, o efeito deve ser muito óbvio.
No entanto, não é assim, por quê? Como o cliente irá armazenar em cache o OCSP, ele poderá ser armazenado em cache por sete dias sem uma única solicitação, ou seja, durante esse período de sete dias, se o usuário visitar muito o site, talvez milhares de vezes, pois uma página possui muitos solicitações, portanto, pode haver apenas uma probabilidade de 1 de aumentar esses três RTTs. Deve-se notar que não necessariamente tem esse efeito.
Otimização de velocidade TLS - tamanho de registro dinâmico
Agora vamos analisar o tamanho dinâmico do registro, ou seja, o ajuste dinâmico do tamanho do bloco de registro.
Vamos explicar brevemente o bloqueio de cabeça de linha no nível do protocolo TLS, ou seja, o pano de fundo do problema de bloqueio de cabeça de linha, porque a unidade mais básica de transmissão do protocolo TLS é o registro, e um bloco de registro não pode exceder 16K no máximo, e algumas implementações de servidor, como Nginx A versão mais antiga tem um tamanho padrão de 16K. Então, o que acontece com 16K? Se você perder um byte no meio, ou porque o chip TCP perde um segmento, os 16K não podem ser verificados, e mesmo que 15,99K de dados sejam recebidos, não há como lidar com isso, porque uma perda de dados, uma a perda do pacote torna o registro inteiro incapaz de ser processado.
Como resolvê-lo? Existem dois métodos.
A primeira é ajustar o tamanho do buffer adequadamente, por exemplo, alterá-lo para 4K, sem o sistema de nome real, mesmo que seja perdido, afetará apenas os dados de 4K, não os dados de 16K.
A segunda é aprender com o princípio de início lento do TCP. O Cloud flare fornece um patch. Quando a conexão TLS acaba de ser estabelecida, porque as condições da rede e o congestionamento são desconhecidos, a configuração de registro é reduzida, por exemplo, para 1 K. Depois que a velocidade de envio é aprimorada, o tamanho do registro é definido para 16 K. Provavelmente é uma ideia assim, e também existe um código fonte aberto.Se você estiver interessado, você pode aprender sobre isso.
Conforme mencionado acima, essas estratégias de otimização são todas para TLS1.2 e versões anteriores. A seguir, apresentaremos a versão TLS1.3, que é um protocolo revolucionário, muito inovador e marcante.
Otimização de velocidade TLS1.3
Otimização de velocidade TLS1.3 - Aperto de mão ORTT
A inovação em termos de desempenho é que ele pode alcançar um handshake completo para 1RTT e um handshake simplificado para 0RTT. Ou seja, não há princípio de handshake no nível de conexão TLS e não aumentará o atraso do RTT. O TLS1.3 ainda está em fase de rascunho.Ele é apresentado aqui porque se você quiser experimentá-lo, ele já está disponível, porque OpenSSL1.1.1 e Nginx1.13.0 suportaram respectivamente o último rascunho20 de TLS1.3. E a última discussão sobre TLS1.3 pode ser lançada oficialmente neste outono. Se o cliente pode controlá-lo, você pode tentar, incluindo o Firefox também suporta TLS1.3. Claro que todas são versões preliminares, então vou apresentá-las aqui, o processo específico é realmente mais complicado, então não vou apresentá-las em detalhes aqui.
Otimização de velocidade HTTPS
Otimização de velocidade HTTPS - HSTS reduz redirecionamentos 302
HSTS é na verdade o cabeçalho do HTTP, sua função é que o servidor informa ao cliente que quando você visitar meu site no futuro, você deve usar HTTPS e não deve usar HTTP dentro do tempo especificado. No entanto, ele tem um problema que o HSTS é retornado por meio de HTTP, que provavelmente será sequestrado pelo intermediário. Em outras palavras, o cliente pode nunca saber que o servidor enviou HSTS e não há como usar https. Nesse caso, há um mecanismo de lista de pré-carregamento fraco. Por exemplo, o navegador Chrome colocará seu site na lista de permissões e, quando você fizer uma solicitação de acesso, usará HTTPS por padrão. O mesmo vale para o cliente.
Otimização de velocidade HTTPS - SPDYHTTP2
SPDY e HTTP2. Por que SPDY é mencionado? Existem dois pontos principais.
O primeiro ponto, porque o HTTP2 é muito popular agora e lançado oficialmente, mas todos os seus recursos e recursos mais importantes são usados no SPDY, exceto o algoritmo de compactação de cabeçalho, então comecei a estudar o protocolo SPDY, e agora pode ser que muitas pessoas só conhece HTTP2 e não SPDY. Assim também para homenagear o protocolo, porque é o originador.
Em segundo lugar, a maioria dos clientes antigos é compatível apenas com SPDY. Por exemplo, as versões do Android anteriores à 4.4 e IOS agora são compatíveis com SPDY. Para serem compatíveis com versões mais antigas e melhorar o desempenho, elas são compatíveis com SPDY e HTTP2.
Tem três propriedades.
A primeira, multiplexação. Envie várias solicitações ao mesmo tempo em um único link, e a solicitação e a solicitação podem ser independentes ou dependentes no nível do protocolo. Por exemplo, se a segunda solicitação for processada primeiro, ela pode ser devolvida antecipadamente. Comparado com o HTTP1.1, ele também fez esforços de pipeline. Ele permite que o cliente envie várias solicitações ao mesmo tempo, mas o servidor deve retornar em ordem estrita, caso contrário, será confuso. Ele não sabe qual solicitação corresponde a qual resposta. Dessa forma, mesmo que a terceira solicitação seja processada primeiro, ela não pode ser devolvida antecipadamente, ou seja, todas as quatro solicitações são processadas, mas a terceira solicitação é perdida e toda a sequência será um problema. O recurso mais poderoso do HTTP2 é a multiplexação, que pode enviar cem solicitações ou até mais de cem solicitações juntas.
Sobre SPDY e HTTP2, você pode facilmente ignorar dois pontos. O primeiro ponto de compactação de cabeçalho, dados compactados, páginas promocionais provavelmente terão uma taxa de compactação de 89% ou 90%, mas esse é realmente o caso? Através de testes, verifica-se que quando uma conexão TCP envia a primeira solicitação, a taxa de compactação HTTP2 naquele momento é de apenas 30%, quando ocorre a segunda solicitação, a taxa de compactação pode chegar a 60%, e a terceira solicitação e posteriores podem chegar 90% , porque o SPDY usa o algoritmo de compactação zlib, e o HTTP2 usa o algoritmo de compactação Hpack, todos eles são compactados com base no espaço de estado, portanto, se as informações forem mais redundantes e repetidas, ao lê-las repetidamente nesta conexão, a compactação proporção será maior. Portanto, quando ocorre a primeira solicitação, o cabeçalho não é tão redundante e a taxa de compactação pode ser de apenas 30%.
Isso nos dá uma inspiração para a otimização de desempenho.Se uma página for colocada na próxima página, podemos enviar duas solicitações vazias para a conexão da página ou nome de domínio com antecedência para acumular dados. Quando a solicitação do usuário real é iniciada, ela atinge a terceira cooperação, de modo que a taxa de compactação do cabeçalho do usuário pode chegar a 90%.
O segundo é o push do servidor. Como o Nginx não suporta push de servidor, esse aplicativo raramente é usado na China, mas faz um ótimo trabalho. Por exemplo, o cliente solicita um html e o html contém css e imagens. Normalmente, após analisar o html, ele precisa enviar a solicitação CSS e a solicitação de imagem respectivamente, mas se o servidor souber que a página suporta push do servidor, o cliente só precisa emitir uma solicitação http, e o servidor envia diretamente o css e a imagem juntos, para que várias respostas à solicitação não sejam enviadas primeiro. Esse é o papel do server push, que é semelhante ao inlining, mas tem duas vantagens em relação ao inlining: o inlining afetará o cache e aumentará o tamanho do html, incluindo a manutenção de templates em segundo plano, o que também aumenta os custos de desenvolvimento e manutenção. clientes Em termos de apenas vários pedidos.
Recomendações de prática HTTP2
Já existem muitas informações na Internet sobre os conselhos práticos e o conhecimento básico do HTTP2P, então eu conto principalmente algumas de nossas próprias experiências e experiências na prática.
Primeiro, use um link ou use menos links. Não usando muitas conexões, por quê? Primeiro, menos conexões significam menos custo de handshake. Em segundo lugar, a taxa de compactação é alta, pois muitas informações são acumuladas em uma conexão, a taxa de compactação será maior. Terceiro, fazer melhor uso dos recursos do TCP, por quê? Como o controle de fluxo do controle de congestionamento do TCP é baseado em uma única conexão, se muitas conexões forem usadas, especialmente no caso de congestionamento de rede, o fator de congestionamento será amplificado e o congestionamento da rede será agravado. continuar a enviar, mas no caso de várias conexões, todos podem tentar enviá-lo, o que levará ao aumento do congestionamento da rede.
Em segundo lugar, use menos nomes de domínio, o que também melhora o uso da conexão e reduz o tempo de resolução do DNS.
Terceiro, se você precisar usar muitos nomes de domínio, tente resolver vários nomes de domínio para o mesmo ip e use o mesmo certificado. Porque o padrão de perspectiva implementado pelo cliente é que, se vários nomes de domínio puderem reutilizar o mesmo ip e o mesmo certificado, eu reutilizarei essa conexão e não criarei uma nova conexão. Por exemplo, navegador chrome; uso flexível de push do servidor em vez de inlining; sobre o TLS1.2, se ele usar a versão anterior ao TLS1.2 por padrão, o HTPP2 não poderá ser usado. O TLS1.2 não suporta todos os conjuntos de criptografia. Ele possui muitos conjuntos de criptografia que pertencem à lista negra, que é uma das razões pelas quais a taxa de uso do HTPP2 é relativamente baixa; o HTPP2 não pode resolver todos os problemas. É adequado para vários elementos , multi-conexão No cenário, se sua página em si for muito simples e tiver apenas algumas solicitações, não há problema em usar TLS normal, não melhorará o desempenho de acesso nesse cenário. Mas no geral, eu definitivamente recomendo a todos.
comportamento do usuário
Conexões pré-criadas
Conexões pré-construídas são a solução mais fácil e eficiente para otimização de velocidade. A ideia de uma conexão pré-estabelecida é estabelecer uma conexão com antecedência antes que um usuário inicie uma conexão real. Dessa forma, o custo e o atraso causados pela conexão não são sentidos pelo usuário. Na série anterior de esquemas de otimização, mesmo para o handshake 0 RTT, ainda existem alguns cálculos, como verificação de ticket.
Então, como pré-construir a conexão? Existem dois métodos.
O primeiro ponto é usar a tag de cabeçalho do link, como a conexão, para informar ao navegador, ou seja, ao servidor, que ele pode retornar; ou informar ao navegador que a página pode precisar visitar a próxima página e, em seguida, estabelecer um pré-conexão comigo com antecedência. Isso é possível com navegadores que suportam cabeçalhos de link. E se esse recurso não for compatível?
O segundo ponto é através da página de controle JS. Por exemplo, existe um JS na página de fundo, e para que a página seja acessada, uma conexão pode ser estabelecida com ele antecipadamente. Quando o usuário inicia uma solicitação, o JS pré-criou uma conexão para ela antecipadamente. Ainda existem muitos cenários. O primeiro é que a página inicial pode ser pré-criada com conexões de subpágina com antecedência. Por exemplo, a página inicial do Baidu, a página inicial do Baidu é muito simples e seus resultados de pesquisa variam muito, mas o site dos resultados da pesquisa também pode ser corrigido para AA.com, que é fácil de construir Conexão; o segundo espaço QQ, alguns usuários podem abrir o espaço QQ para abrir o álbum, e alguns usuários costumam visitar o pingente de shopping e o shopping para acessar os presentes, então podemos estabelecer diferentes pré-conexões diretas para ele com antecedência de acordo com as páginas que os usuários visitam com frequência. , a conexão pré-estabelecida também pode ser desconectada por tempo limite.
Então, como evitá-lo? Pode ser mantido usando conexões longas. Por exemplo, o navegador HTTP2 será desconectado após mais de três minutos e o HTTP será desconectado após mais de cinco minutos. Para manter a conexão de longo prazo, podemos usar JS para iniciar periodicamente uma manutenção de conexão de longo prazo solicitação dessas páginas, neste caso, a conexão é equivalente a O estado estabelecido pelo usuário no momento do acesso será sempre mantido, o que é um benefício das conexões pré-estabelecidas.
Uma conclusão básica sobre a velocidade do HTTPS é que a velocidade de acesso do HTTPS pode exceder o HTTP1.1. O ponto mais crítico e central é que o HTTPS pode usar multiplexação, mas o HTTP1.1 não. Em relação ao nó do método de otimização, conforme mostrado na figura acima, esses são os dados de dois anos atrás, e suas estratégias de otimização são as mesmas, incluindo HTTP2 e SPDY. Não há diferença essencial.
O HTTP2 é o futuro?
Alguns dos fortes recursos do HTTP2 mencionados anteriormente são muito úteis para nós. Hoje o HTTP2 é considerado o protocolo da próxima geração da Internet, mas será mesmo o nosso futuro? Ou o HTTP2 é o protocolo mais autoritário e dominante de desempenho para a próxima década? A resposta é sim. Sim. Por causa de seus muitos recursos, como multiplexação, compactação de cabeçalho, envio de servidor, prioridade, etc., o design é muito avançado e o desempenho também é excelente, resolvendo muitos problemas de desempenho.
Mas a resposta também pode ser não. Por quê? Como o HTTP2 atual é baseado no protocolo TCP e no protocolo TLS, existem alguns problemas.
Primeiro handshake de 3 vias do protocolo TCP. Embora possa suportar o TFO, o TFO requer suporte ao sistema operacional. E na primeira vez que o TFO estabelece uma conexão para obter um cookie, é necessário um RTT adicional para obter o handshake. Além disso, o TLS1.3 suporta handshake 0RTT, mas o TLS não verifica o cabeçalho TCP, que pode estar em risco de ser adulterado, como modificar o número de janelas, modificar o número de série etc., todos os quais podem ser sequestrado.
O maior problema é o bloqueio do cabeçalho da fila do TCP. Por exemplo, quando transmitimos um segmento, se o segundo segmento for perdido, a transmissão falhará. Para garantir sua confiabilidade e ordem, precisamos esperar até o segundo segmento Ele só pode ser carregado para a camada de aplicação e, infelizmente, devido à natureza da multiplexação HTTP2, se as 50 solicitações hipotéticas forem enviadas em uma plataforma TCP, isso agravará o problema de bloqueio de cabeça de linha. Em relação à retransmissão TCP, o número de sequência da retransmissão é o mesmo que o número de sequência original, o que leva à ambiguidade da retransmissão. Com relação ao controle de congestionamento, o sistema operacional precisa ser atualizado, mas o custo de atualização do TCP é alto, o que exige que usuários e intermediários de equipamentos de rede atualizem para suporte.
Então, do nível do protocolo, o HTTP2 não é o protocolo mais dominante ou mais ponderado e autoritário na próxima década, então o que é um protocolo muito competitivo? É o protocolo QUIC, que implementa HTTP2 usando UDP. Seguem suas características.
Adote o protocolo QUIC
Ele suporta todos os recursos do HTTP2, como multiplexação, bloqueio de cabeçalho de linha, compactação de cabeçalho, envio de servidor; suporta handshake 0RTT usando TLS 1.3; usa transmissão UDP; com base na criptografia de pacotes, a consistência dos cabeçalhos dos pacotes é verificada, o que pode ser encontrado uma vez que uma modificação tenha ocorrido.
A otimização de protocolo que mencionei acima também é bem suportada pela Tencent Cloud. Além disso, nosso Tencent Cloud CLB também suporta oficialmente o protocolo QUIC, e o desempenho médio foi melhorado em mais de 15%. Você está convidado a experimentá-lo.
Sobre o autor
Luo Cheng, formado pela Universidade de Zhejiang em 2011. De 2011 a 2015, trabalhou no departamento de operação e manutenção do Baidu, responsável principalmente pela distribuição de arquivos, acesso unificado, busca segura e outros assuntos. Desde 2015, trabalha na Tencent, Tencent TEG Departamento de Infraestrutura, Engenheiro sênior, atualmente responsável principalmente pelo trabalho relacionado ao Tencent STGW (Tencent Security Cloud Gateway). Ter uma compreensão profunda de HTTPS, SPDY, HTTP2, QUIC e outros protocolos de camada de aplicação, tecnologia de servidor de alto desempenho, tecnologia de rede em nuvem, velocidade de acesso do usuário, transferência de arquivos distribuídos, etc.
A recomendação de hojeClique na imagem abaixo para ler
Por que engenheiros de 30 anos mudam facilmente de emprego?
