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

 (brr.fyi)
2 คะแนน โดย GN⁺ 2024-06-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ประสบการณ์การใช้อินเทอร์เน็ตในแอนตาร์กติกา

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

ปัญหาด้านวิศวกรรมเว็บและแอปในสภาพแวดล้อมอินเทอร์เน็ตความเร็วต่ำ

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

ปัญหาหลักและแนวทางแก้ไข

การกำหนด timeout และขนาดชังก์แบบฮาร์ดโค้ด

  • timeout และขนาดชังก์ที่กำหนดแบบฮาร์ดโค้ดก่อปัญหาใหญ่ในสภาพแวดล้อมอินเทอร์เน็ตความเร็วต่ำ
  • แนวทางแก้ไข:
    • หากข้อมูลยังไหลอยู่ก็ปล่อยให้ทำงานต่อไป และแสดงความคืบหน้าผ่าน UI
    • หากการเรียก HTTPS ล้มเหลว ให้ลองใหม่ด้วย timeout ที่ยาวขึ้น
    • อย่าส่งข้อมูลก้อนใหญ่ในครั้งเดียว แต่แบ่งส่งเป็นชังก์เล็ก ๆ
    • เมื่อเกิดปัญหาให้วิเคราะห์ผ่าน DNS, ICMP, HTTP เป็นต้น

ตัวอย่างที่ 1 - การดาวน์โหลดเมตาดาต้าของแอป

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

ตัวอย่างที่ 2 - แอปแชต

  • แอปแชตบางตัวล้มเหลวเพราะใช้ timeout 10 วินาทีในการเริ่มต้น WebSocket
  • ในทางกลับกัน แอปแชตอีกตัวหนึ่งรับมือกับสภาพเครือข่ายที่หลากหลายได้ดี
  • แนวทางแก้ไข:
    • ปรับ timeout แบบไดนามิก และลองใหม่อย่างชาญฉลาดเมื่อเกิดความล้มเหลว
    • แสดงสถานะเครือข่ายปัจจุบันอย่างชัดเจน

ตัวอย่างที่ 3 - การส่งแบบค่อยเป็นค่อยไป

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

การเปิดให้ผู้ใช้ดาวน์โหลดได้เอง

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

ตัวอย่างที่ 1 - การอัปเดต macOS

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

ตัวอย่างที่ 2 - การอัปเดต OS ของโทรศัพท์ Android Samsung

  • การอัปเดต OS ของโทรศัพท์ Android Samsung ล้มเหลวเพราะไม่มีความสามารถหยุดชั่วคราว/ทำต่อ
  • แนวทางแก้ไข:
    • เพิ่มความสามารถหยุดชั่วคราว/ทำต่อในเครื่องมือดาวน์โหลด
    • จัดเตรียมลิงก์ให้ผู้ใช้ดาวน์โหลดไฟล์ได้โดยตรง

ตัวอย่างที่ 3 - การอัปเดตอัตโนมัติของแอปขนาดเล็ก

  • การอัปเดตอัตโนมัติของเดสก์ท็อปแอปขนาดเล็กก่อปัญหาเพราะไม่มีปุ่มหยุดชั่วคราว/ยกเลิก
  • แนวทางแก้ไข:
    • เพิ่มปุ่มหยุดชั่วคราว/ยกเลิกในเครื่องมือดาวน์โหลด

ความเห็นของ GN⁺

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

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

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

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

  • สภาพแวดล้อมอินเทอร์เน็ตของจีน: อินเทอร์เน็ตในจีนไม่เสถียรและ VPN ก็ถูกจำกัด นักพัฒนาจำเป็นต้องย้อนกลับไปคิดแบบปี 2005 และสร้างเว็บแอปที่มีประสิทธิภาพมากกว่านี้

  • ปัญหาเครือข่ายในออสเตรเลียและลอนดอน: เครือข่ายในออสเตรเลียและบนรถไฟใต้ดินลอนดอนมักหลุดบ่อย แต่แอปส่วนใหญ่รับมือกับเรื่องนี้ได้ไม่ดีนัก โดย WhatsApp เป็นข้อยกเว้นที่ทำงานได้ดีเป็นพิเศษ

  • ข้อเสนอให้ใช้รีโมตเดสก์ท็อป: มีคำถามว่าการใช้รีโมตเดสก์ท็อปอาจให้ประสบการณ์ที่ดีกว่าหรือไม่ อย่างไรก็ตาม ประสิทธิภาพของ VNC/Windows Remote Desktop ภายใต้สภาพเครือข่ายที่ย่ำแย่ยังไม่แน่ชัด

  • ปัญหาของอินเทอร์เน็ตช้า: เว็บไซต์จำนวนมากทำงานได้ไม่ดีบนอินเทอร์เน็ตที่ช้า แม้แต่หน้าที่มีแต่ข้อความก็ยังโหลดช้า การเปลี่ยนไปใช้ static site generator ช่วยเพิ่มประสิทธิภาพการทำงานได้มาก

  • ซอฟต์แวร์แบบ local-first: จำเป็นต้องมีซอฟต์แวร์แบบ local-first ซึ่งสอดคล้องกับจุดประสงค์ดั้งเดิมของอินเทอร์เน็ต และช่วยให้ยังคงความเป็นเจ้าของข้อมูลไว้ได้

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

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

  • ความจำเป็นในการคำนึงถึงสภาพเครือข่ายช้า: ผู้คนจำนวนมากยังไม่สามารถเข้าถึงอินเทอร์เน็ตความเร็วสูงได้ จึงควรพัฒนาแอปที่ทำงานได้ดีแม้ในสภาพเครือข่ายช้า

  • ประสบการณ์ในแปซิฟิกใต้: เนื่องจาก Starlink ใช้พลังงานสูง จึงเลือกใช้ซิมท้องถิ่นแทน แต่เครือข่าย EDGE (2G) ช้ามาก การทดสอบซอฟต์แวร์ควรรวมการเชื่อมต่อความเร็วต่ำและมี latency สูงไว้ด้วย

  • การแก้ปัญหาอินเทอร์เน็ตบนเรือ: เพื่อใช้อินเทอร์เน็ตบนเรืออย่างมีประสิทธิภาพ มีการใช้วิธีอย่างการบล็อก DNS query การจำกัดเซสชันของผู้ใช้ และการกระจายแบนด์วิดท์อย่างเป็นธรรม