??一.HTTP協(xié)議概述
??1.什么是HTTP協(xié)議
HTTP/HTTPS協(xié)議是應(yīng)用層的網(wǎng)路協(xié)議
目前大多數(shù)情況HTTP在傳輸層是基于TCP(HTTP1/2 是基于TCP,最新的HTTP協(xié)議是基于UDP協(xié)議,但是我們目前常用的HTTP應(yīng)用層協(xié)議是HTTP1.0)
應(yīng)用層協(xié)議很多時候都是程序員自己定制的，需要根據(jù)具體的場景來制定應(yīng)用層協(xié)議，但是由于程序員水平參差不齊，大佬設(shè)計的協(xié)議很好用，菜鳥設(shè)計的協(xié)議一言難盡，于是有一些大佬就發(fā)明了很好用的協(xié)議，直接讓大家照搬，HTTP就是其中的一個典型代表，HTTP雖然已經(jīng)設(shè)計好了，但是它的擴展性極強，可以根據(jù)需要讓程序員自定義數(shù)據(jù)信息
當我們在瀏覽器中輸入一個 “網(wǎng)址”, 此時瀏覽器就會給對應(yīng)的服務(wù)器發(fā)送一個 HTTP 請求. 對方服務(wù)器收
到這個請求之后, 經(jīng)過計算處理, 就會返回一個 HTTP 響應(yīng)
HTTP是一種超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,那如何才能看到HTTP的報文格式或信息，這就需要對HTTP進行抓包(獲取到請求和響應(yīng)的相關(guān)數(shù)據(jù))，下面介紹一下如何進行HTTP的抓包
??1.2 Fiddler（抓包工具）
Fiddler 下載地址: https://www.telerik.com/fiddler/
● 下載之后就正常點擊安裝就可以
● 安裝完成后雙擊打開，我們先更改設(shè)置這樣我們就能夠捕捉到HTTPS協(xié)議的包，點擊左上角Tools->點擊Options->
● 點擊HTTPS將里面的內(nèi)容全部勾選
● 勾選點擊OK后會彈出，我們點擊YES 后 再點擊再單擊 ”是“ 再點擊”同意安裝“，這個一定要安裝，這個是Fiddler抓包工具的證書，沒有安裝證書是不會獲取到HTTPS協(xié)議的包
● 安裝好整數(shù)之后我們點擊左邊就可以看到我們獲取到的HTTP和HTTPS協(xié)議的包
\
● 我們雙擊一個獲取的協(xié)議包,在點擊Raw就可以在右邊看到包里的請求和相應(yīng)內(nèi)容
● 點擊View in Noyepad 就可以看到文本內(nèi)容
● 如果我們看到亂碼不要擔心是系統(tǒng)BUG，這其實是在傳輸過程中數(shù)據(jù)壓縮之后的結(jié)果
以上就是我們根據(jù)抓包工具就可以在我們開發(fā)的過程中進行調(diào)試來解決BUG
??二.HTTP協(xié)議格式
??2.1HTTP請求
??2.1.1 HTTP請求格式
一.請求行（首行），包含三個部分
● HTTP方法：大概描述了這個請求想要干什么
● URL：描述了想要訪問的網(wǎng)絡(luò)資源具體在哪
● 版本號，HTTP/1.1表示當前使用 HTTP1.1版本
二.請求報頭
● 包含很多行，每一行都有一個鍵值對，鍵值對之間用空格來分割
三.空行
● 相當于結(jié)束標記，類使于鏈表的null
四.請求正文（body）
● 可選的，不一定每個HTTP協(xié)議都有
我們就拿Fiddler（抓包工具）來進行逐步了解
??2.1.2 HTTP請求格式URL
URL：含義就是”網(wǎng)絡(luò)上唯一的資源地址符“
協(xié)議方案名：必選項，使用 http 或https等協(xié)議方案名獲取訪問資源時要指定協(xié)議類型。不區(qū)分字母大小寫，最后附一個冒號:，使用//與后面的字段分隔。
也可使用 jdbc:mysql:// 或 javascript: //這類jdbc程序或腳本程序的方案名。
登錄信息：可選項，這是很早時期上網(wǎng)的時候，在這里會體現(xiàn)出賬號與密碼，現(xiàn)在基本上沒有了，使用@符號與后面的字段分隔。
服務(wù)器地址：必選項，可以使用域名和IP地址來表示，使用:與端口號分隔。
端口號：可選項，表示訪問主機上哪一個應(yīng)用程序，該字段為空，瀏覽器會分配默認的端口號，http是80，https是443。
文件路徑：必選項，描述訪問服務(wù)器的資源是什么，最簡單的路徑就是一個/，你訪問很多網(wǎng)站的首頁的時候，最后都會有一個/，使用?與查詢字符串分隔。
查詢字符串：可選項，表示瀏覽器或者客戶端傳給服務(wù)器自定義的信息，對獲取的資源提出進一步的要求，一般是程序員自定義，所以如果不是你自己寫的，大概率看不懂，使用&進行查詢字符串分割，使用#與片段標識符分隔。
片段標識符：可選項，表示訪問頁面的子位置，能夠控制瀏覽器滾動到某一位置。
HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因為 URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。
URL：小結(jié)
● IP地址
● 端口號（可有）
● 帶層次結(jié)構(gòu)的路徑
● query string 查詢字符串
URL encode / decode
如果查詢字符串(query string)的內(nèi)容包含一些具有特定含義的字符需要進行轉(zhuǎn)義，如/,?,&等，如果含有這些字符，會將這些字符替換為%+字符的ASCII碼，這個過程就是encode，反過來將這些轉(zhuǎn)義的字符串解析為原來的字符，這個過程就是decode，不僅僅是特殊符號，也有可能是漢字
比如，你在瀏覽器上搜索C++，在URL上就會得到C%2B%2B這樣的字符串
??2.1.3 HTTP請求格式方法
請求行里面的方法完整地說應(yīng)該叫做告知服務(wù)器意圖的 HTTP 方法，這里的方法與java里面的方法不同，引入這些方法的初衷就是為了表示不同的語義，比如GET表示獲取資源，POST表示上傳資源，但是大多數(shù)人寫代碼就是GET/POST一把梭，基本上就沒有考慮各種方法的語義。
在http/1.1版本中，我們最常使用的方法有GET，POST，還有其他方法，引謝靈運的話來說才高八斗，就是指GET占八斗，POST占一斗，其他方法分剩下的一斗來表示GET和POST方法的常用
各方法功能如下：
● GET 方法
GET 是最常用的 HTTP 方法. 常用于獲取服務(wù)器上的某個資源.在瀏覽器中直接輸入 URL, 此時瀏覽器就會發(fā)送出一個 GET 請求.另外, HTML 中的 link, img, script 等標簽, 也會觸發(fā) GET 請求.
*后面我們還會學(xué)習, 使用 JavaScript 中的 ajax 也能構(gòu)造 GET 請求.
● GET 請求的特點：
● 首行的第一部分為 GET
● URL 的 query string 可以為空, 也可以不為空.
● header 部分有若干個鍵值對結(jié)構(gòu).
● body 部分為空.
● POST 方法
POST 方法也是一種常見的方法. 多用于提交用戶輸入的數(shù)據(jù)給服務(wù)器(例如登陸頁面).
通過 HTML 中的 form 標簽可以構(gòu)造 POST 請求, 或者使用 JavaScript 的 ajax 也可以構(gòu)造 POST 請求.
●POST 請求的特點
●首行的第一部分為 POST
●URL 的 query string 一般為空 (也可以不為空)
●header 部分有若干個鍵值對結(jié)構(gòu).
●body 部分一般不為空. body 內(nèi)的數(shù)據(jù)格式通過 header 中的 Content-Type 指定. body 的長度由
●header 中的 Content-Length 指定
??2.1.4 GET與POST區(qū)別（面試題）
● 語義上區(qū)別：GET通常用來獲取數(shù)據(jù)，POST通常用來上傳數(shù)據(jù)
● 大多數(shù)情況下：GET沒有body，GET通過query string向服務(wù)器傳遞數(shù)據(jù)；POST是有body的，POST通過body向服務(wù)器傳遞數(shù)據(jù)，但是POST沒有query string
● GET請求是冪等，POST請求一般是不冪等（冪等是每次相同的輸入，得到輸出結(jié)果是確定的；不冪等：每當你相同的輸入，得到的結(jié)果不正確）
● GET可以被緩存，POST不能被緩存(冪等和能不能被緩存是有關(guān)聯(lián)的)
補充說明:
● 關(guān)于語義: GET 完全可以用于提交數(shù)據(jù), POST 也完全可以用于獲取數(shù)據(jù).
● 關(guān)于冪等性: 標準建議 GET 實現(xiàn)為冪等的. 實際開發(fā)中 GET 也不必完全遵守這個規(guī)則(主流網(wǎng)站都有 “猜你喜歡” 功能, 會根據(jù)用戶的歷史行為實時更新現(xiàn)有的結(jié)果.
● 關(guān)于安全性: 有些資料上說 “POST 比 GET 請安全”. 這樣的說法是不科學(xué)的. 是否安全取決于前端在傳輸密碼等敏感信息時是否進行加密, 和 GET POST 無關(guān).
● 關(guān)于傳輸數(shù)據(jù)量: 有的資料上說 “GET 傳輸?shù)臄?shù)據(jù)量小, POST 傳輸數(shù)據(jù)量大”. 這個也是不科學(xué)的, 標準沒有規(guī)定 GET 的 URL 的長度, 也沒有規(guī)定 POST 的 body 的長度. 傳輸數(shù)據(jù)量多少,完全取決于不同瀏覽器和不同服務(wù)器之間的實現(xiàn)區(qū)別.
● 關(guān)于傳輸數(shù)據(jù)類型: 有的資料上說 “GET 只能傳輸文本數(shù)據(jù), POST 可以傳輸二進制數(shù)據(jù)”. 這個也是不科學(xué)的. GET 的 query string 雖然無法直接傳輸二進制數(shù)據(jù), 但是可以針對二進制數(shù)據(jù)進行 url encode.
??2.1.5HTTP請求報頭
● Host
表示服務(wù)器主機的地址和端口
● Content-Type
表示請求的 body 中的數(shù)據(jù)格式
常見選項:
1.application/x-www-form-urlencoded: form 表單提交的數(shù)據(jù)格式. 此時 body 的格式
title=test&content=hello
2.multipart/form-data: form 表單提交的數(shù)據(jù)格式(在 form 標簽中加上enctyped=“multipart/form-data” . 通常用于提交圖片/文件. body 格式)
Content-Type:multipart/form-data; boundary=----
WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
3.application/json: 數(shù)據(jù)為 json 格式. body 格式
{"username":"123456789",(密碼加密，因為博客規(guī)定所以不顯示了，大家可以在Fedeeler去看):"xxxx","code":"jw7l","uuid":"d110a05ccde64b16a861fa2bddfdcd15"}
補充說明：
為什么我們登陸時使用的方法是POST而不是GET，因為使用GET方法中大部分是沒有body，所以我們只能通過URL中的查詢字符串來進行傳遞操作（query string）這樣我們就會在鏈接上看到很長一條所以這影響用戶體驗的，這個時候我們就可以通過POST方法中的body來進行數(shù)據(jù)傳輸了，這樣還可以例如在用戶輸入密碼的時候保留在body中而不是顯示在URL中
● Content-Length
表示 body 中的數(shù)據(jù)長度.
因為HTTP協(xié)議是基于TCP協(xié)議，所以我們也是有可能會沾包問題，所以我們可以需要通過分隔符，和空格，還有長度來進行辨別這個包是否已經(jīng)傳輸結(jié)束了
當多個POST進入TCP緩沖區(qū)中，這個時候哦就可以通過body當讀到空格后可以通過 Content-Length來進行識別還需要繼續(xù)多多少字節(jié)就完整的傳輸包了
● User-Agent (簡稱 UA)
表示當前用戶通過什么設(shè)備，那個瀏覽器來上網(wǎng)
● Referer
表示這個頁面是從哪個頁面跳轉(zhuǎn)過來的
如果直接在瀏覽器中輸入URL, 或者直接通過收藏夾訪問頁面時是沒有 Referer 的.
● Cookie
Cookie 中存儲了一個字符串, 這個數(shù)據(jù)可能是客戶端(網(wǎng)頁)自行通過 JS 寫入的, 也可能來自于服務(wù)器(服務(wù)器在 HTTP 響應(yīng)的 header 中通過 Set-Cookie 字段給瀏覽器返回數(shù)據(jù)).往往可以通過這個字段實現(xiàn) “身份標識” 的功能.
每個不同的域名下都可以有不同的 Cookie, 不同網(wǎng)站之間的 Cookie 并不沖突.
我們可以通過登陸過的博客來查看Cookie
因為HTTP是一種無狀態(tài)的協(xié)議，它無法對之前的發(fā)生過的請求和響應(yīng)狀態(tài)進行記憶，如果遇到需要登錄的頁面，登錄之后，再刷新，是需要重新進行登錄的，這個就非常的難受，為了解決這個問題，引入了Cookie機制
但是也有好處，可以減少服務(wù)器的 CPU 及內(nèi)存資源的消耗。
Cookie是瀏覽器為頁面提供的一種持久化儲存數(shù)據(jù)的機制，即就是將數(shù)據(jù)存儲磁盤上，不會因為瀏覽器或者電腦重啟而導(dǎo)致數(shù)據(jù)丟失。
Cookie會按照域名來進行分類并組織，針對每一個域名，都會分配一個“小房間”(一塊獨立的儲存空間)，這些小房間之間是相互獨立的，在每個“小房間”里面會按照鍵值對的方式儲存數(shù)據(jù)（值），每個鍵值對之間使用&來進行分隔。
那Cookie的數(shù)據(jù)從哪里來？其實是從服務(wù)器返回給客戶端的，服務(wù)器完成客戶端的身份認證之后會通過的頭部字段Set-Cookie來給客戶端響應(yīng)信息
Cookie的作用其實就像醫(yī)院里面的就診卡一樣，就診卡里面有就診人的基本信息，刷卡之后會根據(jù)這些基本信息可以查出在當前醫(yī)院里面的歷史就診記錄等更加詳細的信息，這張就診卡就相當于Cookie，而根據(jù)就診卡信息獲得的詳細記錄叫做session，每個session里面記錄了就診用戶的許多關(guān)鍵信息，例如歷史就診記錄，要做的檢測等等，每一個session都有對應(yīng)的sessionId，即會話標識，服務(wù)器返回給客戶端的Cookie響應(yīng)就有這個會話標識，然后訪問后續(xù)頁面的，根據(jù)這個會話標識就能從服務(wù)器找到對應(yīng)的信息進行登錄，這樣刷新頁面就不用在重復(fù)登錄了
下圖所圈的部分就有可能就是一種sessionId
??2.1.6HTTP請求正文（body）
正文中的內(nèi)容格式和 header 中的 Content-Type 密切相關(guān). 上面也羅列了三種常見的情況.
下面可以通過抓包來觀察這幾種情況：
● application/x-www-form-urlencoded
● multipart/form-data（文件/照片）
● application/json（界面）
??2.2HTTP響應(yīng)
??2.2.1HTTP響應(yīng)格式
一.響應(yīng)行（首行），包含三個部分
● 版本號，HTTP/1.1表示當前使用 HTTP1.1版本
● 狀態(tài)碼：200，描述這個響應(yīng)，是表示”成功的“還是”失敗的“，以及不同的狀態(tài)碼，來描述了失敗的原因
● 狀態(tài)碼描述：OK 描述了當前狀態(tài)碼的含義
二.響應(yīng)報頭
● 包含很多行，每一行都有一個鍵值對，鍵值對之間用空格來分割，不同鍵值對有不同的含義
三.空行
● 相當于結(jié)束標記，類使于鏈表的null
四.請求正文（body）
● 服務(wù)器返回個客戶端的具體數(shù)據(jù)，類似于假如我們訪問一個網(wǎng)頁我們就可以獲得到該網(wǎng)頁給我們響應(yīng)的html
??2.2.2HTTP響應(yīng)狀態(tài)碼
這是我們經(jīng)常見到的狀態(tài)碼
● 200 OK ：表示瀏覽器很順利的獲取到想要的內(nèi)容
● 302 Move temporarily 重定向（例如呼叫轉(zhuǎn)移，知道下一步要去哪里）
● 403 Forbidden 雖然有資源但是沒有權(quán)限進行訪問（丑拒）
● 404 Not Found 要訪問的資源不在
文章來源：http://www.zghlxwxcb.cn/news/detail-782658.html
● 405 Method Not Allowed 很少遇見，就是假如你通過GET方法進行訪問，但是人家網(wǎng)站只支持POST方法進行訪問
● 500 Internal Severe Erro 服務(wù)器自己出現(xiàn)問題r
● 504 Gateway Timeout 服務(wù)器繁忙文章來源地址http://www.zghlxwxcb.cn/news/detail-782658.html
到了這里，關(guān)于計算機網(wǎng)絡(luò)【HTTP協(xié)議】的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
