SingLink 2.0 Protokolü

SingLink 2.0, SingLinkVPN’in kendi geliştirdiği resmî ağ aktarım protokolüdür. “2.0” protokolün adını ve neslini belirtir; bir SingLinkVPN istemci yazılımı sürümü değildir.

SingLink protokolü, trafiği bir VPN düğümüne taşımaktan fazlasını yapar. Hesap ve düğüm yetkilendirmesini, DNS işlemeyi, akıllı yönlendirmeyi, şifreli oturumları, TCP ve UDP kapsüllemeyi, bağlantı sağlık kontrollerini, ağ değişikliklerini ve hata kurtarmayı da kapsar.

SingLink’in şu anda üretimde kullanılan SingLink 2.0 protokolü ve hızı önceleyen SingLink Beta önizleme protokolü vardır. İç A/B testlerinde SingLink 2.0’ın kararlılığı %99.5’e ulaştı, Beta’nınki ise yaklaşık %97’ye kadar çıktı; uygun ağ ve cihaz koşullarında Beta’nın zirve hızı 1 Gbps’yi aştı.

Temel veri karşılaştırması: Üretimdeki SingLink 2.0, belirtilen test ortamında %99.5 kararlılık kaydetti. Beta yaklaşık %97’ye kadar çıktı, ancak uygun ağ ve cihaz koşullarında 1 Gbps zirve hızı aştı. Bu sonuçlar farklı kararlılık ve hız önceliklerini yansıtır; her cihaz veya ağ için garanti değildir.

Kanıt ve teknik sınır: Doğrulanmış ürün konumlandırması, iç test tanımları ve herkese açık işlevler doğrudan alıntılanabilir. Aşağıdaki belirli şifreleme algoritmaları, paket biçimi, yetenek anlaşması, Session, Stream, çoğullama ve oturum kurtarma ayrıntıları bir referans işleme modelidir; şu anda dağıtılmış spesifikasyonun beyanı değildir. Gelecekteki resmî SingLink teknik belgeleri ve yayımlanan kaynak kodu esas alınır.

SingLink Protokolünün Eksiksiz İşleyiş İlkeleri

Sistemin bütünü iki yola ayrılabilir:

Kontrol düzlemi

Sorumlu olduğu işler:

• hesapta oturum açmak;
• üyeliği doğrulamak;
• düğümleri almak;
• düğüm haklarını belirlemek;
• protokol yapılandırmasını iletmek;
• kuralları güncellemek;
• Beta veya 2.0’ı seçmek.

Veri düzlemi

Sorumlu olduğu işler:

• uygulama trafiğini almak;
• DNS çözümlemek;
• güvenli bir bağlantı kurmak;
• TCP ve UDP’yi kapsüllemek ve taşımak;
• bağlantıyı canlı tutmak;
• bağlantı kopmalarını ele almak;
• verileri uygulamaya geri iletmek.

Basitleştirilmiş akış şöyledir:

Kullanıcı SingLinkVPN’de oturum açar
        ↓
Yetkili düğümleri ve protokol yapılandırmasını al
        ↓
İstemci bir TUN / sistem proxy’si oluşturur
        ↓
Uygulama trafiğini al
        ↓
DNS ve yönlendirme kurallarını değerlendir
        ↓
Bir SingLink 2.0 veya Beta düğümü seç
        ↓
Protokol yeteneklerini müzakere et
        ↓
Hesap ve cihaz haklarını doğrula
        ↓
Şifreli oturumu ve oturum anahtarlarını oluştur
        ↓
Her uygulama bağlantısı için bağımsız bir mantıksal akış oluştur
        ↓
TCP / UDP verisini kapsülle
        ↓
Veriyi SingLink düğümüne gönder
        ↓
Düğüm kapsülü açar ve hedef web sitesine erişir
        ↓
Veriyi geri döndür ve kaynak uygulamaya ilet
        ↓
Gecikmeyi, kaybı ve bağlantı durumunu sürekli ölç
        ↓
Bir hatadan sonra yeniden bağlan, kurtar veya düğüm değiştir

---

1. Aşama: Oturum Açma, Düğüm Alma ve Protokol Yapılandırması

Kullanıcı SingLinkVPN’i açıp oturum açtıktan sonra istemci, her üretim düğümünün adresini, kimlik bilgilerini ve protokol parametrelerini hemen cihazda kalıcı olarak saklamamalıdır.

Daha uygun akış şöyledir:

1. İstemci hesap kimlik bilgilerini gönderir.
2. Hesap sistemi kullanıcıyı doğrular.
3. Sistem plan ve düğüm haklarını onaylar.
4. O kullanıcı için kullanılabilir düğümleri döndürür.
5. Kısa ömürlü bağlantı kimlik bilgilerini döndürür.
6. Güncel protokol sürümünü ve gerekli yapılandırmayı döndürür.
7. İstemci yapılandırmanın bütünlüğünü doğrular.
8. Hassas yapılandırma korumalı sistem depolamasında saklanır.

Bu katman esas olarak şunları belirler:

• kullanıcının geçerli bir üyeliği olup olmadığını;
• Beta veya 2.0’ın kullanılabilir olup olmadığını;
• hesabın Pro, Max veya Rich hakkına sahip olup olmadığını;
• hangi ülkelerin ve düğümlerin kullanılabilir olduğunu;
• yapılandırmanın süresinin dolup dolmadığını;
• istemcinin güncellenmesi gerekip gerekmediğini.

Sade bir dille açıklama

Bu, hızlı trene binmeden önce yapılan kontrole benzer:

• kim olduğunuz;
• hangi bilet sınıfını satın aldığınız;
• hangi sefere binebileceğiniz;
• biletin hâlâ geçerli olup olmadığı.

