JavaEE基礎(03)：Http請求詳解，握手揮手流程簡介

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、Http協議簡介

一、概念說明

HTTP超文本傳輸協議,是用於從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議，基於TCP/IP通訊協議來傳遞數據：HTML文件、圖片、查詢數據等。HTTP協議基於客戶端-服務端架構模式。瀏覽器做爲HTTP客戶端經過URL向服務端即WEB服務器發送請求。Web服務器根據接收到的請求後，處理完請求後向客戶端發送響應信息。

二、協議特色

• 簡單快速

請求服務器時，只需傳送請求方法和路徑。請求類型經常使用GET、POST。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

• 靈活：

HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

• 無鏈接

無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

• 無狀態

HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態則後續處理須要前面的信息，沒有則須要從新請求，這樣可能致使每次鏈接傳送的數據量增大。

• 支持客戶/服務器模式

2、Http請求詳解

一、請求接口

public class ServletOneImpl extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        System.out.println("doGet...");
        response.setContentType("text/html;charset=utf-8");
        String userName = request.getParameter("userName") ;
        response.getWriter().print("Hello:"+userName);
    }
    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        System.out.println("doPost...");
        response.setContentType("text/html;charset=utf-8");
        String userName = request.getParameter("userName") ;
        response.getWriter().print("Hello:"+userName);
    }
}

二、請求內容

• Get請求

地址：http://localhost:6003/servletOneImpl?userName=cicada

GET /servletOneImpl?userName=cicada HTTP/1.1
Host: localhost:6003
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
DNT: 1
Referer: http://localhost:6003/request.jsp
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: JSESSIONID=183C0F91B49A025C795FBC3067B37BC8

• Post請求

地址：http://localhost:6003/servletOneImpl

POST /servletOneImpl HTTP/1.1
Host: localhost:6003
Connection: keep-alive
Content-Length: 15
Cache-Control: max-age=0
Origin: http://localhost:6003
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
DNT: 1
Referer: http://localhost:6003/request.jsp
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: JSESSIONID=183C0F91B49A025C795FBC3067B37BC8

三、參數說明

• Method：常見GET 和 POST，另外還有DELETE、PUT 等 ;
• URI：/servletOneImpl，和Host組成請求的URL ;
• HTTP/1.1：傳輸協議Http，版本1.1 ;
• Host：請求資源所在的主機和端口 ;
• Connection：TCP鏈接默認不關閉，能夠被多個請求複用 ;
• Upgrade-Insecure-Requests：瀏覽器再也不顯示 https 頁面中的 http 請求警報 ;
• Content-Length：指示實體主體大小，以字節爲單位十進制數，發送到接收方。
• Cache-Control：max-age=0使用緩存，可是會當即過時 ;
• User-Agent：客戶端瀏覽器類型、版本、操做系統等信息 ;
• Content-Type: 請求或響應中，傳輸資源類型信息 ;
• Origin：當前請求出自的站點 ;
• Accept：客戶端聲明本身能夠接收的資源格式 ;
• DNT: 請求禁用用戶追蹤 ;
• Referer：告訴服務器該網頁是從哪一個頁面連接過來 ;
• Accept-Encoding: 聲明瀏覽器支持的編碼類型 ;
• Accept-Language: 聲明瀏覽器支持的語言類型 ;
• Cookie: 辨識存儲在客戶端的緩存數據，一般會加密 ;

四、GET和POST區別

• 瀏覽器端

從瀏覽器角度看這個兩種請求的區別：GET方式讀取資源，好比Get到靜態頁面，即便屢次讀取不會對訪問數據產生影響，也被稱爲"冪等"操做。POST方式在頁面中定義表單，提交表單會把數據提交到服務器，並且多數狀況下會產生數據，好比經常使用的保存數據接口，並不是"冪等"操做，不冪等也就意味着不能隨意屢次執行。

• 服務接口

這裏指用Ajax程序請求服務接口，提交的請求類型。或者其餘Http請求工具類，還有狀況是微服務中各類Feign接口間的請求。這種狀況接口發送請求時，限制相對較少，好比REST風格接口經常使用GET、POST、PUT、DELETE，幾種方式分別獲取、建立、更新、刪除 資源，

