（三）HTTP再邂逅--熟悉HTTP协议结构和通讯原理

HTTP协议特点

支持客户/服务器模式
客户/服务器模式工作的方式是由客户端向服务器发出请求，服务器端响应请求，并进行相应服务

简单快速
客户向服务器请求服务时，只需传送请求方法和路径
请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同
由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快

灵活
HTTP允许传输任意类型的数据对象
正在传输的类型由Content-Type（Content-Type是HTTP包中用来表示内容类型的标识）加以标记

无连接
无连接的含义是限制每次连接只处理一个请求
服务器处理完客户的请求，并收到客户的应答后，即断开连接
采用这种方式可以节省传输时间

无状态
HTTP协议是无状态协议
无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大
另一方面，在服务器不需要先前信息时它的应答就较快

URL和URI的区别和联系

Q：我们输入在浏览器里的Web地址应该叫URL还是URI?
小A：我们访问的就是URL!
小B：不！其实那是URI好不好！

URI：一个紧凑的字符串用来标示抽象或物理资源
A URI可以进一步被分为定位符、名字或者两者都是
术语“Uniform Resource Locator”（URL）是URI的子集，除了确定一个资源，还提供一种定位该资源的主要访问机制（如其网络“位置”）

URI可以分为URL,URN或同时具备locators和names特性的一个东西
URN作用就好像一个人的名字，URL就像一个人的地址
换句话说：URN确定了东西的身份，URL提供了找到它的方式

URL是URI的一种，但不是所有的URI都是URL
URI和URL最大的差别是"访问机制"
URN是唯一标识的一部分，是身份信息

以上tel:+1-816-555-1212是URI，最后一个是URN，其余都是URL，有访问机制，有protocol

HTTP报文结构分析

HTTP报文结构分析-请求报文

HTTP报文头
HTTP的报文头大体可以分为四类，分别是：
通用报文头、请求报文头、响应报文头和实体报文头

在HTTP/1.1里一共规范了47种报文头字段

通用报文头

请求报文头

响应报文头

实体报文头
实体：请求里面一些报文相应信息

ACCEPT
作用：浏览器端可以接受的媒体类型
Accept：text/html 代表浏览器可以接受服务器回发的类型为text/html，也就是我们常说的html文档，如果服务器无法返回text/html类型的数据，服务器应该返回一个406错误（Non Acceptable）
Accept：/ 代表浏览器可以处理所有类型
如果想要给显示的媒体类型增加优先级，则使用q=来额外表示权重值，重值q的范围是0-1（可精确到小数点后3位），且1为最大值。不指定权重q值时，默认权重q=1.0，当服务器提供多种内容时，将会首先返回权重值更高的媒体类型

ACCEPT-Encoding
作用：浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）
ACCEPT-Encoding:gzip,deflate

ACCEPT-Language
作用：浏览器申明自己接收的语言

ACCEPT-Language:zh-cn,zh;q=0.7,en-us,en;q=0.3

客户端在服务器有中文版资源的情况下，会请求其返回中文版对应的响应，没有中文版时，则请求返回英文版响应

Connection
Connection:keep-alive 当一个网页打开完成后，客户端和服务端之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接

Connection:close 代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭，当客户端再次发送Request，需要重新建立TCP连接

Host
作用：请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的

我们在浏览器中输入：http://www.fljf.com:8080

浏览器发送的请求消息中，就会包含Host请求报文域，如下：
Host: www.fljf.com:8080

Referer
当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器借此可以获得一些信息用于处理

User-Agent
作用：告诉HTTP服务器，客户端使用的操作系统和浏览器的名称和版本
很多情况下我们会通过User-Agent来判断浏览器类型，从而进行不同的兼容设计

Content-Type
作用：说明了报文体内对象的媒体类型
application/xhtml+xml：XHTML格式
application/xml：XML数据格式
application/atom+xml：Atom XML聚合格式
application/json：JSON数据格式
application/pdf：pdf格式
application/msword：Word文档格式
application/octet-stream：二进制流数据（如常见的文件下载）
application/x-www-form-urlencoded：表单提交

HTTP报文结构分析-响应报文

HTTP请求方法剖析

HTTP/1.1 常用方法
GET
POST
PUT
HEAD
DELETE
OPTIONS
TRACE
CONNECT

GET 获取资源
GET方法用来请求访问已被URI识别的资源
指定的资源经服务器端解析后返回响应内容

GET
GET方法也可以用来提交表单和其他数据
http://localhost/login.php?username=aa$password=1234
从上面的URL请求中，很容易就可以辨认出表单提交的内容
同时，浏览器对于提交URL的长度也有所限制

url提交的数据是作为我们GET请求的一部分，所以提交的数据量不能特别大，浏览器对url长度有限制，ie是2803，firefox是65536，chrome是8182

POST
POST方法与GET功能类似，一般用来传输实体的主体
POST方法的主要目的不是获取响应主体的内容

请求头和请求主体中间要加一行换行，空一行下面就是我们表单提交的数据

克服了GET缺点，通过POST数据时，数据不是作为url请求的一部分，而且通过标准数据传送给WEB服务器，这就克服了GET方法数据无法保密，数据信息量太小的缺点

GET是通过url提交数据，数据可以在url上看到，POST数据是放在HTTP包的body里面；GET有大小限制，POST没有；安全性方面，GET使用的参数会显示在地址栏上，而POST不会

PUT
从客户端向服务器传送的数据取代指定的文档的内容
PUT方法与POST方法最大的不同是：PUT是幂等的，而POST是不幂等的
因此，我们更多时候将PUT方法用作传输资源

