图解HTTP

HTTP 是一种不保存状态，即无状态 （stateless ）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。

但为了实现期望的保持状态功能，于 是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。

HTTP 协议使用 URI 定位互联网上的资源。

当客户端请求访问资源而发送请求时，URI  需要将作为请求报文中的 请求 URI 包含在内。

如果不是访问特定资源而是对服务器本身发起请求，可以 用一个 * 来代替请求 URI。

eg: OPTIONS  * HTTP/1.1

GET 方法用来请求访问已被 URI 识别的资源。
如果请求的资源是文本， 那就保持原样返回；

如果是像 CGI（Common Gateway Interface， 通用网关接口） 那样的程序， 则返回经过执行后的输出结果。POST 方法用来传

POST 方法用来传输实体的主体。
虽然用 GET 方法也可以传输实体的主体， 但一般不用 GET 方法进行传输， 而是用 POST 方法。
POST 的主要目的并不是获取响应的主体内容。

PUT 方法用来传输文件。 就像 FTP 协议的文件上传一样， 要求在请求报文的主体中包含文件内容， 然后保存到请求 URI 指定的位置。

鉴于HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件,存在安全性问题，因此一般的 Web 网站不使用该方法。

HEAD 方法和 GET 方法一样， 只是不返回报文主体部分。 用于确认URI 的有效性及资源更新的日期时间等。

DELETE 方法用来删除文件， 是与 PUT 相反的方法。 DELETE 方法按请求 URI 删除指定的资源。
HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制， 所以一般的 Web 网站也不使用 DELETE 方法。 当配合 Web 应用程序的验证机制， 或遵守 REST 标准时还是有可能会开放使用的。

OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。

TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。
客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改
/ 篡改的。 这是因为， 请求想要连接到源目标服务器可能会通过代理
中转， TRACE 方法就是用来确认连接过程中发生的一系列操作。
不怎么常用， 再加上它容易引发XST（Cross-Site Tracing， 跨站追踪） 攻击。

CONNECT 方法要求在与代理服务器通信时建立隧道， 实现用隧道协
议进行 TCP 通信。 主要使用 SSL（Secure Sockets Layer， 安全套接
层） 和 TLS（Transport Layer Security， 传输层安全） 协议把通信内容
加 密后经网络隧道传输
CONNECT 方法的格式如下所示：
CONNECT 代理服务器名:端口号 HTTP版本

问题：HTTP 协议的初始版本中， 每进行一次 HTTP 通信就要断开一次 TCP连接。
解决：持久连接的特点是， 只要任意一端没有明确提出断开连接， 则保持 TCP 连接状态。
持久连接旨在建立 1 次 TCP 连接后进行多次请求和响应的交互。

管线化
持久连接使得多数请求以管线化（pipelining） 方式发送成为可能。 从
前发送请求后需等待并收到响应， 才能发送下一个请求。 管线化技术
出现后， 不用等待响应亦可直接发送下一个请求。

使用 Cookie 的状态管理
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息， 通知客户端保存 Cookie。 当下次客户端再往该服务器发送请求时， 客户端会自动在请求报文中加入 Cookie 值后发送出去。
服务器端发现客户端发送过来的 Cookie 后， 会去检查究竟是从哪一个客户端发来的连接请求， 然后对比服务器上的记录， 最后得到之前的状态信息。

HTTP请求报文和响应报文的格式

请求行

包含用于请求的方法， 请求 URI 和 HTTP 版本。

状态行
包含表明响应结果的状态码， 原因短语和 HTTP 版本。
首部字段
包含表示请求和响应的各种条件和属性的各类首部。
一般有 4 种首部， 分别是： 通用首部、 请求首部、 响应首部和实体首部。
其他
可能包含 HTTP 的 RFC 里未定义的首部（Cookie 等） 。

报文主体和实体主体的差异

报文

