一個(gè)請求的生命周期(HTTP請求過程詳解、TCP/IP五層網(wǎng)絡(luò)模型)

一個(gè)請求的生命周期
前言：當(dāng)我們從電腦上去訪問一個(gè)網(wǎng)址時(shí)，究竟發(fā)生了什么？這個(gè)問題可能是自己思考或者面試的時(shí)候問到，這里我們以訪問百度首頁為例，進(jìn)行一個(gè)全面的HTTP請求分析。

核心概念
計(jì)算機(jī)網(wǎng)絡(luò)核心結(jié)構(gòu)，就是TCP/IP五層網(wǎng)絡(luò)模型（OSI七層模型是將應(yīng)用層分為了三層）

?

以及，每一層對應(yīng)的協(xié)議

?

始于本地
鍵盤輸入：你要訪問www.baidu.com，自然需要在瀏覽器地址欄中使用鍵盤輸入（正常情況下），這個(gè)過程就涉及到輸入設(shè)備與計(jì)算機(jī)的交互了，這個(gè)屬于物理層，這里就不探討了（==其實(shí)是我不會(huì)）
請求域名：首先你訪問的是www.baidu.com，并不帶域名，所以瀏覽器會(huì)自動(dòng)補(bǔ)全協(xié)議頭。但是我們知道，很多時(shí)候域名會(huì)有http和https，它倆的默認(rèn)端口一個(gè)是80，一個(gè)是443，在這里，一般都是對應(yīng)域名的網(wǎng)站做了端口轉(zhuǎn)發(fā)，http協(xié)議實(shí)現(xiàn)了HSTS機(jī)制來使得重定向到HTTPS下的域名。所以HTTP到HTTPS這個(gè)過程是服務(wù)器來完成的，至于瀏覽器的默認(rèn)端口一直是80端口
路由轉(zhuǎn)發(fā)
IP查找：目前我們只知道了帶協(xié)議類型的域名，那么是如何到具體的服務(wù)器的呢？我們知道，對于因特網(wǎng)內(nèi)每個(gè)公有地址IP都是唯一的（局域網(wǎng)內(nèi)不一定），域名相當(dāng)于IP的別名，因?yàn)槲覀儫o法去記住一大堆無意義的IP地址，但如果用一堆有意義的字母組成，大家就能快速訪問對應(yīng)網(wǎng)站。
DNS解析：通過域名去查找IP，先從本地緩存查找，其中本地的hosts文件也綁定了對應(yīng)IP，若在本機(jī)中無法查到，那么就會(huì)去請求本地區(qū)域的域名服務(wù)器（通常是你對應(yīng)的網(wǎng)絡(luò)運(yùn)營商如移動(dòng)），這個(gè)通過網(wǎng)絡(luò)設(shè)置中的LDNS去查找，如果還是沒有命中的話，那么就去根域名服務(wù)器查找，這里有所有因特網(wǎng)上可訪問的域名和IP對應(yīng)信息（根域名服務(wù)器全球共13臺(tái)）。至少到了這里，我們肯定能查找對應(yīng)的IP了，要不就是這個(gè)域名不對。
路由轉(zhuǎn)發(fā)：然后我們通過網(wǎng)卡、路由器、交換機(jī)等設(shè)備，實(shí)現(xiàn)兩個(gè)IP地址之間的通信。這里用到的主要就是路由轉(zhuǎn)發(fā)技術(shù)，根據(jù)路由表去轉(zhuǎn)發(fā)報(bào)文。。。還有子網(wǎng)掩碼、IP廣播等等知識(shí)點(diǎn)。這里就不多做介紹了，計(jì)算機(jī)網(wǎng)絡(luò)里有詳細(xì)準(zhǔn)確的概念~~
連接建立
三次握手：HTTP的底層基于TCP/IP協(xié)議，TCP連接的建立過程少不了三次握手。

?

第一次握手：客戶端主動(dòng)發(fā)送SYN包到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)
第二次握手：服務(wù)器收到SYN包并確認(rèn)，發(fā)送SYN+ACK到客戶端，服務(wù)器進(jìn)入SYN_RECV狀態(tài)
第三次握手：客戶端收到SYN+ACK包，發(fā)送ACK確認(rèn)連接，發(fā)送完畢后客戶端和服務(wù)端進(jìn)入ESTABLISHED狀態(tài)，完成三次握手
數(shù)據(jù)發(fā)送：建立完連接后，TCP才能真正的開始傳輸數(shù)據(jù)==。TCP會(huì)依次、有序的發(fā)送一定大小的報(bào)文，其中包括了超時(shí)重傳、擁塞窗口、慢開始快重傳等等概念。總之加了很多機(jī)制，用來保證數(shù)據(jù)包的完整、有序。當(dāng)然以上都只是傳輸層中TCP做的事，實(shí)現(xiàn)上在應(yīng)用層也加了很多機(jī)制。
HTTPS：

?

大家請看這張圖，一個(gè)完整的HTTPS由以上眾多模塊組成。
a. Queueing：請求等待時(shí)間
b. Stalled： 從TCP建立連接耗時(shí)
c. DNS Lookup：DNS解析
d. Initial connection：初始化連接
e. SSL：SSL就是HTTPS的重頭戲，相比于HTTP建立于TCP基礎(chǔ)上的明文傳輸，HTTPS基于SSL/TLS，而SSL/TLS又是基于TCP/IP，也就是說SSL/TLS基于TCP基礎(chǔ)上再做了一層封裝，對內(nèi)容進(jìn)行加密。對HTTPS如何實(shí)現(xiàn)加密感興趣的同學(xué)可以取看看相關(guān)的話題
f. TTFB：客戶端發(fā)起報(bào)文到服務(wù)器接收到第一個(gè)報(bào)文的耗時(shí)
g. Content Download：服務(wù)器響應(yīng)網(wǎng)頁內(nèi)容接收時(shí)間
GOOGLE原文解釋 文檔地址需翻墻

Queueing The browser queues requests when:

1There are higher priority requests.

2There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.

3The browser is briefly allocating space in the disk cache

Stalled The request could be stalled for any of the reasons described in Queueing.
DNS Lookup The browser is resolving the request’s IP address.
Proxy negotiation The browser is negotiating the request with a proxy server.
Request sent The request is being sent.
ServiceWorker Preparation The browser is starting up the service worker.
Request to ServiceWorker The request is being sent to the service worker.
Waiting (TTFB) The browser is waiting for the first byte of a response. TTFB stands for Time To First Byte. This timing includes 1 round trip of latency and the time the server took to prepare the response.
Content Download The browser is receiving the response.
Receiving Push The browser is receiving data for this response via HTTP/2 Server Push.
Reading Push The browser is reading the local data previously received.

服務(wù)器處理
LVS架構(gòu)：這個(gè)請求在到達(dá)某一個(gè)服務(wù)器前，可能還要經(jīng)歷重重篩選==。反作弊判斷，網(wǎng)關(guān)過濾，CDN等等。其中大型網(wǎng)站最常見的是LVS架構(gòu)。LVS分負(fù)載調(diào)度器，服務(wù)器池，共享存儲(chǔ)。主要就是為了分布式和高并發(fā)場景啦。
LVS文檔

