HTTP協(xié)議是移動(dòng)端開(kāi)發(fā)中最常使用到的協(xié)議；客戶(hù)端的接口請(qǐng)求费韭、網(wǎng)頁(yè)內(nèi)容加載等都通過(guò)該協(xié)議完成數(shù)據(jù)傳輸别垮；這篇文章記錄HTTP協(xié)議相關(guān)的基礎(chǔ)知識(shí)內(nèi)容，并會(huì)補(bǔ)充一些與HTTP協(xié)議相關(guān)的其它網(wǎng)絡(luò)知識(shí)晶府；

• 協(xié)議介紹
• 關(guān)聯(lián)的網(wǎng)絡(luò)知識(shí)（TCP桂躏、IP、DNS等）
• HTTP首部與響應(yīng)狀態(tài)碼
• HTTPS通信安全

1川陆、協(xié)議介紹

HTTP是一種無(wú)狀態(tài)剂习、無(wú)長(zhǎng)連接（不同于Socket等）的客戶(hù)端與服務(wù)端之間的通信協(xié)議；

• 無(wú)狀態(tài)：HTTP協(xié)議本身不保存通信的狀態(tài)较沪，也就是說(shuō)所有的請(qǐng)求與響應(yīng)在協(xié)議層面上都不會(huì)被記錄鳞绕；
  但是在使用HTTP協(xié)議的很多應(yīng)用中，都希望能記錄一些狀態(tài)信息（比如在登錄后希望能記住登錄的狀態(tài)尸曼，在請(qǐng)求新的頁(yè)面時(shí)不需要重新去登錄）们何；為了解決這個(gè)問(wèn)題，引入了cookie技術(shù)控轿；
• 無(wú)長(zhǎng)連接：HTTP在客戶(hù)端與服務(wù)端的通信過(guò)程中冤竹，不保持長(zhǎng)連接；數(shù)據(jù)的更新必須通過(guò)“請(qǐng)求->響應(yīng)”這種模式完成茬射，服務(wù)端不能主動(dòng)推送更新數(shù)據(jù)給客戶(hù)端鹦蠕；
  為了解決這一問(wèn)題，出現(xiàn)了Ajax在抛、Comet钟病、SPDY、全雙工通信的WebSocket等技術(shù)彌補(bǔ)這一缺陷刚梭，這些都是基于HTTP擴(kuò)展出來(lái)的技術(shù)肠阱；

2、與HTTP關(guān)聯(lián)的網(wǎng)絡(luò)知識(shí)（TCP望浩、IP辖所、DNS）

我們?cè)诿嬖嚨倪^(guò)程中，經(jīng)常會(huì)被問(wèn)道什么是“三次握手”等一些和網(wǎng)絡(luò)有關(guān)的基礎(chǔ)知識(shí)磨德，這本身并不屬于HTTP協(xié)議內(nèi)容缘回；但HTTP協(xié)議需要這些更低層的網(wǎng)絡(luò)模塊的支持才能實(shí)現(xiàn)通信吆视；接下來(lái)看看HTTP是如何與這些低層網(wǎng)絡(luò)模塊完成協(xié)作的；

我們先通過(guò)下面這張圖看一下計(jì)算機(jī)網(wǎng)絡(luò)的分層酥宴，和網(wǎng)絡(luò)通信過(guò)程中的數(shù)據(jù)包的傳遞流向啦吧，實(shí)際通信過(guò)程中可能存在更多的中間路由器轉(zhuǎn)發(fā)：

網(wǎng)絡(luò)通信分層.png

通過(guò)一些不同的網(wǎng)絡(luò)設(shè)備（包括集線(xiàn)器、交換機(jī)拙寡、路由器等）把接入到互聯(lián)網(wǎng)內(nèi)的主機(jī)連接在一起授滓，以便讓這些主機(jī)實(shí)現(xiàn)互相通信；實(shí)現(xiàn)通信除了需要有物理設(shè)備連接外，還需要制定一些協(xié)議來(lái)完成數(shù)據(jù)的傳輸過(guò)程，這本身是一個(gè)非常復(fù)雜的過(guò)程宋税，因此對(duì)整個(gè)網(wǎng)絡(luò)通信按不同的功能劃分進(jìn)行了網(wǎng)絡(luò)分層继准；

