HTTP

HTTP是一個(gè)屬于應(yīng)用層的協(xié)議瑰钮，特點(diǎn)是簡介畦娄、快速

HTTP發(fā)展史

HTTP客戶端發(fā)起請求毕箍，創(chuàng)建端口
HTTP服務(wù)器在端口監(jiān)聽客戶端請求
HTTP服務(wù)器向客戶端返回狀態(tài)和內(nèi)容

網(wǎng)絡(luò)請求，頁面渲染

1皆辽、域名解析

• 以Chrome瀏覽器為例萨赁，域名解析過程：

  • 1弊琴、Chrome搜索自身的DNS緩存
  • 2、搜索操作系統(tǒng)自身的DNS緩存（瀏覽器沒有找到緩存或緩存已經(jīng)過期失效）：chrome://net-internals/#dns查看DNS緩存記錄
  • 3杖爽、讀取本地的HOST文件
  • 4敲董、瀏覽器發(fā)起一個(gè)DNS的一個(gè)系統(tǒng)調(diào)用，一般向本地主控DNS服務(wù)器
  • 5慰安、瀏覽器獲得域名對應(yīng)的IP地址后腋寨，發(fā)起HTTP "三次握手"
  • 6、TCP/IP連接建立起來后化焕，瀏覽器就可以向服務(wù)器發(fā)送HTTP請求了萄窜，使用了比如說，用HTTP的GET方法請求一個(gè)根域里的一個(gè)域名撒桨，協(xié)議可以采用HTTP1.0的一個(gè)協(xié)議查刻。
  • 7、服務(wù)器端接收到了這個(gè)請求凤类，根據(jù)根路徑參數(shù)穗泵，經(jīng)過后端的一些處理之后，把處理后的一個(gè)結(jié)果的數(shù)據(jù)返回瀏覽器踱蠢，如果是慕課網(wǎng)的頁面就會把完整的HTML頁面代碼返回給瀏覽器火欧。
  • 8、瀏覽器拿到了慕課網(wǎng)的完整的HTML頁面代碼茎截，在解析和渲染這個(gè)頁面的時(shí)候苇侵，里面的JS、CSS企锌、圖片靜態(tài)資源榆浓，它們同樣也是一個(gè)個(gè)HTTP請求，都需要經(jīng)過上面的主要的七個(gè)步驟撕攒。
  • 9陡鹃、瀏覽器根據(jù)拿到的資源對頁面進(jìn)行渲染，最終把一個(gè)完整的頁面呈現(xiàn)給了用戶抖坪。

• 運(yùn)營商DNS服務(wù)器

  • 1萍鲸、寬帶運(yùn)營商服務(wù)器查看本身緩存
  • 2、運(yùn)營商服務(wù)器發(fā)起一個(gè)迭代的DNS解析請求
    • 運(yùn)營商服務(wù)器把結(jié)果返回操作系統(tǒng)內(nèi)核同時(shí)緩存起來
    • 操作系統(tǒng)內(nèi)核把結(jié)果返回瀏覽器
    • 最終瀏覽器拿到了www.imooc.com對應(yīng)的IP地址

瀏覽器以一個(gè)隨機(jī)端口向服務(wù)器的Web程序發(fā)起一個(gè)TCP連接請求擦俐，此連接請求通過層層路由設(shè)備到達(dá)網(wǎng)卡脊阴，然后進(jìn)入內(nèi)核的TCP/IP協(xié)議棧（有可能經(jīng)過防火墻過濾），最終到達(dá)Web服務(wù)端蚯瞧。

HTTP交互過程

1嘿期、客戶端發(fā)送SYN同步報(bào)文給服務(wù)端
2、服務(wù)端收到SYN同步報(bào)文之后埋合，給客戶端一個(gè)回復(fù)報(bào)文SYN,ACK報(bào)文
3备徐、客戶端收到第二條報(bào)文之后，會再給服務(wù)端回復(fù)一個(gè)ACK報(bào)文

連接建立完成之后甚颂，客戶端和服務(wù)端就可以進(jìn)行正常的HTTP網(wǎng)絡(luò)請求

