HTTP 是瀏覽器和服務器通信時所採用的協議，它的特點有：
1，基於TCP/IP通信協議,2，工作過程：
瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求
Web服務器根據接收到的請求後，向客戶端發送響應信息。
3，無連接/無狀態：（節省傳輸時間）
無連接的含義是限制每次連接只處理一個請求
服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接
HTTP三次握手：
第一次握手：主機A發送位碼爲SYN＝1,隨機產生seq number=a的數據包到服務器
主機B由SYN=1知道，A要求建立聯機；
第二次握手：
主機B收到請求後要確認聯機信息，向A發送 ack number=(a+1)，syn=1，ack=1
隨機產生seq=b的包
第三次握手：
主機A收到後檢查ack number是否正確，即第一次發送的a+1，以及位碼ack是否爲1
若正確，主機A會再發送ack number=(b+1)，ack=1
主機B收到後確認seq值與ack=1則連接建立成功。
四次揮手：
第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不 會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但是，此時主動關閉方還可 以接受數據。
第二次揮手：被動關閉方收到FIN包後，發送一個ACK給對方，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號）
第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
第四次揮手：主動關閉方收到FIN後，發送一個ACK給被動關閉方，確認序號爲收到序號+1，至此，完成四次揮手。
HTTP請求方法：
1、GET 請求指定的頁面信息，並返回實體主體。2、HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。
3、POST請求可能會導致新的資源的建立和/或已有資源的修改。
4、PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。
5、DELETE 請求服務器刪除指定的頁面。
6、CONNECT HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。
7、OPTIONS 允許客戶端查看服務器的性能。
8、TRACE 回顯服務器收到的請求，主要用於測試或診斷。
GET和POST的區別：
GET：
1，請求獲取指定的資源。2，安全、冪等、可緩存的
3，報文主體沒有任何語義
4，提交的數據會在地址欄中顯示出來
5，用於從服務器端獲取數據，包括靜態資源(HTML|JS|CSS|Image等等)、動態數據展示(列表數據、詳情數據等等)
POST：1，語義是根據請求負荷（報文主體）對指定的資源做出處理，具體的處理方式視資源類型而不同。,
2，不安全，不冪等，（大部分實現）不可緩存
3，提交的數據不會在地址欄顯示
4，用於向服務器提交數據，修改服務器上的資源的請求，比如增刪改數據，提交一個表單新建一個用戶、或修改一個用戶等
HTTP之狀態碼：
1xx：指示信息--表示請求已接收，繼續處理2xx：成功--表示請求已被成功接收、理解、接受
200：OK 204：No Content
3xx：重定向--要完成請求必須進行更進一步的操作
301：永久性重定向 302：臨時性重定向 304：請求未滿足條件
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
400：Bad Request 403： Forbidden 404：Not Found
5xx：服務器端錯誤--服務器未能實現合法的請求
500：Internal Server Error 503：Service Unvaliable
關於URI和URL
1，URI，是uniform resource identifier，統一資源標識符，用來唯一的標識一個資源。包括URL和URN
URI一般由三部組成：
①訪問資源的命名機制
②存放資源的主機名
③資源自身的名稱，由路徑表示，着重強調於資源。
示例：[scheme:][//host:port][path][?query][#fragment]
2，URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。URL一般由三部組成：
①協議(或稱爲服務方式)
②存有該資源的主機IP地址(有時也包括端口號)
③主機資源的具體地址。如目錄和文件名等
示例：<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<fragment>
關於持久連接（Persistent Connections）和狀態管理：
持久連接：只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態
好處：較少TCP連接的重複建立和斷開造成的額外開銷，減輕了服務器端的負載。
狀態管理：
HTTP是無狀態協議，不會對之前發生過的請求和響應進行管理，這樣可以減少服務器的CPU即內存資源的消耗，因此提出了Cookie技術，通過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。
Cookie技術：（Cookie具有不可跨域名性） 1，客戶端發送一個http請求到服務器端
2，服務器端發送的響應報文內包含一個叫Set-Cookie的首部字段信息，通知客戶端保存Cookie，併發送http響應給客戶端
3，下次客戶端向服務器端發送請求時，會自動在請求報文中加入Cookie的值後發送出去
4，服務器端發現客戶端發送過來的Cookie後，回去檢查是從哪個客戶端發；來的連接請求，並對比服務器的記錄，最後得到之前的狀態信息。
如果在cookie中設置了HttpOnly屬性，那麼通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊對cookie信息的竊取。
HTTP和HTTPS
HTTP的特點：
1，以明文方式發送內容，不提供任何方式的數據加密，不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。2，客戶端和服務器端無法驗證對方身份
3，端口是80
HTTPS的特點：
1，在HTTP的基礎上加入了SSL(Secure Sockets Layer)協議和TTL協議2，SSL依靠ca證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通信加密。
3，加密採用對稱加密，對稱加密的密鑰用服務器方的整數進行非對稱加密，服務器也可以驗證客戶端身份。
4，端口是443
5，主要作用可以分爲兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
爲什麼HTTPS安全
因爲網絡請求需要中間有很多的服務器路由器的轉發。中間的節點都可能篡改信息，而如果使用HTTPS，密鑰在你和終點站纔有。https之所以比http安全，是因爲他利用ssl/tls協議傳輸。它包含證書，卸載，流量轉發，負載均衡，頁面適配，瀏覽器適配，refer傳遞等。保障了傳輸過程的安全性攻擊與安全：
web注入攻擊
1，以服務器爲目標的主動攻擊
主動攻擊(active attack)是指攻擊者通過直接訪問Web應用，把攻擊代碼傳入的攻擊模式。由於該模式是直接針對服務器上的資源進行攻擊，因此攻擊者需要能夠訪問到那些資源。主動攻擊模式裏具有代表性的攻擊是SQL注入攻擊和OS命令注入攻擊
SQL注入攻擊的防範：通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。（SQL是數據庫語言，針對web應用使用的數據庫）
1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，可以通過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。2.不要把機密信息明文存放，請加密或者hash掉密碼和敏感的信息。
OS命令注入攻擊：系統提供命令執行類函數主要方便處理相關應用場景的功能.而當不合理的使用這類函數，同時調用的變量未考慮安全因素，就會執行惡意的命令調用，被攻擊利用。主要原因是服務端在調用系統命令時採用的是字符串連接的方式。在程序開發時OS命令注入攻擊(OS Command Injection)是指通過Web應用，執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險
1、少用系統命令，執行命令的參數儘量不要從外部獲取。
2，以服務器爲目標的被動攻擊
2，以服務器爲目標的被動攻擊
被動攻擊(passive attack)是指利用圈套策略執行攻擊代碼的攻擊模式。在被動攻擊過程中，攻擊者不直接對目標Web應用訪問發起攻擊被動攻擊通常的攻擊模式如下所示
步驟1：攻擊者誘使用戶觸發已設置好的陷阱，而陷阱會啓動發送已嵌入攻擊代碼的HTTP請求
步驟2：當用戶不知不覺中招之後，用戶的瀏覽器或郵件客戶端就會觸發這個陷阱
步驟3：中招後的用戶瀏覽器會把含有攻擊代碼的HTTP請求發送給作爲攻擊目標的Web應用，運行攻擊代碼
步驟4：執行完攻擊代碼，存在安全漏洞的Web應用會成爲攻擊者的跳板，可能導致用戶所持的Cookie等個人信息被竊取，登錄狀態中的用戶權限遭惡意濫用等後果
被動攻擊模式中具有代表性的攻擊是跨站腳本攻擊和跨站點請求僞造
跨站腳本攻擊(Cross-Site Scripting，XSS)是指通過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊。
例如：攻擊者在論壇中放一個看似安全的鏈接，騙取用戶點擊後，竊取cookie中的用戶私密信息；或者攻擊者在論壇中加一個惡意表單，當用戶提交表單的時候，卻把信息傳送到攻擊者的服務器中，而不是用戶原本以爲的信任站點。
跨站腳本攻擊有可能造成以下影響：利用虛假輸入表單騙取用戶個人信息；利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發送惡意請求；顯示僞造的文章或圖片。
1、避免直接在cookie 中泄露用戶隱私，例如email、密碼等等。
2、儘量採用POST 而非GET 提交表單
跨站點請求僞造(Cross-Site Request Forgeries，CSRF)攻擊是攻擊者通過各種方法僞造一個請求，模仿用戶提交表單的行爲，從而達到修改用戶的數據，或者執行特定任務的目的。跨站點請求僞造有可能會造成以下等影響：利用已通過認證的用戶權限更新設定信息等；利用已通過認證的用戶權限購買商品；利用已通過認證的用戶權限在留言板上發表言論
1、服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加僞隨機數。
2，驗證碼
保證表單提交的密碼字段不被泄露：
（1）使用HTTPS安全傳輸協議
（2）寫一個腳本對內容編碼後傳輸
驗證碼的作用：
防止惡意註冊和暴力破解，減少非正常請求，防止大量惡意註冊和登陸請求，影響網絡性能。
關於Etag
ETag：是實體標籤(Entity Tag)的縮寫。ETag一般不以明文形式相應給客戶端。在資源的各個生命週期中，它都具有不同的值，用於標識出資源的狀態。當資源發生變更時，如果其頭信息中一個或者多個發生變化，或者消息實體發生變化，那麼ETag也隨之發生變化。Etag由服務器端生成，客戶端通過If-Match或者說If-None-Match這個條件判斷請求來驗證資源是否修改。
情景一：若沒有過期，則不向服務器發送請求，直接使用緩存中的結果，此時我們在瀏覽器控制檯中可以看到 200 OK(from cache) ，此時的情況就是完全使用緩存，瀏覽器和服務器沒有任何交互的。
情景二：若已過期，則向服務器發送請求，此時請求中會帶上①中設置的文件修改時間，和Etag
然後，進行資源更新判斷。服務器根據瀏覽器傳過來的文件修改時間，判斷自瀏覽器上一次請求之後，文件是不是沒有被修改過；根據Etag，判斷文件內容自上一次請求之後，有沒有發生變化
情形一：若兩種判斷的結論都是文件沒有被修改過，則服務器就不給瀏覽器發index.html的內容了，直接告訴它，文件沒有被修改過，你用你那邊的緩存吧—— 304 Not Modified，此時瀏覽器就會從本地緩存中獲取index.html的內容。此時的情況叫協議緩存，瀏覽器和服務器之間有一次請求交互。
情形二：若修改時間和文件內容判斷有任意一個沒有通過，則服務器會受理此次請求，之後的操作同①
Expires和Cache-Control
Expires要求客戶端和服務端的時鐘嚴格同步。HTTP1.1引入Cache-Control來克服Expires頭的限制。如果max-age和Expires同時出現，則max-age有更高的優先級。