计算机网络-应用层(上)

HTTP

HTTP报文

HTTP报文分为请求报文和响应报文，它们各自具有特定的结构和组成部分：

请求报文：

  • 请求行：包含请求方法、请求目标(URL等)和请求协议版本。
  • 请求头：包含请求的附加信息，如Host、User-Agent、Content-Type等。
  • 空行：用于分割请求头和请求体
  • 请求体：可选，包含请求的参数。
1
2
3
4
5
6
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

响应报文：

  • 响应行：包含HTTP协议版本、状态码和状态信息。
  • 响应头：包含响应的附加信息，如Content-Type、Content-Length等。
  • 空行：用于分割响应头部和响应体
  • 响应体：包含响应的数据。
1
2
3
4
5
6
7
8
9
10
11
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2023 12:28:53 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Wed, 22 Jul 2023 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello, World!

HTTP常用状态码

HTTP状态码是服务器对客户端请求的响应状态的标识，它们帮助客户端理解请求的处理结果。状态码分为五类，每一类都有特定的含义。以下是一些常用的HTTP状态码及其解释：

1xx（信息性状态码）

这类状态码表示请求已被接收，继续处理，是协议处理中的一种中间状态，使用的比较少。

  • 100 Continue：服务器已接收到请求头，并且客户端应继续发送请求体。
  • 101 Switching Protocols：服务器已理解客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。

2xx（成功状态码）

这类状态码表示请求已成功被服务器接收、理解并接受。

  • 200 OK：请求成功。一般用于GET与POST请求。
  • 201 Created：请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其URI已经随Location头信息返回。
  • 202 Accepted：服务器已接受请求，但尚未处理。
  • 204 No Content：服务器成功处理了请求，但没有返回任何内容。
  • 206 Partial Content：服务器已经成功处理了部分GET请求。

3xx（重定向状态码）

这类状态码表示需要客户端采取进一步的操作才能完成请求。

  • 300 Multiple Choices：被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。
  • 301 Moved Permanently：被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。
  • 302 Found：请求的资源现在临时从不同的URI响应请求。
  • 304 Not Modified：客户端发送了一个带条件的GET请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变。
  • 307 Temporary Redirect：请求的资源现在临时从不同的URI响应请求。

4xx（客户端错误状态码）

这类状态码表示客户端可能发生了错误，妨碍了服务器的处理。

  • 400 Bad Request：服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。
  • 401 Unauthorized：请求要求用户的身份认证。
  • 403 Forbidden：服务器已经理解请求，但是拒绝执行它。
  • 404 Not Found：请求失败，请求所希望得到的资源未被在服务器上发现。
  • 405 Method Not Allowed：请求行中指定的请求方法不能被用于请求相应的资源。
  • 408 Request Timeout：服务器等候请求时发生超时。
  • 410 Gone：被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。
  • 429 Too Many Requests：用户在给定的时间内发送了太多的请求。

5xx（服务器错误状态码）

这类状态码表示服务器在处理请求的过程中发生了错误。

  • 500 Internal Server Error：服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。
  • 501 Not Implemented：服务器不支持当前请求所需要的某个功能。
  • 502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
  • 503 Service Unavailable：由于临时的服务器维护或者过载，服务器当前无法处理请求。
  • 504 Gateway Timeout：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

GET 和 POST 的区别

GET 和 POST 是 HTTP 协议中两种常用的请求方法，它们在不同的场景和目的下有不同的特点和用法。一般来说，可以从以下几个方面来区分二者：

  • 语义(主要区别)：根据REF规范，GET通常用于获取或查询资源，而POST常用于创建或者修改资源。
  • 幂等：GET 请求是幂等的，即多次重复执行不会改变资源的状态，而 POST 请求是不幂等的，即每次执行可能会产生不同的结果或影响资源的状态。
  • 格式：GET请求的参数通常放在URL中，形成查询字符串，而POST请求参数通常放在请求体中，可以有多种编码格式。GET请求的URL长度会受到浏览器的限制，而POST的请求体大小并没有明确的限制。
  • 缓存：由于GET是幂等的，可以被浏览器或者其他中间节点缓存起来以提高i性能和效率；而POST请求则不适合缓存，因为每次请求可能都会对结果造成影响，需要实时的响应。
  • 安全性：
  • GET 请求和 POST 请求如果使用 HTTP 协议的话，那都不安全，因为 HTTP 协议本身是明文传输的，必须使用 HTTPS 协议来加密传输数据。另外，GET 请求相比 POST 请求更容易泄露敏感数据，因为 GET 请求的参数通常放在 URL 中。