4蜜猾、客戶端發(fā)送一個(gè)HTTP請求報(bào)文到服務(wù)端
5、服務(wù)端收到客戶端的HTTP請求報(bào)文振诬，處理之后把數(shù)據(jù)返回給客戶端瓣铣，產(chǎn)生第五條HTTP響應(yīng)報(bào)文

當(dāng)客戶端和服務(wù)端之間結(jié)束網(wǎng)絡(luò)請求之后，這條TCP連接通道就會關(guān)閉
假如斷開由客戶端發(fā)起贷揽，流程：
6棠笑、客戶端發(fā)送FIN終止信號報(bào)文
7、服務(wù)端收到客戶端發(fā)送的終止信號之后禽绪，服務(wù)端會回復(fù)給客戶端一個(gè)ACK確認(rèn)報(bào)文

當(dāng)客戶端收到第七條報(bào)文之后蓖救，有客戶端向服務(wù)端方向的連接就已經(jīng)斷開

8、過一段時(shí)間印屁，服務(wù)端又會發(fā)送給客戶端第八條FIN循捺、ACK終止報(bào)文
9、客戶端收到第八條報(bào)文之后雄人，會回復(fù)給服務(wù)端一條ACK確認(rèn)報(bào)文从橘，此時(shí)由服務(wù)端到客戶端方向的TCP連接通道關(guān)閉念赶。

TCP 連接通道是一個(gè)全雙工的通道，并不是兩條通道

Wireshark工具查看HTTP工作流程

HTTP消息體

HTTP Request 協(xié)議格式

HTTP Request 協(xié)議格式
? {請求方法}{/相對路徑} HTTP/{http版本}\r\n         \r\n = CRLF
? Header-Name-1:value\r\n
? Header-Name-2:value\r\n
? \r\n
? Optional Request Boby

HTTP Request 協(xié)議格式

HTTP Request 協(xié)議格式
? HTTP/{version} {status-code} {message}\r\n
? Header-Name-1:value\r\n
? Header-Name-2:value\r\n
? \r\n
? Optional Request Boby

Headers：頭信息

Preview：資源預(yù)覽

Response：么有處理的響應(yīng)的響應(yīng)的正文

Cookies：請求和返回的Cookies

Timing：圖形化顯示每個(gè)階段耗費(fèi)的時(shí)間

Stalled：等待時(shí)間：瀏覽器要發(fā)出請求到請求可以發(fā)出的等待時(shí)間恰力，一般是代理協(xié)商以及要等到TCP連接釋放的時(shí)間不包含DNS查詢和建立TCP連接的時(shí)間叉谜。

Proxy negotiation：代理協(xié)商的時(shí)間

Request sent：請求時(shí)間：第一個(gè)字節(jié)發(fā)出前，到最后一個(gè)字節(jié)發(fā)出后的時(shí)間踩萎，可以理解為請求時(shí)間或上傳時(shí)間

Watting(TTFB)：請求發(fā)出以后到收到響應(yīng)的第一個(gè)字節(jié)所花費(fèi)的時(shí)間停局，包括整個(gè)數(shù)據(jù)在路由貫穿中所延遲的時(shí)間，以及服務(wù)器端響應(yīng)這個(gè)請求做的處理時(shí)間

Content Download：收到第一個(gè)字節(jié)開始到收到最后一個(gè)字節(jié)結(jié)束所花費(fèi)的時(shí)間

charles工具：抓取HTTP請求和響應(yīng)數(shù)據(jù)

Telnet模擬HTTP請求

HTTPS：Hyper Text Transfer Protocol over Secure Socket Layer.基于SSL層的HTTP

HTTP與HTTPS不同之處

• HTTPS協(xié)議需要到CA申請證書香府，一般免費(fèi)證書很少董栽，需要交費(fèi)；
• HTTP是明文傳輸企孩，HTTPS則是具有安全性的SSL加密傳輸锭碳；
• HTTP和HTTPS使用的端口也不一樣，前者是80勿璃，后者是443工禾；
• HTTPS可進(jìn)行加密傳輸，身份認(rèn)證蝗柔，比HTTP安全闻葵。

HTTP最大特點(diǎn)是無連接無狀態(tài)。

