cookie、session、jwt

cookie是將用戶信息存在cookie中，但是不安全
session驗證是登錄成功后服務(wù)端將用戶信息持久化，將session_id設(shè)置在cookie中。每次請求都會帶上session_id，服務(wù)端根據(jù)session_id查出用戶數(shù)據(jù)。
好處：更安全，不會暴露cookie
缺點：如果服務(wù)向共享用戶信息，在一個頁面登錄另一個直接登錄就可以使用。則需要共享數(shù)據(jù)庫。
jwt是將用戶的登錄信息經(jīng)過加密設(shè)置過期時間生產(chǎn)token返回給瀏覽器，每次請求都會帶上token。服務(wù)端直接解析。
好處：不需要持久化，無狀態(tài)。
缺點：暴露在每次請求中，會不安全

cookie跨域

path跨域
http://127.0.0.2:3000/server1/a.html的cookie在http://127.0.0.2:4000/server2/b.html取不到，因為cookie跨域了。
設(shè)置document.cookie= 'name=kimi;path=/';設(shè)置頂級path。則下面的server1和server2都可以取到

domain跨域
http://www.kimi.com:3000/a.html和http://www.yo.kimi.com:3000/b.html獲取不到。
設(shè)置document.cookie= 'name=kimi;domain=kimi.com';設(shè)置頂級domain，則下面的三級域名也可以取到

http://www.yo.kimi.com com：頂級域 kimi.com 一級域名 yo.kimi.com 二級域名 www.yo.kimi.com 三級域名

輸入網(wǎng)址到現(xiàn)實的過程

1.域名解析（判斷url中是否有非法字符，并轉(zhuǎn)義）
2.查看緩存
3.DNS解析，獲取IP地址
4.TCP連接建立
5.發(fā)送報文請求
6.響應(yīng)報文數(shù)據(jù)
7.瀏覽器解析數(shù)據(jù)
8.渲染

瀏覽器緩存

強(qiáng)緩存：滿足強(qiáng)緩存期間內(nèi)，會直接從本地讀取。狀態(tài)碼 200
1、Expires：http1.0, 表示過期時間，Expires:Sat, 09 Jun 2018 08:13:56 GMT,但是如果客戶端和服務(wù)端時間不一致則會有問題
2、Cache-control（比expires優(yōu)先）：http1.1,設(shè)置緩存的設(shè)置，常見的設(shè)置如下：

max-age: 強(qiáng)緩存的有效時間，單位秒 max-age=30672000
no-cache：使用協(xié)商緩存，不管強(qiáng)制緩存。
no-store：強(qiáng)制關(guān)閉緩存。

from disk和memory區(qū)別。關(guān)閉瀏覽器memory就沒了。一般css放到disk中，js、圖片在memory，因為js要執(zhí)行。如果在disk還需要取到memory

協(xié)商緩存：發(fā)送請求給服務(wù)，如果文件沒有改變會讓瀏覽器讀本地緩存，狀態(tài)碼304，此時如果有強(qiáng)緩存設(shè)置又會進(jìn)入強(qiáng)緩存時間，如果修改了則重新返回
1、用時間比對：Last-modified If-Modified-Since （http1.0）
服務(wù)端會返回Last-modified字段表示最新的更新時間給客戶端保存
客戶端會使用If-Modified-Since帶上更新時間給服務(wù)端，如果服務(wù)端這段期間沒有更新，用緩存
單位是秒，所以更新頻率在1秒之內(nèi)級別則會有文件不一致
2、用內(nèi)容比對：ETag If-None-Match（http1.1）優(yōu)先級更高
服務(wù)端返回文件的唯一標(biāo)識ETag給客戶端保存
客戶端會使用If-None-Match帶上文件hash給服務(wù)對比，如果一致則用緩存

get和post方法有什么區(qū)別

從緩存的角度，GET 請求會被瀏覽器主動緩存下來，留下歷史記錄，而 POST 默認(rèn)不會。
從編碼的角度，GET 只能進(jìn)行 URL 編碼，只能接收 ASCII 字符，而 POST 沒有限制。
從參數(shù)的角度，GET 一般放在 URL 中，因此不安全，POST 放在請求體中，更適合傳輸敏感信息。

HTTP狀態(tài)碼

1xx: 表示目前是協(xié)議處理的中間狀態(tài)，還需要后續(xù)操作。

101 Switching Protocols。在HTTP升級為WebSocket的時候，如果服務(wù)器同意變更，就會發(fā)送狀態(tài)碼 101。

2xx: 表示成功狀態(tài)。

200 OK是見得最多的成功狀態(tài)碼。通常在響應(yīng)體中放有數(shù)據(jù)。
204 No Content含義與 200 相同，但響應(yīng)頭后沒有 body 數(shù)據(jù)。
206 Partial Content顧名思義，表示部分內(nèi)容，它的使用場景為 HTTP 分塊下載和斷點續(xù)傳，當(dāng)然也會帶上相應(yīng)的響應(yīng)頭字段Content-Range。