?

代理服務(wù)器：接下來，這個(gè)請求總算到了服務(wù)器了。去監(jiān)聽它的通常是代理服務(wù)器，如Nginx、Apache等。監(jiān)聽到之后代理服務(wù)器會(huì)將請求轉(zhuǎn)發(fā)給對應(yīng)的socket去處理。比如Nginx和PHP的交互就是Nginx將請求轉(zhuǎn)發(fā)給fastcgi_pass定義的socket（文件socket或IPsocket），然后通過fastcgi處理，才會(huì)真正將請求和參數(shù)丟給server，cgi-app。。。
程序處理
接下來就是代碼去處理具體的邏輯，然后通過response返回啦~~

?

?

在前兩篇文章中，我們完整的描述了計(jì)算機(jī)網(wǎng)絡(luò) OSI 五層模型的相關(guān)內(nèi)容。那么，本篇將會(huì)從一個(gè)實(shí)踐案例開始，帶你從整體上重新認(rèn)識(shí)我們的計(jì)算機(jī)網(wǎng)絡(luò)。?

我們以訪問 Google 為例，當(dāng)我們在瀏覽器地址欄中敲下回車鍵之后，整個(gè)計(jì)算機(jī)網(wǎng)絡(luò)將會(huì)發(fā)生什么呢？?
本機(jī)的網(wǎng)絡(luò)相關(guān)參數(shù)如下：?

首先我們應(yīng)用層的瀏覽器決定向 DNS?服務(wù)器請求解析域名「www.google.com」，那么就要遵循 DNS 協(xié)議。

DNS 運(yùn)行在 53 號(hào)端口，于是瀏覽器會(huì)創(chuàng)建一個(gè) UDP 套接字，標(biāo)識(shí)該套接字的二元組分別是『目的 IP 地址』和『目的端口』。而套接字本質(zhì)上就是為了唯一標(biāo)識(shí)應(yīng)用層進(jìn)程，就是為了讓響應(yīng)報(bào)文能夠找到目的地。

那么這里會(huì)創(chuàng)建一個(gè) UDP 套接字，二元組為「本機(jī) IP 地址 192.168.43.138」和「隨機(jī)產(chǎn)生一個(gè)未使用的端口號(hào)」。?
接著，瀏覽器將 DNS 請求報(bào)文封裝好推入套接字，開始我們的 DNS 解析過程。

有關(guān) DNS 的相關(guān)細(xì)節(jié)，這里不再贅述了，可以參考前面的文章，拿到 DNS 服務(wù)器的響應(yīng)報(bào)文，運(yùn)輸層拆開數(shù)據(jù)報(bào)，得到該報(bào)文的目的 IP 地址和目的端口號(hào)，于是對應(yīng)著去找套接字交付報(bào)文即可。

最終我們會(huì)從『本地 DNS 服務(wù)器』得到 Google 的 IP 地址為：172.194.72.105。?
整個(gè) HTTP 請求可以說才剛剛開始：

應(yīng)用層

瀏覽器封裝 HTTP 請求報(bào)文，然后創(chuàng)建一個(gè) TCP 套接字，采用四元組標(biāo)識(shí)，具體為「源 IP 地址：192.168.43.138」+「源端口號(hào)：隨機(jī)的，這里假設(shè)為 1234」+「目的 IP 地址：172.194.72.105」+「目的端口號(hào)：80」。?
HTTP 報(bào)文也就是我們的應(yīng)用層數(shù)據(jù)報(bào)，大致是這樣的：?

指定了一些請求參數(shù)與動(dòng)作，以及一些要求響應(yīng)報(bào)文的返回格式要求，具體的我們不細(xì)說了。?
緊接著，這個(gè)報(bào)文會(huì)被推進(jìn) TCP 套接字中，等待運(yùn)輸層來收取。

運(yùn)輸層

運(yùn)輸層收取了報(bào)文，并判斷與目的主機(jī)是否建立了 TCP 連接，這里假設(shè)沒有。?
那么，運(yùn)輸層將不急著發(fā)送應(yīng)用層數(shù)據(jù)，得先判斷與目的主機(jī)之間能夠正常通訊，也就是需要『握手』打招呼。?
『三次握手』的相關(guān)細(xì)節(jié)，我們這里也不再贅述了，上篇文章描述的很詳細(xì)了，通過『三次握手』，發(fā)送端和接收端確認(rèn)過發(fā)送與確認(rèn)序號(hào)，分配了相應(yīng)的緩存資源等。?
一切準(zhǔn)備就緒之后，運(yùn)輸層將應(yīng)用層發(fā)過來的數(shù)據(jù)報(bào)又一層封裝，添加進(jìn)『源端口號(hào)』和『目的端口號(hào)』以及相關(guān)差錯(cuò)檢驗(yàn)字段。?
最后將 TCP 數(shù)據(jù)報(bào)向下傳遞到網(wǎng)絡(luò)層。

網(wǎng)絡(luò)層

網(wǎng)絡(luò)層其實(shí)很簡單，拿到數(shù)據(jù)報(bào)并封裝成 IP 數(shù)據(jù)報(bào)，即在原 TCP 報(bào)文的前提之上添加『源 IP 地址』和『目的 IP 地址』等字段信息。

然后交由數(shù)據(jù)鏈路層。

鏈路層

數(shù)據(jù)鏈路層拿到 IP 數(shù)據(jù)報(bào)，它需要封裝成以太網(wǎng)幀才能在網(wǎng)絡(luò)中傳輸，也就是它需要目的主機(jī)的 Mac 地址，然而我們只知道目的主機(jī)的 IP 地址。

所以，鏈路層有一個(gè) ARP 協(xié)議，直接或間接的能夠根據(jù)目的 IP 地址獲得使用該 IP 地址的主機(jī) Mac 地址。

當(dāng)然，ARP 協(xié)議運(yùn)行的前提是，目的 IP 地址和當(dāng)前發(fā)送方主機(jī)處于同一子網(wǎng)絡(luò)中。如果不然，發(fā)送方將目的 Mac 地址填自己網(wǎng)關(guān)路由的 Mac 地址，然后通過物理層發(fā)送出去。

網(wǎng)關(guān)路由由于具有轉(zhuǎn)發(fā)表和路由選擇算法，所以它知道目的網(wǎng)絡(luò)該怎么到達(dá)，所以一路轉(zhuǎn)發(fā)，最終會(huì)發(fā)送到目的網(wǎng)絡(luò)的網(wǎng)關(guān)路由上。

最后，目的網(wǎng)絡(luò)的網(wǎng)關(guān)路由同樣會(huì)經(jīng)由 ARP 協(xié)議，取得目的主機(jī)的 Mac 地址，然后廣播發(fā)送，最后被目的主機(jī)接受。?
這樣谷歌的服務(wù)器就接受到一個(gè) HTTP 請求，于是它解析這個(gè)請求，確定該請求的動(dòng)作是什么，也就是它需要什么東西，并構(gòu)建響應(yīng)報(bào)文，以同樣的方式從網(wǎng)絡(luò)到達(dá)源主機(jī)。

