HTTP:超文本传输协议，是一种通信协议；允许超文本标记文档从Web服务器传送到客户端的浏览器中。
简单：传输html文件的协议。
Web：是一种基于超文本和HTML的、全球性的、动态交互的、跨平台的分布式图形信息系统。
可见HTTP报文一共有四种首部字段（请求头）：请求首部字段、响应首部字段、通用首部字段、实体首部字段；
在chrome的开发者调试工具当中，从请求报文和响应报文分各抽出了一部分，形成了三部分：
General：
RequestHeaders：
ResponseHeaders：
作用：浏览器端可以接受的媒体类型；
若想要给显示的媒体类型增加优先级，则使用q来额外表示权重值，用分号（;）进行分隔。权重值q的范围是0~1（可精确到小数点后3位），且1为最大值。不指定权重q值时，默认权重为q=1.0。
当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。
作用：用来通知服务器用户代理（浏览器）支持的字符集及字符集的相对优先顺序。
图Accept-Charset字段中的值：
Accept-Charset：iso-8859-5,unicode-1-1;q=0.8中的unicode-1-1;q=0.8是一个整体，表示unicode编码优先级为0.8，小于默认的iso编码优先级（默认q=1）；不要以为分号（；）为分割符，其实逗号（，）才是分割符
作用：用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。
Accept-Encoding:gzip,deflate常见的编码方式有：gzip、compress、deflate、identity。
作用：用来告知服务器浏览器能够接收的语言，以及相对优先级。
Accept-Language:zh-cn,zh;q=0.7,en-us,en;q=0.3上述值表示：优先请求中文版，其次是英文版；
Host:www.hackr.jp若服务器未设定主机名，Host为空值即可。
形如If--xxx这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。
上图表示：只有当If-Match的字段值跟Etag值匹配一致时，服务器才会接收请求。
只有在If-None-Match的字段值与ETag值不一致时，可处理该请求。与If-Match首部字段的作用相反；
下面我们思考一下不使用首部字段If-Range发送请求的情况。服务器端的资源如果更新，那客户端持有资源中的一部分也会随之无效，当然，范围请求作为前提是无效的。这时，服务器会暂且以状态码412:PreconditionFailed作为响应返回，其目的是催促客户端再次发送请求。这样一来，与使用首部字段If-Range比起来，就需要花费两倍的功夫。
作用：告诉服务器我是从哪个页面的链接过来的，服务器籍此可以获得一些信息用于处理；
User-Agent:Mozilla/5.0(WindowsNT6.1;WOW64;rv:13.0)Gecko/2010010很多时候我们会通过该字段来判断浏览器类型，从而进行不同的兼容性设计。
首部字段Age能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒。
首部字段ETag能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的ETag值。另外，当资源更新时，ETag值也需要更新。生成ETag值时，并没有统一的算法规则，而仅仅是由服务器来分配。
与响应头If-None-Match是一对；
使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。基本上，该字段会配合3xx：Redirection的响应，提供重定向的URI。
a.请求首部中Cache-Control的指令：
b.响应首部中Cache-Control的指令：
Cache-Control各指令详解：
Cache-Control:s-maxage=604800//（单位：秒）此外，当使用s-maxage指令后，则直接忽略对Expires首部字段及max-age指令的处理。即优先级为：S-maxage>Max-age>Expires
当服务器返回的响应中包含max-age指令时，缓存服务器将不对资源的有效性再作确认，而直接把max-age数值作为保存为缓存的资源的最长时效。
应用HTTP/1.1版本的缓存服务器遇到同时存在Expires首部字段的情况时，会优先处理max-age指令，而忽略掉Expires首部字段。
有两个作用：
如图中，Connection的值为Upgrade表示不将Upgrade这个首部发给代理；
a.当Connection：close时：
代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭（四次挥手）。当客户端再次发送Request，需要重新建立TCP连接（三次握手）。
b.当Connection：Keep-Alive时：
此时，当一个网页打开完成后（已经建立TCP连接），客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器，会继续使用这条已经建立的连接；
使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径：
作用：说明报文内对象的媒体类型；
但是，当首部字段Cache-Control有指定max-age指令时，比起首部字段Expires，会优先处理max-age指令。
Last-Modeified:Wed,23May201209:59:55GMT6.为Cookie服务的首部字段Cookie的工作机制是用户识别及状态管理。Web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内。接着当用户访问该Web网站时，可通过通信方式取回之前发放的Cookie;
调用Cookie时，由于可校验Cookie的有效期，以及发送方的域、路径、协议等信息，所以正规发布的Cookie内的数据不会因来自其他Web站点和攻击者的攻击而泄露。
为Cookie服务的首部字段：
当服务器准备开始管理客户端的状态时，会事先告知各种信息。
Set-Cookie:status=enable;expires=Tue,05Jul201107:26:31GMT;path**Set-Cookie字段的属性**
另外，一旦Cookie从服务器端发送至客户端，服务器端就不存在可以显式删除Cookie的方法。但可通过覆盖已过期的Cookie，实现对客户端Cookie的实质性删除操作。
通过Cookie的domain属性指定的域名可做到与结尾匹配一致。比如，当指定example.com后，除example.com以外，www.example.com或www2.example.com等都可以发送Cookie。
因此，除了针对具体指定的多个域名发送Cookie之外，不指定domain属性显得更安全。
Cookie的secure属性用于限制Web页面仅在HTTPS安全连接时，才可以发送Cookie。
发送Cookie时，指定secure属性的方法如下所示：
当省略secure属性时，不论HTTP还是HTTPS，都会对Cookie进行回收。
Cookie的HttpOnly属性是Cookie的扩展功能，它使JavaScript脚本无法获得Cookie。其主要目的为防止跨站脚本攻击（Cross-sitescripting，XSS）对Cookie的信息窃取。
发送指定HttpOnly属性的Cookie的方法如下所示。
Set-Cookie:name=value;HttpOnly通过上述设置，通常从Web页面内还可以对Cookie进行读取操作。但使用JavaScript的document.cookie就无法读取附加HttpOnly属性后的Cookie的内容了。因此，也就无法在XSS中利用JavaScript劫Cookie了。
首部字段Cookie会告知服务器，当客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时，同样可以以多个Cookie形式发送。
GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。
举例：
GET方法也可以用来提交表单和其他数据：
幂等：幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同；
OPTIONS方法用来查询针对请求URI指定的资源支持的方法。
示例：
HTTP是无状态协议（高效率，不记仇），它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。
保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了Cookie技术。Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。
在一个网站地址栏输入：
javascript:alert(document.cookie)可以弹出该网站的Cookie信息：
Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。
服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
Cookie和Session非常相似，Cookie相当于客户端持有的通行证，Session相当于服务器上的通行名册。
保存SessionID的方式
Session的有效期
Token的引入
Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。
Token的定义
使用Token的目的
Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
Session管理及Cookie应用
BASIC认证的认证步骤：
BASIC认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。换言之，由于明文解码后就是用户ID和密码，在HTTP等非加密通信的线路上进行BASIC认证的过程中，如果被人窃听，被盗的可能性极高。因此并不常用。
为弥补·BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST认证同样使用质询/响应的方式（challenge/response），但不会像BASIC认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。
因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性就降低了。
**DIGEST认证的认证步骤:**
DIGEST认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。因此使用范围不大。
从使用用户ID和密码的认证方式方面来讲，只要二者的内容正确即可认证是本人的行为。但如果用户ID和密码被盗，就很有可能第三者冒充。利用SSL客户端认证则可以避免该情况的发生。
SSL客户端认证的认证步骤:
为达到SSL客户端认证的目的需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
SSL客户端认证采用双因素认证:
HTTP协议是基于请求/响应模式的，因此只要服务端给了响应，本次HTTP请求就结束了；HTTP的长连接和短连接本质上是TCP的长连接和短连接；
完成一次通信之后，客户端主动断开TCP连接；
HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接（三次握手），结束就中断（四次挥手）；
完成一次通信之后，客户端不主动断开TCP连接，而是复用该TCP连接；
HTTP/1.1起，默认使用长连接，用以保持连接特性。此时通用首部字段中的Connection字段值为：Keep-Alive；
HTTP通信时，除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。它们可以配合服务器工作。
这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应再转发给客户端。
代理服务器：
代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求URI，会直接发送给前方持有资源的目标服务器。
持有资源实体的服务器被称为源服务器，从源服务器返回的响应经过代理服务器后再传给客户端。
每次通过代理服务器转发请求或响应时，会追加写入Via首部信息。
使用代理服务器的理由：
利用缓存技术（稍后讲解）减少网络带宽的流量，组织内部针对特定网站的访问控制（墙），以获取访问日志为主要目的，等等。
代理使用方法：
代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另一种是是否会修改报文。
代理转发响应时，缓存代理（CachingProxy）会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（TransparentProxy）。反之，对报文内容进行加工的代理被称为非透明代理。
网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉，自己的通信目标是一个网关。
网关的工作机制和代理十分相似。但是Web网关在一侧使用HTTP协议，在另一侧使用另一种协议（比如FTP、SMTP）。
常见的网关类型：
利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。比如，网关可以连接数据库，使用SQL语句查询数据。另外，在Web购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。
隧道可按要求建立起一条与其他服务器的通信线路，届时使用SSL等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。
隧道本身不会去解析HTTP请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。
通过隧道的传输，可以和远距离的服务器安全通信。隧道本身是透明的，客户端不用在意隧道的存在。
缓存服务器是代理服务器的一种，并归类在缓存代理类型中。换句话说，当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。
缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源。因此客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同的请求了。
即便缓存服务器内有缓存，也不能保证每次都会返回对同资源的请求。因为这关系到被缓存资源的有效性问题。当遇上源服务器上的资源更新时，如果还是使用不变的缓存，那就会演变成返回更新前的“旧”资源了。
即使存在缓存，也会因为客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效，缓存服务器将会再次从源服务器上获取“新”资源。
缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。以InternetExplorer程序为例，把客户端缓存称为临时网络文件（TemporaryInternetFile）；
浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直接从本地磁盘内读取；
另外，和缓存服务器相同的一点是，当判定缓存过期后，会向源服务器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。
在Expires没有过期的情况下，客户端（浏览器）发出请求时，直接使用HTTP本地缓存并返回状态码200，这种HTTP工作方式称为强制缓存；
有了Last-Modified为什么还要用Etag呢？
你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：
这时，利用Etag能够更加准确的控制缓存，因为Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符。Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。
强制缓存：直接使用HTTP本地缓存，此时服务器返回状态码200；
协商缓存：向服务器确认HTTP本地缓存的资源是否发生变化，没变化后再使用HTTP本地缓存，此时服务器返回状态码304；资源发生变化直接返回最新资源，状态码为200；可以这样理解凡是返回304状态码，都属于协商缓存；
强缓存和协商缓存的区别：
请求头Cache-Control的值为no-cache时表示浏览器会先向服务器确认缓存的新鲜度，再决定是否使用缓存，属于协商缓存。
上述的缓存方案存在一个问题：当Expires或Max-age没有过期时，浏览器无法主动确认本地缓存是否发生变化；
CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率；
比如可以把CDN理解为各个城市的快递分发站点，源服务器看作快递总仓库；
CDN缓存工作方式：
CDN节点会代替服务器处理浏览器的请求，会有几种情况：
由上表可知：对于Last-Modified和Etag字段来说，只有在进行Ctrl+F5强制刷新时，这两个字段对缓存是否有效的控制才会失效。即强制刷新后，浏览器不会使用本地缓存，而是直接向服务器发起请求。
指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以响应资源的语言，字符集，编码方式等作为判断的基准。
有三种方式：
由客户端发起请求，服务器发送可选项列表，客户端作出选择后在发送第二次请求；
服务器检查客户端的请求头部集并决定提供哪个版本的页面；
某个中间设备（通常是缓存代理）代表客户端进行协商；
服务器驱动内容协商：请求首部集；
服务器驱动内容协商：实体首部集；
与请求首部集一一对应；
HTTP是通过在Header里两个参数实现的，客户端发出请求时对应的是Range，服务器端响应时对应的是Content-Range，如果续存成功返回206，如果文件有变动返回200和新文件的内容；
用于请求头中，指定第一个字节的位置和最后一个字节的位置，格式为：
//格式（左开右闭）Range:(unit=firstbytepos)-[lastbytepos]//示例Range:bytes=5001-10000接收到附带Range首部字段请求的服务器，会在处理请求之后返回状态码为206PartialContent的响应。无法处理该范围请求时，则会返回状态码200OK的响应及全部资源。
断点续传过程
HTTPS使用的是TSL协议（SSL是TSL协议的一种）；
HTTPS是一个大趋势
网络耗时：HTTP只需要通过TCP的三次握手就能建立HTTP连接：
而HTTPS除了TCP的三次握手外，甚至还需要耗费额外的7个RTP进行验证
关于302自动跳转，这是因为，比如访问百度，我们输入网址全称而是输入baidu.com，所以会自动跳转至HTTPS，这本身也需要耗时；
并且跳转后，URI不一样了，浏览器要与服务器重新通过三次握手建立TCP连接；
之后还要进行TLS协商，比如密钥交换算法，对称加密算法，内容一致性校验算法，证书签名算法等等；浏览器获取到证书后，也需要校验证书的有效性，比如证书是否过期，是否撤销等等；
接着，浏览器首先获取证书里的CA域名如果该CA域名没有命中缓存，浏览器需要解析域名的DNS，这个DNS解析至少耗费一个RTP；
DNS解析到IP之后就要完成三次握手，建立CA站点的TCP连接，这又耗费一个RTP；
再接着浏览器发送OCSP请求，获取响应耗费一个RTP；
最后就是TLS完全握手阶段2，这个阶段主要进行密钥协商，耗时一个RTP；随后进行应用层的TCP数据通信。
计算耗时
可以理解为WebSocket是为了让HTTP支持长连接而打的一个大补丁；
WebSocket是一个持久化的HTTP，而HTTP本身是非持久化的如下图所示：（虽然有Keep-Alive）
请求：
响应：
Upgrade：表示升级为WebSocket
HTTP的瓶颈
请求只能从客户端发起，客户端不可以接收除了响应之外的指令；当客户端需要监听服务器上的内容时，在HTTP中有一些优化处理方式，常用的用：Ajax轮询，LongPoll
原理为，客户端每隔几秒就发送一次请求，询问服务器到底有没有新消息；若有服务器返回新消息，没有就返回提示信息，如此循环：
与Ajax轮询原理相似，客户端先发出请求，直到服务器上有新数据返回之前，都不再发送请求，如此循环：
缺陷：两种方式都非常消耗资源，Ajax轮询需要服务器有很快地处理速度；LongPoll需要服务器有很大容量；
WebSocket解决上上述问题
首先使用HTTP协议通知服务器升级到WebSocket协议，随后在WebSocket协议中，服务器端是可以主动推送数据给客户端的，详细过程：
WebSocket的特点
相比于HTTP的长连接，WebSocket具有以下特点
SPDY是HTTP的增强，在向下兼容的情况下，在TLS层上新增一层会话层SPDY，使用这个会话层来实现SPDY协议，也就是说现有的服务格式均不用改变吗；SPDY是对HTTP的一个更好的实现和支持；
所以基于HTTP的上述缺陷，SPDY进行了以下改进：
直观的影响
对于前端工程师而言，页面优化永远是一个课题。有了SPDY的请求优化，可以将请求顺序重新编排，这样很大程度上缓解了页面加载时图片请求带来的影响；减少了HTTP的请求；
上面所讲的SPDY后来被谷歌放弃了，转而成为了HTTP2.0的前身，基于SPDY的核心改造升级开发出了HTTP2.0。所以两者有比较多相似的地方：
在HTTPS的基础上新增了二进制分帧层：BinaryFraming，在该层上HTTP2.0会将所有的传输信息分割成更小的消息和帧，并对其采用二进制格式的编码；
如下图所示：
HTTP2.0在服务器端和客户端使用首部表来跟踪和存储之前发送的键值对，对于相同的数据不再通过每次请求和响应发送，通讯期间几乎不会改变通用的键值对，比如：Host、User-agent等只需要发送一次；如果这个请求不包含首部，那么首部的开销就变为0字节了，此时首部都自动使用之前发送请求的首部；
如下图所示，Request#2中只需要在HEADERSframe里发送:path这个变化的头部即可，其他头部信息直接沿用Request#1的请求头；或者说新增或变化的头部信息会被追加到新的首部表中，如图中的Request#2。它在HTTP2.0的连接存续期内是始终存在的，由客户端和服务器端共同地渐进地更新；
多路复用这也是继承于SPDY协议的，HTTP2.0所有的通信都在一个TCP连接上完成。HTTP2.0把HTTP通信的基本单位缩小为一个一个的帧，这些帧对应于逻辑流里面的信息，并行的在同一个TCP连接上双向交换；
但链接多资源的优势
也就是说，资源合并减少请求的方式，对于HTTP2.0来说是没有效果，只会开发者无用的工作量而已。所以当HTTP2.0普及之后，像雪碧图呀，文件合并等就没有多大意义了。
简单点说就是可以乱序发送，在HTTP2.0上客户端和服务器可以把HTTP数据的消息分解为互不依赖的数据帧，然后乱序发送，最后在接收端把这些乱序帧重新组合起来。如图所示，同一个连接有多个不同方向的数据流在传输，所以客户端可以一边乱序地发送数据帧，也可以接收服务器的响应；服务器端也是如此都是双向的。
所以：把HTTP消息分解为独立的帧交错发送，然后在另一端重新组装是HTTP2.0一项很重要的增强；
这一特性会发生连锁反应带来巨大的性能提升：
HTTP2.0的这一特性也是继承于SPDY，服务器处理不同的流采取不同的优先策略；
毕竟HTTP2.0的核心是从SPDY的基础上衍生而来的；服务器可以对客户端的一个请求发送多个响应，即除了对最初请求的响应之外服务器还可以额外向服务器推送其他资源，而无需客户端明确请求；如图所示：客户端请求了html文件，服务器就会把js与css文件推送给客户端：
WebDAV（Web-basedDistributedAuthoringandVersioning，基于万维网的分布式创作和版本控制）是一个可对Web服务器上的内容直接进行文件复制、编辑等操作的分布式文件系统（可在线修改文件的网盘）。
除了创建、删除文件等基本功能，它还具备文件创建者管理、文件编辑过程中禁止其他用户内容覆盖的加锁功能，以及对文件内容修改的版本控制功能。
使用HTTP/1.1的PUT方法和DELETE方法，就可以对Web服务器上的文件进行创建和删除操作。可是出于安全性及便捷性等考虑，一般不使用。
WebDAV为实现远程文件管理，向HTTP/1.1中追加了以下这些方法。
新增状态码：
**WebDAV的请求实例**
PROPFIND/fileHTTP/1.1Host:www.example.comContent-Type:application/xml;charset="utf-8"Content-Length:219//...请求主体**WebDAV的响应实例**
HTTP/1.1207Multi-StatusContent-Type:application/xml;charset="utf-8"Content-Length:831//...响应主体不过可以使用FTP替代它；
当TCP连接中传输的数据流stream2中出现丢包时，在发送端没有重传丢失的包之前跟在stream2后面的stream3/4就被阻塞住了；
然而UDP连接中，数据流彼此间没有依赖关系，即使stream2出现丢包，也不影响其他stream数据的传输；
QUIC融合了UDP协议的速度性能和TCP的安全和可靠，大大优化了互联网传输数据的体验。
日常生活中的”安全“
全程WebApplicationSecurityConsortium：是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体，负责为WWW（万维网）制定广为人知的应用安全标准。
全称OpenWebApplicationSecurityProject，该组织致力于发现和解决不安全Web应用的根本原因；它们最重要的项目之一是Web应用的十大安全隐患
总结了目前Web应用最常受到的十种攻击手段，并且按照攻击发生的概率进行了排序（以下为2017年的数据）：
验证机制是Web应用程序中最简单的一种安全机制，也是防御恶意攻击的核心机制；
验证技术
弱密码
许多Web应用程序没有或很少对用户密码强度进行控制；
暴力破解
暴力破解-安全措施
令牌传输安全
增加软硬会话过期
这就是所谓的SQLInjection，即SQL注入；比如：
帐户名中输入的‘or’1=1会被识别为SQL操作指令；
参数化查询
比如使用问号当作占位符，这样即使输入了SQL语句这样也不会被认为是数据SQL的一部分，而是用户输入内容。
字符串过滤
使用正则表达式过滤传入的参数
跨站脚本攻击（CrossSiteScripting），XSS（CSS已被占用所以叫XSS）是一种经常出现在Web应用中的计算机安全漏洞；
它允许Web用户恶意地将代码植入到提供给其他用户使用的页面中，其他用户在观看网页时，恶意脚本就会执行；
MyspaceXSS攻击事件
针对XSS的攻击方式不同，可以把XSS分为如下三大类：
也称为非永久性XSS，目前最流行的XSS攻击；它出现在服务器直接服务器直接使用客户端提交的数据，如URL的数据、HTML表单中提交的数据，并且没有对数据进行无害化处理；如果提交的数据中含有HTML控制字符而没有被正确处理，那么一个简单的XSS攻击就会发生。
典型的反射式攻击方式可通过一个邮件或中间网站，诱饵是一个看起来可信任的站点的链接，其中包含XSS攻击脚本，比如社交群中常发的游戏活动、赌博、美女链接等。如果信任的网站没有正确处理这个脚本，用户点击后就会导致浏览器执行含有恶意攻击的脚本。
也称为永久性XSS，危害更大。攻击将攻击脚本上传到Web服务器上，使得所有访问该页面的用户都面临信息泄露的可能，其中也包括了Web服务器的管理员；
存储式XSS多发生在最终显示给其他用户的位置包含：
典型的存储式XSS攻击过程
反射式XSS攻击和存储式XSS攻击都是通过服务器提取用户提交的数据，并且以不安全的方式将其返回给用户；基于DOM的攻击仅仅通过JavaScript的方式执行；
也就是说这种攻击常发生在应用程序每次返回相同的静态页面（HTML文件），并通过客户端的js文件动态生成信息，并不会与服务器交互获取该js文件的时候；
会话令牌
虚拟置换
注入木马
应用程序之所以结合使用输入确认（次要）与输出净化（首要），原因在于这种方法能够提供两层防御：如果其中一层被攻破，另一层还能提供一些保护；
CSRF（Cross-siteRequestForgery）跨站请求伪造，也被称为OneClickAttack或者Sessionriding通常缩写为CSRF或者XSRF，是一种对网站的恶意利用；
尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左；
CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。
上文中讲了CSRF的两个特点：
针对这两点，我们可以专门制定防护策略，如下：
CSRF的一个特征是，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。
而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。