Agradeceríamos tu apoyo para extender nuestras crónicas acerca de las ciencias informáticas.
Solución:
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 dar crédito al autor por la idea, pero de todos modos también agregué mucho de mi propio conocimiento a la analogía central. Así que aquí va:
Un conector de transmisión es como una llamada telefónica: un lado hace la llamada, el otro responde, se saludan (SYN/ACK en TCP) y luego intercambian información. Una vez que haya terminado, se despide (FIN/ACK en TCP). Si un lado no escucha un adiós, generalmente llamará al otro ya que 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 los 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 que se modifique para cuando llegue allí. Si le pasa dos notas a la misma persona, es posible que lleguen en un 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. .
Por lo tanto, usa un socket de flujo cuando es importante tener información en orden e intacta. Los protocolos de transferencia de archivos son un buen ejemplo aquí. ¡No desea descargar un archivo con su contenido revuelto al azar y dañado!
Usaría un socket de datagramas cuando el pedido es menos importante que la entrega oportuna (piense en VoIP o protocolos de juegos), cuando no desea la mayor sobrecarga de una transmisión (es por eso que DNS es principalmente un protocolo de datagramas, para que los servidores puedan responder a muchas, muchas solicitudes a la vez muy rápidamente), o cuando no le importa demasiado si los datos alguna vez llegan a su destino.
Para ampliar el caso de VoIP/juego, dichos protocolos incluyen su propio mecanismo de ordenación de datos. Pero si un paquete se daña o se pierde, no desea esperar en el protocolo de transmisión (generalmente TCP) para emitir una solicitud de reenvío; debe recuperarse rápidamente. TCP puede tardar varios minutos en recuperarse, y para protocolos en tiempo real como juegos o VoIP, ¡incluso tres segundos pueden ser inaceptables! El uso de un protocolo de datagramas como UDP permite que el software se recupere de tal evento extremadamente rápido, simplemente ignorando los datos perdidos o volviéndolos a solicitar antes de lo que lo haría TCP.
VoIP es un buen candidato para simplemente ignorar los datos perdidos: una de las partes solo escucharía un breve espacio de tiempo, similar a lo que sucede cuando se habla con alguien por un teléfono celular cuando la recepción es deficiente. Los protocolos de juego suelen ser un poco más complejos, pero las acciones que se toman generalmente serán ignorar los datos que faltan (si los datos recibidos posteriormente reemplazan a los datos que se perdieron), volver a solicitar los datos que faltan o solicitar una actualización de estado completa para asegúrese de que el estado del cliente esté sincronizado con el del servidor.
Toma de corriente:
- Canal dedicado y de extremo a extremo entre el servidor y el cliente.
- Utilice el protocolo TCP para la transmisión de datos.
- Confiable y sin pérdidas.
- Datos enviados/recibidos en el mismo orden.
- Mucho tiempo para recuperar datos perdidos/equivocados
Zócalo de datagrama:
- Canal no dedicado y de extremo a extremo entre el servidor y el cliente.
- Utilice UDP para la transmisión de datos.
- No es 100% confiable y puede perder datos.
- Los datos del pedido enviado/recibido pueden no ser los mismos.
- No importa o recuperación rápida de datos perdidos/equivocados.
Sección de Reseñas y Valoraciones
Recuerda algo, que tienes autorización de decir .