关于https协议的123事儿

HTTP工做原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行做为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

如下是 HTTP 请求/响应的步骤：

一、客户端链接到Web服务器 一个HTTP客户端，一般是浏览器，与Web服务器的HTTP端口（默认为80）创建一个TCP套接字链接。

二、发送HTTP请求 经过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

三、服务器接受请求并返回HTTP响应 Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

四、释放链接TCP链接 若connection 模式为close，则服务器主动关闭TCP链接，客户端被动关闭链接，释放TCP链接;若connection 模式为keepalive，则该链接会保持一段时间，在该时间内能够继续接收请求;

五、客户端浏览器解析HTML内容 客户端浏览器首先解析状态行，查看代表请求是否成功的状态代码。而后解析每个响应头，响应头告知如下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

HTTP状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

1xx：指示信息--表示请求已接收，继续处理 2xx：成功--表示请求已被成功接收、理解、接受 3xx：重定向--要完成请求必须进行更进一步的操做 4xx：客户端错误--请求有语法错误或请求没法实现 5xx：服务器端错误--服务器未能实现合法的请求 常见状态码：

200 OK //客户端请求成功 400 Bad Request //客户端请求有语法错误，不能被服务器所理解 401 Unauthorized //请求未经受权，这个状态代码必须和WWW-Authenticate报头域一块儿使用 403 Forbidden //服务器收到请求，可是拒绝提供服务 404 Not Found //请求资源不存在，eg：输入了错误的URL 500 Internal Server Error //服务器发生不可预期的错误 503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常 更多状态码http://www.runoob.com/http/http-status-codes.html

HTTP请求方法

根据HTTP标准，HTTP请求可使用多种请求方法。 HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

GET 请求指定的页面信息，并返回实体主体。 HEAD 相似于get请求，只不过返回的响应中没有具体的内容，用于获取报头 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会致使新的资源的创建和/或已有资源的修改。 PUT 从客户端向服务器传送的数据取代指定的文档的内容。 DELETE 请求服务器删除指定的页面。 CONNECT HTTP/1.1协议中预留给可以将链接改成管道方式的代理服务器。 OPTIONS 容许客户端查看服务器的性能。 TRACE 回显服务器收到的请求，主要用于测试或诊断。

浏览器缓存和服务器缓存

1、浏览器缓存 浏览器缓存即http缓存；浏览器缓存根据是否须要向服务器从新发起HTTP请求将缓存过程分为两个部分，分别是强制缓存和协商缓存。浏览器第一次请求资源的时候服务器会告诉客户端是否应该缓存资源，根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中。以下图：

1.强制缓存：浏览器会对缓存进行查找，并根据必定的规则肯定是否使用缓存。强制缓存的缓存规则？HTTP/1.0Expires这个字段是绝对时间，好比2018年6月30日12:30，而后在这个时间点以前的请求都会使用浏览器缓存，除非清除了缓存。这个字段的缺点就是只会同步客户端的时间，这就有可能修改客户端时间致使缓存失效。HTTP/1.1cache-Control这个是1.1的时候替换Expires的，它会有几种取值：public：全部内容都将被缓存（客户端和代理服务器均可缓存）private：全部内容只有客户端能够缓存，Cache-Control的默认取值no-cache：客户端缓存内容，可是是否使用缓存则须要通过协商缓存来验证决定no-store：全部内容都不会被缓存，即不使用强制缓存，也不使用协商缓存max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效好比max-age=500，则在500秒内再次请求会直接只用缓存。优先性：cache-Control > Expires若是同时存在，cache-Control会覆盖Expires。这个字段的缺点就是：若是资源更新的速度是秒如下单位，那么该缓存是不能被使用的，由于它的时间单位最低是秒。若是文件是经过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，因此起不到缓存的做用。

上图中浏览器缓存中存在该资源的缓存结果，而且没有失效，就会直接使用缓存的内容。

上图中浏览器缓存中没有该资源的缓存结果和标识，就会直接向服务器发起HTTP请求。

