☰

時々、異なるカールエラーが発生する

tag-icon • tag-icon centos curl
時々、異なるカールエラーが発生する

Centos7 を実行している Web サーバーがあり、他のリソースに curl リクエストを送信します。1 秒あたり 5 ～ 10 件のリクエストのレートで、2 ～ 10 分ごとにさまざまな curl エラーが発生することを除いてすべて正常に動作します。リクエストの数が増えるにつれて、この問題が発生するようになったと思います。これはネットワークに関係していると思いますが、私はこの分野についてまったくの初心者です。これらのエラーの原因と、それに対する対処方法を見つけるにはどうすればよいでしょうか。

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」に分類されるでしょう...状況は正常ですが、すべてがめちゃくちゃです。

インターネットは、相互接続されたコンピュータとネットワーク機器の巨大なネットワークです。制御できない他のマシンは、必ずしも期待通りに動作するとは限りません。停電が発生したり、ハードウェア障害が発生したり、宇宙放射線に襲われたり、さまざまなことが起こります。

インターネットの基盤となるネットワーク技術は、このことを念頭に置いて設計されています。インターネットが機能する理由は、膨大なレベルの冗長性にあります。1 つのルート経由で宛先に接続しようとして失敗した場合、そのチェーン内で機能した最後の「ホップ」は失敗を記憶し、将来の通信のために別の「次のホップ」を試みます。実際にはこれよりはるかに複雑ですが、要点は理解していただけると思います。

ほとんどのウェブアプリケーションは、この冗長性を利用するために失敗した接続を再試行します。ただし、すべてではありません。アプリケーションが単純であればあるほど、失敗する可能性が高くなります。これは、小さな単一ジョブツールの*nix原則を適用するターミナルアプリケーションに特に当てはまります。再試行は別のツールの仕事です。はcurlそのようなアプリケーションの1つです。マンcurlページ:

- リトライ

curl が転送を実行しようとしたときに一時的なエラーが返された場合、転送を中止する前にこの回数だけ再試行します。数値を0に設定すると、curlは再試行を行いません（デフォルトです）。 一時的なエラーとは、タイムアウト、FTP 4xx 応答コード、または HTTP 408 または 5xx 応答コードのいずれかを意味します。

curlリソースを取得するために を使用するユースケースが正確に何であるかはわかりませんが、curl を使用してリソースを自動的に提供している場合は、必ず--retry3 ～ 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)

しかし、実稼働サーバーの 1 つから同じコマンドを実行すると、次のようになります。

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)

これら 2 つのルートに共通する唯一のホップは宛先です。それらが通過する他のすべてのマシンは異なります。したがって、たとえば、dls-b22-link.telia.netが不正に動作していた場合、私のサーバーが superuser.com と通信しようとする試みに影響しますが、自宅のコンピューターが同じことをしようとする試みには影響しません。

残念ながら、だった問題があったとしても、dls-b22-link.telia.netそれについて私にできることはあまりないでしょう。また、問題が断続的に発生する性質を考えると、そもそもそれがdls-b22-link.telia.net問題の原因であると特定するのは特に簡単ではありません。

それで...

2b. それは本当に問題でしょうか?

最初にすべきことは、これが実際に問題を引き起こしており、失敗した接続を再試行するだけでは解決できないことを確認することです。つまり、運用サーバーが何らかの形でそのジョブの実行に支障をきたしているということです。これを設定したときには、何らかの目標を念頭に置いていたと思います。その目標は、行動を起こす必要がないほど達成され続けていますか?それが重要な質問です。

前に述べたことに戻ると、このような断続的な問題はインターネットの一部にすぎません。完璧な世界ではこのような問題は発生しませんが、私たちは完璧な世界に住んでいません...だからこそ、冗長性はインターネットの基盤となるすべてのテクノロジーの基本原則なのです。このような接続障害の後に再試行することが標準的な運用手順であるのもそのためです。そして、サーバーに実際に障害が発生しない限り、このような障害についてあまり心配する必要はないのです。

2c. それはあなたのコントロール下にありますか?

