sockets - servidor - ¿Cuál es la diferencia entre las transmisiones y los datagramas en la programación de la red?

sockets datagrama

Question

¿Cuál es la diferencia entre sockets (flujo) vs sockets (datagramas)? ¿Por qué usar uno sobre el otro?

Answer 1

Enchufe de corriente:

• Canal dedicado y punto a punto entre el servidor y el cliente.
• Use el protocolo TCP para la transmisión de datos.
• Confiable y sin pérdida.
• Datos enviados / recibidos en el orden similar.
• Mucho tiempo para recuperar datos perdidos / equivocados

Zócalo de Datagram:

• Sin canal dedicado y punto a punto entre el servidor y el cliente.
• Use UDP para la transmisión de datos.
• No es 100% confiable y puede perder datos.
• Los datos enviados / recibidos pueden no ser los mismos
• No importa o recupera rápidamente datos perdidos / equivocados

Answer 2

Hace mucho tiempo, leí una gran analogía para explicar la diferencia entre los dos. No recuerdo dónde lo leí, así que desafortunadamente no puedo atribuirle al autor la idea, pero de todos modos también he agregado mucho de mi propio conocimiento a la analogía central. Así que aquí va:

Una toma de corriente es como una llamada telefónica: una parte hace la llamada, la otra responde, se saludan entre sí (SYN / ACK en TCP) y luego intercambian información. Una vez que haya terminado, se despide (FIN / ACK en TCP). Si uno de los lados no oye un adiós, generalmente llamará al otro porque este es un evento inesperado; por lo general, el cliente se volverá a conectar al servidor. Existe una garantía de que los datos no llegarán en un orden diferente al que lo envió, y existe una garantía razonable de que los datos no se dañarán.

Un socket de datagrama es como pasar una nota en clase. Considere el caso en el que no está directamente al lado de la persona a la que le está pasando la nota; la nota viajará de persona a persona. Es posible que no llegue a su destino, y puede ser modificado cuando llegue allí. Si pasa dos notas a la misma persona, puede que lleguen en una orden que no pretendía, ya que la ruta que toman las notas a través del aula puede no ser la misma, una persona puede no pasar una nota tan rápido como otra, etc. .

Entonces, usa un socket de flujo cuando tener información en orden e intacta es importante. Los protocolos de transferencia de archivos son un buen ejemplo aquí. ¡No desea descargar ningún archivo con sus contenidos aleatoriamente mezclados y dañados!

Utilizaría un socket de datagrama cuando el orden es menos importante que la entrega oportuna (piense en protocolos VoIP o de juegos), cuando no desee una mayor sobrecarga de una secuencia (esta es la razón por la que DNS es principalmente un protocolo de datagramas, de modo que los servidores pueden responder a muchas, muchas solicitudes a la vez muy rápidamente), o cuando no le importa demasiado si los datos llegan a su destino.

Para ampliar el caso de VoIP / juego, dichos protocolos incluyen su propio mecanismo de ordenamiento de datos. Pero si un paquete está dañado o perdido, no desea esperar en el protocolo de transmisión (generalmente TCP) para emitir una solicitud de reenvío, necesita recuperarse rápidamente. El TCP puede tomar hasta varios minutos para recuperarse, y para protocolos en tiempo real como juegos o VoIP ¡incluso tres segundos pueden ser inaceptables! El uso de un protocolo de datagrama como UDP permite que el software se recupere de dicho evento de manera extremadamente rápida, simplemente ignorando los datos perdidos o volviéndolo a solicitar antes de lo que haría TCP.

VoIP es un buen candidato para simplemente ignorar los datos perdidos: una de las partes solo escucharía una brecha corta, similar a lo que sucede cuando se habla con alguien en un teléfono celular cuando tienen mala recepción. Los protocolos de juego a menudo son un poco más complejos, pero las acciones tomadas usualmente serán ignorar los datos faltantes (si los datos recibidos posteriormente sustituyen a los datos que se perdieron), volver a solicitar los datos faltantes o solicitar una actualización de estado completa a asegúrese de que el estado del cliente esté sincronizado con el del servidor.