本文將涉及以下方面：

• HTTP協議
• HTTP1.0
• HTTP1.1
• HTTP2.0
• 1.0和1.1和2.0之間的區別
• HTTPS

HTTP協議

HTTP（超文字傳輸協議，HyperText Transfer Protocol)是網際網路上應用最為廣泛的一種網路協議。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議。預設使用80埠，HTTP客戶端發起一個請求，建立一個到伺服器指定埠（預設是80埠）的TCP連線。HTTP協議和TCP協議是不衝突的，HTTP定義在七層協議中的應用層，TCP解決的是傳輸層的邏輯。HTTP使用TCP而不是UDP的原因在於（開啟）一個網頁必須傳送很多資料，而TCP協議提供傳輸控制，按順序組織資料，和錯誤糾正。HTTP協議的瓶頸及其優化技巧都是基於TCP協議本身的特性。如TCP建立連線時三次握手有1.5個RTT（round-trip time）的延遲，為了避免每次請求的都經歷握手帶來的延遲，應用層會選擇不同策略的http長連結方案。又如TCP在建立連線的初期有慢啟動（slow start）的特性，所以連線的重用總是比新建連線效能要好。

HTTP連線使用的是“請求—響應”的方式，不僅在請求時需要先建立連線，而且需要客戶端向伺服器發出請求後，伺服器端才能回覆資料。HTTP/1.0是第一個在通訊中指定版本號的HTTP 協議版本，至今仍被廣泛採用，特別是在代理伺服器中。HTTP/1.1是當前版本，持久連線被預設採用，並能很好地配合代理伺服器工作，還支援以管道方式同時傳送多個請求，以便降低線路負載，提高傳輸速度。HTTP／2.0在HTTP 1.x的基礎上，大幅度的提高了web效能，減少了網路延遲。HTTP1.0和1.1在之後很長的一段時間內會一直並存，這是由於網路基礎設施更新緩慢所決定的。

HTTP1.0

HTTP 協議老的標準是HTTP/1.0，為了提高系統的效率，HTTP 1.0規定瀏覽器與伺服器只保持短暫的連線，瀏覽器的每次請求都需要與伺服器建立一個TCP連線，伺服器完成請求處理後立即斷開TCP連線，伺服器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成了一些效能上的缺陷，例如，一個包含有許多影象的網頁檔案中並沒有包含真正的影象資料內容，而只是指明瞭這些影象的URL地址，當WEB瀏覽器訪問這個網頁檔案時，瀏覽器首先要發出針對該網頁檔案的請求，當瀏覽器解析WEB伺服器返回的該網頁文件中的HTML內容時，發現其中的影象標籤後，瀏覽器將根據標籤中的src屬性所指定的URL地址再次向伺服器發出下載影象資料的請求。顯 然，訪問一個包含有許多影象的網頁檔案的整個過程包含了多次請求和響應，每次請求和響應都需要建立一個單獨的連線，每次連線只是傳輸一個文件和影象，上一次和下一次請求完全分離。即使影象檔案都很小，但是客戶端和伺服器端每次建立和關閉連線卻是一個相對比較費時的過程，並且會嚴重影響客戶機和伺服器的效能。當一個網頁檔案中包含JavaScript檔案，CSS檔案等內容時，也會出現類似上述的情況。

同時，頻寬和延遲也是影響一個網路請求的重要因素。在網路基礎建設已經使得頻寬得到極大的提升的當下，大部分時候都是延遲在於響應速度。基於此會發現，http1.0被抱怨最多的就是連線無法複用，和head of line blocking這兩個問題。理解這兩個問題有一個十分重要的前提：客戶端是依據域名來向伺服器建立連線，一般PC端瀏覽器會針對單個域名的server同時建立6～8個連線，手機端的連線數則一般控制在4～6個。顯然連線數並不是越多越好，資源開銷和整體延遲都會隨之增大。連線無法複用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對檔案類大請求影響較大。head of line blocking會導致頻寬無法被充分利用，以及後續健康請求被阻塞。

