İnterneti daha hızlı hissettirmek için sessiz plan

Birkaç ay önce, 900Mbps planından 200Mbps’ye geçerek internetimi düşürdüm. Şimdi, web sitelerinin yüklenmesinin bazen acı verici derecede uzun sürebileceğini, HD YouTube videolarının içinde zıpladığımda durması ve arabelleğe alınması gerektiğini ve video görüşmelerinin can sıkıcı derecede dalgalı olabileceğini görüyorum.

Başka bir deyişle, hemen hemen hiçbir şey değişmedi. Gigabit’e yakın indirme hizmetim olduğunda bile aynı sorunları yaşadım ve muhtemelen yalnız değilim. Eminim birçoğunuz yavaş yüklenen bir web sitesini lanetleme ve bir “hız testi” internetinizin aynı anda düzinelerce 4K Netflix akışını oynatabilmesi gerektiğini söylediğinde kafanız daha da karışmıştır. Peki ne veriyor?

Her konuda olduğu gibi, oyunda birçok faktör var. Ancak bunlardan en önemlisi gecikme süresi veya cihazınızın bir sunucuya veri göndermesi ve verileri geri alması için geçen süredir – paketleriniz (ağ üzerinden dolaşan küçük veri demetleri) bir yerde sıkışıp kalıyorsa ne kadar bant genişliğine sahip olduğunuz önemli değildir. Ancak insanlar, bir “ping” metriği de dahil olmak üzere popüler hız testleri sayesinde gecikmenin nasıl çalıştığı hakkında bir fikre sahip olsa da, bunu ölçmenin yaygın yöntemleri her zaman tam bir resim sağlamamıştır.

İyi haber şu ki, gecikmeyi neredeyse ortadan kaldırmak için bir plan var ve Apple, Google, Comcast, Charter, Nvidia, Valve, Nokia, Ericsson, T-Mobile ana şirketi Deutsche Telekom ve daha fazlası gibi büyük şirketler ilgi gösterdi. Bu, Ocak ayında kesinleşen ve yayınlanan L4S adlı yeni bir internet standardıdır ve web sayfalarının veya akışların yüklenmesini beklemek ve video görüşmelerindeki aksaklıkları azaltmak için harcadığımız zamana ciddi bir zarar verebilir. Ayrıca, internet hızı hakkındaki düşüncelerimizi değiştirmeye ve geliştiricilerin internetin mevcut gerçekleriyle mümkün olmayan uygulamalar oluşturmasına yardımcı olabilir.

L4S hakkında konuşmadan önce, yine de biraz koymalıyız temel.

Bunun birçok olası nedeni var. İnternet, cihazınızı bir sunucuya (veya genellikle birden çok sunucuya) bir yere bağlayan birbirine bağlı yönlendiriciler, anahtarlar, fiberler ve daha fazlasından oluşan geniş bir tüp serisidir. Bu yolun herhangi bir noktasında bir darboğaz varsa, sörf deneyiminiz zarar görebilir. Ve birçok potansiyel darboğaz var – izlemek istediğiniz videoyu barındıran sunucunun yükleme kapasitesi sınırlı olabilir, internet altyapısının hayati bir parçası kapalı olabilir, bu da verilerin size ulaşmak için daha fazla seyahat etmesi gerektiği anlamına gelir, bilgisayarınız verileri işlemekte zorlanıyor olabilir, vb.

Asıl önemli olan, zincirdeki en düşük kapasiteli halkanın mümkün olanın sınırlarını belirlemesidir. 8Gbps bağlantı ile hayal edilebilecek en hızlı sunucuya bağlanabilirsiniz ve yönlendiriciniz bir seferde yalnızca 10Mbps veri işleyebiliyorsa, bununla sınırlı kalacaksınız. Oh, ve ayrıca, her gecikme toplanır, bu nedenle bilgisayarınız 20 milisaniye gecikme eklerse ve yönlendiriciniz 50 milisaniye gecikme eklerse, bir şeyin olması için en az 70 milisaniye beklersiniz. (Bunlar tamamen keyfi örneklerdir, ancak siz anladınız.)

