HTTP/3 คืออะไร – Lowdown บนโปรโตคอลที่ใช้ UDP ใหม่อย่างรวดเร็ว

TL;DR

ในเดือนพฤศจิกายน พ.ศ. 2561 คณะทำงานด้านวิศวกรรมอินเทอร์เน็ต (IETF) ได้พบกันที่กรุงเทพฯ และได้มีการนำร่างอินเทอร์เน็ตฉบับใหม่มาใช้ โปรโตคอลการขนส่ง QUIC ซึ่งเป็นตัวต่อจาก HTTP/2 ถูกเปลี่ยนชื่อเป็น HTTP/3

HTTP/3 สร้างขึ้นบน User Datagram Protocol (UDP) และถูกใช้โดยบริษัทอินเทอร์เน็ตที่มีชื่อเสียงเช่น Google และ Facebook แล้ว หากคุณกำลังใช้ Chrome และเชื่อมต่อกับบริการของ Google แสดงว่าคุณกำลังใช้ QUIC อยู่แล้ว

เวอร์ชันใหม่ของโปรโตคอล HTTP ได้ประโยชน์จากโปรโตคอล UDP ระดับต่ำแบบ Bare-Metal และกำหนดคุณลักษณะใหม่จำนวนมากที่อยู่ใน HTTP เวอร์ชันก่อนหน้าที่เลเยอร์ TCP นี่เป็นวิธีแก้ไขข้อจำกัดภายในโครงสร้างพื้นฐานอินเทอร์เน็ตที่มีอยู่

ผลลัพธ์แรกมีแนวโน้มดี และเมื่อ Internet Draft โดย IETF หมดอายุ ในเดือนสิงหาคม 2021 เราสามารถคาดหวังให้ HTTP/3 ได้รับการส่งเสริมเป็นมาตรฐาน HTTP รุ่นที่สามใหม่

ความคืบหน้า HTTP/3 ในปี 2022

บางคนบอกว่าอุตสาหกรรมเว็บต้องการความเร็วที่มากขึ้นและเวลาแฝงที่ต่ำกว่านั้นตรงกับความหิวของ Google Chrome สำหรับ RAM ที่มากขึ้นเท่านั้น

เมื่อไม่กี่ปีที่ผ่านมา เราได้ตีพิมพ์บทความเกี่ยวกับ HTTP/2 ซึ่งเป็นมาตรฐานที่ W3Techs ระบุ ขณะนี้มีอัตราการนำไปใช้ทั่วโลกประมาณ 45% และจากข้อมูล Can I Use ยังรองรับเว็บเบราว์เซอร์สมัยใหม่ทั้งหมดอีกด้วย เรากำลังเขียนบทความเกี่ยวกับโปรโตคอลเวอร์ชันถัดไป HTTP/3

HTTP/3 เป็น IETF Internet-Draft หรือ ID ในขณะที่เขียนนี้ ซึ่งหมายความว่าขณะนี้อยู่ระหว่างการพิจารณาสำหรับมาตรฐานอินเทอร์เน็ตที่กำลังจะมีขึ้นโดย Internet Engineering Task Force ซึ่งเป็นหน่วยงาน มาตรฐานอินเทอร์เน็ตสากล รับผิดชอบในการกำหนด และส่งเสริมการตกลงกันตามมาตรฐานโปรโตคอลอินเทอร์เน็ต เช่น TCP, IPv6, VoIP, Internet of Things เป็นต้น

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

แม้ว่า HTTP/3 จะไม่ใช่โปรโตคอลอินเทอร์เน็ตอย่างเป็นทางการ แต่บริษัทและโครงการจำนวนมากได้เริ่มเพิ่มการรองรับ HTTP/3 ลงในผลิตภัณฑ์ของตนแล้ว

เว็บเบราว์เซอร์รองรับ HTTP/3

