使人心動的HTTP知識點大全

前言

使人心動的http知識點，學習面試，必知必會！（本文較長，也可選擇看加劇部分哦）

1、TCP/IP協議族

一、定義

全部互聯網相關的協議（http/tcp/udp/ip/dns/ftp等）的總稱，http協議只是其中一小部分。

二、分層

應用層、傳輸層、網絡層、數據鏈路層

三、爲何要分層？

分工明確，各司其職，誰不行就換誰，互不影響，互相獨立，同時又互相幫助，共成完成一件大事。

四、每層都有什麼職責？

應用層： 向用戶提供應用服務時通訊的活動，基本上咱們平時直接接觸到的協議大都在這，如http、ftp、dns等。

傳輸層： 負責傳輸數據的控制，傳輸層爲兩臺主機上的應用程序提供端到端的通訊。傳輸層只關心通訊的起始端和目的端，而不在意數據包的中轉過程，傳輸層是咱們的外交官，知道如何與其餘國家創建一個安全穩定的連接，以保證數據傳輸的準確性和安全性，tcp和udp協議在這層。

網絡層： 傳輸層不關心的中轉過程在這裏作，網絡層實現數據包的選路和轉發，負責在複雜的計算機、路由、中轉服務器等網絡設備中選擇一條適合的傳輸路線。 網絡層就是一個導航系統，在錯綜複雜的路中選擇一條合適的行進路線，保證外交官能放心的出使。IP協議就在這層。

數據鏈路層： 負責真實數據的傳遞。用來處理連接數據的硬件部分，包括控制操做系統、驅動、網卡和光纖等。在物理硬件中進行數據傳輸，使用IP地址是作不到的，必須使用機器的物理地址（MAC地址），那我沒有MAC地址怎麼辦？可使用ARP協議能夠經過目標設備的IP地址，查詢目標設備的MAC地址，以保證通訊的順利進行。這裏是真正的交通工具，外交官就是在這坐車去出使的。

五、發出一個http請求是如何進行網絡流轉的？

網絡流轉

六、TCP三次握手

什麼是三次握手： TCP提供了一種可靠、面向鏈接、字節流、傳輸層的服務，爲了準確無誤地把數據送到目標處，採用三次握手開啓一個TCP鏈接。

什麼時候握手 ：http信息傳到傳輸層以後，向網絡層傳遞信息以前，先握手，創建穩定的TCP連接，OK了在進行數據傳輸。

如何握手： 由客戶端向服務端發送SYN，服務端向客戶端發送SYN+ACK響應報文,客戶端再向服務端發送一個ACK響應報文，這樣就而後創建一個完整的鏈接。

爲何是三次： 至少須要三次握手，才能讓客戶端和服務器雙方都知道本身和對方的發送能力、和接收能力沒有問題。

第一次握手：客戶端向服務端發送SYN。服務端知道了客戶端的發送能力和本身的接收能力沒有問題。

第二次握手：服務端向客戶端發送SYN+ACK響應報文。客戶端知道了本身的發送能力和接收能力、服務端的接收能力和發送能力沒有問題。

第三次握手：客戶端再向服務端發送一個ACK響應報。服務端知道本身發送能力，客戶端的接收能力沒有問題。

示意圖：

三次握手

七、TCP四次揮手

什麼是四次揮手： TCP鏈接的關閉須要發送四個包，所以稱爲四次揮手。

什麼時候揮手： 想要關閉TCP連接時，客戶端或服務器都可主動發起揮手動做。

如何揮手：

（1） TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送。

（2） 服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。

（3） 服務器關閉客戶端的鏈接，發送一個FIN給客戶端。

（4） 客戶端發回ACK報文確認，並將確認序號設置爲收到序號加1。

爲何是四次： 因爲TCP鏈接是全雙工的，所以每一個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP鏈接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。

2、網絡請求方法

GET： 獲取資源。

HEAD： 相似於GET，可是隻獲取響應頭，無數據返回，用於確認URI有效性及資源的更新日期等。

POST： 提交數據。（雖然get也能夠，可是通常不用get方法提交，安全性很差，可傳輸的數據容量也比較小）

PUT【不經常使用】： 傳輸文件。

DELETE【不經常使用】： 刪除文件。

CONNECT： 改用隧道協議連接代理。

OPTIONS： 詢問服務器支持的請求方法。

TRACE【不經常使用】： 使用Max-Forards追逐請求通訊路徑，用於作網絡診斷。

3、狀態碼