2.协商缓存：浏览器的强制缓存失效后(时间过时)，浏览器携带缓存标识请求服务器，由服务器决定是否使用缓存。服务器决定的规则？控制协商缓存的字段有Last-Modified / If-Modified-Since 和 Etag / If-None-Match。①Last-Modified是服务器返回给浏览器的本资源的最后修改时间。当下次再次请求的时候，浏览器会在请求头中带If-Modified-Since,即上次请求下来的Last-Modified的值，而后服务器会用这个值和该资源最后修改的时间比较，若是最后修改时间大于这个值，则会从新请求该资源，返回状态码200。若是这个值和最后修改时间相等，则会返回304，告诉浏览器继续使用缓存。②Etag是服务器返回的一个hash值。当下次再次请求的时候，浏览器会在请求头中带If-None-Match,即上次请求下来的Etag值，而后服务器会用这个值和该资源在服务器的Etag值比较，若是一致则会返回304，继续使用缓存；若是不一致，则会从新请求，返回200。

2、服务器缓存

上面是一个简单的流程图：用户1访问A页面，服务器解析A页面返回给用户1，同时在服务器内存上作必定映射，把A页面缓存在硬盘上面用户2访问A页面，服务器直接根据内存上的映射找到对应的页面缓存，直接返回给用户2，这样就减小了服务器对同一页面的重复解析服务器缓存和浏览器缓存的区别：服务器缓存是把页面缓存到服务器上的硬盘里，而浏览器缓存是把页面缓存到用户本身的电脑里

Nginx服务器 Nginx是一个高性能的HTTP和反向代理服务器。具备很是多的优越性：在链接高并发的状况下，Nginx是Apache服务器不错的替代品，Nginx在美国是作虚拟主机生意的老板们常常选择的软件平台之一。Nginx提供了expires、etag、if-modified-since指令来实现浏览器缓存控制。

连接：www.jianshu.com/p/02db8b55a…

HTTP Cookie

Cookie一般也叫作网站cookie,浏览器cookie或者http cookie,是保存在用户浏览器端的，并在发出http请求时会默认携带的一段文本片断。它能够用来作用户认证，服务器校验等经过文本数据能够处理的问题。

Cookie的类别

a.Session Cookie

这个类型的cookie只在会话期间内有效，即当关闭浏览器的时候，它会被浏览器删除。设置session cookie的办法是：在建立cookie不设置Expires便可。

b.Persistent Cookie

持久型cookie顾名思义就是会长期在用户会话中生效。当你设置cookie的属性Max-Age为1个月的话，那么在这个月里每一个相关URL的http请求中都会带有这个cookie。因此它能够记录不少用户初始化或自定义化的信息，好比何时第一次登陆及弱登陆态等。

c.Secure cookie

安全cookie是在https访问下的cookie形态，以确保cookie在从客户端传递到Server的过程当中始终加密的。这样作大大的下降的cookie内容直接暴露在黑客面前及被盗取的几率。

d.HttpOnly Cookie目前主流的浏览器已经都支持了httponly cookie。1.IE5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.Safari/Chrome。在支持httponly的浏览器上，设置成httponly的cookie只能在http(https)请求上传递。也就是说httponly cookie对客户端脚本语言(javascript)无效，从而避免了跨站攻击时JS偷取cookie的状况。当你使用javascript在设置一样名字的cookie时，只有原来的httponly值会传送到服务器。

e.3rd-party cookie

第一方cookie是cookie种植在浏览器地址栏的域名或子域名下的。第三方cookie则是种植在不一样于浏览器地址栏的域名下。例如：用户访问a.com时，在ad.google.com设置了个cookie，在访问b.com的时候，也在ad.google.com设置了一个cookie。这种场景常常出如今google adsense，阿里妈妈之类的广告服务商。广告商就能够采集用户的一些习惯和访问历史。

f.Super Cookie

超级cookie是设置公共域名前缀上的cookie。一般a.b.com的cookie能够设置在a.b.com和b.com，而不容许设置在.com上，可是很不幸的是历史上一些老版本的浏览器由于对新增后缀过滤不足致使过超级cookie的产生。

Cookie用途

a.会话管理

1.记录用户的登陆状态是cookie最经常使用的用途。一般web服务器会在用户登陆成功后下发一个签名来标记session的有效性，这样免去了用户屡次认证和登陆网站。

2.记录用户的访问状态，例如导航啊，用户的注册流程啊。

b.个性化信息