ที่ด้านหน้าของเว็บเบราว์เซอร์ Chrome v87, Firefox v88 และ Edge v87 ทั้งหมดเปิดใช้งาน HTTP/3 ตามค่าเริ่มต้น สำหรับผู้ใช้ Safari ตัวเลือกในการเปิดใช้งาน HTTP/3 ถูกเพิ่มลงใน Safari Technology Preview v104 อย่างไรก็ตาม ขณะนี้ยังไม่รองรับ HTTP/3 ใน Safari เวอร์ชันเสถียร

ห้องสมุดรองรับ HTTP/3

สำหรับนักพัฒนาที่ต้องการใช้ประโยชน์จากเทคโนโลยี HTTP/3 ไลบรารียอดนิยมจำนวนมากได้เพิ่มการรองรับ HTTP/3 แล้ว เนื่องจาก HTTP/3 ยังอยู่ในขั้น Internet Draft คุณจะต้องแน่ใจว่าคุณได้รับการปรับให้เข้ากับการอัปเดตล่าสุดเมื่อทำงานกับหนึ่งในไลบรารีด้านล่าง

• Python – http3 และ aioquic
• สนิม – คีช เนโก และควินน์
• C – nghttp3 และ lsquic
• ไป – quicgo
• JavaScript – Node.js

รองรับโครงสร้างพื้นฐานสำหรับ HTTP/3

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

ที่ Kinsta ไซต์ทั้งหมดที่เราโฮสต์ได้รับการคุ้มครองโดยการรวม Cloudflare ฟรีของเรา นอกจากไฟร์วอลล์ระดับองค์กรและการป้องกัน DDoS แล้ว ลูกค้า Kinsta ยังสามารถเข้าถึง HTTP/3 ได้อีกด้วย!

หากต้องการทดสอบว่าไซต์ของคุณรองรับ HTTP/3 หรือไม่ คุณสามารถใช้เครื่องมือทดสอบ HTTP/3 ของ Geekflare เพียงพิมพ์โดเมนของคุณแล้วกดปุ่ม "ตรวจสอบ HTTP/3" จากนั้นเครื่องมือจะแจ้งให้คุณทราบว่าไซต์ของคุณเปิดใช้งาน HTTP/3 หรือไม่

หากไซต์ของคุณรองรับ HTTP/3 คุณควรเห็นข้อความดังตัวอย่างด้านล่าง เนื่องจาก kinstalife.com โฮสต์อยู่บน Kinsta จึงรองรับ HTTP/3 ได้อย่างเต็มที่ด้วยการรวม Cloudflare ของเรา

คุณยังสามารถใช้ตัวตรวจสอบเบราว์เซอร์ของคุณเพื่อตรวจสอบการสนับสนุน HTTP/3 สำหรับตัวอย่างนี้ เราจะใช้ Google Chrome เวอร์ชันล่าสุดซึ่งสนับสนุน HTTP/3

หากต้องการเปิดตัวตรวจสอบ ให้คลิกขวาที่หน้าแล้วคลิก "ตรวจสอบ" และไปที่แท็บ "เครือข่าย" ในคอลัมน์ "โปรโตคอล" คุณสามารถดูโปรโตคอล HTTP ที่ใช้สำหรับการเชื่อมต่อได้ การเชื่อมต่อ HTTP/2 แสดงเป็น “h2” ในขณะที่การเชื่อมต่อ HTTP/3 ปรากฏเป็น “h3-XX” (XX หมายถึงร่าง HTTP/3 เฉพาะ) ดังที่คุณเห็นในภาพด้านล่าง kinstalife.com รองรับการเชื่อมต่อผ่าน “h3-29” ซึ่งหมายถึง “HTTP/3 Draft 29”

เมื่อได้ดูสถานะปัจจุบันของ HTTP/3 แล้ว เรามาเจาะลึกความแตกต่างระหว่าง HTTP/2 กับ HTTP/3 กัน!

พื้นหลังเล็กน้อย – เริ่มต้นด้วย HTTP/2

