Comparación de aplicaciones TCP / IP versus aplicaciones HTTP [cerrado]

13

Estoy interesado en desarrollar un sitio web a gran escala orientado al usuario escrito en Java.

En cuanto al diseño, estoy pensando en desarrollar servicios modulares independientes que puedan actuar como proveedores de datos para mi aplicación web principal.

En cuanto a la escritura de estos servicios modulares (proveedores de datos), puedo aprovechar un marco existente como Spring y desarrollar estos servicios siguiendo el patrón de diseño RESTful, y exponer recursos a través de HTTP con un formato de mensaje como JSON ... o puedo aprovechar una red existente marco como Netty ( http://netty.io/ ) y el formato de serialización como Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) y desarrollan un servidor TCP que envía de ida y vuelta el protobuf serializado carga útil.

¿Cuándo debes elegir uno sobre el otro? ¿Sería beneficioso usar un formato de serialización como Protobufs y enviar un flujo de bytes a través del cable? ¿Habría una sobrecarga al usar JSON? ¿Cuánta sobrecarga hay entre usar TCP / IP y HTTP? ¿Cuándo debería usar Spring sobre Netty, y viceversa para construir dicho servicio?

java rest http serialization tcp HiChews123
fuente
Parece que estás pensando más en la pila de tecnología que en los requisitos reales. ¿Cómo podría alguno de nosotros responder esta pregunta sin saber qué es lo que necesita hacer ? ¿Estás creando un juego multijugador que se supone que tiene una latencia cercana a cero? ¿O una aplicación de marcadores sociales en la que la mayor parte del acceso ya se realiza a través de HTTP y es posible que esté almacenando datos en caché durante horas y ni siquiera se preocupe por la frescura, y mucho menos la latencia?
Aaronaught
3
No creo que OP nos pida que tomemos una decisión por él. Simplemente hace una pregunta de alto nivel sobre cómo se toman esas decisiones y qué factores se consideran. No piense que hay algo malo en proporcionar una respuesta de alto nivel a eso ... y lo hice.
DXM
Generalmente me opongo al uso de formatos binarios a menos que realmente tenga que hacerlo. Sin formatos de archivos binarios, sin serializaciones binarias, etc. Por ejemplo, en Java, las serializaciones binarias causan incompatibilidades entre las versiones de Java y las versiones de su propio software, pero creo que XML no es tanto. Creo que el siguiente TCP / IP> HTTP> XML Por supuesto, dependerá de lo que esté haciendo. Creo que JSON es una alternativa a XML. No sé mucho sobre Spring o Netty, aunque sí leo que la gente está usando Spring.
Kaydell
+1 DXM, estoy haciendo preguntas de alto nivel como alimento para pensar cuando pienso en tomar tal decisión.
HiChews123

Respuestas:

21

Definitivamente hay ventajas y desventajas sobre el uso de JSON sobre REST frente a TCP / IP directo con protocolo binario y creo que ya sospecha que el protocolo binario será más rápido. No puedo decir exactamente cuánto más rápido (y esto dependería de muchos factores), pero supongo que tal vez una diferencia de 1-2 órdenes de magnitud.

A primera vista, si algo es 10-100 veces más lento que otra cosa, es posible que tenga una reacción instintiva e intente "algo rápido". Sin embargo, esta diferencia de velocidad es solo en el protocolo en sí. Si hay acceso a la base de datos / archivos en el lado del servidor, eso no se verá afectado por la elección de la capa de transferencia. En algunos casos, puede hacer que la velocidad de la capa de transferencia sea mucho menos significativa.

HTTP REST y JSON son buenos por varias razones:

  • son fácilmente consumibles por casi cualquier persona. Puede escribir su aplicación web, luego dar la vuelta y publicar su API para que la use el resto del mundo. Ahora cualquiera puede alcanzar los mismos puntos finales y acceder a sus servicios
  • son fácilmente depurables, puede abrir un sniffer de paquetes o simplemente volcar las solicitudes entrantes en archivos de texto y ver qué sucede. No puedes hacer eso con protocolos binarios
  • Son fácilmente extensibles. Puede agregar más atributos y datos más adelante y no romper la compatibilidad con clientes antiguos.
  • consumible por clientes javascript (no estoy seguro de que tengan protobuf JS parser todavía, no creo que haya uno)

Protobufs sobre TCP / IP:

  • son mas rapidos

Si fuera mi elección, sin duda iría con HTTP REST y JSON. Hay una razón por la que muchas otras compañías y sitios web tomaron esa ruta. También tenga en cuenta que en el futuro siempre podría admitir 2 puntos finales. Si su diseño es correcto, su elección de punto final debe estar completamente desacoplada de la lógica de negocios del lado del servidor o de la base de datos. Entonces, si luego se da cuenta de que necesita más velocidad para todas / algunas solicitudes, debería poder agregar protobufs con un mínimo de alboroto. Sin embargo, REST / JSON lo levantará del suelo más rápido y lo llevará más lejos.

En cuanto a Netty vs Spring. No he usado Netty directamente, pero creo que es solo un servidor web liviano donde Spring es un marco que proporciona mucho más para ti que eso. Tiene capas de acceso a datos, programación de trabajos en segundo plano y (creo) un modelo MVC, por lo que es mucho más pesado. ¿Cuál elegir? Si decidió seguir el camino HTTP, entonces la siguiente pregunta es, ¿qué tan estándar es su aplicación? Si está a punto de escribir una lógica personalizada loca que no se ajusta al molde estándar y todo lo que necesita es solo una capa de servidor HTTP, vaya con Netty.

Sin embargo, sospecho que su aplicación no es tan especial y probablemente podría beneficiarse de muchas cosas que Spring tiene para ofrecer. Pero eso significa que debe estructurar su aplicación en torno al marco de Spring y hacer las cosas como ellos esperan que haga, lo que significaría aprender más sobre Spring antes de sumergirse en su producto. Los marcos en general son geniales porque nuevamente te hacen despegar más rápido, pero la desventaja es que tienes que encajar en su molde en lugar de hacer tu propio diseño y luego esperar que el marco funcione.

(*) - en el pasado se señaló que mis publicaciones no reflejan las opiniones del mundo entero, así que iré al registro y solo agregaré que tengo una experiencia limitada con Netty (he usado el marco de Play antes que se basa en Netty) o Spring (solo he leído sobre eso). Así que toma lo que digo con un grano de sal.

DXM
fuente
1
+1, especialmente para "esta diferencia de velocidad es solo en el protocolo en sí. Si hay acceso a la base de datos / archivo en el lado del servidor, eso no se verá afectado por la elección de la capa de transferencia". 99% así es exactamente como será, y la optimización prematura (en el lugar equivocado) no ayudará con eso en absoluto.
Shivan Dragon
Gracias por su larga respuesta y análisis en profundidad sobre la comparación de los dos. Entiendo los beneficios de construir una aplicación RESTful porque es fácilmente consumible por clientes públicos. Sin embargo, en el caso que quiero mantener todo en casa y no quiero exponer el servicio (me encargo de la serialización / deserialización), no puedo ver por qué no usar un protocolo binario personalizado no sería la primera elección. Sí, puede despegar más rápido con los marcos existentes, pero a expensas de estar bloqueado en sus API y tener un control menos detallado.
HiChews123
REST es fácil de consumir para TODOS los clientes, no solo los públicos, sino que ciertamente están incluidos. Mi empresa tiene un producto que hemos estado construyendo durante aproximadamente un año. Teníamos un protocolo "propietario" que resultó ser el descanso. Acabamos de abrirlo a otros. Una cosa que te enseñan en la escuela de negocios es el "pensamiento de opciones", toma decisiones para dejarte tantas opciones como sea posible para que puedas tomar decisiones en una fecha posterior. Entonces, dado que todo está igual, elegiría REST no porque hoy tenga clientes JS o acceso a la API, sino porque tengo la opción de tenerlo en el futuro si lo necesito. Por otra parte, si ...
DXM
... está configurado para usar el protocolo binario, adelante. 96% de probabilidad de que su elección de protocolo no tenga ningún efecto en su aplicación final, por lo que no sudaría demasiado esa decisión. Y como dije en la respuesta, con un diseño decente, de todos modos debería poder intercambiar protocolos en una fecha posterior. Otra cosa que me gusta hacer es probar ambos casos, si estoy cerca de tomar una decisión, lanzo una moneda y elijo la opción A. La próxima vez que haga un proyecto similar elijo la opción B solo para poder regresar y compara / contrasta mi experiencia. A veces, esa es la única forma de decidir por ti mismo cuál es mejor
DXM
@DXM, excelentes respuestas, bravo!
HiChews123
0

Esto no es una pregunta real. Según el conjunto de protocolos de Internet, tcp es un protocolo en la capa de transporte y http es un protocolo en la capa de aplicación. Estás comparando cosas totalmente diferentes entre sí. (Ver más aquí: http://en.wikipedia.org/wiki/Internet_protocol_suite )

De hecho, la mayoría de http está sobre tcp / ip. Entonces, para responder a su pregunta, sí, debe usar tcp / ip. Luego, desea agregar un protocolo de capa de aplicación sobre eso (como http) y luego un formato de datos (como json, xml, html). Netty te permite usar http y protobuff es igual a json, xml, html.

Todo depende de cuáles sean sus requisitos y qué tipo de datos necesitará transportar. ¿Necesita sesiones en su protocolo, puede un apretón de manos mejorar la configuración de su protocolo, cuántos datos enviará a la vez, necesita cifrado? Estas son preguntas que debe responder al elegir un protocolo de aplicación.

Para elegir un formato de representación de datos (json, xml, html, protobuff, etc.) depende de su ancho de banda, legibilidad, soporte de idioma / herramienta, etc.

No puede comparar http con tcp.

Recuerda que la velocidad no lo es todo. La velocidad no sirve de nada si no puede expresarse de manera sensata.

iveqy
fuente
55
No hay nada en su pregunta que sugiera que no conoce la diferencia entre las capas de la pila de redes. Preguntó si debería usar HTTP (se supone que HTTP es una capa superior a TCP / IP) o usar TCP / IP con su propio protocolo personalizado. No hay nada malo con su pregunta.
Michael
No estoy de acuerdo, por supuesto. Así no es como lo entendí
iveqy
1
Sí, entiendo que HTTP está en una capa por encima de TCP / IP, mi pregunta es sobre pensar en tomar una decisión en términos de compensaciones: latencia, velocidad de desarrollo, etc. ¡Gracias por hacerme preguntas para pensar!
HiChews123
2
@ acspd7 Evitaría crear su propio protocolo, hay muchos protocolos ya probados y, a menos que su protocolo sea algo que le brinde una ventaja sobre sus competidores, probablemente esté mejor con un protocolo estándar. He implementado un protocolo personalizado, ¡fue muy divertido! Sin embargo, el cifrado, la perforación, mantener vivo, el apretón de manos (diferentes redes requieren diferentes longitudes de trama), etc. es mucho trabajo para hacer las cosas bien. Sin mencionar toda la documentación que necesitará. Piense en lo que realmente necesita en las funciones antes de hacer algo personalizado.
iveqy
1
GPB está bien documentado, utilizado por muchos otros, por lo que realmente no puedo ver ningún problema con su uso. Ser más conciso que XML y JSON debería ser genial. (Es posible que le falte legibilidad humana, pero si eso no es un requisito ...). Sin embargo, ¿no te pierdes una capa? Por lo general, tiene una capa entre tcp y xml, json, protobuff. Algo como http, ssh, etc.
iveqy