1、Servlet

（1）Servlet三大域对象，Jsp四大域对象

1） Servlet三大域对象

对象名称	对象的类型
request	HttpServletRequest
session	HttpSession
application	ServletContext

• request

客户端向服务器发送一次请求,服务器就会创建request对象，
服务器对这次请求作出响应后就会销毁request对象.仅在当前请求中有效。

获取表单提交参数： request.getParameter(）

//从login.jsp中获取用户名和密码
String username = request.getParameter(“username”);

传值到表单： request.setAttribute（）

request.setAttribute(“msg”, “用户名和密码不匹配!”);//传值到表单
request.getAttribute(“msg”);//获取对应request作用域的值

• session

服务器端第一次调用getSession();(保存在服务器内存中)
1.非正常关闭服务器(正常关闭session会序列化，再次启动服务器session会被反序列化)；
2.session过期了默认30分钟.
3.手动调用session.invalidate();
用户保持登录状态：

//登录成功 保存用户登录状态
request.getSession().setAttribute(“user”, user)；

• application

创建：服务器启动的时候,服务器为每个WEB应用创建一个属于该web项目的对象ServletContext类.
销毁：服务器关闭或者项目从服务器中移除的时候.
有效：此信息在整个服务器上被保留。

1.设置作用域中的共享数据（保存数据）

作用域对象.setAttribute(String name,Object value);

2.获取作用域中的共享数据（获取数据）

Object value=作用域对象.getAttribute(String name);

3.删除作用域中的指定的共享数据（删除数据）

作用域对象.removeAttribute(String name);

2）JSP四大域对象

对象名称	对象的类型
pageContext	PageContext
request	HttpServletRequest
session	HttpSession
application	ServletContext

• pageContext

有效：当前页面（最小的一个），超过这个页面就不能够使用。

在当前页面和当前页面中的标签共享数据：

void setAttribute(String name, Object value)；
Object getAttrbiute(String name, Object value)；
void removeAttribute(String name, Object value)；

全域： pageContext.findAttribute(“内容”)在四个域中搜索数据

自动搜索数据顺序:page域->request域->session域->application域(context域)

其他的和Servlet的类似

（2）请求转发和重定向

请求转发forward 只有一次请求，而重定向是两次请求

• 请求转发

request.setAttribute("forward_name", "abcde");//向request设置设置值
System.out.println("请求转发获取的属性:" + request.getAttribute("forward_name"));
request.getRequestDispatcher("/" + path);

在另外一个Servlet当中可以得到值

• 重定向

request.setAttribute("forward_name", "abcde");//向request设置设置值
System.out.println("重定向获取的属性:" + request.getAttribute("send_name"));
response.sendRedirect(path);

在另外一个Servlet当中不可以得到值。

2、http的长连接和短连接区别？

HTTP协议有HTTP/1.0版本和HTTP/1.1版本。
HTTP1.1默认保持长连接（HTTP persistent connection，也翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

在 HTTP/1.0 中，默认使用的是短连接。
也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。从HTTP/1.1起，默认使用的是长连接，用以保持连接特性。

3、http常见的状态码有哪些？

● 200 OK 客户端请求成功

● 301Moved Permanently（永久移除)，请求的URL已移走。Response中应该包含一个 Location URL，说明资源现在所处的位置

● 302found 重定向

● 400Bad Request 客户端请求有语法错误，不能被服务器所理解

● 401Unauthorized 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用

● 403 Forbidden 服务器收到请求，但是拒绝提供服务

● 404 Not Found 请求资源不存在，eg：输入了错误的URL

● 500 Internal Server Error 服务器发生不可预期的错误

● 503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

4、GET和POST的区别？

● GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：login.action?name=zhagnsan&password=123456。
POST 把提交的数据则放置在是HTTP包的包体中。

● GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据。其实这样说是错误的，不准确的：“GET方式提交的数据最多只能是1024字节"，因为 GET 是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。

而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。
这个限制是特定的浏览器及服务器对它的限制。

IE对URL长度的限制是2083字节(2K+35)。

对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

● POST的安全性要比GET的安全性高。

注意：这里所说的安全性和上面 GET 提到的“安全”不是同个概念。

上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的 Security的含义，
比如：通过GET 提交数据，用户名和密码将明文出现在URL上，因为登录页面有可能被浏览器缓存，其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用 GET 提交数据还可能会造成Cross-site request forgery攻击。

● Get 是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求，在FORM（表单）中，Method默认为"GET"，实质上GET和POST只是发送机制不同，并不是一个取一个发。

5、http中重定向和请求转发的区别？

本质区别：转发是服务器行为，重定向是客户端行为。

重定向特点：两次请求，浏览器地址发生变化，可以访问自己web之外的资源，传输的数据会丢失。

请求转发特点：一次强求，浏览器地址不变，访问的是自己本身的web资源，传输的数据不会丢失。

6、Cookie 和 Session 的区别？

Cookie是web服务器发送给浏览器的一块信息，浏览器会在本地一个文件中给每个web服务器存储Cookie。
以后浏览器再给特定的web服务器发送请求时，同时会发送所有为该服务器存储的Cookie。

Session是存储在web服务器端的一块信息。
Session对象存储特定用户会话所需的属性及配置信息。
当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。

7、Cookie和 Session的不同点：

无论客户端做怎样的设置，Session都能够正常工作。

当客户端禁用Cookie时将无法使用Cookie。

在存储的数据量方面：Session能够存储任意的java对象，Cookie只能存储String类型的对象。

8、session共享怎么做的（分布式如何实现session共享）？

问题描述：一个用户在登录成功以后会把用户信息存储在session当中，
这时session所在服务器为server1，那么用户在session失效之前如果再次使用app，
那么可能会被路由到 server2，这时问题来了，server2没有该用户的session，
所以需要用户重新登录，这时的用户体验会非常不好，
所以我们想如何实现多台server之间共享session，让用户状态得以保存。

