前端學習體系（2）--HTTP協議

前言

今天繼續來整理關於前端的一個知識體系的HTTP協議部分，這也是對前端而言很是重要的一部分，來說講我對HTTP協議的理解，因所學有限，所以若是有什麼錯誤的地方，歡迎你們指正。

HTTP概述

先來簡單說下HTTP的一些概念

• HyperText Transfer Protocol 超文本傳輸協議其實也能夠被稱爲超文本轉移協議
• 咱們把一系列與互聯網關聯的協議集合起來稱之爲TCP/IP
• 咱們所說的HTTP實際上是屬於TCP/IP協議族內部，是它的一個內部子集，通俗來講就是HTTP是這麼多協議中的一種
• HTTP是屬於五層模型中的應用層，下面會提到這個分層模型

HTTP歷史版本

• HTTP/0.9 HTTP標準還未創建，所以通常1.0以前的版本都爲0.9版本
• HTTP/1.0 正式發佈標準版本，稱爲HTTP/1.0
• HTTP/1.1 目前的主流版本，也是被普遍使用的版本
• HTTP/2.0 將來的版本，還有待完善

URI和URL

談到HTTP，相信和咱們平常生活中輸入網址查詢資料，那個網址就是咱們HTTP協議中很是重要的一環，咱們所謂的網址有如下三種類型

URI Uniform Resource Identifier 統一資源標識符

URL Uniform Resource Location 統一資源定位符

URN Unifrom Resource Name 統一資源名

URL和URN其實都是屬於URI的子集，也就是說咱們日常說的網址其實均可以叫作URI。另外URN你們可能知道的比較少，URN表示資源的特定內容的惟一名稱，與目前資源所在地無關，所以使用這些URN，就能夠隨意將資源四處轉移，而不擔憂須要去換地址了，目前URN還在實驗階段，基本也是用不上的，簡單瞭解便可。

HTTP首部和狀態碼

先來看下HTTP報文的一個大概的結構

這個是筆者使用fiddler抓取請求的一些信息，上面這些其實就是咱們的報文信息，第一個是請求報文，第二個是響應報文，總結上面的一個報文結構，因而就有了下面的這個HTTP的報文結構

HTTP的報文結構

起始行
報文首部（各類關於HTTP傳輸的重要信息都包含在首部中）
空行（CRLF）
報文主體（客戶端所須要的資源）

須要瞭解的是，這裏的起始行對於請求報文和響應報文來講結構都是固定的

• 請求報文 請求方法+路徑+HTTP/版本號
• 響應報文 HTTP/版本號+狀態碼+狀態短語

HTTP經常使用的報文首部

經常使用的首部字段被分爲四種

• 通用首部字段，表示請求報文和響應報文都會使用的字段
• 請求首部字段，即客戶端向服務端發送請求的首部字段
• 響應首部字段，服務端響應客戶端的首部字段
• 實體首部字段，表示請求和響應報文中實體部分使用的首部字段

經常使用的各個分類的首部字段，能夠去這裏查詢

HTTP狀態碼

經過查看響應報文，咱們能夠看到上面的起始行給出了一個響應的狀態碼，其實就是表明一系列響應信息的一個數字代碼，200就表示響應成功的意思，每一個響應碼的第一位表明了狀態碼的分類，狀態碼有一下幾個分類 | | 5XX |服務端錯誤| 表示服務器處理請求錯誤 |

狀態碼	分類	描述
1XX	信息型	表示請求正在處理
2XX	成功型	表示請求正常處理
3XX	重定向	表示須要進行附加操做完成請求
4XX	客戶端錯誤	表示服務器沒法處理求
5XX	服務端錯誤	表示服務器處理請求錯誤

通常狀態碼後面都會加上一個緣由短語，用來講明狀態碼的含義，像是上面展現的200 ok，‘ok’就是咱們所說的緣由短語。 一些常見的具體狀態碼，像是200、40四、500等你們都很熟悉，就再也不細說了，這裏給你們分享一下一些可能不怎麼常見的狀態碼，可是往後可能會遇到的狀態碼

