HTTP协议总结

1.HTTP协议解析

HTTP（HyperText Transfer Protocol）即超文本传输协议，是一种详细规定了浏览器和万维网服务器之间互相通信的规则，它是万维网交换信息的基础，它允许将HTML（超文本标记语言）文档从Web服务器传送到Web浏览器。
HTTP是一种无状态的协议，无状态是指Web浏览器与Web服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出求，然后Web服务器返回响应（Response），连接就被关闭了，在服务器端不保留连接的有关信息。即HTTP请求只能由客户端发起，而服务器不能主动向客户端发送数据。

HTTP遵循请求（Request）/应答（Response）模型，Web浏览器向Web服务器发送请求时，Web服务器处理请求并返回适当的应答
HTTP使用一种基于消息的模型：客户端发送一条请求消息，而后由服务器返回一条响应消息。

2.HTTP请求

HTTP请求包括三部分，分别是请求行（请求方法）、请求头（消息报头）和请求正文。
HTTP请求第一行为请求行，由三部分组成：
第一部分说明了该请求时POST请求；
第二部分是一个斜杠（/login.php），用来说明请求是该域名根目录下的login.php；
第三部分说明使用的是HTTP1.1版本；
HTTP请求第二行至空白行为请求头（也被称为消息头）：
HOST代表请求主机地址；
User-Agent代表浏览器的标识；
请求头由客户端自行设定；
HTTP请求第三行为请求正文，请求正文是可选的，它最常出现在POST请求方式中。
HTTP请求举例：
POST /test.php HTTP/1.1 //请求行
HOST：www.test.com //请求头
User-Agent：Mozilla/5.0 （windows NT 6.1；rv：15.0）
Gecko/20100101 Firefox/15.0 //空白行，代表请求头结束

Username=admin&password=admin //请求正文
HTTP请求方法：
GET：GET方法用于获取请求页面的指定信息。如果请求资源为动态脚本（非HTML），那么返回文本是Web容器解析后的HTML源代码。GET请求没有消息主体，因此在消息头后的空白行是没有其他数据。
POST：POST方法也与GET方法相似，但最大的区别在于，GET方法没有请求内容，而POST是有请求内容的。
HEAD：这个请求的功能与GET请求相似，不同之处在于服务器不会再其响应中返回消息主体，因此，这种方法可用于检查某一资源在向其提交GET请求前是否存在。
PUT：PUT方法用于请求服务器把请求中的实体存储在请求资源下，如果请求资源已经在服务器中存在，那么将会用此请求中的数据替换原先的数据。向服务器上传指定的资源。

3.HTTP响应

HTTP响应的第一行为响应行，其中有HTTP版本（HTTP/1.1）、状态码（200）以及消息“OK”。
第二行至末尾的空白行为响应头，由服务器向客户端发送。
消息头之后是响应正文，是服务器向客户端发送的HTML数据。
HTTP响应示例：

HTTP常见的状态码：
200：客户端请求成功，是最常见的状态。
302：重定向。
404：请求资源不存在，是最常见的状态。
400：客户端请求有语法错误，不能被服务器所理解。
401：请求未经授权。
403：服务器收到请求，但是拒绝提供服务。
500：服务器内部错误，是最常见的状态。
503：服务器当前不能处理客户端的请求。

4.HTTP消息头

HTTP消息头包括以下两种：
1.请求头：请求头只出现在HTTP请求中，请求报头允许客户端向服务端传递请求的附加信息和客户端自身信息。
2.响应头：响应头是服务器根据请求向客户端发送的HTTP头。
常见的请求头：
Host 请求报头域主要用于指定被请求资源的Internet主机和端口。
User-Agent 请求报头域允许客户端将它的操作系统、浏览器和其他属性告诉服务器。
Referer 包含一个URL，代表当前访问URL的上一个URL，也就是说，用户是从什么地方来到本页面。当前请求的原始URL地址。
Cookie 是非常重要的请求头，常用来表示请求者的身份等。
Accept 这个消息头用于告诉服务器客户端愿意接受那些内容，比如图像类，办公文档格式等等。
常见的响应头：
Server 服务器使用的Web服务器名称。
Location 服务器通过这个头告诉浏览器去访问哪个页面，浏览器接收到这个请求之后，通常会立刻访问Location头所指向的页面。用于在重定向响应中说明重定向的目标地址。
Content-Type 这个消息头用于规定主体的内容类型。例如，HTML文档的内容类型text/html。
Content-Encoding 这个消息头为消息主体中的内容指定编码形式，一些应用程序使用它来压缩响应以加快传输速度。
Content-Length 消息头规定消息主体的字节长度。实体头用于指明实体正文的长度，以字节方式存储的十进制数字来表示。
Connection 允许发送指定连接的选项。

5.会话与会话状态

