HTTP ใช้ UDP หรือไม่

นี่อาจเป็นคำถามโง่ ๆ :

• HTTP เคยใช้ User Datagram Protocol หรือไม่?

ตัวอย่างเช่น:

หากสตรีมมิ่ง MP3 หรือวิดีโอโดยใช้ HTTP จะใช้ UDP ในการขนส่งหรือไม่

โดยปกติแล้วไม่

ไม่ค่อยมีการใช้การสตรีมผ่าน HTTP และ HTTP แทบจะไม่ทำงานผ่าน UDP ดู แต่RTP

สำหรับบางสิ่งตามตัวอย่างของคุณ (ในความคิดเห็น) คุณไม่ได้แสดงโปรโตคอลสำหรับทรัพยากร ถ้าโปรโตคอลนั้นเป็น HTTP ฉันจะไม่เรียกการเข้าถึงว่า "สตรีมมิ่ง" แม้ว่าในบางแง่ของคำก็คือเนื่องจากมันส่งทรัพยากร (อาจมีขนาดใหญ่) แบบอนุกรมผ่านเครือข่าย โดยปกติทรัพยากรจะถูกบันทึกลงในดิสก์ภายในเครื่องก่อนที่จะเล่นดังนั้นการถ่ายโอนเครือข่ายจึงไม่ได้หมายถึง "สตรีมมิง"

ตามที่ผู้แสดงความคิดเห็นได้ชี้ให้เห็นว่าเป็นไปได้อย่างแน่นอนที่จะสตรีมผ่าน HTTP และบางคนก็ทำได้

จากRFC 2616 :

การสื่อสาร HTTP มักเกิดขึ้นผ่านการเชื่อมต่อ TCP / IP พอร์ตเริ่มต้นคือ TCP 80 แต่สามารถใช้พอร์ตอื่นได้ สิ่งนี้ไม่ได้กีดกันไม่ให้นำ HTTP ไปใช้กับโปรโตคอลอื่น ๆ บนอินเทอร์เน็ตหรือบนเครือข่ายอื่น ๆ HTTP ถือว่าเป็นการขนส่งที่เชื่อถือได้เท่านั้น สามารถใช้โปรโตคอลใด ๆ ที่ให้การค้ำประกันดังกล่าวได้ การแมปคำขอ HTTP / 1.1 และโครงสร้างการตอบกลับไปยังหน่วยข้อมูลการขนส่งของโปรโตคอลที่เป็นปัญหาอยู่นอกขอบเขตของข้อกำหนดนี้

ดังนั้นแม้ว่าจะไม่ได้กล่าวอย่างชัดเจน แต่ก็ไม่ได้ใช้ UDP เนื่องจากไม่ใช่ "การขนส่งที่เชื่อถือได้"

แก้ไข - เมื่อเร็ว ๆ นี้โปรโตคอล QUIC (ซึ่งเป็นการขนส่งหลอกหรือโปรโตคอลชั้นเซสชันที่เคร่งครัดกว่า) ใช้ UDP สำหรับการรับส่งข้อมูล HTTP / 2.0 และการรับส่งข้อมูลส่วนใหญ่ของ Google ใช้โปรโตคอลนี้อยู่แล้ว มันกำลังคืบหน้าไปสู่มาตรฐานเป็นHTTP / 3

อาจจะเป็นเรื่องเล็กน้อย แต่ UPnP จะใช้ข้อความที่จัดรูปแบบ HTTP ผ่าน UDP สำหรับการค้นหาอุปกรณ์

ใช่ HTTP เป็นโปรโตคอลแอปพลิเคชันสามารถถ่ายโอนผ่านโปรโตคอลการขนส่ง UDP นี่คือบริการบางส่วนที่ใช้ UDP และโปรโตคอลพื้นฐานสำหรับการถ่ายโอนข้อมูล HTTP และสตรีมไปยังผู้ใช้ปลายทาง:

• วิธีการขนส่ง Jingle Raw UDP ของ XMPP
• หมายเลขสำหรับบริการที่ใช้ UDT - UDP-based Data Transfer Protocol ซึ่งเป็นส่วนเหนือของโปรโตคอล UDP
• โปรโตคอล Transport Layer Security (TLS) ที่ห่อหุ้ม HTTP เช่นเดียวกับ XMPP ที่กล่าวถึงข้างต้นและโปรโตคอลแอปพลิเคชันอื่น ๆ มีการใช้งานที่ใช้ UDP ในเลเยอร์การขนส่ง การใช้งานนี้เรียกว่า Datagram Transport Layer Security (DTLS)
• การแจ้งเตือนแบบพุชใน GNUTella เป็นคำขอ HTTP ที่ส่งผ่านการขนส่ง UDP

บทความนี้มีรายละเอียดเพิ่มเติมเกี่ยวกับการสตรีมผ่าน UDP และ superset ที่เชื่อถือได้ RUDP: Trusted UDP (RUDP): The Next Big Streaming Protocol?