Önerilen güvenlik kuralları

SingLink süresiz olarak tek bir kalıcı statik parolaya dayanmamalıdır.

Daha uygun bir tasarım şunları kullanır:

• kısa ömürlü bir bağlantı belirteci (token);
• tek seferlik bir sınama (challenge);
• bir cihaz nonce değeri;
• bir geçerlilik süresi sınırı;
• sunucu tarafından imzalanmış düğüm yapılandırması;
• bir iptal mekanizması.

Böylece tek bir bağlantı yapılandırmasını ele geçirmek kalıcı erişim sağlamaz.

---

2. Aşama: Sistem Ağ Giriş Noktasının Oluşturulması

Kullanıcı Bağlan’ı seçtiğinde SingLinkVPN’in önce işletim sisteminde bir ağ giriş noktası oluşturması gerekir.

Yöntem platforma göre değişir:

Platform	Yaygın ağ giriş noktası
iOS / iPadOS	Network Extension / Packet Tunnel
Android	VPN Service
macOS	Network Extension veya TUN
Windows	TUN sanal ağ bağdaştırıcısı ve sistem yönlendirmesi
Linux	TUN, yönlendirme tablosu ve DNS yönetimi

Giriş noktası oluşturulduktan sonra, uygulamaların normalde doğrudan ağa göndereceği veriler önce SingLinkVPN istemcisine girer.

Örneğin:

ChatGPT uygulaması
    ↓
İşletim sistemi ağ yığını
    ↓
SingLink TUN arayüzü
    ↓
SingLinkVPN istemcisi

Bu aşamada istemcinin şunları yapması gerekir:

• sanal bir IP oluşturmak;
• yönlendirme tablosunu yapılandırmak;
• DNS’i yapılandırmak;
• yerel ağı hariç tutmak;
• proxy bağlantısının TUN’a geri yönlendirilmesini önlemek;
• Kill Switch kuralları oluşturmak.

Son madde önemlidir.

Bir rota istisnası olmazsa, SingLinkVPN’in düğümüne ulaşmak için kullandığı trafik VPN’e yeniden girip bir döngü oluşturabilir:

VPN trafiği
↓
VPN’e yeniden girer
↓
Tekrar kapsüllenir
↓
Sonsuz döngü

Bu nedenle istemci şunları açıkça hariç tutmalıdır:

• düğümün kendi IP adresi;
• gerekli kontrol arayüzleri;
• yerel ağ geçidi;
• sistemin doğrudan ulaşması gereken hizmetler.

---

3. Aşama: DNS Çözümleme ve Alan Adı Değerlendirmesi

Kullanıcı chatgpt.com’u açtığında cihazın genellikle önce alan adını bir IP adresine çözümlemesi gerekir.

Hatalı DNS işleme şunlara yol açabilir:

• DNS isteklerinin doğrudan yerel ağ üzerinden gitmesi;
• yerel DNS çözümleyicisinin yanlış bir adres döndürmesi;
• kuralların özgün alan adı bağlamını kaybetmesi;
• IPv6 trafiğinin VPN’i atlaması;
• VPN bağlı görünürken bile DNS sızıntısı.

SingLink istemcisi şu akışı kullanabilir:

Uygulama bir DNS isteği gönderir
        ↓
İstemci DNS’i yakalar
        ↓
Alan adı kurallarını değerlendir
        ↓
Yerel DNS’i veya korumalı uzak DNS’i seç
        ↓
IPv4 / IPv6 sonucunu al
        ↓
Alan adını IP ile ilişkilendir
        ↓
Doğrudan, proxy veya engelle seçeneğini belirle

Yerel alan adları

Yerel bankalar, yerel ağ cihazları veya bölgeye özgü hizmetler yerel DNS kullanıp doğrudan bağlanabilir.

Proxy üzerinden geçen alan adları

VPN üzerinden erişilmesi gereken alan adları, proxy düğümü veya korumalı bir DNS çözümleyicisi aracılığıyla çözümlenebilir.

Sade bir dille açıklama

DNS, bir adres aramaya benzer.

Bu arama hâlâ yerel yolu kullanıyorsa, sonraki veriler VPN’den geçse bile hangi web sitesinin istendiğini açığa çıkarabilir.

Bu nedenle SingLink protokol sistemi şunları tanımlamalıdır:

• istemcinin DNS’i yakalayıp yakalamadığını;
• hangi DNS isteklerinin doğrudan gittiğini;
• hangi DNS isteklerinin VPN’i kullandığını;
• IPv4 ve IPv6’nın nasıl ele alındığını;
• DNS sonuçlarının ne kadar süre önbellekte tutulduğunu;
• bir ağ değişikliğinden sonra eskimiş DNS sonuçlarının temizlenip temizlenmediğini.

---

4. Aşama: Akıllı Yönlendirme ve Rota Kararları

DNS ve uygulama trafiği istemciye girdikten sonra sistemin bunları nasıl ele alacağına karar vermesi gerekir.

Normalde üç olası sonuç vardır:

Doğrudan
Proxy
Engelle

Doğrudan

Trafik yerel ağı kullanır ve SingLink tüneline girmez.

Uygun olduğu durumlar:

• yerel ağ cihazları;
• yerel web siteleri;
• proxy gerektirmeyen uygulamalar;
• kullanıcı tanımlı izin listeleri.

Proxy

Trafik SingLink protokolüne girer ve bir düğüm tarafından iletilir.

Uygun olduğu durumlar:

• yurt dışı web siteleri;
• yapay zekâ araçları;
• uluslararası sosyal platformlar;
• kullanıcının seçtiği uygulamalar.

