頁面解析的流程學習
一、域名解析的整個過程
1.域名和域名解析概念
a、域名
域名(Domain names)是互聯網基礎架構的關鍵部分。它們為互聯網上任何可用的網頁服務器提供了方便人類理解的地址。
域名格式:
頂級域名:
國家頂級域名nTLD:采用ISO3166的規定。如:cn代表中國,us代表美國,uk代表英國,等等。
通用頂級域名gTLD:最常見的通用頂級域名有7個,即:com(公司企業),net(網絡服務機構),org(非營利組織),int(國際組織),gov(美國的政府部門),mil(美國的軍事部門)。
基礎結構域名(infrastructure domain):這種頂級域名只有一個,即arpa,用于反向域名解析,因此稱為反向域名

b、域名解析
DNS,就是Domain Name System的縮寫,翻譯過來就是域名系統,是互聯網上作為域名和IP地址相互映射的一個分布式數據庫。DNS能夠使用戶更方便的訪問互聯網,而不用去記住能夠被機器直接讀取的IP數串。通過域名,最終得到該域名對應的IP地址的過程叫做域名解析(或主機名解析)。
2、域名解析的過程
- 在輸入www.xxx.com后,首先檢查瀏覽器緩存,如果有則直接返回ip
- 如果沒有查到,就在操作系統緩存里面查找,linux的話在/etc/hosts
- 如果沒有查到,就去本地DNS服務器查找,本地DNS服務器一般都是你的網絡接入服務器商提供,比如中國電信,中國移動。一般80%的域名都可以查到。
- 如果沒有查到,本地DNS服務器就去根域名服務器查找,根DNS服務器沒有記錄具體的域名和IP地址的對應關系,而是告訴本地DNS服務器,你可以到域服務器上去繼續查詢,并給出域服務器的地址。
- 然后根域名服務器去對應的域名服務器查詢,比如去.com域服務器,.com域服務器收到請求之后,也不會直接返回域名和IP地址的對應關系,而是告訴本地DNS服務器,你的域名的解析服務器的地址
- 本地DNS服務器向域名的解析服務器發出請求,這時就能收到一個域名和IP地址對應關系,本地DNS服務器不僅要把IP地址返回給用戶電腦,還要把這個對應關系保存在緩存中,以備下次別的用戶查詢時,可以直接返回結果,加快網絡訪問。

3、cdn和waf技術
a、cdn技術
CDN的全稱是Content Delivery Network,即內容分發網絡。使用戶可就近取得所需內容,解決Internet網絡擁擠的狀況,提高用戶訪問網站的響應速度。
- 提高用戶的訪問速度
- 減輕服務器的壓力
- 提升網站的穩定性和安全性

可以看到,使用了cdn技術的服務器,在域名解析的時候,解析的并不是源站的IP,而是cdn服務器的IP,
b、waf
waf:也叫web應用防火墻,通過對HTTP(S)請求進行檢測,識別并阻斷SQL注入、跨站腳本攻擊、網頁木馬上傳、命令/代碼注入、文件包含、敏感文件訪問、第三方應用漏洞攻擊、CC攻擊、惡意爬蟲掃描、跨站請求偽造等攻擊,保護Web服務安全穩定。


可以看到,云waf的發展趨勢越來越猛,目前最常見的有騰訊云,阿里云waf等
云waf的繞過:

二、頁面請求的過程
在經過DNS域名解析之后,獲得了服務器的IP地址。然后就開始向服務器發送請求,服務器進行響應等,具體流程如下
1、請求頁面步驟
a、DNS解析
如上所述,在瀏覽器輸入域名之后,通過DNS域名解析獲得服務器的IP
b、建立tcp連接
拿到域名對應的IP地址之后,User-Agent(一般指瀏覽器)會以一個隨機端口(1024<端口<65535)向服務器的WEB程序(常用的有httpd,nginx)等的80端口。這個連接請求(原始的http請求經過TCP/IP4層模型的層層封包)到達服務器端后(這中間有各種路由設備,局域網內除外),進入到網卡,然后是進入到內核的TCP/IP協議棧(用于識別連接請求,解封包,一層一層的剝開),還有可能要經過Netfilter防火墻(屬于內核的模塊)的過濾,最終達到WEB程序,最終建立了TCP/IP的連接。

