HTTP는 UDP를 사용합니까?


103

이것은 어리석은 질문 일 수 있습니다.

  • HTTP는 사용자 데이터 그램 프로토콜을 사용합니까?

예를 들면 :

HTTP를 사용하여 MP3 또는 비디오를 스트리밍하는 경우 내부적으로 전송에 UDP를 사용합니까?


"웹"이란 무엇을 의미합니까? 브라우저 사용을 의미합니까? 아니면 공용 인터넷을 통해?
benc

내가 묻고 자하는 것은 someserver / somemusic.mp3 와 같은 URL에서 호스팅되는 mp3가 있다는 것 입니다. 이것이 모든 클라이언트 (브라우저, 장치 등)로 스트리밍되는 경우 http는이를 어떻게 전송합니까? 아래 답변을 올바르게 이해하면 RTP에 위임됩니다.
Sesh

포트 80 UDP는 HTTP 용으로도 예약되어 있습니다. HTTP를 사용하는 것을 본 적도없고 좋은 용도라고 생각할 수도 없기 때문에 재미 있습니다.
Joshua

1
IANA위원회는 당신이하는 더 유연한 상상력을 가지고 있기 때문에 예약되어 있습니다. ;-) 그들은 그것을 위해 좋은 사용이있을 수 있다고 상상합니다. 게다가, UDP에 대한하지 예비 포트 80 / HTTP는 그냥 혼란의 원인 포트 80에 대해 이야기 할 다른 UDP 프로토콜에 대한 열 떠날 것이다
제시 치솜

답변:


42

일반적으로 아닙니다.

스트리밍은 HTTP 자체에서 거의 사용되지 않으며 HTTP는 UDP에서 거의 실행되지 않습니다. 그러나 RTP를 참조하십시오 .

예를 들어 (주석에서) 리소스에 대한 프로토콜을 표시하지 않습니다. 그 프로토콜이 HTTP라면 액세스를 "스트리밍"이라고 부르지 않을 것입니다. 어떤 의미에서 네트워크를 통해 (아마도 큰) 리소스를 직렬로 전송하기 때문 일지라도. 일반적으로 리소스는 재생되기 전에 로컬 디스크에 저장되므로 네트워크 전송은 일반적으로 "스트리밍"을 의미하는 것이 아닙니다.

댓글 작성자가 지적했듯이 실제로 HTTP를 통해 스트리밍 할 수 있으며 일부는이를 수행합니다.


16
분명히 잘못된 것은 HTTP에 스트리밍을 방해하는 것은 없습니다. 전용 프로토콜만큼 효율적이지 않습니다. 청크를 사용하여 HTTP Dyanmic 스트리밍 : adobe.com/products/httpdynamicstreaming HTTP 의사 스트리밍 : longtailvideo.com/support/jw-player/jw-player-for-flash-v5/...
스티브 - 오

14
YouTube는 http를 통해 스트리밍합니다.
nos

6
@ snowcrash09 수락되었으므로 직접 삭제할 수도 없습니다. 이상 하네. 나는 그것을 다시 썼다. 나는 그것이 지금 덜 불쾌감을 주길 바란다.
언 와인드

1
퀵타임 비디오의 암흑 시대로 거슬러 올라가는 HTTP 및 스트리밍에 대해 현명한 방식으로 server push, HTTP 연결이 HTTP 요청에 대한 MIME 멀티 파트 응답의 개별 부분으로 각각 MJPEG (다중 JPEG 이미지)를 보내는 경우가있었습니다. 각 JPEG 이미지가 도착하여 디스플레이의 이전 이미지를 대체합니다. 그러나 당신은 @unwind가 정확합니다. RTP / RTSP가 더 잘 작동하기 때문에 이것은 오늘날 거의 수행되지 않습니다.
Jesse Chisholm

3
@nos Youtube가 스트리밍되지 않습니다. 브라우저는 파일을 캐시에 다운로드하고 완전히 다운로드되기 전에 파일에서 재생을 시작합니다. 이것은 스트리밍을 시뮬레이션하지만 그렇지 않습니다.
SimonStiph

113

에서 RFC 2616 :

HTTP 통신은 일반적으로 TCP / IP 연결을 통해 이루어집니다. 기본 포트는 TCP 80이지만 다른 포트를 사용할 수 있습니다. 이것은 인터넷이나 다른 네트워크에서 HTTP가 다른 프로토콜 위에 구현되는 것을 배제하지 않습니다. HTTP는 신뢰할 수있는 전송만을 가정합니다. 이러한 보증을 제공하는 모든 프로토콜을 사용할 수 있습니다. HTTP / 1.1 요청 및 응답 구조를 해당 프로토콜의 전송 데이터 단위에 매핑하는 것은이 사양의 범위를 벗어납니다.

따라서 명시 적으로 명시하지는 않지만 UDP는 "신뢰할 수있는 전송"이 아니기 때문에 사용되지 않습니다.

