OSI 七層模型：應(yīng)用層角钩、表示層、會(huì)話層事秀、傳輸層彤断、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層易迹、物理層

osi七層模型.png

TCP/IP 四層模型：應(yīng)用層宰衙、傳輸層、網(wǎng)絡(luò)層睹欲、網(wǎng)絡(luò)接口層
應(yīng)用層位于傳輸層之上供炼，主要提供兩個(gè)終端設(shè)備上的應(yīng)用程序之間信息交換的服務(wù)一屋，它定義了信息交換的格式，消息會(huì)交給下一層傳輸層來傳輸袋哼。
傳輸層的主要任務(wù)就是負(fù)責(zé)向兩臺(tái)終端設(shè)備進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)
網(wǎng)絡(luò)層負(fù)責(zé)為路由和尋址冀墨。
運(yùn)輸層主要使用以下兩種協(xié)議：
傳輸控制協(xié)議 TCP（Transmisson Control Protocol）--提供面向連接的，可靠的數(shù)據(jù)傳輸服務(wù)涛贯。
用戶數(shù)據(jù)協(xié)議 UDP（User Datagram Protocol）--提供無連接的诽嘉，盡最大努力的數(shù)據(jù)傳輸服務(wù)（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/p>

HTTP 協(xié)議 全稱超文本傳輸協(xié)議 HTTP 是一個(gè)無狀態(tài)（stateless）協(xié)議，也就是說服務(wù)器不維護(hù)任何有關(guān)客戶端過去所發(fā)請(qǐng)求的消息弟翘。HTTP 是應(yīng)用層協(xié)議虫腋，它以 TCP（傳輸層）作為底層協(xié)議，默認(rèn)端口為 80

HTTPS協(xié)議是基于 HTTP 的稀余，也是用 TCP 作為底層協(xié)議悦冀，并額外使用SSL/TLS 協(xié)議用作加密和安全認(rèn)證。默認(rèn)端口號(hào)是 443睛琳。SSL/TLS 的核心要素是非對(duì)稱加密盒蟆。

HTTP和HTTPS有什么區(qū)別？

1师骗、端口不同：HTTP使用的是80端口历等，HTTPS使用443端口；
2丧凤、HTTP（超文本傳輸協(xié)議）信息是明文傳輸募闲，HTTPS運(yùn)行在SSL之上，添加了加密和認(rèn)證機(jī)制愿待，更加安全浩螺；
3、HTTPS由于加密解密會(huì)帶來更大的CPU和內(nèi)存開銷
4仍侥、HTTPS通信需要證書要出，一般需要向證書頒發(fā)機(jī)構(gòu)（CA）購(gòu)買

HTTPS數(shù)據(jù)傳輸流程:

1、客戶端發(fā)起https請(qǐng)求农渊，連接到服務(wù)端的443端口
2患蹂、服務(wù)端采用的https有一套CA機(jī)構(gòu)的數(shù)字證書，證書的本質(zhì)是公鑰（發(fā)給任何人）和私鑰（服務(wù)端保留）
3砸紊、服務(wù)端將含有公鑰的證書傳遞給客戶端传于，證書中包含了很多信息
4、客戶端解析證書醉顽，由客戶端的TLS完成沼溜，首先會(huì)驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)游添，過期時(shí)間等系草。如果有異常通熄，就會(huì)彈出警告信息。證書沒問題后會(huì)隨機(jī)生成隨機(jī)值（這個(gè)很重要找都，用于對(duì)稱加密）唇辨，然后使用第三步中的證書對(duì)這個(gè)隨機(jī)值進(jìn)行非對(duì)稱加密
5、將證書非對(duì)稱加密后的隨機(jī)值傳到服務(wù)器
6能耻、服務(wù)器使用私鑰對(duì)其進(jìn)行非對(duì)稱解密后赏枚，得到客戶端的隨機(jī)值，然后把內(nèi)容通過該隨機(jī)值進(jìn)行對(duì)稱加密
7晓猛、服務(wù)端將對(duì)稱加密后的信息發(fā)給客戶端
8嗡贺、客戶端用之前的生成的隨機(jī)值來進(jìn)行對(duì)稱解密，獲取內(nèi)容明文

HTTP響應(yīng)狀態(tài)碼