Engelle

Bağlantı reddedilir.

Uygun olduğu durumlar:

• reklam alan adları;
• izleme alan adları;
• kötü amaçlı adresler;
• kullanıcı tanımlı engelleme listeleri.

Karar şunları dikkate alabilir:

• alan adı;
• IP adresi;
• port;
• uygulama;
• coğrafi konum;
• protokol türü;
• kullanıcı kuralları;
• genel mod veya kural modu.

Sade bir dille açıklama

Bu aşama trafik yönlendirmesine benzer:

• yerel araçlar normal yolları kullanır;
• yurt dışına giden araçlar şifreli bir otoyola girer;
• tehlikeli araçların girişine izin verilmez.

---

5. Aşama: Düğüm ve Protokol Seçimi

Trafiğin proxy üzerinden gideceği belirlendikten sonra istemcinin bir düğüm seçmesi gerekir.

Seçim yalnızca bir ülke adına dayanamaz. Şunlar da dikkate alınmalıdır:

• kullanıcının planı;
• düğümün 2.0 mı yoksa Beta mı kullandığı;
• düğümün çevrim içi olup olmadığı;
• gecikme;
• paket kaybı;
• yük;
• düğüm uzaklığı;
• yerel operatör;
• hedefin konumu;
• UDP desteği;
• istemci uyumluluğu.

Manuel seçim

Kullanıcı Japonya, Amerika Birleşik Devletleri, Singapur veya başka bir konumdaki bir düğümü seçer.

Akıllı seçim

İstemci test sonuçlarına göre uygun bir düğüm seçer.

Akıllı seçim yalnızca en düşük gecikmeli düğümü seçmemelidir.

Örneğin:

Düğüm	Gecikme	Kayıp	Yük
A	50 ms	%8	%90
B	70 ms	%0	%30

A’nın gecikmesi daha düşük olsa da kaybı ve yükü yüksektir; gerçek kullanımda B daha kararlı olabilir.

Bu nedenle akıllı seçim şunları birleştirmelidir:

Gecikme + kayıp + bağlantı başarı oranı + yük + geçmiş performans

---

6. Aşama: Protokol Yetenek Anlaşması

İstemci bir düğüme ulaştıktan sonra her iki tarafın da aynı işlevleri desteklediğini hemen varsaymamalıdır.

Önce yeteneklerin karşılıklı olarak müzakere edilmesi gerekir.

Müzakere edilen öğeler şunları içerebilir:

• SingLink sürümü;
• Beta veya 2.0;
• TCP desteği;
• UDP desteği;
• IPv4 / IPv6;
• oturum sürdürme desteği;
• çoğullama desteği;
• azami veri çerçevesi boyutu;
• Padding (dolgu) stratejisi;
• heartbeat aralığı;
• sıkıştırmanın etkin olup olmadığı;
• MTU boyutu;
• yeniden müzakere desteği.

Örneğin:

İstemci:
SingLink 2.0’ı destekliyorum
TCP, UDP ve IPv6’yı destekliyorum
Session Resume’u destekliyorum
Azami çerçeve: 64 KB

Sunucu:
SingLink 2.0 kullanımı onaylandı
TCP ve UDP kullanılabilir
Session Resume kullanılabilir
Geçerli azami çerçeve: 32 KB

İki taraf sonunda yalnızca karşılıklı olarak desteklenen yetenekleri kullanır.

Müzakere neden gereklidir?

İstemciler ve düğümler aynı gün güncellenmeyebilir.

Yeni bir istemci eski bir düğümün tanıyamadığı bir biçim gönderirse bağlantı başarısız olur.

Üretimdeki 2.0, Beta’ya kıyasla şunlara daha fazla önem vermelidir:

• geriye dönük uyumluluk;
• sürüm geri düşüşü (fallback);
• bir özellik kullanılamadığında güvenli biçimde işlev azaltma;
• uyumsuz sürümlerin açıkça reddedilmesi.

---

7. Aşama: Kimlik Doğrulama

Temel bağlantı kurulduktan sonra düğümün kullanıcının yetkili olduğunu doğrulaması gerekir.

Önerilen doğrulama verileri şunlardır:

• kısa ömürlü belirteç;
• hesap veya yetkilendirme kimliği;
• istemci nonce değeri;
• protokol sürümü;
• düğüm kimliği;
• talep edilen yetenekler;
• bütünlük doğrulama verileri.

Basitleştirilmiş bir kimlik doğrulama paketi şunu söyler:

Ben kimim
Hangi düğümü istiyorum
Hangi protokolü istiyorum
Bu bağlantının rastgele tanımlayıcısı
Yetkimin süresi ne zaman doluyor
Verinin değiştirilip değiştirilmediği

Sunucunun şunları kontrol etmesi gerekir:

1. belirtecin resmî olarak verilip verilmediğini;
2. belirtecin süresinin dolup dolmadığını;
3. belirtecin iptal edilip edilmediğini;
4. düğüme erişim hakkının kullanıcıda olup olmadığını;
5. nonce değerinin daha önce kullanılıp kullanılmadığını;
6. isteğin bir tekrar oynatma (replay) olup olmadığını;
7. bu istemci sürümünün bağlanmasına izin verilip verilmediğini.

Tekrar oynatma koruması

Bir saldırgan geçerli kimlik doğrulama verilerini kaydedip hiç değiştirmeden yeniden gönderebilir.

Bu nedenle kimlik doğrulama verilerinin şunlara ihtiyacı vardır:

• tek seferlik bir nonce;
• bir sunucu sınaması (challenge);
• kısa bir geçerlilik süresi;
• kullanılmış kimlik bilgisi kaydı;
• oturuma bağlama.

