HTTP---暫空

時間 2019-11-30

標籤 http 欄目 HTTP/TCP 简体版

原文原文鏈接

其實學習HTTP主要是爲了讓前端的研發人員在客戶端發起請求和服務器作出響應的過程當中，一旦出現問題能夠更快捷的定位問題所在，提升開發效率。html

TCP/IP

計算機網絡誕生後可以使一臺臺獨立的計算機互相鏈接，使得位於不一樣位置的計算機之間能夠進行通訊，實現信息傳遞和資源共享。經常使用的網絡協議有TCP，UDP，IP和HTTP前端

TCP/IP是互聯網服務的協議族，是網絡通訊協議的統稱，由IP,TCP,HTTP和FTP等協議組成/TCP/IP將通訊過程抽象爲4層，被視爲簡化的OST參考模型。算法

分送的數據會在分層模型內傳遞，而且每到一層，就會附加該層的包首部，包首部包含了該層協議的相關信息，例如MAC地址，IP地址和端口號。

什麼是MAC地址？ MAC地址，也成爲物理地址，用來定義網絡設備的位置，總共有8位，用十六進制表示，由兩大塊組成，是IEEE分配給廠商的識別碼和廠商內部定義的惟一識別碼
00-36-76-47-D6-7A
MAC地址會被燒入進網卡中，每塊網卡的MAC地址在全世界都是惟一的，（神說要有光，便有了光。網卡說我要是惟一的，網卡就變成了惟一的）。MAC地址應用在OSI參考模型的數據鏈路層，經過MAC地址可以轉發數據幀。
瀏覽器

什麼是IP地址緩存

IP地址是指互聯網協議地址，是爲網絡中的每臺主機分配的一個數字標籤。IP地址應用在OSI參考模型的網絡層，保證通訊的正常。經常使用的IP地址分爲兩大類：IPV4與IPV6。
在IP地址後面常會帶着一組以255開頭的數字，稱爲子網掩碼（255.255.255.0）.這麼說吧IP地址就是你家門牌號，子網掩碼是你的省，市，區。
IP地址不夠用了，因此規劃制定了IPV6，IPV6有128位，分爲8組。
CFDE:086E:0291:08D3:760A:04DD:CCAB:2145安全

HTTP

HTTP（HyperText Transfer Protocol）超文本傳輸協議，用來獲取網絡資源（圖像啊，文本之類）的應用層協議，是互聯網數據通訊的基礎。由請求和響應構成。
客戶端發起HTTP請求，在請求報文中會指定資源的URL，而後用傳輸層的TCP協議創建鏈接，最後服務器響應請求，作出應答，回傳數據報文。
目前主流版本是HTTP/1.1，新一代HTTP/2.0是升級版，各方面都超越了前者。但要作到軟硬件兼容還須要時間，反正早學晚學遲早得學。
bash

URI和URL

juejin.im/post/5dbc16…服務器

HTTP協議

HTTP協議有三個特色：持久鏈接，管道化以及無狀態
網絡

1：持久連接

在早期的HTTP版本中，一次HTTP通訊完成後會斷開連接，下一次再從新鏈接。HTTP/1.1提出了持久鏈接，只要通訊兩端的任意一端沒有明確提出斷開，保持鏈接狀態。以便下一次通訊複用該鏈接，避免了重複創建和斷開鏈接所形成的開銷，加速了頁面呈現架構

2：管道化

過去，請求必須按照先進先出的隊列順序，也就是說發送請求後要等待並接收到響應，服務器再按順序一個接一個的響應。啓用管道化後，就會將隊列順序遷移到服務器，這樣就能同時發送多個請求，服務器再按順序一個接一個的響應。

3：狀態管理

HTTP是無狀態協議，請求和響應一一對應，不會出現兩個請求複用一個響應的狀況，也就說，每一個請求都是獨立的，即使在同一條鏈接中，請求之間也沒有聯繫。