1xx ? ? ? ? ? ? 接受的請(qǐng)求正在處理
2xx ? ? ? ? ? ? 請(qǐng)求正常處理完畢
3xx ? ? ? ? ? ? 需要進(jìn)行附加操作以完成請(qǐng)求
4xx ? ? ? ? ? ? 客戶端請(qǐng)求出錯(cuò)鞍帝，服務(wù)器無法處理請(qǐng)求
5xx ? ? ? ? ? ? 服務(wù)器處理請(qǐng)求出錯(cuò)

常見狀態(tài)碼：

200 OK：表示從客戶端發(fā)送給服務(wù)器的請(qǐng)求被正常處理并返回；
204 No Content：表示客戶端發(fā)送給客戶端的請(qǐng)求得到了成功處理,沒有資源可以返回
301 Moved Permanently：永久性重定向煞茫，表示請(qǐng)求的資源被分配了新的URL帕涌，之后應(yīng)使用更改的URL；
302 Found：臨時(shí)性重定向续徽，表示請(qǐng)求的資源被分配了新的URL蚓曼，希望本次訪問使用新的URL；
400 Bad Request：表示請(qǐng)求報(bào)文中存在語法錯(cuò)誤钦扭；
401 Unauthorized：未經(jīng)許可纫版，需要通過HTTP認(rèn)證；
403 Forbidden：服務(wù)器拒絕該次訪問（訪問權(quán)限出現(xiàn)問題）
404 Not Found：表示服務(wù)器上無法找到請(qǐng)求的資源
500 Inter Server Error：表示服務(wù)器在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤
503 Server Unavailable：表示服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)客情，無法處理請(qǐng)求

200：“好的”其弊，
204:“無內(nèi)容”，
301:“永久移動(dòng)”膀斋，
302:“找到”梭伐，
307:“臨時(shí)重定向”，
400:“錯(cuò)誤請(qǐng)求”
401:“未授權(quán)”仰担，
403:“禁止”糊识，
500:“內(nèi)部服務(wù)器錯(cuò)誤”
503:“服務(wù)不可用”

HTTP1.0、 HTTP1.1摔蓝、HTTP2.0 區(qū)別：

HTTP1.0：
瀏覽器與服務(wù)器只保持短暫的連接赂苗，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接

HTTP1.1：
1、Http1.1增加了host字段
2贮尉、引入了持久連接拌滋，即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用
在同一個(gè)TCP連接里面绘盟，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求
雖然允許復(fù)用TCP連接鸠真，但是同一個(gè)TCP連接里面悯仙，所有的數(shù)據(jù)通信是按次序進(jìn)行的，服務(wù)器只有處理完一個(gè)請(qǐng)求吠卷，才會(huì)接著處理下一個(gè)請(qǐng)求锡垄。如果前面的處理特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著
3祭隔、新增了一些請(qǐng)求方法
4货岭、新增了一些請(qǐng)求頭和響應(yīng)頭

HTTP2.0：
1、采用二進(jìn)制格式而非文本格式
2疾渴、完全多路復(fù)用千贯，而非有序并阻塞的、只需一個(gè)連接即可實(shí)現(xiàn)并行
3搞坝、使用報(bào)頭壓縮搔谴，降低開銷
4、服務(wù)器推送

SMTP 協(xié)議只負(fù)責(zé)郵件的發(fā)送桩撮，真正負(fù)責(zé)接收的協(xié)議是POP3/IMAP

FTP 協(xié)議 主要提供文件傳輸服務(wù)敦第，基于 TCP 實(shí)現(xiàn)可靠的傳輸

TCP 3 次握手

三次握手.png

TCP 為什么需要 3 次握手, 為什么 2 次不行, 4 次呢?

