聲明:如下內容多參考整理於網絡文章javascript
以前去面試時,面試官幾乎沒有問其餘問題,整場面試下來,死磕協議的知識不放,因爲本身在這方面準備並非很充分,回答的並非很好,因而回來結合面試的狀況,查了不少的資料,認真地瞭解一下HTTP協議,若是寫的很差的地方,留言指出。css
HTTP ( HyperText Transfer Protocal
),全稱爲超文本傳輸協議。HTTP是一個客戶端終端(用戶)和服務器端(網站)請求和應答的標準。一般,由HTTP客戶端發起一個請求,建立一個到服務器指定端口(默認是80端口)的TCP鏈接。HTTP服務器則在那個端口監聽客戶端的請求。一旦收到請求,服務器會向客戶端返回一個狀態,好比"HTTP/1.1 200 OK",以及返回的內容,如請求的文件、錯誤消息、或者其它信息。html
TCP/IP(Transmission Control Protocol/Internet Protocol,傳輸控制協議/網際協議)是指可以在多個不一樣網絡間實現信息傳輸的協議簇。TCP/IP協議不只僅指的是TCP 和IP兩個協議,而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇, 只是由於在TCP/IP協議中TCP協議和IP協議最具表明性,因此被稱爲TCP/IP協議。java
應用層:負責處理特定的應用程序細節。簡單網絡管理SNMP協議,簡單網絡傳輸SMTP,域名解析DNS,文件下載FTP協議,遠程協助,Telnet協議,超文本傳輸HTTP等等。web
傳輸層:主要爲兩臺主機上的應用提供端到端的通訊。TCP協議和UDP協議面試
網絡層:處理分組在網絡中的活動,好比分組的選路。IP協議等算法
網絡接口層:包括操做系統中的設備驅動程序、計算機中對應的網絡接口卡數據庫
概述:json
HTTP協議傳輸的數據都是未加密的,也就是明文的,能夠用抓包工具直接抓下來而且可見,而HTTPS則是利用了網景公司設計的SSL(Secure Sockets Layer)協議對HTTP協議傳輸的數據進行加密,SSL 依靠證書來驗證服務器的身份,併爲瀏覽器和服務器之間的通訊加密。抓包工具抓下來的是密文,大幅增長了中間人攻擊的成本。簡單來講,HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,要比HTTP協議安全瀏覽器
主要區別:
http://
起始且默認使用端口80,而HTTPS的URL由https://
起始且默認使用端口443HTTP 2.0 的出現,相比於 HTTP 1.x ,大幅度的提高了 web 性能
1.多路複用
多路複用容許經過單一的HTTP2.0鏈接同時發起多重的請求-響應消息,而在HTTP1.0中,瀏覽器客戶端在同一時間,針對同一域名的請求有必定數量的限制,超出限制數目的請求會被阻塞HTTP2.0 能夠很容易的去實現多流並行而不用依賴創建多個 TCP 鏈接,HTTP2.0 把 HTTP 協議通訊的基本單位縮小爲一個一個的幀,這些幀對應着邏輯流中的消息。並行地在同一個 TCP 鏈接上雙向交換消息。
2.二進制分幀
HTTP2.0在應用層(HTTP2.0)和傳輸層(TCP/UDP)之間增長一個二進制分幀層,在二進制分幀層中,HTTP2.0會將全部的信息分割爲更小的消息和幀,並採用二進制格式編碼
HTTP2.0 通訊都在一個鏈接上完成,這個鏈接能夠承載任意數量的雙向數據流。
在過去, HTTP 性能優化的關鍵並不在於高帶寬,而是低延遲。TCP 鏈接會隨着時間進行自我「調諧」,起初會限制鏈接的最大速度,若是數據成功傳輸,會隨着時間的推移提升傳輸的速度。這種調諧則被稱爲TCP 慢啓動。因爲這種緣由,讓本來就具備突發性和短時性的 HTTP 鏈接變的十分低效。HTTP/2 經過讓全部數據流共用同一個鏈接,能夠更有效地使用 TCP 鏈接,讓高帶寬也能真正的服務於HTTP 的性能提高。
3.首部壓縮
HTTP/1.1並不支持 HTTP 首部壓縮,爲此 SPDY 和 HTTP/2 應運而生, SPDY 使用的是通用DEFLATE 算法,而 HTTP/2 則使用了專門爲首部壓縮而設計的 HPACK 算法。
4.服務端推送
服務端推送是一種在客戶端請求以前發送數據的機制。在 HTTP/2 中,服務器能夠對客戶端的一個請求發送多個響應。服務端推送讓 HTTP1.x 時代使用內嵌資源的優化手段變得沒有意義;若是一個請求是由你的主頁發起的,服務器極可能會響應主頁內容、logo 以及樣式表,由於它知道客戶端會用到這些東西。這至關於在一個 HTML 文檔內集合了全部的資源,不過與之相比,服務器推送還有一個很大的優點:能夠緩存!也讓在遵循同源的狀況下,不一樣頁面之間能夠共享緩存資源成爲可能。
協議+主機名+路徑+參數
HTTP請求報文分爲三個部分:請求行,請求頭,請求體
請求行包括三個方面:請求方法、請求地址、協議版本
HTTP/1.1 協議中共定義了八種方法(也叫「動做」)來以不一樣的方式操做指定的資源
方法名 | 功能 |
---|---|
GET | 向指定的資源發出「顯示」請求,使用 GET 方法應該只用在讀取數據上,而不該該用於產生「反作用」的操做中 |
POST | 指定資源提交數據,請求服務器進行處理(例如提交表單或者上傳文件)。數據被包含在請求文本中。這個請求可能會建立新的資源或者修改現有資源,或二者皆有。 |
PUT | 向指定資源位置上傳其最新內容 |
DELETE | 請求服務器刪除 Request-URI 所標識的資源 |
OPTIONS | 使服務器傳回該資源所支持的全部HTTP請求方法。用* 來代替資源名稱,向 Web 服務器發送 OPTIONS 請求,能夠測試服務器功能是否正常運做 |
HEAD | 與 GET 方法同樣,都是向服務器發出指定資源的請求,只不過服務器將不傳回資源的本文部分,它的好處在於,使用這個方法能夠在沒必要傳輸所有內容的狀況下,就能夠獲取其中關於該資源的信息 (原信息或稱元數據) |
TRACE | 顯示服務器收到的請求,主要用於測試或診斷 |
CONNECT | HTTP/1.1 中預留給可以將鏈接改成通道方式的代理服務器。一般用於 SSL 加密服務器的連接(經由非加密的 HTTP 代理服務器) |
下面介紹經常使用方法GET與POST的區別:
注意:
get請求參數在url地址上,直接暴露,post請求的參數放Request body部分,按F12也直接暴露了,因此沒啥安全性可言
GET產生一個TCP數據包;POST產生兩個TCP數據包
緣由是:
對於GET方式的請求,瀏覽器會把http header和data一併發送出去,服務器響應200(返回數據)
而對於POST,瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200 ok(返回數據)
什麼狀況下使用POST請求:
沒法使用緩存文件(更新服務器上的文件或數據庫),GET能請求緩存,POST不能
向服務器發送大量數據(POST 沒有數據量限制)
發送包含未知字符的用戶輸入時,POST 比 GET 更穩定也更可靠
請求頭可用於傳遞一些附加信息,格式爲:鍵: 值
,注意,冒號後面有一個空格:
常見的請求 Header
名稱 | 做用 |
---|---|
Authorization | 用於設置身份認證信息 |
User-Agent | 用戶標識,如:OS 和瀏覽器的類型和版本 |
If-Modified-Since | 值爲上一次服務器返回的Last-Modified 值,用於肯定某個資源是否被更改過,沒有更改過就從緩存中讀取 |
If-None-Match | 值爲上一次服務器返回的 ETag 值,通常會和If-Modified-Since |
Cookie | 已有的Cookie |
Referer | 標識請求引用自哪一個地址,好比你從頁面 A 跳轉到頁面 B 時,值爲頁面 A 的地址 |
Host | 請求的主機和端口號 |
請求和響應常見通用的 Header
名稱 | 做用 |
---|---|
Content-Type | 請求體/響應體的類型,如:text/plain、application/json |
Accept | 說明接收的類型,能夠多個值,用, (英文逗號)分開 |
Content-length | 請求體/響應體的長度,單位字節 |
Content-Encoding | 請求體/響應體的編碼格式,如 gzip、deflate |
Accept-Encoding | 告知對方我方接受的 Content-Encoding |
ETag | 給當前資源的標識,和Last-Modified 、If-None-Match 、If-Modified-Since 配合,用於緩存控制 |
Cache-Control | 取值通常爲no-cache 、max-age=xx ,xx爲整數,表示資源緩存有效期(秒) |
請求體(又叫請求正文)是 post 請求方式中的請求參數,以 key = value 形式進行存儲,多個請求參數之間用&鏈接,若是請求當中請求體,那麼在請求頭當中的 Content-Length 屬性記錄的就是該請求體的長度
HTTP響應報文分爲三個部分:響應狀態行,響應頭,響應體
狀態碼 | 對應的信息 |
---|---|
1XX | 提示信息—表示請求已接收,繼續處理 |
2XX | 用於表示請求已被成功接收、理解、接收 |
3XX | 用於表示資源(網頁等)被永久轉移到其它 URL,也就是所謂的重定向 |
4XX | 客戶端錯誤—請求有語法錯誤或者請求沒法實現 |
5XX | 服務器端錯誤—服務器未能實現合法的請求 |
常見狀態碼
2XX 成功
3XX 重定向
4XX 客戶端錯誤
5XX 服務器錯誤
響應頭一樣可用於傳遞一些附加信息
常見的響應 Header
名稱 | 做用 |
---|---|
Date | 服務器的日期 |
Last-Modified | 該資源最後被修改的時間 |
Transfer-Encoding | 取值通常爲 chunked,出如今 Content-Length 不能肯定的狀況下,表示服務器不知道響應板體的數據大小,通常同時出現Content-Encoding 響應頭 |
Set-Cookie | 設置 Cookie |
Location | 重定向到另外一個 URL,如輸入瀏覽器就輸入 baidu.com 回車,會自動跳轉到[www.baidu.com] 就是經過這個響應頭控制的 |
Server | 後臺服務器 |
響應體也就是網頁的正文內容,通常在響應頭中會用 Content-Length 來明確響應體的長度,便於瀏覽器接收,
對於大數據量的正文信息,也會使用 chunked 的編碼方式。
一、首先,在瀏覽器地址欄中輸入url,先解析url,檢測url地址是否合法
二、瀏覽器先查看瀏覽器緩存-系統緩存-路由器緩存,若是緩存中有,會直接在屏幕中顯示頁面內容。若沒有,則
跳到第三步操做。
瀏覽器緩存:瀏覽器會記錄DNS一段時間,所以,只是第一個地方解析DNS請求;
操做系統緩存:若是在瀏覽器緩存中不包含這個記錄,則會使系統調用操做系統,獲取操做系統的記錄(保存最近
的DNS查詢緩存);
路由器緩存:若是上述兩個步驟均不能成功獲取DNS記錄,繼續搜索路由器緩存;
ISP緩存:若上述均失敗,繼續向ISP搜索。
三、在發送http請求前,須要域名解析(DNS解析),解析獲取相應的IP地址。
四、瀏覽器向服務器發起tcp鏈接,與瀏覽器創建tcp三次握手。
五、握手成功後,瀏覽器向服務器發送http請求,請求數據包。
六、服務器處理收到的請求,將數據返回至瀏覽器
七、瀏覽器收到HTTP響應
八、瀏覽器解碼響應,若是響應能夠緩存,則存入緩存。
九、 瀏覽器發送請求獲取嵌入在HTML中的資源(html,css,javascript,圖片,音樂······),對於未知類型,會彈出對話框。
十、 瀏覽器發送異步請求。
十一、頁面所有渲染結束。