head of line blocking(holb)會導致健康的請求會被不健康的請求影響，而且這種體驗的損耗受網路環境影響，出現隨機且難以監控。為了解決holb帶來的延遲，協議設計者設計了一種新的pipelining機制。pipelining只能適用於http1.1,而且由於使用苛刻，很多瀏覽器廠商並不支援。

HTTP1.1

為了克服HTTP 1.0的這個缺陷，HTTP 1.1支援持久連線（HTTP/1.1的預設模式使用帶流水線的持久連線），在一個TCP連線上可以傳送多個HTTP請求和響應，減少了建立和關閉連線的消耗和延遲。一個包含有許多影象的網頁檔案的多個請求和應答可以在一個連線中傳輸，但每個單獨的網頁檔案的請求和應答仍然需要使用各自的連線。HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但伺服器端必須按照接收到客戶端請求的先後順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間。

在http1.1，request和reponse頭中都有可能出現一個connection的頭，此header的含義是當client和server通訊時對於長連結如何進行處理。
在http1.1中，client和server都是預設對方支援長連結的， 如果client使用http1.1協議，但又不希望使用長連結，則需要在header中指明connection的值為close；如果server方也不想支援長連結，則在response中也需要明確說明connection的值為close。不論request還是response的header中包含了值為close的connection，都表明當前正在使用的tcp連結在當天請求處理完畢後會被斷掉。以後client再進行新的請求時就必須建立新的tcp連結了。

HTTP 1.1在繼承了HTTP 1.0優點的基礎上，也克服了HTTP 1.0的效能問題。HTTP 1.1通過增加更多的請求頭和響應頭來改進和擴充HTTP 1.0的功能。如，HTTP 1.0不支援Host請求頭欄位，WEB瀏覽器無法使用主機頭名來明確表示要訪問伺服器上的哪個WEB站點，這樣就無法使用WEB伺服器在同一個IP地址和埠號上配置多個虛擬WEB站點。在HTTP 1.1中增加Host請求頭欄位後，WEB瀏覽器可以使用主機頭名來明確表示要訪問伺服器上的哪個WEB站點，這才實現了在一臺WEB伺服器上可以在同一個IP地址和埠號上使用不同的主機名來建立多個虛擬WEB站點。HTTP 1.1的持續連線，也需要增加新的請求頭來幫助實現，例如，Connection請求頭的值為Keep-Alive時，客戶端通知伺服器返回本次請求結果後保持連線；Connection請求頭的值為close時，客戶端通知伺服器返回本次請求結果後關閉連線。HTTP 1.1還提供了與身份認證、狀態管理和Cache快取等機制相關的請求頭和響應頭。HTTP/1.0不支援檔案斷點續傳，<code>RANGE:bytes</code>是HTTP/1.1新增內容，HTTP/1.0每次傳送檔案都是從檔案頭開始，即0位元組處開始。<code>RANGE:bytes=XXXX</code>表示要求伺服器從檔案XXXX位元組處開始傳送，這就是我們平時所說的斷點續傳！

由上，HTTP/1.1相較於 HTTP/1.0 協議的區別主要體現在：

1 快取處理

2 頻寬優化及網路連線的使用

3 錯誤通知的管理

4 訊息在網路中的傳送

5 網際網路地址的維護

6 安全性及完整性

常用的請求方式

GET 請求獲取Request-URI所標識的資源

POST 在Request-URI所標識的資源後附加新的資料

HEAD 請求獲取由Request-URI所標識的資源的響應訊息報頭

PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識

DELETE 請求伺服器刪除Request-URI所標識的資源

TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷

CONNECT 保留將來使用

OPTIONS 請求查詢伺服器的效能，或者查詢與資源相關的選項和需求

GET方法：在瀏覽器的位址列中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向伺服器獲取資源，POST方法要求被請求伺服器接受附在請求後面的資料，常用於提交表單。GET是用於獲取資料的，POST一般用於將資料發給伺服器之用。

請求頭資訊示例

// 請求
GET / HTTP/1.1

Host:xxx.xxxx.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2016042316 Firefox/3.0.10

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