TCP 的三次握手是為了保證數(shù)據(jù)的可靠傳輸?shù)模琓CP 是全雙工的協(xié)議店量，也就是說通過 TCP 協(xié)議發(fā)送的消息是要得到回復(fù)的芜果，所以說對(duì)于需要建立 TCP 連接的兩端來說，每一端都需要進(jìn)行一來一回的確認(rèn)融师，這就進(jìn)行三次握手右钾。
1、A 給 B 發(fā)送需要建立連接的請(qǐng)求;
2旱爆、B 給 A 發(fā)送可以建立連接的回復(fù)舀射；
3、A 給 B 發(fā)送確認(rèn)收到回復(fù)的信息疼鸟；
如果只進(jìn)行二次握手：
1后控、A 給 B 發(fā)送需要建立連接的請(qǐng)求;
2、B 給 A 發(fā)送可以建立連接的回復(fù)空镜；
這樣看似沒有什么問題浩淘，但是這樣還是不行的，因?yàn)榈诙挝帐值臅r(shí)候 B 不知道自己發(fā)送給 A 的應(yīng)答包是否可以到達(dá) A吴攒；B 只知道了 A 能發(fā)张抄，并不知道 A 是否能收；所以這樣的連接還是不可靠的洼怔。
如果進(jìn)行四次握手：
1署惯、A 給 B 發(fā)送需要建立連接的請(qǐng)求;
2、B 給 A 發(fā)送可以建立連接的回復(fù)镣隶；
3极谊、A 給 B 發(fā)送確認(rèn)收到回復(fù)的信息诡右；
4、B 給 A 發(fā)送確認(rèn)收到確認(rèn)的信息轻猖；
當(dāng)進(jìn)行到第二步的時(shí)候 B 在等待 A 的確認(rèn)信息帆吻，只有等到這個(gè)消息，B 才能確認(rèn)建立連接咙边，這樣其實(shí)就夠了猜煮，多了反而會(huì)浪費(fèi)資源。

第 2 次握手傳回了 ACK败许，為什么還要傳回 SYN王带？

接收端傳回發(fā)送端所發(fā)送的 ACK 是為了告訴客戶端，我接收到的信息確實(shí)就是你所發(fā)送的信號(hào)了市殷，而回傳 SYN 則是為了建立并確認(rèn)由客戶端發(fā)起帶有SYN的連接愕撰。

為什么要四次揮手

四次揮手.png

tcp是全雙工的協(xié)議、因此雙發(fā)都會(huì)向?qū)Ψ桨l(fā)送協(xié)議醋寝。
四次揮手如下：
1盟戏、客戶端執(zhí)行主動(dòng)關(guān)閉，發(fā)送 fin的包（fin）甥桂，表示客戶端的數(shù)據(jù)發(fā)送完畢。
2邮旷、服務(wù)端執(zhí)行被動(dòng)關(guān)閉黄选，發(fā)送確認(rèn) ask 包。
3婶肩、服務(wù)端給客戶端發(fā)送 fin办陷，告訴客戶端我也要關(guān)閉。
4律歼、客戶端確認(rèn)服務(wù)端的ask的包民镜。
這個(gè)因?yàn)榈谝淮螕]手表示客戶端發(fā)送了一個(gè)fin的包，表示客戶端已發(fā)送數(shù)據(jù)完畢险毁，但是服務(wù)端這個(gè)時(shí)候可能還有數(shù)據(jù)沒有發(fā)送完成制圈，先發(fā)送給客戶端一個(gè)ask的包，等待自己的數(shù)據(jù)發(fā)送完成才能向客戶端發(fā)送一個(gè) fin的包畔况，表示自己的數(shù)據(jù)也已發(fā)送完成鲸鹦。這樣中間就必須為兩次來發(fā)送ask和fin。

TCP 一般用于文件傳輸跷跪、發(fā)送和接收郵件馋嗜、遠(yuǎn)程登錄等場(chǎng)景。

UDP 一般用于QQ 語音吵瞻、 QQ 視頻 葛菇、直播等等甘磨。

tcp-vs-udp.jpg

TCP 協(xié)議如何保證可靠傳輸

1、TCP 給發(fā)送的每一個(gè)包進(jìn)行編號(hào)眯停，接收方對(duì)數(shù)據(jù)包進(jìn)行排序济舆，把有序數(shù)據(jù)傳送給應(yīng)用層。
2庵朝、校驗(yàn)和： TCP 將保持它首部和數(shù)據(jù)的檢驗(yàn)和吗冤。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測(cè)數(shù)據(jù)在傳輸過程中的任何變化九府。
3椎瘟、TCP 的接收端會(huì)丟棄重復(fù)的數(shù)據(jù)。
4侄旬、流量控制：TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制
5肺蔚、擁塞控制： 當(dāng)網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送儡羔。
6宣羊、ARQ 協(xié)議： 也是為了實(shí)現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送汰蜘，等待對(duì)方確認(rèn)仇冯。在收到確認(rèn)后再發(fā)下一個(gè)分組。
7族操、超時(shí)重傳： 當(dāng) TCP 發(fā)出一個(gè)段后苛坚，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段色难。如果不能及時(shí)收到一個(gè)確認(rèn)泼舱，將重發(fā)這個(gè)報(bào)文段。

