☰

Diferentes erros de curl acontecem ocasionalmente

tag-icon • tag-icon centos curl
Diferentes erros de curl acontecem ocasionalmente

Eu tenho um servidor web rodando Centos7 que faz solicitações curl para outros recursos. Com a taxa de 5 a 10 solicitações por segundo, tudo funciona bem, exceto que recebo diferentes erros de curl a cada 2 a 10 minutos. Acho que isso começou a acontecer com o tempo conforme o número de solicitações crescia, o que me faz pensar que tem algo a ver com rede, mas sou totalmente novato nisso. Como descobrir o que causa esses erros e o que posso fazer a respeito?

Network: CURL error 56: TCP connection reset by peer
Network: CURL error 7: Failed to connect to ip: Network is unreachable
Network: CURL error 18: transfer closed with 1473 bytes remaining to read

Responder1

Muito provavelmente, a causa desses erros pode ser geralmente classificada como "SNAFU"... Situação Normal, Tudo Effed Up.

A Internet é uma vasta rede de computadores e dispositivos de rede interconectados. Essas outras máquinas, sobre as quais você não tem controle, nem sempre fazem o que deveriam. Eles sofrem falhas de energia. Eles têm falhas de hardware. Eles são atingidos pela radiação cósmica. Coisas acontecem.

As tecnologias de rede que sustentam a Internet são projetadas com isso em mente. A razão pela qual a Internet funciona é um enorme nível de redundância. Se uma tentativa de conexão a um destino através de uma rota falhar... o último "salto" daquela cadeia que funcionou lembrará a falha e tentará um "próximo salto" diferente para comunicação futura. Na verdade, é muito mais complicado do que isso... mas você entendeu.

A maioria dos aplicativos da Web tentará novamente conexões com falha especificamente para aproveitar essa redundância. Nem todos eles, no entanto. Quanto mais simples for o aplicativo, maior será a probabilidade de ele simplesmente falhar. Isso se torna especialmente verdadeiro em aplicativos de terminal que aplicam os princípios *nix de ferramentas pequenas e de trabalho único. Tentar novamente é trabalho de outra ferramenta. curlé um desses aplicativos. Conformea curlpágina de manual:

--repetir

Se um erro transitório for retornado quando curl tentar realizar uma transferência, ele tentará novamente esse número de vezes antes de desistir.Definir o número como 0 faz com que o curl não faça novas tentativas (qual é o padrão). Erro transitório significa: um tempo limite, um código de resposta FTP 4xx ou um código de resposta HTTP 408 ou 5xx.

Não sei exatamente qual é o seu caso de uso para curlrecuperar recursos, mas se você estiver usando curl para fornecer recursos de maneira automatizada, definitivamente precisará configurá-lo com o --retrysinalizador com um valor de 3-5. Porque erros como você mostrou são perfeitamente normais... e precisam ser contabilizados.

2. Por que a confiabilidade do seu servidor de produção é pior do que do seu computador local?

Em um mundo perfeitoum servidor de produção sempre terá uma conexão mais confiável com recursos baseados na Internet do que qualquer conexão de Internet doméstica ou de escritório. Como esse não é o caso aqui, você tem razão em estar interessado na causa. No entanto, isso ainda não significa necessariamente que você deva se preocupar porque, novamente, isso não é necessariamente um problema causado pelo seu servidor.

Entenda que o seu computador local e o seu servidor quase certamente não compartilham a mesma rota para os recursos em questão. Por exemplo. Se eu executar um comando tracerouteno meu servidor doméstico local para dizer... superuser.comeu recebo isto:

user@home ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
 1  rtr.scrapyard.local (10.5.0.1)
 2  96.120.58.37 (96.120.58.37)
 3  po94-sr22.dothan.al.pancity.comcast.net (68.85.202.165)
 4  162.151.221.209 (162.151.221.209)
 5  be-3666-cr02.56marietta.ga.ibone.comcast.net (68.86.90.209)
 6  * * *
 7  50.242.151.138 (50.242.151.138)
 8  151.101.1.69 (151.101.1.69)

Mas se eu fizer o mesmo comando em um dos meus servidores de produção, recebo o seguinte:

user@production ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
 1  * * *
 2  ae-20-202.gw-distp-a.slr.lxa.us.oneandone.net (74.208.138.130)
 3  ae-10-0.bb-a.ga.mkc.us.oneandone.net (74.208.1.237)
 4  kanc-b1-link.telia.net (80.239.196.109)
 5  dls-b22-link.telia.net (62.115.125.159)
 6  fastly-ic-340339-dls-b22.c.telia.net (62.115.166.191)
 7  151.101.1.69 (151.101.1.69)

O único salto que essas duas rotas têm em comum é o destino. Todas as outras máquinas pelas quais passam são diferentes. Então, se, digamos, dls-b22-link.telia.netestivesse se comportando mal, isso afetaria as tentativas do meu servidor de se comunicar com superuser.com... mas não as tentativas do meu computador doméstico de fazer o mesmo.

Infelizmente, se houvereraum problema com dls-b22-link.telia.netnão haveria muito que eu pudesse fazer sobre isso. E dada a natureza intermitente do problema, não seria particularmente fácil determinar qual dls-b22-link.telia.netera a origem do problema, para começar.

Então...

