Proxies SOCKS ou HTTP: diferenças, velocidade e escolha de protocolo
Proxies HTTP e SOCKS conectam um aplicativo a um destino por um intermediário. Para um navegador, coletor de dados ou cliente de API, um proxy HTTP com CONNECT é um ponto de partida prático. SOCKS5 é útil quando o aplicativo espera SOCKS, precisa de outros protocolos TCP ou oferece suporte ao encaminhamento de UDP. Os dois podem transportar tráfego para sites HTTPS.
O protocolo determina como o programa se comunica com o proxy. A origem do IP de saída, a rotação e o acesso compartilhado ou dedicado são escolhas separadas, explicadas no guia de tipos de proxy e escolha de configuração. Mudar de HTTP para SOCKS não altera, por si só, nenhuma dessas propriedades.
Como HTTP e SOCKS lidam com uma conexão
Encaminhamento HTTP: o proxy trata uma solicitação web
Para uma solicitação HTTP comum sem criptografia, o cliente envia ao proxy a URL de destino, o método e os cabeçalhos. O proxy processa essa solicitação e obtém a resposta do destino. Ele pode aplicar regras HTTP, mudar cabeçalhos ou usar um cache quando configurado para isso. Essas são funções possíveis de um proxy HTTP; um serviço não necessariamente habilita todas elas.
SOCKS5: o proxy abre uma conexão para o aplicativo
O cliente negocia um método de autenticação, autentica-se se necessário e fornece um endereço e uma porta de destino. O proxy então estabelece a conexão TCP solicitada e retransmite os bytes do aplicativo. O mesmo mecanismo pode transportar HTTPS, SSH ou outro protocolo de aplicativo TCP compatível. O proxy não precisa interpretar solicitações HTTP para encaminhá-las.
HTTPS por CONNECT: as duas abordagens se aproximam
Ao abrir um site HTTPS por um proxy HTTP convencional, o cliente normalmente envia uma solicitação CONNECT. Depois que o proxy aceita o túnel, o cliente estabelece TLS com o site dentro dele. O proxy retransmite os dados criptografados. SOCKS5 pode retransmitir a mesma troca TLS após sua própria preparação.
Isso importa ao comparar velocidade e privacidade: um proxy HTTP que transporta HTTPS em um túnel não interpreta cada solicitação de página criptografada. Os dois tipos retransmitem o tráfego protegido. A sequência e a distinção entre encaminhamento HTTP e tunelamento são explicadas em Proxies HTTP e HTTPS.
Visão geral de HTTP e SOCKS5
A comparação abaixo usa SOCKS5. Os protocolos mais antigos SOCKS4 e SOCKS4a têm menos recursos e são relevantes principalmente quando um software existente os exige.
| Recurso | Proxy HTTP / HTTPS | Proxy SOCKS5 |
|---|---|---|
| Solicitações web | Encaminhamento HTTP; HTTPS normalmente usa um túnel CONNECT. | O aplicativo envia HTTP ou HTTPS pela conexão estabelecida. |
| Outros aplicativos TCP | Possível por CONNECT se o cliente oferecer suporte e a porta de destino for permitida. | Adequado a aplicativos com suporte a SOCKS; as regras do serviço continuam valendo. |
| DNS do destino | O proxy pode resolver o nome de host fornecido na solicitação ou no destino de CONNECT. | O cliente pode enviar um nome de host para resolução remota ou resolvê-lo localmente primeiro. |
| Proteção até o proxy | Um proxy HTTPS usa TLS nessa conexão. Um proxy HTTP simples não usa. | Os modos comuns sem autenticação e com nome de usuário/senha não criptografam essa conexão. |
| Controle de acesso | Métodos de autenticação HTTP e/ou regras de acesso do serviço, como uma lista de IPs permitidos. | Métodos de autenticação negociados e/ou regras de acesso do serviço, como uma lista de IPs permitidos. |
| UDP | O CONNECT comum é insuficiente. UDP exige um mecanismo adicional de tunelamento compatível. | Definido pelo protocolo, mas deve ser implementado pelo cliente e pelo serviço. |
| Desempenho | Para um novo túnel HTTPS, o estabelecimento pode exigir menos viagens de ida e volta. A velocidade de transferência também depende da implementação e da rota. | Tem suas próprias trocas de preparação. A ausência de interpretação de HTTP não garante transferências HTTPS mais rápidas. |
Qual é mais rápido: HTTP ou SOCKS5?
Uma nova conexão HTTPS pode ficar pronta mais cedo por HTTP CONNECT, porque a preparação habitual exige menos trocas com o proxy. A comparação abaixo mostra as premissas por trás dessa diferença. Depois que um túnel está aberto, um download longo ou solicitações posteriores podem reutilizá-lo. Nenhum dos protocolos tem vantagem fixa na velocidade de transferência sustentada.
Conexões novas: conte as trocas
Conte as mensagens de preparação depois que a conexão TCP com o proxy estiver pronta, com cada solicitação aguardando sua resposta. Esta comparação não usa uma camada TLS até o proxy. A autenticação HTTP é desnecessária ou tem sucesso com as credenciais incluídas na primeira solicitação CONNECT.
| Método de conexão | Trocas antes de o túnel ficar pronto |
|---|---|
HTTP CONNECT | 1: a solicitação CONNECT e a resposta bem-sucedida. |
| SOCKS5 sem autenticação de protocolo | 2: seleção do método, depois a solicitação de conexão e a resposta. |
| SOCKS5 com nome de usuário e senha | 3: seleção do método, verificação de nome de usuário/senha, depois a solicitação de conexão e a resposta. |
Portanto, nessas premissas, SOCKS5 acrescenta uma viagem de ida e volta entre cliente e proxy no caso sem autenticação, ou duas com autenticação padrão por nome de usuário/senha. Uma viagem de ida e volta, ou RTT, é o tempo que uma mensagem leva para chegar ao proxy e sua resposta leva para retornar. Com um RTT ilustrativo de 50 ms, essas trocas extras representam cerca de 50 ou 100 ms. Essa é uma estimativa a partir da sequência do protocolo, não um teste de desempenho de um serviço de proxy nem o tempo total da solicitação.
Os dois caminhos também exigem que o proxy se conecte ao destino e que o cliente conclua o estabelecimento de TLS com o site. O tempo de DNS, o processamento e o congestionamento podem variar. Um desafio de autenticação HTTP acrescenta trocas; o TLS até um proxy HTTPS acrescenta sua própria preparação. Esses casos precisam ser incluídos ao comparar as configurações reais.
Conexões reutilizadas: a diferença inicial se distribui entre as solicitações
Um pool de conexões mantém conexões adequadas disponíveis para solicitações posteriores. Reutilizar uma conexão HTTPS evita repetir TCP, negociação com o proxy e o handshake TLS do site a cada solicitação. Com suporte a HTTP/2 no cliente e no destino, vários fluxos de solicitações podem compartilhar uma conexão estabelecida. Isso pode funcionar dentro de um túnel HTTP CONNECT ou de uma conexão SOCKS5; o proxy não precisa interpretar as mensagens HTTP/2 dentro do TLS.
Criar um novo objeto cliente HTTP para cada URL pode descartar seu pool de conexões. Aqui, reutilizar um cliente significa manter o objeto de software e suas conexões, não pedir ao proxy que mantenha um IP de saída. Quando um lote contata repetidamente os mesmos hosts, reutilizar essas conexões pode poupar mais trabalho de preparação do que mudar os protocolos de proxy. Destinos novos, conexões fechadas e configurações de proxy alteradas ainda podem exigir túneis novos.
Transferências grandes: observe a largura de banda disponível
Depois que um túnel é estabelecido, a velocidade de download depende da rota, da perda de pacotes, da largura de banda disponível, da carga do proxy e dos limites do serviço. Retransmitir HTTPS por CONNECT já é uma tarefa de encaminhamento de bytes. Descrever SOCKS5 como mais rápido porque ele “não lê HTTP” ignora esse caso.
Para HTTP sem criptografia, o cache ou o processamento de conteúdo configurados podem mudar o resultado. Uma resposta em cache é uma carga de trabalho diferente de baixar o mesmo conteúdo da origem. Uma comparação justa deve levar essa diferença em conta.
Qual protocolo um script web grande deve usar?
Um script web continua fazendo solicitações HTTP quando usa SOCKS5; a opção de proxy muda como ele chega ao servidor. Para um novo script que busca páginas web ou chama APIs HTTPS, comece com um cliente HTTP maduro e HTTP CONNECT, a menos que um requisito específico indique outra opção. Mantenha a escolha do proxy na configuração para que SOCKS5 possa ser testado com a mesma lógica de solicitações. Escolha uma biblioteca com suporte aos dois se essa comparação importar para o projeto.
| Carga de trabalho | Ponto de partida prático |
|---|---|
| Muitas solicitações curtas, frequentemente para hosts novos | Tente HTTP CONNECT primeiro. Sua negociação mais curta pode ajudar quando túneis novos são frequentes. Meça solicitações completas bem-sucedidas. |
| Muitas solicitações a um pequeno conjunto de APIs ou sites | Use um cliente persistente, um pool de conexões e HTTP/2 onde houver suporte. Compare HTTP e SOCKS5 depois de verificar a reutilização. |
| Arquivos grandes ou sessões TCP de longa duração | Escolha o protocolo com bom suporte e teste a taxa de transferência sustentada e as interrupções. O tempo de preparação representa uma parte menor do trabalho. |
| Outros protocolos TCP ou um recurso de UDP obrigatório | Considere SOCKS5 se o aplicativo oferecer suporte ao modo necessário. Se UDP for essencial, verifique se o aplicativo e o serviço conseguem trocar datagramas pelo proxy. |
Tanto HTTP quanto SOCKS5 podem ser usados por software assíncrono. O protocolo de proxy não determina se as solicitações são executadas simultaneamente. Verifique se a biblioteca cliente consegue usar o modo de proxy selecionado para solicitações simultâneas, manter seu pool de conexões e limitar o número de operações em andamento. Aumente a simultaneidade observando o trabalho concluído e os erros: quando o proxy, a rede ou o destino atinge seu limite, mais conexões podem significar filas maiores e mais novas tentativas.
Como comparar a velocidade antes de ampliar
- Use o mesmo programa, as mesmas solicitações de destino, tamanhos de resposta e simultaneidade. Quando possível, compare pontos de conexão de protocolo com o mesmo IP de saída e a mesma rota; caso contrário, mantenha a região de saída e os limites do serviço comparáveis e registre a diferença.
- Execute uma série com conexões novas e outra com o pool normal após a preparação inicial. Mantenha o comportamento de DNS, a proteção TLS, a autenticação, a versão de HTTP e a política de novas tentativas equivalentes ou documente por que diferem.
- Meça as operações concluídas com sucesso por segundo e o tempo do lote inteiro, incluindo novas tentativas. Registre também a mediana e o percentil 95 do tempo de conclusão, os tempos limite excedidos e as operações com falha. O percentil 95 mostra o tempo dentro do qual 95% das operações medidas terminam.
- Para downloads, registre os bytes úteis recebidos por segundo. Para solicitações curtas, separe o estabelecimento da conexão do tempo até o primeiro byte e do tempo total de resposta. O tempo até o primeiro byte também inclui a espera para o destino gerar uma resposta.
- Repita execuções alternadas pelas duas configurações e verifique a rota de proxy pretendida. Se um teste usa outro pool de saída ou recorre a uma conexão direta, seu resultado não isola o protocolo de proxy.
Escolha a configuração que conclui o trabalho real mais rápido com uma taxa de erros aceitável. Uma falha rápida de autenticação ou uma resposta incompleta não representa trabalho útil concluído. Se as duas tiverem desempenho semelhante, prefira a que for mais simples de manter no aplicativo escolhido.
Por que o suporte do aplicativo vem primeiro
Um campo com o rótulo “proxy” não promete todos os protocolos ou métodos de autenticação. Por exemplo, o tratamento integrado de SOCKS5 no Chrome oferece suporte a solicitações TCP, mas não implementa autenticação SOCKS5 com nome de usuário/senha nem encaminhamento UDP. Um serviço SOCKS5 com esses recursos não pode fazer um modo de navegador sem suporte usá-los.
Para SSH, transferência de arquivos ou outro aplicativo TCP, o suporte nativo a SOCKS pode ser conveniente. HTTP CONNECT também pode transportar outros protocolos TCP, desde que o programa consiga criar o túnel e o proxy permita a porta de destino. Portanto, “proxy HTTP” nem sempre significa “somente tráfego web”.
As configurações de proxy do navegador também não abrangem automaticamente outro programa nem todos os recursos dentro do navegador. Adaptadores externos têm seu próprio alcance e suas próprias restrições. As diferenças de versão e a negociação são abordadas em Proxies SOCKS5 e SOCKS4.
Quem resolve o nome de host do destino?
Com SOCKS5, o aplicativo pode resolver o destino localmente e enviar um endereço IP ou enviar um nome de host para o proxy resolver. No curl, socks5:// seleciona a resolução local do destino, enquanto socks5h:// solicita a resolução pelo proxy. A letra extra seleciona o comportamento do cliente; ela não cria um novo protocolo SOCKS.
Proxies HTTP também podem resolver nomes de destino recebidos em URLs ou solicitações CONNECT. Portanto, o DNS remoto do destino está disponível com os dois protocolos. Uma consulta do lado do proxy pode retornar outro endereço de servidor e evita uma consulta local para esse destino. O cliente ainda pode precisar resolver o nome de host do próprio proxy, e outros aplicativos mantêm suas próprias configurações de DNS. Escolha o comportamento de DNS no cliente em vez de deduzi-lo do protocolo de proxy.
Qual conexão é criptografada?
Separe a proteção do conteúdo do site da proteção da conexão até o proxy. Um site HTTPS normalmente mantém os dados do aplicativo criptografados entre o cliente e o site por qualquer um dos tipos de túnel. Isso pressupõe validação normal de certificado e nenhuma interceptação TLS configurada.
Um proxy HTTPS acrescenta TLS entre o cliente e o proxy. Ele protege a solicitação ao proxy e as credenciais nessa parte da rota. Em um endereço de proxy, https:// normalmente indica essa conexão protegida. Uma configuração descrita apenas como “proxy para sites HTTPS” pode, em vez disso, significar um proxy HTTP simples que oferece suporte a CONNECT.
Credenciais HTTP Basic enviadas a um proxy HTTP simples e a troca padrão de nome de usuário/senha de SOCKS5 podem ser lidas por alguém que consegue observar esse caminho de rede sem proteção. A conexão TLS posterior com o site não protege retroativamente o login do proxy. SOCKS5 comum precisa de um transporte seguro separado quando essa proteção é necessária.
O proxy continua sendo um ponto de conexão da sua própria conexão TLS e sabe aonde foi solicitado que ele se conecte. Se o destino final usa HTTP simples, o TLS até o proxy não criptografa a conexão HTTP seguinte. Da mesma forma, o encaminhamento SOCKS não oculta o conteúdo em texto simples apenas porque o proxy não precisa interpretá-lo.
UDP ou HTTP/3 muda a escolha?
Para um aplicativo que realmente precisa de UDP, SOCKS5 define UDP ASSOCIATE. O cliente e o serviço devem implementá-lo, e o caminho de rede deve transportar os datagramas. O HTTP CONNECT comum transporta um túnel TCP. O encaminhamento UDP baseado em HTTP é possível por mecanismos adicionais como CONNECT-UDP, mas as duas extremidades devem implementá-los.
HTTP/3 usa QUIC sobre UDP. Uma página HTTPS carregada com sucesso por um proxy não prova que HTTP/3 funciona: o cliente pode ter usado HTTP/2 ou HTTP/1.1 sobre TCP. Essa alternativa pode ser adequada para um script web; ela não pode substituir UDP em um recurso que exige datagramas. Veja UDP e QUIC por proxies para os caminhos de encaminhamento e suas limitações.
SOCKS oculta melhor o cliente?
No encaminhamento HTTP sem criptografia, um proxy pode acrescentar um cabeçalho como Forwarded que transporta informações sobre o cliente original. Um túnel HTTPS CONNECT convencional não consegue inserir esse cabeçalho na solicitação criptografada sem encerrar a conexão TLS do site. SOCKS5 também não acrescenta cabeçalhos HTTP automaticamente.
Isso não torna nenhum dos protocolos uma garantia de anonimato ou de aceitação por um site. O operador do proxy pode observar metadados de conexão, enquanto o destino pode reconhecer uma conta, cookies ou o comportamento do aplicativo. A reputação do IP de saída e o número de usuários que o compartilham são fatores separados. Mudar de HTTP para SOCKS no mesmo serviço não remove automaticamente bloqueios nem redefine uma sessão de site.
Como fazer a escolha final
Comece pelos protocolos e métodos de acesso compatíveis com o aplicativo. Para automação web comum, HTTP CONNECT é uma boa primeira opção; para um aplicativo feito para SOCKS ou para um modo UDP compatível, SOCKS5 pode ser mais adequado. Depois, escolha o comportamento de DNS e a proteção até o proxy necessários e compare o desempenho com a carga de trabalho real.
Use o nome de host e a porta reais do serviço para o protocolo selecionado. Substituir http:// por socks5:// em uma configuração não habilita SOCKS em um servidor que não o oferece. Antes de ampliar, confirme que as solicitações saem pelo proxy esperado e que uma falha do proxy não aciona silenciosamente uma rota direta indesejada.