2011-09-07 14 views
11

Estaba considerando hacer un servidor de chat usando node.js/socket.io. ¿Debo hacerlo un servidor tcp o un servidor http? Me imagino que el servidor tcp sería más eficiente, pero ¿puedes enviar otras cosas como archivos adjuntos, etc.? Si tcp es más eficiente, ¿cuánto más? Además, ¿solo me pregunto cuántas conexiones simultáneas puede manejar un servidor node.js? ¿Es más trabajo hacer TCP o HTTP?Discusión: servidor de chat a través de node.js: ¿HTTP o TCP?

Respuesta

25

Aquí hablamos de 2 enfoques totalmente diferentes: TCP es un protocolo de capa de transporte y HTTP es un protocolo de capa de aplicación. HTTP (por lo general) funciona a través de TCP, por lo que cualquier opción que elija, todavía estará operando a través de TCP.

La cuestión de la eficiencia es una especie de punto discutible, porque estás hablando de OSI layers diferentes. Si eligió sockets TCP sin procesar, su solución probablemente sea más eficiente, al menos en ancho de banda, ya que HTTP contiene un montón de datos adicionales (los encabezados) que probablemente sean irrelevantes para sus propósitos (dependiendo de la escala del chat). programa). De lo que estás hablando desarrollar es tu propio protocolo de capa de aplicación.

Puede enviar todo lo que quiera sobre TCP; después de todo, HTTP puede enviar archivos adjuntos, y eso funciona a través de TCP. FTP también opera a través de TCP, y está diseñado exclusivamente para transferir "archivos adjuntos". Para hacer esto, necesitaría escribir su protocolo para poder decirle a la ubicación remota que los siguientes datos eran un archivo, luego enviar los datos del archivo y luego decirle a la ubicación remota que la transferencia se completó. Las implementaciones de esto son muchas y variadas (el enfoque HTTP es completamente diferente del enfoque FTP) y sus opciones son bastante infinitas.

No estoy seguro sobre el límite de conexión node.js, pero puedo decir con bastante confianza que está limitado por el sistema operativo. This podría ayudarlo a familiarizarse con la respuesta a esa pregunta.

Es discutible si es más trabajo hacerlo con TCP o HTTP, es mucho trabajo hacerlo en ambos. Probablemente me inclinaría más hacia la opción TCP como tu mejor opción. Mientras que TCP requeriría que diseñaras un protocolo en lugar de/además de una aplicación, HTTP no es particularmente adecuado para aplicaciones bidireccionales en vivo como los servidores de chat. Hay muchas implementaciones de chat a través de HTTP que usan AJAX, pero puedo decirte por experiencia dolorosa que son un dolor completo en la parte trasera.

Yo diría que solo debe mirar HTTP si tiene la intención de que el punto final (es decir, el cliente) sea un navegador. Si vas a escribir una aplicación de escritorio para el punto final, un enlace TCP directo definitivamente sería el camino a seguir. La razón principal de esto es que HTTP funciona de manera de solicitud y respuesta, donde el cliente envía una solicitud al servidor y el servidor responde. Sobre TCP puede abrir una única transmisión TCP, que se puede usar para la comunicación bidireccional. Esto significa que el servidor puede enviar un evento al cliente al instante, mientras que a través de HTTP debe esperar que el cliente envíe una solicitud para que pueda responder con un evento. Si tenía la intención de utilizar un navegador como cliente, esto haría que la transferencia de todo el archivo sea mucho más complicada (al menos el envío).

Hay formas de implementar esto a través de HTTP utilizando long-polling y servidor push (read this) pero puede ser un verdadero dolor de implementar.

Si va a implementar esto en una LAN (o posiblemente incluso a través de Internet) vale la pena considerar UDP sobre TCP: en una aplicación de chat no es absolutamente crítico que los mensajes lleguen en el orden correcto y incluso si lo fuera, los usuarios probablemente no podrían escribir más rápido que las variaciones en la latencia de la red (probablemente < 100ms). Luego, para las transferencias de archivos, puede negociar un socket TCP separado para el intercambio de datos (como FTP) o implementar algún tipo de sistema UDP ACK (como TFTP).

Siento que hay mucho más para decir sobre este tema, pero en este momento no puedo expresarlo en palabras: puedo extender esta respuesta en algún momento.

+0

¿tiene alguna idea de cómo hacer tcp con el lado del cliente node.js/socket.io? Tengo esta pregunta enumerada aquí también: http://stackoverflow.com/questions/7340475/client-side-tcp-with-node-js-socket-io – Derek

+0

por cierto. gracias por explicar mucho. está ayudando mucho Sin embargo, ¿puedes explicar más sobre udp y sus ventajas/desventajas sobre tcp? ¡muchas gracias! – Derek

+0

¿La pérdida de paquetes udp afecta a una aplicación de chat? – Derek

2

Los servidores de chat son el programa Hello World en el nodo. Use http.

En cuanto a la cuestión de cuántas conexiones concurrentes puede manejar, todo depende de su sistema. Configure un servidor de chat simple y luego intente compararlo.

Además, consulte http://search.npmjs.org/ y busque chat para algunos punteros.

Cuestiones relacionadas