ARQ 包括停止等待 ARQ 協(xié)議和連續(xù) ARQ 協(xié)議枷莉。

停止等待 ARQ 協(xié)議是為了實(shí)現(xiàn)可靠傳輸?shù)慕筷迹幕驹砭褪敲堪l(fā)完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)（回復(fù) ACK）笤妙。如果過了一段時(shí)間（超時(shí)時(shí)間后）冒掌，還是沒有收到 ACK 確認(rèn)，說明沒有發(fā)送成功蹲盘，需要重新發(fā)送宋渔，直到收到確認(rèn)后再發(fā)下一個(gè)分組。
連續(xù) ARQ 協(xié)議可提高信道利用率辜限。發(fā)送方維持一個(gè)發(fā)送窗口皇拣，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對(duì)方確認(rèn)。接收方一般采用累積確認(rèn)氧急，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)颗胡，表明到這個(gè)分組為止的所有分組都已經(jīng)正確收到了。

擁塞控制

TCP 的擁塞控制采用了四種算法吩坝，即 慢開始 毒姨、 擁塞避免 、快重傳 和 快恢復(fù)钉寝。在網(wǎng)絡(luò)層也可以使路由器采用適當(dāng)?shù)姆纸M丟棄策略（如主動(dòng)隊(duì)列管理 AQM）弧呐，以減少網(wǎng)絡(luò)擁塞的發(fā)生。

在瀏覽器中輸入url地址->>顯示主頁的過程

1嵌纲、在瀏覽器查找域名的IP地址（DNS解析）
2俘枫、瀏覽器會(huì)向web服務(wù)器發(fā)送一個(gè)HTTP請(qǐng)求（cookie會(huì)隨著請(qǐng)求發(fā)送給服務(wù)器）
3、web服務(wù)器處理收到的請(qǐng)求（處理 請(qǐng)求逮走、參數(shù)鸠蚪、cookie，然后生成一個(gè)HTML響應(yīng)）
4师溅、web服務(wù)器發(fā)回一個(gè)HTML響應(yīng)
5茅信、瀏覽器開始顯示HTML

HTTP 是不保存狀態(tài)的協(xié)議, 如何保存用戶狀態(tài)?

Session 的主要作用就是通過服務(wù)端記錄用戶的狀態(tài)
Cookie 一般用來保存用戶信息
Cookie 數(shù)據(jù)保存在客戶端(瀏覽器端)，Session 數(shù)據(jù)保存在服務(wù)器端墓臭。
用Session 蘸鲸，將Session 存放在服務(wù)器端。通過在Cookie 中存儲(chǔ)實(shí)現(xiàn)Session 跟蹤

Cookie 被禁用怎么辦?

最常用的就是利用 URL 重寫把 Session ID 直接附加在 URL 路徑的后面窿锉。

Cookie棚贾、Session、JWT的詳解

由于 http 是無狀態(tài)的協(xié)議榆综，每個(gè)請(qǐng)求是獨(dú)立的，服務(wù)端無法確認(rèn)當(dāng)前請(qǐng)求者的身份铸史，因此為了實(shí)現(xiàn)服務(wù)器和瀏覽器的會(huì)話跟蹤鼻疮，就需要使用 cookie 或者 session 維持一個(gè)狀態(tài)，該狀態(tài)用于告知服務(wù)端前后的請(qǐng)求是否來自同一用戶

Cookie

• cookie 存儲(chǔ)在客戶端
• cookie 是不可跨域的

Session

seesion 是基于 cookie 實(shí)現(xiàn)的琳轿，session 保存在服務(wù)端判沟， session_id 保存在客戶端的 cookie 中。

Token

