¿Cuál es la diferencia fundamental entre WebSockets y TCP puro?

167

He leído sobre WebSockets y me pregunto por qué el navegador no puede simplemente abrir una conexión TCP trivial y comunicarse con el servidor como cualquier otra aplicación de escritorio. ¿Y por qué esta comunicación es posible a través de websockets?

tcp websocket

— xap4o
fuente

8

Pero cual es el problema? Déjelos usar TCP.

— xap4o

2

Más información stackoverflow.com/questions/8051516/…

— Hernán Eche

2

"WebSocket es un protocolo que proporciona canales de comunicaciones full-duplex a través de una única conexión TCP". ¿También puede crear conexiones TCP que sean full duplex? ¿Qué tiene de especial WebSockets?

— Abhishek Jain

12

El problema es que, por lo general, los servidores web tienen un solo puerto abierto por razones de seguridad, a saber, el puerto 80. Por definición, un puerto puede conectarse a una sola aplicación SOLAMENTE . Entonces, ¿qué pasa si un cliente quiere usar un servicio que no sea web (HTTP) pero solo hay un puerto disponible? Voila! Websockets!

— Pithikos

3

@Pithikos dio en el blanco por qué necesitamos esta complejidad de sockets web y no solo tratamos con sockets TCP directos para la comunicación entre el navegador y el servidor.

— Soleado

260

Es más fácil comunicarse a través de sockets TCP cuando está trabajando dentro de un límite de intranet, ya que probablemente tenga control sobre las máquinas en esa red y pueda abrir puertos adecuados para realizar las conexiones TCP.

A través de Internet, se está comunicando con el servidor de otra persona en el otro extremo. Es extremadamente improbable que tenga algún socket antiguo abierto para las conexiones. Por lo general, solo tendrán unos pocos estándares, como el puerto 80 para HTTP o 443 para HTTPS. Por lo tanto, para comunicarse con el servidor, está obligado a conectarse mediante uno de esos puertos.

Dado que estos son puertos estándar para servidores web que generalmente hablan HTTP, por lo tanto, está obligado a cumplir con el protocolo HTTP; de lo contrario, el servidor no le hablará. El propósito de los sockets web es permitirle iniciar una conexión a través de HTTP, pero luego negociar el uso del protocolo de sockets web (suponiendo que el servidor sea capaz de hacerlo) para permitir un flujo de comunicación similar al "socket TCP".

— Ceniza
fuente

2

Gracias por una explicación fácil, Ash.

— xap4o

Entonces, ¿básicamente WebSocket es simplemente un contenedor para TCP en el sentido de que UDP es simplemente un contenedor para IP?

— Pacerier

3

@Pacerier: un WebSocket requiere algún tipo de protocolo de transporte para operar, pero esa capa de transporte no tiene que ser TCP (aunque casi siempre será TCP en la práctica). Se podría pensar en WebSockets como una especie de envoltorio alrededor de TCP, pero no creo que haya ningún vínculo prescriptivo entre los dos.

— Ash

44

"A través de Internet, se está comunicando con el servidor de otra persona en el otro extremo". "Dado que estos son puertos estándar (80 y 443) para servidores web que generalmente hablan HTTP, por lo tanto, está obligado a cumplir con el protocolo HTTP , de lo contrario, el servidor no te hablará ". Por lo general, el servidor websocket al que accedemos sería el nuestro. Entonces podemos tener una aplicación con un protocolo que definimos para escuchar un puerto. Entonces, ¿por qué necesitaríamos un protocolo de enlace HTTP y un cambio de protocolo? En cambio, ¿por qué no podemos seguir directamente un protocolo websocket?

— Ratul

2

Por RFC6455, WebSocket necesita un protocolo de enlace en HTTP primero y luego el protocolo se actualiza a WebSocket. La mayoría del navegador sigue esto. No sé cómo admitirá su lado del cliente (navegador), si está utilizando algún protocolo en el servidor. Es como si pudiéramos comunicarnos en francés, solo los dos sabemos francés. Y el apretón de manos es como, te pregunto, '¿Podemos comunicarnos en francés?' En inglés (aquí HTTP). Aquí los navegadores (como Chrome) saben francés pero tenemos que enseñarle francés al servidor. Mi pregunta fue por qué RFC6455 (WebSocketProtocol) quiere hacer el protocolo de enlace en HTTP y complicar las cosas, ¿por qué no pueden hacerlo a su manera?

— Ratul

31

Los navegadores web operan en la capa de aplicación, mientras que TCP opera en la capa de transporte. Como desarrollador de aplicaciones web, es más fácil enviar mensajes por cable a través de la capa de aplicación en lugar de bytes sin procesar en la capa de transporte.

La base de WebSockets es TCP, simplemente se abstrae por simplicidad.

— wulfgarpro
fuente

2

Websocket es un protocolo de capa de aplicación, mientras que TCP es el protocolo de capa de transporte. En la capa de transporte, generalmente tenemos el protocolo TCP y UDP. Cualquier mensaje de la capa de aplicación debe pasar por la capa de transporte para transmitirse a otra máquina. Por lo tanto, websocket y tcp tienen una relación entre sí y no pueden ser comparables.

— Minh Trần
fuente

2

Para simplificarlo, las comunicaciones websocket se realizan a través del puerto TCP número 80 (o 443 en el caso de las conexiones cifradas con TLS), lo cual es beneficioso para aquellos entornos que bloquean las conexiones a Internet que no son de la web utilizando un firewall .

¿Le gustaría utilizar el puerto TCP existente o abrir un nuevo puerto TCP que podría estar bloqueado por el firewall?

— Eugene
fuente