วิศวกรรมสำหรับอินเทอร์เน็ตที่ช้า: วิธีลดความไม่สะดวกของผู้ใช้ในแอนตาร์กติกา

 (brr.fyi)
2 คะแนน โดย GN⁺ 2024-06-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อินเทอร์เน็ตของ South Pole พึ่งพาลิงก์ดาวเทียมที่มีข้อจำกัด ทำให้ เชื่อมต่อได้เพียงไม่กี่ชั่วโมงต่อวัน และ ณ เดือนตุลาคม 2023 ผู้ใช้ชุมชนต้องทนกับ latency สูง, bandwidth ต่ำ และการหลุดเป็นระยะ
  • สภาพแวดล้อมจริงมี round-trip latency ประมาณ 750ms พร้อม jitter หลายวินาที ความเร็วตั้งแต่ไม่กี่ kbps ถึง 2Mbps และยังมี congestion, queueing, packet loss และการถูกแย่งใช้บริการซ้อนกัน จนทำลายสมมติฐานด้านเครือข่ายของแอปทั่วไปได้ง่าย
  • JavaScript bundle ขนาดใหญ่, timeout ที่ hardcode ไว้, การทิ้ง progress, cache invalidation และ downloader ในตัวที่ resume ไม่ได้ เป็นปัจจัยที่ทำให้แอปล้มเหลวด้วยตัวเองบนลิงก์ที่ช้า
  • หาก byte ยังไหลอยู่แม้จะช้า ก็ควรรอ และถ้ามี chunked transfer, resume, status display, dynamic timeout และลิงก์ดาวน์โหลดด้วยตนเอง เป้าหมายเล็ก ๆ อย่างข้อความหรือการอัปเดตก็ยังทำได้
  • แอนตาร์กติกาเป็นกรณีสุดขั้ว แต่เรือในทะเล, สถานีวิจัยบนภูเขา, Wi‑Fi ที่ไม่เสถียร, WISP คุณภาพต่ำ และผู้ใช้ที่เชื่อมต่อผ่านสายโทรศัพท์ก็อาจเจอข้อจำกัดคล้ายกัน จึงต้องมี การออกแบบที่ไม่ขัดขวางความคืบหน้าของผู้ใช้

ข้อจำกัดของสภาพแวดล้อมอินเทอร์เน็ตที่ South Pole

  • การให้บริการอินเทอร์เน็ตที่ South Pole นั้นเป็น โจทย์วิศวกรรมที่ไม่ธรรมดา และตัวเลือกดาวเทียมที่ใช้ได้ในเขตขั้วโลกมีจำกัด
    • มีเอกสารสาธารณะคือหน้า South Pole Satellite Communications
    • ความยากของการลากใยแก้วนำแสงแบบดั้งเดิมไปถึงทวีปแอนตาร์กติกายังถูกกล่าวถึงใน 2021 Antarctic Subsea Cable Workshop ด้วย
  • แม้ NSF จะมี ประกาศ เกี่ยวกับ Starlink ที่ McMurdo และ Palmer แต่ ณ เดือนตุลาคม 2023 ยังไม่มีประกาศลักษณะเดียวกันสำหรับ South Pole Station
  • จนถึงไม่นานมานี้ McMurdo มีผู้ใช้เกือบ 1,000 คน รวมถึง workload ด้านวิทยาศาสตร์และปฏิบัติการหลายอย่าง ที่ต้องแชร์ aggregate bandwidth ระดับหลายสิบ Mbps ทั้งสถานี
    • เป็นสถานการณ์ที่ทั้งสถานีต้องแบ่งใช้ bandwidth น้อยกว่าที่คนคนหนึ่งอาจได้รับจากเครือข่ายเซลลูลาร์ 4G ทั่วไปในชานเมืองสหรัฐฯ
  • South Pole เชื่อมต่อได้เฉพาะช่วงที่ดาวเทียมขึ้นเหนือเส้นขอบฟ้าและสถานีได้รับอนุญาตให้ใช้งาน โดยตารางดาวเทียมมักเลื่อนเร็วขึ้นวันละประมาณ 4 นาที เนื่องจากความต่างระหว่าง sidereal time กับ solar time
  • latency ที่ผู้ใช้รู้สึกได้นั้นแตกต่างจากประสบการณ์อินเทอร์เน็ตทั่วไปอย่างมาก
    • round-trip latency ไปยังปลายทางในแผ่นดินใหญ่สหรัฐฯ ประมาณ 750ms
    • ประมาณ 10 เท่าของ round-trip latency สูงสุด 75ms ระหว่างชายฝั่งตะวันออกและตะวันตกของสหรัฐฯ
    • ประมาณ 30 เท่าของค่าสูงสุด 25ms ที่คาดหวังได้จากการเชื่อมต่อเคเบิลหรือใยแก้วนำแสงตามบ้านไปยัง CDN หลัก
    • เมื่อเทียบกับใยแก้วนำแสง GPON ที่บ้านของผู้ใช้ ซึ่งไปถึง Fastly, Cloudflare, CloudFront, Akamai และ Google ได้ราว 3ms แล้ว South Pole สูงกว่ามากกว่า 250 เท่า

เงื่อนไขจริงที่ผู้ใช้ชุมชนต้องเจอ

  • ณ เดือนตุลาคม 2023 บุคคลที่ใช้อินเทอร์เน็ตเพื่อวัตถุประสงค์ชุมชนที่ South Pole อาจเจอสภาพดังนี้
    • round-trip latency เฉลี่ยประมาณ 750ms และ jitter ระหว่าง packet ที่เกินหลายวินาที
    • ความเร็วที่ปลายทางผู้ใช้ตั้งแต่ไม่กี่ kbps จนถึง 2Mbps ในวันที่ดีมาก
    • congestion, queueing และ packet drop อย่างหนัก
    • availability จำกัด, dropout บ่อย และบางครั้งบริการถูก preempt
  • ในบางสถานการณ์อาจพบเงื่อนไขอย่าง 40kbps, latency 1,000ms, jitter สูงสุด 2,000ms, packet loss 10% และการขาดการเชื่อมต่อทั้งหมด 15 วินาทีทุกไม่กี่นาที
  • เนื่องจากทราฟฟิกด้านปฏิบัติการได้รับ priority สูง ผู้ใช้ชุมชนจึงต้องพึ่งพาความจุที่เหลืออยู่
  • ฟีเจอร์อย่างวิดีโอคอนเฟอเรนซ์แบบเรียลไทม์แทบคาดหวังไม่ได้ แต่บางแอปยังส่งรับข้อความตัวอักษรขนาดไม่กี่ byte ได้
  • วิศวกรรมเว็บและแอป ที่ไม่ได้คำนึงถึงลิงก์ที่ช้าหรือขาด ๆ หาย ๆ ทำให้ usability แย่ลงไปอีก

กรณีเว็บแอปสำหรับทำงานร่วมกันที่ต้องใช้ JavaScript 20MB

  • แพลตฟอร์ม collaboration สำหรับองค์กรหนึ่งต้องดาวน์โหลด JavaScript เพียงอย่างเดียวเกือบ 20MB เพื่อ render หน้าหลัก
    • หลังจากการเข้าใช้ครั้งก่อน แอปมีการอัปเดต ทำให้ asset ใน browser cache ทั้งหมดเก่าและต้องดาวน์โหลดใหม่
  • browser และ protocol จัดการ congestion control บนอินเทอร์เน็ตที่ช้าได้ระดับหนึ่ง แต่แอปนี้ตัดการโหลดด้วยเงื่อนไขล้มเหลวของตัวเอง
    • หากโหลดไม่เสร็จภายในเวลาหรือจำนวน retry ที่นักพัฒนากำหนด แอปจะหยุดทำงาน
    • ถูก redirect ไปยัง error page
    • สถานะการโหลดที่ทำไปแล้วหายไป
    • ในการลองครั้งถัดไป มีการใช้มาตรการ cache invalidation ที่รุนแรง
  • โดยเนื้อแท้แล้วแอปนี้เป็น แอปส่งข้อความ และหลังเปิดใช้งาน เมื่อแชทกับเพื่อน payload ของเนื้อหาจริงมีขนาดเป็น byte เท่านั้น
  • ประสิทธิภาพอินเทอร์เน็ตของ South Pole อยู่บนเส้นแบ่งที่นักพัฒนามองว่า “ยอมรับได้” ทำให้ผู้ใช้ต้อง refresh หลายครั้งและดาวน์โหลด JavaScript ชุดเดิมซ้ำ
    • หากปล่อยให้การถ่ายโอนที่จำเป็นดำเนินต่อไปตามเดิม อาจเสร็จภายใน 15 นาที แต่ในความเป็นจริงบางครั้งใช้เวลาหลายชั่วโมง
    • ในกรณีที่สำเร็จ มี HTTP request 809 รายการ, ส่งข้อมูล 51.4MB, โหลด 26.5 นาที แล้วส่งข้อความ 6 byte ด้วย HTTPS POST ขนาด 1.8KB
  • หากแอปถูกออกแบบให้รอต่อไปตราบใดที่ข้อมูลยังไหลอยู่แม้จะช้า ก็จะลดการส่งซ้ำที่ไม่จำเป็นและการสิ้นเปลือง bandwidth ได้