幂等就是不管进行多少次的重复操作，都是实现相同的结果
所以一般来说创建用POST,更新用PUT
但是鉴于HTTP1.1，它的PUT方法自身不带有验证机制，其实是存在一定的安全性问题的
所以后端逻辑里面POST也可以处理成更新

HEAD
类似于GET请求，只不过返回的响应中没有具体的内容，用于获取报头

HEAD方法和GET方法几乎是相同的，它们的区别在于HEAD方法只是请求消息的报文头而不是完整的内容，而对于HEAD请求的回应部分来说，它的HTTP头部信息中包含的信息与通过GET请求得到的信息是相同的，所以利用这个方法，我们就不必要去传输整个的资源内容就可以得到我们想要请求的那个RequestUri所标识的资源信息，所以我们的HEAD方法经常用来测试我们超链接的有效性，去测试我们的链接能不能访问以及最近是不是有更新，现在我们从网上下载的很多超链接探测工具，很多用的是HEAD方法去实现的

DELETE
请求服务器删除指定的资源
与PUT相反的
根据我们请求的URI去删除资源，但是HTTP1.1里，和PUT方法一样，不带有验证机制

OPTIONS
用来查询针对请求URI指定的资源支持的方法
常用来不知道对方支持什么样的方法，进行询问下

TRACE
回显服务器收到的请求，主要用于测试或诊断
客户端可以通过TRACE方法查询发送出去的请求是到底怎么样被加工修改或者被篡改，这是因为请求想要连接到原目标服务器时，可能会通过代理中转，TRACE方法是用来确认连接过程中发生的一系列操作，看看中转的过程，但是TRACE方法特别容易引发一种跨站追踪攻击

CONNECT
开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道

HTTP代理时，我们在使用代理服务器访问互联网时就是使用CONNECT方法，具体来说，我们要通过HTTP代理来访问FaceBook，首先浏览器向代理服务器发送一个CONNECT请求，代理服务器返回HTTP 200，连接已经建立了，之后浏览器和服务器就开始握手并交换数据，代理服务器只负责传输彼此的数据包，不能读取具体的数据内容，不管HTTPS还是HTTP都一样

HTTP响应状态码拆解

是用以表示网页服务器超文本传输协议响应状态的3位数字代码


常用HTTP状态码

206客户端只想向服务器请求部分资源的时候，所以会加上range的消息头来表明我要请求哪份
应用场景：资源下载一半没下载完，下次下载的时候从上次下载的地方开始下载，这叫断点续传


4开头状态码表示服务器接收到也处理完成了，但结果可能和你客户端预想的不太一样

5开头状态码大多数我们发出的请求没问题，只是服务器处理异常

用telnet分析http协议的通讯过程

开启telnet客户端功能：控制面板 > 右上角查看方式改成小图标 > 程序和功能 > 点击启用或关闭windows功能
windows+R调出命令行工具，输入telnet

Test 1

Test 2

Test 3

Test 4

Test 5

HTTP状态管理：Cookie与Session（会话跟踪技术）

Cookie
Cookie实际上是一小段的文本信息，客户端请求服务器，如果服务器需要记录该用户状态，就向客户端浏览器颁发一个Cookie

客户端浏览器会把Cookie保存起来，当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态，服务器还可以根据自己的需要修改cookie的内容

浏览器输入访问地址，浏览器会向服务器发送一个读取网页的请求并且把这个结果在显示器上显示，在发送之前，这个网页在你的电脑寻找Cookie文件，如果找到浏览器会将Cookie里的数据连同前面说的url一同发送给服务器，服务器收到Cookie数据就会在数据库中检索你的id，你的购物信息，记录，个人爱好等等，并且记录下这次新的内容，增加到数据库和Cookie文件里面去，如果没有检测到Cookie信息，或者Cookie信息和数据库里的不符合，那说明是第一次浏览这个网站，服务器就会创建一个新的id，并保存到数据库里，并给你发一个Cookie

Cookie工作原理

Session
Session是另一种记录客户状态的机制，保存在服务器上，客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上
客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了

Session工作原理
客户端保存SessionID的正是我们的Cookie，这样交互过程中浏览器就可以自动地按照规则把SessionID标识发送给服务器

保存Session ID的方式

• Cookie
  通过Cookie保存SessionID是最常用的，但是可以人为的可以把Cookie给禁止掉，如果Cookie被禁止，就不能保存SessionID,可以考虑使用URL重写与隐藏表单

• URL重写
  http://…/xxx;Sessionid=Session ID
  http://…/xxx?Sessionid=Session ID

• 隐藏表单
  服务器会自动修改表单，添加隐藏的字段，以便表单提交时能把SessionID传递给服务器上

Session的有效期
Session超时失效：Cookie有效时间一般特别久，Session会有越来越多的用户来访问服务器，Session越来越多，为了防止内存溢出，服务器就会把长时间没有活跃的Session从内存里删掉，这个时间就是Session超时时间，如果超过这个时间没有访问服务器，Session就会自动失效

程序调用HttpSession.invalidate()：主动失效，退出注销调用HttpSession.invalidate()

服务器进程被停止：服务器一般把缓存放在内存里，一旦服务器异常终止，Session也会失效

Cookie与Session
存放位置不同：Cookie存在客户端，Session存在服务端
安全性（隐私策略）的不同：Cookie在客户端，对客户端是可见的，有可能会被修改
有效期上的不同：Cookie可以设置很久，Session需要定期清理来进行减压，Cookie对SessionID默许是-1，所以只要关闭浏览器，就是一次会话结束，这个Session就失效了
对服务器压力的不同：Session对服务器压力大