http://blog.csdn.net/sunorry?viewmode=contents有些笔记
MIME 类型是一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔：text/html, text/plain, image/jpeg, image/gif, video/quicktime, application/vnd.ms-powerpoint
用 URI 来描述 web 上的资源。URL 和 URN 是它的两种实现。前者用唯一的路径指向资源，后者用唯一的名称来指定资源。不过后者涉及现有架构部署不多。
HTTP请求，request由三个部分组成：起始字段、首部字段、主体，例如：
---------------------------------
| GET /test.html HTTP/1.0 | 起始字段
| Accept: text/* | 首部字段
---------------------------------
就是一个完整的请求。没有主体，因为GET方法不需要向服务器传递参数。
常见请求方法：GET、PUT、DELETE、POST、HEAD。其中 GET 是指从服务器端发回指定资源，POST 是指将客户端数据发给服务器端的接受程序。两者不一样的。现在我们很多时候是在借用 GET。
支持 TCP／IP 协议的应用理论上都可以访问 HTTP 服务器。例如 telnet 程序就可以模拟 web 客户端与服务器通信并建立 http 会话。
HTTP 的版本号：现在最常见是 HTTP 1.0
网关在应用中稀松平常。可是有一个重要功能没多少人意识到：打断协议。例如加速网关，HTTP-FTP网关等。可以HTTP方式请求FTP文件，网关会以FTP方式向后台服务器请求数据，封装为HTTP传回客户端。
隧道就是特定的HTTP传输信道。
常见隧道有：对SSL的HTTP封装，即HTTPS。
SSL和TSL都工作在传输层，比HTTP低一层。到达隧道起点后，封装为HTTP报文，这样可以通过只允许web流量的防火墙。抵达隧道终点后，解析为SSL报文。
客户端不将片段（比如 http://tools.ietf.org/html/rfc2616#page-22 里的#page-22）传送给服务器
近几年，短URL逐渐兴起，实现原理是这样的：服务商提供原始URL转换，生成短URL，用户访问短URL时，服务器通过HTTP301重定向到原始URL。
http://blog.csdn.net/beiyeqingteng/article/details/7706010
状态码是在响应报文的起始行中返回的。返回数字状态和可读状态。数字码便于程序进行查错处理，原因短语便于理解。 状态码的分类： 100到199之间表示信息提示。200到299之间表示成功。300到399之间表示资源被移走，须重定向。400到499之间表示客户端请求错误。500到599之间表示服务器错误。
部分常见状态码：
100 Continue。它的目的是对这样的情况进行优化：HTTP 客户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下服务器是否会接受这个实体。
200 OK 成功。请求的所有数据都在响应主体中。
401 未授权 需要输入用户名和密码 404 未找到 服务器无法找到所请求URL对应的资源
500 Internal Server Error 最常见的服务器端错误。
503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。客户端可以稍后重试。
Connection: Keep-Alive
HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成 之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。
http 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；http 1.1中默认启用Keep-Alive，如果加入"Connection: close "，才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。
HTTP 方面, 其实可以优化的点还是在围着 TCP 说事. 主要分为:
1) 并发连接 TCP.
即并行建立 TCP 连接来传送 HTTP 报文, 而不是串行. 大多数浏览器, 默认支持并行 4 个 TCP 连接. 但服务器随时可以砍掉更多的连接来保证其负载. 而且如果在窄带下, 并行往往还慢于串行.
2) 持久连接: "重用 TCP 连接, 以消除连接及关闭时延".
3) 管道化连接: "通过共享的 TCP 连接发起并发的 HTTP 请求".
4) 复用连接: "交替传送请求和响应报文".
虽然 3) 和 4) 没有看到, 但字面上就看出其区别: 3) 是在同一根 TCP 下并行 HTTP 请求, 4) 是在同一根 TCP 下串行 HTTP 请求.
盲中继的主要问题是这样的：
clients--proxy--server
本来的理想场景是：clients想要和proxy建立keepalive连接，而proxy和server之间应该是用完就断的连接。
但是proxy是盲中继，并不理解keepalive选项的含义。只是将keepalive选项转发给server。于是形成了这样的连接：
clients和proxy之间是用完即断的连接，proxy和server之间是keepalive连接。这对于clients和proxy来说都不对，proxy和server的连接不能及时断掉，会占用资源。而clients和proxy之间没有形成持久连接，导致clients下一个请求到来时，proxy随意丢弃。
web服务器可以将URI路径做映射，至动态生成内容的后端应用程序。Web服务器能够分辨动态资源和静态资源。Web服务器都提供了基本的机制来识别和映射这些资源。
应用程序执行接口提供了后端动态内容支持的机制。
HTTP服务器（如nginx）与应用程序服务器（如FastCGI）常常是分开来部署。
一直以来对web的缓存主要理解的就是，可以降低客户端到服务器端的请求数量，这样就可以更快速度的加载网页，这个理解当然没错。但是对于客户端和服务器端传输这块其实从来没考虑过距离时延的问题。
其实距离时延就是光速的问题，即便你的带宽没有压力，那么光速本身是需要时间的。然后你想想就知道了，如果你将内容缓存放在附近的机房里可以将文件传输距离从数千英里缩短为数十米。
最后注：在实际应用中,信号的传输速度会比光速低一些,因此,距离时延会更加严重。
恶意的网管可能会有意创建一些复杂的爬虫循环来陷害哪些无辜的，毫无戒备的机器人。尤其是，发布一个看起来很像普通文件，实际上确实网管应用程序的URL是很容易的。这个应用程序可以在传输中构造出包含了到同一服务器上虚构URL连接的HTML。请求这些虚构的URL时，这个邪恶的服务器就会捏造出一个带有新的虚构URL的新HTML页面来。 即使这个恶意Web服务器实际上并不包含任何文件，它也可以通过无限虚拟的Web空间将可怜的机器人带入爱丽丝漫游仙境之旅。更糟的是，每次的URL和HTML看起来都有很大的不同，机器人很难检测到环路。
100 Continue 状态码尤其让人糊涂。它的目的是对这样的情况进行优化：HTTP 客户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下服务器是否会接受这个实体。
客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用 100 Continue。