savearoundtrip: เผยแพร่ระเบียน DNS แบบ HTTPS และลดการเดินทางไปกลับลง 1 รอบ

 (savearoundtrip.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากเว็บไซต์ประกาศการรองรับ HTTPS DNS record ไว้ใน HTTPS DNS record เบราว์เซอร์จะสามารถใช้ QUIC/HTTP/3 ได้ตั้งแต่การเชื่อมต่อครั้งแรก ทำให้ลดการเดินทางไปกลับของการเชื่อมต่อได้ 1 รอบ
  • เบราว์เซอร์สามารถค้นพบการรองรับ HTTP/3 ได้โดยเชื่อมต่อด้วย HTTP/1 หรือ HTTP/2 ก่อนเพื่ออ่านเฮดเดอร์ Alt-Svc หรืออ่าน HTTPS record ตั้งแต่ขั้นตอน DNS lookup
  • จากการวัดบน Firefox Nightly พบว่า 31.4% ของการเชื่อมต่อประกาศ HTTP/3 ผ่านเฮดเดอร์ Alt-Svc เพียงอย่างเดียว ซึ่งในกรณีนี้ HTTP/3 จะถูกใช้ได้เฉพาะการเชื่อมต่อครั้งถัดไปเท่านั้น {p:31}
  • HTTPS record สามารถบรรจุ alpn, ech, ipv4hint, ipv6hint เพื่อจัดการการเลือกโปรโตคอลของการเชื่อมต่อครั้งแรก, ECH, และการให้คำใบ้ที่อยู่ภายในคำตอบ DNS
  • HTTPS record ทำงานเสริมกับไคลเอนต์เดิมได้ และควรคง Alt-Svc ไว้เป็น fallback สำหรับไคลเอนต์ที่ไม่ได้รับระเบียนนี้

แนวคิดหลัก

  • เบราว์เซอร์ค้นพบการรองรับ HTTP/3 ของเว็บไซต์ได้ 2 วิธี
    • เชื่อมต่อด้วย HTTP/1 หรือ HTTP/2 ก่อน แล้วอ่าน HTTP header Alt-Svc
    • ตรวจสอบได้ทันทีจาก HTTPS DNS record ก่อนเปิดการเชื่อมต่อ
  • เฉพาะเมื่อใช้ HTTPS DNS record เท่านั้นที่เบราว์เซอร์จะสามารถใช้ HTTP/3 ได้ตั้งแต่การเชื่อมต่อครั้งแรก และลดการเดินทางไปกลับลง 1 รอบผ่าน QUIC
  • จากค่าประมาณเฉลี่ยของบิลด์ล่าสุดใน Firefox Nightly พบว่า 31.4% ของการเชื่อมต่อรู้จัก HTTP/3 ผ่านเฮดเดอร์ Alt-Svc เท่านั้น ไม่ใช่ผ่าน DNS
  • ปัจจุบันการเดินทางไปกลับ 1 รอบไปยังเซิร์ฟเวอร์นี้วัดได้ประมาณ 28ms

ตรวจสอบโดเมน

  • savearoundtrip.com เผยแพร่ HTTPS record ของตัวเองพร้อม h3, IP hint และ ECH
  • HTTPS record ของโดเมนที่ป้อนจะถูกค้นหาผ่าน DNS-over-HTTPS endpoint ของ Cloudflare ในเบราว์เซอร์
  • ไม่สามารถตรวจสอบเฮดเดอร์ Alt-Svc และการจับมือ HTTP/3 จริงได้โดยตรงจากเบราว์เซอร์
    • CORS ซ่อนเฮดเดอร์ข้ามต้นทาง
    • เบราว์เซอร์ไม่สามารถบังคับให้สร้างการเชื่อมต่อ QUIC แบบ cold ได้
  • โดเมนที่ป้อนจะถูกส่งไปยัง โอเพนซอร์สแบ็กเอนด์ขนาดเล็ก ซึ่งทำหน้าที่เพียงตรวจสอบ Alt-Svc และตรวจสอบการจับมือ HTTP/3 จริง
  • ไม่มีการจัดเก็บข้อมูล และการจับมือ HTTP/3 จริงทำผ่าน quic-go

ต้นทุนของการเดินทางไปกลับ 1 รอบ

  • การเดินทางไปกลับ 1 รอบคือกระบวนการส่งข้อความไปยังเซิร์ฟเวอร์และรับกลับมาอีกครั้ง โดยถูกจำกัดด้วยความเร็วแสง
  • เวลาเดินทางไปกลับโดยคร่าว ๆ คือ 5~20ms ภายในเมือง, 40~80ms ระหว่างประเทศ, และมากกว่า 150ms เมื่อข้ามมหาสมุทรหรือบนเครือข่ายมือถือ
  • Cloudflare Radar ให้ค่าตัวเลขแบบเรียลไทม์
  • การโต้ตอบที่น้อยกว่าประมาณ 100ms มักให้ความรู้สึกว่าทันที ส่วนที่มากกว่านั้นจะเริ่มรู้สึกว่าต้องรอ
  • หน้านี้ใช้เวลาประมาณ 41ms ตั้งแต่เริ่มเชื่อมต่อจนถึงการวาดภาพครั้งแรก และเวลาการเดินทางไปกลับจริงไปยังเซิร์ฟเวอร์นี้อยู่ที่ประมาณ 28ms
  • HTTPS record ที่ประกาศไว้ช่วยให้เบราว์เซอร์ใช้ QUIC แทน TCP ตั้งแต่การเชื่อมต่อครั้งแรก จึงลดเวลาการเดินทางไปกลับนี้ได้
  • หน้านี้เป็นหน้าแบบ static และมีขนาดเล็ก จึงมีงบเวลารวมไม่มาก แต่ในแอปจริง การเดินทางไปกลับ 1 รอบก็ยังเป็นต้นทุนคงที่ที่ต้องจ่ายตั้งแต่ต้น และอาจเกิดซ้ำกับหลายต้นทาง

การเดินทางไปกลับที่สูญเปล่า

  • Alt-Svc คือ HTTP response header ตาม RFC 7838
  • หากไคลเอนต์ต้องการอ่าน Alt-Svc จะต้องเปิดการเชื่อมต่อ TCP, จับมือ TLS ให้เสร็จ และส่งคำขอผ่าน HTTP/1.1 หรือ HTTP/2 ให้จบก่อน
  • วิธีนี้ทำให้ไคลเอนต์รู้ว่าเซิร์ฟเวอร์รองรับ HTTP/3 หลังจากการเชื่อมต่อก่อนหน้าเสร็จสิ้นแล้วเท่านั้น ดังนั้นการอัปเกรดเป็น HTTP/3 จึงเกิดขึ้นในการเชื่อมต่อครั้งถัดไป
  • HTTPS record ตาม RFC 9460 ย้ายสัญญาณการรองรับ HTTP/3 แบบเดียวกันนี้ไปไว้ใน DNS
  • ไคลเอนต์อ่านระเบียนนี้ระหว่างการ resolve ชื่อที่ต้องทำอยู่แล้ว จึงสามารถรู้การรองรับ HTTP/3 ได้ก่อนเปิดการเชื่อมต่อ
  • เมื่อใช้ HTTPS DNS record จะสามารถใช้ QUIC/HTTP/3 ได้ตั้งแต่การเชื่อมต่อครั้งแรก โดยไม่ต้องเสียการเชื่อมต่อ HTTP/1 หรือ HTTP/2 ก่อน

ทำไม HTTPS record ถึงดีกว่า

  • ค้นพบ HTTP/3 ก่อน byte แรก

    • SvcParam alpn แสดงรายการ ALPN protocol ID ที่ endpoint รองรับตาม ALPN
    • ตัวอย่างคือ h3 สำหรับ HTTP/3 และ h2
    • เนื่องจากข้อมูลนี้มาถึงระหว่างการ resolve ชื่อ ไคลเอนต์จึงเลือก QUIC ได้ตั้งแต่การเชื่อมต่อแรก โดยไม่ต้องไปค้นพบ h3 หลังจากเชื่อมต่อ HTTP/1 หรือ HTTP/2 ก่อนหน้า

  • ECH: Client Hello ที่เข้ารหัส

    • SvcParam ech บรรจุ public key ของ ECHConfigList ของ endpoint
    • ECH เข้ารหัส TLS ClientHello รวมถึงชื่อเซิร์ฟเวอร์ SNI เพื่อไม่ให้ผู้สังเกตการณ์บนเครือข่ายมองเห็นเว็บไซต์ที่กำลังเยี่ยมชม
    • ปัญหานี้แก้ด้วย HTTP header ไม่ได้ เพราะต้องมี public key ก่อนส่ง ClientHello แรก
    • เนื่องจากต้องใช้คีย์ในช่วงที่ยังไม่มีการเชื่อมต่ออยู่ มีเพียงช่องทางนอกแบนด์อย่าง HTTPS record ใน DNS เท่านั้นที่สามารถ bootstrap ECH ได้
    • หากไม่มี HTTPS RR ก็จะใช้ ECH ไม่ได้

  • เริ่มเชื่อมต่อได้เร็วขึ้นด้วย IP hint

    • Happy Eyeballs v3 ทำ query สำหรับ A, AAAA และ HTTPS แบบขนานกัน
    • ipv4hint และ ipv6hint ในคำตอบ HTTPS จะให้ที่อยู่สำหรับการเชื่อมต่อ候選เมื่อมาถึงก่อน A/AAAA record
    • ไคลเอนต์จึงเริ่มเชื่อมต่อกับที่อยู่ตาม hint ได้แทนที่จะรอคำตอบ A/AAAA
    • A/AAAA record จะยังคงมาถึงตามปกติ และเมื่อมาถึงแล้วจะมาแทนที่ hint
    • Alt-Svc ไม่มีความสามารถเทียบเท่าในส่วนนี้

  • แหล่งข้อมูลอ้างอิงเดียวและการแคช

    • ข้อมูลด้านการเข้าถึงสามารถอยู่ใน DNS เดียวกันพร้อม TTL ปกติได้
    • แนวทาง Alt-Svc ทำให้ข้อมูลกระจายอยู่ในแคช HTTP header ของแต่ละต้นทาง และเกิดปัญหา max-age
    • หาก max-age ยาวเกินไป ไคลเอนต์อาจใช้ทางเลือกที่ล้าสมัย และหากสั้นเกินไปก็จะย้อนกลับไปใช้โปรโตคอลก่อนหน้าบ่อยขึ้น
    • เบราว์เซอร์ต้องทำ DNS lookup อยู่แล้ว ดังนั้น HTTPS record จึงทำให้การ lookup นั้นส่งข้อมูลการเชื่อมต่อที่เหมาะสมที่สุดมาพร้อมกันได้

  • เปรียบเทียบความสามารถ

    • | ความสามารถ | HTTP header Alt-Svc (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | เวลาที่เรียนรู้ข้อมูล | หลังจบการเชื่อมต่อทั้งหมด | ระหว่างการ resolve DNS |
    • | h3 ในการเชื่อมต่อครั้งแรก | ไม่ได้ | ได้ |
    • | IP hint | ไม่มี | ipv4hint / ipv6hint |
    • | ECH key | เป็นไปไม่ได้ | พารามิเตอร์ ech |
    • | แหล่งความจริง | HTTP header และแคชที่เปราะบาง | DNS พร้อม TTL |

การวัดจริงในเบราว์เซอร์

  • จากการวัดใน Firefox Nightly เบราว์เซอร์สามารถรู้การรองรับ HTTP/3 ได้จาก HTTP response header Alt-Svc หรือจาก HTTPS DNS record
  • Alt-Svc จะมองเห็นได้หลังจากเชื่อมต่อแล้วเท่านั้น ส่วน HTTPS DNS record มองเห็นได้ก่อนเชื่อมต่อ
  • การเชื่อมต่อทั้งหมดแบ่งได้เป็น 4 กลุ่ม
    • Neither คือการเชื่อมต่อที่ไม่ได้ประกาศ HTTP/3 เลย
    • Alt-Svc only คือการเชื่อมต่อที่ประกาศผ่าน header เท่านั้น จึงไม่สามารถใช้ HTTP/3 ได้ตั้งแต่การเชื่อมต่อแรก
    • HTTPS record only คือการเชื่อมต่อที่ประกาศผ่าน DNS จึงสามารถไป HTTP/3 ได้ตั้งแต่การเชื่อมต่อแรก
    • Both คือการเชื่อมต่อที่ประกาศทั้งใน DNS และ header
  • สัดส่วนการเชื่อมต่อที่วัดได้คือ Neither 59.8%, Alt-Svc only 31.4%, HTTPS record only 2.8%, Both 6% {b:60,31,3,6}
  • ทั้ง 4 กลุ่มรวมกันครอบคลุมการเชื่อมต่อทั้งหมด จึงรวมกันได้ 100%
  • กลุ่ม HTTPS record only และ Both มี HTTPS record ที่ใช้งานได้ ส่วน Alt-Svc only คือช่องว่างที่อาจลดได้หากมี record
  • ตัวเลขเหล่านี้เป็นค่าประมาณต่อการเชื่อมต่อที่สร้างขึ้นใหม่จาก GLAM histogram ของ Firefox Nightly และเป็นค่าเฉลี่ยของบิลด์ล่าสุด จึงเป็นค่าโดยประมาณ

การเผยแพร่ HTTPS record

  • ServiceMode HTTPS record ที่ประกาศ h3 และ address hint สามารถเผยแพร่ได้ในบรรทัดเดียว
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. คือชื่อที่เผยแพร่ระเบียน โดยจุดท้ายหมายถึงชื่อโดเมนแบบสมบูรณ์
  • 3600 คือ TTL หน่วยเป็นวินาทีที่ resolver สามารถแคชระเบียนนี้ได้
  • IN คือคลาส DNS อินเทอร์เน็ตแบบเดียวกับเว็บเรคคอร์ดทั้งหมด
  • HTTPS คือชนิดเรคคอร์ดตาม RFC 9460
  • 1 คือ priority โดยค่าตั้งแต่ 1 ขึ้นไปคือ ServiceMode ที่บรรจุพารามิเตอร์
  • 0 คือ AliasMode ที่ชี้ไปยังเป้าหมายอื่นเท่านั้น
  • . คือ target host ซึ่งหมายถึงชื่อเจ้าของระเบียนเองคือ example.com
  • alpn="h3,h2" แสดงรายการโปรโตคอลที่เซิร์ฟเวอร์รองรับตามลำดับที่เหมาะสม โดย h3 คือ HTTP/3 และ h2 คือ HTTP/2
  • ipv4hint และ ipv6hint คือที่อยู่ที่ช่วยให้ไคลเอนต์เริ่มเชื่อมต่อได้ทันทีควบคู่กับการ lookup A/AAAA
  • ผู้ให้บริการ DNS แบบ managed ส่วนใหญ่ เช่น Cloudflare และ Route 53 รองรับ HTTPS record type โดยตรง
  • สามารถตรวจสอบการรองรับของโดเมนได้ที่ checker

ความสามารถที่อยู่ใน HTTPS record จริง

  • ใน Firefox Nightly มีการวัดสัดส่วนของความสามารถแต่ละอย่างในบรรดาการเชื่อมต่อที่พบ HTTPS record
  • h3 ใน ALPN อยู่ที่ 80.3% และ IPv4 hint อยู่ที่ 52.9%
  • IPv6 hint อยู่ที่ 49.4% และ ECH อยู่ที่ 12.8% {b:80,53,49,13}
  • ตัวเลขเหล่านี้เป็นค่าประมาณต่อการเชื่อมต่อที่สร้างขึ้นใหม่จาก GLAM histogram จึงเป็นค่าโดยประมาณ

FAQ

  • CDN เผยแพร่ให้อัตโนมัติหรือไม่

    • CDN บางรายเผยแพร่ HTTPS record ให้อัตโนมัติ
    • Cloudflare จะให้ HTTPS record ที่มี alpn="h3" โดยอัตโนมัติสำหรับโซนที่ proxy ไว้
    • CDN รายอื่นอาจต้องให้ผู้ใช้ตั้งค่าเอง
    • วิธีตรวจสอบที่เร็วที่สุดคือใช้ การตรวจสอบโดเมน ด้านบน

  • HTTPS record จะทำให้ไคลเอนต์เก่าใช้งานไม่ได้หรือไม่

    • ไคลเอนต์ที่ไม่เข้าใจ HTTPS record จะเพิกเฉยต่อระเบียนนี้และกลับไปใช้ A/AAAA lookup ปกติ
    • หากยังส่งเฮดเดอร์ Alt-Svc อยู่ ไคลเอนต์เหล่านั้นก็ยังใช้ header นี้ได้เช่นกัน
    • วิธีเผยแพร่ HTTPS record เป็นการเสริมการทำงานเดิม ไม่ใช่การแทนที่

  • แล้วกรณีกลับมาเยี่ยมชมซ้ำล่ะ

    • หลังจากไคลเอนต์สื่อสารด้วย HTTP/3 ได้ครั้งหนึ่งแล้ว จะสามารถ resume การเชื่อมต่อ QUIC แบบ 0-RTT ได้ในการเยี่ยมชมครั้งถัดไป
    • ใน 0-RTT สามารถส่งคำขอแรกได้ทันทีโดยไม่ต้องรอ handshake round trip
    • ตัว HTTPS record เองก็ถูกแคชตาม TTL เช่นเดียวกับคำตอบ DNS อื่น ๆ ดังนั้นเมื่่อกลับมาเยี่ยมชมซ้ำก็มักข้ามการ lookup ไปได้ด้วย

  • เบราว์เซอร์ใดใช้ HTTPS record บ้าง

    • เอนจินหลักต่างรองรับ HTTPS record โดยเปิดใช้งานเป็นค่าปริยาย
    • เบราว์เซอร์จะอ่าน record นี้ไม่ว่าผู้ใช้จะเปิด DNS-over-HTTPS หรือไม่ก็ตาม
    • Safari ใช้ตัว resolver ของระบบปฏิบัติการ
    • Chrome ใช้ resolver ในตัว และทำงานผ่าน DoH หรือ DNS ปกติได้
    • Firefox ใช้ได้ทั้งสองแบบ

  • ควรเอาเฮดเดอร์ Alt-Svc ออกหรือไม่

    • ไม่ควรถอดเฮดเดอร์ Alt-Svc ออก
    • ควรส่งต่อไปในฐานะ fallback สำหรับไคลเอนต์รุ่นเก่า และสำหรับ resolver หรือเครือข่ายที่ไม่ส่ง HTTPS record
    • เบราว์เซอร์ที่อ่าน HTTPS record จะรู้การรองรับ HTTP/3 จาก DNS และไม่ต้องเสียการเดินทางไปกลับ 1 รอบเพื่อค้นพบ HTTP/3

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs
  • ผู้ให้บริการเว็บโฮสติ้งยังไม่รองรับ H3 แต่สามารถอัปเกรดเป็นเวอร์ชันเซิร์ฟเวอร์ใหม่ได้ฟรีเพื่อลองทดสอบ
    พอเสร็จแล้วก็ตั้งค่า HTTPS DNS record
  • dig ของ Apple เป็นเวอร์ชัน 9.10.6 ดูเหมือนจะเก่ากว่าประเภทเรคคอร์ดนี้
    Apple น่าจะควรมี dig ที่ใหม่กว่านี้ และก็สงสัยว่ามีเครื่องมือที่ชอบใช้สำหรับ query DNS บน macOS กันไหม

    • ชอบใช้ doggo บนหลายแพลตฟอร์ม
      มันไม่ได้สมบูรณ์แบบ แต่โดยรวมทำงานได้ค่อนข้างดีและตอบโจทย์สิ่งที่ต้องการพอสมควร

    • ใช้ drill จาก ldns ที่ติดตั้งผ่าน Homebrew

      % drill -Q https savearoundtrip.com  
1 . alpn=h3,h2 ipv4hint=104.21.20.43,172.67.191.84 ech=AEX+DQBBzwAgACAdG3AfYFkusczSXA/kky1bgK67QViv5mNKyS3ITnrWbAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3030::ac43:bf54,2606:4700:3037::6815:142b
  • ถ้ามี HTTPS resource record อยู่ ไคลเอนต์ทุกตัวที่อ่านมันได้ก็จะเชื่อมต่ออย่างปลอดภัย
    ต่อให้ไม่รองรับ QUIC ก็เหมือนกัน
  • ไม่เข้าใจว่าทำไมโพสต์นี้ถึงติดแท็ก vibecoding
    แทบจะมีแค่ CSS ที่ดูเหมือนออกมาจาก LLM เท่านั้น
    • คอมมิตแรกดูชัดเจนว่าใช้ LLM ทำขึ้นมา: https://github.com/mxinden-bot/savearoundtrip/…
      แล้วบทความก็เยิ่นเย้อมาก มีทั้งการพูดซ้ำ เนื้อหาที่ไม่ค่อยมีประโยชน์ และภาพประกอบแปลก ๆ จนความยาวราว 1700 คำ และความสูงทั้งหน้าทะลุ 7300px
      ถ้าลดเหลือประมาณ 500 คำ, ไดอะแกรม 2 อัน และความยาวรวมไม่เกิน 2000px ก็น่าจะดีขึ้นมาก