是 HTTP 通信中的基本单位， 由 8 位组字节流（octet sequence，其中 octet 为 8 个比特） 组成， 通过 HTTP 通信传输。
实体
作为请求或响应的有效载荷数据（补充项） 被传输， 其内容由实体首部和实体主体组成。
HTTP 报文的主体用于传输请求或响应的实体主体。
通常， 报文主体等于实体主体。 只有当传输中进行编码操作时， 实体主体的内容发生变化， 才导致它和报文主体产生差异。

URI和URL的区别

URI 用字符串标识某一互联网资源， 而 URL 表示资源的地点（互联网上所处的位置） 。 可见 URL 是 URI 的子集。

URI  统一资源标识符，用来唯一的标识一个资源。

• Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
• URI一般由三部组成：
• ①访问资源的命名机制
• ②存放资源的主机名
• ③资源自身的名称，由路径表示，着重强调于资源。

URL 统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

• URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
• 采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
• ①协议(或称为服务方式)
• ②存有该资源的主机IP地址(有时也包括端口号)
• ③主机资源的具体地址。如目录和文件名等

URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:java-net@java.sun.com。

• URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

Java中的URI

一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。

在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。

相反的是，URL类可以打开一个到达资源的流.

内容协商

内容协商机制是指客户端和服务器端就响应的资源内容进行交涉， 然后提供给客户端最为适合的资源。 内容协商会以响应资源的语言、 字符集、 编码方式等作为判断的基准。

例子

当浏览器的默认语言为英语或中文， 访问相同 URI 的 Web 页面时，则会显示对应的英语版或中文版的 Web 页面。 这样的机制称为内容协商（Content Negotiation） 。

三种方式

服务器驱动协商、客户端驱动协商、透明协商

状态码

状态码的职责是当客户端向服务器端发送请求时， 描述返回的请求结果。 借助状态码， 用户可以知道服务器端是正常处理了请求， 还是出现了错误。

状态码如 200 OK， 以 3 位数字和原因短语组成。
数字中的第一位指定了响应类别， 后两位无分类。

2XX 成功

200 OK
表示从客户端发来的请求在服务器端被正常处理了。
在响应报文内， 随状态码一起返回的信息会因方法的不同而发生改变。

比如， 使用 GET 方法时， 对应请求资源的实体会作为响应返回；

而使用 HEAD 方法时， 对应请求资源的实体首部不随报文主体作为响应返回（即在响应中只返回首部， 不会返回实体的主体部分） 。

204 No Content
该状态码代表服务器接收的请求已成功处理， 但在返回的响应报文中不含实体的主体部分。 另外， 也不允许返回任何实体的主体。
206 Partial Content
该状态码表示客户端进行了范围请求， 而服务器成功执行了这部分的GET 请求。 响应报文中包含由 Content-Range 指定范围的实体内容。

3XX 重定向

301 Moved Permanently
永久性重定向。 该状态码表示请求的资源已被分配了新的 URI， 以后应使用资源现在所指的 URI。
例子：当指定资源路径的最后忘记添加斜杠“/”， 就会产生 301 状态码。

302 Found
临时性重定向。 该状态码表示请求的资源已被分配了新的 URI， 希望用户（本次） 能使用新的 URI 访问。

303 See Other
该状态码表示由于请求对应的资源存在着另一个 URI， 应使用 GET方法定向获取请求的资源。
304 Not Modified
该状态码表示客户端发送附带条件的请求 时， 服务器端允许请求访问资源， 但未满足条件的情况。 304 状态码返回时， 不包含任何响应的主体部分。
307 Temporary Redirect
临时重定向。

4XX 客户端错误

4XX 的响应结果表明客户端是发生错误的原因所在。

400 Bad Request

该状态码表示请求报文中存在语法错误。 当错误发生时， 需修改请求的内容后再次发送请求。

401 Unauthorized
该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证） 的认证信息。 另外若之前已进行过 1 次请求， 则表示用 户认证失败。
403 Forbidden
该状态码表明对请求资源的访问被服务器拒绝了。
404 Not Found
该状态码表明服务器上无法找到请求的资源。 除此之外， 也可以在服务器端拒绝请求且不想说明理由时使用。
 

