HTTP

一、HTTP協議——-不保存狀態

HTTP自身不對請求和響應之間的通信狀態進行保存，協議對於發送過的請求或響應不做持久化處理。使用HTTP協議，
每當有新的請求發送時，就會有對應的新響應產生，協議本身並不保留之前一切的請求或響應報文的信息。

二、HTTP協議首部

報文首部包含請求行、請求/響應首部字段、通用首部字段、實體首部字段
請求行：包括方法、URI和HTTP版本
HTTP首部字段：包括請求/響應首部字段、通用首部字段、實體首部字段三種。主要提供報文大小，所使用的的語言、認證信息等。

常見的HTTP首部字段：
a、通用首部字段（請求報文與響應報文都會使用的首部字段）
    Date：創建報文時間
    Connection：連接的管理
    Cache-Control：緩存的控制
    Transfer-Encoding：報文主體的傳輸編碼方式
b、請求首部字段（請求報文會使用的首部字段）
    Host：請求資源所在服務器
    Accept：可處理的媒體類型
    Accept-Charset：可接收的字符集
    Accept-Encoding：可接受的內容編碼
    Accept-Language：可接受的自然語言
c、響應首部字段（響應報文會使用的首部字段）
    Accept-Ranges：可接受的字節範圍
    Location：令客戶端重新定向到的URI
    Server：HTTP服務器的安裝信息
d、實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
    Allow：資源可支持的HTTP方法
    Content-Type：實體主類的類型
    Content-Encoding：實體主體適用的編碼方式
    Content-Language：實體主體的自然語言
    Content-Length：實體主體的的字節數
    Content-Range：實體主體的位置範圍，一般用於發出部分請求時使用

三、和TCP/IP協議的關係

TCP/IP協議族分爲四層，應用層、傳輸層、網絡層和數據鏈路層

HTTP協議主要用於應用層，用於生成報文和對請求的內容做處理
IP協議主要解決網絡路由和尋址問題
TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，並且順序
與發出順序一致。

四、狀態碼

     1XX：接收的請求正在處理
     2XX：請求正常處理完畢

200—–客戶端發出的請求在服務器端被正常處理
204—–請求被成功處理，響應報文中不能含有任何實體的主體部分
206—–客戶端進行了範圍請求，服務器端成功執行
```
  3XX：需要執行附加操作以完成請求 
```
301—–永久重定向，表示請求的資源已經被分配了新的URI，以後應使用新的URI
302—–臨時性重定向，表示請求的資源已經被分配了新的URI，僅限本次使用新的URI
303—–表示請求的資源已經被分配了新的URI，要求僅限本次使用GET方法請求資源
304—–客戶端發送附帶條件的請求，服務端允許訪問資源，但發生請求未滿足的情況
附帶條件的請求是指GET方法的請求報文中含有If-Match,If-Modified-Since,If-None-Match等條件請求首部字段。
307—–臨時重定向，表示請求的資源已經被分配了新的URI，僅限本次使用新的URI，不會從POST變爲GET
```
   4XX：客戶端存在錯誤 
```
400—–客戶端請求報文中存在語法錯誤
401—–表示發送的請求需要認證信息
403—–請求資源的訪問被服務器拒絕
404—–服務器上無法找到請求的資源
```
 5XX：服務器處理請求出錯
```
500—–服務器在執行請求時發生錯誤
503—–服務器暫時處於超負載或正在進行停機維護

五、HTTPS=HTTP+加密+認證+完整性保護（說明兩者的區別6點)

HTTP超文本傳輸協議，HTTPS安全超文本傳輸協議
採用HTTPS協議的服務器必須要有一套數字證書
HTTP協議沒有加密機制，HTTPS用SSL（安全套接層）進行加密
HTTPS標準端口443，HTTP標準端口80;
HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

HTTPS比HTTP更加安全，對搜索引擎更友好

HTTPS的功能是：
①對數據進行加密，並建立一個信息安全通道，來保證傳輸過程中的數據安全;
②對網站服務器進行真實身份認證。

HTTP的缺點：    
 ①、通信使用明文不加密，內容可能被竊聽
 ②、不驗證通信方身份，可能遭到僞裝
 ③、無法驗證報文完整性，可能被篡改

六、追加協議WebSocket

WebSocket 是一種網絡通信協議，它的最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向 
服務器發送信息，是真正的雙向平等對話，屬於服務器推送技術的一種。

