- Internet di South Pole bergantung pada tautan satelit yang terbatas sehingga hanya terhubung beberapa jam per hari, dan per Oktober 2023 pengguna komunitas harus menanggung latensi tinggi, bandwidth rendah, serta putus-sambung yang sporadis
- Kondisi nyata di lapangan mencakup latensi bolak-balik sekitar 750ms dengan jitter beberapa detik, kecepatan dari beberapa kbps hingga 2Mbps, ditambah kemacetan, antrean, kehilangan paket, dan preempsi layanan yang dengan mudah merusak asumsi jaringan aplikasi pada umumnya
- Bundel JavaScript besar, timeout yang di-hardcode, pembuangan progres, invalidasi cache, dan downloader bawaan yang tidak bisa melanjutkan unduhan adalah faktor yang membuat aplikasi gagal dengan sendirinya di tautan lambat
- Jika byte tetap mengalir walau lambat, aplikasi seharusnya menunggu; dengan menyediakan transfer berbasis chunk, kemampuan melanjutkan, tampilan status, timeout dinamis, dan tautan unduhan manual, target kecil seperti pesan teks atau pembaruan tetap bisa tercapai
- Antarktika memang kasus ekstrem, tetapi kapal di laut, lokasi riset pegunungan, Wi‑Fi tidak stabil, WISP berkualitas buruk, dan pengguna akses berbasis saluran telepon juga bisa mengalami batasan serupa, sehingga diperlukan desain yang tidak menghambat progres pengguna
Batasan lingkungan internet di South Pole
- Menyediakan internet di South Pole sendiri merupakan tantangan rekayasa yang tidak sepele, dan pilihan satelit yang bisa dipakai di wilayah kutub sangat terbatas
- Ada halaman referensi publik South Pole Satellite Communications
- Kesulitan menghubungkan serat optik tradisional hingga ke benua Antarktika juga dibahas dalam 2021 Antarctic Subsea Cable Workshop
- NSF telah membuat pengumuman terkait Starlink di McMurdo dan Palmer, tetapi per Oktober 2023 tidak ada pengumuman serupa untuk South Pole Station
- Hingga belum lama ini, McMurdo memiliki hampir 1.000 orang serta berbagai beban kerja ilmiah dan operasional yang berbagi total bandwidth puluhan Mbps untuk seluruh pangkalan
- Artinya, seluruh pangkalan berbagi bandwidth yang lebih kecil daripada yang bisa didapat satu orang di jaringan seluler 4G biasa di pinggiran kota AS
- South Pole hanya terhubung saat satelit berada di atas cakrawala dan pangkalan diizinkan menggunakannya, sementara jadwal satelit umumnya maju sekitar 4 menit per hari karena perbedaan antara waktu sideris dan waktu matahari
- Latensi yang dirasakan pengguna sangat berbeda dari pengalaman internet biasa
- Latensi bolak-balik ke tujuan di daratan utama AS sekitar 750ms
- Sekitar 10 kali lebih besar daripada latensi bolak-balik maksimum 75ms antara pantai timur dan barat AS
- Sekitar 30 kali lebih besar daripada maksimum 25ms yang lazim diharapkan dari koneksi kabel atau fiber rumah ke CDN utama
- Dibandingkan sekitar 3ms dari fiber GPON rumahan penulis ke Fastly, Cloudflare, CloudFront, Akamai, dan Google, South Pole lebih dari 250 kali lebih tinggi
Kondisi yang benar-benar dihadapi pengguna komunitas
- Per Oktober 2023, individu yang memakai internet untuk keperluan komunitas di South Pole bisa mengalami kondisi berikut
- Rata-rata latensi bolak-balik sekitar 750ms, dengan jitter antarpaket yang bisa melebihi beberapa detik
- Kecepatan dari beberapa kbps hingga 2Mbps pada hari yang sangat baik, dilihat dari perangkat pengguna akhir
- Kemacetan parah, antrean, dan packet drop
- Ketersediaan terbatas, dropout yang sering, dan kadang preempsi layanan
- Dalam situasi tertentu, kondisi seperti 40kbps, latensi 1.000ms, jitter hingga 2.000ms, kehilangan paket 10%, dan putus total selama 15 detik setiap beberapa menit juga bisa terjadi
- Karena trafik operasional mendapat prioritas sangat tinggi, pengguna komunitas bergantung pada kapasitas yang tersisa
- Fitur seperti konferensi video real-time nyaris mustahil diharapkan, tetapi di beberapa aplikasi pertukaran teks beberapa byte tetap bisa dilakukan
- Rekayasa web dan aplikasi yang tidak mempertimbangkan tautan lambat atau intermiten justru makin memperburuk kegunaan
Kasus aplikasi web kolaborasi yang meminta 20MB JavaScript
- Sebuah platform kolaborasi enterprise perlu mengunduh hampir 20MB JavaScript hanya untuk merender layar utama
- Karena aplikasi telah diperbarui sejak akses sebelumnya, semua aset cache browser menjadi usang dan harus diunduh ulang
- Browser dan protokol memang menangani kontrol kemacetan sampai tingkat tertentu di internet lambat, tetapi aplikasi ini sendiri memutus proses loading lewat kondisi gagal internalnya
- Jika tidak sepenuhnya termuat dalam waktu atau jumlah percobaan ulang yang ditentukan pengembang, aplikasi berhenti
- Pengguna dialihkan ke halaman error
- Status loading yang sudah berjalan hilang
- Pada percobaan berikutnya, invalidasi cache yang agresif diterapkan
- Pada dasarnya aplikasi ini adalah aplikasi pesan, dan setelah berjalan, payload konten sesungguhnya saat mengobrol dengan teman hanya beberapa byte
- Kinerja internet South Pole berada tepat di ambang yang dianggap “masih dapat diterima” oleh pengembang, sehingga pengguna harus berkali-kali me-refresh dan mengunduh JavaScript yang sama berulang-ulang
- Jika transfer yang dibutuhkan dibiarkan berjalan, prosesnya bisa selesai dalam 15 menit, tetapi dalam praktiknya kadang memakan waktu berjam-jam
- Dalam satu kasus berhasil, dibutuhkan 809 permintaan HTTP, transfer 51.4MB, waktu loading 26,5 menit, lalu HTTPS POST 1.8KB untuk mengirim pesan 6 byte
- Jika aplikasi dirancang untuk terus menunggu selama data masih mengalir meski lambat, retransmisi yang tidak perlu dan pemborosan bandwidth bisa dikurangi
Masalah timeout yang di-hardcode dan transfer tunggal besar
- Asumsi tetap tentang seberapa cepat payload akan terkirim, atau berapa banyak yang bisa dikirim dalam satu permintaan, dapat merusak aplikasi di tautan lambat
- Jika bisa diukur bahwa byte masih mengalir, lebih baik jangan memutus transfer meski sangat lambat, dan tampilkan kondisi saat ini di UI
- Jika panggilan HTTPS gagal, coba lagi dengan timeout yang lebih panjang, dan data besar harus dikirim dalam chunk kecil
- Progres per chunk harus dilacak
- Hanya bagian kecil yang gagal saja yang perlu dicoba ulang atau dilanjutkan
- Progres bertahap yang lambat namun stabil lebih aman daripada mencoba mengirim data besar sekaligus
- Jika panggilan HTTPS terus gagal, alih-alih mengulang panggilan yang sama secara buta, sebaiknya periksa DNS, ICMP, HTTP tanpa TLS, dan HTTPS ke endpoint yang diketahui sehat lalu beri tahu statusnya ke pengguna
-
Gagal mengunduh metadata saat startup
- Satu aplikasi desktop populer mengunduh informasi konfigurasi dari situs vendor saat startup, dan memakai timeout yang di-hardcode untuk panggilan HTTPS tersebut
- Jika panggilan ini gagal, aplikasi tidak akan dimuat dan terus mencoba ulang selamanya dengan parameter yang sama, sementara layar loading tidak memberi tahu penyebabnya
- Di South Pole, jika terus dicoba pada akhirnya bisa lolos, tetapi satu nilai timeout tunggal hampir membuat aplikasi enterprise itu tidak bisa dipakai
- Perilaku yang lebih baik adalah timeout panjang dengan backoff bertahap, pemeriksaan status koneksi, penjelasan penyebab, penggunaan cache atau konfigurasi default, serta penyediaan jalur unduh dan instalasi manual
-
Perbandingan dua aplikasi chat
- Satu aplikasi chat populer memakai timeout hardcoded 10 detik untuk inisialisasi WebSocket
- Karena dibutuhkan TCP handshake, sesi TLS, pengaturan WebSocket, dan pensinyalan awal, kondisi seperti South Pole—di mana tiap round-trip bisa memakan beberapa detik—dapat dengan mudah melampaui 10 detik
- Setelah timeout terlewati, aplikasi tidak berfungsi dan masuk ke status backoff panjang, sementara UX-nya tidak menunjukkan situasi ini dengan jelas
- Aplikasi chat pesaing bekerja jauh lebih baik bahkan dalam kondisi jaringan yang sangat buruk
- Memakai beberapa strategi permintaan jaringan
- Secara agresif menggunakan ulang koneksi yang sudah terbuka
- Menyesuaikan timeout secara dinamis
- Memilih interval retry secara cerdas saat gagal
- Menampilkan kondisi jaringan saat ini dengan jelas
- Kedua aplikasi sebenarnya sama-sama hanya mengirim beberapa byte teks biasa, tetapi perbedaan asumsi jaringan membuat syarat agar keduanya dapat dipakai menjadi sangat berbeda
Transfer inkremental dan upload yang bisa dilanjutkan
- brr.fyi adalah blog statis Jekyll, dengan aset disimpan di S3 dan disajikan lewat CloudFront
- File statis dibangun di laptop lokal
- Diunggah langsung ke S3
- Tidak ada server, lingkungan QA, sistem build, hook otomatis, atau elemen dinamis
- Dengan mempertimbangkan batasan South Pole, skrip publikasi Python yang dibuat untuk blog ini mengunggah aset ke API S3 dalam chunk kecil
- Mendeteksi upload yang gagal dan melanjutkannya tanpa kehilangan progres
- Tidak memublikasikan versi baru sampai semua file terunggah dengan aman
- Diimplementasikan dalam sekitar 200 baris Python
- Pengguna yang mengunggah file besar ke platform blog komersial atau media sosial harus menyesuaikan waktu berdasarkan peluang bahwa proses akan berhasil sekaligus dalam jendela satelit yang tersedia
- Jika gagal, mereka harus mencoba berkali-kali
- Kadang tidak jelas apakah konten sudah terunggah, apakah upload sudah selesai, atau apakah aman menekan “Post” lagi
- Jika chunk POST yang gagal bisa dicoba ulang atau dilanjutkan nanti dengan kerugian minimal, pengguna dapat mengumpulkan upload sedikit demi sedikit—bahkan hanya beberapa KB—pada waktu yang nyaman
Standar yang harus dipenuhi downloader bawaan
- Jika aplikasi ingin membuat downloader sendiri, kualitasnya harus sangat tinggi; jika tidak, di internet lambat hasilnya bisa sangat menyebalkan atau gagal total
- Jika memungkinkan, pengguna harus bisa keluar dari downloader bawaan dan mengambil file secara langsung
- Menyediakan tautan unduhan manual sangat membantu
- Jika memungkinkan, lebih baik lagi menyediakan tautan ke file patch diferensial yang sebenarnya ingin diambil aplikasi daripada installer penuh
- Keunggulan tautan unduhan manual jelas
- Pengguna bisa memilih downloader yang lebih tangguh, seperti browser
- File bisa diunduh sekali lalu dibagikan ke beberapa perangkat
- File bisa diunduh dari komputer lain, bukan hanya komputer tempat aplikasi berjalan
- Pengguna dapat menjadwalkan atau mengelola unduhan sesuai batasan mereka sendiri
- South Pole tidak memiliki internet 24 jam, jadi meskipun ada jendela unduhan 4 jam setiap hari, jika data yang bisa diterima selama waktu itu lebih kecil daripada ukuran payload, tidak ada cara menyelesaikannya sekaligus
- Banyak downloader bawaan tidak memiliki pause/resume, notifikasi status, logika retry, pelacakan progres, dan bahkan memberlakukan batas waktu unduhan, sehingga sangat menentukan apakah seluruh aplikasi bisa dipakai atau tidak di internet lambat
Mengapa pengelola unduhan browser menjadi patokan
- Pengelola unduhan browser web modern memberi standar tinggi yang tak terelakkan bagi downloader bawaan untuk dibandingkan
- Menghentikan, menjeda, dan melanjutkan
- Mencoba ulang unduhan yang gagal
- Menampilkan status saat ini, kecepatan, dan sisa waktu
- Memilih lokasi simpan dan memungkinkan file disalin
- Tidak ada cutoff performa yang sewenang-wenang
- Bahkan jika pengguna ingin mengunduh file berukuran beberapa GB pada 60kbps, browser tetap mengizinkannya
- Jika aplikasi tidak bisa mengimplementasikan fitur setara browser, setidaknya lebih baik memberi URL asli agar pengguna bisa mengunduhnya lewat browser
Kasus pembaruan macOS
- Pembaruan macOS sangat membebani di South Pole
- Ukuran patch pembaruan minor OS biasanya 0.5~1.5GB
- Patch upgrade mayor OS kadang lebih dari 6GB
- Alat tambahan seperti Xcode juga sering berukuran beberapa GB
- Jika semua perangkat macOS mengambil pembaruan langsung dari Apple, bandwidth akan terbuang sangat besar
- Updater bawaan macOS memberi kontrol yang minim, dan tidak ada cara mudah untuk mendapatkan file patch yang mendasarinya
- Saat dibatalkan atau gagal, proses tidak selalu melanjutkan secara cerdas, dan kadang progres hilang
- Secara teori, fitur server caching macOS dari Apple dapat mengurangi beban dengan membuat setiap patch hanya perlu diunduh sekali ke South Pole
- Namun dalam praktiknya, tiap klien MacBook harus berhasil melakukan panggilan HTTPS ke Apple untuk negosiasi parameter cache
- Jika panggilan ini gagal, klien Mac langsung mengambil patch dari server publik Apple tanpa notifikasi atau retry
- Di South Pole, panggilan negosiasi awal ini sering gagal sehingga fitur cache tidak banyak berguna
- Installer penuh dapat diunduh dari Apple melalui tautan yang dikumpulkan di Mr. Macintosh, lalu didistribusikan di dalam pangkalan setelah diunduh secara lambat namun hati-hati
- Installer penuh ini berukuran 12GB, dan unduhannya bisa memakan beberapa hari, tetapi andal
- Mac Apple Silicon, bahkan saat diperbarui menggunakan installer penuh, masih mencoba mengunduh konten tambahan 1~2GB langsung dari Apple, seperti pembaruan firmware atau Rosetta
- Tidak ada cara untuk melewati atau menyimpannya dalam cache
- Ada juga kasus ketika unduhan berpindah ke komponen terpisah macOS sehingga progresnya tidak tercermin di UI instalasi
- Situasi seperti layar “32 menit tersisa” yang bertahan berjam-jam sambil mengunduh 1GB di latar belakang pun bisa terjadi
- Yang dibutuhkan adalah penyediaan tautan patch yang diperlukan, pause/resume dan pengelolaan status yang lebih baik, penyertaan item tambahan untuk Apple Silicon dalam installer penuh, serta reliabilitas dan kontrol yang lebih baik pada server cache
Kasus pembaruan OS Samsung Android
- Alat pembaruan OS pada ponsel Samsung Android adalah contoh yang tidak mempertimbangkan internet lambat atau intermiten
- UI pembaruannya tidak menampilkan kecepatan, progres numerik, pause, cancel, ukuran file, atau cara mengakses file untuk unduhan terpisah
- Jika unduhan gagal, proses tidak bisa dilanjutkan dan harus dimulai lagi dari awal
- Di South Pole, karena seluruh pembaruan OS tidak bisa diunduh dalam satu kali satelit lewat, putus koneksi berarti pasti gagal dan harus mulai dari awal
- Dalam praktiknya, orang justru mematikan ponsel sepenuhnya tepat sebelum internet terputus, lalu menyalakannya lagi pada lintasan satelit berikutnya untuk menghindari status gagal unduhan
- Dengan cara ini, unduhan bisa dibagi dan diselesaikan selama beberapa lintasan satelit
- Solusi semacam ini seharusnya tidak perlu; ini adalah jalan pintas yang tidak normal
- Aplikasi pembaruan Verizon untuk macOS dan Windows secara teori memungkinkan flashing pembaruan OS dari komputer, tetapi dalam praktiknya banyak bug, kurang andal, dan memakai downloader bawaan sendiri
- Inti masalahnya adalah alat umum yang disediakan vendor untuk pengguna akhir menawarkan fitur yang tidak memadai bagi pengguna internet lambat
Pembaruan aplikasi kecil dan perbandingan dengan Microsoft Office for Mac
- Updater bawaan satu aplikasi desktop kecil tidak memiliki fitur dasar yang dibutuhkan di tautan lambat
- Tombol pause
- Tombol cancel
- Tampilan progres
- Tampilan kecepatan atau sisa waktu
- Akses ke URL asli
- Pelacakan progres dan kelanjutan yang wajar untuk unduhan terputus
- Aplikasi ini bisa jauh lebih baik bagi pengguna South Pole hanya dengan menyediakan tautan unduhan manual
- Updater otomatis aplikasi lain memang memiliki tombol cancel dan progres visual, tetapi tidak memiliki pause, progres numerik/kecepatan, akses URL asli, maupun kemampuan resume
- Updater otomatis Microsoft Office for Mac adalah contoh yang baik bahkan di South Pole
- Tombol pause
- Tombol cancel
- Tampilan progres
- Tampilan kecepatan dan sisa waktu
- Kelanjutan alami untuk unduhan yang terputus
- Akan lebih baik lagi jika menyediakan URL asli, tetapi antarmukanya sudah cukup baik sehingga masih layak dipakai di South Pole
Prinsip desain praktis untuk pengguna internet lambat
- Dalam lingkungan internet cepat, fitur yang tampak seperti kekurangan kecil bisa menjadi hambatan besar di internet lambat
- Aplikasi harus dirancang agar pengguna tidak terjebak dalam loop yang membuat mereka bahkan tidak bisa mengirim beberapa byte teks hanya karena satu nilai timeout tetap
- Prinsip desain yang memungkinkan sebenarnya sederhana
- Jika byte bergerak, jangan hentikan
- Bagi payload besar menjadi chunk
- Simpan progres meski terjadi kegagalan
- Tampilkan kondisi jaringan dengan jelas kepada pengguna
- Jika downloader bawaan kurang memadai, sediakan tautan unduhan manual
- South Pole memang edge case, tetapi lingkungan Inmarsat di kapal laut, Thales MissionLink dan Iridium Certus di lokasi riset pegunungan, Wi‑Fi tidak stabil, router yang salah konfigurasi, WISP berkualitas buruk, dan pengguna dial-up berbasis saluran telepon lama juga dapat menghadapi batasan serupa
- Pengembang tidak harus mengoptimalkan untuk semua kondisi ekstrem, tetapi tetap perlu berupaya agar produk tidak secara aktif menghambat progres pengguna dengan koneksi lambat
1 komentar
Komentar Hacker News
Tulisan ini sangat mengena. Saya memang bukan di Antartika, melainkan di Beijing, tetapi masih tetap menderita karena internet
Kalau berada di balik Great Firewall, kita harus memakai cara-cara kreatif, dan VPN pun hanya kadang-kadang berfungsi. Setiap VPN meninggalkan jejak, sehingga heuristik dan machine learning firewall pada akhirnya menangkapnya; bahkan VPN yang diizinkan negara pun dibatasi secara “halus” pada masa-masa yang sensitif secara politik
Pada akhirnya, meski bisa terhubung, koneksinya tidak stabil, dan rasanya sangat menyakitkan membuang paket yang berharga untuk round-trip request web app/React yang tidak berguna
Sebagian developer sepertinya perlu melakukan perjalanan waktu ke sekitar tahun 2005 dan mencoba mengembangkan dengan standar era itu agar belajar cara membuat sesuatu yang ringan. Kalau perjalanan waktu tidak memungkinkan, saya sangat berharap mereka menyalakan throttling di developer tools, menyetelnya ke 3G, lalu memastikan apakah web app mereka bisa bertahan
Saya selalu menguji proyek pada bandwidth terbatas. Seperti halnya aksesibilitas, mengikuti praktik yang baik tidak hanya memberi pengalaman yang lebih baik bagi pengguna dengan koneksi buruk, tetapi juga bagi semua pengguna
Peluang lain yang sering terlewat adalah membuat aplikasi satu halaman menjadi offline-first
Saya tidak sepenuhnya menentang inti argumennya, tetapi JavaScript modern sebenarnya cukup bagus untuk menangani internet lambat dalam “aplikasi” server-klien. Hanya saja, membuatnya mudah itu sulit, dan hampir tidak ada materi online yang bisa dijadikan fondasi proyek oleh orang yang coding dengan Google/GPT
Ini sebagian karena terlalu banyak materi JavaScript yang buruk di internet, tetapi juga karena organisasi yang bekerja dengan cara seperti ini tidak membagikannya. Kami juga tidak punya alasan untuk menyerahkan informasi kepada pesaing, jadi materi publik tentang cara kerja kami jumlahnya 0
Ini menjadi latihan menarik untuk mengurangi round-trip yang tidak berguna pada teknologi yang mengharapkan round-trip request untuk segala hal
Saya masih mendapatkan sekitar 1–10 Mbit/s, umumnya bergantung pada waktu, dan hampir tidak ada masalah koneksi
Sebagai orang yang punya banyak pengalaman komuter dengan transportasi umum bawah tanah (terputus-putus dan padat), serta pernah tinggal dan bekerja di Australia, saya bisa mengatakan dengan yakin bahwa sebagian besar layanan sangat buruk bagi orang-orang yang tidak berada dalam kondisi jaringan “ideal”
Di London Underground, sangat kentara bahwa sebagian besar aplikasi benar-benar buruk dalam menangani jaringan yang putus-nyambung kira-kira setiap 2 menit. Koneksi terputus di antara stasiun, lalu kereta berisi 500 penumpang mencoba tersambung sekaligus, sehingga bahkan untuk terhubung ke tiap access point saja butuh sekitar 15 detik
Di Australia, pada dasarnya semuanya berjarak 200 ms. Mungkin terlihat sepele, tetapi itu sangat jelas memperlihatkan aplikasi mana yang tersandung masalah request N+1
Satu-satunya aplikasi yang selalu mengesankan adalah WhatsApp. Setelah tersambung kembali, ia yang pertama bekerja, dan sampai sesaat sebelum koneksi terputus pun ia yang terakhir masih bisa meloloskan trafik; bahkan dengan latensi, panggilan terasa cukup responsif
WhatsApp kemungkinan besar adalah salah satu dari sedikit layanan yang benar-benar mendeploy server di Australia. 200 ms terlihat sebagai sinyal kuat bahwa trafiknya lintas benua
Sebagian besar perusahaan global paling banyak melakukan deployment di tiga kawasan: AS (us-east, us-central, us-east+us-east), Eropa (west-europe), dan, relatif lebih jarang, Timur Jauh (us-west atau Jepang)
Karena itu, tempat seperti Afrika Selatan, Amerika Selatan, dan Australia biasanya harus mengambil data dari salah satu wilayah ini, dan karena batas fisika, latensi minimumnya menjadi 200 ms
Australia terkena dampak khususnya besar. Secara teori, sekalipun ada deployment khusus untuk yurisdiksinya, sering kali server sebenarnya berada di benua yang sama sekali berbeda (AS barat atau Jepang), sehingga pengguna merasakan langsung dampak performa dari paket yang berkeliling setengah dunia
Karena perspektif seperti itu tertanam dalam tujuan pengembangannya, menurut saya ada alasan kuat mengapa WhatsApp menjadi aplikasi pesan utama di banyak negara di dunia
Saat membuka URL .jpg di browser untuk melihat gambar, prosesnya jauh lebih lama dibandingkan beralih ke termux dan menjalankan
wget, dan kadang malah timeout. Saya mengalaminya baik di Firefox maupun browser berbasis ChromeSebagai catatan, unduhan dengan
wgetpun pada koneksi seluler biasanya memakan waktu 10–30 detikSaya tidak paham mengapa Berlin memilih cara seperti ini. Padahal tinggal menyediakan internet di dalam kereta saja
Jika jaringan terus terputus, sebagian besar internet benar-benar bekerja sangat buruk
Saya sering bepergian, dan internet lambat itu cukup umum. Sekarang pun kuota data seluler saya habis, jadi dibatasi ke 8 kbps
Situs web yang halamannya hanya berisi teks seharusnya cepat, tetapi banyak yang tidak begitu. Hacker News sangat cepat, tetapi dokumentasi Google API sama sekali tidak bisa dibuka
Masalah terburuknya adalah sebagian besar UI tidak memperhitungkan request yang lambat. Tombol terasa seperti rusak, dan hal-hal yang seharusnya tidak membutuhkan data berukuran megabyte pun butuh beberapa menit untuk dimuat atau gagal. Seluruh UI Google Maps jadi berantakan
Saya berharap para developer lebih banyak merancang dan menguji untuk internet lambat. Alih-alih, yang muncul adalah situs web rakus data yang hanya berjalan baik di laptop perusahaan yang cepat dan internet yang cepat
Terkait itu, saya mencari nafkah dengan mengelola situs web, dan pindah ke static site generator adalah salah satu pilihan terbaik dari sisi produktivitas. Alih-alih latensi CMS merembes ke setiap pekerjaan, saya bisa mengedit file teks dengan sangat cepat bahkan sepenuhnya offline, lalu ketika online cukup push perubahan saja. Itu benar-benar mengubah permainan
Sekarang, meski mengunduh cache Google Maps 500 MB ke ponsel, rasanya tidak ada gunanya. Tetap saja semuanya diambil lagi dan muncul terlambat
Saat ini salah satu domain saya ditandai sebagai “berbahaya” karena tidak memakai WordPress terbaru
Pada dasarnya setiap request yang dikirim menyentuh aplikasi AppEngine, lalu aplikasi itu menjalankan kode Python untuk mengembalikan HTML. Jadi seharusnya tampak cepat, tetapi kenyataannya tidak
Saya berada di Inggris, dan ping ke news.ycombinator.com adalah 147 ms. Tampaknya karena tidak memakai CDN dan di-host di AS
Sebaliknya, ping ke cloud.google.com adalah 8 ms
Hacker News memang halaman yang sederhana dan minim JavaScript, tetapi bisa ada faktor lain yang membuatnya terasa lambat bagi pengguna di wilayah tertentu. Bahkan dalam lingkungan istimewa yang memakai jalur fiber XGS-PON dengan 8 Gbps simetris sekalipun
Saya pernah memberi tumpangan kepada seseorang yang baru turun dari lapisan es saat sedang hitchhiking, dan menurutnya penulis blog itu memang tulisannya bagus, tetapi cukup tidak disukai orang-orang di sekitarnya karena sering menghabiskan bandwidth yang sudah terbatas saat mengunggah gambar
Namun, karena pihak administrasi melihat nilai publisitasnya, ia mendapat prioritas. Saya pikir ini nyambung dengan diskusi tentang internet lambat
Ponsel di saku bisa saja tanpa perlu memakai semua bandwidth yang tersedia, dan walaupun seseorang menonton video 720p yang hanya pas-pasan bisa diputar, orang lain yang mencoba memuat sesuatu di belakangnya mungkin bahkan tidak bisa menonton 480p. Orang pertama tidak menyadarinya karena ada buffer, sementara orang kedua bisa menyerah sebelum buffer-nya cukup terisi
Sepertinya minimal harus ada akuntansi penggunaan yang memberi tahu berapa persen traffic dalam 1 jam terakhir yang menuju ke diri sendiri, dan dibandingkan dengan nilai acuan berupa bandwidth yang tersedia dibagi jumlah pengguna terhubung, berapa persen jatah diri sendiri seandainya semua orang membutuhkannya secara setara
Lebih jauh lagi, tampaknya mungkin dibuat sistem yang menempatkan semua orang pada prioritas rendah sampai mereka menekan tombol “Ya, saya tahu bandwidth yang akan saya pakai selama [X≤24] jam ke depan dan memang benar-benar membutuhkannya”, lalu setelah ditekan prioritas QoS alamat MAC/IP dinaikkan ke normal
Situasi seperti ini jelas membutuhkan aplikasi local-first dan solusi terkait, dan sejak awal internet memang dibuat untuk arah itu [1][2]
Orang-orang tertipu oleh slogan iklan Salesforce “No Software”, padahal itu bertentangan langsung dengan fondasi dan semangat internet. Sejak 1969, selama sebagian besar sejarah internet, Mbps adalah pengecualian, bukan standar, dan killer app pertama, yaitu pesan email, adalah local-first (dan mungkin masih merupakan aplikasi internet terbaik) [3]
Ironisnya, aplikasi bermasalah yang dikeluhkan penulis juga merupakan aplikasi messenger
[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...
Selama beberapa tahun saya banyak mengerjakan hal terkait jaringan, dan menghabiskan waktu untuk membuat lingkungan “internet lambat” saya sendiri berjalan. Tidak semenarik McMurdo, tetapi saya bisa mengobrol dan menonton video YouTube di penerbangan internasional, kereta yang melewati tempat terpencil, hotel pedesaan yang buruk, bahkan di dalam terowongan
Jika Anda punya akses ke perangkat komputasi serbaguna, mampu menyediakan daya (perangkat seperti ini cenderung boros listrik), dan bersedia membuatnya sendiri, saya merekomendasikan NNCP [1]. NNCP dapat menerima data, memecahnya menjadi potongan-potongan, lalu mengirimkannya. Ia juga menyertakan protokol sinkronisasi yang menggunakan noise di atas TCP, dan mengirim sambil mencoba ulang potongan yang gagal. Tidak perlu TLS, jadi pembentukan koneksi hanya memakan 1,5 RTT
NNCP dapat memasukkan data lewat input standar ke program jarak jauh. Saya membuat YouTube downloader, bot Slack, bot Telegram, dan bot Discord yang membaca data masuk lalu berinteraksi dengan layanan terkait. Di mesin lokal saya menjalankan server Matrix (Dendrite) dan bot, lalu mengirim data lewat NNCP ke layanan jarak jauh yang sesuai
Anda mungkin ingin, atau perlu bereksperimen agar MTU/MSS di sepanjang rute serendah mungkin sehingga retry di level TCP bisa sering terjadi, tetapi konfigurasi ini nyaris tidak pernah gagal ke mana pun saya pergi, dan memungkinkan konsumsi media serta chat
Hal paling menyebalkan pada penerbangan internasional adalah endpoint NNCP tidak tersebar secara geografis. Bergantung pada rute penerbangan dan rute sebenarnya yang ditempuh paket menuju endpoint, latensi dan jitter bisa meningkat besar. Biasanya saya mencoba menaruh endpoint NNCP di dekat tujuan, tetapi rute aktual menurut Wi-Fi pesawat bisa sangat buruk. NNCP kini mendukung Yggdrasil, yang mungkin dapat meredakan ini dan juga membantu mengendalikan masalah MTU, tetapi saya belum pernah memakai Ygg dalam kondisi seperti ini
[1]: http://www.nncpgo.org/
Saya punya pengalaman mirip dengan penulis di kapal di Pasifik Selatan. Ada Starlink, tetapi konsumsi dayanya tinggi (lebih dari 60W), jadi jarang dipakai. Sebagai gantinya saya membeli kartu SIM lokal dan memakai 4G di beberapa tempat, EDGE (2G) di tempat lain
EDGE sendiri di atas kertas tidak terlalu buruk. Bisa mencapai puluhan kilobit per detik. Dalam praktiknya jauh lebih buruk. Saya mengalami aplikasi yang sebenarnya akan berjalan baik jika saja memperhitungkan bahwa loading bisa memakan waktu beberapa menit, bukan milidetik, tetapi gagal karena timeout yang pendek
Koneksi bandwidth rendah dan latensi tinggi seharusnya masuk dalam pengujian rutin perangkat lunak. Di Linux ada netem (https://wiki.linuxfoundation.org/networking/netem) yang memungkinkan hal ini
Masalah lain yang tidak dialami penulis blog anonim itu adalah koneksi berbasis kuota. Karena biaya, upgrade sistem operasi atau aplikasi nyaris mustahil dilakukan. Untungnya, setiap beberapa minggu kami tiba di tempat dengan koneksi tak terbatas sehingga bisa melakukan hal-hal itu. Sebagai gantinya, saya jadi sangat terbiasa dengan cara menandai koneksi sebagai berbasis kuota/tidak berbasis kuota di berbagai sistem operasi, mematikan semua pembaruan otomatis, dan menghemat bandwidth yang berharga
Dan jika “kartu SIM lokal”, berarti Anda turun ke pulau untuk membeli SIM itu; saya penasaran di mana pada 2020-an yang hanya tersedia 2G. Sulit percaya masih ada tempat seperti itu di Pasifik Selatan
Perspektif perlu dijaga. Ada proyek yang bahkan melewatkan pengujian webapp di beberapa browser karena dianggap pemborosan dan biaya yang tidak bisa dibenarkan. Padahal memasukkannya ke matriks pengujian itu sepele dan hanya soal UI
Rekayasa dengan mempertimbangkan internet lambat masih benar-benar penting, dan menurut saya sangat diremehkan oleh sebagian besar pengembang perangkat lunak. Namun sistem satelit orbit rendah (Starlink, khususnya StarLink) kini secara praktis sudah menyelesaikan masalah inti
Pada September–Oktober 2023 saya melewati rute Arktik (dari Alaska ke Norway), dan bahkan di kapal yang berada jauh di atas Lingkar Arktik, meski ada awan, jarak dari daratan, dan es, saya bisa melakukan panggilan video FaceTime. Itu bertepatan dengan periode ketika penulis berada di Antarctica
Apa pun kendalanya, pada akhirnya ini soal kontrak layanan dan membawa terminal ke lokasi. Cakupan wilayah kutub relatif jarang, tetapi karena populasinya sangat kecil, tetap saja memadai
https://satellitemap.space/
Internet lambat punya beberapa makna, salah satunya adalah masalah koneksi. Pada protokol berorientasi koneksi seperti TCP, itu berarti kelambatan akibat kehilangan paket; pada protokol lempar-lalu-selesai seperti UDP, itu berarti pesan tidak sampai. Jadi kelambatan bisa berarti laju transfer rendah, atau bisa juga berupa throughput tinggi sesaat yang kemudian terputus-putus sebentar
Salah satu pendekatan yang tangguh untuk menangani jaringan lambat adalah dukungan mode offline. Semua push/pull data dirancang sebagai transaksi asinkron, dan push data di-cache secara lokal lalu dicoba ulang saat memungkinkan. Ini memunculkan kebutuhan tambahan seperti versioning dan penyelesaian konflik
Secara alami, kebutuhan UI juga bertambah. Diperlukan sinkronisasi/refresh manual, indikator status jaringan, menonaktifkan tindakan yang tidak bermakna saat jaringan terputus, serta pemuatan proaktif agar tetap bisa digunakan saat offline
Suatu hari saya ingin hidup di dunia setelah internet lambat, tetapi itu masih bertahun-tahun lagi. Sebagai catatan, XS memakai modem Intel yang dikenal lebih inferior dibanding flagship Qualcomm pada era itu
Saya tinggal di salah satu tempat dengan kepadatan penduduk tertinggi di dunia, penuh antena 5G dan stasiun Wi-Fi, tetapi situs web yang dibuat asal-asalan tetap terasa tumbang pada koneksi yang lambat atau tersendat-sendat
Satelit geostasioner terlalu dekat dengan horizon di Pole, sehingga cakupan kutub terbatas. Pole memakai satelit geostasioner lama dengan bahan bakar sedikit dan inklinasi orbit relatif besar, sehingga hanya bisa berkomunikasi sekitar 6 jam dari 24 jam
Jadwal: https://www.usap.gov/technology/1935/
Pemerintah tidak akan menginginkan web tanpa sensor atau perusahaan AS menjadi gerbang internet. Mereka akan mempertahankan jaringan di wilayah yang mereka kuasai sekarang, dan masalah kecepatan akan tetap relevan
Kita juga perlu mempertimbangkan jumlah orang di seluruh dunia yang satu-satunya sarana akses internetnya adalah ponsel Android seharga 100 dolar dengan perangkat lunak usang dan CPU terbatas
Ada draf proposal IETF yang memperluas HTTP untuk sinkronisasi status yang efisien, yang dapat meningkatkan pengalaman pengguna di jaringan lambat: https://news.ycombinator.com/item?id=40480016
Braid Protocol memungkinkan berbagai algoritma sinkronisasi saling beroperasi di atas protokol jaringan umum, dan pesan jaringan dari sinkronizer mana pun dapat diterjemahkan ke atasnya. Saat ini spesifikasi Braid menambahkan dua dimensi sinkronisasi ke HTTP
Level 0: HTTP saat ini
Level 1: langganan dengan pembaruan push
Level 2: konsistensi P2P (patch, versi, merge)
Sinkronizer saat ini memakai protokol yang berbeda-beda, tetapi pesan jaringannya membawa jenis informasi yang sama: versi dalam waktu, lokasi dalam ruang, dan patch area ruang dalam rentang waktu. Komposisi himpunan patch arbitrer membentuk struktur matematis bernama braid: percabangan, penggabungan, dan pengurutan ulang ruang sepanjang waktu
Harapan memang selalu muncul
Mengurangi round trip dan membuat sesuatu yang tidak terlalu bloat itu tidak sulit; malah jauh lebih mudah. Bloat ada karena alasan yang sama sekali berbeda
Kadang-kadang, pada internet cepat dan mesin lapang yang dekat dengan data center, bloat tidak terlihat. Itu bisa disimulasikan dengan mudah, tetapi perusahaan harus peduli. Secara umum, teknologi iklan dan ekosistem sekitarnya hampir tidak peduli pada kelompok pengguna kecil. Bahkan satu-satunya alasan mereka peduli pada pengguna akhir adalah karena pengguna itu menghasilkan pendapatan bagi pelanggan sebenarnya, yaitu pengiklan
Kita yang membuat aplikasi, situs web, dan semacamnya harus ingat bahwa banyak orang tidak terhubung ke Wi-Fi cepat atau koneksi fiber seperti yang kita pakai
Di Inggris, sebagian operator mulai mematikan 3G. Sebagian menyisakan 2G sebagai alternatif berdaya rendah, tetapi intinya sekarang disuruh memakai 4G/5G. Masalahnya, 4G belum tersedia di semua tempat, dan hingga belum lama ini di beberapa wilayah hanya sinyal 3G yang cukup baik
Akibatnya, orang makin sering tanpa sengaja jatuh ke 2G/EDGE, dan banyak hal langsung berhenti. Banyak aplikasi tidak diuji pada skenario yang lambat, latensinya tinggi, dan kehilangan paketnya besar
Coba cari rute dengan Google Maps di 2G, dan jawabannya akan terlihat :(