国产无码综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

<button id="keke2"></button>

<rt id="keke2"><dl id="keke2"></dl></rt>

<table id="keke2"></table>

<del id="keke2"></del>

<menu id="keke2"><tfoot id="keke2"></tfoot></menu>

網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https

1年前作者：天罰神分類：Toy博客閱讀(35)違法舉報

這篇具有很好參考價值的文章主要介紹了網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

01 HTTP請求報文協(xié)議（Request）

1）Request簡述

網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

HTTP協(xié)議請求報文是以字符文本的格式傳輸，具體包含以下四大部分：

請求行（首行）：[方法]+[url]+[版本號]，分別使用空格分隔；
請求頭（Header）：請求的屬性，每個鍵值對獨占一行，冒號+空格來分割鍵和值；
空行：遇到空行表示Header部分結(jié)束；
正文（Body）：空行后面的內(nèi)容都是Body，Body允許為空字符串。
示例
字符串展示形式：

POST /dologin.action HTTP/1.1
Host: wiki.tope365.com
Content-Length: 86
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://wiki.tope365.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.6261.112 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://wiki.tope365.com/login.action?logout=true
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: JSESSIONID=B59940DF4F57CFB4D23D9AC8C7DF0C98
Connection: close

os_username=yewenhai&os_password=Lovenier7777&login=%E7%99%BB%E5%BD%95&os_destination=

16進(jìn)制展示形式：
網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

2）請求行（首行）

首行包括：HTTP方法+URL+版本號

HTTP方法
根據(jù) HTTP 標(biāo)準(zhǔn)，HTTP 請求可以使用多種請求方法。
URL

拆解上述圖中的URL，格式分段詳解：

協(xié)議名：表示使用的協(xié)議類型，常見的有http和https，也有其他的類型。(例如訪問
mysql時用的jdbc:mysql)可以省略，省略后默認(rèn)為http://；
登陸信息：現(xiàn)在的網(wǎng)站進(jìn)行身份認(rèn)證一般不再通過URL進(jìn)行了，一般都會省略。
服務(wù)器地址（ip地址/域名）：此處是一個“域名”，域名會通過DNS系統(tǒng)解析成一個具體的IP地址。在HTML中可以省略(比如img，link，script，a標(biāo)簽的src或者h(yuǎn)ref屬性)，省略后表示服務(wù)器的ip/域名與當(dāng)前HTML所屬的ip/域名一致；
端口號：當(dāng)端口號省略的時候，瀏覽器會根據(jù)協(xié)議類型自動決定使用哪個端口。例如http協(xié)議默認(rèn)使用80端口，https協(xié)議默認(rèn)使用443端口。
帶層次的文件路徑：表示需要訪問的資源在服務(wù)器中的層次。可以省略，省略后相當(dāng)于/.有些服務(wù)器會在發(fā)現(xiàn)/路徑的時候自動訪問/index.html；
查詢字符串(query string)：本質(zhì)是一個鍵值對結(jié)構(gòu)，鍵值對之間使用&分隔，鍵和值之間使用=分隔。可以省略；
片段標(biāo)識：片段標(biāo)識主要用于頁面內(nèi)跳轉(zhuǎn)。可以省略；

版本號
表示HTTP的協(xié)議版本，如：HTTP/1.0、HTTP/1.1、HTTP/2.0

3）請求頭（Request Headers）

Host
表示服務(wù)器主機(jī)的地址和端口（這個信息在URL中也存在的）。
Content-Length
表示Body中的數(shù)據(jù)長度（請求報文里有Body，才有該屬性存在）。
Content-Type
表示請求的Body中的數(shù)據(jù)格式（請求報文里有Body，才有該屬性存在）。
HTTP協(xié)議的請求格式一般有：json格式、form表單、form-data格式。
后續(xù)給服務(wù)器提交給請求，不同的Content-Type，服務(wù)器處理數(shù)據(jù)的邏輯是不同的。

服務(wù)器返回數(shù)據(jù)給瀏覽器，也需要設(shè)置合適的Content-Type，瀏覽器也會根據(jù)不同的Content-Type 做出不同的處理。

Upgrade-Insecure-Requests
這個請求頭指示客戶端（通常是瀏覽器），要求服務(wù)器使用 HTTPS 加載資源，并在加載過程中升級所有不安全的請求。這有助于提高網(wǎng)站的安全性，防止未加密的內(nèi)容被加載。
Origin
這個請求頭包含了當(dāng)前文檔或腳本的來源信息，通常用于跨域資源共享（CORS）。它告訴服務(wù)器請求的源自哪里，以幫助服務(wù)器決定是否允許該請求。
X-Forwarded-For
通過名字就知道，X-Forwarded-For 是一個 HTTP 擴(kuò)展頭部。HTTP/1.1（RFC 2616）協(xié)議并沒有對它的定義，它最開始是由 Squid 這個緩存代理軟件引入，用來表示 HTTP 請求端真實 IP。如今它已經(jīng)成為事實上的標(biāo)準(zhǔn)，被各大 HTTP 代理、負(fù)載均衡等轉(zhuǎn)發(fā)服務(wù)廣泛使用，并被寫入 RFC 7239（Forwarded HTTP Extension）標(biāo)準(zhǔn)之中。

X-Forwarded-For 請求頭格式非常簡單，就這樣：

X-Forwarded-For: client, proxy1, proxy2
可以看到，XFF 的內(nèi)容由「英文逗號 + 空格」隔開的多個部分組成，最開始的是離服務(wù)端最遠(yuǎn)的設(shè)備 IP，然后是每一級代理設(shè)備的 IP。

如果一個 HTTP 請求到達(dá)服務(wù)器之前，經(jīng)過了三個代理 Proxy1、Proxy2、Proxy3，IP 分別為 IP1、IP2、IP3，用戶真實 IP 為 IP0，那么按照 XFF 標(biāo)準(zhǔn)，服務(wù)端最終會收到以下信息：

X-Forwarded-For: IP0, IP1, IP2
Proxy3 直連服務(wù)器，它會給 XFF 追加 IP2，表示它是在幫 Proxy2 轉(zhuǎn)發(fā)請求。列表中并沒有 IP3，IP3 可以在服務(wù)端通過 Remote Address 字段獲得。我們知道 HTTP 連接基于 TCP 連接，HTTP 協(xié)議中沒有 IP 的概念，Remote Address 來自 TCP 連接，表示與服務(wù)端建立 TCP 連接的設(shè)備 IP，在這個例子里就是 IP3。

Remote Address 無法偽造，因為建立 TCP 連接需要三次握手，如果偽造了源 IP，無法建立 TCP 連接，更不會有后面的 HTTP 請求。不同語言獲取 Remote Address 的方式不一樣，例如 php 是 $_SERVER[“REMOTE_ADDR”]，Node.js 是 req.connection.remoteAddress，但原理都一樣。

