1. URL

1.1 基本概念

（Uniform Resource Locator,統(tǒng)一資源定位符）

protocol :// hostname[:port] / path / [;parameters][?query]#fragment

protocol協(xié)議類型
指的是當(dāng)前請(qǐng)求的協(xié)議類型，這里是https協(xié)議，常見的協(xié)議還有如下：

• file 資源是本地計(jì)算機(jī)上的文件。格式file:///，注意后邊應(yīng)是三個(gè)斜杠。
• ftp 通過 FTP訪問資源。格式 FTP://
• gopher 通過 Gopher 協(xié)議訪問該資源。
• http 通過 HTTP 訪問該資源。 格式 HTTP://
• https 通過安全的 HTTPS 訪問該資源。 格式 HTTPS://
• mailto 資源為電子郵件地址，通過 SMTP 訪問。 格式 mailto:
• MMS 通過 支持MMS流媒體協(xié)議的播放該資源。（代表軟件：Windows Media Player）格式 MMS://
• ed2k 通過 支持ed2k（專用下載鏈接）協(xié)議的P2P軟件訪問該資源。（代表軟件：電驢 格式 ed2k://)
• Flashget 通過 支持Flashget:（專用下載鏈接）協(xié)議的P2P軟件訪問該資源。（代表軟件：快車） 格式 Flashget://
• thunder 通過 支持thunder（專用下載鏈接）協(xié)議的P2P軟件訪問該資源。（代表軟件：迅雷 格式 thunder://

當(dāng)然我們自己也可以按照需求，自己定義自己的協(xié)議名，如常用到的移動(dòng)應(yīng)用開發(fā)原生和webview的h5交互，我們就會(huì)自定義一個(gè):bridge://xxxx來交互信息。還有在iOS中外部通過URLScheme跳轉(zhuǎn)到某個(gè)App，一般這個(gè)協(xié)議都是自己定義的，如跳轉(zhuǎn)到微信，是weixin://。

hostname（主機(jī)名）
是指存放資源的服務(wù)器的域名系統(tǒng)(DNS) 主機(jī)名或 IP 地址。有時(shí)，在主機(jī)名前也可以包含連接到服務(wù)器所需的用戶名和密碼（格式：username:password@hostname）。

port（端口號(hào)）
整數(shù)，可選，省略時(shí)使用方案的默認(rèn)端口，各種傳輸協(xié)議都有默認(rèn)的端口號(hào)，如http的默認(rèn)端口為80。https默認(rèn)443，ftp默認(rèn)：21。如果輸入時(shí)省略，則使用默認(rèn)端口號(hào)。有時(shí)候出于安全或其他考慮，可以在服務(wù)器上對(duì)端口進(jìn)行重定義，即采用非標(biāo)準(zhǔn)端口號(hào)，此時(shí)，URL中就不能省略端口號(hào)這一項(xiàng)。

path（路徑）
eg:http://www.itdecent.cn/p/f9afd709d447

1. 從域名的第一個(gè)/開始到最后一個(gè)/為止，是文件路徑的部分。/p/
2. 從域名最后一個(gè)/開始到?為止，是文件名部分；如果沒有?，則是從域名最后一個(gè)/開始到#為止，是文件名部分；如果沒有?和#，那么就從域名的最后一個(gè)/從開始到結(jié)束，都是文件名部分。本例中的文件名是f9afd709d447，文件名也不是一個(gè)URL的必須部分，如果沒有文件名，則使用默認(rèn)文件名。默認(rèn)的就是index，default 等

parameters
百度百科：這是用于指定特殊參數(shù)的可選項(xiàng)。暫時(shí)沒碰到

query(查詢參數(shù))
頁(yè)面加載請(qǐng)求數(shù)據(jù)是需要的參數(shù)，用“&”符號(hào)隔開，每個(gè)參數(shù)的名和值用“=”符號(hào)隔開。

fragment（錨部分）
#開始，字符串，用于指定網(wǎng)絡(luò)資源中的片斷。例如一個(gè)網(wǎng)頁(yè)中有多個(gè)名詞解釋，可使用fragment直接定位到某一名詞解釋。定位網(wǎng)頁(yè)滾動(dòng)的位置