3、Https請求協議

一、Https簡介

• 基礎概念

HTTPS：是以安全爲準則的HTTP通道，是HTTP的安全版，在HTTP請求上加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。簡單來講，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。

• 安全模式

HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

二、Https工做原理

(1)客戶基於Https方式訪問服務端，與服務器創建SSL鏈接 ;
(2)服務端收到請求後，會將包含公鑰的證書傳送給客戶端 ;
(3)客戶端與服務端進行協調SSL鏈接的安全等級，也就是指加密的等級 ;
(4)客戶端根據雙方贊成的安全等級，創建會話密鑰，使用公鑰將會話密鑰加密，並傳送給服務端 ;
(5)服務端使用私鑰解密出會話中傳遞的內容，使用會話密鑰加密與客戶端之間的通訊 ;

三、Https和Http區別

• 安全證書

Https協議須要到CA申請證書，通常免費證書較少，於是須要必定費用。

• 數據傳輸

Http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

• 鏈接方式

Http和Https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

4、TCP傳輸協議

一、TCP協議簡介

TCP傳輸控制協議是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議。TCP用意在於適應並支持多網絡應用的分層協議層次結構。

二、三次握手

這一場景在生活中能夠描述爲通話：

甲：你好,我是甲,你是乙嗎;
乙：你好甲：我是乙;
甲：正好找你有點事情,身份確認：

• 第一次握手

客戶端主動向服務器發起請求鏈接，請求報文中發送SYN=1，此時隨機生成初始序列號seq=x，此時，客戶端進程進入SYN-SENT同步已發送狀態。

• 第二次握手

服務端收到請求報文後，確認客戶的SYN，若是請求沒有拒絕，則發出確認報文。報文中應該ACK=1，SYN=1，確認號是ack=x+1，同時本身也發送一個SYN包seq=y，此時，服務器進程進入SYN-RCVD同步收到狀態。

• 第三次握手

客戶端收到確認後，須要向服務器確認報文的ACK=1，ack=y+1，此時，TCP鏈接創建，客戶端進入ESTABLISHED已創建鏈接狀態。完成三次握手，客戶端與服務器開始傳送數據。

三、四次揮手

• 第一次揮手

客戶端發送一個結束FIN，用來主動關閉和服務端的數據傳輸，釋放鏈接且中止發送數據，報文首部：FIN=1，序列號seq=u；隨後客戶端進入終止等待1狀態FIN-WAIT-1。

• 第二次揮手

服務端收到這個FIN，發出確認報文ACK=1，確認收到序號是收到的序號+1，即ack=u+1，且帶上本身的序列號seq=v，和SYN同樣，一個FIN將佔用一個序號。如此，服務器通知應用進程，客戶端已經沒有數據要發送，若是服務器發送數據，客戶端依然要接收，該狀態會持續一段時間，服務端進入關閉等待狀態CLOSE-WAIT。客戶端收到服務器的確認請求後，進入終止等待2狀態FIN-WAIT-2，等待服務器發送鏈接釋放報文。

• 第三次揮手

服務器向客戶端發送釋放鏈接報文FIN=1，ack=u+1，此時服務端還處於半關閉狀態，服務器可能還會發送一些數據，此時序列號爲seq=w，如此，服務器進入最後確認狀態LAST-ACK，等待客戶端的確認。

• 第四次揮手

客戶端收到服務器的鏈接釋放報文後，回發確認，ACK=1，ack=w+1，序列號是seq=u+1，如此，客戶端進入時間等待狀態TIME-WAIT。此時TCP鏈接尚未釋放，必須通過最長報文段壽命的時間後，才進入CLOSED狀態。MSL：最長報文段壽命，通常2分鐘，TCP鏈接釋放時，主動方必須通過2MSL後才進入CLOSED狀態，所以主動方關閉時間比較晚。

5、源代碼地址

GitHub·地址
https://github.com/cicadasmile/java-base-parent
GitEE·地址
https://gitee.com/cicadasmile/java-base-parent