接下来客户端每次向同一个网站发送要求时，要求头都会带上该 Cookie信息（包含 sessionId ）， 然后，做事器通过读取要求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到这次要求的 sessionId。
Session 的缺陷Session 机制有个缺陷，比如 A 做事器存储了 Session，便是做了负载均衡后，如果一段韶光内 A 的访问量激增，会转发到 B 进行访问，但是 B 做事器并没有存储 A 的 Session，会导致 Session 的失落效。
HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie，它是做事器发送到 Web 浏览器的一小块数据。做事器发送到浏览器的 Cookie，浏览器会进行存储，并与下一个要求一起发送到做事器。常日，它用于判断两个要求是否来自于同一个浏览器，例如用户保持登录状态。
HTTP Cookie 机制是 HTTP 协议无状态的一种补充和改良
Cookie 紧张用于下面三个目的
会话管理上岸、购物车、游戏得分或者做事器该当记住的其他内容
个性化用户偏好、主题或者其他设置
追踪记录和剖析用户行为
Cookie 曾经用于一样平常的客户端存储。虽然这是合法的，由于它们是在客户端上存储数据的唯一方法，但如今建议利用当代存储 API。Cookie 随每个要求一起发送，因此它们可能会降落性能（尤其是对付移动数据连接而言）。
创建 Cookie当吸收到客户端发出的 HTTP 要求时，做事器可以发送带有相应的 Set-Cookie 标头，Cookie 常日由浏览器存储，然后将 Cookie 与 HTTP 标头一同向做事器发出要求。
Set-Cookie 和 Cookie 标头Set-Cookie HTTP 相应标头将 cookie 从做事器发送到用户代理。下面是一个发送 Cookie 的例子
此标头见告客户端存储 Cookie
现在，随着对做事器的每个新要求，浏览器将利用 Cookie 头将所有以前存储的 Cookie 发送回做事器。
有两种类型的 Cookies，一种是 Session Cookies，一种是 Persistent Cookies，如果 Cookie 不包含到期日期，则将其视为会话 Cookie。会话 Cookie 存储在内存中，永久不会写入磁盘，当浏览器关闭时，此后 Cookie 将永久丢失。如果 Cookie 包含有效期 ，则将其视为持久性 Cookie。在到期指定的日期，Cookie 将从磁盘中删除。
还有一种是 Cookie的 Secure 和 HttpOnly 标记，下面依次来先容一下
会话 Cookies上面的示例创建的是会话 Cookie ，会话 Cookie 有个特色，客户端关闭时 Cookie 会删除，由于它没有指定Expires或 Max-Age 指令。
但是，Web 浏览器可能会利用会话还原，这会使大多数会话 Cookie 保持永久状态，就像从未关闭过浏览器一样。
永久性 Cookies永久性 Cookie 不会在客户端关闭时过期，而是在特定日期（Expires）或特定时间长度（Max-Age）外过期。例如
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;复制代码Cookie 的 Secure 和 HttpOnly 标记
安全的 Cookie 须要经由 HTTPS 协议通过加密的办法发送到做事器。纵然是安全的，也不应该将敏感信息存储在cookie 中，由于它们实质上是不屈安的，并且此标志不能供应真正的保护。
HttpOnly 的浸染
会话 Cookie 中短缺 HttpOnly 属性会导致攻击者可以通过程序(JS脚本、Applet等)获取到用户的 Cookie 信息，造成用户 Cookie 信息透露，增加攻击者的跨站脚本攻击威胁。HttpOnly 是微软对 Cookie 做的扩展，该值指定 Cookie 是否可通过客户端脚本访问。如果在 Cookie 中没有设置 HttpOnly 属性为 true，可能导致 Cookie 被盗取。盗取的 Cookie 可以包含标识站点用户的敏感信息，如 ASP.NET 会话 ID 或 Forms 身份验证票证，攻击者可以重播盗取的 Cookie，以便伪装成用户或获取敏感信息，进行跨站脚本攻击等。Cookie 的浸染域Domain 和 Path 标识定义了 Cookie 的浸染域：即 Cookie 该当发送给哪些 URL。
Domain 标识指定了哪些主机可以接管 Cookie。如果不指定，默认为当前主机(不包含子域名）。如果指定了Domain，则一样平常包含子域名。
例如，如果设置 Domain=mozilla.org，则 Cookie 也包含在子域名中（如developer.mozilla.org）。
例如，设置 Path=/docs，则以下地址都会匹配：
/docs/docs/Web//docs/Web/HTTPJSON Web Token 和 Session Cookies 的比拟JSON Web Token ，简称 JWT，它和 Session都可以为网站供应用户的身份认证，但是它们不是一回事。
下面是 JWT 和 Session 不同之处的研究
JWT 和 Session Cookies 的相同之处在磋商 JWT 和 Session Cookies 之前，有必要须要先去理解一下它们的相同之处。
它们既可以对用户进行身份验证，也可以用来在用户单击进入不同页面时以及上岸网站或运用程序后进行身份验证。
如果没有这两者，那你可能须要在每个页面切换时都须要进行登录了。由于 HTTP 是一个无状态的协议。这也就意味着当你访问某个网页，然后单击同一站点上的另一个页面时，做事器的内存中将不会记住你之前的操作。
因此，如果你登录并访问了你有权访问的另一个页面，由于 HTTP 不会记录你刚刚登录的信息，因此你将再次登录。
JWT 和 Session Cookies 便是用来处理在不同页面之间切换，保存用户登录信息的机制。
也便是说，这两种技能都是用来保存你的登录状态，能够让你在浏览任意受密码保护的网站。通过在每次产生新的要求时对用户数据进行身份验证来办理此问题。
以是 JWT 和 Session Cookies 的相同之处是什么？那便是它们能够支持你在发送不同要求之间，记录并验证你的登录状态的一种机制。
什么是 Session CookiesSession Cookies 也称为会话 Cookies，在 Session Cookies 中，用户的登录状态会保存在做事器的内存中。当用户登录时，Session 就被做事端安全的创建。
在每次要求时，做事器都会从会话 Cookie 中读取 SessionId，如果做事真个数据和读取的 SessionId 相同，那么做事器就会发送相应给浏览器，许可用户登录。
什么是 Json Web Tokens
Json Web Token 的简称便是 JWT，常日可以称为 Json 令牌。它是RFC 7519 中定义的用于安全的将信息作为 Json 工具进行传输的一种形式。JWT 中存储的信息是经由数字署名的，因此可以被信赖和理解。可以利用 HMAC 算法或利用 RSA/ECDSA 的公用/专用密钥对 JWT 进行署名。
利用 JWT 紧张用来下面两点
认证(Authorization)：这是利用 JWT 最常见的一种情形，一旦用户登录，后面每个要求都会包含 JWT，从而许可用户访问该令牌所许可的路由、做事和资源。单点登录是当今广泛利用 JWT 的一项功能，由于它的开销很小。信息交流(Information Exchange)：JWT 是能够安全传输信息的一种办法。通过利用公钥/私钥对 JWT 进行署名认证。此外，由于署名是利用 head 和 payload 打算的，因此你还可以验证内容是否遭到修改。JWT 的格式下面，我们谈判量一下 JWT 的组成和格式是什么
JWT 紧张由三部分组成，每个部分用 . 进行分割，各个部分分别是
HeaderPayloadSignature因此，一个非常大略的 JWT 组成会是下面这样
然后我们分别对不同的部分进行磋商。
Header
Header 是 JWT 的标头，它常日由两部分组成：令牌的类型(即 JWT)和利用的 署名算法，例如 HMAC SHA256 或 RSA。
例如
{ "alg": "HS256", "typ": "JWT"}复制代码
指定类型和署名算法后，Json 块被 Base64Url 编码形成 JWT 的第一部分。
Payload
Token 的第二部分是 Payload，Payload 中包含一个声明。声明是有关实体（常日是用户）和其他数据的声明。共有三种类型的声明：registered, public 和 private 声明。
registered 声明： 包含一组建议利用的预定义声明，紧张包括ISS 签发人 iss (issuer) 签发人 exp (expiration time) 过期韶光 sub (subject) 主题 aud (audience) 受众 nbf (Not Before) 生效韶光 iat (Issued At) 签发韶光 jti (JWT ID) 编号
public 声明：公共的声明，可以添加任何的信息，一样平常添加用户的干系信息或其他业务须要的必要信息，但不建议添加敏感信息，由于该部分在客户端可解密。private 声明：自定义声明，旨在在赞许利用它们的各方之间共享信息，既不是注册声明也不是公共声明。例如
{ "sub": "1234567890", "name": "John Doe", "admin": true}复制代码
然后 payload Json 块会被Base64Url 编码形成 JWT 的第二部分。
signature
JWT 的第三部分是一个签证信息，这个签证信息由三部分组成
header (base64后的)payload (base64后的)secret比如我们须要 HMAC SHA256 算法进行署名
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)复制代码
署名用于验证在此过程中没有变动，并且对付利用私钥进行署名的令牌，它还可以验证 JWT 的发送者的真实身份
拼凑在一起现在我们把上面的三个由点分隔的 Base64-URL 字符串部分组成在一起，这个字符串可以在 HTML 和 HTTP 环境中轻松通报这些字符串。
下面是一个完全的 JWT 示例，它对 header 和 payload 进行编码，然后利用 signature 进行署名
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ复制代码
如果想自己测试编写的话，可以访问 JWT 官网 jwt.io/#debugger-i…
JWT 和 Session Cookies 的不同JWT 和 Session Cookies 都供应安全的用户身份验证，但是它们有以下几点不同
密码署名JWT 具有加密署名，而 Session Cookies 则没有。
JSON 是无状态的JWT 是无状态的，由于声明被存储在客户端，而不是做事端内存中。
身份验证可以在本地进行，而不是在要求必须通过做事器数据库或类似位置中进行。 这意味着可以对用户进行多次身份验证，而无需与站点或运用程序的数据库进行通信，也无需在此过程中花费大量资源。
可扩展性Session Cookies 是存储在做事器内存中，这就意味着如果网站或者运用很大的情形下会耗费大量的资源。由于 JWT 是无状态的，在许多情形下，它们可以节省做事器资源。因此 JWT 要比 Session Cookies 具有更强的可扩展性。
JWT 支持跨域认证Session Cookies 只能用在单个节点的域或者它的子域中有效。如果它们考试测验通过第三个节点访问，就会被禁止。如果你希望自己的网站和其他站点建立安全连接时，这是一个问题。
利用 JWT 可以办理这个问题，利用 JWT 能够通过多个节点进行用户认证，也便是我们常说的跨域认证。
JWT 和 Session Cookies 的选型我们上面磋商了 JWT 和 Cookies 的不同点，相信你也会对选型有了更深的认识，大致来说
对付只须要登任命户并访问存储在站点数据库中的一些信息的中小型网站来说，Session Cookies 常日就能知足。
如果你有企业级站点，运用程序或附近的站点，并且须要处理大量的要求，尤其是第三方或很多第三方（包括位于不同域的API），则 JWT 显然更适宜。
后记前两天口试的时候问到了这个题，以是写篇文章总结一下，还问到了一个口试题，禁用 Cookies，如何利用 Session ？网上百度了一下，创造这是 PHP 的口试题......
但还是选择理解了一下，如何禁用 Cookies 后，利用 Session
如果禁用了 Cookies，做事器仍会将 sessionId 以 cookie 的办法发送给浏览器，但是，浏览器不再保存这个cookie (即sessionId) 了。如果想要连续利用 session，须要采取 URL 重写 的办法来实现，可以参考 www.cnblogs.com/Renyi-Fan/p…链接：https://juejin.im/post/5e893002f265da48094d8cd3
刚刚入驻头条，有不对的地方可以在评论区留言，以为不错的朋友希望能得到您的转发支持，同时可以持续关注我，每周定期会分享3到4篇精选干货！
