ประสิทธิภาพและประสิทธิภาพ: การทำงานกับ HTTP/3

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

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

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

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

ปัญหาหลัก: ประสิทธิภาพและประสิทธิภาพ

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

ความล่าช้าในการโหลดเว็บไซต์ 100 มิลลิวินาทีสามารถส่งผลกระทบต่ออัตราการแปลง 7 เปอร์เซ็นต์

รายงานประสิทธิภาพการค้าปลีกออนไลน์ของ Akamai: มิลลิวินาทีมีความสำคัญ (2017)

กล่าวอีกนัยหนึ่ง เว็บไซต์อีคอมเมิร์ซที่มียอดขาย 40,000 ดอลลาร์ต่อวันจะสูญเสียหนึ่งล้านดอลลาร์ต่อปีเนื่องจากความล่าช้าดังกล่าว

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

การวิจัยยังพบว่า:

• 47% ของผู้บริโภคคาดหวังว่าหน้าเว็บจะโหลดได้ภายใน 2 วินาทีหรือน้อยกว่า
• 40% ของผู้คนละทิ้งเว็บไซต์ที่ใช้เวลาในการโหลดมากกว่า 3 วินาที

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

HTTP/2? …นั่นอะไร?

ความเข้าใจที่ดีเกี่ยวกับโปรโตคอล HTTP/2 มีความสำคัญต่อการทำความเข้าใจ HTTP/3 ก่อนอื่น เหตุใดจึงมีความจำเป็นสำหรับ HTTP/2

HTTP/2 เริ่มต้นจากโครงการ Google ชื่อ SPDY ซึ่งเป็นผลมาจากการศึกษาที่รายงานว่าปัญหาด้านประสิทธิภาพที่ใหญ่ที่สุดบนเว็บคือ เวลาแฝง ผู้เขียนสรุปว่า “แบนด์วิดธ์ที่มากขึ้นไม่สำคัญ (มาก)”:

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

ในขณะเดียวกัน ไม่ว่าท่อของคุณจะใหญ่แค่ไหน หากท่อว่างเปล่า และคุณต้องการรับน้ำจากจุดหนึ่งไปยังอีกจุดหนึ่ง ก็ต้องใช้เวลาเพื่อให้น้ำไหลผ่านท่อ ในภาษาอินเทอร์เน็ต เวลาที่น้ำใช้ในการเดินทางจากปลายท่อด้านหนึ่งไปยังอีกด้านหนึ่งและกลับมาอีกครั้งเรียกว่า เวลาไปกลับ หรือ RTT

ไมค์ เบลเช

ในการศึกษานี้ เป้าหมายคือการลดเวลาในการโหลดหน้าเว็บ แสดงให้เห็นว่าการเพิ่มแบนด์วิดธ์จะช่วยในขั้นต้น เนื่องจากการเปลี่ยนจาก 1 Mbps เป็น 2 Mbps จะช่วยลดเวลาในการโหลดหน้าเว็บลงครึ่งหนึ่ง อย่างไรก็ตามผลประโยชน์ที่ราบสูงอย่างรวดเร็ว

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

HTTP HOL: ปัญหาการบล็อกบรรทัดแรก

สาเหตุหลักของเวลาในการตอบสนองภายในโปรโตคอล HTTP/1 คือปัญหาการบล็อกบรรทัดแรก หน้าเว็บ (เกือบทุกครั้ง) ต้องการทรัพยากรหลายอย่าง: CSS, JavaScript, แบบอักษร, รูปภาพ, AJAX/XMR เป็นต้น ซึ่งหมายความว่าเว็บเบราว์เซอร์จำเป็นต้องส่งคำขอหลายรายการไปยังเซิร์ฟเวอร์ อย่างไรก็ตาม ไม่จำเป็นต้องใช้ทรัพยากรทั้งหมดเพื่อให้หน้าเว็บมีประโยชน์

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

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

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

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

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

โซลูชันการบล็อก HTTP HOL ของ HTTP/2

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

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

