一、http是什么

通俗來講，http就是計算機通過網路進行通信的規則，是一個基于請求與回應，無狀態的，應用層協議，常用于TCP/IP協議傳輸資料，目前任何終端之間任何一種通信方式都必須按Http協議進行，否則無法連接，tcp(三次握手，四次揮手)，

請求與回應：客戶端請求、服務端回應資料，
無狀態：協議對于事務的處理是沒有記憶能力，客戶端第一次與服務器建立連接發送請求時需要進行一系列的安全認證匹配操作，因此增加頁面等待時間，當客戶端向服務端發送請求，服務端回應完畢后，兩者斷開鏈接，也不保存連接狀態，
TCP/IP:Http使用TCP作為它的支撐運輸協議，Http客戶機發起一個與服務器的TCP連接，一旦連接建立，瀏覽器（客戶機）和服務器行程就可以通過套接字介面（socket interface）訪問TCP，

二 http三個組成部分

http請求由三部分構成，分別是：請求頭、訊息報頭、請求正文

請求方法：get、post、head、put、delete

GET方法與POST方法的區別

區別一：
get重點在從服務器上獲取資源，post重點在向服務器發送資料；
區別二：
get傳輸資料是通過URL請求，以field（欄位）= value的形式，置于URL后，并用"?"連接，多個請求資料間用"&"連接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個程序用戶是可見的；
post傳輸資料通過Http的post機制，將欄位與對應值封存在請求物體中發送給服務器，這個程序對用戶是不可見的；
區別三：
Get傳輸的資料量小，因為受URL長度限制，但效率較高；

Post可以傳輸大量資料，所以上傳檔案時只能用Post方式；

區別四：
get是不安全的，因為URL是可見的，可能會泄露私密資訊，如密碼等；
post較get安全性較高；
區別五：
get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼，
post支持標準字符集，可以正確傳遞中文字符，

常見的HTTP相應狀態碼

　　　　回傳的狀態
　　　　1xx：指示資訊--表示請求已接收，繼續處理
　　　　2xx：成功--表示請求已被成功接收、理解、接受
　　　　3xx：重定向--要完成請求必須進行更進一步的操作
　　　　4xx：客戶端錯誤--請求有語法錯誤或請求無法實作
　　　　5xx：服務器端錯誤--服務器未能實作合法的請求

　　　　200：請求被正常處理
　　　　204：請求被受理但沒有資源可以回傳
　　　　206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中通過Content-Range指定范圍的資源，
　　　　301：永久性重定向
　　　　302：臨時重定向
　　　　303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
　　　　304：發送附帶條件的請求時，條件不滿足時回傳，與重定向無關
　　　　307：臨時重定向，與302類似，只是強制要求使用POST方法
　　　　400：請求報文語法有誤，服務器無法識別
　　　　401：請求需要認證
　　　　403：請求的對應資源禁止被訪問
　　　　404：服務器無法找到對應資源
　　　　500：服務器內部錯誤
　　　　503：服務器正忙

請求URL：他與報文頭的host屬性組成完整的URL
3??協議名稱以及版本號（http1.1）
4??HTTP請求頭（報文頭）：包含Request與Response兩個部分
HTTP請求頭提供了關于請求，回應或者其他的發送物體的資訊，HTTP的頭資訊包括通用頭、請求頭、回應頭和物體頭四個部分，每個頭域由一個域名，冒號（:）和域值三部分組成（屬性名：屬性值），

通用頭標：即可用于請求，也可用于回應，是作為一個整體而不是特定資源與事務相關聯，
請求頭標：允許客戶端傳遞關于自身的資訊和希望的回應形式，
回應頭標：服務器和于傳遞自身資訊的回應，
物體頭標：定義被傳送資源的資訊，即可用于請求，也可用于回應，

5??是報文體，它將一個頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求引數的資料，不但報文體可以傳遞請求引數，請求URL也可以通過類似于“/chapter15/user.html? param1=value1&param2=value2”的方式傳遞請求引數，

