（pdf如果有要的haul，私信吧）

Web 使用一种名为 HTTP（HyperText Transfer Protocol，超文本传输协 议 1）的协议作为规范，完成从客户端到服务器端等一系列运作流 程。而协议是指规则的约定。可以说，Web 是建立在 HTTP 协议上通 信的。 

现在已提出了 3 项 WWW 构建技术，htm,http,url

TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分别分 为以下 4 层：应用层、传输层、网络层和数据链路层。

TCP/IP 协议族各层的作用如下。 

应用层 

应用层决定了向用户提供应用服务时通信的活动。 TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域 名系统）服务就是其中两类。 HTTP 协议也处于该层。 

传输层 

传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据 传输。 在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报 协议）。 

网络层（又名网络互连层） 

网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所 起的作用就是在众多的选项内选择一条传输路线。 

链路层（又名数据链路层，网络接口层） 用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱 动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等 物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在 链路层的作用范围之内。

：具体怎么实现呢

官方给出了解释：

首先作为发送端的客户端在应用层 （HTTP 协议）发出一个想看某个 Web 页面的 HTTP 请求。 接着，为了传输方便，在传输层（TCP 协议）把从应用层处收到的数 据（HTTP 请求报文）进行分割，并在各个报文上打上标记序号及端 口号后转发给网络层。 在网络层（IP 协议），增加作为通信目的地的 MAC 地址后转发给链 路层。这样一来，发往网络的通信请求就准备齐全了。 接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用 层。当传输到应用层，才能算真正接收到由客户端发送过来的 HTTP 请求。

这种把数据信息包装起来的做法称为封装（encapsulate）。

：这就是将数据封装起来了，然后交到服务器的时候被层层剥开

可能有人会把“IP”和“IP 地址”搞混，“IP”其实是一种协议的名称。

：ip协议地址的作用是将数据发送到目标处，且确实发到那里，依仗的条件是IP 地址和 MAC 地址（Media Access Control Address）。

IP 地址指明了节点被分配到的地址，MAC 地址是指网卡所属的固定 地址。IP 地址可以和 MAC 地址进行配对。IP 地址可变换，但 MAC 地址基本上不会更改

：在进行通信的时候，可能会经过多台电脑才能中转到指定位置，中转电脑会采用arp来进行搜索

ARP 是一种用以解析地址的协议，根据通信方 的 IP 地址就可以反查出对应的 MAC 地址。

三次握手

数据分割成几段，采用字节流服务（Byte Stream Service）

用 TCP 协议把数据包送出去后，TCP 不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。 21握手过程中使用了 TCP 的标志（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。 发送端首先发送一个带 SYN 标志的数据包给对方。接收端收到后， 回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。最后，发 送端再回传一个带 ACK 标志的数据包，代表“握手”结束。 若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序发 送相同的数据包。

这样使数据变得可靠

get，post等http方法：

GET ：获取资源 GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器 端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保 持原样返回；如果是像 CGI（Common Gateway Interface，通用网关接 口）那样的程序，则返回经过执行后的输出结果。 使用 GET 方法的请求·响应的例子请求 GET /index.html HTTP/1.1 Host: www.hackr.jp 响应 返回 index.html 的页面资源 请求 GET /index.html HTTP/1.1 Host: www.hackr.jp If-Modified-Since: Thu, 12 Jul 2012 07:30:00 GMT 响应 仅返回2012年7 月12日7 点30分以后更新过的index.html页面资源。如果未 有内容更新，则以状态码304 Not Modified作为响应返回 POST：传输实体主体 POST 方法用来传输实体的主体。 虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行 传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。 使用 POST 方法的请求·响应的例子 请求 POST /submit.cgi HTTP/1.1 Host: www.hackr.jp Content-Length: 1560（1560字节的数据） 响应 返回 submit.cgi 接收数据的处理结果 

PUT：传输文件 PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请 求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。 36但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以 上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。 使用 PUT 方法的请求·响应的例子 请求 PUT /example.html HTTP/1.1 Host: www.hackr.jp Content-Type: text/html Content-Length: 1560（1560 字节的数据） 响应1 响应返回状态码 204 No Content（比如 ：该 html 已存在于服务器上） 1 响应的意思其实是请求执行成功了，但无数据返回。——译者注 