HTTP/2 นำมาซึ่งการปรับปรุงอย่างจริงจังด้วยการดาวน์โหลดที่ไม่ปิดกั้น การวางท่อ และการพุชของเซิร์ฟเวอร์ ซึ่งช่วยให้เราเอาชนะข้อจำกัดบางประการของโปรโตคอล TCP พื้นฐาน ช่วยให้เราลดจำนวนรอบการตอบรับคำขอและการจับมือกัน

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

ในทางปฏิบัติ นี่หมายความว่าตอนนี้ทรัพยากรจาวาสคริปต์ขนาดใหญ่หนึ่งรายการไม่จำเป็นต้องเท่ากับจุดควบคุมสำหรับทรัพยากรสแตติกอื่นๆ ทั้งหมดที่รอการเปิด

เพิ่มไปยังสิ่งเหล่านี้ การบีบอัด HPACK ส่วนหัวของ HTTP/2 และรูปแบบไบนารีเริ่มต้นของการถ่ายโอนข้อมูล และในหลายกรณี เรามีโปรโตคอลที่มีประสิทธิภาพมากขึ้นอย่างเห็นได้ชัด

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

สมมติว่าช่วงแรกๆ ของการนำเวอร์ชันนี้ไปใช้ไม่ได้มีไว้สำหรับคนที่อ่อนแอ

การใช้งาน Nginx ยังขาดคุณสมบัติการพุชเซิร์ฟเวอร์ โดยอาศัยโมดูล และโมดูล Nginx ไม่ใช่โมดูลดรอปอิน Apache ปกติของคุณที่คุณสามารถคัดลอกได้ – NGINX จะต้องคอมไพล์ใหม่ด้วยสิ่งเหล่านี้

ในขณะที่ปัญหาเหล่านี้บางส่วนได้รับการแก้ไขแล้ว หากเราดูที่สแต็กโปรโตคอลทั้งหมด เราจะเห็นว่าข้อจำกัดหลักอยู่ที่ระดับที่ต่ำกว่า HTTP/2 ที่กล้าเสี่ยง

เพื่ออธิบายรายละเอียดนี้อย่างละเอียด เราจะแยก Internet protocol stack ของวันนี้จากชั้นล่างไปด้านบน หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับพื้นหลังของ HTTP/2 โปรดอ่านคู่มือ HTTP/2 ขั้นสูงสุดของเรา

อินเทอร์เน็ตโปรโตคอล (IP)

Internet Protocol (IP) กำหนดส่วนล่างของโครงสร้างอินเทอร์เน็ตทั้งหมด เป็นส่วนหนึ่งของอินเทอร์เน็ตสแต็ก นั่นคือ เราสามารถพูดได้อย่างปลอดภัยว่าไม่สามารถต่อรองได้จริง ๆ โดยไม่ต้องเปลี่ยนแปลงทุกอย่าง รวมถึงการแทนที่โครงสร้างพื้นฐานของฮาร์ดแวร์ทั้งหมด ตั้งแต่เราเตอร์ไปจนถึงเซิร์ฟเวอร์ และแม้แต่เครื่องของผู้ใช้ปลายทาง

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

เราสามารถติดตามจุดเริ่มต้นของโปรโตคอล IP ย้อนกลับไปในปี 1974 ไปยังบทความที่ตีพิมพ์โดย Institute of Electrical and Electronics Engineers และเขียนโดย Vint Cerf และ Bob Cahn มีรายละเอียดแพ็กเก็ตที่ส่งผ่านเครือข่าย กำหนดเส้นทางข้ามที่อยู่ IP และที่อยู่ที่กำหนดเป็นตัวเลขของโหนดในเครือข่าย/เครือข่าย โปรโตคอลกำหนดรูปแบบของแพ็กเก็ตเหล่านี้หรือดาตาแกรม - ส่วนหัวและส่วนของข้อมูล