1.Cookie也常常用来记忆用户相关的信息，以方便用户在使用和本身相关的站点服务。例如：ptlogin会记忆上一次登陆的用户的QQ号码，这样在下次登陆的时候会默认填写好这个QQ号码。

2.Cookie也被用来记忆用户自定义的一些功能。用户在设置自定义特征的时候，仅仅是保存在用户的浏览器中，在下一次访问的时候服务器会根据用户本地的cookie来表现用户的设置。例如google将搜索设置（使用语言、每页的条数，以及打开搜索结果的方式等等）保存在一个COOKIE里。

c.记录用户的行为最典型的是公司的TCSS系统。它使用Cookie来记录用户的点击流和某个产品或商业行为的操做率和流失率。固然功能能够经过IP或http header中的referrer实现，可是Cookie更精准一些。

Cookie的实现

Cookie是web server下发给浏览器的任意的一段文本，在后续的http 请求中，浏览器会将cookie带回给Web Server。同时在浏览器容许脚本执行的状况下，Cookie是能够被JavaScript等脚本设置的。 在网络上传输的数据都是会被监听获取的，尤为是在公共的、非加密的网络环境（free wifi）。这些数据也包括常规的http（非https加密通道）全部session，固然也就包括了HTTP 会话里的Cookie。当黑客拿到明文的cookie以后就能够模拟用户操做，好比改密码、消费等行为。解决这个问题的最根本方法是采起https协议，经过SSL通道对内容及cookie进行加密。此外还有一些二次保护的方法能够做为过渡和折中。

www.jianshu.com/p/1e28fe812…

HTTP 长链接 (Keep Alive)

在 HTTP 1.0 时期，每一个 TCP 链接只会被一个 HTTP Transaction（请求加响应）使用。以后，这个 TCP 链接便会被关闭。当网页内容愈来愈复杂，包含大量图片、CSS 等资源以后，这种模式效率就显得过低了。因此，在 HTTP 1.1 中，引入了 HTTP persistent connection 的概念，也称为 HTTP keep-alive（后面统一称呼为 HTTP 长链接）。

在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不一样，默认状况下所在HTTP1.1中全部链接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close ，这也就是为何Connection: Keep-Alive字段再没有意义的缘由。 在客户端，Java抽象了Keep-Alive，和程序员分享离开来，HttpURLConnection类自动实现了Keep-Alive，若是程序员没有介入去操做Keep-Alive，Keep-Alive会经过客户端内部的一个HttpURLConnection类的实例对象来自动实现。也就是说，在java中keep-alive是由一个Java类库来实现的，但在其余类库中不必定可用。在服务器端，Java依然是将Keep-Alive抽象出来，HttpServlet、HttpServletRequest、和HttpServletResponse类自动实现 了Keep-Alive。这种状况下一些由第三方控制的操做是可能的，如在KeepAliveServlet中提到的JavaWebServer，Keep-Alive是否启用由两个因素决定，内容长度和输出大小，若是内容长度是响应的一部分（即这段内容长度输出后还有内容须要输出），则Keep-Alive被启用（固然须要客户端支持的状况下）；若是内容长度未设定，则Servlet会试着计算响应缓冲区长度以肯定内容长度，在Javasoft实现中，使用一个4KB的缓冲区（至关于上面说的响应）。也就是说若是内容长度未设定，而且返回数据超过4KB，此时至关于内容长度大于响应长度，而不是响应长度一部分，Keep-Alive就不会被启用 。OkHttp 是国外的互联网支付公司 Square 的产品，优势是比较轻量，主要面向 Android 开发 使用，也可使用在服务端开发场景中。使用 OkHttp 设置 HTTP 长链接比较简单，默认就会开启。只需建立一个 OkHttpClient 便可。

HTTPS的数字证书验证原理

HTTPS是一种在HTTP的基础上加了SSL/TLS层（安全套接层）的安全的超文本传输协议。HTTP的传输属于明文传输，因此说是不安全的，在传输的过程当中容易被人截取而且偷窥其中的内容，而HTTPS传输的信息是经过加密的，也是一种安全的传输。说到加密算法，先来了解一下两种经常使用的加密方式，分别是对称加密和非对称加密： 1.对称加密：加密使用的秘钥和解密使用的秘钥是相同的，也就是说加密和解密都使用同一个秘钥，加密算法是公开的，秘钥是加密者和解密者绝对保密的。 2.非对称加密：加密使用的秘钥和解密使用的秘钥是不相同的，HTTPS在数字证书验证的时候，采用的RSA密码体制就是一种非对称加密。