แม้ว่าการทำมัลติเพล็กซ์ตามคำขอจะเป็นฟีเจอร์พาดหัวสำหรับ HTTP/2 แต่ก็มีฟีเจอร์ที่สำคัญอื่นๆ อีกหลายประการ ผู้อ่านอาจสังเกตเห็นว่าพวกเขาทั้งหมดค่อนข้างเกี่ยวข้องกัน

เฟรมไบนารี HTTP/2

HTTP/2 เปลี่ยนมาตรฐานโปรโตคอล HTTP จากโมเดลการตอบสนองคำขอ ASCII ที่มนุษย์อ่านได้ไม่มีประสิทธิภาพไปเป็นการ สร้างเฟรมไบนารี ที่มีประสิทธิภาพ ไม่ใช่แค่คำขอและการตอบกลับอีกต่อไป:

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

HTTP/2 HPACK (การบีบอัดส่วนหัว)

การบีบอัดส่วนหัว ใหม่ของ HTTP/2 โดยใช้รูปแบบ HPACK ช่วยประหยัดแบนด์วิดท์ได้มากมายสำหรับไซต์ส่วนใหญ่ เนื่องจากส่วนหัวส่วนใหญ่เหมือนกันสำหรับคำขอที่ส่งภายในการเชื่อมต่อ

Cloudflare รายงานการประหยัดแบนด์วิดธ์อย่างมากด้วย HPACK เพียงอย่างเดียว:

• การบีบอัด 76% สำหรับส่วนหัวขาเข้า
• ลดปริมาณการรับส่งข้อมูลทั้งหมด 53%
• การบีบอัด 69% สำหรับส่วนหัวขาออก
• ลดปริมาณการรับส่งข้อมูลขาออกทั้งหมด 1.4% ถึง 15%

แน่นอนว่าการใช้แบนด์วิดท์น้อยลงหมายถึงเว็บไซต์ที่เร็วขึ้น

การจัดลำดับความสำคัญของสตรีม HTTP/2 และการพุชเซิร์ฟเวอร์

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

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

นี่เป็นสิ่งสำคัญอย่างยิ่งสำหรับโปรเกรสซีฟเว็บแอปพลิเคชัน (PWAs) ตัวอย่างเช่น สมมติว่าหน้ามีไฟล์ JavaScript สี่ไฟล์ สองรายการสำหรับหน้าที่การใช้งานและอีกสองรายการสำหรับโฆษณา กรณีที่เลวร้ายที่สุดคือการโหลด JS ที่ใช้งานได้ครึ่งหนึ่งและ JS โฆษณาครึ่งหนึ่งจากนั้นจึงโหลดรูปภาพขนาดใหญ่ก่อนที่จะโหลด JS ที่เหลือ ในกรณีนั้น ไม่มีอะไรในเพจทำงานตั้งแต่แรก เพราะทุกอย่างต้องรอทรัพยากรที่ช้าที่สุด

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

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

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

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

การนำ HTTP กับ HTTP/2 มาใช้

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

หลังจากกำหนดมาตรฐานแล้ว การนำ HTTP/2 (หรือ “h2”) มาใช้ก็เพิ่มขึ้นอย่างรวดเร็วจนเป็นประมาณ 40% ของเว็บไซต์ 1,000 อันดับแรก ส่วนใหญ่ได้รับแรงหนุนจากผู้ให้บริการโฮสติ้งและคลาวด์รายใหญ่ที่ปรับใช้การสนับสนุนในนามของลูกค้า น่าเสียดาย หลายปีต่อมา การนำ HTTP/2 มาใช้ได้ช้าลง และอินเทอร์เน็ตส่วนใหญ่ยังคงใช้ HTTP/1

ขาดการสนับสนุนเบราว์เซอร์สำหรับโหมดข้อความล้าง HTTP/2

มีการเรียกร้องให้ HTTP/2 ทำการเข้ารหัสเป็นส่วนที่จำเป็นของมาตรฐานหลายครั้ง มาตรฐานกำหนดโหมดการเข้ารหัส (h2) และข้อความธรรมดา (h2c) แทน ดังนั้น HTTP/2 สามารถแทนที่ HTTP/1 ได้ทั้งหมด

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

