HTTP/3: ตัวเลือกการปรับใช้จริง (ตอนที่ 3)

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

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

การเปลี่ยนแปลงในหน้าและทรัพยากร

เริ่มต้นด้วยข่าวดีกันก่อน: หากคุณใช้ HTTP/2 อยู่แล้ว คุณอาจไม่ต้องเปลี่ยนแปลงอะไรในเพจหรือทรัพยากรของคุณเมื่อเปลี่ยนไปใช้ HTTP/3! . เนื่องจากดังที่เราได้อธิบายไว้ในตอนที่ 1 และตอนที่ 2 แล้ว HTTP/3 นั้นเหมือนกับ HTTP/2-over-QUIC มากกว่า และฟีเจอร์ระดับสูงของทั้งสองเวอร์ชันยังคงเหมือนเดิม ด้วยเหตุนี้ การเปลี่ยนแปลงหรือการเพิ่มประสิทธิภาพใดๆ ที่ทำขึ้นสำหรับ HTTP/2 จะยังคงทำงานสำหรับ HTTP/3 และในทางกลับกัน

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

แหล่งที่มาที่เหมาะสมที่สุดแบบ all-in-one สำหรับ HTTP/2 ที่ฉันสามารถแนะนำได้ในขณะนี้คือหนังสือ HTTP/2 in Action โดย Barry Pollard อย่างไรก็ตาม เนื่องจากเป็นทรัพยากรที่ต้องเสียค่าใช้จ่าย และฉันไม่ต้องการให้คุณถูกทิ้งให้คาดเดาในที่นี้ ฉันจึงได้ระบุประเด็นหลักสองสามประการไว้ด้านล่าง พร้อมกับความเกี่ยวข้องกับ HTTP/3 ที่เกี่ยวข้อง:

1. การเชื่อมต่อเดียว

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

2. การแบ่งเซิร์ฟเวอร์และการรวมการเชื่อมต่อ

ในทางปฏิบัติ การเปลี่ยนไปใช้การตั้งค่าการเชื่อมต่อเดี่ยวนั้นค่อนข้างยาก เนื่องจากมีหลายเพจที่ถูกแบ่งส่วนตามชื่อโฮสต์ที่แตกต่างกันและแม้แต่เซิร์ฟเวอร์ (เช่น img1.example.com และ img2.example.com ) เนื่องจากเบราว์เซอร์เปิดการเชื่อมต่อได้ไม่เกิน 6 รายการสำหรับชื่อโฮสต์แต่ละชื่อ ดังนั้นจึงอนุญาตให้มีการเชื่อมต่อได้หลายรายการ หากไม่มีการเปลี่ยนแปลงในการตั้งค่า HTTP/1.1 นี้ HTTP/2 จะยังคงเปิดการเชื่อมต่อหลายรายการ ซึ่งลดความสามารถในการทำงานของฟีเจอร์อื่นๆ เช่น การจัดลำดับความสำคัญ (ดูด้านล่าง) ได้ดีเพียงใด

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

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

3. การรวมทรัพยากรและการรวมเข้าด้วยกัน

ใน HTTP/1.1 คุณสามารถมีทรัพยากรที่ ใช้งานอยู่ ได้เพียงรายการเดียวต่อการเชื่อมต่อ ซึ่งนำไปสู่การบล็อกส่วนหัวของบรรทัด (HoL) ระดับ HTTP เนื่องจากจำนวนการเชื่อมต่อถูกจำกัดไว้ที่ 6 ถึง 30 ที่เลวทรามต่ำช้า การรวมกลุ่มทรัพยากร (โดยที่ทรัพยากรย่อยที่เล็กกว่าจะรวมกันเป็นทรัพยากรที่ใหญ่กว่าเพียงรายการเดียว) จึงเป็นแนวทางปฏิบัติที่ดีที่สุดมาเป็นเวลานาน เรายังคงเห็นสิ่งนี้ในบันเดิลเช่น Webpack ในทำนองเดียวกัน ทรัพยากรมักจะอยู่ในทรัพยากรอื่นๆ (เช่น CSS ที่สำคัญอยู่ใน HTML)

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

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

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

4. การจัดลำดับความสำคัญ

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

น่าเศร้า นี่คือสิ่งที่คุณในฐานะนักพัฒนาเว็บทั่วไปไม่สามารถทำอะไรได้มากนัก เพราะส่วนใหญ่เป็นปัญหาในเบราว์เซอร์และเซิร์ฟเวอร์เอง อย่างไรก็ตาม คุณสามารถลองลดปัญหาได้โดยใช้ไฟล์แต่ละไฟล์มากเกินไป (ซึ่งจะช่วยลดโอกาสในการจัดลำดับความสำคัญที่แข่งขันกัน) และโดยยังคงใช้การแบ่งส่วนย่อย (จำกัด) อีกทางเลือกหนึ่งคือการใช้เทคนิคที่มีอิทธิพลต่อลำดับความสำคัญต่างๆ เช่น การโหลดแบบ Lazy Loading, JavaScript async และ defer และคำแนะนำทรัพยากร เช่น preload ภายใน สิ่งเหล่านี้ส่วนใหญ่เปลี่ยนลำดับความสำคัญของทรัพยากรเพื่อให้ส่งเร็วหรือช้ากว่านั้น อย่างไรก็ตาม กลไกเหล่านี้สามารถ (และทำ) ได้กับข้อบกพร่อง นอกจากนี้ อย่าคาดหวังว่าจะต้องโหลดทรัพยากร preload จำนวนมากและทำให้สิ่งต่าง ๆ เร็วขึ้น: หากทุกอย่างมีความสำคัญสูงในทันใดก็ไม่มีอะไรเป็น! มันยังง่ายมากที่จะชะลอทรัพยากรที่สำคัญจริงๆ โดยใช้สิ่งต่างๆ เช่น preload

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

5. เซิร์ฟเวอร์พุชและเที่ยวบินแรก

การพุชของเซิร์ฟเวอร์ช่วยให้เซิร์ฟเวอร์ส่งข้อมูลการตอบกลับโดยไม่ต้องรอคำขอจากลูกค้าก่อน อีกครั้ง ฟังดูดีในทางทฤษฎี และสามารถใช้แทนแหล่งข้อมูลภายใน (ดูด้านบน) อย่างไรก็ตาม ตามที่กล่าวไว้ในตอนที่ 2 การพุชเป็นเรื่องยากมากที่จะใช้อย่างถูกต้อง เนื่องจากปัญหาเกี่ยวกับการควบคุมความแออัด การแคช การจัดลำดับความสำคัญ และการบัฟเฟอร์ โดยรวมแล้ว เป็นการดีที่สุดที่ จะไม่ใช้สำหรับการโหลดหน้าเว็บทั่วไป เว้นแต่คุณจะรู้ จริงๆ ว่าคุณกำลังทำอะไรอยู่ และถึงกระนั้นก็อาจเป็นการปรับให้เหมาะสมระดับจุลภาค ฉันยังเชื่อว่าอาจมีที่ที่มี (REST) ​​API ได้ ซึ่งคุณสามารถพุชทรัพยากรย่อยที่ลิงก์ไปในการตอบกลับ (JSON) ในการเชื่อมต่อที่อุ่นเครื่องได้ สิ่งนี้เป็นจริงสำหรับทั้ง HTTP/2 และ HTTP/3

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

มันไม่สิ่งที่ทุกคนหมายถึงอะไร?

ทั้งหมดข้างต้นเป็นกฎง่ายๆ: ใช้คำแนะนำ HTTP/2 ทั่วไปส่วนใหญ่ที่คุณพบทางออนไลน์ แต่อย่าพาดพิงถึงขีดสุด