一、狀態碼範圍

1XX： 信息性狀態碼

2XX： 成功

3XX： 重定向

4XX： 客戶端錯誤

5XX： 服務器錯誤

二、經常使用14種：

200： 成功

204： 成功，可是沒有資源返回，通常在只須要客戶端向服務器發送信息，而服務器不須要發送新的信息內容的狀況下使用。

206： 範圍請求響應成功，響應頭裏用content-range指定範圍的實體內容。

301： 永久重定向，之後這個url我將永遠永遠地重定向到A頁面，若是收藏這個網址了，你能夠換成A頁面的連接了，之後都用新的了。

302： 臨時重定向，我臨時把你請求的url重定向到A頁面了，下次我還可能把這個url重定向到B頁面。

303： 功能同302，可是303明確表示要用get方法獲取資源，這點與302有區別

304： 自從上次請求後，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。

307： 臨時重定向。該狀態碼與302有相同的含義。儘管302標準禁止post變化get，但實際使用時你們不遵照。 307會遵守瀏覽器標準，不會從post變爲get。

400： 請求語法錯誤

401： 須要驗證

403： 禁止訪問

404： 沒有請求的資源，也能夠在服務器拒絕訪問且不想說明理由時使用，有些時候url寫錯了也有可能致使404

500： 服務器內部錯誤

503： 服務器正忙或者停機維護

4、HTTP首部

一、通用首部字段（請求報文和響應報文都能用）

Cache-Control: 經過指定首部字段Cache-Control的指令，就能操做緩存的工做機制。

Connection: 控制不在轉發給代理的首部字段；管理持久鏈接。

Data： 代表建立HTTP報文的時間和日期。

Pragma: 只用在客戶端發送的請求中，全部的中間服務器不返回緩存的資源。

Trailer： 事先說明報文主體後記錄了哪些首部字段。一樣能夠用在分塊傳輸編碼時。

Transfer-Encoding: 規定了傳輸報文主體時採用的編碼方式。

Upgrade: 用於檢測HTTP協議及其餘協議是否可使用更高的版本進行通訊。

Via： 爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。

Warning： 一般會告知用戶一些與緩存相關的問題的警告。

二、請求首部字段

Accept： 該字段可通知服務器，用戶代理可以處理的媒體類型及媒體類型的相對優先級。

Accept-Charset: 用來通知服務器用戶代理支持的字符集及字符集的相對優先順序，可一次性指定多種字符集。

Accept-Encoding: 用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序。

Accept-Language: 用來告知服務器用戶代理嫩鞏固處理的天然語言集（中文或英文等），以及天然語言集的相對優先級。

Authorization: 用來告知服務器，用戶代理的認證信息。

Expect: 客戶端使用首部字段Except來告知服務器，指望出現的某種指定行爲。

From： 用來告知服務器使用用戶代理的用戶的電子郵件地址。

Host: 告知服務器，請求的資源所處的互聯網主機名和端口號。Host首部字段在HTTP/1.1規範內是惟一一個必須包含在請求內的首部字段。

If-Match： 相似於If-xxx這樣的請求首部，能夠稱爲條件請求。

If-Modified-Since: 告知服務器若該字段值早於資源的更新時間，則但願能處理該請求。

If-None-Match: 該字段值得實體標記值與請求資源的ETag不一致時，它就告知服務器處理該請求。

If-Range： 它告知服務器若指定的If-Range字段值和請求資源的ETag值或時間相一致時，則做爲範圍請求處理。反之則返回全體資源。

If-Unmodified-Since: 告知服務器，指定的請求資源只有在字段值內指定的日期時間以後，未發生更新的狀況下，才能處理請求。

Max-Forwards： 經過TRACE方法或OPTIONS方法，發送包含首部字段Max-Forwards的請求時，該字段以十進制整數形式指定可通過的服務器最大數目。當服務器接收到Max-Forwards值爲0的請求時，則再也不進行轉發，而是直接返回響應。

Proxy-Authorization： 客戶端會發送包含首部字段Proxy-Authorization的請求，以告知服務器認證所須要的信息。

Range： 告知服務器資源的指定範圍。

TE： 告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級。

User-Agent: 將建立請求的瀏覽器用戶代理名稱等信息傳達給服務器。

三、響應首部字段

Accept-Ranges： 用來告知客戶端服務器是否可以處理範圍請求，以指定獲取服務器端某個部分的資源。

Age: 告知客戶端，源服務器在多久前建立了響應。單位秒。

