對LNMP的營運追蹤

這篇文章主要介紹了關於對LNMP的營運追蹤，有著一定的參考價值，現在分享給大家，有需要的朋友可以參考一下

LNMP的營運追蹤技巧總結

曾幾何時我開始營運公司的LNMP網站，經過一段時間的摸爬滾打，也算是總結了不少在LNMP伺服器下調試追蹤各種網站錯誤的方法。好記性不如爛筆頭，還是總結一下吧！

在開始我會梳理一下我所理解的一個web請求從發起到響應的各個階段伺服器和瀏覽器分別做了什麼。所以的使用者響應異常都是發生在這個流程中的，知道每個流程的細節可以通過不同的方法分別定位異常發生在哪個階段，從而更準確快速的定位錯誤。後面就是持續更新的我在被這個網站折磨中經曆的各種錯誤，給自己做一個記錄，當然如果能幫到其他人，我也很榮幸。

一個Web請求過程中到底發生了什嗎？

是一個簡單的web請求全過程，嗯，畫的確實有點過於簡單，中我隱藏了很多細節，下面一一說明，可能有沒涉及到的地方歡迎補充：

第一步

使用者輸入url如http:www.baidu.com到瀏覽器，瀏覽器如chrom需要將其解析為ip地址才知道需要到哪裡去訪問哪個伺服器。瀏覽器解析DNS步驟如下：

1. 搜尋瀏覽器自身的dns緩衝，這個緩衝緩衝時間短，緩衝數目有限。

2. 搜尋作業系統的dns緩衝

3. 讀取host檔案的dns映射(一般做本地開發映射都是修改這個檔案來達到攔截瀏覽器請求到本機伺服器的目的，從而使本地可以成功映射伺服器位址)

4. 先本地網卡配置裡的dns伺服器發起網域名稱解析請求，這裡好像還有一套電訊廠商的處理流程就不在展開了。

5. 下面好像還有一些流程，由於基本不會執行到這一步，一般所以dns電訊廠商的dns伺服器都會搞定的。

6. 解析失敗，以上任何一步成功都會返回一個成功的ip地址

第二步

瀏覽器以一個隨機的連接埠享這個ip地址的特定連接埠(預設80)發起著名的TCP3次握手。關於一個http請求是如何到達nginx服務的流程大致如下：

st=>start: TCP請求en=>end: 異常op=>operation: Nginx模組cond1=>condition: 進入網卡？cond2=>condition: 核心的TCP/IP協議棧？cond3=>condition: 防火牆?st->cond1cond1(yes)->cond2cond1(no)->encond2(yes)->cond3cond2(no)->encond3(no)->encond3(yes)->op

第三步

握手完成後的瀏覽器和伺服器就可以愉快地發送http請求了，具體在nginx上流程如下：

st=>start: http請求en=>end: response響應 op1=>operation: 第二步流程 op2=>operation: nginx進程 op3=>operation: 擷取http的頭部資訊 op4=>operation: 匹配server_name，定位到網站的root op5=>operation: 進入代碼架構的路由 op6=>operation: 架構的路由解析器解析出php檔案 op7=>operation: php進入fastcgi進程 op8=>operation: fastcgi進程將php填充成html檔案 op9=>operation: html檔案遞交給nginx並設定響應資訊 st->op1->op2->op3->op4->op5->op6->op7->op8->op9->en

第四步

瀏覽器根據伺服器resopnse的回應標頭和響應體渲染出可視化頁面

響應碼	說明
1xx	資訊性狀態說明
2xx	成功狀態代碼
3xx	重新導向狀態代碼
301	永久重新導向, Location響應首部的值仍為當前URL，因此為隱藏重新導向
302	臨時重新導向，顯式重新導向, Location響應首部的值為新的URL
304	Not Modified 未修改，比如本機快取的資源檔和伺服器上比較時，發現並沒有修改，伺服器返回一個304狀態代碼,告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可
4xx	用戶端錯誤
404	Not Found 請求的URL資源並不存在
5xx	伺服器錯誤
500	Internal Server Error 伺服器內部錯誤
502	Bad Gateway 前面Proxy 伺服器聯絡不到後端的伺服器時出現
504	Gateway Timeout 這個是代理能聯絡到後端的伺服器，但是後端的伺服器在規定的時間內沒有給Proxy 伺服器響應

以上就是本文的全部內容，希望對大家的學習有所協助，更多相關內容請關注topic.alibabacloud.com！