一、HTTP协议

二、WEB容器和TOMCAT

三、Session和Cookie机制

四、跨域请求

五、XSS攻击

一、HTTP协议
什么是？HTTP超文本传输协议，是B/S架构的核心，属于OSI应用层的一种通信协议，建立在TCP、IP协议之上；
Http报文由三部分组成：
起始行：HTTP/1.0 200 OK
首部（Header）：包含属性，主要对两端(说明浏览器类型等)、请求(Content-type、Content-length)等的描述
主体（Body）：包含数据

HTTP请求交互过程：
（1）浏览器解析出主机名；
（2）浏览器查询这个主机IP地址（DNS）
（3）浏览器获得端口号（80）
（4）浏览器发起连接；
（5）浏览器向服务器发送一条HTTP报文；
（6）浏览器从服务器读取HTTP响应报文；
（7）浏览器关闭连接；
二、WEB容器和Tomcat
容器是一种服务调用规范框架，J2EE大量运用了容器和组件技术来构建分层的企业级应用。
WEB容器给处于其中的应用程序组件（JSP，Servlet）提供一个环境。web容器主要由web服务器来实现，Tomcat、weblogic、WebSphere等。
容器提供的接口遵守J2EE规范；
web容器的作用：
通信支持
利用容器提供的方法，实现servlet与web容器的对话。没有容器需要写监听端口；
生命周期管理
容器负责servlet的整个生命周期管理。如何加载类，实例化和初始化servlet，调用servlet方法，并使servlet实例能够被垃圾回收。有了容器，我们就不用花精力去考虑这些资源管理垃圾回收之类的事情。
多线程支持
容器会自动为接收的每个servlet请求创建一个新的java线程，servlet运行完成后，容器会自动结束这个线程。
声明式安全
利用容器，可以使用xml部署描述文件类配置安全性，而不必将其硬编码到servlet中
JSP支持
容器将jsp翻译成java

容器处理请求的过程：
client请求一个url，其url指向一个servlet而不是静态页面。
容器识别出这个请求索要的是一个servlet，所以创建两个对象：httpservletrequest，httpservletresponse
容器根据请求中的url找到对应的servlet，为这个请求创建或分配一个线程，并把两个对象request和response传递到servlet线程中。
容器调用servlet的service()方法，根据请求的不同类型，service（）方法会调用doGet（）和doPost（）方法
doGet或doPost方法生产动态页面，然后把这个页面填入到response对象中，此时容器仍然拥有response对象的引用。
线程结束。容器把response对象转换成http响应，传回client，并销毁response和request对象。

Tomcat总体结构
http://blog.csdn.net/jiaomingliang/article/details/47393141

Tomcat设计非常模块化，通过Server、Service、Engine、Host、Context层层包装已经Connector连接器，组合而成。
Tomcat加载组件时相应组件（容器）的配置参数都是从Server.xml读进去的，这个文件也是tomcat配置及优化的关键。
1、Server：
Server是tomcat的最顶层组件，它可以包含多个Service组件。它要完成的任务就是提供一个接口让其他程序能够访问到它的service集合，同时要维护它的service的生命周期。还包括一些其他次要任务。
它的标准实现类StandardServer

LifeStyle是tomcat的生命周期接口。
Connector：是tomcat中监听TCP网络连接的组件

2、Service：
Service组件相当于Connector和Container容器的包装器，它将一个或多个Connector组件和Container建立关联
Container是一个上层接口，他的子接口包括：Engine、Host、Context（tomcat中的容器概念）
Engine：最顶层的容器，一个Engine可以包含一个或多个Host，也就是说我们一个Tomcat的实例可以配置多个虚拟机。
Host：host定义了一个虚拟主机，一个虚拟主机可以有多个Context，
Context：在tomcat中，每一个运行的webapp其实最终都是以Context的形式存在，每个Context都有一个根路径和请求的url路径
在tomcat中我们通常采用如下两种方式创建一个Context
1、在<CATALINA-HOME>\webapps目录中创建一个目录，这个时候将自动创建一个Context，默认url为http://host:port/dirname，也可以通过在ContextRoot\META-INF中创建一个context.xml的文件，其中包含如下的内容来指定应用的访问路径。<Context path="/yourUrlPath" />
2、conf\server.xml文件中增加context元素。在<HOST>元素增加：

<Context path="/mypath" docBase="/Users/xxx" reloadable="true"></Context>  

Value：中文意思是阈门，Value是tomcat中责任链模式的实现，通过链接多个Value对请求进行处理。每个容器都有一个流水线Pipeline（过滤器链），每个流水线至少有一个阈门。其中Value可以定义在任何Container中，上面说的Engine、host、Context都属于容器。tomcat默认定义了一个名为org.apache.catalina.valves.AccessLogValve的Value，这个Value负责拦截每个请求，然后记录一条日志。

通过上面的分析，我们发现Server、Service、Engine、Host、Context都实现了org.apache.catalina.Lifecycle接口，通过这个接口管理了这些核心组件的生命周期。

