☰

때때로 다른 컬 오류가 발생합니다.

tag-icon • tag-icon centos curl
때때로 다른 컬 오류가 발생합니다.

다른 리소스에 컬 요청을 보내는 Centos7을 실행하는 웹 서버가 있습니다. 초당 5~10개의 요청 비율을 사용하면 2~10분마다 다른 컬 오류가 발생하는 것을 제외하고는 모든 것이 잘 작동합니다. 제 생각에는 요청 수가 늘어나면서 시간이 지남에 따라 이런 일이 발생하기 시작한 것 같습니다. 이로 인해 네트워크와 관련이 있다고 생각하게 되지만 저는 이 분야에 완전히 초보자입니다. 이러한 오류의 원인을 찾는 방법과 이에 대해 무엇을 할 수 있습니까?

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

답변1

아마도 이러한 오류의 원인은 일반적으로 "SNAFU"로 분류될 수 있습니다... 상황 정상, 모두 작동 중단.

인터넷은 상호 연결된 컴퓨터와 네트워킹 장비로 구성된 방대한 네트워크입니다. 당신이 통제할 수 없는 다른 기계들은 항상 해야 할 일을 하지 않습니다. 그들은 정전을 겪습니다. 하드웨어 오류가 있습니다. 그들은 우주 방사선에 노출됩니다. 일이 일어납니다.

인터넷을 뒷받침하는 네트워킹 기술은 이를 염두에 두고 설계되었습니다. 인터넷이 작동하는 이유는 엄청난 수준의 중복성 때문입니다. 하나의 경로를 통해 대상에 연결하려는 시도가 실패하면... 제대로 작동한 해당 체인의 마지막 "홉"이 실패를 기억하고 향후 통신을 위해 다른 "다음 홉"을 시도합니다. 실제로는 이것보다 훨씬 더 복잡합니다. 하지만 요점은 알 수 있습니다.

대부분의 웹 애플리케이션은 특히 이러한 중복성을 활용하기 위해 실패한 연결을 다시 시도합니다. 그러나 전부는 아닙니다. 응용 프로그램이 단순할수록 실패할 확률이 높아집니다. 이는 작은 단일 작업 도구의 *nix 원칙을 적용하는 터미널 애플리케이션의 경우 특히 그렇습니다. 재시도는 다른 도구의 작업입니다. curl그러한 응용 프로그램 중 하나입니다. 에 따라맨 curl페이지:

--다시 해 보다

컬이 전송을 시도할 때 일시적인 오류가 반환되면 포기하기 전에 이 횟수만큼 재시도합니다.숫자를 0으로 설정하면 컬이 재시도를 하지 않게 됩니다(이것이 기본값입니다). 일시적인 오류는 시간 초과, FTP 4xx 응답 코드 또는 HTTP 408 또는 5xx 응답 코드를 의미합니다.

리소스를 검색하는 데 사용하는 사용 사례가 정확히 무엇인지는 잘 모르겠지만 curl, 컬을 사용하여 자동화된 방식으로 리소스를 제공하는 경우 --retry값이 3-5인 플래그로 구성해야 합니다. 당신이 보여준 것과 같은 오류는 완전히 정상적인 것이며... 설명이 필요하기 때문입니다.

2. 로컬 컴퓨터보다 프로덕션 서버의 안정성이 더 나쁜 이유는 무엇입니까?

완벽한 세상에서프로덕션 서버는 항상 집이나 사무실 인터넷 연결보다 인터넷 기반 리소스에 더 안정적으로 연결됩니다. 여기서는 그렇지 않기 때문에 원인에 관심을 갖는 것이 옳습니다. 그러나 이것이 반드시 서버로 인해 발생하는 문제는 아니기 때문에 반드시 걱정해야 한다는 의미는 아닙니다.

로컬 컴퓨터와 서버는 문제의 리소스에 대해 동일한 경로를 거의 공유하지 않는다는 점을 이해하십시오. 예를 들어. traceroute로컬 홈 서버에서 다음을 수행하면 ... superuser.com다음과 같은 결과를 얻습니다.

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)

