Por que a criação de uma nova conexão TCP é considerada cara?

9

Não entendo por que criar uma nova conexão TCP é considerada uma tarefa cara. Basicamente, configurar uma nova conexão refere-se à realização do handshake de três vias do TCP. Então, isso está enviando dois pacotes e recebendo um. Considerando que milhares de pacotes (dados) seguirão, o aperto de mão não pode ser a parte cara. Pode?

networking tcp

Talvez devido ao uso da CPU e da memória das conexões?

— Joeqwerty

@joeqwerty Entendo que uma nova conexão TCP geralmente também significa criar um novo processo / thread no servidor, por exemplo, mas isso não é por causa do TCP, mas devido ao aplicativo.

Se milhares de pacotes de dados se seguirem, os handshaks não são a parte cara. Mas por que não usar uma nova conexão TCP para cada bloco de dados? Porque a criação de uma nova conexão TCP é cara. É por isso que você estabelece uma conexão e a usa para milhares de blocos de dados.

— David Schwartz

1

Considere também que a nova criação de conexão pode não estar limitada apenas ao handshake TCP. Por exemplo, o SSL adiciona muita negociação de detalhes de autenticação e criptografia na parte superior.

— precisa

10

Acredito, de um modo geral, que abrir uma conexão TCP é considerado caro quando comparado à capacidade de reutilizar conexões já abertas mantendo-a aberta. Você está correto, a abertura de uma conexão levará apenas 3 pacotes / turnos, mas esse tempo - 3 x seu RTT - está muito além do custo de reutilizar uma conexão já aberta, muito mais próxima de 0. A disparidade aumenta ainda mais se você estamos abrindo e fechando conexões com freqüência.

Você certamente está certo, porém, quando comparado ao número de turnos que verá como o aplicativo "faz as coisas", esses 3 pacotes podem parecer bem pequenos, mas, novamente, depende de como você deseja comparar as opções E como seu aplicativo se comporta / quantas vezes você planeja abrir uma conexão.

No entanto, se estivermos falando de UDP x TCP, o Cheekaleek está 100% correto - a sobrecarga é massiva a longo prazo, quando comparada às operações sem conexão do UDP.

— Univ426
fonte

1

Um bom exemplo que eu já vi em um rastreamento de pacotes: Uma conexão MySQL reutilizada pode mudar as consultas em 2 a 5 ms. Uma série de consultas do ElasticSearch inverte as consultas entre 17 e 25ms, na maioria das vezes em configuração de conexão (incluindo pesquisa inicial de DNS).

— sysadmin1138

2

Certamente é mais caro do que enviar um pacote UDP e não se importar com o que acontece depois disso.

O TCP também vem com mais dados de cabeçalho e mantém o estado da conexão, que consumirá recursos.

Então, sim, comparado ao UDP, TCP é mais caro, mas caro é um termo relativo.

"Conexões TCP são as melhores amigas de uma garota ???"

— HostBits
fonte

5

"TCP connections are a girl's best friend???" Não, eles não são. Eu ganhei milhares de garotas no aniversário dela e tudo o que ela fez foi parar de devolver meus e-mails. :(

— HopelessN00b

2

Não é apenas o envio e recebimento de pacotes. Memória adicional deve ser alocada e, no mínimo, as tabelas de estado da rede atualizadas a cada etapa até que a sessão seja estabelecida. Sem mencionar as verificações de segurança adicionais que podem ser executadas (proteção contra falsificação de rota, etc.).

Apenas usando alguns exemplos de números (porque não estamos falando de nenhum sistema operacional específico) se um pacote para uma sessão estabelecida tiver um custo de CPU de 1 unidade, o custo de uma nova sessão poderá ser 10x ou 100x o custo no número de operações realizadas. A maioria dos firewalls de hardware com os quais trabalhei podem lidar com uma ordem de magnitude menor que o número de novas conexões por segundo do que com sessões estabelecidas.

Geralmente, isso não é grande coisa, especialmente porque um SYN-SYN / ACK-ACK acontece em milissegundos, mas para sistemas grandes com muitos clientes, novas sessões podem se tornar uma sobrecarga significativa .

— bahamat
fonte

2

A quantidade ou o tipo de tráfego importa muito menos do que o código associado à alocação real de memória e ao rastreamento associado de informações de estado. Se você quiser ter uma idéia geral do que isso implica, dê uma olhada na quantidade de código no kernel do Linux associado ao TCP versus aquele associado ao UDP ou ICMP. Uma comparação incrivelmente grosseira mostra o TCP exigindo algo como 10x o número de linhas de código encontradas no UDP.

Nas redes IP, a quantidade de manutenção de estado necessária é um dos determinantes mais importantes da escalabilidade. Para terminais TCP, isso é expresso não apenas em SYN / ACK, mas também na manutenção contínua de janelas deslizantes, números de sequência, gerenciamento de buffer e ações de QoS, etc. Confira a complexidade do FSM para tcp e considere a falta inerente do mesmo no UDP ...

— rnxrx
fonte