Comparaison des applications TCP / IP et des applications HTTP [fermé]

13

Je souhaite développer un site Web à grande échelle destiné aux utilisateurs, écrit en Java.

En ce qui concerne la conception, je pense développer des services modulaires indépendants pouvant servir de fournisseurs de données à mon application web principale.

En ce qui concerne l'écriture de ces services modulaires (fournisseurs de données), je peux tirer parti d'un cadre existant comme Spring et développer ces services en suivant le modèle de conception RESTful, et exposer des ressources via HTTP avec un format de message comme JSON ... ou je peux tirer parti d'un réseau existant comme Netty ( http://netty.io/ ) et le format de sérialisation comme Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) et développer un serveur TCP qui envoie et retourne le protobuf sérialisé charge utile.

Quand devriez-vous choisir l'un plutôt que l'autre? Serait-il avantageux d'utiliser un format de sérialisation comme Protobufs et d'envoyer un flux d'octets sur le câble? Y aurait-il des frais généraux en utilisant simplement JSON? Combien de temps y a-t-il entre l'utilisation de TCP / IP et l'utilisation de HTTP? Quand devriez-vous utiliser Spring sur Netty, et vice versa pour créer un tel service?

java rest http serialization tcp HiChews123
la source
Il semble que vous pensiez plus à la pile technologique qu'à vos besoins réels. Comment pourrait-on répondre à cette question sans savoir ce que vous devez faire ? Créez-vous un jeu multijoueur censé avoir une latence quasi nulle? Ou une application de bookmarking social où la plupart des accès se font déjà via HTTP et vous pourriez mettre en cache des données pendant des heures à la fois et ne vous souciez même pas de la fraîcheur, sans parler de la latence?
Aaronaught
3
Je ne pense pas que OP nous demande de faire un choix pour lui. Il pose simplement une question de haut niveau sur la façon dont ces choix sont faits et quels facteurs sont pris en compte. Ne pensez pas qu'il y a quelque chose de mal à fournir une réponse de haut niveau à cela ... et je l'ai fait.
DXM
Je suis généralement opposé à l'utilisation de formats binaires, sauf si vous en avez vraiment besoin. Pas de formats de fichiers binaires, pas de sérialisations binaires, etc. Par exemple, en Java, les sérialisations binaires provoquent des incompatibilités entre les versions Java et les versions de votre propre logiciel, mais je pense que XML n'est pas aussi important. Je pense que le TCP / IP> HTTP> XML suivant Bien sûr, cela dépend de ce que vous faites. Je pense que JSON est une alternative à XML. Je ne sais pas grand chose sur Spring ou Netty, bien que je sache que les gens utilisent Spring.
Kaydell
+1 DXM, je pose des questions de haut niveau comme matière à réflexion lorsque je pense à prendre une telle décision.
HiChews123

Réponses:

21

Il y a certainement des avantages / inconvénients à utiliser JSON sur REST par rapport à TCP / IP direct avec un protocole binaire et je pense que vous soupçonnez déjà que le protocole binaire sera plus rapide. Je ne peux pas vous dire exactement combien de temps (et cela dépendrait de beaucoup de facteurs), mais je suppose que peut-être 1-2 ordres de différence de grandeur.

À première vue, si quelque chose est 10 à 100 fois plus lent que quelque chose d'autre, vous pourriez avoir une réaction instinctive et opter pour «chose rapide». Cependant, cette différence de vitesse ne concerne que le protocole lui-même. S'il y a un accès à la base de données / fichiers du côté serveur, cela ne sera pas affecté par votre choix de la couche de transfert. Dans certains cas, cela peut rendre la vitesse de votre couche de transfert beaucoup moins importante.

