เทคโนโลยี QUIC ยังไม่เร็วพอ แม้บนอินเทอร์เน็ตความเร็วสูง

 (arxiv.org)
2 คะแนน โดย GN⁺ 2024-10-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในสภาพแวดล้อมที่รองรับ 500Mbps~1Gbps ขึ้นไป ต่อการเชื่อมต่อ เช่น เครือข่ายแบบมีสายความเร็วสูง, WiFi 6/7 และ 5G สแตก UDP+QUIC+HTTP/3 ให้ อัตราการส่งข้อมูลต่ำกว่าได้สูงสุด 45.2% เมื่อเทียบกับ TCP+TLS+HTTP/2
  • ไม่ใช่แค่การดาวน์โหลดไฟล์อย่างง่ายเท่านั้น แต่ในการทดสอบกับ Chrome, Edge, Firefox, Opera และทั้งเดสก์ท็อปกับมือถือ ยิ่ง แบนด์วิดท์สูงขึ้น ช่องว่างด้านประสิทธิภาพระหว่าง QUIC กับ HTTP/2 ก็ยิ่งกว้างขึ้น
  • จากการติดตามแพ็กเก็ตและโปรไฟล์ทั้งในเคอร์เนลและ user space พบว่าคอขวดอยู่ใกล้กับ โอเวอร์เฮดการประมวลผลฝั่งรับ มากกว่าฝั่งส่ง โดยการรับ QUIC ทำให้เกิดแพ็กเก็ตมากขึ้นและมีการประมวลผล ACK ใน user space มากขึ้น
  • ผลกระทบในระดับแอปพลิเคชันนำไปสู่การลดลงของบิตเรต DASH video สูงสุด 9.8% และ เวลาโหลดหน้าเว็บนานขึ้น 3.0% โดยเฉลี่ยใน 100 เว็บไซต์ตัวแทน
  • แนวทางบรรเทาต้องอาศัยการนำ UDP GRO ฝั่งรับมาใช้, การปรับปรุง GSO/GRO ให้เป็นมิตรกับ QUIC, การปรับปรุงลอจิกรับข้อมูล และการใช้หลาย CPU core แต่ความหลากหลายของอุปกรณ์ไคลเอนต์และระบบปฏิบัติการทำให้การนำไปใช้จริงทำได้ยาก

ช่องว่างด้านประสิทธิภาพของ QUIC ที่ปรากฏบนเครือข่ายความเร็วสูง

  • QUIC เป็นโปรโตคอลชั้นขนส่งแบบ multiplexed บน UDP และถูกมาตรฐานโดย IETF ให้เป็นพื้นฐานการขนส่งของ HTTP/3
  • บริษัทหลายแห่ง เช่น Google, Akamai, Meta และ Cloudflare ได้นำ QUIC ไปใช้งานเชิงพาณิชย์มาตั้งแต่ปี 2013 และถูกจับตามองว่าเป็นตัวเปลี่ยนเกมด้านประสิทธิภาพเว็บร่วมกับ HTTP/3
  • งานศึกษาประสิทธิภาพ QUIC ก่อนหน้านี้มีความหลากหลายทั้งด้าน implementation, สภาพแวดล้อมการประมวลผล และเงื่อนไขเครือข่าย และหลายงานมุ่งเน้นกรณีใช้งานที่มี throughput ต่ำ
  • จุดโฟกัสของการวัดครั้งนี้คือพฤติกรรมของ QUIC บนเครือข่ายความเร็วสูงที่ไปถึง 500Mbps ขึ้นไป หรือ 1Gbps ขึ้นไป ต่อการเชื่อมต่อ เช่น ลิงก์มีสายความเร็วสูง, WiFi 6/7 และ 5G
  • สิ่งที่นำมาเปรียบเทียบไม่ใช่แค่โปรโตคอลเดี่ยว แต่เป็นทั้งสแตกทั้งหมด
    • ฝั่ง QUIC: UDP+QUIC+HTTP/3
    • ฝั่งเดิม: TCP+TLS+HTTP/2
    • เพื่อความกระชับ จะเรียกแต่ละฝั่งว่า QUIC และ HTTP/2

