http協議介紹，token和session原理

1.http協議

https://www.cnblogs.com/lauhp/p/8979393.html

1. 定義

http Hyper Text Transfer Protocol，超文本傳輸協議，基於tcp/ip的應用層協議，把超文本從服務器傳輸到客戶端的傳輸協議。默認使用80端口，可以修改。作用於客戶端--服務器架構上。由客戶端發起請求，服務器響應。

2. 工作原理

1. 建立從客戶端到服務器的TCP套接字連接
2. 客戶端發送http請求
3. 服務器接收請求，返回響應結果
4. 釋放tcp連接
5. 客戶端解析html內容

3. URI和URL的區別

URI，是uniform resource identifier，統一資源標識符，用來唯一的標識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個來URI來定位的
URI一般由三部組成：

• 訪問資源的命名機制

• 存放資源的主機名

• 資源自身的名稱，由路徑表示，着重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何locate這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上，特別是著名的Mosaic。
采用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。URL一般由三部組成：

• 協議(或稱為服務方式)

• 存有該資源的主機IP地址(有時也包括端口號)

• 主機資源的具體地址。如目錄和文件名等

4. 特點

• 無連接

  限制每次連接只處理一個請求，處理完成就斷開，這種方式可以節省傳輸時間，但是多個請求則需要多次建立連接(tcp連接三次握手)。http1.0默認connection是close，即無連接，http1.1默認是keepalive，由服務器決定保持長連接的時間和一次連接最大接收的請求數，達到其中一個條件，連接會斷開。使用長連接之后，客戶端、服務端怎么知道本次傳輸結束呢？兩部分：1. 判斷傳輸數據是否達到了Content-Length 指示的大小；2. 動態生成的文件沒有 Content-Length ，它是分塊傳輸（chunked），這時候就要根據Transfer-Encoding來判斷，chunked 編碼的數據在最后有一個空 chunked 塊，表明本次傳輸數據結束，詳見這里。什么是 chunked 分塊傳輸呢？

• 無狀態

  http協議對事務沒有記憶能力，下一次的請求跟上一次無關。這個特性導致每次請求開銷大。

• 靈活

  支持傳輸任意類型數據對象，由Content-type標記

• 支持B/S,C/S 模式

5. Http 請求

有四部分組成：請求行，請求頭，空行和請求主體/數據

• 請求行：請求方法和協議版本

  • GET

    獲取資源，安全和冪等（每次請求都返回一樣），請求數據在請求行，而不是在請求主體

    把請求數據追加到url，不安全，url長度有限制2083字節(2K+35)，導致get請求數據不能太長

  • POST

    獲取資源/更新資源，請求數據不會在url中展示，會把post的內容發送到表單去接收，處理。安全，長度不限

  • PUT

    上傳資源

  • DELETE

    刪除資源

  • HEAD

    類似get請求，但只返回響應頭

  • OPTIONS

    返回支持的請求方法

  • TRACE

    回顯服務器收到的請求，主要用於測試或診斷

  • CONNECT

    http1.1協議中預留給能夠將連接改為管道方式的代理服務器

  • PATCH

    對put的補充，用來對已知資源進行局部更新

• 請求頭：

