计算机网络：HTTP

ccc_0
238 阅读25分钟

参考

  1. blog.csdn.net/qq_38289815…
  2. (46条消息) get请求和post请求的区别（全面讲解）__处女座程序员的日常的博客-CSDN博客
  3. 聊聊大家都爱问的HTTP1.0和2.0的区别 - 掘金 (juejin.cn)
  4. HTTP发展史，HTTP1.1与HTTP2.0的区别 - 掘金 (juejin.cn)
  5. 彻底理解cookie，session，token - 知乎 (zhihu.com)
  6. 面试必问:session，cookie和token的区别 - 腾讯云开发者社区-腾讯云 (tencent.com)
  7. 什么是Http无状态？Session、Cookie、Token三者之间的区别 - 翎野君 - 博客园 (cnblogs.com)

网络协议是计算机之间为了实现网络通信而达成的一种“约定”或者”规则“，有了这种”约定“，不同厂商的生产设备，以及不同操作系统组成的计算机之间，就可以实现通信。

1. HTTP协议

HTTP 是浏览器与服务端最主要的通信协议
HTTP协议是超文本传输协议的缩写，英文是Hyper Text Transfer Protocol。它是从WEB服务器传输超文本标记语言(HTML)到本地浏览器的传送协议。HTTP 协议是以明文方式发送信息的，如果黑客截取了 Web 浏览器和服务器之间的传输报文，就可以直接获得其中的信息。 设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。HTTP 协议设计的初衷本身就是请求/响应模式，这是规范决定的。不过在技术上是可以利用下层的 TCP 来进行全双工通信的。

HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML 文件,、图片文件, 查询结果等。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。 image.png

原理：

  1. 客户端浏览器通过网络与服务器建立连接。（该连接是通过 TCP 来完成的，一般 TCP 连接的端口号是80。）
  2. 建立连接后，客户机发送一个请求给服务器，(请求方式的格式为：统一资源标识符（URI）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容。)
  3. 服务器接到请求后响应（响应信息：格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。）

HTTP响应报文和响应报文结构： image.png

头部：
14.   HTTP 头部（内容长度，可接受压缩类型（请求报文）/压缩类型（响应报文），catch-control，是否长连接等）

2. HTTP各版本发展及其区别总结

2.1 HTTP0.9

充分验证了 Web 服务的可行性

请求： GET /html文档 响应： 编码后的html<html><body>Hello HTTP/0.9</body></html>
流程：

  • 客户端和服务端建立TCP连接。
  • 客户端发送GET请求到服务端，请求index.html页面的数据。
  • 服务端发送完响应，关闭TCP连接。

特点： 简单，一个请求需要一个连接。
缺点： 通过HTTP来传输脚本、样式、图片、音视频等不同类型的文件。 ————> HTTP1.0

2.2 HTTP1.0

相比于HTTP0.9：

  • 新增请求方法：HEAD、POST
  • 新增响应状态码：标记可能错误原因
  • 引入协议版本号概念
  • 引入HTTP头概念：让HTTP处理请求和响应更加灵活
  • 传输的数据不再局限于文本

请求： 请求方法+版本信息+头信息
响应： 响应头信息+空行+数据部分
特点： 无连接，无状态

无连接： HTTP 1.0 浏览器与服务器只保持短暂的连接，每次请求都需要与服务器建立一个TCP连接。建立连接缺点：

  1. TCP三次握手成本比较高
  2. TCP连接初始速度相对慢：慢启动和拥塞避免

无状态： 服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。 简单来说，就是每次与服务器交互，都需要新开一个连接。

缺点：
每进行一次通信都要经历建立连接、传输数据和断开连接三个阶段。
当请求频繁且少量时，连接开销会很大造成性能缺陷。——>HTTP1.1

Connection:keep-alive：这是HTTP1.0版本为了解决连接开销的机制，在头部信息里带上该字段，服务器在发完响应数据之后就不会断开了TCP连接了，可达到复用目的。
但是由于不是标准字段，不同的实现可能导致表现得不一致，因此不能从根本上解决这个问题。

