HTTP協議

http協議

從輸入URL到頁面加載發生了什麼？

一、在瀏覽器中輸入URL
二、瀏覽器經過域名去找到對應的IP

執行步驟 瀏覽器緩存 –-> 系統緩存 –> 路由緩存（服務商） –> ISP DNS 緩存 –> 遞歸查找 詳細DNS參考
查看本地DNS記錄在谷歌中輸入：chrome://net-internals/#dns

瀏覽器緩存 – 瀏覽器時不時的會緩存DNS記錄. 有意思的是, OS並無明確指明瀏覽器每條記錄的生命週期是多長, 因此瀏覽器按期的緩存DNS記錄(大概2-30分鐘不等) chrome://net-internals/#dns.
系統緩存 – 若是緩存中沒有，就去調用 gethostbyname 庫函數（操做系統不一樣函數也不一樣）進行查詢。函數在試圖進行DNS解析以前首先檢查域名是否在本地 Hosts 裏，Hosts 的位置 不一樣的操做系統有所不一樣.
路由緩存 – 若是 gethostbyname 沒有這個域名的緩存記錄，也沒有在 hosts 裏找到，它將會向 DNS 服務器發送一條 DNS 查詢請求。DNS 服務器是由網絡通訊棧提供的，一般是本地路由器或者 ISP 的緩存 DNS 服務器.
ISP DNS 緩存 – 查詢本地網絡提供商的DNS服務器.

遞歸查找 以下示意圖：

三、瀏覽器向服務器發送一個HTTP請求

因爲facebook的頁面是動態的，因此瀏覽器不會從緩存裏讀頁面的內容，瀏覽器會向服務器發送HTTP請求。
請求：

GET http://facebook.com/ HTTP/1.1
Accept: 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, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET: 使用的是get方法，後面顯示是請求的URL（HTTP協議中請求方法有Get和Post）
Accept: 本身接受什麼樣類型的響應
User-Agent: 代表本身是誰
Accept-Encoding: 本身接受什麼樣類型的響應（壓縮類型）
Connection: 告訴服務器不要關閉TCP鏈接以便爲後來請求所重用
Host: 域
Cookie: 是一些鍵值對，能夠用來保持不一樣頁面請求間的狀態。所以cookie能夠儲存登陸的用戶的名稱，服務端爲用戶分配的惟一密碼以及一些用戶設置信息等。cookie是存在客戶端的，每次客戶端向服務器發送請求都會帶上cookie。

四、facebook服務器發出重定向響應,相似告訴瀏覽器你應該訪問」http://www.facebook.com/「而不是」http://facebook.com/」

五、瀏覽器跟隨重定向,向」http://www.facebook.com/「發送請求

六、服務器開始處理請求，服務器開始處理請求並返回響應。

