使用的网络是在TCP/IP协议族的基础上运做的。HTTP属于它内部的一个子集。javascript
协议:计算机与设备要互相通讯,双方就必须基于相同的方法。这种规则称为协议(protocol) html
TCP/IP协议族按层次分别分为4层:应用层、传输层、网络层、数据链路层。分层的优势是:单一职责和灵活变更。java
应用层:决定向用户提供应用服务时通讯的活动,例如:FTP、DNS。HTTP协议也处于该层。jquery
传输层:提供处于网络链接中的两台计算机之间的数据传输。例如:TCP、UDPgit
网络层:用来处理网络上流动的数据包,规定了经过怎样的路径到达对方计算机。例如:IP协议web
链路层:用来处理链接网络的硬件部分,包括操做系统、硬件设备驱动、光纤等物理部件。算法
发送端顺序从上往下,接收端顺序从下往上。数据库
举例:json
首先客户端在应用层发出一个HTTP请求。传输层把收到的HTTP报文进行分割,并标记序号和端口号发给网络层。api
网络层(IP协议)增长做为通讯目的地的MAC地址后转发给链路层
发送端层与层之间传输数据时,每通过一层则会打上该层所属的首部信息。接收端则通过每层都会把对应信息消除。
IP协议的做用是把各类数据包传送给对方,其中有两个条件必须知足:IP地址和MAC地址。
IP地址指明节点被分配到的地址,MAC地址是指网卡所属的固定地址。IP可变,MAC不可变。
IP间的通讯依赖MAC地址,一般是通过多台计算机和网络设备中转才能链接到对方。
在中转时,会利用下一站中转设备的MAC地址来搜索下一个中转目标。会采用APR协议。
ARP是一种用以解析地址的协议,根据通讯方的IP地址就能够反查出对应的MAC地址。
TCP位于传输层,提供可靠的字节流服务。指将大块数据分割成以报文段为单位的数据包进行管理。
TCP协议为了更容易传送大数据才把数据分割,并且TCP协议可以确认数据最终是否送达到对方。
三次握手
为了准确传送数据,TCP协议采用了三次握手策略。
1. 发送端首先发送一个带有SYN标志的数据包给对方。
2. 接收端收到后,回传一个带有SYN/ACK标志的数据包传达确认信息。
3. 发送端在回传一个带ACK标志的数据包,表示握手结束。
跟HTTP协议同样,处于应用层。DNS协议经过域名查找IP地址或从IP地址反查域名。
URL:统一资源定位符
Uniform:规定统一的格式方便处理多种不一样类型的资源,不用根据上下文环境来识别资源指定的访问方式。
Resource:字符串标志。资源定义是可标识的任何东西。文档、图形、服务
Identifier:可标识的对象。也称为标识符。
采用HTTP协议是,Uniform 就是http。URI用字符串标识某一互联网资源,URL表示资源的地址是URI的子集。
格式:http://(协议名)user:pass(登陆信息)@www.example.jp:80(服务器地址和端口号)/index.html(文件路径)?uid=1(查询字符串)@ch1(片断标识符,例如锚点)
进行HTTP协议通讯时,好比一端是客户端,另外一端是服务端。一定是客户端发送请求,服务端回复响应。
HTTP是不保存状态的协议:即无状态协议。HTTP协议自身不对请求和响应之间的通讯状态进行保存。
持久连接特色是:只要任意一端没有明确提出断开连接,则保持TCP连接状态。用来避免频繁建立连接使服务器压力增大。
HTTP/1.1中全部的连接默认都是持久连接。
管线化
持久链接使多数请求以管线化进行发送。能够作到同时并行发送多个请求,不须要一个接一个地等待响应。
压缩传输
HTTP协议中有一种内容编码的功能,指明应用在实体内容上的编码格式,并保存实体信息原样压缩。
内容编码后的实体由客户端接收并负责解码。
经常使用的内容编码有如下几种:
1. gzip(GNU zip)
2.compress(UNIX系统的标准压缩)
3.deflate(zlib)
4.identity(不进行编码)
分块传输
HTTP通讯中编码实体资源还没有彻底传输完成以前,浏览器没法显示请求页面。
在传输大容量数据时,经过把数据分割成多块,可以让浏览器逐步显示页面。
把实体主体分块的功能称为分块传输编码。
分块传输编码会将实体主体分红多个部分快,每一块用十六进制来标记块的大小,最后一块使用0来标记。
使用分块传输编码的实体主体会由接受的客户端负责解码,恢复到编码前的实体主体。
HTTP/1.1中存在一种称为传输编码的机制,它能够在通讯时按某种编码方式传输,但只定义做用于分块传输编码中。
MIME机制,容许邮件处理文本、图片、视频等多个不一样类型的数据。例如:图片等二进制数据以ASCII码字符串编码的方式,
就是利用MIME来描述标记数据类型。而在MIME扩展中会使用一种称为多部分对象集合的方法,来容纳多份不一样类型的数据。
若是下载过程当中网络中断,就必须从头开始。为了解决问题,须要一种可恢复的机制。能够从以前下载中断处恢复下载。
要实现该功能须要指定下载实体范围。指定范围发送的请求叫作范围请求。
对一份10000字节大小的资源,若是使用范围请求,能够只请求5001-10000字节内的资源。
执行范围请求时,会用到首部资源Range来指定资源的byte范围。例如:
Range:bytes=5001-10000 (从5000-10000)
Range:bytes=5001- (从5001字节以后所有的)
Range:bytes=-3000,5000-7000 (从开始到3000和5000-7000字节)
针对范围请求,响应会返回 206(部份内容)的响应报文。对于多重范围的范围请求,响应在首部字段。
若是没法响应范围请求,则会返回状态码200和完整的实体内容。
当浏览器的默认语言为英文时,访问相同的URI和Web页面则会显示对应的英语版的页面。
指客户端和服务端就响应的资源内容进行交涉,而后提供给客户端最为适合的资源。
内容协商会以响应资源的语言、字符集、编码方式等做为判断的基准。
状态码中第一位指定了响应类别,后两位无分类。响应类别有以下5中。
1XX:接受的请求正在处理
2XX:请求正常处理完毕
3XX:须要进行附加操做已完成请求
4XX:服务器没法处理请求
5XX:服务器处理请求出错
常用的有14中状态码
200 OK
表示从客户端发来的请求被正常处理了
204 No Content
表明服务器接收的请求以成功处理,但在返回的响应报文中不含实体的主体部分。
好比:发送请求处理后,返回204响应,浏览器不发生更新。
206 Partial Content
客户端进行了范围请求,而服务器成功执行了这部分的Get请求。
响应报文中包含有Content-Range 指定范围的实体内容。
301 Moved Permanently
永久性重定向,表示请求资源已被分配了新的URI。
302 Found
临时性重定向。该状态码表示请求的资源已被分配了新的URI。
303 See Other
请求对应的资源存在着另外一个URI,应使用Get方法定义获取请求的资源。
304 Not Modified
不包含任何响应的主体部分。
307 Temporary Redirect
临时重定向,跟302相比,不会从POST变成GET。
400 Bad Request
请求表文中存在语法错误。需修改请求的内容后再次发送请求。
401 Unauthorized
用户认证失败,没有经过HTTP认证。
403 Forbidden
对请求资源的访问被服务器拒绝了。服务器没有必要给出拒绝的详细理由。
未获取文件系统的访问受权,或从未受权的地址发送IP地址试图访问。都是403的缘由。
404 Not Found
没法找到请求的资源
500 Internal Server Error
服务器端在执行请求时发生了错误,也有多是Web应用存在bug或某些临时的故障。
503 Service Unavailable
服务器出超负载或进行停机维护
HTTP通讯时,除客户端和服务器外,还有一些用于通讯数据转发的程序。
代理
一种有转发功能的应用程序,扮演了位于服务器和客户端“中间人”角色。接受由客户端发送的请求并转发给服务器。
网关
网关是转发其余服务器通讯数据的服务器,接受从客户端发来的请求。对请求进行处理。
隧道
隧道是在相隔甚远的客户端和服务器二者之间进行中转,并保存双方通讯链接的应用程序。
缓存指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减小对源服务器的访问。
缓存服务器是代理服务器的一种,并归类在缓存代理类型中。当代理转发从服务器返回的响应时,会保存一份资源的副本。
优点:利用缓存可避免屡次从源服务器转发资源,所以客户端可就近从缓存服务器上获取资源。
有效期
当赶上源服务器上的资源更新时,若是仍是使用不变的缓存,那就会变成返回更新前的旧资源了。
所以会因客户端的要求,花奴才能的有效期等因素。源服务器肯定缓存的有效性。如失效则会重新获取。
客户端的缓存
缓存还能够存在客户端浏览器中。若是有效就没必要向服务器请求相同的资源了,能够从本地直接读取。
当判断缓存国旗后,服务器肯定资源的有效性。若浏览器缓存失效,浏览器会再次请求缓存。
HTTP头分为4种
1.通用首部字段
请求报文和响应报文两方都会使用的首部。
2.请求首部字段
补充了请求的附加内容、客户端信息、响应内容相关优先级等信息
3.响应首部字段
补充了响应的附加内容,要求客户端附加额外的内容信息。
4.实体首部字段
针对请求报文和响应报文的实体部分使用的首部。补充了资源内容、更新时间等于实体有关的信息。
详细列表:HTTP头明细说明
1、做用
不使用SSL/TLS的HTTP通讯,就是不加密的通讯。全部信息明文传播,带来了三大风险。
(1) 窃听风险(eavesdropping):第三方能够获知通讯内容。
(2) 篡改风险(tampering):第三方能够修改通讯内容。
(3) 冒充风险(pretending):第三方能够冒充他人身份参与通讯。
SSL/TLS协议是为了解决这三大风险而设计的,但愿达到:
(1) 全部信息都是加密传播,第三方没法窃听。
(2) 具备校验机制,一旦被篡改,通讯双方会马上发现。
(3) 配备身份证书,防止身份被冒充。
互联网是开放环境,通讯双方都是未知身份,这为协议的设计带来了很大的难度。并且,协议还必须可以经受全部匪夷所思的攻击,这使得SSL/TLS协议变得异常复杂。
2、历史
互联网加密通讯协议的历史,几乎与互联网同样长。
1994年,NetScape公司设计了SSL协议(Secure Sockets Layer)的1.0版,可是未发布。
1995年,NetScape公司发布SSL 2.0版,很快发现有严重漏洞。
1996年,SSL 3.0版问世,获得大规模应用。
1999年,互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。
2006年和2008年,TLS进行了两次升级,分别为TLS 1.1版和TLS 1.2版。最新的变更是2011年TLS 1.2的修订版。
目前,应用最普遍的是TLS 1.0,接下来是SSL 3.0。可是,主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0一般被标示为SSL 3.1,TLS 1.1为SSL 3.2,TLS 1.2为SSL 3.3。
3、基本的运行过程
SSL/TLS协议的基本思路是采用公开密钥加密法,也就是说,客户端先向服务器端索要公钥,而后用公钥加密信息,服务器收到密文后,用本身的私钥解密。
可是,这里有两个问题。
(1)如何保证公钥不被篡改?
解决方法:将公钥放在数字证书中。只要证书是可信的,公钥就是可信的。数字证书认证机构CA,双方均可信赖的第三方机构。
使用CA之后的流程变为:
1.服务器向机构提出申请,机构判明申请者身份后,会对已申请的公开密钥证书作数字签名,而后分配这个已签名的公开密钥。
2.服务器会将这份由数字证书认证机构颁发的公钥证书发给客户端,并进行公共密钥加密方式通讯。
3.接到证书的客户端可以使用数字证书认证机构的公开密钥,对那证书上的签名进行验证。
公开密钥转交给客户端,是一件很困难的事情,所以多数浏览器开发商会在内部植入经常使用的认证机关的公开密钥。
(2)公钥加密计算量太大,如何减小耗用的时间?
解决方法:每一次对话(session),客户端和服务器端都生成一个"对话密钥"(session key),用它来加密信息。因为"对话密钥"是对称加密,因此运算速度很是快,而服务器公钥只用于加密"对话密钥"自己,这样就减小了加密运算的消耗时间。
所以,SSL/TLS协议的基本过程是这样的:
(1) 客户端向服务器端索要并验证公钥。
(2) 双方协商生成"对话密钥"。
(3) 双方采用"对话密钥"进行加密通讯。
上面过程的前两步,又称为"握手阶段"(handshake)。
4、握手阶段的详细过程
"握手阶段"涉及四次通讯,咱们一个个来看。须要注意的是,"握手阶段"的全部通讯都是明文的。
4.1 客户端发出请求(ClientHello)
首先,客户端(一般是浏览器)先向服务器发出加密通讯的请求,这被叫作ClientHello请求。
在这一步,客户端主要向服务器提供如下信息。
(1) 支持的协议版本,好比TLS 1.0版。
(2) 一个客户端生成的随机数,稍后用于生成"对话密钥"。
(3) 支持的加密方法,好比RSA公钥加密。
(4) 支持的压缩方法。
这里须要注意的是,客户端发送的信息之中不包括服务器的域名。也就是说,理论上服务器只能包含一个网站,不然会分不清应该向客户端提供哪个网站的数字证书。这就是为何一般一台服务器只能有一张数字证书的缘由。
对于虚拟主机的用户来讲,这固然很不方便。2006年,TLS协议加入了一个Server Name Indication扩展,容许客户端向服务器提供它所请求的域名。
4.2 服务器回应(SeverHello)
服务器收到客户端请求后,向客户端发出回应,这叫作SeverHello。服务器的回应包含如下内容。
(1) 确认使用的加密通讯协议版本,好比TLS 1.0版本。若是浏览器与服务器支持的版本不一致,服务器关闭加密通讯。
(2) 一个服务器生成的随机数,稍后用于生成"对话密钥"。
(3) 确认使用的加密方法,好比RSA公钥加密。
(4) 服务器证书。
除了上面这些信息,若是服务器须要确认客户端的身份,就会再包含一项请求,要求客户端提供"客户端证书"。好比,金融机构每每只容许认证客户连入本身的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。
4.3 客户端回应
客户端收到服务器回应之后,首先验证服务器证书。若是证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已通过期,就会向访问者显示一个警告,由其选择是否还要继续通讯。
若是证书没有问题,客户端就会从证书中取出服务器的公钥。而后,向服务器发送下面三项信息。
(1) 一个随机数。该随机数用服务器公钥加密,防止被窃听。
(2) 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(3) 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的全部内容的hash值,用来供服务器校验。
上面第一项的随机数,是整个握手阶段出现的第三个随机数,又称"pre-master key"。有了它之后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。
至于为何必定要用三个随机数,来生成"会话密钥",dog250解释得很好:
"无论是客户端仍是服务器,都须要随机数,这样生成的密钥才不会每次都同样。因为SSL协议中证书是静态的,所以十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来讲,pre-master-key自己就是一个随机数,再加上hello消息中的随机,三个随机数经过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每一个主机都能产生彻底随机的随机数,若是随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret做为密钥就不合适了,所以必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能彻底不随机,但是是三个伪随机就十分接近随机了,每增长一个自由度,随机性增长的可不是一。"
此外,若是前一步,服务器要求客户端证书,客户端会在这一步发送证书及相关信息。
4.4 服务器的最后回应
服务器收到客户端的第三个随机数pre-master key以后,计算生成本次会话所用的"会话密钥"。而后,向客户端最后发送下面信息。
(1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的全部内容的hash值,用来供客户端校验。
至此,整个握手阶段所有结束。接下来,客户端与服务器进入加密通讯,就彻底是使用普通的HTTP协议,只不过用"会话密钥"加密内容。
Web攻击分为两种:主动攻击和被动攻击
主动攻击:指攻击者经过访问Web应用,把攻击代码传入的攻击模式。例如:SQL注入
被动攻击:指利用圈套策略执行攻击代码的攻击模式。攻击者不直接对目标发起攻击。例如:XSS(跨站脚本攻击)和CSRF(跨站请求伪造)
步骤大体以下:
1.攻击者诱导用户触发已设置好的陷阱,而陷阱会启动发送已嵌入攻击代码的HTTP请求。
2.当用户不知不觉中招后,用户的浏览器或邮件客户端就会触发这个陷阱。
3.中招后的用户浏览器会把含有攻击代码的HTTP请求发送给做为攻击目标的Web应用,运行攻击代码。
4.存在安全漏洞的Web应用会成为攻击者的跳板,可能致使用户所持的Cookie等我的信息被窃取。
Cross-Site Scripting,XSS:是指经过存在安全漏洞的Web网站注册用户的浏览器运行非法的HTML标签或JavaScript进行的一种攻击。
动态建立的HTML部分有可能隐藏着安全漏洞。攻击者编写脚本设下陷阱,用户在本身的浏览器上运行时,不当心就会受到攻击。
攻击可能形成的影响:
1.利用虚假输入表单骗取用户我的信息。
2.利用脚本窃取用户的Cookie值,被害者在不知情的状况下,帮助攻击者发送恶意请求。
3.显示伪造的文章或图片。
例如:
<head> <meta charset="UTF-8"> <title>Title</title> <script src=" app/bower_components/jquery/dist/jquery.min.js"></script> <script type="text/javascript"> function SaveForm(){ $("#spName").html($("#txtName").val()); } </script> </head> <body> 姓名:<input type="text" id="txtName" /> <span id="spName"></span> <button onclick="SaveForm()">保存</button> </body>
如上所示,我若是在姓名中输入:<script>window.open('http://www.baidu.com');</script>。就会执行脚本,进行跳转。
一般HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。客户端向服务器发送一个请求,请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的相似于MIME的消息结构。服务器以一个状态行做为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
Http协议定义了不少与服务器交互的方法,最基本的有4种,分别是GET、POST、PUT、DELETE。一个URL地址用于描述一个网络上的资源,而HTTP中的GET、POST、PUT、 DELETE就对应着对这个资源的查、改、增、删4个操做,咱们最多见的就是GET和POST了。GET通常用于获取/查询资源信息,而POST通常用于更新资源信息。
HTTP头信息解读
HTTP的头域包括通用头、请求头、响应头和实体头四个部分。每一个头域由一个域名,冒号(:)和域值三部分组成。
通用头部是客户端和服务器均可以使用的头部,能够在客户端、服务器和其余应用程序之间提供一些很是有用的通用功能,如Date头部。
请求头部是请求报文特有的,它们为服务器提供了一些额外信息,好比客户端但愿接收什么类型的数据,如Accept头部。
响应头部便于客户端提供信息,好比,客服端在与哪一种类型的服务器进行交互,如Server头部。
实体头部指的是用于应对实体主体部分的头部,好比,能够用实体头部来讲明实体主体部分的数据类型,如Content-Type头部。
HTTP通用头
通用头域包含请求和响应消息都支持的头域,通用头域包含缓存头部Cache-Control、Pragma及信息性头部Connection、Date、Transfer-Encoding、Update、Via。
一、Cache-Control
Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会修改另外一个消息处理过程当中的缓存处理过程。
缓存请求指令 (指令:参数:说明)
缓存响应指令
二、Pragma
Pragma头域用来包含实现特定的指令,最经常使用的是Pragma:no-cache。在HTTP/1.1协议中,它的含义和Cache- Control:no-cache相同。
三、Connection
Connection表示是否须要持久链接。若是Servlet看到这里的值为“Keep-Alive”,或者看到请求使用的是HTTP 1.1(HTTP 1.1默认进行持久链接),它就能够利用持久链接的优势,当页面包含多个元素时(例如Applet,图片),显著地减小下载所须要的时间。要实现这一点,Servlet须要在应答中发送一个Content-Length头,最简单的实现方法是:先把内容写入ByteArrayOutputStream,而后在正式写出内容以前计算它的大小。
Close:告诉WEB服务器或者代理服务器,在完成本次请求的响应后,断开链接,不要等待本次链接的后续请求了。
Keepalive:告诉WEB服务器或者代理服务器,在完成本次请求的响应后,保持链接,等待本次链接的后续请求。
Keep-Alive:若是浏览器请求保持链接,则该头部代表但愿 WEB 服务器保持链接多长时间(秒),如Keep-Alive:300。
四、Date
Date头域表示消息发送的时间,服务器响应中要包含这个头部,由于缓存在评估响应的新鲜度时要用到,其时间的描述格式由RFC822定义。例如,Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的时间表示世界标准时,换算成本地时间,须要知道用户所在的时区。
五、Trailer
说明在报文主体后记录了哪些首部字段,该字段可应用在分块传输编码时。
五、Transfer-Encoding
WEB 服务器代表本身对本响应消息体(不是消息体里面的对象)做了怎样的编码,好比是否分块(chunked),例如:Transfer-Encoding: chunked
六、Upgrade
它能够指定另外一种可能彻底不一样的协议,如HTTP/1.1客户端能够向服务器发送一条HTTP/1.0请求,其中包含值为“HTTP/1.1”的Update头部,这样客户端就能够测试一下服务器是否也使用HTTP/1.1了。
七、Via
列出从客户端到 OCS 或者相反方向的响应通过了哪些代理服务器,他们用什么协议(和版本)发送的请求。
当客户端请求到达第一个代理服务器时,该服务器会在本身发出的请求里面添加 Via 头部,并填上本身的相关信息,当下一个代理服务器 收到第一个代理服务器的请求时,会在本身发出的请求里面复制前一个代理服务器的请求的Via头部,并把本身的相关信息加到后面,以此类推,当 OCS 收到最后一个代理服务器的请求时,检查 Via 头部,就知道该请求所通过的路由。例如:Via:1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)
七、Warning
Warning首部是从HTTP/1.0的响应首部演变过来的,告知用户一些与缓存相关的警告。一共7种警告:
HTTP请求头
请求头用于说明是谁或什么在发送请求、请求源于何处,或者客户端的喜爱及能力。服务器能够根据请求头部给出的客户端信息,试着为客户端提供更好的响应。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通信双方都支持,若是存在不支持的请求头域,通常将会做为实体头域处理。
八、Accept
告诉WEB服务器本身接受什么介质类型,*/* 表示任何类型,type/* 表示该类型下的全部子类型,type/sub-type。
例如:Accept:text/plain;q=0.3,text/htm。q表示优先级,范围是0-1,使用;进行分割。也就是优先给我html。
九、Accept-Charset
浏览器告诉服务器本身能接收的字符集。
十、Accept-Encoding
浏览器申明本身接收的编码方法,一般指定压缩方法,是否支持压缩,支持什么压缩方法(gzip,deflate)。
十一、Accept-Language
浏览器申明本身接收的语言。语言跟字符集的区别:中文是语言,中文有多种字符集,好比big5,gb2312,gbk等等。
十二、Authorization
当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时,用该头部来回应本身的身份验证信息给WEB服务器。
1三、If-Match
若是对象的 ETag 没有改变,其实也就意味著对象没有改变,才执行请求的动做,获取文档。
1四、If-None-Match
若是对象的 ETag 改变了,其实也就意味著对象也改变了,才执行请求的动做,获取文档。
1五、If-Modified-Since
若是请求的对象在该头部指定的时间以后修改了,才执行请求的动做(好比返回对象),不然返回代码304,告诉浏览器该对象没有修改。例如:If-Modified-Since:Thu, 10 Apr 2008 09:14:42 GMT
1六、If-Unmodified-Since
若是请求的对象在该头部指定的时间以后没修改过,才执行请求的动做(好比返回对象)。
1七、If-Range
浏览器告诉 WEB 服务器,若是我请求的对象没有改变,就把我缺乏的部分给我,若是对象改变了,就把整个对象给我。浏览器经过发送请求对象的ETag 或者本身所知道的最后修改时间给 WEB 服务器,让其判断对象是否改变了。老是跟 Range 头部一块儿使用。
1八、Range
浏览器(好比 Flashget 多线程下载时)告诉 WEB 服务器本身想取对象的哪部分。例如:Range: bytes=1173546
1九、Proxy-Authenticate
代理服务器响应浏览器,要求其提供代理身份验证信息。
20、Proxy-Authorization
浏览器响应代理服务器的身份验证请求,提供本身的身份信息。
2一、Host
客户端指定本身想访问的WEB服务器的域名/IP 地址和端口号。如Host:rss.sina.com.cn
2二、Referer
浏览器向WEB 服务器代表本身是从哪一个网页URL得到点击当前请求中的网址/URL,例如:Referer:http://www.jb51.net
2三、User-Agent
浏览器代表本身的身份(是哪一种浏览器)。例如:User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
HTTP响应头
响应头向客户端提供一些额外信息,好比谁在发送响应、响应者的功能,甚至与响应相关的一些特殊指令。这些头部有助于客户端处理响应,并在未来发起更好的请求。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通信双方都支持,若是存在不支持的响应头域,通常将会做为实体头域处理。
2四、Age
当代理服务器用本身缓存的实体去响应请求时,用该头部代表该实体从产生到如今通过多长时间了。
2五、Server
WEB 服务器代表本身是什么软件及版本等信息。例如:Server:Apache/2.0.61 (Unix)
2六、Accept-Ranges
WEB服务器代表本身是否接受获取其某个实体的一部分(好比文件的一部分)的请求。bytes:表示接受,none:表示不接受。
2七、Vary
WEB服务器用该头部的内容告诉 Cache 服务器,在什么条件下才能用本响应所返回的对象响应后续的请求。假如源WEB服务器在接到第一个请求消息时,其响应消息的头部为:Content-Encoding: gzip; Vary: Content-Encoding,那么Cache服务器会分析后续请求消息的头部,检查其Accept-Encoding,是否跟先前响应的Vary头部值一致,便是否使用相同的内容编码方法,这样就能够防止Cache服务器用本身Cache 里面压缩后的实体响应给不具有解压能力的浏览器。例如:Vary:Accept-Encoding。
HTTP实体头
实体头部提供了有关实体及其内容的大量信息,从有关对象类型的信息,到可以对资源使用的各类有效的请求方法。总之,实体头部能够告知接收者它在对什么进行处理。请求消息和响应消息均可以包含实体信息,实体信息通常由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括信息性头部Allow、Location,内容头部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD五、Content-Range、Content-Type,缓存头部Etag、Expires、Last-Modified、extension-header。
2八、Allow
服务器支持哪些请求方法(如GET、POST等)。
2九、Location
表示客户应当到哪里去提取文档,用于将接收端定位到资源的位置(URL)上。Location一般不是直接设置的,而是经过HttpServletResponse的sendRedirect方法,该方法同时设置状态代码为302。
30、Content-Base
解析主体中的相对URL时使用的基础URL。
3一、Content-Encoding
WEB服务器代表本身使用了什么压缩方法(gzip,deflate)压缩响应中的对象。例如:Content-Encoding:gzip
3二、Content-Language
WEB 服务器告诉浏览器理解主体时最适宜使用的天然语言。
3三、Content-Length
WEB服务器告诉浏览器本身响应的对象的长度或尺寸,例如:Content-Length: 26012
3四、Content-Location
资源实际所处的位置。
3五、Content-MD5
主体的MD5校验和。
3六、Content-Range
实体头用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。通常格式: Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如,传送头500个字节次字段的形式:Content-Range:bytes0- 499/1234若是一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围,Content-Length表示实际传送的字节数。
3七、Content-Type
WEB 服务器告诉浏览器本身响应的对象的类型。例如:Content-Type:application/xml
3八、Etag
就是一个对象(好比URL)的标志值,就一个对象而言,好比一个html文件,若是被修改了,其Etag也会别修改,因此,ETag的做用跟Last-Modified的做用差很少,主要供WEB服务器判断一个对象是否改变了。好比前一次请求某个html文件时,得到了其 ETag,当此次又请求这个文件时,浏览器就会把先前得到ETag值发送给WEB服务器,而后WEB服务器会把这个ETag跟该文件的当前ETag进行对比,而后就知道这个文件有没有改变了。
3九、Expires
WEB服务器代表该实体将在何时过时,对于过时了的对象,只有在跟WEB服务器验证了其有效性后,才能用来响应客户请求。是 HTTP/1.0 的头部。例如:Expires:Sat, 23 May 2009 10:02:12 GMT
40、Last-Modified
WEB服务器认为对象的最后修改时间,好比文件的最后修改时间,动态页面的最后产生时间等等。例如:Last-Modified:Tue, 06 May 2008 02:42:43 GMT
目前最流行的一种互联网软件结构。它结构清晰,符合标准,易于理解,扩展方便。
REST,即Representational State Transfer的缩写,表现层状态话转换。
若是一个架构符合REST原则,则称为RESTful架构。
REST的名称表示层状态转化,表示层指资源的表现层
资源,就是网络上的一个实体,或者网络上的一个具体信息。能够是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实现。能够用一个URI指向它,每种资源对应一个特定的URI。要获取这个资源,访问它的URI就能够,所以URI就成了每个资源的地址或独一无二的识别符。
表示层,把资源具体呈现出来的形式,叫作它的表示层。
好比,文本能够用txt格式表现,也能够用HTML格式,XML格式,JSON格式表现,甚至能够采用二进制格式。图片能够用JPG格式表现,也能够用PNG格式表现。
URI只表明资源的尸体,不表明它的形式。
状态转化,互联网通讯协议HTTP协议是一个无状态协议。全部的状态都保存在服务器端。所以若是客户端想要操做服务器,必须经过某种手段,让服务端发生状态转化(State Transfer)。而这种转化是创建在表现层之上的,就是 表现层状态转化。
客户端用到的手段,只能是HTTP协议。具体来讲,HTTP协议里面,
四个表示操做方式的动词:GET、POST、PUT、DELETE。分别对应四种基本操做。
总结如下RESTful架构
误区
最多见的一种设计错误,就是URI包含动词。由于资源表示一种实体,因此应该是名词,URI不该该有动词,动词应该放在HTTP协议中。
举例:某个URI是/post/show/1,其中show是动词,这个URI就设计错误了。正确的是:/post/1,而后用GET方法表示show
若是某些动做是HTTP动词表达不了的,就应该把动做作成一种资源。
好比网上汇款,错误的URI是
POST /accounts/1/transfer/500/to/2
正确的是
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
协议
API与用户通讯协议,使用HTTPS协议
域名
API部署在专用域名下,使用二级域名:api.example.com
若是很简单,而且不会进一步扩展,能够考虑放在主域名下:example.org/api
路径
RESTful架构中,每个网址表明一种资源,因此网址中不能有动词,只能有名词,并且名词每每与数据库中的表格名对应。数据库中的表是同种记录的集合,因此API中的名词也应该使用复数
举例,有一个API提供动物园信息,则路径应该设计下面这样
HTTP动词
经常使用的HTTP动词有下面五个
过滤信息
若是记录数据不少,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果
状态吗
服务器向用户返回的状态码和提示信息,常见的有如下一些
错误处理
若是状态码是4xx,应该向用户返回出错信息。返回的信息将error做为键名,错误信息做为键值便可
error: "Invalid API key"
返回结果
针对不一样操做,服务器向用户返回的结果应该符合如下规范
服务器返回的数据格式,尽可能使用JSON,避免使用XML
OAuth是一个关于受权的开放网络标准。
名词定义
须要了解几个专用名词,尤为是几张图
OAuth的做用就是让客户端安全可控地获取用户的受权,与服务商提供商进行互动
OAuth的思路
在客户端与服务提供商之间,设置了一个受权层(authorization layer)。客户端不能直接登录服务提供商,只能登录受权层,以此将用户客户端区分开来。客户端 登录受权层所用的令牌(token),与用户的密码不一样。用户能够在登录的时候,指定受权层令牌的权限范围和有效期。
客户端登录受权层以后,服务提供商根据令牌的权限范围和有效期,向客户端开放用户存储的资料
运行流程
B是关键,即用户怎样才能给与客户端受权。有了这个受权以后,客户端就能够获取令牌,进而凭借令牌获取资源
客户端受权模式
客户端必须获得用户的受权,才能得到令牌。OAuth定义了四种受权方式
受权码模式
功能最完整、流程最严密的受权模式。特色就是经过客户端的后台服务器,与服务提供商的认证服务器进行互动
下面是这些步骤所需的参数
A步骤,客户端申请认证URI,包含如下参数
例子
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
C步骤,服务器回应客户端的URI
例子
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
D步骤,客户端向认证服务器申请令牌的HTTP请求,包含如下参数
例子
POST /token HTTP/1.1
Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
E步骤,认证服务器发送HTTP回复,包含如下参数
例子
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
从上面代码能够看到,相关参数使用JSON格式发送(Content-Type:application/json)。HTTP头信息中明确指定不得缓存
简化模式
不经过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了受权码这个步骤。
全部步骤在浏览器中完成,令牌对访问者可见,且客户端不须要认证
下面是上面这些步骤所须要的参数。
A步骤中,客户端发出的HTTP请求,包含如下参数:
下面是一个例子。
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com
C步骤中,认证服务器回应客户端的URI,包含如下参数:
下面是一个例子。
HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
在上面的例子中,认证服务器用HTTP头信息的Location栏,指定浏览器重定向的网址。注意,在这个网址的Hash部分包含了令牌。
根据上面的D步骤,下一步浏览器会访问Location指定的网址,可是Hash部分不会发送。接下来的E步骤,服务提供商的资源服务器发送过来的代码,会提取出Hash中的令牌。
密码模式
用户向客户端提供本身的用户名和密码。客户端使用这些信息,向"服务商提供商"索要受权。
在这种模式中,用户必须把本身的密码给客户端,可是客户端不得储存密码。这一般用在用户对客户端高度信任的状况下,好比客户端是操做系统的一部分,或者由一个著名公司出品。而认证服务器只有在其余受权模式没法执行的状况下,才能考虑使用这种模式。
(A)用户向客户端提供用户名和密码。
(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。
(C)认证服务器确认无误后,向客户端提供访问令牌。
B步骤中,客户端发出的HTTP请求,包含如下参数:
下面是一个例子。
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3w
C步骤中,认证服务器向客户端发送访问令牌,下面是一个例子
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
整个过程当中,客户端不得保存用户的密码
客户端模式
客户端模式(Client Credentials Grant)指客户端以本身的名义,而不是以用户的名义,向"服务提供商"进行认证。严格地说,客户端模式并不属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以本身的名义要求"服务提供商"提供服务,其实不存在受权问题。
A步骤中,客户端发出的HTTP请求,包含如下参数:
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=client_credentials
认证服务器必须以某种方式,验证客户端身份
B步骤中,认证服务器向客户端发送访问令牌
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" }
更新令牌
若是用户访问的时候,客户端的"访问令牌"已通过期,则须要使用"更新令牌"申请一个新的访问令牌。
客户端发出更新令牌的HTTP请求,包含如下参数:
例子
POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
#
IIS 5.x 运行在进程InetInfo.exe中,进程寄宿一个World Wide Web Publishing Service(W3SVC)服务。
W3SVC主要负责HTTP请求的监听、激活管理工做进程、加载配置等。
当检测到HTTP请求,IIS根据扩展名判断请求是静态仍是动态。
静态资源,IIS直接响应内容。
动态资源,根据扩展名从IIS的处理程序映射中找到ISAPI动态连接库(Dynamic Link Library,DLL)
ISAPI,是一套本地的Win32 API,是IIS和其余动态Web应用或平台之间的纽带。
ISAPI支持ISAPI扩展和ISAPI筛选,扩展处理HTTP请求的接口。筛选能够进行查看,修改,转发,拒绝。
当收到ASP.NET资源请求,ISAPI会建立ASP.NET工做进程aspnet.exe.
IIS进程与工做进程之间经过命名管道(Named Pipes)进行通讯。
工做进程初始化时,CLR会加载以构建一个托管的环境。对于某个Web应用的初次请求,CLR会为其建立一个AppDomain应用程序域。
寄存在IIS5.x的全部Web应用都运行在同一个进程的不一样AppDomain里面。
IIS6针对IIS5有如下两点修改。
1. 将ISAPI动态连接库直接加载到工做进程中。
2. IIS6引用应用程序池的机制,能够为一个或多个Web应用建立一个应用程序池。以免全部应用都在一个进程里
能够为一个或多个Web应用建立应用程序池,每一个应用程序池对应一个独立的工做进程,运行在不一样应用程序池中的Web引用基于进程级别的隔离机制。
IIS6建立了一个HTTP.SYS的监听器,以驱动程序的形式运行在Windows内核模式下,是TCP/IP网络子系统的一部分。
HTTP.SYS好处以下
持续监听:因为是网络驱动程序,始终处于运行状态,对用户的HTTP请求可以及时做出反应。
更好的稳定性:HTTP.SYS运行在操做系统内核模式下,并不执行任何用户代码,自己不会受到Web应用,工做进程,IIS进程的影响。
数据缓存:某个资源被频繁请求,HTTP.SYS会把响应的内容进行缓存。
W3SVC在IIS6中,从进程InetInfo.exe转移到SvcHost.exe中了。
当HTTP.SYS监听到HTTP请求,将其分发给W3SVC进行解析,获取目标应用,得到目标应用运行的程序池或工做进程。
工做进程初始化过程当中,ISAPI动态库被加载,负责进行CLR的加载、应用程序域的建立和Web初始化等工做。
引入了Windows进程激活服务(Windows Process Activation Service,WAS)分流W3SVC承载的部分功能。
W3SVC有三大功能
1.HTTP请求接受:接受HTTP.SYS监听到的HTTP请求
2.配置管理:从元数据库中加载配置信息对相关组件进行配置
3.进程管理:建立、回收、监控工做进程
其中后两个功能实现到WAS中了。提供了非HTTP协议的支持,经过监听适配器接口,抽象出针对不一样协议的监听器。
对应3中监听器,他们以Windows服务的形式进行工做。
NetTcpPortSharing:为WCF提供TCP端口共享,即同一个监听端口被多个进程共享
NetTcpActivator:为WAS提供基于TCP的激活请求,包含TCP监听器和对应的监听适配器
NetPipeActivator:为WAS提供命名管道的激活请求
NetMsmqActivator:为WAS提供基于MSMQ的激活请求
不管是从W3SVC接受到的请求,仍是监听器接受的请求,最终都会流转到WAS中。
IIS7分为两种模式,经典模式跟IIS6相同,集成模式是一种统一的处理管道。
将ASP.NET请求管道和IIS请求管道组合在一块儿。能够提供更好的性能,能够完成配置和管理的模块化。继承模式的映射都在web.config中进行处理。
IIS与ASP.NET是两个相互独立的管道,各自具备本身的一套HTTP处理机制。两个管道经过ISAPI连通。
IIS是第一道屏障,进行必要的前期处理。IIS经过ISAPI将请求分发给ASP.NET管道。
ASP.NET在自身管道范围内完成对HTTP请求的处理,结束后再返回IIS。IIS在进行后期处理。
IIS运行在非托管的环境中,ASP.NET管道则是托管。托管环境指CLR搭建的环境,非托管环境指能够由Windows直接调用。
HTTP.SYS接收到HTTP请求是对web应用的第一次访问,加载CLR后IIS会经过AppDomainFactory建立一个AppDomaiin。
ISApiRuntime被加载,会接管该HTTP请求。
建立一个IsapiWorkerRequest对象封装当前的HTTP请求,将此对象传递给CLR的HttpRuntime(当前应用程序的 ASP.NET 运行时服务)
此时,HTTP请求正式进入ASP.NET管道。HttpRuntime会根据对象建立HTTPContext( HTTP 请求的全部 HTTP 特定的信息)俗称 请求上下文
HttpContext建立后,HttpRuntime会利用HttpApplicationFacotry建立HttpApplication(ASP.NET 应用程序内全部应用程序对象公用的方法、属性和事件)
HttpApplication初始化过程当中,ASP.NET会根据配置文件加载并初始化HttpModule(HTTP模块初始化和处置事件)
HttpApplication会在处理HTTP请求的不一样阶段触发不一样的事件,HttpModule经过注册事件, 将操做注入HTTP请求处理流程中。
(定义对 ASP.NET 应用程序内全部应用程序对象公用的方法、属性和事件。 此类是用户在 Global.asax 文件中定义的应用程序的基类)
整个ASP.NET基础架构的核心,负责处理分发给它的HTTP请求。
第一个请求抵达后,会建立多个HttpApplication对象,存放于对象池中。
在HTTPAppliccation处理请求的不一样阶段会触发不一样的事件。
对于ASP.NET应用来讲,HttpApplication派生于Global.asax文件,能够经过此文件,对请求处理行为进行制定。
Global.asax 采用方法名匹配,按照“Application_{事件名}”进行事件注册。
其中事件名内容,就是Application中包含的事件。例如:
protected void Application_BeginRequest(Object sender, EventArgs e) { Application["StartTime"] = System.DateTime.Now; }
其中会有几个是针对整个应用程序而言,而不是针对请求。
请求事件执行顺序以下:
(提供模块初始化和处置事件以实现类)
当请求转入ASP.NET管道时,最终负责处理该请求的是HttpHandler对象。在此以前会先加载HttpModule对象。
ASP.NET提供的不少基础功能都是经过HttpModule实现的。例如
OutputCacheModule:输出缓存功能
SessionStateModule:无状态的HTTP协议上实现基于会话的状态保持
WindowsAuthenticationModule + FormsAuthenticationModule + PassportAuthenticatinonModule:实现了三种典型的身份认证
UrlAuthorizationModule _ FileAuthorizationModule:基于URI和ACL文件的受权
(定义 ASP.NET 以异步方式处理使用自定义 HTTP 处理程序的 HTTP Web 请求而实现的协定)
对不一样资源类型的请求,ASP.NET会加载不一样的Handler来处理,好比aspx与asmx对应的Handler是不一样的。
HttpHandler 能够配置到Web.config中。例子为svc资源的配置。
<system.web> <httpHandlers> <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHander" validate="false" /> </httpHandlers> <compilation debug="true" targetFramework="4.6" /> <httpRuntime targetFramework="4.6" /> <authentication mode="Forms"> <forms loginUrl="~/Account/login.aspx" timeout="2000"></forms> </authentication> </system.web>