2.3 HTTP1.1与HTTP1.0区别

  • 长连接：
    即TCP默认不关闭，可以被多个请求复用

  • 并发连接：对一个域名的请求允许分配多个长连接（缓解了长连接中的「队头阻塞」问题）

  • 复用TCP连接：管道机制(pipeline) （导致队头阻塞的原因） 一个TCP连接可以同时发送多个请求，但要求响应顺序和请求顺序一致。(不常用)
    在一个TCP连接上可以并行传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，建立一次链接，然后多次请求可以均由这个连接完成。HTTP1.1是这样在加载html文件的时候，文件中多个请求和响应就可以在一个连接中传输，减少了性能的浪费。

    缺点在于：同一个TCP连接里面，所有的数据通信是按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。如果前面的处理需要时间特别长特别慢，后面的请求只能排队等着

  • 新增请求方法put、delete、options、新增请求头和响应头。

2.4 HTTP2.0

HTTP2.0在相比之前版本，性能上有很大的提升，添加了一些新特性。

与HTTP1.0比较：

  • 数据格式：
    HTTP2采用二进制格式传输数据，HTTP1采用文本格式(解析更高效)。
  • 新特性：
    • 多路复用：非有序非阻塞，只需一个连接
      复用TCP连接，在一个连接里两端都可以发送多个请求或回应，而且可以不按照顺序一一对应，避免了阻塞现象。
    • 二进制分帧
      每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装，这也是多路复用同时发送数据的实现条件。
      • 帧是HTTP2通信中最小单位信息，将请求和响应数据分割为更小的帧，并且它们采用二进制编码。
      • HTTP2中同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。
    • 首部压缩：降低开销
      HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送。
      首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新。
    • 服务器可以推送
      HTTP2引入服务器推送，允许服务端推送资源给客户端，服务器会顺便把一些客户端需要的资源一起推送到客户端，如在响应一个页面请求中，就可以带上页面的其它资源，避免客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。
      image.png

缺点：

  • 队头阻塞：
    原因在于复用TCP连接，TCP连接要求收发顺序一致，在丢包或网络中断的情况下后面的所有数据都被阻塞： 解决方法1：并发多个TCP长连接，由HTTP1.1引入。
    解决方法2：在一个TCP连接上并行发送多个请求/响应对(多路复用)。这样，即使某个请求的响应被延迟，其他请求仍然可以继续，从而避免了队头阻塞问题。由HTTP/2引入了多路复用的概念。
    解决问题3：从协议上解决。当 TCP 数据包在传输过程中丢失时，在服务器重新发送丢失的数据包之前，接收方无法确认传入的数据包。由于 TCP 在设计上不遵循 HTTP 之类的高级协议，因此单个丢失的数据包将阻塞所有进行中的 HTTP 请求的流，直到重新发送丢失的数据为止。这个问题在不可靠的连接上尤为突出，这在无处不在的移动设备时代并不罕见。————>HTTP3解决

2.5 HTTP3

HTTP/2 的问题不能仅靠应用程序层来解决，因此协议的新迭代必须更新传输层。但是，创建新的传输层协议并非易事。传输协议需要硬件供应商的支持，并且需要大多数网络运营商的部署才能普及。

于是：传输层协议改用UDP
UDP 协议与 TCP 一样得到广泛支持，但前者足够简单，可以作为在其之上运行的自定义协议的基础。**UDP 数据包是一劳永逸的：没有握手、持久连接或错误校正。**HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC （快速UDP互联网连接）协议。

QUIC：

  • 加密：QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安全问题。
  • QUIC单个请求响应包含过程：建立持久连接、协商加密协议、发送第一批数据。
  • 解决传输级别的队头阻塞：数据分流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。

3. HTTPs协议

