基礎拾掇之——http基礎

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文本架構



TITLE


H1



H2




html文檔的生成方式

  • 動態
    通過編譯語言編寫的程序後輸出html格式的結果
    動態語言有:php,jsp,asp,.net

    備註:這些腳本都必須有相應的解釋器,比如說 php需要有php解釋器等等

靜態和動態的方式

  • 靜態

基礎拾掇之——http基礎

  • 1、Web服務器向內核註冊socket
    2、客戶端通過瀏覽器,向Web服務器發起request請求
    3、Web服務器收到客戶端的request信息
    4、如果用戶請求的資源在服務器本地的話,http服務會向系統內核申請調用
    5、內核調用本地磁盤裡的數據,並將數據發給http服務
    6、http將用戶請求的資源通過response報文,最終響應給客戶端

  • 動態

基礎拾掇之——http基礎

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

http協議

http協議的報文

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

  • request Message(請求報文)
    客戶端 -→ 服務器端
    由客戶端向服務器端發出請求,不同的網站用於請求不同的資源(html文檔)

  • response Message(響應報文)
    服務器端 -→ 客戶端
    是服務器予以響應客戶端的請求

請求報文格式介紹

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

基礎拾掇之——http基礎

 
這次請求的方式是什麼,也就是請求方法
請求的是哪個資源,哪個URL。可以是相對路徑,如/images/log.jpg,也可以是絕對路徑,如http://www.magedu.com/images.banner.jpg
請求的協議版本是什麼,http協議版本,格式HTTP/.,例如:HTTP/1.0,HTTP/1.1 首部,首部可能不止一個。各種所可以使用的首部信息
請求實體,你到底請求的內容是什麼
  • 請求行
    由 請求方法字段+請求URL字段+HTTP協議版本組成,用來標識客戶端請求的資源時使用的請求方法,請求的資源,請求的協議版本是什麼,它們直接使用“空格”進行分隔!

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

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

  • 請求實體
    你需要請求的內容到底是什麼

    例如:

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

    響應報文格式介紹

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

基礎拾掇之——http基礎

 響應時客戶端請求的是什麼版本,服務器端就需要響應什麼版本
請求的狀態碼是什麼 202,403等
響應的狀態碼的信息是什麼,原因短語,這個狀態碼所響應的意義,易讀信息
一大堆的響應首部

響應體
  • 起始行
    也稱之為狀態行,用於服務器端響應客戶端請求的狀態信息,由版本號 + 狀態碼 + 原因短語組成,例如“ HTTP/1.1 200 OK”

  • 響應首部
    類似請求報文,起始行後面一般有若干個頭部字段。每個頭部字段都包含一個名字和一個值,兩者之間用冒號分割。格式Name:Value。
    例如:
    Content-Type: test/html; charset=utf-8
    Content-Length: 78

  • 空白行
    最後一個響應首部信息之後就是一個空行,通過發送回車符和換行符,通知客戶端空行下無首部信息

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

例如:

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

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請求返回的標準狀態碼201CREATED 上傳文件成功後顯示301Move Permanently,永久重定向,會返回一個新地址,並告訴我們你所請求的地址將永久挪到那個新地址去了302Fonud,臨時重定向,臨時放到某個地方,會在響應報文中使用“Location:新位置”;304Not Modified,資源沒有做任何修改403Forbidden 請求被拒絕404Not Found 請求的資源不存在405Method Not Allowed 你使用的方法不被允許,不支持500Internal Server Error:服務器內部錯誤502Bad Gateway,代理服務器從上游服務器收到一條偽響應;上一層服務器返回了一個無法理解的報文,所以代理服務器就會表示錯誤。503Service 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

    • Cookie

響應首部

  • 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)(統一資源定位符)
    用於描述一個特定服務器上某資源的特定位置。
    例如:
    URL的格式分為三個部分

  1. scheme(方案)(也叫協議):http://

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

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

CGI

Common Gateway Interface 通用網關接口

基礎拾掇之——http基礎

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

其他需要了解的知識

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

  1. 客戶端在Web瀏覽器輸入需要訪問的地址

  2. Web瀏覽器會請求DNS服務器,查詢解析到指定域名和Web服務器的地址

  3. 客戶端與請求的Web服務器端建立連接(TCP三次握手)

  4. TCP建立成功之後,發起HTTP請求

  5. 服務器端收到客戶端HTTP請求之後,會處理該請求

  6. 處理客戶端指定請求的資源

  7. 服務器構建響應報文,響應給客戶端

  8. 服務器端將此信息記錄到日誌中

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

IP(Internet Protocol)指獨立的IP地址,用於衡量網站流量的一個重要指標。當客戶端使用獨立不同的IP地址訪問網站,都將會被記錄,被記錄的總數就是為一個衡量指標。一般一天內,相同的IP地址訪問網站只會被記錄一次。
但是使用獨立的IP地址來衡量網站的訪問量會缺點,就是我們知道ADSL和NAT的關係,所以獲取到的IP總數和實際訪問情況將不是完全匹配。

PV

PV(Page View)頁面瀏覽訪問量,通常衡量一個網絡新聞頻道和網站甚至一條網絡新聞的主要指標。網頁瀏覽數是評價網站流量的最常用的指標之一。無論客戶端是否不同、IP是否不同,只要你使用瀏覽器向服務器發起一次請求(頁面瀏覽量和單擊量),那麼當服務器端接收到請求後會響應客戶端,而這些都會被記錄在PV中。
所以PV的數量大體反映瀏覽網站的頁面數量,但是也有一定的缺點,那就是刷新網頁也會被計數在PV,所以PV數並不是真正頁面來訪者的數量,因為一個來訪者可以產生多個PV。

UV

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等操作,所以獲取的指標也不能說是完全準確。

對併發量計算

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


分享到:


相關文章: