- Internet ở South Pole phụ thuộc vào các liên kết vệ tinh hạn chế và chỉ kết nối được vài giờ mỗi ngày, nên tính đến tháng 10/2023, người dùng cộng đồng phải chấp nhận độ trễ cao, băng thông thấp và gián đoạn không thường xuyên
- Trong thực tế, môi trường này có độ trễ khứ hồi khoảng 750ms, jitter kéo dài nhiều giây, tốc độ từ vài kbps đến 2Mbps, cùng với tắc nghẽn, hàng đợi, mất gói và việc dịch vụ bị giành quyền ưu tiên, đủ để dễ dàng phá vỡ các giả định mạng của ứng dụng thông thường
- Các gói JavaScript lớn, timeout hard-code, bỏ mất tiến độ, vô hiệu hóa cache, và trình tải xuống tích hợp không thể tiếp tục khiến ứng dụng tự làm mình thất bại trên các kết nối chậm
- Nếu byte vẫn đang chảy dù chậm, cứ chờ; nếu hỗ trợ truyền theo chunk, tiếp tục, hiển thị trạng thái, timeout động và liên kết tải thủ công thì vẫn có thể đạt được các mục tiêu nhỏ như nhắn tin văn bản hay cập nhật
- Nam Cực là trường hợp cực đoan, nhưng tàu biển, điểm nghiên cứu vùng núi, Wi‑Fi không ổn định, WISP chất lượng thấp và người dùng truy cập qua đường dây điện thoại cũng có thể gặp các ràng buộc tương tự, nên cần thiết kế không cản trở tiến trình của người dùng
Các ràng buộc của môi trường Internet tại South Pole
- Việc cung cấp Internet ở South Pole bản thân nó đã là một bài toán kỹ thuật không hề đơn giản, vì các lựa chọn vệ tinh có thể dùng ở vùng cực rất hạn chế
- Có tài liệu công khai tại trang South Pole Satellite Communications
- Khó khăn của việc kéo cáp quang truyền thống tới lục địa Nam Cực cũng được đề cập trong 2021 Antarctic Subsea Cable Workshop
- NSF đã có thông báo về Starlink tại McMurdo và Palmer, nhưng tính đến tháng 10/2023 chưa có thông báo tương tự cho South Pole Station
- Cho đến gần đây, McMurdo có gần 1.000 người cùng nhiều khối lượng công việc khoa học và vận hành phải chia sẻ tổng băng thông toàn căn cứ chỉ ở mức vài chục Mbps
- Tức là cả căn cứ phải dùng chung lượng băng thông còn ít hơn mức một cá nhân có thể nhận được trên mạng 4G di động thông thường ở ngoại ô Mỹ
- South Pole chỉ kết nối khi vệ tinh đi lên trên đường chân trời và trạm được phép sử dụng, còn lịch vệ tinh thường dịch sớm khoảng 4 phút mỗi ngày do chênh lệch giữa thời gian sao và thời gian Mặt Trời
- Độ trễ mà người dùng cảm nhận khác rất xa trải nghiệm Internet thông thường
- Độ trễ khứ hồi tới đích ở lục địa Mỹ khoảng 750ms
- Gần gấp 10 lần mức tối đa khoảng 75ms giữa bờ Đông và bờ Tây nước Mỹ
- Gần gấp 30 lần mức tối đa khoảng 25ms thường kỳ vọng từ kết nối cáp/quang gia đình tới các CDN lớn
- So với khoảng 3ms từ kết nối GPON tại nhà của tác giả tới Fastly, Cloudflare, CloudFront, Akamai và Google, South Pole cao hơn hơn 250 lần
Điều kiện thực tế mà người dùng cộng đồng phải đối mặt
- Tính đến tháng 10/2023, một cá nhân dùng Internet cho mục đích cộng đồng ở South Pole có thể gặp các điều kiện sau
- Độ trễ khứ hồi trung bình khoảng 750ms, jitter giữa các gói có thể vượt quá vài giây
- Tốc độ ở phía thiết bị đầu cuối từ vài kbps tới 2Mbps vào những ngày rất tốt
- Tắc nghẽn nặng, xếp hàng, rớt gói
- Tính sẵn sàng hạn chế, rớt kết nối thường xuyên, đôi khi bị dịch vụ khác giành ưu tiên
- Trong một số tình huống cụ thể còn xuất hiện điều kiện như 40kbps, độ trễ 1.000ms, jitter tới 2.000ms, mất gói 10%, và mất kết nối hoàn toàn 15 giây mỗi vài phút
- Vì lưu lượng vận hành được ưu tiên rất mạnh, người dùng cộng đồng phải dựa vào phần dung lượng còn dư
- Những chức năng như họp video thời gian thực gần như không thể kỳ vọng, nhưng ở một số ứng dụng vẫn có thể gửi nhận vài byte văn bản
- Kỹ thuật web và ứng dụng không tính đến đường truyền chậm hoặc gián đoạn còn làm khả năng sử dụng tệ hơn nữa
Trường hợp một web app cộng tác yêu cầu 20MB JavaScript
- Một nền tảng cộng tác doanh nghiệp cần tải gần 20MB JavaScript chỉ để render màn hình chính
- Ứng dụng đã được cập nhật kể từ lần truy cập trước, nên toàn bộ tài nguyên cache trong trình duyệt đều cũ và phải tải lại
- Trình duyệt và giao thức xử lý điều khiển tắc nghẽn ở mức nào đó trên Internet chậm, nhưng ứng dụng này tự cắt quá trình tải bằng chính điều kiện thất bại của nó
- Nếu không tải hoàn toàn trong khoảng thời gian hoặc số lần thử lại do nhà phát triển đặt ra, ứng dụng sẽ dừng
- Bị chuyển hướng sang trang lỗi
- Trạng thái tải đã đạt được biến mất
- Lần thử tiếp theo áp dụng biện pháp vô hiệu hóa cache rất mạnh
- Về bản chất đây là một ứng dụng nhắn tin, và sau khi chạy xong thì payload nội dung thực tế khi chat với bạn bè chỉ tính bằng byte
- Hiệu năng Internet ở South Pole nằm đúng sát ranh giới mà nhà phát triển coi là “chấp nhận được”, nên người dùng phải refresh nhiều lần và tải lại cùng đống JavaScript đó
- Nếu cứ để quá trình truyền cần thiết chạy tiếp thì có thể xong trong vòng 15 phút, nhưng thực tế đôi khi mất hàng giờ
- Một trường hợp thành công gồm 809 HTTP request, truyền 51,4MB, tải trong 26,5 phút, rồi gửi một thông điệp 6 byte bằng HTTPS POST 1,8KB
- Nếu ứng dụng được thiết kế để tiếp tục chờ miễn là dữ liệu vẫn đang chảy dù chậm, thì có thể giảm việc truyền lại không cần thiết và lãng phí băng thông
Vấn đề của timeout hard-code và các lần truyền đơn khối lớn
- Những giả định cố định về việc payload sẽ truyền nhanh tới đâu, hoặc có thể gửi bao nhiêu trong một request, có thể làm ứng dụng hỏng trên đường truyền chậm
- Nếu có thể đo được rằng byte vẫn đang di chuyển, thì tốt hơn là đừng hủy truyền dù chậm đến đâu, mà hãy hiển thị tình trạng hiện tại trên UI
- Nếu một lệnh gọi HTTPS thất bại, nên thử lại với timeout dài hơn, và dữ liệu lớn nên được chia thành các chunk nhỏ
- Cần theo dõi tiến độ theo từng chunk
- Phải có khả năng thử lại hoặc tiếp tục chỉ những phần nhỏ bị lỗi
- Tiến độ tăng dần chậm nhưng đều an toàn hơn việc cố gửi toàn bộ dữ liệu lớn trong một lần
- Nếu lệnh gọi HTTPS cứ tiếp tục thất bại, thay vì mù quáng lặp lại cùng một lệnh gọi, nên kiểm tra DNS, ICMP, HTTP không có TLS, và HTTPS tới các endpoint trạng thái đã biết là bình thường để thông báo tình trạng cho người dùng
-
Thất bại khi tải metadata lúc khởi động
- Một ứng dụng desktop phổ biến tải thông tin cấu hình từ website của nhà cung cấp khi khởi động, và dùng timeout hard-code cho lệnh gọi HTTPS đó
- Nếu lệnh gọi này thất bại, ứng dụng sẽ không tải, cứ thử lại vô hạn với cùng tham số, còn màn hình loading không nói rõ nguyên nhân
- Ở South Pole, nếu cứ tiếp tục thử thì cuối cùng có thể qua được, nhưng chỉ một giá trị timeout cố định đã khiến một ứng dụng cấp doanh nghiệp gần như không thể dùng
- Hành vi tốt hơn là lùi dần với timeout dài, kiểm tra trạng thái kết nối, hiển thị nguyên nhân, dùng cache hoặc cấu hình mặc định, và cung cấp đường dẫn tải thủ công cùng quy trình cài đặt
-
Đối chiếu hai ứng dụng chat
- Một ứng dụng chat phổ biến dùng timeout hard-code 10 giây cho khởi tạo WebSocket
- Vì cần đủ TCP handshake, TLS session, thiết lập WebSocket và tín hiệu ban đầu, nên trong điều kiện mỗi vòng khứ hồi mất nhiều giây như South Pole, quá trình này có thể vượt 10 giây
- Khi hết timeout, ứng dụng không hoạt động và chuyển sang trạng thái backoff dài, còn UX không thể hiện rõ tình hình
- Một ứng dụng chat cạnh tranh lại hoạt động tốt hơn trong điều kiện mạng cực tệ
- Dùng nhiều chiến lược request mạng
- Tích cực tái sử dụng các kết nối đã mở
- Điều chỉnh timeout động
- Chọn khoảng thử lại một cách thông minh khi thất bại
- Hiển thị rõ trạng thái mạng hiện tại
- Cả hai ứng dụng thực ra chỉ truyền vài byte văn bản thuần, nhưng khác biệt trong giả định mạng đã quyết định điều kiện nào thì chúng còn dùng được
Truyền tăng dần và upload có thể tiếp tục
- brr.fyi là một blog Jekyll tĩnh, tài nguyên được lưu trên S3 và phân phối qua CloudFront
- File tĩnh được build trên laptop cục bộ
- Được upload trực tiếp lên S3
- Không có server, môi trường QA, hệ thống build, hook tự động hay thành phần động
- Một script xuất bản bằng Python được viết để tính đến các ràng buộc của South Pole đã upload tài nguyên qua S3 API theo từng chunk nhỏ
- Phát hiện upload lỗi và tiếp tục mà không mất tiến độ
- Không xuất bản phiên bản mới cho đến khi toàn bộ file đã được upload an toàn
- Được triển khai chỉ trong khoảng 200 dòng Python
- Người dùng tải file lớn lên nền tảng blog thương mại hoặc mạng xã hội phải canh thời gian theo khả năng thành công trọn vẹn trong một khung thời gian vệ tinh
- Nếu thất bại thì phải thử lại nhiều lần
- Đôi khi không rõ nội dung đã được đưa lên chưa, upload đã xong chưa, hay có nên bấm “Post” lại hay không
- Nếu một chunk POST thất bại mà sau đó có thể thử lại hoặc tiếp tục với mức tổn thất tối thiểu, thì người dùng có thể gom upload vài KB một cách thoải mái theo thời gian thuận tiện
Các tiêu chí mà trình tải xuống tích hợp phải đáp ứng
- Nếu ứng dụng tự làm downloader riêng thì phải đạt chất lượng cao; nếu không, trên Internet chậm nó sẽ gây khó chịu nghiêm trọng hoặc thất bại chí mạng
- Khi có thể, nên cho phép người dùng thoát khỏi downloader tích hợp để tự nhận file trực tiếp
- Cung cấp liên kết tải thủ công là rất hữu ích
- Nếu có thể, liên kết tới file patch chênh lệch mà ứng dụng định tải còn tốt hơn là toàn bộ bộ cài
- Lợi ích của liên kết tải thủ công là rất rõ ràng
- Người dùng có thể chọn downloader vững hơn như trình duyệt
- Có thể tải một lần rồi chia sẻ cho nhiều thiết bị
- Có thể tải từ một máy tính khác với máy đang chạy ứng dụng
- Người dùng có thể lên lịch hoặc quản lý việc tải theo đúng giới hạn của mình
- South Pole không có Internet 24/7, nên ngay cả khi mỗi ngày có 4 giờ tải, nếu lượng dữ liệu tải được trong thời gian đó nhỏ hơn kích thước payload thì không có cách nào hoàn thành trong một lần
- Nhiều downloader tích hợp thiếu tạm dừng/tiếp tục, thông báo trạng thái, logic thử lại, theo dõi tiến độ, và còn có các giới hạn như timeout tải xuống, nên chúng quyết định trực tiếp ứng dụng có dùng được hay không trên Internet chậm
Vì sao trình quản lý tải xuống của trình duyệt là chuẩn tham chiếu
- Trình quản lý tải xuống của trình duyệt web hiện đại tạo ra một chuẩn rất cao mà downloader tích hợp buộc phải bị so sánh
- Dừng, tạm dừng, tiếp tục
- Thử lại các lượt tải thất bại
- Hiển thị trạng thái hiện tại, tốc độ, thời gian còn lại
- Chọn vị trí lưu và khả năng sao chép file
- Không có ngưỡng cắt hiệu năng tùy tiện
- Dù người dùng muốn tải một file vài GB ở tốc độ 60kbps, trình duyệt vẫn cho phép
- Nếu ứng dụng không thể triển khai được mức chức năng như trình duyệt, thì ít nhất nên cung cấp URL gốc để người dùng tải bằng trình duyệt
Trường hợp cập nhật macOS
- Cập nhật macOS là gánh nặng đặc biệt lớn ở South Pole
- Patch cập nhật OS nhỏ thường có kích thước 0,5~1,5GB
- Patch nâng cấp OS lớn đôi khi hơn 6GB
- Các công cụ bổ sung như Xcode cũng thường nặng nhiều GB
- Nếu mọi thiết bị macOS đều tự cập nhật trực tiếp từ Apple thì băng thông bị lãng phí rất lớn
- Trình cập nhật tích hợp của macOS ít khả năng kiểm soát, và không có cách dễ dàng để lấy file patch nền tảng bên dưới
- Nếu hủy hoặc thất bại, nó không phải lúc nào cũng tiếp tục thông minh và đôi khi mất tiến độ
- Về lý thuyết, tính năng máy chủ cache của Apple cho macOS có thể giảm gánh nặng bằng cách chỉ tải mỗi patch về South Pole một lần
- Nhưng trên thực tế, mỗi máy MacBook client phải gọi HTTPS thành công tới Apple để thương lượng tham số cache
- Nếu lệnh gọi này thất bại, máy client sẽ tải patch trực tiếp từ máy chủ Apple công cộng mà không có thông báo hay thử lại
- Ở South Pole, lệnh gọi thương lượng ban đầu này thường thất bại nên tính năng cache không hữu ích
- Có thể tải bộ cài đầy đủ từ Apple qua các liên kết được tổng hợp tại Mr. Macintosh, rồi tải chậm nhưng cẩn thận để phân phối trong căn cứ
- Bộ cài đầy đủ có kích thước 12GB và việc tải có thể mất nhiều ngày, nhưng đáng tin cậy
- Máy Apple Silicon, ngay cả khi cập nhật bằng bộ cài đầy đủ, vẫn cố tải thêm 1~2GB nội dung trực tiếp từ Apple như firmware hoặc cập nhật Rosetta
- Không có cách vượt qua hoặc cache phần này
- Việc tải đôi khi chuyển sang một thành phần riêng của macOS nên UI cài đặt không phản ánh tiến độ
- Có thể xuất hiện tình huống màn hình “còn 32 phút” đứng yên hàng giờ trong khi nền đang tải 1GB
- Điều cần thiết là cung cấp liên kết patch cần thiết, tăng cường tạm dừng/tiếp tục và quản lý trạng thái, đưa các phần bổ sung cho Apple Silicon vào bộ cài đầy đủ, và cải thiện độ tin cậy cũng như quyền kiểm soát đối với máy chủ cache
Trường hợp cập nhật OS Android của Samsung
- Công cụ cập nhật OS trên điện thoại Samsung Android là một ví dụ không tính đến Internet chậm hoặc gián đoạn
- UI cập nhật không có hiển thị tốc độ, tiến độ số, tạm dừng, hủy, kích thước file, hay cách truy cập file để tải riêng
- Nếu tải thất bại thì không thể tiếp tục mà phải bắt đầu lại từ đầu
- Ở South Pole, không thể tải trọn một bản cập nhật OS trong một lần vệ tinh đi qua, nên khi kết nối ngắt thì chắc chắn thất bại và phải làm lại từ đầu
- Trên thực tế, ngay trước khi Internet ngắt, người dùng phải tắt hẳn điện thoại, rồi bật lại ở lần vệ tinh đi qua tiếp theo để tránh việc bị đánh dấu là tải thất bại
- Cách này cho phép chia nhỏ quá trình tải qua nhiều lần vệ tinh đi qua để hoàn tất
- Đây là một giải pháp vòng vo bất thường vốn không nên cần đến
- Ứng dụng cập nhật của Verizon cho macOS và Windows về lý thuyết cho phép flash cập nhật OS từ máy tính, nhưng thực tế nhiều lỗi, độ tin cậy thấp và cũng dùng downloader tích hợp riêng
- Cốt lõi của vấn đề là các công cụ phổ thông do nhà cung cấp đưa ra cung cấp quá ít tính năng cho người dùng Internet chậm
Đối chiếu giữa các cập nhật ứng dụng nhỏ và Microsoft Office for Mac
- Trình cập nhật tích hợp của một ứng dụng desktop nhỏ thiếu các chức năng cơ bản cần có trên đường truyền chậm
- Nút tạm dừng
- Nút hủy
- Hiển thị tiến độ
- Hiển thị tốc độ hoặc thời gian còn lại
- Truy cập URL gốc
- Theo dõi tiến độ và tiếp tục tự nhiên với các lượt tải bị gián đoạn
- Chỉ cần ứng dụng này cung cấp liên kết tải thủ công thôi cũng đã cải thiện đáng kể cho người dùng South Pole
- Trình cập nhật tự động của một ứng dụng khác có nút hủy và hiển thị tiến độ trực quan, nhưng thiếu tạm dừng, tiến độ số/tốc độ, truy cập URL gốc và khả năng tiếp tục
- Trình cập nhật tự động của Microsoft Office for Mac là một ví dụ tốt ngay cả ở South Pole
- Nút tạm dừng
- Nút hủy
- Hiển thị tiến độ
- Hiển thị tốc độ và thời gian còn lại
- Tiếp tục tự nhiên với các lượt tải bị gián đoạn
- Sẽ tốt hơn nữa nếu có URL gốc, nhưng giao diện đủ tốt để dùng được ngay cả ở South Pole
Các nguyên tắc thiết kế thực tế cho người dùng Internet chậm
- Trong môi trường Internet nhanh, những thiếu sót tưởng như nhỏ có thể trở thành rào cản lớn trên Internet chậm
- Ứng dụng nên được thiết kế để không khiến người dùng mắc kẹt trong vòng lặp không thể gửi nổi vài byte văn bản chỉ vì một timeout cố định
- Các nguyên tắc thiết kế khả thi rất đơn giản
- Nếu byte còn di chuyển thì đừng ngắt
- Chia payload lớn thành các chunk
- Dù thất bại cũng phải giữ được tiến độ
- Hiển thị rõ trạng thái mạng cho người dùng
- Nếu downloader tích hợp còn thiếu, hãy cung cấp liên kết tải thủ công
- South Pole là edge case, nhưng môi trường Inmarsat trên tàu biển, Thales MissionLink và Iridium Certus tại điểm nghiên cứu vùng núi, Wi‑Fi không ổn định, router cấu hình sai, WISP chất lượng thấp, hay người dùng dial-up trên đường dây điện thoại cũ cũng có thể gặp các ràng buộc tương tự
- Nhà phát triển không nhất thiết phải tối ưu cho mọi trường hợp cực đoan, nhưng vẫn cần nỗ lực để sản phẩm không chủ động cản trở tiến trình của người dùng có kết nối chậm
1 bình luận
Ý kiến trên Hacker News
Bài này chạm đúng nỗi lòng. Tôi không ở Nam Cực mà ở Bắc Kinh, nhưng vẫn khổ sở vì internet
Ở sau Vạn Lý Tường Lửa thì phải dùng các cách sáng tạo, VPN cũng chỉ thỉnh thoảng mới hoạt động. Mỗi VPN đều để lại dấu vết, nên các heuristic và máy học của tường lửa cuối cùng cũng phát hiện ra; ngay cả VPN được nhà nước cho phép cũng bị hạn chế “nhẹ nhàng” vào những thời điểm nhạy cảm về chính trị
Rốt cuộc, dù có kết nối được thì cũng không ổn định, và thật đau đớn khi phải lãng phí những gói tin quý giá vào các webapp vô dụng/các lượt request qua lại của React
Có lẽ một số lập trình viên nên du hành thời gian về khoảng năm 2005 và thử phát triển theo tiêu chuẩn thời đó để học cách làm cho nhẹ. Nếu không du hành thời gian được, tôi thật sự mong họ bật giới hạn tốc độ trong công cụ dành cho nhà phát triển, đặt về 3G, rồi kiểm tra xem webapp của mình có chịu nổi không
Tôi luôn kiểm thử dự án với băng thông hạn chế. Cũng như accessibility, làm theo các thực hành tốt không chỉ giúp người dùng có kết nối kém mà còn mang lại trải nghiệm người dùng tốt hơn cho tất cả mọi người
Một cơ hội khác thường bị bỏ lỡ là làm cho ứng dụng một trang theo hướng offline-first
Tôi không hẳn phản đối toàn bộ ý chính, nhưng JavaScript hiện đại thực ra khá tốt trong việc xử lý internet chậm cho “ứng dụng” server-client. Chỉ là làm cho dễ thì không dễ, và gần như không có tài liệu trực tuyến nào đủ tốt để những người code bằng Google/GPT lấy làm nền tảng dự án
Một phần là vì trên mạng có quá nhiều tài liệu JavaScript tệ, nhưng cũng do các tổ chức làm theo cách này không chia sẻ. Chúng tôi cũng không có lý do gì để trao thông tin cho đối thủ, nên có đúng 0 tài liệu công khai về cách chúng tôi làm việc
Đây là một bài luyện thú vị để giảm các lượt round-trip vô ích trong những công nghệ vốn kỳ vọng dùng round-trip cho mọi thứ
Tôi vẫn đạt khoảng 1~10Mbit/s, nhìn chung tùy theo thời điểm trong ngày, và hầu như không gặp vấn đề kết nối
Với nhiều kinh nghiệm đi làm bằng phương tiện công cộng ngầm (chập chờn, đông đúc), và từng sống, làm việc ở Úc, tôi có thể tự tin nói rằng phần lớn dịch vụ đều rất tệ với những người không có điều kiện mạng “lý tưởng”
Trên London Underground, điều đặc biệt nổi bật là hầu hết ứng dụng xử lý rất kém mạng cứ khoảng 2 phút lại mất rồi có lại. Mất kết nối giữa các ga, và khi một đoàn tàu chở 500 hành khách cùng lúc cố truy cập, việc kết nối vào từng access point cũng mất khoảng 15 giây
Ở Úc, về cơ bản bạn cách mọi nơi 200ms. Nghe có vẻ không đáng kể, nhưng nó phơi bày rất rõ ứng dụng nào vấp phải vấn đề request N+1
Ứng dụng duy nhất luôn gây ấn tượng với tôi là WhatsApp. Nó là thứ hoạt động đầu tiên sau khi kết nối lại, cũng là thứ cuối cùng còn đẩy được traffic qua trước khi mất kết nối, và ngay cả khi có độ trễ thì cuộc gọi vẫn cho cảm giác khá nhanh
WhatsApp rất có thể là một trong số ít dịch vụ thực sự triển khai máy chủ ở Úc. 200ms trông như một tín hiệu mạnh cho thấy traffic liên lục địa
Hầu hết các công ty toàn cầu nhiều nhất cũng chỉ triển khai ở ba khu vực: Mỹ (us-east, us-central, us-east+us-east), châu Âu (west-europe), và hiếm hơn là Viễn Đông (us-west hoặc Nhật Bản)
Vì vậy những nơi như Nam Phi, Nam Mỹ, Úc thường phải lấy dữ liệu từ một trong các khu vực này, và do giới hạn vật lý nên có độ trễ tối thiểu 200ms
Úc đặc biệt bị ảnh hưởng nặng. Ngay cả khi trên lý thuyết có triển khai riêng trong phạm vi tài phán, máy chủ thực tế nhiều khi lại nằm ở một châu lục hoàn toàn khác (bờ Tây Mỹ hoặc Nhật Bản), nên người dùng phải hứng trọn tác động hiệu năng của việc gói tin đi nửa vòng Trái Đất
Tôi nghĩ vì góc nhìn đó đã ăn sâu vào mục tiêu phát triển, nên WhatsApp có đủ lý do để trở thành ứng dụng nhắn tin tiêu biểu ở nhiều nước trên thế giới
Khi mở URL .jpg trong trình duyệt để xem ảnh, nó mất lâu hơn rất nhiều so với khi chuyển sang termux và chạy
wget, đôi khi còn timeout. Tôi gặp chuyện này trên cả Firefox lẫn các trình duyệt họ ChromeNhân tiện, tải bằng
wgettrên kết nối di động thường cũng mất 10~30 giâyTôi không hiểu vì sao Berlin lại làm như vậy. Chỉ cần cung cấp internet trên tàu là được mà
Khi mạng cứ liên tục mất kết nối, phần lớn internet hoạt động thật sự rất tệ
Tôi đi lại khá nhiều, và Internet chậm là chuyện khá phổ biến. Ngay lúc này dữ liệu di động của tôi cũng đã hết nên đang bị giới hạn ở 8kbps.
Những website chỉ có văn bản trên trang lẽ ra phải nhanh, nhưng nhiều nơi lại không như vậy. Hacker News thì cực kỳ nhanh, còn tài liệu Google API thì hoàn toàn không mở được.
Vấn đề tệ nhất là phần lớn UI không tính đến các request chậm. Nút bấm tạo cảm giác như bị hỏng, và cả những thứ đáng ra không cần dữ liệu tính bằng megabyte cũng mất vài phút để tải hoặc thất bại. Toàn bộ UI của Google Maps bị hỏng.
Tôi mong các nhà phát triển thiết kế và kiểm thử nhiều hơn cho Internet chậm. Thay vào đó, chúng ta có những website ngốn dữ liệu, chỉ chạy tốt trên laptop công ty nhanh và đường truyền Internet nhanh.
Liên quan đến chuyện này, tôi kiếm sống bằng cách vận hành website, và việc chuyển sang trình tạo site tĩnh là một trong những lựa chọn tốt nhất về mặt năng suất. Thay vì độ trễ của CMS len vào mọi công việc, tôi có thể chỉnh sửa các file văn bản cực nhanh ngay cả khi hoàn toàn offline, rồi khi online chỉ cần push các thay đổi. Nó thay đổi hẳn cuộc chơi.
Ngày nay, tải 500MB cache Google Maps về điện thoại dường như cũng chẳng có ý nghĩa gì. Nó vẫn kéo mọi thứ về và hiện ra muộn màng.
Hiện một domain của tôi đang bị đánh dấu là “nguy hiểm” chỉ vì không dùng bản WordPress mới nhất.
Về cơ bản, mọi request gửi đi đều chạm tới một ứng dụng AppEngine, ứng dụng đó chạy mã Python rồi trả về HTML. Vì vậy trông có vẻ như nó phải nhanh, nhưng thực tế thì không.
Tôi ở Anh, và ping tới news.ycombinator.com là 147ms. Có vẻ vì nó không dùng CDN và được host ở Mỹ.
Trong khi đó cloud.google.com có ping 8ms.
Hacker News là một trang đơn giản và ít JavaScript, nhưng cũng có thể có những yếu tố khác khiến người dùng ở một số khu vực cảm thấy chậm. Ngay cả trong môi trường đặc quyền dùng đường cáp quang XGS-PON đối xứng 8Gbps cũng vậy.
Tôi từng cho một người vừa rời khỏi vùng băng quá giang, và anh ấy nói rằng tác giả blog đó viết rất hay, nhưng khá thường xuyên ngốn mất phần băng thông vốn đã hạn chế trong lúc upload ảnh, nên bị những người xung quanh ghét ở mức nào đó.
Tuy nhiên, phía hành chính nhận ra giá trị quảng bá nên người đó được ưu tiên. Tôi nghĩ chuyện này rất ăn khớp với cuộc thảo luận về Internet chậm.
Chiếc điện thoại trong túi có thể đang dùng hết mọi băng thông có thể một cách không cần thiết; và ngay cả khi bạn đang xem video 720p chỉ vừa đủ phát, người phía sau đang cố tải có thể không xem nổi cả 480p. Bạn không nhận ra vì có buffer, còn người kia có thể bỏ cuộc trước khi buffer kịp đầy.
Có lẽ tối thiểu cần có hạch toán mức sử dụng cho biết trong lưu lượng 1 giờ qua, bao nhiêu phần trăm đã đi về phía bạn, và nếu so với mức chuẩn là băng thông khả dụng chia cho số người dùng đang kết nối, thì phần của bạn lẽ ra là bao nhiêu phần trăm nếu mọi người đều cần như nhau.
Xa hơn nữa, cũng có thể có một hệ thống mặc định đặt mọi người ở mức ưu tiên thấp cho đến khi họ bấm nút “Có, tôi biết mình sẽ dùng băng thông trong [X≤24] giờ tới và thực sự cần nó”, rồi khi bấm thì nâng ưu tiên QoS của địa chỉ MAC/IP lên bình thường.
Tình huống này đang kêu gọi ứng dụng local-first và các giải pháp tương ứng, và đó cũng chính là lý do Internet được tạo ra ngay từ đầu [1][2].
Mọi người đã bị khẩu hiệu quảng cáo “No Software” của Salesforce đánh lừa, trong khi điều đó đi ngược trực diện với nền tảng và tinh thần của Internet. Trong phần lớn lịch sử Internet kể từ năm 1969, Mbps là ngoại lệ chứ không phải tiêu chuẩn, và killer app đầu tiên là nhắn tin qua email (có lẽ đến nay vẫn là ứng dụng Internet tốt nhất) là local-first [3].
Trớ trêu thay, ứng dụng mà tác giả than phiền cũng là một ứng dụng nhắn tin.
[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...
Trong nhiều năm tôi đã làm khá nhiều việc liên quan đến networking, và dành thời gian để vận hành môi trường “Internet chậm” của riêng mình. Không thú vị bằng McMurdo, nhưng tôi đã chat và xem video YouTube trên các chuyến bay quốc tế, tàu đi qua vùng hẻo lánh, khách sạn nông thôn tệ hại, và cả trong đường hầm.
Nếu bạn có thể tiếp cận thiết bị điện toán đa dụng, chịu được chi phí điện năng (loại thiết bị này thường ăn điện khá nhiều), và sẵn sàng tự dựng, tôi khuyên dùng NNCP [1]. NNCP có thể nhận dữ liệu, chia nhỏ rồi gửi đi. Nó cũng có giao thức đồng bộ dùng noise trên TCP, gửi bằng cách thử lại các mảnh bị lỗi. Không cần TLS nên việc thiết lập kết nối chỉ tốn 1,5 RTT.
NNCP có thể đưa dữ liệu qua stdin vào một chương trình từ xa. Tôi đã tạo YouTube downloader, bot Slack, bot Telegram, bot Discord để đọc dữ liệu đến và tương tác với các dịch vụ tương ứng. Trên máy local, tôi chạy một máy chủ Matrix (Dendrite) và các bot, rồi gửi dữ liệu qua NNCP tới dịch vụ từ xa phù hợp.
Bạn có thể muốn, hoặc cần thử nghiệm để, MTU/MSS trên đường truyền càng thấp càng tốt nhằm cho phép thử lại ở mức TCP thường xuyên hơn; nhưng cấu hình này hầu như chưa từng thất bại ở bất cứ nơi nào tôi đến, và giúp tôi tiêu thụ media cũng như chat được.
Điểm khó chịu nhất trên các chuyến bay quốc tế là các endpoint NNCP không được phân tán về mặt địa lý. Tùy theo đường bay và đường đi thực tế của các gói tin tới endpoint, độ trễ và jitter có thể tăng mạnh. Thường tôi cố đặt endpoint NNCP gần điểm đến, nhưng đường đi thực tế xét theo Wi‑Fi trên máy bay có thể rất tệ. NNCP hiện đã hỗ trợ Yggdrasil, có thể giảm nhẹ việc này và cũng giúp kiểm soát vấn đề MTU, nhưng tôi chưa từng dùng Ygg trong những điều kiện như vậy.
[1]: http://www.nncpgo.org/
Tôi từng có trải nghiệm tương tự tác giả trên một con tàu ở Nam Thái Bình Dương. Có Starlink, nhưng mức tiêu thụ điện cao (trên 60W) nên chúng tôi không dùng thường xuyên. Thay vào đó, tôi mua SIM địa phương và ở một số nơi dùng 4G, một số nơi dùng EDGE (2G).
Bản thân EDGE trên giấy tờ không quá tệ. Nó đạt vài chục kilobit mỗi giây. Thực tế thì tệ hơn nhiều. Tôi gặp cảnh những ứng dụng lẽ ra vẫn chạy tốt nếu chỉ tính đến việc tải có thể mất vài phút thay vì vài mili giây, nhưng lại thất bại vì timeout quá ngắn.
Kết nối băng thông thấp, độ trễ cao nên được đưa vào kiểm thử định kỳ của phần mềm. Trên Linux có netem (https://wiki.linuxfoundation.org/networking/netem) giúp làm việc này.
Một vấn đề mà tác giả blog ẩn danh không gặp phải là kết nối tính phí theo lưu lượng. Vì chi phí, việc nâng cấp hệ điều hành hay ứng dụng gần như bất khả thi. May mắn là cứ vài tuần chúng tôi lại tới được nơi có kết nối không giới hạn để làm những việc đó. Đổi lại, tôi trở nên rất thành thạo cách đánh dấu kết nối là tính phí/không tính phí trên nhiều hệ điều hành, tắt toàn bộ cập nhật tự động, và tiết kiệm băng thông quý giá.
Và nếu nói “SIM địa phương” thì hẳn là đã lên đảo để mua SIM đó; tôi tò mò không biết ở đâu trong thập niên 2020 mà chỉ có 2G. Khó tin là ở Nam Thái Bình Dương vẫn còn những nơi như vậy.
Cần giữ đúng góc nhìn. Có những dự án thậm chí còn bỏ qua việc kiểm thử webapp trên nhiều trình duyệt, coi đó là lãng phí và là chi phí không thể biện minh, dù việc đưa vào ma trận kiểm thử là chuyện nhỏ và chỉ liên quan đến UI.
Kỹ thuật tính đến Internet chậm vẫn thực sự quan trọng, và tôi cho rằng phần lớn nhà phát triển phần mềm đang đánh giá thấp điều này rất nhiều. Tuy nhiên, các hệ thống vệ tinh quỹ đạo thấp (Starlink, đặc biệt là StarLink) giờ về cơ bản đã giải quyết vấn đề cốt lõi
Vào tháng 9–10/2023, tôi đi qua tuyến hàng hải Bắc Cực (từ Alaska đến Norway), và ngay cả trên tàu ở rất xa phía trên Vòng Bắc Cực, bất chấp mây, khoảng cách tới đất liền và băng, tôi vẫn có thể gọi video FaceTime. Đó cũng là cùng thời điểm tác giả ở Antarctica
Dù ràng buộc là gì, cuối cùng vấn đề là hợp đồng dịch vụ và đưa terminal đến hiện trường. Phủ sóng vùng cực tương đối thưa, nhưng dân số cực kỳ ít nên vẫn đủ
https://satellitemap.space/
Internet chậm có nhiều nghĩa, và một trong số đó là vấn đề kết nối. Với các giao thức hướng kết nối như TCP, đó là chậm do mất gói; còn với các giao thức kiểu gửi rồi thôi như UDP, điều đó có nghĩa là thông điệp không đến nơi. Vì vậy, “chậm” có thể là tốc độ truyền thấp, hoặc cũng có thể là sau một khoảng thông lượng cao đột ngột thì bị ngắt quãng từng lúc
Một cách tiếp cận vững chắc để xử lý mạng chậm là hỗ trợ chế độ ngoại tuyến. Thiết kế mọi thao tác push/pull dữ liệu thành giao dịch bất đồng bộ, còn việc push dữ liệu thì cache cục bộ và thử lại khi có thể. Cách này kéo theo các yêu cầu bổ sung như quản lý phiên bản và giải quyết xung đột
Tự nhiên các yêu cầu về UI cũng tăng lên. Cần đồng bộ/làm mới thủ công, hiển thị trạng thái mạng, vô hiệu hóa các thao tác vô nghĩa khi mất mạng, tải trước để vẫn dùng được khi ngoại tuyến, v.v.
Mong một ngày nào đó được sống trong thế giới sau thời Internet chậm, nhưng có lẽ vẫn còn nhiều năm nữa. Nhân tiện, XS dùng modem Intel, vốn được biết là kém hơn flagship Qualcomm cùng thời
Tôi sống ở một trong những nơi có mật độ dân số cao nhất thế giới, đầy ăng-ten 5G và trạm Wi‑Fi, nhưng vẫn cảm nhận rõ các website làm cẩu thả bị sập khi kết nối chậm hoặc chập chờn
Vệ tinh địa tĩnh ở Pole nằm quá sát đường chân trời nên vùng phủ cực bị hạn chế. Pole dùng các vệ tinh địa tĩnh cũ, ít nhiên liệu và có độ nghiêng quỹ đạo tương đối lớn, vì vậy chỉ liên lạc được khoảng 6 giờ trong 24 giờ
Lịch: https://www.usap.gov/technology/1935/
Các chính phủ sẽ không muốn web không bị kiểm duyệt, hay một công ty Mỹ trở thành cổng Internet. Họ sẽ duy trì mạng trong lãnh thổ mà họ đang có, và vấn đề tốc độ sẽ vẫn còn hiệu lực
Cũng cần tính đến số người trên khắp thế giới mà phương tiện truy cập Internet duy nhất là điện thoại Android 100 USD với phần mềm cũ và CPU hạn chế
Có một đề xuất dự thảo IETF mở rộng HTTP để đồng bộ trạng thái hiệu quả, có thể cải thiện trải nghiệm người dùng trên mạng chậm: https://news.ycombinator.com/item?id=40480016
Braid Protocol cho phép nhiều thuật toán đồng bộ tương tác với nhau trên một giao thức mạng chung, và thông điệp mạng của bất kỳ bộ đồng bộ nào cũng có thể được chuyển đổi lên trên đó. Đặc tả Braid hiện thêm hai chiều đồng bộ vào HTTP
Level 0: HTTP ngày nay
Level 1: đăng ký có cập nhật push
Level 2: nhất quán P2P (patch, version, merge)
Các bộ đồng bộ ngày nay dùng các giao thức khác nhau, nhưng thông điệp mạng truyền tải cùng một loại thông tin: phiên bản theo thời gian, vị trí trong không gian, và patch cho vùng không gian qua một khoảng thời gian. Phép hợp thành của một tập patch tùy ý tạo thành một cấu trúc toán học gọi là braid: phân nhánh, hợp nhất và sắp xếp lại không gian theo thời gian
Hy vọng thì luôn trào dâng
Giảm số request khứ hồi và làm thứ gì đó ít phình to hơn không khó, mà còn dễ hơn nhiều. Sự cồng kềnh tồn tại vì những lý do hoàn toàn khác
Đôi khi, với Internet nhanh gần data center và máy móc dư dả, sự cồng kềnh không lộ ra. Có thể mô phỏng dễ dàng, nhưng công ty phải quan tâm. Nhìn chung ad tech và những thứ xung quanh nó hầu như không mấy quan tâm tới các nhóm người dùng nhỏ. Thực ra lý do duy nhất họ quan tâm đến người dùng cuối cũng là vì những người đó tạo doanh thu cho khách hàng thực sự, tức là nhà quảng cáo
Những người làm app, website, v.v. như chúng ta cần nhớ rằng có rất nhiều người không kết nối với Wi‑Fi nhanh hay đường cáp quang như chúng ta dùng
Ở Anh, một số nhà mạng đã bắt đầu tắt 3G. Có nơi giữ 2G làm phương án thay thế tiêu thụ điện thấp, nhưng kiểu như “giờ hãy dùng 4G/5G”. Vấn đề là 4G vẫn chưa có ở mọi nơi, và cho đến gần đây, ở một số khu vực chỉ có tín hiệu 3G là ổn
Vì vậy việc bị rơi xuống 2G/EDGE ngoài ý muốn xảy ra thường xuyên hơn, và nhiều thứ đơn giản là đứng lại. Nhiều app không được kiểm thử trong các kịch bản chậm, độ trễ cao và mất gói lớn
Thử tìm đường bằng Google Maps trên 2G là biết ngay :(