NAT geçişi, bir eşler arası uygulamanın, her biri bir ev ya da ofis yönlendiricisinin ardında bulunan iki cihaz arasında doğrudan bağlantı kurmak için kullandığı teknikler bütünüdür. Yönlendiriciler birçok özel IP adresini tek bir genel IP'ye çevirdiği için (Ağ Adresi Çevirisi, yani NAT), gelen bağlantılar varsayılan olarak engellenir. NAT geçişi — başlıca ICE, STUN ve TURN — her cihazın dışa dönük adresini keşfeder, her iki yönlendiriciden geçici bir yol açar ve yalnızca doğrudan delik açma başarısız olursa bir aktarıcı sunucuya düşer.

STUN nasıl çalışır?

STUN (NAT için Oturum Geçişi Araçları) küçük bir istek-yanıt protokolüdür. İstemci genel bir STUN sunucusuna UDP paketi gönderir ve sunucu, tel üzerinde gerçekten gördüğü kaynak IP'yi ve bağlantı noktasını yanıtlar — bu, genel İnternet'in gördüğü haliyle istemcinin NAT tarafından çevrilmiş adresidir. İstemci daha sonra bu adresi bir sinyalleşme kanalı üzerinden karşı tarafa duyurur, böylece karşı taraf paketleri nereye göndereceğini bilir. STUN'ün kendisi bağlantı kurulumu sırasında yaklaşık bir gidiş-dönüş gecikme ekler, sonrasında sıfır yük getirir.

STUN ile TURN arasındaki fark nedir?

STUN yalnızca her tarafa kendi genel adresini söyler ve böylece doğrudan bağlantı denenebilir. TURN ise doğrudan bağlantı kurulamadığında medyayı bulutta bir sunucu üzerinden aktarır. STUN neredeyse hiç gecikme ya da bant genişliği maliyeti eklemez; TURN bir sıçrama ekler, bölgesel bir aktarıcı için kabaca 30 ila 80 milisaniye gecikmeye mal olur ve sunucu tarafında bant genişliği tüketir. İyi tasarlanmış bir P2P uygulaması önce STUN'ü kullanır ve yalnızca gerektiğinde TURN'e düşer.

Uzak masaüstüm neden bir aktarıcıya düşüyor?

Doğrudan eşler arası delik açma, uçlardan biri ya da her ikisi simetrik NAT, operatör düzeyi NAT (hücresel ağlarda yaygın) ya da gerekli UDP akışını engelleyen katı bir kurumsal güvenlik duvarının ardındaysa başarısız olur. Bu durumlarda uygulama, bağlantının yine de çalışması için bir TURN aktarıcıya düşer. Oturum uçtan uca şifreli kalır — aktarıcı yalnızca anlamsız şifreli veriler görür — ama bölgesel bir aktarıcı için 30 ila 80 milisaniye, bölgeler arası için 200 milisaniyeye kadar gecikme ekler.

ICE (Etkileşimli Bağlantı Kurulumu), tüm adres keşfi tekniklerini birleştiren ve bunları paralel deneyen çerçevedir. Her taraf aday adreslerin bir listesini toplar — yerel ağ (host), STUN ile genel (sunucu yansımalı) ve TURN aktarmalı — ardından listeyi karşı tarafla paylaşır. İki yığın her aday çifti boyunca aynı anda yoklama paketleri gönderir ve başarılı olan ilk çift kazanır. Daha yüksek öncelikli adaylar (önce host, sonra sunucu yansımalı, sonra aktarıcı) tercih edilir; böylece mümkün olduğunda en düşük gecikmeli yol seçilir.

IPv6, NAT geçişi ihtiyacını ortadan kaldırır mı?

Büyük ölçüde evet — IPv6 her cihaza yönlendirilebilir bir genel adres verir, bu yüzden IPv6 destekli iki taraf çeviri olmadan doğrudan bağlanabilir. Ancak 2026'da ev ve mobil ağların büyük bir kısmı hâlâ yalnızca IPv4 ya da çift yığınlı ve birçok güvenlik duvarı gelen IPv6'yı varsayılan olarak engelliyor. Bu yüzden NAT geçişi hâlâ yedek olarak gerekli; üretimdeki uygulamaların çoğu hem IPv4 hem IPv6 adaylarını toplar ve ICE'ın en hızlı bağlanan yolu seçmesine izin verir.

NAT Geçişi Açıklandı: Yönlendiricinizin Ötesinde P2P

Tek bir genel IP'niz ve yönlendiricinizin arkasında bir düzine cihazınız var. iPad'iniz hücresel ağda, üç ağ ötede. Yine de bir uzak masaüstü uygulaması, genellikle araya hiçbir aktarıcı girmeden, bir saniyeden kısa sürede birinden diğerine doğrudan bağlantı açıyor. Bu sihrin gerçekte nasıl çalıştığı: ICE, STUN, TURN, delik açma ve simetrik NAT'ın can sıkıcı gerçeği.

Bu neden önemli

Bir salı sabahını düşünün. Mac mini'niz evde, tek bir genel IPv4 adresine sahip bir yönlendiricinin arkasında. iPad'iniz trende, kendi adres çevirisi katmanları olan bir operatörün mobil ağında. İki cihaz arasında en az iki, muhtemelen üç NAT var. İkisine de varsayılan olarak dış İnternet'ten erişilemiyor.

Yine de iPad'de Remio'yu açıp Mac'e dokunuyorsunuz ve bir saniye sonra masaüstünüze bakıyorsunuz. Video ve girdi iki cihaz arasında doğrudan akıyor — ekranınızı yeniden kodlayan bir bulut aktarıcısı ya da aradaki bir vekil sunucu yok.

Bunu mümkün kılan tekniğin bir adı var — NAT geçişi — ve arkasında iyi tanımlanmış bir protokol ailesi: STUN, TURN ve ICE. Bunlar WebRTC'nin tarayıcı görüntülü görüşmelerinde kullandığı protokollerle aynı; modern her P2P uzak masaüstünün ekran karelerinizi üçüncü bir tarafın veri merkezinden geçirmek zorunda kalmamasının nedeni de bunlar. Bu yazı her birinin ne yaptığını, neden var olduğunu ve yönlendiricilerin ardına saklanmış iki cihaz arasındaki en düşük gecikmeli yolu bulmak için nasıl birleştiklerini anlatıyor.

60 saniyede NAT sorunu

İnternet, her cihazın kendine ait, genel olarak yönlendirilebilir bir adresi olacak şekilde tasarlandı. Tüm uzayda yaklaşık 4,3 milyar IPv4 adresi var — 1981'de bol, 1990'ların sonunda ise açıkça yetersiz.

Çözüm Ağ Adresi Çevirisi (NAT) oldu. Yönlendiriciniz ISS'nizden tek bir genel IPv4 adresi alır. Evinizin içinde her cihaz, ayrılmış bir aralıktan (genellikle 192.168.x.x ya da 10.x.x.x) özel bir adres alır. Dizüstünüz bir paket gönderdiğinde yönlendirici kaynak adresi kendi genel IP'siyle değiştirir, eşlemeyi hatırlar ve iletir. Yanıt geri geldiğinde yönlendirici eşlemeyi bulur ve hedefi tekrar dizüstünüze çevirir.

Gelen bağlantıların varsayılan olarak çalışmamasının nedeni tam olarak budur. Dışarıdan bakıldığında dizüstünüzün adresi yoktur; yalnızca yönlendiricinin vardır. Bir yabancının yonlendiricinizin-genel-ip'si:5060 adresine gönderdiği paket, bunun için eşlemesi olmayan bir yönlendiriciye çarpar ve düşürülür.

Bir P2P uygulaması için bütün oyun budur. İki taraf da yalnızca önce dışarı doğru bir şey gönderdiklerini hatırladıklarında paket ileten yönlendiricilerin ardındadır. Hiçbir taraf diğerini öylece "arayamaz" — geçici bir yol açmak için yönlendiricileriyle iş birliği yapmak zorundadırlar.