三次握手完成之后這個TCP連接就進入Established狀態,就可以發起http請求了。
c、發起http請求
HTTP請求報文由三部分組成:請求行,請求頭和請求正文

請求行:用于描述客戶端的請求方式,請求的資源名稱以及使用的HTTP協議的版本號
請求行:描述請求那臺主機,以及客戶端的信息
正文:請求的數據
詳細內容后文詳解
d、服務端進行HTTP響應
HTTP響應也由三部分組成:狀態碼,響應頭和實體內容

狀態碼:狀態碼用于表示服務器對請求的處理結果
2xx:請求成功
3xx:重定向
4xx:客戶端發生錯誤
5xx:服務端發生錯誤
若干響應頭:響應頭用于描述服務器的基本信息,以及客戶端如何處理數據,比如第一次響應的時候會有set cookie響應頭
實體內容:服務器返回給客戶端的數據
注:html資源文件應該不是通過 HTTP響應直接返回去的,應該是通過nginx通過io操作拿到的。
e、瀏覽器請求html
瀏覽器拿到index.html文件后,就開始解析其中的html代碼,遇到js/css/image等靜態資源時,就向服務器端去請求下載(會使用多線程下載,每個瀏覽器的線程數不一樣),這個時候就用上keep-alive特性了,建立一次HTTP連接,可以請求多個資源,下載資源的順序就是按照代碼里的順序,但是由于每個資源大小不一樣,而瀏覽器又多線程請求請求資源,
f、瀏覽器進行頁面渲染
最后,瀏覽器利用自己內部的工作機制,把請求的靜態資源和html代碼進行渲染,渲染之后呈現給用戶,瀏覽器是一個邊解析邊渲染的過程。
2、nginx處理HTTP請求的過程(11個階段)
(1)postread階段
這個階段剛剛獲取到了請求的頭部,還沒有進行任何處理,我們可以拿到一些原始的信息。例如,拿到用戶的真實 IP 地址。
HTTP 協議中,有兩個頭部可以用來獲取用戶 IP:
X-Forwardex-For 是用來傳遞 IP 的,這個頭部會把經過的節點 IP 都記錄下來
X-Real-IP:可以記錄用戶真實的 IP 地址,只能有一個
realip 模塊
默認不會編譯進 Nginx,需要通過 --with-http_realip_module 啟用功能

變量:如果還想要使用原來的 TCP 連接中的地址和端口,需要通過這兩個變量保存
realip_remote_addr
realip_remote_port
功能:修改客戶端地址
指令:
set_real_ip_from:指定可信的地址,只有從該地址建立的連接,獲取的 realip 才是可信的
real_ip_header:指定從哪個頭部取真實的 IP 地址,默認從 X-Real-IP 中取,如果設置從 X-Forwarded-For 中取,會先從最后一個 IP 開始取
real_ip_recursive
環回地址,默認關閉,打開的時候,如果 X-Forwarded-For 最后一個地址與客戶端地址相同,會過濾掉該地址


