cookie县踢、session、jwt

cookie是將用戶信息存在cookie中伟件，但是不安全
session驗(yàn)證是登錄成功后服務(wù)端將用戶信息持久化硼啤，將session_id設(shè)置在cookie中。每次請(qǐng)求都會(huì)帶上session_id斧账，服務(wù)端根據(jù)session_id查出用戶數(shù)據(jù)谴返。
好處：更安全，不會(huì)暴露cookie
缺點(diǎn)：如果服務(wù)向共享用戶信息咧织，在一個(gè)頁面登錄另一個(gè)直接登錄就可以使用嗓袱。則需要共享數(shù)據(jù)庫。
jwt是將用戶的登錄信息經(jīng)過加密設(shè)置過期時(shí)間生產(chǎn)token返回給瀏覽器习绢，每次請(qǐng)求都會(huì)帶上token渠抹。服務(wù)端直接解析蝙昙。
好處：不需要持久化，無狀態(tài)梧却。
缺點(diǎn)：暴露在每次請(qǐng)求中奇颠，會(huì)不安全

cookie跨域

path跨域
http://127.0.0.2:3000/server1/a.html的cookie在http://127.0.0.2:4000/server2/b.html取不到，因?yàn)閏ookie跨域了放航。
設(shè)置document.cookie= 'name=kimi;path=/';設(shè)置頂級(jí)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è)置頂級(jí)domain广鳍，則下面的三級(jí)域名也可以取到

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

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

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

瀏覽器緩存

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

max-age: 強(qiáng)緩存的有效時(shí)間狈涮，單位秒 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溅话，因?yàn)閖s要執(zhí)行晓锻。如果在disk還需要取到memory

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

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

從緩存的角度以躯，GET 請(qǐng)求會(huì)被瀏覽器主動(dòng)緩存下來槐秧，留下歷史記錄，而 POST 默認(rèn)不會(huì)。
從編碼的角度刁标，GET 只能進(jìn)行 URL 編碼颠通，只能接收 ASCII 字符，而 POST 沒有限制命雀。
從參數(shù)的角度蒜哀，GET 一般放在 URL 中，因此不安全吏砂，POST 放在請(qǐng)求體中撵儿，更適合傳輸敏感信息。

HTTP狀態(tài)碼

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

101 Switching Protocols。在HTTP升級(jí)為WebSocket的時(shí)候匈织，如果服務(wù)器同意變更浪默，就會(huì)發(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)容满钟，它的使用場(chǎng)景為 HTTP 分塊下載和斷點(diǎn)續(xù)傳胜榔，當(dāng)然也會(huì)帶上相應(yīng)的響應(yīng)頭字段Content-Range。

3xx: 重定向狀態(tài)湃番，資源位置發(fā)生變動(dòng)夭织，需要重新請(qǐng)求。

301 Moved Permanently即永久重定向吠撮，對(duì)應(yīng)著302 Found尊惰，即臨時(shí)重定向。
比如你的網(wǎng)站從 HTTP 升級(jí)到了 HTTPS 了泥兰，以前的站點(diǎn)再也不用了择浊，應(yīng)當(dāng)返回301，這個(gè)時(shí)候?yàn)g覽器默認(rèn)會(huì)做緩存優(yōu)化逾条，在第二次訪問的時(shí)候自動(dòng)訪問重定向的那個(gè)地址琢岩。
302如果只是暫時(shí)不可用，那么直接返回302即可师脂，和301不同的是担孔，瀏覽器并不會(huì)做緩存優(yōu)化江锨。
304 Not Modified: 當(dāng)協(xié)商緩存命中時(shí)會(huì)返回這個(gè)狀態(tài)碼。詳見瀏覽器緩存

4xx: 請(qǐng)求報(bào)文有誤糕篇。

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

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

500 Internal Server Error: 僅僅告訴你服務(wù)器出錯(cuò)了挟憔，出了啥錯(cuò)咱也不知道。
501 Not Implemented: 表示客戶端請(qǐng)求的功能還不支持烟号。
502 Bad Gateway: 服務(wù)器自身是正常的绊谭，但訪問的時(shí)候出錯(cuò)了，啥錯(cuò)誤咱也不知道汪拥。
503 Service Unavailable: 表示服務(wù)器當(dāng)前很忙达传，暫時(shí)無法響應(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ù)器收到客戶端請(qǐng)求后邓厕，會(huì)將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端。
（3）客戶端的瀏覽器根據(jù)雙方同意的安全等級(jí)扁瓢，建立會(huì)話密鑰(對(duì)稱加密的公鑰)详恼，然后利用證書的公鑰將會(huì)話密鑰加密，并傳送給網(wǎng)站引几。（非對(duì)稱加密）
（4）Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰昧互。（非對(duì)稱加密解密出對(duì)稱加密的公鑰）
（5）Web服務(wù)器利用會(huì)話密鑰加密與客戶端之間的通信。（對(duì)稱加密）

image.png

HTTPS和HTTP不同

1伟桅、http是明文傳輸敞掘，https是加密傳輸，相對(duì)更安全
2贿讹、http默認(rèn)端口80渐逃，https默認(rèn)443

HTTPS的不足

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

TCP/UDP協(xié)議

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

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

TCP三次握手（面向連接）

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

image.png

TCP重傳

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

image.png

image.png

滑動(dòng)窗口

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

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

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

image.png

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

image.png

TCP擁塞控制

上面的窗口機(jī)制是為了控制流量的彩匕，但是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中腔剂，讓網(wǎng)絡(luò)中的路由器或者鏈路不至于過載。會(huì)有擁塞控制機(jī)制有慢啟動(dòng)和擁塞避免兩種算法
慢啟動(dòng)：不是一次全部發(fā)送推掸，而是根據(jù)網(wǎng)絡(luò)狀況動(dòng)態(tài)的緩慢增加桶蝎。慢啟動(dòng)只是起點(diǎn)低驻仅，增長(zhǎng)的并不是很慢谅畅，1-2-4-8-16。噪服。毡泻。
擁塞避免：剛開始發(fā)送使用慢啟動(dòng)算法，但是會(huì)設(shè)定一個(gè)閾值粘优，等發(fā)送超出閾值后仇味，呈加法增加而不是倍數(shù)呻顽，1-2-4-8-9-10-11。丹墨。廊遍。

接受響應(yīng)消息

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

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

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

這就是TCP的四次揮手

image.png

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

UDP

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

域名解析验辞、音視頻一般采用UDP，因?yàn)橛蛎馕霭『吧溃粢曨l需要保證不延遲跌造，丟幾幀包無所謂