《基礎拾掇之——http基礎》要點:
本文介紹了基礎拾掇之——http基礎,希望對您有用。如果有疑問,可以聯系我們。
http:Hyper Text Transfer Protocol 超文本傳輸協議,是互聯網應用最為廣泛的一種網絡協議,主要用于Web服務.通過計算機處理文本信息,格式為HTML(Hyper Text Mark Language)超文本標記語言來實現.
目前常用的版本就是http 1.0版本和http 1.1版本.
<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>
備注:這些腳本都必須有相應的解釋器,比如說 php需要有php解釋器等等
HTTP報文中存在著很多行的內容,一般是由ASCII碼串組成,各字段長度是不確定的.HTTP的報文可分為兩種:請求報文與響應報文
請求行 + 請求首部 + 空白行 + 請求實體
<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>組成
,用來標識客戶端請求的資源時使用的請求方法,請求的資源,請求的協議版本是什么,它們直接使用“空格”進行分隔!例如:
<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”例如:
<version> <status> <reason-phrase>
<HEADERS> ? ? ? ? ? ? ? ? ? ? ? ?
# 這里一定要是一個空白行
<entity-body>
在HTTP通信過程中,每個HTTP請求報文中都會包含一個HTTP請求方法,用于告知客戶端向服務器端請求執行某些具體的操作,下面列舉幾項常用的HTTP請求方法.
HTTP請求方法 | 描述 |
---|---|
GET | 用于客戶端請求指定資源信息,并返回指定資源實體 |
HEAD | 跟GET相似,但其不需要服務器響應請求的資源,而返回響應首部(只需要響應首部即可,就是告訴我有或者沒有,不需要緩存界面給我) |
POST | 基于HTML表單向服務器提交數據,服務器通常需要存儲此數據,通常存放在mysql這種關系型數據庫中 |
PUT | 與GET相反,是向服務器發送資源的,服務器通常需要存儲此資源(存放的位置通常是文件系統) |
DELETE | 請求服務器端刪除URL指定的資源 |
MOVE | 請求服務器將指定的頁面移至另一個網絡地址 |
OPTIONOS | 探測服務器端對請求的URL所支持使用的請求方法 |
TRACE | 跟一次請求中間所經歷的代理服務器、防火墻或網關等. |
常用的HTTP請求方式是GET, POST, HEAD
狀態碼 | 說明 |
---|---|
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,服務暫時不可用 |
Connection:keep-alive
包含了一個HTTP請求,和對應請求的響應就叫做一個http事務,也可以理解http事務就是一個完整的HTTP請求和HTTP響應的過程.
http協議默認情況下每個事務都會打開和關閉一個新的連接,所以會相當耗費時間和帶寬,由于TCP慢啟動特性,所以每條新的連接的性能本身就會有所降低,所以可打開的并行連接的數量上限是有限的.所以使用持久連接這種模式比默認情況下不使用持久連接的方式會好一點,他的好處表現在其請求和tcp斷開的過程所消耗的時間會被減少.
資源就是通過HTTP協議可以讓用戶通過瀏覽器或用戶代理能夠通過基于http協議向服務器端請求并獲取的內容,像html文檔,一張圖片等等.
格式:major/minor 主標記和次標記
常用的MIME類型
MIME類型 | 文件類型 |
---|---|
test/html | html、htm文本類型 |
text/plain | text文本類型 |
image/jpeg | jpeg圖像類型 |
image/gif | gif圖像類型 |
vedio/mpeg4 | 音頻標記類型 |
application/vnd.ms-powerpoint | 動態資源的標記方式 |
Common Gateway Interface 通用網關接口
web服務器發現需要執行腳本了,就通過CGI協議跟后端的應用程序打交道,把用戶的請求動態交給服務器,這個服務器的結果通過CGI協議返回給http服務器.
因為http默認是工作在阻塞模型下的,默認一次只接收一個請求,處理完請求后再去接收下一個請求,所以只能一個一個來.
所以我們希望并發響應用戶請求,需要多進程模型.web服務器自己會生成多個子進程響應用戶請求,也就是說,當一個用戶請求發到Web服務器,Web主進程不會直接響應用戶請求,而是生成一個子進程響應這個用戶請求,這樣當子進程和此用戶建立連接之后.Web的主進程就會再等待另一個用戶的請求,當第二個用戶請求過來之后,在生成一個子進程響應第二個用戶請求.以此類推.所以每一個用戶請求都由一個子進程來處理.
Client IP,cport ? server IP , sport
一個主進程會生成N個子進程來響應用戶請求,而實際上還是主進程來響應客戶端的請求.連接套接字不是真正響應用戶請求的,而僅僅會是用來標記用戶請求.Web服務器真正建立連接的不是80端口,而是使用一個其他的臨時端口.會有人奇怪,明明我請求的是80端口,而你卻使用臨時端口響應我,其實不是這樣,這個臨時端口只是用來標記這么個客戶端請求的,而不是真正去響應客戶端請求.真正響應還是要主進程的80端口向外響應.
監聽套接字:只有主服務才監聽的.也就是使用80端口
我們使用的是單個線程,而不是進程
我們知道,當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來計算會有一個缺點,那就是比如在學校里,一臺客戶端計算可能存在多個人使用的情況,這樣就會產生數值誤差.
網站服務器在單位時間內能夠處理的最大連接數
1.分析網站的訪問日志,去除相同的IP地址
2.使用第三方統計工具
3.在網頁后添加多一個程序代碼統計字段,然后使用日志分析工具對程序代碼字段進行統計.
1.分析網站的訪問日志,計算HTML及動態語言等網頁的數量
2.使用第三方統計工具
3.在網頁后添加多一個程序代碼統計字段,然后使用日志分析工具對程序代碼字段進行統計.
1.分析客戶端的HTTP請求報文,將客戶端特有的信息記錄下來進行分析.若能滿足共同的特征將會被認為是同一個客戶端,那么此時將記錄為一個UV.
2.通過cookie
當客戶端訪問一個網站時,服務器會向該客戶端發送一個Cookie,Cookie具有獨一性,所以當客戶端再次使用cookie訪問網站時,會附帶此Cookie,那么此時服務器就會認為是同一個客戶端,那么只會記錄一次的UV
缺點:使用Cookie方法比分析客戶端HTTP請求頭部信息更為精準,但是會有缺點,那就是用戶可能會關閉了Cookie功能.或者自動刪除了cookie等操作,所以獲取的指標也不能說是完全準確.
每秒請求數(吞吐量) + 并發瀏覽連接數 + 平均用戶考慮時間 = 網站并發用戶總數
文/溫琦鵬
文章出處:馬哥Linux運維