Colitu Adaptive Connect 2.0 ve Yedek Hat: teknik inceleme

#Özet

Bazı ağlar VPN protokollerini engeller; bazıları ise daha sinsi davranır: bağlantının kurulmasına izin verir, birkaç on saniye sonra trafiği sessizce durdurur. Böyle bir ağda "ping veriyor" ile "trafik taşıyor" aynı şey değildir. Bu rapor, Colitu uygulamalarının bu soruna karşı kullandığı mekanizmalar bütününü, Colitu Adaptive Connect 2.0'ı anlatır: yakınlığı ve gizliliği gözeten sunucu sıralaması, yalnızca cihazda tutulan ağ başına hafıza, anonim sayaçlardan üretilen ağ ipuçları, gerçek trafiğe dayanan bağlantı anı sağlık kontrolü, sunucu yedeklemesi, çalışan bağlantının içinde hazır tutulan yedek hat ve her taşıma için çalışan oturum içi izleme. Değerlendirme tek bir Android telefonda, derin paket incelemesi (DPI) yapılan bir ülkedeki tek bir ev Wi-Fi ağında, sunucu tarafında yalnızca bu istemci için hata enjekte edilerek yapıldı. En iyi yapılandırmada ana yol 120 saniye kesildiğinde VPN açık kaldı, yeniden bağlanma olmadı ve kesinti yaklaşık 5–10 saniye sürdü. 8 sunucuda 11 hatanın enjekte edildiği 60 dakikalık dayanıklılık testinde tünel üzerinden yapılan yoklamaların %98,8'i başarılı oldu; kullanılan sunucu 101 saniye tamamen kesildiğinde kullanıcı yalnızca yaklaşık 5 saniyelik bir duraklama gördü ve VPN açık kaldı. Raporda sınırlar ve henüz ölçülmeyen durumlar ayrıca belirtilir.

#1. Giriş

1. 1
   Bir VPN uygulamasının ilk işi doğru sunucuya ve doğru bağlantı moduna bağlanmaktır. Colitu sunucuları dört protokol ailesinden beş bağlantı modu sunar: Hysteria2 (UDP/QUIC), VLESS Reality, VLESS XHTTP, Trojan ve Shadowsocks 2022 (bkz. Teknik ayrıntılar).
2. 2
   Klasik yaklaşım sunucuları ping süresine göre sıralar ve en hızlı yanıt vereni seçer. Ancak ping yalnızca bir ipucudur: bazı ağlarda bir sunucu ping'e yanıt verir ama üzerinden hiç trafik geçmez.
3. 3
   Daha zor bir durum da vardır: bağlantı kurulur, uygulama "Bağlandı" der, ama bir süre sonra trafik durur ve TCP bağlantısı açık görünmeye devam eder. Kullanıcı açısından bu, VPN'in açık ama internetin yok olması demektir.
4. 4
   Adaptive Connect 1.x bu sorunların bir kısmını çözüyordu; ancak ölçümlerimiz iki önemli eksik gösterdi: sunucu listesi veritabanı kimliği sırasıyla geliyordu ve oturum içi izleme yalnızca Hysteria2'yi kapsıyordu (bkz. 4. bölüm).
5. 5
   Adaptive Connect 2.0'ın hedefi şudur: bağlanırken gerçekten çalışan yolu bulmak, bağlıyken bozulan yolu fark edip kullanıcıyı mümkünse VPN'i kapatmadan başka bir yola taşımak ve bunları kullanıcı hakkında bilgi toplamadan yapmak.

#2. Tehdit ve arıza modeli

Tasarım aşağıdaki arıza türlerine karşı düşünüldü. Bunlar belirli bir ülkeye değil, bazı ağlarda ve bazı mobil operatörlerde görülen davranışlara dayanır.

Varsayımlar:

1. 1
   Ağ, bir modu bir ağda engellerken başka bir ağda engellemeyebilir; bu yüzden "çalışıyor" bilgisi ağa bağlıdır.
2. 2
   Ağ, aynı sunucunun bütün TCP modlarını birlikte dondurabilir; bu durumda aynı sunucudaki başka bir TCP modu yedek olarak işe yaramaz.
3. 3
   Cihazın kendi interneti de gidebilir; bu durumda hiçbir mod suçlanmamalıdır.

#3. Tasarım

