模拟登陆的背后

浏览器和服务器(session)之间的相互识别,是通过服务器端session的id来识别的，现在具体描述一个浏览器和服务器之间会话的过程：

1. 浏览器第一次向指定服务器发送请求；

2.服务器接收到请求创建一个session对象(会话)，session对象具有一个唯一标识的属性id;

3.服务器在给客户端的响应报文中，以cookie的形式将sessionid返回给客户端（tomcat和jetty服务器环境下，这个cookie的名称为jsessionid），客户端接收到响应报文中响应头内的cookie,将其存在浏览器（这个cookie在浏览器关闭时自动销毁）；

4. 第二次请求服务器时，服务器端返回的cookie被带在了请求头中，服务器端获取到客户端传来的cookie值后和服务器上已存在的session匹配。如果匹配上了，则在匹配上的session基础上完成后续操作，可以使用session中存储的数据，以后的响应头中不含sessionid。如果服务器端没有能够匹配的session,则创建一个新的session对象，执行过程3.

遇到的一些现象及其原理：

1.现象： 电脑短时间断网，等网络恢复后发现原来的登录状态任然存在。

原理：客户端的网络虽然断了，但是浏览器没有关闭cookie没有销毁仍然存在，等网络恢复后，只要服务器端session还存在（maxInactiveInterval时间内），客户端提供的cookie任然能够和服务器端的session匹配，可以继续进行断网前的操作。

2.现象：清空了浏览器的cookie，发现浏览器没有关闭，但是操作网页时不能正常操作，跳到了登录页，显示请重新登录。

原理：此种情况是浏览器和服务器端session匹配的cookie丢失导致浏览器无法提供和服务器端匹配的key,导致登录失效，不得不重新登录，服务器端创建新的session对象。原有的session对象则在maxInactiveInterval时间结束后自动销毁。同样，客户端如果长时间不向服务器端发送请求，登录状态也会失效，当请求间隔时间超过session的maxInactiveInterval,session自动销毁，等客服端再向服务器端发送请求时就找不到能够匹配的session,不得不重新创建session,原来的客户端的cookie值也会被新返回的cookie值替换。

一些网页禁止抓取：

可以在代码中模拟客户端欺骗服务器，具体做法是在请求头中加入UserAgent（用户代理）属性及其值，值可以用浏览器的。

 

总结：决定服务畅通的关键是客户端和服务器端都能够提供相互匹配的标识，无论任意一方出现问题，服务都会出现问题。模拟登陆登陆状态的保存，要点在于在第二（非第一次）次请求时将第一次响应头中的cookie值设置到请求头中，实现客户端本次请求和上次会话的对接。

简单瞄了下，这篇文章也是讲模拟登陆的，还有代码实现：

http://www.cnblogs.com/moon-mountain/archive/2012/02/11/2346922.html