HTTPS介绍：
是以安全为目标的 HTTP 通道，是 HTTP 的安全版。
HTTPS 的安全基础是 SSL：SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。SSL 协议可分为两层：

  1. SSL 记录协议（SSL Record Protocol），它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  2. SSL 握手协议（SSL Handshake Protocol），它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。 image.png

HTTPS 设计目标：

  • 数据保密性：保证数据内容在传输的过程中不会被第三方查看。
  • 数据完整性：及时发现被第三方篡改的传输内容。
  • 身份校验安全性：保证数据到达用户期望的目的地。

优点：

  1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器。
  2. HTTPS 协议是由SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、修改，确保数据的完整性。
  3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：
1、HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近。
2、HTTPS 连接缓存不如 HTTP 高效，会增加数据开销，甚至已有的安全措施也会因此而受到影响。
3、HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用。

5、成本增加。部署 HTTPS 后，因为 HTTPS 协议的工作要增加额外的计算资源消耗，例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本。

6、HTTPS 协议的加密范围也比较有限。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

3.1 HTTPs连接过程

image.png

  1. Client发起一个HTTPS的请求（比如juejin.cn/user/428335…
  2. Server把事先配置好的公钥证书（public key certificate）返回给客户端。
  3. Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。
  4. Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
  5. Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
  6. Server使用对称密钥加密“明文内容A”，发送给Client。
  7. Client使用对称密钥解密响应的密文，得到“明文内容A”。
  8. Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

4. HTTP与HTTPS区别

  1. HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。
  2. HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
  3. HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
  4. HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

    无状态：其数据包的发送、传输和接收都是相互独立的。
    无连接：指通信双方都不长久的维持对方的任何信息。

5. 状态码：

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结 果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

2XX 成功：

  • 200 ok（请求成功）
  • 204 no content （请求成功，但是没有结果返回）
  • 206 partial content （客户端请求一部分资源，服务端成功响应，返回一范围资源）

3XX 重定向：

  • 301 move permanently （永久性重定向）：
    状态码301和状态码302相似，不同的是状态码301往往代表的是永久性的重定向，值得注意的是，这种重定向跳转，从严格意义来讲不是服务器跳转，而是客户端跳转的。这个“跳”的动作是服务器是通过回传状态码301来下达给客户端的，让客户端完成跳转。
  • 302 found （临时性重定向）：临时跳转。例如：URL地址A可以向URL地址B上跳转，但这并不是永久性的，在经过一段时间后，URL地址A还可能向URL地址C上跳转。方法定向获取请求的资源）
  • 304 not modified （表示在客户端采用带条件的访问某资源时，服务端找到了资源，但是这个请求的条件不符合。跟重定向无关）：服务器通过返回状态码304可以告诉客户端请求资源成功，但是这个资源不是由服务器提供返回给客户端的，而是客户端本地浏览器缓存中就有的这个资源，因为可以从缓存中获取这个资源，从而节省传输的开销。

4XX 客户端错误：

  • 400 bad request （请求报文存在语法错误）
  • 401 unauthorized （需要认证（第一次返回）或者认证失败（第二次返回））
  • 403 forbidden （请求被服务器拒绝了）
  • 404 not found （服务器上无法找到请求的资源）

5XX 服务器错误：
500 internal server error （服务端执行请求时发生了错误）
503 service unavailable （服务器正在超负载或者停机维护，无法处理请求）

8. HTTP长连接和短链接和流水线

  • 短连接：浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。HTTP1.0默认。
  • 长连接：复用TCP连接。多个HTTP请求可以复用同一个TCP连接，这就节省了TCP连接建立和断开的消耗。要使用长连接，客户端和服务器的HTTP响应头部的Connection要设置为keep-alive，才能支持长连接。HTTP1.1默认使用长连接
  • 流水线：默认情况下，HTTP请求是按顺序发的，下一个请求只有在当前请求收到响应之后才会被发出，有点像停止等待协议。而在收到下一个请求之前，可能需要很长时间。流水线就是在一个HTTP长连接下连续发出请求，不用等待响应返回，减少延迟。

6. GET和POST请求区别

