งานวิจัยและฉบับร่าง

การวิจัย TCP

อาร์กิวเมนต์สำหรับเพิ่มช่วงเวลาความคับคั่งเริ่มต้นของ TCP

โฟลว์ TCP เริ่มต้นด้วยหน้าต่างความคับคั่งเริ่มต้นที่ไม่เกิน 4 ส่วน หรือมีข้อมูลประมาณ 4KB เนื่องจากธุรกรรมบนเว็บส่วนใหญ่จะมีอายุสั้น กรอบเวลาความคับคั่งในช่วงแรกจึงเป็นพารามิเตอร์ TCP ที่สำคัญซึ่งจะระบุความเร็วในการดำเนินการให้เสร็จสิ้น แม้ว่าความเร็วในการเข้าถึงเครือข่ายทั่วโลกจะเพิ่มขึ้นอย่างมากโดยเฉลี่ยในช่วง 10 ปีที่ผ่านมา ค่ามาตรฐานความคับคั่งในช่วงแรกของ TCP ก็ยังคงเหมือนเดิม ในเอกสารนี้ เราเสนอให้เพิ่มช่วงเวลาความแออัดในช่วงเริ่มต้นของ TCP เป็น 10 ส่วนเป็นอย่างน้อย (ประมาณ 15 KB) จากการทดลองอินเทอร์เน็ตจำนวนมาก เราได้ระบุปริมาณประโยชน์ของเวลาในการตอบสนองและค่าใช้จ่ายในการใช้กรอบเวลาที่ใหญ่ขึ้น ตามฟังก์ชันของแบนด์วิดท์เครือข่าย ระยะเวลารับส่งข้อมูล (RTT) ผลิตภัณฑ์สำหรับการหน่วงแบนด์วิดท์ (BDP) และลักษณะของแอปพลิเคชัน เราแสดงให้เห็นว่าเวลาในการตอบสนองเฉลี่ยของการตอบสนอง HTTP เพิ่มขึ้นประมาณ 10% โดยมีประโยชน์มากที่สุดซึ่งแสดงให้เห็นในเครือข่าย RTT และ BDP ที่สูง นอกจากนี้ เวลาในการตอบสนองของเครือข่ายแบนด์วิดท์ต่ำยังเพิ่มขึ้นอย่างมากในการทดสอบของเรา อัตราการส่งโดยเฉลี่ยเพิ่มขึ้นเล็กน้อย 0.5% โดยปริมาณที่เพิ่มขึ้นส่วนใหญ่มาจากแอปพลิเคชันที่หลีกเลี่ยงอัลกอริทึมการเริ่มทำงานที่ช้าของ TCP อย่างมีประสิทธิภาพโดยใช้การเชื่อมต่อพร้อมกันหลายรายการ จากผลจากการทดสอบของเรา เราเชื่อว่าช่วงเวลาความแออัดในช่วงแรกควรมีอย่างน้อย 10 ส่วน และช่วงเดียวกันนี้จะต้องได้รับการตรวจสอบมาตรฐานโดย IETF

TCP Fast Open

บริการบนเว็บในปัจจุบันมีจุดเด่นอยู่ที่ขั้นตอน TCP ที่สั้นมากจนต้องยุติการเดินทางไป-กลับ 2-3 รอบหลังจากการจับมือ การแฮนด์เชคนี้เป็นแหล่งเวลาในการตอบสนองที่สำคัญสำหรับขั้นตอนเหล่านั้น ในเอกสารนี้ เราจะอธิบายการออกแบบ การใช้งาน และการติดตั้งใช้งานโปรโตคอล TCP Fast Open ซึ่งเป็นกลไกใหม่ที่เปิดโอกาสให้เกิดการแลกเปลี่ยนข้อมูลระหว่างการเริ่มต้นแฮนด์เชคของ TCP การดำเนินการดังกล่าวทำให้ TCP Fast Open ลดเวลาในการตอบสนองของเครือข่ายแอปพลิเคชันลงได้ 1 รอบ ทำให้เกิดความล่าช้าจากการโอน TCP ระยะสั้นดังกล่าว เราแก้ไขปัญหาด้านความปลอดภัยตามปกติในการอนุญาตให้มีการแลกเปลี่ยนข้อมูลในระหว่างแฮนด์เชค 3 ทาง ซึ่งเราจะบรรเทาปัญหาโดยใช้โทเค็นการรักษาความปลอดภัยที่ยืนยันการเป็นเจ้าของที่อยู่ IP เราให้รายละเอียดเกี่ยวกับกลไกการป้องกันแบบย้อนกลับอื่นๆ และแก้ไขปัญหาที่เราพบใน Middlebox, ความเข้ากันได้แบบย้อนหลังสำหรับสแต็กเครือข่ายที่มีอยู่ และการติดตั้งใช้งานที่เพิ่มขึ้น จากการวิเคราะห์ปริมาณการใช้งานและการจำลองเครือข่าย เราพบว่า TCP Fast Open จะลดเวลาในการตอบสนองของเครือข่ายธุรกรรม HTTP ลงได้ 15%และเวลาในการโหลดทั้งหน้าเว็บมากกว่า 10% โดยเฉลี่ย และในบางกรณีอาจลดลงถึง 40%