แน่นอนว่าไม่จำเป็นต้องส่งผ่าน TCP ฉันติดตั้ง HTTP บน UDP เพื่อใช้ในอุตสาหกรรมการแพร่ภาพโทรทัศน์ผ่านดาวเทียม

อาจมีการเปลี่ยนแปลงบางอย่างในหัวข้อนี้ด้วย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 และ TCP ควรไม่ต้องขึ้นอยู่กับชนิดของข้อมูล (เช่นเสียงหรือวิดีโอ) หรือว่าโปรแกรมจะเริ่มต้นที่จะเล่นมันก่อนที่จะโอนเป็นที่เรียบร้อยแล้ว ( "สตรีมมิ่ง") แต่ไม่ว่าจะเป็นเวลาจริง ข้อมูลเรียลไทม์ (ตามคำจำกัดความ) ไวต่อความล่าช้าดังนั้นจึงมักส่งผ่าน RTP / UDP ได้ดีที่สุด (โปรโตคอลเรียลไทม์ผ่าน UDP)

ความล่าช้าไม่ใช่ปัญหากับข้อมูลที่จัดเก็บจากไฟล์แม้ว่าจะเป็นเสียงและ / หรือวิดีโอก็ตามดังนั้นจึงควรส่งผ่าน TCP ได้ดีที่สุดเพื่อให้สามารถแก้ไขการสูญเสียแพ็คเก็ตได้ ผู้ส่งสามารถอ่านล่วงหน้าและทำให้เน็ตเวิร์กไพพ์เต็มและผู้รับยังสามารถใช้บัฟเฟอร์การเล่นจำนวนมากได้ดังนั้นจึงไม่ถูกขัดจังหวะจากการส่ง TCP ใหม่เป็นครั้งคราวหรือการชะลอตัวของเครือข่ายชั่วขณะ ข้อ จำกัด คือการถ่ายโอนการบันทึกทั้งหมดก่อนที่จะเริ่มเล่น วิธีนี้ช่วยลดความเสี่ยงของการหยุดเล่น แต่มักจะไม่สามารถใช้งานได้จริง

ปัญหาเกี่ยวกับ TCP สำหรับข้อมูลแบบเรียลไทม์ไม่ใช่การส่งซ้ำมากเท่ากับการบัฟเฟอร์มากเกินไปเนื่องจาก TCP พยายามใช้ไปป์อย่างมีประสิทธิภาพมากที่สุดโดยไม่คำนึงถึงเวลาแฝง UDP รักษาขอบเขตแพ็คเก็ตของแอปพลิเคชันและไม่มีที่เก็บข้อมูลภายในดังนั้นจึงไม่ทำให้เกิดความหน่วงใด ๆ

คำตอบ:ใช่

เหตุผล:ดูโมเดล OSI

คำอธิบาย:

HTTP เป็นโปรโตคอลชั้นแอปพลิเคชันซึ่งสามารถห่อหุ้มด้วยโปรโตคอลที่ใช้ UDP ซึ่งให้การสื่อสารที่เชื่อถือได้เร็วกว่า TCP เซิร์ฟเวอร์ daemon และไคลเอ็นต์จำเป็นต้องสนับสนุนโปรโตคอลใหม่นี้อย่างชัดเจน โปรโตคอล Quake 2 พิสูจน์ว่าสามารถใช้ UDP ผ่าน TCP เพื่อเป็นพื้นฐานสำหรับระบบการสื่อสารที่มีโครงสร้างซึ่งรับประกันการควบคุมการไหล (เช่นรหัสชิ้น)

ลองรัน HTTP ผ่าน UDP ด้วย node-httpp:

https://github.com/InstantWebP2P/node-httpp

http ผ่าน udp ถูกใช้โดยการใช้งานตัวติดตาม torrent บางตัว (และ supporteb โดยลูกค้าหลักทั้งหมด)

(นี่เป็นคำถามเก่า แต่สมควรได้รับคำตอบที่อัปเดตแล้ว)

ในความเป็นไปได้ทั้งหมด HTTP / 3 จะใช้โปรโตคอล QUICซึ่งอธิบายไว้ว่า

การขนส่งแบบมัลติเพล็กซ์ผ่าน UDP

ดังนั้นจากมุมมองหนึ่งคุณสามารถพูดได้ว่า HTTP / 3 จะใช้ UDP

UDP เป็นโปรโตคอลที่ดีที่สุดสำหรับการสตรีมเนื่องจากไม่ต้องการแพ็กเกจที่ขาดหายไปเช่น TCP และหากไม่ตอบสนองความต้องการโฟลว์ก็เร็วขึ้นมากและไม่มีการบัฟเฟอร์ใด ๆ

แม้ความล่าช้าของสตรีมจะน้อยกว่า TCP นั่นเป็นเพราะ TCP (เป็นโปรโตคอลที่ปลอดภัยกว่ามาก) ทำให้ต้องการแพ็กเกจที่หายไปโดยเขียนทับแพ็กเกจที่มีอยู่

ดังนั้น TCP จึงเป็นโปรโตคอลขั้นสูงเกินกว่าที่จะใช้สำหรับการสตรีม