GET请求一般是去获取数据，通过URL拼接传递。对于GET方式请求：浏览器会把 http header 和 data 一并发送出去，服务器响应200（返回数据）表示成功；通过查询获取数据。
POST请求一般是向提交数据。对于 POST，通过请求体传递。浏览器先发送 header，服务器响应 100， 浏览器再继续发送 data，服务器响应 200 （返回数据）。通过添加或修改表单提交数据。

image.png
image.png

  • 安全性和可见性：
    get因为参数会放在url中，所以隐私性，安全性较差，不能用来传输敏感信息，请求的数据长度是有限制的，不同的浏览器和服务器不同，一般限制在 2~8K 之间，更加常见的是 1k 以内；
    post请求是没有的长度限制，请求数据是放在body中；

    • 关于POST方法比GET方法更安全？
      按照网上大部分文章的解释，POST 比 GET 安全，因为数据在地址栏上不可见。然而从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输，只要在网络节点上抓包，就能完整地获取数据报文。要想安全传输，就只有加密，也就是 HTTPS

  • 书签和历史记录：
    get请求可以被收藏为书签和保存在浏览器历史记录中，因为参数就是url中。
    post不能。它的参数不在url中。

  • 刷新/回退
    get请求刷新服务器或者回退没有影响，post请求回退时会重新提交数据请求。

  • 对长度限制：
    get对数据长度有限制：GET向URL添加数据，URL长度受限制
    post不受限制

    GET 方法的长度限制是怎么回事？
    网络上都会提到浏览器地址栏输入的参数是有限的。 首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。 浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

  • 缓存：
    HTTP缓存只适用于不改变服务端数据的请求，比如查询类的请求，所以get符合HTTP缓存。GET请求会被浏览器主动缓存，而POST不会，除非手动设置。

7. HTTP无状态及cookie、session、token

HTTP无状态导致无法处理动态交互：

HTTP 协议是无状态的，所谓的无状态就是客户端每次想要与服务端通信，都必须重新与服务端链接，意味着请求一次客户端和服务端就连接一次，不跟踪每个客户也不记录过去的请求，下一次请求与上一次请求是没有关系的。这种无状态的的好处是快速。

存在问题：协议对于交互性场景没有记忆能力。对于涉及到动态交互的场景，就显得很尴尬了，何为交互？有来又有往，对于一模一样的两个接口，不同的人在请求第二个接口时可能会基于请求第一个接口的结果而有所不同。

具体场景：购物网站买书包
先登录-->加购物车-->支付，第一次登录请求响应成功；第二次加购请求时，服务器已经忘记你是谁有没有经过登录验证了，所以加购物车请求得完成两件事，登录+加购；第三次支付请求同理。

解决方法：

  • 给每个用户颁发会话标识(session id)，每个客户端存储自己的会话标识，服务端存储所有的会话标识。缺点显而易见：服务器保存所有人的会话标识这是一个巨大开销，并且会限制功能扩展。

    缺点——限制功能扩展：机器集群时，用户通过机器A登录，对应session就在机器A上，那如果下次用户发起请求在机器B上了怎么办？ 给session从机器A搬到机器B费时费力。

    如何解决：

    1. session sticky：在哪台机器上登录的，后续请求就都粘连到对应机器。——>该机器挂掉了得话请求还是得转到别的机器。
    2. session集中到一台机器：单点失败，该机器挂了所有人都得再登录一遍。
    3. 服务器不再保存session，只让客户端保存
  • 升级版： 服务器不再保存session，只让客户端保存一个token。
    如果不保存这些session, 怎么验证客户端发给我的session id 的确是我生成的呢？该问题通过token验证解决。

    token：包含两部分，签名和实际数据。签名由数据经过加密算法和密钥生成。

    签名生成：
    image.png

    token验证：用户将自己得token发给服务器，服务器对token中的数据用同样算法和密钥生成一个新签名，与token中的签名对比，如果一致则认证通过。

cookie、session、token及其区别