5XX 服务器错误

500 Internal Server Error
该状态码表明服务器端在执行请求时发生了错误。 也有可能是 Web应用存在的 bug 或某些临时的故障
503 Service Unavailable
该状态码表明服务器暂时处于超负载或正在进行停机维护， 现在无法处理请求。

HTTP1.1版本新特性

• 默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求
• 管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应
• 断点续传
  • 实际上就是利用HTTP消息头使用分块传输编码，将实体主体分块传输。

虚拟主机

HTTP/1.1 规范允许一台 HTTP 服务器搭建多个 Web 站点。
用一台服务器为多位客户服务， 也可以以每位客户持有的域名运行各自不同的网站。

代理

代理是一种有转发功能的应用程序， 它扮演了位于服务器和客户端“中间人”的角色， 接收由客户端发送的请求并转发给服务器， 同时也接收服务器返回的响应并转发给客户端。

一种是是否使用缓存， 另一种是是否会修改报文。

缓存代理转发响应时， 缓存代理（Caching Proxy） 会预先将资源的副本（缓存） 保存在代理服务器上。
转发请求或响应时， 不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy） 。 反之， 对报文内容进行加工的代理被称为非透明代理。

网关

网关是转发其他服务器通信数据的服务器， 接收从客户端发送来的请求时， 它就像自己拥有资源的源服务器一样对请求进行处理。 有时客户端可能都不会察觉， 自己的通信目标是一个网关
网关的工作机制和代理十分相似。 而网关能使通信线路上的服务器提供非 HTTP 协议服务。
利用网关能提高通信的安全性， 因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。 比如， 网关可以连接数据库， 使用SQL语句查询数据。 另外， 在 Web 购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。

隧道

隧道是在相隔甚远的客户端和服务器两者之间进行中转， 并保持双方通信连接的应用程序。
隧道可按要求建立起一条与其他服务器的通信线路， 届时使用 SSL等加密手段进行通信。 隧道的目的是确保客户端能与服务器进行安全的通信。隧道本身不会去解析 HTTP 请求。 也就是说， 请求保持原样中转给之后的服务器。 隧道会在通信双方断开连接时结束。

缓存

分为服务器缓存和客户端缓存（临时网络文件）

缓存存在有效期，当判定缓存过期后， 会向源服务器确认资源的有效性。 若判断浏览器缓存失效， 浏览器会再次请求新资源。
 

通用首部字段

请求首部字段

响应首部字段

实体首部字段

HTTP的缺点

• 通信使用明文（不加密） ， 内容可能会被窃听
• 不验证通信方的身份， 因此有可能遭遇伪装
• 无法证明报文的完整性， 所以有可能已遭篡改

通信使用明文（不加密） ， 内容可能会被窃听

TCP/IP 是可能被窃听的网络

加密处理防止被窃听：通信的加密和内容的加密

通信加密

HTTP 协议中没有加密机制， 但可以通过和 SSL（Secure Socket Layer， 安全套接层） 或TLS（Transport Layer Security， 安全层传输协议） 的组合使用，加密 HTTP 的通信内容。与 SSL组合使用的 HTTP 被称为 HTTPS（HTTPSecure， 超文本传输安全协议） 或 HTTP over SSL。
内容的加密

不验证通信方的身份， 因此有可能遭遇伪装

任何人都可发起请求，不确认通信方， 会存在以下各种隐患：
无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。
无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。
无法确定正在通信的对方是否具备访问权限。
无法判定请求是来自何方、 出自谁手。
无法阻止海量请求下的 DoS 攻击（Denial of Service， 拒绝服务攻击） 。
查明对手的证书
无法证明报文的完整性， 所以有可能已遭篡改

接收到的内容可能有误

像这样， 请求或响应在传输途中， 遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack， MITM） 。
如何防止篡改
常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。依然无法百分百保证确认结果正确。 因
为 PGP 和 MD5 本身被改写的话， 用户是没有办法意识到的。

HTTP+ 加密 + 认证 + 完整性保护=HTTPS