ความแตกต่างที่พบจากการทดลองดาวน์โหลดไฟล์

  • ในการทดลองดาวน์โหลดไฟล์แบบง่ายโดยใช้ cURL และ quic_client ที่อิง Chromium มีการเปรียบเทียบภายใต้เงื่อนไขเดียวกันทั้งอัลกอริทึมควบคุมความหนาแน่นของเครือข่าย, การตั้งค่าเซิร์ฟเวอร์ และสภาพเครือข่าย
  • เมื่อแบนด์วิดท์ค่อนข้างต่ำที่ ต่ำกว่าประมาณ 600Mbps ประสิทธิภาพของ QUIC และ HTTP/2 ใกล้เคียงกัน แต่เมื่อแบนด์วิดท์สูงกว่านั้น throughput ของ QUIC ต่ำกว่า HTTP/2 ได้สูงสุด 15.7%
  • ยิ่งแบนด์วิดท์สูงขึ้น ช่องว่างด้านประสิทธิภาพก็ยิ่งชัดเจนขึ้น และระหว่างการรับแพ็กเก็ต QUIC ใช้ CPU สูงกว่า HTTP/2 อย่างมากบนเครื่องไคลเอนต์รุ่นใหม่
  • ในการทดสอบกับเบราว์เซอร์หลัก ช่องว่างยิ่งกว้างขึ้น
    • เบราว์เซอร์ที่ทดสอบคือ Chrome, Edge, Firefox, Opera
    • บน Chrome เมื่อแบนด์วิดท์เกินประมาณ 500Mbps QUIC เริ่มตามหลัง
    • เมื่อแบนด์วิดท์แตะ 1Gbps QUIC ช้ากว่า HTTP/2 ถึง 45.2%
    • บนไคลเอนต์ที่อ่อนกำลังกว่าอย่างมือถือ ช่องว่างยิ่งมากขึ้น

ผลกระทบต่อเว็บแอปพลิเคชัน

  • การลดลงของประสิทธิภาพไม่ได้จำกัดอยู่แค่การส่งไฟล์ขนาดใหญ่ แต่ยังปรากฏในแอปพลิเคชันที่มีรูปแบบทราฟฟิกไม่ต่อเนื่องด้วย
  • เมื่อนำส่ง DASH video chunk บน Ethernet ความเร็วสูงและ 5G, QUIC ให้ วิดีโอบิตเรตต่ำกว่า HTTP/2 ได้สูงสุด 9.8%
  • การลดลงของ QoE นี้จะปรากฏก็ต่อเมื่อแบนด์วิดท์พื้นฐานสูงเพียงพอเท่านั้น
    • บน 4G ผลกระทบถูกกลบ
    • บน 5G ผลกระทบปรากฏชัด
  • ในการท่องเว็บ ค่าเฉลี่ยของ page load time (PLT) ของ QUIC นานกว่า HTTP/2 3.0% ใน 100 เว็บไซต์ตัวแทน
  • ในกรณีปลายหางยาว ช่องว่างของเวลาโหลดหน้าอาจ เกิน 50% ได้เช่นกัน

สาเหตุของคอขวด: การประมวลผลฝั่งรับและ ACK ใน user space

  • จากการติดตามแพ็กเก็ตและข้อมูลประสิทธิภาพ พบว่าไคลเอนต์ QUIC รับแพ็กเก็ตมากกว่าการดาวน์โหลดผ่าน HTTP/2 อย่างมาก
  • เมื่อ QUIC รับข้อมูลด้วยอัตราการส่งสูง ความหน่วงระหว่างแพ็กเก็ตข้อมูลที่เข้ามากับแพ็กเก็ต ACK ที่ตอบกลับจะเพิ่มขึ้น ทำให้เวลาในการประมวลผลแพ็กเก็ต QUIC สูงขึ้น
  • การสังเกตทั้งสองชี้ว่าต้นตอของประสิทธิภาพ QUIC ที่ลดลงบนอินเทอร์เน็ตความเร็วสูงอยู่ที่ ข้อจำกัดความสามารถในการประมวลผลฝั่งรับ
  • เหตุผลที่ฝั่งรับถูกชี้ว่าเป็นคอขวดมีสองข้อ
    • โดยทั่วไปเซิร์ฟเวอร์มีพลังประมวลผลสูงกว่าไคลเอนต์อย่างเดสก์ท็อป โน้ตบุ๊ก และสมาร์ตโฟน
    • การออกแบบของ QUIC เองทำให้การประมวลผลการรับข้อมูลมีความยากเฉพาะตัว
  • การทำโปรไฟล์เชิงลึกพบสาเหตุหลักสองประการ
    • แพ็กเก็ตข้อมูลมากเกินไป
      • เมื่อต้องดาวน์โหลดไฟล์เดียวกัน UDP stack ในเคอร์เนลทำให้เกิดการอ่านแพ็กเก็ต netif_receive_skb มากกว่า TCP อย่างมาก
      • ไม่มี implementation ของ QUIC ที่ตรวจสอบในการศึกษานี้ใช้ UDP generic receive offload หรือ UDP GRO
      • UDP GRO คือวิธีที่โมดูลชั้นลิงก์รวม UDP datagram ที่รับเข้ามาหลายรายการให้เป็น datagram ขนาดใหญ่หนึ่งรายการก่อนส่งต่อไปยังชั้นขนส่ง
      • สิ่งนี้ตัดกันกับกรณีที่ TCP segmentation offload ถูกใช้อย่างแพร่หลาย และ GSO ซึ่งเป็น offload ฝั่งส่งของ UDP เพิ่งได้รับความสำคัญมากขึ้นในช่วงหลัง
    • การประมวลผล ACK ใน user space
      • ใน user space, QUIC มีโอเวอร์เฮดสูงกว่าในการประมวลผลแพ็กเก็ตที่รับและการสร้างการตอบกลับ
      • สาเหตุรวมถึงแพ็กเก็ตจำนวนมากเกินไปที่ส่งมาจากเคอร์เนล, การประมวลผล QUIC ACK ใน user space และการขาด optimization บางอย่าง เช่น delayed ACK ของ QUIC