หลังจากคำจำกัดความ RFC 760 จากปี 1980 IETF ได้ตกลงกับคำจำกัดความที่ใช้กันอย่างแพร่หลายมาจนถึงทุกวันนี้ในคำขอความคิดเห็น 791 นี่เป็นเวอร์ชันที่สี่ของโปรโตคอล แต่เราสามารถพูดได้ว่านี่เป็นเวอร์ชันที่ใช้งานจริงรุ่นแรก

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

พวกเขากำลังปันส่วน

ไม่นานนักจนกระทั่งรู้ว่าที่อยู่แบบ 32 บิตไม่เพียงพอ และการขาดแคลนก็ใกล้เข้ามา จึงมีการเผยแพร่ RFC จำนวนมากเพื่อพยายามจัดการกับเรื่องนี้ แม้ว่าโซลูชันเหล่านี้จะใช้กันอย่างแพร่หลายในปัจจุบันและเป็นส่วนหนึ่งของชีวิตประจำวันของเรา แต่อาจปลอดภัยที่จะพูดถึงการแฮ็กจำนวนนี้

ลงทะเบียนเพื่อรับจดหมายข่าว

ต้องการทราบว่าเราเพิ่มการเข้าชมของเรามากกว่า 1,000% ได้อย่างไร

เข้าร่วมกับคนอื่นๆ อีกกว่า 20,000 คนที่ได้รับจดหมายข่าวรายสัปดาห์พร้อมเคล็ดลับ WordPress จากวงใน!

สมัครสมาชิกตอนนี้

Internet Protocol เวอร์ชัน 6 หรือ IPv6 เป็นวิธีแก้ไขข้อจำกัดเหล่านี้ รวมถึงการค่อยๆ นำมาใช้กับเวอร์ชันก่อนหน้า มันถูกสร้างเป็นเอกสารร่างมาตรฐานสำหรับ IETF ในปี 2541 และได้รับการยกให้เป็นมาตรฐานอินเทอร์เน็ตในปี 2560

แม้ว่าพื้นที่ที่อยู่ IPv4 จะถูกจำกัดด้วยความยาวที่อยู่แบบ 32 บิต แต่มาตรฐาน IPv6 จะได้รับ 128 บิต หรือ 3.4 * 10 ^ 38 ที่อยู่ได้ นี้ควรจะเพียงพอให้เราเป็นเวลานานพอสมควร

ตามการเชื่อมต่อระหว่างผู้ใช้ของ Google และ IPv6 การใช้งาน IPv6 นั้นมากกว่า 35% ณ เดือนมิถุนายน 2564

IP เป็นเลเยอร์พื้นฐานของอินเทอร์เน็ตสแต็ก ซึ่งกำหนดสิ่งพื้นฐานส่วนใหญ่ โดยไม่มีการรับประกันในการจัดส่ง ความสมบูรณ์ของข้อมูล หรือการจัดลำดับของแพ็กเก็ตที่ส่ง ด้วยตัวมันเองมันไม่น่าเชื่อถือ รูปแบบส่วนหัวของ IPv4 มีไว้สำหรับการตรวจสอบส่วนหัว ซึ่งโหนดการส่งข้อมูลใช้เพื่อตรวจสอบความสมบูรณ์ของส่วนหัว ทำให้แตกต่างจากรุ่น IPv6 ซึ่งอาศัยชั้นลิงก์ด้านล่าง ทำให้ทำงานได้เร็วขึ้น

การทำความเข้าใจบทบาทของ TCP และ UDP

ตอนนี้ได้เวลาสำรวจว่า HTTP/3 เหมาะสมกับ TCP และ UDP อย่างไร

TCP

แม้ว่า IP เป็นเลเยอร์พื้นฐานของการสื่อสารออนไลน์ทั้งหมดของเราในปัจจุบัน แต่ TCP (Transmission Control Protocol) เป็นส่วนระดับสูงของชุดโปรโตคอลอินเทอร์เน็ต ซึ่งให้ความน่าเชื่อถือที่จำเป็นสำหรับเว็บ อีเมล การถ่ายโอนไฟล์ (FTP) – สำหรับชั้นแอปพลิเคชัน/โปรโตคอลของอินเทอร์เน็ต

