Http小结
第一章 了解Web及网络基础
1.TCP/IP协议簇（IEEE 802.3、FDDI、ICMP、TCP、HTTP、IP、FTP、DNS、PPPPoE、SNMP、UDP)
2.TCP/IP分层：应用层、传输层、网络层、数据链路层---(组块化设计)
3.应用层（FTP、DNS等协议）
传输层（TCP、UDP等协议）
网络层（传递数据包）
数据链路层（网络接口层，连接硬件）
4.基本通信方式（封装）：
客户端（套层传输）--应用层（HTTP）->传输层（TCP..）->网络层（IP）->链路层（网络）
服务器（拆层传输）--链路层（网络）->网络层（IP）->传输层（TCP..）->应用层（HTTP）
5.IP地址和IP网际协议（Internet Protocol）
6.网络传输（路由选择）
7.TCP协议的三次握手-flag---SYN、ACK
（1）发送端：发送标有SYN的数据包
（2）接收端：接收标有SYN的数据包并添加ACK标记进行回传
（3）发送端：确认相关数据包，进行通信传输
8.DNS（域名解析）IP--域名
9.URI和URL（服务器域名、端口号--Web默认80、文件路径访问..）
第二章 简单的HTTP协议
1.HTTP通信例子（响应头、请求头---参数---响应---Cookie）
（1）发送请求：GET / HTTP/1.1
HOST：hacker.jp
（2）发送响应：HTTP/1.1 200 OK (http协议版本、状态码)
Date ：...（日期）
Content-Length：...（多少字节的数据）
Content-Type：text/html
<html>....（主体）
2.HTTP协议（简单无状态）---不做持久化处理，减少服务器的CPU及内存资源的消耗。
3.HTTP+Cooike（session）---持久化处理
4.HTTP1.1传输方法:GET（获取资源--响应内容<text\html>）-------------（※）
POST（传输实体主体--信息）
PUT（传输文件--不带验证机制，存在安全问题）
HEAD（获取报文首部）--不返回报文主体
DELETE（删除文件--不带验证机制，存在安全问题）
OPTIONS（询问支持的方法）--返回服务器支持的方法
TRACE（追踪路径）--查询发送出去的请求是怎么被加工修改/篡改的。不常用---易引发XST（跨站追踪）攻击
CONNECT（要求用隧道协议来连接代理）--SSL（安全套接层）、TLS（传输层安全）
格式：CONNECT 代理服务器名：端口号 HTTP 版本
5.持久连接旨在建立1次TCP连接后进行多次请求和响应的交互---减轻服务器端的负载、通信开销
6.管线化（Pipelining）--不等待响应，直接发送下一个请求
7.HTTP+Cookie传输
客户端：发送请求
服务器：生成cookie，记住是向谁发送的，响应中添加Cookie---<Set-Cookie: sid=..；path=/;....>
客户端：保存Cookie。---下次请求可以附带Cookie进行持久化认证处理。
第三章 HTTP报文内的HTTP信息
1.HTTP报文的结构
报文首部：服务器端或客户端处理的请求或响应的内容及属性
空行CR＋LF：CR（Carriage Return，回车符：16进制0x0d）和LF（Line Feed，换行符：16进制0x0a）---划分作用
报文主体：应被发送的数据
2.请求报文结构：
GET /HTTP/1.1 请求行
Host：...
User-Agent：...
Accept：text/html，...... 各种首部字段（通用首部、请求首部、响应首部、实体首部）
空行CR＋LF
响应报文结构：
HTTP/1.1 200 OK 状态行
Date：..
Server：Apache
Last-Modified：....... 各种首部字段
空行CR＋LF
<html xmls="">
.......
</html> 报文主体（message entity）
3.编码提升传输速率
3.1message（HTTP通信的基本单位）和entity（请求或响应的有效载荷数据<补充项>）
3.2压缩传输的内容编码--gzip（GNU zip）、compress(UNIX系统的标准压缩)、deflate（zlib）、identity(不进行编码)
3.3分割发送的分块传输编码---传输大容量的数据时，可分割传输，逐步显示页面内容----接收的客户端负责解码
4.发送多种数据的多部分对象集合
4.1MIME机制(多用途因特网邮件扩展)---允许邮件处理文本、图片、视频等多个不同类型的数据。
4.2HTTP 协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
HTTP 报文中使用多部分对象集合时，需要在首部字段里加上Content-type。
5.获取部分内容的范围请求
5.1恢复是指能从之前下载中断处恢复下载---要实现该功能需要指定下载的实体范围。像这样，指定范围发送的请求叫做范围请求（Range Request）。
5.2对一份 10 000 字节大小的资源，如果使用范围请求，可以只请求5001~10000 字节内的资源。
例子：客户端： GET /tip.jpg HTTP/1.1
HOST:www.abc.com
Range:bytes =5001-10000
服务器：HTTP/1.1 206 Partial Content
Date：....
Content-Range：bytes 5001-10000/10000
Content-Length:5000
Content-Type:image/jpeg
执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。
5001~10 000 字节---Range: bytes=5001-10000
从 5001 字节之后全部的---Range: bytes=5001-
从一开始到 3000 字节和 5000~7000 字节的多重范围---Range: bytes=-3000, 5000-7000
针对范围请求，响应会返回状态码为 206 Partial Content 的响应报文。另外，对于多重范围的范围请求，
响应会在首部字段 Content-Type 标明 multipart/byteranges 后返回响应报文。
如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的实体内容。
6.内容协商返回最合适的内容
6.1当浏览器的默认语言为英语或中文，访问相同 URI 的 Web 页面时，则会显示对应的英语版或中文版的 Web 页面。这样的机制称为内容协商（Content Negotiation）。
6.2内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language
第四章 返回结果的 HTTP 状态码
1.HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端的处理是否正常、通知出现的错误等工作。
2.状态码的类别
1XX Informational（信息性状态码） 接收的请求正在处理
2XX Success（成功状态码） 请求正常处理完毕--------------------204 No Content、206 Partial Content
3XX Redirection（重定向状态码） 需要进行附加操作以完成请求---------301 Moved Permanently、304 Not Modified、307 Temporary Redirect
4XX Client Error（客户端错误状态码） 服务器无法处理请求------400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found
5XX Server Error（服务器错误状态码） 服务器处理请求出错----500 Internal Server Error、503 Service Unavailable
3.状态码和状况的不一致---不少返回的状态码响应都是错误的，但是用户可能察觉不到这点。比如 Web 应用程序内部发生错误，状态码依然返回 200 OK，这种
情况也经常遇到。
第 五 章 与 HTTP 协作的 Web 服务器
1.一台 Web 服务器可搭建多个独立域名的 Web 网站，也可作为通信路径上的中转服务器提升传输效率。
2.用单台虚拟主机实现多个域名。
2.1HTTP/1.1 规范允许一台 HTTP 服务器搭建多个 Web 站点。
2.2即使物理层面只有一台服务器，但只要使用虚拟主机的功能，则可以假想已具有多台服务器。
2.3在相同的 IP 地址下，由于虚拟主机可以寄存多个不同主机名和域名的 Web 网站，因此在发送 HTTP 请求时，必须在 Host 首部内完整指
定主机名或域名的 URI。
3.通信数据转发程序 ：代理、网关、隧道。
3.1HTTP 通信时，除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。它们可以配合服务器工作。
3.2代理---代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时
也接收服务器返回的响应并转发给客户端。大体分类：缓存代理、透明代理
3.3网关---网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客
户端可能都不会察觉，自己的通信目标是一个网关。利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。
3.4隧道---隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。隧道可按要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。
4.保存资源的缓存。
4.1缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。
4.2缓存服务器是代理服务器的一种，并归类在缓存代理类型中。换句话说，当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。
4.3缓存的有效期限---向源服务器确认缓存资源的有效性。
4.4客户端的缓存---以Internet Explorer 程序为例，把客户端缓存称为临时网络文件（Temporary Internet File）。
5.协议
5.1FTP（File Transfer Protocol）---传输文件时使用的协议。
5.2.......
第 六 章 HTTP 首部（重要）
1.HTTP 请求报文---方法、URI、HTTP 版本、HTTP 首部字段等部分构成。
2.HTTP 首部字段结构---首部字段名: 字段值---Content-Type: text/html、Keep-Alive: timeout=15, max=100
3.HTTP 首部字段根据实际用途被分为以下 4 种类型。
3.1通用首部字段（General Header Fields）---请求报文和响应报文两方都会使用的首部。
Cache-Control 控制缓存的行为---no-cache 指令的目的是为了防止从缓存中返回过期的资源。
Connection 逐跳首部、连接的管理
Date 创建报文的日期时间
Pragma 报文指令
Trailer 报文末端的首部一览
Transfer-Encoding 指定报文主体的传输编码方式
Upgrade 升级为其他协议
Via 代理服务器的相关信息
Warning 错误通知
3.2请求首部字段（Request Header Fields）---从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
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 客户端程序的信息
3.3响应首部字段（Response Header Fields）---从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
Accept-Ranges 是否接受字节范围请求
Age 推算资源创建经过时间
ETag 资源的匹配信息
Location 令客户端重定向至指定URI
Proxy-Authenticate 代理服务器对客户端的认证信息
Retry-After 对再次发起请求的时机要求
Server HTTP服务器的安装信息
Vary 代理服务器缓存的管理信息
WWW-Authenticate 服务器对客户端的认证信息
3.4实体首部字段（Entity Header Fields）---针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
Allow 资源可支持的HTTP方法
Content-Encoding 实体主体适用的编码方式
Content-Language 实体主体的自然语言
Content-Length 实体主体的大小（单位：字节）
Content-Location 替代对应资源的URI
Content-MD5 实体主体的报文摘要
Content-Range 实体主体的位置范围
Content-Type 实体主体的媒体类型
Expires 实体主体过期的日期时间
Last-Modified 资源的最后修改日期时间
4.非 HTTP/1.1 首部字段
5.端到端（End-to-end ）首部和 逐跳（Hop-by-hop ）首部 ？？？
6.一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。
7.Set-Cookie 字段的属性
NAME=VALUE 赋予 Cookie 的名称和其值（必需项）
expires=DATE Cookie 的有效期（若不明确指定则默认为浏览器关闭前为止）
path=PATH 将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
domain=域名 作为 Cookie 适用对象的域名 （若不指定则默认为创建 Cookie的服务器的域名）
Secure 仅在 HTTPS 安全通信时才会发送 Cookie
HttpOnly 加以限制，使 Cookie 不能被 JavaScript 脚本访问
8.secure 属性
Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie。
发送 Cookie 时，指定 secure 属性的方法如下所示。
Set-Cookie: name=value; secure
以上例子仅当在 https://www.example.com/（HTTPS）安全连接的情况下才会进行 Cookie 的回收。也就是说，即使域名相同，
http://www.example.com/（HTTP）也不会发生 Cookie 回收行为。
当省略 secure 属性时，不论 HTTP 还是 HTTPS，都会对 Cookie 进行回收。
9.HttpOnly 属性
Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie。
其主要目的为防止跨站脚本攻击（Cross-sitescripting，XSS）对 Cookie 的信息窃取。
发送指定 HttpOnly 属性的 Cookie 的方法如下所示。
Set-Cookie: name=value; HttpOnly
通过上述设置，通常从 Web 页面内还可以对 Cookie 进行读取操作。
但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后的 Cookie 的内容了。因此，也就无法在 XSS 中利用 JavaScript 劫持Cookie 了。
虽然是独立的扩展功能，但 Internet Explorer 6 SP1 以上版本等当下的主流浏览器都已经支持该扩展了。另外顺带一提，该扩展并非是为了防止 XSS 而开发的。
10.DNT
首部字段 DNT 属于 HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。
首部字段 DNT 可指定的字段值如下。
0 ：同意被追踪
1 ：拒绝被追踪
由于首部字段 DNT 的功能具备有效性，所以 Web 服务器需要对 DNT做对应的支持。
11......
第 7 章 确保 Web 安全的HTTPS
1.HTTP 的缺点
1.1通信使用明文（不加密），内容可能会被窃听。
1.2不验证通信方的身份，因此有可能遭遇伪装。
1.3无法证明报文的完整性，所以有可能已遭篡改。
2.互联网上的任何角落都存在通信内容被窃听的风险。
3.数据包的解析---抓包（Packet Capture）或嗅探器（Sniffer）工具。
4.加密的对象可以有这么几个：
4.1通信的加密---HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
4.2内容的加密---由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把HTTP 报文里所含的内容进行加密处理。
为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须
引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。
5.不验证通信方的身份就可能遭遇伪装
5.1HTTP 协议中的请求和响应不会对通信方进行确认。即存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端”等类似问题。
5.2服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。
6.http协议的简单性---即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）。
7.虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。
8.无法证明报文完整性，可能已遭篡改。
8.1从某个 Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。
请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。
8.2其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。
提供文件下载服务的 Web 网站也会提供相应的以 PGP（PrettyGood Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散列值。
PGP 是用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。但用这些方法也依然无法百分百保证确认结果正确。
因为 PGP 和 MD5 本身被改写的话，用户是没有办法意识到的。为了有效防止这些弊端，有必要使用 HTTPS。SSL 提供认证和加密处理及摘要功能。
9.HTTP+ (通信)加密 + (证书)认证 + 完整性保护=HTTPS。
10.HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。
11.通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL 协议这层外壳的 HTTP。
SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。
12.相互交换密钥的公开密钥加密技术。
12.1 SSL 采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。
12.2 加密和解密同用一个密钥的方式称为共享密钥加密（Common keycrypto system），也被叫做对称密钥加密。以共享密钥方式加密时必须将密钥也发给对方。
13.使用两把密钥的公开密钥加密。
13.1 公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，
而公开密钥则可以随意发布，任何人都可以获得。
13.2使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，
不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。解密过程就是在对离散对数进行求值---就目前的技术来看是不太现实的。
14.HTTPS 采用混合加密机制---在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。
15.证明公开密钥正确性的证书。
15.1 公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。为了解决上述问题，可以使用由数字证书认证机构（CA，CertificateAuthority）和其相关机关颁发的公开密钥证书。
16.数字证书认证机构的业务流程。
首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，
然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，
以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书
上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。
16.1 此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
17.可证明组织真实性的 EV SSL 证书。
18.用以确认客户端的客户端证书。
18.1想获取证书时，用户得自行安装客户端证书。但由于客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。
另外，要让知识层次不同的用户们自行安装证书，这件事本身也充满了各种挑战。
18.2现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。例如，银行的网上银行就采用了客户端证书。
在登录网银时不仅要求用户确认输入 ID 和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。
19.由自认证机构颁发的证书称为自签名证书。
19.1如果使用 OpenSSL 这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用， 似乎没什么帮助。独立构建的认证机构叫做自认证机构，由自认证机构颁发的“无用”证书也被戏称为自签名证书。浏览器访问该服务器时，会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息。
20.HTTPS 比 HTTP 要慢 2 到 100 倍。
20.1 SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU 及内存等资源，导致处理速度变慢。---SSL 加速器这种（专用服务器）硬件来改善该问题。
21.既然 HTTPS 那么安全可靠，那为何所有的 Web 网站不一直使用HTTPS ？
其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平
摊到一台计算机上时，能够处理的请求数量必定也会随之减少。因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。
除此之外，想要节约购买证书的开销也是原因之一。要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。
证书价格可能会根据不同的认证机构略有不同。通常，一年的授权需要数万日元（现在一万日元大约折合 600人民币）。
第 8 章 确认访问用户身份的认证
1.核对的信息通常是指以下这些。
密码：只有本人才会知道的字符串信息。
动态令牌：仅限本人持有的设备内显示的一次性密码。
数字证书：仅限本人（终端）持有的信息。
生物认证：指纹和虹膜等本人的生理信息。
IC 卡等：仅限本人持有的信息。
2.HTTP 使用的认证方式。
2.1 BASIC 认证（基本认证）---Base64 编码（首部字段 Authorization）
DIGEST 认证（摘要认证）---临时质询码（随机数，nonce）、 realm
SSL 客户端认证---服务器运营者也可以自己搭建认证机构，但要维持安全运行就会产生相应的费用。
FormBase 认证（基于表单认证）
3.Session 管理及 Cookie 应用。
3.1步骤 1： 客户端把用户 ID 和密码等登录信息放入报文的实体部分，通常是以 POST 方法把请求发送给服务器。而这时，会使用 HTTPS
通信来进行 HTML 表单画面的显示和用户输入数据的发送。
步骤 2： 服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证，然后把用户的认证状态与
Session ID 绑定后记录在服务器端。
向客户端返回响应时，会在首部字段 Set-Cookie 内写入 SessionID（如 PHPSESSID=028a8c…）。
Session ID 应使用难以推测的字符串，且服务器端也需要进行有效期的管理，保证其安全性。
为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie内加上 httponly 属性。
步骤 3： 客户端接收到从服务器端发来的 Session ID 后，会将其作为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送
Cookie，所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。
4.给密码加盐（salt） 1 的方式增加额外信息，再使用散列（hash）函数计算出散列值后保存。
注：salt 其实就是由服务器随机生成的一个字符串，但是要保证长度足够长，并且是真正随机生成的。然后把它和密码字符串相连接（前后都可以）生成散列值。
第 9 章 基于 HTTP 的功能追加协议
1.HTTP 的瓶颈。
Web：为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的，但 HTTP 却无法妥善地处理好这项任务。
使用 HTTP 协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信。
1.1 一条连接上只可发送一个请求。
1.2 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
1.3 请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
1.4 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
1.5 可任意选择数据压缩格式。非强制压缩发送。
2.Ajax 的解决方法---Ajax（Asynchronous JavaScript and XML， 异 步 JavaScript 与 XML 技术）--Ajax 的核心技术是名为 XMLHttpRequest 的 API
2.1 通过 JavaScript 脚本语言的调用就能和服务器进行 HTTP 通信。借由这种手段，就能从已加载完毕的 Web 页面上发起请求，只更新局部页面。
3.Comet 的解决方法。
3.1 一旦服务器端有内容更新了，Comet 不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。
通常，服务器端接收到请求，在处理完毕后就会立即返回响应，但为了实现推送功能，Comet 会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。因此，服务器端一旦有更新，就可以立即反馈给客户端。
内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维持连接会消耗更多的资源。另外，Comet也仍未解决 HTTP 协议本身存在的问题。
4.SPDY 的目标---SPDY 的设计与功能。
4.1 陆续出现的 Ajax 和 Comet 等提高易用性的技术，一定程度上使 HTTP得到了改善，但 HTTP 协议本身的限制也令人有些束手无策。为了进行根本性的改善，
需要有一些协议层面上的改动。处于持续开发状态中的 SPDY 协议，正是为了在协议级别消除 HTTP所遭遇的瓶颈。
4.2 SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 规定通信中使用 SSL。
HTTP --- 应用层
SPDY --- 会话层
SSL --- 表示层
TCP --- 传输层
5.使用浏览器进行全双工通信的WebSocket---WebSocket，即 Web 浏览器与 Web 服务器之间全双工通信标准。
6.一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML 或图片等任意格式的数据。
7.WebSocket 协议的主要特点。
7.1 推送功能---支持由服务器向客户端推送数据的推送功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
7.2 减少通信量---只要建立起 WebSocket 连接，就希望一直保持连接状态。和 HTTP 相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应减少了。
7.2.1 为了实现 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 字段内记录使用的子协议。
握手·响应---对于之前的请求，返回状态码 101 Switching Protocols 的响应。
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Accept 的字段值是由握手请求中的 Sec-WebSocket-Key 的字段值生成的。
8.期盼已久的 HTTP/2.0。
压缩--- SPDY、Friendly
多路复用 ---SPDY
TLS 义务化--- Speed＋ Mobility
协商--- Speed＋ Mobility，Friendly
客户端拉曳（Client Pull）/服务器推送（Server Push） --- Speed＋ Mobility
流量控制--- SPDY
WebSocket -----Speed＋ Mobility
9.Web 服务器管理文件的 WebDAV。
WebDAV（Web-based Distributed Authoring and Versioning，基于万维网的分布式创作和版本控制）是一个可对 Web 服务器上的内容直接进
行文件复制、编辑等操作的分布式文件系统。它作为扩展 HTTP/1.1的协议定义在 RFC4918。
除了创建、删除文件等基本功能，它还具备文件创建者管理、文件编辑过程中禁止其他用户内容覆盖的加锁功能，以及对文件内容修改的版本控制功能。
使用 HTTP/1.1 的 PUT 方法和 DELETE 方法，就可以对 Web 服务器上的文件进行创建和删除操作。可是出于安全性及便捷性等考虑，一般不使用。
第 10 章 构建 Web 内容的技术
1.因 Java 而普及的 Servlet。
2.Servlet 的运行环境叫做 Web 容器或 Servlet 容器。
3.Servlet=Server+Applet，表示轻量服务程序。
4.JavaScript 衍生的轻量级易用 JSON。
第 11 章 Web 的攻击技术
1.以服务器为目标的主动攻击。
1.1主动攻击（active attack）是指攻击者通过直接访问 Web 应用，把攻击代码传入的攻击模式。由于该模式是直接针对服务器上的资源进行攻击，
因此攻击者需要能够访问到那些资源---SQL 注入攻击和 OS 命令注入攻击。
2.以服务器为目标的被动攻击。
2.1被动攻击（passive attack）是指利用圈套策略执行攻击代码的攻击模式。在被动攻击过程中，攻击者不直接对目标 Web 应用访
问发起攻击---跨站脚本攻击和跨站点请求伪造。
3.HTTP 首部注入攻击。
4.SQL注入攻击。
5.OS攻击。
6.XSS攻击。
7.目录遍历攻击。
