基礎拾掇之http基礎應用詳解

作者：溫琦鵬 2016-07-29 10:37:00

http：Hyper Text Transfer Protocol 超文本傳輸協議，是互聯網應用最為廣泛的一種網絡協議，主要用于Web服務。通過計算機處理文本信息，格式為HTML（Hyper Text Mark Language）超文本標記語言來實現。

http協議介紹

http：Hyper Text Transfer Protocol 超文本傳輸協議，是互聯網應用最為廣泛的一種網絡協議，主要用于Web服務。通過計算機處理文本信息，格式為HTML(Hyper Text Mark Language)超文本標記語言來實現。

http協議的版本

http 0.9：僅于用戶傳輸html文檔

http 1.0

引入了MIME(Multipurpose Internet Mail Extesions)機制：多用途互聯網郵件擴展，引入這個技術之后，http可以發送多媒體(比如視頻、音頻等)信息。此機制讓http不在單單只支持html格式，還可以支持其他格式來進行發送了。

引入了keep-alive機制，支持持久連接的功能(但這個keep-alive原理是在首部添加了某個字段而形成的，并非原生就支持此功能)

引入支持緩存功能

http 1.1

支持更多的請求方法，更加精細的緩存控制，原生直接支持持久連接功能(presistent)。

http 2.0

提供了HTTP語義優化的傳輸

spdy : google引入了的一個技術，能夠加速http數據交互，尤其是使用ssl 加速機制，但是spdy現在用的還不多。

目前常用的版本就是http 1.0版本和http 1.1版本。

html文本介紹

html文本架構

<html>  
<head>  
<title>TITLE</title>  
</head>  
<body>  
<h1>H1</h1>  
<p></p>  
<h2>H2</h2>  
<p><a href="admin.html" rel="external nofollow" target="_blank">ToGoogle</a> </p>  
</body>  
</html>

html文檔的生成方式

靜態

事先就編輯并定義完成的

動態

通過編譯語言編寫的程序后輸出html格式的結果

動態語言有：php，jsp，asp，.net

備注：這些腳本都必須有相應的解釋器，比如說 php需要有php解釋器等等。

靜態和動態的方式

靜態

1、Web服務器向內核注冊socket

2、客戶端通過瀏覽器，向Web服務器發起request請求

3、Web服務器收到客戶端的request信息

4、如果用戶請求的資源在服務器本地的話，http服務會向系統內核申請調用

5、內核調用本地磁盤里的數據，并將數據發給http服務

6、http將用戶請求的資源通過response報文，最終響應給客戶端

動態

與靜態不同的是，如果用戶請求的是動態內容，那么此時http服務會調用后端的解析器，由動態語言去處理用戶的請求，如果需要請求數據的時候，會向內核申請調用，從而向磁盤中獲取用戶指定的數據，通過解釋器運行，運行的結果通常會生成html格式的文件。然后構建成響應報文，最終發回給客戶端。

http協議

http協議的報文

HTTP報文中存在著很多行的內容，一般是由ASCII碼串組成，各字段長度是不確定的。HTTP的報文可分為兩種：請求報文與響應報文

request Message(請求報文)

客戶端 -→ 服務器端

由客戶端向服務器端發出請求，不同的網站用于請求不同的資源(html文檔)

response Message(響應報文)

服務器端 -→ 客戶端

是服務器予以響應客戶端的請求

請求報文格式介紹

請求行 + 請求首部 + 空白行 + 請求實體

<method> 這次請求的方式是什么，也就是請求方法

<request-URL> 請求的是哪個資源，哪個URL。可以是相對路徑，如/images/log.jpg，也可以是絕對路徑，如http://www.magedu.com/images.banner.jpg

<version> 請求的協議版本是什么，http協議版本，格式HTTP/<major>.<minor>，例如：HTTP/1.0，HTTP/1.1<HEADERS> 首部，首部可能不止一個。各種所可以使用的首部信息

<entity-body> 請求實體，你到底請求的內容是什么

請求行

由請求方法字段<method>+請求URL字段<request-URL>+HTTP協議版本<version>組成，用來標識客戶端請求的資源時使用的請求方法，請求的資源，請求的協議版本是什么，它們直接使用“空格”進行分隔!

請求首部

由關鍵字+關鍵字的值組成，之間使用“：”進行分隔，格式Name：Value，請求首部的作用是通過客戶端將請求的相關內容告知服務器端，首部可以不止一個。

空白行

請求首部之后會有一個空白行，通過發送回車字符和換行符，用于通知服務器端一下的內容將不會再出現請求首部的信息。

請求實體

你需要請求的內容到底是什么

例如：

<method> <request-URL> <version>  
<HEADERS>  
# 這里一定要是一個空白行  
<entity-body>

響應報文格式介紹

