确认访问用户身份的认证与基于HTTP的协议
何为认证
计算机本身无法判断坐在显示器前的使用者的身份。进一步说，也无法确认网络的那头究竟有谁。可见，为了弄清究竟是谁在访问服务器，就得让对方的客户端自报家门。
可是，就算正在访问服务器的对方声称自己是ueno，身份是否属实这点却也无从谈起。为确认ueno本人是否真的具有访问系统的权限，就需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”。
核对的信息通常是指以下这些。
●密码：只有本人才会知道的字符串信息。
●动态令牌：仅限本人持有的设备内显示的一次性密码。
●数字证书：仅限本人（终端）持有的信息。
●生物认证：指纹和虹膜等本人的生理信息。
●IC卡等：仅限本人持有的信息。
但是，即便对方是假冒的用户，只要能通过用户验证，那么计算机就会默认是出自本人的行为。因此，掌控机密信息的密码绝不能让他人得到，更不能轻易地就被破解出来。
HTTP使用的认证方式
●BASIC认证（基本认证）
●DIGEST认证（摘要认证）
●SSL客户端认证
●FormBase认证（基于表单认证）
此外，还有Windows统一认证（Keberos认证、NTLM认证），
BASIC认证
BASIC认证（基本认证）是从HTTP/1.0就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。是Web服务器与通信客户端之间进行的认证方式。
BASIC认证的认证步骤
步骤1： 当请求的资源需要BASIC认证时，服务器会随状态码401 AuthorizationRequired，返回带WWW-Authenticate首部字段的响应。该字段内包含认证的方式（BASIC）及Request-URI安全域字符串（realm）。
步骤2： 接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号（:）连接后，再经过Base64编码处理。假设用户ID为guest，密码是guest，连接起来就会形成guest:guest这样的字符串。然后经过Base64编码，最后的结果即是Z3Vlc3Q6Z3Vlc3Q=。把这串字符串写入首部字段Authorization后，发送请求。当用户代理为浏览器时，用户仅需输入用户ID和密码即可，之后，浏览器会自动完成到Base64编码的转换工作。
步骤3： 接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应。
BASIC认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。换言之，由于明文解码后就是用户ID和密码，在HTTP等非加密通信的线路上进行BASIC认证的过程中，如果被人窃听，被盗的可能性极高。另外，除此之外想再进行一次BASIC认证时，一般的浏览器却无法实现认证注销操作，这也是问题之一。BASIC认证使用上不够便捷灵活，且达不到多数Web网站期望的安全性等级，因此它并不常用。
DIGEST认证
为弥补BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST认证同样使用质询/响应的方式（challenge/response），但不会像BASIC认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。
因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性就降低了。
DIGEST认证的认证步骤
步骤1： 请求需认证的资源时，服务器会随着状态码401 Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。首部字段WWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。nonce是一种每次随返回的401响应生成的任意随机字符串。该字符串通常推荐由Base64编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。
步骤2： 接收到401状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段Authorization信息。首部字段Authorization内必须包含username、realm、nonce、uri和response的字段信息。其中，realm和nonce就是之前从服务器接收到的响应中的字段。username是realm限定范围内可进行认证的用户名。uri（digest-uri）即Request-URI的值，但考虑到经代理转发后Request-URI的值可能被修改，因此事先会复制一份副本保存在uri内。response也可叫做Request-Digest，存放经过MD5运算后的密码字符串，形成响应码。响应中其他的实体请参见第6章的请求首部字段Authorization。
步骤3： 接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。并且这时会在首部字段Authentication-Info写入一些认证成功的相关信息。DIGEST认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。DIGEST认证和BASIC认证一样，使用上不那么便捷灵活，且仍达不到多数Web网站对高度安全等级的追求标准。因此它的适用范围也有所受限。
SSL客户端认证
从使用用户ID和密码的认证方式方面来讲，只要二者的内容正确，即可认证是本人的行为。但如果用户ID和密码被盗，就很有可能被第三者冒充。利用SSL客户端认证则可以避免该情况的发生。
SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。
SSL客户端认证的认证步骤
为达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
步骤1： 接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
步骤2： 用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certificate报文方式发送给服务器。
步骤3： 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
SSL客户端认证采用双因素认证
在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证（稍后讲解）组合形成一种双因素认证（Two-factorauthentication）来使用。
所谓双因素认证就是指，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式。
换言之，第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
基于表单认证
基于表单的认证方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息（Credential），按登录信息的验证结果认证。
根据Web应用程序的实际安装，提供的用户界面及认证方式也各不相同。
多数情况下，输入已事先登录的用户ID（通常是任意字符串或邮件地址）和密码等登录信息后，发送给Web应用程序，基于认证结果来决定认证是否成功。
认证多半为基于表单认证
由于使用上的便利性及安全性问题，HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。
另外，SSL客户端认证虽然具有高度的安全等级，但因为导入及维持费用等问题，还尚未普及。比如SSH和FTP协议，服务器与客户端之间的认证是合乎标准规范的，并且满足了最基本的功能需求上的安全使用级别，因此这些协议的认证可以拿来直接使用。但是对于Web网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由Web应用程序各自实现基于表单的认证方式。不具备共同标准规范的表单认证，在每个Web网站上都会有各不相同的实现方式。
Session管理和Cookie应用
基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session（会话）。基于表单认证本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。
但鉴于HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用Cookie来管理Session，以弥补HTTP协议中不存在的状态管理功能。
步骤1： 客户端把用户ID和密码等登录信息放入报文的实体部分，通常是以POST方法把请求发送给服务器。而这时，会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送。
步骤2： 服务器会发放用以识别用户的Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与Session ID绑定后记录在服务器端。向客户端返回响应时，会在首部字段Set-Cookie内写入Session ID（如PHPSESSID=028a8c…）。你可以把Session ID想象成一种用以区分不同用户的等位号。然而，如果SessionID被第三方盗走，对方就可以伪装成你的身份进行恶意操作了。因此必须防止Session ID被盗，或被猜出。为了做到这点，Session ID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在Cookie内加上httponly属性。
步骤3： 客户端接收到从服务器端发来的Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也随之发送到服务器。服务器端可通过验证接收到的Session ID识别用户和其认证状态。
另外，不仅基于表单认证的登录信息及认证过程都无标准化的方法，服务器端应如何保存用户提交的密码等登录信息等也没有标准化。通常，一种安全的保存方法是，先利用给密码加盐（salt）的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。但是我们也经常看到直接保存明文密码的做法，而这样的做法具有导致密码泄露的风险。
基于HTTP的协议
在建立HTTP标准规范时，制订者主要想把HTTP当作传输HTML文档的协议。随着时代的发展，Web的用途更具多样性，比如演化成在线购物网站、SNS（Social Networking Service，社交网络服务）、企业或组织内部的各种管理工具，等等。而这些网站所追求的功能可通过Web应用和脚本程序实现。即使这些功能已经满足需求，在性能上却未必最优，这是因为HTTP协议上的限制以及自身性能有限。HTTP功能上的不足可通过创建一套全新的协议来弥补。可是目前基于HTTP的Web浏览器的使用环境已遍布全球，因此无法完全抛弃HTTP。有一些新协议的规则是基于HTTP的，并在此基础上添加了新的功能。
消除HTTP瓶颈的SPDY
HTTP的瓶颈
在Facebook和Twitter等SNS网站上，几乎能够实时观察到海量用户公开发布的内容，这也是一种乐趣。当几百、几千万的用户发布内容时，Web网站为了保存这些新增内容，在很短的时间内就会发生大量的内容更新。为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的，但HTTP却无法妥善地处理好这项任务。使用HTTP协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信。若想在现有Web实现所需的功能，以下这些HTTP标准就会成为瓶颈。
●一条连接上只可发送一个请求。
●请求只能从客户端开始。客户端不可以接收除响应以外的指令。
●请求/响应首部未经压缩就发送。首部信息越多延迟越大。
●发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
●可任意选择数据压缩格式。非强制压缩发送。
Ajax的解决方法
Ajax（Asynchronous JavaScript and XML，异步JavaScript与XML技术）是一种有效利用JavaScript和DOM（Document ObjectModel，文档对象模型）的操作，以达到局部Web页面替换加载的异步通信手段。
和以前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少，这一优点显而易见。Ajax的核心技术是名为XMLHttpRequest的API，通过JavaScript脚本语言的调用就能和服务器进行HTTP通信。借由这种手段，就能从已加载完毕的Web页面上发起请求，只更新局部页面。
而利用Ajax实时地从服务器获取内容，有可能会导致大量请求产生。另外，Ajax仍未解决HTTP协议本身存在的问题。
Comet的解决方法
一旦服务器端有内容更新了，Comet不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。通常，服务器端接收到请求，在处理完毕后就会立即返回响应，但为了实现推送功能，Comet会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。
因此，服务器端一旦有更新，就可以立即反馈给客户端。内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。
期间，为了维持连接会消耗更多的资源。另外，Comet也仍未解决HTTP协议本身存在的问题。
SPDY的目标
陆续出现的Ajax和Comet等提高易用性的技术，一定程度上使HTTP得到了改善，但HTTP协议本身的限制也令人有些束手无策。为了进行根本性的改善，需要有一些协议层面上的改动。
处于持续开发状态中的SPDY协议，正是为了在协议级别消除HTTP所遭遇的瓶颈。
SPDY的设计与功能
SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与传输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY规定通信中使用SSL。
SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接。因此，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP报文等。
使用SPDY后，HTTP协议额外获得以下功能：
- 多路复用流：通过单一的TCP连接，可以无限制处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。
- 赋予请求优先级：SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
- 压缩HTTP首部：压缩HTTP请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
- 推送功能：支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
SPDY消除Web瓶颈了吗
希望使用SPDY时，Web的内容端不必做什么特别改动，而Web浏览器及Web服务器都要为对应SPDY做出一定程度上的改动。有好几家Web浏览器已经针对SPDY做出了相应的调整。另外，Web服务器也进行了实验性质的应用，但把该技术导入实际的Web网站却进展不佳。
因为SPDY基本上只是将单个域名（IP地址）的通信多路复用，所以当一个Web网站上使用多个域名下的资源，改善效果就会受到限制。
SPDY的确是一种可有效消除HTTP瓶颈的技术，但很多Web网站存在的问题并非仅仅是由HTTP瓶颈所导致。对Web本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善Web内容的编写方式等。
使用浏览器进行全双工通信的WebSocket
利用Ajax和Comet技术进行通信可以提升Web的浏览速度。但问题在于通信若使用HTTP协议，就无法彻底解决瓶颈问题。WebSocket网络技术正是为解决这些问题而实现的一套新协议及API。
当时筹划将WebSocket作为HTML5标准的一部分，而现在它却逐渐变成了独立的协议标准。WebSocket通信协议在2011年12月11日，被RFC6455- The WebSocket Protocol定为标准。
WebSocket的设计与功能
WebSocket，即Web浏览器与Web服务器之间全双工通信标准。其中，WebSocket协议由IETF定为标准，WebSocket API由W3C定为标准。仍在开发中的WebSocket技术主要是为了解决Ajax和Comet里XMLHttpRequest附带的缺陷所引起的问题。
WebSocket协议
一旦Web服务器与客户端之间建立起WebSocket协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML或图片等任意格式的数据。
由于是建立在HTTP基础上的协议，因此连接的发起方仍是客户端，而一旦确立WebSocket通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。下面我们列举一下WebSocket协议的主要特点。
- 推送功能：支持由服务器向客户端推送数据的推送功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
- 减少通信量：只要建立起WebSocket连接，就希望一直保持连接状态。和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也相应减少了。
为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次“握手”（Handshaking）的步骤。
握手·请求
为了实现WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的。
Sec-WebSocket-Key字段内记录着握手过程中必不可少的键值。Sec-WebSocket-Protocol字段内记录使用的子协议。子协议按WebSocket协议标准在连接分开使用时，定义那些连接的名称。
握手·响应
对于之前的请求，返回状态码101 SwitchingProtocols的响应。
Sec-WebSocket-Accept的字段值是由握手请求中的Sec-WebSocket-Key的字段值生成的。成功握手确立WebSocket连接之后，通信时不再使用HTTP的数据帧，而采用WebSocket独立的数据帧。
WebSocket API
JavaScript可调用“The WebSocket API”（http://www.w3.org/TR/websockets/，由W3C标准制定）内提供的WebSocket程序接口，以实现WebSocket协议下全双工通信。
HTTP/2.0
HTTP/2.0的特点HTTP/2.0的目标是改善用户在使用Web时的速度体验。由于基本上都会先通过HTTP/1.1与TCP连接，现在我们以下面的这些协议为基础，探讨一下它们的实现方法。●SPDY
●HTTP Speed+Mobility
●Network-Friendly HTTP UpgradeHTTP Speed+Mobility
Web服务器管理文件的WebDAV
WebDAV（Web-based Distributed Authoringand Versioning，基于万维网的分布式创作和版本控制）是一个可对Web服务器上的内容直接进行文件复制、编辑等操作的分布式文件系统。它作为扩展HTTP/1.1的协议定义在RFC4918。
除了创建、删除文件等基本功能，它还具备文件创建者管理、文件编辑过程中禁止其他用户内容覆盖的加锁功能，以及对文件内容修改的版本控制功能。
扩展HTTP/1.1的WebDAV
集合（Co lection）：是一种统一管理多个资源的概念。以集合为单位可进行各种操作。也可实现类似集合的集合这样的叠加。
资源（Resource）：把文件或集合称为资源。
属性（Property）：定义资源的属性。定义以“名称=值”的格式执行。
锁（Lock）：把文件设置成无法编辑状态。多人同时编辑时，可防止在同一时间进行内容写入。
WebDAV内新增的方法及状态码
WebDAV为实现远程文件管理，向HTTP/1.1中追加了以下这些方法。
PROPFIND：获取属性
PROPPATCH：修改属性
MKCOL：创建集合
COPY：复制资源及属性
MOVE：移动资源
LOCK：资源加锁
UNLOCK：资源解锁
为配合扩展的方法，状态码也随之扩展。
102 Processing：可正常处理请求，但目前是处理中状态
207 Multi-Status：存在多种状态
422 Unprocessible Entity：格式正确，内容有误
423 Locked：资源已被加锁
424 Failed Dependency：处理与某请求关联的请求失败，因此不再维持依赖关系
507 Insufficient Storage：保存空间不足