Delik açma: güvenlik duvarına sizi geri aldırmak

İşte numara. Yönlendiricinizin NAT tablosu beşli bir anahtarla çalışır: kaynak IP, kaynak bağlantı noktası, hedef IP, hedef bağlantı noktası ve protokol. Cihazınız 1.2.3.4:5678 adresine giden bir UDP paketi gönderdiğinde yönlendirici, "1.2.3.4:5678 adresinden genel IP'mdeki X bağlantı noktasına bir UDP paketi gelirse, onu bu cihaza Y bağlantı noktasından ilet" diyen geçici bir kayıt oluşturur.

Bu kayıt bir süre — genellikle 30 ila 60 saniye — var olur, sonra bir şey onu yenilemezse sona erer. Bu pencere sırasında hedef adresten gelen her paket kabul edilir.

P2P uygulamalarının kullandığı anahtar deliği budur. İki taraf da birbirinin genel adresini biliyorsa her biri aynı anda diğerine tek bir giden UDP paketi gönderebilir. Her tarafın yönlendiricisi bir giden eşleme açar. Her tarafın ilk paketi büyük olasılıkla düşer — diğer yönlendirici eşlemesini henüz açmamıştır — ama ikinci paketin gidecek bir yeri vardır. O andan itibaren iki yönlendirici de normal bir giden konuşmayı ilettiğini sanır ve iki cihaz doğrudan konuşur.

Buna UDP delik açma denir. Hafif bir mucize, iyi belgelenmiş (RFC 5128) ve sahadaki tüketici NAT'larının büyük çoğunluğunda çalışıyor. Kalan durumlar — simetrik NAT, CGNAT, kurumsal güvenlik duvarları — TURN'ün var olmasının nedeni.

Delik açma bir hile değildir. NAT'ın etrafında tasarlandığı açık sözleşmedir: giden paket, gelen izni oluşturur. P2P uygulamaları yalnızca giden paketi bilerek gönderir.

STUN: "genel adresim ne?"

Delik açmanın tek bir ön koşulu var: her tarafın, diğer tarafa paketleri nereye göndereceğini söyleyebilmesi için kendi dışa dönük adresini bilmesi gerekir. Bu adres cihazın içinden görünmez. iPad'iniz yerel Wi-Fi adresini (192.168.1.42) görür. Yönlendirici paketi yeniden yazdıktan sonra İnternet'in geri kalanının gördüğü ise tamamen farklı bir şeydir.

STUN — NAT için Oturum Geçişi Araçları, RFC 5389 — bunu çözen küçük bir protokoldür. Akış neredeyse utanç verici derecede basit:

Taraf, genel bir STUN sunucusuna UDP paketi gönderir. (Remio yedeklilik için hem Cloudflare'ın hem Google'ın genel STUN sunucularını kullanır.)
STUN sunucusu kaynak IP'yi ve bağlantı noktasını tel üzerinden okur — bu, tanım gereği tarafın NAT tarafından çevrilmiş genel adresidir.
STUN sunucusu bu adresi yük olarak yanıtlar: "Benim görebildiğim kadarıyla siz 203.0.113.42:48291 adresindesiniz."
Taraf artık diğer tarafa hangi adresi duyuracağını bilir.

Bu dışa dönük adrese ICE terminolojisinde sunucu yansımalı aday denir. Neredeyse hiçbir şeye mal olmaz — bağlantı kurulumunda bir gidiş-dönüş ve bağlantı kurulduktan sonra sıfır bant genişliği ya da gecikme yükü. STUN'ün tek işi iki tarafı birbiriyle tanıştırmaktır; konuşmaya başladıktan sonra STUN sunucusunun başka bir rolü yoktur.

TURN: delik açma başarısız olduğunda

Delik açma NAT'ların çoğunda çalışır, ama hepsinde değil. Başarısızlık durumları gerçektir ve bunların var olmadığını varsayan bir P2P uygulaması, kullanıcıların anlamlı bir kısmı için bağlanamayacaktır.

Başlıca kötüler:

Simetrik NAT. Her farklı hedef için farklı bir genel bağlantı noktası atayan NAT. STUN, karşı tarafa 48291 numaralı bağlantı noktasında olduğunuzu söyler (STUN sunucusunun gördüğü bağlantı noktası olduğu için), ama karşı tarafın adresine paket gönderdiğinizde yönlendiriciniz farklı bir bağlantı noktası seçer — diyelim 48317. Karşı tarafın yönlendiricisi paketi, beklenmedik bir bağlantı noktasından geldiği için reddeder. Delik açma çöker.
Operatör düzeyinde NAT (CGNAT). Hücresel ve birçok ISS ağı, operatör düzeyinde ikinci bir NAT katmanı ekler. Farkında olmadan iki NAT'ın ardında olabilirsiniz ve ikisinin de iş birliği yapması gerekir. CGNAT çoğu zaman simetriktir ve ona yönetici erişiminiz yoktur.
Kısıtlayıcı kurumsal güvenlik duvarları. Bazı kurumsal ağlar tüm giden UDP'yi engeller ya da yalnızca belirli hedeflere izin verir. Delik açmanın bir UDP yoluna ihtiyacı vardır; yoksa şansı yoktur.

Bu durumlar için yedek TURN'dür — NAT etrafında aktarıcılarla geçiş, RFC 5766. TURN sunucusu, her zaman gelen trafiği kabul eden bir genel adresi olduğu için iki tarafın da ulaşabildiği bir aktarıcıdır. Her taraf TURN sunucusuna normal bir giden TLS bağlantısı kurar (herhangi bir NAT buna izin verir) ve sunucu iki taraf arasında baytları iletir.

TURN'ün gerçek bir maliyeti var. Her video paketinin fazladan bir ağ sıçramasından geçmesi gerekir. Bölgesel bir TURN aktarıcısında bu yaklaşık 30 ila 80 milisaniyelik gidiş-dönüş gecikmesi ekler. Bölgeler arası — diyelim Tokyo'daki bir taraf ve São Paulo'daki bir taraf için Frankfurt'taki bir aktarıcı — 80 ila 200 milisaniye olabilir. TURN işletmecisi de bant genişliği için öder: yayınınızın her biti onların borularından geçer.

İyi tasarlanmış bir uygulamanın TURN'ü yalnızca delik açmanın açıkça başarısız olduğu durumlarda kullanmasının nedeni budur. ICE bu kararı otomatik olarak verir.

ICE: her adayı paralel deneme

Etkileşimli Bağlantı Kurulumu (ICE), RFC 8445, tüm bunları birbirine bağlayan koreografidir. ICE baştan bir strateji seçmez. Her taraf için olası her aday adresi toplar, tam listeyi karşı tarafla paylaşır, ardından iki yığının her aday çiftini paralel olarak yoklamasını sağlar — çalışan ilkini bulmak için yarışırlar.

ICE her taraf için tipik olarak şunları toplar:

Ana makine adayları — her ağ arayüzündeki (Ethernet, Wi-Fi, sanal arayüzler, IPv4 ve IPv6) her yerel IP adresi.
Sunucu yansımalı adaylar — STUN sunucularından öğrenilen genel adresler.
Aktarıcı adayları — bir TURN sunucusunda ayrılan adresler.

İki taraf bu listeleri bir sinyalleşme kanalı üzerinden paylaşır — Remio'da bu, ICE adaylarını ve WebRTC oturum açıklamasını (SDP) taşıyan, relay.remio.net adresine küçük bir WebSocket bağlantısıdır ve medya akmaya başladığında yapacak başka işi kalmaz.

İki liste de elde olunca ICE bağlantı denetimlerine başlar. Her taraf, öncelik sırasına göre her aday çifti boyunca bir STUN bağlama isteği paketi gönderir. Öncelikler en düşük gecikmeli yolu tercih edecek şekilde tasarlanmıştır:

