ช่วงนี้มีเรื่องเป็นที่ชวนฉงนสงสัยของใครหลายคนที่ใช้ Internet บ้านของ True เหตุใดบางครั้ง มันถึงช้าจนใช้งานไม่ได้ แถมมาเจาะจงเป็นเฉพาะกับบริการของ Google
และ ถ้าเจาะจงมากกว่านั้น ทำไมมันมีปัญหากับเฉพาะ Google Chrome
บางคนได้ถามไปทางผู้ให้บริการแล้วได้คำตอบที่ไม่แน่ชัด แต่ละคนก็มีทฤษฎีตีความกันไปต่างๆ นาๆ แต่คนที่สรุปได้ว่าเป็นเพราะอะไร ไม่ได้ออกมาอธิบายให้รู้ทั่วกัน แถมตัวปัญหาก็ไม่ได้ใหญ่โตเกินแก้ เป็นไปได้หรือไม่ว่า วิศวกรผู้รับผิดชอบของบริษัทดังกล่าว จนบัดนี้ก็ยังไม่เข้าใจว่าเกิดอะไรขึ้น

มีหลายคนสอบถามถึงประเด็นดังกล่าว หลังจากห่างหายวงการข่าว True ไปนานเนื่องจากงานประจำ ผมขอเขียนข่าวสั้น เพื่ออธิบายปรากฏการณ์ที่เกิดขึ้น เพื่อหวังว่าปัญหาจะได้รับการแก้ไขอย่างทันท่วงที

วันนี้เราไปย้อนรอยกันว่า ปรากฏการณ์ "Google ค้าง" เกิดขึ้นได้อย่างไร ปัญหาอยู่ที่ Browser, อยู่ที่บริการของ Google, หรือ เป็นเพราะระบบเครือข่ายของ True

TL;DR version

Google เปลี่ยนแปลง transport protocol ทำให้ปัญหาที่ซ่อนอยู่ใน True เผยโฉมให้เห็น
 

ข้อสังเกต

• มีเว็บ อยู่ตั้งมากมาย แต่มีเฉพาะเว็บที่ติด Google Ads หรือที่เห็นได้ชัดเจนหน่อยคือ ตัวเว็บ search ของ Google เองที่มีปัญหา อันนี้ต้องขอละเว็บที่มีปัญหากับ ISP เจ้านี้ มาหลายปีดีดักตั้งแต่แรกอยู่แล้ว โดย router ของ ISP เจ้านี้ มักจะเกิดอาการมึนงงอยู่บ่อยครั้ง เมื่อปลายทางเป็น Multihoming server
• ปัญหาทั้งหมดจะหายลับเข้ากลีบเมฆ เมื่อคุณลองเปิดเว็บเดียวกันด้วย Firefox ราวกับว่ามันไม่เคยเกิดขึ้น จนหลายครั้งที่คนที่เข้าพวกกับทรูทั้งทางตรงหรือทางอ้อมใช้เป็นข้ออ้าง โทษนั่นนี่ extension มั่ง virus มั่ง จนละเลยที่จะตรวจสอบว่า สาเหตุมันเกิดขึ้นมาจากไหน
• Google ไม่ได้ค้างตลอดเวลา แต่เป็นๆ หายๆ เดี๋ยวเป็น เดี๋ยวหาย และส่วนใหญ่จะเจอเฉพาะกับ Internet บ้าน
   

จากข้อสังเกต ทำให้เราเดาได้ว่า...

Google เอ็งลองทำอะไรแปลกๆ อีกแล้วใช่มั้ย?
และถ้าคุณเป็นคนหนึ่งที่ ตามข่าวเกี่ยวกับระบบเครือข่าย คุณจะพบว่า ในช่วงปีที่ผ่านมา Google ได้ลอง อะไรกับระบบเครือข่ายเยอะมาก โดย หลายครั้งเป็นการ implement หลักการ cryptography ของ D. J. Bernstein ถ้าคุณช่างสังเกตหน่อย จะเห็นว่ามีช่วงหนึ่งที่ Google ใช้ cipher suite แบบ djb way คือใช้ ChaCha20 เป็น bulk cipher และใช้ Poly1305 ในการ authenticate มีโผล่มาให้เห็นกับตาแค่ไม่นานเท่านั้น และยังมีการทดลองอื่นๆ ทั้งที่เราเห็นและไม่เห็นมากมาย หนึ่งในนั้น เป็นการสร้าง transport protocol ใหม่เพื่อเป้าหมายลด network latency ให้ใกล้เคียง 0RTT protocol ดังกล่าว มีชื่อว่า QUIC
 