1.2 URI 和 URL區(qū)別

URI（Uniform Resource Identifier，統(tǒng)一資源標(biāo)識(shí)符）和URL（Uniform Resource Locator,統(tǒng)一資源定位符）的區(qū)別是，一個(gè)是表示身份，一個(gè)是表示位置的。
舉個(gè)通俗的例子，可以這樣理解，我們每個(gè)人都用名字，這個(gè)名字就可以看成URI，標(biāo)識(shí)著我這個(gè)人。同時(shí)我們每個(gè)人都用家庭住址，通過這個(gè)住址能找到我們，這個(gè)家庭住址就相當(dāng)URL。

2. http協(xié)議（超文本傳輸協(xié)議）

1.概念

http是通用URL，來獲取數(shù)據(jù)的網(wǎng)絡(luò)協(xié)議。它是應(yīng)用層協(xié)議，因?yàn)槭侵付丝蛻舳朔?wù)器，所以在傳輸層是基于TCP的。特點(diǎn)：

• 簡(jiǎn)單快速 客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。

• 通用性強(qiáng) HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。

• 無連接 每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

• 無狀態(tài) 每次處理請(qǐng)求都是獨(dú)立的，一次搞完，沒有所謂的分包之類的。如果又缺失的字段，只能全部重新請(qǐng)求

2.協(xié)議格式

image.png

image.png

2.1 http報(bào)文格式

請(qǐng)求報(bào)文.png

響應(yīng)報(bào)文.png

HTTP消息由客戶端到服務(wù)器的請(qǐng)求和服務(wù)器到客戶端的響應(yīng)組成。請(qǐng)求消息和響應(yīng)消息都是由:
1. 開始行（對(duì)于請(qǐng)求消息，開始行就是請(qǐng)求行，對(duì)于響應(yīng)消息，開始行就是狀態(tài)行）
2. 消息報(bào)頭（可選）
3. 空行（只有CRLF的行）
4. 消息正文（可選）組成

2.1.1開始行

對(duì)于請(qǐng)求消息，開始行就是請(qǐng)求行，對(duì)于響應(yīng)消息，開始行就是狀態(tài)行

• 請(qǐng)求行--方法
  HTTP1.0定義了三種請(qǐng)求方法： GET, POST 和 HEAD方法。
  HTTP1.1新增了五種請(qǐng)求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
  
  image.png

這里重點(diǎn)說一下get和post方法區(qū)別：
1、GET提交的數(shù)據(jù)會(huì)放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中
2、GET提交的數(shù)據(jù)大小有限制（因?yàn)闉g覽器對(duì)URL的長(zhǎng)度有限制），而POST方法提交的數(shù)據(jù)沒有限制
3、GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。
4、GET方式提交數(shù)據(jù)，會(huì)帶來安全問題，比如一個(gè)登錄頁(yè)面，通過GET方式提交數(shù)據(jù)時(shí)，用戶名和密碼將出現(xiàn)在URL上，如果頁(yè)面可以被緩存或者其他人可以訪問這臺(tái)機(jī)器，就可以從歷史記錄獲得該用戶的賬號(hào)和密碼.
GET數(shù)據(jù)包

image.png

POST數(shù)據(jù)包

POST數(shù)據(jù)包.png

可以發(fā)現(xiàn), POST傳入的參數(shù)，會(huì)把參數(shù)放在請(qǐng)求報(bào)文body（請(qǐng)求體）中，而GET是直接放在請(qǐng)求行中的url。

• 請(qǐng)求行--URL
  這里第一個(gè)URL的/后面的東西

• 請(qǐng)求行--Version
  http版本，都是http/1.1

• 請(qǐng)求行--CRLF
  就是一行結(jié)束的標(biāo)識(shí)符，就是/r/n

• 狀態(tài)行--http/1.1
  標(biāo)識(shí)協(xié)議版本號(hào)

• 狀態(tài)行--狀態(tài)碼
  HTTP協(xié)議的狀態(tài)碼由3位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別，共有5中類別：

1xx: 指示信息--表示請(qǐng)求已接收，繼續(xù)處理
2xx: 成功--表示請(qǐng)求已被成功接收、理解、接受
3xx: 重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
4xx: 客戶端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)
5xx: 服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

常見錯(cuò)誤碼：
200 OK                        //客戶端請(qǐng)求成功
400 Bad Request               //客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解
401 Unauthorized              //請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用 
403 Forbidden                 //服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)
404 Not Found                 //請(qǐng)求資源不存在，eg：輸入了錯(cuò)誤的URL
500 Internal Server Error     //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
503 Server Unavailable        //服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常

2.1.2消息報(bào)頭

HTTP消息報(bào)頭包括通用報(bào)頭、請(qǐng)求報(bào)頭、響應(yīng)報(bào)頭、實(shí)體報(bào)頭。
報(bào)頭的組成都是: 鍵 + : + 空格 + 值 CRLF。配置了這個(gè)請(qǐng)求或響應(yīng)的基本屬性

• 通用報(bào)頭
通用報(bào)頭指用于所有的請(qǐng)求和響應(yīng)消息，但并不用于被傳輸?shù)?code>實(shí)體，只用于傳輸?shù)南?/code>。

通用報(bào)頭字段名（部分）	解釋	示例
Cache-Control	用于指定緩存指令，緩存指令是單向的（響應(yīng)中出現(xiàn)的緩存指令在請(qǐng)求中未必會(huì)出現(xiàn)），且是獨(dú)立的（一個(gè)消息的緩存指令不會(huì)影響另一個(gè)消息處理的緩存機(jī)制）。請(qǐng)求時(shí)的緩存指令包括：no-cache（用于指示請(qǐng)求或響應(yīng)消息不能緩存）、no-store、max-age、max-stale、min-fresh、only-if-cached;響應(yīng)時(shí)的緩存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.	為了指示IE瀏覽器（客戶端）不要緩存頁(yè)面，服務(wù)器端的JSP程序可以編寫如下：response.sehHeader("Cache-Control","no-cache")。這句代碼將在發(fā)送的響應(yīng)消息中設(shè)置普通報(bào)頭域：Cache-Control:no-cache
Connection	表示是否需要持久連接。（HTTP 1.1默認(rèn)進(jìn)行持久連接）。或者指定“close”選項(xiàng)，通知服務(wù)器，在響應(yīng)完成后，關(guān)閉連接	Connection: keep-alive
Date	表示消息產(chǎn)生的日期和時(shí)間	Date: Tue, 15 Nov 2010 08:12:31 GMT
Upgrade	向服務(wù)器指定某種傳輸協(xié)議以便服務(wù)器進(jìn)行轉(zhuǎn)換（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Via	通知中間網(wǎng)關(guān)或代理服務(wù)器地址，通信協(xié)議	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	關(guān)于消息實(shí)體的警告信息	Warn: 199 Miscellaneous warning

關(guān)于通用報(bào)頭字段代表的含義，參考：https://blog.csdn.net/alexshi5/article/details/80379086

• 請(qǐng)求報(bào)頭
請(qǐng)求報(bào)頭允許客戶端向服務(wù)器端傳遞請(qǐng)求的附加信息以及客戶端自身的信息。

