HTTP/3: ทำลายล้างและก้าวสู่โลกใหม่ที่กล้าหาญ

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

ประวัติเล็กน้อย: HTTP/1.1

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

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

ใน HTTP/1.0 การเชื่อมต่อ TCP ถูกปิดหลังจากการร้องขอแต่ละครั้ง นี่เป็นการสิ้นเปลืองอย่างยิ่งเพราะ... การสร้างการเชื่อมต่อ TCP (3-Way-Handshake) เป็นกระบวนการที่ช้า HTTP/1.1 นำเสนอกลไก Keep-alive ซึ่งช่วยให้คุณใช้การเชื่อมต่อเดียวซ้ำสำหรับคำขอหลายรายการ อย่างไรก็ตาม เนื่องจากสามารถกลายเป็นคอขวดได้อย่างง่ายดาย การใช้งาน HTTP/1.1 หลายๆ แบบจึงทำให้สามารถเปิดการเชื่อมต่อ TCP หลายรายการไปยังโฮสต์เดียวกันได้ ตัวอย่างเช่น Chrome และ Firefox เวอร์ชันล่าสุดอนุญาตให้มีการเชื่อมต่อสูงสุดหกรายการ

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

ภาพประกอบของคลาวด์แฟลร์

ดังนั้น HTTP/1.1 จึงมีปัญหาหลายประการ:

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

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

ความทันสมัยเล็กน้อย: HTTP/2

ในปี 2012 Google เริ่มทำงานกับโปรโตคอล SPDY (อ่านว่า "รวดเร็ว") โปรโตคอลได้รับการออกแบบมาเพื่อแก้ไขปัญหาหลักของ HTTP/1.1 และในเวลาเดียวกันก็ควรที่จะรักษาความเข้ากันได้แบบย้อนหลัง ในปี 2015 คณะทำงาน IETF ได้เปิดตัวข้อกำหนด HTTP/2 ที่ใช้โปรโตคอล SPDY นี่คือความแตกต่างใน HTTP/2:

• การทำให้เป็นอนุกรมแบบไบนารี
• มัลติเพล็กซ์คำขอ HTTP หลายรายการในการเชื่อมต่อ TCP เดียว
• เซิร์ฟเวอร์พุชออกจากกล่อง (ไม่มี WebSocket)

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

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

ปัญหานี้เรียกว่า "การบล็อกส่วนหัว" และน่าเสียดายที่ไม่สามารถแก้ไขได้เมื่อใช้ TCP

ภาพประกอบโดย แดเนียล สไตน์เบิร์ก

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

เราต้องการโปรโตคอลใหม่: UDP กับ TCP

เห็นได้ชัดว่าการใช้โปรโตคอลการขนส่งเลเยอร์ใหม่อย่างสมบูรณ์นั้นเป็นงานที่เป็นไปไม่ได้ในความเป็นจริงในปัจจุบัน ความจริงก็คือฮาร์ดแวร์หรือกล่องกลาง (เราเตอร์ ไฟร์วอลล์ เซิร์ฟเวอร์ NAT...) รู้เกี่ยวกับเลเยอร์การขนส่ง และการสอนสิ่งใหม่ๆ ให้พวกเขานั้นเป็นงานที่ยากมาก นอกจากนี้เคอร์เนลของระบบปฏิบัติการยังรองรับโปรโตคอลการขนส่งอีกด้วย และเคอร์เนลก็ไม่เต็มใจที่จะเปลี่ยนแปลงมากนัก

และที่นี่ใคร ๆ ก็ยกมือขึ้นแล้วพูดว่า "แน่นอนว่าเราจะสร้าง HTTP/3 ใหม่ตามความชอบและโสเภณี แต่จะใช้เวลา 10-15 ปีในการดำเนินการ (หลังจากนั้นประมาณเวลานี้ฮาร์ดแวร์ส่วนใหญ่จะเป็น แทนที่)” แต่มีอีกอย่างหนึ่งที่ไม่เป็นเช่นนั้น ตัวเลือกที่ชัดเจนคือการใช้โปรโตคอล UDP ใช่ ใช่ โปรโตคอลเดียวกับที่เราใช้ในการส่งไฟล์ผ่าน LAN ในช่วงปลายยุค XNUMX และต้นยุค XNUMX ฮาร์ดแวร์ในปัจจุบันเกือบทั้งหมดสามารถทำงานได้

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

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