三、HTTP發展史（HTTP1.1與HTTP2.0）

1. Http0.9：該協議誕生之初的作用是傳輸超文本內容HTML，并且只支持GET請求，

　　　　協議定義了客戶端發起請求、服務端回應請求的通信模式，所以當時的請求報文只有一行：

GET + 請求的檔案路徑

2. Http1.0：瀏覽器希望通過HTTP來傳輸腳本、樣式、圖片、音視頻等不同型別的檔案　　

增加了HEAD、POST等新方法
增加了回應狀態碼，標記可能的錯誤原因
引入了協議版本號概念
引入了HTTP header的概念，讓HTTP處理請求和回應更加靈活
傳輸的資料不再局限于文本

http1.0缺點：

HTTP/1.0最主要的缺點還是跟HTTP/0.9一樣，每一個TCP連接只能發送一個HTTP請求，服務器發送完回應，就關閉連接，如果后面需要請求新的資料，則需要再次建立TCP連接，但是TCP建立連接的三次握手成本比較高，并且TCP連接初始的時候發送資料的速度相對較慢，有一個慢啟動和擁塞避免的階段，極端情況，如果每次請求的資料很少，但是請求很頻繁，這樣每次請求很少的資料都需要建立連接然后斷開，

解決辦法：

為了解決這個問題，在1.0版本使用了一個非標準的Connection頭部欄位，當客戶端再請求頭部資訊里面帶上Connection：keep-alive的時候，服務器在發送完回應資料之后，就不會斷開TCP連接了，從而達到復用同一個TCP連接的目的，但是由于不是標準欄位，不同的實作可能導致表現得不一致，因此不能從根本上解決這個問題，

HTTP/1.0最核心的改變是增加了頭部設定，頭部內容以鍵值對的形式設定，請求頭部通過 Accept 欄位來告訴服務端可以接收的檔案型別，回應頭部再通過 Content-Type 欄位來告訴瀏覽器回傳檔案的型別，頭部欄位不僅用于解決不同型別檔案傳輸的問題，也可以實作其他很多功能如快取、認證資訊等，

3. Http1.1

長連接：引入了 TCP 連接復用，即一個 TCP 默認不關閉，可以被多個請求復用
并發連接：對一個域名的請求允許分配多個長連接（緩解了長連接中的「隊頭阻塞」問題）
引入管道機制（pipelining），一個 TCP 連接，可以同時發送多個請求，（回應的順序必須和請求的順序一致，因此不常用）
增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法
新增了一些快取的欄位（If-Modified-Since, If-None-Match）
請求頭中引入了 range 欄位，支持斷點續傳
允許回應資料分塊（chunked），利于傳輸大檔案
強制要求 Host 頭，讓互聯網主機托管稱為可能

HTTP管道機制（pipelining）

它指的是在一個TCP連接內，多個HTTP請求可以并行，客戶端不用等待上一次請求結果回傳，就可以發出下一次請求，但服務器端必須按照接收到客戶端請求的先后順序依次回送回應結果，以保證客戶端能夠區分出每次請求的回應內容，

隨著網路的發展，HTTP 1.1 還是暴露出一些局限性:

雖然加入 keep-alive 可以復用一部分連接，但域名分片等情況下仍然需要建立多個connection，耗費資源，給服務器帶來性能壓力，
pipeling 只部分解決了隊頭阻塞（ HOLB）， HTTP 1.1 嘗試使用 pipeling 來解決隊頭阻塞問題，即瀏覽器可以一次性發出多個請求（同個域名、同一條 TCP 鏈接），但 pipeling 要求回傳是按序的，那么前一個請求如果很耗時（比如處理大圖片），那么后面的請求即使服務器已經處理完，仍會等待前面的請求處理完才開始按序回傳，
協議開銷大，沒有相應的壓縮傳輸優化方案， HTTP/1.1 在使用時，header 里攜帶的內容過大，在一定程度上增加了傳輸的成本，并且每次請求 header 基本不怎么變化，尤其在移動端增加用戶流量，