Aşağıdaki mekanizmalar Windows, Linux, Android (TV dahil) ve iOS uygulamaları için tasarlandı. Mekanizmaların hepsi bütün uygulamalarda aynıdır. 4. bölümdeki ölçümler bir Android telefonda yapıldı.

3.1 Sunucu sıralaması

1. 1
   Kullanıcının seçtiği konum olduğu gibi kullanılır. Colitu manuel bir seçimi kendi başına asla değiştirmez.
2. 2
   Otomatik modda ("En hızlı sunucu") sıralama şöyledir:

1. 1
   Sunucu listesindeki "Önerilen" her zaman otomatik modun bağlanacağı sunucuyu gösterir.
2. 2
   Gizlilik: Panel listeyi sıralamak için ülkenizi ve internet sağlayıcınızın ağını yalnızca o isteğin IP adresinden çıkarır. Hiçbir şey saklanmaz. İstek VPN üzerinden geldiğinde panel bunları bilemez; uygulama en son öğrendiği değerleri kullanır.

3.2 Ağ başına hafıza

1. 1
   "Ağ", bağlantı türü (Wi-Fi, mobil veri, Ethernet) ile internet sağlayıcınızın ağının birleşimidir. Ev Wi-Fi'si ve mobil veri ayrı ayrı hatırlanır.
2. 2
   Hafıza yalnızca cihazda tutulur:

1. 1
   Eski kayıtlar silinir; en fazla 200 kayıt tutulur.
2. 2
   Sonuç: mobil veride engellenen bir mod, ev Wi-Fi'sinde yine önce denenir.

3.3 Ağ ipuçları

Tek bir cihazın hafızası yalnızca o cihazın deneyimini bilir. Ağ ipuçları, aynı ağdaki başka cihazların deneyimini kimseyi tanımlamadan paylaşır.

1. 1
   İmzalı ağ belirteci. Panel uygulamaya ülke ve ağ numarası (ASN) içeren, HMAC ile imzalanmış ve 48 saat geçerli bir belirteç verir.
2. 2
   Gözlem gönderimi. Uygulama protokol başına sonuçları bu belirteçle gönderir. İsteğin IP adresi gözlem için asla kullanılmaz; bağlıyken bu adres zaten bir VPN sunucusudur.
3. 3
   Anonim saatlik sayaçlar. Panel yalnızca (ülke, ASN, protokol) başına saatlik sayaçlar tutar: başarılı, başarısız ve farklı cihaz sayısı. Farklı cihazlar, saate özel anahtarlı takma adlarla sayılır; takma adlar saat bitince silinir. Sayaçlar 7 gün saklanır.
4. 4
   Eşikler. Bir protokol, son 24 saatte en az 5 cihaz denediyse ve başarı oranı %20'nin altındaysa "bu ağda engelli" sayılır. Ağın verisi azsa ülke düzeyine bakılır: en az 20 cihaz ve %10'un altında başarı.
5. 5
   Hiçbir zaman hepsi değil. Sunulan protokollerin hepsi asla engelli işaretlenmez.
6. 6
   Kullanım. Sunucu listesi yanıtı engelli protokolleri bildirir. Uygulama bunları en sona koyar; ancak son 24 saatte bu cihazda bu ağda çalıştıysa öne almaya devam eder.

3.4 Bağlantı anı sağlık kontrolü ve doğrulama yolu

1. 1
   Bir mod ancak gerçek trafik geçtiğinde çalışıyor sayılır. Kontrol, tünel üzerinden yaygın bağlantı testi adreslerine (Cloudflare, Google, Microsoft) sorar; Colitu'nun kendi sunucularına sormaz. Mod başına yaklaşık 4–6 saniye sürer.
2. 2
   Bir mod çalışmıyor diye işaretlenmeden önce cihazın internete bağlı olup olmadığına bakılır; düşen bir Wi-Fi moda yüklenmez.
3. 3
   Zaman bütçesi: mod başına yaklaşık 8 saniye (başlatma ve trafik kontrolü), sunucu başına yaklaşık 20 saniye, bütün bağlantı için en fazla yaklaşık 45 saniye. Çoğu zaman birkaç saniye yeter.
4. 4
   Android, "Bağlandı" yazısını ancak kontrol geçince gösterir; o zamana kadar "Kontrol ediliyor…" görünür.