Header	解釋	示例
Accept	指定客戶端能夠接收的內容類型	Accept: text/plain, text/html
Accept-Charset	瀏覽器可以接受的字符編碼集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。	Accept-Encoding: compress, gzip
Accept-Language	瀏覽器可接受的語言	Accept-Language: en,zh
Accept-Ranges	可以請求網頁實體的一個或者多個子范圍字段	Accept-Ranges: bytes
Authorization	HTTP授權的授權證書	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定請求和響應遵循的緩存機制	Cache-Control: no-cache
Connection	表示是否需要持久連接。（HTTP 1.1默認進行持久連接）	Connection: close（Http1.0默認時關閉，Http1.1默認是keep-alive）
Cookie	HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。	Cookie: $Version=1; Skin=new;
Content-Length	請求的內容長度	Content-Length: 348
Content-Type	請求的與實體對應的MIME信息	Content-Type: application/x-www-form-urlencoded
Date	請求發送的日期和時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	請求的特定的服務器行為	Expect: 100-continue
From	發出請求的用戶的Email	From: [e-mail]
Host	指定請求的服務器的域名和端口號	Host: www.zcmhi.com
If-Match	只有請求內容與實體相匹配才有效	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	如果請求的部分在指定時間之后被修改則請求成功，未被修改則返回304代碼	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果內容未改變返回304代碼，參數為服務器先前發送的Etag，與服務器回應的Etag比較判斷是否改變	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range	如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。參數也為Etag	If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	只在實體在指定時間之后未被修改才請求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制信息通過代理和網關傳送的時間	Max-Forwards: 10
Pragma	用來包含實現特定的指令	Pragma: no-cache
Proxy-Authorization	連接到代理的授權證書	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只請求實體的一部分，指定范圍	Range: bytes=500-999
Referer	先前網頁的地址，當前請求網頁緊隨其后,即來路	Referer: http://www.zcmhi.com/archives/71.html
TE	客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息	TE: trailers,deflate;q=0.5
Upgrade	向服務器指定某種傳輸協議以便服務器進行轉換（如果支持）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的內容包含發出請求的用戶信息	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中間網關或代理服務器地址，通信協議	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	關於消息實體的警告信息	Warn: 199 Miscellaneous warning

• 空行：最后一個請求頭后面是空行，通知服務器后面沒有請求頭了
• 請求數據

請求數據不在GET方法中使用，而是在POST方法中使用。POST方法適用於需要客戶填寫表單的場合。與請求數據相關的最常使用的請求頭是Content-Type和Content-Length。

6. Http響應

• 響應行

  HTTP狀態碼的英文為HTTP Status Code。狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。

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

  常見狀態代碼、狀態描述的說明如下。

  • 200 OK：客戶端請求成功。
  • 400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
  • 401 Unauthorized：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用。
  • 402 Payment required: 保留，未來使用
  • 403 Forbidden：服務器收到請求，但是拒絕提供服務。
  • 404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
  • 500 Internal Server Error：服務器發生不可預期的錯誤。
  • 501 Not Implemented: 服務器不支持請求的功能
  • 502 Bad Gateway: 作為網關或代理工作的服務器執行請求時接收到無效響應
  • 503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常，舉個例子：HTTP/1.1 200 OK（CRLF）。
  • 504 Gateway Timeout: 充當網關獲得代理的服務器未能及時從遠端獲取請求

• 響應頭

  Header	解釋	示例
  Accept-Ranges	表明服務器是否支持指定范圍請求及哪種類型的分段請求	Accept-Ranges: bytes
  Age	從原始服務器到代理緩存形成的估算時間（以秒計，非負）	Age: 12
  Allow	對某網絡資源的有效的請求行為，不允許則返回405	Allow: GET, HEAD
  Cache-Control	告訴所有的緩存機制是否可以緩存及哪種類型	Cache-Control: no-cache
  Content-Encoding	web服務器支持的返回內容壓縮編碼類型。	Content-Encoding: gzip
  Content-Language	響應體的語言	Content-Language: en,zh
  Content-Length	響應體的長度	Content-Length: 348
  Content-Location	請求資源可替代的備用的另一地址	Content-Location: /index.htm
  Content-MD5	返回資源的MD5校驗值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
  Content-Range	在整個返回體中本部分的字節位置	Content-Range: bytes 21010-47021/47022
  Content-Type	返回內容的MIME類型	Content-Type: text/html; charset=utf-8
  Date	原始服務器消息發出的時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
  ETag	請求變量的實體標簽的當前值	ETag: “737060cd8c284d8af7ad3082f209582d”
  Expires	響應過期的日期和時間	Expires: Thu, 01 Dec 2010 16:00:00 GMT
  Last-Modified	請求資源的最后修改時間	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
  Location	用來重定向接收方到非請求URL的位置來完成請求或標識新的資源	Location: http://www.zcmhi.com/archives/94.html
  Pragma	包括實現特定的指令，它可應用到響應鏈上的任何接收方	Pragma: no-cache
  Proxy-Authenticate	它指出認證方案和可應用到代理的該URL上的參數	Proxy-Authenticate: Basic
  refresh	應用於重定向或一個新的資源被創造，在5秒之后重定向（由網景提出，被大部分瀏覽器支持）	Refresh: 5; url=http://www.zcmhi.com/archives/94.html
  Retry-After	如果實體暫時不可取，通知客戶端在指定時間之后再次嘗試	Retry-After: 120
  Server	web服務器軟件名稱	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
  Set-Cookie	設置Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
  Trailer	指出頭域在分塊傳輸編碼的尾部存在	Trailer: Max-Forwards
  Transfer-Encoding	文件傳輸編碼	Transfer-Encoding:chunked
  Vary	告訴下游代理是使用緩存響應還是從原始服務器請求	Vary: *
  Via	告知代理客戶端響應是通過哪里發送的	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
  Warning	警告實體可能存在的問題	Warning: 199 Miscellaneous warning
  WWW-Authenticate	表明客戶端請求實體應該使用的授權方案	WWW-Authenticate: Basic

• 空行

• 響應主體

7. 授權與鑒權

https://www.cnblogs.com/nickjiang/p/9148136.html

cookie的特點：

1. cookie是一門客戶端緩存技術
2. cookie數據由服務器生成，發送給瀏覽器保存
3. cookie數據的格式：鍵值對
4. cookie數據過期機制：設置expire值

cookie是一門客戶端技術，一般是由服務器生成返回給瀏覽器客戶端來保存的，並且cookie是以鍵值對的形式保存在瀏覽器客戶端的，每一個cookie都會有名稱，值，過期時間...。cookie有很多使用場景，在項目中比較常見的有：

　　1.登錄記住用戶名

　　2.記錄用戶瀏覽記錄

　　...

上面應用中大家最熟悉的應該就是記住用戶名這個場景了，以京東網站的登錄功能為例，當我們登錄了一次京東，后面再去登錄頁面登錄的時候，會發現它會幫你回填之前的用戶名，這個場景就是通過cookie技術實現的

session

session的特點：

1. session是一門服務端會話緩存技術。
2. session由服務器端的web容器創建，保存在服務器端。
3. session保存數據：鍵值對形式
4. session過期：默認30分鍾

session是服務端的會話技術，當用戶登錄了系統，服務器端的web容器就會創建一個會話，此會話中可以保存登錄用戶的信息，並且也是以鍵值對的形式去保存的，現在大部分系統都是使用的session技術來做的鑒權（權限鑒定），即：當用戶登錄完了才可以訪問系統中的一些頁面和數據。

拓展1：session過期處理。

當服務器端的會話過期了，那么當你繼續發起請求的時候，因為你從客戶端帶過去的會話編號還是之前的那個，就會驗證不通過，就會提示你會話過期請重新登錄。

拓展2：token機制

app項目為例：
一般app項目都會基於一個token做鑒權。
因為此時客戶端不是瀏覽器，因此就沒有cookie這一說了。
當用戶登錄app時，服務器會響應回來一個token信息（一般都是返回的一串唯一的標識符，比如說uuid或其他）。
服務器端會將登錄用戶跟token（票據）保存一個映射關系，一般保存在redis或者表里面，服務器端響應回來的token會緩存在手機
的本地緩存里，后面手機去訪問app的其他頁面，就會帶着這個token去服務器做驗證，如果通過這個token能夠從redis找到登錄用戶信息
那么就認為你是已經登錄了的用戶。

token失效：
一段時間后，服務器端的token失效了，那么就會把此token跟用戶的映射關系從redis里刪掉，那么后面再來訪問的時候，根據你手機請求帶來的token
就匹配不上登錄用戶了，服務器就告訴客戶端，需要去做重新登錄了、