ETag： 告知客戶端實體標識，它是一種可將資源以字符串形式作惟一標識的方式。

Location: 能夠將響應接收方引導至某個與請求URI位置不一樣的資源。

Proxy-Authenticate: 把由代理服務器所要求的認證信息發送給客戶端。

Retry-After: 告知客戶端應該在多久以後再次發送請求。

Server： 告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息。

Vary： 可對緩存進行控制，源服務器迴向代理服務器傳達關於本地緩存使用方法的命令。
WWW-Authenticate:用於HTTP訪問認證。

四、實體首部字段（約定請求實體）

Allow： 用於通知客戶端可以支持Request-URI指定資源的全部HTTP方法。

Content-Encoding: 告知客戶端服務器對實體的主體部分選用的內容編碼方式。（gzip/compress/deflate/identity)

Content-Language: 告知客戶端，實體主體使用的天然語言。（中文或英文等語言）

Content-Length： 代表了實體主體部分的大小。

Content-Location: 給出與報文主體返回資源對應的URI。

Content-MD5： 是一串由MD5算法生成的值，其目的在於檢查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。

Content-Range: 針對範圍請求，返回響應時使用的首部字段，能告知客戶端做爲相應返回的實體的哪一個部分符合範圍請求。

Content-Type: 說明了實體主體內對象的媒體類型，該字段用type/subtype形式賦值。

Expires： 會將資源失效的日期告知客戶端。

Last-Modified： 指明資源最終修改的時間。

5、瀏覽器緩存與前端數據存儲

一、http緩存：

先強緩存：

瀏覽器先根據這個資源的http頭信息來判斷是否命中強緩存。若是命中則直接加在緩存中的資源，並不會將請求發送到服務器。在chrome控制檯的Network選項中能夠看到該請求返回200的狀態碼，而且Size顯示from disk cache或from memory cache。

後協商緩存：

若是未命中強緩存，則進行協商緩存，瀏覽器把請求發到服務器，服務器判斷瀏覽器本地緩存是否失效。若可使用，則服務器並不會返回資源信息，瀏覽器繼續從緩存加載資源。若是未命中協商緩存，則服務器會將完整的資源返回給瀏覽器，瀏覽器加載新資源，並更新緩存。

強緩存：

利用http的返回頭中的Expires或者Cache-Control兩個字段來控制的，用來表示資源的緩存時間。

1.Expires： 緩存過時時間，用來指定資源到期的時間，是服務器端的具體的時間點。也就是說，Expires=max-age + 請求時間，須要和Last-modified結合使用。Expires是Web服務器響應消息頭字段，在響應http請求時告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存取數據，而無需再次請求。Expires 是 HTTP/1 的產物，受限於本地時間，若是修改了本地時間，可能會形成緩存失效。

2.Cache-Control： 在HTTP/1.1中，Cache-Control是最重要的規則，主要用於控制網頁緩存。好比當Cache-Control:max-age=300時，則表明在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鐘內再次加載資源，就會命中強緩存。

Cache-Control 能夠在請求頭或者響應頭中設置，而且能夠組合使用多種指令：

3.Expires和Cache-Control區別： 沒啥大區別，Expires是http1.0產物，
Cache-Control是http1.1的產物，同時存在的話，Cache-Control優先級高於Expires，Expires是過期的產物，現階段它的存在只是一種兼容性的寫法。

協商緩存：

若未命中強緩存，則瀏覽器會將請求發送至服務器。服務器根據http頭信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match來判斷是否命中協商緩存。若是命中，則http返回碼爲304，瀏覽器從緩存中加載資源。

1.Last-Modify/If-Modify-Since：

①瀏覽器第一次請求一個資源的時候，服務器返回的header中會加上Last-Modify，Last-modify是一個時間標識該資源的最後修改時間，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。

②當瀏覽器再次請求該資源時，發送的請求頭中會包含If-Modify-Since，該值爲緩存以前返回的Last-Modify。服務器收到If-Modify-Since後，根據資源的最後修改時間判斷是否命中緩存。

2.ETag/If-None-Match：

與Last-Modify/If-Modify-Since不一樣的是，Etag/If-None-Match返回的是一個校驗碼（ETag: entity tag）。ETag能夠保證每個資源是惟一的，資源變化都會致使ETag變化。ETag值的變動則說明資源狀態已經被修改。 服務器根據瀏覽器上發送的If-None-Match值來判斷是否命中緩存。

