应用层上的协议非常重要的一个协议是HTTP协议。
这个协议包括了请求和回复两种报文类型。
请求和回复报文的内容形式是
1）起始行
2）首行
3）消息体
请求报文的内容格式是
<version><request-url><method> <headers> <entity-body>
回复报文的内容格式是
<version><status><reason-pharse> <headers> <entity-body>
报文中标签代表的含义是
method:指请求方法，主要的方法为GET和POST。
request-url:指请求路径/地址
version:指协议版本，现在通常是http/1.1
status:指响应状态码，主要的响应状态例如200,404。
reason-pharse:原因短语，200 Ok、404 No Found 这种后面描述的就是原因短语，不必太过关注。
method
请求方法使用频繁的是Get和POST。面试的时候通常被问到这两个方法有什么区别。这里我们来谈一谈。
GET和POST在传输形式上有一些差异。GET请求时，会在request-url地址后拼接参数，格式是url？parm1=ss&parm2=dd。
所以，这样的形式会在地址栏中暴露参数。由于url地址采用ASCII编码，如果参数中有Unicode编码的字符，例如汉字，需要转码后传输。
url地址的长度没有被限制，但是在一些服务器和浏览器中会限制url的长度，所有get发起的请求地址不能太长。而POST请求是将参数放在
内容中，不会有长度的限制。
另外一点差别表现在语义上。GET请求是希望从服务器中取到数据，频繁的GET请求对服务器没有影响。而POST请求是线修改、删除服务器中
的数据，例如提交表单修改服务器数据，不建议频繁使用POST请求。
header
在请求报文和响应报文的首部，都可以携带一些信息，通过与其他部分的配合，能够实现各种强大的功能。这些信息位于起始行之下和请求实体之间，
以键值对的形式，称为首部。每条首部以回车换行符结尾，最后一个首部额外多一个换行，与请求实体分开。
重要的首部信息是：
Date Cache-Control Last-modified Etag Expires If-Modified-Since If-None-Match If-Unmodified-Since If-Range If-match
HTTP缓存
HTTP协议为了提高客户端访问服务器速度，有了HTTP缓存技术。
发送HTTP请求的客户端从服务器取得资源，资源保存在客户端，当客户端再次请求同一个url的资源，请求先判断本地时候存有缓存资源，有则快速从
本地存储设备中获取缓存资源。
我们知道从同一个url中取得的资源不是一成不变的。服务器中该url的资源可能在一定时间后被修改。这时本地的资源缓存将与服务器一侧的资源存在
差异。
既然在一定时间后资源可能发生改变，那么在某个时间之前我们可以认为这个资源没有改变，从而大胆使用缓存资源。当请求时间超出该时间后，我们
认为这个时间不再与服务器一侧的资源一致了。所以，当我们发起一个资源时需要对缓存的资源进行判断，看看究竟我们是否能使用该缓存资源，这个
个叫做新鲜度检测。
如果我们发现超出缓存使用时间了，本地发起请求时不会直接返回缓存资源，而是先去服务器查看这个资源是否已经改变，这个叫做再验证。如果服务器
中的资源没有发生改变，服务器返回状态码304 Not Modified,并不再返回对应实体。这叫做再验证命中。相反，如果在验证未命中，则会返回 200 Ok，并
将改变的url资源返回，此时缓存更新以待之后请求。
HTTPS
HTTPS流行时，苹果强制上线的APP必须使用https协议，谷歌的chrome浏览器将非https协议一律标注为“不安全”的网络。作为开发者，我们能感受到https
越来越受重视，所以了解https是必须的。
https = http+加密+认证+完整性保护
传统的http协议存在一些缺点：
1） http使用明文传输，在传输过程中容易被盗取信息
2）http对于通信双方没有经过身份认证，通信的双方无法确认对方是否是伪装的客户端或服务端
3）http对于传输内容的完整性没有确认方法，容易被人篡改信息。
因此，在一些需要安全级别较高的场景下，例如银行转账请求时，http无法抵御这些攻击。HTTPs则可以通过TLS/SSL，支持对通信内容的加密，以及通信双方
身份的认证。
HTTPS的加密原理
近代密码学的加密方式分为两类：
1）对称密钥加密
2）非对称密钥加密
对称密钥加密是指加密和解密使用同一把密钥。这种方式的优势是处理速度非常快，但是如何从一端安全地将密钥安全地传递到通信的另一端是一个问题。
非对称密钥加密是指加密和解密使用两把不同的密钥。这两把密钥，一把叫公开密钥，可以随意对外公开。另一把叫私有密钥，只用于本身持有。得到公开
密钥的客户端可以使用公开密钥对传输内容进行加密，得到私有密钥的持有者才能对加密的传输内容进行解密。这种方式克服了密钥交换的问题，但是相对于
对称密钥加密方式，处理速度较慢。
TLS/SSL加密方式结合了对称密钥加密和非对称密钥加密的优点。首先采用非对称加密的方式，将一个对称密钥使用公开密钥加密后传输传输到对方，对方使用
私有密钥解密，得到传输的对称密钥。之后双方使用对称密钥进行通讯。这样既解决了对称密钥加密后的传输问题，又利用了对称密钥的高效率来进行通信内容的
加密或解密。
如何确保加密的公开密钥确实是所期望服务器分发的了？也许在收到密钥之前，这个密钥在中途已经被别人篡改了。因此，我们还需要有对这个密钥进行认证的能力，
以确保我们通信的对方是我们期望的对象。
目前的做法是使用数字证书认证机构颁发的公开密钥证书。服务器的运营人员可以向认证机构提出公开密钥申请，认证机构在审核后，会将公开密钥和公钥证书绑定，
服务器就可以将这个公钥证书下发给客户端，客户端收到证书后，使用认证机构的公开密钥进行认证。一旦验证成功，即可知道这个密钥是可信任的密钥。