分層的好處是可以方便網(wǎng)絡(luò)的維護(hù)與擴(kuò)展，只要制定好跨層之間的通信接口，在具體層的內(nèi)部可以自由的進(jìn)行擴(kuò)展更新；同時(shí)分層也降低了實(shí)現(xiàn)的復(fù)雜度，不同層只需要關(guān)注自己的那部分功能就好和橙，在網(wǎng)絡(luò)需要擴(kuò)展時(shí)不需要對(duì)整個(gè)網(wǎng)絡(luò)結(jié)構(gòu)進(jìn)行修改；

• 物理層與數(shù)據(jù)鏈路層：提供數(shù)據(jù)傳輸?shù)奈锢砭€(xiàn)路支持造垛，還有部分協(xié)議和簡(jiǎn)單的數(shù)據(jù)驗(yàn)證功能魔招；其中集線(xiàn)器工作在物理層，交換機(jī)工作在數(shù)據(jù)鏈路層五辽；

• 網(wǎng)絡(luò)層：也叫“網(wǎng)際層”办斑、“IP層”，負(fù)責(zé)連接不同的子網(wǎng)絡(luò)奔脐，企業(yè)或者一些機(jī)構(gòu)的內(nèi)部網(wǎng)絡(luò)通過(guò)網(wǎng)絡(luò)層俄周，接入到互聯(lián)網(wǎng)中；這一層通過(guò)IP協(xié)議實(shí)現(xiàn)把數(shù)據(jù)包傳送給目標(biāo)主機(jī)髓迎，內(nèi)部還有很多具體協(xié)議做支持（包括路由選擇峦朗、ARP地址解析協(xié)議等）；路由器工作在這一層排龄；

• 運(yùn)輸層：負(fù)責(zé)數(shù)據(jù)的可靠傳輸與交付波势；從應(yīng)用層過(guò)來(lái)的數(shù)據(jù)包一般比較大，并不適合在互聯(lián)網(wǎng)中傳輸橄维；在運(yùn)輸層首先會(huì)把接收到的數(shù)據(jù)包進(jìn)行分割尺铣，把大的數(shù)據(jù)包分割成很多小的數(shù)據(jù)包，并對(duì)分割后的數(shù)據(jù)包進(jìn)行編號(hào)争舞；在目標(biāo)主機(jī)上通過(guò)運(yùn)輸層把接收到的數(shù)據(jù)包按編號(hào)重新組合后交付給上層凛忿；TCP與UDP協(xié)議工作在這一層；

1竞川、UDP不提供可靠傳輸店溢，只做盡最大可能的數(shù)據(jù)交付工作叁熔；

2、TCP協(xié)議提供可靠傳輸服務(wù)床牧，也就是在傳輸過(guò)程中會(huì)對(duì)丟失的數(shù)據(jù)包進(jìn)行重傳荣回；上面說(shuō)的“三次握手”就是TCP協(xié)議中的內(nèi)容，其主要目的就是為了保障可靠傳輸服務(wù)戈咳，除了三次握手TCP還有一些其他方式保證可靠傳輸服務(wù)心软；

三次握手是指：發(fā)送端在發(fā)送一個(gè)數(shù)據(jù)包時(shí)會(huì)對(duì)這個(gè)數(shù)據(jù)包帶上SYN（TCP的標(biāo)志）標(biāo)志，接收端在接收到這個(gè)數(shù)據(jù)包后會(huì)返回一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包給發(fā)送端著蛙，客戶(hù)端在接收到SYN/ACK數(shù)據(jù)包后就知道服務(wù)端已經(jīng)接受到了數(shù)據(jù)删铃，在發(fā)送一個(gè)帶有ACK標(biāo)志的數(shù)據(jù)包給接收端，表示握手結(jié)束册踩；中間有任何一次握手?jǐn)嚅_(kāi)了泳姐，這個(gè)數(shù)據(jù)包都需要重傳；

三次握手.png

這里可以考慮一下為什么是三次握手暂吉，而不是兩次或四次；如果只有兩次握手缎患，接收端為了避免發(fā)送端重傳一個(gè)數(shù)據(jù)包慕的，在收到SYN數(shù)據(jù)包后需要發(fā)送SYN/ACk數(shù)據(jù)包，告訴發(fā)送端我已經(jīng)收到了這個(gè)數(shù)據(jù)包挤渔；但接收端并不知道發(fā)送端是否已經(jīng)收到了SYN/ACK數(shù)據(jù)包肮街，因此它會(huì)認(rèn)為客戶(hù)端可能不知道它已經(jīng)接收到數(shù)據(jù)包，所以它可能會(huì)不停地發(fā)送SYN/ACK數(shù)據(jù)包告訴發(fā)送端我已經(jīng)收到了判导，所以需要發(fā)送端在發(fā)送一個(gè)ACK數(shù)據(jù)包嫉父，告訴接收端我已經(jīng)知道你收到了這個(gè)數(shù)據(jù)包，這次握手可以結(jié)束了眼刃；在接受端收到ACK之后绕辖，就知道這個(gè)數(shù)據(jù)包已經(jīng)完成了，因此就可以結(jié)束握手了擂红；