最后你將看到你想要的谷歌搜索頁面：?

整體上我們自頂而下的描述了一個(gè)請求到達(dá)目的地的完整過程，旨在宏觀上建立完整的框架體系，相關(guān)細(xì)節(jié)之處可以參照前兩篇文章。

瀏覽器輸入網(wǎng)址到響應(yīng)的整個(gè)過程-http 請求到響應(yīng)詳解

這一過程詳細(xì)來講涉及到計(jì)算機(jī)的整個(gè)網(wǎng)絡(luò)架構(gòu)系統(tǒng)，從應(yīng)用層到物理層都可以講述。本講聚焦應(yīng)用層發(fā)生了什么事。

在應(yīng)用層，瀏覽器首先需要獲得將要訪問的網(wǎng)站的 IP 地址，因此首先需要進(jìn)行域名解析，從網(wǎng)址提取出域名，然后進(jìn)行 DNS 請求（UDP）。首先在本機(jī)的域名緩存中查詢，若查詢不到再到直連的路由器中查詢，還是沒有則到直連的網(wǎng)絡(luò)服務(wù)提供商的 DNS 服務(wù)器查詢，查詢不到則會(huì)有兩種方式繼續(xù)查詢一種是遞歸方式，即一級一級的往上一級 DNS 服務(wù)器查詢，直到根 DNS 服務(wù)器，此時(shí)基本能查到；?
示例：?
主機(jī)——>本地 DNS 服務(wù)器——>權(quán)限 DNS 服務(wù)器——>頂級 DNS 服務(wù)器——>根服務(wù)器。其結(jié)果是要么能查到要么報(bào)錯(cuò)。?
一種是非遞歸方式，即直接找根 DNS 服務(wù)器，然后由它指示要找哪一個(gè)根服務(wù)器的下一級 DNS 服務(wù)器。

當(dāng)查到需要的 IP 地址后，地址中沒有端口的話則使用 HTTP 協(xié)議的默認(rèn)短號(hào)，進(jìn)行 TCP 的三次握手，與對端主機(jī)連接。?
成功連接后，則可以向?qū)Χ酥鳈C(jī)發(fā)送 HTTP 請求，成功收到響應(yīng)則進(jìn)行斷連，即 TCP 的四次揮手。若響應(yīng)是重定向，則需要再一次發(fā)送 HTTP 請求到重定向的地址（是否需要重新 DNS 解析？）

最后瀏覽器解析服務(wù)器的響應(yīng)內(nèi)容，并顯示再瀏覽器頁面。

參考鏈接：

https://blog.csdn.net/lzghxjt/article/details/51458540
https://www.jianshu.com/p/aa97810e5fa4

在瀏覽器中輸入www.baidu.com后執(zhí)行的全部過程

在瀏覽器中輸入www.baidu.com后執(zhí)行的全部過程

?

1、客戶端瀏覽器通過DNS解析到www.baidu.com的IP地址220.181.27.48，通過這個(gè)IP地址找到客戶端到服務(wù)器的路徑。客戶端瀏覽器發(fā)起一個(gè)HTTP會(huì)話到220.161.27.48，然后通過TCP進(jìn)行封裝數(shù)據(jù)包，輸入到網(wǎng)絡(luò)層。?
2、在客戶端的傳輸層，把HTTP會(huì)話請求分成報(bào)文段，添加源和目的端口，如服務(wù)器使用80端口監(jiān)聽客戶端的請求，客戶端由系統(tǒng)隨機(jī)選擇一個(gè)端口如5000，與服務(wù)器進(jìn)行交換，服務(wù)器把相應(yīng)的請求返回給客戶端的5000端口。然后使用IP層的IP地址查找目的端。?
3、客戶端的網(wǎng)絡(luò)層不用關(guān)心應(yīng)用層或者傳輸層的東西，主要做的是通過查找路由表確定如何到達(dá)服務(wù)器，期間可能經(jīng)過多個(gè)路由器，這些都是由路由器來完成的工作，我不作過多的描述，無非就是通過查找路由表決定通過那個(gè)路徑到達(dá)服務(wù)器。?
4、客戶端的鏈路層，包通過鏈路層發(fā)送到路由器，通過鄰居協(xié)議查找給定IP地址的MAC地址，然后發(fā)送ARP請求查找目的地址，如果得到回應(yīng)后就可以使用ARP的請求應(yīng)答交換的IP數(shù)據(jù)包現(xiàn)在就可以傳輸了，然后發(fā)送IP數(shù)據(jù)包到達(dá)服務(wù)器的地址。

---

事件順序

(1) 瀏覽器獲取輸入的域名www.baidu.com?
(2) 瀏覽器向DNS請求解析www.baidu.com的IP地址?
(3) 域名系統(tǒng)DNS解析出百度服務(wù)器的IP地址?
(4) 瀏覽器與該服務(wù)器建立TCP連接(默認(rèn)端口號(hào)80)?
(5) 瀏覽器發(fā)出HTTP請求，請求百度首頁?
(6) 服務(wù)器通過HTTP響應(yīng)把首頁文件發(fā)送給瀏覽器?
(7) TCP連接釋放?
(8) 瀏覽器將首頁文件進(jìn)行解析，并將Web頁顯示給用戶。

---

涉及到的協(xié)議?
(1) 應(yīng)用層：HTTP(WWW訪問協(xié)議)，DNS(域名解析服務(wù))?
DNS解析域名為目的IP，通過IP找到服務(wù)器路徑，客戶端向服務(wù)器發(fā)起HTTP會(huì)話，然后通過運(yùn)輸層TCP協(xié)議封裝數(shù)據(jù)包，在TCP協(xié)議基礎(chǔ)上進(jìn)行傳輸

(2) 傳輸層：TCP(為HTTP提供可靠的數(shù)據(jù)傳輸)，UDP(DNS使用UDP傳輸)?
HTTP會(huì)話會(huì)被分成報(bào)文段，添加源、目的端口；TCP協(xié)議進(jìn)行主要工作

(3)網(wǎng)絡(luò)層：IP(IP數(shù)據(jù)數(shù)據(jù)包傳輸和路由選擇)，?
為數(shù)據(jù)包選擇路由，IP協(xié)議進(jìn)行主要工作

(4)數(shù)據(jù)鏈路層：ICMP(提供網(wǎng)絡(luò)傳輸過程中的差錯(cuò)檢測)，ARP(將本機(jī)的默認(rèn)網(wǎng)關(guān)IP地址映射成物理MAC地址)?
相鄰結(jié)點(diǎn)的可靠傳輸，ARP協(xié)議將IP地址轉(zhuǎn)成MAC地址。

?

作為一個(gè)軟件開發(fā)者，你一定會(huì)對網(wǎng)絡(luò)應(yīng)用如何工作有一個(gè)完整的層次化的認(rèn)知，同樣這里也包括這些應(yīng)用所用到的技術(shù)：像瀏覽器，HTTP，HTML，網(wǎng)絡(luò)服務(wù)器，需求處理等等。

