新聞中心
HTTP是超文本傳輸協(xié)議,也就是HyperText Transfer Protocol。
根據(jù)名字,可以將超文本傳輸協(xié)議分解為:超文本、傳輸、協(xié)議。
協(xié)議:HTTP 是?個?在計算機世界?的協(xié)議。它使?計算機能夠理解的語?確?了?種計算機之間交流通信的規(guī)范,以及相關(guān)的各種控制和錯誤處理?式。
傳輸:就是把?堆東?從 A 點搬到 B 點,或者從 B 點 搬到 A 點。而HTTP協(xié)議是雙向協(xié)議,
我們在上?沖浪時,瀏覽器是請求? A ,百度?站就是應(yīng)答? B。雙?約定? HTTP 協(xié)議來通信,于是瀏覽器把請
求數(shù)據(jù)發(fā)送給?站,?站再把?些數(shù)據(jù)返回給瀏覽器,最后由瀏覽器渲染在屏幕,就可以看到圖?、視頻了。
數(shù)據(jù)雖然是在 A 和 B 之間傳輸,但允許中間有中轉(zhuǎn)或接?。?在 HTTP ?,需要中間?遵從 HTTP 協(xié)議,只要不打擾基本的數(shù)據(jù)傳輸,就可以添加任意額外的東?。HTTP 是?個在計算機世界?專??來在兩點之間傳輸數(shù)據(jù)的約定和規(guī)范。
超文本:HTTP 傳輸?shù)膬?nèi)容是「超?本」。
我們先來理解「?本」,在互聯(lián)?早期的時候只是簡單的字符?字,但現(xiàn)在「?本」的涵義已經(jīng)可以擴展為圖?、 視頻、壓縮包等,在 HTTP 眼?這些都算作「?本」。
再來理解「超?本」,它就是超越了普通?本的?本,它是?字、圖?、視頻等的混合體,最關(guān)鍵有超鏈接,能從 ?個超?本跳轉(zhuǎn)到另外?個超?本。
HTML 就是最常?的超?本了,它本身只是純?字?件,但內(nèi)部?很多標簽定義了圖?、視頻等的鏈接,再經(jīng)過瀏 覽器的解釋,呈現(xiàn)給我們的就是?個?字、有畫?的??了。
OK,經(jīng)過了對 HTTP ?這三個名詞的詳細解釋,就可以給出?「超?本傳輸協(xié)議」這七個字更準確更有技術(shù)含量的答案:
HTTP 是?個在計算機世界?專?在「兩點」之間「傳輸」?字、圖?、?頻、視頻等「超?本」數(shù)據(jù)的「約定和規(guī)范」。
客戶端發(fā)送請求時,?來指定服務(wù)器的域名。
服務(wù)器在返回數(shù)據(jù)時,會有 Content-Length 字段,表明本次回應(yīng)的數(shù)據(jù)長度。
如上?則是告訴瀏覽器,本次服務(wù)器回應(yīng)的數(shù)據(jù)?度是 1000 個字節(jié),后?的字節(jié)就屬于下?個回應(yīng)了。
Connection 字段Connection 字段最常?于客戶端要求服務(wù)器使? TCP 持久連接,以便其他請求復(fù)?。
HTTP/1.1 版本的默認連接都是持久連接,但為了兼容?版本的 HTTP,需要指定 Connection ?部字段的值為 Keep-Alive 。
‘Connection: keep-alive’
?個可以復(fù)?的 TCP 連接就建?了,直到客戶端或服務(wù)器主動關(guān)閉連接。但是,這不是標準字段。
Content-Type 字段Content-Type 字段?于服務(wù)器回應(yīng)時,告訴客戶端,本次數(shù)據(jù)是什么格式。
Content-Type: text/html; charset=utf-8
上?的類型表明,發(fā)送的是??,?且編碼是UTF-8。
客戶端請求的時候,可以使? Accept 字段聲明??可以接受哪些數(shù)據(jù)格式。
Accept:/
上?代碼中,客戶端聲明??可以接受任何格式的數(shù)據(jù)。
Content-Encoding 字段Content-Encoding 字段說明數(shù)據(jù)的壓縮?法。表示服務(wù)器返回的數(shù)據(jù)使?了什么壓縮格式
Content-Encoding: gzip
上?表示服務(wù)器返回的數(shù)據(jù)采?了 gzip ?式壓縮,告知客戶端需要?此?式解壓。
客戶端在請求時,? Accept-Encoding 字段說明??可以接受哪些壓縮?法。
Accept-Encoding: gzip, deflate
Get ?法的含義是請求從服務(wù)器獲取資源,這個資源可以是靜態(tài)的?本、??、圖?視頻等。
? POST ?法則是相反操作,它向 URI 指定的資源提交數(shù)據(jù),數(shù)據(jù)就放在報?的 body ?。
HTTP 最凸出的優(yōu)點是「簡單、靈活和易于擴展、應(yīng)??泛和跨平臺」。
簡單HTTP 基本的報?格式就是 header + body ,頭部信息也是 key-value 簡單?本的形式,易于理解,降低了學
習和使?的?檻。
HTTP協(xié)議?的各類請求?法、URI/URL、狀態(tài)碼、頭字段等每個組成要求都沒有被固定死,都允許開發(fā)?員?定
義和擴充。
同時 HTTP 由于是?作在應(yīng)?層( OSI 第七層),則它下層可以隨意變化。
HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層,HTTP/3 甚?把 TCP 層換成了基于 UDP 的 QUIC。
互聯(lián)?發(fā)展?今,HTTP 的應(yīng)?范圍?常的?泛,從臺式機的瀏覽器到?機上的各種 APP,從看新聞、刷貼吧到購物、理財、吃雞,HTTP 的應(yīng)??地開花,同時天然具有跨平臺的優(yōu)越性。
缺點HTTP 協(xié)議?有優(yōu)缺點?體的雙刃劍,分別是「?狀態(tài)、明?傳輸」,同時還有??缺點「不安全」。
- ?狀態(tài)雙刃劍?狀態(tài)的好處,因為服務(wù)器不會去記憶 HTTP 的狀態(tài),所以不需要額外的資源來記錄狀態(tài)信息,這能減輕服務(wù)器的
負擔,能夠把更多的 CPU 和內(nèi)存?來對外提供服務(wù)。
?狀態(tài)的壞處,既然服務(wù)器沒有記憶能?,它在完成有關(guān)聯(lián)性的操作時會?常麻煩。
例如登錄->添加購物?->下單->結(jié)算->?付,這系列操作都要知道?戶的身份才?。但服務(wù)器不知道這些請求是有關(guān)聯(lián)的,每次都要問?遍身份信息。
這樣每操作?次,都要驗證信息,這樣的購物體驗還能愉快嗎?別問,問就是酸爽!
對于?狀態(tài)的問題,解法?案有很多種,其中?較簡單的?式? Cookie 技術(shù)。
Cookie 通過在請求和響應(yīng)報?中寫? Cookie 信息來控制客戶端的狀態(tài)。
相當于,在客戶端第?次請求后,服務(wù)器會下發(fā)?個裝有客戶信息的「?貼紙」,后續(xù)客戶端請求服務(wù)器的時候, 帶上「?貼紙」,服務(wù)器就能認得了了, - 明?傳輸雙刃劍
明?意味著在傳輸過程中的信息,是可?便閱讀的,通過瀏覽器的 F12 控制臺或 Wireshark 抓包都可以直接?眼查看,為我們調(diào)試?作帶了極?的便利性。
但是這正是這樣,HTTP 的所有信息都暴露在了光天化?下,相當于信息裸奔。在傳輸?shù)穆?的過程中,信息的內(nèi)容都毫?隱私可?,很容易就能被竊取,如果??有你的賬號密碼信息,那你號沒了。 - 不安全
HTTP ?較嚴?的缺點就是不安全:
通信使?明?(不加密),內(nèi)容可能會被竊聽。?如,賬號信息容易泄漏,那你號沒了。
不驗證通信?的身份,因此有可能遭遇偽裝。?如,訪問假的淘寶、拼多多,那你錢沒了。
?法證明報?的完整性,所以有可能已遭篡改。?如,??上植?垃圾?告,視覺污染,眼沒了。
- HTTP 是超?本傳輸協(xié)議,信息是明?傳輸,存在安全?險的問題。HTTPS 則解決 HTTP 不安全的缺陷,在
TCP 和 HTTP ?絡(luò)層之間加?了 SSL/TLS 安全協(xié)議,使得報?能夠加密傳輸。 - HTTP 連接建?相對簡單, TCP 三次握?之后便可進? HTTP 的報?傳輸。? HTTPS 在 TCP 三次握?之后,還需進? SSL/TLS 的握?過程,才可進?加密報?傳輸。
- HTTP 的端?號是 80,HTTPS 的端?號是 443。
- HTTPS 協(xié)議需要向 CA(證書權(quán)威機構(gòu))申請數(shù)字證書,來保證服務(wù)器的身份是可信的。
HTTP 由于是明?傳輸,所以安全上存在以下三個?險:
竊聽?險,?如通信鏈路上可以獲取通信內(nèi)容,?戶號容易沒。
篡改?險,?如強制植?垃圾?告,視覺污染,?戶眼容易瞎。
冒充?險,?如冒充淘寶?站,?戶錢容易沒。
本文參考暗暗黑風格-圖解網(wǎng)絡(luò)-小林coding-v3.0所作。
你是否還在尋找穩(wěn)定的海外服務(wù)器提供商?創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源,準確流量調(diào)度確保服務(wù)器高可用性,企業(yè)級服務(wù)器適合批量采購,新人活動首月15元起,快前往官網(wǎng)查看詳情吧
文章題目:簡述HTTP協(xié)議(圖文講解,一看就會)-創(chuàng)新互聯(lián)
URL標題:http://www.dlmjj.cn/article/isesc.html