問題の潜在的な原因を絞り込む必要があります。そのためには、すでに実行したのと同じテスト (特定の時間枠内での失敗の数を数える) を実行しますが、今回はサーバーがまったく異なる場所からリソースを要求します。自宅のコンピューターに、これまで作業していたものと似たいくつかのファイルを含むシンプルな Web サーバーを設定し、curlサーバーでそれらを取得することをおすすめします。

これを実行してもサーバーに障害が発生しない場合は、問題がサーバーまたはサーバーのホスティング プロバイダーにある可能性は極めて低いです。また、既存のテストによって、ローカル ネットワークと ISP、およびリソース自体がホストされている場所が、問題の原因となる可能性はすでに排除されています。これにより、ホスティング プロバイダーとリソースのホスティング プロバイダーの間にあるノードが残り、完全に「制御できないもの」に分類されます。

サーバーがする上記のテスト中に問題が発生した場合は、ローカル ネットワーク/ISP が問題の原因ではないことがすでに判明しているので、問題はサーバーまたはサーバーのホスティング プロバイダーのいずれかにあるとほぼ確信できます。つまり、問題は自分で解決できるということです。また、トラブルシューティングをさらに行う必要があることも意味します。

2d. 次は何?

問題がサーバー、サーバーのホスティングプロバイダー、またはクエリしているリソースにない場合は、原因自体を制御できません。その場合、最善の策はサーバーを移動することです（ホスティングプロバイダーに連絡して、どのようなオプションを提供できるかを確認してください）。希望こうすることで、障害のあるノードがあるルートを使用する必要がなくなります。ただし、これはかなりの試練であり、確実に機能するとは限りません。新しい問題を引き起こす可能性もあります。そのため、このような手順を実行する前に、これを深刻な問題として認識する必要があります。

一方、問題の原因がサーバーかサーバーのホスティング プロバイダーのどちらかに絞り込めば、おそらく修正できるでしょう。マネージド ホスティング契約を結んでいる場合は、ホスティング プロバイダーに連絡して修正してもらいます。マネージド ホスティング契約を結んでいない場合は、サーバーの構成が潜在的な原因ではないことを除外する必要があります。残念ながら、ここで私は話が終わります。私の専門知識の限界に達しています。

一般的に、サーバーによって断続的に発生する問題の場合、ネットワーク バッファリングと関係があるか、何らかの自動化の結果である可能性があります。情報に基づいた推測をいくつか挙げます。

  • 悪意のある調査や攻撃に対してサーバーを強化するための措置を講じましたか?
  • /etc/sysctl.confまたは 内のファイルをいじってしまいましたか/etc/sysctl.d/?
  • 何らかのステートフル パケット インスペクションまたは侵入検知ソフトウェア (iptables/netfilter ベースのファイアウォール、snort など) を設定しましたか?

いずれにせよ、サーバー自体のトラブルシューティングを行っている段階であれば、収集した情報を基にして、サーバー障害そこにいる人たちは、SuperUser の人たちよりもサーバーの問題に関してずっと経験豊富で、次に何を試せばよいかを知っている可能性が高くなります。

3. エラーの見かけの一貫性について

さて、なぜ同じエラーが何度も何度も発生するのでしょうか? それは分かりません。本当に 5 分ごとに時計のように発生していると仮定すると、原因はさまざまです。これらのデバイスには、さまざまな目的のために時計とタイマーが組み込まれています。そのうちの 1 つが 5 分ごとに動作するように設定されていることが、この小さな問題の原因である可能性があります。

サーバーに問題がある可能性があります。または、ホスティング プロバイダーに問題がある可能性があります。または、ホスティング プロバイダーの ISP に問題がある可能性があります。または、自宅/オフィスの ISP に問題がある可能性があります。あるいは、その中間のどこかにある可能性もあります。サーバーの問題ではない場合 (私に話してくれた内容から判断すると、おそらくサーバーの問題ではないと思われます)、結局のところ、失敗した接続を再試行するように設定されていることを確認すること以外は、対処方法はあまりありません。たとえば、すべての最新の Web ブラウザーは、Web サーバーからのリソースの取得をあきらめる前に、数回再試行します。

編集

  1. さらなる説明を求めるコメントに応えて、2番目と3番目のセクションを追加しました。
  2. 修正を考慮して 2 番目のセクションを書き直しました。

関連情報