起始行 + 響應首部 + 空白行 + 響應實體

<version> 響應時客戶端請求的是什么版本，服務器端就需要響應什么版本

<status> 請求的狀態碼是什么 202，403等

<reason-phrase> 響應的狀態碼的信息是什么，原因短語，這個狀態碼所響應的意義，易讀信息

<HEADERS> 一大堆的響應首部

<entity-body> 響應體

起始行

也稱之為狀態行，用于服務器端響應客戶端請求的狀態信息，由版本號<version>+ 狀態碼<status> + 原因短語<reason-phrase>組成，例如“ HTTP/1.1 200 OK”

響應首部

類似請求報文，起始行后面一般有若干個頭部字段。每個頭部字段都包含一個名字和一個值，兩者之間用冒號分割。格式Name：Value。

例如：

Content-Type: test/html; charset=utf-8

Content-Length: 78

空白行

***一個響應首部信息之后就是一個空行，通過發送回車符和換行符，通知客戶端空行下無首部信息

響應實體

響應實體中裝載了要返回給客戶端的數據。這些數據可以是文本，也可以是二進制(例如圖片，視頻)

例如：

# 這里一定要是一個空白行

<entity-body>

HTTP請求方法

在HTTP通信過程中，每個HTTP請求報文中都會包含一個HTTP請求方法，用于告知客戶端向服務器端請求執行某些具體的操作，下面列舉幾項常用的HTTP請求方法。

HTTP請求方法描述

GET用于客戶端請求指定資源信息，并返回指定資源實體

HEAD跟GET相似，但其不需要服務器響應請求的資源，而返回響應首部(只需要響應首部即可，就是告訴我有或者沒有，不需要緩存界面給我)

POST基于HTML表單向服務器提交數據，服務器通常需要存儲此數據，通常存放在mysql這種關系型數據庫中

PUT與GET相反，是向服務器發送資源的，服務器通常需要存儲此資源(存放的位置通常是文件系統)

DELETE請求服務器端刪除URL指定的資源

MOVE請求服務器將指定的頁面移至另一個網絡地址

OPTIONOS探測服務器端對請求的URL所支持使用的請求方法

TRACE跟一次請求中間所經歷的代理服務器、防火墻或網關等。

常用的HTTP請求方式是GET, POST, HEAD

HTTP的狀態碼

狀態碼說明

1XX 信息性狀態碼，用于指定客戶端相應的某些操作

2XX 成功狀態碼，我請求一個資源，這個資源在，這就表示請求成功了。

3XX 重定向的狀態碼，有時會返回的是一個新地址，而非結果

4XX 客戶端類錯誤，你請求的資源不存在，或者你請求的時候，我們這個資源拒絕你訪問，你沒有權限

5XX 服務器類的錯誤信息。向服務器發起請求，服務器發現需要運行一個腳本，從而調用解析庫。如果在調用過程中出錯就會出現這種情況。或者你的腳本有語法錯誤，也可能會導致這個問題。

常用狀態碼說明

狀態碼說明

200 服務器成功返回網頁，這是成功的HTTP請求返回的標準狀態碼

201 CREATED 上傳文件成功后顯示

301 Move Permanently,***重定向，會返回一個新地址，并告訴我們你所請求的地址將***挪到那個新地址去了

302 Fonud,臨時重定向，臨時放到某個地方，會在響應報文中使用“Location：新位置”;

304 Not Modified，資源沒有做任何修改

403 Forbidden 請求被拒絕

404 Not Found 請求的資源不存在

405 Method Not Allowed 你使用的方法不被允許，不支持

500 Internal Server Error：服務器內部錯誤

502 Bad Gateway，代理服務器從上游服務器收到一條偽響應;上一層服務器返回了一個無法理解的報文，所以代理服務器就會表示錯誤。

503 Service Unavailable，服務暫時不可用

HTTP首部介紹

通用首部
請求首部
響應首部
實體首部：專門用來表示實體中資源內部的類型、長度、編碼格式等
擴展首部：非標準首部，可有程序員自行創建

通用首部

Connection：定義C/S之間關于請求、響應的有關選項

在http1.0 的時候，如果他想使用持久連接，那么他所設置的選項即為

Connection：keep-alive

Cache-Control：緩存控制，實現更精細的緩存控制方式。在http 1.1上比較常見

請求首部

Client-IP ：客戶端 IP地址

Host ：請求的主機，這在實現基于主機名的虛擬主機時很有用

Referer ：指明了請求當前資源原始資源的URL，使用referer是可以防盜鏈

User-Agent：用戶代理，一般而言是瀏覽器

Accept首部：指客戶端可以接受哪些編碼的類型

Accept：服務端能夠發送的媒體的類型

Accetp-Charset：接收的字符集

Accept-Encoding：編碼格式