在部分場景中，須要請求有狀態，好比說你登陸一個頁面後得保存登陸狀態，爲了能管理狀態，引入了Cookie技術，Cookie能讓請求和響應的報文都附加Cookie信息，客戶端將Cookie值發送出去，服務器接收並處理這個值，最終就能獲得客戶端的狀態信息。

HTTP報文

1：報文語法：

報文分爲兩類：請求報文和響應報文
請求報文由5部分組成：請求方法，請求URL，HTTP協議版本，可選的請求首部和內容。

<Method><Request URL><Version>
<Header>
<Body>
複製代碼

響應報文也由五部分組成：HTTP協議版本，狀態碼，緣由短語，可選的響應首部和內容。響應報文的格式：

<Version><Status Code><Reason Phrase>
<Header>
<Body>
複製代碼

2:請求方法：

HTTP協議經過請求方法說明請求目的，指望服務器執行某個操做。在可用的請求方法中，GET和POST是最多見的（真的很常見哦！），而PUT和DELETE須要額外的安全機制，門檻過高，用不起。

方法	功能
GET	獲取數據
POST	提交數據
PUT	上傳文件
DELETE	刪除文件
HEAD	獲取除了內容之外的資源信息

3：狀態碼

狀態碼是爲了讓客戶端知道請求結果，服務器是成功處理了請求仍是出現了失誤又或者是沒有處理。狀態碼會和緣由短語成對出現。狀態碼由3位數字組成，第一位數字表明類別。

狀態碼	類別	緣由短語
1XX	信息	請求已被接受，正在處理中
2XX	成功	請求已處理成功
3XX	重定向	客戶端須要附加操做才能完成請求
4XX	客戶端錯誤	客戶端發起的請求服務器沒法處理
5XX	服務器錯誤	服務器在處理請求時發生錯誤或異常

200 OK
304 Not Modified
404 Not Found
500 Internal Server Error

HTTP首部

HTTP首部提供的信息能讓客戶端和服務器執行指定的操做，例如客戶端發出的請求中帶有可接受的內容類型，服務器就知道該返回什麼類型的內容；好比說服務器的響應中帶有內容的壓縮格式，客戶端就知道該如何解壓復原內容。首部有5種類型：通用首部，請求首部，響應首部，實體首部和擴展首部。

1：通用首部：

通用首部既能夠存在於請求中，也能夠存在於響應種。

首部	描述
Connection	管理持久鏈接
Date	報文的建立日期，HTTP協議使用了特殊的日期格式
Transfer-Encoding	傳輸報文主體時的編碼方式，例如分塊傳輸編碼

來個栗子

Connevtion: keep-alive
Date: Fri.24 Sep 2012 02:00:02 GMT
Transfer-Encoding :chunked
複製代碼

2：請求首部:

請求首部只存在於請求報文種，提供客戶端的信息以及服務器的要求，例如幾個以Accept開頭的首部，能讓服務端知道客戶端想獲得什麼

首部	描述
Accept	可接受的MIME類型
Accept-Charset	可接受的字符集
Accept-Encoding	可接受的編碼格式，服務器按指定的編碼格式壓縮數據
Accept-Language	可接受的語言種類
Host	服務器域名和端口
Referer	上一個頁面地址
User-Agent	用戶代理信息，例如操做系統，瀏覽器名稱和版本

說實話，抓個包就啥都懂了

再來個栗子：

Accept-Charset: utf-8
Accept-Encoding:gzip,deflate
Accept-Language: zh-CN,zh:q=0.8
Host: WWW.jian-yi.top
Referer: http://www.baidu.com
User-Agent: Mozilla/5.0(iPhone;CPU iPhone OS 9_1 like Mac OS X)
Apple WebKit/601.1.46(KHTML,Like Gecko)Version/9.0
Mobile/13B143 Safari/601.1
複製代碼

3：響應首部：

響應首部只存在於響應報文中，提供服務器的信息以及對客戶端的要求

首部	描述
Accept-Range	服務器接受的範圍類型
Server	服務器軟件的名稱和版本
Age	響應存在時間，單位爲妙，這個首部可能由代理髮出

