http 基礎

時間 2020-03-25

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

原文原文鏈接

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>
        <h1>H1</h1>
            <p></p>
    <h2>H2</h2>
        <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，請求首部的做用是經過客戶端將請求的相關內容告知服務器端，首部能夠不止一個。
空白行
請求首部以後會有一個空白行，經過發送回車字符和換行符，用於通知服務器端一下的內容將不會再出現請求首部的信息。
請求實體
你須要請求的內容究竟是什麼

例如：
<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 地址來衡量網站的訪問量會缺點，就是咱們知道 ADS L和 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 等操做，因此獲取的指標也不能說是徹底準確。