作為一個前端，了解下 HTTP 協(xié)議是很有必要的蔗包。
先說個題外話魂挂，從《躍遷》一書中提到甫题，高手獲取信息的方式 —— 只獲取一手、二手資料涂召。
我在學(xué)習(xí) HTTP 協(xié)議的時候犯了的毛病是 —— 百度了一堆 HTTP 相關(guān)文章坠非，內(nèi)容不一、質(zhì)量參差不齊芹扭，看得云里霧里麻顶。最后干脆去Google查 HTTP赦抖，發(fā)現(xiàn)在 MDN 上有詳細的 HTTP 相關(guān)資料，于是拋棄三手辅肾、四手資料队萤，直接去看 MDN 上的內(nèi)容。
所以學(xué)習(xí)知識矫钓，必須得先認清資料的來源和專業(yè)程度要尔，在知識源頭學(xué)習(xí)可以提高學(xué)習(xí)的效率和準確性。
簡介
HTTP是一種能夠獲取如 HTML 這樣的網(wǎng)絡(luò)資源的 protocol(通訊協(xié)議)新娜。它是在 Web 上進行數(shù)據(jù)交換的基礎(chǔ)赵辕，是一種 client-server 協(xié)議，也就是說概龄，請求通常是由像瀏覽器這樣的接受方發(fā)起的还惠。一個完整的Web文檔通常是由不同的子文檔拼接而成的，像是文本私杜、布局描述蚕键、圖片、視頻衰粹、腳本等等锣光。
這里加上我個人的理解：HTTP 是一種在客戶端和服務(wù)端之間傳輸信息的傳輸協(xié)議，或者說是一整套傳輸方案铝耻。所以誊爹，像 Headers、Cookie瓢捉、Methods 等都是 HTTP 協(xié)議中的內(nèi)容频丘。用于更好的解決 client-server 傳輸信息中遇到的各種問題。
關(guān)于HTTP的更多歷史信息泊柬，可以看到阮一峰老師的HTTP 協(xié)議入門（阮一峰老師寫的文章還是那么清晰明了椎镣，向老師學(xué)習(xí)！）兽赁。
TCP/IP 三次握手
HTTP 的傳輸協(xié)議是 TCP/IP 協(xié)議，該協(xié)議連接是需要進行三次握手的冷守。
那么為什么必須是三次刀崖？
這個問題的本質(zhì)是：信道不可靠，但是通信雙發(fā)需要就某個問題達成一致拍摇。而要解決這個問題亮钦，無論你在消息中包含什么信息，三次通信是理論上的最小值充活。所以三次握手不是TCP本身的要求蜂莉，而是為了滿足"在不可靠信道上可靠地傳輸信息"這一需求所導(dǎo)致的蜡娶。
以下列出三次握手具體步驟與理解：
- 客戶端發(fā)送 SYN 報文給服務(wù)器端，進入 SYN_SEND 狀態(tài)映穗。 —— 客戶端向服務(wù)器端發(fā)送消息窖张，請求它的回應(yīng)。
- 服務(wù)器收到 SYN 報文蚁滋，回應(yīng)一個 SYN ACK 報文宿接，進入 SYN_RECV 狀態(tài)。 —— 服務(wù)器端收到消息辕录，采取回應(yīng)行為睦霎，回復(fù)消息告訴客戶端收到了。
- 客戶端收到服務(wù)器 SYN 報文走诞，回應(yīng)一個 ACK 報文副女，進入連接狀態(tài)。 —— 客戶端收到消息蚣旱，這時客戶端收到響應(yīng)碑幅，表明發(fā)送的數(shù)據(jù)有回信了。但是服務(wù)器端發(fā)送了回應(yīng)卻還不知道客戶端有沒有收到姻锁。這時客戶端需要再次發(fā)送消息告訴服務(wù)器我收到了枕赵。服務(wù)器收到消息后，客戶端和服務(wù)器都知道對方已準備好通訊位隶，然后就開始連接通訊了拷窜。
HTTP 的請求(request)和響應(yīng)(response)
請求
請求為客戶端發(fā)送給服務(wù)器的數(shù)據(jù)。具體有如下數(shù)據(jù)：
- 請求方法：如 GET涧黄、 POST 這類請求方法篮昧。
- 要獲取的資源路徑。
- HTTP協(xié)議版本號笋妥。
- Headers：傳遞附加信息懊昨。
- body：如果想 POST 請求，就會傳遞 body 資源數(shù)據(jù)給服務(wù)器春宣。
響應(yīng)
響應(yīng)為服務(wù)器收到客戶端發(fā)送數(shù)據(jù)返回的數(shù)據(jù)酵颁，具體有如下數(shù)據(jù)：
- HTTP協(xié)議版本號。
- 狀態(tài)碼（status code）：告知請求是否成功以及失敗原因月帝。
- 狀態(tài)消息（status message）：非權(quán)威狀態(tài)碼信息躏惋，由服務(wù)器自行設(shè)定。
- Headers：傳遞附加信息嚷辅。
- body： 響應(yīng)返回的資源存在body中簿姨。一般返回圖片、HTML等資源。
Headers 頭文件
頭文件允許客戶端和服務(wù)器通過請求和響應(yīng)傳遞附加信息扁位。
下面列出一些常用的消息頭及其用法：
- Date 信息來源的日期時間
- Content-Type 指定服務(wù)器文檔的MIME類型准潭，幫助用戶代理去處理接收到的數(shù)據(jù)。
- Content-Length 表示 body 的字節(jié)長度域仇。
- Host 服務(wù)器的域名刑然。
- User-Agent 可以用來識別發(fā)送請求的瀏覽器，是產(chǎn)品標(biāo)記符和注釋的清單殉簸。
- Accept 用戶代理期望的MIME類型列表
- Accept-Encoding 列出用戶代理支持的壓縮方法
- Accept-Ranges 期望范圍闰集。參數(shù)：byte、none般卑。
- Assess-Control-Allow-Origin 允許組織連接控制 武鲁。
- Age 對象在代理緩存中的時間
- Cache-Control 指定緩存機制
- Connection 是否保持網(wǎng)絡(luò)連接打開狀態(tài)。參數(shù)：keep-alive蝠检、close沐鼠。
- ETag 特定版本資源標(biāo)識符
- Expires 過期時間日期
- Server 服務(wù)器信息，如JSP叹谁、Apache等饲梭。
- Referer 可用于識別用戶訪問位置
還有一些自定專用消息頭可通過 X- 前綴來添加。如 x-oss-object-type焰檩。
狀態(tài)碼
狀態(tài)碼是由服務(wù)器端發(fā)送的響應(yīng)中帶有的請求結(jié)果的信息碼憔涉。可以分為以下幾類：
- 1** 信息響應(yīng)
- 2** 成功響應(yīng)
- 3** 重定向
- 4** 客戶端響應(yīng)
- 5** 服務(wù)器響應(yīng)
列一些常見的狀態(tài)返回碼：
- 200 請求成功析苫。
- 304 未修改兜叨。
- 401 當(dāng)前請求需要用戶驗證。
- 404 未找到資源衩侥。
- 500 服務(wù)器內(nèi)部錯誤国旷，無法完成請求。
狀態(tài)碼其實只要了解常用的茫死，冷門的遇到的時候查查 MDN 就好了跪但。
Cookie
Cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會在瀏覽器下次向同一服務(wù)器發(fā)起請求時被懈怠并發(fā)送到服務(wù)器上峦萎。
HTTP 本質(zhì)上無狀態(tài)屡久，使用 Cookie 可以創(chuàng)建有狀態(tài)會話。服務(wù)器指定 Cookie 后爱榔，瀏覽器的每次請求都會攜帶 Cookie 數(shù)據(jù)涂身。所以，Cookie 常被用來驗證用戶登錄信息搓蚪。
更多 Cookie 內(nèi)容請看 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Cookies
跨域
跨域就是獲取不同域名下服務(wù)器的數(shù)據(jù)《○模跨域?qū)τ?GET 請求沒有影響妒潭。對于其他請求悴能，會先發(fā)送一個 OPTIONS 方法發(fā)送一個預(yù)檢請求，獲知服務(wù)端是否允許跨域請求雳灾。
所以漠酿，之前遇到 POST 方法請求變?yōu)?OPTIONS 請求報錯的問題就是跨域問題。
在 Express 中也遇到個跨域問題谎亩，最終使用 $ npm install cors 的方式解決了炒嘲。
HTTPS
HTTP 和 HTTPS 的區(qū)別
因為 HTTP 所封裝的信息是明文的，通過抓包工具可以分析其信息內(nèi)容匈庭。所以 HTTP 是及其不安全的夫凸。
而 HTTPS 在 HTTP 傳輸協(xié)議的基礎(chǔ)上加上了 SSL/TLS 加密協(xié)議，所以傳輸?shù)男畔⒍际羌用苓^的阱持。不易被截獲信息內(nèi)容夭拌。所以 HTTPS 比 HTTP 安全性更高。
HTTPS 運行機制
大致運行步驟如下：
- 客戶端發(fā)起 HTTPS 請求
- 服務(wù)端獲取數(shù)字證書CA —— 服務(wù)器向數(shù)字證書認證機構(gòu)申請獲取數(shù)字證書 CA 表明服務(wù)器是合法的衷咽、無害的鸽扁。
- 傳送數(shù)字證書 —— 將數(shù)字證書傳給客戶端
- 客戶端解析證書 —— 客戶端向數(shù)字證書認證機構(gòu)查詢，驗證服務(wù)器合法性镶骗。
- 客戶端傳輸加密后信息給服務(wù)端
- 服務(wù)端解密信息
- 服務(wù)端傳輸加密后的信息給客戶端
- 客戶端解密信息
常見加密算法
非對稱加密算法：RSA桶现，DSA/DSS
對稱加密算法：AES，RC4鼎姊，3DES
HASH算法：MD5骡和，SHA1，SHA256
最后
發(fā)現(xiàn)網(wǎng)上寫 HTTP 協(xié)議的文章很多此蜈，但是眾口不一即横，每篇博客的內(nèi)容都有所不同，搜集資料的時候還是蠻困惑的裆赵。
本文整理了一些 HTTP 的基礎(chǔ)知識东囚，寫的不夠詳細。更加深入的學(xué)習(xí)通過查 MDN 來解決問題啦~
參考資料
- MDN https://developer.mozilla.org/zh-CN/docs/Web/HTTP
- 通俗大白話來理解TCP協(xié)議的三次握手和四次分手https://github.com/jawil/blog/issues/14
- https原理：證書傳遞战授、驗證和數(shù)據(jù)加密剩檀、解密過程解析
http://blog.csdn.net/clh604/article/details/22179907
更新內(nèi)容
本文只是 HTTP 的掃盲文，并沒有深入學(xué)習(xí) HTTP 的意思强法，其實深入學(xué)習(xí) HTTP 水還是很深的蟹肘。換位思考，我感覺面試官問 HTTP 相關(guān)問題的主要目的是：能夠很好與后端工程師溝通接口問題楣导；更好處理前端工作中網(wǎng)絡(luò)傳輸?shù)膯栴}废境；保證項目的信息安全；前端工程師作為客戶端方的開發(fā)，也有必要和服務(wù)器端的后端工程師合作將程序開發(fā)的高效噩凹、安全巴元、易維護。
--03-19更新--
我去問了一位前輩前端為什么要學(xué)習(xí) HTTP 協(xié)議驮宴，大牛前輩的回答是這樣的：“就前端來講逮刨，兩個用處吧：前端性能優(yōu)化必須掌握，排障必須掌握”
感覺這篇文章內(nèi)容實在少了點堵泽。所以又補充了點內(nèi)容修己，貼上幾條最靠譜的 HTTP 學(xué)習(xí)資料希望能夠幫到一些想深入學(xué)習(xí) HTTP 童鞋~
記住文章開頭所講的，只去源頭的知識學(xué)習(xí)才能保證學(xué)習(xí)的效率和準確性~祝我們能夠更快更好的學(xué)習(xí)技術(shù)知識迎罗。
