IOS 網絡協議（一）自簽名證書HTTPS文件上傳下載(上)

HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。 HTTP有稱爲：超文本傳輸協議（HTTP，HyperText Transfer Protocol)全部的WWW文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種經過計算機處理文本信息的方法，並稱之爲超文本（hypertext）,這成爲了HTTP超文本傳輸協議標準架構的發展根基。Ted Nelson組織協調萬維網協會（World Wide Web Consortium）和互聯網工程工做小組（Internet Engineering Task Force ）共同合做研究，最終發佈了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1。

HTTP有什麼做用？

主要功能：

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。

HTTP是客戶端瀏覽器或其餘程序與Web服務器之間的應用層通訊協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機須要經過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不只可用於Web訪問，也能夠用於其餘因特網/內聯網應用系統之間的通訊，從而實現各種應用資源超媒體訪問的集成。

咱們在瀏覽器的地址欄裏輸入的網站地址叫作URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址同樣，每一個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級連接時，URL就肯定了要瀏覽的地址。瀏覽器經過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。

HTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。經過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定端口（默認端口爲80）的HTTP請求。（咱們稱這個客戶端）叫用戶代理（user agent）。應答的服務器上存儲着（一些）資源，好比HTML文件和圖像。（咱們稱）這個應答服務器爲源服務器（origin server）。在用戶代理和源服務器中間可能存在多箇中間層，好比代理，網關，或者隧道（tunnels）。儘管TCP/IP協議是互聯網上最流行的應用，HTTP協議並無規定必須使用它和（基於）它支持的層。事實上，HTTP能夠在任何其餘互聯網協議上，或者在其餘網絡上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何可以提供這種保證的協議均可以被其使用。一般，由HTTP客戶端發起一個請求，創建一個到服務器指定端口（默認是80端口）的TCP鏈接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，好比"HTTP/1.1 200 OK"，和（響應的）消息，消息的消息體多是請求的文件、錯誤消息、或者其它一些信息。HTTP使用TCP而不是UDP的緣由在於（打開）一個網頁必須傳送不少數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。經過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。

HTTP 的主要特色?

基於請求/響應模型的協議。請求和響應必須成對，先有請求後有響應

http協議默認端口:80

簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。 5 .無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

HTTP協議有哪些主要版本？

版本	產生時間	內容	發展示狀
HTTP/0.9	1991年	不涉及數據包傳輸，規定客戶端和服務器之間通訊格式，只能GET請求	沒有做爲正式的標準
HTTP/1.0	1996年	傳輸內容格式不限制，增長PUT、PATCH、HEAD、 OPTIONS、DELETE命令	正式做爲標準
HTTP/1.1	1997年	持久鏈接(長鏈接)、節約帶寬、HOST域、管道機制、分塊傳輸編碼	2015年前使用最普遍
HTTP/2	2015年	多路複用、服務器推送、頭信息壓縮、二進制協議等	逐漸覆蓋市場

HTTP/0.9 :只接受GET一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。因爲該版本不支持POST方法，所以客戶端沒法向服務器傳遞太多信息。 HTTP/1.0 :第一個在通訊中指定的版本號，至今被普遍採用，特別是在代理服務器中。 HTTP/1.1 :當前版本號，持久鏈接被默認採用，並能很好地配合代理服務器工做。還支持以管道方式在同時發送多個請求，以便下降線路負載，提升傳輸速度。 HTTP/2.0 正在開發中······

HTTP/1.1與HTTP/1.0的區別？

主要區別：在同一個tcp的鏈接中能夠傳送多個HTTP請求和響應. 多個請求和響應能夠重疊，多個請求和響應能夠同時進行. 更加多的請求頭和響應頭(好比HTTP1.0沒有host的字段). 總之在HTTP/1.0中,大多實現爲每一個請求/響應交換使用新的鏈接。在HTTP/1.1中,一個鏈接可用於一次或屢次請求/響應交換,儘管鏈接可能因爲各類緣由被關閉。

persistent connection（持久鏈接） HTTP/1.0中，每對請求/ 響應都使用一個新的鏈接。 HTTP/1.1則支持持久鏈接（默認）。