Ana makineden ana makineye — iki taraf da aynı yerel ağda. Hayal edilen durum: birkaç yüz mikrosaniyelik gecikme, araya yönlendirici girmez.
Ana makineden sunucu yansımalıya ya da sunucu yansımalıdan sunucu yansımalıya — taraflar farklı ağlarda, kendi NAT'larından delik açılarak bağlanmış. "İnternet üzerinden P2P" pratikte genellikle bu anlama gelir.
Aktarıcı içeren her şey — son çare; yalnızca daha yüksek öncelikli yolların hepsi bağlantı denetimlerinde başarısız olduğunda kullanılır.

İki yönde de başarılı olan ilk aday çifti kazanan olarak belirlenir ve medya o yoldan akmaya başlar. Tüm süreç tipik olarak bir saniyenin çok altında tamamlanır.

ICE aday toplamayı sürekli da yapar. Oturum ortasında daha iyi bir yol belirirse — diyelim telefonunuz hücreselden ayrılıp Wi-Fi'ye katıldı — ICE aramayı düşürmeden yeni yola geçebilir.

Remio neden P2P'yi sıkı sıkıya tercih ediyor

Remio bir uzak masaüstü uygulaması, görüntülü görüşme değil. Gecikme bütçesi acımasız. Bir oturumun ana makinenin başında oturuyormuşsunuz gibi hissettirmesi için tüm hattın — yakalama, kodlama, ağ, çözme, görüntüleme — çok küçük olması gerekir: LAN'da bu yaklaşık 8 ms'ye mal olur, geri kalanı ekranınızın kendi 60 Hz yenileme ritmidir (kare başına yaklaşık 16,7 ms). Fazladan her sıçrama bir günahtır.

Doğrudan bir LAN P2P bağlantısında bu bütçenin ağ kısmı gidiş-dönüş yaklaşık 1 ila 5 milisaniyedir. Aktarıcı yok; baytlar doğrudan bir cihazdan diğerine gider. Remio'nun hattıyla bu, LAN'da yaklaşık 8 ms'lik işlem süresi tutar (dahili olarak ölçülür; geri kalanı ekranınızın kendi 60 Hz yenileme ritmidir) — girdiniz bir sonraki kare çizilmeden ulaşır. Uzaktaki makine yerel bir makineden ayırt edilemez hissettirir.

TURN aktarmalı bir bağlantıda — bölgesel olsa bile — ağ kısmı 30 ila 80 milisaniyeye sıçrar. Kullanıcının algıladığı toplam gecikme artık 40 ila 100 ms'dir. Çoğu iş için hâlâ kullanılabilir, ama hızlı bir sürüklemede ya da art arda tıklamalarda hissedersiniz. İzleme dörtgeni artık tam olarak sizinki gibi hissettirmez.

Oturumları P2P'de tutmak için bu kadar uğraşmamızın nedeni bu fark. Remio'nun WebRTC yığını hem IPv4 hem IPv6 adaylarını toplar, birden çok STUN sunucusuyla paralel konuşur ve ICE'ın aday çifti seçiminde doğrudan yolları agresif şekilde tercih eder. Dahili olarak ölçülen bağlantı RTT'sini bile ağı sınıflandırmak için kullanırız — 15 ms'nin altında LAN olduğunu biliriz, bu yüzden kodlayıcı yüksek başlar ve çok daha fazla bant genişliği kullanabilir. Daha yavaş her şey WAN sayılır ve daha temkinli ayarlanır.

Ve — rakiplerin çoğu zaman sessizce atladığı kısım bu — bağlantı, yoldan bağımsız olarak uçtan uca şifrelidir. Ekranınız sunucularımıza hiç dokunmaz, bir TURN aktarıcısı bile yalnızca şifreli metin görür: anahtarlar, herhangi bir piksel hareket etmeden önce el sıkışma sırasında iki taraf arasında doğrudan müzakere edilir. Baytlar P2P akıyor da olsa TURN üzerinden geçiyor da olsa, ne Remio'nun sinyalleşme sunucusu ne de TURN işletmecisi onları okuyabilir. P2P, veri yolunda hiç üçüncü taraf olmaması demektir.