HEAD：获得报文首部 HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。 图：和 GET 一样，但不返回报文主体 37使用 HEAD 方法的请求·响应的例子 请求 HEAD /index.html HTTP/1.1 Host: www.hackr.jp 响应 返回index.html有关的响应首部 

DELETE：删除文件 DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按 请求 URI 删除指定的资源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用 程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。 使用 DELETE 方法的请求·响应的例子 请求 DELETE /example.html HTTP/1.1 Host: www.hackr.jp 响应 响应返回状态码 204 No Content（比如 ：该 html 已从该服务器上删除） 

OPTIONS：询问支持的方法 OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。 38使用 OPTIONS 方法的请求·响应的例子 请求 OPTIONS * HTTP/1.1 Host: www.hackr.jp 响应 HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS （返回服务器支持的方法）

TRACE：追踪路径 TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方 法。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服 务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最 后接收到请求的服务器端则返回状态码 200 OK 的响应。 客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改 / 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理 中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。 但是，TRACE 方法本来就不怎么常用，再加上它容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。 使用 TRACE 方法的请求·响应的例子 请求 TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2 HTTP/1.1 200 OK Content-Type: message/http 39响应 Content-Length: 1024 TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2（返回响应包含请求内容） 

CONNECT：要求用隧道协议连接代理 CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协 议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容 加 密后经网络隧道传输。 CONNECT 方法的格式如下所示。 CONNECT 代理服务器名:端口号 HTTP版本 使用 CONNECT 方法的请求·响应的例子 请求 CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp 响应 HTTP/1.1 200 OK（之后进入网络隧道）

：以上了解即可

：在客户端与服务器相互通信的过程中，初始的链接是每次传输通信都需要进行tcp的断开，相当花费资源，后面才有了持久链接

持久连接的特点是，只要任意一端 没有明确提出断开连接，则保持 TCP 连接状态

cookie:

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

产生的信息：

1. 请求报文（没有 Cookie 信息的状态） GET /reader/ HTTP/1.1 Host: hackr.jp *首部字段内没有Cookie的相关信息

2. 响应报文（服务器端生成 Cookie 信息） HTTP/1.1 200 OK Date: Thu, 12 Jul 2012 07:12:20 GMT Server: Apache ＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed, 10-Oct-12 07:12:20 GMT＞ Content-Type: text/plain; charset=UTF-8

3. 请求报文（自动发送保存着的 Cookie 信息） GET /image/ HTTP/1.1 Host: hackr.jp Cookie: sid=1342077140226724

第三章

报文的结构

常用的内容编码有以下几种。 gzip（GNU zip） compress（UNIX 系统的标准压缩） deflate（zlib） identity（不进行编码）

分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六 进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标 记。使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编 码前的实体主体。 HTTP/1.1 中存在一种称为传输编码（Transfer Coding）的机制，它可 以在通信时按某种编码方式传输，但只定义作用于分块传输编码中

透明代理 转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理 （Transparent Proxy）。反之，对报文内容进行加工的代理被称为非 透明代理。 

利用网关可以由 HTTP 请求转化为其他协议通信

隧道本身不会去解析 HTTP 请求。也就是说，请求保持原样中转给之 后的服务器。隧道会在通信双方断开连接时结束。通过隧道的传输，可以和远距离的服务器安全通信。隧道本 身是透明的，客户端不用在意隧道的存在 

缓存在一些领域都很常见的用到，具体一些操作中的细节，比如验证有效性，是否已经缓存可以在查资料了解其中到底呢么实现的

一些协议：

在 HTTP 出现之前的协议 在 HTTP 普及之前，也就是从互联网的诞生期至今，曾出现过各式 各样的协议。在 HTTP 规范确立之际，制定者们参考了那些协议的 功能。也有某些协议现在已经彻底退出了人们的视线。接下来，我 们会简单介绍一下这些协议。 FTP（File Transfer Protocol） 传输文件时使用的协议。该协议历史久远，可追溯到 1973 年前 后，比 TCP/IP 协议族的出现还要早。虽然它在 1995 年被 HTTP 的 流量（Traffic）超越，但时至今日，仍被广泛沿用。 NNTP（Network News Transfer Protocol） 用于 NetNews 电子会议室内传送消息的协议。在 1986 年前后出 现，属于比较古老的一类协议。现在，利用 Web 交换信息已成主 流，所以该协议已经不怎么使用了。 Archie 搜索 anonymous FTP 公开的文件信息的协议。1990 年前后出现，现 在已经不常使用。 WAIS（Wide Area Information Servers） 以关键词检索多个数据库使用的协议。1991 年前后出现。由于现 在已经被 HTTP 协议替代，也已经不怎么使用了。 Gopher 查找与互联网连接的计算机内信息的协议。1991 年前后出现，由 于现在已经被 HTTP 协议替代，也已经不怎么使用了。