HTTP/1.1 通過長連接減少了大量創建/斷開連接造成的性能消耗，但是它的并發能力受到限制，表現在兩個方面：

HTTP/1.1 中使用持久連接時，一個連接中同一時刻只能處理一個請求，當前的請求沒有結束之前，其他的請求只能處于阻塞狀態，這種情況被稱為隊頭阻塞
瀏覽器為了減輕服務器的壓力，限制了同一個域名下的 HTTP 連接數，一般為 6 ~ 8 個，為了解決數量限制，出現了 域名分片 技術，其實就是資源分域，將資源放在不同域名下 (比如二級子域名下)，這樣就可以針對不同域名創建連接并請求，以一種討巧的方式突破限制，但是濫用此技術也會造成很多問題，比如每個 TCP 連接本身需要經過 DNS 查詢、三步握手、慢啟動等，還占用額外的 CPU 和記憶體，對于服務器來說過多連接也容易造成網路擁擠、交通阻塞等，
SPDY：HTTP1.X的優化（改進版HTTP/1.1）
2012年google提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體如下：

降低延遲：針對HTTP高延遲的問題，SPDY優雅的采取了多路復用（multiplexing），多路復用通過多個請求stream共享一個tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時提高了帶寬的利用率，
請求優先級（request prioritization）：多路復用帶來一個新的問題是，在連接共享的基礎之上有可能會導致關鍵請求被阻塞，SPDY允許給每個request設定優先級，這樣重要的請求就會優先得到回應，比如瀏覽器加載首頁，首頁的html內容應該優先展示，之后才是各種靜態資源檔案，腳本檔案等加載，這樣可以保證用戶能第一時間看到網頁內容，
header壓縮：前面提到HTTP1.x的header很多時候都是重復多余的，選擇合適的壓縮演算法可以減小包的大小和數量，
基于HTTPS的加密協議傳輸：大大提高了傳輸資料的可靠性，
服務端推送（server push）：可以讓服務端主動把資源檔案推送給客戶端，當然客戶端也有權利選擇是否接收，

4. Http2.0

2015 年正式發布的 HTTP/2 默認不再使用 ASCII 編碼傳輸，而是改為二進制資料，來提升傳輸效率，

客戶端在發送請求時會將每個請求的內容封裝成不同的帶有編號的二進制幀（Frame），然后將這些幀同時發送給服務端，服務端接收到資料之后，會將相同編號的幀合并為完整的請求資訊，同樣，服務端回傳結果、客戶端接收結果也遵循這個幀的拆分與組合的程序，

有了二進制分幀后，對于同一個域，客戶端只需要與服務端建立一個連接即可完成通信需求，這種利用一個連接來發送多個請求的方式稱為多路復用，每一條路都被稱為一個stream（流），

特點：

二進制協議： HTTP/1.1版本的頭部資訊是文本，資料部分可以是文本也可以是二進制，HTTP/2版本的頭部和資料部分都是二進制，且統稱為‘幀’
多路復用： 廢棄了 HTTP/1.1 中的管道，同一個TCP連接里面，客戶端和服務器可以同時發送多個請求和多個回應，并且不用按照順序來，由于服務器不用按順序來處理回應，所以避免了“對頭堵塞”的問題，
頭部資訊壓縮： 使用專用演算法壓縮頭部，減少資料傳輸量，主要是通過服務端和客戶端同時維護一張頭部資訊表，所有的頭部資訊在表里面都會有對應的記錄，并且會有一個索引號，這樣后面只需要發送索引號即可
服務端主動推送： 允許服務器主動向客戶推送資料
資料流：由于HTTP/2版本的資料包不是按照順序發送的，同一個TCP連接里面相連的兩個資料包可能是屬于不同的回應，因此，必須要有一種方法來區分每一個資料包屬于哪個回應，HTTP/2版本中，每個請求或者回應的所有資料包，稱為一個資料流（stream），并且每一個資料流都有一個唯一的編號ID，請求資料流的編號ID為奇數，回應資料流的編號ID為偶數，每個資料包在發送的時候帶上對應資料流的編號ID，這樣服務器和客戶端就能磁區是屬于哪一個資料流，最后，客戶端還能指定資料流的優先級，優先級越高，服務器會越快做出回應，

