Reconstrução de pacotes HTTP

Question

Se eu tiver um pacote HTTP grande que foi dividido em vários pacotes TCP, como posso reconstruí -los de volta em um único pacote HTTP? Basicamente, onde no pacote eu procuro dizer quando um pacote HTTP está começando/termina? Não consigo ver nenhum sinalizador/campos no cabeçalho do TCP que denota o início ou o final do pacote HTTP.

EDITAR: No acompanhamento das respostas. Se o TCP gerencia o fluxo, como sabe quando o fluxo começa e termina? Isso é determinado pela abertura e fechamento do soquete? Algum protocolo, em algum nível, deve ser capaz de saber quando o fluxo/pacote HTTP começou e terminou. É isso que eu gostaria de saber.

A situação em que estou é que estou usando um sniffer de pacote em C# que lê em pacotes TCP e gostaria de poder reconstruir as solicitações/respostas HTTP/etc. Passando pela interface como o Wireshark e vários outros sniffers conseguem. Como alternativa, existem bibliotecas C# que permitem que você toque nos fluxos HTTP no nível superior, economizando -me a ter que reconstruir o fluxo/pacotes HTTP?

Obrigado.

Answer 1

Ok, eu descobri como fazer isso (desonesto, mas isso faz o trabalho).

É simples retirar os cabeçalhos Ethernet, IP e TCP, deixando você com a mensagem de dados 'RAW'. Olhando para dentro da mensagem, é fácil detectar se é o início de um pacote HTTP procurando o "HTTP/1.1 ..." no início do pacote. Isso indica que o pacote é o início de um fluxo HTTP/pacote maior/o que for. Você também pode fazer uma análise simples para ler o campo "Conteúdo", que é o comprimento total de todo o pacote HTTP.

Você também pode usar os números de IP e porta de origem/destino para formar um ID exclusivo para o link. Então, depois de receber o pacote de cabeçalho, tome nota dessas 4 coisas (SRCIP, SRCPORT, Destip, Destport). Da próxima vez que você receber um pacote que corresponda a esta combinação de porta/IP, você pode verificar se é a próxima parte do pacote HTTP. Você pode usar os números de sequência para fazer alguma validação e provavelmente outras coisas, mas geralmente os pacotes estão em ordem, por isso está tudo bem. Eu acho que uma nova porta é aberta para cada fluxo HTTP, para que você não receba pacotes aleatórios que não fazem parte do fluxo, mas isso pode ser uma área propensa a erro.

De qualquer forma, depois de receber este pacote, mais uma vez retire os cabeçalhos e receba a mensagem bruta. Adicione -o à parte já conhecida da mensagem. Se o comprimento da mensagem total recebida até agora for igual ao comprimento lido do campo "Conteúdo do comprimento", o pacote estará completo!

Esse método é obviamente propenso a uma enorme quantidade de erros, mas não estou atrás de uma maneira extremamente robusta de fazê -lo. Eu pensei em responder minha própria pergunta, caso alguém se depare com esse mesmo problema no futuro! Boa sorte com o seu cheirar: D

Answer 2

Você não deve usar nenhuma informação do nível TCP para determinar os limites da solicitação HTTP. O TCP fornece um serviço de fluxo de bytes confiável; Você não pode ver nenhum campo ou bandeira no TCP que ajude nisso porque eles não estão lá.

Para determinar onde os limites estão em uma solicitação HTTP, você deve seguir a RFC 2616. Os limites estão bem definidos e você pode determiná-los analisando os dados que recebe.

Answer 3

Em cada pacote TCP, o início dos dados da carga útil é imediatamente após o cabeçalho do TCP e o final dos dados da carga útil é o final do pacote IP.

O final do cabeçalho do TCP é facilmente encontrado - o Data Offset é um campo de 4 bits no cabeçalho que contém o comprimento do cabeçalho em palavras de 32 bits (então multiplique-o por 4 para obter o comprimento em bytes de 8 bits).

Use os números de sequência TCP do Sequence Campo para encadear as cargas úteis na ordem certa. Observe que pode haver duplicatas, no caso de retransmissões.

Answer 4

TCP é a fluxo Protocolo, não um protocolo de pacote. A camada de aplicativo (ou seja, você) obtém um fluxo de dados, não um monte de pacotes. Você continua lendo bytes do fluxo e obterá toda a sua carga útil HTTP, enquanto o TCP faz a verificação de erros, se reassa, etc.

Answer 5

Você pode usar o código do projeto de código aberto chamado Xplico:http://www.xplico.org

Answer 6

Tivemos que trabalhar para resolver o mesmo problema. Conseguimos extrair parte da funcionalidade principal em um projeto de código aberto.

http://code.google.com/p/pcap-reconst/

Por favor, verifique e deixe -me saber se isso o ajudar.