เช่นเดียวกับ HTTP/2 การทำงานในการสร้างโปรโตคอลใหม่เริ่มต้นที่ Google ในปี 2012 นั่นคือช่วงเวลาเดียวกับที่การทำงานบน SPDY เริ่มต้นขึ้น ในปี 2013 Jim Roskind นำเสนอต่อสาธารณชนทั่วไป โปรโตคอล QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน)และในปี 2015 Internet Draft ก็ได้ถูกนำมาใช้เพื่อสร้างมาตรฐานใน IETF ในเวลานั้นโปรโตคอลที่ Roskind พัฒนาโดย Google นั้นแตกต่างจากมาตรฐานมากดังนั้นเวอร์ชันของ Google จึงเริ่มเรียกว่า gQUIC

QUIC คืออะไร

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

ภาพประกอบโดย แดเนียล สไตน์เบิร์ก

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

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

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

และสุดท้ายก็พาดหัวข่าว การบีบอัดส่วนหัวเป็นหนึ่งในสิ่งที่แตกต่างระหว่าง QUIC และ gQUIC ฉันไม่เห็นประเด็นในการทุ่มเทเวลามากนักในเรื่องนี้ ฉันจะบอกว่าในเวอร์ชันที่ส่งมาเพื่อให้เป็นมาตรฐาน การบีบอัดส่วนหัวถูกสร้างขึ้นให้คล้ายกับการบีบอัดส่วนหัวใน HTTP/2 มากที่สุดเท่าที่จะเป็นไปได้ คุณสามารถอ่านเพิ่มเติมได้ ที่นี่.

เร็วแค่ไหน?

มันเป็นคำถามที่ยาก ความจริงก็คือจนกว่าเราจะมีมาตรฐาน ก็ไม่มีอะไรพิเศษที่จะวัดได้ บางทีสถิติเดียวที่เรามีคือสถิติจาก Google ซึ่งใช้ gQUIC มาตั้งแต่ปี 2013 และในปี 2016 รายงานตัวต่อ IETF แล้วประมาณ 90% ของการรับส่งข้อมูลที่ไปยังเซิร์ฟเวอร์จากเบราว์เซอร์ Chrome ตอนนี้ใช้ QUIC ในการนำเสนอเดียวกัน พวกเขารายงานว่าหน้าเว็บโหลดเร็วขึ้นประมาณ 5% ผ่าน gQUIC และมีการพูดติดอ่างน้อยลงในการสตรีมวิดีโอ 30% เมื่อเทียบกับ TCP

ในปี 2017 กลุ่มนักวิจัยที่นำโดย Arash Molavi Kakhki ตีพิมพ์ เยี่ยมมาก เพื่อศึกษาประสิทธิภาพของ gQUIC เปรียบเทียบกับ TCP
การศึกษาเผยให้เห็นจุดอ่อนหลายประการของ gQUIC เช่น ความไม่เสถียรในการผสมแพ็กเก็ตเครือข่าย ความละโมบ (ความไม่ยุติธรรม) ต่อแบนด์วิดท์ของช่องสัญญาณ และการถ่ายโอนอ็อบเจ็กต์ขนาดเล็ก (สูงสุด 10 kb) ที่ช้าลง อย่างไรก็ตามอย่างหลังสามารถชดเชยได้โดยใช้ 0-RTT ในกรณีอื่นๆ ทั้งหมดที่ศึกษา gQUIC มีความเร็วเพิ่มขึ้นเมื่อเทียบกับ TCP เป็นการยากที่จะพูดถึงตัวเลขเฉพาะที่นี่ อ่านดีกว่า การศึกษานั้นเอง หรือ โพสต์สั้น ๆ.

ในที่นี้ต้องบอกว่าข้อมูลนี้เกี่ยวกับ gQUIC โดยเฉพาะ และไม่เกี่ยวข้องกับมาตรฐานที่กำลังพัฒนา จะเกิดอะไรขึ้นกับ QUIC: ยังคงเป็นความลับ แต่มีความหวังว่าจุดอ่อนที่ระบุใน gQUIC จะถูกนำมาพิจารณาและแก้ไข

อนาคตเล็กน้อย: แล้ว HTTP/3 ล่ะ?

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

ใครอุดหนุนแล้ว

ที่นี่ รายการ การใช้งาน QUIC ที่มีอยู่ ถึงแม้จะขาดมาตรฐานแต่รายการก็ไม่เลว

ขณะนี้ไม่มีเบราว์เซอร์ที่รองรับ QUIC ในรุ่นที่ใช้งานจริง ล่าสุดมีข้อมูลที่สนับสนุน HTTP/3 รวมอยู่ใน Chrome แต่จนถึงขณะนี้มีเฉพาะใน Canary เท่านั้น

