一、Http協議簡介
1.1 什麼是協議
協議就是對計算機之間連接的信息格式、能被收/發雙方接受的傳送信息內容的一組定義。協議有多層結構,常見高層協議如:TCP/IP負責點到點傳送信息包。(簡單來說協議就是在雙方交互的過程中,規定雙方如何通信)
1.2 什麼是HTTP協議
HTTP協議是Hyper Text Transfer Protocol(超文本傳輸協議)的縮寫,是用於從萬維網(WWW:World Wide Web )服務器傳輸超文本到本地瀏覽器的傳送協議。互聯網上應用最爲廣泛的一種網絡協議,所有的www都必須遵守該Http協議標準!
1.3 Web開發中是否也要遵守HTTP協議呢?
答案是:是的!在做Web開發中,瀏覽器與服務器要通訊,而他們通信的過程中也是要遵守Http協議的!
1.4 HTTP協議基層
HTTP是一個基於TCP/IP通信協議來傳遞數據(HTML 文件, 圖片文件, 查詢結果等)。也是基於請求與響應的模型,而Http協議默認端口爲80
1.5 HTTP的工作原理
HTTP協議工作於客戶端-服務端架構上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。
Web服務器有:Nginx,Apache服務器,IIS服務器(Internet Information Services)等。
Web服務器根據接收到的請求後,向客戶端發送響應信息。
1.6 HTTP的特點
HTTP協議的主要特點如下:
- 支持客戶端(瀏覽器)/服務器模式。B/S
- 簡單快速:客戶向服務器請求服務時,只需傳送請求方法和路徑。請求方法常用的有GET、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單,使得HTTP服務器的程序規模小,因而通信速度很快。
- 靈活:HTTP允許傳輸任意類型的數據對象。傳輸的類型由Content-Type加以標記。
- 無連接:無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求,並收到客戶的應答後,即斷開連接。採用這種方式可以節省傳輸時間。
- 無狀態:HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息,則它必須重傳,這樣可能導致每次連接傳送的數據量增大。另一方面,在服務器不需要先前信息時它的應答就較快。
1.7 HTTP協議的通信
HTTP通信機制是在一次完整的HTTP通信過程中,Web瀏覽器與Web服務器之間將完成下列7個步驟:
1、 建立TCP連接
在HTTP工作開始之前,Web瀏覽器首先要通過網絡與Web服務器建立連接,該連接是通過TCP來完成的,該協議與IP協議共同構建Internet,即著名的TCP/IP協議族,因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議,根據規則,只有低層協議建立之後才能進行更低層協議的連接。因此,首先要建立TCP連接,一般TCP連接的端口號是80
2、 瀏覽器向Web服務器發送請求命令
一旦建立了TCP連接,Web瀏覽器就會向Web服務器發送請求命令
例如:GET /sample/hello.html HTTP/1.1
3、 瀏覽器發送請求頭信息
瀏覽器發送其請求命令之後,還要以頭信息的形式向Web服務器發送一些別的信息,之後瀏覽器發送了一空白行來通知服務器,它已經結束了該頭信息的發送。
4、 Web服務器應答
客戶機向服務器發出請求後,服務器會客戶機回送應答,
HTTP/1.1 200 OK
應答的第一部分是協議的版本號和應答狀態碼
5、 Web服務器發送應答頭信息
正如客戶端會隨同請求發送關於自身的信息一樣,服務器也會隨同應答向用戶發送關於它自己的數據及被請求的文檔。
6、 Web服務器向瀏覽器發送數據
Web服務器向瀏覽器發送頭信息後,它會發送一個空白行來表示頭信息的發送到此爲結束,接着,它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據 response.setContentType(“text/html;charset=utf-8”);
7、 Web服務器關閉TCP連接
一般情況下,一旦Web服務器向瀏覽器發送了請求數據,它就要關閉TCP連接,然後如果瀏覽器或者服務器在其頭信息加入了這行代碼
Connection:keep-alive
TCP連接在發送後將仍然保持打開狀態,於是,瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了爲每個請求建立新連接所需的時間,還節約了網絡帶寬
二、HTTP消息結構
2.1 HTTP消息結構介紹
HTTP是基於客戶端/服務端(C/S)的架構模型,通過一個可靠的鏈接來交換信息,是一個無狀態的請求/響應協議。
一個HTTP"客戶端"是一個應用程序(Web瀏覽器或其他任何客戶端),通過連接到服務器達到向服務器發送一個或多個HTTP的請求的目的。
一個HTTP"服務器"同樣也是一個應用程序(通常是一個Web服務,如Apache Web服務器或IIS服務器等),通過接收客戶端的請求並向客戶端發送HTTP響應數據。
HTTP使用統一資源標識符(Uniform Resource Identifiers, URI)來傳輸數據和建立連接。
2.2 CS、BS結構介紹
2.2.1 生活中的兩種上網方式
一、可以通過瀏覽器(browser)進行上網,比如:訪問瀏覽谷歌瀏覽器、火狐瀏覽器
二、可以通過客戶端(client)進行上網,比如:下載淘寶客戶端逛淘寶
2.2.2 BS結構(Browser/Server )
B/S結構(Browser/Server,瀏覽器/服務器模式),是WEB興起後的一種網絡結構模式,WEB瀏覽器是客戶端最主要的應用軟件。這種模式統一了客戶端,將系統功能實現的核心部分集中到服務器上,簡化了系統的開發、維護和使用。客戶機上只要安裝一個瀏覽器,如Netscape Navigator或Internet Explorer,服務器安裝SQL Server、Oracle、MYSQL等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。
- 簡單來說,如下:
- 不需要安裝客戶端,只要能連上網,就能隨時隨地使用
- 開發人員只需要對服務器端程序進行開發、維護,降低開發維護難度和開發維護成本
- 瀏覽器主要負責用戶界面的動態展示,只處理一些簡單的邏輯功能
- 所有具體業務邏輯的處理都由服務器端程序完成,所以程序負載幾乎都轉移給服務器端
- 但是隨着服務器負載的增加,可以平滑地增加服務器的個數並建立集羣服務器系統,然 後在各個服務器之間做負載均衡
- 以下圖是BS結構的工作原理:
2.2.3 CS結構(Client/Server )
C/S結構(Client/Server,服務器/客戶機模式),C/S結構通常採取兩層結構。服務器負責數據的管理,客戶機負責完成與用戶的交互任務。 客戶機通過局域網與服務器相連,接受用戶的請求,並通過網絡向服務器提出請求,對數據庫進行操作。服務器接受客戶機的請求,將數據提交給客戶機,客戶機將數據進行計算並將結果呈現給用戶。服務器還要提供完善安全保護及對數據完整性的處理等操作,並允許多個客戶機同時訪問服務器,這就對服務器的硬件處理數據能力提出了很高的要求。
- 簡單來說,如下:
- 將應用程序分爲客戶端和服務器端兩層,客戶端程序用於展示功能,爲用戶提供操作界 面,同時也可以進行業務邏輯的處理;而服務器端程序負責操作數據庫完成數據處理等 核心業務
- 由此可見通過C/S開發模型開發的應用程序,客戶端程序可以承擔一部分業務邏輯處 理,特別是數據的預處理工作,減輕了服務器端程序的壓力
2.2.4 BS、CS總結
- BS優缺點:
- 優點:實時地更新數據(新功能的增加只需要在服務端完成,瀏覽器刷新就好了)
- 缺點:將負載給了服務器
- CS優缺點:
- 優點:客戶端也分擔了一部分負載
- 缺點:如果有新的功能增加,必須要重新下載客戶端
三、客戶端請求消息
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式:請求行(request line)、請求頭部(header)、空行和請求數據四個部分組成,下圖給出了請求報文的一般格式。
HTTP請求報文
當瀏覽器向Web服務器發出請求時,它向服務器傳遞了一個數據塊,也就是請求信息(請求報文),HTTP請求信息由4部分組成:
1 請求行 請求方法/地址 URI協議/版本
2 請求頭(Request Headers)
3 空行
4 請求正文
下面是一個HTTP請求的例子:
POST/hello HTTP/1.1
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Accept-Language:zh-CN,zh;q=0.8,en-GB;q=0.6,en;q=0.4
Connection:Keep-Alive
Host:localhost:8080
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36
Accept-Encoding:gzip, deflate, br
(空白行)
username=zhangsan&age=20&add=beijing
四、服務器響應消息
HTTP響應也由四個部分組成,分別是:狀態行、消息報頭、空行和響應正文。
HTTP響應報文
HTTP應答與HTTP請求相似,HTTP響應也由4個部分構成,分別是:
1 響應行(狀態行) HTTP/1.1 200 OK (其他的狀態碼會在後面說明!)
2 響應頭(Response Headers)
3 空行
4 響應正文
下面是一個HTTP響應的例子:
HTTP/1.1 200 OK //狀態行
Server: nginx
Date: Tue, 31 May 2016 02:09:24 GMT
Content-Type: text/html;charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With,access_token,access-token,content-type,multipart/form-data,application/x-www-form-urlencoded
Access-Control-Allow-Methods: GET,POST,OPTIONS
Content-Length: 49
\<!DOCTYPE html> //正文
<html>
<head>
<title>網頁標題</title>
<meta charset="utf-8">
</head>
<body>
網頁內容
</body>
五、HTTP請求方式
5.1 HTTP請求方式
根據HTTP標準,HTTP請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
序號 | 方法 | 描述 |
---|---|---|
1 | GET | 請求指定的頁面信息,並返回實體主體 |
2 | HEAD | 類似於get請求,只不過返回的響應中沒有具體內容,用戶獲取報頭 |
3 | POST | 向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中。POST請求可能導致新的資源的建立和/或已有資源的修改 |
4 | PUT | 從客戶端的服務器傳輸的數據取代指定的文檔內容 |
5 | DELETE | 請求服務器刪除指定的頁面 |
6 | CONNECT | HTTP/1.1協議中預留給能夠連接改爲管道方式的代理服務器 |
7 | OPTIONS | 允許客戶端查看服務器性能 |
8 | TRACE | 回顯服務器收到的請求,主要用於測試或診斷 |
5.2 GET、POST請求方式的區別(面試題)
GET一般用於獲取/查詢資源信息,而POST一般用於更新資源信息
GET和POST的區別爲:
- GET提交的數據會放在URL之後,以?分割URL和傳輸數據,參數之間以&相連。而POST方式是把提交的數據放在HTTP包的Body中
- GET提交的數據大小有限制(因爲瀏覽器對URL的長度有限制),而POST方法提交的數據沒有限制
- GET方式需要使用Request.QueryString來取得變量的值,而POST方式通過Request.Form來獲取變量的值
- GET方式提交數據,會帶來安全問題,比如一個登錄頁面,通過GET方式提交數據時,用戶名和密碼將出現在URL上,如果頁面可以被緩存或者其他人可以訪問這臺機器,就可以從歷史記錄獲得該用戶的賬號和密碼 (總之就是GET方式不安全!)
六、HTTP狀態碼
當瀏覽者訪問一個網頁時,瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前,此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭(server header)用以響應瀏覽器的請求。
HTTP狀態碼的英文爲HTTP Status Code。
6.1 常見的HTTP狀態碼
下面是常見的HTTP狀態碼:
- 200 - 請求成功
- 301 - 資源(網頁等)被永久轉移到其它URL
- 404 - 請求的資源(網頁等)不存在
- 500 - 內部服務器錯誤
6.2 HTTP狀態碼分類
HTTP狀態碼由三個十進制數字組成,第一個十進制數字定義了狀態碼的類型,後兩個數字沒有分類的作用。
HTTP狀態碼共分爲5種類型:
分類 | 分類描述 |
---|---|
1** | 提示信息,服務器收到請求,需要請求者繼續執行操作 |
2** | 成功,操作被成功接收並處理 |
3** | 重定向,需要進一步的操作以完成請求 |
4** | 客戶端錯誤,請求包含語法錯誤或無法完成請求 |
5** | 服務器錯誤,服務器在處理請求的過程中發生了錯誤 |
6.3 HTTP狀態碼列表
狀態碼 | 狀態碼英文名稱 | 中文描述 |
---|---|---|
100 | Continue | 繼續。客戶端應繼續其請求 |
101 | Switching Protocols | 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議,例如,切換到HTTP的新版本協議 |
200 | OK | 請求成功。一般用於GET與POST請求 |
201 | Created | 已創建。成功請求並創建了新的資源 |
202 | Accepted | 已接受。已經接受請求,但未處理完成 |
203 | Non-Authoritative Information | 非授權信息。請求成功。但返回的meta信息不在原始的服務器,而是一個副本 |
204 | No Content | 無內容。服務器成功處理,但未返回內容。在未更新網頁的情況下,可確保瀏覽器繼續顯示當前文檔 |
205 | Reset Content | 重置內容。服務器處理成功,用戶終端(例如:瀏覽器)應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域 |
206 | Partial Content | 部分內容。服務器成功處理了部分GET請求 |
300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置,相應可返回一個資源特徵與地址的列表用於用戶終端(例如:瀏覽器)選擇 |
301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI,返回信息會包括新的URI,瀏覽器會自動定向到新URI。今後任何新的請求都應使用新的URI代替 |
302 | Found | 臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
303 | See Other | 查看其它地址。與301類似。使用GET和POST請求查看 |
304 | Not Modified | 未修改。所請求的資源未修改,服務器返回此狀態碼時,不會返回任何資源。客戶端通常會緩存訪問過的資源,通過提供一個頭信息指出客戶端希望只返回在指定日期之後修改的資源 |
305 | Use Proxy | 使用代理。所請求的資源必須通過代理訪問 |
306 | Unused | 已經被廢棄的HTTP狀態碼 |
307 | Temporary Redirect | 臨時重定向。與302類似。使用GET請求重定向 |
400 | Bad Request | 客戶端請求的語法錯誤,服務器無法理解 |
401 | Unauthorized | 請求要求用戶的身份認證 |
402 | Payment Required | 保留,將來使用 |
403 | Forbidden | 服務器理解請求客戶端的請求,但是拒絕執行此請求 |
404 | Not Found | 服務器無法根據客戶端的請求找到資源(網頁)。通過此代碼,網站設計人員可設置"您所請求的資源無法找到"的個性頁面 |
405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
406 | Not Acceptable | 服務器無法根據客戶端請求的內容特性完成請求 |
407 | Proxy Authentication Required | 請求要求代理的身份認證,與401類似,但請求者應當使用代理進行授權 |
408 | Request Time-out | 服務器等待客戶端發送的請求時間過長,超時 |
409 | Conflict | 服務器完成客戶端的PUT請求是可能返回此代碼,服務器處理請求時發生了衝突 |
410 | Gone | 客戶端請求的資源已經不存在。410不同於404,如果資源以前有現在被永久刪除了可使用410代碼,網站設計人員可通過301代碼指定資源的新位置 |
411 | Length Required | 服務器無法處理客戶端發送的不帶Content-Length的請求信息 |
412 | Precondition Failed | 客戶端請求信息的先決條件錯誤 |
413 | Request Entity Too Large | 由於請求的實體過大,服務器無法處理,因此拒絕請求。爲防止客戶端的連續請求,服務器可能會關閉連接。如果只是服務器暫時無法處理,則會包含一個Retry-After的響應信息 |
414 | Request-URI Too Large | 請求的URI過長(URI通常爲網址),服務器無法處理 |
415 | Unsupported Media Type | 服務器無法處理請求附帶的媒體格式 |
416 | Requested range not satisfiable | 客戶端請求的範圍無效 |
417 | Expectation Failed | 服務器無法滿足Expect的請求頭信息 |
500 | Internal Server Error | 服務器內部錯誤,無法完成請求 |
501 | Not Implemented | 服務器不支持請求的功能,無法完成請求 |
502 | Bad Gateway | 作爲網關或者代理工作的服務器嘗試執行請求時,從遠程服務器接收到了一個無效的響應 |
503 | Service Unavailable | 由於超載或系統維護,服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中 |
504 | Gateway Time-out | 充當網關或代理的服務器,未及時從遠端服務器獲取請求 |
505 | HTTP Version not supported | 服務器不支持請求的HTTP協議的版本,無法完成處理 |
七、通過抓包的方式來演示HTTP協議
7.1 部署演示項目進行抓包
首先我們在idea中隨便部署一個項目(裏面可以只有一個index.html)
打開抓包功能,即去瀏覽器中輸入你部署好的項目地址(記住先不要按Enter回車鍵進入),然後打開F12,進入Network界面,其次在按Enter進入你部署好的網頁【如何部署Web項目,請看tomact教科書系列】
抓包後顯示如下內容
- 如果所示,部署的網頁已經顯示在瀏覽器中
- Network裏多出了一個firstweb/,這說明瀏覽器向服務器請求了一個地址index.html
- 注意:這裏顯示的項目名訪問firstweb/,因爲index.html默認項目名稱訪問,所以這裏訪問的是index.html文件
7.2 抓包後Network中的信息及名詞解釋
通過抓包可以看到如下信息:(空白行我們看不見在這裏忽略掉)
- General:請求行、響應行
- Request Headers:請求頭
- Response Headers:響應頭
- 響應正文:將顯示內容攜帶到瀏覽器
- 請求正文:用來接收請求的參數
- 總結:
- 請求包括:請求行、請求頭、請求正文
- 響應包括:相應行、響應頭、響應正文
7.3 HTTP請求的執行流程
- 根據windows系統的域名解析文件(C:\Windows\System32\drivers\etc\host【host文件】)將域名解析成對應的本地ip,如果沒有找到對應的IP,那麼就將域名放到DNS服務器上就解析找到互聯網上的對應IP
- 經過三次握手建立TCP連接(HTTP底層基於TCP)
- 發起HTTP請求,包含請求行,請求頭,請求正文
- 服務器返回HTTP響應,包含響應行,響應頭,響應正文
- 瀏覽器解析響應正文並展示
三次握手、四次揮手見下圖,如果需要了解此內容點擊鏈接:https://blog.csdn.net/weixin_44170221/article/details/105033456
7.4 HTTP請求(簡單版)
HTTP請求分爲四部分:請求行、請求頭、空白行、請求正文
請求行:
- 請求方式:GET、POST
- 請求資源路徑
- 協議版本
請求頭:
- 瀏覽器類型等等
請求正文:
- 只有請求方式是POST纔會有請求正文
7.5 HTTP響應(簡單版)
HTTP響應分爲四部分:響應行、響應頭、空白行、響應正文
響應行:
- 在響應行中最重要的是響應狀態碼(所有響應狀態碼在第六章時我們已經介紹!)
- 這裏在列出常見的響應狀態碼:
- 200-響應成功
- 302-可以與一個響應頭location組成完成重定向
- 304-代表服務器資源沒有改變
- 404-資源訪問不到
- 500-服務器端錯誤
響應頭:
- Location
- 作用: 用於重定向一個新的位置, 包含新的URL地址
- 它與302狀態碼組合可以完成重定向
- Content-type
- 服務器響應的數據mimeType類型:音頻、圖片、文本、html網頁等等
- refresh
- 可以實現定時跳轉
- content-disposition
- 可以完成文件下載,點擊的整個文件是否彈出下載框
- 等等
響應正文:
- 對於HTTP響應正文,它是真正的被瀏覽器解析並顯示在瀏覽器上的信息內容
7.6 簡單再談GET、POST請求方式區別(簡單版回答面試)
- GET只能傳遞1kb以下的小數據,因爲瀏覽器對URL的長度有限制。而POST可以傳遞大數據
- GET請求參數會拼接在瀏覽器地址欄中是不安全的,而POST請求參數是保存在HTML包內body中很安全
- 如果是get請求,有請求參數,請求參數是在http請求行的資源路徑上
- 如果是post請求,有請求參數,請求參數是在請求正文中
可以實現定時跳轉
- content-disposition
- 可以完成文件下載,點擊的整個文件是否彈出下載框
- 等等
響應正文:
- 對於HTTP響應正文,它是真正的被瀏覽器解析並顯示在瀏覽器上的信息內容
7.6 簡單再談GET、POST請求方式區別(簡單版回答面試)
- GET只能傳遞1kb以下的小數據,因爲瀏覽器對URL的長度有限制。而POST可以傳遞大數據
- GET請求參數會拼接在瀏覽器地址欄中是不安全的,而POST請求參數是保存在HTML包內body中很安全
- 如果是get請求,有請求參數,請求參數是在http請求行的資源路徑上
- 如果是post請求,有請求參數,請求參數是在請求正文中
下一章節Servlet內容