Por que Tor parece máis lento ca unha VPN: clics fronte a descargas

As páxinas que se senten pegañentas mentres as descargas van a ritmo normal describen viaxes de ida e volta, non ancho de banda. Unha VPN engade un salto cifrado e un circuíto de Tor engade varios, e cada salto extra custa un handshake antes de que se mova un só byte útil. Ese custo nótase nunha páxina que abre moitas conexións curtas e case desaparece nunha única transferencia grande. Unha vez que o patrón é visible, a discusión deixa de ser sobre que ferramenta é máis rápida.

O síntoma apunta ao custo de configuración, non á capacidade

Cargar unha páxina é unha cadea de intercambios dependentes: unha busca de nome, un handshake de transporte, un handshake TLS e despois a primeira petición. Cada salto do camiño insire a súa propia viaxe de ida e volta nesa cadea antes de que se debuxe nada. Unha descarga grande paga o mesmo custo de configuración unha vez e despois flúe, e por iso mesmo as dúas cargas de traballo non coinciden.

Le no panel de rede o tempo de espera antes do primeiro byte, non o total. Unha espera longa cunha descarga curta de contido apunta a viaxes de ida e volta, mentres que unha descarga longa cunha espera curta apunta ao rendemento. Repite contra un segundo destino, porque un só host detrás dun relé ocupado non demostra nada. Cando a transferencia vai ben e o clic é lento, sospeita do custo de configuración moito antes que do ancho de banda.

A latencia e a capacidade fallan de formas distintas

Toma dúas lecturas e a maior parte da confusión resólvese soa. A latencia é un custo fixo por intercambio e a capacidade é unha taxa ao longo do tempo, así que un camiño pode ser bo na primeira e malo na segunda. Un punto final afastado cun procesador inactivo responde rápido a unha petición pequena e aínda así limita unha transferencia sostida ao que permite a súa ligazón ascendente. Os usuarios viven esa separación como un clic áxil seguido dunha barra de progreso que apenas se move.

Proba a capacidade cunha transferencia sostida e observa se a taxa se mantén estable ou fai serra. Proba a latencia cunha petición pequena repetida moitas veces e le a dispersión en lugar da mellor mostra, porque unha dispersión ampla sente peor do que suxire a súa media. Anota ambos os números antes e despois de cada cambio, ou logo atribuirás o mérito á variable equivocada.

Tratar as dúas como un só número produce correccións que nunca moven a medición que che importa. É a forma máis común de que unha queixa de latencia reciba como resposta unha mellora de ancho de banda.

O encamiñamento en cebola engade saltos que non escolliches

Un circuíto de Tor adoita usar tres relés — un garda, un nodo medio e unha saída — e o cliente escolleos dun consenso, non dun mapa. Por iso o camiño pode ser moito máis longo ca a liña directa ata o destino. Cada relé tamén transporta o tráfico doutras persoas, así que o teu fluxo comparte a capacidade que lle quede a ese relé.

Reutilizar o circuíto suaviza o custo, porque un fluxo novo pode viaxar sobre un circuíto existente en lugar de pagar outra construción. Un cliente que constrúe un circuíto novo por petición paga a configuración unha e outra vez e sente moito peor ca un que reutiliza. A elección de saída tamén importa, porque algunhas saídas levan máis carga e nada na interface che di en cal aterrache. Ese reparto é o sentido do deseño e a razón pola que a latencia non se pode axustar a un valor fixo, así que unha saída lenta é unha mala razón para abandonar a disposición.

Cambiar a orde da cadea cambia o experimento

VPN primeiro e Tor despois é un experimento distinto de Tor primeiro e VPN despois. Na primeira disposición o punto final da VPN transporta todo o circuíto, así que a túa rede de acceso só coñece o enderezo da VPN. Na segunda, a conexión VPN viaxa dentro do camiño de cebola e a saída ve o tráfico da VPN. Ambos son deseños lexítimos, e comparar calquera deles cunha VPN espida mide outra cousa, por iso a páxina do proxecto Tor sobre combinar as dúas o expón como unha pregunta sobre que intentas agochar antes ca como unha pregunta sobre tempos.

Mantén fixos o dispositivo, a rede de acceso e o destino, e cambia exactamente un elemento entre execucións. Mover servidores, circuítos e hosts de proba á vez produce unha diferenza que ninguén pode atribuír. Anota que agocha cada disposición e ante quen antes de optimizala, porque unha cadea rápida que expón o que querías agochar non é unha mellora.

Unha comparación que sobrevive a unha segunda execución

Escolle dous ou tres destinos que realmente uses e cronometra a mesma interacción en cada un, incluída unha páxina que tira moitos recursos pequenos e unha transferencia grande. Repite todo o conxunto a outra hora do día.

Informa da mediana e do peor caso en lugar da mostra máis rápida, porque o traballo interactivo xúlgase polos seus malos momentos. Anota o cliente, o punto final ou a saída, e se o circuíto ou o túnel se reutilizaron nesa execución. Se un cambio mellora a mediana pero empeora a cola, é un intercambio e non unha vitoria, e decidir se os usuarios o notarán é a decisión real.