- South Pole’ün interneti sınırlı uydu bağlantılarına dayanıyordu ve günde yalnızca birkaç saat bağlı kalabiliyordu; Ekim 2023 itibarıyla topluluk kullanıcıları yüksek gecikme, düşük bant genişliği ve aralıklı kopmaları kabullenmek zorundaydı
- Gerçek ortamda yaklaşık 750 ms gidiş-dönüş gecikmesi, birkaç saniyelik jitter, birkaç kbps ile 2 Mbps arası hızlar, tıkanıklık, kuyruklama, paket kaybı ve servis önceliklendirmesi bir araya gelerek sıradan uygulamaların ağ varsayımlarını kolayca bozuyordu
- Büyük JavaScript paketleri, sabit kodlanmış timeout’lar, ilerlemenin çöpe atılması, cache geçersiz kılma ve devam ettirilemeyen yerleşik indiriciler, yavaş bağlantıda uygulamaların kendi kendine başarısız olmasına yol açan etkenlerdi
- Baytlar yavaş da olsa akıyorsa beklemek; parça parça aktarım, devam ettirme, durum göstergesi, dinamik timeout’lar ve manuel indirme bağlantıları sunmak, metin mesajı ya da güncelleme gibi küçük hedeflerin başarılmasını mümkün kılıyordu
- Antarktika uç bir örnek olsa da denizdeki gemiler, dağ araştırma sahaları, kararsız Wi‑Fi, düşük kaliteli WISP’ler ve telefon hattı tabanlı bağlantı kullanıcıları da benzer kısıtlarla karşılaşabilir; bu yüzden kullanıcının ilerlemesini engellemeyen tasarım gerekir
South Pole internet ortamının kısıtları
- South Pole’de internet sağlamak başlı başına önemsiz olmayan bir mühendislik problemi ve kutup bölgesinde kullanılabilecek uydu seçenekleri sınırlı
- Açık kaynak olarak South Pole Satellite Communications sayfası bulunuyor
- Antarktika kıtasına geleneksel fiber optik bağlamanın zorlukları 2021 Antarctic Subsea Cable Workshop kapsamında da ele alındı
- NSF, McMurdo ve Palmer’daki Starlink ile ilgili bir duyuru yaptı ancak Ekim 2023 itibarıyla South Pole Station için benzer bir duyuru yoktu
- McMurdo yakın zamana kadar neredeyse 1.000 kişi ile çeşitli bilimsel ve operasyonel iş yüklerinin, tüm üs genelinde onlarca Mbps düzeyindeki toplam bant genişliğini paylaşmasını gerektiriyordu
- ABD banliyölerinde sıradan bir 4G hücresel ağda tek bir kişinin elde edebileceği bant genişliğinden daha azını tüm üs paylaşıyordu
- South Pole yalnızca uydu ufkun üzerine çıktığında ve üs kullanım izni aldığında bağlanabiliyordu; uydu takvimi yıldız zamanı ile güneş zamanı arasındaki fark nedeniyle genellikle her gün yaklaşık 4 dakika öne çekiliyordu
- Kullanıcıların hissettiği gecikme, alışıldık internet deneyiminden çok farklıydı
- ABD ana karasındaki hedeflere gidiş-dönüş gecikmesi yaklaşık 750 ms
- ABD doğu ve batı kıyıları arasındaki en fazla 75 ms gidiş-dönüş gecikmesinin yaklaşık 10 katı
- Tipik ev tipi kablo veya fiber bağlantıda büyük CDN’lere beklenen en fazla 25 ms’nin yaklaşık 30 katı
- Kullanıcının evindeki GPON fiberden Fastly, Cloudflare, CloudFront, Akamai ve Google’a yaklaşık 3 ms olduğu düşünüldüğünde South Pole 250 kattan fazla büyüktü
Topluluk kullanıcılarının fiilen karşılaştığı koşullar
- Ekim 2023 itibarıyla South Pole’de topluluk amaçlı internet kullanan kişiler şu koşulları yaşayabiliyordu
- Ortalama gidiş-dönüş gecikmesi yaklaşık 750 ms, paketler arasında birkaç saniyeyi aşan jitter
- Son kullanıcı cihazı açısından birkaç kbps’den çok iyi bir günde 2 Mbps’ye kadar hızlar
- Şiddetli tıkanıklık, kuyruklama, paket düşmesi
- Sınırlı erişilebilirlik, sık kopmalar ve ara sıra servis önceliklendirmesiyle bağlantının elden gitmesi
- Belirli durumlarda 40 kbps, 1.000 ms gecikme, 2.000 ms’ye kadar jitter, %10 paket kaybı ve birkaç dakikada bir 15 saniyelik tamamen kopma gibi koşullar da ortaya çıkıyordu
- Operasyon trafiğine güçlü biçimde öncelik verildiği için topluluk kullanıcıları kalan kapasiteye bağımlıydı
- Gerçek zamanlı video konferans gibi özellikleri beklemek zordu; ancak bazı uygulamalarda birkaç baytlık metin gönderip almak mümkündü
- Yavaş veya aralıklı bağlantıları dikkate almayan web ve uygulama mühendisliği kullanılabilirliği daha da kötüleştiriyordu
20 MB JavaScript isteyen iş birliği web uygulaması örneği
- Bir kurumsal iş birliği platformu, ana ekranı render etmek için yalnızca JavaScript olarak neredeyse 20 MB indirmeyi gerektiriyordu
- Önceki girişten sonra uygulama güncellenmiş, tarayıcı cache’indeki tüm varlıklar eskimiş ve yeniden indirilmeleri gerekmişti
- Tarayıcı ve protokoller yavaş internette tıkanıklık kontrolünü bir ölçüde yönetir; ancak bu uygulama kendi başarısızlık koşullarıyla yüklemeyi kesiyordu
- Geliştiricinin belirlediği süre veya yeniden deneme sayısı içinde tamamen yüklenmezse uygulama duruyordu
- Hata sayfasına yönlendiriliyordu
- O ana kadar ilerlemiş yükleme durumu kayboluyordu
- Bir sonraki denemede güçlü cache geçersiz kılma önlemi uygulanıyordu
- Bu uygulama özünde bir mesajlaşma uygulamasıydı ve çalıştıktan sonra arkadaşlarla sohbet ederken gerçek içerik payload’u bayt düzeyindeydi
- South Pole’ün internet performansı, geliştiricinin “kabul edilebilir” gördüğü sınırdaydı ve kullanıcı aynı JavaScript’i tekrar indirmek için defalarca yenilemek zorunda kalıyordu
- Gerekli aktarım kendi haline bırakılsa 15 dakika içinde bitebilirdi, ancak pratikte bazen saatler sürüyordu
- Başarılı bir örnekte 809 HTTP isteği, 51,4 MB aktarım ve 26,5 dakikalık yüklemenin ardından 1,8 KB’lık HTTPS POST ile 6 baytlık mesaj gönderildi
- Uygulama, veri yavaş da olsa akarken beklemeye devam edecek şekilde tasarlansaydı gereksiz yeniden aktarımları ve bant genişliği israfını azaltabilirdi
Sabit kodlanmış timeout’lar ve büyük tek parça aktarımlar sorunu
- Payload’un ne kadar hızlı aktarılacağına ve tek bir istekte ne kadar gönderilebileceğine dair sabit varsayımlar, yavaş bağlantılarda uygulamaları bozabilir
- Baytların aktığını ölçebiliyorsanız ne kadar yavaş olursa olsun aktarımı kesmemek ve mevcut durumu arayüzde göstermek daha iyidir
- Bir HTTPS çağrısı başarısız olursa daha uzun timeout ile yeniden denenmeli ve büyük veriler küçük parçalara bölünerek aktarılmalıdır
- Her parça için ilerleme izlenmelidir
- Yalnızca başarısız olan küçük bölüm yeniden denenebilmeli veya devam ettirilebilmelidir
- Büyük veriyi tek seferde göndermeye çalışmaktansa yavaş ve düzenli artımlı ilerleme daha güvenlidir
- HTTPS çağrıları sürekli başarısız olursa aynı çağrıyı körlemesine tekrarlamak yerine DNS, ICMP, TLS’siz HTTP ve çalıştığı bilinen bir durum endpoint’ine HTTPS gibi kontroller yapılmalı ve kullanıcıya durum bildirilmelidir
-
Başlangıçta metadata indirme hatası
- Popüler bir masaüstü uygulaması başlangıçta tedarikçi web sitesinden yapılandırma bilgisi indiriyor ve HTTPS çağrısında sabit kodlanmış timeout kullanıyordu
- Bu çağrı başarısız olursa uygulama yüklenmiyor, aynı parametrelerle sonsuza kadar yeniden deniyor ve yükleme ekranı nedeni göstermiyordu
- South Pole’de sürekli denenirse sonunda geçebilirdi; ancak tek bir timeout değeri, kurumsal düzeyde bir uygulamayı neredeyse kullanılamaz hale getiriyordu
- Daha iyi davranış; daha uzun timeout’lara kademeli geri çekilme, bağlantı durumunu kontrol etme, nedeni gösterme, cache ve varsayılan ayarları kullanma, manuel indirme ve kurulum yolu sunma olurdu
-
İki sohbet uygulamasının karşıtlığı
- Popüler bir sohbet uygulaması WebSocket başlatma için 10 saniyelik sabit kodlanmış timeout kullanıyordu
- TCP handshake, TLS oturumu, WebSocket kurulumu ve ilk sinyalleşmenin hepsi gerektiğinden, South Pole gibi her gidiş-dönüşün birkaç saniye sürdüğü koşullarda 10 saniye aşılabiliyordu
- Timeout geçince uygulama çalışmıyor ve uzun bir backoff durumuna giriyordu; UX ise durumu net göstermiyordu
- Rakip sohbet uygulaması aşırı kötü ağ koşullarında bile daha iyi çalışıyordu
- Birden fazla ağ isteği stratejisi kullanıyordu
- Açık bağlantıları agresif biçimde yeniden kullanıyordu
- Timeout’ları dinamik olarak ayarlıyordu
- Başarısızlık durumunda yeniden deneme aralıklarını akıllıca seçiyordu
- Mevcut ağ durumunu açıkça gösteriyordu
- Her iki uygulama da gerçekte birkaç baytlık düz metin aktarıyordu; ancak ağ varsayımlarındaki fark yüzünden kullanılabilecekleri koşullar değişiyordu
Artımlı aktarım ve devam ettirilebilir upload
- brr.fyi statik bir Jekyll blogu; varlıklar S3’te saklanıyor ve CloudFront üzerinden sunuluyor
- Statik dosyalar yerel dizüstü bilgisayarda build ediliyor
- Doğrudan S3’e upload ediliyor
- Sunucu, QA ortamı, build sistemi, otomatik hook veya dinamik öğe yok
- South Pole kısıtları düşünülerek oluşturulan Python yayınlama betiği, varlıkları S3 API ile küçük parçalar halinde upload ediyordu
- Başarısız upload’ları algılıyor ve ilerlemeyi kaybetmeden devam ettiriyordu
- Tüm dosyalar güvenli biçimde upload edilene kadar yeni sürümü yayınlamıyordu
- Yaklaşık 200 satır Python ile uygulanmıştı
- Ticari blog platformlarına veya sosyal medyaya büyük dosya yükleyen kullanıcılar, tek bir uydu penceresinde başarıyla tamamlanma olasılığına göre zamanı ayarlamak zorundaydı
- Başarısız olursa defalarca yeniden denemeleri gerekiyordu
- İçeriğin yüklenip yüklenmediği, upload’ın bitip bitmediği veya tekrar “Post”a basmanın güvenli olup olmadığı bazen net değildi
- Parçalı POST başarısız olsa bile daha sonra asgari kayıpla yeniden denenip devam ettirilebiliyorsa, birkaç KB’lık parçalar uygun zamanlarda biriktirilerek upload edilebilir
Yerleşik indiricilerin karşılaması gereken ölçütler
- Bir uygulama kendi indiricisini yapacaksa yüksek bir kalite düzeyi gerekir; aksi halde yavaş internette ciddi rahatsızlık yaratır veya kritik biçimde başarısız olur
- Mümkün olduğunda kullanıcı yerleşik indiricinin dışına çıkıp dosyayı doğrudan alabilmelidir
- Manuel indirme bağlantısı sunmak faydalıdır
- Mümkünse tam kurulum dosyasından ziyade uygulamanın almaya çalıştığı fark yama dosyasının bağlantısı daha iyidir
- Manuel indirme bağlantılarının avantajları nettir
- Kullanıcı, tarayıcı gibi daha sağlam bir indirici seçebilir
- Dosyayı bir kez indirip birden fazla cihazla paylaşabilir
- Uygulamanın çalıştığı bilgisayar dışında başka bir bilgisayarda indirebilir
- Kullanıcı indirmeyi kendi kısıtlarına göre zamanlayabilir veya yönetebilir
- South Pole’de 24 saat internet yoktur; bu yüzden her gün 4 saatlik indirme penceresi olsa bile o sürede alınabilecek veri payload boyutundan küçükse tek seferde tamamlama yolu yoktur
- Birçok yerleşik indiricide duraklatma/devam ettirme, durum bildirimi, yeniden deneme mantığı ve ilerleme takibi eksiktir; indirme süresi sınırı gibi kısıtlar da vardır ve bunlar yavaş internette tüm uygulamanın kullanılabilirliğini belirler
Tarayıcı indirme yöneticisinin neden ölçüt olduğu
- Modern web tarayıcılarının indirme yöneticisi, yerleşik indiricilerin kaçınılmaz olarak karşılaştırılacağı yüksek bir standart sunar
- Kesinti, duraklatma ve devam ettirme özellikleri
- Başarısız indirmeyi yeniden deneme
- Mevcut durum, hız ve kalan süre gösterimi
- Kayıt konumu seçimi ve dosyayı kopyalayabilme
- Keyfi performans kesme sınırı olmaması
- Kullanıcı 60 kbps ile birkaç GB’lık dosya indirmek istese bile tarayıcı buna izin verir
- Uygulama tarayıcı düzeyindeki özellikleri uygulayamıyorsa en azından kullanıcının tarayıcıyla indirebileceği orijinal URL’yi vermek daha iyidir
macOS güncellemeleri örneği
- macOS güncellemeleri South Pole’de özellikle ağır bir yüktü
- Minor OS güncelleme yamalarının boyutu genellikle 0,5–1,5 GB
- Major OS yükseltme yamaları bazen 6 GB üzerinde
- Xcode gibi ek araçlar da çoğu zaman birkaç GB
- Tüm macOS cihazlarının güncellemeleri doğrudan Apple’dan alması bant genişliğini ciddi biçimde israf ediyordu
- macOS’un yerleşik güncelleyicisi az kontrol sunuyor ve alttaki yama dosyasını kolayca elde etmenin bir yolu yoktu
- İptal edilirse veya başarısız olursa her zaman akıllıca devam etmiyor, bazen ilerleme kayboluyordu
- Apple’ın macOS caching server özelliği teoride her yamayı South Pole’e yalnızca bir kez indirterek yükü azaltabilirdi
- Pratikte her istemci MacBook’un cache parametrelerini pazarlık etmek için Apple’a HTTPS çağrısını başarıyla yapması gerekiyordu
- Bu çağrı başarısız olursa istemci Mac, bildirim veya yeniden deneme olmadan yamayı doğrudan genel Apple sunucularından alıyordu
- South Pole’de bu ilk pazarlık çağrısı sıkça başarısız olduğundan caching özelliği kullanışlı değildi
- Tam kurulum dosyası, Mr. Macintosh üzerinde toplanan bağlantılar aracılığıyla Apple’dan alınabiliyordu; bu dosya yavaş ama dikkatli biçimde indirilip üs içinde dağıtılabiliyordu
- Tam kurulum dosyası 12 GB idi ve indirme günler sürebilirdi, ancak güvenilirdi
- Apple Silicon Mac’ler tam kurulum dosyasıyla güncellense bile firmware veya Rosetta güncellemeleri gibi 1–2 GB ek içeriği doğrudan Apple’dan indirmeye çalışıyordu
- Bunu atlatmanın veya cache’lemenin bir yolu yoktu
- İndirme macOS’un ayrı bir bileşenine geçtiğinde kurulum UI’ında ilerleme yansımayabiliyordu
- “32 dakika kaldı” ekranının saatlerce kalıp arka planda 1 GB indirdiği durumlar yaşanıyordu
- Gerekli yama bağlantılarının sağlanması, duraklatma/devam ettirme ve durum yönetiminin güçlendirilmesi, tam kurulum dosyasına Apple Silicon için ek öğelerin dahil edilmesi, caching server’ın güvenilirliği ve kontrolünün iyileştirilmesi gerekiyordu
Samsung Android OS güncellemesi örneği
- Samsung Android telefonların OS güncelleme aracı, yavaş veya aralıklı interneti dikkate almayan bir örnekti
- Güncelleme UI’ında hız göstergesi, sayısal ilerleme, duraklatma, iptal, dosya boyutu gösterimi veya ayrı indirme dosyasına erişim yolu yoktu
- İndirme başarısız olursa devam ettirilemiyor ve en baştan yeniden başlıyordu
- South Pole’de tek bir uydu geçişi içinde tüm OS güncellemesini almak mümkün olmadığı için bağlantı koparsa mutlaka başarısız oluyor ve baştan başlamak gerekiyordu
- Pratikte internet kopmadan hemen önce telefon tamamen kapatılıyor, sonraki uydu geçişinde yeniden açılarak indirme başarısız sayılmasının önüne geçiliyordu
- Bu yöntemle indirme birkaç uydu geçişine bölünerek tamamlanabiliyordu
- Böyle bir workaround gerekmemesi gereken anormal bir çözümdü
- Verizon’un macOS ve Windows için güncelleme uygulaması teoride bilgisayardan OS güncellemesi flash etmeyi sağlıyor; ancak pratikte çok hatalı, güvenilirliği düşük ve kendi yerleşik indiricisini kullanıyordu
- Sorunun özü, tedarikçilerin sunduğu genel kullanıcı araçlarının yavaş internet kullanıcılarına yetersiz özellikler sunmasıydı
Küçük uygulama güncellemeleri ile Microsoft Office for Mac karşılaştırması
- Küçük bir masaüstü uygulamasının yerleşik güncelleyicisi, yavaş bağlantıda gereken temel özelliklerden yoksundu
- Duraklatma düğmesi
- İptal düğmesi
- İlerleme göstergesi
- Hız veya kalan süre göstergesi
- Orijinal URL’ye erişim
- İlerleme takibi ve kesilen indirmenin doğal biçimde devam ettirilmesi
- Bu uygulama yalnızca manuel indirme bağlantısı sunsa bile South Pole kullanıcıları için büyük ölçüde iyileşebilirdi
- Başka bir uygulamanın otomatik güncelleyicisinde iptal düğmesi ve görsel ilerleme göstergesi vardı; ancak duraklatma, sayısal ilerleme/hız, orijinal URL’ye erişim ve devam ettirme yoktu
- Microsoft Office for Mac’in otomatik güncelleyicisi South Pole’de de iyi bir örnekti
- Duraklatma düğmesi
- İptal düğmesi
- İlerleme göstergesi
- Hız ve kalan süre göstergesi
- Kesilen indirmenin doğal biçimde devam ettirilmesi
- Orijinal URL’yi sunsaydı daha iyi olurdu; ancak arayüz yeterince iyi olduğu için South Pole’de de kullanımı uygundu
Yavaş internet kullanıcıları için pratik tasarım ilkeleri
- Hızlı internet ortamında küçük eksiklikler gibi görünen özellikler yavaş internette büyük engellere dönüşebilir
- Uygulamalar, tek bir sabit timeout yüzünden kullanıcının birkaç baytlık metin bile gönderemediği döngülere düşmesini engelleyecek şekilde tasarlanmalıdır
- Olası tasarım ilkeleri basittir
- Baytlar hareket ediyorsa kesme
- Büyük payload’ları parçalara böl
- Başarısız olsa bile ilerlemeyi koru
- Ağ durumunu kullanıcıya açıkça göster
- Yerleşik indirici yetersizse manuel indirme bağlantısı sun
- South Pole bir edge case’tir; ancak denizdeki gemilerde Inmarsat ortamı, dağ araştırma sahalarında Thales MissionLink ve Iridium Certus, kararsız Wi‑Fi, yanlış yapılandırılmış router’lar, düşük kaliteli WISP’ler ve eski telefon hattı tabanlı dial-up kullanıcıları da benzer kısıtlar yaşayabilir
- Geliştiricilerin her uç durumu optimize etmesi gerekmez; ancak ürünün yavaş bağlantı kullanıcılarının ilerlemesini aktif olarak engellememesini sağlamak için çaba gerekir
1 yorum
Hacker News yorumları
Bu yazı bana çok dokundu. Antarktika’da değil, Pekin’deyim ama internet yüzünden hâlâ sıkıntı çekiyorum.
Büyük Güvenlik Duvarı’nın arkasındaysanız yaratıcı yöntemler kullanmanız gerekiyor; VPN’ler de ancak ara sıra çalışıyor. Her VPN bir iz bırakıyor, güvenlik duvarının sezgisel yöntemleri ve makine öğrenimi sonunda bunu yakalıyor; devletin izin verdiği VPN’ler bile siyasi açıdan hassas dönemlerde “yumuşak” biçimde kısıtlanıyor.
Sonuçta bağlantı kursanız bile stabil olmuyor; değerli paketleri gereksiz web uygulaması/React gidiş-dönüş isteklerine harcamak çok acı verici.
Bazı geliştiricilerin hafif işler yapmayı öğrenmesi için yaklaşık 2005’e zaman yolculuğu yapıp o dönemin standartlarıyla geliştirme yapması gerekiyor gibi. Zaman yolculuğu mümkün değilse, lütfen geliştirici araçlarındaki hız sınırlamayı açıp 3G’ye ayarlayarak kendi web uygulamalarının buna dayanıp dayanmadığını kontrol etsinler.
Projeleri her zaman sınırlı bant genişliğinde test ederim. Erişilebilirlikte olduğu gibi, iyi uygulamaları izlediğinizde yalnızca kötü bağlantısı olan kullanıcılar için değil, tüm kullanıcılar için daha iyi bir kullanıcı deneyimi ortaya çıkar.
Sık kaçırılan bir başka fırsat da tek sayfa uygulamaları offline-first yapmak.
Genel fikre mutlaka karşı çıkmıyorum ama modern JavaScript, sunucu-istemci “uygulamalarında” yavaş internetle başa çıkma konusunda aslında oldukça iyi. Sadece bunu kolay yapmak zor; Google/GPT ile kod yazan birinin projesinin temeli yapabileceği çevrimiçi kaynak da neredeyse yok.
Bunun nedeni kısmen internette berbat JavaScript içeriğinin çok fazla olması, kısmen de bu şekilde çalışan kuruluşların bilgi paylaşmaması. Bizim de rakiplere bilgi vermek için bir nedenimiz olmadığından çalışma yöntemlerimize dair herkese açık materyal sayısı 0.
Her şey için gidiş-dönüş istekleri kullanılmasını bekleyen teknolojilerde gereksiz gidiş-dönüşleri azaltmak açısından ilginç bir alıştırma oluyor.
Hâlâ yaklaşık 1–10 Mbit/s alıyorum; çoğunlukla günün saatine göre değişiyor ve bağlantı sorunu neredeyse hiç yok.
Yeraltı toplu taşımada çok işe gidip gelmiş biri olarak (kesintili ve kalabalık), ayrıca Avustralya’da yaşamış ve çalışmış biri olarak, “ideal” ağ koşullarında olmayan insanlar için çoğu hizmetin berbat olduğunu rahatlıkla söyleyebilirim.
London Underground’da çoğu uygulamanın yaklaşık 2 dakikada bir kopup yeniden gelen ağı gerçekten kötü idare etmesi özellikle göze çarpıyor. İstasyonlar arasında bağlantı kopuyor; 500 yolcu taşıyan tren aynı anda bağlanmaya çalıştığı için her erişim noktasına bağlanmak da yaklaşık 15 saniye sürüyor.
Avustralya’da ise genel olarak her yerden 200 ms uzaktasınız. Önemsiz görünebilir ama hangi uygulamanın N+1 istek sorununa takıldığını çok iyi ortaya çıkarıyor.
Her zaman etkileyici olan tek uygulama WhatsApp. Yeniden bağlandıktan sonra ilk çalışan o oluyor, bağlantı kopmadan hemen önce trafiği geçirebilen son uygulama da o; gecikme olsa bile aramalar oldukça hızlı hissettiriyor.
WhatsApp gerçekten de Avustralya’ya sunucu dağıtmış nadir hizmetlerden biri olabilir. 200 ms, kıtalar arası trafik olduğuna dair güçlü bir işaret gibi görünüyor.
Çoğu küresel şirket en fazla üç bölgeye dağıtım yapıyor: ABD (us-east, us-central, us-east+us-east), Avrupa (west-europe) ve nispeten daha nadiren Uzak Doğu (us-west veya Japonya).
Bu yüzden Güney Afrika, Güney Amerika, Avustralya gibi yerler veriyi genellikle bu bölgelerden birinden almak zorunda kalıyor; fiziksel sınırlar nedeniyle en az 200 ms gecikme oluşuyor.
Avustralya özellikle ağır etkileniyor. Teorik olarak kendi yargı alanında özel bir dağıtım olsa bile gerçek sunucu çoğu zaman tamamen başka bir kıtada (ABD Batı Yakası veya Japonya) bulunuyor; kullanıcı da paketlerin dünyanın yarısını dolaşmasının performans etkisini aynen yaşıyor.
Bu bakış açısının geliştirme hedeflerine derinlemesine yerleşmiş olması, WhatsApp’ın dünyanın pek çok ülkesinde başlıca mesajlaşma uygulaması hâline gelmesi için bence yeterli bir neden oluşturdu.
Bir görüntüyü görmek için tarayıcıda .jpg URL’si açmaya çalıştığımda, termux’a geçip
wgetçalıştırmaktan çok daha uzun sürüyor ve bazen zaman aşımına düşüyor. Bunu hem Firefox’ta hem de Chrome tabanlı tarayıcılarda yaşadım.Bu arada mobil bağlantıda
wgetindirmeleri de genelde 10–30 saniye sürüyor.Berlin’in bunu neden böyle yaptığını anlamıyorum. Trenin içinde internet sağlasalar yeterdi.
Ağ sürekli koparsa internetin büyük bölümü gerçekten berbat çalışıyor.
Çok seyahat ediyorum ve yavaş internet oldukça yaygın. Şu anda bile mobil verim bittiği için 8 kbps ile sınırlandırılmış durumdayım
Sayfada sadece metin olan web sitelerinin hızlı olması gerekir, ama çoğu öyle değil. Hacker News inanılmaz hızlı, fakat Google API dokümanları hiç açılmıyor
En kötü sorun, çoğu arayüzün yavaş istekleri hesaba katmaması. Düğme bozukmuş gibi hissettiriyor; megabaytlarca veri gerektirmemesi gereken şeylerin bile yüklenmesi dakikalar sürüyor ya da başarısız oluyor. Google Maps arayüzünün tamamı bozuluyor
Geliştiricilerin yavaş internet için daha fazla tasarım ve test yapmasını isterdim. Bunun yerine, yalnızca hızlı şirket dizüstülerinde ve hızlı internette iyi çalışan veri oburu web siteleri çıkıyor
Bununla bağlantılı olarak, web siteleri işleterek geçimini sağlayan biri olarak statik site oluşturucuya geçmek, üretkenlik açısından verdiğim en iyi kararlardan biriydi. CMS gecikmesi her işe sızmak yerine, tamamen çevrimdışıyken bile metin dosyalarını çok hızlı düzenleyip çevrimiçi olunca yalnızca değişiklikleri push edebiliyorum. Oyunun kurallarını değiştirdi
Bugünlerde telefona 500 MB Google Maps önbelleği indirmenin pek bir anlamı yok gibi. Hâlâ her şeyi çekiyor ve gecikmeli olarak bir anda ortaya çıkıyor
Şu anda alan adlarımdan biri, güncel WordPress kullanmadığım için “tehlikeli” olarak işaretlenmiş durumda
Temelde gönderilen her istek bir AppEngine uygulamasına ulaşıyor; o uygulama Python kodu çalıştırıp HTML döndürüyor. Bu yüzden hızlı görünmesi gerekiyormuş gibi dursa da gerçekte öyle değil
Birleşik Krallık’tayım ve news.ycombinator.com’a ping 147 ms. CDN kullanmayıp ABD’de barındırıldığı için böyle görünüyor
Buna karşılık cloud.google.com’a ping 8 ms
Hacker News basit ve JavaScript’i az bir sayfa olsa da, bazı bölgelerdeki kullanıcılar için yavaş hissettirebilecek başka etkenler de olabilir. Simetrik 8 Gbps sunan XGS-PON fiber hattı kullanan ayrıcalıklı bir ortamda bile böyle
Buzul sahasından yeni inmiş birini otostop yaparken arabaya almıştım; onun söylediğine göre, o blog yazarı harika yazılar yazsa da görsel yüklerken zaten sınırlı olan bant genişliğini sık sık tükettiği için çevresindekilerin bir ölçüde tepkisini çekmiş
Ancak idari taraf tanıtım değerini gördüğü için öncelik verilmiş. Bunun yavaş internet tartışmasıyla iyi örtüştüğünü düşündüm
Cebinizdeki telefon gereksiz yere mümkün olan tüm bant genişliğini kullanıyor olabilir; siz 720p video izlerken ancak oynatacak kadar yetse bile, arkanızdan yükleme yapmak isteyen biri 480p bile izleyemeyebilir. Sizde arabellek olduğu için fark etmeyebilirsiniz, karşı taraf ise arabellek yeterince dolmadan vazgeçebilir
En azından son 1 saatteki trafiğin yüzde kaçının size gittiğini ve kullanılabilir bant genişliğinin bağlı kullanıcı sayısına bölünmesiyle elde edilen referans değerle karşılaştırıldığında, herkes eşit derecede ihtiyaç duysaydı payınızın yüzde kaç olacağını gösteren bir kullanım muhasebesi olmalı gibi
Daha da ileri gidilirse, “Evet, önümüzdeki [X≤24] saat boyunca kullanacağım bant genişliğini biliyorum ve gerçekten ihtiyacım var” düğmesine basılana kadar herkesi düşük öncelikte tutup, basıldığında MAC/IP adresinin QoS önceliğini normale yükselten bir sistem de mümkün görünüyor
Bu durum, yerel öncelikli uygulamalara ve çözümlere ihtiyaç olduğunu haykırıyor; internetin en başta ortaya çıkma nedeni de buydu [1][2]
İnsanlar Salesforce’un “No Software” reklam sloganına kandı; oysa bu, internetin temellerine ve ruhuna doğrudan aykırı. 1969’dan bu yana internet tarihinin büyük bölümünde Mbps istisnaydı, standart değil; ilk killer app olan e-posta mesajlaşması da (muhtemelen hâlâ en iyi internet uygulaması) yerel önceliklidir [3]
İronik olarak, yazarın yakındığı sorunlu uygulama da bir mesajlaşma uygulaması
[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...
Yıllar boyunca ağ tarafında epey iş yaptım ve kendi “yavaş internet” ortamımı çalıştırmaya zaman harcadım. McMurdo kadar ilginç değil ama uluslararası uçaklarda, ücra yerlerden geçen trenlerde, berbat kırsal otellerde, tünellerin içinde bile sohbet ettim ve YouTube videoları izledim.
Genel amaçlı bir bilişim cihazına erişiminiz varsa, elektriği de karşılayabiliyorsanız (bu tür ekipmanlar epey güç tüketir) ve kendiniz kurmaya niyetliyseniz NNCP’yi öneririm [1]. NNCP veriyi alıp parçalara bölebilir ve gönderebilir. TCP üzerinde noise kullanan bir senkronizasyon protokolü de içerir; başarısız parçaları yeniden deneyerek gönderir. TLS gerekmediği için bağlantı kurulumu yalnızca 1,5 RTT sürer.
NNCP, veriyi standart girdiden uzak bir programa besleyebilir. YouTube indirici, Slack botu, Telegram botu ve Discord botu yapıp gelen veriyi okumalarını ve ilgili servisle etkileşime geçmelerini sağladım. Yerel makinede bir Matrix (Dendrite) sunucusu ve botlar çalıştırıyorum; veriyi NNCP üzerinden uygun uzak servislere gönderiyorum.
Yol üzerindeki MTU/MSS’nin mümkün olduğunca düşük olmasını, böylece TCP seviyesinde yeniden denemelerin sık yapılabilmesini istersiniz ya da bunu denemeniz gerekir; ama bu kurulum nereye gidersem gideyim neredeyse hiç başarısız olmadı ve medya tüketimiyle sohbeti mümkün kıldı.
Uluslararası uçuşlarda en sinir bozucu nokta, NNCP uç noktalarının coğrafi olarak dağınık olmaması. Uçuş rotasına ve paketlerin uç noktaya gerçekten izlediği yola bağlı olarak gecikme ve jitter ciddi biçimde artabiliyor. Genelde varış noktasına yakın bir NNCP uç noktası bulundurmaya çalışıyorum, ama uçak içi Wi‑Fi açısından gerçek rota berbat olabiliyor. NNCP artık Yggdrasil desteğine sahip; bu bunu hafifletebilir ve MTU sorununu kontrol etmeye de yardımcı olabilir, fakat bu koşullarda Ygg kullanmış değilim.
[1]: http://www.nncpgo.org/
Güney Pasifik’teki bir teknede yazarınkine benzer bir deneyim yaşadım. Starlink vardı ama güç tüketimi yüksek olduğu için (60 W’tan fazla) sık kullanmadık. Bunun yerine yerel SIM kartlar alıp bazı yerlerde 4G, bazı yerlerde EDGE (2G) kullandık.
EDGE’in kendisi kâğıt üzerinde o kadar da kötü değil. Saniyede onlarca kilobit veriyor. Gerçekte ise çok daha kötüydü. Yüklemenin milisaniyeler değil dakikalar sürebileceği dikkate alınsaydı gayet çalışacak uygulamaların, kısa zaman aşımları yüzünden başarısız olduğunu gördüm.
Düşük bant genişliği, yüksek gecikme bağlantılar yazılımın düzenli testlerine dahil edilmeli. Linux’ta bunu mümkün kılan netem (https://wiki.linuxfoundation.org/networking/netem) var.
Anonim blog yazarının yaşamadığı bir sorun da kota/ücretli bağlantılardı. Maliyet yüzünden işletim sistemi ya da uygulama yükseltmeleri neredeyse imkânsızdı. Neyse ki birkaç haftada bir sınırsız bağlantısı olan bir yere varıp bunları yapabiliyorduk. Bunun karşılığında, çeşitli işletim sistemlerinde bağlantıyı tarifeli/tarifesiz olarak işaretlemeye, otomatik güncellemelerin hepsini kapatmaya ve kıymetli bant genişliğini korumaya çok alıştım.
Ayrıca “yerel SIM kart” deniyorsa, o SIM’i almak için adaya çıktıkları anlamına gelir; 2020’lerde nerede yalnızca 2G olduğunu merak ediyorum. Güney Pasifik’te hâlâ böyle yerler kaldığına inanmak zor.
Perspektifi korumak gerekiyor. Bazı projeler, bir web uygulamasını birden fazla tarayıcıda test etmeyi bile israf ve gerekçelendirilemeyen bir maliyet sayıp atlıyor. Test matrisine eklemek önemsiz ve yalnızca UI ile ilgili bir mesele olsa bile durum böyle.
Yavaş interneti hesaba katarak mühendislik yapmak hâlâ gerçekten önemli ve çoğu yazılım geliştiricisi tarafından ciddi biçimde hafife alınıyor diye düşünüyorum. Ancak alçak Dünya yörüngesi uydu sistemleri (Starlink, özellikle StarLink) artık temel sorunu fiilen çözdü
Eylül–Ekim 2023’te Arktik rotadan (Alaska’dan Norveç’e) geçtim; Kuzey Kutup Dairesi’nin epey kuzeyindeki bir gemide bile bulutlara, karadan uzaklığa ve buza rağmen FaceTime görüntülü görüşmesi yapabildik. Bu, yazarın Antarktika’da olduğu dönemle aynı zamandı
Kısıt her ne idiyse, sonuçta mesele hizmet sözleşmesi ve terminali sahaya götürüp kurmak. Kutup bölgeleri kapsaması görece seyrek ama nüfus aşırı az olduğundan yine de yeterli
https://satellitemap.space/
Yavaş internetin birden fazla anlamı var; bunlardan biri bağlantı sorunu. TCP gibi bağlantı odaklı protokollerde paket kaybından kaynaklanan yavaşlama, UDP gibi gönderip bırakan protokollerde ise mesajın ulaşmaması anlamına gelir. Dolayısıyla yavaşlık düşük aktarım hızı da olabilir, anlık yüksek throughput’un ardından kısa kısa kopmalar şeklinde de olabilir
Yavaş ağlarla başa çıkmak için sağlam yaklaşımlardan biri çevrimdışı mod desteğidir. Tüm veri push/pull işlemlerini asenkron transaction’lar olarak tasarlayıp, veri push’unu yerelde cache’leyerek mümkün olduğunda yeniden denemek. Bu da sürüm yönetimi ve çakışma çözümü gibi ek gereksinimler doğurur
Doğal olarak UI gereksinimleri de artar. Manuel senkronizasyon/yenileme, ağ durumu göstergesi, ağ kesildiğinde anlamsız işlemleri devre dışı bırakma, çevrimdışıyken de kullanılabilmesi için önceden yükleme gibi şeyler gerekir
Bir gün yavaş internet sonrasındaki dünyada yaşamak isterim ama buna daha yıllar var. Bu arada XS, o dönemin Qualcomm amiral gemilerine göre daha zayıf olduğu bilinen Intel modem kullanıyordu
Dünyanın nüfus yoğunluğu en yüksek yerlerinden birinde yaşıyorum; ortalık 5G antenleri ve Wi‑Fi istasyonlarıyla dolu ama özensiz yapılmış web sitelerinin yavaş veya kesintili bağlantıda devrildiğini hâlâ hissediyorum
Jeostatik uydular Pole’dan bakıldığında ufka çok yakın kaldığı için kutup kapsaması sınırlı. Pole, yakıtı az ve yörünge eğimi nispeten yüksek eski jeostatik uydular kullanıyor; bu yüzden 24 saatin yalnızca yaklaşık 6 saatinde iletişim kurabiliyor
Program: https://www.usap.gov/technology/1935/
Hükümetler sansürsüz web’i ya da bir ABD şirketinin internet geçidi olmasını istemeyecektir. Kendi topraklarındaki mevcut ağları koruyacaklar ve hız sorunu geçerliliğini sürdürecek
Ayrıca dünya genelinde internete erişim aracı yalnızca eski yazılımlı ve sınırlı CPU’lu 100 dolarlık Android telefonlar olan insanların sayısını da hesaba katmak gerekiyor
Yavaş ağlarda kullanıcı deneyimini iyileştirebilecek, verimli durum senkronizasyonu için HTTP’yi genişleten bir IETF taslak önerisi var: https://news.ycombinator.com/item?id=40480016
Braid Protocol, birden fazla senkronizasyon algoritmasının ortak bir ağ protokolü üzerinde birlikte çalışmasını sağlar; herhangi bir senkronizer’ın ağ mesajları bunun üzerine dönüştürülebilir. Mevcut Braid spesifikasyonu HTTP’ye iki senkronizasyon boyutu ekliyor
Level 0: Günümüzdeki HTTP
Level 1: push güncellemeleri olan abonelik
Level 2: P2P tutarlılık (patch’ler, sürümler, merge)
Günümüzde senkronizer’lar farklı protokoller kullanıyor ama ağ mesajları aynı türden bilgileri taşıyor: zamandaki sürüm, uzaydaki konum ve bir zaman aralığı boyunca uzaysal bölge patch’i. Rastgele bir patch kümesinin bileşimi, braid denen matematiksel bir yapı oluşturur. Zaman içinde uzayın dallanması, birleşmesi ve yeniden sıralanmasıdır
Umut bitmez
Gidiş-dönüş isteklerini azaltmak ve daha az şişkin şeyler yapmak zor değil; hatta çok daha kolay. Şişkinlik bambaşka nedenlerle var
Bazen veri merkezine yakın hızlı internet ve bol kaynaklı makinelerde şişkinlik göze batmaz. Kolayca simüle edilebilir ama şirketin bunu umursaması gerekir. Genelde reklam teknolojisi ve çevresi küçük kullanıcı gruplarıyla pek ilgilenmez. Aslında son kullanıcıları önemsemelerinin tek nedeni de onların gerçek müşterilere, yani reklamverenlere gelir üretmesidir
Uygulama, web sitesi vb. yapan bizler, kullandığımız hızlı Wi‑Fi’a ya da fiber hatta bağlı olmayan pek çok insan olduğunu unutmamalıyız
Birleşik Krallık’ta bazı operatörler 3G’yi kapatmaya başladı. Bazıları düşük güçte bir yedek olarak 2G’yi bırakıyor ama artık 4G/5G kullanın yaklaşımındalar. Sorun şu ki 4G hâlâ her yerde yok ve yakın zamana kadar bazı bölgelerde yalnızca 3G sinyali makuldü
Bu yüzden istemeden 2G/EDGE’e düşmek daha sık yaşanıyor ve birçok şey sadece duruyor. Birçok uygulama yavaş, yüksek gecikmeli ve paket kaybı yüksek senaryolarda test edilmiyor
2G’de Google Maps ile yol tarifi almayı deneyin, cevabı görürsünüz :(