5. 5
   Doğrulama yolu. Her çekirdek başlatıldığında cihazın içine, yalnızca cihazdan erişilebilen özel bir kontrol girişi eklenir (rastgele port ve kimlik bilgileriyle). Bu giriş ilk yönlendirme kuralıyla doğrudan ana yola bağlanır. Böylece bağlantı anı kontrolü yalnızca ana yolu ölçer; bozuk bir ana yol yedek hattın arkasına saklanamaz ve bir sonraki bağlantıda kaçınılır.

3.5 Sunucu yedeklemesi

1. 1
   Otomatik modda bir sunucunun hiçbir modu sağlık kontrolünden geçmezse uygulama listedeki bir sonraki sunucuya geçer; bir bağlantıda en fazla 3 sunucu denenir. Bu sırada "Başka sunucu deneniyor…" görünür.
2. 2
   Başarısız sunucu o ağda 30 dakika boyunca sonda kalır.
3. 3
   Windows ve Linux'ta kill switch açıkken otomatik yeniden deneme aynı sunucuyu tekrar denemek yerine listede aşağı iner.
4. 4
   Manuel seçilen bir sunucuda her mod başarısız olursa hata mesajında tek dokunuşla "En hızlı sunucuyu dene" seçeneği çıkar.

3.6 Yedek hat

Topoloji. Bağlıyken uygulama, çalışan bağlantının içinde ikinci bir yol hazır tutar. Trafik bir yük dengeleyiciden geçer: ana yol sağlıklıyken her şey ana yoldan gider; ana yol çalışmayı bırakırsa yeni trafik kendiliğinden yedeğe geçer. VPN açık kalır, "yeniden bağlanıyor" ekranı çıkmaz. Geçiş uygulama ekranında değil bağlantının kendisinde olduğu için uygulama arka plandayken de çalışır. Yedek yalnızca kullanıldığında bağlanır.

Yedeğin seçimi.

Bu ağda başarısız olan mod ve sunucular asla yedek olmaz.

Önek tuzağı. Xray'de yük dengeleyici ve gözlemci seçicileri etiketleri önekle eşleştirir. Yedek yolun etiketi ana yolun etiketiyle aynı önekle başlarsa gözlemci yedeği de ana yol sanır. Bu yüzden yedeğin etiketi ana yolla önek paylaşmayacak biçimde seçildi.

DNS. Xray'in DNS modülünün sorguları için yük dengeleyiciye giden açık bir kural vardır.