3xx: 重定向狀態(tài)，資源位置發(fā)生變動，需要重新請求。

301 Moved Permanently即永久重定向，對應(yīng)著302 Found，即臨時重定向。
比如你的網(wǎng)站從 HTTP 升級到了 HTTPS 了，以前的站點再也不用了，應(yīng)當(dāng)返回301，這個時候瀏覽器默認(rèn)會做緩存優(yōu)化，在第二次訪問的時候自動訪問重定向的那個地址。
302如果只是暫時不可用，那么直接返回302即可，和301不同的是，瀏覽器并不會做緩存優(yōu)化。
304 Not Modified: 當(dāng)協(xié)商緩存命中時會返回這個狀態(tài)碼。詳見瀏覽器緩存

4xx: 請求報文有誤。

400 Bad Request: 開發(fā)者經(jīng)常看到一頭霧水，只是籠統(tǒng)地提示了一下錯誤，并不知道哪里出錯了。
401鑒權(quán)失敗
403 Forbidden: 這實際上并不是請求報文出錯，而是服務(wù)器禁止訪問，原因有很多，比如法律禁止、信息敏感。
404 Not Found: 資源未找到，表示沒在服務(wù)器上找到相應(yīng)的資源。
405 Method Not Allowed: 請求方法不被服務(wù)器端允許。
406 Not Acceptable: 資源無法滿足客戶端的條件。
408 Request Timeout: 服務(wù)器等待了太長時間。
409 Conflict: 多個請求發(fā)生了沖突。
413 Request Entity Too Large: 請求體的數(shù)據(jù)過大。
414 Request-URI Too Long: 請求行里的 URI 太大。
429 Too Many Request: 客戶端發(fā)送的請求過多。
431 Request Header Fields Too Large請求頭的字段內(nèi)容太大。

5xx: 服務(wù)器端發(fā)生錯誤。

500 Internal Server Error: 僅僅告訴你服務(wù)器出錯了，出了啥錯咱也不知道。
501 Not Implemented: 表示客戶端請求的功能還不支持。
502 Bad Gateway: 服務(wù)器自身是正常的，但訪問的時候出錯了，啥錯誤咱也不知道。
503 Service Unavailable: 表示服務(wù)器當(dāng)前很忙，暫時無法響應(yīng)服務(wù)。

Accept字段

1、數(shù)據(jù)格式 Content-Type

text：text/html, text/plain, text/css 等
image: image/gif, image/jpeg, image/png 等
audio/video: audio/mpeg, video/mp4 等
application: application/json, application/javascript, application/pdf, application/octet-stream

2、壓縮方式

// 發(fā)送端
Content-Encoding: gzip
// 接收端
Accept-Encoding: gizp

3、支持語言

// 發(fā)送端
Content-Language: zh-CN, zh, en
// 接收端
Accept-Language: zh-CN, zh, en

4、字符集

// 發(fā)送端
Content-Type: text/html; charset=utf-8
// 接收端
Accept-Charset: charset=utf-8

HTTP 2.0

1、頭部壓縮
2、多路復(fù)用（二進(jìn)制分幀）

HTTPS

https = http + TLS
TLS:加密協(xié)議

（1）客戶使用https的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。

（2）Web服務(wù)器收到客戶端請求后，會將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器根據(jù)雙方同意的安全等級，建立會話密鑰(對稱加密的公鑰)，然后利用證書的公鑰將會話密鑰加密，并傳送給網(wǎng)站。（非對稱加密）
（4）Web服務(wù)器利用自己的私鑰解密出會話密鑰。（非對稱加密解密出對稱加密的公鑰）
（5）Web服務(wù)器利用會話密鑰加密與客戶端之間的通信。（對稱加密）

image.png

HTTPS和HTTP不同

1、http是明文傳輸，https是加密傳輸，相對更安全
2、http默認(rèn)端口80，https默認(rèn)443

HTTPS的不足

1、連接復(fù)雜會造成多余的連接損耗，耗費(fèi)流量
2、證書需要多余的成本買

TCP/UDP協(xié)議

TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。在計算機(jī)網(wǎng)絡(luò)的OSI模型中，它完成第四層傳輸層所指定的功能。

UDP是一種簡單的面向數(shù)據(jù)報、面向無連接、不可靠的通信協(xié)議，位于OSI模型的傳輸層。在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。

TCP三次握手（面向連接）