本文將更深入的研究當(dāng)你輸入一個(gè)網(wǎng)址的時(shí)候，后臺(tái)到底發(fā)生了一件件什么樣的事～

1. 首先嘛，你得在瀏覽器里輸入要網(wǎng)址:

?

2. 瀏覽器查找域名的IP地址

?

導(dǎo)航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下：

• 瀏覽器緩存 –?瀏覽器會(huì)緩存DNS記錄一段時(shí)間。 有趣的是，操作系統(tǒng)沒有告訴瀏覽器儲(chǔ)存DNS記錄的時(shí)間，這樣不同瀏覽器會(huì)儲(chǔ)存?zhèn)€自固定的一個(gè)時(shí)間（2分鐘到30分鐘不等）。
• 系統(tǒng)緩存?– 如果在瀏覽器緩存里沒有找到需要的記錄，瀏覽器會(huì)做一個(gè)系統(tǒng)調(diào)用（windows里是gethostbyname）。這樣便可獲得系統(tǒng)緩存中的記錄。
• 路由器緩存?– 接著，前面的查詢請求發(fā)向路由器，它一般會(huì)有自己的DNS緩存。
• ISP DNS 緩存?– 接下來要check的就是ISP緩存DNS的服務(wù)器。在這一般都能找到相應(yīng)的緩存記錄。
• 遞歸搜索?– 你的ISP的DNS服務(wù)器從跟域名服務(wù)器開始進(jìn)行遞歸搜索，從.com頂級域名服務(wù)器到Facebook的域名服務(wù)器。一般DNS服務(wù)器的緩存中會(huì)有.com域名服務(wù)器中的域名，所以到頂級服務(wù)器的匹配過程不是那么必要了。

DNS遞歸查找如下圖所示：

?

DNS有一點(diǎn)令人擔(dān)憂，這就是像wikipedia.org 或者 facebook.com這樣的整個(gè)域名看上去只是對應(yīng)一個(gè)單獨(dú)的IP地址。還好，有幾種方法可以消除這個(gè)瓶頸：

• 循環(huán) DNS?是DNS查找時(shí)返回多個(gè)IP時(shí)的解決方案。舉例來說，Facebook.com實(shí)際上就對應(yīng)了四個(gè)IP地址。
• 負(fù)載平衡器?是以一個(gè)特定IP地址進(jìn)行偵聽并將網(wǎng)絡(luò)請求轉(zhuǎn)發(fā)到集群服務(wù)器上的硬件設(shè)備。 一些大型的站點(diǎn)一般都會(huì)使用這種昂貴的高性能負(fù)載平衡器。
• 地理 DNS?根據(jù)用戶所處的地理位置，通過把域名映射到多個(gè)不同的IP地址提高可擴(kuò)展性。這樣不同的服務(wù)器不能夠更新同步狀態(tài)，但映射靜態(tài)內(nèi)容的話非常好。
• Anycast?是一個(gè)IP地址映射多個(gè)物理主機(jī)的路由技術(shù)。 美中不足，Anycast與TCP協(xié)議適應(yīng)的不是很好，所以很少應(yīng)用在那些方案中。

大多數(shù)DNS服務(wù)器使用Anycast來獲得高效低延遲的DNS查找。

3. 瀏覽器給web服務(wù)器發(fā)送一個(gè)HTTP請求

?

因?yàn)橄馞acebook主頁這樣的動(dòng)態(tài)頁面，打開后在瀏覽器緩存中很快甚至馬上就會(huì)過期，毫無疑問他們不能從中讀取。

所以，瀏覽器將把一下請求發(fā)送到Facebook所在的服務(wù)器：

GET http://facebook.com/ HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]Accept-Encoding: gzip, deflateConnection: Keep-AliveHost: facebook.comCookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET 這個(gè)請求定義了要讀取的URL： “http://facebook.com/”。 瀏覽器自身定義 (User-Agent?頭)， 和它希望接受什么類型的相應(yīng) (Accept?and?Accept-Encoding頭).?Connection頭要求服務(wù)器為了后邊的請求不要關(guān)閉TCP連接。

請求中也包含瀏覽器存儲(chǔ)的該域名的cookies。可能你已經(jīng)知道，在不同頁面請求當(dāng)中，cookies是與跟蹤一個(gè)網(wǎng)站狀態(tài)相匹配的鍵值。這樣cookies會(huì)存儲(chǔ)登錄用戶名，服務(wù)器分配的密碼和一些用戶設(shè)置等。Cookies會(huì)以文本文檔形式存儲(chǔ)在客戶機(jī)里，每次請求時(shí)發(fā)送給服務(wù)器。

用來看原始HTTP請求及其相應(yīng)的工具很多。作者比較喜歡使用fiddler，當(dāng)然也有像FireBug這樣其他的工具。這些軟件在網(wǎng)站優(yōu)化時(shí)會(huì)幫上很大忙。

