超大型集羣第六篇（HTTP協議）

更多精彩內容請關注微信公衆號：新猿技術生態圈

1、HTTP協議簡介

1. 什麼是http協議？具體是幹什麼用的
	http又稱之爲超文本傳輸協議，主要用來從服務器傳輸超文本到本地瀏覽器的傳送協議
    
2. 什麼又是超文本？
	超文本最大的特徵就是能夠超連接文本文檔or圖片等內容(超連接即經過點擊進行跳轉網頁)

'http協議是基於TCP協議來傳遞數據的，另外咱們如今經常使用的http協議版本號爲1.1'

更多精彩內容請關注微信公衆號：新猿技術生態圈
更多精彩內容請關注微信公衆號：新猿技術生態圈
更多精彩內容請關注微信公衆號：新猿技術生態圈

2、HTTP/1.1說明

針對於http1.1版本主要須要說明兩點內容----HTTP無鏈接以及HTTP無狀態

2.1 HTTP無鏈接

# http無鏈接是什麼意思？
(1)無鏈接指的是tcp三次握手後創建的雙向連接只能支持一次數據的傳輸，即便用一次就斷開
(2)若是一直處於無鏈接狀態那麼用戶每次請求就會從新創建tcp的雙向鏈路，此時的訪問速度就有優化的空間


'解決辦法即須要在服務端開啓長連接'
1. 長連接意思爲http數據傳輸後將tcp連接保持在打開的狀態，以便將來的http請求繼續使用。
2. 長連接即需設置服務器的keepalive(保持連接)選項
'我的感受應該是要改nginx配置文件裏的keepalive有效，具體就不曉得改哪一個了'
[root@client ~]# vim /proc/sys/net/ipv4/tcp_keepalive_time 		# 更改裏面數值便可



'有益就有弊，簡單看下長連接的優勢以及缺點'
優: 	keepalive長連接模式更加高效，避免了連接創建和釋放的資源開銷
缺:	長時間的tcp連接容易致使系統資源無效佔用，浪費系統資源，因此上面的配置根據自身狀況來就好

2.2 HTTP無狀態

# http無狀態又是什麼意思？
(1) 官方定義： http無狀態是指協議對於交互性場景沒有記憶能力
(2) 白話解釋： 其實就是默認狀況下http沒有緩存功能，假設此時咱們輸入帳戶密碼，刷新一次又須要從新輸入


# http無狀態的解決辦法是什麼？
'最主要的目的就是讓服務器有記憶能力-----如今咱們較爲經常使用的方法爲Cookie+Session'
1.  Cookie
	'cookie的工做方式'
	(1) cookie實際上是一小段的文本信息，客戶端請求服務器，若是服務器須要記錄該用戶狀態，就會在響應請求是使用set-cookie將用戶狀態信息寫入到客戶端瀏覽器文件中去
	(2) 當瀏覽器下次請求訪問該網站時會將cookie信息添加到request請求的數據當中來代替用戶驗證
    
    'cookie的弊端'
     (1) 因爲cookie保存的數據信息是存在於客戶端的瀏覽器目錄下，因此此文件會有被篡改的風險，基於此種緣由，出現了一種基於cookie的機制Session.


2. Session
	(1) Session是另一種記錄客戶端狀態的機制，不一樣的是cookie保存在客戶端瀏覽器中，而Session保存在服務器上
	(2) 客戶端瀏覽器訪問服務器時，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session
       
     '爲何說Session基於cookie呢？'
 	 # session不只會將客戶端信息存儲在服務器上，還會有一小部分信息存儲在瀏覽器的cookie中，此時存儲在cookie的內容至關於一把用來打開服務器對應信息的鑰匙
    
	'再來講說Seesion的優缺點。。'
    優： 解決了純cookie可能被篡改文件的風險(就算你要改，改的也就是開鎖的內容，並不觸及到真正的用戶信息)
    缺： 在集羣環境下讀取服務器存儲的信息會有速度問題(存放到數據庫--硬盤速度不夠，存放到緩存服務器---內存空間不夠....)
    

3. jwt
	# 簡單粗暴，對cookie所產生的客戶端本地文件進行加密便可，使用服務器的私鑰進行解密便可
	# 據說暫時用的較少
    
4. 番外
	'Session和Cookie的關係'
	(1) cookie 是一個實際存在的、具體的東西，http 協議中定義在 header 中的字段。
	(2) session 是一個抽象概念、開發者爲了實現中斷和繼續等操做，將client和server之間一對一的交互，抽象爲「會話」，進而衍生出「會話狀態」，也就是 session 的概念。
	(3)即session描述的是一種通信會話機制，而cookie只是目前實現這種機制的主流方案裏面的一個參與者，它通常是用於保存session ID。

3、HTTP的請求信息(request)

1. 什麼是URL，什麼又是URI
	URI---統一資源標誌符(在某一規則下能把一個資源獨一無二地標識出來)
	URL---統一資源定位符(一種具體的URI，URL不只用來標識一個資源，並且還指明瞭如何定位這個資源)
    # 跟着大佬栗子解釋一波URI與URL的區別
	# URI:	假設全部的Html文檔都有惟一的編號，記做html:xxxx, xxxx是一串數字，即html文檔的身份證號，這個能惟一標識一個html文檔，那麼這個號碼就是一個URI
    # URL:	而URL則是經過描述是哪一個主機上哪一個路徑上的文件來惟一肯定一個資源，也就是定位的方式來實現的URI
    
    因此-----
    不管是用定位的方式仍是用編號的方式，咱們均可以肯定惟一的一個資源，都是URI的一種實現方式，而URL就是用定位的方式實現的URI
    # 跟着網上大佬再看一遍	https://www.zhihu.com/question/21950864
    
2. Request請求的格式
	客戶端發送一個HTTP請求到服務器的請求消息格式爲如下四部分組成：
    請求行(request line)----請求頭部(header)----空行----請求數據
    
    
    GET /linhaifeng/p/7278389.html HTTP/1.1	# 請求行--請求類型;須要訪問的資源;http版本號
    # 如下皆爲請求頭部信息----get請求沒有請求數據的主體
    Host: www.cnblogs.com
    Connection: keep-alive
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9	
        
  
3. http協議請求的方法
	'常常用的只有兩個'
#	get------請求指定的頁面信息，並返回實體主題
#	post-----向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中。post請求可能會致使新資源的創建和/或已有資源的修改

	'get和post使用上的區別？？'
    (1) 參數的組織方式不一樣
    	get 提交的數據會放在url以後，以？分割url和傳輸數據，參數之間以&相連
        post 是把提交的數據放在http包的body中，不會在地址欄裏顯示出來
    (2) 傳輸數據大小限制
    	get 特定瀏覽器和服務器會對url進行長度限制，因此get請求會有瓶頸
        post 不是經過url傳值，理論上數據不受限制，但理論畢竟是理論，儘可能不要過大
    (3) 安全性
    	顯而易見的post要比get方法安全性要高一些

請求方法	請求含義
GET	請求讀取一個web頁面
POST	附加一個命名資源(如web頁面)
DELETE	刪除web頁面
CONNECT	用於代理服務器
HEAD	請求讀取一個web頁面的頭部
PUT	請求存儲一個web頁面
TRACE	用於測試，要求服務器送回收到的請求
OPTION	查詢特定選項

4、 HTTP協議的響應(Response)

# HTTP響應也有四個部分組成，分別是： 狀態行--消息報頭--空行--響應正文

狀態行： 由http版本號，狀態碼，狀態消息組成
消息報頭： 用來講明客戶端要使用的一些附加信息
空行：----\r\n
響應正文： 服務器返回給客戶端的文本信息

'響應狀態碼詳解'
'印象中寫自動化測試腳本會常常用到狀態碼這個概念用來判斷網頁是否訪問成功'
狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操做
4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
5xx：服務器端錯誤--服務器未能實現合法的請求
常見狀態碼：

200 OK                        //客戶端請求成功
400 Bad Request               //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized              //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用 
403 Forbidden                 //服務器收到請求，可是拒絕提供服務
404 Not Found                 //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error     //服務器發生不可預期的錯誤
503 Server Unavailable        //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

5、HTTP協議完整工做流程

'我是抄的謝謝'
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

如下是 HTTP 請求/響應的步驟：

一、客戶端鏈接到Web服務器
一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。

二、發送HTTP請求
經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。

三、服務器接受請求並返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

四、釋放鏈接TCP鏈接
若connection 模式爲close，則服務器主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;

五、客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。

例如：在瀏覽器地址欄鍵入URL，按下回車以後會經歷如下流程：

一、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;

二、解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器創建TCP鏈接;

三、瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文做爲 TCP 三次握手的第三個報文的數據發送給服務器;

四、服務器對瀏覽器請求做出響應，並把對應的 html 文本發送給瀏覽器;

五、釋放 TCP鏈接;

六、瀏覽器將該 html 文本並顯示內容;

6、瀏覽器獲取數據後，頁面的請求信息詳解