1、客戶端先將SYN標(biāo)志置為1，表示連接。并發(fā)送包的序號seq（一般隨機(jī)）
2、服務(wù)端相應(yīng)后發(fā)送ACK=1標(biāo)志表示確認(rèn)接受到，也發(fā)送SYN標(biāo)志發(fā)起連接。并且發(fā)送已經(jīng)接受到的包序號ack，和響應(yīng)發(fā)出的包序號seq
3、客戶端接收到發(fā)送ACK標(biāo)志表示確認(rèn)接受，并且發(fā)送已經(jīng)收到的包序號ack（等于之前接受的seq+1）

image.png

TCP重傳

TCP如果超過最大字節(jié)數(shù)限制，會根據(jù)包的大小進(jìn)行分包，并且每個包上都添加上TCP頭。

image.png

image.png

滑動窗口

如果在等待服務(wù)端返回ACK的期間什么都不做，那么就比較浪費(fèi)了。所以TCP采用滑動窗口機(jī)制來管理發(fā)送和ACK號的操作，就是不需要等待ACK返回，直接發(fā)送下一個包，這也是提高TCP效率的方式。

這樣帶來的問題是：發(fā)送方有可能發(fā)送的太快超過了接收方處理的速度，接收方緩沖區(qū)有可能溢出

解決辦法：就是接收方會在收到包后，會通過 TCP 頭部中的窗口字段將自己能接收的數(shù)據(jù)量告知發(fā)送方。發(fā)送方會保存。這樣一來，發(fā)送方就不會發(fā)送過多的數(shù)據(jù)，導(dǎo)致超出接收方的處理能力了。接收方處理程序每次從緩沖區(qū)取走包時都需要發(fā)送一個剩下的窗口大小，而且這個請求不會立即發(fā)送，會稍等一下看看有沒有需要返回的ACK信號一起合并發(fā)送，提高效率。所以提高窗口大小是TCP調(diào)優(yōu)的方式之一

image.png

一個窗口期如果之前有錯誤會導(dǎo)致整個窗口數(shù)據(jù)重發(fā)

image.png

TCP擁塞控制

上面的窗口機(jī)制是為了控制流量的，但是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，讓網(wǎng)絡(luò)中的路由器或者鏈路不至于過載。會有擁塞控制機(jī)制有慢啟動和擁塞避免兩種算法
慢啟動：不是一次全部發(fā)送，而是根據(jù)網(wǎng)絡(luò)狀況動態(tài)的緩慢增加。慢啟動只是起點低，增長的并不是很慢，1-2-4-8-16。。。
擁塞避免：剛開始發(fā)送使用慢啟動算法，但是會設(shè)定一個閾值，等發(fā)送超出閾值后，呈加法增加而不是倍數(shù)，1-2-4-8-9-10-11。。。

接受響應(yīng)消息

瀏覽器在委托協(xié)議棧發(fā)送請求消息之后，會調(diào)用 read 程序來獲取響應(yīng)消息。協(xié)議棧會將數(shù)據(jù)暫存到接收緩沖區(qū)中，但這個時候請求消息剛剛發(fā)送出去，響應(yīng)消息可能還沒返回，協(xié)議棧會將應(yīng)用程序的委托的工作暫時掛起 ，等服務(wù)器返回的響應(yīng)消息到達(dá)之后再繼續(xù)執(zhí)行接收操作

接著協(xié)議棧會檢查收到的數(shù)據(jù)塊和 TCP 頭部的內(nèi)容，判斷是否有數(shù)據(jù)丟失，如果沒有問題則返回 ACK 號。然后，協(xié)議棧將數(shù)據(jù)塊暫存到接收緩沖區(qū)中，并將數(shù)據(jù)塊按順序連接起來還原出原始的數(shù)據(jù)，最后將數(shù)據(jù)交給應(yīng)用程序。具體來說，協(xié)議棧會將接收到的數(shù)據(jù)復(fù)制到應(yīng)用程序指定的內(nèi)存地址中，然后將控制流程交回應(yīng)用程序。將數(shù)據(jù)交給應(yīng)用程序之后，協(xié)議棧還需要找到合適的時機(jī)向發(fā)送方發(fā)送窗口更新。

數(shù)據(jù)發(fā)送完畢 -- 斷開

這就是TCP的四次揮手

image.png

為什么TCP連接需要三次握手，而斷開需要四次？
答：因為斷開不是實時的，服務(wù)端發(fā)起斷開，客戶端有可能還需要等到數(shù)據(jù)處理完畢。而握手期間，SYN連接和ACK確認(rèn)信號可以一起返回給客戶端。所以只需要三次

UDP

UDP 不需要建立和斷開連接的步驟，只要在從應(yīng)用程序獲取的數(shù)據(jù)前面加上 UDP 頭部，然后交給 IP 進(jìn)行發(fā)送就可以了，遇到錯誤或者丟包也一概不管。

域名解析、音視頻一般采用UDP，因為域名解析包小，音視頻需要保證不延遲，丟幾幀包無所謂