Host域 HTTP/1.1在請求消息頭多一個Host域；HTTP/1.0 則沒有這個域，創建TCP鏈接的時候已經指定了IP地址，並且默認一個IP地址只對應一個主機名，IP地址上只有一個host。

帶寬優化 HTTP/1.1中在請求消息中引入了range頭域，它容許只請求資源的某個部分。在響應消息中Content-Range頭域聲明瞭返回的這部分對象的偏移值和長度。若是服務器相應地返回了對象所請求範圍的內容，則響應碼爲206（Partial Content），它能夠防止Cache將響應誤覺得是完整的一個對象。請求消息中若是包含比較大的實體內容，但不肯定服務器是否可以接收該請求（如是否有權限），此時若貿然發出帶實體的請求，若是被拒絕也會浪費帶寬。 HTTP/1.1加入了一個新的狀態碼100（Continue）。客戶端事先發送一個只帶頭域的請求，若是服務器由於權限拒絕了請求，就回送響應碼 401（Unauthorized）；若是服務器接收此請求就回送響應碼100，客戶端就能夠繼續發送帶實體的完整請求了。注意，HTTP/1.0的客戶端不支持100響應碼。節省帶寬資源的一個很是有效的作法就是壓縮要傳送的數據。Content-Encoding是對消息進行端到端（end-to-end）的編碼，它多是資源在服務器上保存的固有格式（如jpeg圖片格式）；在請求消息中加入Accept-Encoding頭域，它能夠告訴服務器客戶端可以解碼的編碼方式。而Transfer-Encoding是逐段式（hop-by-hop）的編碼，如Chunked編碼。在請求消息中加入TE頭域用來告訴服務器可以接收的transfer-coding方式。

請求方法和狀態碼 HTTP1.1增長了OPTIONS, PUT, DELETE, TRACE, CONNECT這些Request方法 HTTP/1.0中只定義了16個狀態響應碼，對錯誤或警告的提示不夠具體。HTTP/1.1引入了一個Warning頭域，增長對錯誤或警告信息的描述。在HTTP/1.1中新增了24個狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。

內容協商爲了知足互聯網使用不一樣母語和字符集的用戶，一些網絡資源有不一樣的語言版本（如中文版、英文版）。HTTP/1.0定義了內容協商（content negotiation）的概念，也就是說客戶端能夠告訴服務器本身能夠接收以何種語言（或字符集）表示的資源。例如若是服務器不能明確客戶端須要何種類型的資源，會返回300（Multiple Choices），幷包含一個列表，用來聲明該資源的不一樣可用版本，而後客戶端在請求消息中包含Accept-Language和Accept- Charset頭域指定須要的版本。

狀態碼 100～199：信息狀態碼，表示成功接收請求，要求客戶端繼續提交下一次請求才能完成整個處理過程 100（continue）繼續發送 200～299：成功狀態碼，表示成功接收請求並已完成整個處理過程，經常使用200（OK）成功接收 300～399：重定向狀態碼，例如，請求的資源已經移動一個新地址，經常使用30二、307和304 400～499：客戶端的請求有錯誤，經常使用404（Not Found），403（Fobidden） 500～599：服務器端出現錯誤，經常使用 500

HTTP1.1 解決了HTTP1.0的相關痛點？

一個WEB站點天天可能要接收到上百萬的用戶請求，爲了提升系統的效率，HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。

這也形成了一些性能上的缺陷，例如，一個包含有許多圖像的網頁文件中並無包含真正的圖像數據內容，而只是指明瞭這些圖像的URL地址，當WEB瀏覽器訪問這個網頁文件時，瀏覽器首先要發出針對該網頁文件的請求，當瀏覽器解析WEB服務器返回的該網頁文檔中的HTML內容時，發現其中的img圖像標籤後，瀏覽器將根據img標籤中的src屬性所指定的URL地址再次向服務器發出下載圖像數據的請求。

顯然，訪問一個包含有許多圖像的網頁文件的整個過程包含了屢次請求和響應，每次請求和響應都須要創建一個單獨的鏈接，每次鏈接只是傳輸一個文檔和圖像，上一次和下一次請求徹底分離。即便圖像文件都很小，可是客戶端和服務器端每次創建和關閉鏈接倒是一個相對比較費時的過程，而且會嚴重影響客戶機和服務器的性能。當一個網頁文件中包含Applet，JavaScript文件，CSS文件等內容時，也會出現相似上述的狀況。