var ws = new WebSocket("wss://echo.websocket.org");  
ws.onopen = function(evt) {   console.log("Connection open ...");   
ws.send("Hello WebSockets!"); };   
ws.onmessage = function(evt) {   
        console.log( "Received Message: " + evt.data);  
         ws.close();
 }; 
  ws.onclose = function(evt) {   
        console.log("Connection closed.");
 };

七、HTTP方法（8個）

GET：請求訪問已被URI識別的資源
POST：傳輸信息給服務器
PUT：傳輸文件，報文的主題中包含文件內容，然後保存到請求URI指定的位置。
HEAD：獲得報文首部，與GET方法類似，只是不返回報文主體，一般用於驗證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對應URI位置的文件。
OPTIONS：查詢相應URI支持的HTTP方法。
TRACE：讓WEB服務器端將之前的請求通信返回給客戶端
CONNECT：在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。

八、GET與POST的區別（5個）

①get重點在從服務器上獲取資源，post重點在向服務器發送數據；

②GET的所有參數全部包裝在URL中，明文顯示，非常不安全；POST的URL中只有資源路徑，不包含參數，相對安全。  

③Get傳輸的數據量小，因爲受URL長度限制，一般限制在2~8K之間，但效率較高；Post可以傳輸大量數據，所以上傳文件 
時只能用Post方式；

④get方式只支持ASCII字符，向服務器傳中文字符可能會亂碼。post支持標準字符集，可以正確傳遞中文字符。  

⑤GET 請求能夠被緩存，POST請求默認不會緩存。緩存是針對URL來進行緩存的

九、HTTP協議流程（10步）

1.打開HTTP連接。一定要記住HTTP是一種無狀態協議。正因爲如此，對於每一個請求你都要建立一個新的連接。

2.初始化方法請求。這裏面將包含一些類型的方法指示符用來描述調用什麼方法和方法所需要的參數。 

3.設置HTTP請求頭。這裏麪包含要傳送的數據類型(二進制)和數據的總長。  

4.發送請求。將二進制流寫到服務器。  

5.讀取請求。目標servlet程序將被調用並接受HTTP請求數據。servlet程序就調用所有必要的參數選擇相應的方法。 
注意，如果這是這個客戶端的第一次請求，一個服務器對象的新的實例就會被創建。  

6.調用方法。方法將會被服務器端的對象調用。   

7.初始化方法響應。如果調用的方法拋出一個異常，客戶將接收到出錯信息。否則，返回的類型(如果有)將會被髮送。  

8.設置HTTP響應頭。在響應頭中，一定會設置待發送數據的類型和長度。   

9.發送響應。二進制數據流將從Web服務器發送並返回給客戶端。   

10.關閉連接。

十、TCP三次握手，四次揮手

①幾個有關參數的介紹

（1）序號：seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。
（2）確認序號：ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，ack=seq+1。
(3)標誌位（6個）
（A）URG：緊急指針（urgent pointer）有效。
（B）ACK：確認序號有效。
（C）PSH：接收方應該儘快將這個報文交給應用層。
（D）RST：重置連接。
（E）SYN：發起一個新連接。
（F）FIN：釋放一個連接。

②各種狀態的意義

LISTEN - 偵聽來自遠方TCP端口的連接請求；
SYN-SENT -在發送連接請求後等待匹配的連接請求；
SYN-RECEIVED - 在收到和發送一個連接請求後等待對連接請求的確認；
ESTABLISHED- 代表一個打開的連接，數據可以傳送給用戶；
FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認；
FIN-WAIT-2 - 從遠程TCP等待連接中斷請求；
CLOSE-WAIT - 等待從本地用戶發來的連接中斷請求；
CLOSING -等待遠程TCP對連接中斷的確認；
LAST-ACK - 等待原來發向遠程TCP的連接中斷請求的確認；
TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認；
CLOSED - 沒有任何連接狀態；

③什麼是“三次握手”？爲什麼需要“三次握手” ？

答：所謂三次握手（Three-Way Handshake）即建立TCP連接，就是指建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立。三次握手的目的是連接服務器指定端口，建立TCP連接,並同步連接雙方的序列號和確認號並交換 TCP 窗口大小信息（剩餘緩衝區空間的數量）

④“三次握手”的步驟：

a.第一次握手：
Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
b.第二次握手：
Server收到數據包後由標誌位SYN=1知道Client請求建立連接，Server將標誌位SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求，Server進SYN_RECEIVED狀態。
c.第三次握手：
Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，如果正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸數據了。