HTTP的长连接

HTTP协议采用的是“请求”->“应答”的模式，客户端主动发起请求，服务端才会响应。

由于HTTP是基于TCP协议实现的，客户端与服务器间进行HTTP通信，需要先建立TCP连接，然后客户端发起HTTP请求，服务端收到请求后进行处理、响应，随后释放TCP连接。

但是如果每次都要进行这么一个流程：建立TCP连接 -> 请求资源 -> 响应 -> 释放连接，那么这种方式就是HTTP短连接。

一次连接只能请求一个资源，当多次请求时就会造成频繁的连接建立与释放过程，降低了性能，所以就有了长连接的方式。HTTP中的 Keep-Alive 实现在第一个HTTP请求完成之后，暂时不断开TCP连接以让后续的HTTP请求都沿用该连接的功能，避免了连接建立与销毁的额外开销，这个方法称为HTTP长连接。

HTTP长连接的特点是，TCP连接双方有一方提出了断开连接才会释放，否则保持TCP连接状态。

HTTP为什么不安全

HTTP（HyperText Transfer Protocol）是一种应用层协议，其本身存在一些安全问题，主要原因在于它是明文传输的。以下是HTTP不安全的几个主要原因：

  1. 窃听风险
  • 明文传输：HTTP协议在传输过程中不进行加密，数据以明文形式在网络上传输。这意味着任何在通信链路上的中间人都可以截获并读取通信内容。
  • 敏感信息泄露：由于数据未加密，窃听者可以轻易获取到用户的敏感信息，如登录凭证、信用卡信息等。
  1. 篡改风险
  • 数据完整性缺失：HTTP协议不提供数据完整性校验机制，攻击者可以在数据传输过程中篡改数据。例如，攻击者可以修改网页内容、注入恶意代码或篡改表单数据。
  • 中间人攻击：攻击者可以拦截并修改HTTP请求和响应，导致用户接收到被篡改的信息。
  1. 冒充风险
  • 身份验证缺失：HTTP协议不提供服务器或客户端的身份验证机制，攻击者可以冒充合法的服务器或客户端进行通信。
  • 钓鱼攻击：攻击者可以创建一个与合法网站外观相似的虚假网站，诱使用户输入敏感信息，从而窃取用户的登录凭证或其他敏感数据。

HTTPS如何解决HTTP的安全问题

HTTPS（HyperText Transfer Protocol Secure）通过在HTTP与TCP层之间加入SSL/TLS协议，很好地解决了上述安全问题。

  1. 信息加密
  • SSL/TLS协议：HTTPS使用SSL（Secure Sockets Layer）或TLS（Transport Layer Security）协议对数据进行加密。SSL/TLS协议通过公钥加密技术（如RSA）和会话密钥（对称加密）来保护数据的机密性。
  • 加密传输：即使在通信链路上获取到通信内容，攻击者也无法直接读取信息，因为数据已经被加密。
  1. 校验机制
  • 数据完整性校验：SSL/TLS协议使用消息认证码（MAC）来确保数据的完整性。MAC通过在数据中添加一个校验值，确保数据在传输过程中未被篡改。
  • 防止篡改：如果数据在传输过程中被篡改，接收方可以通过校验值检测到数据的完整性被破坏，从而拒绝接收被篡改的数据。
  1. 身份证书
  • 数字证书：HTTPS使用数字证书来验证服务器的身份。数字证书由受信任的第三方证书颁发机构（CA）签发，包含服务器的公钥和身份信息。
  • 身份验证：客户端在建立HTTPS连接时，会验证服务器的数字证书，确保连接到的是合法的服务器，而不是冒充的虚假服务器。
  • 防止冒充：通过数字证书的身份验证机制，HTTPS可以有效防止中间人攻击和钓鱼攻击。