• 1崭篡、用戶使用用戶名密碼來請(qǐng)求服務(wù)器
• 2挪哄、服務(wù)器進(jìn)行驗(yàn)證用戶的信息
• 3、服務(wù)器通過驗(yàn)證發(fā)送給用戶一個(gè)token
• 4琉闪、客戶端存儲(chǔ)token迹炼，并在每次請(qǐng)求時(shí)附送上這個(gè)token值
• 5、服務(wù)端驗(yàn)證token值，并返回?cái)?shù)據(jù)（需要查數(shù)據(jù)庫）

JWT

JSON WEB TOKEN , 適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景斯入。
JWT是由三段信息構(gòu)成的砂碉，header、payload刻两、signature

• header 指出了聲明類型和加密算法
• payload 存放有效個(gè)人信息如用戶信息增蹭、權(quán)限信息
• signature 由三部分組成header (base64后的)、payload (base64后的)磅摹、secret（secret 是保存在服務(wù)器端的滋迈， jwt 的簽發(fā)生成也是在服務(wù)器端的，secret 就是用來進(jìn)行 jwt 的簽發(fā)和 jwt 的驗(yàn)證）

常見問題

使用 cookie

• 因?yàn)榇鎯?chǔ)在客戶端户誓，容易被客戶端篡改饼灿，使用前需要驗(yàn)證合法性
• 不要存儲(chǔ)敏感數(shù)據(jù)，比如用戶密碼厅克，賬戶余額
• 使用 httpOnly 在一定程度上提高安全性
• 盡量減少 cookie 的體積赔退，能存儲(chǔ)的數(shù)據(jù)量不能超過 4kb
• 設(shè)置正確的 domain 和 path，減少數(shù)據(jù)傳輸
• cookie 無法跨域
• 一個(gè)瀏覽器針對(duì)一個(gè)網(wǎng)站最多存 20 個(gè)Cookie证舟，瀏覽器一般只允許存放 300 個(gè)Cookie
• 移動(dòng)端對(duì) cookie 的支持不是很好硕旗，而 session 需要基于 cookie 實(shí)現(xiàn)，所以移動(dòng)端常用的是 token

使用session

• 將 session 存儲(chǔ)在服務(wù)器里面女责，當(dāng)用戶同時(shí)在線量比較多時(shí)漆枚，這些 session 會(huì)占據(jù)較多的內(nèi)存，需要在服務(wù)端定期的去清理過期的 session
• 當(dāng)網(wǎng)站采用集群部署的時(shí)候抵知，會(huì)遇到多臺(tái) web 服務(wù)器之間如何做 session 共享的問題墙基。因?yàn)?session 是由單個(gè)服務(wù)器創(chuàng)建的，但是處理用戶請(qǐng)求的服務(wù)器不一定是那個(gè)創(chuàng)建 session 的服務(wù)器刷喜，那么該服務(wù)器就無法拿到之前已經(jīng)放入到 session 中的登錄憑證之類的信息了残制。
• 當(dāng)多個(gè)應(yīng)用要共享 session 時(shí)，除了以上問題掖疮，還會(huì)遇到跨域問題初茶，因?yàn)椴煌膽?yīng)用可能部署的主機(jī)不一樣，需要在各個(gè)應(yīng)用做好 cookie 跨域的處理浊闪。
• sessionId 是存儲(chǔ)在 cookie 中的恼布，假如瀏覽器禁止 cookie 或不支持 cookie 怎么辦？ 一般會(huì)把 sessionId 跟在 url 參數(shù)后面即重寫 url搁宾，所以 session 不一定非得需要靠 cookie 實(shí)現(xiàn)
• 移動(dòng)端對(duì) cookie 的支持不是很好折汞，而 session 需要基于 cookie 實(shí)現(xiàn)，所以移動(dòng)端常用的是 token

使用 token

如果你認(rèn)為用數(shù)據(jù)庫來存儲(chǔ) token 會(huì)導(dǎo)致查詢時(shí)間太長(zhǎng)盖腿，可以選擇放在內(nèi)存當(dāng)中爽待。比如 redis 很適合你對(duì) token 查詢的需求。
token 完全由應(yīng)用管理，所以它可以避開同源策略
token 可以避免 CSRF 攻擊(因?yàn)椴恍枰?cookie 了)
移動(dòng)端對(duì) cookie 的支持不是很好堕伪，而 session 需要基于 cookie 實(shí)現(xiàn)揖庄，所以移動(dòng)端常用的是 token