WEB应用中的会话是指一个客户端浏览器与WEB服务器之间连续发生的一系列请求和响应过程。
WEB应用的会话状态是指WEB服务器与浏览器在会话过程中产生的状态信息，借助会话状态，WEB服务器能够把属于同一会话中的一系列的请求和响应过程关联起来。
实现有状态的会话：
1.WEB服务器端程序要能从大量的请求消息中区分出哪些请求消息属于同一个会话，即能识别出来自同一个浏览器的访问请求，这需要浏览器对其发出的每个请求消息都进行标识，属于同一个会话中的请求消息都附带同样的标识号，而属于不同会话的请求消息总是附带不同的标识号，这个标识号就称之为会话ID（SessionID）。
2.会话ID可以通过一种称之为Cookie的技术在请求消息中进行传递，也可以作为请求URL的附加参数进行传递。会话ID是WEB服务器为每个客户端浏览器分配的一个唯一代号，它通常是在WEB服务器接收到某个浏览器的第一次访问时产生，并且随同响应消息一道发送给浏览器。
3.会话过程由WEB服务器端的程序开启，一旦开启了一个会话，服务器端程序就要为这个会话创建一个独立的存储结构来保存该会话的状态信息，同一个会话中的访问请求都可以且只能访问属于该会话的存储结构中的状态信息。

6.Cookie

Cookie是一种在客户端保持HTTP状态信息的技术。
Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一片数据。
一旦WEB浏览器保存了某个Cookie，那么它在以后每次访问该WEB服务器时，都应在HTTP请求头中将这个Cookie回传给WEB服务器。
Cookie是一小段文本信息，伴随着用户请求和页面在Web服务器和浏览器之间传递。Cookie包含每次用户访问站点时Web应用程序都可以读取的信息。
Cookie只是一段文本，所以它只能保存字符串。
Cookie的传送过程示意图 ：

cookie功能特点：
1.存储于浏览器头部/传输于HTTP头部。
2.写时带属性，读时无属性。
3.HTTP头中Cookie: user=bob; cart=books。
4.属性 name/value/expire/domain/path/httponly/secure/…。
5.由三元组[name,domain,path]唯一确定cookie。
6.唯一确定不等于cookie唯一。

a.Set-Cookie2响应头字段

1.Set-Cookie2头字段用于指定WEB服务器向客户端传送的Cookie内容，但是按照Netscape规范实现Cookie功能的WEB服务器，使用的是Set-Cookie头字段。
2.Set-Cookie2头字段中设置的cookie内容是具有一定格式的字符串，它必须以Cookie的名称和设置值开头，格式为“名称=值”，后面可以加上0个或多个以分号（;）和空格分隔的其它可选属性，属性格式一般为“属性名=值”。
3.除了“名称=值”对必须位于最前面外，其它的可选属性的先后顺序可以任意。
4.Cookie的名称只能由普通的英文ASCII字符组成，浏览器不用关心和理解Cookie的值部分的意义和格式，只要WEB服务器能理解值部分的意义就行。
5.大多数现有的WEB服务器都是采用某种编码方式将值部分的内容编码成可打印的ASCII字符，RFC 2965规范中没有明确限定编码方式。
例如：Set-Cookie2: user=hello; Version=1; Path=/
Set-Cookie2头字段中的属性：
Comment=value
Discard
Domain=value
Max-Age=value
Path=value
Port[=“portlist”]
Secure
Version=value
例如：Set-Cookie2: user=hello; Version=1; Path=/; Domain=.hello.org

b.Cookie请求头字段

1.Cookie请求头字段中的每个Cookie之间用逗号（,）或分号（;）分隔。
2.在Cookie请求头字段中除了必须有“名称=值”的设置外，还可以有Version、Path、Domain、Port等几个属性。
3.在Version、Path、Domain、Port等属性名之前，都要增加一个“$”字符作为前缀。
4.Version属性只能出现一次，且要位于Cookie请求头字段设置值的最前面，如果需要设置某个Cookie信息的Path、Domain、Port等属性，它们必须位于该Cookie信息的“名称=值”设置之后。
5.浏览器使用Cookie请求头字段将Cookie信息回送给WEB服务器。
6.多个Cookie信息通过一个Cookie请求头字段回送给WEB服务器。
7.浏览器根据下面的几个规则决定是否发送某个Cookie信息：
请求的主机名是否与某个存储的Cookie的Domain属性匹配；
请求的端口号是否在该Cookie的Port属性列表中；
请求的资源路径是否在该Cookie的Path属性指定的目录及子目录中；
该Cookie的有效期是否已过。
8.Path属性指向子目录的Cookie排在Path属性指向父目录的Cookie之前。
例如：Cookie: $Version=1; Course=Java; $Path=/hello/lesson; Course=vc; $Path=/hello

c.Cookie的安全属性

1.secure属性
当设置为true时，表示创建的Cookie会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是HTTP连接则不会传递该信息，所以不会被窃取到Cookie 的具体内容。
2.HttpOnly属性
如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。
secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取cookie后进行攻击。
这两个属性并不能解决cookie在本机出现的信息泄漏的问题(FireFox的插件FireBug能直接看到cookie的相关信息)。

7.Session