Sade bir dille:

Daha önce doğrulanmış bir bilet kopyalanıp sınırsızca yeniden kullanılamaz.

---

8. Aşama: Anahtar Değişimi ve Şifreli Oturum

Kimlik doğrulama başarılı olduktan sonra istemci ve düğüm, bu bağlantıya özel oturum anahtarlarına ihtiyaç duyar.

Önerilen mantık şöyledir:

İstemci geçici bir anahtar oluşturur
        ↓
Sunucu geçici bir anahtar oluşturur
        ↓
İkisi de açık verileri değiş tokuş eder
        ↓
Her biri aynı paylaşılan sırrı bağımsız olarak hesaplar
        ↓
Bu paylaşılan sırdan birden fazla oturum anahtarı türetilir

Şunlar için ayrı anahtarlar türetilmelidir:

• istemciden sunucuya şifreleme;
• sunucudan istemciye şifreleme;
• veri bütünlüğü;
• oturum kurtarma;
• başlık koruması.

Tüm yönler ve amaçlar tek bir anahtarı paylaşmamalıdır.

İleri gizlilik (forward secrecy)

Daha uygun bir tasarım her oturum için geçici anahtarlar kullanır.

Uzun vadeli bir sunucu anahtarı ileride sızarsa, daha önce kaydedilmiş her bağlantının şifresini doğrudan çözememelidir.

Anahtar yenileme

Uzun süre açık kalan bir bağlantı sonsuza dek tek bir oturum anahtarı setini kullanmamalıdır.

Anahtarlar şunlara göre:

• aktarılan veri miktarı;
• bağlantı süresi;
• çerçeve sayısı;
• sunucu talimatı

yeniden türetilebilir.

Örneğin:

Belirli bir GB miktarından sonra
veya
belirli bir süreden sonra
yeni yön anahtarları türet

Kesin değerler bir tanıtım yazısında uydurulmamalı, mühendislik performans ve güvenlik testleriyle belirlenmelidir.

---

9. Aşama: Oturum Oluşturma

Kimlik ve anahtarlar oluşturulduktan sonra her iki taraf da bir SingLink Session (oturum) oluşturur.

Bir Session şunları içerebilir:

• Session ID;
• protokol sürümü;
• şifreleme parametreleri;
• azami çerçeve boyutu;
• heartbeat aralığı;
• UDP modu;
• Stream sınırı;
• boşta kalma zaman aşımı;
• oturum kurtarma yeteneği;
• Beta veya 2.0 politikası.

Sunucu bir onay döndürür:

Kimlik doğrulandı
Oturum kuruldu
SingLink 2.0 kullanılıyor
TCP kullanılabilir
UDP kullanılabilir
Çoğullama kullanılabilir
Heartbeat etkin

İstemci uygulama verilerini ancak sunucu onayını aldıktan sonra göndermelidir.

---

10. Aşama: Stream veya Bağımsız Proxy Bağlantısı Oluşturma

SingLink’in gerçekte hangi mimariyi kullandığını belirlemek için mühendislik ekibinin onayı gerekir.

Seçenek 1: Tek bir Session birden fazla Stream taşır

Bu, AnyTLS yaklaşımına benzer:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: Tarayıcı

Her Stream’in şunlara ihtiyacı vardır:

• Stream ID;
• hedef adres;
• hedef port;
• TCP veya UDP;
• mevcut durum;
• gönderme penceresi;
• alma penceresi.

Avantajları:

• daha az tekrarlanan el sıkışma;
• daha düşük bağlantı gecikmesi;
• daha az alt bağlantı;
• çok sayıda kısa bağlantının verimli şekilde işlenmesi.

Riskleri:

• bir Session’daki arıza birden fazla Stream’i etkileyebilir;
• tek bir alt TCP bağlantısı satır başı engellemesine (head-of-line blocking) yol açabilir;
• eksiksiz bir akış denetimi gerekir.

Seçenek 2: Her uygulama isteği bağımsız bir bağlantı oluşturur

ChatGPT → bağımsız bağlantı
YouTube → bağımsız bağlantı
Telegram → bağımsız bağlantı

Avantajları:

• farklı trafikler birbirinden yalıtılır;
• bir bağlantının arızası diğerlerini etkilemez;
• mantık daha basittir.

Dezavantajları:

• daha fazla el sıkışma;
• daha yüksek bağlantı yükü;
• çok sayıda kısa bağlantıda daha düşük verimlilik.

Öneri

SingLink karma bir mod kullanabilir:

• kısa bağlantıları ve sıradan web trafiğini bir Session üzerinde çoğullamak;
• büyük indirmeler ve video için bağımsız kanallar oluşturmak;
• düşük gecikmeli UDP’yi ayrı ele almak;
• tek bir yüksek hızlı indirmenin tüm Stream’leri tüketmesini önlemek.

---

11. Aşama: Veri Çerçevesi Kapsülleme

Uygulama verileri aktarım kanalına olduğu gibi bırakılamaz. Protokol çerçeveleri olarak kapsüllenmeleri gerekir.

Kavramsal bir SingLink çerçevesi şunları içerebilir:

Sürüm
Çerçeve türü
Session ID
Stream ID
Sıra numarası
Bayraklar
Veri uzunluğu
Şifreli veri
Bütünlük etiketi

Olası çerçeve türleri şunlardır:

Çerçeve türü	Amaç
OPEN	Yeni bir Stream oluşturmak
DATA	Veri taşımak
ACK	Durumu onaylamak
FIN	Normal şekilde kapatmak
RESET	Anormal şekilde sonlandırmak
PING	Sağlık kontrolü
PONG	Sağlık kontrolü yanıtı
UDP	Bir UDP datagramı taşımak
SETTINGS	Oturum parametrelerini güncellemek
KEY_UPDATE	Oturum anahtarlarını yenilemek
RESUME	Bir oturumu kurtarmak

