HTTP
http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改，严重情况下，会造成恶意的流量劫持等问题，甚至造成个人隐私泄露（比如银行卡卡号和密码泄露）等严重的安全问题。
比如常见的，在http通信过程中，“中间人”将广告链接嵌入到服务器发给用户的http报文里，导致用户界面出现很多不良链接； 或者是修改用户的请求头URL，导致用户的请求被劫持到另外一个网站，用户的请求永远到不了真正的服务器。这些都会导致用户得不到正确的服务，甚至是损失惨重。
HTTPS
Https 怎样保证数据传输安全？
讲 Https的原理之前必须先聊一聊数据加密，目前有以下几种加密方式：
- 对称加密 ： 加密和解密数据使用同一个密钥。这种加密方式的优点是速度很快，常见对称加密的算法有 AES；
- 非对称加密： 加密和解密使用不同的密钥，叫公钥和私钥。数据用公钥加密后必须用私钥解密，数据用私钥加密后必须用公钥解密。一般来说私钥自己保留好，把公钥公开给别人，让别人拿自己的公钥加密数据后发给自己，这样只有自己才能解密。 这种加密方式的特点是速度慢，CPU 开销大，常见非对称加密算法有 RSA；
- Hash： hash 是把任意长度数据经过处理变成一个长度固定唯一的字符串，但任何人拿到这个字符串无法反向解密成原始数据（解开你就是密码学专家了），Hash 常用来验证数据的完整性。常见 Hash 算法有 MD5（已经不安全了）、SHA1、SHA256
服务器首先生成公私钥，将公钥提供给相关机构（CA），CA将公钥放入数字证书（证书由公钥、证书主体、数字签名等内容组成）并将数字证书颁布给服务器，此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书，数字证书中加入了一些数字签名的机制，保证了数字证书一定是服务器给客户端的。
当一个网站要使用 https 时先需在一些国际认证的 CA 机构填写网站信息申请证书，而这些 CA机构往往还有上层 CA，最终有一个根 CA。一般来说浏览器都会内置根 CA 和一些顶级 CA 的证书，但需要验证的时候会通过 CA 链逐级验证。
用户通过客户端发送请求后，服务器会把公钥发给客户端，客户端得到公钥后会生成一个对称加密AES的密钥，然后用服务器的公钥把 AES 密钥加密(AES 密钥长度很短加密几乎不需要时间)，然后把加密后的密钥发给我。服务器收到后用私钥解密，得到约定进行数据传输的对称密钥，用这个对称密钥加密数据进行交流。
常见状态码
200 OK
一切正常，对GET和POST请求的应答文档跟在后面。
202 Accepted
已经接受请求，但处理尚未完成。
301 Moved Permanently
客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
304 Not Modified
客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。 服务器告诉客户，原来缓冲的文档还可以继续使用。
403 Forbidden
资源不可用。服务器理解客户的请求，但拒绝处理它。通常由于服务器上文件或目录的权限设置导致。
404 Not Found
无法找到指定位置的资源。这也是一个常用的应答
500 Internal Server Error
服务器遇到了意料不到的情况，不能完成客户的请求。
503 Service Unavailable
服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个 Retry-After头。
缓存机制
浏览器在请求已经访问过的URL的时候, 会判断是否使用缓存, 判断是否使用缓存主要通过判断缓存是否在有效期内, 通过两个字段来判断:
- Expires, 有效期, 返回的是一个GMT时间, 但是使用的是客户端时间, 与服务器时间存在一定时间差
- Cache-Control => max-age, 最大有效时间, 单位是s, 优先级比expires高, 为了解决expires时间差的问题而出现的
当缓存过期后, 浏览器不会直接去服务器上拿缓存, 而是判断缓存是否有更新, 能否继续使用, 判断的方法有两种:
- Last-Modified 和 If-Modified-Since: 服务器会响应一个Last-Modified字段, 表示最近一次修改缓存的时间, 当缓存过期后, 浏览器就会把这个时间放在If-Modified-Since去请求服务器, 判断缓存是否有更新
- Etag和If-None-Match: 服务器会响应一个Etag字段, 一个表示文件唯一的字符串, 一旦文件更新, Etag也会跟着更改, 当缓存过期后, 浏览器会把这个字符串放在If-None-Match去请求服务器, 判断是否有更新, Etag的优先级比Last-Modified的更高, Etag的出现, 是为了解决一个缓存文件在短时间内被多次修改的问题, 因为Last-Modified只能精确到秒
浏览器缓存控制分为强缓存和协商缓存，协商缓存必须配合强缓存使用。
首先浏览器第一次跟服务器请求一个资源，服务器在返回这个资源和response header的同时，会根据开发者要求或者浏览器默认，在response的header加上相关字段的http response header。
一、当浏览器对某个资源的请求命中了强缓存时，利用[Expires]或者[Cache-Control]这两个http response header实现 。
- [Expires]：描述的是一个绝对时间，根据的是客户端时间。用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT 下次浏览器再次请求同一资源时。先从客户端缓存中寻找，找到这个资源后，拿出它的[Expires]跟当前的请求时间比较。如果请求时间在[Expires]指定的失效时间之前，就能命中缓存，这样就不用再次到服务器上去缓存一遍，节省了资源。但是正因为是绝对时间，如果客户端时间被随意更改下，这个机制就失效了。所以我们需要[Cache-Control]。
- [Cache-Control]：描述的是一个相对时间，在进行缓存命中时，都是利用浏览器时间判断。
这两个header可以只启用一个，也可以同时启用，当response header中，[Expires]和[Cache-Control]同时存在时，[Cache-Control]优先级高于[Expires]。
二、当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中。 如果命中，则还是从客户端缓存中加载。协商缓存利用的是[Last-Modified，If-Modified-Since]和[ETag、If-None-Match]这两对Header来管理的。- [Last-Modified]：原理和上面的[expires]相同，区别是它是根据服务器时间返回的header来判断缓存是否存在。但是有时候也会服务器上资源其实有变化，但是最后修改时间却没有变化的情况（这种问题也不容易被定位），这时候我们需要[ETag、If-None-Match]。
- [ETag、If-None-Match]：原理与上相同，区别是浏览器跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上ETag的header，这个header是服务器根据当前请求的资源生成的一个唯一标识，这个唯一标识是一个字符串，只要资源有变化这个串就不同。
- [ETag、If-None-Match]这么厉害我们为什么还需要[Last-Modified、If-Modified-Since]呢？有一个例子就是分布式系统尽量关闭掉ETag(每台机器生成的ETag都会不一样）
[Last-Modified，If-Modified-Since]和[ETag、If-None-Match]一般都是同时启用。