从字面意思上很容易把 no-cache 误解成为不缓存，但事实上 no-cache 代表不缓 存过期的资源，缓存会向源服务器进行有效期确认后处理资源，也许称为 do-not- serve-from-cache-without-revalidation 更合适。no-store 才是真正地不进行缓存，请 读者注意区别理解。

HTTP/1.1 版本的默认连接都是持久连接。为此，客户端会在持 久连接上连续发送请求。当服务器端想明确断开连接时，则指定 Connection 首部字段的值为 Close。

警告码：

警告码 警告内容 说明 110 Response is stale（响应已过期） 代理返回已过期的资源 111 Revalidation failed（再验证失败） 代理再验证资源有效性时失败（服务 器无法到达等原因） 112 Disconnection operation（断开连接操 作） 代理与互联网连接被故意切断 113 Heuristic expiration（试探性过期） 响应的使用期超过24小时（有效缓存 的设定时间大于24小时的情况下） 199 Miscellaneous warning（杂项警告） 任意的警告内容 214 Transformation applied（使用了转换） 代理对内容编码或媒体类型等执行了 某些处理时 299 Miscellaneous persistent warning（持久 杂项警告） 任意的警告内容

Accept-Encoding: gzip, deflate Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及 内容编码的优先级顺序。可一次性指定多种内容编码。 101下面试举出几个内容编码的例子。 gzip 由文件压缩程序 gzip（GNU zip）生成的编码格式 （RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循环冗余 校验（Cyclic Redundancy Check，通称 CRC）。 compress 由 UNIX 文件压缩程序 compress 生成的编码格式，采用 Lempel- Ziv-Welch 算法（LZW）。 deflate 组合使用 zlib 格式（RFC1950）及由 deflate 压缩算法 （RFC1951）生成的编码格式。 identity 不执行压缩或不会变化的默认编码格式 采用权重 q 值来表示相对优先级，这点与首部字段 Accept 相同。另 外，也可使用星号（*）作为通配符，指定任意的编码格式。 

强 ETag 值和弱 Tag 值 ETag 中有强 ETag 值和弱 ETag 值之分。 强 ETag 值 强 ETag 值，不论实体发生多么细微的变化都会改变其值。 ETag: "usagi-1234" 弱 ETag 值 弱 ETag 值只用于提示资源是否相同。只有资源发生了根本改变，产 生差异时才会改变 ETag 值。这时，会在字段值最开始处附加 W/。 ETag: W/"usagi-1234"

这些子段太多了，大致了解一下，然后有用到的时候再查吧

HTTPS加密问题：

好好理解想想

证书有：EV SSL 证书 ，客户端证书等

关于认证：

如果使用 OpenSSL这套开源程序，每个人都可以构建一套属于 自己的认证机构，从而自己给自己颁发服务器证书。但该服务器 证书在互联网上不可作为证书使用，似乎没什么帮助。 独立构建的认证机构叫做自认证机构，由自认证机构颁发的“无 用”证书也被戏称为自签名证书。由自认证机构颁发的证书称为自签名证书 ，会涉及安全问题，浏览器不让访问，由自认证机构颁发的服务器证书之所以不起作用，是因为它无法 消除伪装的可能性。

https是如何安全通信的呢：

步骤 1： 客户端通过发送 Client Hello 报文开始 SSL通信。报文中包 含客户端支持的 SSL的指定版本、加密组件（Cipher Suite）列表（所 使用的加密算法及密钥长度等）。 

步骤 2： 服务器可进行 SSL通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL版本以及加密组件。服务器的 加密组件内容是从接收到的客户端加密组件内筛选出来的。 

步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证 书。

步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶 段的 SSL握手协商部分结束。 

步骤 5： SSL第一次握手结束之后，客户端以 Client Key Exchange 报 文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。 