除了獲取請求，還有一種是發(fā)送請求，它常在提交表單用到。發(fā)送請求通過URL傳遞其參數(shù)(e.g.: http://robozzle.com/puzzle.aspx?id=85)。發(fā)送請求在請求正文頭之后發(fā)送其參數(shù)。?
像“http://facebook.com/”中的斜杠是至關(guān)重要的。這種情況下，瀏覽器能安全的添加斜杠。而像“http: //example.com/folderOrFile”這樣的地址，因?yàn)闉g覽器不清楚folderOrFile到底是文件夾還是文件，所以不能自動(dòng)添加 斜杠。這時(shí)，瀏覽器就不加斜杠直接訪問地址，服務(wù)器會(huì)響應(yīng)一個(gè)重定向，結(jié)果造成一次不必要的握手。

4. facebook服務(wù)的永久重定向響應(yīng)

?

圖中所示為Facebook服務(wù)器發(fā)回給瀏覽器的響應(yīng)：

HTTP/1.1 301 Moved PermanentlyCache-Control: private, no-store, no-cache, must-revalidate, post-check=0,pre-check=0Expires: Sat, 01 Jan 2000 00:00:00 GMTLocation: http://www.facebook.com/P3P: CP="DSP LAW"Pragma: no-cacheSet-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;path=/; domain=.facebook.com; httponlyContent-Type: text/html; charset=utf-8X-Cnection: closeDate: Fri, 12 Feb 2010 05:09:51 GMTContent-Length: 0

服務(wù)器給瀏覽器響應(yīng)一個(gè)301永久重定向響應(yīng)，這樣瀏覽器就會(huì)訪問“http://www.facebook.com/” 而非“http://facebook.com/”。

為什么服務(wù)器一定要重定向而不是直接發(fā)會(huì)用戶想看的網(wǎng)頁內(nèi)容呢？這個(gè)問題有好多有意思的答案。

其中一個(gè)原因跟搜索引擎排名有 關(guān)。你看，如果一個(gè)頁面有兩個(gè)地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎會(huì)認(rèn)為它們是兩個(gè)網(wǎng)站，結(jié)果造成每一個(gè)的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什么意思，這樣就會(huì)把訪問帶www的和不帶www的地址歸到同一個(gè)網(wǎng)站排名下。

還有一個(gè)是用不同的地址會(huì)造成緩存友好性變差。當(dāng)一個(gè)頁面有好幾個(gè)名字時(shí)，它可能會(huì)在緩存里出現(xiàn)好幾次。

5. 瀏覽器跟蹤重定向地址

?

現(xiàn)在，瀏覽器知道了“http://www.facebook.com/”才是要訪問的正確地址，所以它會(huì)發(fā)送另一個(gè)獲取請求：

GET http://www.facebook.com/ HTTP/1.1Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]Accept-Language: en-USUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]Accept-Encoding: gzip, deflateConnection: Keep-AliveCookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]Host: www.facebook.com

頭信息以之前請求中的意義相同。

6. 服務(wù)器“處理”請求

?

服務(wù)器接收到獲取請求，然后處理并返回一個(gè)響應(yīng)。

這表面上看起來是一個(gè)順向的任務(wù)，但其實(shí)這中間發(fā)生了很多有意思的東西- 就像作者博客這樣簡單的網(wǎng)站，何況像facebook那樣訪問量大的網(wǎng)站呢！

• Web 服務(wù)器軟件?
  web服務(wù)器軟件（像IIS和阿帕奇）接收到HTTP請求，然后確定執(zhí)行什么請求處理來處理它。請求處理就是一個(gè)能夠讀懂請求并且能生成HTML來進(jìn)行響應(yīng)的程序（像ASP.NET,PHP,RUBY...）。

  舉 個(gè)最簡單的例子，需求處理可以以映射網(wǎng)站地址結(jié)構(gòu)的文件層次存儲(chǔ)。像http://example.com/folder1/page1.aspx這個(gè)地 址會(huì)映射/httpdocs/folder1/page1.aspx這個(gè)文件。web服務(wù)器軟件可以設(shè)置成為地址人工的對應(yīng)請求處理，這樣 page1.aspx的發(fā)布地址就可以是http://example.com/folder1/page1。

• 請求處理?
  請求處理閱讀請求及它的參數(shù)和cookies。它會(huì)讀取也可能更新一些數(shù)據(jù)，并講數(shù)據(jù)存儲(chǔ)在服務(wù)器上。然后，需求處理會(huì)生成一個(gè)HTML響應(yīng)。

所 有動(dòng)態(tài)網(wǎng)站都面臨一個(gè)有意思的難點(diǎn) -如何存儲(chǔ)數(shù)據(jù)。小網(wǎng)站一半都會(huì)有一個(gè)SQL數(shù)據(jù)庫來存儲(chǔ)數(shù)據(jù)，存儲(chǔ)大量數(shù)據(jù)和/或訪問量大的網(wǎng)站不得不找一些辦法把數(shù)據(jù)庫分配到多臺(tái)機(jī)器上。解決方案 有：sharding （基于主鍵值講數(shù)據(jù)表分散到多個(gè)數(shù)據(jù)庫中），復(fù)制，利用弱語義一致性的簡化數(shù)據(jù)庫。

委 托工作給批處理是一個(gè)廉價(jià)保持?jǐn)?shù)據(jù)更新的技術(shù)。舉例來講，Fackbook得及時(shí)更新新聞feed，但數(shù)據(jù)支持下的“你可能認(rèn)識(shí)的人”功能只需要每晚更新 （作者猜測是這樣的，改功能如何完善不得而知）。批處理作業(yè)更新會(huì)導(dǎo)致一些不太重要的數(shù)據(jù)陳舊，但能使數(shù)據(jù)更新耕作更快更簡潔。

7. 服務(wù)器發(fā)回一個(gè)HTML響應(yīng)

?

圖中為服務(wù)器生成并返回的響應(yīng)：

HTTP/1.1 200 OKCache-Control: private, no-store, no-cache, must-revalidate, post-check=0,pre-check=0Expires: Sat, 01 Jan 2000 00:00:00 GMTP3P: CP="DSP LAW"Pragma: no-cacheContent-Encoding: gzipContent-Type: text/html; charset=utf-8X-Cnection: closeTransfer-Encoding: chunkedDate: Fri, 12 Feb 2010 09:05:55 GMT2b3Tn@[...]

整個(gè)響應(yīng)大小為35kB，其中大部分在整理后以blob類型傳輸。

內(nèi)容編碼頭告訴瀏覽器整個(gè)響應(yīng)體用gzip算法進(jìn)行壓縮。解壓blob塊后，你可以看到如下期望的HTML：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"lang="en" id="facebook" class=" no_js"><head><meta http-equiv="Content-type" content="text/html; charset=utf-8" /><meta http-equiv="Content-language" content="en" />...

關(guān)于壓縮，頭信息說明了是否緩存這個(gè)頁面，如果緩存的話如何去做，有什么cookies要去設(shè)置（前面這個(gè)響應(yīng)里沒有這點(diǎn)）和隱私信息等等。

請注意報(bào)頭中把Content-type設(shè)置為“text/html”。報(bào)頭讓瀏覽器將該響應(yīng)內(nèi)容以HTML形式呈現(xiàn)，而不是以文件形式下載它。瀏覽器會(huì)根據(jù)報(bào)頭信息決定如何解釋該響應(yīng)，不過同時(shí)也會(huì)考慮像URL擴(kuò)展內(nèi)容等其他因素。

8. 瀏覽器開始顯示HTML

在瀏覽器沒有完整接受全部HTML文檔時(shí)，它就已經(jīng)開始顯示這個(gè)頁面了：

?

9. 瀏覽器發(fā)送獲取嵌入在HTML中的對象

?

在瀏覽器顯示HTML時(shí)，它會(huì)注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時(shí)，瀏覽器會(huì)發(fā)送一個(gè)獲取請求來重新獲得這些文件。

下面是幾個(gè)我們訪問facebook.com時(shí)需要重獲取的幾個(gè)URL：

• 圖片?
  http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif?
  http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif?
  …
• CSS 式樣表?
  http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css?
  http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css?
  …
• JavaScript 文件?
  http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js?
  http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js?
  …

這些地址都要經(jīng)歷一個(gè)和HTML讀取類似的過程。所以瀏覽器會(huì)在DNS中查找這些域名，發(fā)送請求，重定向等等...

但 不像動(dòng)態(tài)頁面那樣，靜態(tài)文件會(huì)允許瀏覽器對其進(jìn)行緩存。有的文件可能會(huì)不需要與服務(wù)器通訊，而從緩存中直接讀取。服務(wù)器的響應(yīng)中包含了靜態(tài)文件保存的期限 信息，所以瀏覽器知道要把它們緩存多長時(shí)間。還有，每個(gè)響應(yīng)都可能包含像版本號(hào)一樣工作的ETag頭（被請求變量的實(shí)體值），如果瀏覽器觀察到文件的版本 ETag信息已經(jīng)存在，就馬上停止這個(gè)文件的傳輸。

試著猜猜看“fbcdn.net”在地址中代表什么？聰明的答案是"Facebook內(nèi)容分發(fā)網(wǎng)絡(luò)"。Facebook利用內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）分發(fā)像圖片，CSS表和JavaScript文件這些靜態(tài)文件。所以，這些文件會(huì)在全球很多CDN的數(shù)據(jù)中心中留下備份。