ปัญหาของ QUIC กับ True

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

RTT (round-trip time)

จินตนาการว่าคุณเป็น pâtissier ทำขนม คุณทำขนมได้วันละ 5,000 ชิ้น คุณมีรถบรรทุก 2 คัน ใส่ขนมได้ คันละ 1,500 ชิ้น ด้วยระยะทางแล้วรถบรรทุกวิ่งได้แค่วันละ 1 รอบ แสดงว่า ถ้าคุณจะทำขนมให้ไม่เสียเปล่า คุณทำออกมาได้แค่วันละ 3,000 ชิ้น
เปรียบเสมือน Internet ที่มี bandwidth 3,000 ชิ้นต่อวัน หรือมองให้เป็น Internet ไปเลยคือ 1 MiB/s (ยกตัวอย่าง) คำถามคือ 1 MiB/s ใช่หน่วยของความเร็ว Internet หรือเปล่า?
มองในมุมหนึ่งแล้ว คำตอบอาจจะเป็นใช่ แต่เราลองย้อนกลับไปที่รถบรรทุกขนขนมอีกที คำตอบมันอาจเป็นอีกแบบ
สมมุติผมโทรสั่งขนมคุณ 1,000 ชิ้น ต่อให้คุณมีรถว่าง 1 คัน หรือ 2 คัน คุณก็ต้องใช้เวลา 5 ชั่วโมง ในการ ส่งขนมให้ผมเท่ากัน ไม่ว่าคุณจะมี bandwidth (ซึ่งมองในมุมหนึ่งแล้วอาจหมายถึงความเร็ว Internet) มากขนาดไหน คุณก็ยังช้าเท่าเดิม แลดงว่ามีปริมาณอีกชนิดที่ใช้บอกความเร็ว Internet ที่ไม่ใช่ความเร็วชนิดเดียวกับ bandwidth มันคือ RTT นั่นเอง การทำให้ Internet เร็วขึ้น ด้วยการเร่ง RTT ให้เร็วขึ้น เป็นเรื่องที่ทำไม่ได้ ไม่เหมือนกับ bandwidth ที่ขยายได้ เพราะ RTT ถูก limit ไว้ที่ความเร็วแสง (Internet ในปัจจุบันก็เดินทางเร็วเกือบเท่าแสงอยู่แล้ว) สิ่งที่ทำได้คือ ลดจำนวน round trip ลง และนั่นก็คือ gist ของเป้าหมายของ QUIC นั่นเอง
 

TCP or UDP

ถ้าเราต้องการจะสร้าง protocol ใหม่ แล้วคิดมันใหม่หมดเลย ใช้ที่ไหนก็ไม่ได้ เพราะคนอื่นไม่รู้เรื่องด้วย มันก็คงเป็น protocol ที่ประสบผลสำเร็จน่าดู (น่าดูว่าทำขึ้นมาทำไม)
เราเลยต้องสร้าง transport protocol ใหม่ ขึ้นบน transport protocol เดิม ที่มีอยู่แล้ว หลักๆ ก็มี TCP กับ UDP นี่แหละครับให้เลือก จะมีพวกที่ออกแบบ protocol ใหม่เอียมขึ้นมาจาก raw socket อยู่เหมือนกัน แต่มักใช้เพื่อการวิจัย การศึกษา หรือลองออกแบบก็เท่านั้น
TCP เป็นตัวเลือกที่ตัดทิ้งไปได้เลย แค่ connection ก็ใช้ไป 1RTT แล้ว ยิ่งถ้าเพิ่ม layer ของ TLS ไปด้วย กว่าจะตอบไปตอบกลับ ตกลง key ก็ใช้ไปหลาย round trip ทีเดียว
 

UDP ไม่มี congestion control