Aktarıcı kaçınılmaz olduğunda (ve sorun değil)

Bazen ağ tanrıları hayır der. Her iki uçta simetrik NAT, katı bir ISS'nin operatöründe çift CGNAT, yalnızca bilinen bulut sağlayıcılarına giden TLS'ye izin veren kurumsal bir güvenlik duvarı — bunlar gerçek, yaygın yapılandırmalardır. Bu durumlarda oturum bir aktarıcıdan geçmek zorundadır, yoksa hiç olmaz.

Remio'nun TURN arka ucu Cloudflare Calls; bu bize çoğu kullanıcıya yakın küresel bir aktarıcı ağı sağlıyor. ICE bir aktarıcı yolu seçtiğinde deneyim "yerel gibi hissettiriyor" düzeyinden "Splashtop gibi hissettiriyor" düzeyine iner — hâlâ çok kullanılabilir, ama fark edersiniz. Eklenen gecikme bölgesel bir aktarıcı için 30 ila 80 ms'dir; bölgeler arasında 200 ms'ye çıkabilir.

Önemli kısım: veri hâlâ uçtan uca şifreli. Cloudflare bir yönde şifreli UDP paketleri, diğer yönde şifreli UDP paketleri görür. Faturalandırma için bayt sayabilir. Ekranınızı, tuş vuruşlarınızı ya da oturum içeriğinizin hiçbirini göremez. Remio tarafında da bir şifre çözme noktası yok, çünkü hatta bir Remio bulutu yok — TURN hizmetini Cloudflare üzerinden işletiyoruz ve yüklere asla dokunmuyoruz.

Güvenlik teknik belgemizin daha ayrıntılı anlattığı mimari bu. Özetle: P2P ya da aktarıcı, tehdit modeli aynı.

IPv6 kaçış kapısı

IPv6'nın 340 undesilyon adresi (3,4 × 10³⁸) var — Dünya'daki her kum tanesine kendi genel IP'sini verip yine birkaç trilyon artıracak kadar. Yalnızca IPv6 olan bir dünyada NAT büyük ölçüde gereksizdir. IPv6 destekli iki cihaz birbirinin adresine paket gönderebilir ve tek engel her iki uçtaki ana makine güvenlik duvarıdır.

Evinizde ve operatörünüzde IPv6 varsa, her iki uç da IPv6 olduğunda bazı uygulamaların daha hızlı bağlandığını fark etmiş olabilirsiniz — çünkü tüm "aday topla, çiftleri yokla" dansında daha az engel var. Keşfedilecek bir NAT çevirisi yok, STUN yolculuğu gerekmiyor, yalnızca doğrudan adresler var.

Ama işin püf noktası şu: 2026'da küresel yaygınlaşma hâlâ eksik. Birçok ev yönlendiricisi IPv6'yı kötü yapıyor ya da hiç yapmıyor. Birçok kurumsal ağ gelen IPv6'yı varsayılan olarak engelliyor. Bazı operatörler radyo tarafında IPv6 sunup başka yerde IPv4'e köprü kuruyor. Saf IPv6'dan IPv6'ya yollar var ama tek mekanizma olarak güvenilemez.

Bu yüzden Remio — her ciddi P2P yığını gibi — hem IPv4 hem IPv6 adaylarını toplar ve ICE'ın bunları yarıştırmasına izin verir. Doğrudan bir IPv6 yolu varsa ve çalışıyorsa genellikle gecikmede kazanır. Yoksa delik açmalı IPv4 devralır. İkisi de başarısız olursa aktarıcı. Kullanıcı bunların hiçbirini görmez; bağlantı sadece kurulur.

Oturumunuzun hangi yolu kullandığını nasıl anlarsınız

Oturumunuzun hangi yola düştüğünü merak mı ediyorsunuz? Remio'nun bağlantı göstergesi türü sade bir dille gösterir — P2P için "Doğrudan", TURN için "Aktarıcı". Geliştirici istatistikleri paneli, belirlenen çiftin aday türleri (host, srflx, relay) ve ölçülen RTT dahil tam WebRTC durumunu gösterir.