⑤“四次揮手”的步驟

a.第一次揮手：
Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
b.第二次揮手：
Server收到FIN後，發送一個ACK給Client，Server進入CLOSE_WAIT狀態。客戶端進入FIN_WAIT_2狀態
c.第三次揮手：
Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
d.第四次揮手：
Client收到FIN後，接着發送一個ACK給Server，Client進入TIME_WAIT狀態，Server進入CLOSED狀態，
完成四次揮手。

⑥爲什麼連接的時候是三次握手，關閉的時候卻是四次揮手？

因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，”你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四次揮手。

  ⑦爲什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？（針對客戶端）

我們必須假想網絡是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在TIME_WAIT狀態中，如果客戶端最後一次發送的ACK丟失了，它將重新發送。TIME_WAIT狀態中所需要的時間是依賴於實現方法的。典型的值爲30秒、1分鐘和2分鐘。等待之後連接正式關閉，並且所有的資源(包括端口號)都被釋放。

十一、前端安全問題

參考：http://blog.csdn.net/github_36978270/article/details/78212616

（一）被動攻擊：利用圈套策略執行攻擊代碼，攻擊者不直接對目標WEB應用訪問發起攻擊

1.XSS—–跨站腳本攻擊(Cross Site Script)

①含義：
        通過存在安全漏洞的WEB網站註冊用戶的瀏覽器運行非法的HTML標籤或JavaScript進行的一種攻擊 
②危害：
         利用虛假輸入表單騙取用戶個人信息。
         利用腳本竊取用戶的 Cookie 值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。   
         顯示僞造的文章或圖片。
③防範：

輸入值驗證—–檢查是否符合系統業務邏輯的數值和字符編碼

任何內容寫到頁面之前必須加以encode(轉義)，避免標籤泄露

避免直接在cookie中泄露隱私

儘量採用POST提交表單

2.CSRF—–跨站點請求僞造

①含義：冒充用戶發起請求（在用戶不知情的情況下），完成一些違背用戶意願的事情
②危害：

利用已通過認證的用戶權限更新設定信息等；

利用已通過認證的用戶權限購買商品；

利用已通過的用戶權限在留言板上發表言論。

③原理：
    CSRF主要是因爲WEB隱式身份驗證機制，WEB身份驗證機制雖然可以保證一個請求是來自某個用戶的瀏覽器， 
    但是不能保證這個請求是用戶批准發出的。
登錄信任的網站A，並且在本地產生的cookie

在不退出A的情況下，訪問危險網站B

④防範：

驗證碼；強制用戶必須與應用進行交互，才能完成最終請求。此種方式能很好的遏制 csrf，但是用戶體驗比較差。儘量使用 post ，限制 get 使用；上一個例子可見，get 太容易被拿來做 csrf 攻擊，但是 post 也並不是萬無一失，攻擊者只需要構造一個form就可以。

Referer check；請求來源限制，此種方法成本最低，但是並不能保證 100% 有效，因爲服務器並不是什麼時候都能取到

Referer，而且低版本的瀏覽器存在僞造 Referer 的風險

token；token 驗證的 CSRF 防禦機制是公認最合適的方案。整體思路如下： -
第一步：後端隨機產生一個 token，把這個token 保存到 session 狀態中；同時後端把這個token 交給前端頁面； -
第二步：前端頁面提交請求時，把 token 加入到請求數據或者頭信息中，一起傳給端； -
第三步：後端驗證前端傳來的 token 與 session 是否一致，一致則合法，否則是非法求。

（二）主動攻擊：攻擊者通過直接訪問WEB應用，把攻擊代碼傳入的攻擊模式

1.SQL注入攻擊

①含義：針對WEB應用所使用的數據庫，通過運行非法的SQL而產生的攻擊
②危害：

        非法查看或篡改數據庫的數據
        規避認證
        執行·和數據庫服務器關聯的程序

③防範:

            對用戶輸入進行校驗
            不要使用動態拼接SQL
            不要使用管理員權限的數據庫連接
           不要把機密信息明文存放

（三）CSP

