共計 7830 個字符，預(yù)計需要花費 20 分鐘才能閱讀完成。
這篇文章給大家介紹 http 基礎(chǔ)應(yīng)用是怎么樣的，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
http 協(xié)議介紹
http：Hyper Text Transfer Protocol 超文本傳輸協(xié)議，是互聯(lián)網(wǎng)應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，主要用于 Web 服務(wù)。通過計算機(jī)處理文本信息，格式為 HTML(Hyper Text Mark Language)超文本標(biāo)記語言來實現(xiàn)。
http 協(xié)議的版本
http 0.9：僅于用戶傳輸 html 文檔
http 1.0
引入了 MIME(Multipurpose Internet Mail Extesions)機(jī)制：多用途互聯(lián)網(wǎng)郵件擴(kuò)展，引入這個技術(shù)之后，http 可以發(fā)送多媒體 (比如視頻、音頻等) 信息。此機(jī)制讓 http 不在單單只支持 html 格式，還可以支持其他格式來進(jìn)行發(fā)送了。
引入了 keep-alive 機(jī)制，支持持久連接的功能(但這個 keep-alive 原理是在首部添加了某個字段而形成的，并非原生就支持此功能)
引入支持緩存功能
http 1.1
支持更多的請求方法，更加精細(xì)的緩存控制，原生直接支持持久連接功能(presistent)。
http 2.0
提供了 HTTP 語義優(yōu)化的傳輸
spdy : google 引入了的一個技術(shù)，能夠加速 http 數(shù)據(jù)交互，尤其是使用 ssl 加速機(jī)制，但是 spdy 現(xiàn)在用的還不多。
目前常用的版本就是 http 1.0 版本和 http 1.1 版本。
html 文本介紹
html 文本架構(gòu)
html head title TITLE /title /head body h2 H1 /h2 p /p h3 H2 /h3 p a href= admin.html rel= external nofollow target= _blank ToGoogle /a /p /body /htmlhtml 文檔的生成方式
靜態(tài)
事先就編輯并定義完成的
動態(tài)
通過編譯語言編寫的程序后輸出 html 格式的結(jié)果
動態(tài)語言有：php，jsp，asp，.net
備注：這些腳本都必須有相應(yīng)的解釋器，比如說 php 需要有 php 解釋器等等。
靜態(tài)和動態(tài)的方式
靜態(tài)
1、Web 服務(wù)器向內(nèi)核注冊 socket
2、客戶端通過瀏覽器，向 Web 服務(wù)器發(fā)起 request 請求
3、Web 服務(wù)器收到客戶端的 request 信息
4、如果用戶請求的資源在服務(wù)器本地的話，http 服務(wù)會向系統(tǒng)內(nèi)核申請調(diào)用
5、內(nèi)核調(diào)用本地磁盤里的數(shù)據(jù)，并將數(shù)據(jù)發(fā)給 http 服務(wù)
6、http 將用戶請求的資源通過 response 報文，最終響應(yīng)給客戶端
動態(tài)
與靜態(tài)不同的是，如果用戶請求的是動態(tài)內(nèi)容，那么此時 http 服務(wù)會調(diào)用后端的解析器，由動態(tài)語言去處理用戶的請求，如果需要請求數(shù)據(jù)的時候，會向內(nèi)核申請調(diào)用，從而向磁盤中獲取用戶指定的數(shù)據(jù)，通過解釋器運行，運行的結(jié)果通常會生成 html 格式的文件。然后構(gòu)建成響應(yīng)報文，最終發(fā)回給客戶端。
http 協(xié)議
http 協(xié)議的報文
HTTP 報文中存在著很多行的內(nèi)容，一般是由 ASCII 碼串組成，各字段長度是不確定的。HTTP 的報文可分為兩種：請求報文與響應(yīng)報文
request Message(請求報文)
客戶端 – rarr; 服務(wù)器端
由客戶端向服務(wù)器端發(fā)出請求，不同的網(wǎng)站用于請求不同的資源(html 文檔)
response Message(響應(yīng)報文)
服務(wù)器端 – rarr; 客戶端
是服務(wù)器予以響應(yīng)客戶端的請求
請求報文格式介紹
請求行 + 請求首部 + 空白行 + 請求實體
method 這次請求的方式是什么，也就是請求方法
request-URL 請求的是哪個資源，哪個 URL。可以是相對路徑，如 /images/log.jpg，也可以是絕對路徑，如 http://www.magedu.com/images.banner.jpg
version 請求的協(xié)議版本是什么，http 協(xié)議版本，格式 HTTP/ major . minor，例如：HTTP/1.0，HTTP/1.1 HEADERS 首部，首部可能不止一個。各種所可以使用的首部信息
entity-body 請求實體，你到底請求的內(nèi)容是什么
請求行
由 請求方法字段 method + 請求 URL 字段 request-URL +HTTP 協(xié)議版本 version 組成，用來標(biāo)識客戶端請求的資源時使用的請求方法，請求的資源，請求的協(xié)議版本是什么，它們直接使用“空格”進(jìn)行分隔!
請求首部
由關(guān)鍵字 + 關(guān)鍵字的值組成，之間使用“：”進(jìn)行分隔，格式 Name：Value，請求首部的作用是通過客戶端將請求的相關(guān)內(nèi)容告知服務(wù)器端，首部可以不止一個。
空白行
請求首部之后會有一個空白行，通過發(fā)送回車字符和換行符，用于通知服務(wù)器端一下的內(nèi)容將不會再出現(xiàn)請求首部的信息。
請求實體
你需要請求的內(nèi)容到底是什么
例如：
method request-URL version HEADERS # 這里一定要是一個空白行 entity-body響應(yīng)報文格式介紹
起始行 + 響應(yīng)首部 + 空白行 + 響應(yīng)實體
version 響應(yīng)時客戶端請求的是什么版本，服務(wù)器端就需要響應(yīng)什么版本
status 請求的狀態(tài)碼是什么 202，403 等
reason-phrase 響應(yīng)的狀態(tài)碼的信息是什么，原因短語，這個狀態(tài)碼所響應(yīng)的意義，易讀信息
HEADERS 一大堆的響應(yīng)首部
entity-body 響應(yīng)體
起始行
也稱之為狀態(tài)行，用于服務(wù)器端響應(yīng)客戶端請求的狀態(tài)信息，由版本號 version + 狀態(tài)碼 status + 原因短語 reason-phrase 組成，例如“HTTP/1.1 200 OK”
響應(yīng)首部
類似請求報文，起始行后面一般有若干個頭部字段。每個頭部字段都包含一個名字和一個值，兩者之間用冒號分割。格式 Name：Value。
例如：
Content-Type: test/html; charset=utf-8
Content-Length: 78
空白行
*** 一個響應(yīng)首部信息之后就是一個空行，通過發(fā)送回車符和換行符，通知客戶端空行下無首部信息
響應(yīng)實體
響應(yīng)實體中裝載了要返回給客戶端的數(shù)據(jù)。這些數(shù)據(jù)可以是文本，也可以是二進(jìn)制(例如圖片，視頻)
例如：
version status reason-phrase
HEADERS
# 這里一定要是一個空白行
entity-body
HTTP 請求方法
在 HTTP 通信過程中，每個 HTTP 請求報文中都會包含一個 HTTP 請求方法，用于告知客戶端向服務(wù)器端請求執(zhí)行某些具體的操作，下面列舉幾項常用的 HTTP 請求方法。
HTTP 請求方法描述
GET 用于客戶端請求指定資源信息，并返回指定資源實體
HEAD 跟 GET 相似，但其不需要服務(wù)器響應(yīng)請求的資源，而返回響應(yīng)首部(只需要響應(yīng)首部即可，就是告訴我有或者沒有，不需要緩存界面給我)
POST 基于 HTML 表單向服務(wù)器提交數(shù)據(jù)，服務(wù)器通常需要存儲此數(shù)據(jù)，通常存放在 mysql 這種關(guān)系型數(shù)據(jù)庫中
PUT 與 GET 相反，是向服務(wù)器發(fā)送資源的，服務(wù)器通常需要存儲此資源(存放的位置通常是文件系統(tǒng))
DELETE 請求服務(wù)器端刪除 URL 指定的資源
MOVE 請求服務(wù)器將指定的頁面移至另一個網(wǎng)絡(luò)地址
OPTIONOS 探測服務(wù)器端對請求的 URL 所支持使用的請求方法
TRACE 跟一次請求中間所經(jīng)歷的代理服務(wù)器、防火墻或網(wǎng)關(guān)等。
常用的 HTTP 請求方式是 GET, POST, HEAD
HTTP 的狀態(tài)碼
狀態(tài)碼 說明
1XX 信息性狀態(tài)碼，用于指定客戶端相應(yīng)的某些操作
2XX 成功狀態(tài)碼，我請求一個資源，這個資源在，這就表示請求成功了。
3XX 重定向的狀態(tài)碼，有時會返回的是一個新地址，而非結(jié)果
4XX 客戶端類錯誤，你請求的資源不存在，或者你請求的時候，我們這個資源拒絕你訪問，你沒有權(quán)限
5XX 服務(wù)器類的錯誤信息。向服務(wù)器發(fā)起請求，服務(wù)器發(fā)現(xiàn)需要運行一個腳本，從而調(diào)用解析庫。如果在調(diào)用過程中出錯就會出現(xiàn)這種情況。或者你的腳本有語法錯誤，也可能會導(dǎo)致這個問題。
常用狀態(tài)碼說明
狀態(tài)碼 說明
200 服務(wù)器成功返回網(wǎng)頁，這是成功的 HTTP 請求返回的標(biāo)準(zhǔn)狀態(tài)碼
201 CREATED 上傳文件成功后顯示
301 Move Permanently,*** 重定向，會返回一個新地址，并告訴我們你所請求的地址將 *** 挪到那個新地址去了
302 Fonud, 臨時重定向，臨時放到某個地方，會在響應(yīng)報文中使用“Location：新位置”;
304 Not Modified，資源沒有做任何修改
403 Forbidden 請求被拒絕
404 Not Found 請求的資源不存在
405 Method Not Allowed 你使用的方法不被允許，不支持
500 Internal Server Error：服務(wù)器內(nèi)部錯誤
502 Bad Gateway，代理服務(wù)器從上游服務(wù)器收到一條偽響應(yīng); 上一層服務(wù)器返回了一個無法理解的報文，所以代理服務(wù)器就會表示錯誤。
503 Service Unavailable，服務(wù)暫時不可用
HTTP 首部介紹
通用首部
請求首部
響應(yīng)首部
實體首部：專門用來表示實體中資源內(nèi)部的類型、長度、編碼格式等
擴(kuò)展首部：非標(biāo)準(zhǔn)首部，可有程序員自行創(chuàng)建
通用首部
Connection：定義 C / S 之間關(guān)于請求、響應(yīng)的有關(guān)選項
在 http1.0 的時候，如果他想使用持久連接，那么他所設(shè)置的選項即為
Connection：keep-alive
Cache-Control：緩存控制，實現(xiàn)更精細(xì)的緩存控制方式。在 http 1.1 上比較常見
請求首部
Client-IP：客戶端 IP 地址
Host：請求的主機(jī)，這在實現(xiàn)基于主機(jī)名的虛擬主機(jī)時很有用
Referer：指明了請求當(dāng)前資源原始資源的 URL，使用 referer 是可以防盜鏈
User-Agent：用戶代理，一般而言是瀏覽器
Accept 首部：指客戶端可以接受哪些編碼的類型
Accept：服務(wù)端能夠發(fā)送的媒體的類型
Accetp-Charset：接收的字符集
Accept-Encoding：編碼格式
Accept-Lanage：所能接受的語言編碼格式
條件式請求首部：(在 http1.1 中才會用到)
當(dāng)發(fā)送請求時，先問問對方是否滿足條件，如果滿足條件就請求，不滿足就不請求
跟安全相關(guān)的請求：
Authorization
Cookie
響應(yīng)首部
Age：資源響應(yīng)給你之后可以使用的時長
Server：向客戶端說明自己用到的程序名稱和版本
協(xié)商類的首部：
Vary：首部列表，服務(wù)器會根據(jù)此列表挑選最適合的版本發(fā)給客戶端
跟安全相關(guān)：
WWW-Authentication
Set-Cookie
實體首部
Location：指明資源的新位置，實現(xiàn) 302 響應(yīng)碼時通常會用到
Allow：允許對此資源使用的請求方法
內(nèi)容相關(guān)的首部
Content-Encoding
Content-Language
Content-Length
Content-Location：內(nèi)容所在的位置
Content-Type
緩存相關(guān)：
ETag：擴(kuò)展標(biāo)簽 / 標(biāo)記
Expires：過期時間
Last-Modified：刪除修改時間
HTTP 的事務(wù)
包含了一個 HTTP 請求，和對應(yīng)請求的響應(yīng)就叫做一個 http 事務(wù)，也可以理解 http 事務(wù)就是一個完整的 HTTP 請求和 HTTP 響應(yīng)的過程。
http 協(xié)議默認(rèn)情況下每個事務(wù)都會打開和關(guān)閉一個新的連接，所以會相當(dāng)耗費時間和帶寬，由于 TCP 慢啟動特性，所以每條新的連接的性能本身就會有所降低，所以可打開的并行連接的數(shù)量上限是有限的。所以使用持久連接這種模式比默認(rèn)情況下不使用持久連接的方式會好一點，他的好處表現(xiàn)在其請求和 tcp 斷開的過程所消耗的時間會被減少。
HTTP 資源
資源就是通過 HTTP 協(xié)議可以讓用戶通過瀏覽器或用戶代理能夠通過基于 http 協(xié)議向服務(wù)器端請求并獲取的內(nèi)容，像 html 文檔，一張圖片等等。
資源類型：是通過 MIME 進(jìn)行標(biāo)記
格式：major/minor 主標(biāo)記和次標(biāo)記
常用的 MIME 類型
MIME 類型 文件類型
test/htmlhtml、htm 文本類型
text/plaintext 文本類型
image/jpegjpeg 圖像類型
image/gifgif 圖像類型
vedio/mpeg4 音頻標(biāo)記類型
application/vnd.ms-powerpoint 動態(tài)資源的標(biāo)記方式
URI 和 URL
URI(Uniform Resource Identifier) 同一資源標(biāo)示符
用于標(biāo)識某一互聯(lián)網(wǎng)資源名稱的字符串，通過這種標(biāo)識來允許你用戶對資源可通過特定的協(xié)議進(jìn)行交互操作。在 Web 上可用的每種資源，包括 HTML 文檔、圖像、視頻片段、程序等， 由一個通用資源標(biāo)識符進(jìn)行定位。所以我們可以使用 URI 來標(biāo)識每個資源的名稱
URL(Uniform Resource Locator)(統(tǒng)一資源定位符)
用于描述一個特定服務(wù)器上某資源的特定位置。
例如：http://www.magedu.com:80/download/bash-4.3.1-1.rpm
URL 的格式分為三個部分
scheme(方案)(也叫協(xié)議)：http：//
Internet 地址：一般這個地址指的是服務(wù)器:www.magedu.com:8080
特定服務(wù)器上的資源：download/bash-4.3.1-1.rpm
CGI
Common Gateway Interface 通用網(wǎng)關(guān)接口
web 服務(wù)器發(fā)現(xiàn)需要執(zhí)行腳本了，就通過 CGI 協(xié)議跟后端的應(yīng)用程序打交道，把用戶的請求動態(tài)交給服務(wù)器，這個服務(wù)器的結(jié)果通過 CGI 協(xié)議返回給 http 服務(wù)器。
其他需要了解的知識
一次 Web 資源請求的具體過程
客戶端在 Web 瀏覽器輸入需要訪問的地址
Web 瀏覽器會請求 DNS 服務(wù)器，查詢解析到指定域名和 Web 服務(wù)器的地址
客戶端與請求的 Web 服務(wù)器端建立連接(TCP 三次握手)
TCP 建立成功之后，發(fā)起 HTTP 請求
服務(wù)器端收到客戶端 HTTP 請求之后，會處理該請求
處理客戶端指定請求的資源
服務(wù)器構(gòu)建響應(yīng)報文，響應(yīng)給客戶端
服務(wù)器端將此信息記錄到日志中
http 如何并發(fā)的接收多個用戶請求
因為 http 默認(rèn)是工作在阻塞模型下的，默認(rèn)一次只接收一個請求，處理完請求后再去接收下一個請求，所以只能一個一個來。
所以我們希望并發(fā)響應(yīng)用戶請求，需要多進(jìn)程模型。web 服務(wù)器自己會生成多個子進(jìn)程響應(yīng)用戶請求，也就是說，當(dāng)一個用戶請求發(fā)到 Web 服務(wù)器，Web 主進(jìn)程不會直接響應(yīng)用戶請求，而是生成一個子進(jìn)程響應(yīng)這個用戶請求，這樣當(dāng)子進(jìn)程和此用戶建立連接之后。Web 的主進(jìn)程就會再等待另一個用戶的請求，當(dāng)?shù)诙€用戶請求過來之后，在生成一個子進(jìn)程響應(yīng)第二個用戶請求。以此類推。所以每一個用戶請求都由一個子進(jìn)程來處理。
連接套接字
Client IP，cport harr; server IP , sport
一個主進(jìn)程會生成 N 個子進(jìn)程來響應(yīng)用戶請求，而實際上還是主進(jìn)程來響應(yīng)客戶端的請求。連接套接字不是真正響應(yīng)用戶請求的，而僅僅會是用來標(biāo)記用戶請求。Web 服務(wù)器真正建立連接的不是 80 端口，而是使用一個其他的臨時端口。會有人奇怪，明明我請求的是 80 端口，而你卻使用臨時端口響應(yīng)我，其實不是這樣，這個臨時端口只是用來標(biāo)記這么個客戶端請求的，而不是真正去響應(yīng)客戶端請求。真正響應(yīng)還是要主進(jìn)程的 80 端口向外響應(yīng)。
監(jiān)聽套接字：只有主服務(wù)才監(jiān)聽的。也就是使用 80 端口
web 服務(wù)器的 I / O 結(jié)構(gòu)：
單進(jìn)程模型：一次只響應(yīng)一個請求
多進(jìn)程模型：每個進(jìn)程響應(yīng)一個用戶請求而實現(xiàn)并發(fā)的效果
復(fù)用的 I / O 機(jī)制：一個進(jìn)程生成多個線程，每個線程響應(yīng)一個用戶請求，
復(fù)用的 I / O 機(jī)制：啟用多個線程，但每個線程響應(yīng)多個請求
我們使用的是單個線程，而不是進(jìn)程
進(jìn)程復(fù)用(多進(jìn)程模型)
我們知道，當(dāng) Web 服務(wù)器需要響應(yīng)用戶請求，會生成一個子進(jìn)程去響應(yīng)該用戶的請求，但一般用戶請求完成之后，Web 服務(wù)器需要銷毀這個子進(jìn)程。那么來來去去，我們需要不斷的創(chuàng)建子進(jìn)程、銷毀子進(jìn)程 hellip;，這樣會消耗系統(tǒng)資源。為了解決這樣的問題，我們可以創(chuàng)建一個進(jìn)程池，里面存放著一些空閑的子進(jìn)程，那么當(dāng)用戶請求過來的時候，我們可以從進(jìn)程池里取出一個空閑的子進(jìn)程去響應(yīng)用戶請求。若請求結(jié)束之后，我們又將子進(jìn)程返回到進(jìn)程池中，這樣就能省去系統(tǒng)創(chuàng)建、銷毀子進(jìn)程所帶來的沒必要的系統(tǒng)資源浪費。
而這個進(jìn)程池有多大呢? 是根據(jù)你服務(wù)器上的資源以及你服務(wù)器用戶需求到到底有多大來創(chuàng)建的。而創(chuàng)建這個進(jìn)程池也有一個好處，能定義我們最多使用多少個子進(jìn)程，這樣能免得一旦大量的請求涌進(jìn)來，直接擊垮我們的服務(wù)器。有了進(jìn)程池就能避免這個問題。當(dāng)我們的進(jìn)程池里的子進(jìn)程全用完了，如果此時還有請求進(jìn)來，那么你就只能在外面排隊等待了。所以使用進(jìn)程池還能做到控制并發(fā)請求量的。
網(wǎng)站流量度量及并發(fā)量概念及計算
IP
IP(Internet Protocol)指獨立的 IP 地址，用于衡量網(wǎng)站流量的一個重要指標(biāo)。當(dāng)客戶端使用獨立不同的 IP 地址訪問網(wǎng)站，都將會被記錄，被記錄的總數(shù)就是為一個衡量指標(biāo)。一般一天內(nèi)，相同的 IP 地址訪問網(wǎng)站只會被記錄一次。
但是使用獨立的 IP 地址來衡量網(wǎng)站的訪問量會缺點，就是我們知道 ADSL 和 NAT 的關(guān)系，所以獲取到的 IP 總數(shù)和實際訪問情況將不是完全匹配。
PV
PV(Page View)頁面瀏覽訪問量，通常衡量一個網(wǎng)絡(luò)新聞頻道和網(wǎng)站甚至一條網(wǎng)絡(luò)新聞的主要指標(biāo)。網(wǎng)頁瀏覽數(shù)是評價網(wǎng)站流量的最常用的指標(biāo)之一。無論客戶端是否不同、IP 是否不同，只要你使用瀏覽器向服務(wù)器發(fā)起一次請求(頁面瀏覽量和單擊量)，那么當(dāng)服務(wù)器端接收到請求后會響應(yīng)客戶端，而這些都會被記錄在 PV 中。
所以 PV 的數(shù)量大體反映瀏覽網(wǎng)站的頁面數(shù)量，但是也有一定的缺點，那就是刷新網(wǎng)頁也會被計數(shù)在 PV，所以 PV 數(shù)并不是真正頁面來訪者的數(shù)量，因為一個來訪者可以產(chǎn)生多個 PV。
UV
UV(Unique Visitor)網(wǎng)站獨立訪客，同一個客戶端訪問網(wǎng)站都會被將認(rèn)為是統(tǒng)一獨立訪客。一天內(nèi)使用相同的客戶端訪問同一個網(wǎng)站都將只會計算一次 UV
使用 UV 來計算會有一個缺點，那就是比如在學(xué)校里，一臺客戶端計算可能存在多個人使用的情況，這樣就會產(chǎn)生數(shù)值誤差。
并發(fā)連接
網(wǎng)站服務(wù)器在單位時間內(nèi)能夠處理的 *** 連接數(shù)
IP、PV、UV、并發(fā)量的計算
對 IP 計算
1. 分析網(wǎng)站的訪問日志，去除相同的 IP 地址
2. 使用第三方統(tǒng)計工具
3. 在網(wǎng)頁后添加多一個程序代碼統(tǒng)計字段，然后使用日志分析工具對程序代碼字段進(jìn)行統(tǒng)計。
對 PV 的計算
1. 分析網(wǎng)站的訪問日志，計算 HTML 及動態(tài)語言等網(wǎng)頁的數(shù)量
2. 使用第三方統(tǒng)計工具
3. 在網(wǎng)頁后添加多一個程序代碼統(tǒng)計字段，然后使用日志分析工具對程序代碼字段進(jìn)行統(tǒng)計。
對 UV 的計算
1. 分析客戶端的 HTTP 請求報文，將客戶端特有的信息記錄下來進(jìn)行分析。若能滿足共同的特征將會被認(rèn)為是同一個客戶端，那么此時將記錄為一個 UV。
2. 通過 cookie
當(dāng)客戶端訪問一個網(wǎng)站時，服務(wù)器會向該客戶端發(fā)送一個 Cookie，Cookie 具有獨一性，所以當(dāng)客戶端再次使用 cookie 訪問網(wǎng)站時，會附帶此 Cookie，那么此時服務(wù)器就會認(rèn)為是同一個客戶端，那么只會記錄一次的 UV
缺點：使用 Cookie 方法比分析客戶端 HTTP 請求頭部信息更為精準(zhǔn)，但是會有缺點，那就是用戶可能會關(guān)閉了 Cookie 功能。或者自動刪除了 cookie 等操作，所以獲取的指標(biāo)也不能說是完全準(zhǔn)確。
對并發(fā)量計算
每秒請求數(shù)(吞吐量) + 并發(fā)瀏覽連接數(shù) + 平均用戶考慮時間 = 網(wǎng)站并發(fā)用戶總數(shù)
關(guān)于 http 基礎(chǔ)應(yīng)用是怎么樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