Accept-Range: bytes
Server: Apache.2.4.10(Win64)PHP/5/5/17
Age:600
複製代碼

4:實體首部：

請求和響應均可能包含實體首部，實體首部提供了大量的實體信息，例如以Content開頭的首部，傳達了內容的尺寸，MIME類型和語言等信息。

首部	描述
Content-Encoding	內容編碼格式，告知客戶端用這個編碼格式解壓
Content-Language	內容語言
Content-Length	內容尺寸，單位是字節
Content-Type	內容的MIME類型

最後一個栗子：

Content-Encoding: gzip
Content-Language: zh-CN
Content-Length:   9191
Content-Type:text/html
複製代碼

緩存

Web緩存能夠自動將資源副本保存到本地，減小了客戶端與服務器之間的通訊次數，加速頁面加載，下降網絡延遲。緩存的處理過程能夠簡單地分爲幾步：
第一步：在緩存中搜索指定資源的副本，若是命中執行第二步

第二步：對資源副本進行新鮮度檢測（檢測文檔是否過時）不新鮮執行第三步

第三步：與服務器進行再驗證，驗證經過更新資源副本的新鮮度，再返回這個資源副本(此時的響應狀態碼爲「304 Not Modified」)

1：新鮮度檢測
通用首部Cache-Control和實體首部expires會爲每一個資源附加一個過時日期，在保質期內的資源都會被認爲是新鮮的，也不會和服務器進行通訊。
Expires首部會指定一個具體的過時日期，可是由於不少服務器的時鐘並不一樣步，因此會有偏差，並不推薦使用。

Expires:  Fir,24 Sep 2023 03:02:03 GMT
複製代碼

Cache-Control首部指定資源處於新鮮狀態的秒數，秒數從服務器將資源傳來之時算起，用秒數比用具體日期要靈活不少。當緩存的資源副本被同時制定了過時秒數和過時日期的時候，會優先處理過時秒數

Cache-Control:  max-age=315360
複製代碼

在Cache-Control首部中，有兩個混淆的值：no-cache和no-store.no-cache字面上比較像禁止資源被緩存。其實不是。no-store纔有這個功能。no-cache能夠將資源緩存，只是要先與服務器進行新鮮度驗證，驗證經過以後纔會將其提供給客戶端。

在通用首部中，還有個歷史遺留首部：Pragma.Pragma首部用於實現特定的指令，它也有一個值爲no-cache，功能和Cache-Control中的相同。

Cache-Control: no-cache
Pragma:        no-cache
複製代碼

2：日期比對法再驗證：
服務器在響應請求的時候，會在響應報文中附加實體首部Last-Modified,指明資源的最後修改日期，客戶端在緩存資源的同時，也會一併把這個日期緩存，當對緩存中的資源副本進行再驗證時，在請求報文中會附加If-Modified-Since首部，攜帶最後修改日期，與服務器上的修改日期進行比對

3：實體標記法進行再驗證：
日期比對法很是依賴日期，若是服務器上的日期不許確，再驗證就會出現誤差，這個時候就會比較適合用實體標記法。服務器會爲每個資源生成惟一的字符串形式的標記(例如52fdbf98-2663)，該標記會保存在實體首部ETag中。在響應報文中附加ETag,把標記返回給客戶端，客戶端接收並將其緩存。當對緩存中的資源副本進行再驗證時，在請求報文中會附加 If-None-Match首部。只有當攜帶的標記與服務器上的資源標記一致時，才能說明緩存沒有國企，這樣就能返回緩存中的資源。

1：在瀏覽器中，一個頁面從輸入URL到加載完成，都有哪些步驟？
爲了便於理解，將這個過程簡單的分爲了5步，以下所示：
(1):域名解析，根據域名找到服務器的IP地址
(2):創建TCP連接，瀏覽器與服務器通過3次握手後創建鏈接。
(3):瀏覽器發起HTTP請求，獲取想要的資源
(4):服務器響應HTTP請求，返回指定的資源
(5):瀏覽器渲染頁面，解析接收到的HTML，CSS和JavaScript文件