HTTPS 并非是应用层的一种新协议。 只是 HTTP 通信接口部分用SSL（Secure Socket Layer） 和 TLS（Transport Layer Security） 协议代替而已。

SSL是独立于 HTTP 的协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用
相互交换密钥的公开密钥加密技术
加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system） ， 也被叫做对称密钥加密
以共享密钥方式加密时必须将密钥也发给对方。如果通信被监听那么密钥就可会落入攻击者之手， 同时也就失去了加密的意义。

公开密钥加密方式很好地解决了共享密钥加密的困难。
公开密钥加密使用一对非对称的密钥。 一把叫做私有密钥（private key） ， 另一把叫做公开密钥（public key） 。 顾名思
义， 私有密钥不能让其他任何人知道， 而公开密钥则可以随意发布， 任何人都可以获得。

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制
公开密钥处理速度慢，充分利用两者各自的优势， 将多种方法组合起来用于通信。

在交换密钥环节使用公开密钥加密方式， 之后的建立通信交换报文阶段则使用共享密钥加密方式。

问题：公开密钥加密方式还是存在一些问题的。 那就是无法证明公开密钥本身就是货真价实的公开密钥。
为了解决上述问题， 可以使用由数字证书认证机构（CA， CertificateAuthority） 和其相关机关颁发的公开密钥证书。
 

证书的一个作用是用来证明作为通信一方的服务器是否规范， 另外一个作用是可确认对方服务器背后运营的企业是否真实存在。
拥有该特性的证书就是 EV SSL证书（Extended Validation SSLCertificate） 。
 

HTTPS 的安全通信机制

步骤 1： 客户端通过发送 Client Hello 报文开始 SSL通信。 报文中包含客户端支持的 SSL的指定版本、 加密组件（Cipher Suite） 列表（所使用的加密算法及密钥长度等） 。
步骤 2： 服务器可进行 SSL通信时， 会以 Server Hello 报文作为应154答。 和客户端一样， 在报文中包含 SSL版本以及加密组件。 服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3： 之后服务器发送 Certificate 报文。 报文中包含公开密钥证书。
步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端， 最初阶段的 SSL握手协商部分结束。
步骤 5： SSL第一次握手结束之后， 客户端以 Client Key Exchange 报文作为回应。 报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。 该报文已用步骤 3 中的公开密钥进行加密。
步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。 该报文会提示服务器， 在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7： 客户端发送 Finished 报文。 该报文包含连接至今全部报文的整体校验值。 这次握手协商是否能够成功， 要以服务器是否能够正确解密该报文作为判定标准。
步骤 8： 服务器同样发送 Change Cipher Spec 报文。
步骤 9： 服务器同样发送 Finished 报文。
步骤 10： 服务器和客户端的 Finished 报文交换完毕之后， SSL连接就算建立完成。 当然， 通信会受到 SSL的保护。 从此处开始进行应用层协议的通信， 即发送 HTTP 请求。
步骤 11： 应用层协议通信， 即发送 HTTP 响应。
步骤 12： 最后由客户端断开连接。 断开连接时， 发送 close_notify 报文。 上图做了一些省略， 这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。
在以上流程中， 应用层发送数据时会附加一种叫做 MAC（MessageAuthentication Code） 的报文摘要。 MAC 能够查知报文是否遭到篡改， 从而保护报文的完整性。

HTTPS工作原理

 

1. 客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策

一次完整的HTTP请求所经历的7个步骤

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

建立TCP连接->发送请求行->发送请求头->（到达服务器）发送状态行->发送响应头->发送响应数据->断TCP连接

• 建立TCP连接

在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建 Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则， 只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。

• Web浏览器向Web服务器发送请求行

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。

• Web浏览器发送请求头

  • 浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

• Web服务器应答

  • 客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。

• Web服务器发送应答头

  • 正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

• Web服务器向浏览器发送数据

  • Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。

• Web服务器关闭TCP连接

  • 一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码：

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

为什么不一直使用 HTTPS

