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

前端南玖發表於2022-03-28

前言

我們知道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協議需要申請證照，一般免費的證照很少。