Relação entre conversas TCP e fluxos TCP no Wireshark

Question

Li sobre Conversas e Fluxos TCP , mas ainda não sei ao certo como eles se relacionam se estiverem na mesma camada.

Para diferentes camadas, é claro para mim que, por exemplo uma conversa IP pode consistir em múltiplos fluxos TCP.

Uma conversação TCP pode consistir em vários fluxos TCP? E em frente, um fluxo TCP pode conter várias conversas TCP? Por quê?

    

Answer 1

Nesse caso, A Conversa ocorre no nível do TCP (Transporte) e é sinônimo de um TCP Conexão entre duas portas.

Um "TCP Stream", neste contexto, é a agregação das mensagens do aplicativo que foram transmitidas em uma conversa. Por exemplo, o fluxo em seu link mostra um host interno executando um programa compatível com UPNP , solicitando que um roteador encaminhe a porta 5000 para isso, e o roteador está respondendo. Então, o que você é realmente é o campo de dados do segmento TCP. Por essa razão, acho que é mal nomeado. Todas as informações do TCP foram removidas, deixando apenas as mensagens que o software em ambos os hosts envia e recebe. Eles podem ser HTTP GETs e respostas, FTP PUTs, SMTP MAILs, ou qualquer idioma de comando nativo de qualquer outro aplicativo.

Pessoalmente, não tenho certeza se gosto da terminologia do Wireshark nesta documentação, mas ela serve bem à sua perspectiva como um analisador de protocolo. Um aplicativo vê uma conexão de soquetes entre dois pontos de extremidade como um fluxo de E / S, independentemente do protocolo subjacente.

Em uma nota lateral, eu diria que discordo do IP ter "conversas". O IP não carrega os dados necessários para manter um circuito virtual e deixa isso para uma camada superior. O TCP lida com um circuito estrito e o UDP lida com um muito solto, deixando a ordem, a correção de erros e o controle de fluxo até sua aplicação.

    

Answer 2

TCP conversas e fluxos TCP devem estar no mesmo nível, mas, pelo menos em algumas versões do Wireshark, eles usam código diferente para identificar quais pacotes fazem parte a conversa / fluxo, para que eles possam dar respostas diferentes.

Um deles pode, por exemplo, tratar todo o tráfego entre dois pontos de extremidade (pares de endereço IP / porta) como parte da mesma conversação / fluxo, mesmo que uma conexão TCP entre esses dois pontos de extremidade seja fechada e outra seja aberto entre os mesmos dois endpoints dentro da mesma captura (improvável, pois as portas não tendem a ser imediatamente reutilizadas, mas não impossíveis), enquanto o outro pode reconhecer a conexão sendo fechada e mostrá-las como conversas / streams separados.

Se eles não estão usando o mesmo código, isso é um bug, mas pode ser um que ninguém tenha corrigido ainda.

Obviamente, IP "conversas", que estão entre dois endpoints IP (dois endereços IP), são diferentes das conversações / fluxos TCP; como você nota, pode haver várias conversações TCP, conversas UDP, etc. entre dois pontos de extremidade IP e, portanto, vários TCP / UDP / etc. conversas na mesma conversa de IP.

    

Answer 3

Apenas olhando os exemplos nas páginas que você vincula, não parece que os termos sejam funcionalmente diferentes. Ambos parecem ser o tamanho de uma única conexão de rede.

A página de conversas não resume várias conexões, ela realmente mostra cada uma delas, com o tempo e a contagem de bytes. A janela de fluxo simplesmente mostra os detalhes dos dados reais enviados.