HTTP与HTTPS的区别

  • 端口号：HTTP端口号默认是80；HTTPS端口号默认是443。
  • URL前缀：HTTP的URL前缀是http://；HTTPS则是https://。
  • 安全性和资源消耗：HTTP基于TCP协议，采用明文传输的方式，故而存在安全风险；而HTTPS协议在与HTTP与TCP中间插入了SSL/TSL安全协议，使得报文能够加密传输。但也因为多加了一层协议的缘故，HTTPS协议需要额外建立一次TSL四次握手，相较于HTTP多消耗了一些性能。
  • SEO(搜索引擎优化)：搜索引擎通常更加青睐于使用HTTPS的网站，故而搜索结果中采用了HTTPS的网站会优先显示，对SEO产生影响。

HTTPS握手过程

HTTPS（HyperText Transfer Protocol Secure）通过在HTTP与TCP层之间加入SSL/TLS协议，提供了安全的通信通道。SSL/TLS协议的核心是握手过程，它确保了通信双方的身份验证、密钥交换和加密算法的协商。以下是HTTPS握手过程的详细步骤：

  1. TSL第一次握手：客户端发起连接
  • Client Hello：客户端向服务器发送Client Hello消息，包含以下信息：
    • 支持的SSL/TLS版本：客户端支持的最高SSL/TLS版本。
    • 加密套件列表：客户端支持的加密算法和密钥交换算法。
    • 随机数（Client Random）：客户端生成的随机数，用于后续的密钥生成。
    • 会话ID（可选）：如果客户端希望恢复之前的会话，会发送会话ID。
  1. TSL第二次握手：服务器响应

  • Server Hello：服务器接收到Client Hello消息后，发送Server Hello消息，包含以下信息：

    • 选择的SSL/TLS版本：服务器选择的SSL/TLS版本。
    • 选择的加密套件：服务器从客户端提供的列表中选择一个加密套件。
    • 随机数（Server Random）：服务器生成的随机数，用于后续的密钥生成。
    • 会话ID（可选）：如果服务器同意恢复之前的会话，会发送会话ID。

  • 服务器证书：服务器发送自己的数字证书给客户端。证书包含服务器的公钥和身份信息，由受信任的第三方证书颁发机构（CA）签发。

  • 服务器密钥交换（可选）：如果选择的加密套件需要额外的密钥交换信息，服务器会发送Server Key Exchange消息。

  • 服务器Hello Done：服务器发送Server Hello Done消息，表示服务器已完成握手消息的发送。

  1. TSL第三次握手：客户端验证证书与密钥生成

​ 验证证书

  • 证书验证：客户端验证服务器的数字证书，确保证书是有效的、未过期的，并且由受信任的CA签发。客户端还会检查证书中的域名是否与服务器的域名匹配。

  • 生成预主密钥：如果证书验证通过，客户端生成一个预主密钥（Pre-Master Secret），并使用服务器的公钥加密后发送给服务器。

​ 密钥生成

  • 生成会话密钥：客户端和服务器使用预主密钥、客户端随机数和服务器随机数，通过伪随机函数（PRF）生成会话密钥（Session Key）。会话密钥用于后续的加密和解密通信内容。

  1. TSL第四次握手

    客户端完成握手

  • Client Key Exchange：客户端发送Client Key Exchange消息，包含加密后的预主密钥。

  • Change Cipher Spec：客户端发送Change Cipher Spec消息，通知服务器后续的通信将使用协商好的加密算法和会话密钥。

  • Finished：客户端发送Finished消息，包含使用会话密钥加密的握手消息摘要，用于验证握手过程的完整性。

