Onion servis performansı sunucu tarafında belirlenir: milisaniyeler nereye gidiyor ve operatör gerçekte neyi ayarlayabilir
Bir onion sitesi yavaş hissettirdiğinde refleks Tor ağını suçlamaktır. Bu yalnızca bir noktaya kadar adil. Gizli bir servis ziyaretçilerle hiç doğrudan konuşmaz ve her bağlantı her iki tarafın seçtiği aktarıcılarla kurulur; ama beklemenin gerçek bir payı servisin kendi makinesinde, Tor'un web backend'inin önündeki tesisatı nasıl idare ettiğinde üretilir. Hangi yarının ne olduğunu bilmek, ayarların işe yarayıp yaramadığına değil, suçun nerede durduğuna karar verir.
Milisaniyeler nereye gidiyor
Tor Project'in protokol genel bakışı tamamlanmış bir onion bağlantısını altı aktarıcıda sayar: üçünü istemci, üçünü servis seçer; rendezvous noktasında birleştirilir ve bu nokta ardından "uçtan uca şifreli mesajları istemciden servise ve tersine yalnızca aktarır" (Tor Project, onion servis protokolü). O devre var olmadan önce birkaç gidiş-dönüş harcanmıştır: istemci servisin imzalı descriptor'unu dağıtık bir hash tablosundan çeker, introduction noktalarından birine giden yolu kurar ve rendezvous'u pazarlık eder. Bunların hiçbiri backend zamanı değildir ama tamamı ziyaretçinin kronometresine düşer. Servis tarafı ayrıca hiçbir istemcinin ödemediği sabit bir maliyet taşır. Introduction noktaları servisten gelen uzun ömürlü, anonimleştirilmiş devreleri açık tutar; Tor el kitabı varsayılan havuzu üç introduction noktasına koyar, v3 serviste yirmiye çıkar. O aktarıcılar servisin tek adresi olduğundan sessizce yok olamazlar: biri düşerse servis başka bir üç sekmeli devre kurar ve imzalı descriptor'unu yeniden yayımlar - bu iş, daha soğuk ve yavaş ilk yüklemeler olarak görünür.Bir operatör gerçekte neyi kontrol ediyor
Tor kısa bir ayar listesi sunar - performans folklorünün kabul ettiğinden dar:- Kripto payı. Introduction ve rendezvous'ların ürettiği el sıkışmaları bir kripto işçi havuzu çözer; el kitabı NumCPUs'u "onionskin'leri ve diğer paralelleştirilebilir işleri çözmek için aynı anda kaç süreç kullanılacağı" olarak tanımlar. CPU'su tıkanan servis tam operatörün düzeltebileceği yerde yavaş hissettirir.
- Introduction havuzu boyutu. HiddenServiceNumIntroductionPoints varsayılanı üç; daha çok nokta, daha çok kalıcı devre bedeliyle introduction'ları daha çok aktarıcıya yayar.
- Devre tazeliği. MaxCircuitDirtiness varsayılanı on dakika ve el kitabı ekliyor: gizli servislerde yaş, devrenin trafiği son taşıdığı andan sayılır. Yükseltmek yeniden kurulumu azaltır; düşürmek daha çok kurulumu daha taze yollarla takas eder.
- Yazılım güncelliği. Tıkanıklık kontrolü 2022'de Tor 0.4.7 ile geldi ve Tor Project açık sözlüydü: "Tor 0.4.7 ve üzeri kullanıcılar, 0.4.7'ye yükseltilmiş exit veya onion servisleri kullandıklarında daha hızlı performans görecek" - eski sürümdeki bir servis her ziyaretçiyi eski akış kontrolüne hapseder (Tor Project blogu).
Tek sekmeyi çekme
Tor'un bu köşesindeki en eski performans tartışması, servise gerçekten üç sekme koruma gerekip gerekmediğidir. Roger Dingledine ve Paul Syverson'un da aralarında bulunduğu bir grup tarafından 2015'te yazılan ve Tor 0.2.9.3-alpha'da uygulanan Proposal 260, "servis tarafındaki konum gizliliğini gelişmiş performans, güvenilirlik ve ölçeklenebilirliğe takas eden" "rendezvous single onion services"i tanımlar: introduction ve rendezvous noktalarına tek sekmeli devreler ve "6 yerine 4" aktarıcıya kısaltılmış yol. Anahtar hâlâ duruyor: HiddenServiceSingleHopMode deneysel ve anonim olmayan olarak belgelenmiş; sunucuyu "kolayca bulunur" yaparken "istemciler anonim kalıyor". Takas duygusuz. Tek sekmeli bir onion .onion adresini ve ziyaretçilerinin anonimliğini korur ama operatörün kendi konum gizliliğini teslim eder - ve proposal'ın yazarları, her ek onion servis çeşidinin "anonimlik kümesini böldüğü" uyarısını yapmıştı. Bu yüzden varsayılan tasarım hayatta: tek sekme, maruz kalmayı kabul edebilen operatörler için seçmeli bir araç olarak kalıyor - Tor'un bilinçli olarak protokolün dışına bıraktığı bir yargı.Büyük siteler neden akort edilmiş backend'ler çalıştırıyor
Uzun ömürlü onion siteleri - arama motorları, aynalar, dizinler - aynı biçime yakınsıyor: ince Tor ön uçları, bilinçli olarak statik ya da önbellekli backend'ler, örnekler arasına yayılmış yük. Proposal 260, rendezvous tabanlı tek sekmeli bir servisin "birden çok rendezvous backend'i arasında yük dengeleyebileceğini" bile not ediyor. Bunların hiçbiri yolu kısaltmaz; operatörün sahip olduğu tek segmenti küçültür ki altı aktarıcılı yolculuk tek anlamlı bekleme olarak kalsın. Tor Metrics, onion trafiğini rendezvous noktası olarak görev yapan aktarıcıların istatistiklerinden dış keşirerek ölçüyor - görünür yük tam o katmanda yaşıyor (Tor Metrics).Neyi düzeltmek mümkün, neyi değil
"Onion servis yolları çıkış yollarından iki katından daha uzun olduğundan (ve dolayısıyla devre gecikmesi iki katından fazla olduğundan), onion servis verimi her zaman çıkış veriminin yarısından az olacaktır" (Proposal 324).Operatör kripto payını, havuz boyutunu, yazılım sürümünü ve backend ağırlığını düzeltebilir. Yol uzunluğunu, o günün devre kurulum sürelerini, aktarıcı tıkanıklığını ya da istemcinin kendi guard değişimini düzeltemez. Dürüst okuma: saniyeler süren ilk önbelleksiz yükleme bozuk bir site değildir - descriptor, introduction ve rendezvous'un tamaminin ödendiği andır - sıcak devre üzerindeki istekler ise backend'in kendi yanıt süresi artı geçiş süresine yakın kalmalıdır. Bir servis ilk sayfadan sonra da yavaşsa operatörün muhtemelen hareket payı var. Yalnızca gece yarısı piklerinde yavaş hissediyorsa vardiya ağın, backend'in değil - bu desen, onion gecikme değişkenliği konulu önceki saha notlarımızda belgeli. Sunucu tarafında kazanımlar gerçek ama sınırlı: torrc'nin sahibi olduğu şeyleri ayarlayın, kaynağı hafif tutun ve yolun protokolün çizdiğinden kısa olmasını ummayı bırakın.