Pesquisa TCP
Um argumento para aumentar a janela de congestionamento inicial do TCP
Os fluxos TCP começam com uma janela de congestionamento inicial de no máximo quatro segmentos ou com aproximadamente 4 KB de dados. Como a maioria das transações na Web é de curta duração, a janela de congestionamento inicial é um parâmetro TCP crítico para determinar a rapidez com que os fluxos podem terminar. Embora as velocidades de acesso à rede global tenham aumentado drasticamente em média na última década, o valor padrão da janela de congestionamento inicial do TCP se manteve inalterado. Neste artigo, propomos aumentar a janela de congestionamento inicial do TCP para pelo menos dez segmentos (cerca de 15 KB). Por meio de experimentos on-line em larga escala, quantificamos os benefícios de latência e os custos do uso de uma janela maior, como funções de largura de banda da rede, tempo de retorno (RTT), produto de atraso de largura de banda (BDP) e natureza dos aplicativos. Mostramos que a latência média das respostas HTTP melhorou em aproximadamente 10%, com os maiores benefícios demonstrados em redes com RTT e BDP altos. A latência das redes de baixa largura de banda também melhorou significativamente nos nossos experimentos. A taxa média de retransmissão aumentou em apenas 0,5%, e a maior parte do aumento veio de aplicativos que efetivamente burlam o algoritmo de inicialização lenta do TCP usando várias conexões simultâneas. Com base nos resultados dos nossos experimentos, acreditamos que a janela de congestionamento inicial deve ter pelo menos dez segmentos e ser investigada para padronização pelo IETF.
Abertura rápida do TCP
Os serviços da Web atuais são dominados por fluxos TCP tão curtos que encerram algumas viagens de ida e volta após o handshake. Esse handshake é uma fonte significativa de latência para esses fluxos. Neste artigo, descrevemos o design, a implementação e a implantação do protocolo TCP Fast Open, um novo mecanismo que permite a troca de dados durante o handshake inicial do TCP. Ao fazer isso, o TCP Fast Open diminui a latência da rede do aplicativo em um tempo de retorno completo, diminuindo o atraso dessas transferências TCP curtas. Resolvemos os problemas de segurança inerentes à permissão da troca de dados durante o handshake de três vias, que são mitigados com um token de segurança que verifica a propriedade do endereço IP. Detalhamos outros mecanismos de defesa contra reversão e abordamos problemas que enfrentamos com middleboxes, compatibilidade com versões anteriores de pilhas de rede existentes e implantação incremental. Com base na análise de tráfego e na emulação de rede, mostramos que o TCP Fast Open diminuiria a latência da rede de transação HTTP em 15%e o tempo de carregamento de toda a página acima de 10% em média e, em alguns casos, até 40%
Redução da taxa proporcional para TCP
As perdas de pacotes aumentam a latência para os usuários da Web. A recuperação rápida é um mecanismo essencial para o TCP se recuperar de perdas de pacotes. Neste artigo, exploramos alguns dos pontos fracos do algoritmo padrão descrito no RFC 3517 e dos algoritmos não padrão implementados no Linux. Constatamos que esses algoritmos desviam do comportamento pretendido no mundo real devido ao efeito combinado de fluxos curtos, paralisações de aplicativos, perdas de burst, perda e reordenação de reconhecimento (ACK) e ACKs de alongamento. O Linux apresenta reduções excessivas na janela de congestionamento, enquanto o RFC 3517 transmite grandes explosões com altas perdas, o que prejudica o resto do fluxo e aumenta a latência da Web. Nossa principal contribuição é um novo design para controlar a transmissão em recuperação rápida chamado de redução proporcional da taxa (PRR, na sigla em inglês). A PRR se recupera de perdas de forma rápida, suave e precisa, acelerando as retransmissões entre as ACKs recebidas. Além do PRR, avaliamos o algoritmo de retransmissão antecipada (ER, na sigla em inglês) do TCP, que diminui o limite de confirmação duplicada para transferências curtas e mostra que atrasar retransmissões antecipadas por um curto intervalo é eficaz em evitar retransmissões falsas na presença de um pequeno grau de reordenação. A PRR e o ER reduzem a latência TCP das conexões com perdas de 3 a 10%, dependendo do tamanho da resposta. Com base na nossa instrumentação nos servidores da Web e do YouTube do Google nos EUA e na Índia, também apresentamos as principais estatísticas sobre a natureza das retransmissões de TCP.
TCP laminar
Laminar é uma nova estrutura para controle de congestionamento do TCP que separa a programação de transmissão, que determina com precisão quando os dados são enviados, do controle de congestionamento puro, que determina a quantidade total de dados enviados durante cada RTT. Espera-se que o Laminar permita a novos algoritmos avançados para regular o tráfego TCP com mais precisão.
Rascunhos de SSL e TLS
Início falso do Transport Layer Security (TLS)
O falso início é um comportamento opcional das implementações do TLS. Ela afeta apenas o tempo do protocolo, não os dados do protocolo, e pode ser implementada unilateralmente. O recurso TLS False Start leva à redução da latência de uma ida e volta para determinados handshakes.
Extensão de negociação do protocolo Transport Layer Security (TLS) Next
Extensão Transport Layer Security (TLS) para a negociação do protocolo da camada do aplicativo. Isso permite que a camada do aplicativo negocie qual protocolo deve ser executado na conexão segura de modo a evitar idas e voltas adicionais e ser independente dos protocolos da camada do aplicativo.
Rascunho do DNS
Sub-rede do cliente em solicitações de DNS
Este rascunho define uma extensão EDNS0 para transportar informações sobre a rede que originou uma consulta DNS e a rede na qual uma resposta pode ser armazenada em cache.