http
第一章
- MIME（Multipurpose Internet Mail Extension）
- MIME 类型是一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔。
-
• HTML 格式的文本文档由 text/html 类型来标记。
• 普通的 ASCII 文本文档由 text/plain 类型来标记。
• JPEG 版本的图片为 image/jpeg 类型。
• GIF 格式的图片为 image/gif 类型。
• Apple 的 QuickTime 电影为 video/quicktime 类型。
• 微软的 PowerPoint 演示文件为 application/vnd.ms-powerpoint 类型
- web服务器会为所有HTTP对象数据附加一个MIME类型。
- 当Web浏览器从服务器中取回一个对象时，会去查看相关的MIME 类型，看看它是否知道应该如何处理这个对象。
- URI（Uniform Resource Identifier）：统一资源标识符；唯一标识并定位信息资源
- URL：统一资源定位符；URL 描述了一台特定服务器上某资源的特定位置。
-
大部分URL 都遵循一种标准格式，这种格式包含三个部分。
• URL 的第一部分被称为方案（scheme），说明了访问资源所使用的协议类型。这
部分通常就是HTTP 协议（http://）。
• 第二部分给出了服务器的因特网地址（比如，www.joes-hardware.com）。
• 其余部分指定了 Web 服务器上的某个资源（比如，/specials/saw-blade.gif）。
-
URN：统一资源名；作为特定内容的唯一名称使用的，与目前的资源所在地无关。通过URN，还可以用同一个名字通过多种网络访问协议来访问资源。（URN 需要一个支撑架构来解析资源的位置。而此类架构的缺乏也延缓了其被采用的进度）
-
五种常见的HTTP方法
| HTTP | 描述 | 是否包含主体 |
|---|---|---|
| GET | 从服务器向客户端发送命名资源 | 否 |
| PUT | 将来自客户端的数据存储到一个命名的服务器资源中去 | 是 |
| DELETE | 从服务器中删除命名资源 | 否 |
| POST | 将客户端数据发送到一个服务器网关应用程序 | 是 |
| HEAD | 仅发送命名资源响应中的HTTP 首部 | 否 |
| TRACE | 对可能经过代理服务器传送到服务器上去的报文进行追踪 | 否 |
| OPTIONS | 决定可以在服务器上执行哪些方法 | 否 |
- 状态码
| HTTP状态码 | 描述 |
|---|---|
| 200 | |
| 302 | |
| 404 |
- HTTP报文：纯文本
-
HTTP报文三部分：
起始行：在请求报文中用来说明要做些什么，在响应报文中说明出现了什么情况
首部字段：起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值，为了便于解析，两者之间用冒号（:）来分隔。首部以一个空行结束。
主体：包含了所有类型的数据。请求主体中包括了要发送给Web 服务器的数据；响应主体中装载了要返回给客户端的数据。主体中可以包含任意的二进制数据或文本。
- 基本的浏览器连接处理
-
步骤如下：
(a) 浏览器从URL 中解析出服务器的主机名；
(b) 浏览器将服务器的主机名转换成服务器的IP 地址；
(c) 浏览器将端口号（如果有的话）从URL 中解析出来；
(d) 浏览器建立一条与Web 服务器的TCP 连接；
(e) 浏览器向服务器发送一条HTTP 请求报文；
(f) 服务器向浏览器回送一条HTTP 响应报文；
(g) 关闭连接，浏览器显示文档。
- 协议版本
-
HTTP/1.0
1.0 是第一个得到广泛使用的HTTP 版本。HTTP/1.0 添加了版本号、各种HTTP首部、一些额外的方法，以及对多媒体对象的处理。HTTP/1.0 使得包含生动图片的Web 页面和交互式表格成为可能，而这些页面和表格促使万维网为人们广泛地接受
HTTP/1.0+
在20 世纪90 年代中叶，很多流行的Web 客户端和服务器都在飞快地向HTTP中添加各种特性，以满足快速扩张且在商业上十分成功的万维网的需要。其中很多特性，包括持久的keep-alive 连接、虚拟主机支持，以及代理连接支持都被加入到HTTP 之中，并成为非官方的事实标准
HTTP/1.1
HTTP/1.1 重点关注的是校正HTTP 设计中的结构性缺陷，明确语义，引入重要的性能优化措施，并删除一些不好的特性
HTTP-NG（又名 HTTP/2.0）
HTTP-NG 是HTTP/1.1 后继结构的原型建议，它重点关注的是性能的大幅优化，以及更强大的服务逻辑远程执行框架
- WEB的结构框架
-
• 代理
位于客户端和服务器之间的HTTP 中间实体。
• 缓存
HTTP 的仓库，使常用页面的副本可以保存在离客户端更近的地方。
• 网关
连接其他应用程序的特殊Web 服务器。通常用于将HTTP 流量转换成其他的协议（例如：http->ftp）
• 隧道
对HTTP 通信报文进行盲转发的特殊代理。HTTP 隧道的一种常见用途是通过HTTP 连接承载加密的安全套接字层（SSL，Secure Sockets Layer）流量，这样SSL 流量就可以穿过只允许Web 流量通过的防火墙了
• Agent 代理
发起自动HTTP 请求的半智能Web 客户端。（网络蜘蛛）
第二章
- URL
-
URL三部分（方案：//服务器位置/路径）
第一部分URL方案（协议），方案告知web客户端怎样访问资源。
第二部分服务器的位置，告知资源位于何处。
第三部分资源路径，说明请求等是服务器上哪个特定的本地资源。
- URL语法 ://:@:/;?#
- 相对URL转换为一个绝对URL
-
第一步找到基础URL
在资源中显示提供
封装资源的基础URL
没有基础URL（可能不完整）
解析相对引用
自动扩展URL
- 常见的方案
-
http:
https:使用ssl
mailto:指向E-mail地址
ftp:
rtsp,rtspu:
file:
news:访问特定的文章或新闻组
telnet:访问交互式业务
http报文
- 报文组成部分：对报文进行描述的起始行(start line)、包含属性的首部块(header),以及可选的、包含数据的主体部分。
- 报文的文法
-
请求报文格式：
<method> <request-URL> <version>
<headers>
<entity-body>
响应报文的格式：
<version> <status> <reason-phrase>
<headers>
<entity-body>
方法（method）：
客户端希望服务器对资源执行的动作；
请求URL（request-URL）：
命名了所请求资源，或者URL路径组件的完整URL
版本（version）：
报文所使用的HTTP版本；
状态码（status-code）:
三位数字描述请求过程中所发生的情况；
原因短语（reason-phrase）：
数字状态码的可读版本，包含行终止序列之前的所有文本
首部（header）：
名字：[ ]值CRLF;
实体的主体部分（entity-body）：
包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分；
- 常见的状态码
GET：用于请求服务器发送某个资源 HEAD：与GET类似，但服务器再响应中只返回首部。不会返回实体的主体部分。
-
在不获取资源的情况下了解资源的情况；
通过查看响应中的状态码，查看某个对象是否存在；
通过查看首部，测试资源是否被修改了。
PUT：向服务器写入文档。语义是让服务器用请求的主体部分来创建一个所请求的URL命名的新文档，若已经存在替代它。
POST：用它支持HTML的表单
TRACE：允许客户端在最终将请求发送给服务器时，查看它变成什么样子。
TRACE请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹出一条TRACE响应，并在响应主体中携带它收到的原始请求报文。
OPTION：请求web服务器告知其支持的各种功能。
DELETE：请服务器删除请求URL所指定的资源。
- 状态码
-
| 状态码 | 原因短语 | 收到请求的初始部分，请客户端继续 |
|---|---|---|
| 100~199 | 信息性状态码 | |
| 100 | Continue | 收到请求的初始部分，请客户端继续 |
| 101 | Switching Protocols | 根据客户端指定，将协议换成Update首部所列的谢毅 |
| 200~299 | 成功状态码 | |
| 200 | OK | 请求没问题，实体的主体部分包含了所请求的资源 |
| 201 | Created | 用于创建服务器对象的请求 |
| 202 | Accepted | 请求已被接受，但服务器还未对其执行任何动作 |
| 203 | Non-Authoritative Information | 实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本 |
| 204 | No Content | 响应报文中包含若干个首部和一个状态行，但没有实体的主题部分 |
| 205 | Reset Content | 告知浏览器清楚当前页面中的所有HTML表单元素 |
| 206 | Partial Content | 成功执行一部分Range（范围）请求 |
| 300~399 | 重定向状态码 | |
| 300 | Multiple Choices | 客户端请求一个实际指向多个资源的URL时会返回这个状态码 |
| 301 | Moved Permanently | 在请求的URL已被移除时使用，响应首部应包含资源现在所处的URL |
| 302 | Found | 类似301，客户端应使用Location首部给出的URL来临时定位资源 |
| 303 | See Other | 告知客户端应使用另一个URL来获取资源。主要目的允许POST请求的响应将客户端定位到某个资源上去 |
| 304 | Not Modified | 客户端可以通过所包含的请求首部，使其请求变成有条件的 |
| 305 | Use Proxy | 必须通过一个代理来访问资源 |
| 307 | Temporary Redirect | 类似301，客户端应使用Location首部给出的URl来临时定位资源 |
| 400~499 | 客户端错误状态码 | |
| 400 | Bad Request | 告知客户端发送一个错误的请求 |
| 401 | Unauthorized | 在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证 |
| 403 | Forbidden | 请求被服务器拒绝了 |
| 404 | Not Found | 服务器无法找到所请求的URL |
| 405 | Method Not Allowed | 发起的请求中带有所请求的URL不支持的方法 |
| 406 | Not Acceptable | 服务器没有与客户端可接受的URL相匹配的资源 |
| 407 | Proxy Authentication Required | 类似401，用于要求资源进行认证的代理服务器 |
| 408 | Request Timeout | 如果客户端完成请求所花的时间太长，服务器回送此状态码，并关闭连接 |
| 409 | Conflict | 请求可能在资源上引发一些冲突 |
| ··· | ··· | ··· |
| 500~599 | 服务器错误状态码 | |
| 500 | Internal Server Error | 服务器遇到一个妨碍它为请求提供服务的错误时 |
| 501 | Not Implemented | 客户端发起的请求超出服务器的能力 |
| 502 | Bad Gateway | 作为代理或网关使用的服务器从请求响应链的吓一条链路上收到一条伪响应 |
| 503 | Service Unavailable | 用来说明服务器现在无法为请求提供服务 |
| 504 | Gateway Timeout | 这里的响应来自一个网关或代理 |
| 505 | HTTP Version Not Supported | 服务器收到的请求使用了它无法或不愿意支持的谢毅版本 |
- HTTP事务的时延主要原因
-
（1）根据URI确定Web服务器的IP地址和端口号。首次通过DNS解析系统URI中的主机名转换成一个IP地址可能要花费数十秒的时间
（2）客户端会向服务器发送一个TCP连接请求，并等待服务器回送一个请求接受应答。每个TCP连接最多只有一两秒钟。数百个HTTP事务，值会叠加。
（3）建立连接，客户端会通过新建立的TCP管道发送HTTP请求。数据到达，web服务器回从TCP连接中读取请求报文，并处理。传输请求报文和处理请求报文都花时间。
（4）web服务器回送HTTP响应，需要时间。
TCP网络延时的大小取决于硬件速度、网络和服务器负载，请求和响应报文的尺寸，以及客户端和服务器之间的距离。TCP协议的技术复杂性也会对时延产生巨大影响。
- 常见的TCP相关时延
（1）TCP连接建立握手（分组）
（2）TCP慢启动拥塞控制
（3）数据聚集的Nagle算法（Nagle算法试图在发送一个分组前，将大量TCP数据绑定在一起，以提高网络效率）
（4）用于捎带确认的TCP延迟确认算法
（5）TIME_OUT时延和端口耗尽（当某个TCP端点关闭TCP连接时，会在内存中维护一个小的控制块，用来记录最近所关闭的IP地址和端口号。通常是所顾忌的最大分段使用期的两倍2MSL，以确保在这段时间内不会创建具有相同地址和端口号的新连接；高速路由器的使用，使之前状况不再可能，可以将2MSL设置较小）
966
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