Son yıllarda, ağ mühendisleri ve araştırmacıları, ağ ekipmanının boğulmamasını sağlamak için kullanılan trafik yönetim sistemlerinin aslında işleri nasıl yavaşlatabileceği konusunda endişelerini dile getirmeye başladılar. Sorunun bir kısmı “tampon şişkinliği” olarak adlandırılan şeydir.

Sağ? Ancak tampon şişkinliğinin gerçekte ne olduğunu anlamak için önce tamponların ne olduğunu anlamamız gerekir. Daha önce de değindiğimiz gibi, ağ oluşturma biraz danstır; Ağın her parçasının (anahtarlar, yönlendiriciler, modemler vb.) ne kadar veriyi işleyebileceği konusunda kendi sınırı vardır. Ancak ağdaki cihazlar ve ne kadar trafikle uğraşmak zorunda oldukları sürekli değiştiğinden, telefonlarımızın veya bilgisayarlarımızın hiçbiri bir seferde ne kadar veri göndereceğini bilmiyor.

Bunu anlamak için, genellikle tek bir hızda veri göndermeye başlarlar. Her şey yolunda giderse, bir şeyler ters gidene kadar tekrar tekrar artıracaklar. Geleneksel olarak, yanlış giden şey paketlerin düşürülmesidir; bir yerdeki bir yönlendirici, verileri gönderebileceğinden daha hızlı alır ve “Oh hayır, şu anda bununla başa çıkamam” der ve ondan kurtulur. Çok ilişkilendirilebilir.

Paketlerin bırakılması genellikle veri kaybına neden olmasa da – bilgisayarların gerekirse bu paketleri tekrar gönderecek kadar akıllı olduğundan emin olduk – yine de kesinlikle ideal değil. Böylece gönderen, paketlerin bırakıldığı mesajını alır ve son birkaç milisaniye içinde işlerin değişmesi durumunda hemen tekrar yükselmeden önce veri hızlarını geçici olarak ölçeklendirir.

Bunun nedeni, bazen paketlerin düşmesine neden olan aşırı veri yüklemesinin geçici olmasıdır; belki ağınızdaki biri Discord’da bir resim göndermeye çalışıyordur ve yönlendiriciniz bu gerçekleşene kadar bekletebilirse, görüntülü görüşmenize sorunsuz bir şekilde devam edebilirsiniz. Bu aynı zamanda birçok ağ ekipmanının yerleşik arabelleklere sahip olmasının nedenlerinden biridir. Bir cihaz aynı anda çok fazla paket alırsa, bunları geçici olarak depolayabilir ve gönderilmek üzere sıraya koyabilir. Bu, sistemlerin büyük miktarda veriyi işlemesine olanak tanır ve aksi takdirde sorunlara neden olabilecek trafik artışlarını yumuşatır.

Öyle! Ancak bazı insanların endişelendiği sorun, işlerin sorunsuz yürümesini sağlamak için tamponların gerçekten büyük olmasıdır. Bu, paketlerin yolculuklarına devam etmeden önce (bazen gerçek) bir saniye sırada beklemeleri gerekebileceği anlamına gelir. Bazı trafik türleri için bu önemli değil; YouTube ve Netflix’in cihazınızda da arabellekleri vardır, bu nedenle şu anda bir sonraki video parçasına ihtiyacınız yoktur. Ancak bir video görüşmesindeyseniz veya GeForce Now gibi bir oyun akışı hizmeti kullanıyorsanız, bir arabelleğin (veya zincirdeki birkaç arabelleğin) neden olduğu gecikme aslında gerçek bir sorun olabilir.

Şu anda bununla başa çıkmanın bazı yolları var ve geçmişte hem verime (veya ne kadar veri aktarıldığına) hem de daha düşük gecikme süresine yönelik bir gözle tıkanıklığı kontrol eden algoritmalar yazmak için epeyce girişimde bulunuldu. Ancak birçoğu, yaygın olarak kullanılan tıkanıklık kontrol sistemleriyle tam olarak iyi oynamıyor, bu da onları internetin bazı bölümleri için kullanıma sunmanın diğer bölümlere zarar vereceği anlamına gelebilir.