If-Modified-Since: Mon, 25 May 2016 03:19:18 GMT


//響應
HTTP/1.1 200 OK

Cache-Control: private, max-age=30

Content-Type: text/html; charset=utf-8

Content-Encoding: gzip

Expires: Mon, 25 May 2016 03:20:33 GMT

Last-Modified: Mon, 25 May 2016 03:20:03 GMT

Vary: Accept-Encoding

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

Date: Mon, 25 May 2016 03:20:02 GMT

Content-Length: 12173

訊息體的內容（略）

示例

HTTP 1.1狀態程式碼及其含義

狀態程式碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

1xx：指示資訊--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操作

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現

5xx：伺服器端錯誤--伺服器未能實現合法的請求

狀態程式碼 狀態資訊 含義
100 Continue 初始的請求已經接受，客戶應當繼續傳送請求的其餘部分。（HTTP 1.1新）
101 Switching Protocols 伺服器將遵從客戶的請求轉換到另外一種協議（HTTP 1.1新）
200 OK 一切正常，對GET和POST請求的應答文件跟在後面。
201 Created 伺服器已經建立了文件，Location頭給出了它的URL。
202 Accepted 已經接受請求，但處理尚未完成。
203 Non-Authoritative Information 文件已經正常地返回，但一些應答頭可能不正確，因為使用的是文件的拷貝（HTTP 1.1新）。
204 No Content 沒有新文件，瀏覽器應該繼續顯示原來的文件。如果使用者定期地重新整理頁面，而Servlet可以確定使用者文件足夠新，這個狀態程式碼是很有用的。
205 Reset Content 沒有新的內容，但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容（HTTP 1.1新）。
206 Partial Content 客戶傳送了一個帶有Range頭的GET請求，伺服器完成了它（HTTP 1.1新）。
300 Multiple Choices 客戶請求的文件可以在多個位置找到，這些位置已經在返回的文件內列出。如果伺服器要提出優先選擇，則應該在Location應答頭指明。
301 Moved Permanently 客戶請求的文件在其他地方，新的URL在Location頭中給出，瀏覽器應該自動地訪問新的URL。
302 Found 類似於301，但新的URL應該被視為臨時性的替代，而不是永久性的。注意，在HTTP1.0中對應的狀態資訊是“Moved Temporatily”。
出現該狀態程式碼時，瀏覽器能夠自動訪問新的URL，因此它是一個很有用的狀態程式碼。
注意這個狀態程式碼有時候可以和301替換使用。例如，如果瀏覽器錯誤地請求http://host/~user（缺少了後面的斜槓），有的伺服器返回301，有的則返回302。
嚴格地說，我們只能假定只有當原來的請求是GET時瀏覽器才會自動重定向。請參見307。

