Web基础知识的复习

1.     Servlet是什么?能干什么?

          Servlet
是运行在 Web
服务器或应用服务器上的程序，它是作为来自
Web 浏览器或其他
HTTP客户端的请求和
HTTP服务器上的数据库或应用程序之间的中间层，通过Servlet可以收集来自网页表单的用户输入，呈现来自数据库或者其他源的记录。

         Servlet的一些优点：

1.Servlet
在 Web
服务器的地址空间内执行。这样它就没有必要再创建一个单独的进程来处理       
每个客户端请求；
         2.纯java代码编写；

         3. Java
类库的全部功能对 Servlet
来说都是可用的

2.      Servlet在 Web 应用程序中的位置：

                                                                   




Servlet任务：

                  1.读取客户端（浏览器）发送的显式的数据，读取客户端（浏览器）发送的隐式的 HTTP
请求数据；

                  2．处理数据并生成结果；

                  3.
发送显式的数据到客户端（浏览器）和发送隐式的 HTTP
响应到客户端（浏览器）。



1.     Servlet生命周期

Servlet生命周期过程：

a.     Servlet通过调用init（）方法进行初始化;

Init（）方法只会被调用一次，在第一次创建Servlet的时候被创建，在后续的每次用户请求不会再调用。Servlet创建于用户第一次访问Servlet的URL时，也可以设定在Servlet在启动服务器的时被加载。

每一个用户请求都会产生一个新的线程，适当的时候移交给 doGet
或 doPost
方法。i

b.     Servlet调用service（）方法处理客户端（浏览器）发送的请求；

service()方法是执行实际任务的主要方法。Web服务器是调用 service()
方法来处理来自客户端（浏览器）的请求，并把格式化的响应写回给客户端。

每次服务器接收到一个 Servlet
请求时，服务器会产生一个新的线程并调用服务。service（）方法检查http请求类型并调用相应的方法处理请求，doGet()
和 doPost()
方法是每次服务请求中最常用的方法。

doGet和doPost二者方法的区别：

1.     二者都是响应get请求和post请求，对于get方式提交数据时有大小限制，一般在1024字节左右，即如果提交数据量很大的需要使用post请求，因为post没有大小限制；

2.     Get方式请求参数会跟在url后面，不安全；而post请求数据不会再url上显示，而是在请求体中。

c.     Servlet调用destroy（）方法进行销毁；

destroy() 方法只会被调用一次，在 Servlet
生命周期结束时被调用。

2.     Servlet工作方式

Servlet 表单数据：

从浏览器到Web服务器，最终到后台程序。浏览器使用两种方式将这些信息传递到Web服务器，分别是Get和Post方式：

Get：

GET方法向页面请求发送已编码的用户信息。页面和已编码的信息中间用？GET 方法是默认的从浏览器向 Web 服务器传递信息的方法，它会产生一个很长的字符串，出现在浏览器的地址栏中。如果您要向服务器传递的是密码或其他的敏感信息，请不要使用 GET 方法。GET 方法有大小限制：请求字符串中最多只能有 1024 个字符。

Post：

向后台程序传递信息的比较可靠的方法是POST方法，它把信息作为一个单独的消息，消息以标准输出的形式传到后台程序，您可以解析和使用这些标准输出

 

 

3.     session和cookie：

Session 与 Cookie 的作用都是为了保持访问用户与后端服务器的交互状态，各有优缺点：

             使用 Cookie 来传递信息时，随着Cookie个数的增多和访问量的增加，它占用的网络带宽也很大，试想假如Cookie占用 200个字节，如果一天的PV有几亿，它要占用多少带宽？所以有大访问量的时候希望Session，但是Session的致命弱点是不容易在多台服务器之间共享，所以这也限制了Session的使用。

 

Cookie：（会话cookie存储在内存中，持久cookie存储在磁盘上）

   当一个用户通过 HTTP 协议访问一个服务器的时候，这个服务器会将一些 Key/Value
键值对返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时这个用户下次访问这个服务器的时候，数据又被完整地带回给服务器。

            在一个很短的时间内，如果与用户相关的数据被频繁访问，可以针对这个数据做缓存，这样可以大大提高数据的访问性能。Cookie 的作用正是在此，由于是同一个客户端发出的请求，每次发出的请求都会带有第一次访问时服务端设置的信息，这样服务端就可以根据 Cookie值来划分访问的用户了。

 

Cookie 是 HTTP 协议头中的一个字段，虽然 HTTP 协议本身对这个字段并没有多少限制，但是 Cookie最终还是存储在浏览器里，所以不同的浏览器对 Cookie 的存储都有一些限制。

 

Session：（存储在内存中）

三种方式能让 Session正常工作：

1.      URL重写的方式：

当浏览器不支持 Cookie 功能时，浏览器会将用户的SessionCookieName 重写到用户请求的 URL 参数中

2.基于cookie

3. 基于 SSL，默认不支持，只有connector.getAttribute("SSLEnabled") 为 TRUE 时才支持

 

Session工作方式：

有了Session ID 服务端就可以创建HttpSession对象了，第一次触发通过request.getSession（）方法。如果当前的Session ID还没有对应HttpSession对象，那么久新创建一个，并将这个对象加到org.apache.catalina. Manager 的sessions 容器中保存。Manager类将管理所有Session生命周期，Session过期被回收，服务器关闭，session被序列化磁盘中等。只要HttpSession对象在，就可以根据Session
ID来获取该对象，来保持会话。

         Session和cookie安全问题：