• 應(yīng)用層：這一層主要是向用戶(hù)提供各種不同服務(wù)的網(wǎng)絡(luò)協(xié)議仪际，其中DNS和HTTP都是工作在這一層；
  DNS（域名解析服務(wù)）提供把域名解析到IP地址的服務(wù)昵骤；計(jì)算機(jī)都有自己的IP地址和MAC地址树碱，在IP層轉(zhuǎn)發(fā)數(shù)據(jù)包時(shí)會(huì)使用這兩個(gè)地址進(jìn)行路由選擇；但是這兩個(gè)地址并不符合人的記憶習(xí)慣变秦，所以在標(biāo)識(shí)主機(jī)時(shí)通過(guò)使用域名來(lái)方便理解（比如baidu.com等）成榜；DNS就是提供把域名解析成IP或通過(guò)IP反查域名的服務(wù)的；

3蹦玫、HTTP首部與響應(yīng)狀態(tài)碼

3.1赎婚、HTTP協(xié)議用于客戶(hù)端與服務(wù)端之間的通信刘绣；

客戶(hù)端發(fā)起對(duì)資源的請(qǐng)求，服務(wù)端負(fù)責(zé)處理請(qǐng)求并返回客戶(hù)端請(qǐng)求的資源惑淳；通過(guò)請(qǐng)求和響應(yīng)的交互完成通信额港；下面兩張圖分別展示了請(qǐng)求和響應(yīng)的報(bào)文格式：

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

請(qǐng)求報(bào)文中主要包括三個(gè)部分，分別是“請(qǐng)求行”歧焦、“報(bào)文首部信息”移斩、“報(bào)文主體內(nèi)容”；“請(qǐng)求行”和“首部信息”統(tǒng)稱(chēng)為報(bào)文首部绢馍，在報(bào)文首部與報(bào)文主體之間通過(guò)空行（CR+LF）來(lái)分割向瓷；

• 請(qǐng)求行：包括請(qǐng)求方法、請(qǐng)求的URI舰涌、和HTTP協(xié)議版本信息
• 報(bào)文首部信息：請(qǐng)求報(bào)文首部信息一般包括幾種類(lèi)型的首部信息猖任，分別是“通用首部信息”、“請(qǐng)求首部信息”瓷耙、“實(shí)體首部信息”和“其他部分首部字段”朱躺；這些都是用來(lái)分別表示請(qǐng)求的各種條件和屬性的首部?jī)?nèi)容；
• 報(bào)文主體內(nèi)容：可以為空搁痛，也可以傳遞狀態(tài)數(shù)據(jù)給服務(wù)端（POST請(qǐng)求等）长搀；

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

響應(yīng)報(bào)文中對(duì)應(yīng)也包括三部分信息，分別是“響應(yīng)行（也叫狀態(tài)行）”鸡典、“報(bào)文首部信息”源请、“報(bào)文主體內(nèi)容”；其中“狀態(tài)行”和“首部信息”統(tǒng)稱(chēng)為響應(yīng)報(bào)文首部彻况，在報(bào)文首部與報(bào)文主體之間通過(guò)空行（CR+LF）來(lái)分割谁尸；

• 響應(yīng)行：包括HTTP協(xié)議版本，響應(yīng)狀態(tài)碼和解釋狀態(tài)碼對(duì)應(yīng)的原因短語(yǔ)纽甘；
• 報(bào)文首部信息：響應(yīng)報(bào)文首部信息也包括幾種類(lèi)型的首部信息良蛮，分別是“通用首部信息”、“響應(yīng)首部信息”贷腕、“實(shí)體首部信息”和“其他部分首部字段”背镇；這些都是用來(lái)分別表示響應(yīng)的各種條件和屬性的首部?jī)?nèi)容；
• 主體內(nèi)容：請(qǐng)求對(duì)應(yīng)的資源數(shù)據(jù)會(huì)在響應(yīng)報(bào)文的主體內(nèi)容中泽裳，可以為空（HEAD請(qǐng)求的響應(yīng)）瞒斩；