ต่อไปนี้คือประเด็นที่เป็นรูปธรรมบางส่วนซึ่งส่วนใหญ่มีไว้สำหรับทั้ง HTTP/2 และ HTTP/3:

1. ทรัพยากรชาร์ดผ่านการเชื่อมต่อประมาณหนึ่งถึงสามรายการบนเส้นทางวิกฤต (เว้นแต่ผู้ใช้ของคุณส่วนใหญ่จะอยู่บนเครือข่ายแบนด์วิดท์ต่ำ) โดยใช้การ preconnect และ dns-prefetch หากจำเป็น
2. รวมทรัพยากรย่อยตามตรรกะตามเส้นทางหรือคุณลักษณะ หรือตามความถี่การเปลี่ยนแปลง JavaScript ห้าถึงสิบและทรัพยากร CSS ห้าถึงสิบต่อหน้าน่าจะใช้ได้ Inlineing Critical CSS ยังคงเป็นการเพิ่มประสิทธิภาพที่ดี
3. ใช้คุณสมบัติที่ซับซ้อน เช่น preload เพียงเล็กน้อย
4. ใช้เซิร์ฟเวอร์ที่รองรับการจัดลำดับความสำคัญ HTTP/2 อย่างเหมาะสม สำหรับ HTTP/2 ฉันแนะนำ H2O Apache และ NGINX ส่วนใหญ่ใช้ได้ (แม้ว่าจะทำได้ดีกว่า) ในขณะที่ควรหลีกเลี่ยง Node.js สำหรับ HTTP/2 สำหรับ HTTP/3 สิ่งต่างๆ ไม่ชัดเจนในขณะนี้ (ดูด้านล่าง)
5. ตรวจสอบให้แน่ใจว่าได้เปิดใช้งาน TLS 1.3 บนเว็บเซิร์ฟเวอร์ HTTP/2 ของคุณ

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

เซิร์ฟเวอร์และเครือข่าย

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

สิ่งที่สำคัญและเสถียรที่สุด ได้แก่ :

อย่างไรก็ตาม การใช้งานเหล่านี้ส่วนใหญ่ (ส่วนใหญ่) จะดูแล HTTP/3 และ QUIC เป็นหลัก พวกมัน ไม่ใช่เว็บเซิร์ฟเวอร์ที่เต็มเปี่ยมด้วยตัวมันเอง เมื่อพูดถึงเซิร์ฟเวอร์ทั่วไปของคุณ (คิดว่า NGINX, Apache, Node.js) สิ่งต่างๆ จะช้าลงเล็กน้อย ด้วยเหตุผลหลายประการ ประการแรก นักพัฒนาบางส่วนของพวกเขาเกี่ยวข้องกับ HTTP/3 ตั้งแต่เริ่มต้น และตอนนี้พวกเขาต้องเล่นให้ทัน หลายคนข้ามสิ่งนี้โดยใช้หนึ่งในการใช้งานที่ระบุไว้ข้างต้นเป็นไลบรารีภายใน แต่การผสานรวมนั้นทำได้ยาก

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

รายชื่อบางส่วนของเว็บเซิร์ฟเวอร์ทั้งหมดที่คุณน่าจะใช้งานได้พร้อมๆ กับการรองรับ HTTP/3 ในปัจจุบันมีดังนี้:

• Apache
  การสนับสนุนไม่ชัดเจนในขณะนี้ ไม่มีอะไรได้รับการประกาศ มีแนวโน้มว่าจะต้องใช้ OpenSSL ด้วย (โปรดทราบว่ามีการใช้ Apache Traffic Server อยู่)
• NGINX
  นี่คือการใช้งานแบบกำหนดเอง นี่เป็นเรื่องใหม่และยังอยู่ในขั้นทดลองอย่างมาก คาดว่าจะรวมเข้ากับ mainline NGINX ภายในสิ้นปี 2564 ซึ่งค่อนข้างใหม่และยังมีการทดลองสูง โปรดทราบว่ามีโปรแกรมแก้ไขเพื่อเรียกใช้ไลบรารี quiche ของ Cloudflare บน NGINX ด้วยเช่นกัน ซึ่งตอนนี้น่าจะเสถียรกว่า
• Node.js
  สิ่งนี้ใช้ไลบรารี ngtcp2 ภายใน มันถูกบล็อกโดยความคืบหน้าของ OpenSSL แม้ว่าพวกเขาวางแผนที่จะเปลี่ยนไปใช้ส้อม QUIC-TLS เพื่อให้ทำงานได้เร็วกว่านี้
• IIS
  การสนับสนุนไม่ชัดเจนในขณะนี้ และยังไม่มีการประกาศใดๆ มีแนวโน้มว่าจะใช้ไลบรารี MsQuic ภายในแม้ว่า
• ไฮเปอร์คอร์น
  รวม aioquic ด้วยการสนับสนุนทดลอง
• แคดดี้
  สิ่งนี้ใช้ quic-go พร้อมการสนับสนุนอย่างเต็มที่
• H2O
  ใช้งานได้คล่องพร้อมการสนับสนุนอย่างเต็มที่
• Litespeed
  สิ่งนี้ใช้ LSQUIC พร้อมการสนับสนุนอย่างเต็มที่

สังเกตความแตกต่างที่สำคัญบางประการ:

• แม้แต่ "การสนับสนุนอย่างเต็มที่" ก็หมายถึง "ดีเท่าที่ได้รับในขณะนี้" ไม่จำเป็นต้อง "พร้อมสำหรับการผลิต" ตัวอย่างเช่น การใช้งานหลายอย่างยังไม่รองรับการย้ายการเชื่อมต่ออย่างสมบูรณ์, 0-RTT, การพุชของเซิร์ฟเวอร์ หรือการจัดลำดับความสำคัญ HTTP/3
• เซิร์ฟเวอร์อื่นที่ไม่อยู่ในรายการ เช่น Tomcat ยังไม่ได้ประกาศ (เท่าที่ทราบ)
• จากเว็บเซิร์ฟเวอร์ที่ระบุไว้ มีเพียง Litespeed, แพตช์ NGINX ของ Cloudflare และ H2O ที่สร้างขึ้นโดยผู้ที่เกี่ยวข้องอย่างใกล้ชิดในการกำหนดมาตรฐาน QUIC และ HTTP/3 ดังนั้นสิ่งเหล่านี้จึงน่าจะทำงานได้ดีที่สุดตั้งแต่แรกเริ่ม
  

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

การกำหนดค่าเครือข่าย

ตามที่อธิบายไว้ในตอนที่ 1 QUIC ทำงานบนโปรโตคอล UDP เพื่อให้ปรับใช้ได้ง่ายขึ้น อย่างไรก็ตาม ส่วนใหญ่หมายความว่าอุปกรณ์เครือข่ายส่วนใหญ่สามารถแยกวิเคราะห์และทำความเข้าใจ UDP ได้ น่าเศร้าที่ ไม่ได้หมายความว่า UDP ได้รับอนุญาตในระดับสากล เนื่องจาก UDP มักใช้สำหรับการโจมตีและไม่สำคัญต่อการทำงานประจำวันตามปกตินอกเหนือจาก DNS เครือข่าย (องค์กร) และไฟร์วอลล์จำนวนมากจึงบล็อกโปรโตคอลเกือบทั้งหมด ดังนั้น UDP จึงอาจต้องได้รับอนุญาตอย่างชัดเจนไปยัง/จากเซิร์ฟเวอร์ HTTP/3 ของคุณ QUIC สามารถทำงานบนพอร์ต UDP ใดก็ได้ แต่คาดว่าพอร์ต 443 (ซึ่งโดยทั่วไปจะใช้สำหรับ HTTPS ผ่าน TCP เช่นกัน) จะพบได้บ่อยที่สุด

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

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

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

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