• 限制每次連接只處理一個(gè)請求癣丧，服務(wù)器處理完客戶的請求之后并且接收到客戶端的答應(yīng)后斷開此連接槽畔。這種方式的最大好處是節(jié)省傳輸時(shí)間。HTTP1.0胁编，早期客戶端與服務(wù)端交換的間歇性較大厢钧，大部分通道處于空閑，會無端占用資源嬉橙，利用這一特點(diǎn)設(shè)計(jì)了請求時(shí)建立連接早直，請求完畢后釋放連接，這樣可以盡快釋放資源市框，服務(wù)其他客戶端霞扬。

• 隨著時(shí)間推移，keep-alive誕生枫振，解決效率低的問題喻圃，功能是客戶端到服務(wù)端連接持續(xù)有效。當(dāng)出現(xiàn)對服務(wù)器后續(xù)請求時(shí)粪滤，keep-alive避免了重新建立連接斧拍。也可以叫做HTTP的持久連接，可以使用同一TCP連接來發(fā)送和接受多個(gè)HTTP請求和應(yīng)答杖小。

安全套接字層SSL & 安全傳輸層TLS

• SSL：Secure Sockets Layer安全套接層
• TLS：Transport Layer Securuty 傳輸層安全肆汹，SSL繼任者
• TLS與SSL在傳輸層之上對網(wǎng)絡(luò)連接進(jìn)行加密愚墓，為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性

SSL協(xié)議

為了解決以下風(fēng)險(xiǎn)而設(shè)計(jì)產(chǎn)生：

• 所有信息都是加密傳播，第三方無法竊聽
• 具有校驗(yàn)機(jī)制昂勉，一旦被篡改浪册，通信雙方會立刻發(fā)現(xiàn)
• 配備身份證書，防止身份被冒充

HTTP與HTTPS架構(gòu)

SSL連接建立過程

1硼啤、客戶端發(fā)送握手信息給服務(wù)端议经，2個(gè)內(nèi)容：隨機(jī)數(shù)number1斧账，協(xié)商的加密算法（或者客戶端支持的加密算法）
2谴返、服務(wù)端給予客戶端響應(yīng)握手信息，隨機(jī)數(shù)number2咧织，匹配好的協(xié)商加密算法（一定是客戶端傳給服務(wù)器端的加密算法的一個(gè)子集）
3嗓袱、服務(wù)端給客戶端第一個(gè)響應(yīng)報(bào)文之后，隨即又會傳遞給客戶端第二個(gè)響應(yīng)報(bào)文习绢，即服務(wù)端的證書
4渠抹、客戶端收到服務(wù)端傳遞的證書之后，對證書進(jìn)行驗(yàn)證闪萄，是否有效梧却、合法（1、客戶端驗(yàn)證服務(wù)端證書的數(shù)字摘要和證書解密后的內(nèi)容是否被篡改败去；2放航、證書鏈。逐級驗(yàn)證服務(wù)端的證書圆裕，一直到根證書是否在我們的操作系統(tǒng)的可信任證書列表當(dāng)中广鳍。根證書會被植入到瀏覽器中或操作系統(tǒng)中）
5、客戶端組裝會話秘鑰（組裝有三個(gè)內(nèi)容：通過客戶端自己保留的隨機(jī)數(shù)number1吓妆、隨機(jī)數(shù)number2赊时，預(yù)主秘鑰組裝會話秘鑰）
6、客戶端將預(yù)主秘鑰通過服務(wù)端傳遞過來的證書里面的公鑰加密行拢，然后傳遞給服務(wù)端
7祖秒、服務(wù)端拿到加密過的預(yù)主秘鑰，通過私鑰解密域主秘鑰舟奠，服務(wù)端也獲取到三個(gè)隨機(jī)數(shù)
8狈涮、服務(wù)端拿到三個(gè)隨機(jī)數(shù)開始組裝會話密鑰
9、客戶端通過組裝的會話密鑰去加密一條消息鸭栖，把加密后的握手消息傳遞給服務(wù)端歌馍，主要為了驗(yàn)證服務(wù)端能否正常接收客戶端加密過的數(shù)據(jù)消息
10、服務(wù)端同樣發(fā)送一個(gè)加密后的握手消息給客戶端晕鹊，來驗(yàn)證客戶端是否能正常解析加密過的數(shù)據(jù)松却。9暴浦，10兩步驗(yàn)證通過，客戶端與服務(wù)端之間的SSL連接就建立完成了晓锻。