3.Etag的出現解決了Last-Modified的什麼問題：

① Last-Modified標註的最後修改只能精確到秒級，若是某些文件在1秒鐘之內，被修改屢次的話，它將不能準確標註文件的修改時間

②若是某些文件會被按期生成，當有時內容並無任何變化，但Last-Modified卻改變了，致使文件無法使用緩存

③有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形

Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的惟一標識符，能夠更加準確的控制緩存。 Last-Modified與ETag是能夠一塊兒使用的，服務器會優先驗證ETag，一致的狀況下，纔會繼續比對Last-Modified，最後才決定是否返回304。

4.總結：

對於強緩存，服務器通知瀏覽器一個緩存時間，在緩存時間內，直接用緩存，不在時間內，執行協商緩存策略。

對於協商緩存，將緩存信息中的Etag和Last-Modified經過請求發送給服務器，由服務器校驗，返回304狀態碼時，瀏覽器直接使用緩存，不然返回資源。

第一次請求

再次請求：

5.用戶行爲對緩存的影響：

二、前端數據存儲

三、如何根據不一樣場景設計緩存方案？

1.服務端緩存策略-不常變化的資源： 長時間強緩存。爲了讓緩存發揮最大效率，你要作的並非更改文件的內容，而是應該更改資源的URL（經過版本控制讓強緩存失效）。(經常使用)

Cache-Control: max-age=31536000 // 設置緩存時間爲1年

2.服務端緩存策略-常常變化的資源： 協商緩存。首先須要使用Cache-Control: no-cache 使瀏覽器每次都請求服務器，而後配合 ETag 或者 Last-Modified 來驗證資源是否有效。這樣的作法雖然不能節省請求數量，可是能顯著減小響應數據大小。(經常使用)

Cache-Control: no-cache

3.客戶端-主動記錄簡單狀態、參與http通訊、4K之內、瀏覽器行爲跟蹤： 使用cookie。(經常使用)

4.客戶端-主動存儲一些不參與http通訊的數據、5M之內、持久化存儲、關閉對話仍然存在： 使用localstorage。(經常使用)

5.客戶端-主動存儲一些不參與http通訊的數據、5M之內、持久化存儲、關閉對話清除： 使用sessionstorage。(不經常使用)

6.客戶端-主動存儲大量結構化的數據、瀏覽器端數據庫： 使用indexdb。(不經常使用)

6、HTTPS

HTTPS = HTTP + SSL 兩者合二爲一，威力無比

一、http存在的問題

通訊使用明文，不驗證通訊方的身份，沒法驗證報文的完整性。

二、https是什麼

https並非一種新的協議，只是HTTP通訊接口部分用SSL和TLS協議代替而已。https = http+加密+認證+完整性保護。

一般，HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。簡言之，所謂HTTPS，其實就是身披SSL協議這層外殼的HTTP。

HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，TLS/SSL 的功能實現主要依賴於三類基本算法：散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

三、http與https的差距

1. HTTP 是明文傳輸協議，HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全。

2. HTTPS比HTTP更加安全，對搜索引擎更友好，利於SEO,谷歌、百度優先索引HTTPS網頁;

3. HTTPS須要用到SSL證書，而HTTP不用;

4. HTTPS標準端口443，HTTP標準端口80;

5. HTTPS基於傳輸層，HTTP基於應用層;

6. HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

四、https加密方式

1.對稱加密

這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。沒有密鑰就沒法對密碼解密，反過來講，任何人只要持有密鑰就能解密了。

以對稱加密方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

2.非對稱加密

公開密鑰加密使用一對非對稱的密鑰。一把叫作私有密鑰，另外一把叫作公開密鑰。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。

3.https加密方式：對稱加密+非對稱加密

使用對稱密鑰的好處是解密的效率比較快，使用非對稱密鑰的好處是可使得傳輸的內容不能被破解，由於就算你攔截到了數據，可是沒有對應的私鑰，也是不能破解內容的。就好比說你搶到了一個保險櫃，可是沒有保險櫃的鑰匙也不能打開保險櫃。那咱們就將對稱加密與非對稱加密結合起來,充分利用二者各自的優點，在交換密鑰環節使用非對稱加密方式，以後的創建通訊交換報文階段則使用對稱加密方式。

具體作法是：發送密文的一方使用對方的公鑰進行加密處理「對稱的密鑰」，而後對方用本身的私鑰解密拿到「對稱的密鑰」，這樣能夠確保交換的密鑰是安全的前提下，使用對稱加密方式進行通訊。 因此，HTTPS採用對稱加密和非對稱加密二者並用的混合加密機制。