3.2、HTTP存在不同的請(qǐng)求方法涮总，請(qǐng)求的資源會(huì)根據(jù)不同的請(qǐng)求方法作出不同的響應(yīng)

常用的請(qǐng)求方法包括以下這些：

• GET：用來(lái)請(qǐng)求訪問(wèn)服務(wù)端的某個(gè)資源胸囱，指定的資源在經(jīng)過(guò)服務(wù)端解析后會(huì)返回響應(yīng)內(nèi)容（如果是文本，會(huì)直接返回瀑梗；如果是接口程序烹笔，會(huì)在程序執(zhí)行完后返回執(zhí)行的結(jié)果）裳扯；

• HEAD：HEAD方法與GET方法一樣，但是不返回報(bào)文的主體內(nèi)容（body為空）谤职；

• POST：POST請(qǐng)求可以傳輸請(qǐng)求的body信息饰豺；與GET的區(qū)別在于POST一般可以傳送數(shù)據(jù)量更大的數(shù)據(jù)體；

• PUT：PUT方法用來(lái)傳輸文件允蜈，在請(qǐng)求的報(bào)文主體中包含文件內(nèi)容冤吨，在指定的URL中保存文件；由于PUT方法本身不帶驗(yàn)證機(jī)制饶套，任何人都可以上傳文件漩蟆，所以一般使用的比較少；實(shí)際使用中可以通過(guò)POST請(qǐng)求實(shí)現(xiàn)文件上傳功能妓蛮；

• OPTION：OPTION方法用來(lái)確認(rèn)資源可以接收哪幾種請(qǐng)求方法怠李；通過(guò)返回可以知道這個(gè)資源可以使用哪幾種方式去請(qǐng)求；

• DELETE：DELETE方法用于刪除指定URL的文件蛤克，與PUT的作用相反捺癞；也不提供驗(yàn)證機(jī)制，所以一般也使用的比較少构挤；

• CONNECT：CONNECT方法要求與代理服務(wù)器通信時(shí)建立隧道翘簇，使用SSL進(jìn)行安全通信；

3.3儿倒、部分首部字段與Cookie技術(shù)的介紹

HTTP首部是HTTP報(bào)文的重要組成部分，他可以用來(lái)傳遞額外的重要信息（除報(bào)文主體之外的信息）呜笑；請(qǐng)求和響應(yīng)報(bào)文都會(huì)使用HTTP首部夫否，下面介紹幾種比較重要的首部字段；

• 通用首部字段：請(qǐng)求報(bào)文和響應(yīng)報(bào)文都會(huì)使用的首部叫胁；

Cache-Control：該首部的值用于控制緩存的行為凰慈，如“Cache-Control : private, max-age=0, no-cache”

Connection：該首部字段有兩個(gè)作用；
1驼鹅、控制代理服務(wù)器不再轉(zhuǎn)發(fā)首部字段微谓；如“ Connection : Upgrade”表示在第一個(gè)代理服務(wù)器收到數(shù)據(jù)包后，會(huì)把Upgrade首部字段刪除后输钩，在繼續(xù)往下轉(zhuǎn)發(fā)豺型；
2、管理持久鏈接买乃；這個(gè)作用主要用于優(yōu)化性能姻氨，減少創(chuàng)建和關(guān)閉網(wǎng)絡(luò)連接的開(kāi)銷(xiāo)；如“ Connection : Keep-Alive”剪验、“ Connection : Close”肴焊；

Transfer-Encoding：規(guī)定傳輸報(bào)文主體時(shí)的編碼方式前联，如“Transfer-Encoding : chunked”；

• 請(qǐng)求首部字段：請(qǐng)求報(bào)文使用的首部娶眷，補(bǔ)充請(qǐng)求的附件內(nèi)容似嗤，客戶(hù)端信息等內(nèi)容；

Accept：代表用戶(hù)代理能夠處理的媒體類(lèi)型和類(lèi)型的優(yōu)先級(jí)届宠，如“ Accept : text/html; q=0.3, application/xml”

Accept-Encoding：告知服務(wù)器用戶(hù)代理支持的內(nèi)容編碼和內(nèi)容編碼的優(yōu)先級(jí)順序烁落，如“Accept-Encoding : gzip, deflate”

