การทำงานของโปรโตคอล QUIC: Uber นำไปใช้อย่างไรเพื่อเพิ่มประสิทธิภาพ

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

รูปภาพสามารถคลิกได้ สนุกกับการอ่าน!

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

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

หลังจากการทดสอบอย่างละเอียด เราสรุปได้ว่าการใช้ QUIC ในแอปพลิเคชันของเราจะส่งผลให้เวลาแฝงลดลงเมื่อเทียบกับ TCP เราสังเกตเห็นการลดลงในช่วง 10-30% สำหรับการรับส่งข้อมูล HTTPS ในแอปพลิเคชันไดรเวอร์และผู้โดยสาร QUIC ยังให้เราควบคุมแพ็คเกจผู้ใช้แบบครบวงจรอีกด้วย

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

เทคโนโลยีล่าสุด: TCP

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

ผู้ใช้ส่วนใหญ่ใช้แอปของเราทุกที่ทุกเวลา และเวลาแฝงของ TCP Tail นั้นไม่ใกล้เคียงกับความต้องการของการรับส่งข้อมูล HTTPS แบบเรียลไทม์ของเราเลย พูดง่ายๆ ก็คือ ผู้ใช้ทั่วโลกประสบปัญหานี้ - รูปที่ 1 แสดงความล่าช้าในเมืองใหญ่ ๆ:

รูปที่ 1: เวลาในการตอบสนองจะแตกต่างกันไปตามเมืองหลักของ Uber

แม้ว่าเวลาแฝงในเครือข่ายอินเดียและบราซิลจะสูงกว่าในสหรัฐอเมริกาและสหราชอาณาจักร แต่เวลาแฝงส่วนท้ายก็สูงกว่าเวลาแฝงเฉลี่ยอย่างมาก และสิ่งนี้ก็เป็นจริงแม้กระทั่งในสหรัฐอเมริกาและสหราชอาณาจักร

ประสิทธิภาพ TCP ผ่านทางอากาศ

TCP ถูกสร้างขึ้นเพื่อ มีสาย เครือข่าย กล่าวคือ โดยเน้นที่ลิงก์ที่สามารถคาดเดาได้สูง อย่างไรก็ตาม, ไร้สาย เครือข่ายมีลักษณะและความยากลำบากในตัวเอง ประการแรก เครือข่ายไร้สายเสี่ยงต่อการสูญเสียเนื่องจากการรบกวนและการลดทอนสัญญาณ ตัวอย่างเช่น เครือข่าย Wi-Fi มีความไวต่อไมโครเวฟ บลูทูธ และคลื่นวิทยุอื่นๆ เครือข่ายโทรศัพท์เคลื่อนที่ประสบปัญหาการสูญเสียสัญญาณ (เส้นทางที่หายไป) เนื่องจากการสะท้อน/การดูดซึมของสัญญาณโดยวัตถุและอาคาร รวมถึงจาก การรบกวน จากเพื่อนบ้าน เสาเซลล์. สิ่งนี้นำไปสู่ความสำคัญมากขึ้น (4-10 ครั้ง) และมีความหลากหลายมากขึ้น เวลาไป-กลับ (RTT) และการสูญเสียแพ็กเก็ตเมื่อเปรียบเทียบกับการเชื่อมต่อแบบมีสาย

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

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

รูปที่ 2 ความล่าช้าโดยใช้รัศมี 2 กม. เป็นตัวอย่าง เดลี, อินเดีย

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

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

ทั้งหมดที่กล่าวมาทำให้ประสิทธิภาพ TCP ไม่มีประสิทธิภาพในเครือข่ายไร้สาย อย่างไรก็ตาม ก่อนที่จะมองหาทางเลือกอื่นนอกเหนือจาก TCP เราต้องการพัฒนาความเข้าใจที่แม่นยำในประเด็นต่อไปนี้:

• TCP เป็นผู้ร้ายหลักที่อยู่เบื้องหลังเวลาแฝงส่วนท้ายในแอปพลิเคชันของเราหรือไม่
• เครือข่ายสมัยใหม่มีความล่าช้าในการเดินทางไปกลับ (RTT) อย่างมีนัยสำคัญและหลากหลายหรือไม่
• ผลกระทบของ RTT และการสูญเสียต่อประสิทธิภาพ TCP คืออะไร