缺點：

HTTP/2雖然解決了許多問題，但在TCP協議級別上仍然存在類似的隊頭問題，而TCP仍然是Web的構建基礎，當 TCP 資料包在傳輸程序中丟失時，在服務器重新發送丟失的資料包之前，接收方無法確認傳入的資料包，由于 TCP 在設計上不遵循 HTTP 之類的高級協議，因此單個丟失的資料包將阻塞所有進行中的 HTTP 請求的流，直到重新發送丟失的資料為止，這個問題在不可靠的連接上尤為突出，這在無處不在的移動設備時代并不罕見，

5.HTTP/3

HTTP/2 由于采用二進制分幀進行多路復用，通常只使用一個 TCP 連接進行傳輸，在丟包或網路中斷的情況下后面的所有資料都被阻塞，
HTTP/2 的問題不能僅靠應用程式層來解決，因此協議的新迭代必須更新傳輸層，但是，創建新的傳輸層協議并非易事，傳輸協議需要硬體供應商的支持，并且需要大多數網路運營商的部署才能普及，

幸運的是還有另一種選擇，UDP 協議與 TCP 一樣得到廣泛支持，但前者足夠簡單，可以作為在其之上運行的自定義協議的基礎，**UDP 資料包是一勞永逸的：沒有握手、持久連接或錯誤校正，**HTTP3 背后的主要思想是放棄 TCP，轉而使用基于 UDP 的 QUIC （快速UDP互聯網連接）協議，

與 HTTP2 在技術上允許未加密的通信不同，QUIC 嚴格要求加密后才能建立連接，此外，加密不僅適用于 HTTP 負載，還適用于流經連接的所有資料，從而避免了一大堆安全問題，建立持久連接、協商加密協議，甚至發送第一批資料都被合并到 QUIC 中的單個請求/回應周期中，從而大大減少了連接等待時間，如果客戶端具有本地快取的密碼引數，則可以通過簡化的握手重新建立與已知主機的連接，

為了解決傳輸級別的線頭阻塞問題，通過 QUIC 連接傳輸的資料被分為一些流，流是持久性 QUIC 連接中短暫、獨立的“子連接”，每個流都處理自己的錯誤糾正和傳遞保證，但使用連接全域壓縮和加密屬性，每個客戶端發起的 HTTP 請求都在單獨的流上運行，因此丟失資料包不會影響其他流/請求的資料傳輸，

6.各版本對比

HTTP的三次握手??與四次揮手???♂?

一個完整的HTTP是包含請求與回應的，所以需要通過TCP來創建連接通道

一個TCP通道可以通過多個HTTP請求

一般來講需要通過三次握手來確認連接程序，規避因為網路原因從而產生的資源消耗，從而創建TCP連接

三次握手

第一次握手：客戶端發送syn包(syn=x)到服務器，并進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手，
握手程序中傳送的包里不包含資料，三次握手完畢后，客戶端與服務器才正式開始傳送資料，理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP 連接都將被一直保持下去，

四次揮手
與建立連接的“三次握手”類似，斷開一個TCP連接則需要“四次握手”，

第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的資料傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發資料了(當然，在fin包之前發送出去的資料，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些資料)，但是，此時主動關閉方還可以接受資料，
第二次揮手：被動關閉方收到FIN包后，發送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），
第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的資料傳送，也就是告訴主動關閉方，我的資料也發送完了，不會再給你發資料了，
第四次揮手：主動關閉方收到FIN后，發送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手，

HTTP/1.0與HTTP/1.1的區別

長連接