爲了克服HTTP 1.0的這個缺陷，HTTP 1.1支持持久鏈接，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲。一個包含有許多圖像的網頁文件的多個請求和應答能夠在一個鏈接中傳輸，但每一個單獨的網頁文件的請求和應答仍然須要使用各自的鏈接。HTTP 1.1還容許客戶端不用等待上一次請求結果返回，就能夠發出下一次請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間。基於HTTP 1.1協議的客戶機與服務器的信息交換過程。

可見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報文格式

HTTP請求報文

HTTP請求報文組成：請求行+請求頭+請求體

請求行（HTTP請求報文的第一行）請求行由方法字段、URL字段和HTTP協議版本字段。其中，方法字段嚴格區分大小寫，當前HTTP協議中的方法都是大寫，方法字段以下介紹以下：

方法字段 ①GET:請求獲取Request-URI(URI:通用資源標識符,URL是其子集，URI注重的是標識，而URL強調的是位置，能夠將URL當作原始的URI),所標識的資源 ②POST：在Request-URI所標識的資源後附加新的數據；支持HTML表單提交，表單中有用戶添入的數據，這些數據會發送到服務器端，由服務器存儲至某位置（例如發送處理程序） ③HEAD:請求Request-URI所標識的資源響應消息報頭，HEAD方法能夠在響應時不返回消息體。 ④PUT：與GET相反，請求服務器存儲一個資源，並用Request-URI作爲其標識；例如發佈系統。 ⑤DELETE：請求刪除URL指向的資源 ⑥OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項 ⑦TRACE：跟蹤請求要通過的防火牆、代理或網關等，主要用於測試或診斷 ⑧CONNECT保留未來使用

URL 一個完整的包括類型、主機名和可選路徑名的統一資源引用名，如：www.example.com/path/to/fil…

請求頭部：位於請求行的下面請求報文中常見的標頭有： Connetion標頭（鏈接管理）、Host標頭（指定請求資源的主機）、Range標頭（請求實體的字節範圍）、User-Agent標頭（包含發出請求的用戶信息）、Accept標頭（首選的媒體類型）、Accept-Language(首選的天然語言)

HTTP首部： 6.1 通用首部：請求和響應均可以使用的； Connection：定義C/S之間關於請求/響應的有關選項對於http/1.0, Connection: keep-alive Via: 顯示了報文通過的中間節點 Cache-Control: 緩存指示 6.2 實體首部：用於指定實體屬性實體主體用於POST方法中。用戶向Web服務器提交表單數據的時候，須要使用POST方法，此時主體中包含用戶添寫在表單的各個屬性字段的值，當Web服務器收到POST方法的HTTP請求報文後，能夠從實體中取出須要的屬性字段的值。也就是說，當用戶經過Web瀏覽器向Web服務器發送請求時,Web瀏覽器會根據用戶的具體請求來選擇不一樣的HTTP請求方法，再將相應的URL和HTTP協議版本及相關的標頭填入頭部行中，如果POST方法，還會將相關的表單數據填入實體主體中，產生一個HTTP請求報文，而後將這個報文發送給Web服務器。

請求報文分析：

常見請求頭屬性： Location: 資源的新位置 Allow: 容許對此資源使用的請求方法一、內容首部： Content-Encoding：支持的編碼 Content-Language：支持的天然語言 Content-Length：文本長度 Content-Location：資源所在位置 Content-Range：在整個資源中此實體表示的字節範圍 Content-Type：主體的對象類型二、緩存首部： ETag: 實體標籤 Expires: 過時期限 Last-Modified: 上一次的修改時間請求首部： Host: 請求的主機名和端口號，虛擬主機環境下用於不一樣的虛擬主機 Referer：指明瞭請求當前資源的原始資源的URL User-Agent: 用戶代理，使用什麼工具發出的請求一、Accept首部：用戶標明客戶本身更傾向於支持的能力 Accept: 指明服務器能發送的媒體類型 Accept-Charset: 支持使用的字符集 Accept-Encoding: 支持使用的編碼方式 Accept-Language: 支持使用語言二、條件請求首部： Expect: 告訴服務器可以發送來哪些媒體類型 If-Modified-Since: 是否在指定時間以來修改過此資源 If-None-Match:若是提供的實體標記與當前文檔的實體標記不符，就獲取此文檔跟安全相關的請求首部： Authorization: 客戶端提交給服務端的認證數據，如賬號和密碼 Cookie: 客戶端發送給服務器端身份標識