2：GET和POST的區別有哪些？
主要區別有四個方面：
(1):語義不一樣，GET是獲取數據，POST是提交數據

(2):HTTP協議規定GET比POST安全，由於GET只作讀取，不會改變服務器中的數據，但這不是規範，並不能保證請求方法的實現也是安全的
(3):GET請求會把附加參數帶在URL上，而POST請求會把提交數據放在報文內。在瀏覽器中，URL長度會被限制(的確如此-親身體會)，因此GET請求能傳遞的數據有限，但HTTP協議其實並無對其作限制，都是瀏覽器在控制
(4):HTTP協議規定GET是冪等的，而POST不是。所謂冪等是指屢次請求返回相同的結果，實際應用中並不會這麼嚴格，當GET獲取動態數據時，每次的結果可能會有所不一樣。

RESTful架構風格

RESTful是一種遵照REST設計的架構風格。REST既不是標準，也不是協議，而是一組架構約束條件和設計指導原則，一種基於HTTP，URI,XML等現有協議與標準的開發方式。

REST

1：資源：
REST是面向資源的，資源是網絡上的一個實體，能夠是一個文件，一張圖像，一首歌曲，甚至是一種服務。資源能夠設計的很抽象，但只要是具體信息，就能夠是資源。資源的本質是一串二進制數據。而且每一個資源必須有URL，經過URL找到資源。
2：表述：
資源在某個特定時刻的狀態說明被稱爲表述，表述由數據和描述數據的元數據組成。資源的表述有多種格式，這些格式也被稱爲MIME類型。好比文本的txt格式，圖像的png格式，視頻的mkv格式等。一個資源能夠有多種表述，例如服務器響應一個請求，返回的資源能夠是JSON格式的數據，也能夠是XML格式的數據。
3：表述性狀態轉移：
表述性狀態轉移的目的是操做資源，經過轉移和控制資源的表述就能實現此目的。例如客戶端能夠向服務器發送GET請求，服務器將資源的表述移到客戶端，客戶端也能夠向服務器發送POST請求，傳遞表述改變服務器中的資源狀態。

約束條件

REST給出了6種約束條件，通訊兩端在遵循這些約束後，就能提升工做效率，改善系統的可伸縮性，可靠性和交互的可見性，還能促進服務解耦。
1：客戶端-服務器：
客戶端關注用戶接口，服務器關注數據存儲。客戶端向服務器發起接口請求(獲取數據或提交數據)，服務器返回處理好的結果給客戶端，客戶端再根據這些數據渲染界面，同一個接口能夠應用於多個終端，而且只要接口定義不變，客戶端和服務器能夠獨立開發，互不影響。
2：無狀態：
兩端通訊必須是無狀態的，服務器不會保存上一次請求的會話狀態，會話狀態要所有保存在客戶端。從客戶端到服務器的每一個請求都要附帶一些用於理解該請求的信息，例如在後臺管理系統中，大部分都是須要身份認證的請求，因此都會附帶用戶登陸狀態。
3：緩存
響應的資源能夠被標記爲可緩存或禁止緩存，若是能夠緩存，那麼客戶端能夠減小與服務器通訊的次數，下降延遲，提升效率。
4：統一接口
統一接口是REST區別於其餘架構風格的核心特徵，接口定義包括4個部分：

(1)資源的識別，也就是用一個URL指向資源，要獲取這個資源，只要訪問它的URL便可，URL就是資源的地址或標識符。REST對URL的命名也有要求，在URL中不能有動詞，只能由名詞組成

(2)經過表述對資源執行操做，在表述中包含了操做該資源的指令，例如用HTTP的請求首部Accept指定須要的表述格式，用HTTP方法(如GET，POST等)完成對數據的增刪改查工做，用HTTP響應狀態碼錶示請求結果。

(3)自描述的消息，包含如何處理該消息的消息，例如消息所使用的表述格式，可否被緩存等。

