摘要：的運(yùn)維追蹤技巧總結(jié)曾幾何時(shí)我開(kāi)始運(yùn)維公司的網(wǎng)站，經(jīng)過(guò)一段時(shí)間的摸爬滾打，也算是總結(jié)了不少在服務(wù)器下調(diào)試追蹤各種網(wǎng)站錯(cuò)誤的方法。

曾幾何時(shí)我開(kāi)始運(yùn)維公司的LNMP網(wǎng)站，經(jīng)過(guò)一段時(shí)間的摸爬滾打，也算是總結(jié)了不少在LNMP服務(wù)器下調(diào)試追蹤各種網(wǎng)站錯(cuò)誤的方法。好記性不如爛筆頭，還是總結(jié)一下吧！

在開(kāi)始我會(huì)梳理一下我所理解的一個(gè)web請(qǐng)求從發(fā)起到響應(yīng)的各個(gè)階段服務(wù)器和瀏覽器分別做了什么。所以的用戶響應(yīng)異常都是發(fā)生在這個(gè)流程中的，知道每個(gè)流程的細(xì)節(jié)可以通過(guò)不同的方法分別定位異常發(fā)生在哪個(gè)階段，從而更準(zhǔn)確快速的定位錯(cuò)誤。后面就是持續(xù)更新的我在被這個(gè)網(wǎng)站折磨中經(jīng)歷的各種錯(cuò)誤，給自己做一個(gè)記錄，當(dāng)然如果能幫到其他人，我也很榮幸。

上圖是一個(gè)簡(jiǎn)單的web請(qǐng)求全過(guò)程，嗯，畫(huà)的確實(shí)有點(diǎn)過(guò)于簡(jiǎn)單，上圖中我隱藏了很多細(xì)節(jié)，下面一一說(shuō)明，可能有沒(méi)涉及到的地方歡迎補(bǔ)充：

用戶輸入url如http:www.baidu.com到瀏覽器，瀏覽器如chrom需要將其解析為ip地址才知道需要到哪里去訪問(wèn)哪個(gè)服務(wù)器。瀏覽器解析DNS步驟如下：

搜索瀏覽器自身的dns緩存，這個(gè)緩存緩存時(shí)間短，緩存數(shù)目有限。

搜索操作系統(tǒng)的dns緩存

讀取host文件的dns映射(一般做本地開(kāi)發(fā)映射都是修改這個(gè)文件來(lái)達(dá)到攔截瀏覽器請(qǐng)求到本地服務(wù)器的目的，從而使本地可以成功映射服務(wù)器地址)

先本地網(wǎng)卡配置里的dns服務(wù)器發(fā)起域名解析請(qǐng)求，這里好像還有一套運(yùn)營(yíng)商的處理流程就不在展開(kāi)了。

下面好像還有一些流程，由于基本不會(huì)執(zhí)行到這一步，一般所以dns運(yùn)營(yíng)商的dns服務(wù)器都會(huì)搞定的。

解析失敗，以上任何一步成功都會(huì)返回一個(gè)成功的ip地址

瀏覽器以一個(gè)隨機(jī)的端口享這個(gè)ip地址的特定端口(默認(rèn)80)發(fā)起著名的TCP3次握手。關(guān)于一個(gè)http請(qǐng)求是如何到達(dá)nginx服務(wù)的流程大致如下：

st=>start: TCP請(qǐng)求
en=>end: 異常
op=>operation: Nginx模塊
cond1=>condition: 進(jìn)入網(wǎng)卡？
cond2=>condition: 內(nèi)核的TCP/IP協(xié)議棧？
cond3=>condition: 防火墻?

st->cond1
cond1(yes)->cond2
cond1(no)->en
cond2(yes)->cond3
cond2(no)->en
cond3(no)->en
cond3(yes)->op

握手完成后的瀏覽器和服務(wù)器就可以愉快地發(fā)送http請(qǐng)求了，具體在nginx上流程如下：

st=>start: http請(qǐng)求
en=>end: response響應(yīng) 
op1=>operation: 第二步流程 
op2=>operation: nginx進(jìn)程 
op3=>operation: 獲取http的頭部信息 
op4=>operation: 匹配server_name，定位到站點(diǎn)的root 
op5=>operation: 進(jìn)入代碼框架的路由 
op6=>operation: 框架的路由解析器解析出php文件 
op7=>operation: php進(jìn)入fastcgi進(jìn)程 
op8=>operation: fastcgi進(jìn)程將php填充成html文件 
op9=>operation: html文件遞交給nginx并設(shè)置響應(yīng)信息 

st->op1->op2->op3->op4->op5->op6->op7->op8->op9->en

瀏覽器根據(jù)服務(wù)器resopnse的響應(yīng)頭和響應(yīng)體渲染出可視化頁(yè)面

上面大致梳理了下一個(gè)http請(qǐng)求在LNMP服務(wù)端體系下的流程。心中有個(gè)整體流程的概念才可以更好的追蹤實(shí)際問(wèn)題。下面就是針對(duì)上面幾個(gè)基本步驟中會(huì)出現(xiàn)的問(wèn)題的定位和追蹤。

ping www.baidu.com 檢測(cè)域名解析器是否異常

檢查域名解析是否錯(cuò)誤

