*********************HTTP基本交互***************************
HTTP请求格式：
HTTP 请求由三部分组成：请求行、请求头和请求正文
请求行： 请求方法 URL 协议/版本
例如：GET /books/?sex=man&name=Professional HTTP/1.1
请求方法有很多，例如：GET Post HEAD PUT DELETE 等等
GET与Post的区别：
1、在客户端，GET方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放在HTTP包的body中。
2、GET方式提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST则没有此限制。
3、安全性问题。正如在（1）中提到，使用 GET 的时候，参数会显示在地址栏上，而 Post 不会。所以，
如果这些数据是中文数据而且是非敏感数据，
那么使用 GET；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。
4.、服务器取值方式不一样。GET方式取值，如php可以使用$_GET来取得变量的值，而POST方式通过$_POST
来获取变量的值
5. 安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。幂等的意味着对同一 URL 的多
个请求应该返回同样的结果Get操作一般不会产生副作用。POST 表示可能改变服务器上的资源的请求。
仍然以新闻站点为例，读者对文章的注解应该通过 POST 请求实现，因为在注解提交之后站点已经不同了
HEAD方法跟GET方法相同，只不过服务器响应时不会返回消息体。一个HEAD请求的响应中，HTTP头中包含的元信
息应该和一个GET请求的响应消息相同。
这种方法可以用来获取请求中隐含的元信息，而不用传输实体本身。也经常用来测试超链接的有效性、可用性
和最近的修改。欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确。
put 和post的区别：这两个方法都有更新或者创建资源的意思
但是put和post有什么区别呢：
在HTTP中，PUT被定义为idempotent的方法，POST则不是，这是一个很重要的区别。
idempotent的意思就是说一个方法重复执行多次，产生的效果是一样，就是idempotent的
假如我们发送两个http://superblogging/blogs/post/Sample请求，服务器端是什么样的行为？如果产生了
两个博客帖子，那就说明这个服务不是idempotent的，
因为多次使用产生了副作用了嘛；如果后一个请求把第一个请求覆盖掉了，那这个服务就是idempotent的。
前一种情况，应该使用POST方法，后一种情况，应该使用PUT方法。
请求头：
每个头域由一个域名，冒号（:）和域值三部分组成。
常见的请求头如下：
Transport头域：
Connection:Keep-Alive 表示是否需要持久连接，HTTP1.1版本还引入了管道机制(pipelining)
即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率
服务器也可以传送多个回应，所以需要一种机制区分数据报是属于哪一种回应，这就是Content-length
这个字段所起的作用，比如本次回应的长度是100个字节，后面的字节就属于下一个回应了
Host头域：
Host请求报头域主要用于指定被请求资源的Internet主机和端口号
Client头域：
Accept:浏览器可以接受的媒体类型，例如text,html,image等等，如果是*/*则表示浏览器可以接受所有类型
Accept-Encoding：浏览器申明自己接收的编码方法，通常指定压缩方法
Accept-Language： 浏览器声明自己接受的语言
User-Agent:告诉HTTP服务器，客户端使用的操作系统和浏览器的名称和版本
Accept-Charset：浏览器声明自己接受的字符集
Cookie/Login 头域：
Cookie: 将Cookie的值发送给HTTP 服务器
Entity头域：
Content-Length：发送给HTTP服务器数据的长度。
Content-Type：表示数据类型和使用的字符集 例如：text/html;charset=utf-8
Miscellaneous 头域
Referer: 提供了Request的上下文信息的服务器，告诉服务器我是从哪个链接过来的
Cache 头域
If-Modified-Since：
把浏览器端缓存页面的最后修改时间发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。
如果时间一致，那么返回304，客户端就直接使用本地缓存文件。如果时间不一致，就会返回200和新的文件内容。
客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中
Cache-Control：指定缓存机制的规则 有以下选项：Public(可以被任何缓存所缓存),private(内容只缓存到私有缓存中),
no-cache(所有内容都不会被缓存)
HTTP响应格式：
HTTP 响应也是由三个部分组成，分别是：状态行、消息报头和响应正文
1.状态行： 状态行由协议版本、数字形式的状态代码，及相应的状态描述组成
200 OK //客户端请求成功
404 Not Found //请求资源不存在，eg：输入了错误的URL
2.消息包头：
Cache头域
Date：作用：生成消息的具体时间和日期，即当前的GMT时间。
Expires：作用: 浏览器会在指定过期时间内使用本地缓存，指明应该在什么时候认为文档已经过期，从而不再缓存它。
Vary：例如: Vary: Accept-Encoding
Cookie/Login 头域
P3P：作用: 用于跨域设置Cookie, 这样可以解决iframe跨域访问Cookie的问题
Set-Cookie
作用： 非常重要的header, 用于把Cookie 发送到客户端浏览器， 每一个写入Cookie都会生成一个Set-Cookie.
例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Entity实体头域：
实体内容的属性，包括实体信息类型，长度，压缩方法，最后一次修改时间，数据有效性等。
ETag：
作用: 和If-None-Match 配合使用。 （实例请看上节中If-None-Match的实例）
Last-Modified
作用： 用于指示资源的最后修改日期和时间。（实例请看上节的If-Modified-Since的实例）
Content-Type：
作用：WEB服务器告诉浏览器自己响应的对象的类型和字符集,
Content-Length：
指明实体正文的长度，以字节方式存储的十进制数字来表示。在数据下行的过程中，Content-Length的方式要预
先在服务器中缓存所有数据，然后所有数据再一股脑儿地发给客户端。
Content-Encoding：
作用：文档的编码（Encode）方法。一般是压缩方式。
Content-Language：
作用： WEB服务器告诉浏览器自己响应的对象的语言
Miscellaneous 头域
Server：作用：指明HTTP服务器的软件信息 例如:Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By：作用：表示网站是用什么技术开发的。例如： X-Powered-By: PHP/5.2.5
Transport头域
Connection 例如Connection: keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的
TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接
Location：作用： 用于重定向一个新的位置， 包含新的URL地址
3.响应正文：
响应正文就是服务器返回的资源的内容，响应头和正文之间也必须用空行分隔
*********************HTTPS内容***********************
session和 Cookie
对称秘钥：即发送和接收数据的双方必使用相同的密钥对明文进行加密和解密运算
SSL TLS:
SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全（Transport Layer Security，TLS）
是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密
SSL/TLS协议的基本过程：
（1） 客户端向服务器端索要并验证公钥。
（2） 双方协商生成"对话密钥"。
（3） 双方采用"对话密钥"进行加密通信。
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
前两步又称握手阶段
1.首先客户端发出请求 --> ClientHello
比如：客户端支持的TLS版本 ; 支持的加密方法 ; 支持的压缩方法 ; 一个客户端生成的随机数
2.服务器回应 --> SeverHello
确认使用的加密通信协议版本，比如TLS 1.0 如果客户端和服务器版本不一致，服务器就会关闭加密服务
确认使用的加密方法；一个服务器生成的随机数; 服务器证书
3. 客户端回应：首先会验证服务器发过来的证书。如果证书不是可信机构颁布、或者证书中的域名与
实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
然后客户端从证书中取出服务器的公钥，并向服务器发送下面的信息：
一个随机数，这个随机数用公钥加密，防止被窃听；
编码改变通知，表示随后的信息都将用双方商定的加密方法和密码发送;
客户端握手结束通知。
4. 服务器收到就利用私钥解密消息得到第三个随机数，然后计算本次会话所用的“会话秘钥”
(至此，服务器和客户端已经有三个随机数，然后双方就使用之前约定好的加密方法生成同一把
“会话秘钥”，这就是后面使用的对称加密的秘钥)，然后服务器就会客户端发送以下消息：
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送；
服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，
用来供客户端校验。
等握手阶段结束以后，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，
只不过用"会话密钥"加密内容。
握手阶段中需要注意的三点：
（1）生成对话密钥一共需要三个随机数。
（2）握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），
无其他作用。
（3）服务器公钥放在服务器的数字证书之中。
************HTTP1.0与HTTP1.1的区别*******************
HTTP 1.1在继承了HTTP 1.0优点的基础上，也克服了HTTP 1.0的性能问题
1.HTTP1.1支持了持久连接Persistent Connection，并默认使用持久连接。为此也增加了新的请求头：
Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；
Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接
2.HTTP1.1新增了请求的流水线（Pipelining）机制，或者叫管道机制。即在同一个TCP连接里面，
客户端可以同时发送多个请求.管道机制则是允许浏览器同时多个请求，但是服务器还是按照请
求顺序回应各个请求。为此也新增了字段Content-Length
3.分块传输编码
使用Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。
对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。
更好的处理方法是，产生一块数据，就发送一块，采用"流模式"（stream）取代"缓存模式"（buffer）。
只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成.
每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，
就表示本次回应的数据发送完了.
4.新增了HOST域
在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。
但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且
它们共享一个IP地址。在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问
服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来
创建多个虚拟WEB站点
5.新增了请求方法
比如OPTIONS,PUT, DELETE, TRACE, CONNECT等方法
6.新增了支持传递部分内容的功能
HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分
HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头
域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206
（Partial Content），它可以防止Cache
将响应误以为是完整的一个对象
7.节约宽带
另外一种浪费带宽的情况是请求消息中如果包含比较大的实体内容，但不确定服务器是否能够接收该请求（如是否有权限），
此时若贸然发出带实体的请求，如果被拒绝也会浪费带宽。
HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，
就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。
注意，HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue
8.新增了一些状态码
***********************session与Cookie******************
google浏览器网址输入栏左边有个 圆圈i，点开后就有Cookie这个文件夹
Cookie(甜饼)
Cookie机制是干什么的，有什么用，怎么用
1.Http是无状态的协议，也就是说同一客户端这一次与下一次发送的请求没有对应关系，如果说类似于用户购买东西
前后买的东西都要放在同一个账号上的购物车里，就需要一种机制确保服务器知道每次客户身份，这样就可以前后客
户是什么关系，是不是同一个用户了。
2.Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户
端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同
该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
Cookie对象使用key-value属性对的形式保存用户状态，
一个Cookie对象保存一个属性对，一个request或者response同时使用多个Cookie
3.如何查看Cookie内容
两种方式 第一种方式利用F12 第二种方式在网址左侧可以查看，后续图片补上
4.Cookie的几个特点：
①：Cookie的不可跨域名性
对于不同的域名会有对应的Cookie，Cookie是保存在客户端上由浏览器来管理，浏览器能保存只处理指定域名的Cookie，
从而保证用户的隐私安全。
②：Cookie的有效性
Cookie的maxAge决定着Cookie的有效期，单位为秒。
客户端可以采用两种方式来保存这个 Cookie 对象，一种方式是保存在客户端内存中，称为临时 Cookie，浏览器关闭后
这个 Cookie 对象将消失。 另外一种方式是保存在客户机的磁盘上，称为永久 Cookie。以后客户端只要访问该网站，
就会将这个 Cookie 再次发送到服务器上，前提是这个 Cookie 在有效期内，这样就实现了对客户的跟踪。
Session机制：
除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态
的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。Session是另一种记录客户状态的机制，不同的
是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以
某种形式记录在服务器上。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。如果说Cookie机
制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认
客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
Session如何实现？
1.利用Cookie
sessionid是一个会话的key，浏览器第一次访问服务器会在服务器端生成一个session，有一个sessionid和它对应。
tomcat生成的sessionid叫做jsessionid。然后服务器通过Cookie发送给客户端。当客户端再发起请求的时候，
将在Cookie头中携带这个sessionid。这样服务器能够找到这个
客户端对应的Session。没有找到则会新建Session.
2.如果客户端浏览器不支持Cookie或者将Cookie禁止了，可以利用URL重写的办法来让服务器获取到session id。
URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写到URL地址中。
服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。
Cookie和Session有以下明显的不同点：
1）Cookie将状态保存在客户端，Session将状态保存在服务器端；
2）Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。Cookie最早在RFC2109中实现，
后续RFC2965做了增强。网络服务器用HTTP头向客户端发送Cookies，在客户终端，浏览器解析这些Cookies并将它们保存
为一个本地文件，它会自动将同一服务器的任何请求缚上这些Cookies。Session并没有在HTTP的协议中定义；
3）Session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,
这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用Cookie时，这个值也可能设置为由get来返回给服务器；
4）就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个Cookie，建议在服务器端的SESSION机制更安全些.
因为它不会任意读取客户存储的信息。
5 )Cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗，考虑到安全应当使用session；
6 )session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用Cookie；