請求字段 1.Accept 做用：瀏覽器客戶端用來告訴服務端能接受什麼類型的響應。例如： Accept: text/html 表明瀏覽器能夠接受服務器回發html文檔,若是服務器沒法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable) 通配符 * 表明任意類型。如： Accept: / 表明瀏覽器能夠處理全部類型

Accept-Encoding 做用：瀏覽器客戶端用來告訴服務器能接受什麼編碼格式，包括字符編碼、壓縮方式等例如：Accept-Encoding:gzip, deflate

Accept-Language 做用：瀏覽器客戶端用來告訴服務器能接受什麼語言。例如：Accept-Language:zh-CN,zh;q=0.9

Connection 做用：客戶端或服務端用來告訴對方當前tcp鏈接的狀態，默認爲keep-alive，即長鏈接。例如：Connection:close 在響應結束後關閉鏈接

Host 做用：指定要請求的資源所在的主機和端口，一般從url裏獲取。這個字段是必需的。例如：咱們在地址欄輸入：www.baidu.com Host:www.baidu.com

Referer 做用：瀏覽器客戶端用來告訴服務器這個請求是從哪一個頁面連接過來的，即請求來源。

User-Agent 做用：告訴服務器，客戶端使用的操做系統、瀏覽器版本和名稱例如：Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 另外，有些屬性不必定會有但比較常見：

Cache-Control 做用：客戶端瀏覽器用來判斷是否須要用本地緩存。默認值爲private；經常使用值有private、no-cache、max-age、must-revalidate。具體場景舉例： a.打開新窗口時值爲private、no-cache、must-revalidate，那麼打開新窗口訪問時都會從新訪問服務器。而若是指定了max-age值（單位爲秒），那麼在此值內的時間裏就不會從新訪問服務器，例如： Cache-control: max-age=5(表示當訪問此網頁後的5秒內再次訪問不會去服務器) b.在地址欄回車值爲private或must-revalidate則只有第一次訪問時會訪問服務器，之後就再也不訪問。值爲no-cache，那麼每次都會訪問。值爲max-age，則在過時以前不會重複訪問。 c.按後退按扭值爲private、must-revalidate、max-age，則不會重訪問，值爲no-cache，則每次都重複訪問 d.按刷新按扭不管爲什麼值，都會重複訪問 2.Cookie 做用：客戶端瀏覽器用來存儲一些用戶信息以便讓服務器辨別用戶身份的（大多數須要登陸的網站上面會比較常見），好比用戶名和密碼，sessionId等。

If-Modify-Since 做用：把瀏覽器端緩存頁面的最後修改時間（精確到秒）發送到服務器去，服務器會把這個時間與服務器上實際文件的最後修改時間進行對比。若是時間一致，那麼返回304 ，客戶端就直接使用本地緩存文件。若是時間不一致，就會返回200和新的文件內容以及新的修改時間(Last-Modify)。客戶端接到以後，會丟棄舊文件，把新文件緩存起來，並顯示在瀏覽器中。例如：Wed, 30 May 2018 08:32:42 GMT

If-None-Match 做用：If-None-Match和ETag一塊兒工做，工做原理是在HTTP Response中添加ETag信息。當用戶再次請求該資源時，將在HTTP Request 中加入If-None-Match信息(ETag的值)。若是服務器驗證資源的ETag沒有改變（該資源沒有更新），將返回一個304狀態告訴客戶端使用本地緩存文件。不然將返回200狀態和新的資源和Etag. 使用這樣的機制將提升網站的性能。例如: If-None-Match: W/"3119-1437038474000" 注意：If-Modify-Since和If-None-Match均可以給服務器用來判斷所請求的文件距離上次訪問之間是否被修改過，不過If-Modify-Since只能精確到秒，而If-None-Match只要文件修改過就會變化。 Etag的使用場景： 1.有些文件須要頻繁更新，可是文件內容並無變化。 2.同一文件存儲在多臺web服務器中，用戶請求在多臺之間輪詢。

