一洪添、輸入一個網(wǎng)址后都發(fā)生了什么
- 輸入網(wǎng)址并回車,瀏覽器檢查網(wǎng)絡是否連通
2雀费、解析域名(訪問DNS服務器)
3干奢、瀏覽器發(fā)送HTTP請求
4、服務器處理請求
5盏袄、服務器返回HTML響應
6律胀、瀏覽器處理HTML頁面
7、繼續(xù)請求其他資源
這時我們要注意的是客戶端請求服務器的鏈路和服務器返回客戶端的鏈路不一定是同一條貌矿。
擴展
拓撲結構: 拓撲結構是指網(wǎng)絡中各個站點相互連接的形式,在局域網(wǎng)中明確一點講就是文件服務器罪佳、工作站和電纜等的連接形式
二逛漫、什么是http協(xié)議
HTTP是超文本傳輸協(xié)議,從www瀏覽器傳輸?shù)奖镜貫g覽器的一種傳輸協(xié)議赘艳,網(wǎng)站是基于HTTP協(xié)議的酌毡,例如網(wǎng)站的圖片、CSS蕾管、JS等都是基于 HTTP協(xié)議進行傳輸?shù)摹?br> HTTP協(xié)議是由從客戶機到服務器的請求(Request)和從服務器到客戶機的響應(response)進行約束和規(guī)范枷踏。
三、TCP/IP協(xié)議棧
先來看下這張圖:
我們來看右邊掰曾,看看我們網(wǎng)站在每一層都干了什么旭蠕。
應用層: HTTP、FTP旷坦、DNS掏熬、SMTP等
傳輸層:
- 為應用層實體提供端到端的通信功能,保證數(shù)據(jù)包的順序傳送及數(shù)
據(jù)的完整性秒梅。 - 該層定義了兩個主要的協(xié)議:傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)報協(xié) 議(UDP)
- 數(shù)據(jù)可靠性封裝
網(wǎng)絡層:主要解決主機到主機的通信問題旗芬。IP協(xié)議是網(wǎng)際互聯(lián)層最重要的協(xié)議
網(wǎng)絡接口層: 這里分為兩層。
- 上層:網(wǎng)卡捆蜀,負責將數(shù)據(jù)傳到電腦
- 下層:如wifi疮丛,光纜等
TCP/IP在協(xié)議棧中的位置如下圖:
image.png
這里我們要知道HTTP和HTTPS是兩套不同的協(xié)議
HTTP默認端口號為80;HTTPS默認端口號為443
目前普遍應用版本HTTP 1.1 正在逐步向HTTP 2遷移
再來看下左邊的OSI模型
應用層:軟件相關
表示層:數(shù)據(jù)格式
會話層:加密
數(shù)據(jù)鏈路層:mac地址辆它,網(wǎng)卡
物理層:硬件誊薄,光纜,路由器
我們再來看看每一層分別傳輸?shù)膮f(xié)議娩井,如下圖:
四暇屋、HTTP的工作過程
一次HTTP操作稱為一個事務,其工作過程可分為四步:
1)首先客戶機與服務器需要建立連接洞辣。只要單擊某個超級鏈接咐刨,HTTP的工作開始昙衅。
2)建立連接后,客戶機發(fā)送一個請求給服務器定鸟,請求方式的格式為:統(tǒng)一資源標識符(URL)而涉、協(xié)議版本號, 后邊是MIME信息包括請求修飾符联予、客戶機信息和可能的內(nèi)容啼县。
3)服務器接到請求后,給予相應的響應信息沸久,其格式為一個狀態(tài)行季眷,包括信息的協(xié)議版本號、一個成功 或錯誤的代碼卷胯,后邊是MIME信息包括服務器信息子刮、實體信息和可能的內(nèi)容。
4)客戶端接收服務器所返回的信息通過瀏覽器顯示在用戶的顯示屏上窑睁,然后客戶機與服務器斷開連接挺峡。
如果在以上過程中的某一步出現(xiàn)錯誤,那么產(chǎn)生錯誤的信息將返回到客戶端担钮,有顯示屏輸出橱赠。對于用戶 來說,這些過程是由HTTP自己完成的箫津,用戶只要用鼠標點擊狭姨,等待信息顯示就可以了。
五鲤嫡、HTTP請求與響應
HTTP請求組成:請求行送挑、消息報頭、請求正文暖眼。 HTTP響應組成:狀態(tài)行惕耕、消息報頭、響應正文诫肠。 請求行組成:以一個方法符號開頭司澎,后面跟著請求的URI和協(xié)議的版本。
狀態(tài)行組成:服務器HTTP協(xié)議的版本栋豫,服務器發(fā)回的響應狀態(tài)代碼和狀 態(tài)代碼的文本描述挤安。
要注意的是服務器主動推送不算response,http1.1 之服務器只能接收請求丧鸯,不會主動發(fā)起請求蛤铜,http2以后服務器可以主動發(fā)起請求
我們首先來看請求頭,如下圖所示
這里我們可以看到,每行結尾出都有個回車符加換行符围肥,報文頭和報文體中間另外多了一個空行(回車符/r剿干,換行符/n)。這是為了不使解析錯誤穆刻,因為報文頭置尔,響應頭行數(shù)是不確定的,為了區(qū)分報文頭與報文體氢伟,所以空一行
我們再來看下常用的請求頭字段:
Accept: 告訴瀏覽器可以接收什么樣的內(nèi)容 */*表示任何東西
Accepe-Encoding: 告訴服務器接收的數(shù)據(jù)是否接收壓縮
Accept-Language: 語言
Cache-control: 緩存
Connection: 是否支持長連接
cookie: 瀏覽器在本地寫的文本
Pragma: 與緩存有關
Upgrade-Insecure-Requests: 安全性相關
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
User-Agent:以前功能榜轿,通過識別瀏覽器,操作系統(tǒng)等推送不同的個性頁面朵锣,現(xiàn)在收集隱私谬盐,防低級反爬蟲措施
Mozilla/5.0(瀏覽器標識,競爭的產(chǎn)物)诚些,Macintosh; Intel Mac OS X 10_14_0(電腦機型),AppleWebKit/537.36(瀏覽器內(nèi)核),KHTML, like Gecko(版本號),Chrome/70.0.3538.110 Safari/537.36 瀏覽器產(chǎn)品名字
referer: 請求來源路徑(通過哪一個頁面设褐,哪個地方過來的),作安全性檢查
Accept 請求報頭域用于指定客戶端接受哪些類型的信息泣刹。eg:Accept:image/gif,Accept:text/ htmlAccept-Charset請求報頭域用于指定客戶端接受的字符集犀被。Accept-Encoding:Accept-Encoding請求報 頭域類似于Accept椅您,但是它是用于指定可接受的內(nèi)容編碼。
Accept-Language 請求報頭域類似于Accept寡键,但是它是用于指定一種自然語言掀泳。
Authorization請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時西轩,如果收到服 務器的響應代碼為401(未授權)员舵,可以發(fā)送一個包含Authorization 請求報頭域的請求,要求服務器對其進 行驗證藕畔。
Host請求報頭域主要用于指定被請求資源的Internet主機和端口號马僻,它通常從HTTP URL中提取出來的,發(fā) 送請求時注服,該報頭域是必需的韭邓。
User-Agent請求報頭域允許客戶端將它的操作系統(tǒng)、瀏覽器和其它屬性告訴服務器溶弟。
下面再來看下響應頭:
這里我們需要注意的是女淑,響應頭是可以自己加字段的(下面HTTP2部分會詳細介紹),理論上x開頭的都是自定義的辜御。且如果有帶冒號的響應頭鸭你,則說明是http2協(xié)議
Bdpagetype: 2
Bdqid: 0x8b99350d0002163f 這兩行是百度自己的
Cache-Control: 緩存策略中的一部分
Connection: 和請求頭的對應
Content-Encoding: 和請求頭的對應
Content-Type: text/html;charset=utf-8 返回給頁面內(nèi)容的描述
Date: Sat, 緩存用的,服務器的響應時間
Expires: 緩存用的,緩存有效時間
Server: web服務器是哪一種
Set-Cookie: 逐條返回的cookie袱巨,這是因為瀏覽器發(fā)送給服務器時是鍵值對形式阁谆,服務器返回給瀏覽器的除了key,value外還有返回路徑,對域的限制瓣窄,安全性等等
Strict-Transport-Security: 安全性相關
Transfer-Encoding: chunked 固定用法
X-Ua-Compatible: IE=Edge,chrome=1 支持什么樣的瀏覽器和版本
Location響應報頭域用于重定向接受者到一個新的位置笛厦。Location響應 報頭域常用在更換域名的時候。
Server響應報頭域包含了服務器用來處理請求的軟件信息俺夕。與User- Agent請求報頭域是相對應的裳凸。
WWW-Authenticate響應報頭域必須被包含在401(未授權的)響應消息 中,客戶端收到401響應消息時候劝贸,并發(fā)送Authorization報頭域請求服 務器對其進行驗證時姨谷,服務端響應報頭就包含該報頭域。
實體報頭
請求和響應消息都可以傳送一個實體映九。一個實體由實體報頭域和實體正 文組成梦湘,但并不是說實體報頭域和實體正文要在一起發(fā)送,可以只發(fā)送 實體報頭域件甥。實體報頭定義了關于實體正文(eg:有無實體正文)和請 求所標識的資源的元信息捌议。
常用的實體報頭
Content-Encoding實體報頭域被用作媒體類型的修飾符,它的值指示了已經(jīng)被應用到實體正文的 附加內(nèi)容的編碼引有,因而要獲得Content-Type報頭域中所引用的媒體類型瓣颅,必須采用相應的解碼 機制。
Content-Language實體報頭域描述了資源所用的自然語言譬正。 Content-Length實體報頭域用于指明實體正文的長度宫补,以字節(jié)方式存儲的十進制數(shù)字來表示。 Content-Type實體報頭域用語指明發(fā)送給接收者的實體正文的媒體類型曾我。 Last-Modified實體報頭域用于指示資源的最后修改日期和時間粉怕。 Expires實體報頭域給出響應過期的日期和時間。
六抒巢、請求方式
http0.9只支持GET贫贝,POST,http1.0加了HEAD蛉谜,http1.1又加了以下5個平酿,PUT,DELETE悦陋,TRACE蜈彼,CONNECT,OPTIONS
GET: 請求獲取Request-URI所標識的資源
POST: 在Request-URI所標識的資源后附加新的數(shù)據(jù)
HEAD: 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT: 請求服務器存儲一個資源俺驶,并用Request-URI作為其標識 DELETE: 請求服務器刪除Request-URI所標識的資源
TRACE: 請求服務器回送收到的請求信息幸逆,主要用于測試或診斷 CONNECT:HTTP/1.1協(xié)議中預留給能夠?qū)⑦B接改為管道方式的代理服務器棍辕。 OPTIONS: 請求查詢服務器的性能,或者查詢與資源相關的選項和需求
head一般用于測試还绘,和get區(qū)別是不會返回內(nèi)容楚昭,只返回響應頭
嚴格意義上post用來修改拍顷,put用來添加
七昔案、HTTP狀態(tài)碼
狀態(tài)代碼有三位數(shù)字組成踏揣,第一個數(shù)字定義了響應的類別捞稿,且有五種可能取值:
1xx:指示信息--表示請求已接收娱局,繼續(xù)處理
2xx:成功--表示請求已被成功接收衰齐、理解娇斩、接受
3xx:重定向--要完成請求必須進行更進一步的操作
4xx:客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)
5xx:服務器端錯誤--服務器未能實現(xiàn)合法的請求
502一般代表反向代理出錯
八、cookie與session
- Cookie:客戶端將服務器設置的Cookie返回到服務器;
- Set-Cookie:服務器向客戶端設置Cookie;
服務器在響應消息中用Set-Cookie頭將 Cookie的內(nèi)容回送給客戶端芒帕,客戶端在 新的請求中將相同的內(nèi)容攜帶在Cookie 頭中發(fā)送給服務器背蟆。從而實現(xiàn)會話的保 持。
九志珍、HTTP緩存機制
緩存會根據(jù)請求保存輸出內(nèi)容的副本伦糯,例如html頁面,圖片喂击,文件翰绊,當 下一個請求來到的時候:如果是相同的URL,緩存直接使用副本響應訪 問請求秤茅,而不是向源服務器再次發(fā)送請求框喳。
使用緩存有如下優(yōu)點:
- 減少相應延遲
- 減少網(wǎng)絡帶寬消耗
先來看下第一次請求時的情況,如下圖:
接下來是之后請求的情況
我們來了解下兩種緩存策略,強制緩存與對比緩存
- 強制緩存诞挨,服務器通知瀏覽器一個緩存時間,在緩存時間內(nèi)呢蛤,下次請求,直接用緩存其障,不在時間內(nèi),執(zhí)行比較緩存策略励翼。
- 比較緩存,將緩存信息中的Etag和Last-Modified通過請求發(fā)送給服務器汽抚,由服務器校驗抓狭,返 回304狀態(tài)碼時,瀏覽器直接使用緩存辐宾。
Etag/If-None-Match策略
Last-Modified/If-Modified-Since策略
十叠纹、HTTPS協(xié)議分析
HTTPS協(xié)議的安全性由SSL協(xié)議實現(xiàn)誉察,當前使用的TLS協(xié)議1.2版本包含了四個核 心子協(xié)議:握手協(xié)議持偏、密鑰配置切換協(xié)議、應用數(shù)據(jù)協(xié)議及報警協(xié)議。
數(shù)字證書:數(shù)字證書是互聯(lián)網(wǎng)通信中標識雙方身份信息的數(shù)字文件卿叽,由CA簽發(fā)桥胞。
CA:CA(certification authority)是數(shù)字證書的簽發(fā)機構。作為權威機構考婴,其審 核申請者身份后簽發(fā)數(shù)字證書贩虾,這樣我們只需要校驗數(shù)字證書即可確定對方的真 實身份。
HTTPS協(xié)議沥阱、SSL協(xié)議缎罢、TLS協(xié)議、握手協(xié)議的關系
- HTTPS是Hypertext Transfer Protocol over Secure Socket Layer的縮寫考杉,即 HTTP over SSL策精,可理解為基于SSL的HTTP協(xié)議。HTTPS協(xié)議安全是由SSL協(xié) 議實現(xiàn)的崇棠。
- SSL協(xié)議是一種記錄協(xié)議咽袜,擴展性良好,可以很方便的添加子協(xié)議易茬,而握手協(xié) 議便是SSL協(xié)議的一個子協(xié)議。
-
TLS協(xié)議是SSL協(xié)議的后續(xù)版本及老,本文中涉及的SSL協(xié)議默認是TLS協(xié)議1.2版 本抽莱。
過程如下圖所示:
image.png
十一、 HTTP 2協(xié)議分析
- 使用二進制格式傳輸骄恶,更高效食铐、更緊湊。
- 對報頭壓縮僧鲁,降低開銷虐呻。
- 多路復用象泵,一個網(wǎng)絡連接實現(xiàn)并行請求。
- 服務器主動推送斟叼,減少請求的延遲
-
默認使用加密
來看下HTTPHTTP1.1與2的對比圖
image.png
來看下HTTP2的偽頭字段
偽頭部字段是http2內(nèi)置的幾個特殊的以”:”開始的 key偶惠,用于替代HTTP/1.x中請求行/響應行中的信 息,比如請求方法朗涩,響應狀態(tài)碼等
- :method 目標URL模式部分(請求)
- :scheme 目標URL模式部分(請求)
- :authority 目標RUL認證部分(請求)
- :path 目標URL的路徑和查詢部分(絕對路徑 產(chǎn)生式和一個跟著"?"字符的查詢產(chǎn)生式)忽孽。 (請求)
- :status 響應頭中的HTTP狀態(tài)碼部分(響應)
十二、三次握手谢床,四次揮手
在說這個之前兄一,我們先來看下分包問題,因為當數(shù)據(jù)很大時识腿,一旦傳輸時某個地方出錯出革,那這個包就要重新發(fā)送,所以我們需要分成很多小包渡讼。我們知道網(wǎng)絡是拓撲結構的骂束,所以傳輸時通過的鏈路是不相同的,那么收到的包也是亂序的硝全,所以我們需要給每個包排上編號栖雾,以便進行編號,這樣即使發(fā)生丟包伟众,服務端也會將丟包的編號發(fā)給服務端析藕,服務端只需要把這個編號的包重新發(fā)送。
來看下上圖凳厢,可以簡單概括為如下這幾個步驟账胧,其中seq是請求包編號,ACK是應答包編號
客戶端請求->服務端應答->客戶端應答->數(shù)據(jù)傳輸->客戶端發(fā)出關閉請求->服務器檢查是否還有工作->服務器發(fā)出關閉應答->客戶端發(fā)送斷開連接
之所以關閉時進行了四次揮手是為了防止半連接問題先紫。
十三治泥、DNS解析
首先我們來看一個域名:以https: www.baidu.com/index
為例,其中https: www.baidu.com
是域名遮精,index
是資源路徑
下面來看看我們購買一個域名時不同的記錄都代表什么:
SOA:指定哪個服務器解析DNS居夹,這個一般都是配好的,不需要我們處理
A記錄:只能解析IPv4
CNAME:多個域名指向同一臺服務器