​ 服务器完成握手

  • Change Cipher Spec：服务器发送Change Cipher Spec消息，通知客户端后续的通信将使用协商好的加密算法和会话密钥。

  • Finished：服务器发送Finished消息，包含使用会话密钥加密的握手消息摘要，用于验证握手过程的完整性。

​ 安全通信

  • 加密通信：握手完成后，客户端和服务器之间的所有通信都将使用会话密钥进行加密和解密，确保数据的机密性和完整性。

HTTP/1.0与HTTP/1.1区别

  • 连接方式：HTTP/1.0采用短连接方式，HTTP/1.1支持长连接。
  • 状态响应码：HTTP/1.1加入了大量的状态响应码。比如100(Continue)在请求大资源前的预热请求、409(Conflict)请求与当前资源的规定冲突等。
  • 带宽：HTTP/1.0中，存在一些带宽资源浪费现象，例如客户端只需要对象的某一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。
  • Host头处理：HTTP/1.1引入了Host头，允许在一个IP地址上托管多个域名，从而支持虚拟主机的功能。

HTTP/1.1与HTTP/2.0区别

  • 多路复用（Multiplexing）：HTTP/2.0 在同一连接上可以同时传输多个请求和响应（可以看作是 HTTP/1.1 中长链接的升级版本），互不干扰。HTTP/1.1 则使用串行方式，每个请求和响应都需要独立的连接，而浏览器为了控制资源会有 6-8 个 TCP 连接的限制。。这使得 HTTP/2.0 在处理多个请求时更加高效，减少了网络延迟和提高了性能。
  • 二进制帧（Binary Frames）：HTTP/2.0 使用二进制帧进行数据传输，而 HTTP/1.1 则使用文本格式的报文。二进制帧更加紧凑和高效，减少了传输的数据量和带宽消耗。
  • 头部压缩（Header Compression）：HTTP/1.1 支持Body压缩，Header不支持压缩。HTTP/2.0 支持对Header压缩，使用了专门为Header压缩而设计的 HPACK 算法，减少了网络开销。
  • 服务器推送（Server Push）：HTTP/2.0 支持服务器推送，可以在客户端请求一个资源时，将其他相关资源一并推送给客户端，从而减少了客户端的请求次数和延迟。而 HTTP/1.1 需要客户端自己发送请求来获取相关资源。

HTTP、SOCKET和TCP的区别

HTTP是应用层的协议，定义了客户端和服务器间数据的传输规范；Socket是通信的一端，提供了网路通信的接口；TCP是传输层协议，负责为端到端之间提供可靠的数据传输服务。它们在网络中充当不同的角色。

HTTP如何保存用户状态

HTTP（HyperText Transfer Protocol）是一种无状态的协议，这意味着每次请求都是独立的，服务器不会保存客户端的状态信息。然而，在实际应用中，许多场景需要保存用户的状态，例如用户登录状态、购物车内容等。为了解决这个问题，引入了Session机制。

Session机制

Session机制的主要作用是通过服务端记录用户的状态。典型的场景是购物车，当用户添加商品到购物车时，系统需要知道是哪个用户操作的，因为HTTP协议是无状态的。服务端为特定的用户创建特定的Session之后，就可以标识这个用户并且跟踪这个用户。

Session的工作原理

  1. 创建Session：当用户首次访问服务器时，服务器会为该用户创建一个唯一的Session ID，并将该Session ID与用户的状态信息（如用户ID、购物车内容等）关联起来。服务器可以选择将Session信息保存在内存、数据库（如Redis）或其他持久化存储中。
  2. 传递Session ID：服务器将Session ID返回给客户端，通常通过在响应头中设置Set-Cookie字段，将Session ID存储在客户端的Cookie中。客户端在后续的请求中，会将Session ID通过请求头中的Cookie字段发送给服务器。
  3. Session跟踪：服务器接收到客户端的请求时，会从请求头中提取Session ID，并根据Session ID查找对应的用户状态信息。服务器可以根据Session信息进行用户身份验证、状态管理等操作。
  4. Session销毁：服务器会在一定时间内保存Session信息，过了时间限制，就会销毁这个Session。用户退出登录或关闭浏览器时，服务器也会销毁对应的Session。

