Quais são algumas dicas de ajuste de TCP para um serviço atingido pelos clientes do iPhone em redes móveis como o 3G?

Question

Eu sou um desenvolvedor que tem a boa + má situação de projetar um serviço de rede que será muito atingido pelos clientes do iPhone. O aplicativo para iPhone tem mais de 10 milhões de downloads no ano passado e agora estou trazendo os usuários on-line para interagir uns com os outros.

Eu gostaria de ajustar a implementação do TCP para os servidores que hospedarão meu serviço de rede baseado em TCP. O tamanho por solicitação enviado será "pequeno" (digamos < 256 bytes). OK, você descobriu, é um servidor de jogo (choque!).

FYI, eu não estou interessado em UDP (ou uma camada confiável no topo do UDP, como visto em ENet e RakNet, por exemplo) para este serviço em particular, pois os jogos não são parecidos com o Quake; todos os pacotes devem ser recebidos de forma confiável e é para isso que o TCP foi projetado. Assim, as conexões entre o cliente do iPhone e o serviço serão "de longa duração" (tanto quanto possível - túneis e elevadores sejam danados!).

FYI, estou executando o serviço em um uplink de 100 Mbps em servidores que executam o Linux 2.6.18-164.9.1.el5.

Meus objetivos são simultaneamente:

• mantenha a latência o mais baixa possível; e
• minimize a quantidade de memória usada por cliente conectado.

Há um número grande de botões relacionados ao TCP para ajustar! Depois de algumas pesquisas básicas, parece que a maioria das pessoas recomenda deixar as configurações como estão. No entanto, existem várias configurações que parecem ser ajustadas para casos específicos. Isso é um pouco vago, e é por isso que estou pedindo ajuda.

Coisas a considerar ajuste para pequenos pedidos / respostas em redes escamosas, minimizando a memória, tanto quanto possível, pode ser:

• memória disponível para a implementação do TCP / IP
• definindo a opção "nodelay" (desative o algoritmo Nagle, já que este é um servidor de jogos em tempo semi-real)
• algoritmos de controle de congestionamento
• etc. (o que mais?)

Considere TCP algoritmos de controle de congestionamento :

• reno: TCP tradicional usado por quase todos os outros sistemas operacionais
• cúbico: CUBIC-TCP
• bic: BIC-TCP
• htcp: TCP de Hamilton
• vegas: TCP Vegas
• westwood: otimizado para redes com perdas

Meus servidores padrão são bic cujo "objetivo é criar um protocolo que pode escalar seu desempenho em até várias dezenas de gigabits por segundo em redes de longa distância de alta velocidade, mantendo uma strong imparcialidade, estabilidade e compatibilidade com TCP. "

Apenas a partir da descrição minúscula, Westwood soa mais apropriado, já que "destina-se a lidar melhor com Caminhos de produto de grande atraso de largura de banda (tubos grandes), com potencial perda de pacotes devido a erros de transmissão ou outros (canos com vazamentos) e com carga dinâmica (tubos dinâmicos) ".

Estou entrando muito fundo aqui ou isso é par para o curso?

Que tipos de coisas vocês ajustam o TCP / IP geralmente? Como? Quais regras existem para saber?

Que palavras de sabedoria você tem para o meu caso particular?

Muito obrigado!

    

Answer 1

Então, como você descobriu, o controle de congestionamento do TCP é uma área bastante complicada.

Para este caso em particular, por causa das pequenas requisições, você vai querer tentar manter as conexões abertas o máximo possível, porque uma conexão por requisição vai levar cinco pacotes cada, enquanto você pode obter o média para um pouco mais de dois pacotes, se você mantiver conexões por aí.

NODELAY é a coisa certa para um servidor de jogo; você quer que seus 256 bytes sejam entregues imediatamente, e isso não é um segmento inteiro, então Nagle fará uma pausa a menos que você use NODELAY.

Se os seus servidores tiverem muita memória, as opções de memória não são grandes, os novos kernels têm razão.

Quanto aos algoritmos de controle de congestionamento, você avistou Westwood. A outra opção é CUBIC. Você pode apenas ir com um, ou você pode fazer alguma pesquisa e compará-los. Isso pode ser um pouco trabalhoso, mas para clientes de 10M vale a pena. Então, eu estaria olhando para executar uma simulação usando um gerador de tráfego em um Mac ou três (uma vez que eles têm a mesma implementação TCP do telefone), uma caixa Linux entre agindo como um roteador (mais sobre isso em breve) e um de seus servidores, para ver como funciona.

Agora, essa caixa intermediária do Linux deve executar ns-3 para que você possa simular um caminho mais complicado do que apenas um switch ethernet. Em seguida, você captura alguns rastreios de pacotes no fim de envio das conexões TCP e os analisa com tcptrace ou com os modos de representação gráfica tcptrace do wireshark. A documentação do tcptrace é uma boa introdução para analisar o comportamento de congestionamento do TCP.