读《图解HTTP》记录
1、确认访问用户身份的认证
某些Web页面只想让特定的人浏览，必不可少的就是认证功能。
1.1、何为认证
计算机本身无法判断客户端的身份，为了弄清楚是谁在访问服务器，就得要让客户端自报家门。可是，就算是对方声称自己是a,身份是否属实这点也无从谈起。位了确认a本人是否真的具有访问权限，就需要核对“登陆者本人才知道的信息”、“登陆者本人才会有的信息”。核对信息通常指一下：
- 密码：只有本人才会知道的字符串信息。
- 动态令牌：仅限本人持有的设备内显示的一次性密码。
- 数字证书：仅限本人(终端)持有的信息。
- 生物认证：指纹和虹膜等本人的生理信息。
-
IC卡等：仅限本人持有的信息。
但是，即便对方是假冒用户，只要能通过用户验证，那么计算机就会默认是出自本人的行为。因此 ，掌握机密信息的密码绝对不能让他人得到，根不能轻易被破解出来。
HTTP使用的认证方式
HTTP/1.1使用的认证方式如下
- BASIC认证(基本认证)
- DIGEST认证(摘要认证)
- SSL客户端认证
- FormBase认证(基于表单认证)
此外还有Windows统一认证(Keberos认证、NTLM认证)
1.2、BASIC认证
BASIC认证是从HTTP/1.0就定义的认证方式。即便是现在仍有一部分网站会使用这种认证方式。是Web服务器与通信客户端之间进行的认证方式。
BASIC认证的步骤
- 1、当请求的资源需要BASIC认证时，服务器会伴随状态码401 Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含认证的方式(BASIC)以及Request-URI安全域字符串(realm)。
- 2、客户端接收到状态码401后需要将用户ID、密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者之间以（:）连接，再经过Base64编码后，写入首部字段Authorization中，然后发送请求。
- 3、接收到包含Authorization首部字段的请求后，服务器会对认证信息的正确性校验。如果通过，则返回一条包含Request-URI资源的响应。
BASIC认证采用的虽然是Base64编码，方这不是加密处理。不需要任何附带信息就能解码。在HTTP等非加密通信的线路上如果被 窃听，被盗的可能性极高。
另外，如果想再进行一次BASIC认证，一般的浏览器却无法实现认证注销操作，这也是问题。
BASIC认证使用上不够便捷灵活，且达不到多数Web网站期望的安全性等级，因此它并不常用。
1.3 DIGEST认证
为弥补BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST认证同样使用质询/响应的方式，但是不会像BASIC认证那样直接发送明文密码。
所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将向响应码返回给对方进行认证的方式。
因为发送给对方的只是响应摘要及由质询码产生的计算结果，所以比起BASIC认证，密码泄露的可能性就降低了。
DIGEST认证的认证步骤
- 1、请求需要认证的资源时，服务器会随着状态码401 Authorization Required,返回带WWW-Authenticate首部字段的响应。该字段内包含质问相应方式认证所需要的临时质询码(随机数，nonce).首部字段WWW-Authenticate内必须包含realm和nince这两个字段的信息。客户端就是依靠向服务器发送者两个值进行认证的。
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运算后的密码字符串，形成响应码。
- 3、接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。
并且这时会在首部字段Authentication-Info写入一些认证成功的相关信息。
DIGEST认证提供了高于BASIC认证的安全等级，但是和HTTPS的客户端认证相比仍旧很弱。DIGEST认证提供防止密码被窃听的保护机制，但并不存在防止用户伪装的保护机制。
DIGEST认证和BASIC认证一样，使用上不那么灵活便捷，且仍达不到多数Web网站对高度安全等级的最求标准。因此它的适用范围也有所受限。
1.4 SSL客户端认证
从使用用户ID和密码的认证方面来讲，只要二者的内容正确，就可以认证是本人的行为。但是如果用户ID和密码被盗，就很有可能被第三者冒充。利用SSL客户端认证则可以避免该情况的发生。
SSL客户端认证是由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可以确认访问是否来自已登录的客户端。
1.4.1 SSL客户端认证的步骤
为了达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
- 1、接收到需要认证资源的请求，服务器会发送Certificate Request 报文，要求客户端提供客户端证书。
- 2、用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certificate报文方式发送给服务器。
- 3、服务器检查客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
1.4.2 SSL客户端认证采用双因素认证
在多数情况下，SSL客户端认证不仅依靠证书完成认证，一般会和基于表单认证组成形成一种双因素认证来使用。所谓双因素认证就是指，认证过程中不仅需要密码这一因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式。
就是说，第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。
通过双因素认证之后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
1.4.3 SSL客户端认证必要的费用
使用SSL客户端认证需要用到客户端证书。而客户端证书需要支付一定费用才能使用。
这里的费用是，从认证机构购买客户端证书的费用，以及服务器运营者为保证自己搭建的认证机构安全运营所产生的费用。
1.5 基于表单认证
基于保单的认真方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息,按登录信息的验证结果认证。
多数情况下，客户端把事前登录好的用户ID和密码等登录信息发送给Web程序，基于认证结果来决定认证是否成功。
1.5.1、认证多为基于表单认证
由于使用上的便利性以及安全性问题，HTTP协议标准提供的BASIC认证和DIGEST认证几乎不怎么使用。另外，SSL客户端认证虽然安全，但有成本，现在还未普及。
比如SSH和FTP协议，服务器和客户端之间的认证是合乎标准规范的，并且满足了最基本的功能需求上的安全级别，因此这些协议的认证可以拿来直接使用。但对于Web网站的认证功能，能够满足其安全使用级别的标准规范并不存在，所以只好使用由Web应用程序各自实现基于表单的认证方式。
不具备共同标准规范的表单认证，在每个Web网站上都会有各自不同的实现方式。如果是全面考虑过安全性能而事先的表单认证，那么就能具备高度的安全等级。但在表单认证的实现中存在问题的Web网站也很多见。
1.5.2、Session管理和Cookie应用
基于表单认证的标准规范尚未有定论，一般会使用Cookie来管理Session。
基于表单认真本身是通过服务器端的Web应用，将客户端发送过来的用户ID和密码与之前登录过的信息做匹配来进行认证的。
但鉴于HTTP是无状态协议，之前已认证成功的用户状态无法通过协议层保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他用户。于是我们用Cookie来管理Session,以弥补HTTP协议中病不存在的状态管理功能。
- 1、客户端把用户ID和密码等登陆信息放入报文的实体部分，通常以POST方式把请求发送给服务器。这时，会使用HTTPS通信来进行HTML表单页面的显示和用户输入数据的发送。
- 2、服务器会发放用于识别用户的Se's'si'o'nID.通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与SessionID绑定后记录在服务器端。
向客户端返回响应时，会在首部字段Set-Cookie内写入SessionID.
但是如果SessionID被第三方盗走，对方就可以伪装成你的身份进行恶意操作。因此必须方式Se's'si'o'nID被盗，或被猜出。位了左到这点，SessionID应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。
另外，为了跨站脚本攻击造成的损失，建议事先在Cookie内加上httponly属性。 - 3、客户端接收到从服务器发送来的SessionID后，会将其作为Cookie保存在本地。下次再向服务器发送请求时，浏览器会自动发送Cookie，所以SessionID也随之发送到服务器。服务器端也通过验证接收到SessionID识别用户和其认证状态。
除了以上介绍的应用实例，还有应用其他不同方案的案例。
另外，不仅基于表单认证的登录信息以及认证过程都无标准化的方法，服务器端因如何让保存用户提交的密码信息等登录信息也没办法标准化。
通常，一种安全的保存方法是，先利用给密码加盐(salt)的方式增加额外信息，再使用散列函数计算出散列值后保存。但是我们也经常看到直接保存明文密码的做法，而这样的做法具有导致密码泄露的风险。
加盐(salt)其实是由服务器随机生成一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串连接(前后都可以)生成散列值。当两个用户使用同一个密码时，由于随机生成的salt不同,对应的散列值也是不同的。这样一来，很大程度上减少了名密码特征，攻击者也就很难利用自己手中的密码特征进行破解。
2、基于HTTP的功能追加协议
虽然HTTP协议既简单又简捷，但随着时代的发展，其功能使用上已经不满足现阶段了。下面就要讲基于HTTP新增加的功能的协议。
2.1、基于HTTP的协议
在建立HTTP标准规范时，制定者主要是想把HTTP当作传输HTML文档的协议。随着时代的发展，Web的用途根据多样性，比如演化成在线购物网站、社交网络服务、企业内部的管理工具等等。
而这些网站所追求的功能可通过Web应用和脚本程序实现。即使这些功能已经满足需求，在性能上却未必最优，这是因为HTTP协议上的限制以及自身性能有限。
HTTP功能的不足可通过创建一套全新的协议来弥补。可是目前基于HTTP的Web浏览器的使用环境已遍布全球，因此无法完全抛弃HTTP。有一些行协议的规则也是基于HTTP的，并在此基础上添加了新的功能。
2.2 消除HTTP瓶颈的SPDY
Google在2010年发布了SPDY,其开发目标是为了解决HTTP的性能平静，缩短Web页面加载时间(50%)。
2.2.1 HTTP瓶颈
在Facebook和Teitter等社交网站上，几乎能够实时观察到海量用户公开发布的内容，这也是一种乐趣。当几百、几千万的用户发布内容时，Web网站位了保存这些新增的内容，在短时间内就会发生大量内容更新。
为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的页面上，虽然看起来挺简单，但HTTP却无法妥善的处理好这项任务。
使用HTTP协议探知服务器上是否有内容更新，就必须频繁从客户端到服务器进行确认。如果服务器上没有内容更新，那么就会产生很多徒劳的通信。
若想在所有Web实现所需的功能，以下这些HTTP标准就会成为瓶颈。
- 一条连接上只可发送一个请求
- 请求只能从客户端开始，客户端不可以接收除响应之外的指令。
- 请求/响应首部未经压缩就发送。首部信息越多延迟越大。
- 发送冗余的首部。每次互相发送相同的首部造成的浪费较多。
-
可任意选择数据压缩格式。非强制压缩发送。
以前的HTTP通信
Ajax的解决方法
Ajax(Asynchronous JavaScript and XML,异步JavaScript与XML技术)是一种有效利用JavaScript的DOM(Document Object Model，文档对象模型)的操作，以达到局部Web页面替换加载的而异步通信手段。和之前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少，这一优点是显而易见的。
Ajax的核心技术是名为XMLHttpRequest的API，通过JavaScript脚本语岩的调用就能和服务器进行HTTP通信。借由这种手段，就能从已加载完毕的Web页面发起请求，只更新局部页面。
而利用Ajax实时得从服务器获取内容，有可能会导致大量请求产生。另外Ajax仍未解决HTTP协议本身存在的问题。
Comet的解决方法
一旦服务器端有内容更新了，Comet不会让请求等待，而是直接给客户端响应。这是一种通过延迟应答，模拟实现服务器端先客户端图送(Server Push)的功能。
通常，服务器收到请求，会在处理完毕之后就立即返回响应，单位了实现推送功能，Comet会先将响应置于挂起状态，但服务器端有内容更新时，再返回该响应。因此，服务器一旦有更新，就可以立即反馈给客户端。
内容上虽然可以左到实时更新，但位了保留相应，一次连接的持续时间也边长了。期间为了维持连接会消耗更多的资源。另外，Comet也仍未解决HTTP协议本身存在的问题。
SPDY的目标
陆续出现的Ajax和Comet等提高易用性的技术，一定程度上使HTTP得到了改善，当HTTP协议本身的限制也令人无奈。为了进行根本性的改善，需要有一些协议层面上的改动。
处于持续开发状态中的SPDY协议，真是为了在协议级别消除HTTP所遭遇的瓶颈。
2.2.2 SPDY的设计与功能
SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层和运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY规定通信使用SSL。
SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接。因此，可以照常使用HTTP的GET/POST等方法以及Cookie和HTTP报文等。
使用SPDY后，HTTP协议额外获得了一下功能。
- 多路复用流
通过单一的TCP连接，可以无限制处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。 - 赋予请求优先级
SPDY不仅可以无限制地并发处理请求，还可以给请求诸葛分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致相应变慢的问题。 - 压缩HTTP首部
压缩HTTP请求和响应的首部，这样一来，通信产生的数据包数量和发送的字节数就变少了。 - 推送功能
支持服务器向客户端同送数据的功能，这样服务器可以直接发哦是那个数据给客户端，不必客户端轮询。 - 服务器提示功能
服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存的情况下，可以避免发送不必要的请求。
2.2.3 SPDY消除Web瓶颈了吗？
希望使用SPDY时，Web的内容端不必做什么特别改动，而Web浏览器及Web服务器都要为对应SPDY做出一定程度上的改动。有好几家Web浏览器已经针对SPDY做出了相应的调整。另外，Web服务器也进行了实验性质的应用，但把该技术导入实际的Web网站却进展不佳。
因为SPDY基本上只是讲单个域名(IP地址)的通信多路复用，所以当一个Web网站上使用多个域名下的资源，改善效果就会受到限制。
SPDY的确是一种可有效消除HTTP瓶颈的技术，但很多Web网站存在的问题并非仅仅是由HTTP瓶颈所导致。对Web本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善Web内容夫人编写方式等。
2.3 使用浏览器进行双工通信的WebSocket
一旦Web服务器与客户端之间建立起WebSocket协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML或图片等任意格式的数据。
由于是建立在HTTP基础上的协议，因此连接的发起方仍然是客户端，而一旦确立WebSocket通信连接，不论服务器还是客户端，任意以放都可直接向对方发送报文。
一下是WebSocket协议的主要特点：
- 推送功能
支持由服务器向客户端推送数据的推送功能。 - 减少通信量
只要建立起WebSocket连接，就希望一直保持连接状态。和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也响应减少了。
为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次"握手"(Handshaking)的步骤。
- 请求握手
位了实现WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的。
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Sec-WebSocket-Key字段内记录着握手过程中必不可少的键值。
Sec-WebSocket-Protocol字段内记录使用的子协议。
子协议按WebSocket协议标准在连接分开使用时，定义那些连接的名称。
- 响应握手
对于之前的请求，返回状态码101 Switching Protocols的响应。
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: cha
Sec-WebSocket-Accept的字段值是由握手请求中的Sec-WebSocket-Key的字段值生成的。
成功握手确立WebSocket连接之后，通信时不再使用HTTP的数据帧，而采用WebSocket独立的数据帧。
- WebSocket API
JavaScript 可调用”The WebSocket API“（http://www.w3.org/TR/websockets/,由W3C标准制定）内提供的WebSocket程序接口，以实现WebSocket协议下全双工通信。
以下为调用WebSocket API，每50ms发送一次数据的实例。
var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
setInterval(function() {
if (socket.bufferedAmount == 0)
socket.send(getUpdateData());
}, 50);
};
