Esta pode ser uma pergunta boba:
- O HTTP usa o protocolo de datagrama do usuário?
Por exemplo:
Se alguém estiver transmitindo MP3 ou vídeo usando HTTP, ele usa UDP internamente para transporte?
Esta pode ser uma pergunta boba:
Por exemplo:
Se alguém estiver transmitindo MP3 ou vídeo usando HTTP, ele usa UDP internamente para transporte?
Respostas:
Normalmente, não.
O streaming raramente é usado no próprio HTTP, e o HTTP raramente é executado no UDP. Veja, no entanto, RTP .
Para algo como seu exemplo (no comentário), você não está mostrando um protocolo para o recurso. Se esse protocolo fosse HTTP, eu não chamaria o acesso de "streaming"; mesmo que em algum sentido da palavra seja, já que está enviando um recurso (possivelmente grande) em série pela rede. Normalmente, o recurso é salvo no disco local antes de ser reproduzido, portanto, a transferência de rede não é o que normalmente se entende por "streaming".
Como os comentaristas apontaram, no entanto, certamente é possível realmente transmitir via HTTP, e isso é feito por alguns.
server push
, onde a conexão HTTP envia MJPEG (imagens JPEG múltiplas) cada um como uma parte separada de uma resposta MIME multiparte para a solicitação HTTP. Cada imagem JPEG chega e substitui a anterior no visor. Mas você está correto @unwind, isso raramente é feito hoje, já que o RTP / RTSP funciona melhor.
De RFC 2616 :
A comunicação HTTP geralmente ocorre por meio de conexões TCP / IP. A porta padrão é TCP 80, mas outras portas podem ser usadas. Isso não impede que o HTTP seja implementado em cima de qualquer outro protocolo na Internet ou em outras redes. HTTP pressupõe apenas um transporte confiável; qualquer protocolo que forneça tais garantias pode ser usado; o mapeamento das estruturas de solicitação e resposta HTTP / 1.1 nas unidades de dados de transporte do protocolo em questão está fora do escopo desta especificação.
Portanto, embora não diga isso explicitamente, o UDP não é usado porque não é um "transporte confiável".
EDIT - mais recentemente, o protocolo QUIC (que é mais estritamente um pseudo-transporte ou um protocolo de camada de sessão) usa UDP para transportar tráfego HTTP / 2.0 e grande parte do tráfego do Google já usa esse protocolo. Atualmente está progredindo em direção à padronização como HTTP / 3 .
Talvez seja apenas um pouco de trivialidade, mas o UPnP usará mensagens formatadas em HTTP sobre UDP para descoberta de dispositivos.
METHOD
conjunto é diferente. Depois disso, UPnP usa outros protocolos (e geralmente TCP) para o resto do que faz.
Sim, o HTTP, como um protocolo de aplicativo, pode ser transferido pelo protocolo de transporte UDP. Aqui estão alguns dos serviços que usam UDP e um protocolo subjacente para transferir dados HTTP e fazer streaming para o usuário final:
Este artigo contém mais detalhes sobre streaming sobre UDP e seu superconjunto confiável, o RUDP: UDP confiável (RUDP): o próximo grande protocolo de streaming?
Talvez alguma mudança neste tópico com o QUIC
QUIC (Quick UDP Internet Connections, pronuncia-se rápido) é um protocolo de rede de camada de transporte experimental desenvolvido pelo Google e implementado em 2013. O QUIC oferece suporte a um conjunto de conexões multiplexadas entre dois endpoints por meio do User Datagram Protocol (UDP) e foi projetado para fornecer proteção de segurança equivalente a TLS / SSL, junto com conexão reduzida e latência de transporte e estimativa de largura de banda em cada direção para evitar congestionamento. O objetivo principal do QUIC é otimizar aplicativos da web orientados a conexão que usam TCP atualmente.
Se você estiver transmitindo um mp3 ou vídeo que pode não ser necessariamente por HTTP, na verdade eu ficaria surpreso se fosse. Provavelmente seria outro protocolo sobre TCP, mas não vejo razão para que você não possa transmitir sobre UDP.
Se for você tem que levar em conta que não há certeza de que seus dados chegarão na outra ponta, mas posso supor que você conhece o UDP.
Para responder à sua pergunta, não, o HTTP NÃO usa UDP. No entanto, pelo que você falou, o streaming de mp3 / vídeo PODERIA acontecer por UDP e, na minha opinião, nunca deveria acontecer por HTTP.
Em teoria, sim, é possível usar UDP para http, mas isso pode ser problemático. Digamos, por exemplo, que em seu exemplo um mp3 ou um vídeo esteja sendo transmitido, haverá um problema de pedido e alguns bits podem ser perdidos, pois o UDP não é orientado para conexão e não há mecanismo de retransmissão.
UDP is not connection oriented there is no retransmit mechanism
.
Acho que algumas das respostas estão perdendo um ponto importante. A escolha entre UDP e TCP não deve ser baseada no tipo de dados (por exemplo, áudio ou vídeo) ou se o aplicativo começa a reproduzi-los antes que a transferência seja concluída ("streaming"), mas sim se é em tempo real . Os dados em tempo real são (por definição) sensíveis a atrasos, portanto, geralmente são mais bem enviados por RTP / UDP (Real Time Protocol over UDP).
O atraso não é um problema com os dados armazenados de um arquivo, mesmo se for áudio e / ou vídeo, portanto, provavelmente é melhor enviar por TCP para que quaisquer perdas de pacote possam ser corrigidas. O remetente pode ler adiante e manter o canal de rede cheio e o receptor também pode usar muitos buffer de playout para que não seja interrompido pela retransmissão TCP ocasional ou desaceleração momentânea da rede. O caso limite é quando toda a gravação é transferida antes do início da reprodução. Isso elimina qualquer risco de travamento da reprodução, mas geralmente não é prático.
O problema com o TCP para dados em tempo real não é a retransmissão, mas sim o buffer excessivo, pois o TCP tenta usar o pipe da maneira mais eficiente possível, sem levar em conta a latência. O UDP preserva os limites do pacote de aplicativos e não tem armazenamento interno, portanto, não introduz latência.
A resposta: sim
Motivo: Veja o modelo OSI.
Explicação:
HTTP é um protocolo de camada de aplicativo, que pode ser encapsulado com um protocolo que usa UDP, fornecendo uma comunicação confiável mais rápida do que o TCP. O daemon do servidor e o cliente obviamente precisariam oferecer suporte a esse novo protocolo. O protocolo Quake 2 prova que o UDP pode ser usado sobre o TCP para fornecer uma base para um sistema de comunicação estruturado garantindo o controle de fluxo (por exemplo, ids de chunk).
Tente executar HTTP sobre UDP com node-httpp:
http sobre udp é usado por algumas implementações de torrent tracker (e suportado por todos os clientes principais)
(Esta é uma pergunta antiga, mas merece uma resposta atualizada.)
Muito provavelmente , HTTP / 3 estará usando o protocolo QUIC , que é descrito como
transporte multiplexado sobre UDP
Então, de um certo ponto de vista , você poderia dizer que HTTP / 3 estará usando UDP.
UDP é o melhor protocolo para streaming, porque não exige pacotes ausentes como TCP. E se não fizer demandas, o fluxo é muito mais rápido e sem buffer.
Mesmo o atraso do fluxo é menor que o TCP. Isso ocorre porque o TCP (como um protocolo muito mais seguro) exige pacotes ausentes, sobrescrevendo os existentes.
Portanto, o TCP é um protocolo muito avançado para ser usado para streaming.