편집하다 -최근에는 QUIC 프로토콜 (보다 엄격하게 의사 전송 또는 세션 계층 프로토콜)은 HTTP / 2.0 트래픽을 전송하는 데 UDP를 사용하며 Google 트래픽의 대부분은 이미이 프로토콜을 사용합니다. 현재 HTTP / 3 로 표준화를 진행하고 있습니다 .


TCP가 아닌 연결을 허용하도록 구성 할 수있는 웹 서버가 있습니까?
Spidey

1
여기 pel.cis.udel.edu 에서 TCP 대신 SCTP 프로토콜을 사용 하도록 아파치가 수정되었습니다 .
nos

@nos Yup, Google에도 SPDY가 있습니다. 하지만 둘 다 신뢰할 수있는 전송 메커니즘입니다.
Alnitak 2011 년

5
@Alnitak SPDY는 전송 계층 프로토콜이 아닌 애플리케이션 계층 프로토콜입니다.
Walking Wiki

@WalkingWiki 당신은 물론 맞습니다-그 맥락에서 SPDY는 TCP가 아닌 HTTP를 대체합니다.
알니 타크

36

약간의 퀴즈 일 수도 있지만 UPnP는 장치 검색을 위해 UDP를 통해 HTTP 형식 메시지를 사용합니다.


4
보다 구체적으로 UDP 및 HTTP와 유사한 메시지를 사용하는 UPnP 부분을 SSDP (Simple Service Discovery Protocol)라고합니다. 메시지 구조는 동일하지만 METHOD세트가 다릅니다. 그 후 UPnP는 나머지 작업을 위해 다른 프로토콜 (일반적으로 TCP)을 사용합니다.
Jesse Chisholm

20

예, 애플리케이션 프로토콜 인 HTTP는 UDP 전송 프로토콜을 통해 전송할 수 있습니다. 다음은 HTTP 데이터를 전송하고 최종 사용자에게 스트리밍하기 위해 UDP 및 기본 프로토콜을 사용하는 몇 가지 서비스입니다.

  • XMPP의 Jingle Raw UDP 전송 방법
  • UDT를 사용하는 서비스의 번호 --- UDP 프로토콜의 상위 집합 인 UDP 기반 데이터 전송 프로토콜입니다.
  • HTTP를 캡슐화하는 TLS (Transport Layer Security) 프로토콜과 위에서 언급 한 XMPP 및 기타 응용 프로그램 프로토콜에는 전송 계층에서 UDP를 사용하는 구현이 있습니다. 이 구현을 DTLS (Datagram Transport Layer Security)라고합니다.
  • GNUTella의 푸시 알림은 UDP 전송을 통해 전송되는 HTTP 요청입니다.

이 기사에는 UDP를 통한 스트리밍과 신뢰할 수있는 상위 집합 인 RUDP : RUDP (Reliable UDP) : 차세대 빅 스트리밍 프로토콜?


1
또 다른 질문 : 주요 웹 브라우저가 UDP를 통한 웹 페이지 HTTP를 지원합니까?
user2284570 2015 년

예, HTTP는 애플리케이션 계층에 있고 UDP는 전송 계층에 있기 때문입니다. 브라우저는 TCP 또는 UDP 패킷을 작성하지 않습니다. 또한 IP 패킷을 작성하지도 않습니다. 그것들은 OS와 드라이버에 의해 처리됩니다. 이더넷 계층이 너무 낮아서이 시점에서 MAC에 가까운 칩에있을 수 있습니다.
yan bellavance

@yanbellavance는 완전히 틀 렸습니다. 브라우저와 웹 서버가 실제로 발생하지 않지만 원시 (그 문제에 대한 나 UDP 것들) TCP 프레임을 그들은 않는 사용에 전송을 선택해야하고, 일반 HTTP에 대한 TCP 항상 그. 그러나 최신 QUIC 의사 프로토콜은 UDP를 사용합니다.
Alnitak

18

물론 반드시 TCP를 통해 전송 될 필요는 없습니다. 저는 위성 TV 방송 산업에서 사용하기 위해 UDP 위에 HTTP를 구현했습니다.


6

QUIC 로이 주제에 대한 약간의 변경

QUIC (Quick UDP Internet Connections, quick 발음)는 Google에서 개발하고 2013 년에 구현 한 실험적인 전송 계층 네트워크 프로토콜입니다. QUIC는 UDP (User Datagram Protocol)를 통해 두 엔드 포인트 간의 다중 연결 집합을 지원하며 보안 보호를 제공하도록 설계되었습니다. TLS / SSL과 동일하며 연결 ​​및 전송 대기 시간 감소, 혼잡을 방지하기위한 각 방향의 대역폭 추정. QUIC의 주요 목표는 현재 TCP를 사용하는 연결 지향 웹 애플리케이션을 최적화하는 것입니다.


4

HTTP를 통하지 않을 수도있는 mp3 또는 비디오를 스트리밍하는 경우 실제로 그랬다면 놀라 울 것입니다. 아마도 TCP를 통한 또 다른 프로토콜 일 수 있지만 UDP를 통해 스트리밍 할 수없는 이유가 없습니다.