(4)做爲應用狀態引擎的超媒體，超媒體並非一種技術，而是一種策略，創建一種客戶端與服務器之間的對話方式。超媒體能夠將資源互相鏈接，並能描述他們的能力，告訴客戶端如何構建HTTP請求。

5：分層系統：將架構分解爲若干層，下降層之間的耦合性。每一個層只能和與他相鄰的層進行通訊。

6：按需代碼：這是一條可選的約束，支持客戶端下載並執行一些代碼(例如Java Applet,JavaScript,或Flash)進行功能擴展。

什麼的RESTful API?如何設計RESTful API

RESTful API是指符合REST設計風格的WebAPI。爲了使得接口安全，易用，可維護以及可擴展，通常設計RESTful API須要考慮一下幾個方面：
(1)通訊用HTTPS安全協議
(2)在URL中加入版本號，例如 "V1/animals"
(3)URL中的路徑(endpoint)不能有動詞，只能用名詞
(4)用HTTP方法對資源進行增刪改查的操做
(5)用HTTP狀態碼傳達執行結果和失敗緣由。
(6)爲集和提供過濾，排序，分頁等功能
(7)用查詢字符串或HTTP首部Accept進行內容協商，指定返回結果的數據格式
。 (8)及時更新文檔，每一個接口都有對應的說明

TCP

TCP是一種面向鏈接，可靠的字節流通訊協議，位於OSI參考模型的傳輸層，具有順序控制，重發控制，流量控制和擁塞控制等衆多功能，保證數據可以安全抵達目的地。

關於TCP進行數據傳輸的通訊過程:
首先經過三次握手創建鏈接；而後把發送窗口調整到合適大小，既能避免網絡擁塞，又能提升傳輸效率；
在傳輸過程當中，發出去的每一個包都會獲得對面的確認，當運送的數據包丟失時，能夠執行超時重發，當數據包亂序時(有的數據包先發後到)，經過數據包中的序號能夠按順序排列，同時也能丟棄重複的包；
再根據端口號將數據準去傳送至通訊中的應用程序，端口號至關於程序地址；
待到全部數據安全到達後，執行四次揮手斷開鏈接，本次傳輸完成

鏈接管理

雖然我以前已經寫過了，可是呢我還想寫一遍！書讀百遍其意自現！！
1：三次握手
通訊兩端會先經歷三次握手，才能創建鏈接。
(1):客戶端發送一個攜帶SYN(這是個啥？)標誌位的包，請求創建鏈接
(2):服務器響應一個攜帶SYN和ACK標誌位的包，贊成創建鏈接。
(3):客戶端再發送一個攜帶ACK標誌位的包，表示鏈接成功，開始進行數據傳輸

主要是二次握手它很差使知道吧，客戶端發了一個請求創建鏈接的包，結果網太卡了，服務器死活接收不到，客戶端就一直髮一直髮，行，服務器收到了第二個，結果第一個過來了，但其實第一個他是無效的啊，第一個過時了的，服務器哪知道啊，結果就創建了一條無效的連接。

阿大對阿二說：我要和你成親，你聽到了嗎？

阿二說：嗯

阿大說：禮成

2：四次揮手
斷開鏈接時，要揮手四次才能斷開連接。由於鏈接是雙向的，客戶端和服務器都要發送FIN標誌位的包，纔算完全斷開鏈接。

(1):客戶端發送一個攜帶FIN標誌位的包，請求斷開鏈接
(2):服務器響應一個攜帶ACK標誌位的包，贊成客戶端斷開鏈接
(3):服務器再發送一個攜帶FIN標誌位的包，請求斷開鏈接
(4):客戶端最後發送一個攜帶ACK標誌位的包，贊成服務器斷開鏈接

阿大和阿二說：我要跟你分手

阿二說：「行」

阿大回過勁來想：憑啥是你甩了老子，是老子甩了你好嘛

阿大和阿二說：「勞資要跟你分手，你滾吧」

確認應答

