HTTP工作原理
HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
以下是 HTTP 请求/响应的步骤：
1、客户端连接到Web服务器 一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。
2、发送HTTP请求 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3、服务器接受请求并返回HTTP响应 Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4、释放连接TCP连接 若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5、客户端浏览器解析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 回显服务器收到的请求，主要用于测试或诊断。
浏览器缓存和服务器缓存
一、浏览器缓存 浏览器缓存即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。
二、服务器缓存
上面是一个简单的流程图：用户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进行加密。此外还有一些二次保护的方法可以作为过渡和折中。
HTTP 长连接 (Keep Alive)
在 HTTP 1.0 时期，每个 TCP 连接只会被一个 HTTP Transaction（请求加响应）使用。之后，这个 TCP 连接便会被关闭。当网页内容越来越复杂，包含大量图片、CSS 等资源之后，这种模式效率就显得太低了。所以，在 HTTP 1.1 中，引入了 HTTP persistent connection 的概念，也称为 HTTP keep-alive（后面统一称呼为 HTTP 长连接）。
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的数字证书验证是怎么样的一个过程
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头。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