Authorization：發(fā)送用戶(hù)的認(rèn)證信息給服務(wù)端；

Max-Forwords：指定可經(jīng)過(guò)的最大服務(wù)器數(shù)目席揽，如“Max-Forwords : 3”表示可經(jīng)過(guò)3個(gè)服務(wù)器顽馋，每經(jīng)過(guò)一個(gè)代理服務(wù)器字段值會(huì)減一然后繼續(xù)往下發(fā)送，到值為0時(shí)幌羞，服務(wù)器就會(huì)立即返回響應(yīng)寸谜；

Range：用于范圍請(qǐng)求獲取實(shí)體的部分資源；如“ Range : 200-400”可獲取200字節(jié)到400字節(jié)之間的數(shù)據(jù)属桦；

User-Agent：會(huì)發(fā)送創(chuàng)建請(qǐng)求的瀏覽器和用戶(hù)代理名稱(chēng)等信息給服務(wù)端熊痴，也可以自己寫(xiě)入一些系統(tǒng)信息；

• 響應(yīng)首部字段：響應(yīng)報(bào)文會(huì)使用的首部聂宾，補(bǔ)充了響應(yīng)的附件內(nèi)容果善；

Accept-Ranges：用于告知客戶(hù)端服務(wù)器是否能處理指定的范圍請(qǐng)求，存在兩個(gè)值系谐，能處理時(shí)為“Accept-Ranges : bytes”巾陕，不能處理時(shí)為“Accept-Ranges : none”；

ETag：用于標(biāo)識(shí)一個(gè)資源纪他，當(dāng)資源的內(nèi)容更新時(shí)鄙煤，URL沒(méi)有改變，但是ETag值對(duì)應(yīng)會(huì)發(fā)生改變茶袒；

Location：在需要重定向時(shí)梯刚，放入需要重定向訪問(wèn)的URL資源地址；

Server：返回客戶(hù)端當(dāng)前服務(wù)端的HTTP服務(wù)器信息薪寓；

WWW-Authenticate：告知客戶(hù)端訪問(wèn)指定資源時(shí)需要的認(rèn)證方法亡资，一般會(huì)和401狀態(tài)碼一起返回；

• 實(shí)體報(bào)文首部：針對(duì)報(bào)文實(shí)體信息的首部向叉，補(bǔ)充與實(shí)體有關(guān)的信息锥腻；

Allow：用于告知客戶(hù)端請(qǐng)求的資源能接受的訪問(wèn)方法，如“Allow : GET, HEAD, POST”植康；

Content-Encoding：告知客戶(hù)端服務(wù)器對(duì)實(shí)體主體的內(nèi)容編碼方式旷太，如“Content-Encoding : gzip”；

Content-Length：實(shí)體主體的內(nèi)容大小供璧；

Content-Type：說(shuō)明實(shí)體主體內(nèi)的對(duì)象的媒體類(lèi)型

Cookie的概念和與Cookie有關(guān)的首部字段
HTTP協(xié)議本身是無(wú)狀態(tài)的存崖，即協(xié)議本身不保存請(qǐng)求和響應(yīng)的任何信息，也就無(wú)法根據(jù)之前的狀態(tài)進(jìn)行下一次請(qǐng)求的處理睡毒；

但是很多實(shí)際的應(yīng)用場(chǎng)景中需要記錄一些用戶(hù)信息的狀態(tài)值来惧；比如一個(gè)需要登錄才能訪問(wèn)的網(wǎng)站，在完成登錄之后如果不記錄登錄的狀態(tài)演顾，在繼續(xù)訪問(wèn)一些其他頁(yè)面時(shí)供搀，又要去重新登錄，這顯得很不合理钠至；因此引入了Cookie技術(shù)解決此問(wèn)題葛虐；

服務(wù)端在首次接收到用戶(hù)的請(qǐng)求信息后，會(huì)根據(jù)用戶(hù)的信息生成一個(gè)可以唯一標(biāo)識(shí)用戶(hù)身份的字符串信息棉钧；然后通過(guò)響應(yīng)首部字段“Set-Cookie”把這一信息返回給客戶(hù)端屿脐，客戶(hù)端在接收到返回的Set-Cookie后，會(huì)把信息在本地保存下來(lái)宪卿，在下次請(qǐng)求時(shí)通過(guò)請(qǐng)求首部字段“Cookie”把這一信息帶上的诵，服務(wù)端在收到包含Cookie的請(qǐng)求后做一下驗(yàn)證就知道是之前用戶(hù)發(fā)送過(guò)來(lái)的請(qǐng)求，因此可以用來(lái)標(biāo)記用戶(hù)的身份信息佑钾；