在TCP 傳輸的過程當中，發出去的每一個包都會獲得對方的確認，藉助數據包中的幾個字段就能又快又準的通知對方發送的包已到達，再結合延遲確認,Nagle算法等技術就能實現一套高效的應答機制
1：字段：TCP的每一個數據包中包含3個字段：Seq,Len和Ack.Seq表示每一個包的序號，用於排列亂序的包；Len表示數據的長度，不包括TCP頭信息；Ack表示確認號，用於確認已經收到的字節。
Seq等於上一個包中的Seq和Len二者之和。假設上一個包中的Seq爲30，Len爲40，那麼當前的Seq爲70，下面是Seq的計算公式：
Seq=Seq+Len
Ack等於對面發送過來的包中的Seq和Len二者之和，下面是Ack的計算公式：Ack=Seq+Len 服務器的對面是客戶端，假設客戶端發送的包中Seq爲10，Len爲20，那麼服務器的Ack就爲30
通訊兩端都會維護各自的Seq,
2:延遲確認
延遲確認就是在一段時間內若是沒有數據發送，那麼就將幾個確認信息合併成一個包，在一塊兒確認。TCP採用延遲確認的目的是下降網絡負擔，提高傳輸效率
3：Nagle算法
Nagle算法是指在發生的數據沒有獲得確認以前，又有幾塊小數據要發送，就把它們合併成一個包，在一塊兒發送。

延遲確認和Nagle算法都能下降網絡負擔，提高傳輸效率，但若是將二者結合使用，卻會下降性能。
當啓用Nagle算法的客戶端發出一個小的數據包，啓用延遲確認的服務器會接受並等待下一個數據包到達。而客戶端在未接受到第一個數據包的確認以前，不會再次發送，兩段都在等待對方，這反而增長了延遲，下降了傳輸效率

窗口控制

數據包所能攜帶的最大數據量稱爲MSS。當TCP傳送大塊數據的時候，會先將其分割爲多個MMS在進行傳送。MMS是發送數據包的單位，重發時也是以MSS爲單位，在進行鏈接時，兩端會告訴對方本身所能接受的MSS的大小，而後再選擇一個較小的值投入使用。

1：發送窗口：
發送窗口控制了一次能發的字節量，也就是一次能發多少個MSS。發送窗口會受接收方的接收窗口和網絡的影響，因此在包中看不到關於發送窗口的信息。用WireShark抓包時，每一個包的傳輸層都含有"Window size"信息，這個字段並不表示發送窗口，而是接收窗口。
發送窗口一次不能發送太多數據，否則會使網絡擁堵，甚至癱瘓。理想狀況下，發送窗口能發送的數據量正好是網絡所能承受的最大數據量，這個閾值可稱爲擁塞點。(我知道我在那裏看見過這個了！！！！！計算機網絡的書上不是有這個題嘛！！！！！)。爲了找到擁塞點，定義了一個虛擬的擁塞窗口，經過調節擁塞窗口的大小來限制發送窗口。
2：擁塞窗口：在通訊開始時，經過慢啓動對擁塞窗口進行控制，先把擁塞窗口的初始值定義爲1個MMS，而後發送數據，每收到一次確認，擁塞窗口就加1，例如發出兩個MSS，，獲得2次確認，擁塞窗口會以4，8，16等指數增加。當擁塞窗口的大小超過慢啓動閾值時，就得改用擁塞避免算法。每一個往返時間只增長1個MSS，例如發出16個MSS，獲得16次確認，但擁塞窗口只加1，最終大小爲17，這種方式一直持續到出現網絡擁堵.
(哎呀，這我的講的啥啊，亂七八糟的，聽不懂！！！！！！還不如課本上講的呢，辣雞！！！)

待你爹把課本上的更新上來

重傳控制

TCP是一種可靠的通訊協議，所以若是發送方經過一些技術手段(如超時重傳，快速重傳等)確認某些數據包已經丟失了，那麼就會再次發送這些丟失的包。