Birkaç hızlı yorum:

RTT 5 ms'nin altında, Doğrudan — ana makineyle aynı LAN'dasınız. En iyi durum. Yaklaşık 8 ms'lik işlem süresi (geri kalanı ekranınızın kendi 60 Hz yenileme ritmidir) ulaşılabilir.
RTT 5 ila 15 ms, Doğrudan — aynı Wi-Fi ağı ama fazladan bir erişim noktası ya da mesh sıçraması var. Hâlâ mükemmel.
RTT 15 ila 80 ms, Doğrudan — ana makineden farklı bir ağdasınız, delik açma başarılı oldu. İnternet P2P çalışıyor.
RTT 30 ila 80 ms, Aktarıcı (bölgesel) — simetrik NAT ya da operatör düzeyi NAT delik açmayı yendi. Yakındaki Cloudflare TURN devraldı.
RTT 80 ila 200 ms, Aktarıcı — daha uzun coğrafi mesafe üzerinden TURN ya da siz ve ana makine çok farklı bölgelerdesiniz.

Evde bile sürekli aktarıcıya düşüyorsanız olağan şüpheliler: simetrik NAT yapan bir ISS modemi, ev bağlantınızda IPv4 CGNAT (fiber bayilerinde sandığınızdan yaygın) ya da gelen UDP'yi engelleyen aşırı gayretli bir güvenlik duvarı. Uzak masaüstü gecikmesini azaltma rehberimiz yaygın suçluları ele alıyor; iki cihaz da ağınızdaysa doğrudan LAN bağlantısı sayfası hızlı yol.

Gerçek dünya performans rakamları

Hepsini bir araya getirince, bir Remio oturumunun izleyebileceği farklı yollarda üretimde ölçtüğümüz gecikme rakamları şöyle:

Doğrudan LAN P2P: 1–5 ms ağ RTT. Uçtan uca (girdi olayından piksel güncellemesine): hattın geri kalanı iş birliği yaptığında yaklaşık 8 ms'lik işlem süresi (geri kalanı ekranınızın kendi 60 Hz yenileme ritmidir).
Fazladan sıçramalı aynı Wi-Fi ağı: 5–10 ms ağ RTT.
TURN aktarıcı, bölgesel: 30–80 ms ağ RTT.
TURN aktarıcı, bölgeler arası: 80–200 ms ağ RTT.
4G/5G hücresel, delik açılmış P2P: 40–100 ms ağ RTT.

Bunlar Remio'nun kıyaslamalarındaki rakamlarla örtüşüyor ve LAN–WAN eşiğini neden 15 ms RTT'ye koyduğumuzu açıklıyor — doğrudan yolları her aktarıcıdan (en az 30 ms) ya da hücresel yoldan (en az 40 ms) çok az yanlış pozitifle net biçimde ayırıyor.

NAT geçişi, protokollerin tek tek basit ama kombinatoriğin çetrefilli olduğu konulardan biri. Çoğu kullanıcının ICE, STUN ve TURN'ün var olduğunu bilmesine hiç gerek kalmayacak — yalnızca her yerden her yere hızlı bağlanan bir uygulama deneyimleyecekler. Protokoller siz fark etmediğinizde işlerini yapıyor demektir. Fark ettiğinizde — bir oturum biraz fazla uzun sürdüğünde ya da "Doğrudan" yerine "Aktarıcı" yazdığında — artık zihinsel modeliniz var.

Remio'nun yerel hattı ve 1–5 ms'lik ağ gecikmesini yaklaşık 8 ms'lik işlem süresine (geri kalanı ekranınızın kendi 60 Hz yenileme ritmidir) dönüştüren tercihler hakkında daha fazlası için yerel çözümün neden önemli olduğuna bakın. Aktarıcı yolları için tehdit modeli ise güvenlik teknik belgesinde. Ya da özelliklere göz atıp Remio'yu indirerek çalıştığını hissedin.

NAT geçişi açıklandı: P2P uzak masaüstü yönlendiricinizin ötesine nasıl ulaşır.