個人HTTP學習之路（二）簡單的講述HTTP協議

時間 2020-01-17

標籤個人 http 學習之路簡單講述協議欄目 HTTP/TCP 简体版

原文原文鏈接

簡單的HTTP協議

1、HTTP的特徵

一、用於客戶端和服務端的通訊html

HTTP協議可以分清哪端是客戶端，哪一個是服務端。安全

二、經過請求和響應類達成通訊服務器

確定是先從客戶端發出請求，服務端接受到請求後，返回響應。cookie

請求報文

GET src/index.html HTTP/1.1
Host: hark.jp
Connection: keep-alive
Content-Type: application/x-wwww-form-urlencoded
Content-Length: 16

name=meils&id=123456

請求由請求方法、資源路徑URI、HTTP版本、可選的請求首部、內容實體。網絡

響應報文

HTTP/1.1 200 OK
Data: Tue 10 Jul 2012 
Content-Length: 162
Content-Type: text/html

<html>
...
</html>

三、HTTP是不保存狀態的協議app

HTTP是不保存狀態的，是無狀態的協議，HTTP不會對請求和響應之間的通訊進行保存的。不作持久化處理。學習

這樣設計是爲了保證可以處理大量的事務，可是隨着WEB不斷的發展，許多的有狀態的需求不斷出現，所以最後引入了Cookie技術。url

四、經過URI定位資源spa

URI爲絕對URI
URI 爲相對的URI(須要Host指明網絡的域名huoIP地址)

若是不訪問任何資源，只是請求服務器,使用*代替

GET * HTTP/1.1

2、HTTP的請求方法

GET 獲取資源

POST 傳輸實體主體

PUT 傳輸文件

容許在請求報文的主體中添加文件內容，而後保存到URI指定的位置。
因爲PUT不帶有驗證機制，存在安全性問題，因此通常不用。設計

HEAD 獲取報文首部

HEAD與GET相似，只是不返回報文主體，用於確認URI的有效性及資源更新的日期等。

DELETE 刪除文件

與PUT相反，跟它存在由同樣的問題，因此通常也不會用

OPTIONS 詢問支持的方法

該方法用來查詢針對的URI指定的資源的支持方法。

3、HTPP通訊的持久連接

一、最初的版本每次通訊都會斷開一次鏈接

每一次通訊只進行一次HTTP請求和響應。

2. 隨着WEB技術的發展，HTTP通訊實現了持久鏈接

隨着WEB技術的發展，一張頁面中會包含許多的資源。若是仍是採用以前的那種方案，無疑會加劇服務器的負擔，下降效率。
爲了解決上述難題，HTTP/1.1提出了持久鏈接（HTTPkeep-alive）。

持久鏈接的特色就是，只要任意一端沒有提出斷開鏈接，則一致保持鏈接狀態。

可是持久鏈接仍然存在必定的問題，那就是每一個請求和響應都是單獨的，且必須是一個請求收到響應後再發送另外一個請求。爲了解決這個問題，就出現了 管線化。

4、管線化

4、使用Cookie實現狀態保存

使用Cookie來進行狀態保存。假設一個須要登錄驗證的頁面，若是不對用戶的登錄狀態進行保存，那麼每個頁面都須要進行一次登錄，這將會是一件惹人討厭的事情。

不能否認，HTTP正是由於這種無狀態的特性，才使得它較爲輕巧簡介，天然也減小了服務器CPU及內存資源的消耗。因此纔會再各類場景中被使用。

爲了再不破壞HTTP這種不保存狀態的特性下，還能使得它可以保持狀態，就出現了偉大的Cookie。

Cookie技術是經過再請求和響應中寫入Cookie信息來控制客戶端的狀態的。

Cookie會根據服務端返回的響應報文中的一個 Set-Cookie的首部信息，來通知客戶端進行保存Cookie。當下次請求的是時候就會將這個 Cookie帶上。
服務端會檢查客戶端發來的Cookie，會檢查到底是哪一個發來的，而後對比服務器上的記錄，最後獲得那個狀態信息。

第一次請求

GET /reader/ HTTP/1.1
Host: hack.jp
// 沒有cookie信息哦

響應

// 返回了Cookie值
HTTP/1.1 200 OK
Date: Tue, 12...
Server: Apache
<set-Cookie: sid=221312321321414; path=/; ...>

第二次請求

GET /reader/ HTTP/1.1
Host: hack.jp
Cookie: sid=221312321321414

關於Cookie具體的首部信息，以後會詳細學習一下啦。
未完待續！！加油~~~

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。