การวัดเบื้องต้นและทิศทางการบรรเทา

  • การทดลองเบื้องต้นในการดาวน์โหลดไฟล์ 1GB บนเบราว์เซอร์ Chrome แสดงให้เห็นว่าเมื่อเปิดใช้ QUIC เวลาในการดาวน์โหลดเพิ่มขึ้นเกือบเป็นสองเท่า
  • ผลตัวอย่างเป็นค่าเฉลี่ยจากการรัน 10 ครั้ง
    • เดสก์ท็อป Ethernet: HTTP/2 9.32 วินาที, HTTP/3 18.60 วินาที เพิ่มขึ้น 99%, การใช้ CPU เพิ่มจาก 77.5% เป็น 96.9%
    • Pixel 5 low-band 5G: HTTP/2 37.11 วินาที, HTTP/3 78.65 วินาที เพิ่มขึ้น 112%, การใช้ CPU เพิ่มจาก 121.55% เป็น 161.77%
    • Pixel 5 mmWave 5G: HTTP/2 30.10 วินาที, HTTP/3 63.20 วินาที เพิ่มขึ้น 110%, การใช้ CPU เพิ่มจาก 128.43% เป็น 165.20%
  • การวัดการใช้ CPU บนเดสก์ท็อปอ้างอิงจากบริการเครือข่ายของเบราว์เซอร์ ส่วนบนสมาร์ตโฟนอ้างอิงจากทั้งโปรเซสของเบราว์เซอร์
  • ค่า CPU usage ที่เกิน 100% หมายความว่าโปรเซสของเบราว์เซอร์ใช้มากกว่าหนึ่งคอร์บนระบบแบบ multi-core
  • แนวทางบรรเทาที่เสนอคือการนำ UDP GRO ฝั่งรับมาใช้, การปรับปรุง GSO และ GRO ให้เป็นมิตรกับ QUIC, การปรับปรุงลอจิกรับข้อมูลฝั่ง QUIC และการรับข้อมูล QUIC ผ่านหลาย CPU core
  • เนื่องจากโฮสต์ฝั่งไคลเอนต์มีความหลากหลายสูงกว่าเซิร์ฟเวอร์ ทั้งพีซี อุปกรณ์พกพา อุปกรณ์ embedded และระบบปฏิบัติการหลากหลายชนิด การทำให้แนวทางบรรเทาเกิดขึ้นจริงจึงมีความยากในทางปฏิบัติ
  • ข้อมูลการวัดและซอร์สโค้ดถูกเผยแพร่พร้อมกับงานวิจัยดังกล่าว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-20