데이터가 다른 쪽 끝에 도착할 것이라는 확신이 없다는 점을 고려해야하지만 UDP에 대해 알고있는 것으로 받아 들일 수 있습니다.

아니오, HTTP는 UDP를 사용하지 않습니다. 그러나 당신이 말하는 것에 대해, mp3 / 비디오 스트리밍은 UDP를 통해 발생할 수 있으며 제 생각에는 HTTP를 통해 발생해서는 안됩니다.


1
HTTP를 통한 "스트리밍"은 일반적으로 (내가 가장 정확하게 생각하는) "의사 스트리밍"(HTTP를 통해 규제 된 데이터 비트 전송률)이라고합니다. 우리 세계에서와 마찬가지로 마케팅 유형은 명명법을 남용하여 우리와 같은 세부 사항 지향적 인 사람들이 세부 사항을 파악합니다.
Stu Thompson

4

이론 상으로는 http에 UDP를 사용할 수 있지만 문제가 될 수 있습니다. 예를 들어 귀하의 예에서 mp3 또는 비디오가 스트리밍되고 있으며 주문 문제가 있으며 UDP가 연결 지향적이지 않기 때문에 일부 비트가 누락 될 수 있으며 재전송 메커니즘이 없습니다.


1
잘 언급 : UDP is not connection oriented there is no retransmit mechanism.
ivanleoncz

4

일부 답변에 중요한 점이 누락 된 것 같습니다. UDP와 TCP 사이의 선택 은 데이터 유형 (예 : 오디오 또는 비디오) 또는 전송이 완료되기 전에 애플리케이션이 재생을 시작하는지 ( "스트리밍") 여부를 기반으로 해서는 안되며 실시간 인지 여부를 기반으로해야 합니다. 실시간 데이터는 (정의상) 지연에 민감하므로 종종 RTP / UDP (Real Time Protocol over UDP)를 통해 전송하는 것이 가장 좋습니다.

지연은 오디오 및 / 또는 비디오라도 파일에서 저장된 데이터에 문제가되지 않으므로 패킷 손실을 수정할 수 있도록 TCP를 통해 전송하는 것이 가장 좋습니다. 송신자는 미리 읽을 수 있고 네트워크 파이프를 가득 채울 수 있으며 수신자는 많은 재생 버퍼링을 사용할 수 있으므로 가끔 TCP 재전송이나 일시적인 네트워크 속도 저하로 인해 중단되지 않습니다. 제한적인 경우는 재생이 시작되기 전에 전체 녹음이 전송되는 경우입니다. 이것은 재생 지연의 위험을 제거하지만 종종 비실용적입니다.

실시간 데이터에 대한 TCP의 문제는 TCP가 지연 시간에 관계없이 가능한 한 효율적으로 파이프를 사용하려고 시도하는 것만 큼 과도한 버퍼링만큼 재전송이 아닙니다. UDP는 애플리케이션 패킷 경계를 유지하고 내부 저장소가 없으므로 대기 시간이 발생하지 않습니다.


3

대답 :

이유 : OSI 모델을 참조하십시오.

설명 :

HTTP는 UDP를 사용하는 프로토콜로 캡슐화 될 수있는 애플리케이션 계층 프로토콜로, TCP보다 더 빠르고 안정적인 통신을 제공합니다. 서버 데몬과 클라이언트는 분명히이 새로운 프로토콜을 지원해야합니다. Quake 2 프로토콜은 UDP가 TCP를 통해 흐름 제어를 보장하는 구조적 통신 시스템 (예 : 청크 ID)의 기반을 제공 할 수 있음을 증명합니다.


1
해당 수준에서 필요한 것보다 더 많은 정보 없이는 TCP를 손으로 이길 수 없습니다.
Joshua

1
"UDP는 TCP를 통해 사용할 수 있습니다". 둘 다 전송 계층 프로토콜이므로 둘 중 하나입니다.
opyate




1

UDP는 TCP와 같은 누락 된 패키지를 요구하지 않기 때문에 스트리밍에 가장 적합한 프로토콜입니다. 그리고 그것이 요구하지 않는다면, 흐름은 버퍼링없이 훨씬 더 빨라집니다.

스트림 지연조차도 TCP보다 적습니다. 이는 TCP (훨씬 더 안전한 프로토콜)가 누락 된 패키지를 요구하여 기존 패키지를 덮어 쓰기 때문입니다.

따라서 TCP는 스트리밍에 사용하기에는 너무 발전된 프로토콜입니다.


3
이것은 질문에 대한 대답은 아니지만 대답을위한 추론 일 수 있습니다.
Hawken

2
re : "개별 데이터 청크의 속도"를 고려할 때 "스트리밍을위한 최상의 프로토콜"은 "모든 데이터가 통과하는 것"보다 더 중요합니다. 스트림이 누락 된 청크에서 쉽게 복구 할 수 없다면 TCP를 사용하는 것이 좋습니다. 많은 보안 비디오 프로토콜이 이러한 이유로 TCP를 선택합니다. 즉, 원시 속도보다 안정성이 더 중요합니다.
Jesse Chisholm
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.