在開發過程中常常遇到這樣的需求，模擬瀏覽器訪問某介面，並獲取返回資料。我們比較常使用的方法是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就壓縮後再返回，瀏覽器得到內容後解壓縮再顯示。但是如果內容太短的話，壓縮後體積反而會增加，再加上壓縮、解壓縮的時間，就更加得不償失了。

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