Accept-Lanage：所能接受的語言編碼格式

條件式請求首部：(在http1.1中才會用到)

當發送請求時，先問問對方是否滿足條件，如果滿足條件就請求，不滿足就不請求

跟安全相關的請求：

Authorization

響應首部

Age：資源響應給你之后可以使用的時長

Server：向客戶端說明自己用到的程序名稱和版本

協商類的首部：

Vary：首部列表，服務器會根據此列表挑選最適合的版本發給客戶端

跟安全相關：

WWW-Authentication

Set-Cookie

實體首部

Location：指明資源的新位置，實現302響應碼時通常會用到

Allow：允許對此資源使用的請求方法

內容相關的首部

Content-Encoding

Content-Language

Content-Length

Content-Location：內容所在的位置

Content-Type

緩存相關：

ETag：擴展標簽/標記

Expires：過期時間

Last-Modified：刪除修改時間

HTTP的事務

包含了一個HTTP請求，和對應請求的響應就叫做一個http事務，也可以理解http事務就是一個完整的HTTP請求和HTTP響應的過程。

http協議默認情況下每個事務都會打開和關閉一個新的連接，所以會相當耗費時間和帶寬，由于TCP慢啟動特性，所以每條新的連接的性能本身就會有所降低，所以可打開的并行連接的數量上限是有限的。所以使用持久連接這種模式比默認情況下不使用持久連接的方式會好一點，他的好處表現在其請求和tcp斷開的過程所消耗的時間會被減少。

HTTP資源

資源就是通過HTTP協議可以讓用戶通過瀏覽器或用戶代理能夠通過基于http協議向服務器端請求并獲取的內容，像html文檔，一張圖片等等。

資源類型：是通過MIME進行標記

格式：major/minor 主標記和次標記

常用的MIME類型

MIME類型文件類型

test/htmlhtml、htm 文本類型

text/plaintext 文本類型

image/jpegjpeg 圖像類型

image/gifgif 圖像類型

vedio/mpeg4 音頻標記類型

application/vnd.ms-powerpoint 動態資源的標記方式

URI和URL

URI(Uniform Resource Identifier) 同一資源標示符

用于標識某一互聯網資源名稱的字符串，通過這種標識來允許你用戶對資源可通過特定的協議進行交互操作。在Web上可用的每種資源，包括HTML文檔、圖像、視頻片段、程序等，由一個通用資源標識符進行定位。所以我們可以使用URI來標識每個資源的名稱

URL(Uniform Resource Locator)(統一資源定位符)

用于描述一個特定服務器上某資源的特定位置。

例如：http://www.magedu.com:80/download/bash-4.3.1-1.rpm

URL的格式分為三個部分

scheme(方案)(也叫協議)：http：//

Internet地址：一般這個地址指的是服務器:www.magedu.com:8080

特定服務器上的資源：download/bash-4.3.1-1.rpm

CGI

Common Gateway Interface 通用網關接口

web服務器發現需要執行腳本了，就通過CGI協議跟后端的應用程序打交道，把用戶的請求動態交給服務器，這個服務器的結果通過CGI協議返回給http服務器。

其他需要了解的知識

一次Web資源請求的具體過程

客戶端在Web瀏覽器輸入需要訪問的地址
Web瀏覽器會請求DNS服務器，查詢解析到指定域名和Web服務器的地址
客戶端與請求的Web服務器端建立連接(TCP三次握手)
TCP建立成功之后，發起HTTP請求
服務器端收到客戶端HTTP請求之后，會處理該請求
處理客戶端指定請求的資源
服務器構建響應報文，響應給客戶端
服務器端將此信息記錄到日志中

http如何并發的接收多個用戶請求

因為http默認是工作在阻塞模型下的，默認一次只接收一個請求，處理完請求后再去接收下一個請求，所以只能一個一個來。

所以我們希望并發響應用戶請求，需要多進程模型。web服務器自己會生成多個子進程響應用戶請求，也就是說，當一個用戶請求發到Web服務器，Web主進程不會直接響應用戶請求，而是生成一個子進程響應這個用戶請求，這樣當子進程和此用戶建立連接之后。Web的主進程就會再等待另一個用戶的請求，當第二個用戶請求過來之后，在生成一個子進程響應第二個用戶請求。以此類推。所以每一個用戶請求都由一個子進程來處理。

連接套接字

Client IP，cport ↔ server IP , sport

一個主進程會生成N個子進程來響應用戶請求，而實際上還是主進程來響應客戶端的請求。連接套接字不是真正響應用戶請求的，而僅僅會是用來標記用戶請求。Web服務器真正建立連接的不是80端口，而是使用一個其他的臨時端口。會有人奇怪，明明我請求的是80端口，而你卻使用臨時端口響應我，其實不是這樣，這個臨時端口只是用來標記這么個客戶端請求的，而不是真正去響應客戶端請求。真正響應還是要主進程的80端口向外響應。

