基礎拾掇之——http基礎

時間 2020-03-25

標籤基礎拾掇 http 欄目 HTTP/TCP 简体版

原文原文鏈接

基礎拾掇之——http基礎

http協議介紹

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

http協議的版本

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

http 1.0mysql

引入了MIME(Multipurpose Internet Mail Extesions)機制：多用途互聯網郵件擴展，引入這個技術以後，http能夠發送多媒體（好比視頻、音頻等）信息。此機制讓http不在單單隻支持html格式，還能夠支持其餘格式來進行發送了。程序員

引入了keep-alive機制，支持持久鏈接的功能（但這個keep-alive原理是在首部添加了某個字段而造成的，並不是原生就支持此功能）web

引入支持緩存功能sql

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>

<p></p>

<p><a href="admin.html">ToGoogle</a> </p>

</body>

</html>

html文檔的生成方式

靜態
事先就編輯並定義完成的

動態
經過編譯語言編寫的程序後輸出html格式的結果
動態語言有：php，jsp，asp，.net

備註：這些腳本都必須有相應的解釋器，好比說 php須要有php解釋器等等

靜態和動態的方式

靜態
一、Web服務器向內核註冊socket
二、客戶端經過瀏覽器，向Web服務器發起request請求
三、Web服務器收到客戶端的request信息
四、若是用戶請求的資源在服務器本地的話，http服務會向系統內核申請調用
五、內核調用本地磁盤裏的數據，並將數據發給http服務
六、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，請求首部的做用是經過客戶端將請求的相關內容告知服務器端，首部能夠不止一個。

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

請求實體
你須要請求的內容究竟是什麼

例如：

<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

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

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

例如：

<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

響應首部

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

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等操做，因此獲取的指標也不能說是徹底準確。

對併發量計算

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

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。