Cookie被禁用怎么办？

如果客户端禁用了Cookie，服务器无法通过Cookie传递Session ID，此时可以使用URL重写技术，即把Session ID附加在URL路径后面。

DNS

了解DNS

DNS(Domain Name System，域名系统)，它是互联网中用于将域名转化为对应的IP的分布式数据库系统。DNS扮演着一个重要的角色，使得人们不需要记得难记得IP地址而转向方便的域名，即可访问互联网资源。

DNS中的域名采用句点分割，比如www.example.com，此处句点代表不同层次之间得界限。在域名中，越靠右的位置代表其层级越高。（毕竟域名是外国人搞得，外国人姓在右名在左）。实际上最右边还有一个点，代表根域名，根域在最顶层。

因此，客户端只要找到任意DNS服务器，就可以回到其根域服务器，然后逐级找到目标DNS服务器。

DNS解析过程详解

域名系统（DNS）是互联网中用于将域名转换为IP地址的关键基础设施。以下是DNS解析过程的详细步骤：

  1. 客户端发起DNS查询：当用户在浏览器中输入“www.example.com”时，客户端（通常是操作系统或浏览器）会向本地DNS服务器发起DNS查询请求，以获取该域名对应的IP地址。

  2. 本地DNS服务器处理请求：本地DNS服务器接收到查询请求后，首先会检查其本地缓存。如果缓存中存在该域名的IP地址记录，则直接将该IP地址返回给客户端，从而避免了后续的递归查询过程。若缓存中不存在该记录，本地DNS服务器将启动递归查询。

  3. 根域名服务器的角色：本地DNS服务器向根域名服务器发起查询。根域名服务器不直接解析具体的域名，而是指示本地DNS服务器向负责顶级域名（TLD）的DNS服务器进行进一步查询。例如，对于“www.example.com”，根域名服务器会告知本地DNS服务器“.com”顶级域名服务器的地址。

  4. 顶级域名服务器的参与：本地DNS服务器随后向“.com”顶级域名服务器发起查询。顶级域名服务器进一步指示本地DNS服务器向负责“example.com”区域的权威DNS服务器进行查询。

  5. 权威DNS服务器的解析：权威DNS服务器是域名解析的最终来源，它存储了域名与IP地址的映射关系。本地DNS服务器向权威DNS服务器发起查询，权威DNS服务器返回“www.example.com”对应的IP地址。

  6. 本地DNS服务器的响应：本地DNS服务器接收到权威DNS服务器的响应后，将IP地址返回给客户端，并在本地缓存中存储该记录，以便后续查询时能够快速响应。

  7. 客户端发起HTTP请求：客户端接收到IP地址后，使用该IP地址发起HTTP请求，与目标服务器建立连接，从而完成域名解析的全过程。

深入解析

  • 递归查询与迭代查询：在上述过程中，本地DNS服务器执行的是递归查询，即它代表客户端完成整个查询过程。而根域名服务器、顶级域名服务器和权威DNS服务器执行的是迭代查询，它们仅提供下一步查询的指示，而不直接返回最终结果。

  • DNS缓存机制：DNS缓存是提高解析效率的关键机制。本地DNS服务器、ISP的DNS服务器以及操作系统都可能缓存DNS记录。缓存的有效期由DNS记录的TTL（Time to Live）值决定，TTL值越小，缓存的有效期越短，DNS解析的实时性越高。

  • 权威DNS服务器：权威DNS服务器是域名解析的最终权威，它存储了域名的权威记录（如A记录、CNAME记录等）。权威DNS服务器通常由域名注册商或企业自行管理，确保域名解析的准确性和安全性。

DNS基于UDP协议