ปัญหาของ timeout ที่ hardcode และการส่งข้อมูลก้อนใหญ่ครั้งเดียว

  • สมมติฐานแบบตายตัว ว่า payload จะถูกส่งเร็วแค่ไหน หรือหนึ่ง request จะส่งได้มากเท่าใด สามารถทำให้แอปพังบนลิงก์ที่ช้าได้
  • หากวัดได้ว่า byte ยังไหลอยู่ ก็ควรไม่หยุดการถ่ายโอนไม่ว่าจะช้าแค่ไหน และควรแสดงสถานการณ์ปัจจุบันใน UI
  • หาก HTTPS call ล้มเหลว ควร retry ด้วย timeout ที่ยาวขึ้น และแบ่งข้อมูลขนาดใหญ่เป็น chunk เล็ก ๆ เพื่อส่ง
    • ต้องติดตาม progress ราย chunk
    • ต้อง retry หรือ resume เฉพาะส่วนเล็ก ๆ ที่ล้มเหลวได้
    • ความคืบหน้าแบบเพิ่มทีละน้อยอย่างช้า ๆ แต่สม่ำเสมอปลอดภัยกว่าการพยายามส่งข้อมูลใหญ่ทีเดียว
  • หาก HTTPS call ล้มเหลวต่อเนื่อง ควรตรวจสอบ DNS, ICMP, HTTP แบบไม่มี TLS และ HTTPS ไปยัง endpoint สถานะปกติที่รู้จัก แล้วแจ้งสถานะให้ผู้ใช้ทราบ แทนที่จะวนซ้ำ call เดิมอย่างมืดบอด

  • การดาวน์โหลด metadata ตอนเริ่มต้นล้มเหลว

    • แอปเดสก์ท็อปยอดนิยมหนึ่งดาวน์โหลดข้อมูล configuration จากเว็บไซต์ vendor ตอนเริ่มต้น และใช้ timeout ที่ hardcode ไว้ สำหรับ HTTPS call
    • เมื่อ call นี้ล้มเหลว แอปจะไม่โหลดและ retry ตลอดไปด้วย parameter เดิม โดยหน้า loading ไม่บอกสาเหตุ
    • ที่ South Pole หากพยายามต่อไปเรื่อย ๆ สุดท้ายอาจผ่านได้ แต่ timeout ค่าเดียวทำให้แอประดับองค์กรแทบใช้งานไม่ได้
    • พฤติกรรมที่ดีกว่าคือค่อย ๆ fallback ไปยัง timeout ที่ยาวขึ้น, ตรวจสอบสถานะการเชื่อมต่อ, แสดงสาเหตุ, ใช้ cache หรือค่า default และให้เส้นทางดาวน์โหลดกับติดตั้งด้วยตนเอง

  • ความแตกต่างของแอปแชทสองตัว

    • แอปแชทยอดนิยมหนึ่งใช้ timeout 10 วินาทีที่ hardcode ไว้ สำหรับการ initialize WebSocket
    • TCP handshake, TLS session, การตั้งค่า WebSocket และ initial signaling ล้วนจำเป็น ดังนั้นในเงื่อนไขอย่าง South Pole ที่แต่ละรอบไปกลับใช้เวลาหลายวินาที จึงอาจเกิน 10 วินาทีได้
    • เมื่อ timeout ผ่านไป แอปจะไม่ทำงานและเข้าสู่สถานะ backoff ยาว โดย UX ไม่แสดงสถานการณ์อย่างชัดเจน
    • แอปแชทคู่แข่งทำงานได้ดีกว่าแม้ในสภาพเครือข่ายที่แย่มาก
      • ใช้กลยุทธ์ network request หลายแบบ
      • reuse connection ที่เปิดอยู่เชิงรุก
      • ปรับ timeout แบบ dynamic
      • เลือกช่วง retry อย่างชาญฉลาดเมื่อเกิดความล้มเหลว
      • แสดงสถานะเครือข่ายปัจจุบันอย่างชัดเจน
    • ทั้งสองแอปส่งข้อความ plain text จริง ๆ เพียงไม่กี่ byte แต่เงื่อนไขที่ใช้งานได้ต่างกันเพราะสมมติฐานด้านเครือข่ายต่างกัน

การถ่ายโอนแบบเพิ่มทีละส่วนและ upload ที่ resume ได้

  • brr.fyi เป็นบล็อก Jekyll แบบ static โดย asset เก็บใน S3 และให้บริการผ่าน CloudFront
    • static file ถูก build บน laptop ในเครื่อง
    • upload ตรงไปยัง S3
    • ไม่มี server, QA environment, build system, automated hook หรือองค์ประกอบ dynamic
  • สคริปต์ publish ภาษา Python ที่สร้างโดยคำนึงถึงข้อจำกัดของ South Pole upload asset ผ่าน S3 API เป็น chunk เล็ก ๆ
    • ตรวจจับ upload ที่ล้มเหลวและ resume โดยไม่เสีย progress
    • ไม่ publish เวอร์ชันใหม่จนกว่าไฟล์ทั้งหมดจะ upload อย่างปลอดภัย
    • implement ด้วย Python ประมาณ 200 บรรทัด
  • ผู้ใช้ที่ upload ไฟล์ใหญ่ไปยังแพลตฟอร์มบล็อกเชิงพาณิชย์หรือ social media ต้องจัดเวลาให้มีโอกาสสำเร็จในครั้งเดียวภายในหน้าต่างดาวเทียม
    • หากล้มเหลวต้อง retry หลายครั้ง
    • บางครั้งไม่ชัดเจนว่า content ขึ้นไปแล้วหรือไม่, upload เสร็จหรือยัง หรือกด “Post” อีกครั้งได้หรือไม่
  • หาก chunk POST ล้มเหลวแล้วยัง retry หรือ resume ภายหลังได้โดยสูญเสียน้อยที่สุด ก็สามารถค่อย ๆ รวบรวม upload ทีละไม่กี่ KB ในเวลาที่สะดวกได้

เกณฑ์ที่ downloader ในตัวต้องมี

  • หากแอปจะสร้าง downloader ของตัวเอง ต้องมีคุณภาพระดับสูง มิฉะนั้นบนอินเทอร์เน็ตที่ช้าจะสร้างความไม่สะดวกอย่างมากหรือล้มเหลวแบบร้ายแรง
  • หากเป็นไปได้ ผู้ใช้ควร ออกจาก downloader ในตัว แล้วดาวน์โหลดไฟล์โดยตรงได้
    • การให้ลิงก์ดาวน์โหลดด้วยตนเองมีประโยชน์
    • หากทำได้ ลิงก์ไปยังไฟล์ differential patch ที่แอปตั้งใจจะดาวน์โหลด ดีกว่าไฟล์ติดตั้งเต็ม
  • ข้อดีของลิงก์ดาวน์โหลดด้วยตนเองชัดเจน
    • ผู้ใช้เลือก downloader ที่ robust กว่า เช่น browser ได้
    • ดาวน์โหลดไฟล์ครั้งเดียวแล้วแชร์ไปหลายอุปกรณ์ได้
    • ดาวน์โหลดจากคอมพิวเตอร์เครื่องอื่นที่ไม่ใช่เครื่องที่รันแอปได้
    • ผู้ใช้ schedule หรือจัดการ download ให้เข้ากับข้อจำกัดของตนเองได้
  • South Pole ไม่มีอินเทอร์เน็ต 24 ชั่วโมง ดังนั้นแม้จะมีหน้าต่าง download วันละ 4 ชั่วโมง หากข้อมูลที่รับได้ในช่วงนั้นน้อยกว่าขนาด payload ก็ไม่มีทางทำให้เสร็จในครั้งเดียว
  • downloader ในตัวจำนวนมากขาด pause/resume, status notification, retry logic, progress tracking และยังมีข้อจำกัดอย่าง time limit สำหรับ download ซึ่งเป็นตัวกำหนดว่าแอปทั้งตัวจะใช้งานได้บนอินเทอร์เน็ตช้าหรือไม่