①含義：一個標準，對瀏覽器做出限制，以保證它只能從可信賴來源下載資源。用於幫助檢測和緩解某些類型的攻擊，包括跨站腳本 (XSS) 和數據注入等攻擊。
②原理：CSP遵循以下規則：
不許允不可信賴的來源：只有來自明確定義過的可信賴來源的外鏈資源纔可以被下載
不允許內聯資源：行內腳本和內聯CSS不允許被執行。
不允許eval函數：Javascript的eval函數不可以被使用
③使用：如何配置CSP？
在服務器返回的響應中添加額外的HTTP頭部：Content-Security-Policy。 
因爲安全策略是附屬於每一個HTTP返回中，所以對服務器來說可以逐個頁面的設置安全策略。通過在  
每一個返回中添加統一的CSP頭來使得整個站點都可以採取同一個策略。  

十二、HTTP緩存機制

參考：http://www.cnblogs.com/skynet/archive/2012/11/28/2792503.html
http://blog.csdn.net/abc86319253/article/details/43765333
http://blog.csdn.net/mjr99999/article/details/78682744
http://mp.weixin.qq.com/s/qOMO0LIdA47j3RjhbCWUEQ?utm_source=caibaojian.com

Expires策略

Expires會將資源失效的日期告知客戶端，在Expires字段值指定的時間之前，相應的副本會一直被保存

Cache-control策略（重點關注）

Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。只不過Cache-Control的選擇更多，設置更細緻，如果同時設置的話，其優先級高於Expires。以下爲幾個相關的控制指令：

public:其他用戶也可利用緩存
private:這允許服務器對特定用戶提供資源緩存的服務，此響應消息對於其他用戶的請求無效。
no-cache代表不緩存過期的資源，緩存會向源服務器進行有效期確認
no-store用於防止重要的信息被無意的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存。
max-age指示客戶機可以接收生存期不大於指定時間（以秒爲單位）的響應。

  Etag/If-None-Match

Etag：web服務器響應請求時，告訴瀏覽器當前資源在服務器的唯一標識。
當客戶端發現和服務器約定的直接讀取緩存的時間過了，就在請求中發送If-None-Match選項，值即爲上次請求後響應頭的ETag值，該值在服務端和服務端代表該文件唯一的字符串對比（如果服務端該文件改變了，該值就會變），如果相同，則相應HTTP304，客戶端直接讀取本地緩存，如果不相同，HTTP200，下載正確的數據，更新ETag值。

Last-Modified/If-Modified-Since

Last-Modified：標示這個響應資源的最後修改時間。web服務器在響應請求時，告訴瀏覽器資源的最後修改時間。
If-Modified-Since：當資源過期時（使用Cache-Control標識的max-age），發現資源具有Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。若最後修改時間較新，說明資源又被改動過，則響應整片資源內容（寫在響應消息包體內），HTTP 200；若最後修改時間較舊，說明資源無新修改，則響應HTTP 304 (無需包體，節省瀏覽)，告知瀏覽器繼續使用所保存的cache。
```
 （三）既生Last-Modified何生Etag？
```
你可能會覺得使用Last-Modified已經足以讓瀏覽器知道本地的緩存副本是否足夠新，爲什麼還需要Etag（實體標識）呢？HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：
Last-Modified標註的最後修改只能精確到秒級，如果某些文件在1秒鐘以內，被修改多次的話，它將不能準確標註文件的修改時間
如果某些文件會被定期生成，當有時內容並沒有任何變化，但Last-Modified卻改變了，導致文件沒法使用緩存
有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符，能夠更加準確的控制緩存。Last-Modified與ETag是可以一起使用的，服務器會優先驗證ETag，一致的情況下，纔會繼續比對Last-Modified，最後才決定是否返回304。

十三、cookie和Session

參考：https://www.jianshu.com/p/25802021be63
https://www.jianshu.com/p/ca8637b05c8a?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation
http://blog.csdn.net/u010168160/article/details/47128443

（一）Session出現原因：

由於HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶，這個機制就是Session.服務端要爲特定的用戶創建了特定的Session，用用於標識這個用戶，並且跟蹤用戶

 (二)cookie出現的原因

服務器端需要識別特定的用戶，每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的

（三）服務器識別特定用戶具體實現過程：

第一次創建Session的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 裏面記錄一個Session ID，以後每次請求把這個會話ID發送到服務器，我就知道你是誰了。有人問，如果客戶端的瀏覽器禁用了 Cookie 怎麼辦？一般這種情況下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP交互，URL後面都會被附加上一個諸如 sid=xxxxx 這樣的參數，服務端據此來識別用戶。

（四）兩者的區別：

1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行
3、session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
4、單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能大於3K。
5、所以個人建議：
將登陸信息等重要信息存放爲SESSION
其他信息如果需要保留，可以放在COOKIE中