DNS底层基于UDP协议，而不是TCP协议。主要考虑的因素是基于UDP协议具有的低延迟、轻量级、简单快速的特性。其高性能更加适合于DNS对需要快速响应的域名解析要求。

  • 低延时：UDP是无连接的协议，不需要建立连接减少了等待时间。
  • 简单快速：UDP没有连接管理和流量控制，传输效率更高。
  • 轻量级：UDP头部较小，占用网络资源少，适合DNS这种小而且频繁的数据交换。

Cookie 与 Session

HTTP协议的无状态性及其状态保持机制

HTTP的无状态性

HTTP（Hypertext Transfer Protocol）被设计为一种无状态协议，这意味着每个HTTP请求都是独立的，服务器不会保存关于客户端的状态信息。具体来说，服务器在处理一个请求时，不会依赖于之前或之后的请求，每个请求都被视为一个全新的交互。

无状态性的优点

  1. 简单性：无状态协议的设计相对简单，服务器不需要维护复杂的会话状态，从而简化了服务器的实现和维护。
  2. 可扩展性：无状态协议更容易实现负载均衡和高可用性，因为每个请求都可以独立处理，服务器之间不需要共享状态信息。
  3. 可靠性：由于每个请求都是独立的，服务器在处理请求时不会因为之前的请求失败而受到影响。

状态保持机制

尽管HTTP本身是无状态的，但在实际应用中，许多场景需要服务器能够识别和跟踪客户端的状态。为了实现这一需求，HTTP引入了一些状态保持机制，其中最常见的是Cookie和Session。

Cookie是一种在客户端（通常是浏览器）存储的小型文本文件，用于在客户端和服务器之间传递状态信息。服务器可以在HTTP响应中设置Cookie，客户端在后续请求中自动携带这些Cookie，从而实现状态保持。

Session

Session是一种在服务器端存储用户状态的机制。服务器为每个用户生成一个唯一的Session ID，并将其通过Cookie或其他方式传递给客户端。客户端在后续请求中携带Session ID，服务器根据Session ID查找对应的用户状态信息。

为什么HTTP仍然是无状态的？

虽然Cookie和Session等机制能够在一定程度上实现状态保持，但HTTP协议本身仍然被认为是无状态的。这是因为：

  1. 独立请求：服务器对于每个HTTP请求都是独立的，服务器不会自动保存或关联请求之间的状态信息。每个请求都需要携带足够的信息来理解请求的意图。
  2. 无状态设计：HTTP协议的设计初衷是无状态的，Cookie和Session等机制只是为了弥补无状态协议在某些场景下的不足，而不是改变HTTP协议的无状态特性。

在Web开发中，Cookie和Session是两种常用的状态管理技术，它们在存储位置、数据容量、安全性以及生命周期等方面存在显著差异。以下是对这两种技术的详细比较：

  1. 存储位置

  • Cookie：Cookie的数据存储在客户端（通常是浏览器）。当浏览器向服务器发起请求时，会自动附带Cookie中的数据。Cookie是HTTP协议的一部分，服务器可以通过HTTP响应头（Set-Cookie）设置Cookie，客户端在后续请求中通过HTTP请求头（Cookie）携带这些数据。

  • Session：Session的数据存储在服务器端。服务器会为每一个用户分配一个唯一的Session ID，通过Cookie或URL重写的方式发送给客户端，后续客户端的请求都要附带Session ID。服务器根据Session ID找到之前会话保留的数据。

  1. 数据容量

  • Cookie：单个Cookie文件的大小通常限制在4KB左右，并且大多数浏览器对单个域名下的Cookie数量也有一定的限制（通常为20个左右）。因此，Cookie的数据容量相对较小。

  • Session：Session数据保存在服务器中，仅受限于服务器的存储容量。因此，Session可以存储更多的数据，适用于需要存储大量用户状态信息的场景。

  1. 安全性

  • Cookie：Cookie相对不安全，因为数据存储在客户端，容易受到跨站脚本攻击（XSS）和跨站请求伪造（CSRF）的威胁。虽然可以通过设置HTTPOnly属性来防止JavaScript访问Cookie，但仍有可能受到CSRF攻击。

  • Session：Session通常被认为比Cookie更安全，因为数据保存在服务器端，不易受到客户端攻击。然而，Session仍然可能存在Session劫持的风险，特别是在Session ID通过不安全的通道（如未加密的HTTP）传输时。

  1. 生命周期

  • Cookie：Cookie可以设置过期时间，过期后自动删除；也可以设置为会话Cookie，浏览器关闭后自动删除。Cookie的生命周期可以通过服务器端的设置进行控制。

  • Session：Session默认在浏览器关闭时关闭会话，Session数据被删除。服务器也可以设置Session的过期时间，当Session超过一定时间没有活动时，Session也会失效。Session的生命周期通常由服务器端的管理策略决定。