五、https工做流程

1. Client發起一個HTTPS（好比https://juejin.im/user/5a9a9cdcf265da238b7d771c）的請求，根據RFC2818的規定，Client知道須要鏈接Server的443（默認）端口。

2. Server把事先配置好的公鑰證書（public key certificate）返回給客戶端。

3. Client驗證公鑰證書：好比是否在有效期內，證書的用途是否是匹配Client請求的站點，是否是在CRL吊銷列表裏面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操做系統內置的Root證書或者Client內置的Root證書）。若是驗證經過則繼續，不經過則顯示警告信息。

4. Client使用僞隨機數生成器生成加密所使用的對稱密鑰，而後用證書的公鑰加密這個對稱密鑰，發給Server。

5. Server使用本身的私鑰（private key）解密這個消息，獲得對稱密鑰。至此，Client和Server雙方都持有了相同的對稱密鑰。

6. Server使用對稱密鑰加密「明文內容A」，發送給Client。

7. Client使用對稱密鑰解密響應的密文，獲得「明文內容A」。

8. Client再次發起HTTPS的請求，使用對稱密鑰加密請求的「明文內容B」，而後Server使用對稱密鑰解密密文，獲得「明文內容B」。

7、Web安全

一、XSS

什麼是XSS： XSS (Cross Site Script)，跨站腳本攻擊，由於縮寫和 CSS (Cascading Style Sheets) 重疊，因此只能叫 XSS。

原理： 惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的腳本代碼會被執行，從而能夠達到攻擊者盜取用戶信息或其餘侵犯用戶安全隱私的目的。

分類： 非持久型 XSS、持久型 XSS、基於字符集的 XSS、基於 Flash 的跨站 XSS

非持久型 XSS：

①攻擊方式： 非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，通常是經過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。

②攻擊實例：

正常url： http://www.test.com/message.html?from=Hello,World

前端獲取url中from參數渲染到dom中，沒問題

非正常url： http://www.test.com/message.html?from=

前端獲取url中from參數渲染到dom中，惡意操做的代碼就會被執行

③防守策略：

1 . Web 頁面渲染的全部內容或者渲染的數據都必須來自於服務端。

2 . 儘可能不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。

3 . 儘可能不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，
innerHTML，document.creteElement() 等可執行字符串的方法。

4 . 若是作不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數作 escape 轉義。

5 . 前端渲染的時候對任何的字段都須要作 escape 轉義編碼。

持久型 XSS：

①攻擊方式： 持久型 XSS 漏洞，也被稱爲存儲型 XSS 漏洞，通常存在於 Form 表單提交等交互功能，如發帖留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面得到後端從數據庫中讀出的注入代碼時，剛好將其渲染執行。

②攻擊知足條件：

1 . POST 請求提交表單後端沒作轉義直接入庫。

2 . 後端從數據庫中取出數據沒作轉義直接輸出給前端。

3 . 前端拿到後端數據沒作轉義直接渲染成 DOM。

③防守策略：

1 . 後端在入庫前應該選擇不相信任何前端數據，將全部的字段統一進行轉義處理。

2 . 後端在輸出給前端數據統一進行轉義處理。

3 . 前端在渲染頁面 DOM的時候應該選擇不相信任何後端數據，任何字段都須要作轉義處理。

基於字符集的 XSS：

①攻擊方式： 其實如今不少的瀏覽器以及各類開源的庫都專門針對了 XSS 進行轉義處理，儘可能默認抵禦絕大多數 XSS 攻擊，可是仍是有不少方式能夠繞過轉義規則，讓人防不勝防。好比「基於字符集的 XSS 攻擊」就是繞過這些轉義處理的一種攻擊方式，好比有些 Web 頁面字符集不固定，用戶輸入非指望字符集的字符，有時會繞過轉義過濾規則。

②攻擊實例：
utf-7 是能夠將全部的 unicode 經過 7bit 來表示的一種字符集 (但如今已經從 Unicode 規格中移除)。這個字符集爲了經過 7bit 來表示全部的文字, 除去數字和一部分的符號,其它的部分將都以 base64 編碼爲基礎的方式呈現。

能夠造成「基於字符集的 XSS 攻擊」的緣由是因爲瀏覽器在 meta 沒有指定 charset 的時候有自動識別編碼的機制，因此這類攻擊一般就是發生在沒有指定或者沒來得及指定 meta 標籤的 charset 的狀況下。