ประการสุดท้าย ยังมีข้อควรพิจารณาด้านความปลอดภัยอื่นๆ ในระดับที่สูงกว่า ส่วนใหญ่เกี่ยวกับการโจมตี 0-RTT และการโจมตีแบบปฏิเสธการให้บริการ (DDoS) แบบกระจาย ตามที่กล่าวไว้ในส่วนที่ 2 QUIC ได้รวมการบรรเทาปัญหาเหล่านี้ไว้บ้างแล้ว แต่ในอุดมคติแล้ว พวกเขาจะใช้แนวป้องกันเพิ่มเติมในเครือข่ายด้วย ตัวอย่างเช่น พร็อกซีหรือเซิร์ฟเวอร์ Edge อาจบล็อกคำขอ 0-RTT บางรายการไม่ให้เข้าถึงส่วนหลังจริงเพื่อป้องกันการโจมตีซ้ำ อีกทางหนึ่ง เพื่อป้องกันการโจมตีแบบสะท้อนหรือการโจมตี DDoS ที่ส่งเฉพาะแพ็คเก็ต handshake แรกแล้วหยุดตอบกลับ (เรียกว่า SYN ฟลัดใน TCP) QUIC ได้รวมคุณลักษณะลองใหม่ ซึ่งช่วยให้เซิร์ฟเวอร์ตรวจสอบว่าเป็นไคลเอ็นต์ที่มีพฤติกรรมดี โดยไม่ต้องเก็บสถานะใดๆ ไว้ในระหว่างนี้ (เทียบเท่ากับคุกกี้ TCP SYN) แน่นอนว่ากระบวนการลองใหม่นี้จะเกิดขึ้นที่ใดที่หนึ่งก่อนเซิร์ฟเวอร์แบ็คเอนด์ ตัวอย่างเช่น ที่โหลดบาลานเซอร์ อีกครั้ง สิ่งนี้ต้องมีการกำหนดค่าและการสื่อสารเพิ่มเติมเพื่อตั้งค่า

นี่เป็นเพียงปัญหาที่เด่นชัดที่สุดที่ผู้ดูแลระบบเครือข่ายและผู้ดูแลระบบจะมีกับ QUIC และ HTTP/3 มีอีกหลายอย่าง บางเรื่องก็เคยพูดถึง นอกจากนี้ยังมีเอกสารประกอบแยกต่างหากสองฉบับสำหรับ QUIC RFCs ที่กล่าวถึงปัญหาเหล่านี้และการบรรเทา (บางส่วน) ที่เป็นไปได้

มันไม่สิ่งที่ทุกคนหมายถึงอะไร?

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

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

ดังนั้น โดยเฉพาะอย่างยิ่งในช่วงแรกๆ อาจเป็นการดีที่สุดที่จะ พึ่งพาบริษัทโฮสติ้งขนาดใหญ่หรือ CDN เพื่อตั้งค่าและกำหนดค่าโปรโตคอลสำหรับคุณ ดังที่กล่าวไว้ในตอนที่ 2 ที่ซึ่ง QUIC มักจะจ่ายออกไปอยู่แล้ว และการใช้ CDN เป็นหนึ่งในการปรับประสิทธิภาพการทำงานหลักที่คุณสามารถทำได้ โดยส่วนตัวแล้วฉันจะแนะนำให้ใช้ Cloudflare หรือ Fastly เพราะพวกเขามีส่วนเกี่ยวข้องอย่างใกล้ชิดในกระบวนการกำหนดมาตรฐานและจะมีการใช้งานขั้นสูงและปรับแต่งมาอย่างดี

ลูกค้าและ QUIC Discovery

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

ก่อนทำเรื่องนั้น เรามาเริ่มด้วยข่าวดีกันดีกว่า: เบราว์เซอร์ยอดนิยมส่วนใหญ่รองรับ HTTP/3 (ทดลองแล้ว) อยู่แล้ว! โดยเฉพาะในขณะที่เขียนนี่คือสถานะการสนับสนุน (ดูเพิ่มเติมที่ caniuse.com):

• Google Chrome (เวอร์ชัน 91+) : เปิดใช้งานโดยค่าเริ่มต้น
• Mozilla Firefox (เวอร์ชัน 89+) : เปิดใช้งานโดยค่าเริ่มต้น
• Microsoft Edge (เวอร์ชัน 90+) : เปิดใช้งานโดยค่าเริ่มต้น (ใช้ Chromium ภายใน)
• Opera (เวอร์ชัน 77+) : เปิดใช้งานโดยค่าเริ่มต้น (ใช้ Chromium ภายใน)
• Apple Safari (เวอร์ชัน 14) : ด้านหลังแฟล็กแมนนวล จะเปิดใช้งานตามค่าเริ่มต้นในเวอร์ชัน 15 ซึ่งขณะนี้อยู่ในตัวอย่างเทคโนโลยี
• เบราว์เซอร์อื่น : ยังไม่มีสัญญาณที่ฉันรู้ (แม้ว่าเบราว์เซอร์อื่นๆ ที่ใช้ Chromium ภายใน เช่น Brave ในทางทฤษฎี ก็สามารถเริ่มเปิดใช้งานได้เช่นกัน)

สังเกตความแตกต่างบางประการ:

• เบราว์เซอร์ส่วนใหญ่กำลังทยอยเปิดตัว โดยผู้ใช้บางรายอาจไม่ได้รับการสนับสนุน HTTP/3 ตามค่าเริ่มต้นตั้งแต่เริ่มต้น สิ่งนี้ทำเพื่อจำกัดความเสี่ยงที่บั๊กที่ถูกมองข้ามเพียงจุดเดียวอาจส่งผลกระทบต่อผู้ใช้จำนวนมาก หรือการทำให้เซิร์ฟเวอร์ใช้งานได้ทำงานหนักเกินไป ด้วยเหตุนี้ จึงมีโอกาสเล็กน้อยที่แม้ในเบราว์เซอร์เวอร์ชันล่าสุด คุณจะไม่ได้รับ HTTP/3 เป็นค่าเริ่มต้น และจะต้องเปิดใช้งานด้วยตนเอง
• เช่นเดียวกับเซิร์ฟเวอร์ การรองรับ HTTP/3 ไม่ได้หมายความว่าฟีเจอร์ทั้งหมดได้รับการใช้งานหรือกำลังใช้งานอยู่ในขณะนี้ โดยเฉพาะอย่างยิ่ง 0-RTT, การโยกย้ายการเชื่อมต่อ, การพุชของเซิร์ฟเวอร์, การบีบอัดส่วนหัว QPACK แบบไดนามิก และการจัดลำดับความสำคัญ HTTP/3 อาจยังคงขาดหายไป ปิดใช้งาน ใช้เพียงเล็กน้อย หรือกำหนดค่าได้ไม่ดี
• หากคุณต้องการใช้ HTTP/3 ฝั่งไคลเอ็นต์ภายนอกเบราว์เซอร์ (เช่น ในแอปที่มาพร้อมเครื่อง) คุณจะต้องผสานรวมหนึ่งในไลบรารีที่ระบุไว้ด้านบนหรือใช้ cURL เร็วๆ นี้ Apple จะนำการรองรับ HTTP/3 และ QUIC แบบเนทีฟมาสู่ไลบรารีเครือข่ายในตัวบน macOS และ iOS และ Microsoft กำลังเพิ่ม QUIC ให้กับเคอร์เนลของ Windows และสภาพแวดล้อม .NET ของพวกเขา แต่การสนับสนุนดั้งเดิมที่คล้ายคลึงกัน (เท่าที่ฉันรู้) ไม่เป็นเช่นนั้น ประกาศสำหรับระบบอื่นๆ เช่น Android