1：超時重傳：TCP會設定一個超時重傳計數器(RTO),定義數據包從發出到失效的時間間隔，當發送方發出數據包後，在這段時間內沒有收到確認，就會重傳這個包。重傳以後的擁塞窗口須要從新調整一下，而且超時重傳會嚴重下降傳輸性能，由於在發送方等待階段，不能傳數據.
2：快速重傳：快速重傳不會一味的等待，當發送方連續收到3個或3個以上對相同數據包的重複確認時，就會認爲這個包丟失了，須要當即重發。
(我都問了三遍你在不在了，你都不理我，那你確定不在呀)

TCP和UDP有哪些區別？
UDP是一種簡單的，不可靠的通訊協議，只負責將數據發出，但不保證他們可否到達目的地。之因此不可靠是由於如下幾個緣由：
(1):UDP沒有順序控制，因此當數據包亂序到達時，沒有糾正功能
(2):UDP沒有重傳控制，因此當數據包丟失時，也不會重發
(3):UDP在通訊開始時，不須要創建鏈接，結束時也不用斷開鏈接
(4):UDP沒法進行流量控制，擁塞控制等避免網絡擁堵的機制
UDP的包頭長度不到TCP包頭的一半，而且沒有重發，鏈接等機制，故而在傳輸速度上比起TCP有更大的又是，比較適合即時通訊，信息量較小的通訊和廣播通訊。TCP至關於打電話，UDP至關於寫信或者發郵件，打電話須要先撥號創建鏈接，再掛電話斷開鏈接，而寫信只要把信丟入郵箱，就能送到指定地址。所以平常生活中的語音聊天和在線視頻使用UDP做爲傳輸協議的比較多，由於即便丟幾個包也不會有太大影響
。

HTTPS

HTTPS是一種構建在SSL或TLS上的HTTP協議，簡單的說，HTTP就是HTTP的安全版本。SSL(Secrue Sockets Layer)以及其繼任者TLS(Transport Layer Security)是一種安全協議，爲網絡通訊提供來源認證，數據加密和報文完整性檢測，保證通訊的保密性和可靠性。HTTPS協議的URL都以「https://」開頭，在訪問某個Web頁面時，客戶端會打開一條到服務器443端口的鏈接。

之因此說HTTP不安全，是因爲以3個緣由致使的。
(1):數據以明文傳遞，有被竊聽的風險
(2):接收到的報文沒法證實是發送時的報文，不能保障完整性，所以報文有被篡改的風險
(3):不驗證通訊兩端的身份，請求或響應有被僞造的風險。

加密

加密和解密都由兩部分組成：算法和密鑰。加密算法能夠分爲兩類：對稱加密和非對稱加密。
1:對稱加密
對稱加密在加密和解密的過程當中只使用一個密鑰，這個密鑰叫作對稱密鑰，也叫共享密鑰。對稱加密的優勢是計算速度快，其缺點也很明顯，就是通訊兩端須要分享密鑰。客戶端和服務器在進行對話前，要先將對稱密鑰發送給對方，在傳輸過程當中密鑰有被竊取的風險，一旦被竊取，那麼密文就能被輕鬆翻譯成明文，

2：非對稱加密：非對稱加密在加密的過程當中使用公開密鑰，在解密的過程當中使用私有密鑰。反過來也能夠。缺點是計算速度慢可是卻能避免信息泄露。

HTTPS採用混合加密機制，將兩種加密算法組合使用。在交換公鑰階段使用非堆成加密，在傳輸報文階段使用對稱加密。

數字簽名

數字簽名是一段由發送者生成的特殊加密校驗碼，用於肯定報文的完整性。數字簽名的生成設計兩種技術：非對稱加密和數字摘要。數字摘要能夠將變長的報文提取爲定長的摘要，報文內容不一樣，提取出的摘要也講不一樣，經常使用的摘要算法有MD5和SHA。簽名和校驗的過程總共分爲5步。
(1):發送方用摘要算法對報文進行提取，生成一段摘要
(2):而後用私鑰對摘要進行加密，加密後的摘要做爲數字簽名附加在報文上，一塊兒發送給接收方
(3):接收方收到報文後，用一樣的摘要算法提取出摘要
(4):再用接收到的公鑰對報文中的數字簽名進行解密
(5):若是兩個摘要相同，那麼就能證實報文沒有被篡改