2b. É realmente um problema?

A primeira coisa que você deve fazer é confirmar se isso está causando um problema real que simplesmente tentar novamente as conexões com falha não resolverá. O que significa que o seu servidor de produção está sendo prejudicado de alguma forma. Presumo que você tinha um objetivo em mente quando configurou isso.Esse objetivo ainda está sendo alcançado de tal forma que você não precisa agir?Essa é a questão chave.

Voltando ao que eu disse antes, questões intermitentes como essa simplesmente fazem parte da internet. Num mundo perfeito, isso não aconteceria, mas não vivemos num mundo perfeito... é por isso que a redundância é um princípio fundamental em todas as tecnologias nas quais a Internet é construída. É por isso que tentar novamente após esse tipo de falha de conexão é um procedimento operacional padrão. E por que você não deve se preocupar muito com essas falhas, a menos que elas prejudiquem ativamente o seu servidor.

2c. Está sob seu controle?

Você precisa restringir a origem potencial do problema. Para fazer isso, basta fazer os mesmos testes que você já fez (contando o número de falhas em um determinado período de tempo), mas desta vez faça com que o servidor solicite recursos de algum lugar radicalmente diferente. Eu sugeriria configurar um servidor web simples em seu computador doméstico com alguns arquivos semelhantes aos que você está trabalhando e usar curlem seu servidor.

Se o servidor não apresentar falhas ao fazer isso, é muito improvável que o problema esteja no seu servidor ou no provedor de hospedagem do servidor. E seus testes existentes já eliminaram sua rede local e ISP, bem como onde quer que os próprios recursos estejam hospedados, como fontes potenciais do problema. Isso deixa os nós entre o seu provedor de hospedagem e o provedor de hospedagem dos recursos e cai diretamente em “coisas sobre as quais você não tem controle”.

Se o servidorfaztiver problemas durante o teste acima, como você já eliminou sua rede local/ISP como o problema, você pode ter quase certeza de que o problema está no seu servidor ou no provedor de hospedagem do servidor. Isso significa que está sob seu controle consertar. Isso também significa que você tem mais soluções de problemas para resolver.

2d. Qual o proximo?

Se o problema não for com o seu servidor, com o provedor de hospedagem do seu servidor ou com os recursos que você está consultando... então a causa em si não está sob seu controle. Sua melhor aposta, nesse caso, é realocar o servidor (entre em contato com seu provedor de hospedagem e veja quais opções ele pode oferecer). Oter esperançaé que, ao fazer isso, você não precisará mais usar a rota que contém o nó com defeito. É uma grande provação e não há garantia de que funcione. Pode até levar a novos problemas. É por isso que isso definitivamente precisa ser um problema sério antes de você dar esse passo.

Por outro lado, se você restringiu o problema ao seu servidor ou ao provedor de hospedagem do seu servidor, provavelmente poderá consertá-lo. Se você tiver um contrato de hospedagem gerenciada, ligue para seu provedor de hospedagem e peça para eles consertarem. Se você não tiver um contrato de hospedagem gerenciada, precisará eliminar a configuração do seu servidor como um possível culpado. E é aí, infelizmente, que desço do trem. Estamos atingindo os limites da minha experiência.

Geralmente, para que seja um problema intermitente causado pelo seu servidor, provavelmente tem algo a ver com o buffer da rede ou é resultado de algum tipo de automação. Algumas suposições informadas:

  • Você tomou alguma medida para proteger seu servidor contra investigações e ataques maliciosos?
  • Você mexeu no seu /etc/sysctl.confou nos arquivos /etc/sysctl.d/?
  • Você configurou algum tipo de inspeção de pacotes com estado ou software de detecção de intrusão (firewalls baseados em iptables/netfilter, snort, etc.)?

Independentemente disso, se você estiver no ponto em que está solucionando problemas no próprio servidor, meu conselho seria pegar as informações que você coletou e fazer uma nova pergunta noFalha no servidor. As pessoas de lá têm muito mais experiência com problemas de servidor do que as pessoas aqui no SuperUser e são mais propensas a saber o que tentar em seguida.

3. Quanto à aparente consistência dos erros

Agora, por que você está recebendo o mesmo erro específico repetidamente? É difícil dizer. Supondo que realmente esteja acontecendo como um relógio a cada 5 minutos... ainda pode ser qualquer coisa. Esses dispositivos possuem relógios e temporizadores para uma ampla variedade de finalidades. Pode ser que algo que um deles esteja configurado para fazer a cada cinco minutos esteja causando esse pequeno problema.

É possível que seja um problema com o seu servidor. Ou é um problema com seu provedor de hospedagem. Ou é um problema com o ISP do seu provedor de hospedagem. Ou é um problema com o ISP de sua casa/escritório. Ou em qualquer lugar intermediário. Se não for o seu servidor e provavelmente não for baseado no que você me disse, o resultado final é que você não pode fazer muito a respeito ... exceto certificar-se de que está configurado para tentar novamente conexões com falha. Todos os navegadores modernos, por exemplo, tentam várias vezes antes de desistir de recuperar um recurso de um servidor web.

EDITAR% S

  1. Adicionada segunda e terceira seção em resposta a um comentário solicitando mais esclarecimentos
  2. Reescreveu a segunda seção para dar conta das correções.

informação relacionada