ในส่วนของแบ็กเอนด์ HTTP/3 รองรับเฉพาะเท่านั้น นวมกาน้ำร้อน и Cloudflareแต่ยังคงอยู่ในช่วงทดลอง NGINX เมื่อปลายฤดูใบไม้ผลิ 2019 ประกาศที่พวกเขาเริ่มทำงานกับการสนับสนุน HTTP/3 แต่ยังไม่เสร็จสิ้น

มีปัญหาอะไรบ้าง?

คุณและฉันอาศัยอยู่ในโลกแห่งความเป็นจริง ซึ่งไม่มีเทคโนโลยีขนาดใหญ่ใดสามารถเข้าถึงคนจำนวนมากได้หากปราศจากการต่อต้าน และ QUIC ก็ไม่มีข้อยกเว้น

สิ่งที่สำคัญที่สุดคือคุณต้องอธิบายให้เบราว์เซอร์ฟังว่า “https://” ไม่ใช่ข้อเท็จจริงที่ว่าจะนำไปสู่พอร์ต TCP 443 อีกต่อไป อาจไม่มี TCP เลย ส่วนหัว Alt-Svc ใช้สำหรับสิ่งนี้ ช่วยให้คุณบอกเบราว์เซอร์ว่าเว็บไซต์นี้มีให้บริการบนโปรโตคอลดังกล่าวและที่อยู่ดังกล่าวด้วย ตามทฤษฎีแล้ว สิ่งนี้น่าจะได้ผล แต่ในทางปฏิบัติเราจะเจอกับความจริงที่ว่า UDP สามารถถูกห้ามบนไฟร์วอลล์ได้ เพื่อหลีกเลี่ยงการโจมตี DDoS

แต่ถึงแม้จะไม่ได้ห้าม UDP ไคลเอนต์ก็อาจอยู่หลังเราเตอร์ NAT ที่ได้รับการกำหนดค่าให้เก็บเซสชัน TCP ตามที่อยู่ IP และเนื่องจาก เราใช้ UDP ซึ่งไม่มีเซสชันฮาร์ดแวร์ NAT จะไม่เก็บการเชื่อมต่อ และใช้เซสชัน QUIC จะแตกสลายไปอย่างต่อเนื่อง.

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

นอกจากนี้ ตามที่อธิบายไว้แล้ว QUIC เพิ่มการใช้งาน CPU อย่างมาก ดาเนียล สเตนเบิร์ก ชื่นชม โปรเซสเซอร์เติบโตถึงสามเท่า

HTTP/3 จะมาถึงเมื่อใด

มาตรฐาน ต้องการที่จะยอมรับ ภายในเดือนพฤษภาคม 2020 แต่เนื่องจากเอกสารที่กำหนดในเดือนกรกฎาคม 2019 ยังไม่เสร็จในขณะนี้ จึงอาจกล่าวได้ว่าวันที่ดังกล่าวมีแนวโน้มที่จะถูกเลื่อนออกไป

Google ได้ใช้งาน gQUIC มาตั้งแต่ปี 2013 หากคุณดูคำขอ HTTP ที่ส่งไปยังเครื่องมือค้นหาของ Google คุณจะเห็นสิ่งนี้:

ผลการวิจัย

ตอนนี้ QUIC ดูเหมือนเป็นเทคโนโลยีที่ค่อนข้างหยาบ แต่มีแนวโน้มมาก เมื่อพิจารณาว่าในช่วง 20 ปีที่ผ่านมา การเพิ่มประสิทธิภาพโปรโตคอลชั้นการขนส่งทั้งหมดเกี่ยวข้องกับ TCP, QUIC เป็นหลัก ซึ่งโดยส่วนใหญ่แล้วจะมีประสิทธิภาพที่ดีที่สุด และดูดีอยู่แล้ว

อย่างไรก็ตาม ยังคงมีปัญหาที่ยังไม่ได้รับการแก้ไขซึ่งจะต้องได้รับการจัดการในอีกไม่กี่ปีข้างหน้า กระบวนการนี้อาจล่าช้าเนื่องจากมีฮาร์ดแวร์ที่เกี่ยวข้องซึ่งไม่มีใครชอบอัปเดต แต่อย่างไรก็ตาม ปัญหาทั้งหมดดูค่อนข้างแก้ไขได้ และไม่ช้าก็เร็วเราทุกคนก็จะมี HTTP/3

อนาคตอยู่ใกล้แค่เอื้อม!

ที่มา: will.com