cookie：

  • what: cookie 是保存在客户端浏览器里的一种信息载体，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
  • why: 用来保存一些站点的用户数据，能够为用户定值一些功能，比如免登录功能。
  • how: cookie由服务器生成，放在响应报文首部的set-cookie字段里，发送给浏览器，浏览器收到后把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie携带在请求中发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。

session：

  • what：session对象是服务器为每个浏览器创建的“身份标识”，保存在服务器中，用来区分请求来源。

    客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。

  • why: 存储在浏览器的cookie不安全，可能会有js脚本能拿到cookie信息，所以存储在服务器里面
  • how:基于cookie+session的身份验证的过程如下：
    1. 客户端会发送一个http请求到服务器端。
    2. 服务器端接受客户端请求后，建立一个session，并创建一个名为sessionID的cookie，其值映射了服务器里的session，并发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。该头部包含了带有sessionID信息的cookie。
    3. 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie
    4. 服务器接收请求，从cookie中提取处sessionID并从中读取用户信息，核对成功后返回response给客户端
  • 例子：使用session维护用户登陆状态，用户登录时将用户名密码表单放入http请求报文中，服务器收到后为其创建一个session，并创建一个名为sessionID的cookie，其值映射了服务器里的session，客户端之后对同一服务器请求时就会带上该cookie，服务器收到后提取出sessionID从中读取出用户信息，避免了由于http无状态而需要重复登录的情形。

token：
基于Token的身份验证的过程如下:

  1. 用户通过用户名和密码发送请求。
  2. 程序验证。
  3. 程序返回一个签名的token 给客户端。
  4. 客户端储存token,并且每次用于每次发送请求。
  5. 服务端验证token并返回数据。

token组成:
uid: 用户唯一身份标识
time: 当前时间的时间戳
sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

token常见加密算法：
HMAC-SHA256算法，即使用SHA-256生成哈希值的HMAC算法。依据HMAC算法和SHA-256算法内容，可知HMAC-SHA256算法的明文分组长度B为512-bit，可通过任意长度密钥K（最小推荐长度为256-bit，一般应大于B），得出长度为256-bit散列值（摘要）

HMAC（Hash-based Message Authentication Code，散列消息认证码）是一种使用密码散列函数，同时结合一个加密密钥，通过特别计算方式之后产生的消息认证码（MAC）。它可以用来保证数据的完整性，同时可以用来作某个消息的身份验证。HMAC算法 是一种基于密钥的报文完整性的验证方法。HMAC算法利用哈希运算，以一个密钥和一个消息为输入，生成一个消息摘要作为输出。其安全性是建立在Hash加密算法基础上的。它要求通信双方共享密钥、约定算法、对报文进行Hash运算，形成固定长度的认证码。通信双方通过认证码的校验来确定报文的合法性。HMAC算法可以用来作加密、数字签名、报文验证等。 SHA-256（Secure Hash Algorithm 256，安全散列算法256）是散列函数（或哈希函数）的一种，能对一个任意长度（按bit计算）的数字消息（message），计算出一个32个字节长度的字符串（又称消息摘要，message digest）。散列函数它被认为是一种单向函数——根据函数输出的结

coolie、session、token区别：
共同点是为了解决鉴权和认证问题。session 是空间换时间，token 是时间换空间。如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。

  • session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie。
  • cookie存储于客户端，类似一个令牌，装有sessionId，浏览器通常会自动添加。
  • token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。

cookie和session区别： 作用范围不同：cookie保存在客户端，session保存在服务器。
有效期不同：cookie可设置为长时间保持，比如经常使用的默认登录功能，而session一般失效时间较短，客户端关闭或者session超时都会失效。
隐私策略不同：Cookie存储在客户端，容易被窃取；Session存储在服务器，安全性相对Cookie要好一些。 存储大小不同：单个Cookie存储大小不超过4K；对于Session来说存储没有上限，但出于对服务器性能考虑，Session内不要存放过多的数据，并且需要设置Session删除机制。

avatar
文章
阅读
粉丝