Це може бути дурним питанням:
- Чи HTTP коли-небудь використовує протокол User Datagram?
Наприклад:
Якщо хтось передає MP3 або відео за допомогою HTTP, чи використовує він внутрішньо UDP для транспорту?
Це може бути дурним питанням:
Наприклад:
Якщо хтось передає MP3 або відео за допомогою HTTP, чи використовує він внутрішньо UDP для транспорту?
Відповіді:
Як правило, ні.
Потокова передача рідко використовується через сам HTTP, а HTTP рідко працює над UDP. Дивіться, однак, RTP .
Щось як ваш приклад (у коментарі), ви не показуєте протокол для ресурсу. Якби цей протокол був HTTP, я б не називав доступ "потоковим"; навіть якщо це в якомусь сенсі цього слова, оскільки він посилає (можливо, великий) ресурс серійно по мережі. Зазвичай ресурс буде зберігатися на локальному диску перед відтворенням, тому мережева передача - це не те, що зазвичай означає "потокове передавання".
Як зазначають коментатори, проте, звичайно, можна реально протікати по HTTP, і це роблять деякі.
server push
, де HTTP-з'єднання надсилає MJPEG (кілька зображень JPEG) кожен як окрему частину MIME багаточастинної відповіді на HTTP-запит. Кожне зображення JPEG надходить та замінює попереднє на дисплеї. Але ви праві @unwind, сьогодні це рідко робиться, оскільки RTP / RTSP працює краще.
Від RFC 2616 :
Зв'язок HTTP зазвичай відбувається через TCP / IP-з'єднання. Типовим портом є TCP 80, але можна використовувати інші порти. Це не перешкоджає впровадженню HTTP поверх будь-якого іншого протоколу в Інтернеті чи інших мережах. HTTP передбачає лише надійний транспорт; будь-який протокол, що забезпечує такі гарантії, може бути використаний; відображення структури запиту та відповіді HTTP / 1.1 на одиниці транспортних даних відповідного протоколу виходить за межі цієї специфікації.
Тож, хоча це прямо не сказано, UDP не використовується, оскільки це не "надійний транспорт".
EDIT - останнім часом протокол QUIC (що більш суворо є псевдоперевезенням або протоколом сеансового рівня) використовує UDP для перенесення HTTP / 2.0 трафіку, і значна частина трафіку Google вже використовує цей протокол. В даний час прогресує до стандартизації як HTTP / 3 .
Можливо, трохи дрібниць, але UPnP використовуватиме форматування HTTP-повідомлень через UDP для виявлення пристроїв.
METHOD
набір різна. Після цього UPnP використовує інші протоколи (і зазвичай TCP) для решти того, що робить.
Так, HTTP, як протокол програми, може передаватися через транспортний протокол UDP. Ось деякі сервіси, які використовують UDP та базовий протокол для передачі даних HTTP та передачі їх кінцевому користувачеві:
Ця стаття містить більш детальну інформацію про потокове передавання через UDP та його надійний суперсет, RUDP: Надійний UDP (RUDP): Наступний великий протокол потокового передачі?
Можливо, якась зміна на цю тему з QUIC
QUIC (Quick UDP Internet Connections, вимовляється швидкий) - це експериментальний мережевий протокол експериментального рівня, розроблений Google та впроваджений у 2013 році. QUIC підтримує набір мультиплексованих з'єднань між двома кінцевими точками через User Datagram Protocol (UDP) і був розроблений для забезпечення захисту безпеки еквівалент TLS / SSL, поряд із зменшеною затримкою з'єднання та транспорту та оцінкою пропускної здатності в кожному напрямку, щоб уникнути перевантажень. Основна мета QUIC - оптимізувати веб-додатки, орієнтовані на з'єднання, які зараз використовують TCP.
Якщо ви передаєте mp3 або відео, які не обов'язково перебувають через HTTP, насправді я здивувався б, якби це було. Можливо, це буде ще один протокол через TCP, але я не бачу жодної причини, через яку ви не можете передавати протокол через UDP.
Якщо ви повинні взяти до уваги, що немає впевненості, що ваші дані надійдуть на інший кінець, але я можу вважати, що ви знаєте про UDP.
Щоб відповісти на ваше запитання, Ні, HTTP НЕ використовує UDP. Щодо того, про що ви говорите, хоча, потокове передавання mp3 / відео МОЖЕ відбуватися через UDP, і, на мою думку, ніколи не повинно відбуватися через HTTP.
Теоретично так, можна використовувати UDP для http, але це може бути проблематично. Скажімо, наприклад, у своєму прикладі передається mp3 або відео, виникне проблема замовлення, і деякі біти можуть пропасти, оскільки UDP не орієнтований на з'єднання, немає механізму повторної передачі.
UDP is not connection oriented there is no retransmit mechanism
.
Я думаю, що в деяких відповідях пропускається важливий момент. Вибір між UDP та TCP не повинен базуватися на типі даних (наприклад, аудіо чи відео) або на тому, чи програма починає відтворювати їх до завершення передачі ("потокове передавання"), а чи в реальному часі . Дані в режимі реального часу залежать від затримки (за визначенням), тому їх часто найкраще надсилати через RTP / UDP (протокол реального часу через UDP).
Затримка не є проблемою із збереженими даними з файлу, навіть якщо це аудіо та / або відео, тому, ймовірно, найкраще надсилатись через TCP, щоб будь-які втрати пакетів могли бути виправлені. Відправник може читати заздалегідь і підтримувати мережеву трубку повною, а приймач також може використовувати багато буферизації відтворення, щоб її не перервало випадкова повторна передача TCP або миттєве сповільнення мережі. Обмежувальний випадок, коли весь запис передається перед початком відтворення. Це виключає будь-який ризик зупинки відтворення, але часто недоцільно.
Проблема з TCP для даних у режимі реального часу - це не повторна передача, а надмірна буферизація, оскільки TCP намагається використовувати трубу максимально ефективно, без урахування затримок. UDP зберігає межі пакетів додатків і не має внутрішнього сховища, тому не вносить ніяких затримок.
Відповідь: Так
Причина: Дивіться модель OSI.
Пояснення:
HTTP - це протокол рівня додатків, який може бути інкапсульований протоколом, що використовує UDP, забезпечуючи, мабуть, швидший надійний зв’язок, ніж TCP. Демон сервера та клієнт, очевидно, повинні підтримувати цей новий протокол. Протокол Quake 2 доводить, що UDP може використовуватися через TCP, щоб забезпечити основу для структурованої системи зв'язку, яка забезпечує управління потоком (наприклад, ідентифікатори блоку).
Спробуйте запустити HTTP через UDP за допомогою node-httpp:
http over udp використовується деякими реалізаціями торрент-трекера (і підтримкою всіх основних клієнтів)
(Це старе питання, але воно заслуговує на оновлену відповідь.)
Цілком ймовірно , HTTP / 3 буде використовувати протокол Quic , який описаний , як
мультиплексований транспорт через UDP
Отже, з певної точки зору , ви можете сказати, що HTTP / 3 буде використовувати UDP.
UDP - найкращий протокол для потокового передачі, оскільки він не вимагає відсутніх пакетів, таких як TCP. І якщо це не вимагає, потік набагато швидший і без буферизації.
Навіть затримка потоку менше, ніж TCP. Це тому, що TCP (як набагато більш безпечний протокол) висуває вимоги до відсутніх пакетів, замінюючи існуючі.
Таким чином, TCP - протокол надто розширений, щоб використовувати його для потокового передачі.