telnet 127.0.0.1 80 追蹤端口是否異常

檢查端口是否打開(kāi)，防火墻是否過(guò)濾

這一步一般是網(wǎng)站出問(wèn)題的主要地方，絕大部分問(wèn)題都是出現(xiàn)在這個(gè)階段，同樣這個(gè)階段出現(xiàn)的問(wèn)題也是最難定位和解決的。為了更好的處理這個(gè)階段的問(wèn)題我們需要更深入地了解下一個(gè)web服務(wù)器與一個(gè)web程序直接的信息通信的模型與流程。

要說(shuō)明這個(gè)問(wèn)題，首先我們需要了解什么是大名頂頂?shù)腃GI協(xié)議、FASTCGI協(xié)議和PHP-FPM，以及它們之前的關(guān)系。

對(duì)于一個(gè)PHP的web程序來(lái)說(shuō)，web服務(wù)器（如：nginx）要想與它通信需要通過(guò)CGI協(xié)議。當(dāng)一個(gè)web請(qǐng)求觸達(dá)web服務(wù)器時(shí)，web服務(wù)器會(huì)創(chuàng)建一個(gè)CGI進(jìn)程,CGI進(jìn)程將web的請(qǐng)求按照固定的格式進(jìn)行解析，然后寫(xiě)入標(biāo)準(zhǔn)輸入(STDIN)和環(huán)境變量中，然后PHP啟動(dòng)的CGI解析器會(huì)從標(biāo)準(zhǔn)輸入(STDIN)和環(huán)境變量中讀取http請(qǐng)求的數(shù)據(jù)，所以$_SERVER才會(huì)有數(shù)據(jù)，然后做出相應(yīng)的邏輯處理，然后將處理結(jié)果放入標(biāo)準(zhǔn)輸出(STDOUT)，CGI進(jìn)程從STDOUT中讀取響應(yīng)數(shù)據(jù)然后傳輸給瀏覽器，這樣服務(wù)端就完成了一次http請(qǐng)求。

上面是CGI的實(shí)現(xiàn)流程，但是使用CGI協(xié)議的服務(wù)器在用戶每次訪問(wèn)服務(wù)器的時(shí)候都需要fork/銷(xiāo)毀CGI進(jìn)程，必然照成多余的系統(tǒng)開(kāi)銷(xiāo)，所以FASTCGI就是為了解決這個(gè)問(wèn)題的。

FastCGI會(huì)創(chuàng)建一個(gè)常駐的master進(jìn)程和多個(gè)worker進(jìn)程，master進(jìn)程負(fù)責(zé)管理和為worker進(jìn)程反派任務(wù)，worker進(jìn)程負(fù)責(zé)內(nèi)部嵌入了CGI解析器用于解釋php代碼。

PHP-FPM是一個(gè)FastCGI進(jìn)程管理器，在LNMP體系中就是由它來(lái)實(shí)現(xiàn)FastCGI協(xié)議的。同樣，它也會(huì)創(chuàng)建一個(gè)常駐的master進(jìn)程和多個(gè)worker進(jìn)程，master進(jìn)程負(fù)責(zé)監(jiān)聽(tīng)端口和接收來(lái)自nginx的請(qǐng)求，指派任務(wù)給worker進(jìn)程。worker進(jìn)程的負(fù)責(zé)解釋php代碼。PHP-FPM可以通過(guò)配置預(yù)先啟動(dòng)一定數(shù)量的worker進(jìn)程，這樣當(dāng)http請(qǐng)求觸達(dá)時(shí)就可以更快速的響應(yīng)。

nginx與PHP-FPM之間的通信一般通過(guò)其ngx_http_fastcgi_module模塊來(lái)實(shí)現(xiàn)。其中fastcgi_pass用于設(shè)置fastcgi服務(wù)器的IP地址;fastcgi_param設(shè)置傳入fastcgi服務(wù)器的參數(shù)。這個(gè)模塊出現(xiàn)的配置問(wèn)題一般集中在這一塊。

相對(duì)于并發(fā)狀態(tài)下出現(xiàn)的問(wèn)題，一般也都集中在fastcgi服務(wù)器上，具體表現(xiàn)為fastcgi服務(wù)器為了應(yīng)對(duì)大量的http請(qǐng)求必須不停的fork新的worker進(jìn)程，這時(shí)就需要考慮服務(wù)器可支持的最大鏈接數(shù)和最大打開(kāi)文件數(shù)（可通過(guò)ulimit -n查看）以及php-fpm配置里的最低開(kāi)啟worker數(shù)和最高開(kāi)啟worker數(shù)的限制。高性能服務(wù)器可以在這個(gè)方向上調(diào)優(yōu)。這也是我目前還在探索的地方，以后肯定也會(huì)寫(xiě)一個(gè)總結(jié)。

這一步一般很少出現(xiàn)問(wèn)題，出現(xiàn)問(wèn)題也很容易定位，多是前端渲染問(wèn)題，我也不是很懂。

未完分割線，后面我會(huì)總結(jié)一些各個(gè)階段可能發(fā)生的錯(cuò)誤，這些錯(cuò)誤在客戶端的表現(xiàn)，如何定位，以及如何解決。

CSDN傳送門(mén)