HTTP誕生
1989年為知識共享而誕生的Web，提出了3項WWW構建技術：
- 標準通用標記語言設為HTML（HyperText Markup Language，超文本標記語言）
- 文檔傳輸協議HTTP（HyperText Transfer Protocol，超文本傳輸協議）
- 文檔定位URL（Uniform Resource Locator，統一資源定位符）
HTTP特點
- 無狀態協議（不對請求和響應之間的通信狀態進行保存，無法實現狀態管理），所以后面引入Cookie和LocalStorage等技術。
- 請求方法有：GET（獲取資源）、POST（傳輸實體主體）、PUT（傳輸文件）、HEAD（獲得報文首部）、DELETE（刪除文件）、OPTIONS（詢問支持的方法）、TRACE（追蹤路徑）、CONNECT（要求用隧道協議連接代理）
- HTTP/1.1中，所有連接默認都是持久連接（keep-alive），即建立一次TCP連接后可以進行多次HTTP請求和響應
-
管線化，即可并行發送多個請求。
瀏覽器并發數 -
Cookie：
1）客戶端發送請求報文；
2）服務器生成包含Cookie信息的響應報文（Set-Cookie字段包含sid）；
3）客戶端發送帶Cookie信息的請求報文（Cookie字段的sid）；
HTTP報文
- HTTP報文本身是由多行數據構成的字符串文本。
-
請求報文與相應報文的結構
請求報文與相應報文的結構
報文實例
請求行：請求的方法、請求URI、HTTP版本
狀態行：表明響應結果的狀態碼、原因短語、HTTP版本
- 壓縮傳輸的內容編碼（gzip、compress、deflate、identity）、分割發送的分塊傳輸編碼
- MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）
HTTP狀態碼
1） 200 OK ；請求正常處理
2） 204 No Content ；請求處理成功，但沒有資源可返回
3） 206 Partial Content ； 客戶端進行了范圍請求，服務器成功處理
4） 301 Moved Permanently ； 永久性重定向，即請求的資源已經被分配了新的URI
5） 302 Found ； 臨時重定向，即請求的資源臨時被分配了新的URI
6） 303 See Other ； 表示請求對應的資源存在著另一個URI，應使用GET方法定向獲取
7） 304 Not Modified ； 服務器資源未改變，可直接使用客戶端未過期的緩存（與重定向無關）
8） 307 Temporary Redirect ； 臨時重定向（會強制瀏覽器不能將POST改為GET方法）
9） 400 Bad Request ； 表示請求報文中存在語法錯誤
10） 401 Unauthorized ； 表明請求需要通過HTTP認證，若之前已請求過一次，則表示用戶認證失敗
11） 403 Forbidden ； 服務器拒絕該資源的訪問
12） 404 Not Found ； 服務器無法找到請求的資源
13） 500 Internal Server Error ； 服務器發生內部錯誤
14） 503 Service Unavailable ； 服務器超負荷，無法處理請求
有些時候，狀態碼和狀況會不一致
說明：301和302狀態碼都是重定向，但區別是301是永久重定向，302為臨時重定向。若客戶端將URL保存為書簽，那么301就會去更新書簽，而302不會去更新書簽。
重定向：服務器告訴客戶端，需要重新發送請求到新的URL。服務器返回302狀態碼時，設置響應頭的Location字段。
HTTPS（HTTP over SSL，包括加密、認證、完整性保護）
- HTTP的缺點
1）通信使用明文（不加密），內容可能會被竊聽；—>加密
2）不驗證通信方的身份，可能遭遇偽裝；—>驗證身份
例子：偽裝的web服務器；偽裝的客戶端；無訪問權限的通信方；無法判定無意義請求，可能遭受DoS攻擊；
3） 無法證明報文的完整性，內容可能遭遇篡改； -
加密
- 通信的加密、內容的加密
- 加密方式：對稱密鑰加密（共享密鑰加密）、非對稱密鑰加密（公開密鑰加密）
對稱加密：加密和解密使用相同的密鑰；問題：密鑰如何安全到達對方；
非對稱加密：一對密鑰（公開密鑰+私有密鑰）；
方式：服務器擁有一對密鑰，當需要加密傳輸時，服務器將公開密鑰分發給客戶端，客戶端利用公開密鑰加密發送密文給服務器，服務器利用私有密鑰解密；
報文+公開密鑰=密文；密文+公開密鑰!=報文（技術上異常困難，離散對數求值）；
非對稱加密相比對稱加密速度慢； -
HTTPS采用混合加密機制（非對稱加密+對稱加密）
利用非對稱加密 傳輸 對稱加密時所需的 密鑰，然后采用對稱加密 傳輸主體；
- 如何判斷服務器發來的公開密鑰的真實性？
借用第三方數字認證機構（CA，Certificate Authority）
1）服務器將自己的公開密鑰登錄至CA，申請公鑰證書
2）CA頒發公鑰證書（公開密鑰+CA數字簽名）
3）服務器向客戶端發送公鑰證書
4）客戶端利用瀏覽器內置的CA公鑰驗證 該公鑰證書的 有效性
5）客戶端使用公開密鑰對報文加密后發送 - MAC（Message Authentication Code）報文摘要檢測報文的完整性
- 用以確認客戶端的客戶端證書
用戶得自行安裝客戶端證書，一般用于網上銀行 - 補充：抓包工具：wireshark，tcpdump
HTTP緩存
-
HTTP緩存分為強制緩存和對比緩存，兩類緩存規則可以同時存在，強制緩存優先級高于對比緩存。
HTTP緩存 -
強制緩存（Expires/Cache-Control）
HTTP 1.0中Expires的值為服務端返回的資源到期時間，所以要求時鐘同步
HTTP1.1中使用Cache-Control
Cache-Control -
對比緩存（Etag / If-None-Match 或者Last-Modified / If-Modified-Since ）
對比緩存生效時，狀態碼為304，只返回header
- Etag / If-None-Match（優先級高）
第一次請求時，服務器通過Etag告訴客戶端資源的唯一標識符
再次請求時，客戶端通過If-None-Match告訴服務器該資源緩存數據庫中的資源標識符，服務器將其進行校驗比對，若資源發生變化（資源標識符變化），則返回修改過的資源，200；若資源未被修改過，則返回304。 - Last-Modified / If-Modified-Since
第一次請求時，服務器在響應請求時，通過Last-Modified告訴瀏覽器資源的最后修改時間。
再次請求時，客戶端通過If-Modified-Since發送資源的最后修改時間，服務器接收到后進行校驗對比，若資源在該時間之后被修改過，則返回修改過的資源，200；若資源未被修改過，則返回304。
cnblog講解
個人理解：客戶端緩存數據庫中的資源帶有Expires的時間、Cache-Control的時間間隔、If-None-Match的資源標識符 或者 If-Modified-Since的標識時間。瀏覽器在請求相應資源時，分別判斷資源的各個標識符，采用緩存資源或者發送相應的http頭部信息給服務器端進行校驗。
get與post區別
- get可被緩存
- get請求保留在瀏覽器歷史紀錄中
- get請求可被收藏為書簽
- get請求不應在處理敏感數據時使用，get請求在url中發送，post請求在http消息主體中發送。
- get請求長度有限制(url的限制),post請求對數據長度沒有要求
- get只能是url編碼
- get參數會顯示在url中
- 后退和刷新，post會被重新提交
- get是冪等的，意味著對同一URL的多個請求應該返回同樣的結果。
- 對資源的增，刪，改，查操作，其實都可以通過GET/POST完成，不需要用到PUT和DELETE
get與post區別
web安全
- 主動攻擊：
1） SQL注入攻擊
方式：把SQL命令插入到表單中提交或URL中的查詢字符串中，以欺騙服務器執行惡意的SQL命令；
解決方法：對用戶的輸入進行校驗、不使用管理員權限的數據庫連接、機密信息加密存放；
2） OS命令注入攻擊（利用web應用的漏洞）； - 被動攻擊：
1）跨站腳本攻擊XSS
方式：在正規網站的URL查詢字段中加入script標簽，使客戶端在瀏覽正規網站的同時，運行JS代碼；
解決辦法：對用戶的輸入進行校驗、寫到頁面的內容先進行編碼、用適當的方法對 HTML，JS 進行轉義、將Set-Cookie設置為HttpOnly，則通過JS腳本無法讀取到cookie信息；
2）跨站點請求偽造（CSRF）
方式：用戶點擊了正規網站和黑客網站，黑客網站向往正規網站服務器發送了請求，這個請求會攜帶用戶本地瀏覽器的cookie，所以得以成功跨站點請求偽造。
解決辦法：1）設置驗證HTTP Referer字段，以確保請求的來源網站的合法性。2）設置token。
CSDN博客
3）HTTP首部注入（攻擊者在響應首部字段內插入換行，添加任意響應首部或主體）、
4）郵件首部注入攻擊
其他攻擊：DoS攻擊（拒絕服務攻擊，向服務器發送大量請求，造成服務器資源過載）
DDoS（分布式拒絕服務攻擊，常利用感染病毒的計算機作為攻擊者的攻擊跳板）
CSDN博客