請(qǐng)求報(bào)頭字段名（部分）	解釋	示例
Accept	用于指定客戶端接受哪些類型的響應(yīng)信息。比如Accept：image/gif，表明客戶端希望接受GIF圖象格式的資源；而Accept：text/html，表明客戶端希望接受html文本; Accept: image/gif,text/html，表明客戶希望接受gif圖像或html文本	Accept: text/plain, text/html,/
Accept-Charset	請(qǐng)求報(bào)頭域用于指定客戶端接受的字符集。如果在請(qǐng)求消息中沒有設(shè)置這個(gè)域，缺省是任何字符集都可以接受。	Accept-Charset:iso-8859-1,gb2312
Accept-Encoding	請(qǐng)求報(bào)頭域類似于Accept,但是它是用于指定可接受的內(nèi)容編碼。如果請(qǐng)求消息中沒有設(shè)置這個(gè)域服務(wù)器假定客戶端對(duì)各種內(nèi)容編碼都可以接受。。	Accept-Encoding:gzip.deflate.
Accept-Language	請(qǐng)求報(bào)頭域類似于Accept，但是它是用于指定一種自然語(yǔ)言。如果請(qǐng)求消息中沒有設(shè)置這個(gè)報(bào)頭域，服務(wù)器假定客戶端對(duì)各種語(yǔ)言都可以接受。	Accept-Language: en,zh
Authorization	主要用于證明客戶端有權(quán)查看某個(gè)資源。當(dāng)瀏覽器訪問一個(gè)頁(yè)面時(shí)，如果收到服務(wù)器的響應(yīng)代碼為401（未授權(quán)），可以發(fā)送一個(gè)包含Authorization請(qǐng)求報(bào)頭域的請(qǐng)求，要求服務(wù)器對(duì)其進(jìn)行驗(yàn)證	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Host	（發(fā)送請(qǐng)求時(shí)，該報(bào)頭域是必需的）主要用于指定被請(qǐng)求資源的Internet主機(jī)和端口號(hào)，它通常從HTTP URL中提取出來的	HOST: restapi-test.ihaozhuo.com:82
User-Agent	我們上網(wǎng)登陸論壇的時(shí)候，往往會(huì)看到一些歡迎信息，其中列出了你的操作系統(tǒng)的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實(shí)際上，服務(wù)器應(yīng)用程序就是從User-Agent這個(gè)請(qǐng)求報(bào)頭域中獲取到這些信息。User-Agent請(qǐng)求報(bào)頭域允許客戶端將它的操作系統(tǒng)、瀏覽器和其它屬性告訴服務(wù)器。不過，這個(gè)報(bào)頭域不是必需的，如果我們自己編寫一個(gè)瀏覽器，不使用User-Agent請(qǐng)求報(bào)頭域，那么服務(wù)器端就無法得知我們的信息了。	user-agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Mobile Safari/537.36
Pragma	它是HTTP/1.1之前版本的歷史遺留字段，僅作為HTTP/1.0的向后兼容。如果所有的中間服務(wù)器都使用HTTP/1.1版本協(xié)議的話，那么直接使用Cache-Control:no-cache是最理想的，但所有的中間服務(wù)器使用的HTTP協(xié)議版本并不完全一致。因此，發(fā)送的請(qǐng)求會(huì)同時(shí)含有下面兩個(gè)字段。	Pragma: no-cache
From	該首部字段用來告知服務(wù)器使用代理的用戶的電子郵件地址。通常，使用目的就是為了顯示搜索引擎等用戶代理的負(fù)責(zé)人的電子郵件聯(lián)系方式。使用代理時(shí)，應(yīng)盡可能使用該字段，但有的代理可能會(huì)將電子郵件地址在User-Agent首部字段內(nèi)。	From: user@email.com
If-Match	形如If-xxx這種形式的請(qǐng)求首部字段，都可稱為條件請(qǐng)求，服務(wù)器接收到附帶條件的請(qǐng)求后，只有判斷指定條件為真時(shí)，才會(huì)執(zhí)行請(qǐng)求。	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-None-Match	該首部字段與If-Match的作用相反。	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	該首部字段用于確認(rèn)代理或客戶端擁有的本地資源的有效性。它會(huì)告知服務(wù)器在些字段指定的時(shí)間后資源發(fā)生了更新就處理該請(qǐng)求，如果請(qǐng)求的資源沒有更新過，則返回狀態(tài)碼304的響應(yīng)。	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-Unmodified-Since	該首部字段與If-Modified-Since的作用相反。	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-Range	該首部字段屬于附帶條件之一，它告訴服務(wù)器若指定的If-Range值（ETag值或時(shí)間）和請(qǐng)求資源的ETag值或時(shí)間相同時(shí)，則作為范圍請(qǐng)求處理。否則，返回全體資源。	If-Range:"123456"
Max-Forwards	通過Trace或Options的方法發(fā)送包含該首部字段的請(qǐng)求時(shí)，該字段以十進(jìn)制整數(shù)形式指定可經(jīng)過的服務(wù)器最大數(shù)目。服務(wù)器在往下一下服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求之前，會(huì)將該首部字段的值減1后重新賦值。當(dāng)值為0時(shí)，請(qǐng)求不再進(jìn)行轉(zhuǎn)發(fā)，而是直接返回響應(yīng)	Max-Forwards: 10
Proxy-Authorization	客戶端接收到從代理服務(wù)器發(fā)送過來的認(rèn)證質(zhì)詢時(shí)，客戶端會(huì)發(fā)送包含該首部字段的請(qǐng)求，以告知服務(wù)器認(rèn)證所需要的信息。	Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
Range	客戶端發(fā)送帶有該首部字段的請(qǐng)求可以指定服務(wù)器資源的范圍。接收到該首部字段的服務(wù)器，會(huì)在處理請(qǐng)求之后返回狀態(tài)碼為206 Partial Content的響應(yīng)，如果無法處理該范圍請(qǐng)求，則會(huì)返回狀態(tài)碼為200 OK的響應(yīng)及全部資源。	Range: bytes=500-999
Referer	先前網(wǎng)頁(yè)的地址，當(dāng)前請(qǐng)求網(wǎng)頁(yè)緊隨其后,即來路	Referer: http://www.zcmhi.com/archives/71.html
TE	該首部字段會(huì)告知服務(wù)器客戶端能夠處理響應(yīng)的傳輸編碼方式以及相對(duì)優(yōu)先級(jí)，它和Accept-Encoding的功能很像，但是TE只是用于傳輸編碼。首部字段TE除指定傳輸編碼之外，還可以指定伴隨trailer字段的分塊傳輸編碼的方式。這時(shí)需要把trailers賦值給該字段值。如下所示：TE: trailers	TE: trailers,deflate;q=0.5
Cookie	HTTP請(qǐng)求發(fā)送時(shí)，會(huì)把保存在該請(qǐng)求域名下的所有cookie值一起發(fā)送給web服務(wù)器。	Cookie: $Version=1; Skin=new;