ซึ่งรวมถึงการสร้างการเชื่อมต่อแบบหลายขั้นตอนด้วยการจับมือกัน ลำดับของแพ็กเก็ตที่มั่นใจ และการส่งข้อมูลซ้ำของแพ็กเก็ตที่สูญหาย มันให้ข้อเสนอแนะ (Acks) ของการส่งมอบไปยังผู้ส่งและอื่น ๆ นอกจากนี้ยังมีการคำนวณเช็คซัมเพื่อตรวจหาข้อผิดพลาด

สิ่งเหล่านี้บ่งบอกถึงขั้นตอนมากมายที่ทำให้ TCP เป็นโปรโตคอลที่เชื่อถือได้ ทำให้เป็นรากฐานของบริการอินเทอร์เน็ตที่มีชื่อเสียงที่สุดที่เราใช้ในปัจจุบัน

ข้อมูลจำเพาะย้อนหลังไปถึงปี 1974 (RFC 675) และ 1981 (RFC 793) ไม่ได้เปลี่ยนแปลงไปอย่างมากจนถึงทุกวันนี้

อย่างไรก็ตาม ความน่าเชื่อถือที่ TCP มอบให้นั้นไม่ได้มาโดยไม่มีค่าใช้จ่าย ค่าโสหุ้ยของการไปกลับทั้งหมดที่จำเป็นสำหรับการจับมือกัน การตอบกลับในการจัดส่ง การค้ำประกันการสั่งซื้อ และการตรวจสอบที่อาจถือว่าอ่อนแอและซ้ำซ้อน มันทำให้ TCP เป็นคอขวดของโปรโตคอลสแต็คสมัยใหม่ HTTP/2 ได้มาถึงจุดที่ปรับปรุงความเร็วที่สามารถทำได้บน TCP

UDP

User Datagram Protocol (UDP) เป็นหนึ่งในส่วนต่างๆ ของ Internet Protocol Suite โดยมีข้อกำหนดย้อนหลังไปถึงปี 1980 (RFC 768)

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

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

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

หัวข้อนี้ใน Hacker News สามารถช่วยให้เราเริ่มเข้าใจเหตุผลที่อยู่เบื้องหลังการสร้างเวอร์ชัน HTTP ใหม่บนเครือข่ายสแต็กที่มีอยู่ แทนที่จะสร้างใหม่ (แม้ว่าจะมีมากกว่านั้น)

ข้อกำหนดรูปแบบแพ็กเก็ต UDP ค่อนข้างน้อย ส่วนหัวประกอบด้วยพอร์ตต้นทาง พอร์ตปลายทาง ความยาว เป็นไบต์ ส่วนหัวของแพ็กเก็ตและข้อมูลแพ็กเก็ต และเช็คซัม สามารถใช้ Checksum เพื่อตรวจสอบความถูกต้องของข้อมูลทั้งสำหรับส่วนหัวและส่วนข้อมูลของแพ็กเก็ต

Checksum เป็นทางเลือกเมื่อเลเยอร์โปรโตคอลพื้นฐานคือ IPv4 และบังคับกับ IPv6 จนถึงตอนนี้ UDP ถูกใช้สำหรับสิ่งต่างๆ เช่น การซิงโครไนซ์นาฬิกาของระบบคอมพิวเตอร์ (NTP), แอปพลิเคชัน VoIP, การสตรีมวิดีโอ, ระบบ DNS และโปรโตคอล DHCP

QUIC และ HTTP/3

QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน) ใช้งานครั้งแรกโดย Google ในปี 2555 โดยกำหนดขอบเขตของเลเยอร์เครือข่ายใหม่ โดยอาศัยโปรโตคอล UDP ระดับล่าง การกำหนดแฮนด์เชคใหม่ คุณลักษณะความน่าเชื่อถือ และคุณลักษณะด้านความปลอดภัยใน "พื้นที่ผู้ใช้" โดยหลีกเลี่ยงความจำเป็น การอัพเกรดเมล็ดของระบบอินเตอร์เน็ต

