QUIC (การเชื่อมต่ออินเทอร์เน็ต UDP ด่วน) เป็นโปรโตคอลที่อยู่ด้านบนของ UDP ที่รองรับคุณสมบัติทั้งหมดของ TCP, TLS และ HTTP/2 และแก้ไขปัญหาส่วนใหญ่ได้ มักเรียกว่าโปรโตคอลใหม่หรือ "การทดลอง" แต่มีอายุยืนยาวกว่าขั้นตอนการทดลองมานานแล้ว: การพัฒนาดำเนินไปอย่างต่อเนื่องมานานกว่า 7 ปี ในช่วงเวลานี้ โปรโตคอลไม่ได้กลายเป็นมาตรฐาน แต่ก็ยังแพร่หลาย ตัวอย่างเช่น QUIC ถูกใช้โดยยักษ์ใหญ่อย่าง Google และ Facebook เพื่อเร่งความเร็วการรับส่งข้อมูลและลดความล่าช้าในเครือข่ายมือถือ และ IETF ได้ประกาศการแยกโปรโตคอลเป็นพื้นฐานสำหรับมาตรฐาน HTTP/3 (แม้ว่า HTTP/2 จะใช้ HTTP/XNUMX เว็บไซต์)
แนวคิด
QUIC ได้รับการพัฒนาเพื่อทดแทน TCP รุ่นเก่า ซึ่งแต่เดิมได้รับการออกแบบมาสำหรับเครือข่ายแบบมีสายที่สูญเสียน้อย TCP จะส่งแพ็กเก็ตตามลำดับ ดังนั้นหากแพ็กเก็ตหนึ่งหายไป คิวทั้งหมดจะหยุดทำงาน () ซึ่งส่งผลเสียต่อคุณภาพและความเสถียรของการเชื่อมต่อ เพื่อหลีกเลี่ยงการสูญเสียครั้งใหญ่ เครือข่ายโทรศัพท์เคลื่อนที่หันไปใช้บัฟเฟอร์ขนาดใหญ่ ซึ่งจะนำไปสู่ความซ้ำซ้อนและการตอบสนองเชิงลบที่ผิดพลาดของโปรโตคอล (). นอกจากนี้ TCP ยังใช้เวลาส่วนใหญ่ในการสร้างการเชื่อมต่อ: คำขอ SYN/ACK และ TLS จะได้รับการประมวลผลแยกกัน โดยกำหนดให้ต้องเดินทางไปกลับสามครั้งแทนที่จะเป็นครั้งเดียว เหมือนกับที่ QUIC ทำ
เนื่องจาก QUIC รวมการแทนที่ TCP และการใช้งาน TLS 1.3 เข้าด้วยกัน การเชื่อมต่อทั้งหมดจึงได้รับการเข้ารหัสอยู่เสมอ และการถอดรหัสการรับส่งข้อมูลดังกล่าวจึงไม่ง่ายไปกว่าการใช้ HTTPS นอกจากนี้ QUIC ยังถูกนำไปใช้ในระดับแอปพลิเคชัน เนื่องจากจะต้องใช้การแทนที่สแต็ก TCP โดยสมบูรณ์ กัลป์.
แม้จะรองรับมัลติเพล็กซ์ใน HTTP/2 แต่ปัญหาของการบล็อกส่วนหัวยังคงอยู่ที่นั่นเนื่องจากจำเป็นต้องส่งแพ็กเก็ตตามลำดับ QUIC ถูกใช้งานบน UDP ดังนั้นจึงไม่มีการปิดกั้นในหลักการ และเพื่อป้องกันไม่ให้แพ็กเก็ตสูญหายตลอดไป จึงมีการเรียงลำดับหมายเลขและสามารถประกอบด้วยส่วนของ "เพื่อนบ้าน" ซึ่งทำให้เกิดความซ้ำซ้อน นอกจากนี้ QUIC ยังแบ่งคิวเสาหินออกเป็นหลายเธรดสำหรับคำขอประเภทต่างๆ ภายในการเชื่อมต่อเดียว ดังนั้น หากแพ็กเก็ตสูญหาย ปัญหาอาจเกิดขึ้นสำหรับคิวเดียวเท่านั้น (ตัวอย่างเช่น สำหรับการถ่ายโอนไฟล์เฉพาะ):
ใช้
ในช่วงแรก QUIC ได้รับการพัฒนาภายใน Google และได้รับการปรับแต่งเพื่อใช้ภายในบริษัทเป็นส่วนใหญ่ ในปี 2013 โปรโตคอลดังกล่าวถูกโอนไปยัง IETF เพื่อสร้างมาตรฐาน (ซึ่งยังคงดำเนินอยู่) และตอนนี้ทุกคนสามารถมีส่วนร่วมในการพัฒนาโปรโตคอลได้โดยเสนอสิ่งที่พวกเขาขาดหายไป คณะทำงาน IETF จะจัดการประชุมประจำปีในระหว่างที่มีการอนุมัติมาตรฐานใหม่และมีการหารือเกี่ยวกับนวัตกรรมต่างๆ การใช้งาน QUIC นี้ถือเป็นการดำเนินการหลักและเป็นไปตามมาตรฐาน HTTP/3 ที่ได้รับการรับรอง
จนถึงตอนนี้ ยังไม่มีการพูดถึงการรวม HTTP/3 เป็นโปรโตคอลหลัก เนื่องจากยังไม่เสร็จสิ้นและเกือบจะไม่รองรับ:
แต่ QUIC สามารถนำไปใช้เป็นการขนส่งระหว่างแอปพลิเคชันและเซิร์ฟเวอร์ ซึ่งสำเร็จที่ Uber:
ความคิดเห็นของ Uber เกี่ยวกับการแนะนำ QUIC
เพื่อให้ฝัง QUIC ได้สำเร็จและปรับปรุงประสิทธิภาพของแอปพลิเคชันในสภาพแวดล้อมการเชื่อมต่อที่ไม่ดี เราได้แทนที่สแต็กเก่า (HTTP/2 บน TLS/TCP) ด้วยโปรโตคอล QUIC เราใช้ไลบรารีเครือข่าย ของ ซึ่งมีโปรโตคอลเวอร์ชันดั้งเดิมของ Google - gQUIC การใช้งานนี้ยังได้รับการปรับปรุงอย่างต่อเนื่องเพื่อให้เป็นไปตามข้อกำหนด IETF ล่าสุด
ก่อนอื่นเราได้รวม Cronet เข้ากับแอพ Android ของเราเพื่อเพิ่มการรองรับ QUIC การบูรณาการดำเนินการในลักษณะที่จะลดต้นทุนการโยกย้ายให้มากที่สุด แทนที่จะแทนที่สแต็คเครือข่ายเก่าที่ใช้ไลบรารีโดยสิ้นเชิง เราได้รวม Cronet ภายใต้กรอบงาน OkHttp API ด้วยการผสานรวมด้วยวิธีนี้ เราจึงหลีกเลี่ยงการเปลี่ยนแปลงการโทรผ่านเครือข่ายของเรา (ซึ่งใช้โดย ) ในระดับ API
เช่นเดียวกับแนวทางสำหรับอุปกรณ์ Android เราได้นำ Cronet ไปใช้กับแอพ Uber บน iOS โดยสกัดกั้นการรับส่งข้อมูล HTTP จากเครือข่าย ใช้ . นามธรรมนี้จัดทำโดย iOS Foundation จัดการข้อมูล URL เฉพาะโปรโตคอลและทำให้แน่ใจว่าเราสามารถรวม Cronet เข้ากับแอปพลิเคชัน iOS ของเราได้โดยไม่มีค่าใช้จ่ายในการย้ายข้อมูลจำนวนมาก
เอามาจาก บทความของอูเบอร์
บนแบ็กเอนด์ พวกเขาจับการเชื่อมต่อ QUIC ผ่าน Google Cloud lb ซึ่ง ตั้งแต่กลางปี 2018
ไม่น่าแปลกใจเลยที่ Google Cloud ทำงานได้ดีกับโปรโตคอลที่ Google พัฒนาขึ้น แต่ทางเลือกอื่นคืออะไร
Nginx
ไม่นานมานี้ CloudFlare nginx (ซึ่งไม่รองรับ HTTP/3 ตามค่าเริ่มต้น) ด้วยเครื่องมือ Quiche การใช้งานนี้มีให้ใช้งานในรูปแบบไฟล์ .patch ไฟล์เดียว ซึ่งมาพร้อมกับบทช่วยสอนการติดตั้ง:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchที่นี่คุณสามารถเชื่อมต่อโมดูลของคุณได้หากจำเป็น
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeสิ่งที่เหลืออยู่คือการเปิดใช้งานการสนับสนุน HTTP/3
events {
worker_connections 1024;
}
http {
server {
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Enable all TLS versions (TLSv1.3 is required for QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Request buffering in not currently supported for HTTP/3.
proxy_request_buffering off;
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
}
ยังไม่สามารถเชื่อมต่อผ่าน HTTP/3 ในเบราว์เซอร์ทั่วไปได้ แต่คุณสามารถใช้งานได้ และวิ่งไปพร้อมกับธง --enable-quicไปที่เซิร์ฟเวอร์ของคุณหรือตัวอย่างเช่น ไซต์ quic.rocks และดูประเภทการเชื่อมต่อในเครื่องมือสำหรับนักพัฒนา:
แทนที่จะเขียนเป็น HTTP/3 http2+quic/99แต่โดยพื้นฐานแล้วมันเป็นสิ่งเดียวกัน
เทคโนโลยีอื่นๆ
- QUIC ยังสนับสนุน (ซึ่งเชื่อมต่อกับ Facebook ผ่าน HTTP/3 พร้อมการประโคมข่าวที่ยอดเยี่ยม) และก้าวหน้า . Apache ยังทำไม่ได้ แต่งานอยู่ระหว่างดำเนินการ .
- อัปเดตวันที่ 21 มกราคม
- เมื่อวันก่อน Microsoft เปิดทำการ ซึ่งฟังก์ชั่นบางอย่างจากมาตรฐาน IETF ยังไม่พร้อมใช้งาน แต่นี่เป็นความก้าวหน้าครั้งใหญ่อยู่แล้ว
ข้อสรุป
ความสนใจใน QUIC นั้นไม่แน่นอน แต่กำลังเพิ่มขึ้น และกำลังดำเนินการเพื่อสร้างมาตรฐาน การใช้งานโปรโตคอลใหม่ปรากฏขึ้นเกือบทุกเดือน และทุกปีมีนักพัฒนาจำนวนมากขึ้นเรื่อยๆ ที่เชื่อมั่นว่า QUIC คืออนาคต เป็นไปได้ที่จะรวมโปรโตคอลไว้ใน TCP stack เวอร์ชันอนาคตซึ่งหมายความว่าไม่ช้าก็เร็วอินเทอร์เน็ตทั้งหมดจะย้ายไปสู่การเชื่อมต่อที่เสถียรและรวดเร็วยิ่งขึ้น
ตอนนี้คุณสามารถกำหนดค่าการโต้ตอบ QUIC สำหรับโครงสร้างพื้นฐานของคุณหรือแม้กระทั่งมอบให้กับเบราว์เซอร์ - พวกเขากำลังวางแผนที่จะเพิ่มการรองรับโปรโตคอลและสถิติที่น่าเศร้ากับ caniuse จะร่าเริงมากขึ้น
ที่มา: will.com