206 Partial Content

表示客戶端請求資源的部份內容，而服務器成功響應了部分的資源內容的狀態碼，而且會響應報文中會帶上Content-Range的指定範圍的實體內容

302 Found

臨時性重定向，表示資源已經臨時轉移到其餘URL上，但願用戶本次訪問新的URL，返回的響應報文中會攜帶Location字段顯示新的URL

403 Forbidden

表示請求的資源被服務器拒絕了，服務器能夠在實體中聲明拒絕的緣由，也能夠不說明，通常表示權限出現了某些問題

503 Service Unavailable

表示服務器正在進行超負載或者停機維護的狀態，如今沒法處理請求，若是得知解決以上情況所需的時間，能夠寫入Retry-After字段返回給客戶端

咱們會常常遇到狀態碼和實際情況不一致的狀況，其實這就是在開發的時候，可能並無遵照各個響應碼所表明的含義，就直接返回給客戶端了，可是這樣作很差的地方在於沒有標準，後來的人可能很難去維護前人的代碼。

HTTP緩存

關於緩存問題，實際上是很是複雜的一個問題，筆者以前也是覺得緩存很是簡單，可是實際比咱們想象的更復雜，這裏說的緩存嚴格意義上來講其實就是客戶端緩存，就是保存在瀏覽器端的資源的副本，經過一些簡單首部字段控制緩存行爲，那麼緩存到底是什麼呢？

緩存就是自動保存文檔的副本，能夠解決冗餘的數據傳輸、帶寬限制、服務器響應速速以及網絡延遲等問題

下面就說說這幾個有關緩存的HTTP的首部字段，關於緩存的深刻了解，筆者也還在瞭解中，就暫時不誤人子弟了

• Pragma HTTP1.1以前的版本遺留的字段，只有一個值no-cache表示強制要求緩存服務器去源服務器驗證資源的有效性
• Cache-Control 控制緩存的行爲，請求報文和響應報文中可能都會有這個字段，有如下幾個常見的值，來控制相應的行爲

public 用做響應報文，表示任何客戶端均可以得到響應緩存

private 用做響應報文，表示只有指定的用戶能夠得到緩存

no-cache 做爲請求報文時，是指強制請求服務器驗證緩存，在服務器端做爲響應報文的話，是指每次緩存前肯定資源的有效性

no-store 不管是什麼報文，是表示不緩存請求和響應

Expires 表示資源失效的時間，意思就是在指定的時間內的資源副本，會被當作緩存返回給客戶端，若是在指定時間以後的話，則會請求源服務器獲取資源

max-age 做爲請求報文字段時，表示若是緩存資源的緩存時間不超過設置的時間，則客戶端接收緩存資源。若是是做爲服務器響應報文的話，則表示當前資源保存的最長的時間。須要注意的是，在HTTP1.1版本的時候，若是同時遇到Expires字段時，會忽略該字段，先處理max-age字段，可是在HTTP1.0時，則相反先處理Expires字段

ETag 表示告知客戶端資源實體的標識符，是一種將資源以字符串形式作惟一的標識性的方式，通常都是服務器來進行分配。須要知道的是，ETag有強弱之分，強ETag值表示不管實體發生多麼微小的變化，都會更新其值，而弱ETag則表示資源是否相同，只有資源產生根本性差別，纔會改變其值，這時會在字段開始處附加w/，以下所示：

ETag: W/"123456"
複製代碼

If-Match 表示只有匹配的ETag值和服務器返回的ETag值一致時纔會返回請求，反之則會返回412 Precondition Failed狀態碼

If-None-Match 與If-Match字段恰好相反，表示與返回ETag字段不一致時返回，則處理該請求

If-Modified-Since 表示資源在指定的日期之後有更新過，則服務器接收請求，反之則會返回304 Not Modified，指資源在指定的日期以後沒有被修改過，可使用緩存

If-Unmodified-Since 這個字段與上面的恰好相反，表示在指定日期以後未發生更新，才能處理請求，不然返回412 Precondition Failed