เช่นเดียวกับ HTTP/2 ซึ่งเป็นความก้าวหน้าที่ SPDY ของ Google เป็นผู้นำหรือมีความรวดเร็ว HTTP/3 จะสร้างความสำเร็จเหล่านี้ขึ้นมาอีกครั้ง

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

ซึ่งหมายความว่าแพ็กเก็ตทั้งหมด แม้ว่าแพ็กเก็ตเหล่านั้นจะถูกส่งและรออยู่แล้ว ในบัฟเฟอร์ของโหนดปลายทาง จะถูกบล็อกจนกว่าแพ็กเก็ตที่สูญหายจะถูกส่งต่อ Daniel Stenberg ในหนังสือของเขาที่ http/3 เรียกสิ่งนี้ว่า "การบล็อกส่วนหัวของบรรทัดที่ใช้ TCP" เขาอ้างว่าด้วยการสูญเสียแพ็กเก็ต 2% ผู้ใช้จะทำได้ดีขึ้นด้วย HTTP/1 โดยมีการเชื่อมต่อหกรายการเพื่อป้องกันความเสี่ยงนี้

QUIC ไม่ได้ถูกจำกัดด้วยสิ่งนี้ ด้วยการสร้าง QUIC บนโปรโตคอล UDP แบบไม่มีการเชื่อมต่อ แนวคิดของการเชื่อมต่อไม่มีข้อจำกัดของ TCP และความล้มเหลวของสตรีมหนึ่งๆ ไม่จำเป็นต้องส่งผลต่อส่วนที่เหลือ

ดังที่ Lucas Pardue จาก Cloudflare กล่าวไว้ว่า:

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

ผู้คนที่ Cisco ได้ทำวิดีโอที่น่าสนใจซึ่งอธิบายการจับมือ 3 ทางของ TCP:

แม้ว่า QUIC จะขจัดคุณสมบัติความน่าเชื่อถือของ TCP ออกไป แต่ก็ทำให้อยู่เหนือเลเยอร์ UDP โดยให้การส่งแพ็กเก็ตอีกครั้ง การสั่งซื้อ และอื่นๆ Google Cloud Platform เปิดตัวการรองรับ QUIC สำหรับตัวโหลดบาลานซ์ในปี 2018 และพบ ว่าเวลาในการโหลดหน้าเว็บเฉลี่ยเพิ่มขึ้น 8% ทั่วโลก และสูงถึง 13% ในภูมิภาคที่มีเวลาในการตอบสนองสูงกว่า

ระหว่าง Google Chrome, YouTube, Gmail, การค้นหาของ Google และบริการอื่นๆ Google สามารถปรับใช้ QUIC กับกลุ่มอินเทอร์เน็ตที่ดี โดยไม่ต้องรอ IETF วิศวกรของ Google อ้างว่าในปี 2560 7% ของปริมาณการใช้อินเทอร์เน็ตได้ดำเนินการผ่าน QUIC แล้ว

QUIC เวอร์ชันของ Google เน้นเฉพาะการขนส่ง HTTP โดยใช้ไวยากรณ์ HTTP/2 ผู้คนจาก IETF (ผู้รับผิดชอบในการสร้างมาตรฐาน QUIC) ตัดสินใจว่า QUIC เวอร์ชัน IETF ควรจะสามารถขนส่งได้มากกว่าแค่ HTTP อย่างไรก็ตาม ในระหว่างนี้ งานใดๆ บนโปรโตคอลที่ไม่ใช่ HTTP บน QUIC จะถูกระงับ

