Comparando aplicativos TCP / IP versus aplicativos HTTP [fechado]

13

Estou interessado em desenvolver um site voltado para o usuário em grande escala, escrito em Java.

Quanto ao design, estou pensando em desenvolver serviços modulares e independentes que possam atuar como provedores de dados para meu aplicativo Web principal.

Quanto a escrever esses serviços modulares (provedores de dados), eu posso alavancar uma estrutura existente como Spring e desenvolver esses serviços seguindo o padrão de design RESTful e expor recursos via HTTP com um formato de mensagem como JSON ... ou eu posso alavancar uma rede existente estrutura como Netty ( http://netty.io/ ) e formato de serialização como Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) e desenvolva um servidor TCP que envia e volta o protobuf serializado carga útil.

Quando você deve escolher um sobre o outro? Haveria algum benefício em usar um formato de serialização como o Protobufs e enviar um fluxo de bytes por fio? Haveria sobrecarga apenas usando JSON? Quanta sobrecarga existe entre o uso de TCP / IP e HTTP? Quando você deve usar o Spring over Netty e vice-versa para criar esse serviço?

java rest http serialization tcp HiChews123
fonte
Parece que você está pensando mais na pilha de tecnologia do que nos requisitos reais. Como é que algum de nós poderia responder a essa pergunta sem saber o que você precisa fazer ? Você está criando um jogo multiplayer com uma latência quase zero? Ou um aplicativo de bookmarking social em que a maior parte do acesso já é via HTTP e você pode armazenar dados em cache por horas a fio e nem se importa com a atualização, quanto mais com a latência?
Aaronaught
3
Não acho que a OP esteja nos pedindo para fazer uma escolha por ele. Ele está simplesmente fazendo uma pergunta de alto nível sobre como essas escolhas são feitas e quais fatores são considerados. Não pense que há algo errado em fornecer uma resposta de alto nível a isso ... e eu fiz.
DXM 12/12
Geralmente sou contra o uso de formatos binários, a menos que você realmente precise. Sem formatos de arquivos binários, sem serializações binárias, etc. Por exemplo, em Java, as serializações binárias causam incompatibilidades entre versões Java e versões de seu próprio software, mas acredito que o XML não seja tanto assim. Eu pensaria o seguinte TCP / IP> HTTP> XML Claro, isso dependeria do que você está fazendo. Eu acho que o JSON é uma alternativa ao XML. Não sei muito sobre Spring ou Netty, apesar de ler que as pessoas estão usando Spring.
Kaydell
+1 DXM, estou fazendo perguntas de alto nível como alimento para pensar quando penso em tomar uma decisão dessas.
HiChews123

Respostas:

21

Definitivamente, existem prós / contras sobre o uso de JSON sobre REST vs. TCP / IP direto com protocolo binário e acho que você já suspeita que o protocolo binário será mais rápido. Não sei exatamente o quanto mais rápido (e isso dependeria de muitos fatores), mas acho que talvez haja uma ou duas ordens de diferença de magnitude.

À primeira vista, se algo é 10 a 100 vezes mais lento do que qualquer outra coisa, você pode ter uma reação brusca e optar por "coisa rápida". No entanto, essa diferença de velocidade está apenas no próprio protocolo. Se houver acesso ao banco de dados / arquivo no lado do servidor, isso não será afetado por sua escolha da camada de transferência. Em alguns casos, isso pode tornar a velocidade da camada de transferência muito menos significativa.

HTTP REST e JSON são válidos por vários motivos:

  • eles são facilmente consumíveis por praticamente qualquer pessoa. Você pode escrever seu Web App, virar e publicar sua API para o resto do mundo. Agora qualquer pessoa pode atingir os mesmos pontos finais e acessar seus serviços
  • eles são facilmente depuráveis, você pode abrir um farejador de pacotes ou simplesmente despejar solicitações recebidas em arquivos de texto e ver o que está acontecendo. Você não pode fazer isso com protocolos binários
  • eles são facilmente extensíveis. Você pode adicionar mais atributos e dados posteriormente e não quebrar a compatibilidade com clientes antigos.
  • consumível por clientes javascript (ainda não tenho certeza de que eles têm um analisador de protobuf JS, não acredito que exista)

Protobufs sobre TCP / IP:

  • eles são mais rápidos

Se fosse minha escolha, eu usaria o HTTP REST e o JSON. Há uma razão para tantas outras empresas e sites seguirem esse caminho. Lembre-se também de que no futuro você sempre poderá oferecer suporte a 2 pontos finais. Se seu design estiver correto, sua escolha do ponto final deve ser completamente dissociada da lógica de negócios do servidor ou do banco de dados. Portanto, se você perceber mais tarde que precisa de mais velocidade para todas / algumas solicitações, poderá adicionar protobufs com o mínimo de barulho. Logo de cara, no entanto, o REST / JSON o levará mais rápido do chão e o levará adiante.

Tanto quanto Netty vs Spring vai. Não usei o Netty diretamente, mas acredito que seja apenas um servidor da Web leve, pois o Spring é uma estrutura que fornece muito mais para você do que apenas isso. Ele possui camadas de acesso a dados, agendamento de tarefas em segundo plano e (eu acho) um modelo MVC, por isso é muito mais pesado. Qual escolher? Se você decidiu seguir o caminho HTTP, a próxima pergunta provavelmente é qual é o padrão do seu aplicativo. Se você está prestes a escrever uma lógica personalizada maluca que não se encaixa no molde padrão e tudo que você precisa é apenas uma camada de servidor HTTP, vá com o Netty.

No entanto, desconfio que seu aplicativo não seja tão especial e provavelmente poderia se beneficiar de muitas coisas que o Spring tem a oferecer. Mas isso significa que você deve estruturar seu aplicativo em torno da estrutura do Spring e fazer as coisas da maneira que eles esperam, o que significaria aprender mais sobre o Spring antes de mergulhar em seu produto. As estruturas em geral são ótimas porque, mais uma vez, tiram você do papel mais rapidamente, mas a desvantagem é que você precisa se encaixar no molde delas, em vez de fazer seu próprio design, e esperar que a estrutura funcione.

(*) - no passado, foi apontado que minhas postagens não refletem opiniões de todo o mundo, por isso vou gravar e acrescentar que tenho uma experiência limitada com o Netty (já usei o framework Play antes que é baseado no Netty) ou no Spring (eu só li sobre isso). Então pegue o que eu digo com um grão de sal.

DXM
fonte
1
+1, especialmente para "essa diferença de velocidade é apenas no próprio protocolo. Se houver acesso ao banco de dados / arquivos no servidor, isso não será afetado pela sua escolha da camada de transferência". 99% é exatamente assim que será, e a otimização prematura (no lugar errado) não ajudará nisso.
Shivan Dragão
Obrigado pela sua resposta longa e análise aprofundada ao comparar os dois. Entendo os benefícios de criar um aplicativo RESTful porque é facilmente consumível por clientes públicos. No entanto, no caso, quero manter tudo internamente e não quero expor o serviço (eu cuido da serialização / desserialização), não vejo por que não usar um protocolo binário personalizado não seria a primeira escolha. Sim, você pode sair do papel mais rapidamente com as estruturas existentes, mas às custas de ficar bloqueado nas APIs e ter um controle menos refinado.
HiChews123
O REST é fácil de consumir por TODOS os clientes, não apenas os públicos, mas eles certamente estão incluídos. Minha empresa tem um produto que estamos construindo há cerca de um ano. Tínhamos um protocolo "proprietário" que, por acaso, era descanso. Acabamos de abrir para os outros. Uma coisa que eles ensinam na escola de negócios é "pensar em opções", tomar decisões para deixar o máximo de opções possível para que você possa tomar decisões posteriormente. Portanto, dado o conjunto igual, eu escolheria o REST não porque tenho clientes JS ou acesso à API hoje, mas que tenho a opção de tê-lo no futuro, se necessário. Então, novamente, se ...
DXM 16/10
... você está pronto para usar o protocolo binário, vá em frente. 96% de chance de sua escolha de protocolo não ter nenhum efeito sobre sua aplicação final, para que eu não sueie muito essa decisão. E como eu disse na resposta, com um design decente, você poderá trocar os protocolos em uma data posterior de qualquer maneira. Outra coisa que gosto de fazer é tentar os dois casos. Se estiver em cima do muro para tomar uma decisão, jogo uma moeda e pego a opção A. Na próxima vez que faço um projeto semelhante, escolho a opção B, só para poder voltar e comparar / contrastar minha experiência. Às vezes, essa é a única maneira que você decidir por si mesmo o que é melhor
DXM
@ DXM, ótimas respostas, bravo!
HiChews123
0

Esta é realmente uma questão não. De acordo com o conjunto de protocolos da Internet, tcp é um protocolo na camada de transporte e http é um protocolo na camada de aplicativos. Você está comparando coisas totalmente diferentes entre si. (Veja mais aqui: http://en.wikipedia.org/wiki/Internet_protocol_suite )

De fato, a maioria dos http é sobre TCP / IP. Então, para responder sua pergunta, sim, você deve usar TCP / IP. Então você deseja adicionar um protocolo de camada de aplicativo sobre isso (como http) e, em seguida, um formato de dados (como json, xml, html). Netty permite que você use http e protobuff é igual a json, xml, html.

Tudo depende de quais são seus requisitos e que tipo de dados você precisará transportar. Você precisa de sessões no seu protocolo de protocolo, um aperto de mão pode melhorar sua configuração de protocolo, quantos dados você enviará de uma só vez, precisa de criptografia? Estas são perguntas que você precisa responder ao escolher um protocolo de aplicativo.

Para escolher um formato de representação de dados (json, xml, html, protobuff, etc.), depende da largura de banda, legibilidade, suporte a idiomas / ferramentas etc.

Você não pode comparar o http com o tcp.

Lembre-se de que velocidade não é tudo. A velocidade é inútil se você não conseguir se expressar de maneira sensata.

iveqy
fonte
5
Não há nada em sua pergunta que sugira que ele não saiba a diferença entre as camadas da pilha de rede. Ele perguntou se deveria usar HTTP (o fato de que HTTP é uma camada acima de TCP / IP é assumido) ou usar TCP / IP com seu próprio protocolo personalizado. Não há nada de errado com sua pergunta.
Michael
Eu discordo, é claro. Não foi assim que eu o entendi
Iveqy 14/10
1
Sim, eu entendo que o HTTP está em uma camada acima do TCP / IP, minha pergunta é realmente sobre pensar em tomar uma decisão em termos de tradeoffs - latência, velocidade de desenvolvimento, etc. Obrigado por fazer perguntas para eu pensar!
HiChews123
2
@ acspd7 Eu evitaria criar seu próprio protocoll, já existem muitos protocolls já comprovados e, a menos que seu protocoll seja algo que lhe proporcione uma vantagem sobre seus concorrentes, você provavelmente estará melhor com um protocoll padrão. Eu implementei um protocolo personalizado, foi muito divertido! No entanto, criptografia, perfuração, manutenção de funcionamento, handshake (redes diferentes exigem comprimentos de quadro diferentes) etc. é muito trabalho para fazer coisas boas. Sem mencionar toda a documentação que você precisará. Pense no que você realmente precisa nos recursos antes de fazer algo personalizado.
iveqy
1
O GPB está bem documentado, usado por muitos outros, então não vejo realmente nenhum problema em usá-lo. Ser mais conciso que XML e JSON deve ser ótimo! (você pode ter falta de legibilidade humana, mas se isso não for um requisito ...). No entanto, você não sente falta de uma camada? Geralmente você tem uma camada entre tcp e xml, json, protobuff. Algo como http, ssh, etc.
iveqy 16/10