If-Range 表示指定的值若是和返回的ETag的值，或者Date日期的值一致，則會被當作範圍請求來處理，反之則會返回所有資源

下面是一個展現緩存流程的步驟圖：

1. 當請求到達服務器或者是代理時，判斷是否有緩存；
2. 若是沒有緩存的話直接從服務器獲取，而後存入緩存中；
3. 若是有緩存，則會與服務器驗證新鮮度；
4. 若是緩存新鮮度足夠，則對緩存的新鮮度進行更新；
5. 若是新鮮度不夠則請求服務器獲取，回到第二步；

安全的HTTPS

雖然HTTP很是的方便好用，可是由於它是明文傳輸，因此很容易被別人竊取其中的內容，所以爲了防止這種狀況的出現，就有了咱們的HTTPS的出現。

先來看下HTTPS的定義

咱們把添加了加密及認證機制的HTTP稱爲HTTPS，即HTTP Secure --摘自《圖解HTTP》

那麼什麼叫作加密以及認證機制呢？咱們一步步來講。

要知道HTTPS本質其實仍是使用HTTP協議的，所不一樣的地方在於HTTP是直接明文和TCP通訊的，而HTTPS則是利用了SSL（Secure Socket Layer）和TLS（Transport Layer Security）協議，用他們來和TCP進行傳輸，換言之，就是在HTTP協議外面報了一層SSL的殼，就稱爲HTTPS。

那麼問題又來了，爲何加個殼就能安全傳輸了呢？這就要提到咱們上面說過的加密和認證機制了。

對稱加密

通訊雙方使用一樣的密鑰來對報文進行加密，這樣的話別人就看不到了，可是缺點就是首次通訊的時候，須要將密鑰發送給對方，此時密鑰都是明文的，若是被竊取的話，則通訊雙方的信息也就被破解了。

非對稱加密

針對上面的對稱加密的缺點，因而又了非對稱加密。通訊雙方使用兩把密鑰，一把是私鑰，即只有本身知道的祕鑰，一把是公鑰，是公開給全部人知道的。發送信息的一方使用本身的公鑰進行加密，收到信息的一方則使用本身的私鑰進行解密，這樣的話就不須要將密鑰發送保證了數據傳輸的安全。

可是針對這種狀況，若是中間人竊取了數據包，更換了數據，再用公鑰進行加密發送出去，這樣接收方根本不知道本身收到的內容是不是發送方想要傳遞的信息。 另外則是雖然非對稱加密安全性比較高，可是其處理效率是很是低的，若是HTTPS使用這種方式的話，那處理的速度也會很是的低，因而就有了下面的混合加密。

混合加密機制

混合加密機制則是混合了對稱加密和非對稱加密的優勢，實現安全快速的發送信息，具體的實現思路以下：

1. 使用非對稱加密的方式，發送者將後續用於通訊的對稱加密的密鑰使用公鑰進行加密
2. 接受者收到信息後用本身的私鑰進行解密，得到對稱加密的密鑰
3. 在確保交換密鑰是安全的前提下，後續則可使用對稱加密的密鑰進行通訊

這樣作既實現了安全，又實現了效率的提升，可是還有一個問題，就是上面的非對稱加密的一個缺陷，即咱們如何保證咱們在第二步收到的信息中的密鑰就是發送者開始發送的密鑰呢？

這裏人們又想出來一個想法（ps：不得不感慨人類的智慧真的是無窮的），由可信任的第三方數字證書認證機構頒發公開密鑰證書，這樣的話，咱們上面的三步通訊方式則發生了以下的改變

1. 服務器將本身的公鑰登錄至數字證書認證機構
2. 數字證書認證機構根據服務器的公鑰，利用本身的私鑰，進行部署簽名和頒發公鑰證書
3. 客戶端拿到數字證書認證機構的公鑰證書之後，利用其公開的密鑰向數字證書認證機構驗證公鑰證書上的簽名，確保服務器公鑰的真實性
4. 確認服務器的公鑰無誤之後，則利用公鑰對報文加密之後發送
5. 服務器拿到報文之後，使用本身的私鑰進行解密，這樣就獲取了服務器的公鑰