Alt-Svc

แม้ว่าคุณจะได้ตั้งค่าเซิร์ฟเวอร์ที่เข้ากันได้กับ HTTP/3 และใช้เบราว์เซอร์ที่อัปเดตแล้ว คุณอาจแปลกใจที่พบว่า HTTP/3 ไม่ได้ถูกใช้อย่างสม่ำเสมอ จริงๆ เพื่อให้เข้าใจเหตุผล สมมติว่าคุณเป็นเบราว์เซอร์อยู่ครู่หนึ่ง ผู้ใช้ของคุณขอให้คุณไปที่ example.com (เว็บไซต์ที่คุณไม่เคยเข้าชมมาก่อน) และคุณใช้ DNS เพื่อแก้ไขให้เป็น IP คุณส่งแพ็กเก็ตจับมือ QUIC อย่างน้อยหนึ่งชุดไปยัง IP นั้น ตอนนี้มีหลายอย่างที่อาจผิดพลาดได้:

1. เซิร์ฟเวอร์อาจไม่รองรับ QUIC
2. หนึ่งในเครือข่ายหรือไฟร์วอลล์ระดับกลางอาจบล็อก QUIC และ/หรือ UDP โดยสิ้นเชิง
3. ซองจับมืออาจสูญหายระหว่างการขนส่ง

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

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

ดังนั้น สำหรับ QUIC และ HTTP/3 เบราว์เซอร์จึงอยากเล่นอย่างปลอดภัยและ ลองใช้ QUIC ก็ต่อเมื่อรู้ว่าเซิร์ฟเวอร์รองรับ ดังนั้น ในครั้งแรกที่มีการติดต่อเซิร์ฟเวอร์ใหม่ เบราว์เซอร์จะใช้ HTTP/2 หรือ HTTP/1.1 ผ่านการเชื่อมต่อ TCP เท่านั้น เซิร์ฟเวอร์สามารถแจ้งให้เบราว์เซอร์ทราบว่ายังรองรับ HTTP/3 สำหรับการเชื่อมต่อในภายหลัง ทำได้โดยการตั้งค่าส่วนหัว HTTP พิเศษในการตอบกลับที่ส่งกลับผ่าน HTTP/2 หรือ HTTP/1.1 ส่วนหัวนี้เรียกว่า Alt-Svc ซึ่งย่อมาจาก “alternative services” สามารถใช้ Alt-Svc เพื่อให้เบราว์เซอร์ทราบว่าบริการบางอย่างสามารถเข้าถึงได้ผ่านเซิร์ฟเวอร์อื่น (IP และ/หรือพอร์ต) แต่ยังช่วยให้สามารถระบุโปรโตคอลอื่นได้ สามารถเห็นได้ด้านล่างใน รูปที่ 1

เมื่อได้รับส่วนหัว Alt-Svc ที่ถูกต้องซึ่งระบุการสนับสนุน HTTP/3 เบราว์เซอร์จะ แคช สิ่งนี้และพยายามตั้งค่าการเชื่อมต่อ QUIC ตั้งแต่นั้นมา ไคลเอนต์บางตัวจะทำสิ่งนี้โดยเร็วที่สุด (แม้ในระหว่างการโหลดหน้าแรก — ดูด้านล่าง) ในขณะที่บางตัวจะรอจนกว่าการเชื่อมต่อ TCP ที่มีอยู่จะถูกปิด ซึ่งหมายความว่าเบราว์เซอร์ จะใช้ HTTP/3 หลังจากดาวน์โหลดทรัพยากรอย่างน้อยสองสามรายการผ่าน HTTP/2 หรือ HTTP/1.1 ก่อน เท่านั้น ถึงอย่างนั้นก็แล่นไม่ราบรื่น ตอนนี้เบราว์เซอร์รู้ว่าเซิร์ฟเวอร์รองรับ HTTP/3 แต่นั่นไม่ได้หมายความว่าเครือข่ายระดับกลางจะไม่บล็อกมัน ในทางปฏิบัติยังคงจำเป็นต้องมีการแข่งการเชื่อมต่อ ดังนั้น คุณอาจยังลงเอยด้วย HTTP/2 หากเครือข่ายหน่วงเวลาการจับมือ QUIC ให้เพียงพอ นอกจากนี้ หากการเชื่อมต่อ QUIC ไม่สามารถสร้างได้สองสามครั้งติดต่อกัน เบราว์เซอร์บางตัวจะใส่รายการแคช Alt-Svc ในรายการปฏิเสธในบางครั้ง โดยไม่ได้ลองใช้ HTTP/3 สักระยะ ดังนั้น การล้างแคชของเบราว์เซอร์ด้วยตนเองอาจเป็นประโยชน์หากเกิดปัญหาขึ้น เพราะนั่นควรล้างการเชื่อมโยง Alt-Svc ด้วย ในที่สุด Alt-Svc ก็แสดงให้เห็นว่ามีความเสี่ยงด้านความปลอดภัยที่ร้ายแรง ด้วยเหตุนี้ บางเบราว์เซอร์จึงมีข้อจำกัดเพิ่มเติม เช่น พอร์ตใดบ้างที่สามารถใช้ได้ (ใน Chrome เซิร์ฟเวอร์ HTTP/2 และ HTTP/3 ของคุณจะต้องอยู่บนพอร์ตที่ต่ำกว่า 1024 หรือทั้งคู่บนพอร์ตที่สูงกว่าหรือเท่ากับ ถึง 1024 มิฉะนั้น Alt-Svc จะถูกละเว้น) ตรรกะทั้งหมดนี้แตกต่างกันไปและพัฒนาอย่างดุเดือดระหว่างเบราว์เซอร์ ซึ่งหมายความว่า การเชื่อมต่อ HTTP/3 ที่สอดคล้องกันอาจเป็นเรื่องยาก ซึ่งทำให้การทดสอบการตั้งค่าใหม่ทำได้ยาก

มีงานอย่างต่อเนื่องในการปรับปรุงกระบวนการ Alt-Svc สองขั้นตอนนี้บ้าง แนวคิดคือการใช้ระเบียน DNS ใหม่ที่เรียกว่า SVCB และ HTTPS ซึ่งจะมีข้อมูลที่คล้ายกับที่อยู่ใน Alt-Svc ด้วยเหตุนี้ ไคลเอ็นต์จึงสามารถค้นพบว่าเซิร์ฟเวอร์สนับสนุน HTTP/3 ในระหว่างขั้นตอนการแก้ปัญหา DNS แทน ซึ่งหมายความว่าสามารถลองใช้ QUIC ได้จากการโหลดหน้าแรก แทนที่จะต้องผ่าน HTTP/2 หรือ HTTP/1.1 ก่อน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับสิ่งนี้และ Alt-Svc ดูบท Web Almanac ของปีที่แล้วใน HTTP/2

อย่างที่คุณเห็น Alt-Svc และกระบวนการค้นพบ HTTP/3 ช่วยเพิ่มความซับซ้อนให้กับการปรับใช้เซิร์ฟเวอร์ QUIC ที่ท้าทายอยู่แล้ว เนื่องจาก:

• คุณจะต้องปรับใช้เซิร์ฟเวอร์ HTTP/3 ข้างเซิร์ฟเวอร์ HTTP/2 และ/หรือ HTTP/1.1 เสมอ
• คุณจะต้องกำหนดค่าเซิร์ฟเวอร์ HTTP/2 และ HTTP/1.1 เพื่อตั้งค่าส่วนหัว Alt-Svc ที่ถูกต้องในการตอบกลับ

แม้ว่าสิ่งนี้ควรสามารถจัดการได้ในการตั้งค่าระดับการใช้งานจริง (เพราะเช่น อินสแตนซ์ Apache หรือ NGINX เดียวมีแนวโน้มว่าจะรองรับ HTTP ทั้งสามเวอร์ชันพร้อมกัน) แต่ชุด ทดสอบ (ในเครื่อง) อาจสร้างความรำคาญใจกว่ามาก ups (ฉันเห็นแล้วว่าตัวเองลืมเพิ่มส่วนหัว Alt-Svc หรือทำให้ยุ่งเหยิง) ปัญหานี้เกิดจาก (ปัจจุบัน) ไม่มีบันทึกข้อผิดพลาดของเบราว์เซอร์และตัวบ่งชี้ DevTools ซึ่งหมายความว่าการค้นหาสาเหตุที่การตั้งค่าไม่ทำงานอย่างแท้จริงอาจเป็นเรื่องยาก

ปัญหาเพิ่มเติม

ราวกับว่ายังไม่เพียงพอ ปัญหาอื่นจะทำให้การทดสอบในพื้นที่ยากขึ้น: Chrome ทำให้คุณใช้ใบรับรอง TLS ที่ลงชื่อด้วยตนเองสำหรับ QUIC ได้ยากมาก เนื่องจากบริษัทมักใช้ใบรับรอง TLS ที่ไม่เป็นทางการเพื่อถอดรหัสการรับส่งข้อมูล TLS ของพนักงาน (เช่น ให้ไฟร์วอลล์สแกนภายในการรับส่งข้อมูลที่เข้ารหัส) อย่างไรก็ตาม หากบริษัทต่างๆ จะเริ่มทำเช่นนั้นด้วย QUIC เราก็จะมีการใช้งานมิดเดิลบ็อกซ์แบบกำหนดเองอีกครั้งซึ่งสร้างสมมติฐานของตนเองเกี่ยวกับโปรโตคอล ซึ่งอาจนำไปสู่การทำลายการสนับสนุนโปรโตคอลในอนาคต ซึ่งเป็นสิ่งที่เราพยายามป้องกันโดยการเข้ารหัส QUIC อย่างกว้างขวางตั้งแต่แรก! As such, Chrome takes a very opinionated stance on this: If you're not using an official TLS certificate (signed by a certificate authority or root certificate that is trusted by Chrome, such as Let's Encrypt), then you cannot use QUIC . This, sadly, also includes self-signed certificates, which are often used for local test set-ups.

It is still possible to bypass this with some freaky command-line flags (because the common --ignore-certificate-errors doesn't work for QUIC yet), by using per-developer certificates (although setting this up can be tedious), or by setting up the real certificate on your development PC (but this is rarely an option for big teams because you would have to share the certificate's private key with each developer). Finally, while you can install a custom root certificate, you would then also need to pass both the --origin-to-force-quic-on and --ignore-certificate-errors-spki-list flags when starting Chrome (see below). Luckily, for now, only Chrome is being so strict, and hopefully, its developers will loosen their approach over time.

If you are having problems with your QUIC set-up from inside a browser, it's best to first validate it using a tool such as cURL. cURL has excellent HTTP/3 support (you can even choose between two different underlying libraries) and also makes it easier to observe Alt-Svc caching logic.

มันไม่สิ่งที่ทุกคนหมายถึงอะไร?

Next to the challenges involved with setting up HTTP/3 and QUIC on the server-side, there are also difficulties in getting browsers to use the new protocols consistently. This is due to a two-step discovery process involving the Alt-Svc HTTP header and the fact that HTTP/2 connections cannot simply be “upgraded” to HTTP/3, because the latter uses UDP.

Even if a server supports HTTP/3, however, clients (and website owners!) need to deal with the fact that intermediate networks might block UDP and/or QUIC traffic. As such, HTTP/3 will never completely replace HTTP/2 . In practice, keeping a well-tuned HTTP/2 set-up will remain necessary both for first-time visitors and visitors on non-permissive networks. Luckily, as we discussed, there shouldn't be many page-level changes between HTTP/2 and HTTP/3, so this shouldn't be a major headache.

What could become a problem, however, is testing and verifying whether you are using the correct configuration and whether the protocols are being used as expected. This is true in production, but especially in local set-ups. As such, I expect that most people will continue to run HTTP/2 (or even HTTP/1.1) development servers , switching only to HTTP/3 in a later deployment stage. Even then, however, validating protocol performance with the current generation of tools won't be easy.

Tools and Testing

As was the case with many major servers, the makers of the most popular web performance testing tools have not been keeping up with HTTP/3 from the start. Consequently, few tools have dedicated support for the new protocol as of July 2021, although they support it to a certain degree.

Google Lighthouse