그러나 프로덕션 서버 중 하나에서 동일한 명령을 수행하면 다음과 같은 결과가 나타납니다.

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)

두 경로가 공통으로 갖는 유일한 홉은 목적지입니다. 그들이 통과하는 모든 기계는 다릅니다. 따라서 예를 들어, dls-b22-link.telia.net가 오작동하는 경우 내 서버가 superuser.com과 통신하려는 시도에는 영향을 미치지만 내 집 컴퓨터의 동일한 시도에는 영향을 미치지 않습니다.

불행하게도 거기에 있다면~였다그 문제 dls-b22-link.telia.net에 대해 내가 할 수 있는 일은 많지 않을 것이다. 그리고 문제의 간헐적인 특성을 고려하면 그것이 dls-b22-link.telia.net문제의 원인인지 판단하는 것이 특히 쉽지 않습니다 .

그래서...

2b. 정말 문제인가요?

가장 먼저 해야 할 일은 이것이 실패한 연결을 다시 시도하는 것만으로는 해결되지 않는 실제 문제를 일으키는지 확인하는 것입니다. 이는 프로덕션 서버가 어떤 방식으로든 작업을 수행하는 데 장애가 있음을 의미합니다. 나는 이것을 설정할 때 염두에 둔 목표를 가지고 있다고 가정합니다.조치를 취할 필요가 없을 정도로 목표가 여전히 달성되고 있나요?이것이 핵심 질문입니다.

앞서 말한 내용으로 돌아가면 이와 같이 간헐적으로 발생하는 문제는 단순히 인터넷의 일부일 뿐입니다. 완벽한 세상에서는 그런 일이 일어나지 않을 것이지만 우리는 완벽한 세상에 살고 있지 않습니다. 이것이 바로 중복성이 인터넷을 기반으로 하는 모든 기술의 기본 원칙인 이유입니다. 이것이 바로 이러한 종류의 연결 실패 후 재시도가 표준 운영 절차인 이유입니다. 그리고 서버를 적극적으로 손상시키지 않는 한 그러한 실패에 대해 너무 많이 걱정하지 않아도 되는 이유는 무엇입니까?

2c. 그것은 당신의 통제하에 있습니까?

문제의 잠재적 원인을 좁혀야 합니다. 그렇게 하려면 이미 수행한 것과 동일한 테스트를 수행하기만 하면 됩니다(주어진 시간 프레임에서 실패 횟수 계산). 그러나 이번에는 서버가 근본적으로 다른 곳에서 리소스를 요청하도록 합니다. 나는 당신이 작업해왔던 것과 유사한 몇 개의 파일을 가지고 당신의 집 컴퓨터에 간단한 웹 서버를 설정하고 curl서버에서 그것들을 사용하는 것을 제안할 것입니다.

서버에서 이 작업을 수행하는 데 오류가 발생하지 않으면 서버나 서버의 호스팅 공급자에 문제가 있을 가능성이 거의 없습니다. 그리고 기존 테스트에서는 이미 로컬 네트워크와 ISP는 물론 리소스 자체가 호스팅되는 모든 곳에서 문제의 잠재적 원인을 제거했습니다. 이는 귀하의 호스팅 제공업체와 리소스 호스팅 제공업체 사이에 노드를 남겨두고 "귀하가 통제할 수 없는 것"에 완전히 해당됩니다.

서버의 경우하다위 테스트 중에 문제가 발생하면 이미 로컬 네트워크/isp 문제를 제거했기 때문에 문제가 서버나 서버의 호스팅 공급자에 있다는 것을 거의 확신할 수 있습니다. 이는 문제를 해결하는 것이 귀하의 통제하에 있음을 의미합니다. 이는 또한 수행해야 할 문제 해결이 더 많다는 것을 의미합니다.

2d. 다음은 무엇입니까?

