Esta podría ser una pregunta tonta:
- ¿HTTP alguna vez usa el protocolo de datagramas de usuario?
Por ejemplo:
Si uno está transmitiendo MP3 o video usando HTTP, ¿usa internamente UDP para el transporte?
Esta podría ser una pregunta tonta:
Por ejemplo:
Si uno está transmitiendo MP3 o video usando HTTP, ¿usa internamente UDP para el transporte?
Respuestas:
Normalmente, no.
La transmisión por secuencias rara vez se utiliza a través de HTTP, y HTTP rara vez se ejecuta a través de UDP. Sin embargo, consulte RTP .
Para algo como su ejemplo (en el comentario), no está mostrando un protocolo para el recurso. Si ese protocolo fuera HTTP, entonces no llamaría "streaming" al acceso; incluso si en algún sentido de la palabra es porque está enviando un recurso (posiblemente grande) en serie a través de una red. Normalmente, el recurso se guardará en el disco local antes de reproducirse, por lo que la transferencia de red no es lo que normalmente se entiende por "transmisión".
Sin embargo, como han señalado los comentaristas, es ciertamente posible transmitir a través de HTTP, y eso es lo que hacen algunos.
server push
, donde la conexión HTTP enviaba MJPEG (múltiples imágenes JPEG) cada una como una parte separada de una respuesta MIME multiparte a la solicitud HTTP. Cada imagen JPEG llega y reemplaza a la anterior en la pantalla. Pero tienes razón @unwind, esto rara vez se hace hoy, ya que RTP / RTSP funciona mejor.
Desde RFC 2616 :
La comunicación HTTP generalmente tiene lugar a través de conexiones TCP / IP. El puerto predeterminado es TCP 80, pero se pueden utilizar otros puertos. Esto no impide que HTTP se implemente sobre cualquier otro protocolo en Internet o en otras redes. HTTP solo presupone un transporte confiable; se puede utilizar cualquier protocolo que proporcione tales garantías; la correspondencia de las estructuras de solicitud y respuesta HTTP / 1.1 con las unidades de datos de transporte del protocolo en cuestión está fuera del alcance de esta especificación.
Entonces, aunque no lo dice explícitamente, UDP no se usa porque no es un "transporte confiable".
EDITAR : más recientemente, el protocolo QUIC (que es más estrictamente un pseudo-transporte o un protocolo de capa de sesión) usa UDP para transportar tráfico HTTP / 2.0 y gran parte del tráfico de Google ya usa este protocolo. Actualmente está progresando hacia la estandarización como HTTP / 3 .
Quizás solo un poco de trivia, pero UPnP usará mensajes con formato HTTP sobre UDP para el descubrimiento de dispositivos.
METHOD
conjunto es diferente. Después de eso, UPnP usa otros protocolos (y generalmente TCP) para el resto de lo que hace.
Sí, HTTP, como protocolo de aplicación, se puede transferir a través del protocolo de transporte UDP. Estos son algunos de los servicios que utilizan UDP y un protocolo subyacente para transferir datos HTTP y transmitirlos al usuario final:
Este artículo contiene más detalles sobre la transmisión por UDP y su superconjunto confiable, el RUDP: Reliable UDP (RUDP): ¿El próximo gran protocolo de transmisión?
Quizás algún cambio en este tema con QUIC
QUIC (Quick UDP Internet Connections, pronunciado rápido) es un protocolo de red de capa de transporte experimental desarrollado por Google e implementado en 2013. QUIC admite un conjunto de conexiones multiplexadas entre dos puntos finales a través del User Datagram Protocol (UDP) y fue diseñado para brindar protección de seguridad equivalente a TLS / SSL, junto con una conexión y una latencia de transporte reducidas, y una estimación del ancho de banda en cada dirección para evitar la congestión. El objetivo principal de QUIC es optimizar las aplicaciones web orientadas a la conexión que actualmente utilizan TCP.
Si está transmitiendo un mp3 o video que no necesariamente sea a través de HTTP, de hecho, me sorprendería que lo fuera. Probablemente sería otro protocolo sobre TCP, pero no veo ninguna razón por la que no pueda transmitir a través de UDP.
Si es así tienes que tener en cuenta que no hay certeza de que tus datos lleguen por el otro extremo, pero puedo asumir que conoces UDP.
Para responder a su pregunta, No, HTTP NO usa UDP. Sin embargo, para lo que habla, la transmisión de mp3 / video PODRÍA ocurrir a través de UDP y, en mi opinión, nunca debería ocurrir a través de HTTP.
En teoría, sí, es posible usar UDP para http, pero eso podría ser problemático. Digamos, por ejemplo, que en su ejemplo se está transmitiendo un mp3 o un video, habrá un problema de pedido y algunos bits podrían faltar ya que UDP no está orientado a la conexión, no hay ningún mecanismo de retransmisión.
UDP is not connection oriented there is no retransmit mechanism
.
Creo que a algunas de las respuestas les falta un punto importante. La elección entre UDP y TCP no debe basarse en el tipo de datos (por ejemplo, audio o video) o si la aplicación comienza a reproducirlos antes de que se complete la transferencia ("streaming"), sino si es en tiempo real . Los datos en tiempo real son (por definición) sensibles a los retrasos, por lo que a menudo es mejor enviarlos a través de RTP / UDP (Protocolo de tiempo real a través de UDP).
La demora no es un problema con los datos almacenados de un archivo, incluso si se trata de audio y / o video, por lo que probablemente sea mejor enviarlo a través de TCP para que se pueda corregir cualquier pérdida de paquetes. El remitente puede leer con anticipación y mantener la tubería de red llena y el receptor también puede usar mucho almacenamiento en búfer de reproducción para que no sea interrumpido por la retransmisión TCP ocasional o la desaceleración momentánea de la red. El caso límite es cuando se transfiere toda la grabación antes de que comience la reproducción. Esto elimina cualquier riesgo de que la reproducción se atasque, pero a menudo no es práctico.
El problema con TCP para datos en tiempo real no son tanto las retransmisiones como el almacenamiento en búfer excesivo, ya que TCP intenta usar la canalización de la manera más eficiente posible sin tener en cuenta la latencia. UDP conserva los límites de los paquetes de la aplicación y no tiene almacenamiento interno, por lo que no introduce ninguna latencia.
La respuesta: si
Motivo: consulte el modelo OSI.
Explicación:
HTTP es un protocolo de capa de aplicación, que podría encapsularse con un protocolo que usa UDP, proporcionando una comunicación confiable más rápida que TCP. El daemon del servidor y el cliente obviamente necesitarían soportar este nuevo protocolo. El protocolo Quake 2 demuestra que UDP se puede utilizar sobre TCP para proporcionar una base para un sistema de comunicación estructurado que asegure el control de flujo (por ejemplo, ID de fragmentos).
Intente ejecutar HTTP sobre UDP con node-httpp:
http sobre udp es utilizado por algunas implementaciones de rastreadores de torrents (y es compatible con eb por todos los clientes principales)
(Esta es una pregunta antigua, pero merece una respuesta actualizada).
Con toda probabilidad , HTTP / 3 utilizará el protocolo QUIC , que se describe como
transporte multiplexado sobre UDP
Entonces, desde cierto punto de vista , se podría decir que HTTP / 3 usará UDP.
UDP es el mejor protocolo para la transmisión, porque no exige paquetes faltantes como TCP. Y si no hace demandas, el flujo es mucho más rápido y sin búfer.
Incluso el retraso de la transmisión es menor que el de TCP. Esto se debe a que TCP (como protocolo mucho más seguro) exige paquetes faltantes, sobrescribiendo los existentes.
Por lo tanto, TCP es un protocolo demasiado avanzado para usarse en streaming.