ทำไมต้อง HTTP/3 และแตกต่างกันอย่างไร?

ด้วยปัญหาการบล็อกส่วนหัวของ HTTP ที่แก้ไขโดย HTTP/2 นักพัฒนาโปรโตคอลได้หันความสนใจไปที่ไดรเวอร์เวลาแฝงที่ใหญ่ที่สุดตัวถัดไป: ปัญหาการบล็อกส่วนหัวของ TCP

โปรโตคอลควบคุมการส่ง (TCP)

เครือข่าย IP (โปรโตคอลอินเทอร์เน็ต) อิงตามแนวคิดของคอมพิวเตอร์ที่ส่งแพ็กเก็ตระหว่างกัน แพ็กเก็ตเป็นเพียงข้อมูลที่มีข้อมูลที่อยู่ติดอยู่ด้านบน

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

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

ในเดือนตุลาคมปี '86 อินเทอร์เน็ตได้กลายมาเป็นชุดของ 'ความแออัดที่ล่มสลาย' ในช่วงเวลานี้ อัตราการส่งข้อมูลจาก LBL ไปยัง UC Berkeley (ไซต์ที่แยกจากกัน 400 หลาและ IMP สามครั้ง) ลดลงจาก 32 Kbps เป็น 40 bps

วี. เจคอบสัน (1988)

นั่นคือที่มาของปัญหาการบล็อก TCP head-of-line

ปัญหาการบล็อก TCP HOL

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

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

อีกโครงการหนึ่งจาก Google มีเป้าหมายเพื่อแก้ปัญหานี้โดยแนะนำโปรโตคอลที่เรียกว่า QUIC

โปรโตคอล QUIC สร้างขึ้นบน UDP แทน TCP และ QUIC กำลังสร้างพื้นฐานสำหรับ HTTP/3

UDP คืออะไร?

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

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

โซลูชัน TCP HOL ของ HTTP/3

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

เนื่องจาก QUIC เข้าควบคุมการจัดการสตรีม การจัดเฟรมไบนารี ฯลฯ จึงเหลือไม่มากสำหรับ HTTP/2 ที่ต้องทำเมื่อทำงานบน QUIC นี่เป็นส่วนหนึ่งของปัจจัยขับเคลื่อนสู่การผสมผสานใหม่ของ QUIC + HTTP ที่ได้มาตรฐานเป็น HTTP/3

หมายเหตุ: QUIC มีหลายเวอร์ชัน เนื่องจากโปรโตคอลนี้อยู่ในระหว่างการพัฒนาและใช้งานในสภาพแวดล้อมที่ใช้งานจริงมานานหลายปี มีแม้กระทั่งเวอร์ชันเฉพาะของ Google ที่เรียกว่า GQUIC ดังนั้น สิ่งสำคัญคือต้องสร้างความแตกต่างระหว่างโปรโตคอล QUIC เก่ากับมาตรฐาน HTTP/3 ใหม่

เข้ารหัสเสมอ

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

การเปลี่ยนแปลงนี้เป็นเพราะ HTTP/3 แตกต่างจาก HTTPS ในแง่ของการเข้ารหัส ด้วยโปรโตคอล HTTPS รุ่นเก่า เฉพาะข้อมูลเท่านั้นที่ได้รับการปกป้องโดย TLS ทำให้มองเห็นข้อมูลเมตาการส่งข้อมูลจำนวนมาก ใน HTTP/3 ทั้งข้อมูลและโปรโตคอลการขนส่งได้รับการปกป้อง นี่อาจฟังดูเหมือนคุณลักษณะด้านความปลอดภัยและเป็นเช่นนั้น แต่วิธีนี้ทำเพื่อหลีกเลี่ยงโอเวอร์เฮดจำนวนมากใน HTTP/2 ดังนั้นการเข้ารหัสโปรโตคอลการขนส่งตลอดจนข้อมูลทำให้โปรโตคอลมีประสิทธิภาพมากขึ้น

