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

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

eu li sobreConversaseFluxos TCPmas ainda não tenho certeza de como eles se relacionam se estiverem na mesma camada.

Para diferentes camadas, está claro para mim que, por exemplo, uma conversação IP pode consistir em vários fluxos TCP.

Uma conversação TCP pode consistir em vários fluxos TCP? E, ao contrário, um fluxo TCP pode conter várias conversas TCP? Por que?

Responder1

Neste caso, AConversaçãoocorre no nível TCP (Transporte) e é sinônimo de conexão TCP entre duas portas.

Um "TCP Stream", neste contexto, é a agregação das mensagens do aplicativo que foram passadas em uma conversa. Por exemplo, o fluxo no seu link mostra um host interno executando umUPNP-programa compatível, solicitando a um roteador que encaminhe a porta 5000 para ele e o roteador responde. Então o que você é na verdade é o campo de dados do segmento TCP. Por esse motivo acho que tem um nome ruim. Todas as informações TCP foram eliminadas, deixando apenas as mensagens que o software em ambos os hosts envia e recebe. Eles podem serHTTPGETs e respostas,FTPPUT,SMTPMAILs ou linguagem de comando nativa de qualquer outro aplicativo.

Pessoalmente, não tenho certeza se gosto da terminologia do Wireshark nesta documentação, mas ela atende bem à perspectiva deles como 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.

Por outro lado, eu diria que discordo de IP ter "conversas". O IP não transporta 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 circuito muito flexível, deixando a ordenação, a correção de erros e o controle de fluxo para sua aplicação.

Responder2

TCPconversas e fluxos TCPdeveestar no mesmo nível, mas, pelo menos em algumas versões do Wireshark, eles usam códigos diferentes para identificar quais pacotes fazem parte da conversa/stream, portanto, podem dar respostas diferentes.

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

Se eles não estiverem usando o mesmo código, isso é sem dúvida um bug, mas pode ser um bug que ninguém corrigiu ainda.

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

Responder3

Apenas olhando os exemplos nas páginas vinculadas, não parece que os termos sejam funcionalmente diferentes. Ambos parecem ter o comprimento de uma única conexão de rede.

A página de conversas não resume várias conexões; na verdade, mostra cada uma delas individualmente, com duração e contagem de bytes. A janela de fluxo simplesmente mostra os detalhes dos dados reais enviados.

informação relacionada