1. JSP 和 Servlet 有什么区别

JSP（Java Server Pages）和Servlet 是 Java Web 开发中常用的两种技术。

Servlet 是一种基于 Java编写的服务器端程序，其主要作用是处理HTTP请求、响应、业务逻辑等操作。通过 Servlet，可以在服务器端生成动态内容，并将其传输到客户端浏览器。

JSP 可以看作是 Servlet 的一种简化形式，它允许在 HTML 页面中嵌入 Java 代码来实现动态网页的功能。相比于 Servlet，JSP 更加易于维护和开发，特别是对于前端工程师而言。

因此，Servlet 主要用于处理底层的协议通信、数据库访问等逻辑，而 JSP 则更多地专注于呈现数据、与用户交互等方面。两者并不是对立的关系，而是可以互相配合使用的。

2. JSP有哪些内置对象 分别是什么

JSP（Java Server Pages）中有多个内置对象，包括：

request 对象：代表 HTTP 请求，并提供了访问客户端提交的数据的方法。

response 对象：代表服务器对客户端请求的响应，并提供了向客户端发送数据的方法。

out 对象：代表输出流，并提供了向客户端输出内容的方法。

session 对象：代表用户会话，在同一会话中可以共享数据。

application 对象：代表 ServletContext 对象，代表整个 Web 应用程序，并提供了在应用程序范围内共享数据的方法。

pageContext 对象：代表 JSP 页面本身的上下文，并提供了获取其他内置对象的方法。

config 对象：代表 ServletConfig 对象，提供了获取 Web 应用程序配置信息的方法。

exception 对象：代表异常信息，可以获取最近一次抛出的异常。

、

3. 详细讲解cookie session token

在 Web 应用程序中，经常需要对用户进行身份认证和权限控制。Cookie、Session 和 Token 是常用的三种方式。

Cookie

Cookie 是一种客户端存储机制，服务器通过设置 Cookie 将数据保存在客户端浏览器中。之后，在每个请求中都会自动发送 Cookie 到服务器，以便服务器验证用户的身份信息。Cookie 可以包含任何信息，如用户名、密码、喜好设置等。

Cookie 的优点在于易于实现和管理，可以在不同站点间共享信息。缺点是存在 Cookie 被窃取或篡改的风险。为了减小这种风险，应使用 HTTPS 协议，并保证 Cookie 仅在受信赖的域名下使用。

Session

Session 是一种服务器端存储机制，服务器通过创建唯一的 Session ID（会话标识符）来维护与客户端之间的会话。服务器将 Session ID 存储在 Cookie 中或者 URL 参数中发送给客户端，客户端收到之后再发送回服务器，服务器通过 Session ID 来查询客户端的相关会话信息。

Session 的优点在于安全性高，因为所有的数据都保存在服务器端，客户端只接收和发送 Session ID，而无法获取具体的信息内容。缺点是需要在服务器上保存大量的会话数据，会占用服务器的内存和存储空间。

Token

Token 是一种轻量级的身份认证机制，客户端在登录成功后由服务器生成一个 JSON Web Token （JWT），并将其保存在客户端本地。之后，在每个请求中都会发送该 Token 信息，以便服务器验证用户的身份和权限信息。

Token 的优点在于灵活性高，可以用于不同类型的客户端和服务器端架构，无需依赖 Cookie。缺点是存在某些安全风险，如果 Token 被泄露，则有可能被恶意利用篡改或伪造 Token。为了减少这种风险，应使用 JWT 签名和加密、设置过期时间等措施。

Cookie、Session 和 Token 都是常见的身份认证和权限控制机制，各有优缺点，应根据具体的业务场景选择合适的方式。

4. 如果客户端禁止 了cookie ，session 还能用吗

如果客户端禁止了 Cookie，则 Session 可能无法正常工作，因为 Session ID 通常是通过 Cookie 在客户端和服务器之间传递的。此时，需要使用其他机制来实现身份认证和会话管理，例如：

URL 重写：将 Session ID 写入 URL 中的查询参数中，在后续的请求中通过 URL 中的参数来识别用户的会话。但是这种方式可能会泄露用户的信息，同样存在安全风险。

隐藏表单域：将 Session ID 写入 HTML 页面的隐藏表单域中，在后续的请求中将 Session ID 一同提交到服务器端。但是这种方式需要特殊的处理，且对前端页面设计有要求。

LocalStorage 或 IndexedDB：在客户端使用浏览器本地存储来保存 Session 相关数据，而不是依赖于 Cookie。但是这种方式需要浏览器支持，同时需要注意清理浏览器本地存储中过期的 Session 数据，以免造成安全隐患。

Token 认证：使用 Token 认证机制，客户端在每次请求时都必须发送 Token，服务器通过验证 Token 来判断用户身份。Token 可以通过 HTTP 头部、URL 参数等方式传递，不依赖于 Cookie。

所以 虽然禁止 Cookie 的情况下可能会影响 Session 的使用，但仍然有多种手段可以实现身份认证和会话管理。根据具体的业务场景，选择合适的解决方案是非常重要的。

5. session 的工作原理

Session 是一种服务器端的状态管理机制，它在服务端保存客户端会话的相关数据，并为每个客户端分配一个 Session ID。客户端通过向服务器发送 Session ID 来获取该客户端的会话数据。

Session 的工作原理如下：

客户端请求网页：当客户端访问网站时，服务器会自动创建一个唯一的 Session ID，并将它存储在 Cookie 中，然后返回该 Cookie 到客户端浏览器。如果客户端禁用了 Cookie，Session ID 可能会存在于 URL 的查询参数中。

服务器创建 Session 数据：服务器根据 Session ID 创建一个包含会话数据的空 Session 对象，并把 Session ID 保存到 Session 存储机制（通常是内存或数据库）中，以便后续能够根据 Session ID 获取到该客户端对应的 Session 对象。

客户端与服务器交互：接下来，客户端与服务器之间进行一系列的交互。例如，客户端可能提交表单、点击链接等操作，服务器会根据请求中的 Session ID 查找对应的 Session 对象，并通过 Session 对象来处理相应的请求，更新 Session 数据。此时，通常会修改用户的登录状态、记录用户的浏览信息、保存购物车等相关信息。

服务器关闭 Session：通常情况下，Session 会随着客户端访问网站的结束而关闭。服务器判断客户端是否长时间没有活动，或关闭浏览器等行为，会把该客户端对应的 Session 数据从存储机制中删除，并在下次访问时重新创建一个新的 Session 对象。

通过以上步骤，Session 可以实现跨请求和跨页面的状态保存，在 Web 应用程序中扮演着重要的角色。同时，也需要注意 Session 的安全性，避免泄露 Session ID 和 Session 数据。