前言

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

一、TCP/IP協議族

1、定義

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

2、分層

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

3、為什么要分層？

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

4、每層都有什么職責？

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

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

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

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

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

網絡流轉

6、TCP三次握手

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

何時握手 ：http信息傳到傳輸層之后，向網絡層傳遞信息之前，先握手，建立穩定的TCP鏈接，OK了在進行數據傳輸。

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

為什么是三次： 至少需要三次握手，才能讓客戶端和服務器雙方都知道自己和對方的發送能力、和接收能力沒有問題。

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

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

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

示意圖：

三次握手

7、TCP四次揮手

什么是四次揮手： TCP連接的關閉需要發送四個包，因此稱為四次揮手。

何時揮手： 想要關閉TCP鏈接時，客戶端或服務器均可主動發起揮手動作。

如何揮手：

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

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

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

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

為什么是四次： 由于TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務后就能發送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數據流動，一個TCP連接在收到一個FIN后仍能發送數據。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

二、網絡請求方法

GET： 獲取資源。

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

POST： 提交數據。（雖然get也可以，但是一般不用get方法提交，安全性不好，可傳輸的數據容量也比較小）

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

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

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

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

TRACE【不常用】： 使用Max-Forards追逐請求通信路徑，用于做網絡診斷。

三、狀態碼

1、狀態碼范圍

1XX： 信息性狀態碼

2XX： 成功

3XX： 重定向

4XX： 客戶端錯誤

5XX： 服務器錯誤

2、常用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： 服務器正忙或者停機維護

四、HTTP首部

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

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

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

Data： 表明創建HTTP報文的時間和日期。

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

Trailer： 事先說明報文主體后記錄了哪些首部字段。同樣可以用在分塊傳輸編碼時。

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

Upgrade: 用于檢測HTTP協議及其他協議是否可以使用更高的版本進行通信。

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

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

2、請求首部字段

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: 將創建請求的瀏覽器用戶代理名稱等信息傳達給服務器。

3、響應首部字段

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

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

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

Location: 可以將響應接收方引導至某個與請求URI位置不同的資源。

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

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

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

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

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

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： 指明資源最終修改的時間。

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

1、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.用戶行為對緩存的影響：

2、前端數據存儲

3、如何根據不同場景設計緩存方案？

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。(不常用)

六、HTTPS

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

1、http存在的問題

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

2、https是什么

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

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

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

3、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沒有顯示;

4、https加密方式

1.對稱加密

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

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

2.非對稱加密

公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。

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

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

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

具體做法是：發送密文的一方使用對方的公鑰進行加密處理“對稱的密鑰”，然后對方用自己的私鑰解密拿到“對稱的密鑰”，這樣可以確保交換的密鑰是安全的前提下，使用對稱加密方式進行通信。 所以，HTTPS采用對稱加密和非對稱加密兩者并用的混合加密機制。

5、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”。

七、Web安全

1、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 轉義處理

2、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 頭中自定義的屬性里。

3、SQL 注入

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

SQL攻防策略：

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

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

4、點擊劫持

什么是點擊劫持： 點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中，并將 iframe 設置為透明，在頁面中透出一個按鈕誘導用戶點擊。

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

防守策略：

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

DENY：表示頁面不允許通過 iframe 的方式展示

SAMEORIGIN：表示頁面可以在相同域名下通過 iframe 的方式展示

ALLOW-FROM：表示頁面可以在指定來源的 iframe 中展示

八、HTTP/2和HTTP/3

1、HTTP/2簡介

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

2、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新增的一個強大的新功能，就是服務器可以對一個客戶端請求發送多個響應。服務器向客戶端推送資源無需客戶端明確的請求。

3、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 新功能。

4、QUIC 新特性

1.大大縮短連接建立時間

由于建立在 UDP 的基礎上，同時又實現了 0RTT 的安全握手，所以在大部分情況下，只需要 0 個 RTT 就能實現數據發送，在實現前向加密的基礎上，并且 0RTT 的成功率相比 TLS 的會話記錄單要高很多。

2.改進的擁塞控制

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

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

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

4.前向糾錯

QUIC 協議有一個非常獨特的特性，稱為向前糾錯 (Forward Error Correction，FEC)，每個數據包除了它本身的內容之外，還包括了部分其他數據包的數據，因此少量的丟包可以通過其他包的冗余數據直接組裝而無需重傳。

九、其他問題

1、對于連接方式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

2、為什么利用多個域名來提供網站資源更有效？

1.CDN緩存更方便

動靜分離，提高效率

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

不同瀏覽器同一域名一般建立的鏈接不超過6個

3.節約cookie帶寬

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

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

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

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

對于UGC的內容和主站隔離，防止不必要的安全問題(用戶上傳js竊取主站cookie之類的)。正是這個原因要求用戶內容的域名必須不是自己主站的子域名，而是一個完全獨立的第三方域名。

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

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

轉載于:https://juejin.im/post/5cdc17f5f265da03ae74e76d

總結

以上是生活随笔為你收集整理的令人心动的HTTP知识点大全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。