相比上面的步驟，這裏則是多了一個第三方的數字證書認證機構頒發證書籤名的步驟，關於數字證書籤名怎麼獲取，頒發等等就不展開，有興趣的同窗能夠上網搜搜，固然認證機構的公開密鑰怎麼安全的轉交客戶端其實也是一個問題，因此通常來講，瀏覽器開發商會事先在瀏覽器中植入經常使用認證機關的公開密鑰

這裏就是一個csdn網站的一個相關的整數信息

其實以上這些就是咱們在開頭所說的SSL和TLS協議的一個實現，咱們的HTTPS就是在以上這些內容中實現的，那麼一樣的HTTPS其實也會具備上面的一些不足的地方，就是效率會比HTTP低不少，由於須要不斷的進行加密和解密的操做，會消耗大量的CPU和內存等資源，所以處理速度也是相對比較慢的。

TCP/IP協議族

上面的HTTPS也是說到了咱們是利用SSL和TLS來和TCP進行通訊的，那麼TCP又是什麼呢，別急，咱們慢慢道來。 首先咱們的HTTP協議實際上是屬於TCP/IP協議族中的一個內部子集，而TCP則是這個協議族的重要組成部分。

TCP/IP協議族的一個突出思想就是分層，爲何要採用分層呢，其實簡單來講就是各司其職，減小耦合，這樣後續若是各層進行更新升級不會影響到其餘層的協議了，如今主流的或者說是主要的就是如下的五層模型：

• 應用層面向用戶，爲用戶提供直接服務，如HTTP，FTP，DNS都是屬於應用層
• 傳輸層包含兩個性質不一樣的協議TCP（傳輸控制協議）和UDP（用戶數據報協議）
• 網絡層處理在網絡上流動的數據包
• 網絡鏈路層連接硬件設備，諸如硬件驅動，操做系統等
• 物理層負責數據傳輸的硬件設備，如電話線路，以太網等

另外還有一個七層的osi分層模型，就是在應用層裏面細分出了表現層和會話層

• 表示層 表示層把數據轉換爲合適、可理解的語法和語義
• 會話層 維護網絡鏈接的狀態

知道了這些，咱們大概就知道了以上說的全部的知識點的一個大概層次結構了，那麼咱們接着TCP往下說說是如何進行TCP的鏈接以及TCP協議的一些相關信息

TCP協議

• TCP位於傳輸層，提供字節流服務（Byte Stream Service），即大數據塊分割成以報文段爲單位的數據包進行管理
• 能夠將數據準確可靠的傳遞給對方

TCP的三次握手就是爲了準確無誤的將數據送到目標處

• 客戶端先發送一個帶有SYN標誌的數據包給對方
• 服務端接受到之後，回傳一個帶有SYN/ACK標誌的數據包表示確認收到的信息
• 客戶端再發送一個ACK標誌的數據包，表示握手結束

若握手過程當中某個階段連接斷開了，則TCP協議會以相同的順序再次發送數據包

TCP四次揮手確認斷開連接

• 第一次揮手：客戶端發送一個FIN，用來關閉客戶端到服務端的數據傳送，客戶端進入FIN_WAIT_1狀態。
• 第二次揮手：服務端收到FIN後，發送一個ACK給客戶端，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），服務端進入CLOSE_WAIT狀態。
• 第三次揮手：服務端發送一個FIN，用來關閉服務端到客戶端的數據傳送，服務端進入LAST_ACK狀態。
• 第四次揮手：客戶端收到FIN後，客戶端進入TIME_WAIT狀態，接着發送一個ACK給服務端，確認序號爲收到序號+1，服務端進入CLOSED狀態，完成四次揮手。

