servicios - TCP vs. Http Benchmark
tcp/ip pdf (3)
La pregunta para la que realmente necesita una respuesta es "¿Será TCP o HTTP más rápido para mi aplicación?". La respuesta es que depende de la naturaleza de su aplicación y de la forma en que usa TCP y / o HTTP en su aplicación. Un benchmark HTTP vs. TCP genérico no responderá a su pregunta, porque es probable que el benchmark no coincida con el comportamiento de su aplicación.
En teoría, una solución diseñada / implementada de manera óptima utilizando TCP será más rápida que una que use HTTP. Pero también puede ser mucho más trabajo implementar ... dependiendo de los detalles de su aplicación.
Hay otros problemas que pueden afectar su elección. Por ejemplo, es menos probable que se encuentre con problemas de firewall si usa HTTP que si usa TCP en algún puerto aleatorio. Otra es que HTTP facilitaría la implementación de un equilibrador de carga entre el servidor IIS y los sistemas back-end.
Finalmente, al final del día es probablemente más importante que su sistema sea confiable, mantenible y (quizás) escalable de lo que es rápido. Una estrategia sensata es implementar primero la versión simple, pero tiene planes en mente para hacerla más rápida ... si la solución simple es demasiado lenta.
Tengo una aplicación web sentada en IIS y hablando con [remota] Service-Machine. No estoy seguro de si elegir TCP o Http, como el protocolo principal.
más detalles:
- tendré más de un servicio / endpoint
- algunos de ellos serán de ida
- el otro será bidireccional
- las páginas web funcionarán frente a los servicios
- estamos hablando de un sitio web de alta escala
Sé la diferencia bastante bien, pero estoy buscando un buen punto de referencia, que muestre cuánto más rápido es el TCP.
Siempre podrías compararlo.
En general, si lo que desea lograr se puede realizar fácilmente a través de HTTP (es decir, la única razón por la que de otra manera pensaría en usar TCP sin procesar para un posible aumento del rendimiento) probablemente solo deba usar HTTP. Claro, puedes hacer la programación del socket, pero ¿para qué molestarse? Mucha gente ha dedicado mucho tiempo y esfuerzo a construir bibliotecas y servidores de clientes HTTP, y han pasado más tiempo optimizando y probando ese código de lo que posiblemente puedas gastar en tus sockets TCP. Simplemente hay tantos errores posibles que tendría que manejar, casos límite y optimizaciones que se pueden hacer, que normalmente es más fácil y más seguro usar una función de biblioteca para HTTP.
Además, las especificaciones HTTP definen todo tipo de características (y los clientes / servidores lo implementan, lo que se puede usar "gratis", es decir, sin trabajo adicional de implementación) lo que hace que la interoperabilidad entre terceros sea mucho más fácil. "Aquí está mi URL, aquí están las reglas para lo que envía, aquí están las reglas para lo que devuelvo ..."
HTTP es una capa construida en la parte superior de la capa TCP para algo que estandariza la transmisión de datos. Entonces, naturalmente, usar sockets TCP será menos pesado que usar HTTP. Si el rendimiento es lo único que le importa, TCP simple es la mejor solución para usted.
Es posible que desee considerar HTTP debido a su facilidad de uso y simplicidad que, en última instancia, reduce el tiempo de desarrollo. Si está haciendo algo que podría ser consumido directamente por un navegador (a través de una llamada AJAX), entonces debe usar HTTP. Para que un navegador no moderno pueda consumir directamente las conexiones TCP sin HTTP, debería usar Flash o Silverlight, y esto normalmente sucede con contenido enriquecido como video y / o audio. Sin embargo, muchos navegadores modernos ahora (a partir de 2013) admiten API para acceder a recursos de red, audio y video directamente a través de JavaScript. Lo único a considerar es la tasa de uso de los navegadores web modernos entre sus usuarios; consulte caniuse.com para obtener la información más reciente sobre la compatibilidad del navegador.
En cuanto a los puntos de referencia, esto es lo único que encontré. Vea la página 5, tiene el gráfico de rendimiento. Tenga en cuenta que realmente no compara manzanas con manzanas ya que compara la opción de datos TCP / Binary con la opción de datos HTTP / XML. Lo que nos lleva a la pregunta: ¿qué tipo de datos son sus servicios de salida? binario (video, audio, archivos) o texto (JSON, XML, HTML)?
En general, el sistema orientado al rendimiento, como los del sector militar o financiero, probablemente utilizará conexiones TCP simples. Mientras que las empresas centradas en la web general optarán por usar HTTP y usar IIS o Apache para alojar sus servicios.