● 服务器实现的session复制或session共享，这类型的共享session是和服务器紧密相关的，
比如webSphere或JBOSS在搭建集群时候可以配置实现session复制或session共享，但是这种方式有一个致命的缺点，
就是不好扩展和移植，比如我们更换服务器，那么就要修改服务器配置。

● 利用成熟的技术session复制，比如12306使用的gemfire，
比如常见的内存数据库如redis 或memorycache，这类方案虽然比较普适，
但是严重依赖于第三方，这样当第三方服务器出现问题的时候，那么将是应用的灾难。

● 将session维护在客户端，很容易想到就是利用cookie，但是客户端存在风险，数据不安全，而且可以存放的数据量比较小，
所以将session维护在客户端还要对session中的信息加密。我们实现的方案可以说是第二种方案和第三种方案的合体，
可以利用gemfire实现session复制共享，还可以session维护在redis中实现session共享，
同时可以将session维护在客户端的cookie中，但是前提是数据要加密。

这三种方式可以迅速切换，而不影响应用正常执行。

我们在实践中，首选gemfire或者redis作为session共享的载体，一旦session不稳定出现问题的时候，可以紧急切换cookie维护session作为备用，不影响应用提供服务。

这里主要讲解redis和cookie方案，gemfire比较复杂大家可以自行查看gemfire工作原理。利用redis做session共享，首先需要与业务逻辑代码解耦，不然session共享将没有意义，其次支持动态切换到客户端cookie模式。

redis的方案是，重写服务器中的HttpSession和HttpServletRequest，首先实现HttpSession接口，重写session的所有方法，将session以hash值的方式存在redis中，一个session的key就是sessionID，setAtrribute重写之后就是更新redis中的数据，getAttribute重写之后就是获取redis中的数据，等等需要将HttpSession的接口一一实现。

实现了HttpSesson，那么我们先将该session类叫做MySession（当然实践中不是这么命名的），当MySession出现之后问题才开始，怎么能在不影响业务逻辑代码的情况下，还能让原本的request.getSession()获取到的是MySession，而不是服务器原生的session。

这里，我决定重写服务器的HttpServletRequet，这里先称为MyRequest，
但是这可不是单纯的重写，我需要在原生的request基础上重写，
于是我决定在filter中，实现request的偷梁换柱，我的思路是这样的，MyRequest的构建器，必须以request作为参数，
于是我在filter中将服务器原生的request（也有可能是框架封装过的request），
当做参数new出来一个MyRequest，并且MyRequest也实现了HttpServletRequest接口，
其实就是对原生request的一个增强，这里主要重写了几个request的方法，
但是最重要的是重写了request.getSession()，
写到这里大家应该都明白为什么重写这个方法了吧，
当然是为了获取MySession，于是这样就在filter中，
偷偷的将原生的request换成MyRequest了，
然后再将替换过的request传入chan.doFilter()，
这样filter时候的代码都使用的是MyRequest了，
同时对业务代码是透明的，业务代码获取session的方法仍然是request.getSession()，
但其实获取到的已经是MySession了，这样对session的操作已经变成了对redis的操作。

这样实现的好处有两个，第一开发人员不需要对session共享做任何关注，session共享对用户是透明的；

第二，filter是可配置的，通过filter的方式可以将session共享做成一项可插拔的功能，没有任何侵入性。这个时候已经实现了一套可插拔的session共享的框架了，

但是我们想到如果redis服务出了问题，这时我们该怎么办呢，于是我们延续redis的想法，想到可以将session维护在客户端内（加密的cookie），

当然实现方法还是一样的，我们重写HttpSession接口，实现其所有方法，比如setAttribute就是写入cookie，getAttribute就是读取cookie，我们可以将重写的session称作MySession2，

这时怎么让开发人员透明的获取到MySession2呢，实现方法还是在filter内偷梁换柱，
在MyRequest加一个判断，读取sessionType配置，如果sessionType是redis的，

那么getSession的时候获取到的是MySession，如果sessionType是coolie的，
那么getSession的时候获取到的是MySession2，以此类推，用同样的方法就可以获取到MySession3，4，5，6等等。

这样两种方式都有了，那么我们怎实现两种session共享方式的快速切换呢，刚刚我提到一个sessionType，这是用来决定获取到session的类型的，

只要变换sessionType就能实现两种session共享方式的切换，但是sessionType必须对所有的服务器都是一致的，如果不一致那将会出现比较严重的问题，

我们目前是将sessionType维护在环境变量里，如果要切换sessionType就要重启每一台服务器，完成session共享的转换，但是当服务器太多的时候将是一种灾难。

而且重启服务意味着服务的中断，所以这样的方式只适合服务器规模比较小，而且用户量比较少的情况，当服务器太多的时候，务必需要一种协调技术，能够让服务器能够及时获取切换的通知。

基于这样的原因，我们选用zookeeper作为配置平台，每一台服务器都会订阅zookeeper上的配置，
当我们切换sessionType之后，所有服务器都会订阅到修改之后的配置，那么切换就会立即生效，
当然可能会有短暂的时间延迟，但这是可以接受的。

9、在单点登录中，如果cookie被禁用了怎么办？​​​​​​​

单点登录的原理是后端生成一个sessionID，然后设置到cookie，后面的所有请求浏览器都会带上cookie，然后服务端从cookie里获取sessionID，再查询到用户信息。

所以，保持登录的关键不是cookie，而是通过cookie保存和传输的sessionID，其本质是能获取用户信息的数据。

除了cookie，还通常使用HTTP请求头来传输。
但是这个请求头浏览器不会像cookie一样自动携带，需要手工处理。