在開發過程中常常遇到這樣的需求，模擬瀏覽器訪問某接口，並獲取返回數據。我們比較常使用的方法是fsockopen與接口建立連接，然後發出指令，然後通過fgets接受返回值。

但是我們發現，通過PHP模擬訪問接口往往比瀏覽器訪問同樣的接口慢很多。這個問題困擾過我很久，今天終於找到原因了。我看網上很多朋友有同樣的問題，分享出來供大家參考。

我們常常寫這樣的代碼：

while(!feof($sHnd)) {
$line = fgets($sHnd, 4096);
}

fgets會獲取文件描述符$sHnd的當前的4096（也可能是別的常數）個字節，如果還沒有到4096個字節遇到換行符了，則只返回換行符及換行符之前的內容。

許多文檔教程裏也都是這麽講的，這段代碼許多情況下也能正常執行。我一步一步跟蹤PHP語句的耗時，發現前面若幹次的fgets都很快，最耗時的是最後一次fgets，有時長達幾秒，有時長達十幾秒。

原來這是服務器的KeepAlive功能造成的，Apache有這麽一個設置（nginx等其他web服務器也都有）：KeepAlive，如果這個設置置為On，則完成一次請求後，服務器並不會關閉TCP連接，而是保持連接等待瀏覽器下次發起其他請求時直接利用這個連接。但是當fgets獲取最後一段內容時沒有發現換行符，也沒有文件結束標誌（feof()），所以fgets獲取完內容後仍繼續等待，希望遇到換行符或者其他內容以達到4096個字符。於是，就這樣服務器和PHP耗上了，互相等待。耗了一會後，服務器先耗不起了，畢竟服務器的連接數很寶貴，當連接若幹秒沒有活動，就會關掉這個連接（Apache通過KeepAliveTimeout這個選項進行設置，這個值通常為5-15）。服務器關掉連接之後，PHP這邊的fgets這才失落得返回最後一批內容，訪問接口過程結束。

清楚了慢的原因就知道了解決方案了：

服務器返回的HTTP頭中包含有內容長度這個屬性，當已接受的內容長度與之相等時，我們就可以斷定：接口內容已經獲取完畢，不必再等了。具體做法是：每次獲取不超過剩余總長度的內容（min(4096, $leftlength)）。剩余總長度為0時，跳出while(feof($xxxxx))的循環。

經過這樣的修改，php通過sock方式訪問接口速度慢的問題已經基本解決了，但還不夠完美，繼續速度優化的思路還在KeepAlive上。

大家都知道訪問接口的耗時相當一部分是浪費在建立連接上，如果我們需要頻繁調用接口的話，還有很大的優化余地。既然服務器保持了連接，那如果PHP也把連接保存下來那是不是就不用建立連接了？答案是肯定的：第一次訪問接口時使用pfsockopen（pfsockopen與fsockopen唯一的區別就是它建立的是長連接）函數建立與服務器的連接，在訪問完成後不關掉（fclose）連接，以後的訪問就直接使用這個連接。具體到代碼裏就是：先判斷有沒有連接，如果有，繼續用，如果沒有，建立pfsockopen連接。

另外，如果接口返回內容比較短（比如：小於50字符）的話，還有優化的余地，那就是在HTTP請求頭的Accept-Encoding中去掉gzip。它的作用是告訴服務器，我（瀏覽器）可以接受壓縮過的內容，如果服務器也支持gzip就壓縮後再返回，瀏覽器得到內容後解壓縮再顯示。但是如果內容太短的話，壓縮後體積反而會增加，再加上壓縮、解壓縮的時間，就更加得不償失了。

經過以上幾步，訪問接口速度應該與瀏覽器一樣，理論上還會稍微快一點點。

http://blog.csdn.net/lzr77/article/details/9704405

http://blog.csdn.net/dazhi_100/article/details/46806519

PHP的fsockopen方式訪問接口慢的原因與優化方案