其中一个原因是， 因为与纯文本通信相比， 加密通信会消耗更多的CPU 及内存资源。因此， 如果是非敏感信息则使用 HTTP 通信， 只有在包含个人信息等敏感数据时， 才利用 HTTPS 加密通信。
想要节约购买证书的开销也是原因之一。

认证

什么要认证？

判断是谁在访问服务器

为了要访问服务器，需要核对信息：只有本人所持有的一些信息--密码、动态令牌、数字证书、生物认证、IC卡

HTTP/1.1 使用的认证方式：
BASIC 认证（基本认证）
DIGEST 认证（摘要认证）
SSL 客户端认证
FormBase 认证（基于表单认证）

BASIC 认证步骤

客户端发送请求-->服务器返回状态码401已告知客户端需要认证-->客户端用户ID和密码以Base64方式编码后发送-->服务器认证成功者返回状态码200，若认证失败则返回状态码401

缺点

采用Base64方式编码，但不是加密处理（直接发送明文密码），容易解码，导致被盗；

再一次认证时，浏览器无法实现认证注销；

使用不灵活，达不到web网站安全等级。

DIGEST 认证
使用质询 / 响应的方式
所谓质询响应方式是指， 一开始一方会先发送认证要求给另一方， 接着使用从另一方那接收到的质询码计算生成响应码。 最后将响应码返回给对方进行认证的方式。
DIGEST 认证的认证步骤
客户端发送请求-->服务器发送临时的质询码（随机数、nonce）以及告知需要认领的状态码401-->客户端发送摘要以及由质询码计算出的响应码（response）-->服务器认证成功返回状态码200，失败则再次发送状态码401

缺点

认证等级与HTTPS相比仍旧较弱，提供防止密码被窃听，但不提供防止用户伪装的保护机制。

使用不灵活，达不到web网站安全等级

SSL 客户端认证
防止用户被第三者冒充（有用户ID和密码，但不是本人）

SSL客户端认证借由 HTTPS 的客户端证书完成认证。凭借客户端证书 认证，服务器可确认访问是否来自已登录的客户端。
SSL 客户端认证的认证步骤
步骤 1： 接收到需要认证资源的请求， 服务器会发送 CertificateRequest 报文， 要求客户端提供客户端证书。
步骤 2： 用户选择将发送的客户端证书后， 客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。
步骤 3： 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥， 然后开始 HTTPS 加密通信。
SSL 客户端认证采用双因素认证
第一个认证因素的 SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。

基于表单认证
未在 HTTP 协议中定义，认证多半为基于表单认证，不具备共同标准规范

基于表单认证：通过服务器端的 Web 应用， 将客户端发送过来的用户 ID 和密码与之前登录过的信息做匹配来进行认证。

为什么采用？

由于使用上的便利性及安全性问题， HTTP 协议标准提供的 BASIC 认证和 DIGEST 认证几乎不怎么使用。 另外， SSL客户端认证虽然具有高度的安全等级， 但因为导入及维持费用等问题， 还尚未普及。

基于表单认证的标准规范尚未有定论， 一般会使用 Cookie 来管理Session（会话） 。

基于表单认证的步骤

步骤 1： 客户端把用户 ID 和密码等登录信息放入报文的实体部分，通常是以 POST 方法把请求发送给服务器。 而这时， 会使用 HTTPS通信来进行 HTML表单画面的显示和用户输入数据的发送。
步骤 2： 服务器会发放用以识别用户的 Session ID。 通过验证从客户端发送过来的登录信息进行身份认证， 然后把用户的认证状态与Session ID 绑定后记录在服务器端。

步骤 3： 客户端接收到从服务器端发来的 Session ID 后， 会将其作为Cookie 保存在本地。 下次向服务器发送请求时， 浏览器会自动发送Cookie， 所以 Session ID 也随之发送到服务器。 服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。
向客户端返回响应时， 会在首部字段 Set-Cookie 内写入 SessionID。为防止被盗，Session ID 应使用难以推测的字符串，且服务器端进行有效期的管理。为减轻跨站脚本攻击（XSS） 造成的损失， 建议事先在 Cookie内加上 httponly 属性。

