web-dev-qa-db-ja.com

REST API呼び出しが5分を超える場合にエラー52または56を返すカール

だから私はこれを約1週間理解しようとしています。要約は次のとおりです。

PHPでCURLを使用してAPIからデータをプルします。API呼び出しへの応答が大きくなると（一度に15,000レコードをプルする）、5分以上かかるAPI呼び出しがあることに気付きました。 （数秒以内に）CentOSサーバーとSuseサーバーに戻らないので、CLIからCURL経由でAPI呼び出しをテストしたところ、同じ問題が発生しました。奇妙なことに、OS X経由でCURLコマンドを実行すると、コマンドは正常に実行されます。約7分後に戻ります。

これが私がCURL経由で実行しているコマンド（検閲されたクレジット）です：

curl -m 0 -k --trace-ascii trace.txt --trace-time -X GET -H "tenant-code: 1cmPx7tqVDVTdN1GSelwycFUmICmASnLCmNQsV72" -H "Authorization: Basic JxHAsXeUiHMRkS8Msiu6pWb3PvY20p6am3QvXCY3knXTAntlxTBS3EyEDgly" -H "Content-Type: application/json" -H "Cache-Control: no-cache" 'https://api.endpoint.com/API/v1/system/users/search?groupid=555' > dump.txt

そして、これが各プラットフォームのCURLからのバージョン出力です。

CentOS（これは私がこれを機能させるために本当に必要な場所です）-

curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

Suse-

curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

OS X-

curl 7.37.1 (x86_64-Apple-darwin14.0) libcurl/7.37.1 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps Gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz

そして、これらは私がCentosから取得したエラーコードです：

curl: (56) SSL read: errno -5961

ドキュメントで参照されているコードが見つかりません。 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/sslerr.html

Suseとは少し異なるエラーが発生します。

curl: (52) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104

エラー104は、サーバーが接続を停止/リセットしていると私に信じさせますが、サーバー側のログには接続が切断されたことが示されておらず、OSXは問題なくデータをプルできます。それが問題ではないことを確認するために、ユーザーエージェントになりすましてみました。

したがって、この時点で、SSLパッケージSecureTransportは、OpenSSLおよびNSSが実行していないことを実行していると想定しています。問題は何であり、そうでない場合、問題は何ですか？

centosphpmac-osxcurlsles
1
Hybrid

MacOSXマシンでcurlコマンドを実行しますが、出力をリダイレクトせず、シェルウィンドウにストリーミングします。 IEのように、バッファリングが関係しているように見えるかどうかを確認します。最初から少しずつ出力を取得しますか、それとも5分間何も取得せず、その後一度に大量のデータを取得しますか？

タイムアウトしたマシンでcurlコマンドを再度実行し、動作を比較します。 APIサーバーのバックグラウンドプロセスによって出力がバッファリングされている場合、クエリが完了するまで結果が得られない可能性があります。クライアントアプリケーション、クライアントのOS、サーバーのOS、サーバーのREST api、およびそれらの間のSSLのタイムアウト値がゼロ以外の場合、そのタイマーがゼロでない場合）データが5分間流れるのを見ると、理由をあまり言わずに接続が閉じる可能性があります。これはHTTPベースのサービスでよく発生します。Perlでは習慣的に$|=1;コードの先頭で、サーバー側の出力バッファリングを無効にします。

CiscoASAなどのサードパーティデバイスでNATルールのタイムアウトとトリガーの問題が発生する可能性もあります。この問題は、クライアントからの読み取りを試行しているAMANDAバックアップで発生します。 ASAの外部。クライアントがASAを介してサイズの見積もりをAMANDAサーバに返すのに時間がかかりすぎる場合、ASAは動的NATルールをドロップし、バックアップは失敗します。この提案は次のとおりです。動作するMacOSXとAPIサーバーの間にファイアウォールがないかどうかを調査する価値がありますが、失敗したMacOSXにはファイアウォールがあります。

MacOSXのタイムアウト値が0（永久に待機）に設定されていても、Linuxのデフォルトが60秒または90秒に制限されていても、少なくとも私は驚かないでしょう。

2
user207998