เหตุผลที่ตัวจัดการ download ของ browser เป็น baseline

  • download manager ของเว็บ browser สมัยใหม่ให้มาตรฐานสูงที่ downloader ในตัวหลีกเลี่ยงการถูกเทียบไม่ได้
    • interrupt, pause และ resume
    • retry download ที่ล้มเหลว
    • แสดงสถานะปัจจุบัน, ความเร็ว และเวลาที่เหลือ
    • เลือกตำแหน่งบันทึกและคัดลอกไฟล์ได้
    • ไม่มี cutoff ด้านประสิทธิภาพตามอำเภอใจ
  • แม้ผู้ใช้จะอยากดาวน์โหลดไฟล์หลาย GB ที่ 60kbps browser ก็ยอมให้ทำ
  • หากแอป implement ฟีเจอร์ระดับ browser ไม่ได้ อย่างน้อยก็ควรให้ URL ต้นทาง ที่ผู้ใช้สามารถดาวน์โหลดด้วย browser ได้

กรณีอัปเดต macOS

  • การอัปเดต macOS เป็นภาระหนักเป็นพิเศษที่ South Pole
    • ขนาด patch ของ minor OS update มักอยู่ที่ 0.5–1.5GB
    • patch ของ major OS upgrade บางครั้ง เกิน 6GB
    • เครื่องมือเพิ่มเติมอย่าง Xcode ก็มักมีขนาดหลาย GB
  • หากอุปกรณ์ macOS ทุกเครื่องดาวน์โหลด update จาก Apple โดยตรง จะเปลือง bandwidth อย่างมาก
  • updater ในตัวของ macOS มีการควบคุมน้อย และไม่มีวิธีง่าย ๆ ในการเอาไฟล์ patch เบื้องล่างมาใช้
    • หากยกเลิกหรือล้มเหลว ก็ไม่ได้ resume อย่างชาญฉลาดเสมอไป และบางครั้งเสีย progress
  • ฟีเจอร์ macOS caching server ของ Apple ในทางทฤษฎีสามารถลดภาระได้ด้วยการดาวน์โหลด patch แต่ละตัวมายัง South Pole เพียงครั้งเดียว
    • แต่ในทางปฏิบัติ client MacBook แต่ละเครื่องต้องทำ HTTPS call ไปยัง Apple สำเร็จเพื่อ negotiate parameter ของ cache
    • หาก call นี้ล้มเหลว client Mac จะดาวน์โหลด patch โดยตรงจาก public Apple server โดยไม่มี notification หรือ retry
    • ที่ South Pole การเรียก negotiate ตอนเริ่มต้นนี้ล้มเหลวบ่อย ทำให้ caching function ไม่ค่อยมีประโยชน์
  • ไฟล์ติดตั้งเต็มสามารถดาวน์โหลดจาก Apple ผ่านลิงก์ที่รวบรวมไว้ใน Mr. Macintosh แล้วนำมารับอย่างช้า ๆ แต่ระมัดระวังเพื่อกระจายในสถานีได้
    • ไฟล์ติดตั้งเต็มมีขนาด 12GB และการดาวน์โหลดอาจใช้เวลาหลายวัน แต่เชื่อถือได้
  • Mac ที่ใช้ Apple Silicon แม้อัปเดตด้วยไฟล์ติดตั้งเต็ม ก็ยังพยายามดาวน์โหลด content เพิ่มเติม 1–2GB จาก Apple โดยตรง เช่น firmware หรือ Rosetta update
    • ไม่มีวิธี bypass หรือ cache สิ่งนี้
    • บางครั้ง download ถูกส่งต่อไปยัง component แยกของ macOS ทำให้ progress ไม่สะท้อนใน UI การติดตั้ง
    • เกิดสถานการณ์ที่หน้าจอ “เหลือ 32 นาที” ค้างอยู่นานหลายชั่วโมง ขณะดาวน์โหลด 1GB ในเบื้องหลัง
  • จำเป็นต้องมีลิงก์ patch ที่ต้องใช้, pause/resume และการจัดการสถานะที่ดีขึ้น, รวมรายการเสริมสำหรับ Apple Silicon ไว้ในไฟล์ติดตั้งเต็ม และปรับปรุงความน่าเชื่อถือกับสิทธิ์ควบคุมของ caching server

กรณีอัปเดต Samsung Android OS

  • เครื่องมืออัปเดต OS ของโทรศัพท์ Samsung Android เป็นตัวอย่างของการไม่คำนึงถึงอินเทอร์เน็ตที่ช้าหรือขาด ๆ หาย ๆ
  • UI อัปเดตไม่มีการแสดงความเร็ว, progress เป็นตัวเลข, pause, cancel, ขนาดไฟล์ หรือวิธีเข้าถึงไฟล์สำหรับดาวน์โหลดแยกต่างหาก
  • หากดาวน์โหลดล้มเหลว จะ resume ไม่ได้และเริ่มใหม่ตั้งแต่ต้น
  • ที่ South Pole ไม่สามารถดาวน์โหลด OS update ทั้งหมดภายใน satellite pass เดียวได้ ดังนั้นเมื่อการเชื่อมต่อหลุด ย่อมล้มเหลวและต้องเริ่มใหม่ตั้งแต่ต้น
  • ในทางปฏิบัติมีการปิดโทรศัพท์ให้สนิทก่อนอินเทอร์เน็ตจะหลุด แล้วเปิดใหม่ใน satellite pass ถัดไป เพื่อหลีกเลี่ยงไม่ให้ระบบตัดสินว่าดาวน์โหลดล้มเหลว
    • วิธีนี้ทำให้แบ่งการดาวน์โหลดออกหลาย satellite pass จนเสร็จได้
    • workaround แบบนี้เป็นวิธีแก้ที่ผิดปกติและไม่ควรจำเป็น
  • แอปอัปเดตของ Verizon สำหรับ macOS และ Windows ในทางทฤษฎีให้ flash OS update จากคอมพิวเตอร์ได้ แต่ในความเป็นจริงมีบั๊กมาก ความน่าเชื่อถือต่ำ และใช้ downloader ในตัวของมันเอง
  • แก่นของปัญหาคือเครื่องมือสำหรับผู้ใช้ทั่วไปที่ vendor ให้มามี ฟีเจอร์ไม่เพียงพอ สำหรับผู้ใช้อินเทอร์เน็ตช้า

ความต่างระหว่างอัปเดตแอปขนาดเล็กกับ Microsoft Office for Mac

  • updater ในตัวของแอปเดสก์ท็อปขนาดเล็กหนึ่งขาดฟีเจอร์พื้นฐานที่จำเป็นบนลิงก์ช้า
    • ปุ่ม pause
    • ปุ่ม cancel
    • การแสดง progress
    • การแสดงความเร็วหรือเวลาที่เหลือ
    • การเข้าถึง URL ต้นทาง
    • progress tracking และการ resume อย่างเป็นธรรมชาติเมื่อ download ถูก interrupt
  • แอปนี้เพียงแค่ให้ลิงก์ดาวน์โหลดด้วยตนเอง ก็จะดีขึ้นมากสำหรับผู้ใช้ South Pole
  • auto-updater ของแอปอีกตัวมีปุ่ม cancel และ progress แบบภาพ แต่ยังขาด pause, progress/ความเร็วเป็นตัวเลข, การเข้าถึง URL ต้นทาง และ resume
  • auto-updater ของ Microsoft Office for Mac เป็นตัวอย่างที่ดีแม้ที่ South Pole
    • ปุ่ม pause
    • ปุ่ม cancel
    • การแสดง progress
    • การแสดงความเร็วและเวลาที่เหลือ
    • การ resume อย่างเป็นธรรมชาติเมื่อ download ถูก interrupt
  • หากให้ URL ต้นทางด้วยจะดียิ่งขึ้น แต่ interface ดีพอจนใช้งานที่ South Pole ได้พอสมควร

