Se o HTTP for executado em uma porta, isso significa que o TCP também pode ser executado nessa porta?

1

Estou criando um aplicativo que precisa ser executado em um smartphone móvel em uma rede GPRS / 3G. Eu estou fazendo operações de bits, então todo byte desperdiçado através de cabeçalhos HTTP é ruim. Provedores móveis na minha área fazem uso pesado de proxies e afins. Websockets para um não funcionam.

O HTTP nas portas 80 e 443 parece funcionar sempre , mas isso significa que posso criar uma conexão de soquete TCP para o meu servidor na mesma porta e iniciar um comunicação bidirecional? Eu não acho que aplicativos móveis como WhatsApp, Viber, etc. usem conexões HTTP, mas eu não encontrei nenhum detalhe sobre suas implementações e se eles fazem alguma coisa para fazer a rede funcionar sem falhas através de 3G, ou se ela funciona como está .

    
por Alper Turan 28.04.2015 / 19:25

2 respostas

9

TCP e HTTP são coisas diferentes.

TCP é a camada de transporte. Por definição, ele é responsável por carregar os protocolos da camada de aplicação (HTTP no seu caso) sobre ele. O TCP não é executado em uma porta. É o árbitro dos portos. Em outras palavras, quando você se conecta a um servidor HTTP, você se conecta à porta TCP 80. Ao se conectar ao HTTPS, você está se conectando pela porta TCP 443.

HTTP e HTTPS podem ser executados em qualquer porta TCP. 80 e 443 são apenas os mais comuns. Você pode fazer com que qualquer aplicativo escute essas portas, se quiser. Então, sim, você pode se conectar ao seu servidor pela porta 80 usando algum outro protocolo em vez de HTTP, mas somente se o servidor estiver configurado para escutar nessa porta usando esse outro protocolo e somente se HTTP ou HTTPS estiverem configurados para não use essas portas (supondo que você esteja executando um servidor web nele).

Agora, você mencionou que seu provedor está usando um proxy. Você pode fazer uma conexão não HTTP / HTTPS pela porta 80 ou 443? Isso depende de quão inteligente é o proxy. Se estiver realizando a inspeção de pacotes, pode-se verificar os cabeçalhos HTTP para garantir que o tráfego passando por essas portas seja de fato tráfego HTTP. Existem maneiras de fingir, mas depende de quão profundamente o proxy está inspecionando o tráfego. Se o proxy estiver bloqueando o tráfego que não é HTTP / HTTPS nas portas HTTP / HTTPS, não há muito o que fazer a não ser reclamação em seu provedor (ou pagar o preço mais alto, conforme o caso).

Quando se trata de como vários aplicativos móveis se comunicam, tudo depende de como o fornecedor os escreveu. A maioria usa HTTP ou HTTPS pela porta 80 ou 443, respectivamente, porque a maioria dos aplicativos móveis são apenas aplicativos da web. Mas não há nenhuma regra que diga que eles precisam, e não há nenhuma maneira real de você saber a menos que você cheire os pacotes de alguma forma.

Espero ter respondido à sua pergunta.

    
por 28.04.2015 / 19:50
6

Se eu entendi sua pergunta corretamente, posso reformulá-la como: "Se a infra-estrutura de rede permitir que o tráfego HTTP passe em uma determinada porta, ela também permitirá TCP puro (sem operação compatível com HTTP ou mesmo cabeçalhos HTTP falsos) para passar nessa porta? "

Infelizmente, a resposta é: "Depende de detalhes que você ainda não descobriu a respeito de como a rede (s) em questão filtra o tráfego". Certamente, existem infraestruturas de rede que filtram o tráfego apenas com base no número da porta, portanto, qualquer tráfego TCP pela porta 80 ou 443 pode funcionar, independentemente de as cargas TCP ou não parecerem ou agirem como HTTP.

No entanto, existem outras redes que inserem proxies HTTP ou fazem inspeção profunda de pacotes para ver se o tráfego realmente tem cabeçalhos HTTP, e esses tipos de redes bloqueariam o tráfego que não é HTTP adequado. Você pode ser capaz de contornar alguns desses filtros, colocando um falso…

GET / HTTP/1.0\r\n\r\n

… na cabeça de cada fluxo TCP cliente-servidor, e um falso…

HTTP/1.0 200 OK\r\n\r\n

… na cabeça de cada fluxo TCP servidor-para-cliente. Mas esse tipo de falsidade pode não ser suficiente para fazê-lo funcionar através de um proxy HTTP completo.

    
por 28.04.2015 / 20:16