③防守策略：

1 . 記住指定

2 . XML 中不只要指定字符集爲 utf-8，並且標籤要閉合

基於 Flash 的跨站 XSS：

①攻擊方式： 基於 Flash 的跨站 XSS 也是屬於反射型 XSS 的一種，雖然如今開發 ActionScript 的產品線幾乎沒有了，但仍是提一句吧，AS 腳本能夠接受用戶輸入並操做 cookie，攻擊者能夠配合其餘 XSS（持久型或者非持久型）方法將惡意 swf 文件嵌入頁面中。主要是由於 AS 有時候須要和 JS 傳參交互，攻擊者會經過惡意的 XSS 注入篡改參數，竊取並操做cookie。

③防守策略：

1 . 嚴格管理 cookie 的讀寫權限

2 . 對 Flash 能接受用戶輸入的參數進行過濾 escape 轉義處理

二、CSRF

什麼是CSRF： CSRF（Cross-site request forgery）跨站請求僞造：攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞事後臺的用戶驗證，達到冒充用戶對被攻擊的網站執行某項操做的目的。

示意圖：

CSRF 攻擊必需要有三個條件：

1 . 用戶已經登陸了站點 A，並在本地記錄了 cookie

2 . 在用戶沒有登出站點 A 的狀況下（也就是 cookie 生效的狀況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。

3 . 站點 A 沒有作任何 CSRF 防護

CSRF防護策略：

1. 驗證 HTTP Referer 字段

根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。只須要在最後給全部安全敏感的只須要統一增長一個攔截器來檢查 Referer 的值就能夠。特別是對於當前現有的系統，不須要改變當前系統的任何已有代碼和邏輯，沒有風險，很是便捷。 然而，這種方法並不是萬無一失。對於某些瀏覽器，目前已經有一些方法能夠篡改 Referer 值。並且，用戶本身能夠設置瀏覽器使其在發送請求時不提供 Referer。因此這種方式並非萬無一失。

2. 在請求地址中添加 token 並驗證

CSRF攻擊之因此可以成功，是由於服務器誤把攻擊者發送的請求當成了用戶本身的請求。那麼咱們能夠要求全部的用戶請求都攜帶一個CSRF攻擊者沒法獲取到的Token。服務器經過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開。跟驗證碼相似，只是用戶無感知。

①服務端給用戶生成一個token，加密後傳遞給用戶

②在提交請求時，須要攜帶這個token

③服務端驗證token是否正確

3. 在 HTTP 頭中自定義屬性並驗證

這種方法也是使用 token 並進行驗證，和上一種方法不一樣的是，這裏並非把 token 以參數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性裏。

三、SQL 注入

什麼是SQL 注入： SQL 注入漏洞（SQL Injection）是 Web 開發中最多見的一種安全漏洞。能夠用它來從數據庫獲取敏感信息，或者利用數據庫的特性執行添加用戶，導出文件等一系列惡意操做，甚至有可能獲取數據庫乃至系統用戶最高權限。

SQL攻防策略：

形成 SQL 注入的緣由是由於程序沒有有效的轉義過濾用戶的輸入，使攻擊者成功的向服務器提交惡意的 SQL 查詢代碼，程序在接收後錯誤的將攻擊者的輸入做爲查詢語句的一部分執行，致使原始的查詢邏輯被改變，額外的執行了攻擊者精心構造的惡意代碼。

不少 Web 開發者沒有意識到 SQL 查詢是能夠被篡改的，從而把 SQL 查詢看成可信任的命令。卻不知，SQL 查詢是能夠繞開訪問控制，從而繞過身份驗證和權限檢查的。更有甚者，有可能經過 SQL 查詢去運行主機系統級的命令。

四、點擊劫持

什麼是點擊劫持： 點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將須要攻擊的網站經過 iframe 嵌套的方式嵌入本身的網頁中，並將 iframe 設置爲透明，在頁面中透出一個按鈕誘導用戶點擊。

攻擊方式：
用戶在登錄 A 網站的系統後，被攻擊者誘惑打開第三方網站，而第三方網站經過 iframe 引入了 A 網站的頁面內容，用戶在第三方網站中點擊某個按鈕（被裝飾的按鈕），其實是點擊了 A 網站的按鈕。

防守策略：

X-FRAME-OPTIONS： 這是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是爲了防護用 iframe 嵌套的點擊劫持攻擊。
該響應頭有三個值可選，分別是