虽然 Cookie 和 Session都可以跟踪客户端的访问记录，但是它们的工作方式显然是不同的，Cookie 通过把所有要保存的数据通过 HTTP
协议的头部从客户端传递到服务端，又从服务端再传回到客户端，所有的数据都存储在客户端的浏览器里，所以这些
Cookie 数据可以被访问到，可以被查看，甚至修改，所以安全性不高。

相比而言Session安全性较高，因为Session是将数据保存到服务器，只是通过cookie传递一个Session ID而已，比较敏感的数据还是使用Session。

 

6.  分布式Session 框架（该部分是参考了大神的博文：http://my.oschina.net/kevinair/blog/192829）

大型互联网应用系统一个应用有上百台机器，而且有很多不同的应用系统协同工作，由于 Cookie
是将值存储在客户端的浏览器里，用户每次访问都会将最新的值带回给处理该请求的服务器，所以也就解决了同一个用户的请求可能不在同一台服务器处理而导致的 Cookie 不一致的问题。

但是cookie受存储的限制，如果数据量过大即会出现超过限制就会出现丢弃 Cookie 的现象发生；cookie安全性不高，虽然可以通过设置 HttpOnly 属性防止一些私密
Cookie 被客户端访问，但是仍然不能保证 Cookie 无法被篡改。为了保证cookie安全性，通常会对cookie进行加密，但是维护这个加密key也是一件麻烦的事。

 

解决方案：

为了达成上面所说的几点目标，我们需要一个服务订阅服务器，在应用启动时可以从这个订阅服务器订阅这个应用需要的可写 Session 项和可写 Cookie 项，这些配置的 Session 和 Cookie
可以限制这个应用能够使用哪些 Session
和 Cookie，甚至可以控制 Session
和 Cookie 可读或者可写。这样可以精确地控制哪些应用可以操作哪些 Session 和 Cookie，可以有效控制 Session的安全性和 Cookie 的数量。

   统一通过订阅服务器推送配置可以有效地集中管理资源，所以可以省去每个应用都来配置 Cookie，简化 Cookie 的管理。如果应用要使用一个新增 Cookie，可以通过一个统一的平台来申请，申请通过才将这个配置项增加到订阅服务器。如果是一个所有应用都要使用的全局 Cookie，那么只需将这个 Cookie 通过订阅服务器统一推送过去就行了，省去了要在每个应用中手动增加 Cookie 的配置。

         关于这个订阅服务器现在有很多开源的配置服务器，如
Zookeeper 集群管理服务器，可以统一管理所有服务器的配置文件。

       由于应用是一个集群，所以不可能将创建的 Session 都保存在每台应用服务器的内存中，因为如果每台服务器有几十万的访问用户，服务器的内存肯定不够用，即使内存够用，这些 Session也无法同步到这个应用的所有服务器中。所以要共享这些
Session 必须将它们存储在一个分布式缓存中，可以随时写入和读取，而且性能要很好才能满足要求。当前能满足这个要求的系统有很多，如
MemCache 或者淘宝的开源分布式缓存系统 Tair
都是很好的选择。

解决了配置和存储问题，下面看一下如何存取 Session和 Cookie

既然是一个分布式 Session的处理框架，必然会重新实现 HttpSession
的操作接口，使得应用操作 Session的对象都是我们实现的 InnerHttpSession 对象，这个操作必须在进入应用之前完成，所以可以配置一个 filter 拦截用户的请求。



还有一个非常重要的问题就是如何处理跨域名来共享 Cookie
的问题。我们知道 Cookie
是有域名限制的，也就是一个域名下的 Cookie 不能被另一个域名访问，所以如果在一个域名下已经登录成功，如何访问到另外一个域名的应用且保证登录状态仍然有效，这个问题大型网站应该经常会遇到，解决方案如下：



要实现 Session 同步，需要另外一个跳转应用，这个应用可以被一个或者多个域名访问，它的主要功能是从一个域名下取得sessionID，然后将这个sessionID 同步到另外一个域名下。这个 sessionID 其实就是一个 Cookie，相当于我们经常遇到的 JSESSIONID，所以要实现两个域名下的 Session 同步，必须要将同一个
sessionID 作为 Cookie
写到两个域名下。

如果 Cookie 量非常大，可以考虑将 Cookie 也做压缩，压缩方式是将 Cookie 的多个k/v对看成普通的文本，做文本压缩。

 

防止表单重复提交：

网站中在很多地方都有表单重复提交问题，一种情况是用户在网速慢的情况下可能会重复提交表单，还有就是恶意用户通过程序来发送恶意请求，在这些情况下都要设计一个防止表单重复提交的机制。

要能够防止表单重复提交，就要标识用户的每一次访问请求，使得每一次访问对服务端来说都是唯一确定的。为了标识用户的每次访问请求，可以在用户请求一个表单域时增加一个隐藏表单项，这个表单项的值每次都是唯一的token。

当用户在请求时生成这个唯一的 token
时，同时将这个 token 保存在用户的 Session
中，等用户提交请求时检查这个 token
和当前的 Session
中保存的 token 是否一致。如果一致，说明没有重复提交，否则用户提交上来的 token 已经不是当前的这个请求的合法 token。



验证过程：



当用户提交表单时会将请求时生成的 token 带回来，这样就可以和 Session 中保存的 token 做对比，从而确认这次表单验证是否合法。

具体的token操作会后续介绍。