1.1 WWW(World Wide Web，万维网)
1.2 网络基础TCP/IP协议簇
通常使用的网络(包括互联网)是在TCP/IP协议族的基础上运作的。而HTTP属于它内部对的一个子集。
四层：应用层、传输层、网络层和数据链路层。
负责传输的IP协议(Internet Protocol)
位于网络层，传送数据包；
两个重要条件：IP地址和MAC地址。
确保可靠性的TCP(Transmission Control Protocol,传输控制协议)
传输层，提供可靠的字节流服务；
vs UDP(User Data Protocol,用户数据报协议)；
三次握手 - 确保数据能到达目标
③负责域名解析的DNS服务(Domain Name System)
提供域名到IP地址之间的解析服务(通过域名查找IP地址，或逆向)。
各种协议与HTTP协议的关系
报文首部 和 (2)报文主体 两块。(通常并不一定要有报文主体)。
报文主体和实体主体的差异（实体主体⫋报文主体）
HTTP通信中的基本单位，由8位组字节流（octet sequence，其中octet为8个比特）组成，通过HTTP通信传输。有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。
编码提升传输效率
①压缩传输的内容编码
②分割发送的分块传输编码
| 类别 | 原因短语 | |
|---|---|---|
| 1XX | Informational （信息性状态码） |
接收的请求正在处理 |
| 2XX | Success （成功状态码） |
请求正常处理完毕 |
| 3XX | Redirection （重定向状态码） |
需要进行附加操作以完成请求 |
| 4XX | Client Error (客户端错误状态码) |
服务器无法处理请求 |
| 5XX | Server Error (服务器错误状态码) |
服务器处理请求出错 |
| 状态码 (状态码英文名称) |
详解 |
|---|---|
| 100 (Continue) |
继续，客户端应继续其请求。如果服务器收到头信息中带有100-continue的请求，这是指客户端询问是否可以在后续的请求中发送附件。在这种情况下，服务器用100(SC_CONTINUE)允许客户端继续或用417 (Expectation Failed)告诉客户端不同意接受附件。这个状态码是 HTTP 1.1中新加入的。 |
| 101 (Switching Protocols) |
切换协议，服务器根据客户端的请求切换协议。当客户端通过在请求里使用Upgrade报头，以通知服务器它想改用除HTTP协议之外的其他协议时，客户端将获得此响应代码。101响应代码表示“行，我现在改用另一个协议了”。 |
| 200 (OK) |
 |
| 请求成功。一般用于GET与POST请求 | |
| 204 (No Content) |
 |
| 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 | |
| 206 (Partial Content) |
 |
| 该状态码表示客户端进行范围请求，服务器成功执行GET请求，响应报文中包含Content-Range指定范围的实体内容。 | |
| 301 (Moved Permanently) |
 |
| xx | 永久性重定向。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。（需要更新书签） |
| 302 (Found) |
 |
| 临时性重定向。与301类似。但资源只是临时被移动。客户端应继续使用原有URI。（不会更新书签） | |
| 303 (See Other) |
 |
| 与302类似，区别是明确表示客户端应使用GET方法定向获取请求的资源。 ps: 301、302标准是禁止将POST改为GET的，但是实际上几乎所有的浏览器都会这么改。 |
|
| 304 (Not Modified) |
 |
| 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源. | |
| 307 (Temporary Redirect) |
/ |
| 与302类似，区别是不会从POST变成GET | |
| 400 (Bad Request) |
 |
| 请求报文中存在语法错误，需修改请求内容中再次发送。 | |
| 401 (Unauthorized) |
 |
| 表示发送的请求需要有通过HTTP认证(BASIC认证、DIGEST认证)的认证信息。 返回401必须包含一个适用请求资源的WWW-Authenticate首部用以质询用户信息，初次接受会弹出认证对话窗口。 |
|
| 403 (Forbidden) |
 |
| 表明对请求的资源的访问被服务器拒绝了 . | |
| 404 (Not Found) |
 |
| 表明服务器上无法找到请求的资源. | |
| 500 (Internal Server Error) |
 |
| 表明服务器端执行请求时发生了错误. | |
| 502 (Bad Gateway) |
/ |
| 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 | |
| 503 (Service Unavailable) |
 |