303 See Other 類似於301/302，不同之處在於，如果原來的請求是POST，Location頭指定的重定向目標文件應該通過GET提取（HTTP 1.1新）。
304 Not Modified 客戶端有緩衝的文件併發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文件）。伺服器告訴客戶，原來緩衝的文件還可以繼續使用。
305 Use Proxy 客戶請求的文件應該通過Location頭所指明的代理伺服器提取（HTTP 1.1新）。
307 Temporary Redirect 和302（Found）相同。許多瀏覽器會錯誤地響應302應答進行重定向，即使原來的請求是POST，即使它實際上只能在POST請求的應答是303時 才能重定向。由於這個原因，HTTP 1.1新增了307，以便更加清除地區分幾個狀態程式碼：當出現303應答時，瀏覽器可以跟隨重定向的GET和POST請求；如果是307應答，則瀏覽器只能跟隨對GET請求的重定向。（HTTP 1.1新）
400 Bad Request 請求出現語法錯誤。
401 Unauthorized 客戶試圖未經授權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭，瀏覽器據此顯示使用者名稱字/密碼對話方塊，然後在填寫合適的Authorization頭後再次發出請求。
403 Forbidden 資源不可用。伺服器理解客戶的請求，但拒絕處理它。通常由於伺服器上檔案或目錄的許可權設定導致。
404 Not Found 無法找到指定位置的資源。這也是一個常用的應答。
405 Method Not Allowed 請求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）對指定的資源不適用。（HTTP 1.1新）
406 Not Acceptable 指定的資源已經找到，但它的MIME型別和客戶在Accpet頭中所指定的不相容（HTTP 1.1新）。
407 Proxy Authentication Required 類似於401，表示客戶必須先經過代理伺服器的授權。（HTTP 1.1新）
408 Request Timeout 在伺服器許可的等待時間內，客戶一直沒有發出任何請求。客戶可以在以後重複同一請求。（HTTP 1.1新）
409 Conflict 通常和PUT請求有關。由於請求和資源的當前狀態相沖突，因此請求不能成功。（HTTP 1.1新）
410 Gone 所請求的文件已經不再可用，而且伺服器不知道應該重定向到哪一個地址。它和404的不同在於，返回407表示文件永久地離開了指定的位置，而404表示由於未知的原因文件不可用。（HTTP 1.1新）
411 Length Required 伺服器不能處理請求，除非客戶傳送一個Content-Length頭。（HTTP 1.1新）
412 Precondition Failed 請求頭中指定的一些前提條件失敗（HTTP 1.1新）。
413 Request Entity Too Large 目標文件的大小超過伺服器當前願意處理的大小。如果伺服器認為自己能夠稍後再處理該請求，則應該提供一個Retry-After頭（HTTP 1.1新）。
414 Request URI Too Long URI太長（HTTP 1.1新）。
416 Requested Range Not Satisfiable 伺服器不能滿足客戶在請求中指定的Range頭。（HTTP 1.1新）
500 Internal Server Error 伺服器遇到了意料不到的情況，不能完成客戶的請求。
501 Not Implemented 伺服器不支援實現請求所需要的功能。例如，客戶發出了一個伺服器不支援的PUT請求。
502 Bad Gateway 伺服器作為閘道器或者代理時，為了完成請求訪問下一個伺服器，但該伺服器返回了非法的應答。
503 Service Unavailable 伺服器由於維護或者負載過重未能應答。例如，Servlet可能在資料庫連線池已滿的情況下返回503。伺服器返回503時可以提供一個Retry-After頭。
504 Gateway Timeout 由作為代理或閘道器的伺服器使用，表示不能及時地從遠端伺服器獲得應答。（HTTP 1.1新）
505 HTTP Version Not Supported 伺服器不支援請求中所指明的HTTP版本。（HTTP 1.1新）

移動app上的困難

一段時間內的連線複用對PC端瀏覽器的體驗幫助很大，因為大部分的請求在集中在一小段時間以內。但對移動app來說，成效不大，app端的請求比較分散且時間跨度相對較大。所以移動端app一般會從應用層尋求其它解決方案，長連線方案或者偽長連線方案：

方案一：基於tcp的長連結

現在越來越多的移動端app都會建立一條自己的長連結通道，通道的實現是基於tcp協議。基於tcp的socket程式設計技術難度相對複雜很多，而且需要自己制定協議，但帶來的回報也很大。資訊的上報和推送變得更及時，在請求量爆發的時間點還能減輕伺服器壓力（http短連線模式會頻繁的建立和銷燬連線）。不止是IM app有這樣的通道，像淘寶這類電商類app都有自己的專屬長連線通道了。現在業界也有不少成熟的方案可供選擇了，google的protobuf就是其中之一。

方案二：http long-polling（推送）

客戶端在初始狀態就會發送一個polling（輪尋）請求到伺服器，伺服器並不會馬上返回業務資料，而是等待有新的業務資料產生的時候再返回。所以連線會一直被保持，一旦結束馬上又會發起一個新的polling請求，如此反覆，所以一直會有一個連線被保持。伺服器有新的內容產生的時候，並不需要等待客戶端建立一個新的連線。做法雖然簡單，但有些難題需要攻克才能實現穩定可靠的業務框架：
和傳統的http短連結相比，長連線會在使用者增長的時候極大的增加伺服器壓力，
移動端網路環境複雜，像wifi和4g的網路切換，進電梯導致網路臨時斷掉等，這些場景都需要考慮怎麼重建健康的連線通道。這種polling的方式穩定性並不好，需要做好資料可靠性的保證，比如重發和ack機制（ACK是一個對資料包的確認，當正確收到資料包後，接收端會發送一個ACk給傳送端，裡面會說明對那個資料包進行確認，每個資料包裡都會有一個序列號，如果收到的資料包有誤，或錯序，還會申請重發，NAK是一個否定的回答，ACK是確定回答，這樣保證資料的正確傳輸）。

