โปรโตคอล QUIC คืออะไร ? รู้จักการรับส่งข้อมูลแบบใหม่ และต่างจากเดิมอย่างไร ?

โปรโตคอล Quick UDP Internet Connections (QUIC) คืออะไร ?

ด้วยการพัฒนาอย่างรวดเร็วของเทคโนโลยี อินเทอร์เน็ต (Internet) การออกแบบ และปรับแต่ง โปรโตคอล (Protocol) ใน ชั้นขนส่งของเครือข่าย (Transport Layer) จึงมีความสำคัญมากขึ้นเรื่อย ๆ โปรโตคอล QUIC ซึ่งเป็นโปรโตคอล Transport Layer ตัวใหม่ที่ทาง Google ได้นำเสนอขึ้นมา ซึ่งมันได้รับความสนใจ และถูกศึกษาวิจัยอย่างแพร่หลายในช่วงไม่กี่ปีที่ผ่านมา

โปรโตคอล QUIC มีเป้าหมายเพื่อแก้ไขข้อจำกัดของโปรโตคอล TCP แบบดั้งเดิม โดยเฉพาะในด้าน ความหน่วง (Latency) สูง และปัญหาการติดบล็อกที่หัวแถว (Head-of-Line Blocking) ซึ่งมีผลให้เครือข่ายถูกจำกัดประสิทธิภาพเมื่อแพ็กเก็ตต้องเสียเวลาเรียงคิวต่อกัน พร้อมทั้งมอบประสิทธิภาพในการส่งข้อมูล และความปลอดภัยที่สูงกว่า

ในบทความนี้ มาอ่านละเอียดเกี่ยวกับโปรโตคอล QUIC, ความแตกต่างจากโปรโตคอลแบบเดิม และหลักการทำงานของมันกัน

โปรโตคอล QUIC คืออะไร ? (What is QUIC Protocol ?)

QUIC ตามนิยามของ คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต (Internet Engineering Task Force-IETF) คือโปรโตคอลแบบ เข้ารหัส (Encryption) ที่มีลักษณะการเชื่อมต่อแบบ "Connection-Oriented" การส่งข้อมูลแบบมีสถานะเชื่อมต่อ ซึ่งต้องมีการสร้างการเชื่อมต่อระหว่างสองอุปกรณ์ก่อนส่งข้อมูล และจะตัดการเชื่อมต่อหลังจากส่งข้อมูลเสร็จสิ้นแล้ว โดย QUIC ทำงานอยู่ในชั้นขนส่ง (Transport Layer) หรือชั้นที่ 4 ของโมเดล OSI

ภาพจาก : https://www.network-supply.com/blogs/knowledge/the-osi-model-explained

แม้ว่า QUIC จะเพิ่งได้รับการรับรองมาตรฐานอย่างเป็นทางการในฐานะโดย IETF เมื่อเดือนพฤษภาคม ปี ค.ศ. 2021 (พ.ศ. 2564) แต่อันที่จริง มันได้เริ่มการพัฒนามาเกือบสิบปีแล้ว

ในปี ค.ศ. 2012 (พ.ศ. 2555) วิศวกรของ Google ได้พัฒนาโปรโตคอล Quick UDP Internet Connections หรือย่อว่า QUIC ขึ้นมา เพราะต้องการทดลอง หาทางปรับปรุงประสิทธิภาพของ เว็บแอปพลิเคชัน (Web Application) ของ Google แม้ว่าในตอนแรก QUIC จะเป็นคำย่อ แต่ในมาตรฐานอย่างเป็นทางการของ มาตรฐานอินเทอร์เน็ต RFC 9000 ได้ระบุว่า QUIC เป็นชื่อเต็มแล้ว ไม่ใช่คำย่อ 

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

