Perché Tor sembra più lento di una VPN: clic contro download
Il ritardo di Tor e VPN colpisce carichi di lavoro diversi: diagnostica la pagina appiccicosa prima di dare la colpa alla larghezza di banda, poi cambia una variabile per prova.
Le pagine che sembrano appiccicose mentre i download procedono a ritmo normale descrivono andate e ritorni, non larghezza di banda. Una VPN aggiunge un salto cifrato e un circuito Tor ne aggiunge diversi, e ogni salto in più costa una stretta di mano prima che si muova un solo byte utile. Quel costo si vede su una pagina che apre molte connessioni brevi e quasi svanisce in un unico trasferimento grande. Una volta visibile lo schema, la discussione smette di riguardare quale strumento sia più veloce.
Il sintomo punta al costo di configurazione, non alla capacità
Caricare una pagina è una catena di scambi dipendenti: una ricerca del nome, una stretta di mano di trasporto, una stretta di mano TLS, poi la prima richiesta. Ogni salto del percorso inserisce il proprio andata e ritorno in quella catena prima che qualsiasi cosa venga disegnata. Un download grande paga lo stesso costo di configurazione una volta e poi fluisce, ed è esattamente per questo che i due carichi di lavoro non concordano.
Leggi nel pannello di rete il tempo di attesa prima del primo byte, non il totale. Un'attesa lunga con un download di contenuto breve punta agli andate e ritorni, mentre un download lungo con un'attesa breve punta al rendimento. Ripeti verso una seconda destinazione, perché un solo host dietro un relè occupato non dimostra nulla. Quando il trasferimento va bene e il clic è lento, sospetta il costo di configurazione molto prima della larghezza di banda.
Ritardo e capacità falliscono in modi diversi
Prendi due letture e la maggior parte della confusione si risolve da sola. La latenza è un costo fisso per scambio e la capacità è una velocità nel tempo, quindi un percorso può essere buono nella prima e cattivo nella seconda. Un endpoint lontano con un processore inattivo risponde rapidamente a una richiesta piccola e limita comunque un trasferimento sostenuto a ciò che consente il suo collegamento in salita. Gli utenti vivono questa separazione come un clic scattante seguito da una barra di avanzamento che si muove appena.
Prova la capacità con un trasferimento sostenuto e osserva se la velocità resta stabile o a denti di sega. Prova la latenza con una richiesta piccola ripetuta molte volte e leggi la dispersione invece del campione migliore, perché una dispersione ampia si sente peggio di quanto suggerisca la sua media. Annota entrambi i numeri prima e dopo ogni modifica, altrimenti attribuirai il merito alla variabile sbagliata.
Trattare le due come un unico numero produce correzioni che non muovono mai la misura che ti interessa. È il modo più comune in cui una lamentela sulla latenza riceve come risposta un potenziamento della larghezza di banda.
L’instradamento a cipolla aggiunge salti che non hai scelto
Un circuito Tor usa di solito tre relè — una guardia, un nodo intermedio e un'uscita — e il client li sceglie da un consenso, non da una mappa. Il percorso può quindi essere molto più lungo della linea diretta verso la destinazione. Ogni relè trasporta anche il traffico altrui, quindi il tuo flusso condivide la capacità che resta a quel relè.
Riusare il circuito attenua il costo, perché un nuovo flusso può cavalcare un circuito esistente invece di pagare un'altra costruzione. Un client che costruisce un circuito nuovo per ogni richiesta paga la configurazione più e più volte e si sente molto peggio di uno che riusa. Anche la scelta dell'uscita conta, perché alcune uscite portano un carico più pesante e nulla nell'interfaccia ti dice su quale sei atterrato. Quella condivisione è il senso del progetto e la ragione per cui la latenza non può essere regolata su un valore fisso, quindi un'uscita lenta è una cattiva ragione per abbandonare la disposizione.
Cambiare l’ordine della catena cambia l’esperimento
Prima VPN e poi Tor è un esperimento diverso da prima Tor e poi VPN. Nella prima disposizione l'endpoint della VPN porta tutto il circuito, quindi la tua rete di accesso apprende solo l'indirizzo della VPN. Nella seconda la connessione VPN stessa viaggia dentro il percorso a cipolla, e l'uscita vede il traffico VPN. Entrambe sono progettazioni legittime, e confrontare l'una o l'altra con una VPN nuda misura qualcos'altro, per questo la pagina del progetto Tor sulla combinazione delle due la inquadra come una domanda su cosa stai cercando di nascondere prima che come una domanda sui tempi.
Tieni fissi dispositivo, rete di accesso e destinazione, e cambia esattamente un elemento tra le esecuzioni. Spostare server, circuiti e host di prova insieme produce una differenza che nessuno può attribuire. Annota cosa nasconde ogni disposizione e a chi prima di ottimizzarla, perché una catena veloce che espone ciò che volevi nascondere non è un miglioramento.
Un confronto che sopravvive a una seconda esecuzione
Scegli due o tre destinazioni che usi davvero e cronometra la stessa interazione su ciascuna, inclusa una pagina che tira molte risorse piccole e un trasferimento grande. Ripeti l'intero insieme a un'altra ora del giorno.
Riporta la mediana e il caso peggiore invece del campione più veloce, perché il lavoro interattivo si giudica dai suoi momenti brutti. Annota il client, l'endpoint o l'uscita, e se il circuito o il tunnel è stato riusato per quell'esecuzione. Se una modifica migliora la mediana ma peggiora la coda, è uno scambio e non una vittoria, e decidere se gli utenti lo noteranno è la decisione reale.