具體屬性資料：https://github.com/mqyqingfeng/Blog/issues/157

起因：HTTP是無狀態(tài)協(xié)議

注意：Cookie的存在是為了解決后端服務(wù)的狀態(tài)問題，而不是通訊協(xié)議的狀態(tài)問題，別搞混了。

優(yōu)點：不需要保持狀態(tài)，減少服務(wù)器的CPU及內(nèi)存消耗。也正是因為HTTP協(xié)議本身非常簡單，所以被應(yīng)用于不同場景。

解決方案：Cookie

Cookie

作用：通過在請求和響應(yīng)報文中寫入Cookie信息來控制客戶端的狀態(tài)。

主要流程：Cookie會根據(jù)服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的Set-Cookie首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再次發(fā)送請求，帶上該Cookie;服務(wù)端根據(jù)客戶端Cookie鑒定客戶端來源，對比服務(wù)器記錄，得到該客戶端之前狀態(tài)信息。

跨域和跨站

首先要理解的一點就是跨站和跨域是不同的。同站(same-site)/跨站(cross-site)」和第一方(first-party)/第三方(third-party)是等價的。但是與瀏覽器同源策略（SOP）中的「同源(same-origin)/跨域(cross-origin)」是完全不同的概念。

同源策略的同源是指兩個 URL 的協(xié)議/主機名/端口一致。例如，https://www.taobao.com/pages/...，它的協(xié)議是?https，主機名是?www.taobao.com，端口是?443。

同源策略作為瀏覽器的安全基石，其「同源」判斷是比較嚴格的，相對而言，Cookie中的「同站」判斷就比較寬松：只要兩個 URL 的 eTLD+1 相同即可，不需要考慮協(xié)議和端口。其中，eTLD 表示有效頂級域名，注冊于 Mozilla 維護的公共后綴列表（Public Suffix List）中，例如，.com、.co.uk、.github.io 等。eTLD+1 則表示，有效頂級域名+二級域名，例如 taobao.com 等。

舉幾個例子，www.taobao.com 和?www.baidu.com?是跨站，www.a.taobao.com 和?www.b.taobao.com?是同站，a.github.io 和 b.github.io 是跨站(注意是跨站)。

主要注意點：SameSite

SameSite 是最近非常值得一提的內(nèi)容，因為 2 月份發(fā)布的 Chrome80 版本中默認屏蔽了第三方的 Cookie，這會導(dǎo)致阿里系的很多應(yīng)用都產(chǎn)生問題，為此還專門成立了問題小組，推動各 BU 進行改造。

屬性值：
1. Strict：僅允許一方請求攜帶Cookie，即瀏覽器將只發(fā)送相同站點請求的Cookie，即當(dāng)前網(wǎng)頁URL與請求目標URL完全一致。

2. Lax: 允許部分第三方請求攜帶Cookie

3. None: 無論是否跨站都會發(fā)送Cookie

影響：舉個例子，例如阿里巴巴在各大網(wǎng)站比如今日頭條、網(wǎng)易、微博等投放廣告，是用iframe嵌入的，設(shè)置SameSite為Lax就不能發(fā)送Cookie，就不能準確的進行推薦。

解決：設(shè)置SameSite為None

不過也會有兩點要注意的地方：

HTTP 接口不支持 SameSite=none

????如果你想加 SameSite=none 屬性，那么該 Cookie 就必須同時加上 Secure 屬性，表示只有在 HTTPS 協(xié)議下該 Cookie 才會被發(fā)送。

需要 UA 檢測，部分瀏覽器不能加 SameSite=none

????IOS 12 的 Safari 以及老版本的一些 Chrome 會把 SameSite=none 識別成 SameSite=Strict，所以服務(wù)端必須在下發(fā) Set-Cookie 響應(yīng)頭時進行 User-Agent 檢測，對這些瀏覽器不下發(fā) SameSite=none 屬性