¿Qué quieres decir con "la web"? ¿Te refieres a usar un navegador? ¿O a través de Internet público?
benc
Lo que quise preguntar es decir que hay un mp3 alojado en una URL, algo así como someserver / somemusic.mp3 . Si esto se transmite a cualquier cliente (navegador, dispositivo, etc.), ¿cómo lo transfiere http? Si entiendo correctamente las respuestas a continuación, esto se delega a RTP.
Sesión
El puerto 80 UDP también está reservado para HTTP, lo que me parece divertido ya que nunca lo he visto usar, ni imagino un buen uso para él.
Joshua
1
Está reservado porque el comité de la IANA tiene una imaginación más flexible que tú. ;-) Ellos imaginan que podría haber un buen uso para él. Además, no reservar el puerto 80 para UDP / HTTP lo dejaría abierto para algún otro protocolo UDP, lo que solo causaría confusión cuando se habla del puerto 80.
Jesse Chisholm
Respuestas:
42
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.
@ snowcrash09 Ni siquiera puedo eliminarlo yo mismo, ya que está aceptado. Eso es raro. Lo reescribí, espero que ahora sea menos ofensivo.
relajarse
1
Simplemente ser pedante con HTTP y la transmisión, allá por la era oscura del video QuickTime, existía 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.
Jesse Chisholm
3
@nos Youtube no está transmitiendo. El navegador descarga un archivo en un caché y comienza a reproducirse desde el archivo antes de que se descargue por completo. Aunque esto simula la transmisión, no lo es.
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 .
Para ser más específicos, la parte de UPnP que usa mensajes UDP y similares a HTTP se llama SSDP (Protocolo simple de descubrimiento de servicios). La estructura del mensaje es la misma, pero el METHODconjunto es diferente. Después de eso, UPnP usa otros protocolos (y generalmente TCP) para el resto de lo que hace.
Jesse Chisholm
20
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:
Método de transporte Jingle Raw UDP de XMPP
Un número para servicios que utilizan UDT --- Protocolo de transferencia de datos basado en UDP, que es un superconjunto del protocolo UDP.
El protocolo Transport Layer Security (TLS) que encapsula HTTP, así como el XMPP mencionado anteriormente y otros protocolos de aplicación, tiene una implementación que usa UDP en su capa de transporte; esta implementación se llama Datagram Transport Layer Security (DTLS).
Las notificaciones push en GNUTella son solicitudes HTTP enviadas a través del transporte UDP.
Otra pregunta: ¿los principales navegadores web admiten páginas web HTTP sobre UDP?
user2284570
sí, porque HTTP está en la capa de aplicación y UDP en la capa de transporte. los navegadores no escriben paquetes TCP o UDP. Tampoco escriben paquetes IP. Estos son manejados por el sistema operativo y los controladores. La capa de Ethernet es tan baja que puede estar en un chip cerca del MAC en este punto.
Yan Bellavance
@yanbellavance eso es completamente incorrecto. Mientras que los navegadores y servidores web de hecho no generan primas tramas TCP (UDP ni los para el caso) que no tienen que seleccionar el transporte de usar, y para HTTP normal que siempre es TCP. Sin embargo, el pseudoprotocolo QUIC más nuevo utiliza UDP.
Alnitak
18
Por supuesto, no es necesario que se transmita a través de TCP. Implementé HTTP sobre UDP, para su uso en la industria de transmisión de televisión por satélite.
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.
La "transmisión" a través de HTTP se denomina comúnmente (lo que considero con mayor precisión) "pseudo transmisión", una velocidad de bits regulada de datos a través de HTTP. Como ocurre con muchas otras cosas en nuestro mundo, los tipos de marketing han abusado de la nomenclatura dejando a las personas orientadas a los detalles como nosotros aferrándose a los detalles.
Stu Thompson
4
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.
Bueno mencionó: UDP is not connection oriented there is no retransmit mechanism.
ivanleoncz
4
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.
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).
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.
esto no responde a la pregunta, sin embargo, podría ser un razonamiento para una respuesta.
Hawken
2
re: "el mejor protocolo para la transmisión" dado que "la velocidad de los fragmentos de datos individuales" es más importante que "todos los datos que pasan". Si su transmisión no puede recuperarse fácilmente de los fragmentos faltantes, será mejor que utilice TCP. Muchos protocolos de video de seguridad eligen TCP por esa razón: la confiabilidad es más importante que la velocidad bruta.
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.
fuente
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 :
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 .
fuente
Quizás solo un poco de trivia, pero UPnP usará mensajes con formato HTTP sobre UDP para el descubrimiento de dispositivos.
fuente
METHODconjunto 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?
fuente
Por supuesto, no es necesario que se transmita a través de TCP. Implementé HTTP sobre UDP, para su uso en la industria de transmisión de televisión por satélite.
fuente
Quizás algún cambio en este tema con QUIC
fuente
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.
fuente
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.
fuente
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.
fuente
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).
fuente
Intente ejecutar HTTP sobre UDP con node-httpp:
https://github.com/InstantWebP2P/node-httpp
fuente
http sobre udp es utilizado por algunas implementaciones de rastreadores de torrents (y es compatible con eb por todos los clientes principales)
fuente
(Esta es una pregunta antigua, pero merece una respuesta actualizada).
Con toda probabilidad , HTTP / 3 utilizará el protocolo QUIC , que se describe como
Entonces, desde cierto punto de vista , se podría decir que HTTP / 3 usará UDP.
fuente
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.
fuente