靜態(tài)內(nèi)容往往代表站點(diǎn)的帶寬大小，也能通過CDN輕松的復(fù)制。通常網(wǎng)站會(huì)使用第三方的CDN。例如，Facebook的靜態(tài)文件由最大的CDN提供商Akamai來托管。

舉例來講，當(dāng)你試著ping static.ak.fbcdn.net的時(shí)候，可能會(huì)從某個(gè)akamai.net服務(wù)器上獲得響應(yīng)。有意思的是，當(dāng)你同樣再ping一次的時(shí)候，響應(yīng)的服務(wù)器可能就不一樣，這說明幕后的負(fù)載平衡開始起作用了。

10. 瀏覽器發(fā)送異步（AJAX）請求

?

在Web 2.0偉大精神的指引下，頁面顯示完成后客戶端仍與服務(wù)器端保持著聯(lián)系。

以 Facebook聊天功能為例，它會(huì)持續(xù)與服務(wù)器保持聯(lián)系來及時(shí)更新你那些亮亮灰灰的好友狀態(tài)。為了更新這些頭像亮著的好友狀態(tài)，在瀏覽器中執(zhí)行的 JavaScript代碼會(huì)給服務(wù)器發(fā)送異步請求。這個(gè)異步請求發(fā)送給特定的地址，它是一個(gè)按照程式構(gòu)造的獲取或發(fā)送請求。還是在Facebook這個(gè)例 子中，客戶端發(fā)送給http://www.facebook.com/ajax/chat/buddy_list.php一個(gè)發(fā)布請求來獲取你好友里哪個(gè) 在線的狀態(tài)信息。

提起這個(gè)模式，就必須要講講"AJAX"-- “異步JavaScript 和 XML”，雖然服務(wù)器為什么用XML格式來進(jìn)行響應(yīng)也沒有個(gè)一清二白的原因。再舉個(gè)例子吧，對于異步請求，Facebook會(huì)返回一些JavaScript的代碼片段。

除了其他，fiddler這個(gè)工具能夠讓你看到瀏覽器發(fā)送的異步請求。事實(shí)上，你不僅可以被動(dòng)的做為這些請求的看客，還能主動(dòng)出擊修改和重新發(fā)送它們。AJAX請求這么容易被蒙，可著實(shí)讓那些計(jì)分的在線游戲開發(fā)者們郁悶的了。（當(dāng)然，可別那樣騙人家~）

Facebook聊天功能提供了關(guān)于AJAX一個(gè)有意思的問題案例：把數(shù)據(jù)從服務(wù)器端推送到客戶端。因?yàn)镠TTP是一個(gè)請求-響應(yīng)協(xié)議，所以聊天服務(wù)器不能把新消息發(fā)給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務(wù)器端看自己有沒有新消息。

這些情況發(fā)生時(shí)長輪詢是個(gè)減輕服務(wù)器負(fù)載挺有趣的技術(shù)。如果當(dāng)被輪詢時(shí)服務(wù)器沒有新消息，它就不理這個(gè)客戶端。而當(dāng)尚未超時(shí)的情況下收到了該客戶的新消息，服務(wù)器就會(huì)找到未完成的請求，把新消息做為響應(yīng)返回給客戶端。

?

基于Web的HTTP請求/響應(yīng)生命周期的關(guān)鍵點(diǎn)

路由
建立一個(gè)復(fù)雜將URL映射到函數(shù)的路由器。

函數(shù)執(zhí)行
函數(shù)應(yīng)該通過異步的方式執(zhí)行，一旦函數(shù)執(zhí)行完成，就應(yīng)該執(zhí)行一個(gè)回調(diào)函數(shù)。

響應(yīng)/渲染
一旦執(zhí)行完成，就應(yīng)該通過異步的方式執(zhí)行渲染。

序列化
在執(zhí)行、渲染階段獲取和使用過的所有數(shù)據(jù)都應(yīng)該成為服務(wù)器端響應(yīng)的一部分。

反序列化
任何對象和數(shù)據(jù)都需要在客戶端重新創(chuàng)建，因?yàn)楫?dāng)用戶和應(yīng)用進(jìn)行交互時(shí)，客戶端運(yùn)行時(shí)需要用到這些數(shù)據(jù)。

添加事件
應(yīng)綁定事件處理器，以便應(yīng)用可交互。
?

#目錄

##1、基本概念

* 什么是CGI？

* 部分專業(yè)術(shù)語解釋

* 圖解靜態(tài)請求和動(dòng)態(tài)請求

* php組成

##2、PHP的生命周期

##3、PHP底層工作原理

###基本概念

####1.什么是CGI？

1）什么是cgi呢？

CGI是common gateway interface的縮寫，譯作通用網(wǎng)關(guān)接口，但很不幸，我們無法見名知意，我們知道，web服務(wù)器所處理的內(nèi)容都是靜態(tài)的，要想處理動(dòng)態(tài)內(nèi)容，需要依賴于web應(yīng)用程序，如php、jsp、python、perl等。但是web server如何將動(dòng)態(tài)的請求傳遞給這些應(yīng)用程序？它所依賴的就是cgi協(xié)議。沒錯(cuò)，是協(xié)議，也就是web server和web應(yīng)用程序交流時(shí)的規(guī)范。換句話說，通過cgi協(xié)議，再結(jié)合已搭建好的web應(yīng)用程序，就可以讓web server也能"處理"動(dòng)態(tài)請求，你肯定知道處理兩字為什么要加上雙引號(hào)。

簡單版的cgi工作方式如下：


***

####2.部分專業(yè)術(shù)語解釋

#####CGI：

**概念**：它是一種協(xié)議。通過cgi協(xié)議，web server可以將動(dòng)態(tài)請求和相關(guān)參數(shù)發(fā)送給專門處理動(dòng)態(tài)內(nèi)容的應(yīng)用程序。

**工作原理**：CGI方式在遇到連接請求（用戶請求）先要?jiǎng)?chuàng)建cgi的子進(jìn)程，激活一個(gè)CGI進(jìn)程，然后處理請求，處理完后結(jié)束這個(gè)子進(jìn)程。這就是fork-and-execute模式。所以用cgi方式的服務(wù)器有多少連接請求就會(huì)有多少cgi子進(jìn)程，子進(jìn)程反復(fù)加載是cgi性能低下的主要原因。當(dāng)用戶請求數(shù)量非常多時(shí)，會(huì)大量擠占系統(tǒng)的資源如內(nèi)存，CPU時(shí)間等，造成效能低下。

***

#####2）FASTCGI：

**概念**：也是一種協(xié)議，只不過是cgi的優(yōu)化版。cgi的性能較爛，fastcgi則在其基礎(chǔ)上進(jìn)行了改進(jìn)。FastCGI技術(shù)目前支持語言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等