七、服務器返回HTML響應(200成功）

Content-Encoding header告訴瀏覽器響應的body是被gzip給壓縮過的，將body解壓以後，本來的HTML就顯示出來了。
除了解壓方式以外，headers還會告訴瀏覽器如何緩存頁面等

響應狀態碼參考

八、瀏覽器開始渲染HTML

九、瀏覽器發送請求去獲取HTML中的一些內嵌對象

十、瀏覽器發送異步的AJAX請求

HTTP協議概述
HTTP是一種可以獲取如HTML這樣網絡資源的協議。它是Web上數據交換的基礎，是一種client-server協議，也就是說請求一般是由像瀏覽器這樣的接受方發起的。一個完整的web文檔是由不一樣的子文檔從新組合而成的，像是文本、佈局描述、圖片、視頻、腳本等等。

示意圖：

客戶端和服務端經過交換各自的消息（與數據流正好相反）來進行交互。一般由像瀏覽器這樣的客戶端發出的消息叫作requests，那麼被服務端迴應的消息就叫作 responses。

HTTP協議的參與者

HTTP是一個client-server協議：請求經過一個實體被髮出，實體也就是用戶代理。
每個發送到服務器的請求，都會被服務器處理而且返回一個消息，也就是response。在client與server之間，還有許許多多的被稱爲proxies的實體，他們的做用與表現各不相同，好比有些是網關，還有些是caches等。
示意圖：

客戶端: user-agent

嚴格意義來講，user-agent就是任何可以表現出用戶通常行爲的工具。但實際上，這個角色一般都是由瀏覽器來扮演。
簡單來講user-agent就是來者何人,留下姓名的意思。
對於發起請求來講，瀏覽器老是做爲發起一個請求的實體，而永遠不是服務器（雖然一些機制已經可以模擬服務器發起請求的消息了）。
要渲染出一個網頁，瀏覽器首先要發送第一個請求來獲取這個頁面的HTML文檔，再解析它並根據文檔中的資源信息發送其餘的請求來獲取腳本信息，或者CSS來進行頁面佈局渲染，還有一些其它的頁面資源（如圖片和視頻等）。而後，它把這些資源結合到一塊兒，展示出來一個完整的文檔，也就是網頁。打開一個網頁後，瀏覽器還能夠根據腳本內容來獲取更多的資源來更新網頁。
一個網頁就是一個超文本文檔，也就是說有一部分顯示的文本多是連接，啓動它（一般是鼠標的點擊）就能夠獲取一個新的網頁。網頁使得用戶能夠控制它的user-agent來導航Web。瀏覽器來負責翻譯HTTP請求的命令，並翻譯HTTP的返回消息讓用戶能明白返回消息的內容。

瀏覽器發起請求–>服務器給出響應–>瀏覽器進行解析渲染

Web服務端
通訊過程的另外一端，就是一個Web Server來服務並提供客戶端請求的文檔。Server只是虛擬意義上：它能夠是許多共同分擔負載（負載平衡）的一組服務器組成的計算機羣，也能夠是一種複雜的軟件，經過向其餘計算機發起請求來獲取部分或所有資源的軟件。

Server再也不只是一個單獨的機器，它能夠是在同一個機器上裝載的許多服務之一。在HTTP/1.1和Host頭部中，它們甚至能夠共享同一個IP地址。

Proxies
在瀏覽器和服務器之間，有許多計算機和其餘設備轉發了HTTP的消息。由於Web棧層次結構的緣由，它們大多數都出如今傳輸層、網絡層和物理層上，對於HTTP的應用層來講就是透明的（雖然它們可能會對應用層的性能有重要影響）。而還有一部分表如今應用層上的，就叫作proxies了。Proxies既能夠表現得透明，又能夠不透明（看請求是否經過它們），主要表如今這幾個功能上：

緩存（能夠是公開的或是私有的，像瀏覽器的緩存）
過濾（像反病毒掃描，家長監護）
負載均衡，讓多個服務器服務不一樣的請求
對不一樣資源的權限控制
登錄，容許存儲歷史信息

HTTP 的基本性質

HTTP 是簡單的
HTTP 是可擴展的
HTTP 是無狀態，有會話的（而HTTP的核心是無狀態的，cookies的使用能夠建立有狀態的會話。）
HTTP 和鏈接（一個鏈接是由傳輸層來控制的，基本不屬於HTTP的範圍內。然而HTTP並不須要下面傳輸層的協議是面向鏈接的，它只須要它是可靠的，就是說不能丟失消息（至少沒有錯誤）。在因特網兩個最經常使用的傳輸層協議中，TCP是可靠的，而UDP不是。所以，HTTP依賴於TCP進行消息傳遞）

HTTP 能控制什麼

緩存(由服務端能告訴代理和客戶端什麼須要被緩存，緩存多久，而客戶端可以命令中間緩存代理來忽略存儲的文檔。）
開放同源限制(HTTP能夠經過修改頭部來開放這樣的限制，所以web文檔能夠是由不一樣域下的信息拼接成的（在某些狀況下，這樣作還有安全因素考慮在裏面）。)
認證(一些頁面可以被保護起來，僅讓特定的用戶進行訪問。)
代理(服務端和客戶端一般都處在內部網上，彼此的真實地址都是不可見隱藏的。HTTP請求就要經過代理穿過網絡障礙。)
會話(Cookies用一個服務端的狀態鏈接起了每個請求。這就建立了會話)

HTTP 流

當客戶端想要和服務端進行信息交互時（服務端是指做爲最終的服務器，或者是做爲中間代理），過程表現爲下面的幾步：

打開一個TCP鏈接（或者重用以前的一個）
發送一個HTTP報文
讀取服務端返回的報文
關閉鏈接或者爲之後的請求重用鏈接。

HTTP 報文

有兩種HTTP報文的類型，請求與響應，每種都有其特定的格式。

請求
示意圖：

請求由下面的元素組成：

一個HTTP的method，常常是由一個動詞像GET, POST 或者一個名詞像OPTIONS，HEAD來定義客戶端的動做行爲的。一般客戶端的操做都是獲取資源（用GET方法）或者發送一個HTML form表單的值（用POST方法），雖然在一些狀況下也會有其餘的操做。 要獲取的資源的路徑，一般是上下文中就很明顯的元素資源的URL，它沒有protocol （http://），domain（developer.mozilla.org），或是TCP的port（HTTP是80端口）。
HTTP協議的版本號。
爲服務端表達其餘信息的可選擇性的headers。
對於一些像POST這樣的方法，報文的body就包含了發送的資源，這個body與迴應報文的body相似。

響應
示意圖：

響應報文包含了下面的元素

HTTP的版本號。
一個狀態碼（status code），來告知對應的請求發送成功或失敗，以及失敗的緣由。
一個狀態信息，這個信息是非權威的狀態碼描述信息，也就是說能夠由服務端自行設定的。
HTTP headers，與請求的很像。
可選的，可是比在請求報文中更加常見地包含獲取資源的body。

總結

HTTP是很簡單可擴展的一種協議。結合了輕鬆添加頭部信息能力的Client-server結構使得HTTP能夠和Web的功能擴充一同發展。

即便HTTP/2爲了提升性能把HTTP報文嵌到幀中這一舉措增長了複雜度，可是從Web應用的角度來看，報文的基本結構是沒有變化的，從HTTP/1.0發佈起就是相同的。會話流依舊很簡單，用一個簡單的 HTTP message monitor就能夠查看它和debug。

實戰: 使用chrome發者工具

chrome打開itest.info
windows按f12打開chrome開發者工具(mac command+option+i)，並選擇Network標籤
刷新頁面
找到itest.info這個請求，並查看結果
結果

General

Request URL:http://www.itest.info/
Request Method:GET
Status Code:200 OK
Remote Address:119.29.203.242:80
Referrer Policy:no-referrer-when-downgrade

Response Headers

Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Sun, 18 Feb 2018 12:25:50 GMT
ETag:W/"cffea4bad3fa3910cb02d02294ff50fd"
Server:nginx/1.10.3 (Ubuntu)
Set-Cookie:_itest5_session=T004czBTMjJSenJQdHhlT3ExK1YreHA4dnh4QVlrUVMrQ1dtOGdMRlZDK0FNaHZaM0dsM012eVJMcUxkV21wU0xhR2JQTWVIcCtwdHZqTjhuK0UwTjFkUnpRV0tzSkZBTTNYQ0ZUNDZmTll0Z2JvSHhYTEhhTVpERS83ZzZiTHFxczZnR0s2UCt6MURzcGtKVHpoU0NRPT0tLWRmRWZFaTZxUWFPdkZLUW9UYUhTeHc9PQ%3D%3D--dfb838c81bb8f70a1ce3a46052ce65f2e261303d; path=/; HttpOnly
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:170873e5-69b2-43b3-943f-1ce304eb8bd4
X-Runtime:0.011807
X-XSS-Protection:1; mode=block

Resquest Headers

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:zh-CN,zh;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:_itest5_session=Uy9kMVBaWHhzQ241dnVHclFENEwwbUdUVjJwa0JpQWNkN0ZoWEFIQzBjb1ZzZzNpdjFFYWFMZUJKVGliZ2JuaTFyaXFReG1UZURFMFJZOG1TczAzQ0xTWThvZkhBdXhkWFhsZFZIbEJvV2dqVW9LM2NQTFBUZjYwdUdOb293clBYVjB6NjF5TGkzMVBTZ0hSUWFYTElBPT0tLVpORmJ5VTZtVGRQSDgvVVlKSm5EMXc9PQ%3D%3D--6c6125c340dd629da4bf24cf0becac3e4db07aa0; Hm_lvt_906c6961a45234ebc29e93442b414707=1518572575,1518578300,1518675966,1518956108; Hm_lpvt_906c6961a45234ebc29e93442b414707=1518956178
Host:www.itest.info
If-None-Match:W/"b09aa665df826ef2ded50aa4a76dc712"
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

實戰yslow前端性能測試

一、Chrome點擊連接添加yslow插件以下圖：

二、運行yslow插件

三、點擊run test

5條結果低於A

有17個靜態組件不在CDN上
有3個靜態組件，沒有一個很遙遠的過時日期。
有一個純文本組件應該被壓縮
有15個組件不是無cookie的
有5張圖片被縮小了

yslow插件在firefox中不支持36以上版本
加入書籤方法報錯

HTTP緩存

更詳細的緩存信息

緩存是指存儲指定資源的一份拷貝，並在下次請求該資源時提供該拷貝的技術。當 web 緩存發現請求的資源已經被存儲，它會攔截請求，返回該資源的拷貝，而不會去源服務器從新下載。這樣帶來的好處有：緩解服務器端壓力，提高性能(獲取資源的耗時更短了)。對於網站來講，緩存是達到高性能的重要組成部分。緩存須要合理配置，由於並非全部資源都是永久不變的：重要的是對一個資源的緩存應截止到其下一次發生改變（即不能緩存過時的資源）。
示意圖：

HTTP 緩存不是必須的，但重用緩存的資源一般是必要的。然而常見的 HTTP 緩存只能存儲 GET 響應，對於其餘類型的響應則無能爲力。緩存的關鍵主要包括request method和目標URI（通常只有GET請求才會被緩存）。
徹底不支持緩存:緩存中不得存儲任何關於客戶端請求和服務端響應的內容,每次由客戶端發起的請求都會下載完整的響應內容
不緩存內容:在釋放緩存內容前像服務端源地址發送請求以驗證緩存是否有效
公共緩存public：響應能夠被任何請求來源緩存。針對須要進行http身份驗證的頁面或者一些不能被順利緩存的響應碼，經過定義public以支持緩存。
私有緩存private：響應的內容只能被惟一的用戶緩存，不能夠被共享緩存存儲。隱私模式下的瀏覽器會經過這種方式存儲緩存。
緩存過時:判斷緩存是否過時是一個最常使用的標誌是max-age.,它是距離請求發起的時間的秒數,針對一些不會發生改變的文件,能夠手動設置必定的時長保證緩存有效
緩存驗證:must-revalidate:在使用一些老的資源前強制驗證狀態判斷其是否過時
緩存有效性:按期移除一部分緩存文件,叫作緩存拋棄.
緩存驗證:緩存的響應頭信息裏含有"cache-control:must-revalidate",則在瀏覽的過程當中會觸發緩存驗證

HTTP請求（request）

點擊瞭解更多
HTTP消息是服務器和客戶端之間交換數據的方式。有兩種類型的消息︰

請求--由客戶端發送用來觸發一個服務器上的動做；
響應--來自服務器的應答。

HTTP消息由採用ASCII編碼的多行文本構成。在HTTP/1.1及早期版本中，這些消息經過鏈接公開地發送。在HTTP/2中，爲了優化和性能方面的改進，曾經可人工閱讀的消息被分到多個HTTP幀中。

Web 開發人員或網站管理員，不多本身手工建立這些原始的HTTP消息︰ 由軟件、瀏覽器、 代理或 服務器完成。他們經過配置文件（用於代理服務器或服務器），API （用於瀏覽器）或其餘接口提供HTTP消息。

HTTP請求是由客戶端發出的消息，用來使服務器執行動做。起始行 (start-line) 包含三個元素：

一個 HTTP 方法，一個動詞 (像 GET, PUT 或者 POST) 或者一個名詞 (像 HEAD 或者 OPTIONS), 描述要執行的動做. 例如, GET 表示要獲取資源，POST 表示向服務器推送數據 (建立或修改資源, 或者產生要返回的臨時文件)。
請求目標 (request target)，一般是一個 URL，或者是協議、端口和域名的絕對路徑，一般以請求的環境爲特徵。請求的格式因不一樣的 HTTP 方法而異。
HTTP 版本 (HTTP version)，定義了剩餘報文的結構，做爲對指望的響應版本的指示符

Headers

有許多請求頭可用，它們能夠分爲幾組：

General headers，例如 Via，適用於整個報文。
Request headers，例如 User-Agent，Accept-Type，經過進一步的定義(例如 Accept-Language)，或者給定上下文(例如 Referer)，或者進行有條件的限制 (例如 If-None) 來修改請求。
Entity headers，例如 Content-Length，適用於請求的 body。顯然，若是請求中沒有任何 body，則不會發送這樣的頭文件。

示意圖：

Body

請求的最後一部分是它的 body。不是全部的請求都有一個 body：例如獲取資源的請求，GET，HEAD，DELETE 和 OPTIONS，一般它們不須要 body。
Body 大體可分爲兩類：

Single-resource bodies，由一個單文件組成。該類型 body 由兩個 header 定義： Content-Type 和 Content-Length.
Multiple-resource bodies，由多部分 body 組成，每一部分包含不一樣的信息位。一般是和 HTML Forms 連繫在一塊兒。

HTTP響應（response）

狀態行

HTTP 響應的起始行被稱做 狀態行 (status line)，包含如下信息：

協議版本，一般爲 HTTP/1.1。
狀態碼 (status code)，代表請求是成功或失敗。常見的狀態碼是 200，404，或 302。
狀態文本 (status text)。一個簡短的，純粹的信息，經過狀態碼的文本描述，幫助人們理解該 HTTP 消息。
一個典型的狀態行看起來像這樣：HTTP/1.1 404 Not Found。

Headers

響應的 HTTP headers 遵循和任何其它 header 相同的結構：不區分大小寫的字符串，緊跟着的冒號 (‘:’) 和一個結構取決於 header 類型的值。 整個 header（包括其值）表現爲單行形式。

有許多響應頭可用，這些響應頭能夠分爲幾組：

General headers，例如 Via，適用於整個報文。
Response headers，例如 Vary 和 Accept-Ranges，提供其它不符合狀態行的關於服務器的信息。
Entity headers，例如 Content-Length，適用於請求的 body。顯然，若是請求中沒有任何 body，則不會發送這樣的頭文件。

示意圖：

Body

響應的最後一部分是 body。不是全部的響應都有 body：具備狀態碼 (如 201 或 204) 的響應，一般不會有 body。

Body 大體可分爲三類：

Single-resource bodies，由已知長度的單個文件組成。該類型 body 由兩個 header 定義：Content-Type 和 Content-Length。
Single-resource bodies，由未知長度的單個文件組成，經過將 Transfer-Encoding 設置爲 chunked 來使用 chunks 編碼。
Multiple-resource bodies，由多部分 body 組成，每部分包含不一樣的信息段。但這是比較少見的。

http cookie

HTTP Cookie（也叫Webcookie或者瀏覽器Cookie）是服務器發送到用戶瀏覽器並保存在瀏覽器上的一塊數據，它會在瀏覽器下一次發起請求時被攜帶併發送到服務器上。能夠它用來肯定兩次請求是否來自於同一個瀏覽器，從而可以確認和保持用戶的登陸狀態。

Cookie主要用在如下三個方面:

會話狀態管理（如用戶登陸狀態、購物車）
個性化設置（如用戶自定義設置）
瀏覽器行爲跟蹤（如跟蹤分析用戶行爲）

建立cookie:

當服務器收到HTTP請求時，能夠在響應頭裏面增長一個Set-Cookie頭部。瀏覽器收到響應以後會取出Cookie信息並保存，以後對該服務器每一次請求中都經過Cookie請求頭部將Cookie信息發送給服務器。另外，Cookie的過時時間、域、路徑、有效期、站點均可以根據須要來指定

set-cookie響應頭部和cookie請求頭部:

服務器使用set-cookie響應頭部向用戶代理髮送cookie信息,服務器告訴客戶端要保存cookie信息,響應的數據裏面應該包含set-cookie頭,瀏覽器收到以後將cookie保存

會話期cookie:

它在瀏覽器關閉以後會自動刪除,僅在會話期間有效

持久cookie:

它能夠指定一個特定的過時時間或者有效期

安全和httponly類型cookie:

只有在使用sll和https協議向服務器發送請求時,才能確保cookie被安全地發送到服務器

cookie的做用域：

domain和path定義了cookie的做用域,即須要發送cookie的url集合
domain規定了須要發送cookie的主機名,默認是當前的文檔地址上的主機名,若是指定了domain,則通常包含子域名
path代表須要發送cookie的url路徑,用%x2F作文件夾分隔符
同站cookie:容許服務器指定在跨站請求時cookie是否會被髮送,從而能夠阻止跨站請求僞造攻擊.

同站Cookie:

同站Cookie容許服務器指定在跨站請求時Cookie是否會被髮送，從而能夠阻止跨站請求僞造攻擊（CSRF）。

第三方cookie：

cookie的域和頁面的域是同樣的,則是第一方cookie,若是cookie的域和頁面的域不同,則爲第三方cookie

Session和Cookie的區別

Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據能夠保存在集羣、數據庫、文件中；
Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。

更多詳細參考