HTTP發展史，HTTP1.1與HTTP2.0的區別

本文轉載自查看原文 2022-03-28 08:25 700 前端面試題

前言

我們知道HTTP是瀏覽器中最重要且使用最多的協議，它不僅是瀏覽器與服務端的通信語言，更是互聯網的基石。隨着瀏覽器的不斷更新迭代，HTTP為了適應技術的更新也在不斷進化，學習HTTP的最佳途徑就是從瀏覽器的發展視角來了解HTTP的演進：即將完成使命的HTTP/1、正在向我們走來的HTTP/2、未來的HTTP/3

如果這篇文章有幫助到你，❤️關注+點贊❤️鼓勵一下作者，文章公眾號首發，關注 前端南玖 第一時間獲取最新文章～

HTTP發展史

HTTP 是瀏覽器與服務端最主要的通信協議

20 世紀 60 年代，美國國防部高等研究計划署（ARPA）建立了 ARPA 網，這被認為是互聯網的起源。70 年代，研究人員基於對 ARPA 網的實踐和思考，發明出了著名的 TCP/IP 協議。該協議具有良好的分層結構和穩定的性能，並在 80 年代中期進入了 UNIX 系統內核，促使更多的計算機接入了網絡。

1989 年，蒂姆伯納斯-李博士發表了一篇論文，提出了在互聯網上構建超鏈接文檔系統的構想。在篇文章中他確立了三項關鍵技術：URI、HTML、HTTP。

HTTP發展史.png

HTTP/0.9

1991年HTTP（HyperText Transfer Protocol，超文本傳輸協議）正式誕生，萬維網協會（World Wide Web Consortium，W3C）和互聯網工程任務組（IETF）制定了 HTTP 0.9 標准。該協議誕生之初的作用是傳輸超文本內容HTML，並且只支持GET請求。

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

GET + 請求的文件路徑

服務端在收到請求后會返回一個以 ASCII 字符流編碼的 HTML 文檔。
HTTP0.9.png

請求： GET /index.html

響應： <html><body>Hello HTTP/0.9</body></html>

流程：

客戶端和服務端建立TCP連接。
客戶端發送GET請求到服務端，請求index.html頁面的數據。
服務端發送完響應，關閉TCP連接。

特點： 簡單，一個請求需要一個連接。

HTTP/0.9 雖然簡單，但是它充分驗證了 Web 服務的可行性

首先它只有一個命令GET。
它沒有HEADER等描述數據的信息。因為這個時候的請求非常簡單，它需要達到的目的也非常簡單，沒有那么多數據格式。
服務器發送完內容之后，就關閉TCP連接。這里需要注意一點，這里的TCP連接和http請求是不一樣的。http請求和TCP連接不是一個概念。一個http請求通過TCP連接發送，而一個TCP連接里面可以發送很多個http請求（HTTP/0.9不能這么做，但是HTTP/1.1可以這么做，而且在HTTP/2這方面會更大程度地優化，來提高HTTP協議傳輸的效率以及服務器的性能）

HTTP/1.0

隨着互聯網的發展，之前的HTTP/0.9已經無法滿足用戶需求了，瀏覽器希望通過HTTP來傳輸腳本、樣式、圖片、音視頻等不同類型的文件，所以在1996年HTTP進行了一次版本更新：

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

請求： 第一行請求命令+版本信息，后面的多行為頭信息

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

響應： 響應頭信息 + 空行(\r\n) + 數據部分

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 2345
Expires: Thu, 05 Dec 2020 16:00:00 GMT
Last-Modified: Wed, 5 August 2020 15:55:28 GMT
Server: Apache 0.84

<html>
   <body>Hello World</body>
</html>

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 字段來告訴瀏覽器返回文件的類型。頭部字段不僅用於解決不同類型文件傳輸的問題，也可以實現其他很多功能如緩存、認證信息等。

HTTP/1.0 並不是一個“標准”，只是一份參考文檔，不具有實際的約束力。

HTTP/1.1

隨着互聯網的快速發展，HTTP/1.0也無法滿足用戶需求了，最根本的問題就是鏈接問題， HTTP/1.0 每進行一次通信，都需要經歷建立連接、傳輸數據和斷開連接三個階段。當一個頁面引用了較多的外部文件時，這個建立連接和斷開連接的過程就會增加大量網絡開銷。

為了解決 HTTP/1.0 的問題，1999 年推出的 HTTP/1.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）：可以讓服務端主動把資源文件推送給客戶端。當然客戶端也有權利選擇是否接收。

HTTP/2

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 請求的流，直到重新發送丟失的數據為止。這個問題在不可靠的連接上尤為突出，這在無處不在的移動設備時代並不罕見。

HTTP/3

HTTP/2 由於采用二進制分幀進行多路復用，通常只使用一個 TCP 連接進行傳輸，在丟包或網絡中斷的情況下后面的所有數據都被阻塞。

HTTP/2 的問題不能僅靠應用程序層來解決，因此協議的新迭代必須更新傳輸層。但是，創建新的傳輸層協議並非易事。傳輸協議需要硬件供應商的支持，並且需要大多數網絡運營商的部署才能普及。

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

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

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

各版本對比

協議版本	解決的核心問題	解決方式
0.9	HTML 文件傳輸	確立了客戶端請求、服務端響應的通信流程
1.0	不同類型文件傳輸	設立頭部字段
1.1	創建/斷開 TCP 連接開銷大	建立長連接進行復用
2	並發數有限	二進制分幀
3	TCP 丟包阻塞	采用 UDP 協議
SPDY	HTTP1.X的請求延遲	多路復用

HTTP的三次握手🤝與四次揮手🙋‍♂️

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

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

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

三次握手

第一次握手： 客戶端發送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)不同個數之間的比較：（由於網絡延遲不同，測試結果或有差異）

HTTP1與HTTP2性能對比.png

可以看到分別使用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協議需要申請證書，一般免費的證書很少。