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