Bu, internet servis sağlayıcısının veya ISS’nin pazarlamasının hilesidir. Kullanıcılar “daha hızlı” internet istediklerini söylediklerinde, kastettikleri şey, bir şey istedikleri andan aldıkları zamana kadar daha az zaman olmasını istedikleridir. Bununla birlikte, internet sağlayıcıları bağlantıları kapasiteye göre satar: bir kerede ne kadar veriyi geri çekebilirsiniz?

Kapasite eklemenin, beklemek için harcadığınız süreyi gerçekten azalttığı bir zaman vardı.

Tamamen yasal bir web sitesinden dokuz megabaytlık bir MP3 dosyası indiriyorsanız, saniyede 56 kilobit çevirmeli bağlantıda uzun zaman alacaktır – yaklaşık 21 buçuk dakika. Son derece hızlı 10 Mbps bağlantıya yükseltin ve şarkıya 10 saniyeden daha kısa sürede sahip olun.

Ancak veri aktarımı için gereken süre, verim arttıkça giderek daha az fark edilir hale gelir; 100 Mbps’de 0,72 saniye süren bir şarkı indirme ile 250 Mbps’de 0,288 saniye süren bir şarkı indirme arasındaki farkı, teknik olarak yarısından daha az olmasına rağmen fark etmezsiniz. (Ayrıca, gerçekte, bundan daha uzun sürer çünkü bir şarkıyı indirme işlemi

sadece verilerin aktarılmasını içermez). Daha büyük dosyalar indirirken sayılar biraz daha önemlidir, ancak yine de bir noktada azalan getirilere ulaşırsınız; 4K bir filmi izleyebileceğinizden 30 kat daha hızlı izlemek ile izleyebileceğinizden beş kat daha hızlı izlemek arasındaki fark özellikle önemli değildir.

İnternet “hızımız” arasındaki kopukluk (genellikle insanların bahsettiği şey verimdir – soru, teslimat kamyonunun ne kadar hızlı gittiği ve yolculukta ne kadar taşıyabileceği hakkında daha azdır) ve bu yüksek bant genişliğine sahip bağlantıları nasıl deneyimlediğimiz arasındaki kopukluk, basit web sayfalarının yüklenmesi yavaş olduğunda ortaya çıkar; Teorik olarak, metin, resim ve JavaScript’i yıldırım hızlarında yükleyebilmeliyiz. Bununla birlikte, bir web sayfasını yüklemek, cihazlarımız ve sunucularımız arasında birkaç tur ileri geri iletişim anlamına gelir, bu nedenle gecikme sorunları çoğalır. 25 milisaniye boyunca takılan paketler, yolculuğu 10 veya 20 kez yapmak zorunda kaldıklarında gerçekten toplanabilir. İnternet bağlantımız aracılığıyla bir kerede taşıyabileceğimiz veri miktarı darboğaz değil – paketlerimizin cihazlar arasında geçiş yapmak için harcadığı zamandır. Bu nedenle, daha fazla kapasite eklemek yardımcı olmayacaktır.

L4S, Düşük Gecikme, Düşük Kayıp, Ölçeklenebilir Verim anlamına gelir ve amacı, kuyruk ihtiyacını azaltarak paketlerinizin gereksiz yere sırada beklerken mümkün olduğunca az zaman harcamasını sağlamaktır. Bunu yapmak için, gecikme geri bildirim döngüsünü kısaltmaya çalışır; tıkanıklık olmaya başladığında, L4S, cihazlarınızın bunu neredeyse anında öğrendiği ve sorunu çözmek için bir şeyler yapmaya başlayabileceği anlamına gelir. Genellikle bu, ne kadar veri gönderdikleri konusunda biraz geri adım atmak anlamına gelir.