• 響應(yīng)報(bào)頭
  響應(yīng)報(bào)頭允許服務(wù)器傳遞不能放在狀態(tài)行中的附加響應(yīng)信息，以及關(guān)于服務(wù)器的信息和對(duì)Request-URI所標(biāo)識(shí)的資源進(jìn)行下一步訪問的信息。

響應(yīng)頭字段名（部分）	解釋	示例
Server	響應(yīng)報(bào)頭域包含了服務(wù)器用來處理請(qǐng)求的軟件信息，標(biāo)識(shí)服務(wù)器那邊的一些信息。與User-Agent請(qǐng)求報(bào)頭域是相對(duì)應(yīng)的。
Location	響應(yīng)報(bào)頭域用于重定向接受者到一個(gè)新的位置。Location響應(yīng)報(bào)頭域常用在更換域名的時(shí)候。
WWW-Authorization	響應(yīng)報(bào)頭域必須被包含在401（未授權(quán)的）響應(yīng)消息中，客戶端收到401響應(yīng)消息時(shí)候，并發(fā)送Authorization報(bào)頭域請(qǐng)求服務(wù)器對(duì)其進(jìn)行驗(yàn)證時(shí)，服務(wù)端響應(yīng)報(bào)頭就包含該報(bào)頭域。	WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服務(wù)器對(duì)請(qǐng)求資源采用的是基本驗(yàn)證機(jī)制。

• 實(shí)體報(bào)頭
請(qǐng)求和響應(yīng)消息都可以傳送一個(gè)實(shí)體。一個(gè)實(shí)體由實(shí)體報(bào)頭域和實(shí)體正文組成，但并不是說實(shí)體報(bào)頭域和實(shí)體正文要在一起發(fā)送，可以只發(fā)送實(shí)體報(bào)頭域。實(shí)體報(bào)頭定義了關(guān)于實(shí)體正文（eg：有無實(shí)體正文）和請(qǐng)求所標(biāo)識(shí)的資源的元信息。

