一、Http
1.URL
URL:HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建⽴立連接。URL是一種特殊 類型的URI，包含了⽤於查找某個資源的足夠的信息 URL,全稱是Uniform Resource Locator, 中⽂文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。
URL組成：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
- 協議部分：該URL的協議部分爲“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協 議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後⾯面的“//”爲分隔符
- 域名部分：該URL的域名部分爲“www.aspxfans.com”。一個URL中，也可以使用IP地址作爲域名使用
- 端口部分：跟在域名後⾯面的是端口，域名和端口之間⽤用“:”作爲分隔符。端口不是一個URL必須的部分， 如果省略端口部分，將採⽤用默認端⼝口
- 虛擬目錄部分：從域名後的第一個“/”開始到最後一個“/”爲止，是虛擬⽬目錄部分。虛擬⽬目錄也不是一個 URL必須的部分。本例例中的虛擬⽬目錄是“/news/”
- 文件名部分：從域名後的最後⼀一個“/”開始到“？”爲⽌止，是文件名部分，如果沒有“?”,則是從域名後的最後 一個“/”開始到“#”爲止，是文件部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是文件名部分。本例例中的⽂文件名是“index.asp”。文件名部分也不是⼀一個URL必須的部分，如果省略略該部分，則使⽤用默認的⽂文件名
- 錨部分：從“#”開始到最後，都是錨部分。本例例中的錨部分是“name”。錨部分也不不是一個URL必須的部分
- 參數部分：從“？”開始到“#”爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例例中的參數部分 爲“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間⽤用“&”作爲分隔符。
2.Http協議
Http協議：HTTP協議（HyperText Transfer Protocol，超⽂文本傳輸協議）是因特網上應用最爲廣泛的一種網絡傳輸協議，所有的WWW文件都必須遵守這個標準。HTTP是一個基於TCP/IP通信協議來傳遞數據（HTML ⽂文件, 圖片⽂文件, 查詢結 果等）。
原理：HTTP協議定義Web客戶端如何從Web服務器器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採⽤了請求/響應模型。客戶端向服務器 發送一個請求報⽂文，請求報⽂文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作爲響應，響應的內容包括協議的版本、成功 或者錯誤代碼、服務器器信息、響應頭部和響應據。
一個請求的過程：
- 瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
- 解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器建立TCP連接;
- 瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文作爲 TCP 三次握手的第三個報文的數據發送給服務器;
- 服務器對瀏覽器請求作出響應，並把對應的 html 文本發送給瀏覽器; 釋放 TCP連接;
- 瀏覽器將該 html 文本並顯示內容;
Http協議是基於TCP/IP協議上的應用層協議
Http特點：
- 基於請求-響應的模式：HTTP協議規定,請求從客戶端發出,最後服務器端響應該請求並返回。換句話說,肯定是先從客戶端開始建立通信的,服務器器端在沒有接收到請求之前不會發送響應。
- 無狀態保存：HTTP是一種不保存狀態,即無狀態(stateless)協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別,協議對於發送過的請求或響應都不做持久化處理。HTTP/1.1雖然是無狀態協議,但爲了 實現期望的保持狀態功能, 於是引入了Cookie技術。有了Cookie再用HTTP協 通信,就可以管理理狀態了
- 無連接：無連接的含義是限制每次連接只處理理一個請求。服務器器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種⽅方式可以節省傳輸時間，並且 可以提高併發性能，不能和每個用戶建立⻓長久的連接，請求一次相應一次，服務 端和客戶端就中斷了。
注：早期的http協議是一個請求一個響應之後，直接就斷開了了，但是現在的http協 議1.1版本不是直接就斷開了了，⽽而是等幾秒鐘，這⼏幾秒鐘是等什麼呢，等着用戶有後續的操作，如果用戶在這幾秒鐘之內有新的請求，那麼還是通過之前的連接通道來收發消息，如果過了這⼏秒鐘用戶沒有發送新的請求，那麼就會斷開連接，這樣可 以提⾼高效率，減少短時間內建⽴立連接的次數，
3.Http請求與響應
Http的請求：
- HTTP請求協議包括：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成
- 請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本。
![在這裏插入圖片描述]()
Httpx協議請求方法：
- GET 請求指定的頁面信息，並返回實體主體。
- HEAD 類似於get請求，只不不過返回的響應中沒有具體的內容，用於獲取報頭
- POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳⽂文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
- PUT 從客戶端向服務器器傳送的數據取代指定的文檔的內容。
- DELETE 請求服務器器刪除指定的頁面。
- CONNECT HTTP/1.1協議中預留給能夠將連接改爲管道方式的代理服務器。
- OPTIONS 允許客戶端查看服務器器的性能。
- TRACE 回顯服務器器收到的請求，主要⽤用於測試或診斷。
GET和POST的區別：
- GET提交的數據會放在URL之後，以?分割URL和傳輸數據，參數之間以&相連，如 EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的 Body中.
- GET提交的數據大小有限制（因爲瀏覽器對URL的長度有限制），⽽而POST方法提交的數據沒有限制.
- GET方式提交數據，會帶來安全問題，⽐比如⼀一個登錄⻚頁⾯面，通過GET方式提交數據時，⽤戶名和密碼將出現在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼.
Http響應：
-
HTTP響應協議包括：四個部分，分別是：狀態行、消息報頭、空行和響應正文：
![在這裏插入圖片描述]()
-
HTTP狀態碼（狀態代碼有三位數字組成，第一個數字定義了響應的類別）：
- 1xx：指示信息--表示請求已接收，繼續處理理
- 2xx：成功–表示請求已被成功接收、理理解、接受
- 200 ok //客戶端請求成功
- 3xx：重定向–要完成請求必須進行更進一步的操作
- 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
- 400 Bad Request //客戶端請求有語法錯誤，不能被服務器理解
- 401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域⼀起使用
- 403 Forbidden // 服務器收到請求，但拒絕提供服務
- 404 Not Found // 請求資源不存在，錯誤的URL
- 5xx：服務器端錯誤–服務器未能實現合法的請求
- 500 Internal Server Error //服務器發送不可預期的錯誤
- 503 Server Unavailable // 服務器當前不能處理客戶的請求，一段時間後可能回覆正常
請求過程：
二、Https
http不足：
- 通信使⽤明⽂，內容可能會被竊聽 —— 加密通信線路
- 不驗證通信⽅，可能遭遇僞裝 —— 證書
- ⽆法驗證報⽂的完整性，可能已被篡改 —— 數字簽名
HTTPS：HTTP 協議中沒有加密機制,但可以通過和 SSL(Secure Socket Layer, 安全套接層 )或 TLS(Transport Layer Security, 安全層傳輸協議)的組合使⽤,加密 HTTP 的通信內 容。屬於通信加密，即在整個通信線路中加密。
HTTP + 加密 + 認證 + 完整性保護 = HTTPS（HTTP Secure ）
HTTPS 採⽤共享密鑰加密（對稱）和公開密鑰加密（⾮對稱）兩者並⽤的混合加密機制。若密鑰能夠實現安全交換,那麼有可能會考慮僅使⽤公開密鑰加密來通 信。但是公開密鑰加密與共享密鑰加密相⽐,其處理速度要慢。
三、對稱加密與非對稱加密
1.對稱加密
對稱加密的特點是文件加密和解密都是使用相同的密鑰，因此密鑰需要在加密方和解密方傳輸，導致密鑰容易泄露和被破解。
2.非對稱加密
非對稱加密算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密， 根據公開的公鑰無法測算出另一不不公開的密鑰（即爲私鑰），而私有密鑰保存在解密方本地，只要解密方自己不泄露出去，私鑰就沒有泄露的可能。非對稱加密很好的克服對稱加密算法的弱點
常常使用的SSH’就是非對稱加密
HTTPS不足：
- 加密解密過程複雜，導致訪問速度慢
- 加密需要想認證機構付費
- 整個頁面的請求都要使用HTTPS