ที่ TCP ทำงานได้ช้า สืบเนื่องมาจากในการทำงาน มันจำเป็นต้องทำการจับมือสามทาง (Three-Way Handshake) เพื่อเริ่มต้นการเชื่อมต่อ และหลังจากนั้นยังต้องประสานงานเพื่อรับค่าการเข้ารหัสสำหรับ TLS ก่อนที่ข้อมูลที่ผู้ใช้ต้องการจะเริ่มถูกส่งจริง ๆ ซึ่งหมายความว่า ในกระบวนการทำงานจะมีการสื่อสารเกิดขึ้นหลายรอบ เพียงเพื่อสร้างเส้นทางให้สองอุปกรณ์สามารถสื่อสารกันได้ ส่งผลให้ค่า Latency สูง 

ส่วน QUIC ได้ใช้โปรโตคอล User Datagram Protocol (UDP) แทน จึงไม่จำเป็นต้องมีขั้นตอน Handshake ที่ซับซ้อนในการเริ่มต้นการเชื่อมต่อ โปรโตคอลนี้รวมขั้นตอนการเริ่มต้นการเข้ารหัส และการแลกเปลี่ยนกุญแจไว้ใน Handshake ครั้งแรกเลย ทำให้สามารถสร้างเส้นทางการสื่อสารได้ภายในหนึ่งรอบการสื่อสารเท่านั้น จึงมีค่า Latency ต่ำกว่ามาก

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

ภาพจาก : https://www.auvik.com/franklyit/blog/what-is-quic-protocol/

โปรโตคอล QUIC ต่างจากโปรโตคอลดั้งเดิมอย่างไร ? (Differences between the QUIC Protocol and Traditional Protocol)

ความแตกต่างหลักระหว่างโปรโตคอล QUIC กับโปรโตคอลแบบดั้งเดิม เช่น TCP และ UDP อยู่ที่เป้าหมายในการออกแบบ, หลักการทำงาน และความสามารถในการปรับตัว ให้เข้ากับความต้องการของแอปพลิเคชันบนเครือข่ายยุคใหม่ โดยมีรายละเอียดดังนี้

ทำงานบนพื้นฐานของ UDP

โปรโตคอล QUIC เลือกใช้ UDP เป็นโปรโตคอลพื้นฐาน แทนที่จะอิงกับ IP โดยตรงเหมือน TCP ความเรียบง่ายของ UDP ทำให้ QUIC สามารถหลีกเลี่ยงฟีเจอร์ที่ซับซ้อน และบางครั้งก็ไม่จำเป็นของ TCP เช่น ขั้นตอนการจับมือสามทาง (Three-Way Handshake) และอัลกอริธึมควบคุมความแออัด ส่งผลให้สามารถลดเวลาแฝงของเครือข่ายได้อย่างมีประสิทธิภาพ

• QUIC สร้างขึ้นโดยเพิ่มชั้นการทำงานบน UDP ซึ่งยังคงคุณสมบัติสำคัญของ TCP เช่น การควบคุม
• QUIC ใช้เทคโนโลยี 0-RTT เพื่อสร้างการเชื่อมต่อที่ปลอดภัยตั้งแต่คำขอแรกของไคลเอนต์ ทำให้ลดเวลาในการเชื่อมต่อได้อย่างมาก
• QUIC รองรับการส่งข้อมูลหลายสตรีมพร้อมกันผ่านการเชื่อมต่อเดียว ซึ่งช่วยหลีกเลี่ยงปัญหา Head-Of-Line Blocking ที่พบใน TCP และเพิ่มประสิทธิภาพในการใช้แบนด์วิดท์
• QUIC มีการเข้ารหัสด้วยโปรโตคอล TLS 1.3 ในตัว เพื่อรับรองความปลอดภัยของข้อมูลตั้งแต่ต้นทางถึงปลายทาง
• ในสภาพแวดล้อมเครือข่ายที่ไม่เสถียร QUIC สามารถโยกย้ายการเชื่อมต่อได้อย่างราบรื่นโดยไม่ต้องเริ่มต้นใหม่

เชื่อมต่อแบบ Zero RTT (Round-Trip Time)