步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提 示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。 （因为第一次握手后，发送的key已经使用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（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡 改，从而保护报文的完整性。

要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认 证机构（CA）购买。证书价格可能会根据不同的认证机构略有不 同。通常，一年的授权需要数万日元（现在一万日元大约折合 600 人民币）。

、

认证：

HTTP/1.1 使用的认证方式如下所示。 

BASIC 认证（基本认证） DIGEST 认证（摘要认证） SSL 客户端认证 FormBase 认证（基于表单认证） 此外，还有 Windows 统一认证（Keberos 认证、NTLM 认证）

下面介绍认证：

步骤 1： 当请求的资源需要 BASIC 认证时，服务器会随状态码 401 Authorization Required，返回带 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 网站期望的安 全性等级，因此它并不常用。

：这种情况其实在下载的时候我们可能会遇到，就像你用迅雷下载一个文件弹出站点的认证消息，需要输入账号密码，或者在git或者gitee 下载或者clone文件的时候

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。另 外，有关 Request-Digest 的计算规则较复杂，有兴趣的读者不妨深入 学习一下 RFC2617。 

步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会确认认 证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。 并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信 息。DIGEST 认证提供了高于 BASIC 认证的安全等级，但是和 HTTPS 的 客户端认证相比仍旧很弱。DIGEST 认证提供防止密码被窃听的保护 机制，但并不存在防止用户伪装的保护机制。 DIGEST 认证和 BASIC 认证一样，使用上不那么便捷灵活，且仍达不 到多数 Web 网站对高度安全等级的追求标准。因此它的适用范围也 有所受限。

SSL 客户端认证的认证步骤 

为达到 SSL客户端认证的目的，需要事先将客户端证书分发给客户 端，且客户端必须安装此证书。 步骤 1： 接收到需要认证资源的请求，服务器会发送 Certificate Request 报文，要求客户端提供客户端证书。 

步骤 2： 用户选择将发送的客户端证书后，客户端会把客户端证书信 息以 Client Certificate 报文方式发送给服务器。 

 步骤 3： 服务器验证客户端证书验证通过后方可领取证书内客户端的 165公开密钥，然后开始 HTTPS 加密通信。

但是：

在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和 基于表单认证（稍后讲解）组合形成一种双因素认证（Two-factor authentication）来使用。所谓双因素认证就是指，认证过程中不仅需 要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为 另一个因素，与其组合使用的认证方式。 换言之，第一个认证因素的 SSL客户端证书用来认证客户端计算机， 另一个认证因素的密码则用来确定这是用户本人的行为。 通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算 机访问服务器。而且证书一般还是收费的。

基于表单认证

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

步骤 1： 客户端把用户 ID 和密码等登录信息放入报文的实体部分， 通常是以 POST 方法把请求发送给服务器。而这时，会使用 HTTPS 通信来进行 HTML表单画面的显示和用户输入数据的发送。 

步骤 2： 服务器会发放用以识别用户的 Session ID。通过验证从客户 端发送过来的登录信息进行身份认证，然后把用户的认证状态与 Session ID 绑定后记录在服务器端。 向客户端返回响应时，会在首部字段 Set-Cookie 内写入 Session ID（如 PHPSESSID=028a8c…）。 你可以把 Session ID 想象成一种用以区分不同用户的等位号。然而，如果 Session ID 被第三方盗走，对方就可以伪装成你的身份进 行恶意操作了。因此必须防止 Session ID 被盗，或被猜出。为了做到 这点，Session ID 应使用难以推测的字符串，且服务器端也需要进行 有效期的管理，保证其安全性。 另外，为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie 内加上 httponly 属性。 

步骤 3： 客户端接收到从服务器端发来的 Session ID 后，会将其作为 Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送 Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证 接收到的 Session ID 识别用户和其认证状态。

spdy设计模式:

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

webscock之后：

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 ：保存空间不足

html:

DOM 是用以操作 HTML文档和 XML文档的 API（Application Programming Interface，应用编程接口）。使用 DOM 可以将 HTML内 的元素当作对象操作，如取出元素内的字符串、改变那个 CSS 的属 性等，使页面的设计发生改变。

CGI（Common Gateway Interface，通用网关接口）是指 Web 服务器在 接收到客户端发送过来的请求后转发给程序的一组机制。