ความคิดเห็นจาก Hacker News

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

    • ตอนนี้กำลังทำโปรเจกต์ที่ เอา JavaScript ออกจากแอป React อยู่ และสนุกมาก
      มันเร็วขึ้นและแข็งแรงทนทานขึ้นมาก แถมความไม่ตรงกันของสถานะระหว่างฟรอนต์เอนด์กับแบ็กเอนด์ก็หายไป
      เพื่อความสะดวก ยังยอมให้มี JavaScript ขั้นต่ำอยู่ ตอนนี้มีอยู่ไม่กี่ร้อยบรรทัด และยังจะเพิ่มอีกเล็กน้อยเพื่อให้ยังดูเหมือนแอปแบบหน้าเดียว
      ด้วยวิธีนี้จะลบ React ได้ราว 40,000 บรรทัด และ Kotlin ราว 20,000 บรรทัด แต่ต้องเขียนโค้ดแบ็กเอนด์ใหม่ประมาณ 30,000 บรรทัด
      ถึงอย่างนั้นก็ยังชอบ
    • ช่วงใกล้เรียนจบมหาวิทยาลัย ผมเชื่อตามกระแส การพัฒนาเว็บที่อิงเฟรมเวิร์ก เต็มที่ และคิดว่างานพัฒนาเว็บแบบ “องค์กร” ต้องทำแบบนั้น
      เลยลองย้ายโฮมเพจของตัวเองไปเป็นเวอร์ชัน VUE.JS แบบสแตติกเพื่อเก็บประสบการณ์ แต่การส่งชื่อตัวแปรเป็นสตริงเพื่อผูกวิวกับสถานะดูแปลก การขยายสภาพแวดล้อมบิลด์ก็ซับซ้อนเกินจำเป็น ทุกอย่างช้าและต้องทำได้เฉพาะตามวิธีหนึ่ง ๆ
      ตอนนั้นคิดว่าทุกคนใช้กันก็น่าจะถูกแล้ว แต่ตอนนี้หลุดจากมุมมองนั้นมาได้ และเวอร์ชันใหม่ก็จบด้วย HTML ดิบกับเทมเพลตของตัวสร้างไซต์สแตติก
      ขนาด HTML ลดลง 90%, ปริมาณการใช้ JS ลดลง 97% และเวลาบิลด์ลดจาก 20 วินาทีเหลือ 2 วินาที
      ประสบการณ์ผู้ใช้ก็ดีขึ้น และหลังเวอร์ชันใหม่ จำนวนการเข้าชมก็เพิ่มขึ้น 30%
      ถ้าใช้เว็บให้น้อยลง เว็บก็จะเจ๋งขึ้นได้มาก
    • เว็บไซต์ที่เบาไม่อาจกลายเป็น เรซูเม่ที่หรูหรา ได้
      ฝั่งแบ็กเอนด์ ทุกวันนี้ไข่ทองคำก็คือการขายไมโครเซอร์วิสผ่านผลิตภัณฑ์ headless SaaS ที่เชื่อมต่อด้วย API และพูดทำนองว่าประสิทธิภาพจะดีขึ้นเองแน่นอน
      https://macharchitecture.com/
      ถ้าผู้คนอยากซื้อพลั่วแบบนั้น โลก IT ก็มีแต่ต้องตุนพลั่วแบบนั้นไว้
    • โปรเจกต์ส่วนตัวทั้งหมดทำด้วย HTML ที่เรนเดอร์บนเซิร์ฟเวอร์
      บล็อกเป็นไซต์ Hugo ที่เรนเดอร์แบบสแตติกจึงไม่มี JS เลย ส่วนโปรเจกต์ใช้ Rails กับ HTML ที่เรนเดอร์บนเซิร์ฟเวอร์ และมี JS ขั้นต่ำเฉพาะฟีเจอร์ที่มีแล้วดี
      แม้ไม่มี JS ก็ยังทำงานได้
      อาจพูดแบบนี้เพราะเป็นไซต์ของตัวเอง แต่ประสบการณ์ดีกว่าเว็บส่วนใหญ่มาก และเราสูญเสียอะไรไปมากเกินไปแล้ว
    • ตัวอย่างหน้าเว็บทุกวันนี้ที่เปิดขึ้นแทบจะทันที: https://www.mcmaster.com/

  • Google เคยทำ Speedtest ที่ใช้ JS ล้วนมาก่อน
    ตอนนั้น Ookla ยังใช้ Flash อยู่ จึงไม่ทำงานบน Chromebook และกลายเป็นปัญหาสำหรับเจ้าหน้าที่ติดตั้งในการตรวจสอบสถานะการติดตั้ง
    ระหว่างนั้นได้เรียนรู้มากมายว่า TCP ตอบสนองต่อปัจจัยต่าง ๆ อย่างไร
    ผลลัพธ์ในบทความนี้แทบจะเป็นไปตามที่คาดไว้ เพราะเป็นการผลักการควบคุมการไหลจากเคอร์เนล และอาจรวมถึงอะแดปเตอร์เครือข่าย ไปยัง user space
    TCP มีการควบคุมการไหลและการรับประกันลำดับ ส่วน QUIC ก็เหมือนทำให้ต้องจัดการสิ่งนั้นเอง
    แน่นอนว่ามีเหตุผลที่ดีสำหรับเรื่องนี้
    การควบคุมความแออัดของ TCP ขึ้นชื่อว่าตามความเร็วการเชื่อมต่อสมัยใหม่ไม่ทัน และมีอัลกอริทึมใหม่อย่าง BBR ออกมาแล้ว แต่ก็มาพร้อมต้นทุน [1]
    สิ่งสำคัญที่มักขาดหายไปบ่อยเกินไปในการทดสอบเครือข่ายหรือเว็บแอปคือ เวลาแฝง
    ถ้าอยู่ในเอเชียหรือออสเตรเลีย ก็น่าจะรู้ว่าเวลาแฝงไป-กลับ 100ms นั้นร้ายแรงแค่ไหน
    มันสามารถทำให้สิ่งที่เคยตอบสนองได้อย่างสมบูรณ์กลายเป็นใช้งานแทบไม่ได้เลย และเพราะหน้าต่างรับส่งข้อมูล มันยังลดแบนด์วิดท์ที่การเชื่อมต่อรองรับได้ อีกทั้งทำให้การควบคุมข้อผิดพลาดและความแออัดตอบสนองช้าลงด้วย
    หากกำลังทดสอบเครือข่ายหรือเว็บแอป ขอแนะนำอย่างยิ่งให้มีการทดสอบที่สุ่มเพิ่มเวลาแฝงเข้าไป 100ms [2]
    ดังนั้นโอเวอร์เฮดของ QUIC อาจไม่ได้สำคัญจริง ๆ ก็ได้
    เพราะแบนด์วิดท์ที่ใช้งานได้จริงบนการเชื่อมต่อ TCP เดี่ยวหรือสตรีม QUIC เดี่ยวอาจต่ำกว่าแบนด์วิดท์ดิบจริงมาก
    พูดอีกแบบคือ แม้จะมีข้อมูลเพิ่มขึ้น 45% แต่ถ้าการจัดการควบคุมความแออัดเองทำให้ความเร็วที่ใช้งานได้จริงระหว่างสองจุดสูงขึ้น ก็อาจคุ้มค่า
    [1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
    [2]: https://bencane.com/simulating-network-latency-for-testing-i...

    • ผมทดสอบในสภาพแวดล้อมจริงกับแอปโอนไฟล์ของผม[1] ไปมาก และตอนแรกคาดว่า QUIC จะยอดเยี่ยมมาก แต่สุดท้ายผิดหวังด้วยหลายเหตุผลและกลับไปใช้ TCP
      มองย้อนกลับไปก็ชัดเจนอยู่แล้ว แต่ใน TCP เราแค่บอกว่า “เคอร์เนล ช่วยส่งบัฟเฟอร์ก้อนใหญ่นี้ให้หน่อย” ก็พอ ขณะที่ UDP เป็นแบบแลกเปลี่ยนแพ็กเก็ต แม้แต่การส่ง 0 ก็มีต้นทุน CPU สูงจากการสลับโหมดบนระบบปฏิบัติการและฮาร์ดแวร์ผู้บริโภคส่วนใหญ่
      มีวิธีอ้อมอยู่ แต่ก็ไม่ง่าย และจากประสบการณ์ของผมยังไม่พร้อมนัก อีกทั้งยังจำกัดตัวเลือกภาษา ไลบรารี และแพลตฟอร์มที่จะใช้ด้วย
      แถมยังเห็นว่า throughput ลดลงมากเมื่อใช้ MacBook ด้วยแบตเตอรี่ ซึ่งน่าจะเกี่ยวข้องกับคอร์ประหยัดพลังงาน
      อย่างที่สอง QUIC ทำการควบคุมความแออัดได้ไม่ดี
      ผมใช้ quic-go ดังนั้นอาจต่างกันไปตามสภาพแวดล้อม แต่การปรับแต่งใด ๆ ก็ไม่ได้ช่วยมากนัก และเมื่ออยู่ร่วมกับ TCP stream แล้ว TCP จะเอาแบนด์วิดท์ไปได้มากกว่า
      อย่างที่สาม API แปลก
      ตัว QUIC เองมีหลายสตรีม จึงไม่ใช่ตัวแทนแบบเสียบแทน TCP ได้ตรง ๆ
      เพียงแต่มีเจตนาจะทำให้ HTTP/3 เป็นตัวแทนแบบเสียบแทนได้ในเลเยอร์ที่สูงกว่า ซึ่งผมยังไม่ได้ลองจึงพูดไม่ได้
      ถ้าทำงานในระดับสตรีม ก็เป็นเรื่องที่ควรนึกไว้
      สรุปแล้วรู้สึกเหมือนแพ้พอสมควร แต่พร้อมกันนั้นก็เกิดความเคารพขึ้นใหม่ต่อการปรับแต่งและความทนทานของเพื่อนเก่าอย่าง TCP
      เป็นเทคโนโลยีที่น่าทึ่งจริง ๆ และระบบปฏิบัติการก็มอบให้ใช้ฟรีเสมอ
      ปัญหาหลักบางส่วนของ TCP ก็ไม่ได้เป็นข้อบกพร่องด้านการออกแบบเท่าไร แต่เป็นค่าเริ่มต้นที่อนุรักษนิยม หรือเป็นมรดกตกค้างมากกว่า
      เช่นข้อจำกัดบัฟเฟอร์ของ Linux, Nagle และทำนองนั้น
      ถ้าสามารถปรับปรุง TCP ไปเลย แทนที่จะประดิษฐ์ล้อขึ้นมาใหม่ ก็คงดี
      [1]: https://payload.app/
    • คำกล่าวที่ว่า “เพราะเป็นการผลักการควบคุมการไหลจากเคอร์เนลและอะแดปเตอร์เครือข่ายไปยัง user space” ไม่ใช่ คุณสมบัติโดยเนื้อแท้ของโปรโตคอล QUIC แต่เป็นเพียงการตัดสินใจด้าน implementation
      เป็นการตัดสินใจที่จำเป็นเพื่อให้ QUIC เริ่มต้นได้ แต่เมื่อมันมีอยู่แล้ว ก็อาจนำกลับมาทบทวนได้
      ไม่มีอุปสรรคทางเทคนิคในการ implement QUIC ในเคอร์เนล และถ้ามีข้อได้เปรียบด้านประสิทธิภาพมากพอ ใครสักคนก็น่าจะทำเกือบแน่นอนในไม่ช้า
    • จากมุมมองของคนที่เวลาแฝงจากจีนไปยังเซิร์ฟเวอร์นอกจีนมักเกิน 300ms ผม สนับสนุน QUIC อย่างมาก
      ความต่างกันราวฟ้ากับดิน
    • ในแท็บ Network ของ Chrome Developer Tools สามารถลดคุณภาพการเชื่อมต่อได้
      มีพรีเซ็ต Slow/Fast 4G, 3G และสามารถสร้างพรีเซ็ตแบบกำหนดเองที่ระบุความเร็วดาวน์โหลด/อัปโหลด, เวลาแฝงเป็น ms, อัตราการสูญหายของแพ็กเก็ต, ความยาวคิวแพ็กเก็ต และเปิดการจัดเรียงแพ็กเก็ตใหม่ได้
    • มีสมมติฐานแฝงว่า user space ช้า แต่ TCP/IP stack ประสิทธิภาพสูง ที่เร็วที่สุดบางส่วนหรือส่วนใหญ่ก็ถูกสร้างใน user space

  • Daniel Stenberg ผู้สร้างและผู้ดูแล curl เคยเขียนเกี่ยวกับ HTTP/3 ใน curl ไว้เมื่อไม่กี่เดือนก่อน: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
    หนึ่งในสิ่งที่เขาเน้นคือ การใช้ CPU ที่สูงกว่าของ HTTP/3 และ CPU ถึงขั้นกลายเป็นข้อจำกัดของ throughput
    เลยสงสัยว่าในนี้เกิดจากความยังไม่สุกงอมของ implementation แค่ไหน และเกิดจากคุณสมบัติของการออกแบบ QUIC เองแค่ไหน

    • คำแนะนำสองข้อในนั้นพูดถึงการปรับปรุง implementation ฝั่งรับ คือการ optimize และทำ multithreading จึงดูเป็นสัญญาณว่า implementation ยังไม่สุกงอม
      คำแนะนำข้อที่สามคือ UDP GRO ซึ่งเป็นการแก้ kernel และถ้าดีที่สุดก็คือฮาร์ดแวร์ NIC เพื่อรวมแพ็กเก็ต UDP ขาเข้า ลดงานต่อแพ็กเก็ต แล้วเปลี่ยนเป็นงานต่อกลุ่มแทน
      TCP มีสิ่งนี้อยู่แล้ว และฝั่งส่งก็มีสิ่งคล้าย ๆ กัน เช่น TSO และ GSO ของ Linux
      สิ่งนี้ก็ให้ความรู้สึกว่ายังไม่สุกงอมเหมือนกัน แต่ถ้าคิดถึงความเป็นไปได้ว่าเป็นเพราะขาดฟีเจอร์ฮาร์ดแวร์ ก็อาจแก้ได้ยากกว่า
      บทคัดย่อพูดถึงต้นทุนของวิธี ACK ของ QUIC แต่ผมยังไม่ได้ดูข้ออ้างนั้นโดยละเอียด
      อีกฟีเจอร์หนึ่งที่พบได้ในเซิร์ฟเวอร์ยุคใหม่ที่ใช้ TCP คือการ offload TLS ไปให้ฮาร์ดแวร์
      เรื่องนี้ดูสำคัญกว่าในเซิร์ฟเวอร์ที่ส่ง TCP stream จำนวนมากพร้อมกัน
      บน Linux ทำได้โดยใช้ user-space networking หรือผ่าน ‘kernel tls’ และถ้าเป็นไปได้ก็จะ offload ไปยังฮาร์ดแวร์
      ฟีเจอร์นี้ยังเกี่ยวข้องกับความสามารถเฉพาะของ Linux ที่ทำให้แบ่ง TCP stream เป็น ‘message’ แล้วส่งไปยังเธรดอื่นได้ด้วย แต่ไม่รู้ว่าสามารถส่งต่อ message ด้านหลังล่วงหน้าได้หรือไม่เมื่อแพ็กเก็ตก่อนหน้าสูญหาย
    • ผมเข้าใจมาตลอดว่า QUIC ถูกออกแบบมาสำหรับการเชื่อมต่อที่ไม่ได้รับประกันว่าจะเสถียรหรือเร็ว เช่น เครือข่ายมือถือ
      ไม่เคยรู้สึกว่ามันตั้งใจจะทำให้ทุกการเชื่อมต่อเร็วขึ้น
      ถ้ามองจากมุมนั้น การแลกเปลี่ยนข้อดีข้อเสียก็ดูสมเหตุสมผล
      ผมไม่ใช่ผู้เชี่ยวชาญ ดังนั้นหวังว่าคนที่รู้ดีกว่าจะช่วยแก้ให้
    • คำว่า “ความยังไม่สุกงอมของ implementation” ตรงนี้น่าสนใจ
      QUIC ถูกสร้างขึ้นเพราะไม่มีทางเลยที่จะทำให้ฮาร์ดแวร์และ middleware ทุกชิ้นทั่วอินเทอร์เน็ต รวมถึงทุกอย่างรอบ ๆ รองรับมาตรฐาน TCP หรือ TLS ใหม่ได้
      ดังนั้น QUIC จึงเป็นทางออกที่สวยงามในการวาง มาตรฐาน transport ใหม่บน UDP ทับฮาร์ดแวร์อินเทอร์เน็ตแบบ legacy
      ในโลกอุดมคติ เราคงสร้างมาตรฐาน TCP และ TLS ใหม่ แล้วเปลี่ยนหรืออัปเดตเราเตอร์และฮาร์ดแวร์อินเทอร์เน็ตทั่วโลกทั้งหมด เพื่อให้ implement ได้โดยใช้ CPU ต่ำกว่า
    • ผลลัพธ์ด้านประสิทธิภาพนั้นทำให้ผมแปลกใจเหมือนกัน
      ในการทดสอบ quiche ที่ติด CPU ได้ต่ำกว่า 200MB/s ส่วน nghttp2 เกิน 900MB/s
      สงสัยว่า CPU ถูก throttle หรือเปล่า
      ถ้า implementation ของ HTTP/3 ใช้ CPU มากกว่า 4 เท่า ก็น่าสนใจ แต่ถ้าค่าสัมบูรณ์เดิมต่ำมากอยู่แล้ว ก็อาจไม่ใช่ปัญหาใหญ่เสมอไป

  • ประเด็นหลักคือส่วนที่ว่า “บนอินเทอร์เน็ตที่เร็ว สแตก UDP+QUIC+HTTP/3 ทำให้อัตราข้อมูลลดลงได้สูงสุด 45.2% เมื่อเทียบกับ TCP+TLS+HTTP/2” แต่ถึงยังไม่ได้อ่าน paper ทั้งฉบับ ในบทนำดูเหมือนจะถือว่าต่ำกว่า 600Mbit/s เป็น อินเทอร์เน็ตช้า

    • พูดอีกอย่างคือ ให้เปิด HTTP/3 + QUIC ในช่วง client browser <> edge และจำกัดช่วง edge <> origin ให้เป็น HTTP/2 หรือ HTTP/1
      ถ้ายก Cloudflare เป็นตัวอย่าง ก็รองรับ QUIC เฉพาะระหว่าง client <> edge เท่านั้น ไม่รองรับสำหรับการเชื่อมต่อไปยัง origin
      ถ้าการเชื่อมต่อ edge <> origin สามารถ reuse ได้ เสถียร และ “เร็ว” ก็สมเหตุสมผล
      https://developers.cloudflare.com/speed/optimization/protoco...
    • ส่วนที่สำคัญพอ ๆ กันคือสาเหตุคือ overhead การประมวลผลฝั่งรับที่สูง โดยเฉพาะแพ็กเก็ตข้อมูลที่มากเกินไปและ ACK ของ QUIC ใน user space
      ฟังดูไม่ได้เหมือนเป็นปัญหาพื้นฐานของตัว protocol เอง
    • ผมมองว่าการลดลงของ throughput น่าจะมาจาก ปัญหา latency ที่เกิดจาก implementation ของเบราว์เซอร์เป็นหลัก ซึ่งไม่มีประสิทธิภาพหรือมี system call มากเกินไป
      แต่ปัญหา latency แบบนี้ไม่ได้เพิ่มการใช้แบตเตอรี่มากนัก ต่างจากปัญหาการใช้ CPU ที่ทำให้ CPU ต้อง boost
      ในการสื่อสารระหว่างเซิร์ฟเวอร์ก็ไม่ใช่ปัญหาเช่นกัน
      โดยพื้นฐานแล้ว มันคือระดับที่การส่งข้อมูลแบนด์วิดท์สูงบนอุปกรณ์ผู้ใช้ปลายทาง “ช้าลง” เมื่อใช้การเชื่อมต่อที่เร็วมากแม้ในปี 2024
      ความเร็วที่พูดถึงตรงนี้ไม่ได้อิงจากความเร็วที่ซื้อจากโฆษณา แต่เป็นความเร็วใช้งานจริงจากอุปกรณ์ไปถึงเซิร์ฟเวอร์
      ไม่ได้หมายความว่า paper นี้ไร้ประโยชน์ implementation ของเบราว์เซอร์ควรถูกปรับปรุง และ paper ก็แสดงให้เห็นจุดนั้นได้ดี
      แต่อย่างไรก็ดี ชื่อ paper แทบจะเป็น clickbait 100%
    • การเชื่อมต่ออินเทอร์เน็ตย่อมจะเร็วขึ้นต่อไปอย่างหลีกเลี่ยงไม่ได้
      ในช่วงที่อินเทอร์เน็ตระดับกิกะบิตกำลังแพร่หลาย การเปลี่ยนไปใช้วิธีส่งข้อมูลที่ช้ากว่าย่อมเป็นความผิดพลาดอย่างชัดเจน
    • ในสวิตเซอร์แลนด์ สามารถใช้ 25Gbit/s ได้ในราคาเดือนละ 60 ดอลลาร์
      อีก 30 ปีข้างหน้ามันจะเร็วขึ้นอีก และถ้าต้องใช้ protocol ที่เก่ากว่าเพื่อใช้ความเร็วสายให้เต็ม ก็คงเป็นเรื่องโง่มาก

  • เมื่อเดือนกันยายนก็มีโพสต์เดียวกันนี้ขึ้นมาแล้ว: QUIC is not quick enough over fast internet (acm.org)
    https://news.ycombinator.com/item?id=41484991 (327 ความคิดเห็น)

    • โดยส่วนตัวแล้ว ผมสรุปว่าไม่ควรปล่อยให้ Google ผ่าน Chromium ออกแบบและบังคับใช้ Internet protocol แบบแทบจะฝ่ายเดียว
      Brave/Vivaldi/Opera ฯลฯ ต้องเลือกอย่างมีสติ
    • QUIC เป็นเทคโนโลยีเกี่ยวกับการที่บริษัทโฆษณาต้องการ รับประกันการส่งโฆษณา ไปถึงผู้บริโภค
      ทำนองว่าขอแค่โฆษณาไปถึงเร็ว อย่างอื่นไม่สำคัญ

  • เรื่องนี้ฟังดูแปลกมากจริง ๆ
    ผมเคยทำความเร็วได้ 900mbps ด้วย QUIC+HTTP/3 อย่างเดียว และแม้แต่ด้วย QUIC อย่างเดียวด้วยซ้ำ
    ดูเหมือนเป็น implementation ของ TLS ที่แย่ หรือ implementation รุ่นแรก ๆ ที่ไม่มีประสิทธิภาพ
    การใช้ CPU อยู่ประมาณ 5% บนคอร์ EPYC รุ่นที่ 2 ซึ่งค่อนข้างปกติ

    • จริง ๆ แล้วเรื่องนี้เป็นที่รู้กันดี implementation ของ QUIC ในเบราว์เซอร์ปัจจุบันยังไม่เสถียร และสร้างขึ้นบน rustls หรือแนวทางปะ ๆ ที่คล้ายกัน

  • เล่าเป็นเกร็ดว่า เคยมีปัญหาในการเข้าถึง wordpress.org
    ตอนเริ่มใช้ Wordpress ใหม่ ๆ ยังอ่านเอกสารได้ปกติ แต่พอถึงจุดหนึ่งก็เข้าเว็บไซต์ไม่ได้เลย
    ลองบูตคู่กับ Linux แล้วจึงไม่ใช่ปัญหาของ Windows, ping ก็ได้ปกติ และแม้เปลี่ยนเบราว์เซอร์สามตัวก็ยังเหมือนเดิม
    พอเข้าเว็บแล้วมันค้าง ไม่โหลดอะไรเลย หรือบางครั้งหน้าก็หยุดโหลดกลางคัน
    วันนี้เจอวิธีแก้ คือปิด Experimental QUIC Protocol ในการตั้งค่าของ Chrome
    มีปัญหาเข้าถึง wordpress.org มาหลายเดือน แต่กังวลตรงที่ไม่มีสัญญาณอะไรเลยว่านี่เกิดจาก QUIC
    เพิ่งสังเกตได้แบบหวุดหวิดเพราะในเครื่องมือนักพัฒนามีข้อผิดพลาดเกี่ยวกับ QUIC โผล่มาเป็นครั้งคราวเท่านั้น
    สงสัยว่ายังมีเว็บไซต์อีกสักเท่าไรที่เข้าถึงไม่ได้เพราะโปรโตคอลนี้ แต่ผู้ใช้ไม่รู้สาเหตุ

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

  • ที่ตลกคือ ทั้งที่เราไม่ค่อยรู้รายละเอียดมากนัก แต่ก็ยอมรับโดยปริยายกับความคิดทำนองว่า “QUIC คือ HTTP/2 ตัวใหม่” เพียงเพราะ เร็ว = ดี
    คล้ายกับการซื้อโทรศัพท์ 5G รุ่นใหม่เพราะเขาบอกว่ามันเร็วกว่า 4G หลายเท่า
    ทั้งที่จริง ๆ แล้ว 1) โทรศัพท์ 4G ของฉันไม่เคยทำงานถึงความเร็วสูงสุดของ 4G เลยสักครั้ง และ 2) ปัญหาการเชื่อมต่อแทบจะมักไม่ได้เกิดจากความเร็วของสายอินเทอร์เน็ต แต่เป็น DNS server, เว็บไซต์ปลายทาง หรืออุปกรณ์ multiplexing การเชื่อมต่อฝั่งผู้ให้บริการที่มีปัญหา
    ถึงอย่างนั้นก็ยังกลายเป็นว่า “แต่มันเป็น 5G นะ”
    โฆษณา “ไฟเบอร์ broadband” ที่ทำเหมือนคนดูทีวีแล้วผมปลิวเพราะแรงลมก็ตลกเหมือนกัน
    ของจริงไม่ได้ทำงานแบบนั้น
    สมัยก่อนยังสตรีมด้วยการเชื่อมต่อ 8Mb ได้ ดังนั้น 300Mb อาจดีสำหรับบางงาน แต่ก็สงสัยว่าจะรู้สึกถึงความแตกต่างมากแค่ไหน

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

    • ถ้าเพิ่มคีย์ส่วนตัวของเซิร์ฟเวอร์เข้าไปใน Wireshark มันจะถอดรหัสแพ็กเก็ตให้อัตโนมัติ
    • QUIC นำบางส่วนของสเปก TLS มาใช้ซ้ำ เช่น handshake และ transport state เป็นต้น
      ดังนั้นจึงไม่สามารถทำงานได้หากไม่มีสิ่งนั้น