響應報文

HTTP響應報文一樣也分爲三部分，有狀態行、首部行、實體

狀態行:HTTP響應報文的第一行狀態行包括三個字段：協議版本、狀態碼與緣由短語。

狀態碼： 1xx：這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。 2xx: 這一類型的狀態碼，表明請求已成功被服務器接收、理解、並接受。 3xx: 這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的Location域中指明。 4xx: 這類的狀態碼錶明客戶端類的錯誤 5xx: 服務器類的錯誤

常見狀態碼：

響應首部

響應字段響應首部（首部行）：位於響應報文狀態行以後 Date標頭：消息產生的時間 Age標頭:（從最初建立開始）響應持續時間 Server標頭: 向客戶端標明服務器程序名稱和版本 ETage標頭：不透明驗證者 Location標頭：URL備用的位置 Content-Length標頭：實體的長度 Content-Tyep標頭：實體的媒體類型協商首部： Accept-Ranges: 對當前資源來說，服務器所可以接受的範圍類型 Vary: 首部列表，服務器會根據列表中的內容挑選出最適合的版本發送給客戶端跟安全相關的響應首部： Set-Cookie: 服務器端在某客戶端第一次請求時發給令牌 WWW-Authentication: 質詢，即要求客戶提供賬號和密碼

實體：位於首部行以後實體包含了Web客戶端請求的對象。Content-Length標頭及Content-Type標頭用於計算實體的位置、數據類型和數據長度。當Web服務器接收到Web客戶端的請求報文後，對HTTP請求報文進行解析，並將Web客戶端的請求的對象取出打包，經過HTTP響應報文將數據傳回給Web客戶端，若是出現錯誤則返回包含對應錯誤的錯誤代碼和錯誤緣由的HTTP響應報文。

2.2 HTTPS 的一些基本概念

什麼是HTTPS

HTTPS實際就是HTTP + SSL，就是在HTTP協議的基礎上增長了SSL安全加密傳輸。《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP。HTTPS是一種經過計算機網絡進行安全通訊的傳輸協議，經由HTTP進行通訊，利用SSL/TLS創建全信道，加密數據包。HTTPS使用的主要目的是提供對網站服務器的身份認證，同時保護交換數據的隱私與完整性。

TLS是傳輸層加密協議，前身是SSL協議，由網景公司1995年發佈，有時候二者不區分。

HTTPS的特色

內容加密：採用混合加密技術，中間者沒法直接查看明文內容

驗證身份：經過證書認證客戶端訪問的是本身的服務器

保護數據完整性：防止傳輸的內容被中間人冒充或者篡改

咱們能夠對比HTTP抓包分析

HTTP抓包以下：

HTTPS抓包：

經過抓包能夠看到HTTPS中數據不是明文傳輸。HTTPS主要經過RSA混合加密，使用RSA加密客戶端產生的隨機祕鑰，服務器端獲得客戶端的祕鑰，雙方就可使用這個隨機祕鑰進行對稱加密傳輸。

混合加密：結合非對稱加密和對稱加密技術。客戶端使用對稱加密生成密鑰對傳輸數據進行加密，而後使用非對稱加密的公鑰再對祕鑰進行加密，因此網絡上傳輸的數據是被祕鑰加密的密文和用公鑰加密後的祕密祕鑰，所以即便被黑客截取，因爲沒有私鑰，沒法獲取到加密明文的祕鑰，便沒法獲取到明文數據。

數字摘要：經過單向hash函數對原文進行哈希，將需加密的明文「摘要」成一串固定長度(如128bit)的密文，不一樣的明文摘要成的密文其結果老是不相同，一樣的明文其摘要一定一致，而且即便知道了摘要也不能反推出明文。

數字簽名技術：數字簽名創建在公鑰加密體制基礎上，是公鑰加密技術的另外一類應用。它把公鑰加密技術和數字摘要結合起來，造成了實用的數字簽名技術。

經過加密後能夠作到: 收方可以證明發送方的真實身份；發送方過後不可否認所發送過的報文；收方或非法者不能僞造、篡改報文