一种安全的保存方法是， 先利用给密码加盐（salt） 1 的方式增加额外信息， 再使用散列（hash） 函数计算出散列值后保存。
1 salt 其实就是由服务器随机生成的一个字符串，但是要保证长度足够长， 并且是真正随机生成的。然后把它和密码字符串相连接（前后都可以） 生成散列值。

HTTP 的瓶颈

在现有 Web 实现所需的功能， 以下这些 HTTP 标准就会成为瓶颈:

一条连接上只可发送一个请求。
请求只能从客户端开始。 客户端不可以接收除响应以外的指令。
请求 / 响应首部未经压缩就发送。 首部信息越多延迟越大。
发送冗长的首部。 每次互相发送相同的首部造成的浪费较多。
可任意选择数据压缩格式。 非强制压缩发送。

Ajax 的解决方法
Ajax（Asynchronous JavaScript and XML， 异 步 JavaScript 与 XML技术） 是一种有效利用 JavaScript 和 DOM（Document Object Model， 文档对象模型） 的操作， 以达到局部 Web 页面替换加载的异步通信手段。

核心技术是名为 XMLHttpRequest 的 API， 通过 JavaScript 脚本语言的调用就能和服务器进行 HTTP 通信。

实时地从服务器获取内容， 有可能会导致大量请求产生。

Comet 的解决方法
一旦服务器端有内容更新了， Comet 不会让请求等待， 而是直接给客户端返回响应。 这是一种通过延迟应答， 模拟实现服务器端向客户端推送（Server Push） 的功能。
虽然可以做到实时更新， 但为了保留响应， 一次连接的持续时间也变长了。 期间， 为了维持连接会消耗更多的资源。

上述技术均未解决 HTTP 协议本身存在的问题。
Google 在 2010 年发布了 SPDY（取自 SPeeDY， 发音同 speedy） ， 其开发目标旨在解决 HTTP 的性能瓶颈， 缩短 Web 页面的加载时间（50%）。
SPDY的设计与功能
没有完全改写 HTTP 协议， 而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。 同时， 考虑到安全性问题， SPDY 规定通信中使用 SSL。SPDY 以会话层的形式加入， 控制对数据的流动， 但还是采用 HTTP建立通信连接。

使用 SPDY 后， HTTP 协议额外获得的功能：

多路复用流
通过单一的 TCP 连接， 可以无限制处理多个 HTTP 请求。 所有请求的处理都在一条 TCP 连接上完成， 因此 TCP 的处理效率得到提高。
赋予请求优先级
SPDY 不仅可以无限制地并发处理请求， 还可以给请求逐个分配优先级顺序。 这样主要是为了在发送多个请求时， 解决因带宽低而导致响应变慢的问题。
压缩 HTTP 首部
压缩 HTTP 请求和响应的首部。 这样一来， 通信产生的数据包数量和发送的字节数就更少了。
推送功能
支持服务器主动向客户端推送数据的功能。 这样， 服务器可直接发送数据， 而不必等待客户端的请求。
服务器提示功能
服务器可以主动提示客户端请求所需的资源。 由于在客户端发现资源之前就可以获知资源的存在， 因此在资源已缓存等情况下， 可以避免发送不必要的请求。

特点
SPDY 基本上只是将单个域名（IP 地址） 的通信多路复用， 所以当一个 Web 网站上使用多个域名下的资源， 改善效果就会受到限制。

使用浏览器进行全双工通信的WebSocket

利用 Ajax 和 Comet 技术进行通信可以提升 Web 的浏览速度。 但问题在于通信若使用 HTTP 协议， 就无法彻底解决瓶颈问题。 WebSocket网络技术正是为解决这些问题而实现的一套新协议及 API。
WebSocket， 即 Web 浏览器与 Web 服务器之间全双工通信标准。
WebSocket 协议的主要特点