| 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
2.4.1 用单台虚拟主机实现多个域名
2.4.2 通信数据转发程序：代理、网关、隧道
①代理：代理是一种有转发功能的应用程序，接收从客户端发送来的请求并转发给服务器，反之。接收服务器的响应转发给客户端。
②网关：网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求并对请求进行处理。
其工作机制与代理十分相似，而网关能使通信线路上的服务器提供非HTTP协议服务。
提高安全性，客户端 - 加密 - 网关。
③隧道：在相隔甚远的客户端和服务器两者之间建立通信路线 ，并保持双方通信连接的应用程序。
2.4.3 保存资源的缓存
1. HTTP/1.1规范定义了如下47种首部字段。
通用首部字段
| 首部字段名 | 说明 |
|---|---|
| Cache-Control | 控制缓存的行为 |
| Connection | 逐跳首部，连接的管理 |
| Date | 创建HTTP报文的日期时间。 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主体的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器的相关信息 |
| Warning | 错误通知 |
请求首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言(自然语言) |
| Authorization | Web认证信息 |
| Expect | 期待服务器的特定行为 |
| From | 用户的电子邮箱地址 |
| Host | 请求资源所在服务器 |
| if-Match | 比较实体标记（ETag） |
| if-Modified-Since | 比较资源的更新时间 |
| if-None-Match | 比较实体标记（与if-Match相反） |
| if-Range | 资源未更新时发送实体Byte的范围请求 |
| if-Unmodified-Since | 比较资源的更新时间（与if-Modified-Since相反） |
| Max-Forwards | 最大传输逐跳数 |
| Proxy-Authorization | 代理服务器要求客户端的认证信息 |
| Range | 实体的字节范围请求 |
| Referer | 对请求中URI的原始获取方 |
| TE | 传输编码的优先级 |
| User-Agent | HTTP客户端程序的信息 |
响应首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 推算资源创建经过时间 |
| ETag | 资源的匹配信息 |
| LOcation | 令客户端重新定向至指定的URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server | HTTP服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户度端的认证信息 |
实体首部字段
| 首部字段名 | 说明 |
|---|---|
| Allow | 资源可支持的HTTP方法 |
| Content—Encoding | 实体主体适用的内容编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体部分的大小（单位：字节） |
| Content-Location | 替代对应资源的URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Context-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
2. 为Cookie服务的首部字段
| 首部字段名 | 说明 | 首部类型 |
|---|---|---|
| Set Cookie | 开始状态管理所使用的Cookie信息 | 响应首部字段 |
| Cookie | 服务器接收到的Cookie信息 | 请求首部字段 |
 