User-Agent
User-Agent簡稱UA，表示瀏覽器/操作系統(tǒng)的屬性，現(xiàn)在主要用來區(qū)分PC端還是移動端設(shè)備。
UA表述了主機(jī)操作系統(tǒng)版本和瀏覽器的版本，通俗點說，UA表示你用什么設(shè)備上網(wǎng)。
Accept
告訴 WEB 服務(wù)器自己接受什么介質(zhì)類型，/ 表示任何類型，type/* 表示該類型下的所有子類型，type/sub-type。
Accept-Charset
瀏覽器申明自己接收的字符集。
Referer
表示這個頁面是從哪個頁面跳轉(zhuǎn)過來的。
如果直接在瀏覽器中輸入URL，或者直接通過收藏夾訪問頁面時是沒有Referer屬性的。
Accept-Encoding
這個請求頭告訴服務(wù)器客戶端支持的壓縮算法，以便服務(wù)器在返回響應(yīng)時可以選擇適當(dāng)?shù)膲嚎s方式。通過使用壓縮算法，可以減少傳輸過程中的數(shù)據(jù)量，提高網(wǎng)站性能和加載速度。
Accept-Language
這個請求頭用于指示服務(wù)器用戶代理（通常是瀏覽器）接受的首選自然語言。服務(wù)器可以使用這個信息來返回特定語言版本的內(nèi)容，以提供更好的用戶體驗。
Cookie
Cookie中存儲了一個字符串，往往是從服務(wù)器返回的數(shù)據(jù)(也可以是頁面自己生成的)。Cookie是按照鍵值對的形式來組織的，這里的鍵值對也都是程序猿自定義的(和query string差不多)。
Authorization
當(dāng)客戶端接收到來自WEB服務(wù)器的 WWW-Authenticate 響應(yīng)時，用該頭部來回應(yīng)自己的身份驗證信息給 WEB 服務(wù)器。
Range

表示頭500個字節(jié)：bytes=0-499
表示第二個500字節(jié)：bytes=500-999
表示最后500個字節(jié)：bytes=-500
表示500字節(jié)以后的范圍：bytes=500-
第一個和最后一個字節(jié)：bytes=0-0,-1
同時指定幾個范圍：bytes=500-600,601-999

但是服務(wù)器可以忽略此請求頭，如果無條件 GET 包含 Range 請求頭，響應(yīng)會以狀態(tài)碼 206（PartialContent）返回而不是以 200 （OK）

通用頭域
通用頭域包含請求和響應(yīng)消息都支持的頭域，通用頭域包含 Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴(kuò)展要求通訊雙方都支持此擴(kuò)展，如果存在不支持的通用頭域，一般將會作為實體頭域處理。下面簡單介紹幾個在 UPnP 消息中使用的通用頭域。
Cache-Control頭域
Cache -Control 指定請求和響應(yīng)遵循的緩存機(jī)制。在請求消息或響應(yīng)消息中設(shè)置 Cache-Control 并不會修改另一個消息處理過程中的緩存處理過程。

請求時的緩存指令包括：

no-cache、
no-store、
max-age、
max-stale、
min-fresh、
only-if-cached

響應(yīng)消息中的指令包括：

Public 指示響應(yīng)可被任何緩存區(qū)緩存；
Private 指示對于單個用戶的整個或部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述當(dāng)用戶的部分響應(yīng)消息，此響應(yīng)消息對于其他用戶的請求無效；
no-cache 指示請求或響應(yīng)消息不能緩存；
no-store 用于防止重要的信息被無意的發(fā)布。在請求消息中發(fā)送將使得請求和響應(yīng)消息都不使用緩存；
max-age 指示客戶機(jī)可以接收生存期不大于指定時間（以秒為單位）的響應(yīng)；
min-fresh 指示客戶機(jī)可以接收響應(yīng)時間小于當(dāng)前時間加上指定時間的響應(yīng)；
max-stale 指示客戶機(jī)可以接收超出超時期間的響應(yīng)消息。如果指定 max-stale 消息的值，那么客戶機(jī)可以接收超出超時期指定值之內(nèi)的響應(yīng)消息。

Pragma 頭域
Pragma 頭域用來包含實現(xiàn)特定的指令，最常用的是 Pragma:no-cache。在 HTTP/1.1 協(xié)議中，它的含義和 Cache-Control:no-cache 相同。
Connection頭域
Connection 表示連接狀態(tài)
請求

close（告訴 WEB 服務(wù)器或者代理服務(wù)器，在完成本次請求的響應(yīng)后，斷開連接，不要等待本次連接的后續(xù)請求了）。
keepalive（告訴 WEB 服務(wù)器或者代理服務(wù)器，在完成本次請求的響應(yīng)后，保持連接，等待本次連接的后續(xù)請求）。

響應(yīng)

close（連接已經(jīng)關(guān)閉）。
Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望 WEB 服務(wù)器保持連接多長時間（秒）。例如：Keep-Alive：300

Date 頭域
date 頭域表示消息發(fā)送的時間，時間的描述格式由 rfc822 定義。例如，Date:Mon,31Dec200104:25:57GMT。Date 描述的時間表示世界標(biāo)準(zhǔn)時，換算成本地時間，需要知道用戶所在的時區(qū)。

4）空行

5）正文（Request Body）

請求體，一般承載的內(nèi)容是 POST 請求中的表單數(shù)據(jù)，對于 GET 請求，請求體為空。

除此之外，Content-type 還可以設(shè)為 application/x-www-form-urlencoded，這樣內(nèi)容就會以表單數(shù)據(jù)的形式放在請求體中提交，同時 Content-type 也可設(shè)為 multipart/from-data 來上傳文件。
網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

02 HTTP響應(yīng)報文協(xié)議（Response）

響應(yīng)，就是由服務(wù)器返回給客戶端，可以分為三個部分：響應(yīng)狀態(tài)碼、響應(yīng)頭、響應(yīng)體。

1）Response簡述

HTTP響應(yīng)也由四個部分組成，分別是：狀態(tài)行、消息報頭、空行和響應(yīng)正文。
網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

示例

HTTP/1.1 200 OK
Date: Tue, 26 Mar 2024 23:30:34 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 29706
Connection: close
Server: Apache-Coyote/1.1
X-ASEN: YOU MAKE ME A SAD PANDA.
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Confluence-Request-Time: 1711495834783
X-Seraph-LoginReason: AUTHENTICATED_FAILED
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Vary: User-Agent

<!DOCTYPE html>
<html>
<head>
                    <title>登錄 - Confluence</title>
 ****省略，反正就是返回html相關(guān)的源代碼，效果如下，就是登陸失敗的html頁面*****

網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

2）狀態(tài)行（Resqonse Status Code）

狀態(tài)碼有很多種，主要分為五類：1xx、2xx、3xx、4xx、5xx

1xx：信息響應(yīng)
2xx：成功響應(yīng)
3xx：重定向
4xx：客戶端錯誤
5xx：服務(wù)器錯誤

3）響應(yīng)頭（Response Headers）

響應(yīng)頭，包含了服務(wù)器對請求的應(yīng)答信息，如 Content-Type、Server、Set-Cookie等。下面簡要介紹一些常用的響應(yīng)頭信息

Allow
服務(wù)器支持哪些請求方法（如GET、POST等）。
Date
用于表示響應(yīng)產(chǎn)生的時間，當(dāng)前的GMT時間。你可以用setDateHeader來設(shè)置這個頭以避免轉(zhuǎn)換時間格式的麻煩。
Last-Modified
用于指定資源的最后修改時間，文檔的最后改動時間?？蛻艨梢酝ㄟ^If-Modified-Since請求頭提供一個日期，該請求將被視為一個條件GET，只有改動時間遲于指定時間的文檔才會返回，否則返回一個304（Not Modified）狀態(tài)。Last-Modified也可用setDateHeader方法來設(shè)置。
Content-Encoding
用于指定響應(yīng)內(nèi)容的編碼，文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。Java的GZIPOutputStream可以很方便地進(jìn)行g(shù)zip壓縮，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet應(yīng)該通過查看Accept-Encoding頭（即request.getHeader(“Accept-Encoding”)）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁面，為其他瀏覽器返回普通頁面。
Content-Type
Content-Type（內(nèi)容類型），一般是指網(wǎng)頁中存在的 Content-Type，用于定義網(wǎng)絡(luò)文件的類型和網(wǎng)頁的編碼，決定瀏覽器將以什么形式、什么編碼讀取這個文件，這就是經(jīng)常看到一些 PHP 網(wǎng)頁點擊的結(jié)果卻是下載一個文件或一張圖片的原因。
Content-Type 標(biāo)頭告訴客戶端實際返回的內(nèi)容的內(nèi)容類型。
語法格式：

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

常見的媒體格式類型如下：

text/html ： HTML格式
text/plain ：純文本格式
text/xml ： XML格式
image/gif ：gif圖片格式
image/jpeg ：jpg圖片格式
image/png：png圖片格式
以application開頭的媒體格式類型：
application/xhtml+xml ：XHTML格式
application/xml： XML數(shù)據(jù)格式
application/atom+xml ：Atom XML聚合格式
application/json： JSON數(shù)據(jù)格式
application/pdf：pdf格式
application/msword ： Word文檔格式
application/octet-stream ： 二進(jìn)制流數(shù)據(jù)（如常見的文件下載）
application/x-www-form-urlencoded ： <form encType=””>中默認(rèn)的encType，form表單數(shù)據(jù)被編碼為key/value格式發(fā)送到服務(wù)器（表單默認(rèn)的提交數(shù)據(jù)的格式）
另外一種常見的媒體格式是上傳文件之時使用的：
multipart/form-data ： 需要在表單中進(jìn)行文件上傳時，就需要使用該格式

Content-Length
表示內(nèi)容長度。只有當(dāng)瀏覽器使用持久HTTP連接時才需要這個數(shù)據(jù)。如果你想要利用持久連接的優(yōu)勢，可以把輸出文檔寫入 ByteArrayOutputStream，完成后查看其大小，然后把該值放入Content-Length頭，最后通過byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容。
Expires
應(yīng)該在什么時候認(rèn)為文檔已經(jīng)過期，從而不再緩存它？
Server
包含服務(wù)器的信息，例如名稱、版本號…
Set-Cookie
設(shè)置 Cookie。響應(yīng)頭中 Set-Cookie 用于告訴瀏覽器需要將次內(nèi)容放置 Cookie 中，下次請求將 Cookie 帶上。
Location
表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。Location通常不是直接設(shè)置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設(shè)置狀態(tài)代碼為302。
Refresh
表示瀏覽器應(yīng)該在多少時間之后刷新文檔，以秒計。除了刷新當(dāng)前文檔之外，你還可以通過setHeader(“Refresh”, “5; URL=http://host/path”)讓瀏覽器讀取指定的頁面。
注意這種功能通常是通過設(shè)置HTML頁面HEAD區(qū)的＜META HTTP-EQUIV=“Refresh” CONTENT="5;URL=http://host/path"＞實現(xiàn)，這是因為，自動刷新或重定向?qū)τ谀切┎荒苁褂肅GI或Servlet的HTML編寫者十分重要。但是，對于Servlet來說，直接設(shè)置Refresh頭更加方便。

注意Refresh的意義是"N秒之后刷新本頁面或訪問指定頁面"，而不是"每隔N秒刷新本頁面或訪問指定頁面"。因此，連續(xù)刷新要求每次都發(fā)送一個Refresh頭，而發(fā)送204狀態(tài)代碼則可以阻止瀏覽器繼續(xù)刷新，不管是使用Refresh頭還是＜META HTTP-EQUIV=“Refresh” …＞。

注意Refresh頭不屬于HTTP 1.1正式規(guī)范的一部分，而是一個擴(kuò)展，但Netscape和IE都支持它。

WWW-Authenticate
客戶應(yīng)該在Authorization頭中提供什么類型的授權(quán)信息？在包含401（Unauthorized）狀態(tài)行的應(yīng)答中這個頭是必需的。例如，response.setHeader(“WWW-Authenticate”, “BASIC realm=＼“executives＼””)。
注意Servlet一般不進(jìn)行這方面的處理，而是讓W(xué)eb服務(wù)器的專門機(jī)制來控制受密碼保護(hù)頁面的訪問（例如.htaccess）。

4）空行

5）響應(yīng)體（Response Body）

響應(yīng)體，也能叫正文，響應(yīng)的數(shù)據(jù)都存在正文中，例如請求一個網(wǎng)頁，正文就是網(wǎng)頁的 HTML代碼。

03 抓包分析

根據(jù) HTTP 標(biāo)準(zhǔn)，HTTP 請求可以使用多種請求方法。
HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD 方法。
HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

1）GET（一個Hello接口）

Postman
- 請求報文
  postman做了很深層次的封裝，基本看不到HTTP相關(guān)的報文信息，只有簡單的Headers、Cookies等信息。
- 響應(yīng)報文
  只有Body、以及一些基本信息，同樣封裝的狠，看不到更多的信息。
Burp Suite Community Edition
這個工具，改報文重試使用會比較方便，但還是不太適合用于底層抓包學(xué)習(xí)。
Wireshark
Http協(xié)議其實只是“報文數(shù)據(jù)”，其實所有應(yīng)用層也都是不同格式的“報文數(shù)據(jù)”而已，到達(dá)傳輸層都是依賴于TCP、UDP來建立傳輸通道，操作系統(tǒng)使用FD文件描述符來控制傳輸通道，通過4元組來識別，在不同硬件級別如路由器、網(wǎng)關(guān)、ECS上都會有不同程度的“操作系統(tǒng)”“嵌入式系統(tǒng)”來解析數(shù)據(jù)包，最終通過物理層進(jìn)行光電信號的傳輸。

過濾條件：
(http or tcp) and ip.addr == 192.168.50.223

Java測試源代碼：

@Slf4j
@RestController
public class TempController {
    // 支持以下幾種方法：GET、POST、OPTIONS、HEAD、PUT、DELETE、PATCH、
    @RequestMapping(value = "/hello", method = {RequestMethod.GET, RequestMethod.POST, RequestMethod.OPTIONS, RequestMethod.HEAD,
            RequestMethod.PUT, RequestMethod.DELETE, RequestMethod.PATCH})
    public ResultVo hello() {
        return new ResultUtil().setSuccessMsg();
    }
}

請求報文：

響應(yīng)報文：
網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

第一層，數(shù)據(jù)比特（物理層）
以太網(wǎng)幀表示了數(shù)據(jù)通過物理介質(zhì)傳輸。
給出了數(shù)據(jù)幀的全局信息，包括幀長，幀到達(dá)的時間，接口的編號和幀的類型。

Frame 20: 265 bytes on wire (2120 bits), 265 bytes captured (2120 bits) on interface \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}, id 0
    Section number: 1
    Interface id: 0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})
        Interface name: \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}
        Interface description: 以太網(wǎng)
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr 10, 2024 08:38:07.322193000 中國標(biāo)準(zhǔn)時間
    UTC Arrival Time: Apr 10, 2024 00:38:07.322193000 UTC
    Epoch Arrival Time: 1712709487.322193000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.001178000 seconds]
    [Time delta from previous displayed frame: 0.001178000 seconds]
    [Time since reference or first frame: 1.648897000 seconds]
    Frame Number: 20
    Frame Length: 265 bytes (2120 bits)
    Capture Length: 265 bytes (2120 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:http]
    [Coloring Rule Name: HTTP]
    [Coloring Rule String: http || tcp.port == 80 || http2]

該數(shù)據(jù)包通過以太網(wǎng)傳輸，其內(nèi)容涉及到了 IP、TCP 和 HTTP 協(xié)議。此信息有助于網(wǎng)絡(luò)分析人員深入了解數(shù)據(jù)包的特征和通信情況。
根據(jù)提供的數(shù)據(jù)包分析信息，這是關(guān)于第 20 幀的詳細(xì)信息：

數(shù)據(jù)包長度：265 字節(jié)（2120 位），采用以太網(wǎng)封裝。
接口信息：
接口ID：0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})
接口名稱：\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}
接口描述：以太網(wǎng)
封裝類型：以太網(wǎng) (Ethernet)
到達(dá)時間：Apr 10, 2024 08:38:07.322193000 中國標(biāo)準(zhǔn)時間
UTC 到達(dá)時間：Apr 10, 2024 00:38:07.322193000 UTC
Epoch 到達(dá)時間：1712709487.322193000
時間偏移：0.000000000 秒
距上一個捕獲幀的時間差：0.001178000 秒
距上一個顯示幀的時間差：0.001178000 秒
自參考或第一個幀以來的時間：1.648897000 秒
數(shù)據(jù)包編號：20
幀長度：265 字節(jié)（2120 位）
捕獲長度：265 字節(jié)（2120 位）
協(xié)議層次：以太網(wǎng)、以太網(wǎng)類型、IP、TCP、HTTP
著色規(guī)則名：HTTP
著色規(guī)則字符串：http || tcp.port == 80 || http2

Frame 23: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}, id 0
    Section number: 1
    Interface id: 0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})
        Interface name: \Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}
        Interface description: 以太網(wǎng)
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr 10, 2024 08:38:07.344797000 中國標(biāo)準(zhǔn)時間
    UTC Arrival Time: Apr 10, 2024 00:38:07.344797000 UTC
    Epoch Arrival Time: 1712709487.344797000
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 0.002458000 seconds]
    [Time delta from previous displayed frame: 0.002458000 seconds]
    [Time since reference or first frame: 1.671501000 seconds]
    Frame Number: 23
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp:http:json]
    [Coloring Rule Name: HTTP]
    [Coloring Rule String: http || tcp.port == 80 || http2]

該數(shù)據(jù)包通過以太網(wǎng)傳輸，內(nèi)容涉及到了 IP、TCP、HTTP 和 JSON 協(xié)議。網(wǎng)絡(luò)分析人員可利用這些信息進(jìn)一步了解數(shù)據(jù)包的內(nèi)容和通信情況，有助于進(jìn)行網(wǎng)絡(luò)故障排除或安全分析。
根據(jù)提供的數(shù)據(jù)包分析信息，這是關(guān)于第 23 幀的詳細(xì)信息：

數(shù)據(jù)包長度：60 字節(jié)（480 位），采用以太網(wǎng)封裝。
接口信息：
接口ID：0 (\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A})
接口名稱：\Device\NPF_{D9FB5F55-8918-4224-8467-3E2E78713D8A}
接口描述：以太網(wǎng)
封裝類型：以太網(wǎng) (Ethernet)
到達(dá)時間：Apr 10, 2024 08:38:07.344797000 中國標(biāo)準(zhǔn)時間
UTC 到達(dá)時間：Apr 10, 2024 00:38:07.344797000 UTC
Epoch 到達(dá)時間：1712709487.344797000
時間偏移：0.000000000 秒
距上一個捕獲幀的時間差：0.002458000 秒
距上一個顯示幀的時間差：0.002458000 秒
自參考或第一個幀以來的時間：1.671501000 秒
數(shù)據(jù)包編號：23
幀長度：60 字節(jié)（480 位）
捕獲長度：60 字節(jié)（480 位）
協(xié)議層次：以太網(wǎng)、以太網(wǎng)類型、IP、TCP、HTTP、JSON
著色規(guī)則名：HTTP
著色規(guī)則字符串：http || tcp.port == 80 || http2
第二行，數(shù)據(jù)幀（數(shù)據(jù)鏈路層）
Ethernet II - MAC 地址用于在局域網(wǎng)中唯一標(biāo)識設(shè)備。
可以看到以太幀頭部包括的三個字段，目的MAC地址，源MAC地址、類型字段，類型字段取值為十六進(jìn)制的0800，說明數(shù)據(jù)幀中包含的是一個IP分組。

Ethernet II, Src: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a), Dst: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)
    Destination: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)
        Address: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)
        Address: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)

這段信息提供了源地址、目標(biāo)地址和數(shù)據(jù)包類型等信息，有助于網(wǎng)絡(luò)分析人員識別和理解網(wǎng)絡(luò)通信中不同設(shè)備之間的通信關(guān)系。MAC 地址用于在局域網(wǎng)環(huán)境中唯一標(biāo)識設(shè)備，而類型字段可以告訴我們該幀中封裝的數(shù)據(jù)包是什么類型的協(xié)議。
根據(jù)提供的以太網(wǎng)幀信息進(jìn)行分析：

源地址（Source）：GigaByteTech_3f:c8:7a（MAC 地址為 e0:d5:5e:3f:c8:7a）
- 地址類型：全球唯一地址（工廠默認(rèn)）
- 地址類型：單播地址
目標(biāo)地址（Destination）：RuijieNetwor_1d:4c:55（MAC 地址為 c0:b8:e6:1d:4c:55）
- 地址類型：全球唯一地址（工廠默認(rèn)）
- 地址類型：單播地址
類型：IPv4 (0x0800) 表示該幀中封裝了一個 IPv4 數(shù)據(jù)包。

Ethernet II, Src: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55), Dst: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)
    Destination: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)
        Address: GigaByteTech_3f:c8:7a (e0:d5:5e:3f:c8:7a)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)
        Address: RuijieNetwor_1d:4c:55 (c0:b8:e6:1d:4c:55)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
    Padding: 00

這段信息提供了源地址、目標(biāo)地址和數(shù)據(jù)包類型等信息，有助于網(wǎng)絡(luò)分析人員識別和理解發(fā)送方和接收方之間的通信關(guān)系。MAC 地址用于在局域網(wǎng)環(huán)境中唯一標(biāo)識設(shè)備，而類型字段可以告訴我們該幀中封裝的數(shù)據(jù)包是什么類型的協(xié)議。填充字段主要用于數(shù)據(jù)包長度的調(diào)整和對齊。
根據(jù)提供的以太網(wǎng)幀信息進(jìn)行分析：

源地址（Source）：RuijieNetwor_1d:4c:55（MAC 地址為 c0:b8:e6:1d:4c:55）
- 地址類型：全球唯一地址（工廠默認(rèn)）
- 地址類型：單播地址
目標(biāo)地址（Destination）：GigaByteTech_3f:c8:7a（MAC 地址為 e0:d5:5e:3f:c8:7a）
- 地址類型：全球唯一地址（工廠默認(rèn)）
- 地址類型：單播地址
類型：IPv4 (0x0800) 表示該幀中封裝了一個 IPv4 數(shù)據(jù)包。
填充（Padding）：填充字段為 00，用于確保數(shù)據(jù)包達(dá)到最小長度要求。
第三行，IP數(shù)據(jù)包（網(wǎng)絡(luò)層）
Internet Protocol Version 4 (IPv4) - 用于在網(wǎng)絡(luò)上唯一標(biāo)識設(shè)備，并提供路由功能。
包括版本號4，頭部長度20字節(jié)，服務(wù)類型，數(shù)據(jù)報總長度，用于分片的標(biāo)志字0，分片偏移字段0，說明這是一個完整的IP數(shù)據(jù)報。沒有被分片。生存周期128，表示最多允許經(jīng)過128跳路由器的轉(zhuǎn)發(fā)。協(xié)議字段1，說明IP分組里面封裝的是一個ICMP報文，頭部校驗、源IP地址，目的IP地址。我們可以對照以太網(wǎng)IP協(xié)議規(guī)范的報文格式來檢查ICMP報文該字段是符合規(guī)范的。

Internet Protocol Version 4, Src: 192.168.10.238, Dst: 192.168.50.223
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 251
    Identification: 0x8e9d (36509)
    010. .... = Flags: 0x2, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: TCP (6)
    Header Checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.10.238
    Destination Address: 192.168.50.223

這些信息描述了IPv4數(shù)據(jù)包的各種屬性，包括頭部長度、差異化服務(wù)、總長度、標(biāo)識、標(biāo)記位、協(xié)議類型等。網(wǎng)絡(luò)分析人員可以利用這些信息來深入了解數(shù)據(jù)包的特征以及網(wǎng)絡(luò)通信中涉及的設(shè)備和協(xié)議。
根據(jù)提供的 IPv4 數(shù)據(jù)包信息進(jìn)行分析：

版本（Version）：IPv4 版本為 4。
頭部長度（Header Length）：20 字節(jié)（5 個 32 位字）。
區(qū)分服務(wù)字段（Differentiated Services Field）：0x00
差異化服務(wù)代碼點（DSCP）：CS0（默認(rèn)）
顯式擁塞通知（ECN）：未啟用
總長度（Total Length）：251 字節(jié)。
標(biāo)識（Identification）：0x8e9d（36509）。
標(biāo)記位（Flags）：0x2，表示"不分片"（Don’t fragment）。
分片偏移（Fragment Offset）：0。
存活時間（Time to Live）：128。
協(xié)議（Protocol）：TCP，協(xié)議編號為 6。
頭部校驗和（Header Checksum）：0x0000（校驗和驗證已禁用）。
源地址（Source Address）為 192.168.10.238，
目標(biāo)地址（Destination Address）為 192.168.50.223。

Internet Protocol Version 4, Src: 192.168.50.223, Dst: 192.168.10.238
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 45
    Identification: 0xe673 (58995)
    010. .... = Flags: 0x2, Don't fragment
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 63
    Protocol: TCP (6)
    Header Checksum: 0x9639 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.50.223
    Destination Address: 192.168.10.238

這些信息描述了該 IPv4 數(shù)據(jù)包的各種屬性，如頭部長度、差異化服務(wù)、總長度、標(biāo)識、標(biāo)記位、協(xié)議類型等。網(wǎng)絡(luò)分析人員可以利用這些信息來深入了解數(shù)據(jù)包的特征以及網(wǎng)絡(luò)通信中涉及的設(shè)備和協(xié)議。
根據(jù)提供的IPv4數(shù)據(jù)包信息進(jìn)行分析：

版本（Version）：IPv4 版本為 4。
頭部長度（Header Length）：20 字節(jié)（5 個 32 位字）。
區(qū)分服務(wù)字段（Differentiated Services Field）：0x00
差異化服務(wù)代碼點（DSCP）：CS0（默認(rèn)）
顯式擁塞通知（ECN）：未啟用
總長度（Total Length）：45 字節(jié)。
標(biāo)識（Identification）：0xe673（58995）。
標(biāo)記位（Flags）：0x2，表示"不分片"（Don’t fragment）。
分片偏移（Fragment Offset）：0。
存活時間（Time to Live）：63。
協(xié)議（Protocol）：TCP，協(xié)議編號為 6。
頭部校驗和（Header Checksum）：0x9639（校驗和驗證已禁用）。
源地址（Source Address）為 192.168.50.223，
目標(biāo)地址（Destination Address）為 192.168.10.238。
第四行，TCP報文段（傳輸層）
Transmission Control Protocol (TCP) - 提供可靠的數(shù)據(jù)傳輸，使用端口號來標(biāo)識不同的應(yīng)用程序通信。

Transmission Control Protocol, Src Port: 53387, Dst Port: 7778, Seq: 1, Ack: 1, Len: 211
    Source Port: 53387
    Destination Port: 7778
    [Stream index: 9]
    [Conversation completeness: Incomplete, DATA (15)]
        ..0. .... = RST: Absent
        ...0 .... = FIN: Absent
        .... 1... = Data: Present
        .... .1.. = ACK: Present
        .... ..1. = SYN-ACK: Present
        .... ...1 = SYN: Present
        [Completeness Flags: ··DASS]
    [TCP Segment Len: 211]
    Sequence Number: 1    (relative sequence number)
    Sequence Number (raw): 3565710654
    [Next Sequence Number: 212    (relative sequence number)]
    Acknowledgment Number: 1    (relative ack number)
    Acknowledgment number (raw): 4139666102
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Accurate ECN: Not set
        .... 0... .... = Congestion Window Reduced: Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window: 8212
    [Calculated window size: 2102272]
    [Window size scaling factor: 256]
    Checksum: 0xc00b [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [Timestamps]
        [Time since first frame in this TCP stream: 0.001515000 seconds]
        [Time since previous frame in this TCP stream: 0.001178000 seconds]
    [SEQ/ACK analysis]
        [iRTT: 0.000337000 seconds]
        [Bytes in flight: 211]
        [Bytes sent since last PSH flag: 211]
    TCP payload (211 bytes)

在 TCP 數(shù)據(jù)包中，源端口和目標(biāo)端口定義了通信所涉及的應(yīng)用程序，標(biāo)志字段描述了該數(shù)據(jù)包的狀態(tài)，序列號和確認(rèn)號用于 TCP 數(shù)據(jù)包的順序控制和可靠性傳輸。窗口大小表示接收端的可用緩沖區(qū)大小，檢驗和用于數(shù)據(jù)完整性驗證。這些信息有助于理解網(wǎng)絡(luò)通信中傳輸?shù)臄?shù)據(jù)包特征和行為。
根據(jù)提供的傳輸控制協(xié)議（TCP）數(shù)據(jù)包信息進(jìn)行分析：

源端口（Source Port）：53387
目標(biāo)端口（Destination Port）：7778
TCP 標(biāo)志（Flags）：0x018 (PSH, ACK)
PSH（Push）: 數(shù)據(jù)段應(yīng)該立即被傳送給應(yīng)用層。
ACK（Acknowledgment）: 確認(rèn)號字段有效。
序列號（Sequence Number）：1 (相對序列號)，原始序列號為 3565710654。
下一個序列號：212 (下一個相對序列號)。
確認(rèn)號（Acknowledgment Number）：1 (相對確認(rèn)號)，原始確認(rèn)號為 4139666102。
頭部長度（Header Length）：20 字節(jié) (5 個 32 位字)。
窗口大?。╓indow Size）：8212，經(jīng)過窗口大小縮放后為 2102272。
數(shù)據(jù)長度（TCP Segment Length）：211 字節(jié)。
檢驗和（Checksum）：0xc00b（未驗證）。
緊急指針（Urgent Pointer）：0。

Transmission Control Protocol, Src Port: 7778, Dst Port: 53387, Seq: 419, Ack: 212, Len: 5
    Source Port: 7778
    Destination Port: 53387
    [Stream index: 9]
    [Conversation completeness: Incomplete, DATA (15)]
        ..0. .... = RST: Absent
        ...0 .... = FIN: Absent
        .... 1... = Data: Present
        .... .1.. = ACK: Present
        .... ..1. = SYN-ACK: Present
        .... ...1 = SYN: Present
        [Completeness Flags: ··DASS]
    [TCP Segment Len: 5]
    Sequence Number: 419    (relative sequence number)
    Sequence Number (raw): 4139666520
    [Next Sequence Number: 424    (relative sequence number)]
    Acknowledgment Number: 212    (relative ack number)
    Acknowledgment number (raw): 3565710865
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Accurate ECN: Not set
        .... 0... .... = Congestion Window Reduced: Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window: 237
    [Calculated window size: 30336]
    [Window size scaling factor: 128]
    Checksum: 0x3703 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [Timestamps]
        [Time since first frame in this TCP stream: 0.024119000 seconds]
        [Time since previous frame in this TCP stream: 0.002458000 seconds]
    [SEQ/ACK analysis]
        [iRTT: 0.000337000 seconds]
        [Bytes in flight: 423]
        [Bytes sent since last PSH flag: 5]
    TCP payload (5 bytes)
    TCP segment data (5 bytes)

在這個 TCP 數(shù)據(jù)包中，源端口和目標(biāo)端口定義了通信雙方的應(yīng)用程序，標(biāo)志字段描述了數(shù)據(jù)包狀態(tài)，序列號和確認(rèn)號用于 TCP 數(shù)據(jù)包的順序控制和可靠性傳輸。窗口大小表示接收方的可用緩沖區(qū)大小，檢驗和用于數(shù)據(jù)完整性驗證。這些信息有助于理解網(wǎng)絡(luò)通信中傳輸?shù)臄?shù)據(jù)包特征和行為。
根據(jù)提供的傳輸控制協(xié)議（TCP）數(shù)據(jù)包信息進(jìn)行分析：

源端口（Source Port）：7778
目標(biāo)端口（Destination Port）：53387
TCP 標(biāo)志（Flags）：0x018 (PSH, ACK)
PSH（Push）: 數(shù)據(jù)段應(yīng)該立即被傳送給應(yīng)用層。
ACK（Acknowledgment）: 確認(rèn)號字段有效。
序列號（Sequence Number）：419 (相對序列號)，原始序列號為 4139666520。
下一個序列號：424 (下一個相對序列號)。
確認(rèn)號（Acknowledgment Number）：212 (相對確認(rèn)號)，原始確認(rèn)號為 3565710865。
頭部長度（Header Length）：20 字節(jié) (5 個 32 位字)。
窗口大?。╓indow Size）：237，經(jīng)過窗口大小縮放后為 30336。
數(shù)據(jù)長度（TCP Segment Length）：5 字節(jié)。
檢驗和（Checksum）：0x3703（未驗證）。

第五行，HTTP報文（應(yīng)用層）
Hypertext Transfer Protocol (HTTP) - 用于在客戶端和服務(wù)器之間傳輸超文本內(nèi)容的協(xié)議。

Hypertext Transfer Protocol
    GET /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET /hello HTTP/1.1\r\n]
            [GET /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: GET
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: 7a4a6ad5-ef7c-482b-b2bf-dcba41a4e281\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 1/1]
    [Response in frame: 23]

在這個 HTTP 請求中，客戶端（User-Agent）使用 PostmanRuntime/7.37.3 進(jìn)行通信，請求的資源為 http://192.168.50.223:7778/hello。請求方法為 GET，表示獲取指定資源。Accept 頭部字段指示客戶端可以接受任何類型的響應(yīng)內(nèi)容。請求頭部中還包括了一些其他信息，如主機(jī)、壓縮和連接方式等。通過這些信息，服務(wù)器可以解析請求并返回相應(yīng)的響應(yīng)。

根據(jù)提供的超文本傳輸協(xié)議（HTTP）請求信息進(jìn)行分析：

請求行：GET /hello HTTP/1.1
請求方法（Request Method）：GET
請求 URI（Request URI）：/hello
請求版本（Request Version）：HTTP/1.1

接下來是請求頭部信息：

User-Agent: PostmanRuntime/7.37.3
Accept: /
Postman-Token: 7a4a6ad5-ef7c-482b-b2bf-dcba41a4e281
Host: 192.168.50.223:7778
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
最后是空行 \r\n，表示請求頭部結(jié)束。

Hypertext Transfer Protocol, has 2 chunks (including last chunk)
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Set-Cookie: JSESSIONID=AC55C30B845F298471BDAC902F865616; Path=/; HttpOnly\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 00:38:08 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.022604000 seconds]
    [Request in frame: 20]
    [Request URI: http://192.168.50.223:7778/hello]
    HTTP chunked response
        Data chunk (86 octets)
            Chunk size: 86 octets
            Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323730393438383234332c2264617461223a6e756c6c7d
            Chunk boundary: 0d0a
        End of chunked encoding
            Chunk size: 0 octets
        \r\n
    File Data: 86 bytes

在 HTTP 響應(yīng)中，服務(wù)器返回了狀態(tài)碼 200，表示請求成功。響應(yīng)內(nèi)容采用了分塊傳輸編碼（chunked transfer encoding），數(shù)據(jù)被分成多個塊傳送，每個塊包含一個塊大小以及具體的數(shù)據(jù)。最后一個塊的大小為 0，表示所有數(shù)據(jù)塊已全部傳輸，即分塊編碼結(jié)束。
在這個響應(yīng)中，返回了一段 JSON 數(shù)據(jù)，長度為 86 字節(jié)。數(shù)據(jù)塊編碼中，包含了經(jīng)過編碼處理的 JSON 數(shù)據(jù)和塊邊界標(biāo)志 0d0a（回車換行）。通過這些信息，客戶端可以解析數(shù)據(jù)塊并處理對應(yīng)的響應(yīng)內(nèi)容。
根據(jù)提供的超文本傳輸協(xié)議（HTTP）響應(yīng)信息進(jìn)行分析：

響應(yīng)行：HTTP/1.1 200
響應(yīng)版本（Response Version）：HTTP/1.1
狀態(tài)碼（Status Code）：200
狀態(tài)碼描述：OK

接下來是響應(yīng)頭部信息：

Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Set-Cookie: JSESSIONID=AC55C30B845F298471BDAC902F865616; Path=/; HttpOnly
Content-Type: application/json
Transfer-Encoding: chunked
Date: Wed, 10 Apr 2024 00:38:08 GMT
Keep-Alive: timeout=60
Connection: keep-alive

2）POST

請求報文
網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

Hypertext Transfer Protocol
    POST /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): POST /hello HTTP/1.1\r\n]
            [POST /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: POST
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: aa66df48-7879-4f4a-b447-46d47e0e3d73\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n
        Cookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E
    Content-Length: 0\r\n
        [Content length: 0]
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 1/1]
    [Response in frame: 35]

這段文本是一個HTTP請求的數(shù)據(jù)包內(nèi)容。下面是對該HTTP請求的分析：

請求行：POST /hello HTTP/1.1 表示這是一個使用POST方法，目標(biāo)地址為/hello的HTTP/1.1版本的請求。
請求頭部：
- User-Agent: PostmanRuntime/7.37.3：標(biāo)識客戶端應(yīng)用程序的用戶代理信息。
- Accept: /：指定客戶端能夠處理的MIME類型。
- Postman-Token: aa66df48-7879-4f4a-b447-46d47e0e3d73：Postman工具生成的令牌。
- Host: 192.168.50.223:7778：指定請求的主機(jī)和端口號。
- Accept-Encoding: gzip, deflate, br：指定客戶端可以支持的壓縮算法。
- Connection: keep-alive：指示客戶端與服務(wù)器之間的連接保持活動狀態(tài)。
- Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含會話標(biāo)識符的Cookie。
- Content-Length: 0：指定請求正文的長度為0，表示請求中沒有主體內(nèi)容。
完整請求URI：http://192.168.50.223:7778/hello 表示完整的請求URI。
分析結(jié)論：此請求是使用POST方法發(fā)送到/hello的URL，客戶端是通過Postman工具發(fā)送的，請求不包含任何主體內(nèi)容（Content）。

綜上所述，這是一個簡單的HTTP POST請求，由Postman工具發(fā)起，針對http://192.168.50.223:7778/hello的目標(biāo)地址，在請求頭部中包含了各種元數(shù)據(jù)信息，但請求正文為空。

響應(yīng)報文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 01:12:10 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.008740000 seconds]
    [Request in frame: 33]
    [Request URI: http://192.168.50.223:7778/hello]
    HTTP chunked response
        Data chunk (86 octets)
            Chunk size: 86 octets
            Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313533303535362c2264617461223a6e756c6c7d
            Chunk boundary: 0d0a
        End of chunked encoding
            Chunk size: 0 octets
        \r\n
    File Data: 86 bytes

這段文本是一個HTTP響應(yīng)的數(shù)據(jù)包內(nèi)容，主要針對一個使用了chunked傳輸編碼的響應(yīng)進(jìn)行了分析。下面是對該HTTP響應(yīng)的分析：

響應(yīng)行：HTTP/1.1 200 表示這是一個HTTP/1.1版本的狀態(tài)碼為200（OK）的響應(yīng)。
響應(yīng)頭部：
- Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：表示服務(wù)器對緩存的響應(yīng)做了變化，可能根據(jù)請求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值進(jìn)行響應(yīng)的變化。
- Content-Type: application/json：指定響應(yīng)內(nèi)容的類型為JSON。
- Transfer-Encoding: chunked：指示響應(yīng)體使用了分塊編碼方式傳輸。
- Date: Wed, 10 Apr 2024 01:12:10 GMT：指示響應(yīng)生成的日期和時間。
- Keep-Alive: timeout=60、Connection: keep-alive：表示保持連接活動狀態(tài)，超時時間為60秒。
數(shù)據(jù)塊：在Data chunk中，提供了一部分經(jīng)過編碼的數(shù)據(jù)。
Chunk size: 86 octets：表示該數(shù)據(jù)塊的大小為86字節(jié)。
Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313533303535362c2264617461223a6e756c6c7d：該數(shù)據(jù)塊的內(nèi)容，可能是經(jīng)過壓縮或其他編碼的JSON數(shù)據(jù)。
Chunk boundary: 0d0a：表示數(shù)據(jù)塊邊界。
結(jié)束標(biāo)志：End of chunked encoding 中的 Chunk size: 0 octets 表示編碼的結(jié)束。
文件數(shù)據(jù)：總共有86字節(jié)的文件數(shù)據(jù)。

綜上所述，這是一個以分塊編碼方式傳輸?shù)腍TTP響應(yīng)，并且響應(yīng)正文含有經(jīng)過編碼的數(shù)據(jù)塊，最后以結(jié)束標(biāo)志表示編碼結(jié)束。

3）OPTIONS

請求報文

Hypertext Transfer Protocol
    OPTIONS /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): OPTIONS /hello HTTP/1.1\r\n]
            [OPTIONS /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: OPTIONS
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: a6f51f30-a7b6-4dc2-bba9-355d269e5150\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n
        Cookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 1/1]
    [Response in frame: 4701]

這段文本是一個HTTP請求的數(shù)據(jù)包內(nèi)容。下面是對該HTTP請求的分析：
請求行：OPTIONS /hello HTTP/1.1 表示這是一個使用OPTIONS方法，目標(biāo)地址為/hello的HTTP/1.1版本的請求。
請求頭部：

User-Agent: PostmanRuntime/7.37.3：標(biāo)識客戶端應(yīng)用程序的用戶代理信息。
Accept: /：指定客戶端能夠處理的MIME類型。
Postman-Token: a6f51f30-a7b6-4dc2-bba9-355d269e5150：Postman工具生成的令牌。
Host: 192.168.50.223:7778：指定請求的主機(jī)和端口號。
Accept-Encoding: gzip, deflate, br：指定客戶端可以支持的壓縮算法。
Connection: keep-alive：指示客戶端與服務(wù)器之間的連接保持活動狀態(tài)。
Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含會話標(biāo)識符的Cookie。
完整請求URI：http://192.168.50.223:7778/hello 表示完整的請求URI。
分析結(jié)論：此請求是使用OPTIONS方法發(fā)送到/hello的URL，客戶端是通過Postman工具發(fā)送的，請求中包含了各種元數(shù)據(jù)信息，但沒有主體內(nèi)容（Content）。

綜上所述，這是一個簡單的HTTP OPTIONS請求，由Postman工具發(fā)起，針對http://192.168.50.223:7778/hello的目標(biāo)地址，在請求頭部中包含了各種元數(shù)據(jù)信息，但請求正文為空。

響應(yīng)報文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 01:15:09 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.009532000 seconds]
    [Request in frame: 4698]
    [Request URI: http://192.168.50.223:7778/hello]
    HTTP chunked response
        Data chunk (86 octets)
            Chunk size: 86 octets
            Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313730393933362c2264617461223a6e756c6c7d
            Chunk boundary: 0d0a
        End of chunked encoding
            Chunk size: 0 octets
        \r\n
    File Data: 86 bytes

這段文本描述了一個HTTP響應(yīng)的數(shù)據(jù)包內(nèi)容，主要涉及使用了chunked傳輸編碼的響應(yīng)。以下是對該HTTP響應(yīng)的分析：

響應(yīng)行：HTTP/1.1 200 表示這是一個狀態(tài)碼為200（OK）的HTTP/1.1版本的響應(yīng)。
響應(yīng)頭部：
- Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服務(wù)器對緩存的響應(yīng)做了變化，可能會根據(jù)請求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值進(jìn)行響應(yīng)的調(diào)整。
- Content-Type: application/json：指定響應(yīng)內(nèi)容的類型為JSON。
- Transfer-Encoding: chunked：表明響應(yīng)體使用了分塊編碼方式傳輸。
- Date: Wed, 10 Apr 2024 01:15:09 GMT：表示響應(yīng)產(chǎn)生的日期和時間。
- Keep-Alive: timeout=60、Connection: keep-alive：說明保持連接活動狀態(tài)，超時時間為60秒。
數(shù)據(jù)塊：在Data chunk中，提供了一部分經(jīng)過編碼的數(shù)據(jù)。
- Chunk size: 86 octets：表示該數(shù)據(jù)塊的大小為86字節(jié)。
- Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313730393933362c2264617461223a6e756c7c7d：該數(shù)據(jù)塊的內(nèi)容，可能是經(jīng)過壓縮或其他編碼的JSON數(shù)據(jù)。
- Chunk boundary: 0d0a：表示數(shù)據(jù)塊的邊界。
結(jié)束標(biāo)志：End of chunked encoding 中的 Chunk size: 0 octets 表示編碼的結(jié)束。
文件數(shù)據(jù)：共有86字節(jié)的文件數(shù)據(jù)。

綜上所述，這是一個使用了分塊編碼方式傳輸?shù)腍TTP響應(yīng)，響應(yīng)正文包含了經(jīng)過編碼的數(shù)據(jù)塊，并用結(jié)束標(biāo)志表示編碼的結(jié)束。

4）HEAD

請求報文

Hypertext Transfer Protocol
    HEAD /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): HEAD /hello HTTP/1.1\r\n]
            [HEAD /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: HEAD
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: 1ee6d1d3-34f1-4e83-9cb9-86f7e0ca4cb0\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n
        Cookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 2/2]
    [Prev request in frame: 4698]
    [Response in frame: 5172]

這段文本是一個HTTP請求的數(shù)據(jù)包內(nèi)容。以下是對該HTTP請求的分析：

請求行：HEAD /hello HTTP/1.1 表示這是一個使用HEAD方法，目標(biāo)地址為/hello的HTTP/1.1版本的請求。
請求頭部：
- User-Agent: PostmanRuntime/7.37.3：標(biāo)識客戶端應(yīng)用程序的用戶代理信息。
- Accept: /：指定客戶端能夠處理的MIME類型。
- Postman-Token: 1ee6d1d3-34f1-4e83-9cb9-86f7e0ca4cb0：Postman工具生成的令牌。
- Host: 192.168.50.223:7778：指定請求的主機(jī)和端口號。
- Accept-Encoding: gzip, deflate, br：指定客戶端可以支持的壓縮算法。
- Connection: keep-alive：表示客戶端與服務(wù)器之間的連接保持活動狀態(tài)。
- Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含會話標(biāo)識符的Cookie。
完整請求URI：http://192.168.50.223:7778/hello 表示完整的請求URI。
其他信息：
- [HTTP request 2/2]：表示這是第二個HTTP請求中的第二個請求。
- [Prev request in frame: 4698]：指明前一個請求是在幀 4698 中。
- [Response in frame: 5172]：說明響應(yīng)在幀 5172 中。

綜上所述，這是一個使用HEAD方法發(fā)送到/hello的URL的HTTP請求。請求由Postman工具發(fā)起，包含了各種元數(shù)據(jù)信息，但沒有主體內(nèi)容（Content）。這次請求是第二個HTTP請求中的第二個，并且包含了前一個請求和響應(yīng)的幀信息。

響應(yīng)報文

Hypertext Transfer Protocol
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 01:15:51 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 2/2]
    [Time since request: 0.004596000 seconds]
    [Prev request in frame: 4698]
    [Prev response in frame: 4701]
    [Request in frame: 5171]
    [Request URI: http://192.168.50.223:7778/hello]

這段文本描述了一個HTTP響應(yīng)的數(shù)據(jù)包內(nèi)容。以下是對該HTTP響應(yīng)的分析：

響應(yīng)行：HTTP/1.1 200 表示這是一個狀態(tài)碼為200（OK）的HTTP/1.1版本的響應(yīng)。
響應(yīng)頭部：
- Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服務(wù)器對緩存的響應(yīng)做了變化，可能會根據(jù)請求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值進(jìn)行響應(yīng)的調(diào)整。
- Content-Type: application/json：指定響應(yīng)內(nèi)容的類型為JSON。
- Transfer-Encoding: chunked：表明響應(yīng)體使用了分塊編碼方式傳輸。
- Date: Wed, 10 Apr 2024 01:15:51 GMT：表示響應(yīng)產(chǎn)生的日期和時間。
- Keep-Alive: timeout=60、Connection: keep-alive：說明保持連接活動狀態(tài)，超時時間為60秒。
其他信息：
- [HTTP response 2/2]：表示這是第二個HTTP響應(yīng)中的第二個響應(yīng)。
- [Time since request: 0.004596000 seconds]：距離發(fā)出請求的時間為0.004596秒。
- [Prev request in frame: 4698]：說明前一個請求在幀 4698 中。
- [Prev response in frame: 4701]：指明前一個響應(yīng)在幀 4701 中。
- [Request in frame: 5171]：表示請求在幀 5171 中。
請求URI：http://192.168.50.223:7778/hello 表示請求的完整URI。

綜上所述，這是一個狀態(tài)碼為200（OK）的HTTP響應(yīng)，響應(yīng)內(nèi)容為application/json類型，并且使用了分塊編碼方式傳輸。響應(yīng)中包含了一些頭部信息，以及與前一個請求和響應(yīng)相關(guān)的幀信息。

5）PUT

請求報文

Hypertext Transfer Protocol
    PUT /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): PUT /hello HTTP/1.1\r\n]
            [PUT /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: PUT
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: e6e536a0-17bd-44c3-a88d-f74f0055c630\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n
        Cookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E
    Content-Length: 0\r\n
        [Content length: 0]
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 3/3]
    [Prev request in frame: 5171]
    [Response in frame: 5958]

這段文本是一個HTTP請求的數(shù)據(jù)包內(nèi)容。以下是對該HTTP請求的分析：

請求行：PUT /hello HTTP/1.1 表示這是一個使用PUT方法，目標(biāo)地址為/hello的HTTP/1.1版本的請求。
請求頭部：
- User-Agent: PostmanRuntime/7.37.3：標(biāo)識客戶端應(yīng)用程序的用戶代理信息。
- Accept: /：指定客戶端能夠處理的MIME類型。
- Postman-Token: e6e536a0-17bd-44c3-a88d-f74f0055c630：Postman工具生成的令牌。
- Host: 192.168.50.223:7778：指定請求的主機(jī)和端口號。
- Accept-Encoding: gzip, deflate, br：指定客戶端可以支持的壓縮算法。
- Connection: keep-alive：表示客戶端與服務(wù)器之間的連接保持活動狀態(tài)。
- Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含會話標(biāo)識符的Cookie。
- Content-Length: 0：說明請求體中的內(nèi)容長度為0字節(jié)。
完整請求URI：http://192.168.50.223:7778/hello 表示完整的請求URI。
其他信息：
- [HTTP request 3/3]：表示這是第三個HTTP請求中的第三個請求。
- [Prev request in frame: 5171]：說明前一個請求在幀 5171 中。
- [Response in frame: 5958]：指明響應(yīng)在幀 5958 中。

綜上所述，這是一個使用PUT方法發(fā)送到/hello的URL的HTTP請求。請求由Postman工具發(fā)起，包含了各種元數(shù)據(jù)信息，但沒有主體內(nèi)容（Content），因為Content-Length為0。這次請求是第三個HTTP請求中的第三個，并且包含了前一個請求和響應(yīng)的幀信息。

響應(yīng)報文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 01:16:33 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 3/3]
    [Time since request: 0.009709000 seconds]
    [Prev request in frame: 5171]
    [Prev response in frame: 5172]
    [Request in frame: 5956]
    [Request URI: http://192.168.50.223:7778/hello]
    HTTP chunked response
        Data chunk (86 octets)
            Chunk size: 86 octets
            Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313739333030322c2264617461223a6e756c6c7d
            Chunk boundary: 0d0a
        End of chunked encoding
            Chunk size: 0 octets
        \r\n
    File Data: 86 bytes

這段文本描述了一個HTTP響應(yīng)的數(shù)據(jù)包內(nèi)容，其中包含了使用分塊編碼傳輸?shù)臄?shù)據(jù)。以下是對該HTTP響應(yīng)的分析：

響應(yīng)行：HTTP/1.1 200 表示這是一個狀態(tài)碼為200（OK）的HTTP/1.1版本的響應(yīng)。
響應(yīng)頭部：
- Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服務(wù)器對緩存的響應(yīng)做了變化，可能會根據(jù)請求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值進(jìn)行響應(yīng)的調(diào)整。
- Content-Type: application/json：指定響應(yīng)內(nèi)容的類型為JSON。
- Transfer-Encoding: chunked：表明響應(yīng)體使用了分塊編碼方式傳輸。
- Date: Wed, 10 Apr 2024 01:16:33 GMT：表示響應(yīng)產(chǎn)生的日期和時間。
- Keep-Alive: timeout=60、Connection: keep-alive：說明保持連接活動狀態(tài)，超時時間為60秒。
其他信息：
- [HTTP response 3/3]：表示這是第三個HTTP響應(yīng)中的第三個響應(yīng)。
- [Time since request: 0.009709000 seconds]：距離發(fā)出請求的時間為0.009709秒。
- [Prev request in frame: 5171]：說明前一個請求在幀 5171 中。
- [Prev response in frame: 5172]：指明前一個響應(yīng)在幀 5172 中。
- [Request in frame: 5956]：表示請求在幀 5956 中。
請求URI：http://192.168.50.223:7778/hello 表示請求的完整URI。
分塊編碼響應(yīng)：
- 第一個數(shù)據(jù)塊：
  Chunk size: 86 octets
  Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313739333030322c2264617461223a6e756c6c7d
  Chunk boundary: 0d0a (CRLF)
- 結(jié)束分塊編碼：
  Chunk size: 0 octets
文件數(shù)據(jù)：86字節(jié)

綜上所述，這是一個狀態(tài)碼為200（OK）的HTTP響應(yīng)，響應(yīng)內(nèi)容為application/json類型，并且使用了分塊編碼方式傳輸。響應(yīng)中包含了一些頭部信息，以及一個包含86個字節(jié)數(shù)據(jù)塊的分塊編碼響應(yīng)。

6）DELETE

請求報文

Hypertext Transfer Protocol
    DELETE /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): DELETE /hello HTTP/1.1\r\n]
            [DELETE /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: DELETE
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: 5baf4561-ec2e-4fa1-b5f7-c5a7fd7381ee\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n
        Cookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 4/4]
    [Prev request in frame: 5956]
    [Response in frame: 6546]

這段文本是一個HTTP請求的數(shù)據(jù)包內(nèi)容。以下是對該HTTP請求的分析：

請求行：DELETE /hello HTTP/1.1 表示這是一個使用DELETE方法，目標(biāo)地址為/hello的HTTP/1.1版本的請求。
請求頭部：
- User-Agent: PostmanRuntime/7.37.3：標(biāo)識客戶端應(yīng)用程序的用戶代理信息。
- Accept: /：指定客戶端能夠處理的MIME類型。
- Postman-Token: 5baf4561-ec2e-4fa1-b5f7-c5a7fd7381ee：Postman工具生成的令牌。
- Host: 192.168.50.223:7778：指定請求的主機(jī)和端口號。
- Accept-Encoding: gzip, deflate, br：指定客戶端可以支持的壓縮算法。
- Connection: keep-alive：表示客戶端與服務(wù)器之間的連接保持活動狀態(tài)。
- Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含會話標(biāo)識符的Cookie。
完整請求URI：http://192.168.50.223:7778/hello 表示完整的請求URI。
其他信息：
- [HTTP request 4/4]：表示這是第四個HTTP請求中的第四個請求。
- [Prev request in frame: 5956]：說明前一個請求在幀 5956 中。
- [Response in frame: 6546]：指明響應(yīng)在幀 6546 中。

綜上所述，這是一個使用DELETE方法發(fā)送到/hello的URL的HTTP請求。請求由Postman工具發(fā)起，包含了各種元數(shù)據(jù)信息。這次請求是第四個HTTP請求中的第四個，并且包含了前一個請求和響應(yīng)的幀信息。

響應(yīng)報文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 01:17:10 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 4/4]
    [Time since request: 0.006411000 seconds]
    [Prev request in frame: 5956]
    [Prev response in frame: 5958]
    [Request in frame: 6544]
    [Request URI: http://192.168.50.223:7778/hello]
    HTTP chunked response
        Data chunk (86 octets)
            Chunk size: 86 octets
            Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313833303937352c2264617461223a6e756c6c7d
            Chunk boundary: 0d0a
        End of chunked encoding
            Chunk size: 0 octets
        \r\n
    File Data: 86 bytes

這段文本描述了一個HTTP響應(yīng)的數(shù)據(jù)包內(nèi)容，其中包含了使用分塊編碼傳輸?shù)臄?shù)據(jù)。以下是對該HTTP響應(yīng)的分析：

響應(yīng)行：HTTP/1.1 200 表示這是一個狀態(tài)碼為200（OK）的HTTP/1.1版本的響應(yīng)。
響應(yīng)頭部：
- Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服務(wù)器對緩存的響應(yīng)做了變化，可能會根據(jù)請求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值進(jìn)行響應(yīng)的調(diào)整。
- Content-Type: application/json：指定響應(yīng)內(nèi)容的類型為JSON。
- Transfer-Encoding: chunked：表明響應(yīng)體使用了分塊編碼方式傳輸。
- Date: Wed, 10 Apr 2024 01:17:10 GMT：表示響應(yīng)產(chǎn)生的日期和時間。
- Keep-Alive: timeout=60、Connection: keep-alive：說明保持連接活動狀態(tài)，超時時間為60秒。
其他信息：
- [HTTP response 4/4]：表示這是第四個HTTP響應(yīng)中的第四個響應(yīng)。
- [Time since request: 0.006411000 seconds]：距離發(fā)出請求的時間為0.006411秒。
- [Prev request in frame: 5956]：說明前一個請求在幀 5956 中。
- [Prev response in frame: 5958]：指明前一個響應(yīng)在幀 5958 中。
- [Request in frame: 6544]：表示請求在幀 6544 中。
請求URI：http://192.168.50.223:7778/hello 表示請求的完整URI。
分塊編碼響應(yīng)：
- 第一個數(shù)據(jù)塊：
  Chunk size: 86 octets
  Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313833303937352c2264617461223a6e756c7c7d
  Chunk boundary: 0d0a (CRLF)
- 結(jié)束分塊編碼：
  Chunk size: 0 octets
文件數(shù)據(jù)：86字節(jié)

綜上所述，這是一個狀態(tài)碼為200（OK）的HTTP響應(yīng)，響應(yīng)內(nèi)容為application/json類型，并且使用了分塊編碼方式傳輸。響應(yīng)中包含了一些頭部信息，以及一個包含86個字節(jié)數(shù)據(jù)塊的分塊編碼響應(yīng)。

7）PATCH

請求報文

Hypertext Transfer Protocol
    PATCH /hello HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): PATCH /hello HTTP/1.1\r\n]
            [PATCH /hello HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: PATCH
        Request URI: /hello
        Request Version: HTTP/1.1
    User-Agent: PostmanRuntime/7.37.3\r\n
    Accept: */*\r\n
    Postman-Token: 777aa266-72c1-4c97-8134-a75cb82c5c0a\r\n
    Host: 192.168.50.223:7778\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Connection: keep-alive\r\n
    Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E\r\n
        Cookie pair: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E
    Content-Length: 0\r\n
        [Content length: 0]
    \r\n
    [Full request URI: http://192.168.50.223:7778/hello]
    [HTTP request 5/5]
    [Prev request in frame: 6544]
    [Response in frame: 8109]

這段文本描述了一個使用PATCH方法的HTTP請求。以下是對該請求的分析：

請求行：PATCH /hello HTTP/1.1 表示這是一個使用PATCH方法，目標(biāo)地址為/hello的HTTP/1.1版本的請求。
請求頭部：
- User-Agent: PostmanRuntime/7.37.3：標(biāo)識客戶端應(yīng)用程序的用戶代理信息。
- Accept: /：指定客戶端能夠處理的MIME類型。
- Postman-Token: 777aa266-72c1-4c97-8134-a75cb82c5c0a：Postman工具生成的令牌。
- Host: 192.168.50.223:7778：指定請求的主機(jī)和端口號。
- Accept-Encoding: gzip, deflate, br：指定客戶端可以支持的壓縮算法。
- Connection: keep-alive：表示客戶端與服務(wù)器之間的連接保持活動狀態(tài)。
- Cookie: JSESSIONID=21F30205BA50CC422465B6AEBCD5D08E：包含會話標(biāo)識符的Cookie。
- Content-Length: 0：說明請求體內(nèi)容長度為0字節(jié)。
其他信息：
- [Full request URI: http://192.168.50.223:7778/hello]：完整的請求URI為http://192.168.50.223:7778/hello。
- [HTTP request 5/5]：表示這是第五次HTTP請求中的第五個請求。
- [Prev request in frame: 6544]：上一個請求在幀 6544 中。
- [Response in frame: 8109]：響應(yīng)在幀 8109 中。

綜上所述，這是一個使用PATCH方法發(fā)送到/hello的URL的HTTP請求。請求由Postman工具發(fā)起，包含了各種元數(shù)據(jù)信息。請求體為空，并且這是第五個HTTP請求中的最后一個請求，響應(yīng)位于幀 8109。

響應(yīng)報文

Hypertext Transfer Protocol, has 2 chunks (including last chunk)
    HTTP/1.1 200 \r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 \r\n]
            [HTTP/1.1 200 \r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
    Vary: Origin\r\n
    Vary: Access-Control-Request-Method\r\n
    Vary: Access-Control-Request-Headers\r\n
    Content-Type: application/json\r\n
    Transfer-Encoding: chunked\r\n
    Date: Wed, 10 Apr 2024 01:17:45 GMT\r\n
    Keep-Alive: timeout=60\r\n
    Connection: keep-alive\r\n
    \r\n
    [HTTP response 5/5]
    [Time since request: 0.003991000 seconds]
    [Prev request in frame: 6544]
    [Prev response in frame: 6546]
    [Request in frame: 8107]
    [Request URI: http://192.168.50.223:7778/hello]
    HTTP chunked response
        Data chunk (86 octets)
            Chunk size: 86 octets
            Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313836353238362c2264617461223a6e756c6c7d
            Chunk boundary: 0d0a
        End of chunked encoding
            Chunk size: 0 octets
        \r\n
    File Data: 86 bytes

這段文本描述了一個HTTP響應(yīng)的數(shù)據(jù)包內(nèi)容，其中包含了使用分塊編碼傳輸?shù)臄?shù)據(jù)。以下是對該HTTP響應(yīng)的分析：

響應(yīng)行：HTTP/1.1 200 表示這是一個狀態(tài)碼為200（OK）的HTTP/1.1版本的響應(yīng)。
響應(yīng)頭部：
- Vary: Origin、Vary: Access-Control-Request-Method、Vary: Access-Control-Request-Headers：指示服務(wù)器對緩存的響應(yīng)做了變化，可能會根據(jù)請求中的Origin、Access-Control-Request-Method或Access-Control-Request-Headers值進(jìn)行響應(yīng)的調(diào)整。
- Content-Type: application/json：指定響應(yīng)內(nèi)容的類型為JSON。
- Transfer-Encoding: chunked：表明響應(yīng)體使用了分塊編碼方式傳輸。
- Date: Wed, 10 Apr 2024 01:17:45 GMT：表示響應(yīng)產(chǎn)生的日期和時間。
- Keep-Alive: timeout=60、Connection: keep-alive：說明保持連接活動狀態(tài)，超時時間為60秒。
其他信息：
- [HTTP response 5/5]：表示這是第五個HTTP響應(yīng)中的最后一個響應(yīng)。
- [Time since request: 0.003991000 seconds]：距離發(fā)出請求的時間為0.003991秒。
- [Prev request in frame: 6544]：前一個請求在幀 6544 中。
- [Prev response in frame: 6546]：前一個響應(yīng)在幀 6546 中。
- [Request in frame: 8107]：請求在幀 8107 中。
請求URI：http://192.168.50.223:7778/hello 表示請求的完整URI。
分塊編碼響應(yīng)：
- 第一個數(shù)據(jù)塊：
  Chunk size: 86 octets
  Chunk data: 7b2273756363657373223a747275652c226d7367223a22e6938de4bd9ce68890e58a9f222c22636f6465223a3230302c2274696d657374616d70223a313731323731313836353238362c2264617461223a6e756c6c7d
  Chunk boundary: 0d0a (CRLF)
- 結(jié)束分塊編碼：
  Chunk size: 0 octets
文件數(shù)據(jù)：86字節(jié)

綜上所述，這是一個狀態(tài)碼為200（OK）的HTTP響應(yīng)，響應(yīng)內(nèi)容為application/json類型，并且使用了分塊編碼方式傳輸。響應(yīng)中包含了一些頭部信息，以及一個包含86個字節(jié)數(shù)據(jù)塊的分塊編碼響應(yīng)。

04 HTTPS

1）簡介

HTTPS 協(xié)議是 HyperText Transfer Protocol Secure（超文本傳輸安全協(xié)議）的縮寫，是一種通過計算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議。
HTTPS = HTTP + SSL/TLS，HTTPS 經(jīng)由 HTTP 進(jìn)行通信，但利用 SSL/TLS 來加密數(shù)據(jù)包，HTTPS 開發(fā)的主要目的，是提供對網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換資料的隱私與完整性。

HTTPS 的信任基于證書頒發(fā)機(jī)構(gòu)（CA），與一個網(wǎng)站之間的 HTTPS 連線僅在這些情況下可被信任：

瀏覽器正確地實現(xiàn)了 HTTPS 且操作系統(tǒng)中安裝了正確且受信任的證書頒發(fā)機(jī)構(gòu)；
證書頒發(fā)機(jī)構(gòu)僅信任合法的網(wǎng)站；
被訪問的網(wǎng)站提供了一個有效的證書，也就是說它是一個由操作系統(tǒng)信任的證書頒發(fā)機(jī)構(gòu)簽發(fā)的（大部分瀏覽器會對無效的證書發(fā)出警告）；
該證書正確地驗證了被訪問的網(wǎng)站（例如，訪問 https://www.runoob.com 時收到了簽發(fā)給 www.runoob.com 而不是其它域名的證書）；
此協(xié)議的加密層（SSL/TLS）能夠有效地提供認(rèn)證和高強(qiáng)度的加密。

2）與Http的區(qū)別

HTTPS 默認(rèn)工作在 TCP 協(xié)議443端口，它的工作流程一般如以下方式：

1、TCP 三次同步握手
2、客戶端驗證服務(wù)器數(shù)字證書
3、DH 算法協(xié)商對稱加密算法的密鑰、hash 算法的密鑰
4、SSL 安全加密隧道協(xié)商完成
5、網(wǎng)頁以加密的方式傳輸，用協(xié)商的對稱加密算法和密鑰加密，保證數(shù)據(jù)機(jī)密性；用協(xié)商的hash算法進(jìn)行數(shù)據(jù)完整性保護(hù)，保證數(shù)據(jù)不被篡改。

區(qū)別如下：

HTTP 明文傳輸，數(shù)據(jù)都是未加密的，安全性較差，HTTPS（SSL+HTTP）數(shù)據(jù)傳輸過程是加密的，安全性較好。
使用 HTTPS 協(xié)議需要到 CA（Certificate Authority，數(shù)字證書認(rèn)證機(jī)構(gòu)）申請證書，一般免費證書較少，因而需要一定費用。證書頒發(fā)機(jī)構(gòu)如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
HTTP 頁面響應(yīng)速度比 HTTPS 快，主要是因為 HTTP 使用 TCP 三次握手建立連接，客戶端和服務(wù)器需要交換 3 個包，而HTTPS除了 TCP 的三個包，還要加上 ssl 握手需要的 9 個包，所以一共是 12 個包。
http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443。
HTTPS 其實就是建構(gòu)在 SSL/TLS 之上的 HTTP 協(xié)議，所以，要比較 HTTPS 比 HTTP 要更耗費服務(wù)器資源。

3）https工作原理

網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https,網(wǎng)絡(luò)協(xié)議棧,netty4,網(wǎng)絡(luò),http,https,java

1、客戶端發(fā)起 HTTPS 請求
這個沒什么好說的，就是用戶在瀏覽器里輸入一個 https 網(wǎng)址，然后連接到 server 的 443 端口。
2、服務(wù)端的配置
采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl 就是個不錯的選擇，有 1 年的免費服務(wù))。
這套證書其實就是一對公鑰和私鑰，如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
3、傳送證書
這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)，過期時間等等。
4、客戶端解析證書
這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。
如果證書沒有問題，那么就生成一個隨機(jī)值，然后用證書對該隨機(jī)值進(jìn)行加密，就好像上面說的，把隨機(jī)值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。
5、傳送加密信息
這部分傳送的是用證書加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個隨機(jī)值，以后客戶端和服務(wù)端的通信就可以通過這個隨機(jī)值來進(jìn)行加密解密了。
6、服務(wù)端解密信息
服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機(jī)值(對稱秘鑰)，然后把內(nèi)容通過該值進(jìn)行對稱加密，所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。
7、傳輸加密后的信息
這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原。
8、客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息，于是獲取了解密后的內(nèi)容，整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。