การลดอัตราสัดส่วนสำหรับ TCP

การสูญเสียแพ็กเกตจะเพิ่มเวลาในการตอบสนองสำหรับผู้ใช้เว็บ การกู้คืนอย่างรวดเร็วเป็นกลไกหลักสำหรับ TCP เพื่อกู้คืนจากการสูญเสียแพ็คเก็ต ในบทความนี้ เราได้สำรวจจุดอ่อนของอัลกอริทึมมาตรฐานที่อธิบายไว้ใน RFC 3517 และอัลกอริทึมที่ไม่เป็นมาตรฐานซึ่งใช้ใน Linux เราพบว่าอัลกอริทึมเหล่านี้เบี่ยงเบนไปจากพฤติกรรมที่ตั้งใจไว้ในชีวิตจริงเนื่องจากผลกระทบรวมของขั้นตอนสั้นๆ, แผงขายแอปพลิเคชัน, การสูญเสียจากจุดเร่ง, การลดลงของการรับรู้ (ACK) และเรียงลำดับใหม่ และยืด ACK Linux ประสบปัญหาการลดหน้าต่างความแออัดมากเกินไปขณะที่ RFC 3517 ส่งการเร่งประสิทธิภาพขนาดใหญ่ภายใต้การสูญเสียที่สูง ซึ่งทั้ง 2 อย่างนี้เป็นอันตรายต่อขั้นตอนที่เหลือและเพิ่มเวลาในการตอบสนองของเว็บ การสนับสนุนหลักของเราคือการออกแบบใหม่เพื่อควบคุมการส่งให้ฟื้นตัวอย่างรวดเร็วที่เรียกว่าการลดอัตราตามสัดส่วน (PRR) PRR จะฟื้นตัวจากการขาดทุนได้อย่างรวดเร็ว ราบรื่น และถูกต้องด้วยการกำหนดอัตราการส่งข้อมูลซ้ำใน ACK ที่ได้รับ นอกจาก PRR แล้ว เรายังประเมินอัลกอริทึมการส่งซ้ำก่อนกำหนดของ TCP (ER) ซึ่งจะลดเกณฑ์การรับทราบที่ซ้ำกันสำหรับการโอนสั้นๆ และแสดงให้เห็นว่าการหน่วงการส่งช่วงแรกเป็นเวลาสั้นๆ นั้นมีประสิทธิภาพในการหลีกเลี่ยงการส่งซ้ำที่ไม่เป็นจริงในกรณีที่มีการจัดลําดับใหม่เพียงเล็กน้อย PRR และ ER จะลดเวลาในการตอบสนองของ TCP ในการเชื่อมต่อที่มีการสูญเสียได้ 3-10% ขึ้นอยู่กับขนาดการตอบสนอง นอกจากนี้ เรายังแสดงสถิติที่สำคัญเกี่ยวกับลักษณะการส่งสัญญาณซ้ำผ่าน TCP โดยอิงจากการใช้เครื่องมือของเราบน Google Web และเซิร์ฟเวอร์ของ YouTube ในสหรัฐอเมริกาและอินเดียด้วย

ลามิเนียร์ TCP

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

SSL และ TLS ฉบับร่าง

Transport Layer Security (TLS) False Start

False Start คือลักษณะการทำงานที่ไม่บังคับของการใช้งาน TLS นโยบายจะมีผลเฉพาะกับช่วงเวลาของโปรโตคอลเท่านั้น ไม่ได้อยู่ในข้อมูลแบบ Wireprotocol และสามารถนำมาใช้แบบฝ่ายเดียวได้ ฟีเจอร์ TLS False Start จะลดเวลาในการตอบสนองของการส่งข้อมูลไปกลับ 1 รอบสำหรับแฮนด์เชคบางรายการ

ส่วนขยายการเจรจาโปรโตคอลถัดไปสำหรับ Transport Layer Security (TLS)

ส่วนขยาย Transport Layer Security (TLS) สำหรับการเจรจาโปรโตคอลเลเยอร์ของแอปพลิเคชัน วิธีนี้จะช่วยให้เลเยอร์ของแอปพลิเคชันเจรจาว่าจะใช้โปรโตคอลใดผ่านการเชื่อมต่อที่ปลอดภัยในลักษณะที่หลีกเลี่ยงการเดินทางไป-กลับเพิ่มเติม และเป็นอิสระจากโปรโตคอลเลเยอร์ของแอปพลิเคชัน

ฉบับร่าง DNS

ซับเน็ตของไคลเอ็นต์ในคำขอ DNS

ฉบับร่างนี้กำหนดส่วนขยาย EDNS0 เพื่อส่งข้อมูลเกี่ยวกับเครือข่ายที่ทำให้เกิดคำค้นหา DNS และเครือข่ายที่แคชการตอบกลับได้