實(shí)體報(bào)頭字段名（部分）	解釋	示例
Content-Type	指明發(fā)送給接收者的實(shí)體正文的媒體類型	Content-Type:text/html;charset=ISO-8859-1 或 Content-Type:text/html;charset=GB2312
Content-Encoding	實(shí)體報(bào)頭域被用作媒體類型的修飾符，它的值指示了已經(jīng)被應(yīng)用到實(shí)體正文的附加內(nèi)容的編碼，因?yàn)橐@得Content-Type報(bào)頭域中所引用的媒體類型，必須采用相應(yīng)的解碼機(jī)制。Content-Encoding這樣用于記錄文檔的壓縮方法	Content-Encoding：gzip
Content-Language	資源所用的自然語(yǔ)言。沒有設(shè)置該域則認(rèn)為實(shí)體內(nèi)容將提供給所有的語(yǔ)言閱讀者。
Content-Length	實(shí)體報(bào)頭域用于指明實(shí)體正文的長(zhǎng)度，以字節(jié)方式存儲(chǔ)的十進(jìn)制數(shù)字來表示
Last-Modified	用于指示資源的最后修改日期和時(shí)間
Expires	實(shí)體報(bào)頭域給出響應(yīng)過期的日期和時(shí)間。為了讓代理服務(wù)器或?yàn)g覽器在一段時(shí)間以后更新緩存中(再次訪問曾訪問過的頁(yè)面時(shí)，直接從緩存中加載，縮短響應(yīng)時(shí)間和降低服務(wù)器負(fù)載)的頁(yè)面，我們可以使用Expires實(shí)體報(bào)頭域指定頁(yè)面過期的時(shí)間。	eg：Expires：Thu，15 Sep 2006 16:23:12 GMT

2.1.3 單獨(dú)的空行（只有CRLF的行）

標(biāo)識(shí)報(bào)文頭的結(jié)束

2.1.4 實(shí)體正文

實(shí)體正文可有可無，取決于你的請(qǐng)求響應(yīng)的類型，如GET請(qǐng)求，請(qǐng)求報(bào)文就沒有實(shí)體正文，POST請(qǐng)求就有。還有響應(yīng)報(bào)文也可能沒有實(shí)體正文，如狀態(tài)碼status：401請(qǐng)求未經(jīng)授權(quán)。這時(shí)候就只有響應(yīng)頭，而沒有實(shí)體正文。

3.HTTPS

3.1,基本概念

基于HTTP協(xié)議，通過SSL或TLS提供加密處理數(shù)據(jù)、驗(yàn)證對(duì)方身份以及數(shù)據(jù)完整性保護(hù)。其中TLS升級(jí)版的SSL。是為網(wǎng)絡(luò)通信數(shù)據(jù)完整性的一種安全協(xié)議。TLS與SSL在傳輸層對(duì)網(wǎng)絡(luò)連接進(jìn)行加密。

分層.png

SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用協(xié)議之間

SSL(Secure Socket Layer)，為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸?shù)陌踩?，利用?shù)據(jù)加密技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸過程中不會(huì)被截取及竊聽。

SSL由從前的網(wǎng)景公司開發(fā) 有1.0,2.0,3.0三個(gè)版本，但現(xiàn)在只使用版本3.0。TLS是SSL的標(biāo)準(zhǔn)化后的產(chǎn)物
有1.0 1.1 1.2三個(gè)版本,默認(rèn)使用1.0，TLS1.0和SSL3.0幾乎沒有區(qū)別。事實(shí)上我們現(xiàn)在用的都是TLS，但因?yàn)闅v史上習(xí)慣了SSL這個(gè)稱呼，平常還是以SSL為多。

3.2 對(duì)稱加密/非對(duì)稱加密

3.2.1 對(duì)稱加密

