返回结果的HTTP状态码
服务器返回的各类状态码
状态码以3位数字和原因短语组成。
数字中的第一位指定了响应类型，后两位无分类。响应类型有以下五种
| 类别 | 原因短语 | |
|---|---|---|
| 1XX | Informational(信息性状态码) | 接收的请求正在处理 |
| 2XX | Success(成功状态码) | 请求正常处理完毕 |
| 3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 |
常见2XX状态码举例
- 200 OK ：表示请求被正常处理
- 204 No Content：请求处理成功，但是没有资源可以返回。
- 206 Partial Content：表示进程了范围请求，响应报文包含由Content-Range指定范围的实体内容。
常见3XX状态码举例：
- 301 Moved Permanently：永久性重定向，表示该请求的资源已经分配了新的URI。如果已经把资源对应的URI保存为书签了，这时候应该按Location首部字段提示的URI重新保存。
- 302 Found：便是请求的资源已经被分配了新的URI，希望用户（本次）能使用新的URI。
- 303 See Other：对应资源存在另一个URI，应使用GET方法定向获取请求的资源。
- 304 Not Modified：服务端允许请求访问资源，但未满足条件。虽然也是3开头，但和重定向没有关系。
- 307 Temporary Redirect：临时重定向，和302有相同的含义。
常见的4XX状态码举例
- 400 Bad Request：表示请求报文中存在语法错误。需要修改请求内容后再次发送。
- 401 Unauthorized：显示发送的请求需要通过认证。如果之前已经认证一次，表示用户认证失败。
- 403 Forbidden：表明对请求的资源的访问被服务端拒绝了。服务端可以在实体的主体部分对原因进行描述，这样就能让用户看到。
- 404 Not Found：便是无法找到请求的资源。也可以用在服务端拒绝请求且不想说理由时候
常见的5XX状态码举例
- 500 Internal Server Error：表示服务端执行请求时候发生了错误。也可能是Web应用存在Bug或某些临时的故障。
- 503 Service Unavailable：表示服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求。可以再首部字段RetryAfter中写入恢复时间。
与HTTP协作的Web服务器
用单台虚拟主机实现多个域名
一台实体服务器，可以建立多个虚拟主机，用来绑定多个域名。
由于虚拟可以寄存多个不同主机名和域名的Web网站，因此在发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI。
代理、网关、隧道
-
代理
是一种有转发功能的应用程序，扮演位于服务器和客户端之间的中间人角色。接收有客户端发送的请求到服务端，同时接收服务端返回的响应到客户端。
- 基本行为：就是转发客户端请求到其他服务器，可以连接多个代理。每次通过代理会最佳写入Via首部信息
- 使用理由：利用缓存技术减少网络带宽，阻止内部针对特定网站的访问控制、获取访问日志。
- 分类
- 缓存代理：代理会缓存之前访问的资源，再次访问时候，就可以不从原服务器获取资源，而直接返回缓存了。
- 透明代理：转发请求时候不对报文进行任何加工的代理称为透明代理。反之称为非透明代理。
-
网关
网关是转发其他服务器通信数据的服务器，接收客户端的请求后，他就像自己拥有资源的服务器一样对请求处理，客户端甚至不会发现
工作机制和代理类似，而网关可以使通信线路上的服务器提供非HTTP协议服务。
利用网关可以提高安全性。比如可以再客户单与网关之间的通信线路上加密以保证连接的安全。
-
隧道
隧道是在相隔甚远的客户端和服务端之间进行中转，并保持双方通信连接的应用程序。
隧道的目的是确保客户单能与服务器进行安全的通信。
隧道本身不会解析HTTP请求。会在通信双方断开连接时结束。
缓存
-
概念：
是指代理服务器或客户端本地保存的资源副本，利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。 -
缓存的有效期
每次请求时候，即使存在缓存，也会和服务端确认缓存是或否有效，如果失效，将再次从服务器获取新的资源并缓存。
HTTPS
-
HTTP的缺点
- 通信使用明文，内容可能会被窃听
- 不验证通信方的身份，因此可能遭遇伪装
- 无法证明报文的完整性，所以有可能以遭篡改
-
HTTPS的特点
- 客户端、服务端都使用证书来证明身份
- 不是一种新的协议，是HTTP通信接口部分用SSL和TLS协议代替而已。
相互交换密钥的公开密钥加密技术
SSL采用一种叫做公开密钥加密的加密处理方式。也就是加密算法是公开的，而密钥确是保密的。通过这种方式来保证加密方法的安全性。-
共享密钥加密的困难：
加密解密都用一个密钥的方法叫做共享密钥加密。
如果使用这种加密，需要在加密时，把密钥发送给对方。但是任何发送方式都可能被监听。所以这个方法执行不下去了。
-
使用两把密钥的公开密钥加密
公开密钥加密使用一对非对称的密钥。一把私钥一把公钥。公钥可以随意发布，私钥需要自己保存。
发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，在使用自己的私钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不用担心被拦截。
而且根据密文和公开的密钥，恢复到信息的原文是异常困难的。
公钥加密后，可以用私钥解密，不能用公钥解密
-
HTTPS采用混合加密机制
- 先使用公钥加密的方式安全的交换在稍后的共享密钥加密中要使用的密钥
- 确保交换的密钥是安全的前提下，使用共享密钥的方式进行通讯
- 公钥、私钥在一块。公钥会发送出去，用来对方加密。对方发来的信息肯定是用我方的公钥加密的，这样才能解开。
-
HTTPS证书的安全性
在使用过程中，我们无法证明服务器的公钥是正确的公钥。为了解决这个问题，各种认证机构就开始产生了。
数字证书认证机构处于客户端和服务端双方都可信赖的第三方机构的立场上。数字证书认证时，会确定对应的机构是否有资质，然后发送对应的证书。
认证完后，客户端拿到服务端的公钥会先向数字认证机构验证，已确认服务器的公开密钥的真实性
确认访问用户身份的认证
-
何为认证
计算机本身无法判断使用者的身份，为了弄清使用者的身份，就需要认证
认证需要核对的信息有：
- 密码：只有本人知道的字符串
- 动态令牌：仅限本人持有设备显示的一次性密码
- 数字证书：仅限本人持有的信息
- 生物认证：职位、虹膜及面部识别等
- IC卡等：仅限本人持有的信息
-
BASIC认证
- 发送请求
- 服务端返回401告知需要认证
- 客户端键有户名密码用冒号连接，Base64编码后发送
- 认证成功返回200，认证失败返回401
缺陷
Base64只是编码，不是加密，在HTTP等非加密通信的线路上进行BASIC认证的过程中，如果被窃听，可能被盗。
-
DIGEST认证
步骤
-
客户端发送请求
-
服务端返回临时的质询码，告知需要认证的状态码401
首部字段内会包含realm和nonce这两个字段的信息。客户端就是依靠向服务器返回这两个值进行认证的。
nonce是一种每次岁返回的401响应生成的任意随机字符串。该字符串通常由Base64编码的十六进制树组成。
-
客户端发送摘要以及有质询码计算出的响应码
在响应吗中，会包含服务端接收的字段realm和nonce。然后再加入username字段表示用户名，response用来存放MD5加密后的密码。这些字段会放入请求的首部字段Authorization中。
-
服务端认证成功返回200失败再次发送状态码401
服务器收到还有字段Authorization的请求后，会确认认证的准确性，然后返回对应的结果。
缺陷
和HTTPS的客户端认证相比仍旧较弱。虽然提供了放置密码被窃听的保护机制，但是并不能防止用户伪装的保护机制。
-
-
SSL客户端认证
介绍
SSL客户端认证是借由HTTPS的客户单证书完成的认证方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。
SSL客户端认证的认证步骤
- 接受需要认真的请求时候，服务按会发送CertificateRequest报文，要求客户端提供证书。
- 用户端选择证书，把证书信息用ClientCertificate报文方式发送给服务端
- 服务端验证证书通过后，领取客户端的公钥，然后开始HTTPS加密通信。
SSL双因素认证
也就是除了需要用证书来确定当前客户端的合法性外，还需要账号密码来确认是用户本人在使用当前电脑。
-
基于表单的认证
介绍
基于表单的认证方法并不是在HTTP协议中定义的。客户端回想服务器上的Web应用程序发送登录信息(Credential)，按登录信息的验证结果认证。
认证多半基于表单认证
由于使用便利性不太好，所以BASIC和DIGEST认证几乎不怎么使用，SSL客户端认证虽然具有高度安全性，但因为导入及费用等问题，还未普及。
Session管理及Cookie应用
表单认证时候一般会使用Cookie来管理Session(会话)。
具体步骤如下：
- 客户端把ID和密码放入报文实体部分，一般通过POST方法把请求发送给服务器。
- 服务端根据用户名密码发放用于识别用户的SessionID。SessionID回放在首部字段Set-Cookie中。为了安全不被盗用，SessionID应该是难以推测的字符串，而且服务器要对其有效期进行管理，保证其安全性。
- 客户端收到服务端的SessionID后，会将其保存在本地Cookie，下次请求时候，会自动发送Cookie，SessionID也会随之发送。
基于HTTP的功能追加协议
HTTP建立之初，只是为了传输HTML文档，完全没有想到现在发展的这么五花八门啥都想传。所以HTTP有了很多限制，但是由于HPPT的使用范围太广了，所以一些新的协议只能基于HTTP来修改，这样诞生了很多基于HTTP的协议。
-
SPDY协议
HTTP的瓶颈
在Facebook和微博等SNS网站上，用户短时间发的信息是千万级别的，web网站为了显示这些信息，需要不断把服务器的最新内容反馈到客户端，这个用HTTP十分难以实现。
解决方法
-
Ajax解决方法
利用JavaScript和DOM的操作，达到局部Web页面替换加载的异步通讯手段。和以前的同步通讯相比，由于只是更新了一部分页面，响应中传输的数据量会因此而减少。不过Ajax未解决HTTP协议本身的限制。
-
Comet解决方法
是一种延迟应答，模拟实现服务器向客户端推送的功能。一但服务端有内容更新了，Comet不会让请求等待，而是直接给客户端返回。
这种方式虽然内容上做到了实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维护连接会消耗更多的资源，当然也没有解决HTTP协议本身的问题。
-
引出了SPDY
为了根本性的解决这一问题，需要有一些协议层面上的改动，处于持续开发状态的SPDY协议，正是为了在协议级别消除HTTP所遇到的瓶颈
-
-
SPDY的设计与功能
介绍
在TCP/IP的应用层与传输层之间通过新加会话层的形式运作。同时为了安全考虑，SPDY规定通信中使用SSL
实用功能
使用SPDY后，HTTP协议额外获得以下功能：
-
多路复用流
通过单一的TCP连接，可以无限制处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。
-
赋予请求优先级
给请求逐个分配优先级顺序，为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
-
压缩HTTP首部
-
推送功能
可以支持服务器主动向客户端推送数据。这样服务器就可直接发送数据，而不必等待客户端的请求。
-
服务器提示功能
服务器可以主动提示客户端请求所需的资源。由于在客户端实现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。
综上可以得出结论，SPDY的确是一种可有效消除HTTP瓶颈的技术，但很多Web网站的问题并非仅仅由HTTP瓶颈导致。对Web本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善Web内容的编写方式等。
-