Daha önce ele aldığımız gibi, cihazlarımız sürekli olarak hızlanıyor, sonra yavaşlıyor ve bu döngüyü tekrarlıyor çünkü ağdaki bağlantıların uğraşması gereken veri miktarı sürekli değişiyor. Ancak paketlerin düşmesi, özellikle arabellekler denklemin bir parçası olduğunda harika bir sinyal değildir – cihazınız çok fazla veri gönderene kadar çok fazla veri gönderdiğini fark etmeyecektir, bu da sert bir şekilde sıkıştırması gerektiği anlamına gelir.

/div

p

h3

/em

a href=\”https://datatracker.ietf.org/doc/rfc9330/\”/a/p/divdiv class=\”duet–article–article-body-component clear-both block md:float-left md:mr-30 md:w-[320px] lg:-ml-100\”

div class=\”duet–article–article–pullquote mb-20\”

/div

p

h3

/div

div class=\”duet–article–article-body-component\”

p class=\”duet–article–dangerously-set-cms-markup duet–article–standard-paragraph mb-20 font-fkroman text-18 leading-160 -tracking-1 selection:bg-franklin-20 dark:text-white dark:selection:bg-blurple [&_a:hover]:shadow-highlight-franklin dark:[&_a:hover]:shadow-highlight-blurple [&_a]:shadow-underline-black dark:[&_a]:shadow-underline-white\”

/div

div class=\”duet–article–article-body-component\”

p class=\”duet–article–dangerously-set-cms-markup duet–article–standard-paragraph mb-20 font-fkroman text-18 leading-160 -tracking-1 seçim:bg-franklin-20 dark:text-white dark:selection:bg-blurple [&_a:hover]:shadow-highlight-franklin dark:[&_a:hover]:shadow-highlight-blurple [&_a]:shadow-underline-black dark:[&_a]:shadow-underline-white\”

/em

a href=\”https://www.cablelabs.com/blog/l4s-interop-lays-groundwork-for-10g-metaverse\”/a/p/divp

h3

/em

/p/divdiv class=\”duet–article–article-body-component\”

p class=\”duet–article–dangerously-set-cms-markup duet–article–standard-paragraph mb-20 font-fkroman text-18 leading-160 -tracking-1 selection:bg-franklin-20 dark:text-white dark:selection:bg-blurple [&_a:hover]:shadow-highlight-franklin dark:[&_a:hover]:shadow-highlight-blurple [&_a]:shadow-underline-black dark:[&_a]:shadow-underline-white\”

/div

div class=\”duet–article–article-body-component\”

p class=\”duet–article–dangerously-set-cms-markup duet–article–standard-paragraph mb-20 font-fkroman text-18 leading-160 -tracking-1 selection:bg-franklin-20 dark:text-white dark:selection:bg-blurple [&_a:hover]:shadow-highlight-franklin dark:[&_a:hover]:shadow-highlight-blurple [&_a]:shadow-underline-black dark:[&_a]:shadow-underline-white\”

/em

/p/divp

h3

/a

/p/divdiv class=\”duet–article–article-body-component\”

p class=\”duet–article–dangerously-set-cms-markup duet–article–standard-paragraph mb-20 font-fkroman text-18 leading-160 -tracking-1 selection:bg-franklin-20 dark:text-white dark:selection:bg-blurple [&_a:hover]:shadow-highlight-franklin dark:[&_a:hover]:shadow-highlight-blurple [&_a]:shadow-underline-black dark:[&_a]:shadow-underline-white\”

/a

/p/divdiv class=\”düet–article–article-body-component\”

p class=\”duet–article–dangerously-set-cms-markup duet–article–standard-paragraph mb-20 font-fkroman text-18 leading-160 -tracking-1 seçim:bg-franklin-20 dark:text-white dark:selection:bg-blurple [&_a:hover]:shadow-highlight-franklin dark:[&_a:hover]:shadow-highlight-blurple [&_a]:shadow-underline-black dark:[&_a]:shadow-underline-white\”

/a

