服務(wù)器中的錯誤記錄類似于這種：

124.65.133.242 – – [27/Oct/2014:14:30:51 +0800] “-” 400 0 “-” “-”
124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] “-” 400 0 “-” “-”
124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] “-” 400 0 “-” “-”
124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] “-” 400 0 “-” “-”

踩點(diǎn)

經(jīng)過分析nginx的log文件，發(fā)現(xiàn)都是在一次正常訪問之后產(chǎn)生的數(shù)個400錯誤，每次有大概連續(xù)出現(xiàn)1-6個不等，而且也并不是每次客戶訪問都會產(chǎn)生400錯誤。

再觀察產(chǎn)生400錯誤的前一次訪問是很正常的，200狀態(tài)碼，正常的文件，正常的來路，正常的User-Agent… 一切都很和諧，那400是腫么來的呢？

通過仔細(xì)觀察發(fā)現(xiàn)，所有產(chǎn)生400錯誤的前一次訪問的User-Agent都是Google Chrome瀏覽器留下的，也就是說400錯誤是由Chrome瀏覽器產(chǎn)生的。但是經(jīng)過本地抓包發(fā)現(xiàn)，chrome是沒有向服務(wù)器發(fā)送異常請求或者數(shù)據(jù)包的。

在抓包分析中發(fā)現(xiàn)，Chrome在訪問服務(wù)器時發(fā)起的連接不止一個，一般有5到6個不等，而如果請求的資源不需要那么多連接時，Chrome就會關(guān)閉未用的連接，這項技術(shù)叫做pre-connection“預(yù)先連接”。

通常我們訪問一個網(wǎng)站時，第一個獲取的是一個html主文件，而里面鏈接了網(wǎng)頁所需要的css、js、圖片等其他媒體資源文件，而一般資源文件和主 html文件是在一個域下的，預(yù)先連接就是在獲取html之前就建立很多的tcp連接，而不是等到獲取到html文件之后再去連接服務(wù)器獲取其他的文件， 因為連接服務(wù)器是需要消耗一些時間的，所以這項技術(shù)可以很大程度上加快網(wǎng)頁的呈現(xiàn)速度。

如果網(wǎng)頁html鏈接的資源比較少，或者客戶端有緩存，不需要連接下載，那么Chrome瀏覽器發(fā)出的5-6個連接很可能只有1個是需要的，其他的 都得關(guān)閉掉，這樣就產(chǎn)生了一個問題：連接了服務(wù)器，而沒有發(fā)送任何請求。對于這種情況，nginx是當(dāng)做400錯誤來處理的，但由于連接已經(jīng)關(guān)閉，錯誤信 息不會發(fā)送到客戶端，這就產(chǎn)生了日志文件中記錄了錯誤，而抓包分析中什么也看不到的現(xiàn)象。

測試
要驗證上面的分析結(jié)果很簡單，打開命令行cmd.exe，在里面輸入telnet serverip 80，等待連接成功之后直接關(guān)掉cmd，這時去查看nginx的log文件中就多了一條400錯誤記錄。

一句評論
pre-connection的優(yōu)點(diǎn)已經(jīng)很清楚了，但是它也是有缺點(diǎn)的，如果站長做了優(yōu)化，使用了Cookie-free技術(shù)，或者網(wǎng)頁和靜態(tài)資源 使用不同的服務(wù)器，那么網(wǎng)頁需要的css、js資源就和主html不在同一個域下，也可能不在同一個IP上，那么pre-connection不僅是雞 肋，而且會對主html服務(wù)器產(chǎn)生不必要的負(fù)擔(dān)。

其它原因

網(wǎng)上很多人寫過相關(guān)的文章，大多的人的原因是因為 header 的頭部大小超了，引起響應(yīng) 400 告訴是 bad request.但其實(shí)還有一種可能，就是象端口測試工具，只是檢查端口是否是活的。像 LVS 之類什么的，也會引起這種問題，然后日志中會出現(xiàn)大量的 400 錯誤。

對于上述問題可以在nginx.conf中，將client_header_buffer_size和large_client_header_buffers都調(diào)大，可緩解此問題。

最新評論