2010-12-21 19 views
5

すべてを検索した後、私のケースでは、リモートSSL対応ホストに発行されたcURLリクエストが50%程度しか成功しなかった理由を理解できません。状況は次のとおりです。PHP CLIを使用して実行する1つのPHPスクリプト内で、一連のcURLリクエストがHTTPSリモートホストに発行されています。時折、私は要求が正常に実行されますが、何らかの理由で時間のほとんどは、私はそれを実行するスクリプトを実行したときに、私のcURLから次のエラーを取得する:cURL/PHPリクエストが時間の50%を実行する

* About to connect() to www.virginia.edu port 443 (#0) 
* Trying 128.143.22.36... * connected 
* Connected to www.virginia.edu (128.143.22.36) port 443 (#0) 
* successfully set certificate verify locations: 
* CAfile: none 
    CApath: /etc/ssl/certs 
* error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac 
* Closing connection #0 

私は再び、私は同じ結果を得る数回をしようとすると、何度か試してみると、リクエストは正常に処理されます。それ以降スクリプトを実行すると、エラーが発生し、パターンが続行されます。エラー「アラート・バッド・レコード・マック」を調べても何の助けにもならなかったし、スクリプトがまだ実行されていないのでSSL問題に責任を負うことを躊躇する。

私はUbuntu Server 10.04にphp5とphp5-curlをインストールし、最新のopensslをインストールしています。 cURL固有のオプションでは、CURLOPT_SSL_VERIFYPEERはfalseに設定され、CURLOPT_TIMEOUTとCURLOPT_CONNECTTIMEOUTの両方が4秒に設定されます。この問題をさらに詳しく示すことは、私のMac OS Xの開発マシンでも同じような状況が発生するということです。リクエストは時間のわずか50%しか過ぎません。

+0

あなたはGoogleに「エラー140943FC」を入力してください。 –

+0

私はそう信じています。私は、ワーカースレッドとは対照的に、プリフォークMPMでApacheを実行していることを確認しました。これはワーカースレッドバージョン(これは助けにならなかったので、すでに実行しています)に起因するバグです。 – mquinn

+2

不正なレコードMACは、ネットワークインターフェイスのMACアドレスを参照していません。それは "メッセージ認証コード" –

答えて

3

リモートホストは実際の一意のホストではない可能性があります。たぶん、いくつかのサーバーが入ってくるリクエストを受け取っている何らかの負荷分散ソリューションです。 私はそれがエラーメッセージの 'macエラー'である可能性があると思います。これは、SSLネゴシエーションが実行中にリモートホストのMACアドレスが変更されたことを意味する可能性があります。そして、これは時々あなたが何の問題もないことを説明することができます。

ただし、おそらく:-) SSLの問題は見つけにくいです。

私はprefork MPM vs Worker MPMについてあなたの答えを理解していませんが、あなたがapi MPMを使用しないでcliモードでPHPを実行すると、あなたはApacheを使用していません。

+0

の問題点を指しています。負荷分散されたリモートホストは私の状況では理にかなっています。私は妥当で虚偽のカール反応を得てそこから行くまでブロックすることに決めました。最高の私は今のために得た。 – mquinn

+3

私はMACがネットワークMACアドレスと関係がないと思います。それはメッセージ認証コードの略です:http://en.wikipedia.org/wiki/Message_authentication_code ...これは、 "リモートホストのMACアドレス"の変更はこの問題とは何の関係もなく、その逆の結論に導きます。 –

+0

@Charles Oliver Nutterは良いキャッチですが、これはまだホスト間で共有されるべきもの(sslキャッシュ?)とは異なるものに問題があります。 – regilero

1

は、このオプションが必要になる場合があります

CURLOPT_FORBID_REUSE

長いを渡します。終了時に次の転送が明示的に接続を閉じるようにするには、1に設定します。通常、libcurlは、それらを再使用できる後続のものがある場合に備えて、1回の転送で完了したときにすべての接続を維持します。このオプションは、何をしているのかを理解している場合にのみ、注意して使用する必要があります。 libcurlに接続を開いたままにしておくと、後で再利用できるようになります(デフォルト動作)。

+0

提案してくれてありがとうが、それは役に立たなかった。以前私はCURLOPT_FRESH_CONNECTを試していましたが、それはうまくいかず、FORBID_REUSEは同じ古い動作になりました。 – mquinn

0

試してみましたか? curl_setopt($ handle、CURLOPT_SSLVERSION、3);

関連する問題