โปรโตคอล TCP แบบดั้งเดิม จำเป็นต้องใช้กระบวนการจับมือสามทาง (Three-Way Handshake) เพื่อเริ่มต้นการเชื่อมต่อ ซึ่งส่งผลให้เกิดความล่าช้าเพิ่มเติมในการสื่อสาร ในทางกลับกัน โปรโตคอล QUIC ได้เสนอแนวคิดที่เรียกว่า "การโยกย้ายการเชื่อมต่อ" (Connection Migration) ซึ่งช่วยให้ไคลเอนต์ และ เซิร์ฟเวอร์ (Server) สามารถเริ่มส่งข้อมูลสตรีมใหม่ผ่านการเชื่อมต่อเดิมได้ทันที โดยไม่ต้องทำการจับมือใหม่อีกครั้ง จึงสามารถสร้างการเชื่อมต่อแบบ Zero RTT ได้อย่างมีประสิทธิภาพ ลดเวลาแฝงในการเริ่มต้นการสื่อสารลงอย่างมาก

ระบบความปลอดภัยระดับชั้นทรานสปอร์ตในตัว (Built-in Transport Layer Security)

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

การทำมัลติเพล็กซ์ (Multiplexing)

ในโปรโตคอล TCP การส่งข้อมูลผ่านการเชื่อมต่อ จะถูกประมวลผลแบบเรียงลำดับ และหากมีแพ็กเก็ตก่อนหน้าสูญหาย จะส่งผลให้แพ็กเก็ตถัดไปไม่สามารถส่งต่อได้ทันที ซึ่งปัญหานี้เรียกว่า “Head-Of-Line Blocking” โปรโตคอล QUIC ได้แนะนำแนวคิดของ "สตรีม" (Streams) ซึ่งช่วยให้สามารถส่งข้อมูลหลายสตรีมพร้อมกันผ่านการเชื่อมต่อเดียว โดยแต่ละสตรีมจะทำงานอย่างอิสระ ไม่ได้รับผลกระทบจากการสูญหายของแพ็กเก็ตในสตรีมอื่น ทำให้การส่งข้อมูลมีประสิทธิภาพมากขึ้น และลดความล่าช้าในการสื่อสาร

จับมือ และปิดการเชื่อมต่ออย่างรวดเร็ว (Fast Handshake and Closure)

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

ปรับตัวแบบไดนามิก (Dynamic Adjustment)

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

การโยกย้ายการเชื่อมต่อ (Connection Migration)

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

จัดการข้อผิดพลาด และกู้คืน (Error Handling and Recovery)

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

ขยายความสามารถ (Extensibility)

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

ประวัติความเป็นมาของ โปรโตคอล QUIC (History of the QUIC Protocol)

การพัฒนาโปรโตคอล QUIC เป็นกระบวนการที่เริ่มต้นจากโครงการทดลองเล็ก ๆ ของ Google ก่อนจะกลายมาเป็นมาตรฐานของ IETF โดยในตอนแรก มันมีเป้าหมายเพื่อปรับปรุงประสิทธิภาพ และความน่าเชื่อถือของอินเทอร์เน็ต ผ่านการพัฒนาในระดับเลเยอร์การขนส่งข้อมูล (Transport Layer) โดยมีลำดับเหตุการณ์ ดังนี้

โปรโตคอล QUIC ถูกออกแบบเป็นครั้งแรกโดย Jim Roskind นักพัฒนาของ Google และถูกนำไปใช้งานจริงในปี ค.ศ. 2012 (พ.ศ. 2555) ต่อมาในปี ค.ศ. 2013 (พ.ศ. 2556) Google ได้เปิดเผยรายละเอียดของ QUIC ต่อสาธารณะ และนำเสนอแนวคิดของโปรโตคอลใหม่นี้ต่อ IETF

หลังจาก Google ส่งข้อเสนอโปรโตคอล QUIC ไปยัง IETF ในปี ค.ศ. 2015 (พ.ศ. 2556) IETF ได้จัดตั้งกลุ่มทำงาน QUIC Working Group ขึ้นอย่างเป็นทางการขึ้นมา จนกระทั่งในเดือนพฤษภาคม ค.ศ. 2021 (พ.ศ. 2564) IETF ได้ประกาศมาตรฐาน QUIC อย่างเป็นทางการใน RFC9000 ถือเป็นการยอมรับมาตรฐานโปรโตคอล QUIC อย่างสมบูรณ์