RSA是一种公钥秘钥密码体制，如今使用很是普遍，这个密码体制分为三部分，公钥、私钥、加密算法，其中公钥和加密算法是公布的，私钥是本身保密的。这种机制最大的特色是，经过公钥加密的密文只有对应的私钥才能解密，一样经过私钥加密的密文也是只有对应的公钥才能解密。下面咱们将会讲到HTTPS是如何经过RSA这种密码体制去验证身份的。

先了解一下数字证书，它有点像身份证，是由权威的CA机构颁发的，证书的主要内容有：公钥（Public Key）、ISSUER（证书的发布机构）、Subject（证书持有者）、证书有效期、签名算法、指纹及指纹算法。这里特别说明一下，CA机构也有本身的证书，咱们姑且称之为根证书，它也有本身的公钥和私钥，我称之为根公钥和根私钥吧。固然根公钥和加密算法是向外公布的，而根私钥是机构本身绝对保密的。

指纹是一个证书的签名，是经过指纹算法sha1计算出来的一个hash值，这个很重要，是用来验证证书内容有没有被篡改的。证书在发布以前，CA机构会把所颁发证书的内容用根私钥经过指纹算法计算出一个hash值，这个hash值只能经过对应机构的根公钥才能解密，因此在验证证书的时候，咱们经过一样的指纹算法把证书内容进行hash计算获得另外一个hash值，若是这个hash值跟证书上自带的hash值相同，就表明证书没有被修改过。

下面咱们将基于一个简单的图例，去分析整个HTTPS的数字证书验证是怎么样的一个过程

假设这是一个浏览器的HTTPS请求。

1.首先浏览器经过URL网址去请求某个后台服务器，服务器接收到请求后，就会给浏览器发送一个本身的CA数字证书。

2.浏览器接收到数字证书之后，就要进行验证工做了。首先从证书的内容中获取证书的颁发机构，而后从浏览器系统中去寻找此颁发机构是否为浏览器的信任机构。这里解析一下，世界上就几个权威的CA机构，这几个机构都是预先嵌入到咱们的浏览器系统中的。若是接收到一个数字证书但其颁发机构没有在咱们浏览器系统中的，那么就会有警告提示，没法确认证书的真假。若是是受信任的机构，那么就到下一步。

此时咱们就能够从浏览器中找到对应的机构的根公钥，用这个公钥去解析证书的签名获得一个hash值H1，上面提到过，这个签名是证书发布以前CA机构用本身的私钥加密而成的，因此这里只能由根证书的根公钥去解密。而后用证书的指纹算法对证书的内容再进行hash计算获得另外一个hash值H2，经过H1和H2的比对，若是相等，就表明证书没有被修改过，能够信任。此时再检查证书的持有者对应的URL（好比掘金）是否为咱们请求的URL，若是是，那么就能够证实浏览器当前链接的是正确的网址，而不是一些钓鱼网之类的。

这里咱们假设，若是浏览器的链接被某个钓鱼网截取了，钓鱼网也能够发一个本身的证书给浏览器，而后经过了证书没有被篡改的验证，可是在证书没有被篡改的状况下，经过对比证书上的URL和咱们请求的URL，就能够知道这个证书的URL不是咱们所要链接的网址，因此说钓鱼网页骗不了咱们。

看到这里不是很明白这个证书验证的话，我特别解析一下，咱们知道CA机构有本身的根公钥和根私钥。在证书颁发以前，机构会用根私钥将这个证书内容加密获得一个签名，这个签名只能用对应的根公钥去解密。在客户端（浏览器）收到服务器发过来的证书之后，咱们首先从浏览器中拿到机构的根公钥，用这个根公钥去解析证书的签名获得一个哈希值H1，这个H1表明证书的原始内容，即使你本身去生成了一个证书的签名，可是你这个签名不多是用根私钥去加密生成的（由于根私钥是CA机构私有），因此根公钥也不可能去解密任何第三方生成的签名（加密内容只能由对应的公钥私钥解析）。而后下一步咱们再用一样的哈希算法对收证书内容进行计算获得哈希值H2，经过对比H1和H2是否相等就知道证书有没有被褚篡改过了。讲到这里，咱们应该明白证书是否被篡改的验证机制了吧。