同一個(gè)密鑰可以同時(shí)用作信息的加密和解密，這種加密方法稱為對(duì)稱加密。類似我們自然使用的鎖和鑰匙的關(guān)系，一把鑰匙可以上鎖也可以開鎖。

優(yōu)點(diǎn)：對(duì)稱加密算法的是算法公開、計(jì)算量小、加密速度快、加密效率高。
缺點(diǎn)：對(duì)稱加密算法的缺點(diǎn)是在數(shù)據(jù)傳送前，發(fā)送方和接收方必須商定好秘鑰，然后使雙方都能保存好秘鑰。其次如果一方的秘鑰被泄露，那么加密信息也就不安全了。另外，每對(duì)用戶每次使用對(duì)稱加密算法時(shí)，都需要使用其他人不知道的獨(dú)一秘鑰，這會(huì)使得收、發(fā)雙方所擁有的鑰匙數(shù)量巨大，密鑰管理成為雙方的負(fù)擔(dān)。

3.2.2 非對(duì)稱加密

和對(duì)稱加密相對(duì)，就是加密解密不在通過同一把鑰匙，而是兩把，一個(gè)公鑰，一個(gè)私鑰，他倆是一對(duì)！
很明顯公鑰是給別人用的，私鑰是給自己用的。

A和B通信，A生成一對(duì)密鑰公鑰和私鑰，A把公鑰給B，自己留有私鑰。這時(shí)候如果B給A發(fā)消息，就用A給B的公鑰加密，A收到消息后，就可以用自己的那個(gè)私鑰解密，就知道B給A發(fā)送的消息是啥了。

非對(duì)稱加密過程.png

常見非對(duì)稱交密算法：RSA

3.3 CA機(jī)構(gòu)

CA機(jī)構(gòu)是什么？CA機(jī)構(gòu)就是SSL證書審核簽發(fā)機(jī)構(gòu)，電子商務(wù)交易中備受信任的第三方，承擔(dān)檢驗(yàn)公鑰體系合法性的責(zé)任。
就是一些受信任的第三方機(jī)構(gòu)，類似于公證處，如果我們的網(wǎng)站在那邊公正過，他就給我發(fā)頒發(fā)數(shù)字證書CA。證書中包含了一個(gè)密鑰對(duì)（公鑰和私鑰）和所有者識(shí)別信息。數(shù)字證書被放到服務(wù)端，具有服務(wù)器身份驗(yàn)證和數(shù)據(jù)傳輸加密功能。?

3.4 Https傳輸過程

https訪問的過程.png

方便理解過程簡(jiǎn)化了，但基本流程是不變的，只是證書校驗(yàn)和對(duì)稱加密的密鑰生成方式復(fù)雜化的問題。具體過程參照https://mp.weixin.qq.com/s/UiGEzXoCn3F66NRz_T9crA。

1, 客戶端訪問服務(wù)端，地址是https的網(wǎng)址
2, 服務(wù)端必須要有一套CA數(shù)字證書，可以自己制作，也可以向組織申請(qǐng)。自己制作的，也可以通過https訪問，但是會(huì)顯示不信任，有的瀏覽器會(huì)彈框。正規(guī)CA機(jī)構(gòu)申請(qǐng)的，就是可信任的！
3，服務(wù)端有了一個(gè)可信任的CA證書，就有了一個(gè)SSL公鑰(CA公鑰)，一個(gè)SSL私鑰(CA私鑰)。一般在服務(wù)器配置支持https的時(shí)候，這兩個(gè)密鑰都需要配置。當(dāng)客戶端前來訪問的時(shí)候，服務(wù)器就會(huì)先把CA證書/CA公鑰發(fā)送給客戶端。
4, 客戶端解析證書，這部分工作是由客戶端的TLS來完成的，首先會(huì)驗(yàn)證證書是否有效，比如頒發(fā)機(jī)構(gòu)，過期時(shí)間等等，如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個(gè)隨機(jī)值比如123456作為一個(gè)明文密鑰。然后用CA公鑰證書對(duì)該123456這個(gè)明文密鑰進(jìn)行加密得到密文密鑰：abcde。
5, 客戶端發(fā)送密文密鑰abcde給服務(wù)端。
6, 服務(wù)端的到密文密鑰abcde，就用CA私鑰對(duì)其進(jìn)行解密，就可以得到明文密鑰：123456，用明文密鑰加密要發(fā)送的內(nèi)容?？梢姡?strong>密鑰的傳遞用的是非對(duì)稱加密。
7，客戶端收到這個(gè)內(nèi)容，因?yàn)樽约河忻艽a：123456，就直接可以進(jìn)行解密，得到正確的內(nèi)容。 可見：內(nèi)容的傳遞用的是對(duì)稱加密。