Session技术是一种将会话状态保存在服务器端的技术。
客户端需要接收、记忆和回送Session的会话标识号，Session可以且通常是借助Cookie来传递会话标识号。

a.Session的跟踪机制

1.Servlet API规范中定义了一个HttpSession接口，HttpSession接口定义了各种管理和操作会话状态的方法。
2.HttpSession对象是保持会话状态信息的存储结构，一个客户端在WEB服务器端对应一个各自的HttpSession对象。
3.WEB服务器并不会在客户端开始访问它时就创建HttpSession对象，只有客户端访问某个能与客户端开启会话的Servlet程序时，WEB应用程序才会创建一个与该客户端对应的HttpSession对象。
4.WEB服务器为HttpSession对象分配一个独一无二的会话标识号，然后在响应消息中将这个会话标识号传递给客户端。客户端需要记住会话标识号，并在后续的每次访问请求中都把这个会话标识号传送给WEB服务器，WEB服务器端程序依据回传的会话标识号就知道这次请求是哪个客户端发出的，从而选择与之对应的HttpSession对象。
5.WEB应用程序创建了与某个客户端对应的HttpSession对象后，只要没有超出一个限定的空闲时间段，HttpSession对象就驻留在WEB服务器内存之中，该客户端此后访问任意的Servlet程序时，它们都使用与客户端对应的那个已存在的HttpSession对象。
6.HttpSession接口中专门定义了一个setAttribute方法来将对象存储到HttpSession对象中，还定义了一个getAttribute方法来检索存储在HttpSession对象中的对象，存储进HttpSession对象中的对象可以被属于同一个会话的各个请求的处理程序共享。

b.Session的超时管理

1.WEB服务器采用“超时限制”的办法来判断客户端是否还在继续访问，如果某个客户端在一定的时间之内没有发出后续请求，WEB服务器则认为客户端已经停止了活动，结束与该客户端的会话并将与之对应的HttpSession对象变成垃圾。
2.如果客户端浏览器超时后再次发出访问请求，WEB服务器则认为这是一个新的会话的开始，将为之创建新的HttpSession对象和分配新的会话标识号。
3.会话的超时间隔可以在web.xml文件中设置，其默认值由Servlet容器定义。
例如：

c.利用Cookie实现Session跟踪

1.如果WEB服务器处理某个访问请求时创建了新的HttpSession对象，它将把会话标识号作为一个Cookie项加入到响应消息中，通常情况下，浏览器在随后发出的访问请求中又将会话标识号以Cookie的形式回传给WEB服务器。
2.WEB服务器端程序依据回传的会话标识号就知道以前已经为该客户端创建了HttpSession对象，不必再为该客户端创建新的HttpSession对象，而是直接使用与该会话标识号匹配的HttpSession对象，通过这种方式就实现了对同一个客户端的会话状态的跟踪。

d.利用URL重写实现Session跟踪

1.Servlet规范中引入了一种补充的会话管理机制，它允许不支持Cookie的浏览器也可以与WEB服务器保持连续的会话。这种补充机制要求在响应消息的实体内容中必须包含下一次请求的超链接，并将会话标识号作为超链接的URL地址的一个特殊参数。
2.将会话标识号以参数形式附加在超链接的URL地址后面的技术称为URL重写。如果在浏览器不支持Cookie或者关闭了Cookie功能的情况下，WEB服务器还要能够与浏览器实现有状态的会话，就必须对所有可能被客户端访问的请求路径（包括超链接、form表单的action属性设置和重定向的URL）进行URL重写。
3.HttpServletResponse接口中定义了两个用于完成URL重写方法：
encodeURL方法；
encodeRedirectURL方法；

8.Cookie和session的不同

1.cookie数据存放在客户的浏览器上，session数据放在服务器上。
2.cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。
3.session会在一定时间内保存在服务器上。当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。
4.单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。
5.生命周期不同，session生命周期：在指定的时间（如20分钟）到了之后会结束，不到指定的时间，也会随着浏览器进程的结束而结束。
cookies默认情况下也随着浏览器进程结束而结束，但如果手动指定时间，则不受浏览器进程结束的影响。

9.HTTP其它相关

1.网站登陆–身份认证：
一个页面是否能够被访问，判断依据是通过存储信息区域中用户的信息来判断的；
而登录页面的作用就是验证用户输入的用户名+密码的组合是否在数据库中存在，如果存在则把信息保存在存储信息的区域，以便各个页面去判断权限。

2.cookie漏洞包括泄露、缺乏完整性保护等、cookie防御使用HTTPS等。
3.拦截HTTP请求：
Fiddler：
Fiddler是一个http协议调试代理工具，它能够记录并检查所有你的电脑和互联网之间的http通讯，设置断点，查看所有的“进出”Fiddler的数据（指cookie,html,js,css等文件）。
Burp Suite：
Burp Suite是用于攻击web应用程序的集成平台。它包含了许多工具，并为这些工具设计了许多接口，以促进加快攻击应用程序的过程。所有的工具都共享一个能处理并显示HTTP消息，持久性，认证，代理，日志，警报的一个强大的可扩展的框架。