'基本信息-----General'
Request URL: https://www.cnblogs.com/		# 請求的url
Request Method: GET		# 請求的方式
Status Code: 200 OK		# 請求返回的狀態以及狀態碼
Remote Address: 121.40.43.188:443	# 請求的遠程主機ip與端口
# 下列選項的做用是爲了控制請求頭中的referrer的內容
# strict...origin表示不容許refferrer信息顯示在從https網站到http網站的請求中
Referrer Policy: strict-origin-when-cross-origin



'請求頭部-----Request Header'
authority: www.cnblogs.com		# 請求的域名
method: GET		# 請求的方式
path: /		# 請求的地址和文件，此時訪問的是index文件
scheme: https		# 請求的協議
# accept爲請求的資源類型
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

accept-encoding: gzip, deflate, br		# 壓縮
accept-language: zh-CN,zh;q=0.9		# 字符類型
cache-control: max-age=0		# 緩存的時間
upgrade-insecure-requests: 1	# 升級
user-agent....		# 表示客戶端信息



'響應頭部-----Response Header'
age: 8		# 當代理服務器用本身緩存的實體去響應請求時，用該頭部代表該實體從產生到如今通過了多長時間
cache-control: public,max-age=30	# 表示此頁面(資源的有效時間)只能緩存30秒
content-encoding: gzip		# 壓縮的格式
content-type: text/html; charset=utf-8	# 文件類型和字符集
date: Mon, 09 Aug 2021 07:05:38 GMT		# 返回數據的時間
strict-transport-security: max-age=2592000; includeSubDomains; preload	# 此選項應該是禁止http連接
vary: Accept-Encoding	# 告訴代理服務器緩存兩種版本的資源：壓縮和非壓縮


'CDN服務器的經常使用參數'
#CDN緩存是否命中
x-cache: MISS TCP_MISS dirn:-2:-2
#緩存版本號
x-powered-by: PHP/7.1.21
#緩存時間
x-swift-cachetime: 0
#保存時間
x-swift-savetime: Sat, 03 Aug 2019 06:30:33 GMT

7、用戶訪問集羣架構流程(重要)

1. 客戶端發起http請求，請求會先到達防火牆

2. 防火牆識別用戶身份，正常的請求經過內部交換機經過tcp連接後端的負載均衡，傳遞用戶的http請求

3. 負載均衡收到請求，會根據請求的內容進行下發任務，經過tcp鏈接後端的web，轉發用戶的http請求

4. web接收到用戶的http請求後，會根據用戶請求的內容進行解析，解析分爲以下：
	靜態請求：web直接返回給負載均衡-->防火牆-->用戶
	動態請求：web向後端的動態程序創建tcp鏈接，將用戶的動態http請求傳遞至動態程序->由動態程序進行解析
	
5. 動態程序在解析的過程當中，若是碰到查詢數據庫請求，則優先與緩存創建tcp鏈接，併發起數據查詢操做

6. 若是緩存沒有對應的數據，動態程序再次向數據庫創建tcp鏈接，併發起查詢操做

7. 最後數據由 ： 數據庫->緩存->動態程序->web服務->負載均衡->防火牆->用戶

8、http其餘相關內容

# 1. SOA鬆耦合架構
	面向服務的架構(SOA)是一個組件模型，它將應用程序的不一樣功能單元(服務)進行拆分，並經過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺，操做系統和變成語言。這使得構建在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互
	'將一個服務拆分紅多個小型服務，方便每個小型服務進行迭代更新以及減緩請求壓力'
	'其中一個服務出現問題的話不會影響其餘服務的正常運行'
	'好比將登陸與註冊拆分，若是註冊服務器掛掉了，不會影響已經註冊的用戶正常登陸'
	
# 2. websocket協議
	(1) websocket是基於TCP的應用層協議，用於在C/S架構的應用中實現雙向通訊
	(2) 雖然websocket協議在創建鏈接時會使用http協議，但這並不意味着websocket是基於http實現的
	詳情請點擊----https://www.cnblogs.com/nuccch/p/10947256.html
	
# 3. http的請求頭之User-Agent
	User-Agent中文名爲用戶代理，他是一個特殊的字符串頭，主要用於可以讓服務器識別客戶端使用的操做系統、瀏覽器版本等內容
	

# 4. pv和uv的共同點和區別是什麼
	PV(訪問量): 即Page view---頁面瀏覽量或點擊量，用戶每次刷新即被計算一次
	UV(獨立訪客): 即Unique Visitor---訪問你網站的每個客戶端爲一個訪客，24小時內相同的客戶端只被計算一次
	'一個UV能夠有不少PV,一個PV也只能對應一個IP'

更多精彩內容請關注微信公衆號：新猿技術生態圈
更多精彩內容請關注微信公衆號：新猿技術生態圈
更多精彩內容請關注微信公衆號：新猿技術生態圈