HTTP 1.1支持長連接（PersistentConnection）和請求的管道（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和回應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection: Keep-Alive； HTTP1.0默認使用短連接，規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求，要建立長連接，可以在請求訊息中包含Connection: Keep-Alive頭域，如果服務器愿意維持這條連接，在回應訊息中也會包含一個Connection: Keep-Alive的頭域，

快取處理

在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為快取判斷的標準，HTTP1.1則引入了更多的快取控制策略例如Entity tag，If-Unmodified-Since,If-Match, If-None-Match等更多可供選擇的快取頭來控制快取策略，

Expires：瀏覽器會在指定過期時間內使用本地快取，指明應該在什么時候認為檔案已經過期，從而不再快取它，時間為格林威治時間GMT，例如: Expires: Thu, 19 Nov 1981 08:52:00 GMT

Last-Modified：請求物件最后一次的修改時間用來判斷快取是否過期通常由檔案的時間資訊產生

Date：生成訊息的具體時間和日期，即當前的GMT時間，例如:Date: Sun, 17 Mar 2013 08:12:54 GMT

If-Modified-Since：客戶端存取的該資源最后一次修改的時間，用來和服務器端的Last-Modified做比較

Set-Cookie: 用于把cookie 發送到客戶端，例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

Pragma:no-cache：客戶端使用該頭域說明請求資源不能從cache中獲取，而必須回源獲取，

帶寬優化

HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個物件的一部分，而服務器卻將整個物件送過來了，并且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即回傳碼是206（Partial Content），這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接，

錯誤通知的管理（狀態碼）

在HTTP1.1中新增了24個錯誤狀態回應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的洗掉，

Host頭處理

在HTTP1.0中認為每臺服務器都系結一個唯一的IP地址，因此，請求訊息中的URL并沒有傳遞主機名（hostname），但隨著虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址，HTTP1.1的請求訊息和回應訊息都應支持Host頭域，且請求訊息中如果沒有Host頭域會報告一個錯誤（400 Bad Request），

HTTP/2與SPDY的區別

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
HTTP2.0 訊息頭的壓縮演算法采用 HPACK，而非 SPDY 采用的 DEFLATE

HTTP/1.1與HTTP/2的區別

新的二進制格式（Binary Format），HTTP1.x決議是基于文本的，基于文本協議的格式決議存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合，基于這種考慮HTTP2.0的協議決議決定采用二進制格式，實作方便且健壯，
多路復用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的，一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面，
header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量資訊，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小，
服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能，

HTTP/2的多路復用和HTTP/1.X中的長連接復用的區別

HTTP/1.X 一次請求-回應，建立一個連接，用完關閉；每一個請求都要建立一個連接；
HTTP/1.1 Pipeling解決方式為，若干個請求排隊串行化單執行緒處理，后面的請求等待前面請求的回傳才能獲得執行機會，一旦有某請求超時等，后續請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；
HTTP/2多個請求可同時在一個連接上并行執行，某個請求任務耗時嚴重，不會影響到其它連接的正常執行；

HTTP/1.1與HTTP/2性能對比

官網提供了多種版本的對比測驗有HTTP1.1與HTTP2的比較，還有服務器端推送(server-push)不同個數之間的比較：（由于網路延遲不同，測驗結果或有差異）

可以看到分別使用HTTP/1.1和HTTP/2加載同一張由多張小圖片組成的大圖片：HTTP/1.1用了7.41s，而HTTP/2只用了1.47s，HTTP2比HTTP/1.1快了將近5倍，
因為為了加載這張大圖，需要請求許多的小圖，HTTP/1.1采用的是串行請求，所以速度要比采用并行請求的HTTP/2要慢上許多，

HTTP與HTTPS的區別

HTTPS

HTTPS是以安全為目標的 HTTP 通道，是 HTTP 的安全版，HTTPS 的安全基礎是 SSL，SSL 協議位于 TCP/IP 協議與各種應用層協議之間，為資料通訊提供安全支持，

SSL 協議可分為兩層：

SSL 記錄協議（SSL Record Protocol），它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支持，

SSL 握手協議（SSL Handshake Protocol），它建立在 SSL 記錄協議之上，用于在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密密鑰等，

