這篇文章主要介紹了關於對LNMP的維運追踪,有著一定的參考價值,現在分享給大家,有需要的朋友可以參考一下
曾幾何時我開始維運公司的LNMP網站,經過一段時間的摸爬滾打,也算是總結了不少在LNMP伺服器下調試追蹤各種網站錯誤的方法。好記性不如爛筆頭,還是總結一下吧!
在開始我會梳理一下我所理解的一個web請求從發起到回應的各個階段伺服器和瀏覽器分別做了什麼。所以的使用者回應異常都是發生在這個流程中的,知道每個流程的細節可以透過不同的方法分別定位異常發生在哪個階段,從而更準確快速的定位錯誤。後面就是持續更新的我在被這個網站折磨中經歷的各種錯誤,給自己做一個記錄,當然如果能幫到其他人,我也很榮幸。
上圖是一個簡單的web請求全過程,嗯,畫的確實有點過於簡單,上圖中我隱藏了很多細節,下面一一說明,可能有沒涉及到的地方歡迎補充:
用戶輸入url如http:www.baidu.com到瀏覽器,瀏覽器如chrom需要解析為ip位址才知道需要到哪裡去訪問哪個伺服器。瀏覽器解析DNS步驟如下:
搜尋瀏覽器本身的dns緩存,這個快取快取時間短,快取數量有限。
搜尋作業系統的dns快取
讀取host檔案的dns映射(一般做本地開發映射都是修改這個檔案來達到攔截瀏覽器請求到本地伺服器的目的,從而使本地可以成功映射伺服器位址)
#先本地網卡配置裡的dns伺服器發起網域名稱解析請求,這裡好像還有一套運營商的處理流程就不在展開了。
下面好像還有一些流程,由於基本上不會執行到這一步,一般所以dns運營商的dns伺服器都會搞定的。
解析失敗,以上任何一步成功都會傳回一個成功的ip位址
瀏覽器以一個隨機的連接埠享受這個ip位址的特定連接埠(預設80)發起著名的TCP3次握手。關於一個http請求是如何到達nginx服務的流程大致如下:
st=>start: TCP请求 en=>end: 异常 op=>operation: Nginx模块 cond1=>condition: 进入网卡? cond2=>condition: 内核的TCP/IP协议栈? cond3=>condition: 防火墙? st->cond1 cond1(yes)->cond2 cond1(no)->en cond2(yes)->cond3 cond2(no)->en cond3(no)->en cond3(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 前面代理伺服器聯絡不到後端的伺服器時出現 |
504 | Gateway Timeout 這個是代理能聯絡後端的伺服器,但是後端的伺服器在規定的時間內沒有給代理伺服器回應 |
以上就是本文的全部內容,希望對大家的學習有所幫助,更多相關內容請關注PHP中文網!
相關推薦:
以上是對LNMP的維運追蹤的詳細內容。更多資訊請關注PHP中文網其他相關文章!