หลักการออกแบบเชิงปฏิบัติสำหรับผู้ใช้อินเทอร์เน็ตช้า

  • ฟีเจอร์ที่ดูเหมือนเป็นช่องว่างเล็ก ๆ ในสภาพอินเทอร์เน็ตเร็ว อาจกลายเป็น อุปสรรคสำคัญ บนอินเทอร์เน็ตช้า
  • แอปควรถูกออกแบบไม่ให้ผู้ใช้ติดอยู่ใน loop ที่ทำให้ส่งข้อความไม่กี่ byte ไม่ได้ เพียงเพราะ timeout ค่าตายตัวเดียว
  • หลักการออกแบบที่ทำได้มีความเรียบง่าย
    • หาก byte ยังเคลื่อนอยู่ อย่าหยุด
    • แบ่ง payload ขนาดใหญ่เป็น chunk
    • เก็บ progress ไว้แม้เกิดความล้มเหลว
    • แสดงสถานะเครือข่ายให้ผู้ใช้เห็นชัดเจน
    • หาก downloader ในตัวไม่เพียงพอ ให้ลิงก์ดาวน์โหลดด้วยตนเอง
  • South Pole เป็น edge case แต่สภาพ Inmarsat บนเรือในทะเล, Thales MissionLink และ Iridium Certus ที่สถานีวิจัยบนภูเขา, Wi‑Fi ที่ไม่เสถียร, router ที่ตั้งค่าผิด, WISP คุณภาพต่ำ และผู้ใช้ dial-up ผ่านสายโทรศัพท์เก่า ก็อาจเจอข้อจำกัดคล้ายกัน
  • นักพัฒนาไม่จำเป็นต้อง optimize ทุกสถานการณ์สุดขั้ว แต่จำเป็นต้องพยายามทำให้ผลิตภัณฑ์ ไม่ขัดขวางความคืบหน้าของผู้ใช้ ที่เชื่อมต่อช้าอย่างแข็งขัน

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

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

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

  • บทความนี้โดนใจมาก ผมไม่ได้อยู่แอนตาร์กติกา แต่อยู่ที่ ปักกิ่ง และก็ยังลำบากเพราะอินเทอร์เน็ตอยู่ดี
    ถ้าอยู่หลัง Great Firewall ก็ต้องใช้วิธีสร้างสรรค์หน่อย และแม้แต่ VPN ก็ใช้ได้เป็นครั้งคราวเท่านั้น VPN แต่ละตัวทิ้งร่องรอยไว้ ทำให้สุดท้ายฮิวริสติกและแมชชีนเลิร์นนิงของไฟร์วอลล์ก็จับได้ แม้แต่ VPN ที่รัฐอนุญาตเองก็ยังถูกจำกัดแบบ “นุ่มนวล” ในช่วงเวลาที่อ่อนไหวทางการเมือง
    ต่อให้เชื่อมต่อได้ สุดท้ายก็ไม่เสถียรอยู่ดี และการเอาแพ็กเก็ตอันมีค่าไปเปลืองกับคำขอไป-กลับไร้ประโยชน์ของเว็บแอป/React นี่ทรมานมาก
    นักพัฒนาบางคนควรย้อนเวลากลับไปราวปี 2005 แล้วลองพัฒนาตามมาตรฐานยุคนั้นบ้าง จะได้เรียนรู้วิธีทำให้มันเบา ถ้าย้อนเวลาไม่ได้ อย่างน้อยก็ช่วยเปิด การจำกัดความเร็ว ในเครื่องมือนักพัฒนา ปรับเป็น 3G แล้วเช็กหน่อยว่าเว็บแอปของตัวเองยังพอใช้งานไหวไหม

    • ไม่ต้องประดิษฐ์ไทม์แมชชีนหรอก แค่ส่งไปทำเวิร์กกิงรีทรีตในที่ที่มีแต่ สัญญาณมือถือแย่ๆ สักไม่กี่วันก็พอ
    • ผมอยู่ Shoreditch มา 7 ปี แล้วอินเทอร์เน็ตของบ้านส่วนใหญ่ที่เคยอยู่ก็แทบจะเร็วระดับ 3G บ้านหลังสุดท้ายหน้าต่างดันทำงานเหมือน กรงฟาราเดย์ โดยบังเอิญ
      ผมเลยทดสอบโปรเจกต์บนแบนด์วิดท์จำกัดตลอด เพราะเหมือนกับเรื่องการเข้าถึง ถ้าทำตามแนวปฏิบัติที่ดี มันจะมอบประสบการณ์ใช้งานที่ดีกว่าให้ทั้งผู้ใช้ที่เน็ตแย่และผู้ใช้ทุกคน
      อีกโอกาสหนึ่งที่มักถูกมองข้ามคือการทำ single-page app ให้เป็นแบบ offline-first
    • เรากำลังออกแบบโดยคำนึงถึงอินเทอร์เน็ตช้า และ React ก็เป็นหนึ่งในตัวเลือกที่ดีพอสมควรถ้าผสมกับ server-side rendering, code splitting, HTTP/2 push และไคลเอนต์ที่เป็นมิตรกับออฟไลน์มากกว่าอย่าง Tauri ถ้ารันบน “edge” ก็ยังดีพลอยใกล้ผู้ใช้ได้ด้วย
      ไม่ได้ถึงกับคัดค้านประเด็นหลักทั้งหมดนะ แต่ JavaScript ยุคใหม่จริงๆ แล้วค่อนข้างดีในการรับมืออินเทอร์เน็ตช้าสำหรับ “แอปพลิเคชัน” แบบเซิร์ฟเวอร์-ไคลเอนต์ เพียงแต่มันไม่ได้ทำให้ง่าย และแทบไม่มีข้อมูลออนไลน์ที่คนเขียนโค้ดด้วย Google/GPT จะเอาไปใช้เป็นฐานโปรเจกต์ได้
      ส่วนหนึ่งก็เพราะข้อมูล JavaScript แย่ๆ บนอินเทอร์เน็ตมีเยอะเกินไป แต่อีกส่วนก็เพราะองค์กรที่ทำงานแบบนี้ไม่ค่อยแชร์กัน เราเองก็ไม่มีเหตุผลจะให้ข้อมูลกับคู่แข่ง เลยไม่มีเอกสารสาธารณะเกี่ยวกับวิธีทำงานของเราเลย
    • ผมอยู่ในเมืองที่การเชื่อมต่อดี แต่บริษัทเบิกค่าใช้จ่ายให้เฉพาะ virtual machine ที่อยู่อีกทวีปหนึ่ง เลยทำให้โปรเจกต์ส่วนใหญ่ “เร็ว” แต่ถูกผูกติดกับ latency
      มันเลยกลายเป็นการฝึกที่น่าสนใจในการลดคำขอไป-กลับที่ไม่จำเป็น ในสแต็กเทคโนโลยีที่คาดหวังให้ทุกอย่างใช้ round trip
    • ตอนลอง VPN หลายตัวในจีน สุดท้ายผมถึงกับทำ ชั้น obfuscation สำหรับ Wireshark ขึ้นมาเอง พอลองค้นดูก็พบว่าใน GitHub มีโปรเจกต์คล้ายๆ กันอยู่หลายอัน แต่ของพวกนี้พอเริ่มเป็นที่สังเกตได้ก็ดูเหมือนจะใช้ไม่ได้ดีเหมือนเมื่อก่อน
      ตอนนี้ยังได้ราว 1~10Mbit/s อยู่ และส่วนใหญ่ขึ้นกับช่วงเวลา แทบไม่มีปัญหาเรื่องการเชื่อมต่อ

  • จากประสบการณ์นั่งขนส่งสาธารณะใต้ดินเป็นประจำระหว่างเดินทางไปทำงาน (สัญญาณขาดๆ หายๆ และแออัด) และจากการที่เคยใช้ชีวิตและทำงานในออสเตรเลีย ผมพูดได้อย่างมั่นใจว่าบริการส่วนใหญ่แย่มากสำหรับคนที่ไม่ได้อยู่ในสภาพเครือข่ายที่ “เหมาะสม”
    บน London Underground เห็นได้ชัดมากว่าแอปส่วนใหญ่รับมือกับเครือข่ายที่หลุดแล้วต่อใหม่ทุกประมาณ 2 นาทีได้แย่มาก มันจะหลุดระหว่างสถานี แล้วเพราะมีผู้โดยสาร 500 คนบนขบวนเดียวกันพยายามเชื่อมต่อพร้อมกัน แค่จะต่อเข้ากับ access point แต่ละจุดก็ใช้เวลาราว 15 วินาทีแล้ว
    ในออสเตรเลีย โดยทั่วไปคุณอยู่ห่างจากทุกอย่างประมาณ 200ms มันอาจดูไม่มาก แต่ทำให้เห็นชัดมากว่าแอปไหนสะดุดเพราะปัญหา N+1 requests
    แอปเดียวที่น่าประทับใจเสมอคือ WhatsApp มันกลับมาทำงานได้ก่อนใครหลังเชื่อมต่อใหม่ ยอมส่งทราฟฟิกได้จนวินาทีสุดท้ายก่อนหลุด และแม้จะมี latency การโทรก็ยังรู้สึกว่าตอบสนองได้ค่อนข้างเร็ว

    • 200ms บอกอะไรได้เยอะมาก
      มีโอกาสสูงว่า WhatsApp เป็นหนึ่งในไม่กี่บริการที่ นำเซิร์ฟเวอร์ไปวางในออสเตรเลียจริงๆ 200ms เป็นสัญญาณชัดเจนมากว่าทราฟฟิกกำลังข้ามทวีป
      บริษัทระดับโลกส่วนใหญ่ดีพลอยมากสุดแค่สามภูมิภาค คือสหรัฐ (us-east, us-central, us-east+us-east), ยุโรป (west-europe) และที่พบไม่บ่อยนักคือฝั่งตะวันออกไกล (us-west หรือญี่ปุ่น)
      ดังนั้นที่อย่างแอฟริกาใต้ อเมริกาใต้ หรือออสเตรเลีย ก็มักต้องดึงข้อมูลมาจากภูมิภาคใดภูมิภาคหนึ่งเหล่านี้ และด้วยข้อจำกัดทางฟิสิกส์จึงเกิด latency ขั้นต่ำราว 200ms
      ออสเตรเลียโดนหนักเป็นพิเศษ แม้ในทางทฤษฎีจะมี deployment แยกตามเขตอำนาจศาล แต่บ่อยครั้งเซิร์ฟเวอร์จริงกลับอยู่คนละทวีปโดยสิ้นเชิง (ฝั่งตะวันตกของสหรัฐหรือญี่ปุ่น) ทำให้ผู้ใช้ต้องรับผลด้านประสิทธิภาพจากการที่แพ็กเก็ตวิ่งอ้อมโลกไปครึ่งใบโดยตรง
    • WhatsApp มีฐานผู้ใช้ขนาดใหญ่มหาศาลใน ประเทศกำลังพัฒนา ที่อินเทอร์เน็ตช้าและอุปกรณ์ที่ช้ากว่านั้นเป็นเรื่องปกติ
      เพราะมุมมองแบบนั้นถูกฝังลึกอยู่ในเป้าหมายการพัฒนา ผมจึงคิดว่ามันอธิบายได้ดีว่าทำไม WhatsApp ถึงกลายเป็นแอปรับส่งข้อความหลักในหลายประเทศทั่วโลก
    • ปัญหาไม่ได้อยู่ที่ตัวบริการอย่างเดียวด้วย ผมใช้อินเทอร์เน็ตมือถือที่ช้ามาก และการดาวน์โหลดรูปภาพในเบราว์เซอร์นี่น่าหงุดหงิดสุดๆ
      ถ้าพยายามเปิด URL ของ .jpg ในเบราว์เซอร์เพื่อดูรูป มันใช้เวลานานกว่าการสลับไป termux แล้วรัน wget มาก บางทีก็ timeout ทั้ง Firefox และเบราว์เซอร์ตระกูล Chrome ก็เป็นเหมือนกัน
      อ้างอิงไว้ว่าแม้แต่การดาวน์โหลดด้วย wget บนการเชื่อมต่อมือถือก็มักใช้เวลา 10~30 วินาที
    • ดูเหมือนว่าใน London จะใช้ Wi‑Fi ได้แค่ที่สถานี และ Berlin ก็เหมือนกัน แต่ที่ Helsinki ใช้ Wi‑Fi ได้ทั้งบนรถไฟและที่สถานี เลยไม่โดนตัดการเชื่อมต่อระหว่างเดินทาง
      ผมไม่เข้าใจว่าทำไม Berlin ถึงทำแบบนี้ แค่ให้มีอินเทอร์เน็ตบนขบวนรถก็น่าจะจบ
      ถ้าเครือข่ายตัดๆ ต่อๆ อยู่ตลอด อินเทอร์เน็ตส่วนใหญ่จะใช้งานได้แย่มาก
    • การที่ London Underground ไม่ได้ให้การเชื่อมต่อจนช้ากว่าระบบรถไฟใต้ดินอื่นๆ เป็นเวลาหลายสิบปี ก็แค่แสดงให้เห็นว่าการเชื่อมต่อสูงระหว่างการเดินทางไม่ใช่สิ่งจำเป็นเสมอไป

  • เดินทางบ่อยเลยเจอ อินเทอร์เน็ตช้า ค่อนข้างเป็นเรื่องปกติ ตอนนี้ก็ใช้ข้อมูลมือถือหมดแล้วเลยถูกจำกัดเหลือ 8kbps
    ถ้าเป็นเว็บไซต์ที่มีแต่ข้อความก็น่าจะต้องเร็ว แต่หลายเว็บกลับไม่เป็นแบบนั้น Hacker News เร็วมาก แต่เอกสาร Google API เปิดไม่ขึ้นเลย
    ปัญหาที่แย่ที่สุดคือ UI ส่วนใหญ่ไม่ได้ออกแบบโดยคำนึงถึงคำขอที่ช้า ปุ่มเลยให้ความรู้สึกเหมือนพัง และสิ่งที่ไม่ควรต้องใช้ข้อมูลระดับหลายเมกะไบต์ก็ยังใช้เวลาโหลดเป็นนาทีหรือล้มเหลวได้ UI ของ Google Maps พังหมดทั้งชุด
    อยากให้นักพัฒนาออกแบบและทดสอบกับอินเทอร์เน็ตช้ากันมากกว่านี้ แต่กลับได้เว็บที่กินดาต้าหนักซึ่งทำงานดีแค่บนโน้ตบุ๊กบริษัทแรง ๆ กับอินเทอร์เน็ตเร็ว ๆ
    อีกเรื่องหนึ่งคือ ผมหาเลี้ยงชีพด้วยการทำเว็บ และการย้ายไปใช้ static site generator เป็นหนึ่งในการตัดสินใจที่ดีที่สุดด้านประสิทธิภาพการทำงาน แทนที่ latency ของ CMS จะซึมอยู่ในทุกขั้นตอน ผมกลับแก้ไขไฟล์ข้อความได้เร็วมากแม้จะออฟไลน์สนิท และพอออนไลน์ก็ค่อย push แค่ส่วนที่เปลี่ยนไป มันเปลี่ยนเกมเลย

    • เมื่อก่อน Google ใส่ใจแอปที่ช้าได้ดี ตอนสมัยใช้ Gmail บนคอมโรงเรียน ถ้าเว็บโหลดช้าเกินไป มันจะตรวจจับแล้วแสดง เวอร์ชัน HTML พื้นฐาน แทน
      ทุกวันนี้ต่อให้แคช Google Maps ลงมือถือ 500MB ก็ดูเหมือนไม่มีความหมาย มันก็ยังดึงทุกอย่างอยู่ดีแล้วค่อยโผล่มาทีหลัง
    • ผมเพิ่งเรียนรู้อย่างยากลำบากถึงข้อดีเพิ่มเติมของเว็บแบบสแตติกอย่างหนึ่ง คือมันแทบจะมีภูมิคุ้มกันต่อการโจมตี
      ตอนนี้โดเมนหนึ่งของผมถูกติดป้ายว่า “อันตราย” เพราะไม่ได้ใช้ WordPress เวอร์ชันล่าสุด
    • ผมเคยทำงานในทีมที่ให้บริการเอกสารนั้น ด้วยการตัดสินใจทางเทคนิคที่โชคร้ายภายใต้ข้ออ้างว่าจะทำเอกสารให้เป็นแบบไดนามิกและโต้ตอบได้ ทำให้เกือบทั้งหมด ไม่ถูกแคช
      โดยพื้นฐานแล้วทุกคำขอที่ส่งไปจะไปถึงแอป AppEngine แล้วแอปนั้นก็รันโค้ด Python เพื่อคืน HTML กลับมา เลยดูเหมือนว่าน่าจะเร็ว แต่ในความเป็นจริงไม่ใช่
    • สถานการณ์ไม่ได้เรียบง่ายแบบนั้นเสมอไป
      ผมอยู่ในสหราชอาณาจักร และ ping ไปที่ news.ycombinator.com ได้ 147ms ดูเหมือนเพราะโฮสต์อยู่ในสหรัฐฯ และไม่ได้ใช้ CDN
      ในทางกลับกัน cloud.google.com มี ping แค่ 8ms
      Hacker News เป็นหน้าเว็บเรียบง่ายและมี JavaScript น้อย แต่ก็อาจมีปัจจัยอื่นที่ทำให้ผู้ใช้บางภูมิภาครู้สึกว่ามันช้าได้ แม้จะอยู่ในสภาพแวดล้อมอภิสิทธิ์ที่ใช้ สายไฟเบอร์ XGS-PON แบบ symmetric 8Gbps ก็ตาม

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

    • ผมสงสัยว่าการปฏิบัติการจริงเป็นอย่างไร ไม่ใช่ทุกคนจะรู้ว่าระบบปฏิบัติการหรือแอปของตัวเองเริ่มอัปเดตเมื่อไร
      โทรศัพท์ในกระเป๋าอาจกำลังใช้แบนด์วิดท์ทั้งหมดเท่าที่จะใช้ได้โดยไม่จำเป็น และถ้ามีคนดูวิดีโอ 720p แบบที่เล่นได้แบบกระตุก ๆ คนที่พยายามจะโหลดต่อจากนั้นอาจดูได้ไม่ถึง 480p ด้วยซ้ำ เจ้าตัวอาจไม่รู้เพราะมีบัฟเฟอร์อยู่ ส่วนอีกคนอาจยอมแพ้ก่อนที่บัฟเฟอร์จะเต็มพอ
      อย่างน้อยน่าจะมี การทำบัญชีการใช้งาน ที่บอกว่าในทราฟฟิกช่วง 1 ชั่วโมงที่ผ่านมา มีกี่ % ที่เป็นของตัวเอง และถ้าทุกคนต้องการใช้อย่างเท่าเทียมกัน ส่วนแบ่งของตัวเองควรเป็นกี่ % เมื่อเทียบกับค่ามาตรฐานที่เอาแบนด์วิดท์ที่ใช้ได้หารด้วยจำนวนผู้ใช้ที่เชื่อมต่อ
      ไปไกลกว่านั้นก็ดูเหมือนจะทำระบบได้ด้วย คือกำหนดให้ทุกคนอยู่ที่ลำดับความสำคัญต่ำก่อน แล้วค่อยกดปุ่มว่า “ใช่ ผมรู้ว่าต่อจากนี้ [X≤24] ชั่วโมงจะใช้แบนด์วิดท์ และจำเป็นต้องใช้จริง” จากนั้นค่อยยกระดับ QoS priority ของ MAC/IP address กลับเป็นปกติ

  • สถานการณ์แบบนี้เหมือนกำลังร้องตะโกนว่าจำเป็นต้องมี แอปพลิเคชันแบบ local-first และทางแก้ ซึ่งจริง ๆ แล้วนั่นก็เป็นเหตุผลที่อินเทอร์เน็ตถูกสร้างขึ้นมาตั้งแต่แรก [1][2]
    ผู้คนถูกคำโฆษณา “No Software” ของ Salesforce หลอก ซึ่งขัดกับรากฐานและจิตวิญญาณของอินเทอร์เน็ตโดยตรง ตลอดประวัติศาสตร์อินเทอร์เน็ตส่วนใหญ่นับตั้งแต่ปี 1969, Mbps เป็นข้อยกเว้น ไม่ใช่มาตรฐาน และแอปนักฆ่าตัวแรกอย่างการส่งข้อความอีเมล (และอาจยังเป็นแอปอินเทอร์เน็ตที่ดีที่สุดมาจนถึงตอนนี้) ก็เป็นแบบ local-first [3]
    น่าขันที่แอปพลิเคชันที่ผู้เขียนกำลังคร่ำครวญถึงก็เป็นแอปแชตเหมือนกัน
    [1] Local-first software: You own your data, in spite of the cloud:
    https://www.inkandswitch.com/local-first/
    [2] Local-first Software:
    https://localfirstweb.dev/
    [3] Leonard Kleinrock: Mr. Internet:
    https://www.latimes.com/opinion/la-oe-morrison-use24-2009oct...

  • ฉันทำงานด้านเครือข่ายมาเยอะตลอดหลายปีที่ผ่านมา และใช้เวลาทำสภาพแวดล้อม “อินเทอร์เน็ตช้า” ของตัวเองให้ใช้งานได้ แม้จะไม่น่าสนใจเท่า McMurdo แต่ฉันก็แชตและดูวิดีโอ YouTube ได้ทั้งบนเที่ยวบินระหว่างประเทศ รถไฟที่วิ่งผ่านพื้นที่ห่างไกล โรงแรมชนบทสุดห่วย และแม้แต่ในอุโมงค์
    ถ้าคุณเข้าถึงอุปกรณ์คอมพิวเตอร์เอนกประสงค์ได้ รับภาระเรื่องพลังงานไหว (อุปกรณ์แบบนี้มักกินไฟมาก) และตั้งใจจะประกอบเอง ฉันขอแนะนำ NNCP [1] NNCP สามารถรับข้อมูล แบ่งเป็นชิ้น แล้วส่งออกไปได้ นอกจากนี้ยังมีโปรโตคอลซิงก์ที่ใช้ noise บน TCP และส่งซ้ำเฉพาะชิ้นที่ล้มเหลวได้ด้วย ไม่ต้องใช้ TLS จึงใช้เวลาเพียง 1.5 RTT ในการตั้งการเชื่อมต่อ
    NNCP สามารถป้อนข้อมูลไปยังโปรแกรมระยะไกลผ่าน standard input ได้ ฉันเคยทำ YouTube downloader, Slack bot, Telegram bot และ Discord bot ให้คอยอ่านข้อมูลขาเข้าแล้วโต้ตอบกับบริการนั้น ๆ บนเครื่องโลคัลฉันรันเซิร์ฟเวอร์ Matrix (Dendrite) และบอตไว้ แล้วส่งข้อมูลผ่าน NNCP ไปยังบริการระยะไกลที่เหมาะสม
    คุณอาจต้องทดลองหรือหวังว่า MTU/MSS ตามเส้นทางจะต่ำที่สุดเท่าที่เป็นไปได้ เพื่อให้มีการส่งซ้ำในระดับ TCP ได้บ่อย แต่ชุดคอนฟิกนี้แทบไม่เคยล้มเหลวไม่ว่าจะไปที่ไหน และทำให้ทั้งการเสพสื่อและการแชตเป็นไปได้
    สิ่งที่น่าหงุดหงิดที่สุดบนเที่ยวบินระหว่างประเทศคือ endpoint ของ NNCP ไม่ได้กระจายตัวทางภูมิศาสตร์ หากขึ้นอยู่กับเส้นทางการบินและเส้นทางจริงที่แพ็กเก็ตวิ่งไปถึง endpoint ค่า latency และ jitter อาจเพิ่มขึ้นมาก โดยปกติฉันพยายามวาง endpoint ของ NNCP ไว้ใกล้จุดหมาย แต่สำหรับ Wi-Fi บนเครื่องบิน เส้นทางจริงอาจแย่มาก ตอนนี้ NNCP รองรับ Yggdrasil แล้ว ซึ่งอาจช่วยบรรเทาเรื่องนี้และช่วยควบคุมปัญหา MTU ได้ แต่ฉันยังไม่เคยลองใช้ Ygg ในสภาพแบบนี้
    [1]: http://www.nncpgo.org/

    • น่าสนใจ มีบทความที่อธิบายวิธีจัดคอนฟิกไหม?

  • ฉันมีประสบการณ์คล้ายผู้เขียนตอนอยู่บนเรือในแปซิฟิกใต้ มี Starlink แต่ไม่ได้ใช้บ่อยเพราะกินไฟสูง (มากกว่า 60W) เลยซื้อ SIM ท้องถิ่นมาใช้ และในบางแห่งได้ 4G บางแห่งได้ EDGE (2G)
    ตัว EDGE เองตามสเปกไม่ได้แย่มากนัก ยังได้ระดับหลายสิบกิโลบิตต่อวินาที แต่ในการใช้งานจริงมันแย่กว่านั้นมาก ฉันเจอแอปที่น่าจะทำงานได้ดีถ้าแค่คำนึงว่าการโหลดอาจใช้เวลาเป็นนาทีแทนมิลลิวินาที แต่กลับล้มเหลวเพราะ timeout ที่สั้นเกินไป
    การเชื่อมต่อแบบ แบนด์วิดท์ต่ำ·latency สูง ควรถูกรวมอยู่ในการทดสอบซอฟต์แวร์เป็นประจำ Linux มี netem(https://wiki.linuxfoundation.org/networking/netem) ที่ช่วยให้ทำแบบนั้นได้
    ปัญหาอีกอย่างที่บล็อกเกอร์นิรนามไม่ได้เจอคือการเชื่อมต่อแบบคิดค่าบริการตามปริมาณใช้งาน เพราะค่าใช้จ่ายทำให้แทบเป็นไปไม่ได้เลยที่จะอัปเกรดระบบปฏิบัติการหรือแอป โชคดีที่ทุก ๆ สองสามสัปดาห์ฉันจะไปถึงที่ที่มีการเชื่อมต่อไม่จำกัดและทำงานพวกนั้นได้ ผลก็คือฉันคุ้นเคยมากกับการตั้งค่าให้หลายระบบปฏิบัติการมองการเชื่อมต่อว่าเป็นแบบคิดตามปริมาณ/ไม่คิดตามปริมาณ ปิดการอัปเดตอัตโนมัติทั้งหมด และประหยัดแบนด์วิดท์อันมีค่า

    • ถ้าเป็นแปซิฟิกใต้ แสงแดดก็น่าจะแรงมาก จึงน่าแปลกที่ไม่มีแผงโซลาร์พอจ่ายไฟมากกว่า 60W
      อีกอย่าง ถ้าบอกว่าเป็น “SIM ท้องถิ่น” ก็น่าจะหมายความว่าได้ขึ้นฝั่งไปซื้อ SIM บนเกาะ ฉันเลยสงสัยว่าในยุค 2020s ยังมีที่ไหนที่ใช้ได้แค่ 2G อยู่บ้าง เชื่อยากเหมือนกันว่าในแปซิฟิกใต้ยังมีแบบนั้นเหลืออยู่
    • “ขนาดเดียวเหมาะกับทุกคน” ใช้ไม่ได้เสมอไป การออกแบบหรือออกแบบแอปใหม่เพราะมีผู้ใช้กลุ่มหนึ่งที่อาจอยู่บนเรือกลางมหาสมุทรแปซิฟิก อาจเป็นการเสียเวลาและแรงเปล่า
      ต้องรักษามุมมองไว้ให้ดี บางโปรเจกต์ถึงขั้นข้ามการทดสอบเว็บแอปบนหลายเบราว์เซอร์ เพราะมองว่าเป็นความสิ้นเปลืองและต้นทุนที่ไม่สมเหตุสมผล ทั้งที่การใส่ไว้ใน test matrix นั้นเป็นเรื่องเล็กน้อยและเป็นแค่ปัญหาฝั่ง UI เท่านั้น

  • วิศวกรรมที่คำนึงถึงอินเทอร์เน็ตช้ายังคงสำคัญมากจริง ๆ และน่าจะถูกประเมินต่ำไปมากโดยนักพัฒนาซอฟต์แวร์ส่วนใหญ่ แต่ระบบดาวเทียมวงโคจรต่ำ (Starlink โดยเฉพาะ StarLink) ได้แก้ปัญหาหลักในทางปฏิบัติไปแล้ว
    ช่วงกันยายน–ตุลาคม 2023 ฉันเดินทางผ่านเส้นทางอาร์กติก (จาก Alaska ไป Norway) และแม้อยู่บนเรือที่เลยวงกลมอาร์กติกขึ้นไปมาก ก็ยังวิดีโอคอลผ่าน FaceTime ได้ทั้งที่มีเมฆ อยู่ไกลจากแผ่นดิน และมีน้ำแข็งด้วย ช่วงเวลาเดียวกับที่ผู้เขียนอยู่ที่ Antarctica
    ไม่ว่าข้อจำกัดนั้นคืออะไร ท้ายที่สุดก็เป็นเรื่องของการนำสัญญาบริการและเทอร์มินัลไปไว้หน้างาน ความครอบคลุมในเขตขั้วโลกมีไม่มากนักเมื่อเทียบกัน แต่ประชากรก็น้อยมากจนยังเพียงพอ
    https://satellitemap.space/

    • ความเห็นที่ว่าระบบดาวเทียมวงโคจรต่ำแก้ปัญหาหลักแล้ว ดูเหมือนจะยังมองไม่ตรงจุดของปัญหาพื้นฐาน
      อินเทอร์เน็ตช้ามีได้หลายความหมาย และหนึ่งในนั้นคือปัญหาการเชื่อมต่อ สำหรับโปรโตคอลแบบ connection-oriented อย่าง TCP ความช้าหมายถึงการช้าลงจาก packet loss ส่วนโปรโตคอลแบบส่งแล้วจบอย่าง UDP หมายถึงข้อความไปไม่ถึง ดังนั้นความช้าอาจหมายถึงอัตรารับส่งต่ำ หรืออาจเป็นลักษณะที่ throughput พุ่งสูงเป็นช่วง ๆ แล้วหลุดเป็นพัก ๆ
      แนวทางที่ทนทานอย่างหนึ่งในการรับมือเครือข่ายช้าคือรองรับโหมดออฟไลน์ ออกแบบการ push/pull ข้อมูลทั้งหมดให้เป็นธุรกรรมแบบ asynchronous และแคชการ push ข้อมูลไว้ในเครื่องเพื่อคอยลองใหม่เมื่อทำได้ แบบนี้ก็จะมีความต้องการเพิ่มขึ้น เช่น versioning และการจัดการ conflict
      ตามธรรมชาติแล้วความต้องการฝั่ง UI ก็เพิ่มขึ้นด้วย ต้องมีการซิงก์/รีเฟรชด้วยตนเอง การแสดงสถานะเครือข่าย การปิดการทำงานที่ไม่มีความหมายเมื่อเครือข่ายหลุด และการโหลดไว้ล่วงหน้าเพื่อให้ใช้งานแบบออฟไลน์ได้
    • ฉันมีร้านอาหารที่ไปประจำใน SF ปกตินั่งโต๊ะที่อยู่ห่างจากประตูราว 15 ฟุตในย่านการค้าที่คนแน่น มีสิทธิ์เข้าถึงเครือข่ายพรีเมียมของ Verizon และ iPhone XS ก็ขึ้น LTE สองขีด แต่ไม่เคยได้ throughput มากพอแม้แต่ให้ DNS resolve ได้เลย ที่คลินิกทันตกรรมก็เหมือนกัน
      สักวันหนึ่งอยากอยู่ในโลกหลังยุคอินเทอร์เน็ตช้า แต่คงยังอีกหลายปี อนึ่ง XS ใช้ Intel modem ที่ขึ้นชื่อว่าด้อยกว่า Qualcomm รุ่นเรือธงในยุคนั้น
    • เมื่อคนเต็มขบวนรถไฟชานเมืองมาเชื่อมกับ access point เดียวกับที่สถานีที่ฉันอยู่ ดาวเทียมวงโคจรต่ำ จะช่วยอะไรได้?
      ฉันอาศัยอยู่ในหนึ่งในพื้นที่ที่มีความหนาแน่นประชากรสูงที่สุดในโลก เต็มไปด้วยเสา 5G และสถานี Wi-Fi แต่ก็ยังรู้สึกได้เสมอว่าเว็บไซต์ที่ทำแบบลวก ๆ ล้มไม่เป็นท่าเมื่อเจอการเชื่อมต่อช้าหรือไม่เสถียร
    • ที่ Pole ไม่มี Starlink แต่ที่ McMurdo มี และมีเหตุผลอยู่
      ดาวเทียมค้างฟ้ามีข้อจำกัดด้านการครอบคลุมในเขตขั้วโลก เพราะที่ Pole มันอยู่ใกล้ขอบฟ้ามากเกินไป Pole ใช้ดาวเทียมค้างฟ้ารุ่นเก่าที่มีเชื้อเพลิงน้อยและมุมเอียงวงโคจรค่อนข้างมาก ดังนั้นจึงสื่อสารได้เพียงราว 6 ชั่วโมงจาก 24 ชั่วโมง
      ตารางเวลา: https://www.usap.gov/technology/1935/
    • มองในแง่ดีเกินไปมาก ต่อไปหลายประเทศน่าจะรบกวนสัญญาณ Starlink เพื่อบล็อกมัน คล้ายกับที่บางประเทศรบกวน GPS อย่างหนักและทำได้สำเร็จ
      รัฐบาลคงไม่ต้องการเว็บที่ไม่ถูกเซ็นเซอร์ หรือให้บริษัทอเมริกันเป็นประตูสู่อินเทอร์เน็ต พวกเขาจะยังคงรักษาเครือข่ายภายในดินแดนที่ตนถือครองไว้ และปัญหาเรื่องความเร็วก็จะยังคงมีผลอยู่
      ควรคำนึงด้วยว่าทั่วโลกมีคนจำนวนมากที่อุปกรณ์เข้าถึงอินเทอร์เน็ตมีเพียงโทรศัพท์ Android ราคา 100 ดอลลาร์ที่ใช้ซอฟต์แวร์เก่าและ CPU จำกัด

  • มีข้อเสนอร่าง IETF สำหรับขยาย HTTP เพื่อซิงก์สถานะอย่างมีประสิทธิภาพ ซึ่งอาจช่วยปรับปรุงประสบการณ์ผู้ใช้บนเครือข่ายช้าได้: https://news.ycombinator.com/item?id=40480016
    Braid Protocol ทำให้อัลกอริทึมการซิงก์หลายแบบทำงานร่วมกันได้บนโปรโตคอลเครือข่ายร่วมกัน และข้อความเครือข่ายของตัวซิงก์ใด ๆ ก็สามารถแปลงขึ้นไปอยู่บนนั้นได้ ปัจจุบันสเปกของ Braid เพิ่มมิติการซิงก์สองระดับให้ HTTP
    Level 0: HTTP แบบทุกวันนี้
    Level 1: subscription ที่มี push update
    Level 2: ความสอดคล้องแบบ P2P (patch, version, merge)
    ปัจจุบันตัวซิงก์ใช้โปรโตคอลต่างกัน แต่ข้อความเครือข่ายกลับส่งข้อมูลชนิดเดียวกัน คือเวอร์ชันตามเวลา ตำแหน่งในเชิงพื้นที่ และแพตช์ของพื้นที่ในช่วงเวลา การประกอบรวมกันของชุดแพตช์ใด ๆ จะก่อเป็นโครงสร้างทางคณิตศาสตร์ที่เรียกว่า braid เป็นการแตกแขนง การรวม และการจัดเรียงใหม่ของพื้นที่ตามเวลา
    ความหวังยังคงผุดขึ้นมาไม่รู้จบ

    • ดีเลย ได้โปรด! เพิ่มชั้นขยะที่ซับซ้อนโดยไม่จำเป็นเข้าไปอีก รับรองว่าต้องดีขึ้นแน่นอน
    • ฟังดูคล้าย Matrix อย่างน่าสงสัย แบบนี้ต้องอาศัยการยินยอมจาก user agent หรือถ้านำไปใช้แล้วเบราว์เซอร์เดิม ๆ ก็ได้ประโยชน์ด้วย?
    • ถ้ามองแบบประชด เทคโนโลยีที่ซับซ้อนขึ้นไม่ได้แก้ปัญหาทางธุรกิจและสังคม ที่แท้จริงหรอก อันที่จริง ถ้าจะทำให้เละแบบนี้ต้องตั้งใจพยายามกันพอสมควร
      การลดจำนวน request แบบไป-กลับและทำของที่ไม่บวมเกินนั้นไม่ยาก แถมง่ายกว่ามากด้วยซ้ำ ความอืดบวมมีอยู่ด้วยเหตุผลคนละแบบโดยสิ้นเชิง
      บางครั้งบนอินเทอร์เน็ตเร็ว ๆ ใกล้ดาต้าเซ็นเตอร์และเครื่องแรง ๆ ความอืดบวมแทบมองไม่เห็น จำลองได้ง่าย แต่บริษัทต้องใส่ใจถึงจะทำ โดยมากแล้ว ad tech และสิ่งรอบตัวมันแทบไม่สนใจผู้ใช้กลุ่มเล็ก ๆ เลย ที่จริงเหตุผลเดียวที่พวกเขาสนใจผู้ใช้ปลายทาง ก็เพราะผู้ใช้เหล่านั้นสร้างรายได้ให้ลูกค้าตัวจริง นั่นคือผู้ลงโฆษณา

  • คนที่สร้างแอป เว็บไซต์ และอื่น ๆ อย่างพวกเรา ต้องจำไว้ว่า มีคนจำนวนมากที่ไม่ได้เชื่อมต่อกับ Wi‑Fi เร็ว ๆ หรือไฟเบอร์แบบที่เราใช้
    ในสหราชอาณาจักร ผู้ให้บริการบางรายเริ่มยุติ 3G แล้ว บางแห่งยังคง 2G ไว้เป็นทางเลือกพลังงานต่ำ แต่โดยรวมคือให้ไปใช้ 4G/5G ปัญหาคือ 4G ยังใช้ไม่ได้ทุกพื้นที่ และจนไม่นานมานี้ บางพื้นที่สัญญาณ 3G ยังดีกว่า
    ผลคือมีการตกลงไปอยู่ที่ 2G/EDGE แบบไม่ตั้งใจบ่อยขึ้น และหลายอย่างก็หยุดทำงานไปเลย แอปจำนวนมากไม่ได้ทดสอบกับสถานการณ์ที่ช้า หน่วงสูง และ packet loss มาก

    • การยุติ 3G เป็นความผิดพลาด นอกจากจะทำให้อุปกรณ์จำนวนมหาศาลกลายเป็นขยะอิเล็กทรอนิกส์ แล้ว มันยังเป็นแบ็กอัปที่ดีเมื่อ 4G แออัด
    • ในสหรัฐฯ ถ้าใช้แพ็กเกจข้อมูลหมด หลายเครือข่ายจะลดลงไปเหลือ 2G คนจนส่วนใหญ่มีโควตาข้อมูลต่ำมาก จึงต้องอยู่กับ2G เกือบทั้งเดือน
      ลองเปิด Google Maps บน 2G เพื่อหาเส้นทางดู แล้วจะเข้าใจ :(