說完了TCP，以後就是IP協議，也就是存在於網絡層的IP協議，用來處理TCP傳過來的數據包，這部分只是簡單認識一下，由於我對下面這些瞭解的也很少了（手動狗頭）

IP協議

位於網絡層，IP（Internet Protocol）即網際協議，IP協議的做用把各類數據包傳送給對方

IP地址

通俗來講就是你上網的位置，即當前網絡被分配到的地址，上網的位置是隨時可變的，所以IP地址也是能夠變的

MAC地址

網卡所屬的固定地址，這個是商家指定分配的，是不可變的

ARP協議

解析地址的協議，根據對方的IP地址來解析對應的MAC地址

DNS

提供域名到IP地址之間的解析服務

那麼將以上這些鏈接起來，就造成了一個完整的從請求到響應的過程了，在瀏覽器窗口輸入URL，由DNS解析域名，分離IP地址和端口號，HTTP協議則將信息包裝成報文進行發送，TCP協議負責將報文分段進行傳輸，將數據包發送給下一層，即網絡層，IP協議則搜索目標地址，進行傳送，利用ARP協議獲取MAC地址，增長做爲通訊目的地的MAC地址，將數據轉發給鏈路層。服務端接受也是按照相反順序從HTTP協議中獲取請求。

Web的攻擊技術

瞭解完基本的HTTP知識後，安全問題也是咱們一直不得不去重視的另一個問題，這裏所說的一些攻擊技術，也是基於筆者本人所瞭解的，若是有疏漏或者錯誤，歡迎你們儘早提出呀。

針對Web應用的攻擊分爲兩種

• 主動攻擊
• 被動攻擊

顧名思義，主動攻擊，即攻擊者直接訪問Web應用，將攻擊代碼傳入，而被動攻擊，則是利用圈套策略執行攻擊代碼的攻擊模式。 主動攻擊主要有SQL注入攻擊，被動攻擊則主要是XSS攻擊和CSRF攻擊等，下面就來講說這幾種攻擊。

SQL注入

針對Web應用使用的數據庫，運行非法的SQL而產生的攻擊。

用我本身的話來講的話就是，因爲服務端運行SQL一些動態SQL的時候，沒有對動態的內容進行過濾，致使一些關鍵詞被使用，從而產生了意想不到的執行結果。

XSS攻擊

跨站腳本攻擊，即運行了非法的JS腳本或者HTML標籤，致使頁面的內容被篡改或者信息被泄露

簡單解釋一下的話，就是在頁面的輸入框等地方，沒有對輸入內容進行過濾，致使運行了一些非法的JS腳本和HTML標籤，致使這個問題的主要緣由就是Web端的驗證和服務器端的驗證沒有對一些特殊的標籤和關鍵字進行過濾，即輸出值轉義不徹底引發的安全漏洞。

CSRF攻擊

跨站請求僞造

指攻擊者經過設置好的陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態更新，屬於被動攻擊

這裏說下跨站請求僞造的一個簡單的過程

1. 用戶經過登陸獲取認證信息登陸網站
2. 攻擊者佈下陷阱，誘使用戶點擊非法連接觸發陷阱
3. 用戶點擊連接發送請求時，會帶上網站的認證信息，這樣就等於攻擊者竊取了用戶的身份，能夠在網站進行用戶的操做

通常的防護方案，就是使用token進行驗證用戶的請求或者是使用驗證碼，使用自定義的字段來驗證請求等都是能夠來防護CSRF攻擊

上面的請求字段x-csrf-token就是一個自定義的驗證字段，用來防止csrf的攻擊，這個也是從筆者的我的網站中截取的部分，地址在下面已經提供，關於web安全，筆者瞭解的還比較片面，也歡迎大佬們補充。

後記

筆者會將這些文章詳細信息放在我的博客中，固然我的博客如今還只是初步階段完善中，歡迎你們給筆者留言或者是建議等。

參考資料

• 《圖解HTTP》人民郵電出版社
• 《HTTP權威指南》人民郵電出版社
• 面試：計算機網絡基礎詳解
• 【前端詞典】進階必備的網絡基礎