使用 JWT

• JWT 并不依賴 Cookie 的，所以你可以使用任何域名提供你的 API 服務(wù)而不需要擔(dān)心跨域資源共享問題（CORS）
• JWT 默認(rèn)是不加密欠雌，但也是可以加密的蹄梢。生成原始 Token 以后，可以用密鑰再加密一次富俄。
• JWT 不加密的情況下禁炒，不能將秘密數(shù)據(jù)寫入 JWT。
• JWT 不僅可以用于認(rèn)證霍比，也可以用于交換信息幕袱。有效使用 JWT，可以降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)悠瞬。
• JWT 最大的優(yōu)勢(shì)是服務(wù)器不再需要存儲(chǔ) Session们豌，使得服務(wù)器認(rèn)證鑒權(quán)業(yè)務(wù)可以方便擴(kuò)展。但這也是 JWT 最大的缺點(diǎn)：由于服務(wù)器不需要存儲(chǔ) Session 狀態(tài)浅妆，因此使用過程中無法廢棄某個(gè) Token 或者更改 Token 的權(quán)限望迎。也就是說一旦 JWT 簽發(fā)了，到期之前就會(huì)始終有效凌外，除非服務(wù)器部署額外的邏輯辩尊。
• JWT 本身包含了認(rèn)證信息，一旦泄露康辑，任何人都可以獲得該令牌的所有權(quán)限摄欲。為了減少盜用，JWT的有效期應(yīng)該設(shè)置得比較短疮薇。對(duì)于一些比較重要的權(quán)限胸墙，使用時(shí)應(yīng)該再次對(duì)用戶進(jìn)行認(rèn)證。
• JWT 適合一次性的命令認(rèn)證按咒，頒發(fā)一個(gè)有效期極短的 JWT迟隅，即使暴露了危險(xiǎn)也很小，由于每次操作都會(huì)生成新的 JWT胖齐，因此也沒必要保存 JWT，真正實(shí)現(xiàn)無狀態(tài)嗽冒。
• 為了減少盜用呀伙，JWT 不應(yīng)該使用 HTTP 協(xié)議明碼傳輸，要使用 HTTPS 協(xié)議傳輸添坊。

JWT的優(yōu)點(diǎn)

• JWT 一般不放在 cookie 中（cookie 中的話不能跨域）剿另，直接放在 HTTP 請(qǐng)求頭信息中的 Authorization 字段內(nèi)，使用 Bearer 模式添加 JWT。
• 用戶狀態(tài)不儲(chǔ)存在服務(wù)端的內(nèi)存中雨女，這是一種 無狀態(tài)的認(rèn)證機(jī)制
• 服務(wù)端的保護(hù)路由將會(huì)檢查請(qǐng)求頭 Authorization 中的 JWT 信息谚攒，如果合法，則允許用戶的行為
• 由于 JWT 包含了用戶信息和權(quán)限信息氛堕，因此減少了需要查詢數(shù)據(jù)庫的需要
• 因?yàn)?JWT 并不使用 Cookie 馏臭，所以你可以使用任何域名提供你的 API 服務(wù)而不需要擔(dān)心跨域資源共享問題（CORS）

Token 和 JWT 的區(qū)別

相同：

• 都是訪問資源的令牌
• 都可以記錄用戶的信息
• 都是使服務(wù)端無狀態(tài)化
• 都是只有驗(yàn)證成功后，客戶端才能訪問服務(wù)端上受保護(hù)的資源
  區(qū)別：
  Token：服務(wù)端驗(yàn)證客戶端發(fā)送過來的 Token 時(shí)讼稚，還需要查詢數(shù)據(jù)庫獲取用戶信息括儒，然后驗(yàn)證 Token 是否有效。
  JWT：將 Token 和 Payload 加密后存儲(chǔ)于客戶端锐想，服務(wù)端只需要使用密鑰解密進(jìn)行校驗(yàn)（校驗(yàn)也是 JWT 自己實(shí)現(xiàn)的）即可帮寻，不需要查詢或者減少查詢數(shù)據(jù)庫，因?yàn)?JWT 自包含了用戶信息和加密的數(shù)據(jù)赠摇。

Cookie不能跨域固逗？