HTTPS 加密，解密流程

HTTPS對比HTTP的區別

https協議須要到CA申請證書，通常免費證書較少，於是須要必定費用。(原來網易官網是http，而網易郵箱是https。)

http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

http的鏈接很簡單，是無狀態的。Https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。(無狀態的意思是其數據包的發送、傳輸和接收都是相互獨立的。無鏈接的意思是指通訊雙方都不長久的維持對方的任何信息。)

HTTPS的優勢

使用Https協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器。

Https協議是由SSL+Http協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、修改，確保數據的完整性。

Https是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

HTTPS的缺點

Https協議握手階段比較費時，會使頁面的加載時間延長近。

Https鏈接緩存不如Http高效，會增長數據開銷，甚至已有的安全措施也會所以而受到影響；

SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。

Https協議的加密範圍也比較有限。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行。

HTTPS SSL加密創建鏈接過程

以下圖：

過程詳解：

①客戶端的瀏覽器向服務器發送請求，並傳送客戶端SSL 協議的版本號，加密算法的種類，產生的隨機數，以及其餘服務器和客戶端之間通信所須要的各類信息。

②服務器向客戶端傳送SSL 協議的版本號，加密算法的種類，隨機數以及其餘相關信息，同時服務器還將向客戶端傳送本身的證書。

③客戶端利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過時，發行服務器證書的CA 是否可靠，發行者證書的公鑰可否正確解開服務器證書的「發行者的數字簽名」，服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過，通信將斷開；若是合法性驗證經過，將繼續進行第四步。

④用戶端隨機產生一個用於通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。

⑤若是服務器要求客戶的身份認證（在握手過程當中爲可選），用戶能夠創建一個隨機數而後對其進行數據簽名，將這個含有簽名的隨機數和客戶本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。

⑥若是服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的CA 是否可靠，發行CA 的公鑰可否正確解開客戶證書的發行CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗若是沒有經過，通信馬上中斷；若是驗證經過，服務器將用本身的私鑰解開加密的「預主密碼」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。

⑦服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於SSL 協議的安全數據通信的加解密通信。同時在SSL 通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。

⑧客戶端向服務器端發出信息，指明後面的數據通信將使用的步驟. ⑦中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。

⑨服務器向客戶端發出信息，指明後面的數據通信將使用的步驟⑦中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。

⑩SSL 的握手部分結束，SSL 安全通道的數據通信開始，客戶和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。

2.3 HTTPS 與HTTP的區別

一、https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

3. HTTPS 通信中SSL處理流程

3.1 SSL創建鏈接過程

鏈接過程：

client向server發送請求https://baidu.com，而後鏈接到server的443端口，發送的信息主要是隨機值1和客戶端支持的加密算法。

server接收到信息以後給予client響應握手信息，包括隨機值2和匹配好的協商加密算法，這個加密算法必定是client發送給server加密算法的子集。

隨即server給client發送第二個響應報文是數字證書。服務端必需要有一套數字證書，能夠本身製做，也能夠向組織申請。區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。傳送證書，這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間、服務端的公鑰，第三方證書認證機構(CA)的簽名，服務端的域名信息等內容。

客戶端解析證書，這部分工做是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。若是證書沒有問題，那麼就生成一個隨即值（預主祕鑰）。

客戶端認證證書經過以後，接下來是經過隨機值一、隨機值2和預主祕鑰組裝會話祕鑰。而後經過證書的公鑰加密會話祕鑰。

傳送加密信息，這部分傳送的是用證書加密後的會話祕鑰，目的就是讓服務端使用祕鑰解密獲得隨機值一、隨機值2和預主祕鑰。

服務端解密獲得隨機值一、隨機值2和預主祕鑰，而後組裝會話祕鑰，跟客戶端會話祕鑰相同。

客戶端經過會話祕鑰加密一條消息發送給服務端，主要驗證服務端是否正常接受客戶端加密的消息。

一樣服務端也會經過會話祕鑰加密一條消息回傳給客戶端，若是客戶端可以正常接受的話代表SSL層鏈接創建完成了。

怎麼保證保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人僞造的公鑰呢？
證書如何安全傳輸，被掉包了怎麼辦？

4. HTTPS 中使用的自簽名證書生成，配置