HTTP REST et JSON sont bons pour plusieurs raisons:

  • ils sont facilement consommables par n'importe qui. Vous pouvez écrire votre application Web, puis faire demi-tour et publier votre API pour le reste du monde à utiliser. Maintenant, n'importe qui peut atteindre les mêmes points finaux et accéder à vos services
  • ils sont facilement déboggables, vous pouvez ouvrir un renifleur de paquets ou simplement vider les demandes entrantes dans des fichiers texte et voir ce qui se passe. Vous ne pouvez pas faire ça avec des protocoles binaires
  • ils sont facilement extensibles. Vous pouvez ajouter plus d'attributs et de données ultérieurement et ne pas rompre la compatibilité avec les anciens clients.
  • consommable par les clients javascript (je ne suis pas sûr qu'ils aient encore l'analyseur protobuf JS, je ne pense pas qu'il y en ait un)

Protobufs sur TCP / IP:

  • ils sont plus rapides

Si c'était mon choix, j'irais de loin avec HTTP REST et JSON. Il y a une raison pour laquelle tant d'autres entreprises et sites Web ont choisi cette voie. Gardez également à l'esprit qu'à l'avenir, vous pourrez toujours prendre en charge 2 points d'extrémité. Si votre conception est correcte, votre choix de point final doit être complètement découplé de votre logique métier côté serveur ou de la base de données. Donc, si vous réalisez plus tard que vous avez besoin de plus de vitesse pour toutes / certaines demandes, vous devriez pouvoir ajouter des protobufs avec un minimum d'agitation. Mais dès le départ, REST / JSON vous fera décoller plus rapidement et vous mènera plus loin.

En ce qui concerne Netty vs Spring. Je n'ai pas utilisé Netty directement, mais je pense que c'est juste un serveur Web léger où Spring est un cadre qui vous offre beaucoup plus que cela. Il a des couches d'accès aux données, une planification des tâches en arrière-plan et (je pense) un modèle MVC, il est donc beaucoup plus lourd. Lequel choisir? Si vous avez décidé de passer à la méthode HTTP, la question suivante est probablement la norme de votre application Si vous êtes sur le point d'écrire une logique personnalisée folle qui ne correspond pas au moule standard et tout ce dont vous avez besoin est juste une couche de serveur HTTP, allez avec Netty.

Cependant, je soupçonne que votre application n'est pas si spéciale et qu'elle pourrait probablement bénéficier de beaucoup de choses que Spring a à offrir. Mais cela signifie que vous devez structurer votre application autour du cadre de Spring et faire les choses comme ils attendent de vous, ce qui signifierait en savoir plus sur Spring avant de plonger dans votre produit. Les cadres en général sont excellents, car ils vous permettent de décoller plus rapidement, mais l'inconvénient est que vous devez vous adapter à leur moule au lieu de faire votre propre conception, puis vous attendre à ce que le cadre fonctionne simplement.

(*) - dans le passé, il a été souligné que mes messages ne reflètent pas les opinions du monde entier, donc je vais enregistrer et ajouter simplement que j'ai une expérience limitée avec Netty (j'ai déjà utilisé le cadre Play qui est basé sur Netty) ou Spring (j'ai seulement lu à ce sujet). Alors, prenez ce que je dis avec un grain de sel.

DXM
la source
1
+1, en particulier pour "cette différence de vitesse ne concerne que le protocole lui-même. S'il y a un accès à la base de données / fichiers côté serveur, cela ne sera pas affecté par votre choix de la couche de transfert". 99% c'est exactement comme ça et l'optimisation prématurée (au mauvais endroit) n'y aidera pas du tout.
Shivan Dragon
Merci pour votre longue réponse et votre analyse approfondie de la comparaison des deux. Je comprends les avantages de la création d'une application RESTful car elle est facilement consommable par les clients publics. Dans le cas cependant, je veux tout garder en interne et je ne veux pas exposer le service (je m'occupe de la sérialisation / désérialisation), je ne vois pas pourquoi ne pas utiliser un protocole binaire personnalisé ne serait pas le premier choix. Oui, vous pouvez décoller plus rapidement avec les frameworks existants, mais au détriment d'être enfermés dans leurs API et un contrôle moins fin.
HiChews123
REST est facile à consommer par TOUS les clients, pas seulement par les clients publics, mais ils sont certainement inclus. Mon entreprise a un produit que nous construisons depuis environ un an maintenant. Nous avions un protocole "propriétaire" qui se trouvait être du repos. Nous venons de l'ouvrir aux autres. Une chose qu'ils vous enseignent à l'école de commerce est la «réflexion sur les options», prenez la décision de vous laisser autant d'options que possible afin que vous puissiez prendre des décisions à une date ultérieure. Donc, si tous les paramètres sont égaux, je choisirais REST non pas parce que j'ai des clients JS ou un accès API aujourd'hui, mais que j'ai la possibilité de l'avoir à l'avenir si j'en ai besoin. Là encore, si ...
DXM
... vous êtes prêt à utiliser le protocole binaire, allez-y. 96% de chances que votre choix de protocole n'ait aucun effet sur votre demande finale, donc je ne ferais pas trop de mal à cette décision. Et comme je l'ai dit dans la réponse, avec un design décent, vous devriez de toute façon pouvoir échanger des protocoles à une date ultérieure. Une autre chose que j'aime faire est d'essayer les deux cas, si je suis sur le point de prendre une décision, je lance une pièce et je choisis l'option A. La prochaine fois que je fais un projet similaire, je choisis l'option B juste pour pouvoir ensuite revenir en arrière et comparer / contraster mon expérience. Parfois, c'est la seule façon de décider par vous-même de ce qui est le mieux
DXM
@DXM, bonnes réponses, bravo!
HiChews123
0