05 HTTP2

TLS（傳輸層安全性協(xié)議）和 SSL（安全套接字層）都是用于保護(hù)網(wǎng)絡(luò)通信安全性的加密協(xié)議。它們在確保數(shù)據(jù)傳輸過程中的機(jī)密性、完整性和認(rèn)證方面起著重要作用。

SSL：最初由 Netscape 開發(fā)，旨在為互聯(lián)網(wǎng)通信提供安全性。SSL 使用加密技術(shù)對傳輸?shù)臄?shù)據(jù)進(jìn)行加密，防止第三方截取和竊取信息，同時具備解密的功能。
TLS：傳輸層安全性協(xié)議（TLS）是 SSL 的繼任者，目前廣泛使用。TLS 提供了更強(qiáng)大的加密算法和安全性選項，并通過不斷更新來保持網(wǎng)絡(luò)通信的安全性。

1）TLS傳輸層加密

雖然理論上HTTP/2也是支持非加密連接傳輸?shù)模ㄟ@種非加密連接的HTTP/2簡稱為h2c），但實際上目前主流瀏覽器廠商都只實現(xiàn)了加密連接的模式，所以https變成了HTTP/2的事實上的標(biāo)準(zhǔn)。

2）HTTP/2 特點

下面是 HTTP/2 的一些特點和改進(jìn)之處：