由于域名不同，用戶向系統(tǒng)A登錄后藕帜，系統(tǒng)A返回給瀏覽器的Cookie烫罩，用戶再請(qǐng)求系統(tǒng)B的時(shí)候不會(huì)將系統(tǒng)A的Cookie帶過去。
針對(duì)Cookie存在跨域問題耘戚，有幾種解決方案：
1嗡髓、服務(wù)端將Cookie寫到客戶端后，客戶端對(duì)Cookie進(jìn)行解析收津，將Token解析出來饿这，此后請(qǐng)求都把這個(gè)Token帶上就行了
2、多個(gè)域名共享Cookie撞秋，在寫到客戶端的時(shí)候設(shè)置Cookie的domain长捧。
3、將Token保存在SessionStroage中（不依賴Cookie就沒有跨域的問題了）

Session和Cookie 的區(qū)別

1吻贿、Cookie 數(shù)據(jù)保存在客戶端(瀏覽器端)串结，Session 數(shù)據(jù)保存在服務(wù)器端。
2舅列、Cookie不是很安全肌割，容易被用作cookie欺騙。
3帐要、Session 會(huì)在一定時(shí)間存放在服務(wù)器上把敞，當(dāng)訪問增多時(shí)，會(huì)占用服務(wù)器性能榨惠。
4奋早、Cookie 只支持存字符串?dāng)?shù)據(jù)盛霎，想要設(shè)置其他類型的數(shù)據(jù)，需要將其轉(zhuǎn)換成字符串耽装，Session 可以存任意數(shù)據(jù)類型愤炸。
5、單個(gè) Cookie 保存的數(shù)據(jù)不能超過 4K掉奄，Session 可存儲(chǔ)數(shù)據(jù)遠(yuǎn)高于 Cookie规个，但是當(dāng)訪問量過多，會(huì)占用過多的服務(wù)器資源挥萌。

Session 和 Token 的區(qū)別

• Session 是記錄服務(wù)器和客戶端會(huì)話狀態(tài)的機(jī)制绰姻，使服務(wù)端有狀態(tài)化，可以記錄會(huì)話信息引瀑， token 是訪問資源接口的資源憑證,每次請(qǐng)求都要解析狂芋，服務(wù)端無狀態(tài)化，不儲(chǔ)存會(huì)話信息憨栽。
• Session 只提供簡(jiǎn)單的認(rèn)證帜矾， 而 Token 提供的是 認(rèn)證 和 授權(quán) ，認(rèn)證是針對(duì)用戶屑柔，授權(quán)是針對(duì) App 屡萤。

Session的認(rèn)證流程

• 1、用戶第一次請(qǐng)求服務(wù)器的時(shí)候掸宛，服務(wù)器根據(jù)用戶提交的相關(guān)信息死陆，創(chuàng)建對(duì)應(yīng)的SessionID
• 2、請(qǐng)求返回時(shí)將此 Session 的唯一標(biāo)識(shí)信息 SessionID 返回給瀏覽器
• 3唧瘾、瀏覽器接收到服務(wù)器返回的 SessionID 信息后措译，會(huì)將此信息存入到 Cookie 中，同時(shí) Cookie 記錄此 SessionID 屬于哪個(gè)域名
• 4饰序、當(dāng)用戶第二次訪問服務(wù)器的時(shí)候领虹，請(qǐng)求會(huì)自動(dòng)判斷此域名下是否存在 Cookie 信息，如果存在自動(dòng)將 Cookie 信息也發(fā)送給服務(wù)端求豫，服務(wù)端會(huì)從 Cookie 中獲取 SessionID塌衰，再根據(jù) SessionID 查找對(duì)應(yīng)的 Session 信息，如果沒有找到說明用戶沒有登錄或者登錄失效蝠嘉，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作最疆。

Refresh Token

專用于刷新 access token 的 token≡楦妫客戶端直接用 refresh token 去更新 access token努酸，無需用戶進(jìn)行額外的操作。

分布式架構(gòu)下 session 的共享

session 復(fù)制：任何一個(gè)服務(wù)器上的 session 發(fā)生改變（增刪改）罩缴，該節(jié)點(diǎn)會(huì)把這個(gè) session 的所有內(nèi)容序列化蚊逢，然后廣播給所有其它節(jié)點(diǎn)卵皂，不管其他服務(wù)器需不需要 session 功蜓，以此來保證 session 同步