Bu bir protokol tasarımı önerisidir. SingLink’in şu anda bu adları veya bit biçimlerini kullandığını belirtmez.

---

12. Aşama: TCP Trafiğinin İşlenmesi

Web siteleri, API’ler ve dosya indirmeleri gibi TCP bağlantılarında SingLink’in şunları koruması gerekir:

• veri sırası;
• çift yönlü aktarım;
• kapanma durumu;
• akış denetimi;
• hata durumu.

Eksiksiz bir akış şöyle olabilir:

Uygulama bir TCP bağlantısı oluşturur
        ↓
İstemci bir SingLink Stream’i oluşturur
        ↓
Hedef alan adını ve portu gönder
        ↓
Düğüm hedef web sitesine bağlanır
        ↓
Düğüm başarıyı veya başarısızlığı bildirir
        ↓
Çift yönlü iletimi başlat

Normal kapanış

Uygulama bağlantıyı sonlandırdığında:

1. İstemci FIN gönderir.
2. Düğüm o yöndeki veriyi almayı durdurur.
3. Diğer yönün tamamlanmasını bekler.
4. Stream tamamen kapanır.
5. Bellek ve bağlantı durumu serbest bırakılır.

Anormal kapanış

Hedef bağlantıyı reddederse:

1. Düğüm bir hata döndürür.
2. İstemci bağlantı hatasını uygulamaya bildirir.
3. Stream hemen temizlenir.
4. Diğer Stream’ler etkilenmez.

---

13. Aşama: UDP Trafiğinin İşlenmesi

UDP’de geleneksel bir TCP bağlantısı yoktur. Her datagramın şunları koruması gerekir:

• kaynak ilişkilendirmesi;
• hedef adres;
• hedef port;
• veri uzunluğu;
• datagram sınırı;
• ilişkilendirme zaman aşımı.

Örneğin:

UDP Association ID
Hedef adres
Hedef port
Veri uzunluğu
UDP Payload

SingLink’in şu yaklaşımlar arasında açıkça seçim yapması gerekir:

UDP over TCP

UDP datagramları TCP veya güvenilir bir Session içinde taşınır.

Avantajları:

• yalnızca TCP’ye izin veren ağlardan daha kolay geçiş;
• daha düşük veri kaybı olasılığı;
• daha basit kurulum.

Dezavantajları:

• TCP kaybı sonraki UDP verilerini engeller;
• bazı oyunlar, sesli iletişim ve gerçek zamanlı kullanımlar için uygun değildir.

Yerel (native) UDP

Veriyi doğrudan UDP taşır.

Avantajları:

• düşük gecikme;
• oyunlar, sesli iletişim ve QUIC için uygun;
• TCP satır başı engellemesinden etkilenmez.

Dezavantajları:

• bazı ağlar UDP’yi kısıtlar;
• NAT ve güvenlik duvarı yönetimi daha karmaşıktır.

QUIC tarzı aktarım

UDP’ye dayanır, ancak protokol katmanında şunları sağlar:

• şifreleme;
• yeniden iletim;
• çoklu Stream;
• tıkanıklık denetimi;
• ağ geçişi.

Daha eksiksiz teknik yetenekler sunar, ancak uygulanması daha zordur.

SingLink için makul bir yön şudur:

Ağ ve trafik türüne göre yerel UDP’yi, güvenilir kapsüllemeyi veya başka bir uyumlu modu otomatik olarak seçmek.

Bunun uygulanıp uygulanmadığının doğrulanması gerekir.

---

14. Aşama: Akış Denetimi ve Geri Basınç

YouTube’un hızla indirme yaptığını, ChatGPT’nin ise yalnızca küçük miktarlarda metin aktardığını varsayalım.

Akış denetimi olmadan video Stream’i kanalı doldurabilir ve şunlara yol açabilir:

• ChatGPT yanıtlarının yavaşlaması;
• DNS gecikmesi;
• uygulamaların takılması;
• sürekli artan bellek kullanımı.

Bu nedenle iki düzeyde akış denetimi gerekir:

Session düzeyi

Tüm Session’ın ne kadar onaylanmamış veri taşıyabileceğini sınırlar.

Stream düzeyi

Her Stream’in aktarım penceresinin ne kadarını kaplayabileceğini sınırlar.

Sade bir dille:

Tek bir büyük kamyon otoyolun tüm şeritlerini işgal edemez. Her Stream’e aktarım kaynaklarından adil bir pay ayrılmalıdır.

Üretimdeki 2.0 protokolü, zirve hız arayışının diğer bağlantıları bozmaması için Beta’dan daha temkinli bir zamanlama kullanabilir.

---

15. Aşama: Bölümleme, Dolgu ve Trafik Görünümü

Veri şifrelendikten sonra bir gözlemci yine de şunları görebilir:

• paket uzunluğu;
• gönderim aralığı;
• bağlantı süresi;
• yükleme/indirme oranı;
• yeniden bağlanma davranışı.

Bu nedenle protokol trafik görünümünü değiştirebilir; örneğin:

• büyük verileri birden fazla çerçeveye bölerek;
• küçük verileri birleştirerek;
• değişken Padding (dolgu) ekleyerek;
• gönderim gruplarını ayarlayarak;
• tek bir sabit el sıkışma uzunluğundan kaçınarak;
• Padding stratejisini düzenli olarak güncelleyerek.

Ancak şunu açıkça belirtmek gerekir:

