Sou um desenvolvedor que tem a situação boa e ruim de projetar um serviço de rede que será duramente atingido pelos clientes do iPhone. O aplicativo para iPhone teve mais de 10 milhões de downloads no ano passado e agora estou colocando os usuários on-line para interagir uns com os outros.
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 enviada será "pequeno" (digamos <256 bytes). OK, você descobriu, é um servidor de jogo (choque!).
Para sua informação, não estou interessado em UDP (ou em uma camada confiável sobre UDP, como visto em ENet e RakNet, por exemplo) para este serviço específico, pois os jogos não são do tipo 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 iPhone e o serviço serão “longas” (tanto quanto possível – danem-se túneis e elevadores!).
Para sua informação, estou executando o serviço em um uplink de 100 Mbps em servidores que executam Linux 2.6.18-164.9.1.el5.
Meus objetivos são simultaneamente:
- mantenha a latência o mais baixa possível; e
- minimizar a quantidade de memória usada por cliente conectado.
Há umgrandenúmero de botões relacionados ao TCP para ajustar! Após algumas pesquisas básicas, parece que a maioria das pessoas recomenda deixar as configurações como estão. No entanto, há uma série de configurações queparecercomo se eles devessem ser ajustados para casos específicos. Isso é um pouco vago, eu sei, e é por isso que peço ajuda.
Coisas a serem consideradas para ajustar pequenas solicitações/respostas em redes instáveis, minimizando ao máximo a memória, podem ser:
- memória disponível para a implementação TCP/IP
- definindo a opção "nodelay" (desative o algoritmo Nagle, pois este é um servidor de jogo em tempo semi-real)
- algoritmos de controle de congestionamento
- etc. (o que mais?)
Considere o TCPalgoritmos de controle de congestionamento:
- reno: TCP tradicional usado por quase todos os outros sistemas operacionais
- cúbico: CUBIC-TCP
- bic: BIC-TCP
- htcp: HamiltonTCP
- Vegas: TCP Vegas
- westwood: otimizado para redes com perdas
Meus servidores são padronizados parabiccujo "objetivo é projetar um protocolo que possa escalar seu desempenho até várias dezenas de gigabits por segundo em redes de longa distância de alta velocidade, mantendo ao mesmo tempo forte imparcialidade, estabilidade e facilidade de uso do TCP."
Apenas pela pequena descrição,Westwoodparece mais apropriado, uma vez que "destina-se a lidar melhor com caminhos de produtos com grande atraso de largura de banda (tubos grandes), com perda potencial de pacotes devido à transmissão ou outros erros (tubos com vazamento) e com carga dinâmica (tubos dinâmicos)".
Estou me aprofundando muito aqui ou isso é normal?
Para quais tipos de coisas vocês geralmente ajustam o TCP/IP? Como? Que regras básicas existem para saber?
Que palavras de sabedoria você tem para o meu caso específico?
Muito obrigado!
Responder1
Então, como você descobriu, o controle de congestionamento do TCP é uma área bastante complicada.
Para este caso específico, por causa das solicitações pequenas, você vai querer tentar manter as conexões abertas tanto quanto possível, porque uma conexão por solicitação levará cinco pacotes cada, enquanto você pode reduzir a média para um pouco mais de dois pacotes se você mantiver conexões por perto.
NODELAY é a coisa certa para um servidor de jogos; você deseja 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 seus servidores têm muita memória, as opções de memória não são grande coisa, os novos kernels estão corretos.
Quanto aos algoritmos de controle de congestionamento, você viu Westwood. A outra opção é CÚBICO. Você pode simplesmente escolher um ou fazer algumas pesquisas e compará-los. Isso pode dar bastante trabalho, mas para 10 milhões de clientes vale a pena. Então, eu gostaria de executar uma simulação usando um gerador de tráfego em um Mac ou três (já que eles têm a mesma implementação TCP do telefone), uma caixa Linux atuando como roteador (mais sobre isso em breve) e um de seus servidores, para ver como vai.
Agora, essa caixa central do Linux deve rodarns-3para que você possa simular um caminho mais complicado do que apenas um switch Ethernet. Em seguida, você captura alguns rastreamentos de pacotes na extremidade de envio das conexões TCP e os analisa comtcptraceou os modos gráficos tcptrace do wireshark. A documentação do tcptrace é uma boa introdução à análise do comportamento de congestionamento do TCP.