session 共享：使用分布式緩存方案比如 Memcached 、Redis 來緩存 session虑稼，但是要求 Memcached 或 Redis 必須是集群檬寂，把 session 放到 Redis 中存儲(chǔ)

Post和Get的區(qū)別

1终抽、post的參數(shù)是放在請(qǐng)求體的，而get參數(shù)是通過URL傳遞的
2桶至、get請(qǐng)求只能進(jìn)行url編碼昼伴，而post請(qǐng)求支持多種編碼方式
3、get請(qǐng)求在url中傳送的參數(shù)是有長(zhǎng)度限制的镣屹，而post沒有
4圃郊、get請(qǐng)求在瀏覽器回退時(shí)是無害的，而post請(qǐng)求會(huì)再次提交請(qǐng)求

ARP地址解析協(xié)議

將IP地址轉(zhuǎn)化為對(duì)應(yīng)的物理地址

什么是SQL 注入女蜈？舉個(gè)例子持舆？

把SQL命令插入到Web表單提交或輸入域名或頁面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令伪窖。

用戶的個(gè)人信息可以存儲(chǔ)在cookie或localstorage中

什么是XSS攻擊?

XSS：跨站腳本攻擊逸寓。XSS的重點(diǎn)不在于跨站點(diǎn)，而在于腳本的執(zhí)行覆山。
XSS的原理是：惡意攻擊者在web頁面中會(huì)插入一些惡意的script代碼竹伸。當(dāng)用戶瀏覽該頁面的時(shí)候，那么嵌入到web頁面中script代碼會(huì)執(zhí)行簇宽，因此會(huì)達(dá)到惡意攻擊用戶的目的勋篓。

什么是 CSRF？

CSRF又稱為跨站請(qǐng)求攻擊晦毙，攻擊者盜取用戶Cookie信息偽造請(qǐng)求訪問其他網(wǎng)站

用戶登錄了受信任的網(wǎng)站生巡，并在本地生成了 cookie。然后訪問了危險(xiǎn)網(wǎng)站见妒，由于瀏覽器會(huì)自動(dòng)帶上用戶 cookie孤荣，由此盜取用戶Cookie信息從而達(dá)成模擬用戶操作的目的。

解決方案
1须揣、同源檢測(cè)：利用HTTP協(xié)議中的盐股，異步請(qǐng)求攜帶的Origin/Refer Header；通過這兩個(gè)請(qǐng)求頭可以確定請(qǐng)求源耻卡。
2疯汁、Token：

為什么說Token可以防止CSRF攻擊

token 驗(yàn)證的規(guī)則是，服務(wù)器從請(qǐng)求體（POST）或者請(qǐng)求參數(shù)（GET）中獲取設(shè)置的 token卵酪，然后和 Cookie 中的 token 進(jìn)行比較幌蚊，一致之后才執(zhí)行請(qǐng)求谤碳。
CSRF 攻擊只是借用了 Cookie，并不能獲取 Cookie 中的信息溢豆，所以不能獲取 Cookie 中的 token蜒简，也就不能在發(fā)送請(qǐng)求時(shí)在 POST 或者 GET 中設(shè)置 token，把請(qǐng)求發(fā)送到服務(wù)器端時(shí)漩仙，token 驗(yàn)證不通過搓茬，也就不會(huì)處理請(qǐng)求了。

為什么CSRF攻擊不能解析Cookie中的token队他？

token 校驗(yàn)之所以能防御 csrf卷仑，是因?yàn)橄嘈艦g覽器的同源策略。為什么這么說麸折？因?yàn)橹挥性谕吹那闆r下锡凝，頁面才能進(jìn)行腳本操作和使用 js 獲取 cookie 的操作，才能獲取到 token垢啼。也就是說第三方網(wǎng)站是沒有辦法拿到 token 的私爷。只有真正有權(quán)限的網(wǎng)站或頁面才有辦法取到 token，并將 token 傳到服務(wù)端膊夹。所以服務(wù)端默認(rèn)帶有相應(yīng) token 的請(qǐng)求都是合法的請(qǐng)求衬浑。

跨域

1、協(xié)議放刨，域名工秩，端口三者其中存在不同都會(huì)形成跨域
2、跨域存在原因：瀏覽器的同源限制策略