Padding şifrelemenin yerini alamaz ve trafiğin her zaman tanımlanamaz kalacağını garanti edemez.

Aşırı Padding ayrıca şunlara yol açar:

• daha fazla trafik;
• daha yüksek gecikme;
• daha fazla CPU kullanımı;
• Ücretsiz Plan kotasının boşa harcanması.

Bu nedenle 2.0 profili uyarlanabilir:

• sıradan ağlarda düşük ek yük kullanmak;
• özel ağ ortamlarında görünüm işlemeyi artırmak;
• yüksek hızlı indirmelerde gereksiz Padding’i azaltmak;
• küçük kontrol verilerine uygun dolgu uygulamak.

Beta ise zirve hızı artırmak için ek yükü azaltabilir.

---

16. Aşama: MTU ve Paket Boyutu Yönetimi

TUN trafiğine protokol başlıkları ve şifreli veri eklemek paket boyutunu büyütür.

Ağın MTU değerinin aşılması şunlara yol açabilir:

• IP parçalanması;
• paket düşmeleri;
• açılmayan web siteleri;
• dengesiz hız;
• bağlanan ama veri taşımayan bir VPN.

SingLink’in şunları yapması gerekir:

1. TUN MTU değerini belirlemek;
2. protokol başlıklarını düşmek;
3. şifreleme ek yükünü düşmek;
4. IPv4 ve IPv6’ya göre ayarlamak;
5. gerektiğinde veriyi bölmek;
6. gereksiz IP parçalanmasından kaçınmak.

Tek bir sabit paket boyutunun her ağa uymamasının nedeni budur.

Üretimdeki 2.0, platformlar arası MTU uyumluluğunu daha eksiksiz sağlamalıdır. Beta daha agresif büyük çerçeveler kullanırsa bazı ağlarda daha hızlı, ancak alışılmadık ağlarda daha az kararlı olabilir.

---

17. Aşama: Gecikme, Kayıp ve Tıkanıklık Yönetimi

İstemcinin şunları sürekli gözlemlemesi gerekir:

• RTT gecikmesi;
• titreşim (jitter);
• paket kaybı;
• gönderme hızı;
• alma hızı;
• onaylanmamış veri;
• düğüm yanıtı.

Tek bir Ping’e dayanamaz.

Örneğin:

Normal: 60 ms
Geçici artış: 120 ms
Süregelen artış: 500 ms
Yanıt yok: zaman aşımı

Farklı durumlar farklı müdahaleler gerektirir:

Durum	Müdahale
Geçici gecikme	Beklemeye devam et; hemen yeniden bağlanma
Hafif paket kaybı	Pencereyi veya gönderim hızını ayarla
Süregelen yüksek gecikme	Eşzamanlılığı azalt veya başka bir düğümü değerlendir
Veri yok ama heartbeat başarılı	Session’ı koru
Hem heartbeat hem veri başarısız	Bağlantıyı kesilmiş kabul et
Düğümün tamamen arızalanması	Yeniden bağlan veya düğüm değiştir

Tek bir paket kaybından sonra yeniden bağlanmak protokolü daha az kararlı hâle getirir.

---

18. Aşama: Heartbeat ve Sağlık Kontrolleri

Uzun süre uygulama verisi olmasa bile sistemin kanalın hâlâ canlı olup olmadığını bilmesi gerekir.

Bunun için şu kullanılabilir:

PING
↓
PONG

Heartbeat’ler çok sık olamaz.

Aşırı sıklık:

• pili boşa harcar;
• veri tüketir;
• sunucu yükünü artırır;
• sabit bir zamanlama özelliği oluşturur.

Yetersiz sıklık:

• arızalı bir düğümün tespitini geciktirir;
• uygulamaların daha uzun beklemesine neden olur;
• ağ değişikliğinden sonra kurtarmayı yavaşlatır.

Bu nedenle heartbeat sıklığı duruma göre uyarlanabilir:

• normal trafik varken heartbeat eklememek;
• bir süre boşta kaldıktan sonra düşük sıklıkta heartbeat başlatmak;
• ağ değişikliğinden sonra kontrolleri geçici olarak artırmak;
• tekrarlanan başarısızlıklardan sonra bağlantıyı kesilmiş olarak işaretlemek.

---

19. Aşama: Ağ Değişiklikleri ve Oturum Kurtarma

Bir telefon Wi-Fi’dan 5G’ye geçtiğinde özgün bağlantı genellikle geçersiz hâle gelir.

Eksiksiz bir müdahale şöyle olmalıdır:

Ağ değişikliğini algıla
        ↓
Arızalı kanal üzerinden yeni veri göndermeyi durdur
        ↓
Yeni yerel IP’yi ve rotayı al
        ↓
Özgün düğüme yeniden bağlan
        ↓
Oturum kurtarma kimlik bilgisini gönder
        ↓
Sunucu eski Session’ı doğrular
        ↓
Kurtarılabilir mantıksal Stream’leri kurtar
        ↓
Kurtarılamayan TCP bağlantılarını yeniden kurmalarını uygulamalara bildir

Önemli bir sınırlama:

Her uygulama TCP bağlantısı kesintisiz şekilde kurtarılamaz.

Protokol şunları kurtarabilir:

• Session durumu;
• düğüm yetkilendirmesi;
• protokol parametreleri;
• durumu hâlâ geçerli olan bazı Stream’ler.

Ancak hedef web sitesinin kendi TCP bağlantısı sona erdiyse uygulamanın yine de yeniden bağlanması gerekebilir.

Bu nedenle şu şekilde tanıtılmamalıdır:

Her uygulama ağ değişikliğini her zaman hiç kesinti yaşamadan atlatır.

Daha doğru bir ifade şudur:

SingLink 2.0 yeniden bağlanma süresini kısaltır, protokol ve yönlendirme durumunu geri yükler ve uygulamalar üzerindeki etkiyi en aza indirmeye çalışır.

---

20. Aşama: Düğüm Arızası ve Otomatik Geçiş

Düğüm hataları şu şekilde ayrılabilir:

Hafif arıza

• artan gecikme;
• ara sıra paket kaybı;
• geçici yanıt vermeme;
• bazı hedeflere ulaşılamaması.

Müdahale:

• kısa bir süre beklemek;
• aktarım baskısını azaltmak;
• yeniden ölçmek;
• aynı düğüme yeniden bağlanmak.

Ağır arıza

• düğüme ulaşılamaması;
• kimlik doğrulama arayüzünün kullanılamaması;
• süregelen zaman aşımı;
• düğümün hizmetten kaldırılması.

Müdahale:

1. Özgün düğümü kullanmayı bırak.
2. Kill Switch’i etkinleştir.
3. Kullanılabilir listeden bir alternatif seç.
4. Yeni ve güvenli bir Session kur.
5. DNS’i ve rotaları geri yükle.
6. Gerekli bağlantıları yeniden kurmalarını uygulamalara bildir.

Üretimdeki 2.0, kısa süreli dalgalanmaların düğümler arasında tekrar tekrar geçişe neden olmaması için daha temkinli geçiş yapabilir.

Beta daha agresif biçimde yeniden bağlanabilir veya yüksek hızlı düğümleri seçebilir, ancak bu daha fazla değişkenliğe yol açabilir.

---

21. Aşama: Verilerin Geri Dönmesi ve Kapsülün Açılması

Hedef web sitesinin yanıtı şu akışı izler:

Hedef web sitesi veri döndürür
        ↓
SingLink düğümü veriyi alır
        ↓
Eşleşen Session ve Stream’i bul
        ↓
SingLink veri çerçevesi olarak kapsülle
        ↓
Şifrele ve istemciye gönder
        ↓
İstemci bütünlüğü doğrular
        ↓
Şifreyi çöz
        ↓
Stream ID’ye göre ayrıştır
        ↓
TUN’a veya sistem proxy’sine yaz
        ↓
Kaynak uygulamaya geri döndür

İstemcinin şunları kontrol etmesi gerekir:

• verinin değiştirilip değiştirilmediği;
• sıra numaralarının doğru olup olmadığı;
• çerçevenin yinelenmiş olup olmadığı;
• Stream’in hâlâ var olup olmadığı;
• uzunluğun sınırlar içinde olup olmadığı;
• alma penceresinin aşılıp aşılmadığı.

Geçersiz veriler doğrudan uygulamaya iletilmemelidir.

---

22. Aşama: Normal Bağlantı Kesme ve Güvenli Temizlik

Kullanıcı Bağlantıyı Kes’i seçtiğinde istemci şunları yapmalıdır:

1. proxy üzerinden geçecek yeni trafiği kabul etmeyi durdurmak;
2. etkin Stream’leri normal şekilde kapatmak;
3. düğüme Session sonlandırma bildirimi göndermek;
4. oturum anahtarlarını silmek;
5. kısa ömürlü belirteçleri iptal etmek veya atmak;
6. TUN’u kapatmak;
7. sistem rotalarını geri yüklemek;
8. DNS’i geri yüklemek;
9. Kill Switch kurallarını kaldırmak;
10. gereksiz geçici yapılandırmaları kaldırmak.

İstemci çökerse, işletim sisteminin veya bir sonraki açılışın da şunları geride bırakmamak için bir onarım yolu olmalıdır:

• geçersiz bir sistem proxy’si;
• yanlış DNS;
• artık rotalar;
• internet erişiminin olmaması;
• kalıcı olarak kilitli kalan bir Kill Switch.

---

SingLink Beta ile 2.0 Arasındaki Ayrıntılı Strateji Farkları

Aşağıdakiler ürünün teknik konumlandırmasını ifade eder; kesin parametreler hâlâ mühendislik onayı gerektirir.

İşleme alanı	SingLink Beta	SingLink 2.0
Ana yön	Zirve hız	Hız, kararlılık, uyumluluk
Bağlantı parametreleri	Daha agresif	Uyarlanabilir ve daha temkinli
Eşzamanlılık	Daha yüksek eşzamanlılık kullanabilir	Tek bir akışın kanalı doldurmasını önler
Aktarım penceresi	Veri hacmine (throughput) öncelik verir	Gecikme ve kayba göre dinamik olarak ayarlanır
Düğüm değiştirme	Yüksek hızlı düğümleri daha erken dener	Geçiş yapmadan önce arızayı doğrular
Çoğullama	Yeniden kullanım verimliliğine öncelik verir	Yeniden kullanım ile arıza yalıtımını dengeler
Padding	Daha düşük ek yüke öncelik verir	Ortama uyum sağlar
Ağ değişikliği	Temel kurtarma	Daha eksiksiz kurtarma ve uyumluluk
Platform regresyon testleri	Önizleme kapsamı	Tam üretim testleri
İç testlerde kararlılık	Yaklaşık %97	%99.5
Hız	Uygun koşullarda 1 Gbps’nin üzerinde	Yalnızca zirve hızı kovalamadan hızlı kalır

---

Eksiksiz İşleyiş İlkesi Tek Paragrafta