การวิเคราะห์ประสิทธิภาพ TCP

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

หากแพ็กเก็ตหรือ ACK สูญหาย ผู้ส่งจะส่งอีกครั้งหลังจากหมดเวลา (RTO, หมดเวลาการส่งสัญญาณซ้ำ). RTO ได้รับการคำนวณแบบไดนามิกโดยอิงตามปัจจัยต่างๆ เช่น ความล่าช้า RTT ที่คาดไว้ระหว่างผู้ส่งและผู้รับ

รูปที่ 4 การแลกเปลี่ยนแพ็กเก็ตผ่าน TCP/TLS มีกลไกการส่งข้อมูลใหม่

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

ผลลัพธ์ของการทดลองทั้งสองมีความสอดคล้องกัน เราเห็นเวลาแฝง RTT สูง ค่าหางสูงกว่าค่ามัธยฐานเกือบ 6 เท่า ค่าเฉลี่ยเลขคณิตของความล่าช้ามากกว่า 1 วินาที การเชื่อมต่อจำนวนมากสูญเสียไป ทำให้ TCP ส่งข้อมูลซ้ำ 3,5% ของแพ็กเก็ตทั้งหมด ในพื้นที่แออัด เช่น สนามบินและสถานีรถไฟ เราเห็นการขาดทุน 7% ผลลัพธ์เหล่านี้ทำให้เกิดข้อสงสัยต่อภูมิปัญญาดั้งเดิมที่ใช้ในเครือข่ายเซลลูล่าร์ วงจรการส่งซ้ำขั้นสูง ลดความสูญเสียในระดับการขนส่งได้อย่างมาก ด้านล่างนี้คือผลการทดสอบจากแอปพลิเคชัน “จำลอง”:

ตัวชี้วัดเครือข่าย
ความหมาย

RTT, มิลลิวินาที [50%,75%, 95%,99%]
[350, 425, 725, 2300]

ความแตกต่าง RTT วินาที
โดยเฉลี่ย ~1,2 วินาที

การสูญเสียแพ็กเก็ตจากการเชื่อมต่อที่ไม่เสถียร
เฉลี่ย ~3.5% (7% ในพื้นที่โอเวอร์โหลด)

เกือบครึ่งหนึ่งของการเชื่อมต่อเหล่านี้สูญเสียแพ็กเก็ตอย่างน้อยหนึ่งครั้ง ส่วนใหญ่เป็นแพ็กเก็ต SYN และ SYN-ACK การใช้งาน TCP ส่วนใหญ่ใช้ค่า RTO 1 วินาทีสำหรับแพ็กเก็ต SYN ซึ่งจะเพิ่มขึ้นแบบทวีคูณสำหรับการสูญเสียที่ตามมา เวลาในการโหลดแอปพลิเคชันอาจเพิ่มขึ้นเนื่องจาก TCP ใช้เวลาสร้างการเชื่อมต่อนานกว่า

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

ในขณะที่เปอร์เซ็นไทล์ที่ 75 ของ RTT ที่วัดได้อยู่ที่ประมาณ 425 มิลลิวินาที เปอร์เซ็นไทล์ที่ 75 สำหรับ TCP อยู่ที่เกือบ 3 วินาที สิ่งนี้บอกเป็นนัยว่าการสูญเสียทำให้ TCP ใช้เวลา 7-10 รอบในการส่งข้อมูลได้สำเร็จ นี่อาจเป็นผลมาจากการคำนวณ RTO ที่ไม่มีประสิทธิภาพ TCP ไม่สามารถตอบสนองต่อการสูญเสียได้อย่างรวดเร็ว แพ็คเกจล่าสุด ในหน้าต่างและความไร้ประสิทธิภาพของอัลกอริธึมควบคุมความแออัด ซึ่งไม่ได้แยกความแตกต่างระหว่างการสูญเสียแบบไร้สายและการสูญเสียอันเนื่องมาจากความแออัดของเครือข่าย ด้านล่างนี้คือผลลัพธ์ของการทดสอบการสูญเสีย TCP:

สถิติการสูญเสียแพ็กเก็ต TCP
มูลค่า

เปอร์เซ็นต์ของการเชื่อมต่อที่มีการสูญเสียแพ็คเก็ตอย่างน้อย 1 ครั้ง
ลด 45%

เปอร์เซ็นต์ของการเชื่อมต่อที่สูญเสียระหว่างการตั้งค่าการเชื่อมต่อ
ลด 30%

เปอร์เซ็นต์การเชื่อมต่อที่สูญเสียระหว่างการแลกเปลี่ยนข้อมูล
ลด 76%

การกระจายความล่าช้าในการส่งสัญญาณซ้ำ วินาที [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

การกระจายจำนวนการส่งสัญญาณซ้ำสำหรับหนึ่งแพ็กเก็ตหรือเซ็กเมนต์ TCP
[1,3,6,7]

การประยุกต์ใช้ QUIC

QUIC เดิมพัฒนาโดย Google เป็นโปรโตคอลการขนส่งสมัยใหม่แบบมัลติเธรดที่ทำงานบน UDP ขณะนี้ QUIC อยู่ใน กระบวนการมาตรฐาน (เราได้เขียนไปแล้วว่ามี QUIC สองเวอร์ชันที่อยากรู้อยากเห็น สามารถตามลิงค์ได้เลย – ประมาณ. นักแปล) ดังแสดงในรูปที่ 5 QUIC อยู่ภายใต้ HTTP/3 (อันที่จริง HTTP/2 ที่ด้านบนของ QUIC คือ HTTP/3 ซึ่งขณะนี้กำลังได้รับมาตรฐานอย่างเข้มงวด) บางส่วนจะแทนที่เลเยอร์ HTTPS และ TCP โดยใช้ UDP เพื่อสร้างแพ็กเก็ต QUIC รองรับการถ่ายโอนข้อมูลที่ปลอดภัยเท่านั้น เนื่องจาก TLS ถูกสร้างขึ้นใน QUIC โดยสมบูรณ์

รูปที่ 5: QUIC ทำงานภายใต้ HTTP/3 แทนที่ TLS ซึ่งก่อนหน้านี้ทำงานภายใต้ HTTP/2

ด้านล่างนี้คือเหตุผลที่ทำให้เรามั่นใจว่าจะใช้ QUIC สำหรับการขยาย TCP:

• การสร้างการเชื่อมต่อ 0-RTT QUIC อนุญาตให้นำการอนุญาตจากการเชื่อมต่อก่อนหน้านี้มาใช้ซ้ำ ช่วยลดจำนวนการจับมือกันด้านความปลอดภัย ต่อไปในอนาคต TLS1.3 จะรองรับ 0-RTT แต่ยังคงต้องมีการจับมือ TCP แบบสามทาง
• เอาชนะการบล็อก HoL HTTP/2 ใช้การเชื่อมต่อ TCP หนึ่งรายการต่อไคลเอนต์เพื่อปรับปรุงประสิทธิภาพ แต่สิ่งนี้สามารถนำไปสู่การบล็อก HoL (ส่วนหัวของบรรทัด) QUIC ช่วยลดความยุ่งยากในการมัลติเพล็กซ์และส่งคำขอไปยังแอปพลิเคชันอย่างอิสระ
• การควบคุมความแออัด QUIC อยู่ที่เลเยอร์แอปพลิเคชัน ทำให้ง่ายต่อการอัปเดตอัลกอริธึมการขนส่งหลักที่ควบคุมการส่งตามพารามิเตอร์เครือข่าย (จำนวนการสูญเสียหรือ RTT) การใช้งาน TCP ส่วนใหญ่ใช้อัลกอริทึม คิวบิกซึ่งไม่เหมาะสมสำหรับการรับส่งข้อมูลที่มีความอ่อนไหวต่อเวลาในการตอบสนอง อัลกอริธึมที่พัฒนาขึ้นล่าสุดเช่น BBRสร้างโมเดลเครือข่ายได้แม่นยำยิ่งขึ้นและเพิ่มประสิทธิภาพเวลาแฝง QUIC อนุญาตให้คุณใช้ BBR และอัปเดตอัลกอริทึมนี้ตามที่มีการใช้งาน การปรับปรุง.
• การเติมเต็มการสูญเสีย QUIC เรียก TLP สองตัว (การตรวจสอบการสูญเสียหาง) ก่อนที่ RTO จะถูกทริกเกอร์ - แม้ว่าการสูญเสียจะเห็นได้ชัดเจนก็ตาม สิ่งนี้แตกต่างจากการใช้งาน TCP TLP จะส่งแพ็กเก็ตสุดท้ายอีกครั้งเป็นหลัก (หรือแพ็กเก็ตใหม่ ถ้ามี) เพื่อกระตุ้นการเติมเต็มอย่างรวดเร็ว การจัดการความล่าช้าส่วนท้ายมีประโยชน์อย่างยิ่งสำหรับวิธีที่ Uber ดำเนินการเครือข่าย กล่าวคือ สำหรับการถ่ายโอนข้อมูลระยะสั้น เป็นระยะ ๆ และไวต่อความหน่วง
• ACK ที่ปรับให้เหมาะสม เนื่องจากแต่ละแพ็กเก็ตมีหมายเลขลำดับที่ไม่ซ้ำกัน จึงไม่มีปัญหา ความแตกต่าง แพ็กเก็ตเมื่อมีการส่งซ้ำ แพ็กเก็ต ACK ยังมีเวลาในการประมวลผลแพ็กเก็ตและสร้าง ACK บนฝั่งไคลเอ็นต์ คุณสมบัติเหล่านี้ช่วยให้มั่นใจได้ว่า QUIC คำนวณ RTT ได้แม่นยำยิ่งขึ้น ACK ใน QUIC รองรับได้ถึง 256 แบนด์ แน็คช่วยให้ผู้ส่งมีความยืดหยุ่นมากขึ้นในการสับแพ็กเก็ตและใช้ไบต์น้อยลงในกระบวนการ เลือก ACK (กระสอบ) ใน TCP ไม่สามารถแก้ปัญหานี้ได้ในทุกกรณี
• การโยกย้ายการเชื่อมต่อ การเชื่อมต่อ QUIC จะถูกระบุด้วย ID 64 บิต ดังนั้นหากไคลเอนต์เปลี่ยนที่อยู่ IP รหัสการเชื่อมต่อเก่าจะยังสามารถใช้กับที่อยู่ IP ใหม่ต่อไปได้โดยไม่หยุดชะงัก นี่เป็นแนวทางปฏิบัติทั่วไปสำหรับแอปพลิเคชันบนมือถือที่ผู้ใช้สลับระหว่างการเชื่อมต่อ Wi-Fi และโทรศัพท์มือถือ

ทางเลือกอื่นสำหรับ QUIC

เราพิจารณาแนวทางอื่นในการแก้ปัญหาก่อนที่จะเลือก QUIC

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

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

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

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

การรวม QUIC เข้ากับแพลตฟอร์ม

เพื่อให้ฝัง QUIC ได้สำเร็จและปรับปรุงประสิทธิภาพของแอปพลิเคชันในสภาพแวดล้อมการเชื่อมต่อที่ไม่ดี เราได้แทนที่สแต็กเก่า (HTTP/2 บน TLS/TCP) ด้วยโปรโตคอล QUIC เราใช้ไลบรารีเครือข่าย โครเน็ต ของ โครงการโครเมียมซึ่งมีโปรโตคอลเวอร์ชันดั้งเดิมของ Google - gQUIC การใช้งานนี้ยังได้รับการปรับปรุงอย่างต่อเนื่องเพื่อให้เป็นไปตามข้อกำหนด IETF ล่าสุด

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

เช่นเดียวกับแนวทางสำหรับอุปกรณ์ Android เราได้นำ Cronet ไปใช้กับแอพ Uber บน iOS โดยสกัดกั้นการรับส่งข้อมูล HTTP จากเครือข่าย APIใช้ NSURLProtocol. นามธรรมนี้จัดทำโดย iOS Foundation จัดการข้อมูล URL เฉพาะโปรโตคอลและทำให้แน่ใจว่าเราสามารถรวม Cronet เข้ากับแอปพลิเคชัน iOS ของเราได้โดยไม่มีค่าใช้จ่ายในการย้ายข้อมูลจำนวนมาก

ดำเนินการ QUIC ให้เสร็จสิ้นบน Google Cloud Balancer

ในด้านแบ็กเอนด์ ความสมบูรณ์ของ QUIC นั้นมาจากโครงสร้างพื้นฐานการปรับสมดุลโหลดของ Google Cloud ซึ่งใช้ alt-svc ส่วนหัวในการตอบสนองต่อการสนับสนุน QUIC โดยทั่วไป ตัวปรับสมดุลจะเพิ่มส่วนหัว alt-svc ให้กับคำขอ HTTP แต่ละรายการ และนี่เป็นการตรวจสอบการสนับสนุน QUIC สำหรับโดเมนแล้ว เมื่อไคลเอ็นต์ Cronet ได้รับการตอบกลับ HTTP ด้วยส่วนหัวนี้ ไคลเอ็นต์จะใช้ QUIC สำหรับคำขอ HTTP ตามมาไปยังโดเมนนั้น เมื่อบาลานเซอร์ทำ QUIC เสร็จแล้ว โครงสร้างพื้นฐานของเราจะส่งการกระทำนี้ผ่าน HTTP2/TCP ไปยังศูนย์ข้อมูลของเราอย่างชัดเจน

ประสิทธิภาพการทำงาน: ผลลัพธ์

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

การทดลอง 1

อุปกรณ์สำหรับการทดลอง:

• ทดสอบอุปกรณ์ Android ด้วยสแต็ค OkHttp และ Cronet เพื่อให้แน่ใจว่าเราอนุญาตการรับส่งข้อมูล HTTPS ผ่าน TCP และ QUIC ตามลำดับ
• เซิร์ฟเวอร์จำลองที่ใช้ Java ซึ่งส่งส่วนหัว HTTPS ประเภทเดียวกันในการตอบกลับและโหลดอุปกรณ์ไคลเอ็นต์เพื่อรับคำขอจากอุปกรณ์เหล่านั้น
• พร็อกซีระบบคลาวด์ซึ่งตั้งอยู่ใกล้กับอินเดียเพื่อยุติการเชื่อมต่อ TCP และ QUIC ในขณะที่การยกเลิก TCP เราใช้พร็อกซีย้อนกลับ NGINXเป็นการยากที่จะค้นหาพร็อกซีย้อนกลับแบบโอเพ่นซอร์สสำหรับ QUIC เราสร้างพร็อกซีย้อนกลับสำหรับ QUIC ด้วยตัวเราเองโดยใช้สแต็ก QUIC พื้นฐานจาก Chromium และ การตีพิมพ์ มันเป็นโครเมียมเป็นโอเพ่นซอร์ส

รูปที่ 6 ชุดทดสอบ TCP กับ QUIC ประกอบด้วยอุปกรณ์ Android ที่มี OkHttp และ Cronet, พรอกซีบนคลาวด์สำหรับยุติการเชื่อมต่อ และเซิร์ฟเวอร์จำลอง

การทดลอง 2

เมื่อ Google ทำให้ QUIC ใช้งานได้กับ การปรับสมดุลโหลดของ Google Cloudเราใช้พื้นที่โฆษณาเดียวกัน แต่มีการแก้ไขเพียงครั้งเดียว แทนที่จะใช้ NGINX เราใช้โหลดบาลานเซอร์ของ Google เพื่อยุติการเชื่อมต่อ TCP และ QUIC จากอุปกรณ์ ตลอดจนกำหนดเส้นทางการรับส่งข้อมูล HTTPS ไปยังเซิร์ฟเวอร์จำลอง บาลานเซอร์กระจายอยู่ทั่วโลก แต่ใช้เซิร์ฟเวอร์ PoP ใกล้กับอุปกรณ์มากที่สุด (ขอบคุณตำแหน่งทางภูมิศาสตร์)

รูปที่ 7 ในการทดลองครั้งที่สอง เราต้องการเปรียบเทียบเวลาแฝงที่เสร็จสมบูรณ์ของ TCP และ QUIC: การใช้ Google Cloud และการใช้พร็อกซีคลาวด์ของเรา

ด้วยเหตุนี้ จึงมีการเปิดเผยหลายประการรอเราอยู่:

• การยกเลิกผ่าน PoP ปรับปรุงประสิทธิภาพ TCP เนื่องจากบาลานเซอร์ยุติการเชื่อมต่อ TCP ใกล้กับผู้ใช้มากขึ้นและได้รับการปรับให้เหมาะสมที่สุด ส่งผลให้ RTT ลดลง ซึ่งช่วยปรับปรุงประสิทธิภาพของ TCP และถึงแม้ว่า QUIC จะได้รับผลกระทบน้อยกว่า แต่ก็ยังมีประสิทธิภาพเหนือกว่า TCP ในแง่ของการลดเวลาแฝง (ประมาณ 10-30 เปอร์เซ็นต์)
• หางได้รับผลกระทบ กระโดดเครือข่าย. แม้ว่าพร็อกซี QUIC ของเราจะอยู่ห่างจากอุปกรณ์ (เวลาแฝงสูงกว่าประมาณ 50 มิลลิวินาที) มากกว่าโหลดบาลานเซอร์ของ Google แต่ก็ให้ประสิทธิภาพที่คล้ายคลึงกัน นั่นคือเวลาแฝงลดลง 15% เทียบกับเปอร์เซ็นไทล์ที่ 20 ที่ลดลง 99% สำหรับ TCP นี่แสดงให้เห็นว่าการเปลี่ยนไมล์สุดท้ายเป็นปัญหาคอขวดในเครือข่าย

รูปที่ 8: ผลลัพธ์จากการทดลองสองครั้งแสดงให้เห็นว่า QUIC มีประสิทธิภาพเหนือกว่า TCP อย่างมาก

ต่อสู้กับการจราจร

แรงบันดาลใจจากการทดลอง เราได้ใช้การสนับสนุน QUIC ในแอปพลิเคชัน Android และ iOS ของเรา เราทำการทดสอบ A/B เพื่อพิจารณาผลกระทบของ QUIC ในเมืองต่างๆ ที่ Uber ดำเนินการอยู่ โดยทั่วไป เราพบว่าความล่าช้าหางลดลงอย่างมากในทั้งสองภูมิภาค ผู้ให้บริการโทรคมนาคม และประเภทเครือข่าย

กราฟด้านล่างแสดงเปอร์เซ็นต์การปรับปรุงส่วนท้าย (95 และ 99 เปอร์เซ็นไทล์) ตามภูมิภาคมาโครและประเภทเครือข่ายต่างๆ - LTE, 3G, 2G

รูปที่ 9 ในการทดสอบการต่อสู้ QUIC มีประสิทธิภาพเหนือกว่า TCP ในแง่ของเวลาแฝง

ไปข้างหน้าเท่านั้น

บางทีนี่อาจเป็นเพียงจุดเริ่มต้น - การเปิดตัว QUIC สู่การใช้งานจริงได้มอบโอกาสที่ยอดเยี่ยมในการปรับปรุงประสิทธิภาพของแอปพลิเคชันในเครือข่ายทั้งที่เสถียรและไม่เสถียร กล่าวคือ:

ความคุ้มครองที่เพิ่มขึ้น

จากการวิเคราะห์ประสิทธิภาพของโปรโตคอลกับการรับส่งข้อมูลจริง เราพบว่าประมาณ 80% ของเซสชันใช้ QUIC ได้สำเร็จ ทั้งหมด คำขอ ในขณะที่ 15% ของเซสชันใช้การผสมผสานระหว่าง QUIC และ TCP เราสันนิษฐานว่าการรวมกันนี้เกิดจากการหมดเวลาของไลบรารี Cronet กลับไปที่ TCP เนื่องจากไม่สามารถแยกแยะระหว่างความล้มเหลว UDP จริงและสภาพเครือข่ายที่ไม่ดีได้ ขณะนี้เรากำลังพิจารณาวิธีแก้ไขปัญหานี้ในขณะที่เราดำเนินการนำ QUIC ไปใช้ในภายหลัง

การเพิ่มประสิทธิภาพ QUIC

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

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

ที่มา: will.com