Respuestas:
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 he agregado mucho de mi propio conocimiento a la analogía central. Entonces aquí va:
Una toma de corriente es como una llamada telefónica: un lado realiza 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 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 usted envió, y hay 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 pasa la nota; la nota viajará de persona a persona. Es posible que no llegue a su destino, y puede ser modificado para cuando llegue allí. Si pasa dos notas a la misma persona, es posible que lleguen en un orden que no tenía intención, 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, utiliza 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 querrás descargar algún archivo con su contenido aleatoriamente mezclado y dañado!
Usaría un socket de datagrama cuando el pedido sea menos importante que la entrega oportuna (piense en los protocolos de juego o VoIP), cuando no desee una mayor sobrecarga de una transmisión (es por eso que DNS es principalmente un protocolo de datagrama, 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 llegan a su destino.
Para ampliar el caso de VoIP / juego, dichos protocolos incluyen su propio mecanismo de pedido 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. El TCP puede tardar hasta 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 datagrama como UDP permite que el software se recupere de tal evento extremadamente rápido, simplemente ignorando los datos perdidos o volviendo a solicitarlos 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 una brecha breve, similar a lo que sucede cuando se habla con alguien por teléfono celular cuando tienen una recepción deficiente. Los protocolos de juego son a menudo un poco más complejos, pero las acciones tomadas generalmente serán ignorar los datos faltantes (si los datos recibidos posteriormente reemplazan a los datos perdidos), volver a solicitar los datos faltantes 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:
Enchufe de datagrama:
Si se trata de la programación de red, creo que comenzar desde sockets sería un buen comienzo.
socket = ip + port
hay tres tipos de
flujo de sockets (TCP, pedido y entrega garantizados, sin duplicación, sin límites de longitud o carácter para datos,
datagrama orientado a conexión, confiable, concurrencia) (UDP, basado en paquetes, sin conexión, datagrama límite de tamaño, los datos pueden perderse o duplicarse, orden no garantizada, no confiable) sin
procesar (acceso directo a los protocolos de capa inferior IP, ICMP)
No veo ninguna regla estricta para el tipo de protocolo de transporte en cuanto a qué socket debe usar qué protocolo de transporte y la fiabilidad no debe confundirse porque UDP es confiable en caso de que ambos extremos estén activos.
La confiabilidad se refiere más a la confiabilidad de la entrega ya que hay verificaciones de números de secuencia usando TCP como protocolo de transporte que no existen en UDP. Es mejor usar un analizador de protocolos de red como wireshark tcpdump, etc. para ver qué está haciendo exactamente su software; tipo de verificación o teoría de fusión en el papel con su trabajo en acción.