C'est en fait une non question. Selon la suite de protocoles Internet, tcp est un protocole dans la couche transport et http est un protocole dans la couche application. Vous comparez des choses totalement différentes les unes aux autres. (Voir plus ici: http://en.wikipedia.org/wiki/Internet_protocol_suite )

En fait, la plupart des http sont sur tcp / ip. Donc, pour répondre à votre question, oui, vous devez utiliser tcp / ip. Ensuite, vous souhaitez ajouter un protocole de couche application sur celui-ci (comme http) puis un format de données (comme json, xml, html). Netty vous permet d'utiliser http et protobuff est égal à json, xml, html.

Tout dépend de vos besoins et du type de données à transporter. Avez-vous besoin de sessions dans votre protocole, une poignée de main peut-elle améliorer la configuration de votre protocole, combien de données enverrez-vous à la fois, avez-vous besoin d'un chiffrement? Ce sont des questions auxquelles vous devez répondre lors du choix d'un protocole d'application.

Pour choisir un format de représentation des données (json, xml, html, protobuff, etc.), cela dépend de votre bande passante, de la lisibilité, de la langue / de la prise en charge des outils, etc.

Vous ne pouvez pas comparer http à tcp.

N'oubliez pas que la vitesse n'est pas tout. La vitesse ne sert à rien si vous ne pouvez pas vous exprimer de manière sensée.

iveqy
la source
5
Il n'y a rien dans sa question qui suggère qu'il ne connaît pas la différence entre les couches de la pile réseau. Il a demandé s'il devait utiliser HTTP (le fait que HTTP est une couche au-dessus de TCP / IP est supposé) ou utiliser TCP / IP avec son propre protocole personnalisé. Il n'y a rien de mal à sa question.
Michael
Je suis en désaccord bien sûr. Ce n'est pas comme ça que je l'ai compris
iveqy
1
Oui, je comprends que HTTP est au-dessus de TCP / IP, ma question est en effet de penser à prendre une décision en termes de compromis - latence, vitesse de développement, etc. Merci de me poser des questions, cependant!
HiChews123
2
@ acspd7 J'éviterais de créer votre propre protocole, il existe de nombreux protocoles déjà éprouvés et à moins que votre protocole ne vous donne un avantage sur vos concurrents, vous êtes probablement mieux avec un protocole standard. J'ai implémenté un protocole personnalisé, c'était très amusant! Cependant, le cryptage, la perforation, le maintien en vie, la prise de contact (différents réseaux nécessitent des longueurs de trame différentes), etc., cela demande beaucoup de travail pour bien faire les choses. Sans oublier toute la documentation dont vous aurez besoin. Pensez à ce dont vous avez vraiment besoin dans les fonctionnalités avant de faire quelque chose de personnalisé.
iveqy
1
Les GPB sont bien documentés, utilisés par beaucoup d'autres, donc je ne vois vraiment aucun problème avec son utilisation. Être plus concis que XML et JSON devrait être génial! (vous pourriez manquer de lisibilité humaine, mais si ce n'est pas une exigence ...). Cependant, ne manquez-vous pas une couche? Habituellement, vous avez une couche entre tcp et xml, json, protobuff. Quelque chose comme http, ssh, etc.
iveqy