預(yù)主密鑰：由客戶端產(chǎn)生歌焦，傳遞給服務(wù)端，在會話中起著非常重要的作用砚哆，配合隨機(jī)數(shù)1和隨機(jī)數(shù)2生成最終的會話密鑰独撇。傳遞的隨機(jī)數(shù)和預(yù)主秘鑰完全可以只有預(yù)主秘鑰承擔(dān)，為什么產(chǎn)生三個(gè)隨機(jī)數(shù)：協(xié)議設(shè)計(jì)之初躁锁，假設(shè)客戶端所產(chǎn)生的隨機(jī)數(shù)不是真正的隨機(jī)數(shù)纷铣，為了保證隨機(jī)數(shù)的隨機(jī)性，我們通過產(chǎn)生多個(gè)隨機(jī)數(shù)來達(dá)到最終產(chǎn)生的秘鑰具有非常好的隨機(jī)性战转，防止被中間攻擊人隨意竊取搜立。

公鑰、私鑰：非對稱加密中的專業(yè)術(shù)語槐秧。

對稱加密算法：加密所使用的秘鑰和解密所使用的秘鑰相同啄踊。常見的有AES、DES刁标。安全性差颠通，因?yàn)樾枰獙⑺借€傳輸給服務(wù)端。

對稱加密

非對稱加密：使用公鑰進(jìn)行加密膀懈，解密使用私密的算法顿锰。常見RSA。

非對稱加密

請求方法

• GET：請求獲取Request-URI所標(biāo)識的資源
• POST：新創(chuàng)建資源吏砂，在Request-URI所標(biāo)識的資源后附加新的數(shù)據(jù)
• PUT：請求服務(wù)器存儲一個(gè)資源撵儿，并用Request-URI作為其標(biāo)識。向指定資源位置上傳最新內(nèi)容
• DELETE：請求服務(wù)器刪除Request-URI所標(biāo)識的資源
• HEAD：請求獲取由Request-URI所表示的資源的響應(yīng)消息報(bào)頭狐血，可以不用傳入全部內(nèi)容
• TRACE
• OPTIONS 請求查詢服務(wù)器的性能淀歇，或者查詢與資源相關(guān)的選項(xiàng)和需求

狀態(tài)碼

• 1xx：信息響應(yīng)類，表示接收到請求并且繼續(xù)處理
• 2xx：處理成功響應(yīng)類匈织，表示動作被成功接收浪默、理解和接受
• 3xx：重定向響應(yīng)類，為了完成指定的動作缀匕，必須接受進(jìn)一步處理
• 4xx：客戶端錯誤纳决，客戶請求包含語法錯誤或者是不能正確執(zhí)行
• 5xx：服務(wù)器端錯誤，服務(wù)器不能正確執(zhí)行一個(gè)正確的請求

常用狀態(tài)碼

• 200 OK 客戶端請求成功
• 400 Bad Request 客戶端請求有語法錯誤乡小，不能被服務(wù)器所理解
• 401 Unauthorized 服務(wù)器收到請求阔加，但是拒絕提供服務(wù)
• 404 Not Found 請求資源不存在
• 500 Internal Server Error 服務(wù)器發(fā)生不可預(yù)期的錯誤
• 503 Server Unavailable 服務(wù)器當(dāng)前不能處理客戶端的請求

URL：同一資源定位符，偏重定位满钟，說明了通過那種協(xié)議來訪問一個(gè)資源胜榔。

URI：同一資源標(biāo)識符胳喷，偏重標(biāo)識，一個(gè)字符串格式規(guī)范夭织。

URL是URI的子集吭露。

Restful

• REST（Resource Representational State Transfer）是Roy Thomas Fielding在他2000年的博士論文中提出的。如果一個(gè)架構(gòu)符合REST原則尊惰，就稱為RESTful架構(gòu)

• 本質(zhì)：一種軟件架構(gòu)風(fēng)格

• 核心：面向資源

• 解決問題：降低開發(fā)的復(fù)雜性讲竿；提高系統(tǒng)的可伸縮性