推送功能
支持由服务器向客户端推送数据的推送功能。 这样， 服务器可直接发送数据， 而不必等待客户端的请求。
减少通信量
只要建立起 WebSocket 连接， 就希望一直保持连接状态。 和 HTTP 相比， 不但每次连接时的总开销减少， 而且由于 WebSocket 的首部信息很小， 通信量也相应减少了。

为了实现 WebSocket 通信， 在 HTTP 连接建立之后， 需要完成一次“握手”（Handshaking） 的步骤。
握手·请求
为了实现 WebSocket 通信， 需要用到 HTTP 的 Upgrade 首部字段， 告知服务器通信协议发生改变， 以达到握手的目的。
握手·响应
对于之前的请求， 返回状态码 101 Switching Protocols 的响应。
成功握手确立 WebSocket 连接之后， 通信时不再使用 HTTP 的数据帧， 而采用 WebSocket 独立的数据帧。

HTTP/2.0 的特点

HTTP/2.0 的目标是改善用户在使用 Web 时的速度体验。 基本上都会先通过 HTTP/1.1 与 TCP 连接。
HTTP/2.0 围绕着主要的 7 项技术进行讨论

Web 服务器管理文件的 WebDAV
WebDAV（Web-based Distributed Authoring and Versioning， 基于万维网的分布式创作和版本控制） 是一个可对 Web 服务器上的内容直接进行文件复制、 编辑等操作的分布式文件系统。

为什么 HTTP 协议受众能够如此广泛呢？
与企业或组织的防火墙设定有着莫大的关系，使用新协议或端口号则必须修改防火墙设置。
在构建 Web 服务器或访问 Web 站点时， 需事先设置防火墙 HTTP（80/tcp） 和 HTTPS（443/tcp） 的权限。
HTTP 具有导入简单这一大优势。 而这也是基于 HTTP 服务或内容不断增加的原因之一。
作为 HTTP 客户端的浏览器已相当普遍， HTTP 服务器的数量已颇具规模， HTTP 本身就是优异的应用。

针对 Web 应用的攻击模式

对 Web 应用的攻击模式有两种：主动攻击、被动攻击。
以服务器为目标的主动攻击
主动攻击（active attack） 是指攻击者通过直接访问 Web 应用，把攻击代码传入的攻击模式。 由于该模式是直接针对服务器上的资源进行攻击， 因此攻击者需要能够访问到那些资源。
主动攻击模式里具有代表性的攻击是 SQL注入攻击和 OS 命令注入攻击。

以服务器为目标的被动攻击
被动攻击（passive attack） 是指利用圈套策略执行攻击代码的攻击模式。 在被动攻击过程中， 攻击者不直接对目标 Web 应用访问发起攻击。
被动攻击通常的攻击模式如下所示：
步骤 1： 攻击者诱使用户触发已设置好的陷阱， 而陷阱会启动发送已嵌入攻击代码的 HTTP 请求。
步骤 2： 当用户不知不觉中招之后， 用户的浏览器或邮件客户端就会触发这个陷阱。
步骤 3： 中招后的用户浏览器会把含有攻击代码的 HTTP 请求发送给作为攻击目标的 Web 应用， 运行攻击代码。
步骤 4： 执行完攻击代码， 存在安全漏洞的 Web 应用会成为攻击者的跳板， 可能导致用户所持的 Cookie 等个人信息被窃取，
               登录状态中的用户权限遭恶意滥用等后果。

被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求伪造。

利用用户的身份攻击企业内部网络（被动攻击）

安全漏洞

因输出值转义不完全引发的安全漏洞

跨站脚本攻击（Cross-Site Scripting， XSS）
SQL 注入攻击
OS 命令注入攻击（OS Command Injection）
HTTP 首部注入攻击
邮件首部注入攻击
目录遍历攻击
远程文件包含漏洞
因设置或设计上的缺陷引发的安全漏洞
强制浏览
不正确的错误消息处理
开放重定向
因会话管理疏忽引发的安全漏洞
会话劫持
会话固定攻击
跨站点请求伪造
其他安全漏洞
密码破解
点击劫持
DoS 攻击（Denial of Service attack）
后门程序