DENY：表示頁面不容許經過 iframe 的方式展現

SAMEORIGIN：表示頁面能夠在相同域名下經過 iframe 的方式展現

ALLOW-FROM：表示頁面能夠在指定來源的 iframe 中展現

8、HTTP/2和HTTP/3

一、HTTP/2簡介

2015 年，HTTP/2 發佈。HTTP/2 是現行 HTTP 協議（HTTP/1.x）的替代，但它不是重寫，HTTP 方法/狀態碼/語義都與 HTTP/1.x 同樣。HTTP/2 基於 SPDY3，專一於性能，最大的一個目標是在用戶和網站間只用一個鏈接（connection）。

二、HTTP/2 新特性

1.二進制傳輸

HTTP/2 採用二進制格式傳輸數據，而非 HTTP 1.x 的文本格式，二進制協議解析起來更高效。 HTTP / 1 的請求和響應報文，都是由起始行，首部和實體正文（可選）組成，各部分之間以文本換行符分隔。HTTP/2 將請求和響應數據分割爲更小的幀，而且它們採用二進制編碼。

2.多路複用

在 HTTP/2 中引入了多路複用的技術。多路複用很好的解決了瀏覽器限制同一個域名下的請求數量的問題，同時也接更容易實現全速傳輸，畢竟新開一個 TCP 鏈接都須要慢慢提高傳輸速度。

3. Header壓縮

在 HTTP/1 中，咱們使用文本的形式傳輸 header，在 header 攜帶 cookie 的狀況下，可能每次都須要重複傳輸幾百到幾千的字節。
爲了減小這塊的資源消耗並提高性能， HTTP/2 對這些首部採起了壓縮策略。

4.服務器推送

HTTP/2新增的一個強大的新功能，就是服務器能夠對一個客戶端請求發送多個響應。服務器向客戶端推送資源無需客戶端明確的請求。

三、HTTP/3簡介

雖然 HTTP/2 解決了不少以前舊版本的問題，可是它仍是存在一個巨大的問題，主要是底層支撐的 TCP 協議形成的。

上文提到 HTTP/2 使用了多路複用，通常來講同一域名下只須要使用一個 TCP 鏈接。但當這個鏈接中出現了丟包的狀況，那就會致使 HTTP/2 的表現狀況反倒不如 HTTP/1 了。

由於在出現丟包的狀況下，整個 TCP 都要開始等待重傳，也就致使了後面的全部數據都被阻塞了。可是對於 HTTP/1.1 來講，能夠開啓多個 TCP 鏈接，出現這種狀況反到只會影響其中一個鏈接，剩餘的 TCP 鏈接還能夠正常傳輸數據。

那麼可能就會有人考慮到去修改 TCP 協議，其實這已是一件不可能完成的任務了。由於 TCP 存在的時間實在太長，已經充斥在各類設備中，而且這個協議是由操做系統實現的，更新起來不大現實。

基於這個緣由，Google 就更起爐竈搞了一個基於 UDP 協議的 QUIC 協議，而且使用在了 HTTP/3 上，HTTP/3 以前名爲 HTTP-over-QUIC，從這個名字中咱們也能夠發現，HTTP/3 最大的改造就是使用了 QUIC。

QUIC 雖然基於 UDP，可是在本來的基礎上新增了不少功能，接下來咱們重點介紹幾個 QUIC 新功能。

四、QUIC 新特性

1.大大縮短鏈接創建時間

因爲創建在 UDP 的基礎上，同時又實現了 0RTT 的安全握手，因此在大部分狀況下，只須要 0 個 RTT 就能實現數據發送，在實現前向加密的基礎上，而且 0RTT 的成功率相比 TLS 的會話記錄單要高不少。

2.改進的擁塞控制

使用UDP，不存在 TCP 隊頭阻塞

3.無線頭阻塞的多路複用

雖然 HTTP/2 支持了多路複用，可是 TCP 協議終究是沒有這個功能的。QUIC 原生就實現了這個功能，而且傳輸的單個數據流能夠保證有序交付且不會影響其餘的數據流，這樣的技術就解決了以前 TCP 存在的問題。

4.前向糾錯

QUIC 協議有一個很是獨特的特性，稱爲向前糾錯 (Forward Error Correction，FEC)，每一個數據包除了它自己的內容以外，還包括了部分其餘數據包的數據，所以少許的丟包能夠經過其餘包的冗餘數據直接組裝而無需重傳。

9、其餘問題