十四、cookie的弊端

cookie雖然在持久保存客戶端數據提供了方便，分擔了服務器存儲的負擔，但還是有很多侷限性的。
第一：每個特定的域名下最多生成20個cookie

    1.IE6或更低版本最多20個cookie
    2.IE7和之後的版本最後可以有50個cookie。
    3.Firefox最多50個cookie
    4.chrome和Safari沒有做硬性限制，IE和Opera 會清理近期最少使用的cookie，Firefox會隨機清理cookie。  
    cookie的最大大約爲4096字節，爲了兼容性，一般不能超過4095字節。

IE 提供了一種存儲可以持久化用戶數據，叫做uerData，從IE5.0就開始支持。每個數據最多128K，每個域名下最多1M。這個持久化數據放在緩存中，如果緩存沒有清理，那麼會一直存在。

    優點：極高的擴展性和可用性
    1.通過良好的編程，控制保存在cookie中的session對象的大小。
    2.通過加密和安全傳輸技術（SSL），減少cookie被破解的可能性。
    3.只在cookie中存放不敏感數據，即使被盜也不會有重大損失。
    4.控制cookie的生命期，使之不會永遠有效。偷盜者很可能拿到一個過期的cookie。

缺點：

    1.`Cookie`數量和長度的限制。每個domain最多只能有20條cookie，每個cookie長度不能超過4KB，否則會被截掉。
    2.安全性問題。如果cookie被人攔截了，那人就可以取得所有的session信息。即使加密也與事無補，因爲攔截者  
    並不需要知道cookie的意義，他只要原樣轉發cookie就可以達到目的了。
    3.有些狀態不可能保存在客戶端。例如，爲了防止重複提交表單，我們需要在服務器端保存一個計數器。如果我們   
    把這個計數器保存在客戶端，那麼它起不到任何作用。

十五、JSON和XML

JSON的理解，處理JSON的方法，對象與JSON的轉換，JSON的序列化和反序列化

（一）JSON是什麼？

JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。它是基於JavaScript的一個子集。數據格式簡單, 易於讀寫, 佔用帶寬小。是前後臺數據交互最常見的一種數據格式。

（二）JSON語法

1.數據在鍵值對中，如： key:value 使用冒號分隔。
2.數據由逗號分隔
3.花括號保存對象
4.方括號保存數組

（三）對象與JSON的轉換

1.JavaScript對象序列化爲JSON對象:

var jsonText=JSON.stringify(obj);
第二個參數可以爲數組或函數，返回值只保留傳入的部分（序列化第二部考慮）
第三個參數用於控制縮進和空白符（序列化第三步考慮）
定義toJSON()方法，返回某些值（序列化第一步考慮）

2.JSON字符串解析爲原生JavaScript值：

var bookCopy=JSON.parse(jsonText)
第二個參數爲還原函數，返回某些值

(四)JSON的序列化

var jsonText=JSON.stringify(obj);

（五）JSON的反序列化

var bookCopy=JSON.parse(jsonText)

（六）JSON和XML的區別

數據體積：JSON的數據體積更小
數據交互：JSON與JavaScript的交互更方便，更容易解析處理，更好交互
數據描述：JSON對數據的描述性比較差
傳輸速度：JSON的速度要遠遠快於XML

我的絕倫大人

發佈了31 篇原創文章 · 獲贊 9 · 訪問量 1萬+

私信關注

一、HTTP協議——-不保存狀態

二、HTTP協議首部

三、和TCP/IP協議的關係

四、狀態碼

五、HTTPS=HTTP+加密+認證+完整性保護（說明兩者的區別6點)

六、追加協議WebSocket

七、HTTP方法（8個）

八、GET與POST的區別（5個）

九、HTTP協議流程（10步）

十、TCP三次握手，四次揮手

十一、前端安全問題

（一）被動攻擊：利用圈套策略執行攻擊代碼，攻擊者不直接對目標WEB應用訪問發起攻擊

（二）主動攻擊：攻擊者通過直接訪問WEB應用，把攻擊代碼傳入的攻擊模式

（三）CSP

十二、HTTP緩存機制

（一）強緩存相關的header字段

（二）協商緩存相關的header字段

十三、cookie和Session

十四、cookie的弊端

十五、JSON和XML

SQL優化-20231016

CSS預處理器和後處理器

css剩餘部分

跨域

BFC神奇背後的原理

CSS居中問題

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結