當前位置:首頁 » 網路連接 » HTTP計算機網路

HTTP計算機網路

發布時間: 2023-01-14 15:39:51

A. http網路協議是什麼意思

一、HTTP網路協議的概念:

  1. HTTP是Hyper Text Transfer Protocol(超文本傳輸協議)的縮寫。

  2. 發展是萬維網協會(World Wide Web Consortium)和Internet工作小組IETF(Internet Engineering Task Force)合作的結果,最終發布了一系列的RFC,RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。

  3. RFC 2616定義了今天普遍使用的一個版本——HTTP 1.1。

  4. HTTP協議(HyperText Transfer Protocol,超文本傳輸協議)是用於從WWW伺服器傳輸超文本到本地瀏覽器的傳送協議。可以使瀏覽器更加高效,使網路傳輸減少。不僅保證計算機正確快速地傳輸超文本文檔,還確定傳輸文檔中的哪一部分,以及哪部分內容首先顯示(如文本先於圖形)等。

  5. HTTP是一個應用層協議,由請求和響應構成,是一個標準的客戶端伺服器模型。HTTP是一個無狀態的協議。

三、HTTP的幾個重要概念:

  1. 連接:Connection

    一個傳輸層的實際環流,它是建立在兩個相互通訊的應用程序之間。 在http1.1,request和reponse頭中都有可能出現一個connection的頭,此header的含義是當client和server通信時對於長鏈接如何進行處理。 在http1.1中,client和server都是默認對方支持長鏈接的, 如果client使用http1.1協議,但又不希望使用長鏈接,則需要在header中指明connection的值為close;如果server方也不想支持長鏈接,則在response中也需要明確說明connection的值為close。不論request還是response的header中包含了值為close的connection,都表明當前正在使用的tcp鏈接在當天請求處理完畢後會被斷掉。以後client再進行新的請求時就必須創建新的tcp鏈接了。

  2. 消息:Message

    HTTP通訊的基本單位,包括一個結構化的八元組序列並通過連接傳輸。

  3. 請求:Request

    一個從客戶端到伺服器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號。

  4. 響應:Response

    一個從伺服器返回的信息包括HTTP協議的版本號、請求的狀態(例如「成功」或「沒找到」)和文檔的MIME類型。

  5. 資源:Resource

    由URI標識的網路數據對象或服務。

  6. 實體:Entity

    數據資源或來自服務資源的回映的一種特殊表示方法,它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的本身內容。

  7. 客戶機:Client

    一個為發送請求目的而建立連接的應用程序。

  8. 用戶代理:UserAgent

    初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。

  9. 伺服器:Server

    一個接受連接並對請求返回信息的應用程序。

  10. 源伺服器:Originserver

    是一個給定資源可以在其上駐留或被創建的伺服器。

  11. 代理:Proxy

    一個中間程序,它可以充當一個伺服器,也可以充當一個客戶機,為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的伺服器中。一個代理在發送請求信息之前,必須解釋並且如果可能重寫它。 代理經常作為通過防火牆的客戶機端的門戶,代理還可以作為一個幫助應用來通過協議處理沒有被用戶代理完成的請求。

  12. 網關:Gateway

    一個作為其它伺服器中間媒介的伺服器。與代理不同的是,網關接受請求就好象對被請求的資源來說它就是源伺服器;發出請求的客戶機並沒有意識到它在同網關打交道。 網關經常作為通過防火牆的伺服器端的門戶,網關還可以作為一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。

  13. 通道:Tunnel

    是作為兩個連接中繼的中介程序。一旦激活,通道便被認為不屬於HTTP通訊,盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時,通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。

  14. 緩存:Cache

    反應信息的局域存儲。

B. 計算機名詞HTTP的解釋!

HTTP:超文本傳輸協議
HTTP:Hypertext Transfer Protocol

超文本傳輸協議(HTTP)是應用層協議,由於其簡捷、快速的方式,適用於分布式和合作式超媒體信息系統。自 1990 年起,HTTP 就已經被應用於 WWW 全球信息服務系統。
HTTP 允許使用自由答復的方法表明請求目的,它建立在統一資源識別器(URI)提供的參考原則下,作為一個地址(URL)或名字(URN),用以標志採用哪種方法,它用類似於網路郵件和多用途網際郵件擴充協議(MIME)的格式傳遞消息。

HTTP 也可用作普通協議,實現用戶代理與連接其它 Internet 服務(如SMTP、NNTP、FTP、 GOPHER 及 WAIS)的代理伺服器或網關之間的通信,允許基本的超媒體訪問各種應用提供的資源,同時簡化了用戶代理系統的實施。

HTTP 是一種請求/響應式的協議。一個客戶機與伺服器建立連接後,發送一個請求給伺服器,請求的格式是:統一資源標識符(URI)、協議版本號,後面是類似 MIME 的信息,包括請求修飾符、客戶機信息和可能的內容。伺服器接到請求後,給予相應的響應信息,其格式是:一個狀態行包括信息的協議版本號、一個成功或錯誤的代碼,後面也是類似 MIME 的信息,包括伺服器信息、實體信息和可能的內容。

