TCP Vs. Http Benchmark

Question

Je vais avoir une application Web assis sur IIS, et de parler avec [remote]Service de la Machine. Je ne suis pas sûr que ce soit de choisir TCP ou Http, le protocole principale.

plus de détails:

1. je vais avoir plus d'un service\extrémité
2. certains d'entre eux seront d'une manière
3. l'autre sera de deux façons
4. les pages du site web de travail en face de la les services
5. nous parlons hi-échelle de web-site

Je sais faire la différence assez bien, mais je suis à la recherche d'un bon point de repère, qui montre comment beaucoup plus rapide est le TCP?

Answer 1

HTTP est un calque construit ontop de la couche TCP pour certains ce normaliser la transmission de données. Alors, naturellement, à l'aide de sockets TCP sera moins lourde utilisant le protocole HTTP. Si la performance est la seule chose que vous vous souciez de simple, le protocole TCP est la meilleure solution pour vous.

Vous souhaitez mai à envisager HTTP raison de sa facilité d'utilisation et la simplicité, ce qui en fin de compte réduit les temps de développement. Si vous faites quelque chose qui peut être consommée directement par un navigateur (par le biais d'un appel AJAX), alors vous devez utiliser le protocole HTTP. Pour un non-navigateur moderne à consommer directement les connexions TCP sans HTTP, vous devez utiliser de Flash ou Silverlight et ce qui se passe normalement pour les riches de contenu, tels que la vidéo et/ou audio. Cependant, beaucoup de navigateurs modernes maintenant (2013) de support de l'API pour accéder au réseau, audio et vidéo des ressources directement via JavaScript. La seule chose à considérer est le taux d'utilisation des navigateurs web modernes parmi vos utilisateurs; voir caniuse.com pour les dernières infos concernant la compatibilité du navigateur.

Comme pour les indices de référence, c' est la seule chose que j'ai trouvé. Voir à la page 5, il est la représentation graphique de la performance. Notez qu'il n'a pas vraiment comparer des pommes avec des pommes, car il compare le protocole TCP/données Binaires option avec HTTP/XML des données de l'option. Ce qui amène la question: quel type de données sont vos services en sortie? binaire (vidéo, audio, fichiers) ou texte (JSON, XML, HTML)?

En général axés sur la performance du système, comme ceux de l'armée ou le secteur financier seront probablement utiliser de simples connexions TCP. Où que le web axé entreprises opteront pour utiliser le protocole HTTP et utiliser IIS ou Apache pour héberger leurs services.

Answer 2

La question que vous avez vraiment besoin d'une réponse pour est "va TCP ou HTTP-être plus rapide pour mon application". La réponse est que cela dépend de la nature de votre demande, et sur la façon dont vous utilisez le protocole TCP et/ou l'adresse HTTP dans votre application. Un générique vs HTTP TCP de référence ne pourront pas répondre à votre question, parce que les chances sont que le point de référence ne correspond pas à votre demande de comportement.

En théorie, une conception optimale / solution mise en œuvre à l'aide de TCP sera plus rapide que celui qui utilise le protocole HTTP. Mais il peut aussi être beaucoup plus de travail à mettre en œuvre ... selon les détails de votre demande.

Il y a d'autres questions qui pourraient influer sur votre choix. Par exemple, vous êtes moins susceptible de courir dans des problèmes de pare-feu si vous utilisez HTTP que si vous utilisez le protocole TCP sur certains de port aléatoire. Une autre est que HTTP rendre plus facile à mettre en œuvre un programme d'équilibrage de charge entre les serveurs IIS et les systèmes dorsaux.

Enfin, à la fin de la journée, il est probablement plus important que votre système est fiable, facile à entretenir et (peut-être) évolutif qu'il est rapide. Une stratégie sensée est de mettre en œuvre la version simple de la première, mais ont des plans dans votre tête pour savoir comment le rendre plus rapide ... si la solution la plus simple est trop lent.

Answer 3

Vous pouvez toujours comparer.

En général, si ce que vous voulez accomplir peut être fait facilement via HTTP (c'est à dire la seule raison pour laquelle vous ne pourrait le penser sur l'utilisation de TCP est pour une possible augmentation des performances), vous devriez probablement utiliser HTTP. Bien sûr, vous pouvez faire programmation socket, mais pourquoi s'embêter? Beaucoup de gens ont passé beaucoup de temps et d'efforts bâtiment HTTP bibliothèques clientes et serveurs, et ils ont passé waaaaaay plus de temps à l'optimisation et tests de code que vous aurez jamais être en mesure de peut-être passer sur votre sockets TCP. Il ya tout simplement beaucoup d'éventuelles erreurs que vous avez à gérer, les cas limites et les optimisations qui peuvent être faites, qu'il est généralement plus facile et plus sûr d'utiliser une fonction de la bibliothèque pour HTTP.

De Plus, la HTTP spécifications de définir tous les types de fonctionnalités (et clients/serveurs de mettre en œuvre, vous arrivez à utiliser "gratuitement", c'est à dire sans supplément de mise en œuvre) qui fait un tiers de l'interopérabilité que beaucoup plus facile. "Voici l'adresse de ma page, voici les règles de ce que vous envoyez, voici les règles pour ce que j'en retour..."

Answer 4

Je le compare avec un simple ping-pong.

Pour la connexion socket, j'utilise Ruby comme serveur et l'appareil Android comme client.

Pour la connexion HTTP, j'utilise Sinatra (Ruby) comme serveur et l'appareil Android comme client.

La connexion socket est 10 fois plus rapide que la connexion HTTP.