**工作原理**：fast-cgi是cgi的升級版本，是一個(gè)進(jìn)程可以處理多個(gè)請求，和上面的cgi協(xié)議完全不一樣，cgi是一個(gè)進(jìn)程只能處理一個(gè)請求，這樣就會(huì)導(dǎo)致大量的cgi程序，因此會(huì)給服務(wù)器帶來負(fù)擔(dān)。FastCGI像是一個(gè)常駐型的CGI，它可以一直執(zhí)行著，只要激活后，不會(huì)每次都要花費(fèi)時(shí)間去fork一次

***

#####3）PHP-CGI：

**概念**：PHP-CGI是PHP自帶的FastCGI管理器。

**工作原理**：fastcgi是一種協(xié)議，而php-cgi實(shí)現(xiàn)了這種協(xié)議。不過這種實(shí)現(xiàn)比較爛。它是單進(jìn)程的，一個(gè)進(jìn)程處理一個(gè)請求，處理結(jié)束后進(jìn)程就銷毀。

#####4）PHP-FPM：

**概念**：PHP-FPM是一個(gè)PHP FastCGI管理器，是只用于PHP的是對php-cgi的改進(jìn)版，它直接管理多個(gè)php-cgi進(jìn)程/線程。也就是說，php-fpm是php-cgi的進(jìn)程管理器因此它也算是fastcgi協(xié)議的實(shí)現(xiàn)。

**工作原理**：php-fpm會(huì)開啟多個(gè)php-cgi程序，并且php-fpm常駐內(nèi)存，每次web serve服務(wù)器發(fā)送連接過來的時(shí)候，php-fpm將連接信息分配給下面其中的一個(gè)子程序php-cgi進(jìn)行處理，處理完畢這個(gè)php-cgi并不會(huì)關(guān)閉，而是繼續(xù)等待下一個(gè)連接（一個(gè)進(jìn)程至少服務(wù)上萬次請求才退出），這也是fast-cgi加速的原理，但是由于php-fpm是多進(jìn)程的，而一個(gè)php-cgi基本消耗7-25M內(nèi)存，因此如果連接過多就會(huì)導(dǎo)致內(nèi)存消耗過大，引發(fā)一些問題，例如nginx里的502錯(cuò)誤。

**為什么一定要退出？**因?yàn)閾?dān)心RINIT->RSHUTDOWN循環(huán)，有哪個(gè)代碼寫的不好，變量一直沒釋放，內(nèi)存泄露GC又回收不了。php-fpm里的pm.max_requests配置就是設(shè)置RINT循環(huán)多少次，退出進(jìn)程。

**同時(shí)php-fpm還附帶一些其他的功能**：例如平滑過渡配置更改，普通的php-cgi在每次更改配置后，需要重新啟動(dòng)才能初始化新的配置，而php-fpm是不需要，php-fpm分將新的連接發(fā)送給新的子程序php-cgi，這個(gè)時(shí)候加載的是新的配置，而原先**正在運(yùn)行**的php-cgi還是使用的原先的配置，等到**這個(gè)連接后下一次連接**的時(shí)候會(huì)使用新的配置初始化，這就是**平滑過渡**。

***

#####5）CGI進(jìn)程/線程

**概念**：在php上，就是php-cgi進(jìn)程/線程。專門用于接收web server的動(dòng)態(tài)請求，**調(diào)用并初始化zend虛擬機(jī)。**

***

#####6）CGI腳本：

**概念**：被執(zhí)行的php源代碼文件。

***

#####7）ZEND虛擬機(jī)：

**概念**：對php文件做詞法分析、語法分析、編譯成opcode，并執(zhí)行。最后關(guān)閉zend虛擬機(jī)。

**CGI進(jìn)程/線程和ZEND虛擬機(jī)的關(guān)系**：cgi進(jìn)程調(diào)用并初始化zend虛擬機(jī)的各種環(huán)境。

***

#####8）常見的SAPI

SAPI提供了一個(gè)和外部通信的接口，常見的SAPI有：cgi 、fast-cgi、cli、isapi、apache 模塊的 DLL

***

####3.圖解靜態(tài)請求和動(dòng)態(tài)請求


***


###4.PHP的組成

**PHP總共有三個(gè)模塊：內(nèi)核、Zend引擎、以及擴(kuò)展層。**

**PHP內(nèi)核**用來處理請求、文件流、錯(cuò)誤處理等相關(guān)操作。

**Zend引擎**用以將源文件轉(zhuǎn)換成機(jī)器語言，然后在虛擬機(jī)上運(yùn)行它。

**擴(kuò)展層**是一組函數(shù)、類庫和流，PHP使用它們來執(zhí)行一些特定的操作。

比如，我們需要mysql擴(kuò)展來連接MySQL數(shù)據(jù)庫； 當(dāng)ZE執(zhí)行程序時(shí)可能會(huì)需要連接若干擴(kuò)展，這時(shí)ZE將控制權(quán)交給擴(kuò)展，等處理完特定任務(wù)后再返還；最后，ZE將程序運(yùn)行結(jié)果返回給PHP內(nèi)核，它再將結(jié)果傳送給SAPI層，最終輸出到瀏覽器上。

####5、WEB-SERVER和PHP-CGI的交互模式

web server和php-cgi有3種交互模式。

* **cgi模式**：httpd接收到一個(gè)動(dòng)態(tài)請求就fork一個(gè)cgi進(jìn)程，cgi進(jìn)程返回結(jié)果給httpd進(jìn)程后自我銷毀。

* **動(dòng)態(tài)模塊模式**：將php-cgi的模塊編譯進(jìn)httpd(Apache的方法)。在httpd啟動(dòng)時(shí)會(huì)加載模塊，加載時(shí)也將對應(yīng)的模塊激活，php-cgi也就啟動(dòng)了。(注：糾正一個(gè)小小錯(cuò)誤，很多人以為動(dòng)態(tài)編譯的模塊是可以在需要的時(shí)候隨時(shí)加載調(diào)用，不需要的時(shí)候它們就停止了，實(shí)際上不是這樣的。和靜態(tài)編譯的模塊一樣，動(dòng)態(tài)加載的模塊在被加載時(shí)就被加入到激活鏈表中，無論是否使用它，它都已經(jīng)運(yùn)行在apache httpd的內(nèi)部)

* **php-fpm模式**：使用php-fpm管理php-cgi，此時(shí)httpd不再控制php-cgi進(jìn)程的啟動(dòng)。可以將php-fpm獨(dú)立運(yùn)行在非web服務(wù)器上，實(shí)現(xiàn)所謂的動(dòng)靜分離。

實(shí)際上，借助模塊mod_fastcgi還可以實(shí)現(xiàn)fastcgi模式。同cgi一樣，管理模式的先天缺陷決定了這并不是一種好方法。

###

###2、PHP的生命周期

####流程圖解：


####PHP開始和結(jié)束階段：


由上面的圖，我們能知道，SAPI運(yùn)行PHP都經(jīng)過下面幾個(gè)階段

*? 模塊初始化階段(Module init)：即調(diào)用每個(gè)拓展源碼中的的PHP\_MINIT\_FUNCTION中的方法初始化模塊,進(jìn)行一些模塊所需變量的申請,內(nèi)存分配等。