First, there is the Google Lighthouse tool suite. While this is an amazing tool for web performance in general, I have always found it somewhat lacking in aspects of protocol performance. This is mostly because it simulates slow networks in a relatively unrealistic way, in the browser (the same way that Chrome's DevTools handle this). While this approach is quite usable and typically “good enough” to get an idea of the impact of a slow network, testing low-level protocol differences is not realistic enough. Because the browser doesn't have direct access to the TCP stack, it still downloads the page on your normal network, and it then artificially delays the data from reaching the necessary browser logic. This means, for example, that Lighthouse emulates only delay and bandwidth, but not packet loss (which, as we've seen, is a major point where HTTP/3 could potentially differ from HTTP/2). Alternatively, Lighthouse uses a highly advanced simulation model to guesstimate the real network impact, because, for example, Google Chrome has some complex logic that tweaks several aspects of a page load if it detects a slow network. This model has, to the best of my knowledge, not been adjusted to handle IETF QUIC or HTTP/3 yet. As such, if you use Lighthouse today for the sole purpose of comparing HTTP/2 and HTTP/3 performance, then you are likely to get erroneous or oversimplified results, which could lead you to wrong conclusions about what HTTP/3 can do for your website in practice. The silver lining is that, in theory, this can be improved massively in the future, because the browser does have full access to the QUIC stack, and thus Lighthouse could add much more advanced simulations (including packet loss!) for HTTP/3 down the line. For now, though, while Lighthouse can, in theory, load pages over HTTP/3, I would recommend against it.

WebPageTest

Secondly, there is WebPageTest. This amazing project lets you load pages over real networks from real devices across the world, and it also allows you to add packet-level network emulation on top, including aspects such as packet loss! As such, WebPageTest is conceptually in a prime position to be used to compare HTTP/2 and HTTP/3 performance. However, while it can indeed already load pages over the new protocol, HTTP/3 has not yet been properly integrated into the tooling or visualizations . For example, there are currently no easy ways to force a page load over QUIC, to easily view how Alt-Svc was actually used, or even to see QUIC handshake details. In some cases, even seeing whether a response used HTTP/3 or HTTP/2 can be challenging. Still, in April, I was able to use WebPageTest to run quite a few tests on facebook.com and see HTTP/3 in action, which I'll go over now.

First, I ran a default test for facebook.com , enabling the “repeat view” option. As explained above, I would expect the first page load to use HTTP/2, which will include the Alt-Svc response header. As such, the repeat view should use HTTP/3 from the start. In Firefox version 89, this is more or less what happens. However, when looking at individual responses, we see that even during the first page load, Firefox will switch to using HTTP/3 instead of HTTP/2 ! As you can see in figure 2, this happens from the 20th resource onwards. This means that Firefox establishes a new QUIC connection as soon as it sees the Alt-Svc header, and it switches to it once it succeeds. If you scroll down to the connection view, it also seems to show that Firefox even opened two QUIC connections: one for credentialed CORS requests and one for no-CORS requests. This would be expected because, as we discussed above, even for HTTP/2 and HTTP/3, browsers will open multiple connections due to security concerns. However, because WebPageTest doesn't provide more details in this view, it's difficult to confirm without manually digging through the data. Looking at the repeat view (second visit), it starts by directly using HTTP/3 for the first request, as expected.

Next, for Chrome, we see similar behavior for the first page load, although here Chrome already switches on the 10th resource, much earlier than Firefox. It's a bit more unclear here whether it switches as soon as possible or only when a new connection is needed (for example, for requests with different credentials), because, unlike for Firefox, the connection view also doesn't seem to show multiple QUIC connections. For the repeat view, we see some weirder things. Unexpectedly, Chrome starts off using HTTP/2 there as well , switching to HTTP/3 only after a few requests! I performed a few more tests on other pages as well, to confirm that this is indeed consistent behaviour. This could be due to several things: It might just be Chrome's current policy, it might be that Chrome “raced” a TCP and QUIC connection and TCP won initially, or it might be that the Alt-Svc cache from the first view was unused for some reason. At this point, there is, sadly, no easy way to determine what the problem really is (and whether it can even be fixed).

Another interesting thing I noticed here is the apparent connection coalescing behavior. As discussed above, both HTTP/2 and HTTP/3 can reuse connections even if they go to other hostnames, to prevent downsides from hostname sharding. However, as shown in figure 3, WebPageTest reports that, for this Facebook load, connection coalescing is used over HTTP/3 for facebook.com and fbcdn.net , but not over HTTP/2 (as Chrome opens a secondary connection for the second domain). I suspect this is a bug in WebPageTest, however, because facebook.com and fbcnd.net resolve to different IPs and, as such, can't really be coalesced.

The figure also shows that some key QUIC handshake information is missing from the current WebPageTest visualization.

Note : As we see, getting “real” HTTP/3 going can be difficult sometimes. Luckily, for Chrome specifically, we have additional options we can use to test QUIC and HTTP/3, in the form of command-line parameters.

On the bottom of WebPageTest's “Chromium” tab, I used the following command-line options:

 --enable-quic --quic-version=h3-29 --origin-to-force-quic-on=www.facebook.com:443,static.xx.fbcdn.net:443

The results from this test show that this indeed forces a QUIC connection from the start, even in the first view, thus bypassing the Alt-Svc process. Interestingly, you will notice I had to pass two hostnames to --origin-to-force-quic-on . In the version where I didn't, Chrome, of course, still first opened an HTTP/2 connection to the fbcnd.net domain, even in the repeat view. As such, you'll need to manually indicate all QUIC origins in order for this to work !

We can see even from these few examples that a lot of stuff is going on with how browsers actually use HTTP/3 in practice. It seems they even switch to the new protocol during the initial page load, abandoning HTTP/2 either as soon as possible or when a new connection is needed. As such, it's difficult not only getting a full HTTP/3 load, but also getting a pure HTTP/2 load on a set-up that supports both ! Because WebPageTest doesn't show much HTTP/3 or QUIC metadata yet, figuring out what's going on can be challenging, and you can't trust the tools and visualizations at face value either.

So, if you use WebPageTest, you'll need to double-check the results to make sure which protocols were actually used. Consequently, I think this means that it's too early to really test HTTP/3 performance at this time (and especially too early to compare it to HTTP/2). This belief is strengthened by the fact that not all servers and clients have implemented all protocol features yet. Due to the fact that WebPageTest doesn't yet have easy ways of showing whether advanced aspects such as 0-RTT were used, it will be tricky to know what you're actually measuring. This is especially true for the HTTP/3 prioritization feature, which isn't implemented properly in all browsers yet and which many servers also lack full support for. Because prioritization can be a major aspect driving web performance, it would be unfair to compare HTTP/3 to HTTP/2 without making sure that at least this feature works properly (for both protocols!). This is just one aspect, though, as my research shows how big the differences between QUIC implementations can be. If you do any comparison of this sort yourself (or if you read articles that do), make 100% sure that you've checked what's actually going on .

Finally, also note that other higher-level tools (or data sets such as the amazing HTTP Archive) are often based on WebPageTest or Lighthouse (or use similar methods), so I suspect that most of my comments here will be widely applicable to most web performance tooling. Even for those tool vendors announcing HTTP/3 support in the coming months, I would be a bit skeptical and would validate that they're actually doing it correctly. For some tools, things are probably even worse, though; for example, Google's PageSpeed Insights only got HTTP/2 support this year, so I wouldn't wait for HTTP/3 arriving anytime soon.

Wireshark, qlog และ qvis

จากการสนทนาข้างต้นแสดงให้เห็นว่า การวิเคราะห์พฤติกรรม HTTP/3 โดยใช้ Lighthouse หรือ WebPageTest เพียงอย่างเดียวอาจเป็นเรื่องยาก โชคดีที่มีเครื่องมือระดับล่างอื่นๆ ที่ช่วยในเรื่องนี้ อย่างแรก เครื่องมือ Wireshark ที่ยอดเยี่ยมมีการรองรับ QUIC ขั้นสูง และสามารถผ่า HTTP/3 ในการทดลองได้เช่นกัน วิธีนี้ช่วยให้คุณสังเกตได้ว่าแพ็กเก็ต QUIC และ HTTP/3 ใดที่ส่งผ่านสายจริง อย่างไรก็ตาม เพื่อให้ใช้งานได้ คุณต้องได้รับคีย์ถอดรหัส TLS สำหรับการเชื่อมต่อที่กำหนด ซึ่งการใช้งานส่วนใหญ่ (รวมถึง Chrome และ Firefox) อนุญาตให้คุณแยกข้อมูลโดยใช้ตัวแปรสภาพแวดล้อม SSLKEYLOGFILE แม้ว่าสิ่งนี้จะมีประโยชน์สำหรับบางสิ่ง แต่การค้นหาจริงๆ ว่าเกิดอะไรขึ้น โดยเฉพาะอย่างยิ่งสำหรับการเชื่อมต่อที่ยาวขึ้น อาจนำมาซึ่งการทำงานด้วยตนเองจำนวนมาก คุณจะต้องมีความเข้าใจขั้นสูงเกี่ยวกับการทำงานภายในของโปรโตคอล

โชคดีที่มีตัวเลือกที่สองคือ qlog และ qvis qlog เป็นรูปแบบการบันทึกที่ใช้ JSON โดยเฉพาะสำหรับ QUIC และ HTTP/3 ที่ได้รับการสนับสนุนโดยการใช้งาน QUIC ส่วนใหญ่ แทนที่จะดูแพ็กเก็ตที่ส่งผ่านสาย qlog จะรวบรวมข้อมูลนี้บนไคลเอนต์และเซิร์ฟเวอร์โดยตรง ซึ่งช่วยให้รวมข้อมูลเพิ่มเติมบางอย่างได้ (เช่น รายละเอียดการควบคุมความแออัด) โดยทั่วไป คุณสามารถทริกเกอร์เอาต์พุต qlog เมื่อเริ่มต้นเซิร์ฟเวอร์และไคลเอ็นต์ด้วยตัวแปรสภาพแวดล้อม QLOGDIR (โปรดทราบว่าใน Firefox คุณต้องตั้งค่าการตั้งค่า network.http.http3.enable_qlog อุปกรณ์ Apple และ Safari ใช้ QUIC_LOG_DIRECTORY แทน Chrome ยังไม่รองรับ qlog)

ไฟล์ qlog เหล่านี้สามารถอัปโหลดไปยังชุดเครื่องมือ qvis ได้ที่ qvis.quictools.info ที่นั่น คุณจะได้รับ การแสดงภาพเชิงโต้ตอบขั้นสูงจำนวนหนึ่งที่ช่วยให้ตีความการรับส่งข้อมูล QUIC และ HTTP/3 ได้ง่ายขึ้น qvis ยังรองรับการอัปโหลดการดักจับแพ็กเก็ต Wireshark (ไฟล์ .pcap ) และมีการทดลองรองรับไฟล์ netlog ของ Chrome ดังนั้นคุณจึงสามารถวิเคราะห์พฤติกรรมของ Chrome ได้ กวดวิชาเต็มรูปแบบเกี่ยวกับ qlog และ qvis อยู่นอกเหนือขอบเขตของบทความนี้ แต่รายละเอียดเพิ่มเติมสามารถพบได้ในแบบฟอร์มการสอน เป็นกระดาษ หรือแม้แต่ในรูปแบบทอล์คโชว์ คุณสามารถถามฉันเกี่ยวกับพวกเขาได้โดยตรงเพราะฉันเป็นผู้ดำเนินการหลักของ qlog และ qvis ;)

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

มันไม่สิ่งที่ทุกคนหมายถึงอะไร?

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

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

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

บทสรุปและประเด็นสำคัญ

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

สรุป

ประการแรก ในส่วนที่ 1 เราได้พูดคุยกันว่า HTTP/3 มีความจำเป็นเนื่องจากโปรโตคอลการขนส่ง QUIC พื้นฐานใหม่เป็นหลัก QUIC เป็นผู้สืบทอดทางจิตวิญญาณของ TCP และรวมเอาแนวปฏิบัติที่ดีที่สุดทั้งหมดรวมทั้ง TLS 1.3 สิ่งนี้จำเป็นอย่างยิ่งเนื่องจาก TCP เนื่องจากการปรับใช้และการรวมที่แพร่หลายในมิดเดิลบ็อกซ์นั้นไม่ยืดหยุ่นเกินไปที่จะพัฒนา การใช้ UDP ของ QUIC และการเข้ารหัสเกือบเต็มรูปแบบหมายความว่าเรา (หวังว่า) จะต้องอัปเดตปลายทางเท่านั้นในอนาคตเพื่อเพิ่มคุณสมบัติใหม่ ซึ่งน่าจะง่ายกว่า อย่างไรก็ตาม QUIC ยังเพิ่มความสามารถใหม่ที่น่าสนใจอีกด้วย ประการแรก การขนส่งและการจับมือแบบเข้ารหัสของ QUIC นั้นเร็วกว่า TCP + TLS และสามารถใช้คุณลักษณะ 0-RTT ให้เกิดประโยชน์ได้ ประการที่สอง QUIC ทราบดีว่ามีการสตรีมไบต์อิสระหลายรายการและสามารถจัดการความสูญเสียและความล่าช้าได้อย่างชาญฉลาดยิ่งขึ้น บรรเทาปัญหาการบล็อกบรรทัดแรก ประการที่สาม การเชื่อมต่อ QUIC สามารถอยู่รอดของผู้ใช้ที่ย้ายไปยังเครือข่ายอื่น (เรียกว่าการย้ายการเชื่อมต่อ) โดยการแท็กแต่ละแพ็กเก็ตด้วย ID การเชื่อมต่อ ในที่สุด โครงสร้างแพ็กเก็ตที่ยืดหยุ่นของ QUIC (การนำเฟรมไปใช้) ทำให้มีประสิทธิภาพมากขึ้น แต่ยังมีความยืดหยุ่นและขยายได้มากขึ้นในอนาคต โดยสรุป เป็นที่ชัดเจนว่า QUIC เป็นโปรโตคอลการขนส่งยุคหน้า และจะมีการใช้และขยายเวลาไปอีกหลายปี

ประการที่สอง ในส่วนที่ 2 เราได้ พิจารณาคุณลักษณะใหม่เหล่านี้อย่างมีวิจารณญาณเล็กน้อย โดยเฉพาะอย่างยิ่งผลกระทบด้านประสิทธิภาพ อย่างแรก เราเห็นว่าการใช้ UDP ของ QUIC ไม่ได้ทำให้เร็วขึ้นอย่างน่าอัศจรรย์ (หรือช้ากว่านั้น) เพราะ QUIC ใช้กลไกการควบคุมความแออัดที่คล้ายกับ TCP มากเพื่อป้องกันการโอเวอร์โหลดเครือข่าย ประการที่สอง การจับมือกันที่เร็วขึ้นและ 0-RTT นั้นเป็นการเพิ่มประสิทธิภาพระดับไมโครมากกว่า เพราะพวกเขาเดินทางไปกลับเร็วกว่าสแต็ก TCP + TLS ที่ปรับให้เหมาะสมเพียงรอบเดียว และ 0-RTT จริงของ QUIC ได้รับผลกระทบเพิ่มเติมจากข้อกังวลด้านความปลอดภัยต่างๆ ที่อาจจำกัด ประโยชน์ของมัน ประการที่สาม การย้ายข้อมูลการเชื่อมต่อมีความจำเป็นเฉพาะในบางกรณีเท่านั้น และยังคงหมายถึงการรีเซ็ตอัตราการส่ง เนื่องจากการควบคุมความแออัดไม่ทราบว่าเครือข่ายใหม่สามารถจัดการข้อมูลได้มากเพียงใด ประการที่สี่ ประสิทธิภาพของการลบการบล็อกบรรทัดแรกของ QUIC นั้นขึ้นอยู่กับว่าสตรีมข้อมูลถูกมัลติเพล็กซ์และจัดลำดับความสำคัญอย่างไร แนวทางที่เหมาะสมที่สุดในการกู้คืนจากการสูญเสียแพ็กเก็ตดูเหมือนจะส่งผลเสียต่อกรณีการใช้งานทั่วไปของประสิทธิภาพการโหลดหน้าเว็บและในทางกลับกัน แม้ว่าจำเป็นต้องมีการวิจัยเพิ่มเติม ประการที่ห้า QUIC อาจช้ากว่าการส่งแพ็กเก็ตได้ช้ากว่า TCP + TLS เนื่องจาก UDP API มีอายุน้อยกว่า และ QUIC จะเข้ารหัสแต่ละแพ็กเก็ตแยกกัน แม้ว่าจะบรรเทาลงได้มากก็ตาม ประการที่หก HTTP/3 เองไม่ได้นำคุณลักษณะประสิทธิภาพใหม่ที่สำคัญมาสู่ตาราง แต่หลักๆ แล้ว การทำงานใหม่และทำให้ภายในของคุณลักษณะ HTTP/2 ที่รู้จักง่ายขึ้น สุดท้าย คุณลักษณะที่เกี่ยวข้องกับประสิทธิภาพที่น่าตื่นเต้นที่สุดบางอย่างที่ QUIC อนุญาต (หลายเส้นทาง ข้อมูลไม่น่าเชื่อถือ WebTransport การแก้ไขข้อผิดพลาดในการส่งต่อ ฯลฯ) ไม่ได้เป็นส่วนหนึ่งของมาตรฐานหลักของ QUIC และ HTTP/3 แต่เป็นส่วนขยายที่เสนอที่จะใช้ มีเวลาอีกพอสมควร โดยสรุป นี่หมายความว่า QUIC อาจไม่ปรับปรุงประสิทธิภาพมากนักสำหรับผู้ใช้ในเครือข่ายความเร็วสูง แต่จะมีความสำคัญกับผู้ใช้ในเครือข่ายที่ช้าและเสถียรน้อยกว่าเป็น หลัก

สุดท้ายนี้ ในส่วนที่ 3 เรามาดู วิธีใช้และปรับใช้ QUIC และ HTTP/3 ในทางปฏิบัติ อันดับแรก เราเห็นว่าแนวทางปฏิบัติที่ดีที่สุดและบทเรียนส่วนใหญ่ที่เรียนรู้จาก HTTP/2 ควรส่งต่อไปยัง HTTP/3 ไม่จำเป็นต้องเปลี่ยนกลยุทธ์การรวมกลุ่มหรือการรวมกลุ่ม หรือการรวมหรือแยกส่วนข้อมูลฟาร์มเซิร์ฟเวอร์ของคุณ การพุชของเซิร์ฟเวอร์ยังไม่ใช่คุณสมบัติที่ดีที่สุดในการใช้งาน และการ preload อาจเป็นปืนลูกซองที่ทรงพลังในทำนองเดียวกัน ประการที่สอง เราได้พูดคุยกันว่าอาจต้องใช้เวลาสักระยะก่อนที่แพ็คเกจเว็บเซิร์ฟเวอร์แบบออฟไลน์จะรองรับ HTTP/3 เต็มรูปแบบ (ส่วนหนึ่งเนื่องมาจากปัญหาการรองรับไลบรารี TLS) แม้ว่าจะมีตัวเลือกโอเพนซอร์สมากมายสำหรับผู้เริ่มใช้งานและ CDN รายใหญ่หลายแห่งมีข้อเสนอที่ครบกำหนด ประการที่สาม เป็นที่ชัดเจนว่าเบราว์เซอร์หลักส่วนใหญ่มีการรองรับ (พื้นฐาน) HTTP/3 แม้ว่าจะเปิดใช้งานตามค่าเริ่มต้นก็ตาม มีความแตกต่างที่สำคัญในวิธีการใช้ HTTP/3 และคุณลักษณะใหม่เมื่อใดและเมื่อใด ดังนั้นการทำความเข้าใจพฤติกรรมของพวกเขาจึงเป็นสิ่งที่ท้าทาย ประการที่สี่ เราได้พูดคุยกันแล้วว่ามันแย่ลงเพราะขาดการสนับสนุน HTTP/3 อย่างชัดแจ้งในเครื่องมือยอดนิยม เช่น Lighthouse และ WebPageTest ทำให้ยากเป็นพิเศษในการเปรียบเทียบประสิทธิภาพ HTTP/3 กับ HTTP/2 และ HTTP/1.1 ในขณะนี้ โดยสรุป HTTP/3 และ QUIC อาจยัง ไม่ พร้อมสำหรับช่วงไพรม์ไทม์ แต่อีกไม่นานก็จะเป็น .

คำแนะนำ

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

อย่างแรก ตามที่กล่าวไว้ในตอนท้ายของส่วนที่ 2 แม้ว่าผู้ใช้ "โดยเฉลี่ย" ของคุณอาจไม่พบประสิทธิภาพ ที่ เพิ่มขึ้นมากนัก (ขึ้นอยู่กับตลาดเป้าหมายของคุณ) ผู้ชมส่วนใหญ่ของคุณน่า จะ เห็นการปรับปรุงที่น่าประทับใจ 0-RTT อาจบันทึกการเดินทางไปกลับเพียงครั้งเดียว แต่ก็ยังสามารถหมายถึงหลายร้อยมิลลิวินาทีสำหรับผู้ใช้บางคน การโยกย้ายการเชื่อมต่ออาจไม่รองรับการดาวน์โหลดที่รวดเร็วอย่างสม่ำเสมอ แต่จะช่วยให้ผู้ที่พยายามดึง PDF นั้นบนรถไฟความเร็วสูงได้อย่างแน่นอน แพ็กเก็ตสูญหายบนสายเคเบิลอาจระเบิดได้ แต่ลิงก์ไร้สายอาจได้ประโยชน์มากกว่าจากการลบการบล็อกแบบ head-of-line ของ QUIC ยิ่งไปกว่านั้น ผู้ใช้เหล่านี้คือผู้ที่มักจะพบกับประสิทธิภาพ ที่แย่ที่สุด ของผลิตภัณฑ์ของคุณ และด้วยเหตุนี้ ผู้ใช้เหล่านี้จึงได้รับผลกระทบมากที่สุด หากคุณสงสัยว่าเหตุใดจึงสำคัญ โปรดอ่านเกร็ดเล็กเกร็ดน้อยเกี่ยวกับประสิทธิภาพของเว็บที่มีชื่อเสียงของ Chris Zacharias

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

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

อ่านเพิ่มเติม

แม้ว่าข้อความนี้จะมีความยาว แต่น่าเศร้าที่จริง ๆ แล้วเป็นเพียงรอยขีดข่วนพื้นผิวทางเทคนิคของโปรโตคอลที่ซับซ้อนที่ QUIC และ HTTP/3 เป็น

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

• “คำอธิบาย HTTP/3” แดเนียล สเตนเบิร์ก
  e-book เล่มนี้โดยผู้สร้าง cURL สรุปโปรโตคอล
• “การใช้งาน HTTP/2” แบร์รี พอลลาร์ด
  หนังสือรอบด้านที่ยอดเยี่ยมเล่มนี้เกี่ยวกับ HTTP/2 มีคำแนะนำเกี่ยวกับการใช้ซ้ำและหัวข้อเกี่ยวกับ HTTP/3
• @programmingart ทวิตเตอร์
  ทวีตของฉันส่วนใหญ่ทุ่มเทให้กับ QUIC, HTTP/3 และประสิทธิภาพเว็บ (รวมถึงข่าว) โดยทั่วไป ดูตัวอย่างกระทู้ล่าสุดของฉันเกี่ยวกับคุณสมบัติ QUIC
• “YouTube” โรบิน มาร์กซ์
  การพูดคุยเชิงลึกมากกว่า 10 ครั้งของฉันครอบคลุมแง่มุมต่างๆ ของโปรโตคอล
• “บล็อก Cloudlare”
  นี่คือผลิตภัณฑ์หลักของบริษัทที่รัน CDN ที่ด้านข้างด้วย
• “บล็อกอย่างรวดเร็ว”
  บล็อกนี้มีการอภิปรายที่ยอดเยี่ยมในด้านเทคนิค ซึ่งฝังอยู่ในบริบทที่กว้างขึ้น
• QUIC RFC ที่แท้จริง
  คุณจะพบลิงก์ไปยังเอกสาร IETF QUIC และ HTTP/3 RFC และส่วนขยายที่เป็นทางการอื่นๆ
• บล็อกของวิศวกร IIJ: คำอธิบายทางเทคนิคเชิงลึกที่ยอดเยี่ยมของรายละเอียดคุณสมบัติ QUIC
• เอกสารวิชาการ HTTP/3 และ QUIC, Robin Marx
  เอกสารการวิจัยของฉันครอบคลุมถึงการสตรีมมัลติเพล็กซ์และการจัดลำดับความสำคัญ เครื่องมือ และความแตกต่างในการใช้งาน
• QUIPS, EPIQ 2018 และ EPIQ 2020
  เอกสารเหล่านี้จากการประชุมเชิงปฏิบัติการทางวิชาการประกอบด้วยการวิจัยเชิงลึกเกี่ยวกับความปลอดภัย ประสิทธิภาพ และส่วนขยายของโปรโตคอล

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