一、對於鏈接方式Long-Polling, Websockets, SSE(Server-Sent Event), WebRTC 之間的區別？

1.普通的http

①客戶端從服務器端請求網頁

②服務器做出相應的反應

③服務器返回相應到客戶端

2.AJAX Polling：

①客戶端使用普通的http方式向服務器端請求網頁

②客戶端執行網頁中的JavaScript輪詢腳本，按期循環的向服務器發送請求（例如每5秒發送一次請求），獲取信息

③服務器對每次請求做出響應，並返回相應信息，就像正常的http請求同樣

3.Long-Polling：

①客戶端使用普通的http方式向服務器端請求網頁

②客戶端執行網頁中的JavaScript腳本，向服務器發送數據、請求信息

③服務器並非當即就對客戶端的請求做出響應，而是等待有效的更新

④當信息是有效的更新時，服務器纔會把數據推送給客戶端

⑤當客戶端接收到服務器的通知時，當即會發送一個新的請求，進入到下一次的輪詢

4.HTML5 Server Sent Events (SSE) / EventSource:

①客戶端使用普通的http方式向服務器端請求網頁

②客戶端執行網頁中的JavaScript腳本，與服務器之間創建了一個鏈接

③當服務器端有有效的更新時，會發送一個事件到客戶端

5.HTML5 Websockets:

①客戶端使用普通的http方式向服務器端請求網頁

②客戶端執行網頁中的JavaScript腳本，與服務器之間創建了一個鏈接

③服務器和客戶端之間，能夠雙向的發送有效數據到對方

6.WebRTC:

WebRTC是一種點對點類型的傳輸方式，它支持多種傳輸協議，如：UDP、TCP甚至是抽象層的協議。設計它時同時考慮到了容許使用可靠和不可靠的兩種方式傳輸數據。這種技術通常應用在傳輸數據量較大的內容，好比音、視頻等流媒體的傳輸。

7.Comet:

Comet是一種用於web的推送技術，能使服務器實時地將更新的信息傳送到客戶端，而無須客戶端發出請求，目前有兩種實現方式，長輪詢和iframe流。若是你想了解更多，能夠參考維基百科或者IBM

二、爲何利用多個域名來提供網站資源更有效？

1.CDN緩存更方便

動靜分離，提升效率

2.突破瀏覽器併發限制，瀏覽器一次能發送的http請求是有限的

不一樣瀏覽器同一域名通常創建的連接不超過6個

3.節約cookie帶寬

同域每次請求都要帶上cookie，佔用帶寬

4.減小主域名的鏈接數，優化頁面響應速度

節約主域名的鏈接數，從而提升客戶端網絡帶寬的利用率，優化頁面響應。由於老的瀏覽器（IE6是典型），針對同一個域名只容許同時保持兩個HTTP鏈接。將圖片等資源請求分配到其餘域名上，避免了大圖片之類的並不必定重要的內容阻塞住主域名上其餘後續資源的鏈接（好比ajax請求）。

5.防止沒必要要的安全問題

對於UGC的內容和主站隔離，防止沒必要要的安全問題(用戶上傳js竊取主站cookie之類的)。正是這個緣由要求用戶內容的域名必須不是本身主站的子域名，而是一個徹底獨立的第三方域名。

（PS：關於多域名，也不是越多越好，雖然服務器端能夠作泛解釋，瀏覽器作dns解釋也是耗時間的，並且太多域名，若是要走https的話，還有要多買證書和部署的問題，時間也會慢，通常不超過3個。域名發散和域名收斂之間會有一個折中的最優解，等你去探索吧！）

三、如何進行HTTP性能優化？

1. 合理設置 HTTP緩存，能夠大大的減小請求。

2. CSS Sprites，合併小圖片，減小請求。

3. 資源合併與壓縮，減小請求，節省空間。

4. Inline Images

5. 減小重定向，規避301（url最後文件夾不寫/）

萌在最後

OK，that's all. 本期就到這裏了，喜歡點個關注吧~!

參考連接

1.《圖解http》

2.https://blog.fundebug.com/2019/03/07/understand-http2-and-http3/

3.https://github.com/ljianshu/Blog/issues/56

4.https://github.com/ljianshu/Blog

5.https://www.cnblogs.com/laiqun/p/5478435.html

6.https://www.jianshu.com/p/303206ae2471

7.https://www.cnblogs.com/ranyonsue/p/8918908.html

8.https://www.cnblogs.com/lizhengtan/p/5494089.html