3.此时第二步完成了，能够确认是浏览器的链接网址是正确的，是咱们想要链接的那个服务器，而此时也拿到了证书上的公钥。下一步有一个很重要的任务就是，如何将一个对称加密算法的秘钥安全地发给服务器，首先随机生成一个字符串R做为咱们的秘钥，而后经过证书公钥加密成密文，将密文发送给服务器。由于此密文是用公钥加密的，这是一个非对称加密，咱们知道，这个密文只有私钥的持有者才能进行解密，因此说任何第三方截取到密文也是没用的，由于没有对应的私钥因此解析不出来。

这里还有一个很重要的步骤是，发送密文的时候，会对消息内容进行签名操做。签名上面讲解过，就是对密文内容进行hash计算获得的一个hash值，同时将这个hash值进行加密和消息内容一块儿发送出去。接收方收到消息之后，经过私钥解析密文，同时也会对消息内容进行一样的hash计算获得hash值，经过比对两个hash值是否相同来判断密文是否有修改过。

4.经过第三步的操做，此时客户端和服务器都拥有了对称加密算法的秘钥，由于只有它们二者知道，因此此时兄弟两就能够愉快地安全通讯了。

5.经过上面咱们能够看到，有两个很是重要的步骤，第一是验证数字证书的正确性还有链接网址是否正确，第二是经过RSA机制的原理安全地进行了对称加密算法秘钥的输送。这两步都完成之后，整个HTTPS的数字证书的验证就算是成功了。 blog.csdn.net/liuxingrong…

SSL协议

SSL（Secure Sockets Layer，安全套接层），及其继任者 TLS（Transport Layer Security，传输层安全）是为网络通讯提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络链接进行加密。

为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程当中不会被截取及窃听。

SSL协议位于TCP/IP协议与各类应用层协议之间，为数据通信提供安全支持。SSL协议可分为两层： SSL记录协议（SSL RecordProtocol）：它创建在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它创建在SSL记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议提供的服务主要有：   1）认证用户和服务器，确保数据发送到正确的客户机和服务器；   2）加密数据以防止数据中途被窃取；   3）维护数据的完整性，确保数据在传输过程当中不被改变。

SSL的位置

  SSL介于应用层和TCP层之间。应用层数据再也不直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增长本身的SSL头。

SSL协议的一个重要方面是认证(Authentication)。这就是说，在你开始试图经过一个安全链接与一个Web服务器交流的时候，这个服务器会要求你的浏览器出示一组证件，经过“鉴定”的方式来证实这就是你所声明的网站。在某些状况下，服务器还会要求你的web浏览器的认证书，证实你就是你所说的那我的。这就是所知的“客户认证”，尽管实际状况中，更多地用在商务-对-商务(B2B)交易，而不是对我的用户。大多数有SSL功能的web服务器不要求客户认证(Client Authentication)。为了能实施SSL，一个web服务器对每一个接受安全链接的外部接口(IP地址)必需要有相应的认证书(Certificate)。关于这个设计的理论是一个服务器必须提供某种合理的保证以证实这个服务器的主人就是你所认为的那我的，特别是在接收任何敏感信息以前要这样作。SSL 证书（也称为数字证书）将身份与一对可用于加密和签名数字信息的电子密钥绑定。SSL 证书可以实现对某人自称有权使用特定密钥的声明的验证，有助于防止有人使用欺骗性密钥来模拟其余用户。当与加密配合使用时，SSL 证书可提供完整的安全解决方案，能够保证参与事务的一方或各方的身份。 SSL 证书是由受信任的第三方（称为证书颁发机构 (CA)）发放的。CA 的做用有些像护照办理处。CA 必须采起一些措施来肯定要向其发放 ID 的人或组织的身份。一旦 CA 创建某个组织的身份后，就能够发出一个包含该组织的公钥的证书，并用 CA 的私钥对其签名。