數字證書內容

包括了加密後服務器的公鑰、權威機構的信息、服務器域名，還有通過CA私鑰簽名以後的證書內容（通過先經過Hash函數計算獲得證書數字摘要，而後用權威機構私鑰加密數字摘要獲得數字簽名)，簽名計算方法以及證書對應的域名。

驗證證書安全性過程

當客戶端收到這個證書以後，使用本地配置的權威機構的公鑰對證書進行解密獲得服務端的公鑰和證書的數字簽名，數字簽名通過CA公鑰解密獲得證書信息摘要。

而後證書籤名的方法計算一下當前證書的信息摘要，與收到的信息摘要做對比，若是同樣，表示證書必定是服務器下發的，沒有被中間人篡改過。由於中間人雖然有權威機構的公鑰，可以解析證書內容並篡改，可是篡改完成以後中間人須要將證書從新加密，可是中間人沒有權威機構的私鑰，沒法加密，強行加密只會致使客戶端沒法解密，若是中間人強行亂修改證書，就會致使證書內容和證書籤名不匹配。

第三方攻擊者可否讓本身的證書顯示出來的信息也是服務端呢？

(假裝服務端同樣的配置）顯然這個是不行的，由於當第三方攻擊者去CA那邊尋求認證的時候CA會要求其提供例如域名的whois信息、域名管理郵箱等證實你是服務端域名的擁有者，而第三方攻擊者是沒法提供這些信息因此他就是沒法騙CA他擁有屬於服務端的域名

中間人攻擊（MITM攻擊）

中間人攻擊（MITM攻擊）是指，黑客攔截並篡改網絡中的通訊數據。又分爲被動MITM和主動MITM，被動MITM只竊取通訊數據而不修改，而主動MITM不但能竊取數據，還會篡改通訊數據。最多見的中間人攻擊經常發生在公共wifi或者公共路由上。

HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用 SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行

HTTPS的一些缺點

SSL證書須要購買申請，功能越強大的證書費用越高

SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展能夠部分解決這個問題，可是比較麻煩，並且要求瀏覽器、操做系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。

根據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增長10%到20%的耗電。

HTTPS鏈接緩存不如HTTP高效，流量成本高。

HTTPS鏈接服務器端資源佔用高不少，支持訪客多的網站須要投入更大的成本。

HTTPS協議握手階段比較費時，對網站的響應速度有影響，影響用戶體驗。比較好的方式是採用分而治之，相似12306網站的主頁使用HTTP協議，有關於用戶信息等方面使用HTTPS。

爲啥使用自簽名證書

這個主要是專業機構認證的CA證書費用很高，通常須要5千美金一年。不少公司承受不了這樣的費用

CA認證證書，客戶端不須要作任何處理就能夠訪問，根HTTP同樣使用，可是自簽名證書須要本身實現安全認證後，信任後才能使用。

蘋果自2017年後要求全部HTTP通信必須走HTTPS方式，不然不予審覈經過。

對於嵌入式設備和App的通信使用自簽名證書比較靈活一點。

自簽證書相對申請CA證書，流程更簡單

自簽證書一樣能夠對數據進行加密

自簽證書的有效期能夠設置很長，免去續簽的麻煩

自簽證書更方便測試，好比說你想生成多少個不一樣服務器ip的均可以

SSL協議提供的服務主要有哪些？

1）認證用戶和服務器，確保數據發送到正確的客戶機和服務器 2）加密數據以防止數據中途被竊取 3）維護數據的完整性，確保數據在傳輸過程當中不被改變

SSL證書的做用?

SSL證書是數字證書的一種，相似於駕駛證、護照和營業執照的電子副本。

SSL證書的兩大做用：數據加密和身份認證

SSL 證書遵照 SSL協議，經過在客戶端瀏覽器和Web服務器之間創建一條SSL安全通道

一個有效、可信的 SSL 數字證書包括一個公共密鑰和一個私用密鑰。公共密鑰用於加密信息，私用密鑰用於解譯加密的信息。所以，瀏覽器指向一個安全域時，SSL 將同步確認服務器和客戶端，並建立一種加密方式和一個惟一的會話密鑰。它們能夠啓動一個保證消息的隱私性和完整性的安全會話。