Comparaison des applications TCP / IP et des applications HTTP
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 cadre comme Netty ( http://netty.io/ ) et format de sérialisation comme Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) et développez un serveur TCP qui envoie dans les deux sens la charge utile du protobuf sérialisé.
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?
Il y a certainement des avantages/inconvénients à utiliser JSON sur REST par rapport à TCP/IP direct avec 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 plus rapide (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 (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, je préfèrerais aller avec HTTP REST et JSON. Il y a une raison pour laquelle tant d'autres sociétés et sites Web ont choisi cette voie. Gardez également à l'esprit qu'à l'avenir, vous pourriez toujours prendre en charge 2 points de terminaison. Si votre conception est correcte, votre choix de point de terminaison 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 devrait être en mesure d'ajouter des protobufs avec un minimum de tracas. Dès le départ cependant, REST/JSON vous fera décoller plus rapidement et vous amè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 à quel point votre application est-elle standard? Si vous êtes sur le point d'écrire une logique personnalisée folle qui ne correspond pas au moule standard et que vous n'avez besoin que d'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 utilisé le cadre Play avant qui est basé sur Netty) ou Spring (j'ai seulement lu à ce sujet). Alors, prenez ce que je dis avec un grain de sel.
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.