polling的response有可能會被中間代理cache住，要處理好業務資料的過期機制。long-polling方式還有一些缺點是無法克服的，比如每次新的請求都會帶上重複的header資訊，還有資料通道是單向的，主動權掌握在server這邊，客戶端有新的業務請求的時候無法及時傳送。

方案三：http streaming

同long-polling不同的是，server並不會結束初始的streaming請求，而是持續的通過這個通道返回最新的業務資料。顯然這個資料通道也是單向的。streaming是通過在server response的頭部裡增加”Transfer Encoding: chunked”來告訴客戶端後續還會有新的資料到來。除了和long－polling相同的難點之外，streaming還有幾個缺陷：有些代理伺服器會等待伺服器的response結束之後才會將結果推送到請求客戶端。對於streaming這種永遠不會結束的方式來說，客戶端就會一直處於等待response的過程中。業務資料無法按照請求來做分割，所以客戶端每收到一塊資料都需要自己做協議解析，也就是說要做自己的協議定製。streaming不會產生重複的header資料。

方案四：web socket

WebSocket和傳統的tcp socket連線相似，也是基於tcp協議，提供雙向的資料通道。WebSocket優勢在於提供了message的概念，比基於位元組流的tcp socket使用更簡單，同時又提供了傳統的http所缺少的長連線功能。不過WebSocket相對較新，2010年才起草，並不是所有的瀏覽器都提供了支援。各大瀏覽器廠商最新的版本都提供了支援。

HTTP2.0

使用HTTP2.o測試便可看出HTTP2.0比之前的協議在效能上有很大的提升。下面總結了HTTP2.0協議的幾個特性。

多路複用 (Multiplexing)

多路複用允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息。在 HTTP/1.1 協議中瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量限制。超過限制數目的請求會被阻塞。這也是為何一些站點會有多個靜態資源 CDN 域名的原因之一，拿 Twitter 為例，http://twimg.com，目的就是變相的解決瀏覽器針對同一域名的請求限制阻塞問題。而 HTTP/2 的多路複用(Multiplexing) 則允許同時通過單一的 HTTP/2 連線發起多重的請求-響應訊息。因此 HTTP/2 可以很容易的去實現多流並行而不用依賴建立多個 TCP 連線，HTTP/2 把 HTTP 協議通訊的基本單位縮小為一個一個的幀，這些幀對應著邏輯流中的訊息。並行地在同一個 TCP 連線上雙向交換訊息。

二進位制分幀

HTTP/2在 應用層(HTTP/2)和傳輸層(TCP or UDP)之間增加一個二進位制分幀層。在不改動 HTTP/1.x 的語義、方法、狀態碼、URI 以及首部欄位的情況下, 解決了HTTP1.1 的效能限制，改進傳輸效能，實現低延遲和高吞吐量。在二進位制分幀層中， HTTP/2 會將所有傳輸的資訊分割為更小的訊息和幀（frame）,並對它們採用二進位制格式的編碼 ，其中 HTTP1.x 的首部資訊會被封裝到 HEADER frame，而相應的 Request Body 則封裝到 DATA frame 裡面。

HTTP/2 通訊都在一個連線上完成，這個連線可以承載任意數量的雙向資料流。在過去， HTTP 效能優化的關鍵並不在於高頻寬，而是低延遲。TCP 連線會隨著時間進行自我調諧，起初會限制連線的最大速度，如果資料成功傳輸，會隨著時間的推移提高傳輸的速度。這種調諧則被稱為 TCP 慢啟動。由於這種原因，讓原本就具有突發性和短時性的 HTTP 連線變的十分低效。HTTP/2 通過讓所有資料流共用同一個連線，可以更有效地使用 TCP 連線，讓高頻寬也能真正的服務於 HTTP 的效能提升。