Tomcat中的设计模式
1、责任链模式
Tomcat中最容易发现的设计模式就是责任链模式，这个设计模式也是Tomcat中Container设计的基础，整个容器就是通过一个链连接在一起的，这个链一直将请求正确的传递给最终处理请求的那个Servlet。
2、观察者模式
控制组件生命周期的Lifecycle；还有对Servlet实例的创建、Session的管理、Container等

3、命令模式
Connector和Container组件之间，Tomcat作为一个应用服务器，会接收到很多请求，
4、门面模式

三、会话跟踪机制
  会话跟踪机制概述：会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。
1、Cookie机制
  在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。
  Cookie机制可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

   Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

  Java中把Cookie封装成了javax.servlet.http.Cookie类。每个Cookie都是该Cookie类的对象。服务器通过操作Cookie类对象对客户端Cookie进行操作。通过request.getCookie()获取客户端提交的所有Cookie（以Cookie[]数组形式返回），通过response.addCookie(Cookiecookie)向客户端设置Cookie。  
  Cookie对象使用key-value属性对的形式保存用户状态，一个Cookie对象保存一个属性对，一个request或者response同时使用多个Cookie。因为Cookie类位于包javax.servlet.http.*下面，所以JSP中不需要import该类。
  Cookie在客户端是由浏览器来管理的。Cookie具有不可跨域名性。
Unicode编码：保存中文
  中文与英文字符不同，中文属于Unicode字符，在内存中占4个字符，而英文属于ASCII字符，内存中只占2个字节。Cookie中使用Unicode字符时需要对Unicode字符进行编码，否则会乱码。
提示：Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码，因为浏览器不一定支持，而且JavaScript也不支持GBK编码。BASE64编码：保存二进制图片
  Cookie不仅可以使用ASCII字符与Unicode字符，还可以使用二进制数据。例如在Cookie中使用数字证书，提供安全度。使用二进制数据时也需要进行编码。
注意：本程序仅用于展示Cookie中可以存储二进制内容，并不实用。由于浏览器每次请求服务器都会携带Cookie，因此Cookie内容不宜过多，否则影响速度。Cookie的内容应该少而精。

2、 Session机制

Session是服务器端使用的一种记录客户端状态的机制。

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对，通过getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的Session。

Session的生命周期

Session在用户第一次访问服务器的时候自动创建（request.getSession(true)）。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。

(Session需要使用Cookie作为识别标志。服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。该Cookie为服务器自动生成的，它的maxAge属性一般为–1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。)

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

Session的有效期（Tomcat默认20min）。如果超过了超时时间没访问过服务器，Session就自动失效了。Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。

Session的销毁只有两种情况：

第一：session调用了session.invalidate()方法

第二：前后两次请求超出了session指定的生命周期时间

Session对浏览器的要求

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户

同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。

注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在链接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗口便可以访问父窗口的Session。

URL地址重写

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写，例如：

<td>
  <a href="<%=response.encodeURL("index.jsp?c=1&wd=Java") %>"> Homepage</a>
</td>

该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。重写后的输出可能是这样的：

<td>
  <ahref="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=1&wd=Java">Homepage</a>
</td>

即在文件名的后面，在URL参数的前面添加了字符串“;jsessionid=XXX”。其中XXX为Session的id。分析一下可以知道，增添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把Session的id通过URL提交到服务器上，服务器通过解析URL地址获得Session的id。

如果是页面重定向（Redirection），URL地址重写可以这样写：

<%
 if(“administrator”.equals(userName))  {
  response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));
  return;
 }
%>

效果跟response.encodeURL(String url)是一样的：如果客户端支持Cookie，生成原URL地址，如果不支持Cookie，传回重写后的带有jsessionid字符串的地址。

对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。

注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。

Session中禁止使用Cookie

既然WAP上大部分的客户浏览器都不支持Cookie，索性禁止Session使用Cookie，统一使用URL地址重写会更好一些。Java Web规范支持通过配置的方式禁用Cookie。下面举例说一下怎样通过配置禁止使用Cookie。

打开项目sessionWeb的WebRoot目录下的META-INF文件夹（跟WEB-INF文件夹同级，如果没有则创建），打开context.xml（如果没有则创建），编辑内容如下：

代码/META-INF/context.xml

<?xml version='1.0' encoding='UTF-8'?>
<Context path="/sessionWeb"cookies="false">
</Context>

或者修改Tomcat全局的conf/context.xml，修改内容如下：

代码context.xml

<!-- The contents of this file will be loaded for eachweb application -->
<Context cookies="false">
  <!-- ... 中间代码略 -->
</Context>

部署后TOMCAT便不会自动生成名JSESSIONID的Cookie，Session也不会以Cookie为识别标志，而仅仅以重写后的URL地址为识别标志了。

注意：该配置只是禁止Session使用Cookie作为识别标志，并不能阻止其他的Cookie读写。也就是说服务器不会自动维护名为JSESSIONID的Cookie了，但是程序中仍然可以读写其他的Cookie。