HTTPS的優點

使用 HTTPS 協議可認證用戶和服務器，確保資料發送到正確的客戶機和服務器，
HTTPS 協議是由SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，要比 HTTP 協議安全，可防止資料在傳輸程序中不被竊取、修改，確保資料的完整性，
HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本，

HTTPS的缺點

HTTPS 協議握手階段比較費時，會使頁面的加載時間延長近，
HTTPS 連接快取不如 HTTP 高效，會增加資料開銷，甚至已有的安全措施也會因此而受到影響，
HTTPS 協議的安全是有范圍的，在黑客攻擊、拒絕服務攻擊和服務器劫持等方面幾乎起不到什么作用，
SSL 證書通常需要系結 IP，不能在同一 IP 上系結多個域名，IPv4 資源不可能支撐這個消耗，
部署 HTTPS 后，因為 HTTPS 協議的作業要增加額外的計算資源消耗，例如 SSL 協議加密演算法和 SSL 互動次數將占用一定的計算資源和服務器成本，
HTTPS 協議的加密范圍也比較有限，最關鍵的，SSL 證書的信用鏈體系并不安全，特別是在某些國家可以控制 CA 根證書的情況下，中間人攻擊一樣可行，

與HTTP的區別

HTTP 是超文本傳輸協議，資訊是明文傳輸，HTTPS 則是具有安全性的 SSL 加密傳輸協議，
HTTP與HTTPS的連接方式不同，埠也不同，HTTP埠用的是80，HTTPS埠用的是443，
HTTP 的連接很簡單，是無狀態的，HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 HTTP 協議安全，(無狀態的意思是其資料包的發送、傳輸和接收都是相互獨立的，無連接的意思是指通信雙方都不長久的維持對方的任何資訊，)
HTTPS協議需要申請證書，一般免費的證書很少，

HTTP優化

啟用長連接，TCP 和 SSL 建立新連接的成本是非常高的，有可能會占到客戶端總延遲的一半以上，長連接雖然不能優化連接握手，但可以把成本“均攤”到多次請求里，這樣只有第一次請求會有延遲，之后的請求就不會有連接延遲，總體的延遲也就降低了，
資料壓縮編碼不僅可以使用標準的gzip，還可以使用新壓縮演算法br，有更好的壓縮效果，除此之外，對于HTTP協議傳輸的各種格式資料，我們可以有針對性地采用特殊的壓縮方式，
HTML/CSS/JavaScript 屬于純文本，就可以采用特殊的壓縮，去掉原始碼里多余的空格、換行、注釋等元素，

圖片在 HTTP 傳輸里占有非常高的比例，雖然它本身已經被壓縮過了，不能被 gzip、br 處理，但仍然有優化的空間，比如說，去除圖片里的拍攝時間、地點、機型等元資料，適當降低解析度，縮小尺寸，圖片的格式也很關鍵，盡量選擇高壓縮率的格式，有損格式應該用 JPEG，無損格式應該用 Webp 格式，

剛才說的幾種資料壓縮針對的都是 HTTP 報文里的 body，在 HTTP/1 里沒有辦法可以壓縮 header，但我們也可以采取一些手段來減少 header 的大小，不必要的欄位就盡量不發（例如 Server、X-Powered-By）

對于小文本或者小圖片，可以使用資源合并的方式，把許多小資源合并成一個大資源，用一個請求全下載到客戶端，然后客戶端再切分后使用，好處是節省了請求次數，缺點是可能會快取有影響，可能降低快取的可用性

盡量不使用重定向，重定向引發的客戶端延遲也很高，它不僅增加了一次請求往返，還有可能導致新域名的 DNS 決議，

利用好快取，為每個資源都添加 ETag 和 Last-modified 欄位，再用 Cache-Control、Expires 設定好快取控制屬性，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/550577.html

標籤：JavaScript

上一篇：CSS—相對單位rem

下一篇：http1.1與http2.0

http1.1與http2.0