多路復(fù)用：HTTP/2 允許同時發(fā)送多個請求和響應(yīng)，而不是像 HTTP/1.1 一樣只能一個一個地處理。這樣可以減少延遲，提高效率，提高網(wǎng)絡(luò)吞吐量。
二進(jìn)制傳輸：HTTP/2 使用二進(jìn)制協(xié)議，與 HTTP/1.1 使用的文本協(xié)議不同。二進(jìn)制協(xié)議可以更快地解析，更有效地傳輸數(shù)據(jù)，減少了傳輸過程中的開銷和延遲。
頭部壓縮：HTTP/2 使用 HPACK 算法對 HTTP 頭部進(jìn)行壓縮，減少了頭部傳輸?shù)臄?shù)據(jù)量，從而減少了網(wǎng)絡(luò)延遲。
服務(wù)器推送：HTTP/2 支持服務(wù)器推送，允許服務(wù)器在客戶端請求之前推送資源，以提高性能。
改進(jìn)的安全性：HTTP/2 默認(rèn)使用 TLS（Transport Layer Security）加密傳輸數(shù)據(jù)，提高了安全性。
兼容 HTTP/1.1：HTTP/2 可以與 HTTP/1.1 共存，服務(wù)器可以同時支持 HTTP/1.1 和 HTTP/2。如果客戶端不支持 HTTP/2，服務(wù)器可以回退到 HTTP/1.1。

