目录
第1章 HTTP概述
- HTTP给每种要通过Web传输的对象都打上了名为MIME类型的数据格式标签。
- 当Web浏览器从服务器取回一个对象时，会去查看相关的MIME类型，再决定该如何去处理这个对象。
- 服务器资源名称被称为统一资源标识符（URI），它在世界范围内唯一标识并定位信息资源。
- URI有两种形式，URL和URN。
- 统一资源定位符（URL）：描述了一台特定服务器上某资源的特定位置。可以明确说明如何从一个精确、固定的位置获取资源。
- 大部分URL遵循一种标准格式，包含三个部分：
①方案（scheme）：说明访问资源所使用的协议类型，通常是HTTP协议。（http://）
②服务器的因特网地址
③指定Web服务器上的某个资源 - 统一资源名（URN）：作为特定内容的唯一名称使用，与目前的资源所在地无关。
- HTTP支持几种不同的请求命令，这些命令称为HTTP方法（HTTP method）。每条HTTP请求报文都包含一个方法。这个方法告诉服务器要执行什么动作，常见的五种HTTP方法：
①GET：从服务器向客户端发送命名资源。
②PUT：将来自客户端的数据存储到一个命名的服务器资源中去。
③DELETE：从服务器中删除命名资源。
④POST：将客户端数据发送到一个服务器网关应用程序。
⑤HEAD：仅发送命名资源响应中的HTTP首部。 - 每条HTTP响应报文返回时都会携带一个状态码，三位数字，告知客户端请求是否成功，或者是否需要采取其他动作。
- HTTP报文是由一行一行的简单字符串组成的。HTTP报文均是纯文本，而不是二进制代码。
- HTTP报文包括以下三部分：
①起始行：报文的第一行，在请求报文中用于说明要做些什么，在响应报文中说明出现了什么情况。
②首部字段：起始行后，有0个或多个首部字段。每个首部字段都包含一个名字和一个值，为了便于解析，两者之间用一个冒号分隔。首部以一个空行结束。
③主体：空行后是可选的报文主体。请求主体包括要发给WEB服务器的数据；响应主体中装载了要返回给客户端的数据。 - 起始行和首部是结构化的、文本形式的。主体则可以包含任意的二进制数据（图片、视频、音轨、软件程序等，当然也可以有文本）。
- HTTP是个应用层协议。联网的细节用的是TCP/IP协议。
- TCP/IP连接需要IP地址和端口号。URL可以是IP地址，也可以是域名（DNS解析为IP）。端口号在默认情况下为80。
- 浏览器连接处理步骤：
①从URL中解析出服务器的主机名。
②将服务器的主机名替换成服务器IP。
③将端口号从URL中解析出来（没有则是80）。
④建立与该服务器的TCP连接。
⑤浏览器向服务器发送一条HTTP请求报文
⑥服务器向浏览器回送一条HTTP响应报文
⑦关闭连接。浏览器显示。 - HTTP协议有几个版本（0.9 1.0 1.0+ 1.1 NG），HTTP应用程序要尽量强健地处理各种不同的HTTP协议变体。
第2章 URL与资源
- 多数URL的结构是：方案://服务器位置/路径
- 更准确一点的URL语法，是这个由9部分构成的通用格式：
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag> - URL不会说要完全包含这9部分，最重要的是方案（scheme）、主机（host）、路径（path）。
- 对这9个部分的总结：
①方案：访问服务器时用哪种协议。
②用户：某些方案访问资源时需要用户名（默认为匿名）。
③密码：用户名后面可能需要包含密码，中间以冒号分隔。
④主机：主机名或者IP地址。
⑤端口：服务器正在监听的端口号。（方案有默认的端口号，例如HTTP是80）
⑥路径：服务器上资源的本地名。由一个/与前面其他部分分隔开。
⑦参数：某些方案使用这个来输入参数。参数为名/值对。可以有多个，用分号分隔。
⑧查询：某些方案会用这个传递参数激活应用程序（数据库、公告板、搜索引擎等）。
⑨片段：一小片或一部分资源的名字。不会将该frag字段传送给服务器，是在客户端内部使用的。 - HTTP的路径可以分成若干段，每段都可以有自己的参数。
- 查询可以在问号后面用字符&分隔多个条目。
- 片段的作用：例如一本小说，你想看其中某一章节。服务器通常无法只传输其中一个章节，那么通过客户端处理片段可以达到这个效果。
第3章 HTTP报文
- HTTP使用术语流入（inbound）和流出（outbound）来描述事物处理（transaction）的方向。
- 所有报文都会向下游流动，所有报文的发送者都在接收者的上游。
- 起始行和首部都是由行分割的，识别行是靠回车符（13）和换行符（10）组成，这两个字符可称CRLF。
- 如下图所示，首部给出了一些和主体相关的信息。Content-Type说明主体是什么；Content-Length说明主体有多大（19个字节）。
- 所有HTTP报文均可分为两类：请求报文（request message）和响应报文（response message）。请求报文会向服务器请求一个动作，响应报文会将请求的结构返回给客户端。
- 获取一张GIF图片的请求和响应报文：
- HTTP报文各部分简述：
①方法（method）：客户端希望服务器对资源执行的动作。
②请求URL（request-URL）：命名了所请求的资源。
③版本（version）：报文使用的HTTP版本。
HTTP/<major>.<minor>
④状态码（status-code）：描述请求过程中所发生的情况。
⑤原因短语（reason-phrase）
⑥首部（header）
⑦实体的主体部分（entity-body）
- 请求报文的起始行说明了要做些什么，响应报文的起始行说明发生了什么。
- 请求报文的起始行（也称为“请求行”），包含了一个方法和一个请求URL。方法描述了服务器应该执行的操作，请求URL描述了要对哪个资源执行这个方法。同时包含HTTP的版本。
- 响应报文有状态信息和操作产生的所有结果数据。响应报文的起始行（也成为“响应行”），包含了响应报文使用的HTTP版本、数字状态码、原因短语。这几个字段均由空格分隔。
- 常用的HTTP方法
| 方法 | 描述 | 是否包含主体 |
|---|---|---|
| GET | 从服务器获取一份文档 | 否 |
| HEAD | 只从服务器获取文档的首部 | 否 |
| POST | 向服务器发送需要处理的数据 | 是 |
| PUT | 将请求的主体部分存储在服务器上 | 是 |
| TRACE | 对可能经过代理服务器传送到服务器上的报文进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行哪些方法 | 否 |
| DELETE | 从服务器上删除一份文档 | 否 |
- 并不是所有服务器均实现了上述所有7种方法。另外，除了这些方法，其他服务器可能还会实现一些自己的请求方法。称为“扩展方法”。
- 状态码分类
| 整体范围 | 已定义范围 | 分类 |
|---|---|---|
| 100~199 | 100~101 | 信息提示 |
| 200~299 | 200~206 | 成功 |
| 300~399 | 300~305 | 重定向 |
| 400~499 | 400~415 | 客户端错误 |
| 500~599 | 500~505 | 服务器错误 |
- 100（continue）：说明收到了请求的初始部分，请客户端继续。
- 客户端发送一个携带值为100 Countinue的Expect请求首部，意味着客户端在发送实体前等待100 Continue响应。这是一种优化，客户端在避免向服务器发送一个大实体时，才使用。
- 101（Switching Protocols）：说明服务器正在根据客户端的指定，将协议切换成Update首部所列的协议。
- 200（OK）：请求没问题，实体的主体部分包含了所请求的资源。
- 201（Created）：用于创建服务器对象的请求的响应（例如PUT）。实体主体部分包含各种引用了已创建的资源的URL。
- 202（Accepted）：请求已被接受，但服务器还未对其执行任何动作，无法保证服务器会完成这个请求。
- 203（Non-Authoritative Information）：实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。
- 204（No Content）：响应报文有状态行和首部，但没有实体的主体部分。
- 205（Reset Content）：告知浏览器清除当前页面中的所有HTML表单元素。
- 206（Partial Content）：成功执行了一个部分或Range（范围）请求。
- 重定向状态码要么告知客户端使用替代位置来访问他们所要访问的资源，要么提供一个替代的响应而不是资源的内容。
- 资源被移动的情况下，发送一个重定向状态码和一个可选的Location首部告知客户端资源已被移动，并且可以在哪里找到。
- 300（Multiple Choices）：客户端请求一个实际指向多个资源的URL时会返回这个状态码。
- 301（Moved Permanently）：请求的URL已经被移除，响应中Location首部包含资源现所处的URL。
- 302（Found）：与301类似，但是客户端应该用Location首部的URL来临时定位资源，将来的请求仍用老的URL。
- 303（See Other）：告知客户端应该用另一个URL来获取资源，新URL位于Location首部，允许POST请求的响应将客户端定向到某个资源上去。
- 304（Not Modified）：客户端可以通过所包含的请求首部，使其变成有条件的。
- 305（Use Proxy）：说明必须通过一个代理来访问资源，代理位置由Location首部给出。
- 306（未使用）
- 307（Temporary Redirect）：和302一样。
- 400（Bad Request）：用于告知客户端它发送了一个错误的请求。
- 401（Unauthorized）：与适当的首部一起返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。
- 402（Payment Required）：保留状态码，未来之用。
- 403（Forbidden）：说明请求被访问权拒绝。拒绝原因可能在实体的主体部分。
- 404（Not Found）：服务器无法找到所请求的URL。
- 405（Method Not Allowed）：发起请求中带有所请求的URL不支持的方法。响应中有Allow首部，告知客户端对所请求的资源可以用哪些方法。
- 406（Not Acceptable）：客户端可以通过参数说明它们接受什么类型的实体，服务器没有和客户端可接受的URL相匹配的资源时用此代码。
- 407（Proxy Authentication Required）：和401相似，但用于要求对资源进行认证的代理服务器。
- 408（Request Timeout）：如果完成请求所花时间太长，服务器可以返回此状态码。
- 409（Confict）：说明请求可能在资源上引发的一些冲突。
- 410（Gone）：与404类似，只是服务器之前有过此资源。
- 411（Length Required）：服务器要求在请求报文中包含Content-Length首部。
- 412（Precondition Failed）：客户端发起了条件请求，且其中一个条件失败了。
- 413（Request Entity Too Large）：实体主体部分过大。
- 414（Request URI Too Long）：URL比服务器能处理的长。
- 415（Unsupport Media Type）：无法理解或无法支持客户端所发实体的内容类型。
- 416（Requested Range Not Satisfiable）：请求报文请求的是指定资源的某个范围，而此范围无效或无法满足。
- 417（Expectation Failed）：请求的Expect请求首部包含一个期望，但服务器无法满足此期望。
- 500（Internal Server Error）：服务器遇到一个妨碍它为请求提供服务的错误。
- 501（Not Implemented）：客户端发起的请求超出服务器的能力范围。
- 502（Bad Gateway）：作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应。
- 503（Service Unavailable）：说明服务器现在无法为请求提供服务，将来可以。
- 504（Gateway Timeout）：与408相似。
- 505（HTTP Version Not Support）：服务器收到的请求使用了它无法或不愿意支持的协议版本。
- 首部分类：
①通用首部：可以出现在请求报文，也可以出现在响应报文。
Connection：允许客户端和服务器指定与请求/响应连接有关的选项。
Date：说明报文是什么时间创建的
②请求首部：提供更多有关请求信息。
Host、Client-IP、From、Referer、UA-OS、UA-CPU、User-Agent……
③响应首部：提供更多有关响应信息。
Age、Public、Server……
④实体首部：描述主体的长度和内容，或者资源自身。
Location、Allow、Content-Type、Content-Length……
⑤扩展首部：规范中没有定义的新首部。 - 可以将长的首部行分为多行，多出的行每行前至少要有一个空格或制表符。
- GET方法通常用于请求服务器发送某个资源。HEAD方法与GET类似，但只返回首部，不返回主体；允许客户端在未获得实际资源的情况下，对资源的首部进行检查：
①不获取资源的情况下了解资源情况（判断类型）
②通过看响应中的状态码，看看某个对象是否存在
③通过查看首部，测试资源是否被修改了 - PUT方法会向服务器写入文档。PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，如果那个URL已存在，就用这个主体来替代它。
- 由于PUT允许用户对内容进行修改，因此多数WEB服务器都要求在执行PUT之前，用密码登陆。
- 一个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE请求会在行程最后一站的服务器弹回一条TRACE响应，响应中包含该服务器收到的请求报文。
- DELETE方法是请求服务器删除请求URL所指定的资源。但是，HTTP规范允许服务器在不通知客户端的情况下撤销请求。
第4章 连接管理
- HTTP和HTTPS网络协议栈：
- HTTP事务的时延：与TCP建立连接、传输报文的时间相比，事务处理时间可能是很短的。除非客户端或服务器超载，或正在处理复杂的动态资源，否则HTTP时延就是TCP网络时延造成的。
- HTTP事务时延的主要原因：
①客户端首先需要根据URI确定WEB服务器的IP地址和端口号。DNS解析（如果没有缓存）可能需要数十秒的时间。
②客户端会向服务器发送一条TCP连接请求，并等待服务器回送一个请求接受应答。每条TCP连接都会有连接建立时延，如果有数百个HTTP事务的话，时延会变大。
③一旦建立连接，客户端会通过TCP管道来发送HTTP请求。数据到达时，WEB服务器会从TCP连接中读取请求报文，并对其进行处理（需要一定时间）。
④WEB服务器会回送HTTP响应，也需要花费时间。 - TCP造成的时延：
①TCP连接建立握手
②TCP慢启动拥塞控制
③数据聚集的Nagle算法
④用于捎带确认的TCP延迟确认算法
⑤TIME_WAIT时延和端口耗尽 - 如果通过三次握手建立了一个TCP连接，却只传输很少的数据就断开，那么一个HTTP事务可能会在TCP连接建立上花费50%或以上的时间。可以通过重用现存连接来克服这个缺点。
- 有几种现存和新兴的方法可以提高HTTP连接性能：
并行连接：通过多条TCP连接发起并发的HTTP请求。
持久连接：重用TCP连接，以消除连接及关闭时延。
管道化连接：通过共享的TCP连接发起并发的HTTP请求。
复用的连接：交替传送的请求和响应报文。
- 浏览器可以先完整地请求原始的HTML页面，然后请求第一个嵌入对象，然后请求第二个嵌入对象等。但这样太慢了。HTTP允许客户端打开多条连接，并行执行多个HTTP事物，因此可以并行加载这些对象。（当网络带宽不足时，这种做法不一定能提高速度）
- 一个Web页面上大部分内嵌图片通常都来自同一个Web站点，且相当一部分指向其他对象的超链接都指向同一站点。因此，初始化了对某服务器HTTP请求的应用程序可能会在不久的将来对该服务器发起更多请求。这种性质称为站点本地性（site locality）。
- HTTP/1.1允许HTTP设备在事务处理结束后将TCP连接保持在打开状态，以便未来的HTTP请求重用现存的连接。这种连接称为“持久连接”。持久连接会在不同的事务之间保持打开状态，直到客户端或服务器决定将其关闭为止。
- keep-alive连接，是早期实验型的持久连接，存在一些问题，但很多客户端和服务器仍然在使用这些早期的keep-alive连接。
- keep-alive通过在Connection:Keep-Alive首部请求一条连接保持打开。如果服务器同意保持连接，响应中也要有一样的首部。
- HTTP/1.1允许在持久连接上可选地使用请求管道，这是在keep-alive连接上的进一步性能优化。在响应到达之前，可以将多条请求放入队列。
第5章 Web服务器
- 这一章的知识可能有点老，所以笔记不多。
- Web服务器请求的步骤：
①建立连接：接受一个客户端连接；或者不希望和该客户端连接，关闭该连接。
②接收请求：从网络中读取一条HTTP请求报文。
③处理请求：对请求报文进行解释，并采取行动。
④访问资源：对请求报文进行解释，并采取行动。
⑤构建响应：创建带有正确首部的HTTP响应报文。
⑥发送响应：将响应回送给客户端。
⑦记录事务处理过程：将与已完成事务有关的内容记录在一个日志文件中。
- Web服务器可以随意拒绝或关闭任意一条连接。
第6章 代理
- 单个客户端专用的代理称为私有代理，众多客户端共享的代理称为公共代理。
- 代理连接的是两个或多个使用相同协议的应用程序；网关连接的则是两个或多个使用不同协议的端点。
- 代理可以改善安全性，提高性能，节省费用。它可以看到并接触到所有流过的HTTP流量，可以监视并对其进行修改，实现很多有用的增值Web服务。
- 可以实现这类功能：儿童过滤器、文档访问控制、安全防火墙、Web缓存、反向代理、内容路由器、转码器等。
第7章 缓存
- Web缓存是可以自动保存常见文档副本的HTTP设备。
- 使用Web缓存优点：
①减少了冗余的数据传输
②缓解了网络瓶颈问题，不需要更多的带宽就能更快地加载页面。
③降低了对原始服务器的要求，服务器可以更快地响应，避免过载。
④降低了距离时延。 - 可以用已有的副本为某些到达缓存的请求提供服务，称为“缓存命中”。
- 其他一些到达缓存的请求可能会由于没有副本可用，而被转发给原始服务器，这称为“缓存未命中”。
- 原始服务器的内容可能会发生变化，所以缓存要不时检查，看它们保存的副本是否服务器上的最新版本。这称为“HTTP再验证”。
- 缓存进行再验证时，会向原始服务器发送一个小的再验证请求。如果内容没变化，原始服务器会响应304 Not Modified。这叫做再验证命中或缓慢命中。
- 字节命中率表示的是缓存提供的字节在传输的所有字节中所占的比例。
- HTTP不太能判断是通过原始服务器还是从缓存得到，响应码都是200 OK。客户端可以通过Date首部，如果Date首部的时间比请求时间早，可以认为这是一条缓存的响应。
- 代理缓存层次化：较小缓存中未命中的请求会被导向较大的父缓存。在靠近客户端的地方使用小型廉价缓存，更高层次中，逐步采用更大、功能更强的缓存来装载多用户共享的文档。
- 在层次结构很深的情况下，请求可能要穿过很长的缓存，但每个拦截代理都会添加一些性能损耗，当代理链路变得很长的时候，这种性能损耗会变得非常明显。
- 对一条HTTP GET报文的基本缓存处理过程包括7个步骤：
①接收：缓存从网络中读取抵达的请求报文。
②解析：缓存对报文进行解析，提取URL和各种首部。
③查询：缓存查看本地是否有副本可用，没有的话就去获取并且存在本地。
④新鲜度检测：缓存查看已缓存的副本是否足够新鲜，如果不是就询问服务器是否有任何更新。
HTTP通过缓存将服务器文档的副本保留一段时间，这段时间里认为文档是“新鲜的”。但一旦时间过长，就认为过时了，需要向服务器再次确认。
⑤创建响应：缓存会用新的首部和已缓存的主体来构建一条响应报文。
为了让响应看起来就是原始服务器一样，缓存将已缓存的服务器响应首部作为响应首部起点，然后对这些基础首部进行修改和扩充。
⑥发送：缓存通过网络将响应发回给客户端。
⑦日志：缓存可选地创建一个日志文件条目来描述这个事务。 - HTTP有一些机制让服务器在不记住那些缓存有它的副本的情况下，去保持已缓存数据与服务器数据之间的一致。这些简单的机制是文档过期和服务器再验证。
①文档过期：原始服务器向每个文档添加一个“过期日期”。过期之前，可以随意使用这些副本，无需找服务器。
②服务器再验证：过期的文档，说不定还是没有变化，缓存需询问服务器。如果发生了变化，会获取一份新的文档副本；如果没有变化，则获取新的首部，包括一个信的过期日期。
第8章 集成点：网关、隧道及中继
- 网关可以作为某种翻译器使用，它抽象出了一种能够到达资源的方法。应用程序可以请求网关来处理某条请求，网关可以提供一条响应。网关可以向数据库发送查询语句，或者生成动态的内容，就像一个门一样：进去一条请求，出来一个响应。
- 三个WEB网关实例
- 应用程序服务器：
①收到客户端A请求，根据URI将其通过API发送给一个数码相机应用程序。将得到的照片绑定到一条HTTP响应报文中，再回送给客户端，在客户端的浏览器中显示。
②客户端B的URI请求的是一个电子商务应用程序。通过服务器网关的API发送给电子商务软件，结果会被回送给浏览器。 - 请求需要使用网关的资源时，服务器会请辅助应用程序来处理请求。服务器会把请求传送给辅助应用程序，然后辅助应用程序会向服务器返回一条响应或响应数据，服务器再把该响应转发给客户端。
- 服务器和网关是相互独立的应用程序。
- CGI（Common Gateway Interface，通用网关接口）：第一个、广泛应用的服务器扩展。CGI应用程序是独立于服务器的。
- Web隧道允许用户通过HTTP连接发送非HTTP流量，可以在HTTP上捎带其他协议的数据。
- 最初开发Web隧道的目的是用于传输加密的SSL流量。
第9章 Web机器人
- Web机器人是能够在无需人类干预的情况下自动进行一系列Web事务处理的软件程序。
- 很多机器人会从一个Web站点逛到另一个Web站点，获取内容，跟踪超链，并对它们找到的数据进行处理。（例如“爬虫”）
- 爬虫：会递归地对各种信息性Web站点进行遍历，获取一个Web界面，然后获取那个页面指向的所有Web页面，然后是那些页面指向的所有Web页面，以此类推。使用爬虫在Web上游荡，并把它们碰到的文档全部拉回来处理。
- 爬虫开始访问的URL初始集合被称为根集（root set）。
- 爬虫时要避免环路的出现，也就是机器人要记录它们到过什么地方。
第10章 HTTP-NG
- HTTP至少存在4个方面的问题：
①复杂性：HTTP相当复杂，而且其特性之间是相互依存的。
②可扩展性：HTTP很难实现递增式扩展。
③性能：HTTP中有些部分效率不高。
④传输依赖性：HTTP依赖TCP/IP网络协议栈设计。应该为替代协议栈提供更多支持，方便应用与嵌入式和无线应用程序之中。 - HTTP-NG将功能都分散到各层之中去实现：
- 报文传输：报文传输层为报文传输提供一个API，无论底层实际采用的是什么网络协议栈都可以使用。
第11章 客户端识别与cookie机制
- 现代的Web站点希望能够提供个性化的接触，因此需要对连接的另一端的用户有更多的连接。个性化诸如：个性化的问候、有的放矢的推荐、管理信息的存档、记录会话。
- 承载用户相关信息的HTTP首部：
首部名称 首部类型 描述 From 请求 用户的E-mail地址 User-Agent 请求 用户的浏览器软件 Referer 请求 用户是从这个页面上依照链接跳转过来的 Authorization 请求 用户名和密码 Client-IP 扩展（请求） 客户端的IP地址 X-Forwarded-For 扩展（请求） 客户端的IP地址 Cookie 扩展（请求） 服务器产生的ID标签 -
使用客户端IP地址来识别用户存在很多缺点，诸如：动态IP，一个IP有多个用户，NAT转换等等。
- 要求用户通过用户名和密码进行认证，显式地询问用户是谁，不再使用IP。
- cookie是当前识别用户，实现持久会话的最好方式。
- 可以将其分为两类：会话cookie和持久cookie
①会话cookie：一种临时cookie，记录了用户访问站点时的设置和偏好，退出浏览器时cookie便被删除。
②持久cookie：存储在硬盘上，退出浏览器、重启计算机它们都还会存在。用于维护某个用户会周期性访问的站点的配置文件或登录名。 - 服务器通过Set-Cookie或Set-Cookie2的HTTP响应首部，将cookie放到客户端。
- cookie中可以包含任意信息，是一个name=value的表，通常只包含一个服务器为了进行跟踪而产生的独特的识别码。
- cookie的基本思想就是让浏览器积累一组服务器特有的信息，每次访问服务器时都将这些信息提供给它。
第12章 基本认证机制
- HTTP提供了一个原生的质询/响应（challenge/response）框架，简化了对用户的认证过程。
- 质询/响应框架：
- HTTP基本认证将用户名和密码（由冒号分隔）打包在一起，用Base-4编码方式对其进行编码。
- 基本认证并不安全，只能用于防止非恶意用户无意间进行的访问。或可以将其与SSL等加密技术配合使用。
第13章 摘要认证
- 摘要认证与基本认证兼容，但更为安全。摘要认证并不是最安全的协议。
- 摘要认证进行了如下改进：
①永远不会以明文方式在网络上发送密码。
②可以防止恶意用户捕获并重放认证的握手过程。
③可以有选择地防止对报文内容的篡改。
④防范其他几种常见的攻击方式。 - 客户端不会发送密码，而是发送一个“指纹”或密码的“摘要”，这是密码的不可逆扰码。客户端和服务器都知道这个密码，因此可以通过摘要验证是否与密码相匹配。
- 摘要是一种单向函数，主要用于将无限的输入值转为有限的浓缩输出值，常见的有MD5函数。（其实就类似于哈希）
- 即使不知道密码，恶意用户也可以通过获取摘要，并重放给服务器，因为摘要和密码一样好用。
- 为解决这种重放攻击，服务器可以向客户端发送一个称为随机数的特殊令牌，这个数会经常变换，客户端在计算摘要前要把这个随机数附加到密码上去。
第14章 安全HTTP
- HTTPS是最流行的HTTP安全形式，由网景公司首创，所有主要的浏览器和服务器都支持此协议。
- 使用HTTPS时，所有的HTTP请求和响应数据发送到网络之前，均要进行加密。大部分编码解码工作都是在SSL库中完成的，因此Web客户端和服务器无需过多地修改其协议处理逻辑。
- 除了加密报文之外，还可以用加密系统对报文进行签名（sign），说明是谁编写的报文，同时证明报文未被篡改过。这种技术称为数字签名（digital signing）。
- 只有作者才有私有密钥，所以只有作者才能计算出校验和。如果有恶意攻击者在报文传输过程篡改了报文，校验和就不匹配了，因为校验和需要私有密钥才能产生，所以攻击者无法为篡改过的报文伪造正确的校验码。
- 数字证书中包含一组信息，这些信息是由一个官方的“证书颁发机构”以数字方式签发的。常见内容有：对象的名称（人、服务器、组织等）、过期时间、证书发布者（由谁为证书担保）、来自证书发布者的数字签名、对象的公开密钥。
- 通过HTTPS建立了一个安全的Web事务后，现代的浏览器都会自动获取所连接服务器的数字证书。如果服务器没有证书，安全连接就好失败。收到证书会对签名颁发机构进行检查，如果该机构是个权威的公共签名机构，浏览器就知道已经公开的密钥，可以验证签名。如果不知名的签名颁发机构，会弹窗提示用户是否信任这个签名颁发者。
第15章 实体和编码
- HTTP/1.1版定义了以下几个基本字体首部字段：
①Content-Type：实体中所承载对象的类型。
②Content-Length：所传送实体主体的长度或大小。
③Content-Language：与所传送对象最相配的人类语言。
④Content-Encoding：对象数据所做的任意变换（比如压缩）。
⑤Content-Location：一个备用位置，请求时可通过它获得对象。
⑥Content-Range：如果这是部分实体，这个首部说明它是整体的哪个部分。
⑦Content-MD5：实体主体内容的校验和。
⑧Last-Modified：所传输内容在服务器上创建或最后修改的日期时间。
⑨Expires：实体数据将要失效的日期时间。
⑩Allow：该资源所允许的各种请求方法，例如GET和HEAD这些。
⑪ETag：这份文档特定实例的唯一验证码。（没有正式定义为实体首部）
⑫Cache-Control：指出应该如何缓存该文档。（没有正式定义为实体首部） - 实体主体中就是原始数据，其他任何描述性信息都包含在首部中，要靠实体首部来描述数据的意义。
- Content-Length指示报文中实体主体的字节大小，该大小是包含了所有内容编码的。（也就是说如果有压缩是压缩后的大小，而不是原始大小）
- Content-Type首部字段说明实体主体的MIME类型。MIME类型是标准化的名字，用来说明实体的基本媒体类型。
- MIME类型由一个主媒体类型，后面跟一条斜线以及一个子类型组成，子类型用于进一步描述媒体类型。
例如：text/html（html文档）、text/plain（纯文本文档）、image/gif、image/jpeg、audio/x-wav、model/vrml（三维的VRML模型）、application/vnd.ms-powerpoint（PPT）、multipart/byteranges（有若干个部分，每个部分都包含了完整文档中不同的字节范围）、message/http（完整的HTTP报文）
第16章 国际化
- 网站国际化要注意两个主要问题：字符集编码（character set encoding）和语言标记（language tag）。
- 客户端发送Accept-Charset首部和Accept-Language首部，告知服务器它理解哪些字符集编码算法和语言以及其中的优先顺序。
- HTTP字符集的值说明如何把实体内容的二进制码转换为特定字母表中的字符。
- 下面的Content-Type首部告知接收者，传输的内容是一份HTML文件，用charset参数告知接收者使用iso-8859-6阿拉伯字符集的解码算法把实体中的二进制码转换为字符：
Content-Type: text/html; charset=iso-8859-6
第17章 内容协商与转码
- HTTP提供了内容协商方法，通过这些方法，单一的URL就可以代表不同的资源（例如同一个网站页面的法语版和英语版）。这些不同的版本称为变体。
- 内容协商技术：
| 技术 | 工作原理 | 优点 | 缺点 |
|---|---|---|---|
| 客户端驱动 | 客户端发起请求，服务器发送可选项的列表，客户端选择。 | 在服务器端的实现最容易。客户端可以选择最合适的内容 | 增加了时延，为了获得正确的内容，至少要发送两次请求。 |
| 服务器驱动 | 服务器检查客户端的请求首部集，并决定提供哪个版本的页面。 | 比客户端驱动的协商方式要快。 | 如果结论不是很明确（比如首部集不匹配），服务器要做猜测 |
| 透明 | 某个中间设备（通常是缓存代理）代表客户端进行请求协商 | 免除了Web服务器的协商开销，比客户端驱动的协商要快 | 还没有正式的规范 |
- HTTP协议中定义了质量值，允许客户端为每种偏好类别列出多种选项，并为每种偏好选项关联一个优先次序。q值的范围从0.0~1.0（从优先级低到高。）下示客户端无论如何不想收到法语和土耳其语，最愿意收到法语。
Accept-Language：en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0
2636
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