監聽套接字：只有主服務才監聽的。也就是使用80端口

web服務器的I/O結構：

單進程模型：一次只響應一個請求
多進程模型：每個進程響應一個用戶請求而實現并發的效果
復用的I/O機制：一個進程生成多個線程，每個線程響應一個用戶請求，
復用的I/O機制：啟用多個線程，但每個線程響應多個請求

我們使用的是單個線程，而不是進程

進程復用(多進程模型)

我們知道，當Web服務器需要響應用戶請求，會生成一個子進程去響應該用戶的請求，但一般用戶請求完成之后，Web服務器需要銷毀這個子進程。那么來來去去，我們需要不斷的創建子進程、銷毀子進程…，這樣會消耗系統資源。為了解決這樣的問題，我們可以創建一個進程池，里面存放著一些空閑的子進程，那么當用戶請求過來的時候，我們可以從進程池里取出一個空閑的子進程去響應用戶請求。若請求結束之后，我們又將子進程返回到進程池中，這樣就能省去系統創建、銷毀子進程所帶來的沒必要的系統資源浪費。

而這個進程池有多大呢?是根據你服務器上的資源以及你服務器用戶需求到到底有多大來創建的。而創建這個進程池也有一個好處，能定義我們最多使用多少個子進程，這樣能免得一旦大量的請求涌進來，直接擊垮我們的服務器。有了進程池就能避免這個問題。當我們的進程池里的子進程全用完了，如果此時還有請求進來，那么你就只能在外面排隊等待了。所以使用進程池還能做到控制并發請求量的。

網站流量度量及并發量概念及計算

IP(Internet Protocol)指獨立的IP地址，用于衡量網站流量的一個重要指標。當客戶端使用獨立不同的IP地址訪問網站，都將會被記錄，被記錄的總數就是為一個衡量指標。一般一天內，相同的IP地址訪問網站只會被記錄一次。

但是使用獨立的IP地址來衡量網站的訪問量會缺點，就是我們知道ADSL和NAT的關系，所以獲取到的IP總數和實際訪問情況將不是完全匹配。

PV(Page View)頁面瀏覽訪問量，通常衡量一個網絡新聞頻道和網站甚至一條網絡新聞的主要指標。網頁瀏覽數是評價網站流量的最常用的指標之一。無論客戶端是否不同、IP是否不同，只要你使用瀏覽器向服務器發起一次請求(頁面瀏覽量和單擊量)，那么當服務器端接收到請求后會響應客戶端，而這些都會被記錄在PV中。

所以PV的數量大體反映瀏覽網站的頁面數量，但是也有一定的缺點，那就是刷新網頁也會被計數在PV，所以PV數并不是真正頁面來訪者的數量，因為一個來訪者可以產生多個PV。

UV(Unique Visitor)網站獨立訪客，同一個客戶端訪問網站都會被將認為是統一獨立訪客。一天內使用相同的客戶端訪問同一個網站都將只會計算一次UV

使用UV來計算會有一個缺點，那就是比如在學校里，一臺客戶端計算可能存在多個人使用的情況，這樣就會產生數值誤差。

并發連接

網站服務器在單位時間內能夠處理的***連接數

IP、PV、UV、并發量的計算

對IP計算

1.分析網站的訪問日志，去除相同的IP地址

2.使用第三方統計工具

3.在網頁后添加多一個程序代碼統計字段，然后使用日志分析工具對程序代碼字段進行統計。

對PV的計算

1.分析網站的訪問日志，計算HTML及動態語言等網頁的數量

2.使用第三方統計工具

3.在網頁后添加多一個程序代碼統計字段，然后使用日志分析工具對程序代碼字段進行統計。

對UV的計算

1.分析客戶端的HTTP請求報文，將客戶端特有的信息記錄下來進行分析。若能滿足共同的特征將會被認為是同一個客戶端，那么此時將記錄為一個UV。

2.通過cookie

當客戶端訪問一個網站時，服務器會向該客戶端發送一個Cookie，Cookie具有獨一性，所以當客戶端再次使用cookie訪問網站時，會附帶此Cookie，那么此時服務器就會認為是同一個客戶端，那么只會記錄一次的UV

缺點：使用Cookie方法比分析客戶端HTTP請求頭部信息更為精準，但是會有缺點，那就是用戶可能會關閉了Cookie功能。或者自動刪除了cookie等操作，所以獲取的指標也不能說是完全準確。

對并發量計算

每秒請求數(吞吐量) + 并發瀏覽連接數 + 平均用戶考慮時間 = 網站并發用戶總數

責任編輯：龐桂玉來源：運維派