* 請求初始化階段(Request init)：即接受到客戶端的請求后調(diào)用每個(gè)拓展的PHP\_RINIT\_FUNCTION中的方法,初始化PHP腳本的執(zhí)行環(huán)境。

* 執(zhí)行PHP腳本

?

* 請求結(jié)束(Request Shutdown)：這時(shí)候調(diào)用每個(gè)拓展的PHP\_RSHUTDOWN\_FUNCTION方法清理請求現(xiàn)場,并且ZE開始回收變量和內(nèi)存。

* 關(guān)閉模塊(Module shutdown)： Web服務(wù)器退出或者命令行腳本執(zhí)行完畢退出會(huì)調(diào)用拓展源碼中的PHP\_MSHUTDOWN\_FUNCTION 方法。

####我們具體來看看每一步都做了什么？

1）**模塊初始化階段**：

在整個(gè)SAPI生命周期內(nèi)(例如Apache啟動(dòng)以后的整個(gè)生命周期內(nèi)或者命令行程序整個(gè)執(zhí)行過程中)， 該過程只進(jìn)行一次，第一步的操作在任何請求到達(dá)之前就發(fā)生了。

PHP調(diào)用各個(gè)擴(kuò)展的MINIT方法，從而使這些擴(kuò)展切換到可用狀態(tài)。我們可以看看php.ini文件里打開了哪些擴(kuò)展，這些擴(kuò)展會(huì)在這個(gè)階段進(jìn)行”模塊初始化“。 MINIT的意思是“模塊初始化”。各個(gè)模塊都定義了一組函數(shù)、類庫等用以處理其他請求。

2） **請求初始化**：

當(dāng)一個(gè)頁面請求發(fā)生時(shí)，SAPI層將控制權(quán)交給PHP層。于是PHP設(shè)置了用于回復(fù)本次請求所需的環(huán)境變量。同時(shí)，它還建立一個(gè)變量表，用來存放執(zhí)行過程 中產(chǎn)生的變量名和值。PHP調(diào)用各個(gè)模塊的RINIT方法，即“請求初始化”。一個(gè)經(jīng)典的例子是Session模塊的RINIT，如果在php.ini中 啟用了Session模塊，那在調(diào)用該模塊的RINIT時(shí)就會(huì)初始化$_SESSION變量，并將相關(guān)內(nèi)容讀入；RINIT方法可以看作是一個(gè)準(zhǔn)備過程， 在程序執(zhí)行之間就會(huì)自動(dòng)啟動(dòng)。

3）**執(zhí)行腳本**

一旦請求被初始化了，ZE開始接管控制權(quán)，將PHP腳本翻譯成符號(hào)(OPcode)，最終形成操作碼并逐步運(yùn)行之。如任一操作碼需要調(diào)用擴(kuò)展的函數(shù)，ZE將會(huì)把參數(shù)綁定到該函數(shù)，并且臨時(shí)交出控制權(quán)直到函數(shù)運(yùn)行結(jié)束。

1. scanner

?

? ? 將PHP代碼轉(zhuǎn)換為Tokens，詳見代碼Zend/zend\_language\_scanner.l。

?

2. parser

?

? ? 將Tokens轉(zhuǎn)換成表達(dá)式，詳見代碼Zend/zend\_language\_parser.y。

?

3. compile

?

? ? 將表達(dá)式編譯成opcode。opcode存放在op\_array中。

?

4. execute

?

? ? Zend Engine調(diào)用zend\_execute來執(zhí)行op\_array，輸出結(jié)果。

4）**關(guān)閉第一步（請求關(guān)閉）**

如同PHP啟動(dòng)一樣，PHP的關(guān)閉也分兩步。一旦頁面執(zhí)行完畢（無論是執(zhí)行到了文件末尾還是用exit或die函數(shù)中止），PHP就會(huì)啟動(dòng)清理程序。它會(huì)按順序調(diào)用各個(gè)模塊的RSHUTDOWN方法。 RSHUTDOWN用以清除程序運(yùn)行時(shí)產(chǎn)生的符號(hào)表，也就是對每個(gè)變量調(diào)用unset函數(shù)。

5）**關(guān)閉第二步（模塊關(guān)閉）**

所有的請求都已處理完畢，SAPI也準(zhǔn)備關(guān)閉了，PHP開始執(zhí)行第二步：PHP調(diào)用每個(gè)擴(kuò)展的MSHUTDOWN方法，這是各個(gè)模塊最后一次釋放內(nèi)存的機(jī)會(huì)。

**這樣，整個(gè)PHP生命周期就結(jié)束了。要注意的是，只有在服務(wù)器沒有請求的情況下才會(huì)執(zhí)行“啟動(dòng)第一步”和“關(guān)閉第二步”。**

###3、PHP底層工作原理


**從圖上可以看出，php從下到上是一個(gè)4層體系**

**①Zend引擎**

Zend整體用純c實(shí)現(xiàn)，是php的內(nèi)核部分，它將php代碼翻譯（詞法、語法解析等一系列編譯過程）為可執(zhí)行opcode的處理并實(shí)現(xiàn)相應(yīng)的處理方法、實(shí)現(xiàn)了基本的數(shù)據(jù)結(jié)構(gòu)（如hashtable、oo）、內(nèi)存分配及管理、提供了相應(yīng)的api方法供外部調(diào)用，是一切的核心，所有的外圍功能均圍繞zend實(shí)現(xiàn)。

**②Extensions**

圍繞著zend引擎，extensions通過組件式的方式提供各種基礎(chǔ)服務(wù)，我們常見的各種內(nèi)置函數(shù)（如array系列）、標(biāo)準(zhǔn)庫等都是通過extension來實(shí)現(xiàn)，用戶也可以根據(jù)需要實(shí)現(xiàn)自己的extension以達(dá)到功能擴(kuò)展、性能優(yōu)化等目的（如貼吧正在使用的php中間層、富文本解析就是extension的典型應(yīng)用）。

**③Sapi**

Sapi全稱是Server Application Programming Interface，也就是服務(wù)端應(yīng)用編程接口，sapi通過一系列鉤子函數(shù)，使得php可以和外圍交互數(shù)據(jù)，這是php非常優(yōu)雅和成功的一個(gè)設(shè)計(jì)，通過sapi成功的將php本身和上層應(yīng)用解耦隔離，php可以不再考慮如何針對不同應(yīng)用進(jìn)行兼容，而應(yīng)用本身也可以針對自己的特點(diǎn)實(shí)現(xiàn)不同的處理方式。后面將在sapi章節(jié)中介紹

**④上層應(yīng)用**

這就是我們平時(shí)編寫的php程序，通過不同的sapi方式得到各種各樣的應(yīng)用模式，如通過webserver實(shí)現(xiàn)web應(yīng)用、在命令行下以腳本方式運(yùn)行等等。

**構(gòu)架思想：**

引擎(Zend)+組件(ext)的模式降低內(nèi)部耦合

中間層(sapi)隔絕web server和php

總結(jié)

以上是生活随笔為你收集整理的OSI七层网络模型 TCP/IP五层网络模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。