php請求的全過程：
網(wǎng)頁調(diào)用請求:
1.dns域名解析:
1.1 本地域名解析(未找到則走1.2)
1.2 遠程dns域名解析
2.三次握手協(xié)議:
客戶端發(fā)起連接請求,服務器接收后返回應答告訴客戶端接收到了請求嗤形，客戶端接收到應答請求后返回確認接收應答請求，連接建立弧圆。
(ps：為啥是三次握手而不是兩次赋兵？ 三次握手的本質是客戶端和服務器端相互確認對方開始通信的序列號笔咽，兩次握手只能確定客戶端的初始序列號而沒有對服務器端的序列號進行確認，這樣會導致服務器端無法知道接收到的請求連接是否是正確的或者是延遲的霹期，導致服務器端面對一個錯誤的請求也要正常執(zhí)行產(chǎn)生問題叶组。
因為序列號沒有綁定到整個網(wǎng)絡的全局時鐘，所以無法確認請求中的序列號是否正確历造。所以需要三次握手讓雙方確認對方的序列號)
(ps:為啥不是四次握手甩十？
三次握手之后的握手雙方都確定了對方的序列號，確保了通信的可靠性吭产，不需要在進行握手來確定)
rfc793協(xié)議： 當兩個進程需要通信的時候侣监，他們的TCPs必須首先建立一個連接（在每一端初始化狀態(tài)信息）。當通信完成的時候臣淤，連接終止或者關閉以釋放資源用于其它用途。由于連接必須在不可靠的主機和不可靠的internet通信系統(tǒng)上建立姓蜂，一個帶有基于時鐘的系列號的握手機制被用來避免連接的錯誤初始化钱慢。三次握手的基本原則是防止老的重復連接發(fā)起導致的混亂
TCP 需要 seq 序列號來做可靠重傳或接收，而避免連接復用時無法分辨出 seq 是延遲或者是舊鏈接的 seq麦箍，因此需要三次握手來約定確定雙方的 ISN（初始 seq 序列號）
3.請求到達web服務器（以nginx為例）挟裂，nginx識別請求是php請求诀蓉，根據(jù)nginx配置文件中配置php處理路徑將請求轉發(fā)給fastcgi進行管理器進行php請求解析。（php-fpm是fastcgi協(xié)議的實現(xiàn)添吗，并添加了進程管理的功能僵腺。fastcgi是cgi協(xié)議的優(yōu)化版辰如，解決了每次請求都要初始化進程導致的效率低下琉兜。 cgi協(xié)議是客戶端與服務器端進行通信用來規(guī)范雙方通信傳輸中數(shù)據(jù)類型和數(shù)據(jù)結構的協(xié)議。nginx服務器就是以這個協(xié)議來和php解析器進行通信)
4.PHP解析器解析PHP文件并執(zhí)行梧疲，執(zhí)行后將數(shù)據(jù)返回給web服務器擂找，服務器在將數(shù)據(jù)回傳給客戶端贯涎。
5.請求結束陆盘，執(zhí)行四次揮手協(xié)議斷開鏈接。（四次揮手：客戶端發(fā)起fin報文斷開鏈接請求妻顶，服務器收到請求并不會立即斷開請求幔嗦，因為服務器可能還有未回傳數(shù)據(jù)在處理邀泉，服務器會回傳一個ack報文確認收到客戶端請求庞钢，客戶端接收后不再傳數(shù)據(jù)給服務器并等待服務器發(fā)送fin報文斷開鏈接焊夸。當服務器端處理完后向客戶端發(fā)起fin報文結束請求阱穗，客戶端接收后回傳ack報文，此時雙方斷開請求）（ps：為啥是四次揮手鲁僚？因為客戶端發(fā)起斷開請求，服務器可能還沒有將數(shù)據(jù)全部回傳給客戶端拓挥，這時返回一個確認報文告訴客戶端可以斷開客戶端到服務器端的數(shù)據(jù)傳輸侥啤，當服務器處理完后再發(fā)送fin請求告訴客戶端已經(jīng)處理完數(shù)據(jù)可以斷開鏈接，客戶端收到后返回一個確認報文給服務器赁炎，這時雙方都知道對方不會再傳輸數(shù)據(jù)于是斷開鏈接）