3.4西疤、常見(jiàn)響應(yīng)狀態(tài)碼介紹

響應(yīng)狀態(tài)碼代表了HTTP請(qǐng)求的處理結(jié)果，可以表示服務(wù)端處理請(qǐng)求是否正常完成或者是出現(xiàn)了錯(cuò)誤休溶；常見(jiàn)的狀態(tài)碼一般分為2XX代赁、3XX、4XX兽掰、5XX等管跺；其中1XX的狀態(tài)碼比較少見(jiàn)，它代表請(qǐng)求正在處理禾进；

• 2XX狀態(tài)碼，請(qǐng)求成功的返回狀態(tài)碼
  200 OK：請(qǐng)求成功廉涕，結(jié)果正常返回泻云；
  204 NO Content：請(qǐng)求處理成功，但沒(méi)有數(shù)據(jù)內(nèi)容可以返回狐蜕，即返回的報(bào)文不包含主體內(nèi)容宠纯；一般用在只需要從客戶(hù)端發(fā)送信息，不需要服務(wù)端返回新數(shù)據(jù)的情況层释；
  206 Partial Content：表示處理范圍請(qǐng)求成功婆瓜，返回了指定范圍的數(shù)據(jù)內(nèi)容，可以用在下載功能的斷點(diǎn)續(xù)傳上；根據(jù)Content-Range首部字段指定范圍的大辛住个初；

• 3XX狀態(tài)碼，請(qǐng)求需要重定向
  301 Moved Permanently：資源被永久性的重定向猴蹂，以后訪問(wèn)資源需要使用資源的新URL地址院溺；
  302 Found：臨時(shí)性重定向，希望本次訪問(wèn)可以使用新指定的URL進(jìn)行磅轻；
  303 See Other：與302效果一樣珍逸，不同之處在于，明確指定這次請(qǐng)求應(yīng)該以GET方式訪問(wèn)新URL聋溜；
  304 Not Modified：當(dāng)發(fā)送了附帶條件的請(qǐng)求后谆膳，服務(wù)端允許訪問(wèn)；但因發(fā)生了請(qǐng)求未滿(mǎn)足條件的情況（附帶條件沒(méi)有被滿(mǎn)足）撮躁，直接返回了304（資源未更新漱病，可使用客戶(hù)端緩存）；304返回不包含任何主體內(nèi)容馒胆；

• 4XX狀態(tài)碼缨称，代表客戶(hù)端請(qǐng)求體發(fā)生了錯(cuò)誤
  400 Bad Request：請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤需要修改；
  401 Unauthorized：表示請(qǐng)求的資源需要使用通過(guò)HTTP認(rèn)證的認(rèn)證信息祝迂；如果已經(jīng)進(jìn)行過(guò)一次認(rèn)證睦尽，則表示認(rèn)證失敗型雳；
  403 Forbidden：訪問(wèn)請(qǐng)求的資源時(shí)被服務(wù)器拒絕了当凡；可以在響應(yīng)的主體中說(shuō)明拒絕原因；
  404 Not Found：在服務(wù)器上沒(méi)有找到請(qǐng)求的資源纠俭；或者是服務(wù)器拒絕請(qǐng)求但不想說(shuō)明理由時(shí)使用沿量；

• 5XX狀態(tài)碼，代表服務(wù)端處理請(qǐng)求時(shí)發(fā)生了錯(cuò)誤
  500 Internet Server Error：服務(wù)器在處理請(qǐng)求時(shí)發(fā)生了錯(cuò)誤冤荆，一般很有可能是服務(wù)端的程序bug朴则；
  503 Service Unavailable：服務(wù)端處于超負(fù)載或正在停機(jī)維護(hù)中，一般還會(huì)在響應(yīng)首部中帶上Retry-After指示可以恢復(fù)訪問(wèn)的時(shí)間值钓简；

4乌妒、 HTTPS通信安全