這種單連線多資源的方式，減少服務端的連結壓力,記憶體佔用更少,連線吞吐量更大；而且由於 TCP 連線的減少而使網路擁塞狀況得以改善，同時慢啟動時間的減少,使擁塞和丟包恢復速度更快。

首部壓縮（Header Compression）

HTTP/1.1並不支援 HTTP 首部壓縮，為此 SPDY 和 HTTP/2 應運而生， SPDY 使用的是通用的DEFLATE 演算法，而 HTTP/2 則使用了專門為首部壓縮而設計的 HPACK 演算法。

服務端推送（Server Push）

服務端推送是一種在客戶端請求之前傳送資料的機制。在 HTTP/2 中，伺服器可以對客戶端的一個請求傳送多個響應。Server Push 讓 HTTP1.x 時代使用內嵌資源的優化手段變得沒有意義；如果一個請求是由你的主頁發起的，伺服器很可能會響應主頁內容、logo 以及樣式表，因為它知道客戶端會用到這些東西。這相當於在一個 HTML 文件內集合了所有的資源，不過與之相比，伺服器推送還有一個很大的優勢：可以快取！也讓在遵循同源的情況下，不同頁面之間可以共享快取資源成為可能。

HTTPS

HTTP協議傳輸的資料都是未加密的，也就是明文的，因此使用HTTP協議傳輸隱私資訊非常不安全。為了保證這些隱私資料能加密傳輸，於是網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的資料進行加密，從而就誕生了HTTPS。現在的HTTPS都是用的TLS協議，但是由於SSL出現的時間比較早，並且依舊被現在瀏覽器所支援，因此SSL依然是HTTPS的代名詞。

HTTPS在傳輸資料之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸資料的密碼資訊。TLS/SSL協議不僅僅是一套加密傳輸的協議，TLS/SSL中使用了非對稱加密，對稱加密以及HASH演算法。握手過程的簡單描述如下：

1.瀏覽器將自己支援的一套加密規則傳送給網站。

2.網站從中選出一組加密演算法與HASH演算法，並將自己的身份資訊以證書的形式發回給瀏覽器。證書裡面包含了網站地址，加密公鑰，以及證書的頒發機構等資訊。

3.獲得網站證書之後瀏覽器要做以下工作：
a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。
b) 如果證書受信任，或者是使用者接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
c) 使用約定好的HASH計算握手訊息，並使用生成的隨機數對訊息進行加密，最後將之前生成的所有資訊傳送給網站。

4.網站接收瀏覽器發來的資料之後要做以下的操作：
a) 使用自己的私鑰將資訊解密取出密碼，使用密碼解密瀏覽器發來的握手訊息，並驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手訊息，傳送給瀏覽器。

5.瀏覽器解密並計算握手訊息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通訊資料將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密。

這裡瀏覽器與網站互相傳送加密的握手訊息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密資料。其中非對稱加密演算法用於在握手過程中加密生成的密碼，對稱加密演算法用於對真正傳輸的資料進行加密，而HASH演算法用於驗證資料的完整性。由於瀏覽器生成的密碼是整個資料加密的關鍵，因此在傳輸的時候使用了非對稱加密演算法對其加密。非對稱加密演算法會生成公鑰和私鑰，公鑰只能用於加密資料，因此可以隨意傳輸，而網站的私鑰用於對資料進行解密，所以網站都會非常小心的保管自己的私鑰，防止洩漏。

TLS握手過程中如果有任何錯誤，都會使加密連線斷開，從而阻止了隱私資訊的傳輸。正是由於HTTPS非常的安全，攻擊者無法從中找到下手的地方，於是更多的是採用了假證書的手法來欺騙客戶端，從而獲取明文的資訊。預設HTTP的埠號為80，HTTPS的埠號為443。