문제가 서버, 서버의 호스팅 공급자 또는 쿼리 중인 리소스에 있지 않은 경우 원인 자체는 사용자가 통제할 수 없습니다. 이 경우 가장 좋은 방법은 서버를 재배치하는 것입니다(호스팅 공급자에게 문의하여 어떤 옵션을 제공할 수 있는지 확인하십시오). 그만큼희망그렇게 하면 결함이 있는 노드가 있는 경로를 더 이상 사용할 필요가 없다는 것입니다. 하지만 이는 상당한 시련이며 작동이 보장되지는 않습니다. 새로운 문제가 발생할 수도 있습니다. 그러므로 그러한 조치를 취하기 전에 이것이 확실히 심각한 문제가 되어야 하는 이유는 무엇입니까?

반면에 문제의 범위를 서버나 서버의 호스팅 공급자로 좁힌 경우 문제를 해결할 수 있습니다. 관리형 호스팅 계약이 있는 경우 호스팅 제공업체에 전화하여 문제를 해결하도록 하세요. 관리형 호스팅 계약이 없는 경우 잠재적인 원인인 서버 구성을 제거해야 합니다. 불행하게도 내가 기차에서 내리는 곳은 바로 그곳이었다. 우리는 내 전문 지식의 한계에 도달하고 있습니다.

일반적으로 서버로 인해 간헐적으로 발생하는 문제인 경우 네트워크 버퍼링과 관련이 있거나 일종의 자동화의 결과일 가능성이 높습니다. 정보에 입각한 추측:

  • 악의적인 조사 및 공격으로부터 서버를 강화하기 위한 조치를 취했습니까?
  • /etc/sysctl.conf당신 이나 의 파일을 망쳤습니까 /etc/sysctl.d/?
  • 어떤 종류의 상태 저장 패킷 검사 또는 침입 감지 소프트웨어(iptables/netfilter 기반 방화벽, snort 등)를 설정하셨나요?

그럼에도 불구하고, 서버 자체의 문제를 해결하는 시점에 있다면 수집한 정보를 바탕으로 서버 자체에 대해 새로운 질문을 하라는 조언을 드립니다.서버 오류. 그곳의 사람들은 여기 슈퍼유저의 사람들보다 서버 문제에 대해 훨씬 더 많은 경험을 갖고 있으며 다음에 무엇을 시도해야 할지 더 잘 알고 있습니다.

3. 오류의 명백한 일관성에 관하여

이제 왜 동일한 특정 오류가 계속해서 발생합니까? 말하기가 어렵습니다. 그것이 실제로 5분마다 시계처럼 일어나고 있다고 가정하면... 여전히 무엇이든 될 수 있습니다. 이러한 장치에는 다양한 목적을 위한 시계와 타이머가 포함되어 있습니다. 그 중 하나가 5분마다 수행하도록 설정된 작업으로 인해 작은 문제가 발생할 수 있습니다.

서버에 문제가 있을 가능성도 있습니다. 아니면 호스팅 제공업체의 문제일 수도 있습니다. 아니면 호스팅 제공업체의 ISP에 문제가 있는 것입니다. 아니면 집/사무실 ISP에 문제가 있는 것입니다. 아니면 그 사이 어디든지요. 그것이 귀하의 서버가 아니고 아마도 귀하가 나에게 말한 내용을 기반으로 하지 않은 경우 결론은 그것에 대해 많은 것을 할 수 없다는 것입니다... 실패한 연결을 재시도하도록 설정했는지 확인하는 것 외에는 말이죠. 예를 들어 모든 최신 웹 브라우저는 웹 서버에서 리소스 검색을 포기하기 전에 여러 번 재시도합니다.

편집

  1. 추가 설명을 요청하는 의견에 대한 응답으로 두 번째 및 세 번째 섹션을 추가했습니다.
  2. 수정 사항을 설명하기 위해 두 번째 섹션을 다시 작성했습니다.

관련 정보