อีกสิ่งหนึ่งที่คณะทำงานของ IETF ตัดสินใจคือเวอร์ชันมาตรฐานจะใช้การเข้ารหัส TLS 1.3 แทนโซลูชันที่กำหนดเองของ Google เมื่อเทียบกับเวอร์ชันเก่า TLS 1.3 ยังช่วยให้โปรโตคอลมีความเร็ว เนื่องจากการแฮนด์เชคต้องการการไปกลับน้อยกว่า Kinsta รองรับ TLS 1.3 บนเซิร์ฟเวอร์ทั้งหมดของเราและ Kinsta CDN ของเรา

ขณะนี้ Google ยังคงใช้ QUIC เวอร์ชันของตนเองในผลิตภัณฑ์ของตนต่อไป ในขณะเดียวกันก็นำความพยายามในการพัฒนาไปสู่มาตรฐาน IETF ผู้เล่นอินเทอร์เน็ตรายอื่น ๆ ส่วนใหญ่สร้างบนเวอร์ชัน IETF (ทั้งสองต่างกันในด้านอื่น ๆ นอกเหนือจากการเข้ารหัส)

หากเราเปิดเครื่องมือ Chrome Dev และโหลดผลิตภัณฑ์บางอย่างของ Google เช่น Gmail ในคอลัมน์โปรโตคอลของแท็บเครือข่าย เราจะเห็นทรัพยากรจำนวนมากถูกโหลดผ่านโปรโตคอล QUIC เวอร์ชันของ Google นี่เป็นกรณีของผลิตภัณฑ์ของ Google เช่น Analytics, Google Tag Manager เป็นต้น

Cloudflare เผยแพร่การอัปเดตที่ครอบคลุมมากเกี่ยวกับความคืบหน้าของมาตรฐาน

แม้ว่า UDP จะให้ข้อดีบางประการแก่ QUIC และ HTTP/3 แต่ก็นำมาซึ่งความท้าทายบางประการ

TCP เป็นโปรโตคอลหลักมาหลายปีแล้ว ในขณะที่ UDP ไม่มี ดังนั้นโดยทั่วไปแล้ว ระบบปฏิบัติการและสแต็กซอฟต์แวร์จึงไม่ได้รับการปรับให้เหมาะสม ดังนั้นจึงมีภาระ/ข้อกำหนดของ CPU ที่สูงขึ้นมากสำหรับ QUIC จากการประมาณการบางอย่าง ซึ่งมากกว่า HTTP/2 ถึงสองเท่า

การเพิ่มประสิทธิภาพจะลงลึกไปถึงเคอร์เนลของระบบปฏิบัติการ ตลอดจนเราเตอร์และเฟิร์มแวร์ของอุปกรณ์ต่างๆ คู่มือการปรับแต่ง Red Hat นี้อาจให้ความกระจ่างมากขึ้นในหัวข้อสำหรับผู้ที่มีแนวโน้มทางเทคนิคมากขึ้น

เราอาจกล่าวได้ว่า QUIC พยายามปรับโครงสร้างคุณสมบัติ TCP ใหม่โดยใช้โปรโตคอลที่น้อยที่สุดและยืดหยุ่นกว่า

การเชื่อมต่อ QUIC ที่เรากล่าวถึงก่อนหน้านี้ ได้รวม TLS และการขนส่งแฮนด์เชคเข้าด้วยกัน เมื่อสร้างแล้ว จะถูกระบุโดย CID ที่ไม่ซ้ำกัน (ID การเชื่อมต่อ) รหัสเหล่านี้คงอยู่ตลอดการเปลี่ยนแปลง IP และสามารถช่วยรักษาความปลอดภัยให้กับการดาวน์โหลดอย่างต่อเนื่อง เช่น การเปลี่ยนจาก 4G เป็น WiFi สิ่งนี้มีความเกี่ยวข้องโดยเฉพาะอย่างยิ่งเนื่องจากมีการรับส่งข้อมูลทางอินเทอร์เน็ตบนอุปกรณ์มือถือมากขึ้นเรื่อย ๆ อาจมีคำถามว่า Google เป็นผู้กำหนดองค์ประกอบนี้เพื่ออำนวยความสะดวกในการติดตามผู้ใช้ที่ดีขึ้นในการเชื่อมต่อและผู้ให้บริการอินเทอร์เน็ตต่างๆ หรือไม่

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