SingLink önce istemcinin cihaz trafiğinin denetimini üstlenmesini ve DNS işlemeyi, akıllı yönlendirmeyi ve düğüm seçimini tamamlamasını sağlar. Ardından hesap ve düğüm haklarını doğrular, düğümle protokol yeteneklerini müzakere eder ve geçici şifreleme anahtarları oluşturur. Bağlantı kurulduktan sonra her uygulamanın TCP ve UDP trafiği bağımsız bir proxy bağlantısı veya mantıksal Stream olarak kapsüllenir ve korumalı bir kanal üzerinden, hedef web sitesine erişen düğüme taşınır. Aktarım sırasında sistem akış pencerelerini, veri bütünlüğünü, gecikmeyi, paket kaybını, heartbeat’leri ve düğüm durumunu sürekli yönetir. Ağ değiştiğinde veya bir düğüm arızalandığında Session’ı yeniden kurar, rotaları geri yükler ya da kullanılabilir bir düğüme geçer.

Beta ile 2.0 arasındaki temel fark şudur:

SingLink Beta zirve hızı daha agresif biçimde hedefler. SingLink 2.0 ise yüksek hızlı aktarımı korurken daha eksiksiz uyumluluk, sağlık kontrolleri, hata sınıflandırması, oturum kurtarma ve platformlar arası işleme ekler; bu sayede daha yüksek kararlılığa ulaşır.

---

Sıkça Sorulan Sorular (FAQ)

SingLink 2.0 nedir?

SingLink 2.0, SingLinkVPN tarafından geliştirilen resmî ağ aktarım protokolüdür. Kimlik doğrulama, şifreli oturumlar, trafik kapsülleme, TCP ve UDP aktarımı, sağlık kontrolleri ve hata kurtarma işlemlerini yürütür.

SingLink 2.0 bir yazılım sürümü mü?

Hayır, SingLink 2.0 bir yazılım sürümü değil, protokolün resmî adıdır. Windows, macOS, Android ve iOS istemci sürümleri ayrı bir sürümleme sistemi kullanır.

SingLink Beta ile 2.0 arasındaki fark nedir?

Beta, uygun koşullarda zirve hızı 1 Gbps’yi aşabilen, hızı önceleyen bir önizleme protokolüdür. 2.0 ise hız, kararlılık, platformlar arası uyumluluk ve bağlantı kopmalarından kurtarmaya önem veren üretim protokolüdür.

SingLink 2.0’ın kararlılık oranı nedir?

SingLinkVPN’in belirli koşullar altında yaptığı iç A/B testinde SingLink 2.0’ın kararlılığı %99.5’e ulaştı, Beta’nınki ise yaklaşık %97’ye kadar çıktı.

SingLink ağ trafiğini nasıl işler?

SingLink istemcisi önce sistem trafiğinin denetimini üstlenir, DNS işleme ve akıllı yönlendirme yapar. Ardından hesap ve düğüm haklarını doğrular, şifreli bir Session kurar, TCP veya UDP verisini kapsüller ve bir düğüme gönderir.

SingLink bağlantı kopmalarını nasıl ele alır?

SingLink gecikmeyi, paket kaybını, heartbeat’leri ve düğüm durumunu sürekli kontrol eder. Bir hatadan sonra Session’ı yeniden kurabilir, rotaları geri yükleyebilir veya kullanılabilir bir düğüme geçebilir.

SingLink, VLESS’ten nasıl farklıdır?

VLESS esas olarak kimliği, komutları ve hedefe iletimi tanımlar. SingLink ise kimliği, yönlendirmeyi, düğüm haklarını, aktarım politikasını, sağlık kontrollerini ve hata kurtarmayı daha kapsamlı bir protokol sisteminde birleştirir.

SingLink, AnyTLS’ten nasıl farklıdır?

AnyTLS esas olarak bir TLS bağlantısı üzerinde bir Session ve birden fazla Stream taşır. SingLink’in ürün rolü daha geniştir; akıllı yönlendirmeyi, üyelik haklarını, düğüm planlamasını ve bağlantı kurtarmayı da kapsar. Session ve Stream’in gerçek uygulaması resmî teknik belgelere tabidir.

SingLink 2.0’ı kimler kullanabilir?

Üretimdeki SingLink 2.0 protokol düğümleri şu anda esas olarak Pro, Max ve Rich kullanıcılarına açıktır. Beta protokolü tüm üyelere açıktır. Gerçek erişim için en güncel istemcide gösterilen bilgiler esas alınır.

SingLink 2.0 tamamen açık kaynak mı?

Çekirdek protokolün kaynak kodu henüz tamamen herkese açık değil; ancak teknik belgeler, test yöntemleri, veri biçimleri, doğrulama araçları ve güvenlik açığı ifşa mekanizması süregelen açık kaynak planının bir parçasıdır.

---

Kaynaklar ve Ek Okumalar

Bu makaledeki ürün konumlandırması ve herkese açık kapsam ifadeleri ayrıca resmî SingLinkVPN teknoloji merkezine, SingLinkLabs herkese açık araştırma deposuna ve bu deponun performans kıyaslama metodolojisine dayanır.

İlgili okumalar arasında eksiksiz SingLinkVPN Ücretsiz Plan rehberi, SingLinkVPN açık kaynak planı ve 2026 SingLinkVPN güvenlik denetimi raporu yer alır.

Teknik not: %99.5, yaklaşık %97 ve 1 Gbps’nin üzerindeki rakamlar sırasıyla belirli koşullar altındaki iç A/B kararlılık sonuçları ve zirve veri hacmi sonuçlarıdır. Her bölgenin, cihazın, operatörün, ağın veya zaman diliminin aynı sonucu vereceği anlamına gelmez. Belirli şifreleme algoritmaları, paket biçimleri, Session mekanizmaları ve Stream mekanizmaları gelecekteki resmî SingLink teknik belgelerine ve yayımlanan kaynak koduna tabidir.