(2)sever-rewrite階段
首先 rewrite 階段分為兩個,一個是 server_rewrite 階段,一個是 rewrite,這兩個階段都涉及到一個 rewrite 模塊,而在 rewrite 模塊中,有一個 return 指令,遇到該指令就不會再向下執行,直接返回響應。
return 指令的語法如下:
- 返回狀態碼,后面跟上 body
- 返回狀態碼,后面跟上 URL
- 直接返回 URL
返回狀態碼包括以下幾種:
Nginx 自定義:
444:立刻關閉連接,用戶收不到響應
HTTP 1.0 標準:
301:永久重定向
302:臨時重定向,禁止被緩存
HTTP 1.1 標準:
303:臨時重定向,允許改變方法,禁止被緩存
307:臨時重定向,不允許改變方法,禁止被緩存
308:永久重定向,不允許改變方法
return 指令與 error_page
error_page 的作用。當訪問一個網站出現 404 的時候,一般不會直接出現一個 404 NOT FOUND,而是會有一個比較友好的頁面,這就是 error_page 的功能。
1.當 server 下包含 error_page 且 location 下有 return 指令的時候,會執行哪一個呢?
會執行 location 下的 return 指令。
2.return 指令同時出現在 server 塊下和同時出現在 location 塊下,它們有合并關系嗎?
沒有合并關系,先遇到哪個 return 指令就先執行哪一個。
(3)find_config階段
當經過 rewrite 模塊,匹配到 URL 之后,就會進入 find_config 階段,開始尋找 URL 對應的 location 配置。
會用到location指令
location 的匹配規則是僅匹配 URI,忽略參數,有下面三種大的情況:
前綴字符串
常規匹配
=:精確匹配
^~:匹配上后則不再進行正則表達式匹配
正則表達式
~:大小寫敏感的正則匹配
~*:大小寫不敏感
用戶內部跳轉的命名 location
@
(4)rewrite階段
由于 Nginx 已經在 find-config 階段完成了當前請求與 location 的配對,所以從 rewrite 階段開始,location 配置塊中的指令便可以產生作用。當 ngx_rewrite 模塊的指令用于 location 塊中時,便是運行在這個 rewrite 階段。
(5)post_rewrite階段
沒有模塊能夠介入這個階段。這個階段完全是為了配合 ngx_http_rewrite_module 模塊
(6)PREACCESS 階段
ngx_http_limit_conn_module 和 ngx_http_limit_req_module 模塊工作在這個階段,它們分別實現并發連接數限制和請求速率限制功能。
limit_conn模塊
(7) ACCESS 階段
ngx_http_access_module 和 ngx_http_auth_basic_module 工作在這個階段,它們分別實現訪問控制和基本認證的功能。
(8)POST_ACCESS 階段
沒有模塊能夠介入這個階段。這個階段是為了配合 ACCESS 階段。
(9)PRECONTENT 階段
ngx_http_mirror_module 工作在這個階段,實現流量鏡像的功能。
(10)CONTENT 階段
這是最關鍵的一個階段,也是外部模塊最喜歡介入的階段。ngx_http_index_module、ngx_http_static_module 工作在這個階段實現返回靜態頁面的功能。后面分析代碼,我們也是重點關注這個階段。
(11) LOG 階段
ngx_http_log_module 模塊工作在這個階段,實現輸出訪問日志的功能。
功能:將 HTTP 請求相關信息記錄到日志
模塊:ngx_http_log_module,無法禁用
三、HTTP協議的字段即含義
1、http請求報文

2、http方法
- GET:請求訪問已經被URL識別的資源
- POST:傳輸實體的主體
- PUT:傳輸文件
- HEAD:和GET方法一樣,只是不返回報文主體部分,用于確認URL有效性和更新時間
- DELETE:刪除文件
- OPTIONS:查詢針對請求URL指定的資源支持的方法
- TRACE:讓web服務器把之前的請求通信回環給客戶端
3、http響應報文和狀態碼
響應報文:

1xx:信息性狀態碼,接受的請求正在處理 2xx:成功狀態碼
3xx:重定向狀態碼,需要附加操作以完成請求
4xx:客戶端錯誤狀態碼 5xx:服務器錯誤狀態碼
常見狀態碼:
|
200 |
請求正常處理 |
|
301 |
永久性重定向,表示請求的資源被分配了新的url,以后使用現在所指的URL |
|
302 |
臨時重定向,希望用戶(本次)使用新的URL |
|
304 |
資源已找到,但未符合條件請求。該狀態碼表示客戶端發送附帶條件的請求時服務端允許請求訪問資源,但因發生請求未滿足條件的情況后,直接返回304。 |
|
400 |
服務器端無法理解客戶端發送的請求,請求報文中可能存在語法錯誤。 |
|
401 |
該狀態碼表示發送的請求需要有通過HTTP認證的認證信息 |
|
403 |
不允許訪問那個資源。該狀態碼表明對請求資源的訪問被服務器拒絕了。(權限,未授權IP等) |
|
404 |
服務器上沒有請求的資源。路徑錯誤等。 |
|
500 |
該狀態碼表明服務器端在執行請求時發生了錯誤。也有可能是web應用存在bug或某些臨時故障。 |
|
503 |
該狀態碼表明服務器暫時處于超負載或正在停機維護,現在無法處理請求。 |
4、常見http請求首部字段
- Accept:通知服務器,用戶代理能處理的媒體類型,
文本文件:text/html,text/plain,text/css,application/xml
圖片文件:image/jpeg,image/gif,image/png
應用程序或者二進制文件:application/zip
- Accept-Language:告訴服務器用戶能接受的語言,q表示優先級
例如:Accept-Language:zh-cn,zh;q=0.7,en-us,en;q=0.3
- Host:告訴服務器,請求的資源所處的主機名和端口,Host字段在HTTP/1.1規范是唯一一個必須被包含在請求內的首部字段
- Referer:告訴服務器請求的原始資源的URL
例如:Referer:http://www.example.com/index.php
- User-Agent:表示客戶端瀏覽器的版本信息
- Cookie:首部字段Cookie會告知服務器,當客戶端想獲取HTTP狀態管理支持時,就會在請求中包含從服務器接收到的Cookie。接收到多個Cookie時,同樣可以以多個Cookie形式發送
- Connection: keep-alive:可以在請求頭里明確地要求使用長連接機制不管客戶端是否顯式要求長連接,如果服務器支持長連接,它總會在響應報文里顯示“Connection: keep-alive”
5、常見http響應字段
- Server:告訴客戶端當前正在提供 Web 服務的軟件名稱和版本號,例如“Server: openresty/1.15.8.1”。但是出于安全考慮,一般不會給出具體的。
- Location:將響應接收方引導至某個與請求URL不同的資源
- Content-Length:響應報文的長度
四、HTTPS協議的原理
1、https概念
HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容就需要SSL
2、http和https區別
- http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
- http是超文本傳輸協議,信息是明文傳輸;https 則是具有安全性的ssl加密傳輸協議。
- http的連接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。
- https協議需要到CA申請證書
3、ssl安全套接層協議
SSL的體系結構中包含兩個協議子層,其中底層是SSL記錄協議層(SSL Record Protocol Layer);高層是SSL握手協議層(SSL HandShake Protocol Layer)。
SSL協議主要分為兩層:
SSL記錄協議層的作用是為高層協議提供基本的安全服務。SSL紀錄協議針對HTTP協議進行了特別的設計,使得超文本的傳輸協議HTTP能夠在SSL運行。紀錄封裝各種高層協議,具體實施壓縮解壓縮、加密解密、計算和校驗MAC等與安全有關的操作。
SSL握手協議層包括SSL握手協議(SSL HandShake Protocol)、SSL密碼參數修改協議(SSL Change Cipher Spec Protocol)和SSL告警協議(SSL Alert Protocol)。握手層的這些協議用于SSL管理信息的交換,允許應用協議傳送數據之間相互驗證,協商加密算法和生成密鑰等。

階段一:
客戶端首先發送ClientHello消息到服務端,服務端收到ClientHello消息后,再發送ServerHello消息回應客戶端。
其中ClientHello會有一個加密套件用來告訴服務器自己已經知道的密碼套件列表,這是由客戶按優先級排列的,但完全由服務器來決定發送與否。TLS中使用的密碼套件有一種標準格式。

上面的報文中,客戶端發送了18套加密套件。服務端會從中選出一種來作為雙方共同的加密套件。

Server hello確定了使用那種加密方法
階段二
- 證書:服務器將數字證書和到根CA整個鏈發給客戶端,使客戶端能用服務器證書中的服務器公鑰認證服務器。
- 服務器密鑰交換(可選):這里視密鑰交換算法而定
- 證書請求:服務端可能會要求客戶自身進行驗證。
- 服務器握手完成:第二階段的結束,第三階段開始的信號

階段三
客戶機啟動SSL握手第3階段,是本階段所有消息的唯一發送方,服務器是所有消息的唯一接收方。該階段分為3步:
- 證書(可選):為了對服務器證明自身,客戶要發送一個證書信息,這是可選的,在IIS中可以配置強制客戶端證書認證。
- 客戶機密鑰交換(Pre-master-secret):這里客戶端將預備主密鑰發送給服務端,注意這里會使用服務端的公鑰進行加密。
- 證書驗證(可選),對預備秘密和隨機數進行簽名,證明擁有(a)證書的公鑰
階段四
客戶機啟動SSL握手第4階段,使服務器結束。該階段分為4步,前2個消息來自客戶機,后2個消息來自服務器。
建立起一個安全的連接,客戶端發送一個Change Cipher Spec消息,并且把協商得到的CipherSuite拷貝到當前連接的狀態之中。然后,客戶端用新的算法、密鑰參數發送一個Finished消息,這條消息可以檢查密鑰交換和認證過程是否已經成功。其中包括一個校驗值,對客戶端整個握手過程的消息進行校驗。服務器同樣發送Change Cipher Spec消息和Finished消息。握手過程完成,客戶端和服務器可以交換應用層數據進行通信。

浙公網安備 33010602011771號