TCP kullanıcı zaman aşımı. Yedek bağlıyken TCP yolları 10 saniyelik bir TCP kullanıcı zaman aşımı (RFC 5482'deki kavram) kullanır; böylece ölü bağlantılar asılı kalmak yerine kapanır.

Algılama süresi ve maliyet.

Windows kill switch yedek sunucuya da izin verir; Linux onu izin listesine ekler. Yedeğin yapılandırması bağlantıyla paralel olarak alınır, bağlantıyı geciktirmez ve önbelleğe alınır. Yedek hat varsayılan olarak açıktır; Gelişmiş modda kapatılabilir, Basit modda her zaman açıktır.

3.7 Oturum içi izleme ve yedeği gözeten kural

1. 1
   Adaptive Connect 1.x'te oturum içi izleme yalnızca Hysteria2'yi kapsıyordu. 2.0'da her taşıma izlenir.
2. 2
   İzleme sıklığı: ilk 90 saniye boyunca 5 saniyede bir, sonra 30 saniyede bir. Cihaz çevrimiçiyken art arda 3 başarısız kontrol, ana yolun ölü sayılması demektir.
3. 3
   Yedeği gözeten kural. Yedek bağlıyken izleyici iki şeyi ayrı ayrı kontrol eder: yalnız ana yolu ve normal yolu (yük dengeleyicinin kullandığı yol).

1. 1
   Bu kural, 4. bölümdeki 1. deneyde görülen hatanın düzeltmesidir: eski izleyici, yedek trafiği taşırken bağlantıyı yeniden başlatıp bozuyordu.
2. 2
   Android ve iOS beklenmedik bir kopmadan sonra kendiliğinden yeniden bağlanır (yaklaşık 2, 5 ve 15 saniye sonra, ardından hata gösterilir) ve ağ geri geldiğinde tekrar dener. Bağlantıyı siz kestiyseniz, oturumu kapattıysanız ya da plan veya cihaz duraklatıldıysa bunu yapmaz.

3.8 Ağı kilitleyemeyen donma işaretleri

Donma işaretleri yanlış verilirse bir ağda hiçbir mod denenmez hale gelebilir. Bunu önlemek için iki kural vardır:

1. 1
   İşaretler, sunulan taşımalardan en fazla birini bırakacaksa o tur için yok sayılır.
2. 2
   Tamamen başarısız bir tur sırasında bulunan işaretler 10 dakika sürer. 6 saatlik süre yalnızca aynı ağda başka bir taşıma ardından trafik taşıdıysa geçerlidir; yani sorun gerçekten o moda özgüyse.

3.9 Sunucuların çevrimiçi raporları ve yük

Sunucular her kalp atışında bağlı farklı kullanıcı sayısını bildirir (Xray'in çevrimiçi kullanıcı istatistikleri ve Hysteria2'nin çevrimiçi arayüzü). Panel yalnızca eksiksiz raporları kullanır; bir çekirdeğin istatistiği alınamadıysa önceki değer korunur. Böylece dolu sunucular artık önerilmez ve yüke göre dağıtım gerçek sayılarla yapılır. Bu raporlar bütün sunucularda canlıdır.

3.10 Yedek sağlık kontrolü ve paralel bağlantı

Aşağıdaki iki mekanizma bütün uygulamalarda vardır; ikisi de 4.3'teki dayanıklılık testinde etkindi:

1. 1
   Yedek sağlık kontrolü. Yedek yol da yaklaşık dakikada bir kendi kontrol girişi üzerinden denenir. Ölü bir yedek yalnızca tünel boştayken değiştirilir; bir arama sırasında asla.
2. 2
   Paralel bağlantı ("happy eyeballs"). En iyi iki aday aynı anda kontrol edilir ve trafiği ilk taşıyan kazanır. Fikir, RFC 8305'teki Happy Eyeballs yaklaşımına dayanır.

#4. Değerlendirme

4.1 Yöntem

Bu amaçla bir iç araç (hata laboratuvarı) yazıldı: bir protokolü (listelenen bütün sunucularda) ya da bir sunucunun tamamını tek bir istemci için etiketli güvenlik duvarı kurallarıyla keser, kuralları kendi kendini silen zamanlayıcılarla kaldırır, istemciyi bir saat boyunca 5 saniyede bir yoklar ve her hata için kesinti süresini raporlar. 4.2'deki yedek hat deneylerinde hatalar tek tek uygulandı; 4.3'teki dayanıklılık testinde araç 60 dakika boyunca rastgele sırayla hata enjekte etti.

4.2 Sonuçlar

Sıralama. Kullanıcının kendi ülkesindeki bir sunucu en düşük ping'i verdi (13–15 ms) ama doğru biçimde yakındaki bir yabancı sunucunun (16–17 ms) arkasına yerleşti. Adaptive Connect 1.x'te liste veritabanı kimliği sırasıyla geliyordu ve başka bir kıtadaki yaklaşık 222 ms'lik bir sunucu "Önerilen" olarak görünüyordu.

Dondurma gözlemi. Bu ağda yakındaki bir sunucuya giden bütün TCP taşımaları (VLESS Reality, VLESS XHTTP, Trojan) bağlandıktan yaklaşık 30–50 saniye sonra dondu: trafik durdu, TCP açık kaldı. Hysteria2 çalışmaya devam etti. Yalnızca Hysteria2'yi izleyen eski izleyici bu durumda "Bağlandı" gösteriyordu ama trafik yoktu. Her taşımayı izleyen yeni izleyici donmayı fark etti ve taşımayı yaklaşık 1,3 saniyede değiştirdi.

Temel çizgi. Aynı ağda yayımlanmış 2.7.0 sürümü Hysteria2 ile 100 saniye kesintisiz çalıştı.

Yedek hat deneyleri (ana yolun paketleri sunucuda yalnızca bu istemci için düşürüldü):

4.3 Dayanıklılık testi

10 Ekim 2026'da aynı telefon ve aynı Wi-Fi ağında, 2.0'ın bütün mekanizmalarını (yedek sağlık kontrolü ve paralel bağlantı dahil) içeren bir Android sürümüyle, otomatik modda 60 dakikalık bir dayanıklılık testi yapıldı.

1. 1
   Yöntem. Hata laboratuvarı 8 sunucu üzerinde rastgele sırayla 11 hata enjekte etti; hatalar arasında 2–5 dakika vardı ve her hata 60–120 saniye sürdü. İki hata türü kullanıldı: bir protokolün bu istemci için bütün sunucularda kesilmesi ve bir sunucunun bu istemci için tamamen kesilmesi.
2. 2
   Yoklama. 5 saniyede bir tünel üzerinden bir HTTP isteği.
3. 3
   Sonuç. 750 yoklamanın 741'i başarılı oldu (%98,8).

Yorum.

1. 1
   3. hata asıl durumdur: kullanılan sunucu 101 saniye boyunca ortadan kalktı; kullanıcı yaklaşık 5 saniyelik bir duraklama gördü ve VPN açık kaldı.
2. 2
   11. hata: bu ağda bütün TCP protokolleri DPI tarafından donduruluyor. Hysteria2 her yerde kesilince çalışan hiçbir protokol kalmadı; trafik, hata bittikten 2 saniye sonra geri geldi.
3. 3
   Kullanılmayan protokol ve sunuculardaki hatalar beklendiği gibi 0 saniye gösteriyor: başka yerdeki hatalar oturumu bozmuyor.

Sınırlar. Bir cihaz, bir ağ, bir saat; hatalar gerçek bir sansür sistemi tarafından değil, sunucu tarafında enjekte edildi.

Test edilen mekanizmalar Android (TV dahil), iOS, Windows ve Linux uygulamalarının hepsinde aynıdır; ölçüm bir Android telefonda yapıldı.

4.4 Tartışma

1. 1
   1. deney: Yedek hat tek başına yetmez; izleyicinin yedeği bilmesi gerekir. Bu deney 3.7'deki yedeği gözeten kuralı doğurdu.
2. 2
   2. deney: Aynı sunucudaki yedek, ağın o sunucunun bütün TCP modlarını dondurduğu durumda işe yaramaz (varsayım 2). Burada çalışan bir yol hiç yoktu; ölçülen süre engelin kendisidir, mekanizmanın gecikmesi değildir.
3. 3
   3. deney: "Diğer aile" kuralı her ağda doğru değildir. Bu ağda TCP ailesi bir bütün olarak donuyordu; diğer aileyi seçmek, donan bir aileyi seçmek demekti. Bu deney 3.6'daki "kanıtlanmış taşıma" kuralını doğurdu: bu ağda çalıştığı kanıtlanan taşıma, bir sonraki sunucuda yedek olur.
4. 4
   4. deney: Kanıtlanmış taşıma ve farklı sunucu birlikte kullanıldığında ana yolun kesilmesi kullanıcıya yalnızca kısa bir duraklama olarak yansıdı.
5. 5
   Dayanıklılık testi: Kullanılan sunucunun 101 saniye tamamen kesilmesi yaklaşık 5 saniyelik bir duraklamaya indi; tek uzun kesinti, çalışan hiçbir protokolün kalmadığı 11. hataydı.
6. 6
   Dondurma gözlemi: "Bağlandı" ile "trafik var" arasındaki fark gerçek bir arıza türüdür ve yalnızca bir taşımayı izlemek yetmez.

4.5 Henüz ölçülmeyenler

Wi-Fi ile mobil veri arasında geçiş ve iOS, Windows ve Linux'un gerçek cihazlardaki ölçümü henüz yapılmadı.

#5. Sınırlar

1. 1
   Çıkış IP'si döndürme. Bu özellik bir sunucuda VLESS'i zorunlu kılar ve yedek hattı kapatır. Ölçüm yapılan ağda bu, tekrarlanan donmalar demekti. Bu bilinen bir sınırdır.
2. 2
   Açık TCP akışları. Yedeğe geçişte aramalar kısa bir aksamadan sonra sürer, sayfalar ve mesajlar kendiliğinden yeniden bağlanır; ama o anda süren büyük bir indirme yeniden başlayabilir. İndirmelerin gerçekten kesintisiz sürmesi gelecekteki bir iştir.
3. 3
   Tek cihaz, tek ağ, bir saat. Değerlendirme tek bir Android telefonda, tek bir ağda ve en uzun bir saatlik testle yapıldı; hatalar gerçek bir sansür sistemi tarafından değil, sunucu tarafında enjekte edildi. Sonuçlar başka ağlara genellenemez.
4. 4
   Eskiyen ağ anahtarı. VPN açıkken panel isteğin geldiği ağı göremez; uygulama, liste VPN kapalıyken yeniden alınana kadar son öğrendiği ağı kullanır.
5. 5
   Çevrimiçi sayılar. sing-box üzerinden bağlı kullanıcılar çevrimiçi raporlara dahil değildir; iki sunucuya bağlı bir kullanıcı toplamda iki kez sayılır.
6. 6
   Yedek yok. Multihop rotalarında ve tek modlu sunucularda yedek hat yoktur. sing-box XHTTP çalıştıramaz.

#6. Gelecek çalışma: CSL oturum katmanı

Colitu Session Layer (CSL), yedek hattın üstüne eklenmesi planlanan bir oturum katmanıdır. Plan taslak aşamasındadır ve hiçbir tarih ya da sonuç vaat edilmez.

1. 1
   Ne ekler? Bugün yedek hat yeni bağlantıları yedeğe taşır, ama açık indirmeler ve TCP üzerinden giden aramalar kopabilir. CSL'de uygulama tek bir oturum açar; alttaki tünel (taşıyıcı) değişse de oturum sürer. Laboratuvar prototipinde en uzun duraklama 0,08–1,75 saniye oldu ve indirmeler kopmadan doğrulandı.
2. 2
   Sınırı. Bir CSL oturumu tek bir sunucuya bağlıdır; ilk sürümde oturumu başka bir sunucuya taşımak yoktur. CSL aynı sunucu içindeki sorunları çözer (Wi-Fi ile mobil veri arasında geçiş, bir protokolün engellenmesi, anlık kopma). Sunucunun kendisi çökerse yedek hat devreye girer. İkisi birbirinin yerine geçmez, birlikte çalışır.
3. 3
   Aşamalar. Önce geçici test sunucularında gerçek tünellerle (Reality, Trojan, Hysteria2) kesinti, engelleme, ağ değişimi ve yük senaryoları; sonra sunucu tarafı servis, panelde sunucu başına aç/kapat bayrağı ve bütün CSL'yi kapatan acil anahtar; ardından önce Windows, sonra Linux, Android ve en son iOS. Hedefler arasında yedek hazırken taşıyıcı değişiminde 2 saniyeyi geçmeyen duraklama ve doğrudan bağlantının en az %90'ı kadar hız vardır.
4. 4
   UDP ve aramalar. İlk sürüm yalnızca TCP'yi korur; UDP (WhatsApp ve Meet aramaları, QUIC/HTTP3) bugünkü gibi yedek hattın korumasında kalır. Sonraki adım UDP'yi CSL oturumu içinde datagram olarak taşımaktır; taşıyıcı değişirken 2 saniyeden kısa bir boşluk beklenir. Gelişmiş modda isteğe bağlı bir "QUIC'i TCP'ye zorla" seçeneği de düşünülüyor.
5. 5
   CSL yokken. Sunucuda bayrak kapalıysa, CSL yanıt vermiyorsa ya da "meşgul" veya "reddedildi" diyorsa istemci birkaç saniye içinde bugünkü yola döner. Taşıyıcısız 90 saniyeden uzun kalan oturum kaybolur. Takılan bir CSL istemcisini bir bekçi süreç kapatır.
6. 6
   Kullanıcıya sunuluşu. Gelişmiş modda "Kesintisiz oturum (beta)" olarak; varsayılan olarak kapalı ve yalnızca bayrağı açık sunucularda görünür.

#7. Sonuç

Adaptive Connect 2.0'ın temel dersi şudur: bir yolun çalışıp çalışmadığına ping değil, gerçek trafik karar verir ve bu karar ağa bağlıdır. Yakınlığı ve gizliliği gözeten sıralama, cihazda tutulan ağ hafızası, anonim ağ ipuçları ve yalnızca ana yolu ölçen sağlık kontrolü doğru yolu bulmayı sağlar. Bağlıyken yedek hat, her taşımayı izleyen ve yedeği gözeten izleyiciyle birlikte, ana yolun kesilmesini yaklaşık 5–10 saniyelik bir duraklamaya indirir. 60 dakikalık dayanıklılık testinde yoklamaların %98,8'i başarılı oldu ve kullanılan sunucunun tamamen kesilmesi yaklaşık 5 saniyelik bir duraklama olarak yansıdı. Değerlendirme dar kapsamlıdır; ağ değişimi ve diğer platformlardaki ölçümler sonraki adımdır.

#Kaynaklar

1. 1
   RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
2. 2
   RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
3. 3
   RFC 5482, TCP User Timeout Option.
4. 4
   Hysteria2 proje belgeleri.
5. 5
   Xray-core proje belgeleri.