Cookie、Session 和 Token 的区别

在Web开发中，Cookie、Session和Token是三种常用的状态管理技术，它们在实现机制、存储位置、安全性、可扩展性等方面存在显著差异。以下是对这三种技术的详细比较：

实现机制

  • Cookie：Cookie是一种在客户端存储的小型文本文件，用于在客户端和服务器之间传递状态信息。服务器可以通过HTTP响应头（Set-Cookie）设置Cookie，客户端在后续请求中通过HTTP请求头（Cookie）携带这些数据。
  • Session：Session是一种在服务器端存储用户状态的机制。服务器为每个用户生成一个唯一的Session ID，并将其通过Cookie或其他方式传递给客户端。客户端在后续请求中携带Session ID，服务器根据Session ID查找对应的用户状态信息。
  • Token：Token是一种基于令牌的身份验证机制。服务器在用户登录成功后生成一个Token，并将其返回给客户端。客户端在后续请求中携带Token，服务器通过验证Token来确认用户身份。Token通常是无状态的，服务器不需要存储Token信息。

存储位置

  • Cookie：Cookie的数据存储在客户端（通常是浏览器）。
  • Session：Session的数据存储在服务器端。
  • Token：Token的数据通常存储在客户端（如浏览器、本地存储或移动设备），服务器不需要存储Token信息。

安全性

  • Cookie：Cookie相对不安全，因为数据存储在客户端，容易受到跨站脚本攻击（XSS）和跨站请求伪造（CSRF）的威胁。虽然可以通过设置HTTPOnly和Secure属性来提高安全性，但仍有可能受到攻击。
  • Session：Session通常被认为比Cookie更安全，因为数据保存在服务器端，不易受到客户端攻击。然而，Session仍然可能存在Session劫持的风险，特别是在Session ID通过不安全的通道（如未加密的HTTP）传输时。
  • Token：Token通常被认为比Cookie和Session更安全，因为Token是无状态的，服务器不需要存储Token信息。Token通常使用加密算法生成，并且可以通过签名和加密来防止篡改和伪造。Token的安全性依赖于加密算法和传输通道的安全性。

可扩展性

  • Cookie：Cookie的可扩展性较差，因为数据存储在客户端，受限于浏览器对Cookie数量和大小的限制。
  • Session：Session的可扩展性较好，因为数据存储在服务器端，可以通过分布式存储和负载均衡来提高系统的可扩展性。然而，Session需要服务器端存储和管理，可能会增加服务器的负担。
  • Token：Token的可扩展性非常好，因为Token是无状态的，服务器不需要存储Token信息。Token可以轻松地在分布式系统中使用，适用于大规模和高并发的应用场景。

如果客户端禁用了Cookie，Session还能用吗？

默认情况下禁用了Cookie之后，Session无法正常使用，因为大多数Web服务都依赖于Cookie来传递Session ID。

当然，针对该问题有以下方案：

  1. URL重写：将Session ID附加到URL中作为参数。缺点是容易泄漏Session ID。
  2. 隐藏表单字段：在提交请求表单，单独划一个属性字段来存储Session ID。此方式只适合通过表单提交的交互方式。