06 HTTP3

在quic的協(xié)議基礎(chǔ)上進(jìn)行建設(shè)的。文章來源地址http://www.zghlxwxcb.cn/news/detail-851938.html

到了這里，關(guān)于網(wǎng)絡(luò)篇05 | 應(yīng)用層 http/https的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！

本文來自互聯(lián)網(wǎng)用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載，請注明出處：如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實不符，請點擊違法舉報進(jìn)行投訴反饋，一經(jīng)查實，立即刪除！

分享到：

領(lǐng)支付寶紅包贊助服務(wù)器費用

【網(wǎng)絡(luò)】應(yīng)用層——HTTPS協(xié)議
??作者：一只大喵咪1201 ??專欄：《網(wǎng)絡(luò)》 ??格言：你只管努力，剩下的交給時間！前面本喵講解并演示了HTTP協(xié)議，在比較 POST 和 GET 方法的時候，本喵說這兩個方法都不安全，雖然 POST 的提交的表單內(nèi)容在請求正文中，無法在地址的 url 中看到，但是它仍然是不安全的。
2024年02月14日
瀏覽(25)
【應(yīng)用層】網(wǎng)絡(luò)基礎(chǔ) -- HTTPS協(xié)議
HTTPS 是什么？ HTTPS 也是?個應(yīng)用層協(xié)議。是在 HTTP 協(xié)議的基礎(chǔ)上引入了?個加密層。 HTTP 協(xié)議內(nèi)容都是按照文本的方式明文傳輸?shù)摹＿@就導(dǎo)致在傳輸過程中出現(xiàn)?些被篡改的情況加密就是把明文 (要傳輸?shù)男畔?進(jìn)行?系列變換，生成密文。解密就是把密文再進(jìn)行?系列
2024年02月11日
瀏覽(18)
【計算機(jī)網(wǎng)絡(luò)】應(yīng)用層協(xié)議 -- 安全的HTTPS協(xié)議
HTTPS全稱為 Hyper Text Tranfer Protocol over SecureSocket Layer 。 HTTPS協(xié)議也是一個應(yīng)用層協(xié)議，是在HTTP協(xié)議的基礎(chǔ)上引入了一個加密層。在傳統(tǒng)的HTTP協(xié)議中，數(shù)據(jù)以明文的形式在網(wǎng)絡(luò)上傳輸，這意味著敏感信息（如密碼、個人信息等）可能會在傳輸過程中被攻擊者截獲和竊取。為了解
2024年02月15日
瀏覽(27)
【網(wǎng)絡(luò)】應(yīng)用層——HTTP協(xié)議
??作者：一只大喵咪1201 ??專欄：《網(wǎng)絡(luò)》 ??格言：你只管努力，剩下的交給時間！上篇文章中，本喵帶著大家對HTTP有了一個初步的認(rèn)識，今天就來詳細(xì)講解一下這個應(yīng)用層協(xié)議。如上圖所示的 url (網(wǎng)址)，里面包含有 / 以及 ? 等字符。像這樣的字符，已經(jīng)被url當(dāng)做特殊
2024年02月15日
瀏覽(25)
網(wǎng)絡(luò)協(xié)議（七）應(yīng)用層-HTTP
上篇文章介紹了傳輸層的TCP、UDP協(xié)議，在TCP/IP協(xié)議中，下三層（網(wǎng)絡(luò)接口層，網(wǎng)絡(luò)層，傳輸層）都是計算機(jī)系統(tǒng)聯(lián)合其他硬件設(shè)備自己在干的事，身為程序員的我們平時對其感知不大。而應(yīng)用層卻是與程序開發(fā)息息相關(guān)的一層，如HTTP，HTTPS，DNS，F(xiàn)TP，SMTP等等，針對不同應(yīng)用場
2024年02月03日
瀏覽(31)
9.3.5網(wǎng)絡(luò)原理(應(yīng)用層HTTP/HTTPS)
一.HTTP: 1. HTTP是超文本傳輸協(xié)議,除了傳輸字符串,還可以傳輸圖片,字體,視頻,音頻. 2.? 3.HTTP協(xié)議報文格式:a.首行,b.請求頭(header),c.空行(相當(dāng)于一個分隔符,分隔了header和body),d.正文(body). 4. 5.URL:唯一資源描述符(長度不限制).? a. b.注意:查詢字符串(query string)是鍵值對的格式.鍵值對
2024年02月07日
瀏覽(23)
「網(wǎng)絡(luò)編程」應(yīng)用層協(xié)議_ HTTPS協(xié)議學(xué)習(xí)及原理理解
「前言」文章內(nèi)容大致是應(yīng)用層協(xié)議的HTTPS協(xié)議講解，續(xù)上篇HTTP協(xié)議。「歸屬專欄」網(wǎng)絡(luò)編程「主頁鏈接」個人主頁「筆者」楓葉先生(fy) HTTPS（HyperText Transfer Protocol Secure）是一種通過加密和身份驗證保護(hù)網(wǎng)絡(luò)通信安全的協(xié)議。它是基于HTTP協(xié)議的安全版本，也是工作在應(yīng)用
2024年02月16日
瀏覽(24)
【計算機(jī)網(wǎng)絡(luò)】應(yīng)用層協(xié)議 -- HTTP協(xié)議
協(xié)議。網(wǎng)絡(luò)協(xié)議的簡稱，網(wǎng)絡(luò)協(xié)議是通信計算機(jī)雙方必須共同遵守的一組約定，比如怎么建立連接，怎么互相識別等。為了使數(shù)據(jù)在網(wǎng)絡(luò)上能夠從源頭到達(dá)目的，網(wǎng)絡(luò)通信的參與方必須遵守相同的規(guī)則，我們稱這套相同的規(guī)則為協(xié)議（protocol），而協(xié)議最終都需要通過計算機(jī)
2024年02月15日
瀏覽(27)
【應(yīng)用層】網(wǎng)絡(luò)基礎(chǔ) -- HTTP協(xié)議
協(xié)議是一種 “約定”. socket api的接口，在讀寫數(shù)據(jù)時，都是按 “字符串” 的方式來發(fā)送接收的(tcp是以字節(jié)流的方式發(fā)送的，這里便與表述使用\\\"字符串\\\") 如果我們要傳輸一些\\\"結(jié)構(gòu)化的數(shù)據(jù)\\\" 怎么辦呢? 那么我們(TCP)在收到一個報文的時候，如何保證你收到了一個完整的報文？
2024年02月11日
瀏覽(58)
Linux網(wǎng)絡(luò)：應(yīng)用層之HTTP協(xié)議
我們程序員寫的一個個解決實際問題，滿足日常需求的網(wǎng)絡(luò)程序，都是在應(yīng)用層。協(xié)議是一種約定。網(wǎng)絡(luò)協(xié)議是計算機(jī)網(wǎng)絡(luò)中通信雙方都必須遵守的一組約定。在網(wǎng)絡(luò)通信中，都是以 “字符串” 的方式來發(fā)送和接收數(shù)據(jù)的。如果要發(fā)送和接收一些結(jié)構(gòu)化的數(shù)據(jù)，就需要序
2023年04月26日
瀏覽(19)

<noframes id="esqm4"></noframes>

<ul id="esqm4"></ul>