ผลกระทบของ HTTP/3 ต่อโครงสร้างพื้นฐานเครือข่าย

HTTP/3 ไม่ได้ไร้ข้อโต้แย้ง ความกังวลหลักเกี่ยวกับโครงสร้างพื้นฐานเครือข่าย

HTTP/3 . ฝั่งไคลเอ็นต์

ในฝั่งไคลเอ็นต์ เป็นเรื่องปกติที่ทราฟฟิก UDP จะถูกจำกัดอัตราอย่างมากและ/หรือถูกบล็อก การใช้ข้อจำกัดเหล่านี้กับ HTTP/3 จะทำลายจุดสำคัญของโปรโตคอล

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

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

เป็นที่น่าสังเกตว่าการกรองแบบจำกัด สามารถ ทำได้ในขณะนี้ นี่เป็นเพราะว่าฟิลด์บ่งชี้ชื่อเซิร์ฟเวอร์ (SNI)—ซึ่งมีชื่อโฮสต์ของเว็บไซต์แต่ไม่ใช่พาธ, พารามิเตอร์การค้นหา ฯลฯ— ยังไม่ได้เข้ารหัส แต่สิ่งนี้จะเปลี่ยนแปลงในอนาคตอันใกล้ด้วยการเปิดตัว ESNI (SNI ที่เข้ารหัส) ซึ่งเพิ่งถูกเพิ่มเข้าไปในมาตรฐาน TLS

HTTP/3 . ฝั่งเซิร์ฟเวอร์

ทางฝั่งเซิร์ฟเวอร์ แนวทางปฏิบัติที่ดีที่สุดคือการบล็อกพอร์ตและโปรโตคอลใดๆ ที่ไม่คาดว่าจะมีการรับส่งข้อมูล หมายความว่าผู้ดูแลระบบเซิร์ฟเวอร์ต้องเปิด UDP 443 สำหรับ HTTP/3 แทนที่จะใช้กฎ TCP 443 ที่มีอยู่

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

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

สุดท้ายนี้ ผู้ดูแลระบบจำนวนมากไม่เห็นด้วยกับการจัดการใบรับรอง SSL ให้มากขึ้น แม้ว่าตอนนี้จะไม่มีปัญหากับบริการอย่างเช่น Let's Encrypt ก็ตาม

จนกว่าจะมีวิธีแก้ปัญหาที่เป็นที่รู้จักกันดีและเป็นที่ยอมรับในวงกว้างเพื่อจัดการกับข้อกังวลเหล่านี้ ฉันคิดว่ามีความเป็นไปได้ที่เครือข่ายขนาดใหญ่จำนวนมากจะบล็อก HTTP/3 ได้ง่ายๆ

ผลกระทบของ HTTP/3 ต่อการพัฒนาเว็บ

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

ใช้ HTTP/3 ตอนนี้

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

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

1. การตั้งค่า DNS รับชื่อโฮสต์ที่ใช้งานได้ซึ่งแสดงอยู่บนอินเทอร์เน็ต เช่น yourhostname.example.com IN A 192.0.2.1
2. การสร้างแคดดี้ไฟล์ ควรมีบรรทัดเหล่านี้:

 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]

1. Running Caddy: docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic —หรือภายนอก Docker, caddy --quic
2. ใช้โครเมียมโดยเปิดใช้งาน QUIC: chromium --enable-quic
3. (ไม่บังคับ) การติดตั้งส่วนขยายตัวบ่งชี้โปรโตคอล
4. การนำทางไปยังเซิร์ฟเวอร์ที่เปิดใช้งาน QUIC ซึ่งควรมองเห็นไฟล์เบราว์เซอร์

นักพัฒนายังสามารถทดสอบเซิร์ฟเวอร์ของตนด้วยเครื่องมือที่มีประโยชน์ดังต่อไปนี้:

• การทดสอบ HTTP/2 ของ Keycdn
• HTTP3Check ของ LiteSpeed
• การทดสอบเซิร์ฟเวอร์ SSL ของ Qualys

ขอบคุณที่อ่าน!