HTTP 的第一版本 HTTP/0.9 是一種簡單的用於網路間原始數據傳輸的協議。而由 RFC 1945 定義的 HTTP/1.0 ,在原 HTTP/0.9 的基礎上,有了進一步的改進,允許消息以類 MIME 信息格式存在,包括請求/響應範式中的已傳輸數據和修飾符等方面的信息。但是,HTTP/1.0 沒有充分考慮到分層代理伺服器、高速緩沖存儲器、持久連接需求或虛擬主機等方面的效能。相比之下,HTTP/1.1 要求更加嚴格以確保服務的可靠性。關於安全增強版的 HTTP (即S-HTTP),將在相關文件中再作介紹。

C. 計算機網路:這是一份全面& 詳細 HTTP知識講解

講解 HTTP 協議前,先了解一些基礎的計算機網路相關知識

下面,將簡單介紹一下 HTTP

則 請求行是: GET /chn/yxsz/index.htm HTTP/1.1

2. 常見請求Header

至此,關於請求報文的請求行、請求頭、請求體 均講解完畢。

下面,將詳細介紹每個組成部分

2. 常見響應Header

下面,簡單總結兩種報文結構

下面將講解一些關於 HTTP 的額外知識:

Http1.1 比 Http1.0 多了以下優點:

不定期分享關於 安卓開發 的干貨,追求 短、平、快 ,但 卻不缺深度

D. http狀態返回代碼400怎麼解決

http狀態返回代碼400,這是因為計算機網路狀態異常導致的,具體的修復方法如下:

1、首先,點擊電腦右下角的網路圖標,然後將電腦的寬頻斷開:

E. 計算機網路——應用層-Web&HTTP

計算機網路系列博文——目錄

20世紀90年代初
網際網路應用

Web應用的組成

由對象組成。對象是一個文件,如HTML文件,JPEG圖像,Java程序,視頻片段等。
對象可通過一個URL地址定址。
Web頁面常由一個HTML基本文件和多個引用對象構成。

URL(Uniform Resoure Locator):統一資源定位器 RFC1738

用以定址Web對象
由一個存放對象的伺服器主機名和對象路徑名構成。

HTTP 由客戶端程序和服務端程序實現,二者通過交換HTTP報文會話。
HTTP規范定義了HTTP客戶端和服務端之間的通信協議。

Web瀏覽器實現HTTP客戶端,請求、接收、展示Web對象
Web伺服器實現HTTP服務端,響應客戶的請求,發送對象

HTTP使用TCP作為支撐運輸層協議。

埠:80

無狀態協議 伺服器不保存關於客戶的任何信息
伺服器向客戶發送被請求的文件,而不存儲任何關於客戶的狀態信息。

往返時間(Round-Trip Time,RTT)
一個短分組從客戶到伺服器然後再返回客戶所花費的時間。

某客戶和伺服器的一次會話中,每個請求/響應對通過一個單獨的TCP連接傳輸

HTTP 1.0版本使用非持續性連接

對多個待獲得的web對象,客戶端一次只請求一個對象,待前一個對象接收完畢後再發送對下一個對象的請求。

時間分析

瀏覽器通常支持並行的TCP連接。並行TCP連接數通常為5~10個。
對多個待獲得的web對象,客戶端一次可同時建立多個TCP連接,以同時請求多個web對象。
時間分析

某客戶和伺服器的一次會話中,所有請求/響應對經同一TCP連接傳輸

HTTP 1.1版本在默認方式下採用持續連接,但也可由客戶端/伺服器配置為非持續連接。

客戶端只有收到前一個響應後才發送新的請求
可理解為同個TCP內的串列

時間分析

客戶端只要遇到一個引用對象就盡快發出請求
可理解為同個TCP內的並行
HTTP 1.1的默認選項

時間分析

TCP 三次握手
1.客戶向伺服器發送一個小TCP報文段;
2.伺服器用一個小TCP報文段做出確認和響應;
3.客戶向伺服器返回確認和一個HTTP請求報文;
4.伺服器返回相應HTML文件;

HTTP規范
RFC 1945 , RFC 2616

用ASCII文本書寫
HTTP協議有兩類消息,請求消息(request)和響應消息(response)

請求行 HTTP請求報文的第一行

方法

首部行 請求行後繼的其它行,包含一些會話信息

空行 回車換行,分隔首部行和實體體

實體體(entity body)
GET方法下實體體為空
POST方法下實體體包含表單信息

狀態行

常見狀態碼

首部行

空行

實體體
包含了所請求的對象

HTTP是無狀態協議,但cookie技術允許伺服器識別用戶
cookie在無狀態的HTTP之上建立一個用戶會話層

參見 [RFC 6265]

cookie組件

cookie技術的爭議在於它可能泄露用戶的隱私

代表原Web伺服器來響應HTTP請求的網路實體

Web緩沖器通常由ISP購買並安裝

允許緩存器證實其緩存的副本是新的。
如果緩存器有web對象最新的版本,則初始伺服器不需要向緩存器發送該web對象

在HTTP請求消息中聲明所持有版本的日期
If-modified-since: <date>

如果緩存的版本是最新的,則響應消息中不包含對象
HTTP/1.0 304 Not Modified

內容分發網路(Content Distribution Network,CDN)
基於緩存器技術,CDN公司在網際網路上安裝許多地理上分散的緩存器,使得大流量本地化。
有共享CDN(Akamai,Limelight),專用CDN(谷歌,微軟)

F. 計算機網路中,HTTP的中文意思是

HTTP叫做超文本傳輸協議。而HTTPS則是安全超文本傳輸協議。

G. 計算機網路-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支持更多的 編碼類型 且不對 數據類型 限制