數字證書

數字證書至關於網絡上的身份證，用於身份識別。證書的內容包括：有效期，頒發機構，頒發機構的簽名，證書全部者的名稱，證書全部者的公開密鑰，版本號和惟一序列號等信息。客戶端(瀏覽器)會預先植入一個受信任的頒發機構列表，若是收到的證書來自陌生的機構，那麼會彈出一個安全警報對話框。

說明這個請求來自意料以外的服務器；若是不經過，就說明證書被冒用，來源可疑，客戶端會馬上發出警告。

安全通訊機制

客戶端和服務器將經過好幾個步驟創建起安全鏈接，而後開始通訊。
(1):客戶端發送Client Hello報文開始SSL通訊，報文中還包括協議版本號，加密算法等信息
(2):服務器發送Server Hello報文做爲應答，在報文中也會包括協議版本號，加密算法等信息
(3):服務器發送數字證書，數字證書中包括服務器的公開密鑰
(4):客戶端解開並驗證數字證書，驗證經過後，生成一個隨機密碼串，再用收到的服務器公鑰加密，發送給服務器
(5):客戶端再發送Change Clipher Spec報文，提示服務器在此報文以後，採用剛剛生成的隨機密碼串進行數據加密
(6):服務器也發送Change Clipher Spec報文
(7):SSL鏈接創建完成，接下來就能夠傳輸數據了。

1:HTTPS有哪些缺點？
HTTPS有以下4個缺點：
(1):通訊兩端都須要進行加密和解密，會消耗大量的CPU，內存等資源，增長了服務器的負載
(2):加密運算和屢次握手下降了訪問速度
(3):在開發階段，加大了頁面調試難度。因爲信息都被加密了，因此用代理工具，須要先解密才能看到真實信息
(4):用HTTPS訪問的頁面，頁面內的外部資源都得用HTTPS請求。包括腳本中的AJAX請求
。

2：什麼是運營商劫持？有什麼辦法預防？
運行商是指提供網絡服務的ISP，例如三大基礎運營商：移動，聯通，電信。運營商爲了謀取經濟利益，有時候會劫持用戶的HTTP訪問，最明顯的特徵就是在頁面上植入廣告，有些是購物廣告，有些確實淫穢廣告(噫噫噫，嘔嘔嘔)，很是影響界面體驗和公司形象。爲了不被運營商劫持，可讓服務器支持HTTPS協議，HTTPS傳輸的數據都被加密過了，運營商就沒法再注入廣告代碼，頁面也就不會被再劫持了。

HTTP/2.0

2.0版本保留了1.1版本的大部分語義，例如請求方法，狀態碼和首部等。由互聯網工程任務組爲2.0版本實現標準化。2.0版本從協議層面進行改動，目標是優化應用，突破性能限制，改善用戶在瀏覽Web頁面時的速度體驗。

HTTP/1.1有不少不足，下面列舉5個比較有表明性的不足：
(1)在傳輸中會出現隊首阻塞問題
(2)響應不分輕重緩急，只會按照先來後到的順序執行
(3)並行通訊須要創建多個TCP鏈接
(4)服務器不能主動推送客戶端想要的資源，只能被動的等待客戶端發起請求
(5)因爲HTTP是無狀態的，因此每次請求和響應都會攜帶大量冗餘信息

二進制分幀層

二進制分幀層是HTTP/2.0性能加強的關鍵，它改變了通訊兩端交互數據的方式，原先都是以文本傳輸，如今要先對數據進行二進制編碼，再把數據分紅一個個的幀，接着把幀送到數據流中，最後對方接收幀並拼成一條消息,若干條消息在數據流中傳輸，一個TCP鏈接能夠分出若干條數據流，所以HTTP/2.0只要創建一次TCP鏈接就能完成全部傳輸。流，消息，幀是二進制分幀層的基本概念

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。