สตรีม QUIC จะถูกส่งผ่านการเชื่อมต่อ QUIC แบบทิศทางเดียวหรือแบบสองทิศทาง สตรีมมีรหัสที่ระบุตัวเริ่มต้น และสตรีมเป็นแบบทิศทางเดียวหรือสองทิศทาง และยังให้บริการการควบคุมโฟลว์ในสตรีมด้วย

แม้ว่า QUIC เป็นโปรโตคอลเลเยอร์การขนส่ง HTTP เป็นเลเยอร์ที่สูงกว่านั้น โปรโตคอลเลเยอร์แอปพลิเคชัน หรือโปรโตคอลแอปพลิเคชัน

เนื่องจากความเข้ากันได้แบบย้อนหลังมีความสำคัญสูงสุด IETF จึงสนับสนุนการใช้งาน HTTP/3 และจะรวมเวอร์ชันเก่า (HTT1 หรือ HTTP/2) ไว้ในการตอบสนอง ซึ่งจะรวมส่วนหัวที่แจ้งไคลเอ็นต์ว่า HTTP/3 พร้อมใช้งาน พร้อมกับข้อมูลพอร์ต/โฮสต์ ตามที่อธิบายไว้ใน RFC 7838

ซึ่งแตกต่างจาก HTTP/2 ซึ่งสามารถเจรจาการขนส่งได้ภายใน TLS handshake แต่เนื่องจาก IETF มีทั้งหมดยกเว้นการนำ HTTP/3 แบบ QUIC มาใช้เป็นมาตรฐานถัดไป เราจึงคาดว่าเว็บไคลเอ็นต์จะคาดการณ์ว่า HTTP/3 จะรองรับมากขึ้นเรื่อยๆ เป็นไปได้ที่ไคลเอ็นต์จะแคชข้อมูลจากการเชื่อมต่อ HTTP/3 ก่อนหน้า และเชื่อมต่อโดยตรง (zero-ไป-กลับ หรือ 0-RTT) ในการเยี่ยมชมครั้งต่อไปไปยังโฮสต์เดียวกัน

สรุป

มีบางคนที่คิดว่ามาตรฐาน HTTP/2 ยังไม่ถูกนำมาใช้อย่างเต็มรูปแบบ อาจยังเร็วเกินไปที่จะผลักดัน HTTP/3 อย่างกว้างขวาง นี่เป็นจุดที่ถูกต้อง แต่ดังที่เราได้กล่าวไปแล้ว โปรโตคอลนี้ได้เห็นการทดสอบและการใช้งานในวงกว้างแล้ว Google เริ่มทดสอบตั้งแต่ต้นปี 2558 และ Facebook ในปี 2560

ในปี 2022 เรามีการสนับสนุน HTTP/3 จากเบราว์เซอร์หลักๆ เช่น Google Chrome และ Brave ที่ด้านหน้าของโครงสร้างพื้นฐาน เว็บเซิร์ฟเวอร์เช่น Litespeed และ Nginx มีการใช้งาน HTTP/3 ที่ใช้งานได้ ในขณะที่ผู้ให้บริการเครือข่ายเช่น Cloudflare ได้ปรับใช้การสนับสนุน HTTP/3 อย่างเต็มรูปแบบแล้ว

ขณะนี้ HTTP/3 ยังอยู่ในช่วง Internet Draft และการแก้ไขล่าสุดจะหมดอายุในเดือนสิงหาคม 2564 ปีนี้จะเป็นปีที่น่าตื่นเต้น เนื่องจากเราคาดว่าจะเห็นความเคลื่อนไหวของผู้จำหน่ายซอฟต์แวร์รายใหญ่ที่จะนำซอฟต์แวร์ใหม่นี้ไปใช้ มาตรฐาน.