• Restful資源層Resource：文本、圖片弄屡、服務(wù)题禀、音頻等等

• Restful表現(xiàn)層Representational

  • 文本：txt、html琢岩、xml投剥、json师脂、二進(jìn)制
  • 圖片：jpg担孔、png
  • Case：book是一個(gè)資源，獲取不同的格式
  • http協(xié)議的content-type和accept

• Restful狀態(tài)轉(zhuǎn)化State Transfer

  • 冪等性：每次HTTP請求相同的參數(shù)吃警，相同的URI糕篇，產(chǎn)生的結(jié)果是相同的
  • GET
  • POST
  • PUT
  • DELETE

設(shè)計(jì)概念和準(zhǔn)則

• 網(wǎng)絡(luò)上的所有事物都可以被抽象為資源。
• 每一個(gè)資源都有唯一的資源標(biāo)識酌心，對資源的操作不會改變這些標(biāo)識拌消。
• 所有的操作都是無狀態(tài)的。

資源：網(wǎng)絡(luò)上的一個(gè)實(shí)體安券，或者說是網(wǎng)絡(luò)上的一個(gè)具體信息墩崩。

schema://host[:port]/path [?query-string][#anchor]

• schema：指定底層使用的協(xié)議（例如：http，https侯勉，ftp）

• host：服務(wù)器的IP地址或者域名

• port：服務(wù)器端口鹦筹，默認(rèn)為80

• path：訪問資源的路徑

• query-string：發(fā)送給http服務(wù)器的數(shù)據(jù)

• anchor：錨

SOAP WebService

WebService：是一種跨編程語言和操作系統(tǒng)平臺的遠(yuǎn)程調(diào)用技術(shù)。

WebService通過HTTP協(xié)議發(fā)送請求和接收結(jié)果時(shí)采用XML格式封裝址貌，并增加了一些特點(diǎn)的HTTP消息頭铐拐，這些特定的HTTP消息頭和XML內(nèi)容格式就是SOAP協(xié)議。

效率與易用性

SOAP由于各種需求不斷擴(kuò)充其本身協(xié)議的內(nèi)容练对，導(dǎo)致在SOAP處理方面的性能有所下降遍蟋。同時(shí)在易用性方面以及學(xué)習(xí)成本上也有所增加。

RESTful由于其面向資源接口設(shè)計(jì)以及操作抽象簡化了開發(fā)者的不良設(shè)計(jì)螟凭，同時(shí)也最大限度的利用了http最初的應(yīng)用協(xié)議設(shè)計(jì)理念虚青。

安全性

RESTful對于資源型服務(wù)接口來說很合適，同時(shí)特別適合對效率要求很高螺男，但是對于安全要求不高的場景棒厘。

SOAP的成熟性可以給需要提供給多開發(fā)語言钟些，對于安全性要求較高的接口設(shè)計(jì)帶來便利。所以我覺得純粹說什么設(shè)計(jì)模式將會占據(jù)主導(dǎo)地位沒有什么意義绊谭，關(guān)鍵還是看應(yīng)用場景政恍。

如何設(shè)計(jì)RESTful API

• 資源路徑（URI）
• HTTP動詞
• 過濾信息
• 狀態(tài)碼
• 錯誤處理

HTTP動詞

對于資源的操作（CRUD），由HTTP動詞（謂詞）表示达传。

• GET：從服務(wù)器取出資源（一項(xiàng)或多項(xiàng)）
• POST：在服務(wù)器新建一個(gè)資源
• PUT：在服務(wù)器更新資源（客戶端提供改變后的完整資源）
• PATCH：在服務(wù)器更新資源（客戶端提供改變的屬性）
• DELETE：從服務(wù)器刪除資源

過濾信息

• 如果記錄數(shù)量很多篙耗，服務(wù)器不可能都將它們返回給用戶。API應(yīng)該提供參數(shù)宪赶，過濾返回結(jié)果宗弯。

舉例：

• ?offset=10：指定返回記錄的開始位置
• ?page=2&per_page=100：指定第幾頁，以及每頁的記錄數(shù)
• ?sortby=name&order=asc：指定返回結(jié)果排序搂妻，以及排序順序
• ?animal_type_id=1：指定篩選條件