① 計算機網路-Http/Https基礎
一、前言
主要包括：1、http基礎：TCP/IP，TCP協議，IP協議，DNS協議，URI與URL；
2、http協議：http報文，http方法，http狀態碼，常見問題
名詞解釋：
（1）HTTP（HyperText Transfer Protocol）超文本傳輸協議
（2）URL（Uniform Resource Locator）統一資源定位符
（3）URI（Uniform Resource Identifer）統一資源標識符
（4）TCP（Transmission Control Protocol）傳輸控制協議
（5）IP（Internet Protocol）網際協議
（6）UDP（User Data Protocol）用戶數據報協議
（7）MAC地址（Media Access Control）媒體訪問控制地址／物理地址／硬體地址
（8）ARP協議（Address Resolution Protocol）地址解析協議
二、HTTP基礎
2.1TCP/IP
TCP/IP是互聯網相關的各類協議族的總稱，而http是TCP/IP協議族中的一個子集。
TCP/IP協議族可以分為四層：
（1）應用層：決定向用戶提供 應用服務時通信的活動 ，TCP/IP協議族內預存了各類通用的應用服務，如：http，ftp，dns等。
（2）傳輸層：提供處於網路連接中的兩台計算機之間的 數據傳輸 ，包含兩個協議：tcp，udp。
（3）網路層：用來處理 網路上流動的數據包 ，在眾多的選項中選擇一條傳輸線路，將數據包傳送到對方計算機。包含的協議：IP協議。
（4）數據鏈路層：用來 處理連接網路的硬體 部分。
2.2 IP協議
IP協議屬於網路層，負責處理網路上流動的數據包。為了保證傳送成功，需要滿足各類條件，其中兩個重要的條件時IP地址和MAC地址。
（1）IP地址，指明了節點被分配到的地址；
（2）MAC地址，指網卡所屬的固定地址；
（3）IP地址可以和MAC地址進行配對，IP地址可以變換，但是MAC地址基本上不會更改；
（4）使用ARP地址解析協議可以根據通信方的IP地址反查出對應的MAC地址
2.3 TCP協議
TCP協議位於傳輸層，提供 可靠的位元組流服務 （也就是說，將大數據分隔成以報文段為單位的數據包進行管理）。
為了確保數據准確無誤的到達目標處，TCP協議通常採用三次握手策略。
如果在握手的過程中某一個階段莫名的 中斷 了， TCP協議會再次以相同的順序發送相同的數據包 。
2.4DNS協議
DNS協議位於應用層，提供域名到IP地址之間的解析服務。
2.5 URI和URL
URI是某一個協議方案表示的 資源的定位標識符 ，協議方案是指訪問資源所使用的協議類型，如：http，ftp，file等。
URL用字元串標識某一個互聯網資源 ，而 URL表示資源的地點，URL是URI的子集。
2.6 HTTP協議
HTTP協議用於客戶端和伺服器端之間的通信。請求必定由客戶端發出，而伺服器端回復響應。
HTTP協議不保存狀態，為 無狀態協議 。這是為了更快的處理大量事務，確保協議的可伸縮性而特意設計的。
但是隨著Web的不斷發展，這一特性也引發了一些問題，如：如何保持登錄狀態、如何記錄用戶信息等，為了解決這一問題，引入了Cookie技術。
2.6.1常見狀態碼
2XX 成功
200 OK，表示從客戶端發來的請求在伺服器端被正確處理
204 No content，表示請求成功，但響應報文不含實體的主體部分
205 Reset Content，表示請求成功，但響應報文不含實體的主體部分，但是與 204 響應不同在於要求請求方重置內容
206 Partial Content，進行范圍請求
3XX 重定向
301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL
303 see other，表示資源存在著另一個 URL，應使用 GET 方法獲取資源
304 not modified，表示伺服器允許訪問資源，但因發生請求未滿足條件的情況
307 temporary redirect，臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求
4XX 客戶端錯誤
400 bad request，請求報文存在語法錯誤
401 unauthorized，表示發送的請求需要有通過 HTTP 認證的認證信息
403 forbidden，表示對請求資源的訪問被伺服器拒絕
404 not found，表示在伺服器上沒有找到請求的資源
5XX 伺服器錯誤
500 internal sever error，表示伺服器端在執行請求時發生了錯誤
501 Not Implemented，表示伺服器不支持當前請求所需要的某個功能
503 service unavailable，表明伺服器暫時處於超負載或正在停機維護，無法處理請求
2.6.2HTTP報文頭部（HTTP首部）
| 通用欄位 | ** 作用** |
| Cache-Control | 控制緩存的行為 |
| Connection | 瀏覽器想要優先使用的連接類型，比如：keep-alive |
| Date | 創建報文時間 |
| Pragma | 報文指令 |
| Via | 代理伺服器相關信息 |
| Transfer-Encoding | 傳輸編碼方式 |
| Upgrade | 要求客戶端升級協議 |
| Warning | 在內容中可能存在錯誤 |
| ** 請求欄位** | ** 作用** |
| Accept | 能正確接收的媒體類型 |
| Accept-Charset | 能正確接收的字元集 |
| Accept-Encoding | 能正確接收的編碼格式列表 |
| Accept-Language | 能正確接收的語言列表 |
| Expect | 期待服務端的指定行為 |
| From | 請求方郵箱地址 |
| Host | 伺服器的域名 |
| If-Match | 兩端資源標記比較 |
| If-Modified-Since | 本地資源未修改返回 304（比較時間） |
| If-None-Match | 本地資源未修改返回 304（比較標記） |
| User-Agent | 客戶端信息 |
| Max-Forwards | 限制可被代理及網關轉發的次數 |
| Proxy-Authorization | 向代理伺服器發送驗證信息 |
| Range | 請求某個內容的一部分 |
| Referer | 示瀏覽器所訪問的前一個頁面 |
| TE | 傳輸編碼方式 |
| 響應欄位 | 作用 |
| Accept-Ranges | 是否支持某些種類的范圍 |
| Age | 資源在代理緩存中存在的時間 |
| ETag | 資源標識 |
| Location | 客戶端重定向到某個 URL |
| Proxy-Authenticate | 向代理伺服器發送驗證信息 |
| Server | 伺服器名字 |
| WWW-Authenticate | 獲取資源需要的驗證信息 |
| 實體欄位 | 作用 |
| Allow | 資源的正確請求方式 |
| Content-Encoding | 內容的編碼格式 |
| Content-Language | 內容使用的語言 |
| Content-Length | request body 長度 |
| Content-Location | 返回數據的備用地址 |
| Content-MD5 | Base64加密格式的內容 MD5檢驗值 |
| Content-Range | 內容的位置范圍 |
| Content-Type | 內容的媒體類型 |
| Expires | 內容的過期時間 |
| Last_modified | 內容的最後修改時間 |
2.6.3 HTTP方法
三****、HTTPS基礎
HTTPS 還是通過了 HTTP 來傳輸信息，但是信息通過 TLS 協議進行了加密。
3.1 TLS
TLS 協議位於傳輸層之上，應用層之下。首次進行 TLS 協議傳輸需要兩個 RTT ，接下來可以通過 Session Resumption 減少到一個 RTT。（RTT表示發送端發送數據到接收到對端數據所需的往返時間）
在 TLS 中使用了兩種加密技術，分別為：對稱加密和非對稱加密。
對稱加密：
對稱加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。
非對稱加密：
有公鑰私鑰之分，公鑰所有人都可以知道，可以將數據用公鑰加密，但是將數據解密必須使用私鑰解密，私鑰只有分發公鑰的一方才知道。
3.2 TLS 握手過程如下圖：
（1）客戶端發送一個隨機值，需要的協議和加密方式
（2）服務端收到客戶端的隨機值，自己也產生一個隨機值，並根據客戶端需求的協議和加密方式來使用對應的方式，發送自己的證書（如果需要驗證客戶端證書需要說明）
（3）客戶端收到服務端的證書並驗證是否有效，驗證通過會再生成一個隨機值，通過服務端證書的公鑰去加密這個隨機值並發送給服務端，如果服務端需要驗證客戶端證書的話會附帶證書
（4）服務端收到加密過的隨機值並使用私鑰解密獲得第三個隨機值，這時候兩端都擁有了三個隨機值，可以通過這三個隨機值按照之前約定的加密方式生成密鑰，接下來的通信就可以通過該密鑰來加密解密
通過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通信，但是因為非對稱加密損耗的性能比對稱加密大，所以在 正式傳輸數據 時，兩端使用 對稱加密 的方式通信。
PS：以上說明的都是 TLS 1.2 協議的握手情況 ，在 1.3 協議中，首次建立連接只需要一個 RTT，後面恢復連接不需要 RTT 了。
四、GET和POST的區別
從技術上說：
1、get請求能緩存，post不能；
2、post相對於get來說，安全一點點，因為get請求都會包含在URL里，會被瀏覽器保存歷史記錄，post不會，但是在抓包的情況是一樣的。
3、post可以request body來傳遞比get更多的數據，get米有這個技術。
4、url長度有限制，會影響get請求，長度限制是瀏覽器限制規定的，不是rfc（互聯網通信協議）規定的。
5、post支持更多的 編碼類型 且不對 數據類型 限制
② 手機上網連接類型HTTP是指什麼
TTP是一個屬於應用層的面向對象的協議，由於其簡捷、快速的方式，適用於分布式超媒體信息系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規范化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。HTTP協議的主要特點可概括如下：1.支持客戶/伺服器模式。2.簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯系的類型不同。由於HTTP協議簡單，使得HTTP伺服器的程序規模小，因而通信速度很快。3.靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。4.無連接：無連接的含義是限制每次連接只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在伺服器不需要先前信息時它的應答就較快。2.2 HTTP協議的幾個重要概念1.連接(Connection)：一個傳輸層的實際環流，它是建立在兩個相互通訊的應用程序之間。2.消息(Message)：HTTP通訊的基本單位，包括一個結構化的八元組序列並通過連接傳輸。3.請求(Request)：一個從客戶端到伺服器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號4.響應(Response)：一個從伺服器返回的信息包括HTTP協議的版本號、請求的狀態(例如「成功」或「沒找到」)和文檔的MIME類型。5.資源(Resource)：由URI標識的網路數據對象或服務。6.實體(Entity)：數據資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的本身內容。7.客戶機(Client)：一個為發送請求目的而建立連接的應用程序。8.用戶代理(User agent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。9.伺服器(Server)：一個接受連接並對請求返回信息的應用程序。10.源伺服器(Origin server)：是一個給定資源可以在其上駐留或被創建的伺服器。11.代理(Proxy)：一個中間程序，它可以充當一個伺服器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的伺服器中。一個代理在發送請求信息之前，必須解釋並且如果可能重寫它。代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處理沒有被用戶代理完成的請求。12.網關(Gateway)：一個作為其它伺服器中間缺顫媒介的伺服器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源伺服器；發出請求的客戶機並沒有意識到它在同網關打交道。網關經常作為通過防火牆的伺服器端的門戶，網關還可以作為一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。13.通道(Tunnel)：是作為兩個連接中繼的中介程序。一旦激活，通道便被認為不屬於HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道悶扮散被經常使用。14.緩存(Cache)：反應信息的局域存儲。2.3 HTTP協議的運作方式HTTP協議是基於請求／響應範式的。一個客戶機與伺服器建立連接後，發送一個請求給伺服器，請求方式的格式為，統一資源標識符、協議版本號，後邊是 MIME信息包括請求修飾符、客戶機信息和可能的內容。伺服器接到請求後，給予相應的響應螞氏信息，其格式為一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括伺服器信息、實體信息和可能的內容。許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源伺服器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源伺服器(O)之間通過一個單獨的連接來完成(見圖2-1)。圖2-1當一個或多個中介出現在請求／響應鏈中時，情況就變得復雜一些。中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)。一個代理根據URI的絕對格式來接受請求，重寫全部或部分消息，通過URI的標識把已格式化過的請求發送到伺服器。網關是一個接收代理，作為一些其它伺服器的上層，並且如果必須的話，可以把請求翻譯給下層的伺服器協議。一個通道作為不改變消息的兩個連接之間的中繼點。當通訊需要通過一個中介(例如：防火牆等)或者是中介不能識別消息的內容時，通道經常被使用。圖2-2上面的圖2-2表明了在用戶代理(UA)和源伺服器(O)之間有三個中介(A,B和C)。一個通過整個鏈的請求或響應消息必須經過四個連接段。這個區別是重要的，因為一些HTTP通訊選擇可能應用於最近的連接、沒有通道的鄰居，應用於鏈的終點或應用於沿鏈的所有連接。盡管圖2-2是線性的，每個參與者都可能從事多重的、並發的通訊。例如，B可能從許多客戶機接收請求而不通過A，並且／或者不通過C把請求送到A，在同時它還可能處理A的請求。任何針對不作為通道的匯聚可能為處理請求啟用一個內部緩存。緩存的效果是請求／響應鏈被縮短，條件是沿鏈的參與者之一具有一個緩存的響應作用於那個請求。下圖說明結果鏈，其條件是針對一個未被UA或A加緩存的請求，B有一個經過C來自O的一個前期響應的緩存拷貝。圖2-3在Internet上，HTTP通訊通常發生在TCP/IP連接之上。預設埠是TCP 80，但其它的埠也是可用的。但這並不預示著HTTP協議在Internet或其它網路的其它協議之上才能完成。HTTP只預示著一個可靠的傳輸。以上簡要介紹了HTTP協議的宏觀運作方式，下面介紹一下HTTP協議的內部操作過程。首先，簡單介紹基於HTTP協議的客戶/伺服器模式的信息交換過程，如圖2-4所示，它分四個過程，建立連接、發送請求信息、發送響應信息、關閉連接。圖2-4在WWW中，「客戶」與「伺服器」是一個相對的概念，只存在於一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作為伺服器。WWW伺服器運行時，一直在TCP80埠(WWW的預設埠)監聽，等待連接的出現。下面，討論HTTP協議下客戶/伺服器模式中信息交換的實現。 1.建立連接 連接的建立是通過申請套接字(Socket)實現的。客戶打開一個套接字並把它約束在一個埠上，如果成功，就相當於建立了一個虛擬文件。以後就可以在該虛擬文件上寫數據並通過網路向外傳送。2.發送請求打開一個連接後，客戶機把請求消息送到伺服器的停留埠上，完成提出請求動作。HTTP/1.0 請求消息的格式為：請求消息=請求行(通用信息|請求頭|實體頭) CRLF[實體內容]請求 行=方法 請求URL HTTP版本號 CRLF方 法=GET|HEAD|POST|擴展方法U R L=協議名稱+宿主名+目錄與文件名請求行中的方法描述指定資源中應該執行的動作，常用的方法有GET、HEAD和POST。不同的請求對象對應GET的結果是不同的，對應關系如下：對象 GET的結果文件 文件的內容程序 該程序的執行結果資料庫查詢 查詢結果HEAD——要求伺服器查找某對象的元信息，而不是對象本身。POST——從客戶機向伺服器傳送數據，在要求伺服器和CGI做進一步處理時會用到POST方法。POST主要用於發送HTML文本中FORM的內容，讓CGI程序處理。一個請求的例子為：GET http://networking.zju.e.cn/zju/index.htm HTTP/1.0頭信息又稱為元信息，即信息的信息，利用元信息可以實現有條件的請求或應答。請求頭——告訴伺服器怎樣解釋本次請求，主要包括用戶可以接受的數據類型、壓縮方法和語言等。實體頭——實體信息類型、長度、壓縮方法、最後一次修改時間、數據有效期等。實體——請求或應答對象本身。3.發送響應伺服器在處理完客戶的請求之後，要向客戶機發送響應消息。HTTP/1.0的響應消息格式如下：響應消息=狀態行(通用信息頭|響應頭|實體頭) CRLF 〔實體內容〕狀 態 行=HTTP版本號 狀態碼 原因敘述狀態碼表示響應類型1×× 保留2×× 表示請求成功地接收3×× 為完成請求客戶需進一步細化請求4×× 客戶錯誤5×× 伺服器錯誤響應頭的信息包括：服務程序名，通知客戶請求的URL需要認證，請求的資源何時能使用。4.關閉連接客戶和伺服器雙方都可以通過關閉套接字來結束TCP/IP對話