a href=\”https://developer.apple.com/videos/play/wwdc2023/10004/?time=546\”/aa href=\”https://developer.apple.com/documentation/network/testing_and_debugging_l4s_in_your_app/\”/a/p/divdiv class=\”duet–article–article-body-component clear-both block\”>

p

Comcast’in teknoloji politikası, ürün ve standartlardan sorumlu başkan yardımcısı Jason Livingood’a göre (ve

tweet’leri L4S’yi

L4S’yi kullanmak için onu destekleyen bir işletim sistemine, yönlendiriciye ve sunucuya ihtiyacınız vardır

Yine de, bir sonraki Zoom görüşmenizin neredeyse gecikmesiz olabilmesi için yapılması gereken çok iş var. Ağdaki her atlamanın bir fark yaratması için L4S’yi desteklemesi gerekmez, ancak genellikle darboğazlar olanlardır. (White, ABD’de bunun genellikle Wi-Fi yönlendiriciniz veya “erişim ağınızdaki”, yani ISS’nize bağlanmak için kullandığınız ve ISS’nizin diğer herkese bağlanmak için kullandığı ekipman anlamına geldiğini söylüyor.) Diğer tarafta da önemlidir; Bağlandığınız sunucuların da bunu desteklemesi gerekir.

Çoğunlukla, bireysel uygulamaların, özellikle ağ ayrıntılarıyla uğraşma görevini cihazınızın işletim sistemine devretmeleri durumunda, onu desteklemek için çok fazla değişiklik yapması gerekmemelidir. (Bu, işletim sisteminizin L4S’yi de desteklediğini varsayar, bu da henüz herkes için geçerli değildir.) Bununla birlikte, maksimum performans elde edebilmek için kendi ağ kodlarını yazan şirketler, muhtemelen L4S’yi desteklemek için yeniden yazmak zorunda kalacaklardı – ancak, onunla mümkün olan kazanımlar göz önüne alındığında, muhtemelen yapmaya değer olacaktır.

Tabii ki, meyve vermeyen başka umut verici teknolojiler gördük ve geliştirme yaşam döngüsünün başlarında var olabilecek tavuk ve yumurta senaryosunun üstesinden gelmek zor olabilir. Ağ operatörleri, hiçbir internet trafiği kullanmadığında neden L4S’yi desteklemek için çaba sarf etsin? Ve hiçbir ağ operatörü bunu desteklemiyorsa, bu trafiği oluşturan uygulamalar ve hizmetler neden bunu uygulama zahmetine girsin?

a:hover]:shadow-highlight-franklin dark:[&>a:hover]:shadow-highlight-franklin [&>a]:shadow-underline-black dark:[&>a]:shadow-underline-white\”>L4S’nin internetimi daha iyi hale getirip getirmeyeceğini nasıl anlarım?

Neyse ki, bazı hız testi uygulamaları bu verileri göstermeye başlıyor. Mayıs 2022’de Ookla, internetinizin ne kadar hızlı olduğunu görmek için en popüler araçlardan biri olan Speedtest’e gecikmeye daha gerçekçi bir genel bakış

(Çevirmeli bağlantı kullanan herkesi bana ne kadar yumuşak olduğumu söylemeye ve her web sitesinin yüklenmesinin 10 saniye sürdüğü günleri hatırlamaya davet ediyorum, her iki yönde de karda yokuş yukarı.)

İnternette bir seferde yalnızca bir şey yaparsanız ve neredeyse hiç kimsenin kullanmadığı siteleri kullanırsanız, o zaman belki de L4S nihayet geldiğinde sizin için fazla bir şey yapmaz. Ama bu gerçekçi bir senaryo değil. Teknolojiyi, herkesle aynı siteleri ziyaret etmek için kullandığımız, giderek daha yoğun hale gelen ev ağlarımıza getirebilirsek, web’in kullanıcı deneyiminde sessiz bir devrim olma ihtimali var. Ve çoğu insan buna sahip olduğunda, insanlar ultra düşük gecikme süresi olmadan var olamayacak uygulamalar geliştirmeye başlayabilir.