23

cURL 経由でソーシャル メディア API をクエリする Python アプリケーションを作成しています。私が照会するさまざまなサーバー (Google+、Reddit、Twitter、Facebook など) のほとんどで、cURL が不平を言っています。

追加のものは正常に転送されません.c:1037: 0 0

通常とは異なる点として、アプリケーションの初回起動時に、各サービスの応答でこの行が 1 回または 2 回スローされます。数分後、線が数回表示されます。明らかに、cURL は気に入らないものを特定しています。約 30 分後、サーバーがタイムアウトし始め、この行が何十回も繰​​り返されるため、実際の問題が示されています。

これをどのように診断できますか？Wireshark を使用して要求ヘッダーと応答ヘッダーをキャプチャし、cURL が不平を言う原因となる可能性のある異常を検索しようとしましたが、Wireshark のすべての複雑さのために、ヘッダーのみを分離して表示する方法はないようです。

コードの関連部分は次のとおりです。

output = cStringIO.StringIO()
c = pycurl.Curl()
c.setopt(c.URL, url)
c.setopt(c.USERAGENT, 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0')
c.setopt(c.WRITEFUNCTION, output.write)
c.setopt(c.CONNECTTIMEOUT, 10) 
c.setopt(c.TIMEOUT, 15) 
c.setopt(c.FAILONERROR, True)
c.setopt(c.NOSIGNAL, 1)

try:
    c.perform()
    toReturn = output.getvalue()
    output.close()
    return toReturn

except pycurl.error, error:
    errno, errstr = error
    print 'The following cURL error occurred: ', errstr
4

3 に答える 3

29

これは実際にはどの HTTP ヘッダーにも含まれていないことは 99.99% 確信していますがstderr、libcurl. おそらくこれは、ヘッダーをログに記録している最中に発生する可能性があり、それが混乱した理由です。

とにかく、ソースの最近の変更をすばやく検索すると"additional stuff not fine" curl transfer.c、説明は次のとおりです。

Curl_readwrite: デバッグ出力を削除

「additional stuff not fine」というテキストは、少し前にデバッグ目的で追加されましたが、実際には誰の役にも立たず、何らかの理由で一部の Linux ディストリビューションは、デバッグ情報を使用してビルドされた libcurls を提供しているため、(あまりにも多くの) ユーザーが存在します。この情報を読んでください。

libcurlしたがって、これは基本的に無害であり、これが表示される唯一の理由は、完全なデバッグ ログが有効になっている (おそらく Linux ディストリビューションからの)ビルドを取得したことです(作成者はそれcurlを悪い考えだと考えていますが)。したがって、次の 3 つのオプションがあります。

  1. それを無視します。
  2. の新しいバージョンにアップグレードしlibcurlます。
  3. libcurlデバッグ情報なしで再構築します。

libcurl(上にリンクされている) のソースを見て、transfer.c何が不満なのかを理解しようとすることができcurlます。メーリング リストで同じ時期のスレッドを探すか、メーリング リストにメールして質問してください。

ただし、最初からこれを見ていることを考えると、実際には実際の問題にはまったく関係がないのではないかと思います。

ここで明らかに間違っている可能性があることが 3 つあります。

  1. curl のバグ、または使用方法。
  2. ネットワークの設定に問題があります (例: ISP は、発信接続が多すぎるか、30 分間に使用するバイト数が多すぎるため切断します)。
  3. あなたがしていることは、サーバーにあなたがスパマー/ DoS攻撃者/その他のものであると思わせ、ブロックしていることです.

最初のものは、実際には最も可能性が低いようです。除外したい場合は、作成したすべてのリクエストをキャプチャしてから、他のライブラリを使用してまったく同じリクエストを再生する簡単なスクリプトを作成し、同じ動作が得られるかどうかを確認してください。もしそうなら、問題は明らかにあなたの要求をどのように行うかの実装にあるはずはありません.

ケース 2 とケース 3 は、タイミングによって区別できる場合があります。すべてのサービスが一度にタイムアウトする場合、特に、異なる時間にアクセスを開始した場合でも、すべてのサービスがタイムアウトする場合 (たとえば、Facebook の 15 分後に Google+ のアクセスを開始し、Facebook の 30 分後に両方ともタイムアウトになる場合)。 、それは間違いなくケース 2 です。そうでない場合は、ケース 3 である可能性があります。

これら 3 つすべてを除外した場合は、他に問題がある可能性があるものを探し始めることができますが、ここから始めます。

または、あなたのアプリが何をしているかについて詳しく教えていただければ (例えば、できるだけ早くサーバーに何度もアクセスしようとしますか? 多数の異なるユーザーに代わって接続しようとしますか? を使用していますか?開発キーまたはエンドユーザー アプリ キーなど)、これらのサービスの経験が豊富な他の誰かが推測できる可能性があります。

于 2012-12-18T23:52:50.133 に答える
4

これには同意しません。BIGIP LTM 外部 VIP アドレスを介して Web サイトを呼び出そうとすると、同じメッセージが表示されます。

例えば：

私はウェブサイトhttp://11five.10.10.10/index.htmlを呼び出します (この場合、IP アドレスはランダムです)。BIG F5 は、仮想サーバーに関連付けられたプールを介して、2 つの内部 Web サーバー (17two.20.0.10 および 17two.20.0.11) へのトラフィックを負荷分散する必要があります。

この場合、外部ソース (内部クライアント) から TCP 80 上の VIP アドレスに送信される要求は、2 つの Web サーバー間でラウンドロビンする必要があります。私が見つけたのは、すべてのサーバーが最初の SYN パケットを受信し、SYN-ACK を受信しないことです。

実サーバーが存在するローカル サブネット内の端末に座っている場合、17two.20.0.11 からhttp://17two.20.0.10 }/index.html にソースされる index.html Web ページを "wget" できます。

外部から、*additional stuff not fine transfer.c:1037 0 0 メッセージが表示されます。

libcurl ライブラリの古いリビジョンに組み込まれた CURL のデバッグ メカニズムであると言うのは正しいですが、以下のステートメントには同意しません。

A bug in curl, or the way you're using it.
Something wrong with your network setup (e.g., your ISP cuts you off for making too many outgoing connections or using too many bytes in 30 minutes).
Something you're doing is making the servers think you're a spammer/DoS attacker/whatever and they're blocking you.

これを引き起こしているのは、IE 環境内のネットワークの問題です。Web サーバーはトラフィックを元のソースに戻すことができないため、このエラーまたは 2 つが表示されます。要求ヘッダーと応答に問題があります。ウェブサーバーから。

この場合、元の問題は、ローカル サブネット内のテスト ホストからの元の要求で異なる UR を使用して curl を実行したときに、index.html Web ページを正常に取得できた可能性が高いと言うことにします。これは、サーバーが FQDN とサーバーの短い名前を使用して接続をリッスンし、受け入れていることを意味します。

このエラーは、カールが不明な応答を受信したため、上記のエラーが発生したことを示唆していると思います。curl を開発したり、ソース コードを読んだりしないと、これ以上コメントできません。

このロジックに疑問を呈する追加の回答は大歓迎です-すべては新しいことを学ぶためです.

アンディ

于 2013-04-21T09:40:24.253 に答える