design choice เดียวที่สมเหตุสมผล คือ UDP เมื่อเลือกได้แล้วก็ยังมีปัญหาให้ QUIC team ตามแก้อีกมากมาย หนึ่งในนั้นมีที่เกี่ยวข้องกับเหตุการณ์นี้ คือ congestion control ครับ ระบบเครือข่ายมันถูกออกแบบไว้อย่างนี้ คือ ทุกอุปกรณ์ ในระบบเครือข่ายจะไม่ระดมยิง packet เข้าเครือข่าย เหมือนคนกรูกันเข้าขึ้นรถเมล์เหมือนที่เราเห็นในกรุงเทพฯ บางจุด แต่มันจะมีระบบการจัดการจราจร หรือที่เรียกว่า congestion control ระบบนี้ จะบอกให้ device ทุกตัว ถอย และส่งข้อมูลให้ช้าลง device ที่ออกแบบมาให้ได้มาตรฐานก็จะทำตามนะครับ ถ้าไม่มีเจ้าระบบนี้ จะไม่มีใครใช้ระบบเครือข่ายได้เลยครับ เหมือนกับที่เวลาคุณบางพวกบางกลุ่มแย่งประโยชน์กันจนไม่มีใครได้อะไรไปเลยนั่นแหละครับ
เจ้า congestion control นี่จะมีผลเฉพาะ กับ TCP เท่านั้น ส่วน UDP น่ะเหรอ ก็ถูก router drop packet ทิ้ง เหมือนไม่มีการส่งเกิดขึ้นเลยน่ะสิ QUIC แก้ปัญหานี้ยังไงเป็นเรื่องที่คุณต้องติดตามต่อไปด้วยตัวเองนะครับ
 

ต่อจิ๊กซอ

ตอนนี้เรามีชิ้นส่วนมากพอที่จะรู้เรื่องราวที่เกิดขึ้นทั้งหมดแล้ว อย่างน้อยเราก็รู้ว่า gist ของปัญหามันคือ UDP เรามาดูกันทีละประเด็นครับ ว่ามันเป็นยังไง

ทำไมเป็นเฉพาะกับบริการ Google?
เพราะ Google เป็นเจ้าเดียวที่ใช้ QUIC server อย่างจริงๆ จังๆ

ทำไมเป็นเฉพาะกับ Chromium based browser (เช่น Google Chrome)?
เพราะ Chromium เป็น client browser เดียวที่รองรับ QUIC protocol

ทำไมเพิ่งจะมาเห็น ก่อนหน้านี้ไม่เคยเป็น?
ปกติแล้ว ถ้าคุณอยากลองเล่น QUIC คุณต้องไปเปิด flag QUIC ใน Google Chrome ด้วยตัวเอง แต่เมื่อไม่นานมานี้ Google เพิ่ง rollout เปิดการทำงาน QUIC เป็น default ของ Google Chrome

ทำไมเดี๋ยวเป็นเดี๋ยวหาย?
ปัญหาจะโผล่มาเฉพาะ ตอนระบบเครือข่ายเกิด congestion

ตกลง True มาเกี่ยวอะไรด้วย?
ปรากฏการณ์นี้ อาจเกิดขึ้นเพราะ router ไม่มีคุณภาพ หรือ config ไม่ดีผมก็ไม่อาจทราบได้ แต่ เท่าที่เดาได้คือ เวลาเกิด congestion ในระบบเครือข่าย router ในระบบเลือกที่จะทำให้ TCP packet ช้าลงระดับหนึ่ง แต่ drop UDP packet ทิ้งเรียบ แทนที่จะให้ QoS ทั้งกับ UDP และ TCP ส่งผลให้ UDP traffic เป็นอัมพาตชั่วคราว การถูก drop packet ทิ้งเรียบ ต่อให้ออกแบบ protocol มาดีขนาดไหน ก็ทำงานไม่ไหวจ้า
 
สำหรับข่าวนี้สั้นกว่าปกติ (ข่าวเก่าๆ) ตัวปัญหาไม่น่าจะแก้ไขยาก (ขึ้นกับว่า ข้างในทำเน่าไว้ระดับไหน) คิดว่าข่าวจะล้าสมัยค่อนข้างเร็ว แต่ไม่ว่าคุณจะมาอ่านเร็วๆ นี้ หรือมาอ่านวันหลังๆ ผมก็
สวัสดีนะ