|
||
| 3. 其他首部字段 |
HTTPS是身披SSL外壳的HTTP(通信的加密)
相互交换密钥的公开密钥加密技术(SSL采用这种 内容的加密 方式)
使用两把密钥的公开密钥加密：
证明公开密钥正确性的证书
使用由数字证书认证机构（CA, Certificate Authority）和其相关机关颁发的公开密钥证书。
跨站脚本攻击(Cross-Site Scripting,XSS)
是指通过存在安全漏洞的 Web 网站注册用户的浏览器内运行非法的HTML 标签或 JavaScript 进行的一种攻击。
是攻击者利用预先设置的陷阱触发的被动攻击。
SQL注入攻击（会执行非法 SQL）
是指针对 Web 应用使用的数据库，通过运行非法的 SQL 而产生的攻击。
OS命令注入攻击
是指通过 Web 应用，执行非法的操作系统命令达到攻击的目的。
http首部注入攻击
HTTP 首部注入攻击(HTTP Header Injection)是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。
属于被动攻击模式。
HTTP 首部注入攻击有可能会造成以下一些影响。
设置任何 Cookie 信息、重定向至任意 URL、显示任意的主体(HTTP 响应截断攻击)
邮件首部注入攻击
是指 Web 应用中的邮件发送功能,攻击者通过向邮件首部 To 或 Subject 内任意添加非法内容发起的攻击。利用存在安全漏洞的 Web 网站，可对任意邮件地址发送广告邮件或病毒邮件。
目录遍历攻击
是指对本无意公开的文件目录，通过非法截断其目录路径后，达成访问目的的一种攻击。这种攻击有时也称为路径遍历(Path Traversal)攻击。
远程文件包含漏洞
是指当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的 URL 充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击。
强制浏览
从安置在 Web 服务器的公开目录下的文件中，浏览那些原本非自愿公开的文件。
不正确的错误消息处理
eg：画面提示“邮件地址未注册”的错误消息。当输入的邮件地址尚未在该 Web 网站上注册时，就会触发 这条错误消息。因为倘若邮件地址存在，应该会提示“输入的密码有误”之类的错误消息。攻击者利用进行不同的输入会提示不同的错误信息这条，就可用来确认输入的邮件地址是否已在这个Web 网站上注册过了。
为了不让错误消息给攻击者以启发,建议将提示消息的内容仅保留到“认证错误”这种程度即可。
开放重定向
而于此功能相关联的安全漏洞是指，假如指定的重定向 URL 到某个具有恶意的 Web 网站，那么用户就会被诱导至那个 Web 网站。
eg：http://example.com/?redirect=http://www.tricorder.jp
攻击：http://example.com/?redirect=http://hackr.jp
用户看到 URL 后原以为访问 example.com，不料实际上被诱导至 hackr.jp 这个指定的重定向目标。可信度高的 Web 网站如果开放重定向功能，则很有可能被攻击者选中并用来作为钓鱼攻击的跳板。
跨站点请求伪造跨站点请求伪造(Cross-Site Request Forgeries,CSRF)攻击是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新，属于被动攻击。
Basic认证
①客户端发起请求
→ ②服务端返回401+WWW-Authenticate首部字段（认证的方式(BASIC)+Request-URL安全域字符串(realm)）
→ ③客户端发生送用户名密码
→ ④服务器验证+返回资源
DIGEST认证
①客户端发起请求
→ ②服务端返回401+WWW-Authenticate首部字段（认证的方式(DIGEST)+质问响应的方式认证所需的临时质询码(随机数nonce)+realm）
→ ③客户端请求(首部字段Authorization (必须包含username，realm，none从，uri和response的字段信息)
→ ④服务器验证+返回资源
SSL客户端认证
①一条连接上只可发送一个请求
②请求只能从客户端开始，客户端不可以接收除响应以外的指令
③请求/响应首部未经压缩就发送，信息越多延迟越大
④发送冗长的首部，相同首部会浪费
⑤可任意选择数据压缩格式。非强制压缩发送
Ajax的解决办法
Ajax 的核心技术是名为 XMLHttpRequest 的 API，通过 JavaScript 脚本语言的调用就能和服务器进行 HTTP 通信。借由这种手段，就能从已加载完毕的 Web 页面上发起请求，只更新局部页面。而利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求产生。另外， Ajax 仍未解决 HTTP 协议本身存在的问题。
Comet 的解决方法
一旦服务器端有内容更新了， Comet 不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。通常，服务器端接收到请求，在处理完毕后就会立即返回响应，但为了实现推送功能， Comet 会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。因此，服务器端一旦有更新，就可以立即反馈给客户端。内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维持连接会消耗更多的资源。另外， Comet 也仍未解决 HTTP 协议本身存在的问题。
SPDY的设计与功能
在TCP/IP的应用层与运输层之间通过新加会话层的形式运作，同时通信使用SSL。
使用 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 通信，在 HTTP 连接建立之后，需要完成一次“握手”（Handshaking）的步骤：
6. 期盼已久的 HTTP/2.0
协议：SPDY、HTTP Speed＋Mobility 、Network-Friendly HTTP Upgrade
HTTP/2.0的特点：
| 压缩 | SPDY、Friendly |
|---|---|
| 多路复用 | SPDY |
| TLS义务化 | Speed＋Mobility |
| 协商 | Speed＋Mobility，Friendly |
| 客户端拉曳（Client Pull）/服务器推送（Server Push） | Speed＋Mobility |
| 流量控制 | SPDY |
| WebSocket | Speed＋ Mobility |
| 注：HTTP Speed＋Mobility 简写为Speed＋Mobility，Network-Friendly HTTP Upgrade简写为Friendly. |