HTTPS（HTTP Secure）的主要作用是可以對(duì)通信方的身份進(jìn)行確認(rèn)，并在通信過(guò)程中對(duì)數(shù)據(jù)進(jìn)行加密以確保數(shù)據(jù)的安全性外邓，使用的是混合加密方式撤蚊；這些是通過(guò)SSL（安全套接層）協(xié)議完成的，SSL使用證書(shū)機(jī)制來(lái)驗(yàn)證身份损话，使用加密算法來(lái)保證數(shù)據(jù)傳輸?shù)陌踩裕?/p>

在HTTP數(shù)據(jù)包下發(fā)到運(yùn)輸層之前侦啸，增加了SSL層的調(diào)用槽唾；SSL是獨(dú)立于HTTP之外的協(xié)議，所以應(yīng)用層的其他協(xié)議也可以使用SSL做數(shù)據(jù)加密處理光涂；其中TLS協(xié)議是基于SSL3.0的庞萍，目前TLS的最新版本是TLS1.2；既可以使用SSL3.0協(xié)議也可以使用TLS協(xié)議顶捷，所以有時(shí)也會(huì)叫SSL/TLS1.2協(xié)議挂绰；

對(duì)通信方身份的確認(rèn)主要是通過(guò)CA證書(shū)實(shí)現(xiàn)的；由認(rèn)證機(jī)構(gòu)頒發(fā)的數(shù)字簽名證書(shū)很難被仿制服赎，所以只要驗(yàn)證了證書(shū)的簽名沒(méi)有問(wèn)題葵蒂，就可以確認(rèn)訪問(wèn)的服務(wù)器的身份，可以避免第三方偽裝的服務(wù)器重虑；如果客戶(hù)端端也存在認(rèn)證證書(shū)践付，則可以確認(rèn)通信雙方的身份，但是一般只有服務(wù)端才會(huì)布置CA證書(shū)缺厉；

通信過(guò)程中的數(shù)據(jù)加密使用的是混合加密方式永高，即既包括非對(duì)稱(chēng)加密算法也包括對(duì)稱(chēng)加密算法，共同保證數(shù)據(jù)傳輸?shù)陌踩裕?/p>

在客戶(hù)端發(fā)送了請(qǐng)求給服務(wù)端后提针，服務(wù)端首先會(huì)返回認(rèn)證證書(shū)信息給客戶(hù)端命爬；客戶(hù)端在接收到證書(shū)后，會(huì)驗(yàn)證證書(shū)的有效性辐脖，一般是驗(yàn)證證書(shū)的有效期饲宛，然后根據(jù)植入到手機(jī)系統(tǒng)中的CA根證書(shū)驗(yàn)證服務(wù)端返回的證書(shū)簽名是否有效（即驗(yàn)證是否是有認(rèn)證機(jī)構(gòu)簽名的證書(shū)），如果驗(yàn)證通過(guò)嗜价，則會(huì)生成一串“隨機(jī)碼”艇抠，并使用證書(shū)中公鑰信息對(duì)這個(gè)隨機(jī)碼做加密處理，然后發(fā)送到服務(wù)端久锥，服務(wù)端接收到加密的隨機(jī)碼后家淤，用私鑰對(duì)數(shù)據(jù)做解密處理，得到客戶(hù)端發(fā)送過(guò)來(lái)的隨機(jī)碼瑟由；之后這個(gè)“隨機(jī)碼”會(huì)被用作對(duì)稱(chēng)加密算法的密鑰絮重，服務(wù)端與客戶(hù)端接下來(lái)的數(shù)據(jù)傳輸都會(huì)使用對(duì)稱(chēng)加密算法做加密處理；

最后

這篇文章記錄了關(guān)于HTTP協(xié)議的基礎(chǔ)內(nèi)容和 與HTTP相關(guān)的其他網(wǎng)絡(luò)基礎(chǔ)知識(shí)歹苦；方便自己后續(xù)可以快速的回顧復(fù)習(xí)這部分的內(nèi)容绿鸣；HTTP協(xié)議還會(huì)涉及到一些其他的關(guān)聯(lián)內(nèi)容，如怎樣更安全的完成身份驗(yàn)證暂氯、緩存處理機(jī)制、網(wǎng)關(guān)服務(wù)器亮蛔、預(yù)防網(wǎng)絡(luò)攻擊等痴施，有些不屬于HTTP協(xié)議本身的內(nèi)容，但是卻是在協(xié)議實(shí)際使用中需要考慮的問(wèn)題；如果需要了解更多這方面內(nèi)容辣吃，建議可以查看一些對(duì)應(yīng)主題的技術(shù)文章來(lái)加深理解动遭。