基礎拾掇之——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文字架構
<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 - 空白行
最後一個響應首部資訊之後就是一個空行，通過傳送回車符和換行符，通知客戶端空行下無首部資訊 - 響應實體
響應實體中裝載了要返回給客戶端的資料。這些資料可以是文字，也可以是二進位制（例如圖片，視訊）
例如：
<version> <status> <reason-phrase>
<HEADERS>
# 這裡一定要是一個空白行
<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
- 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/html | html、htm文字型別 |
| text/plain | text文字型別 |
| image/jpeg | jpeg影象型別 |
| image/gif | gif影象型別 |
| 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
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等操作，所以獲取的指標也不能說是完全準確。
對併發量計算
每秒請求數（吞吐量） + 併發瀏覽連線數 + 平均使用者考慮時間 = 網站併發使用者總數
文/溫琦鵬
文章出處：馬哥Linux運維