2010-12-21 99 views
5

全部搜索後,我不明白爲什麼向遠程啓用SSL的主機發出的cURL請求在我的情況下只有50%左右的時間成功。情況如下:我使用PHP CLI運行的單個PHP腳本中有一系列cURL請求,它們全部發給HTTPS遠程主機。偶爾當我運行的請求成功執行,但由於某些原因大多數時候我運行的腳本,我從捲曲以下錯誤: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 

如果我再試了幾次,我得到了相同的結果,但在幾次嘗試後,請求將成功完成。之後再次運行腳本會導致錯誤,並且該模式會繼續。研究錯誤'alert bad record mac'並沒有給我帶來任何幫助,而且我仍然毫不猶豫地將它歸咎於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」 – 2010-12-21 07:10:46

+0

相信我,我做到了。我甚至檢查過,以確保我在prefork MPM中運行Apache,而不是工作線程,因爲顯然有一個與工作線程版本相關的錯誤(我正在運行prefork,所以它沒有幫助)。 – mquinn 2010-12-21 10:57:40

+2

錯誤記錄MAC不引用網絡接口的MAC地址。它指的是「消息認證碼」 – 2012-12-18 03:26:13

回答

3

遠程主機可能不是真正的唯一主機。也許這是某種負載平衡解決方案,其中有幾臺服務器接收傳入的請求。 是什麼讓我覺得它可能是錯誤消息中的'mac error'。這可能意味着遠程主機mac地址在SSL重協同運行時發生了改變。這可以解釋,有時你沒有任何問題。

但也許不是:-) SSL問題很難找到。

我不明白你對prefork MPM vs Worker MPM的回答,如果你在cli模式下運行PHP你的apache MPM沒有使用,你甚至不使用Apache。

+0

的一個問題,負載均衡的遠程主機在我的情況下會有意義。爲了解決這個問題,我決定阻止,直到我可以得到一個有效的,非錯誤的捲曲響應並從那裏開始。最好的我現在得到了。 – mquinn 2010-12-23 06:59:57

+3

我不認爲MAC與網絡MAC地址有任何關係。它代表消息認證代碼:http://en.wikipedia.org/wiki/Message_authentication_code ...這使我得出結論:「遠程主機MAC地址」的變化與此問題無關,反之亦然。 – 2013-10-04 12:05:35

+0

@Charles Oliver Nutter很好的捕獲,但這可能仍然是一個問題,應該在主機之間共享(ssl緩存?),而不是。 – regilero 2013-10-04 14:59:21

1

您可能需要此選項:

CURLOPT_FORBID_REUSE

傳遞一個長。設置爲1以使下一次傳輸在完成時顯式關閉連接。通常情況下,libcurl在一次傳輸完成後保留所有連接,以防隨後的傳輸可以重新使用它們。這個選項應該謹慎使用,只有當你明白它的作用時。設置爲0以使libcurl保持連接打開以供將來重新使用(默認行爲)。

+0

感謝您的建議,但它是無濟於事。我以前曾嘗試過CURLOPT_FRESH_CONNECT,但這並不奏效,並且FORBID_REUSE導致了相同的舊行爲。 – mquinn 2010-12-23 06:44:07

0

你試過了嗎? curl_setopt($ handle,CURLOPT_SSLVERSION,3);