3.5 怎么保證保證服務(wù)器給客戶端下發(fā)的公鑰是真正的公鑰，而不是中間人偽造的公鑰呢？

中間人模式.png

Charles抓包工具能抓到https的包，就是利用了這個(gè)原理，配置了自己的一個(gè)CA證書，通信的時(shí)候客戶端代理Charles上，Charles作為中間人轉(zhuǎn)發(fā)我們的信息！

那如何防止了？這里就有了雙向驗(yàn)證
如上，Charles之所以能抓包，那是它偽裝成了真正的客戶端，這個(gè)真正的客戶端和服務(wù)端通信，而我們的客戶端是從Charles那邊拿到的信息。如果我們想杜絕這種情況，就需要不僅對(duì)服務(wù)端進(jìn)行校驗(yàn)，還需要對(duì)客戶端進(jìn)行校驗(yàn)。
所以：雙向驗(yàn)證本質(zhì)上和單向驗(yàn)證沒區(qū)別，上面的單向認(rèn)證是客戶端 check 服務(wù)端是否合法。雙向就是服務(wù)端 同時(shí) check 客戶端是否合法。

以下是引用內(nèi)容https://mp.weixin.qq.com/s/UiGEzXoCn3F66NRz_T9crA：

1、單向驗(yàn)證中，如果是你客戶端，你需要拿到服務(wù)器的證書，并放到你的信任庫(kù)中；如果是服務(wù)端，你要生成私鑰和證書，并將這兩個(gè)放到你的密鑰庫(kù)中，并且將證書發(fā)給所有客戶端。
2、雙向驗(yàn)證中，如果你是客戶端，你要生成客戶端的私鑰和證書，將它們放到密鑰庫(kù)中，并將證書發(fā)給服務(wù)端，同時(shí)，在信任庫(kù)中導(dǎo)入服務(wù)端的證書。如果你是服務(wù)端，除了在密鑰庫(kù)中保存服務(wù)器的私鑰和證書，還要在信任庫(kù)中導(dǎo)入客戶端的證書。
3、再次強(qiáng)調(diào)，使用單向驗(yàn)證還是雙向驗(yàn)證，是服務(wù)器決定的。
4、https的驗(yàn)證過程，不管是單向還是雙向，只有四步，網(wǎng)上很多關(guān)于https驗(yàn)證過程的文章中，寫了來來回回七八上十步。要真是這樣，訪問一個(gè)https地址，時(shí)間全花在了交互上了。

注意：
1，雙向驗(yàn)證，只是對(duì)客戶端身份進(jìn)行驗(yàn)證，驗(yàn)證過程和客戶端驗(yàn)證服務(wù)端的原理過程類似
2，客戶端如何標(biāo)識(shí)自己的身份是合法的了，也需要配置證書，生成公鑰，私鑰。這個(gè)證書在服務(wù)器那邊也是授信的，做到這一點(diǎn)，iOS開發(fā)中我們一般把服務(wù)器的證書給down下來導(dǎo)入到本地。也可以自己配置一個(gè)新的證書，然后到處p12文件，讓服務(wù)器那邊信任這個(gè)證書。

根據(jù)網(wǎng)絡(luò)資源總結(jié)，有紕漏，請(qǐng)指正，謝謝！

參考：
https://blog.csdn.net/xiaoming100001/article/details/81109617
https://mp.weixin.qq.com/s/UiGEzXoCn3F66NRz_T9crA