目录
一、了解web和网络基础
1.HTTP历史
1990年，针对HTML1.0草案进行了讨论，因HTML1.0中存在多处模糊部分，草案被直接废弃。
1993年，现代浏览器的祖先NCSA研发的Mosaic问世。它以inline（内联）等形式显示HTML图像，从此在世界流行开来。
1994年12月，网景通信公司发布Netscape Navigator1.0。
1995年，微软公司发布Internet Explorer1.0和2.0。
从1995年起，微软和网景公司之间爆发浏览器大战，两家公司各自对HTML做了扩展。于是导致在写HTML页面时，必须考虑两家公司的浏览器。时至今日，这个问题仍令写页面前端的工程师感到棘手。
1996年5月，HTTP/1.0标准被公布，并记载于RFC19455。
1997年1月，公布HTTP/1.1。它目前仍是主流的HTTP协议版本（现在的传输协议中仍可看到这个版本信息）。
2000年前后，网景通信公司衰落。
2004年，Mozilla基金发布Firefox浏览器，开启第二次浏览器大战。
2.TCP/IP管理
通常使用的网络是在TCP/IP协议簇的基础上运行的，而HTTP属于它的一部分。
TCP/IP协议簇按层次分为4层：应用层、传输层、网络层、链路层。
应用层：
应用层决定了向用户提供应用服务时通信的活动。包括FTP(文件传输协议)、DNS（域名系统）和HTTP。
传输层：
提供处于网络连接中的两台计算机之间的数据传输。在这层存在TCP和UDP协议。
网络层：
与对方计算机之间通过多台计算机或网络设备连接时，网络层可以在众多选项中选择一条传输线路。
链路层：
处理连接网络的硬件设备。
3.HTTP是不保存状态的协议，协议本身不保存之前一切的请求或响应报文的信息。但随着web不断发展，因无状态而导致业务处理变得棘手的情况增多。（比如用户登录到一家购物网站，即使他跳到该站其他页面后，也能继续保持登录状态）。为了实现期望的保持状态，引入了cookie技术。
二、HTTP请求报文首部
上图是HTTP请求报文结构。HTTP请求报文由报文首部、空行和报文主体构成。报文首部又分为请求行、请求首部、通用首部、实体首部和其他字段。
1.请求行
请求行由请求方法、URI和HTTP版本构成
1）请求方法
| 请求方法 | 说明 | 支持版本 |
|---|---|---|
| GET | 获取页面/文件资源 | 1.0、1.1 |
| POST | 传输实体主体 | 1.0、1.1 |
| PUT | 传输文件 | 1.0、1.1 |
| HEAD | 获取报文首部 | 1.0、1.1 |
| DELETE | 删除文件 | 1.0、1.1 |
| OPTIONS | 询问服务器支持的请求方法 | 1.1 |
| TRACE | 让服务器将之前的请求 通信环返回给客户端 | 1.1 |
| CONNECT | 要求与代理服务器通信时建立隧道协议 | 1.1 |
2）URI（统一资源标识符）
URI用字符串表示某一互联网资源。而URL（统一资源定位符）表示资源的地点。可见URL是URI的子集。
绝对URI的格式如下：
相对URI简单，比如/dir/index.htm。
对于HTTP报文首部来说，使用相对URI会简单一些。
3）HTTP版本
目前，HTTP只有两个版本。HTTP/1.0和HTTP/1.1。其中，主要以后者为主。
2.请求首部字段
请求首部字段是从客户端往服务器发送请求报文中所使用的字段，用于补充请求的附加信息。以下是一些请求首部字段格式，其中，加粗的是常见类型。
| 类型 | 内容 | 格式 |
|---|---|---|
| Accept | 用户支持的媒体类型及相对优先级 （优先级用q表示，权重值范围为0~1， 其中1最大；不指定时默认为1。） | 1)文本文件 Accept:text/html,text/plain,text/css ... Accept:application/xhtml+xml,application/xml ... 2)图片文件 Accept:image/jpeg,image/gif,image/png ... 3)视频文件 Accept:video/mpeg,video/quicktime;q=0.9 ... 4)应用程序使用的二进制文件 Accept:application/octet-stream,application/zip ... |
| Accept-Charset | 用户支持的字符集及字符集的优先顺序 （与媒体类型相同以q表示优先级） | Accept-Charset:iso-8859-5,unicode-1-1;q=0.8 |
| Accept-Encoding | 用户支持的内容编码及编码优先顺序 （与媒体类型相同以q表示优先级） | Accept-Encoding:gzip,compress,deflate |
| Accept-Language | 用户支持的语言集及语言集优先顺序 （与媒体类型相同以q表示优先级） | Accept-Language:zh-cn;q=0.7,en-us;q=0.3 |
| Authorization | 用户的认证信息 | Authorization:basic csd4cd3s43rSD== |
| Expect | 告知服务器希望出现某种特定行为 | Expect:100-continue |
| From | 告知服务器用户邮件地址 | From:info@hackr.jp |
| Host | 若多个服务器运行在一个IP， 客户端需要找到哪个服务器 | Host:www.hackr.jp |
| If-Match | 告知服务器匹配资源所用的实体标记值(ETag) ，服务器比较If-Match和自身储存的ETag， 两者一致时才会执行请求。 | If-Match:"123456" |
| If-Modified-Since | 如果在指定日期后，资源发生更新， 服务器则会接受请求 | If-Modified-Since:Thu,15 Apr 2004 00:00:00 GMT |
| Range | 只获取部分资源 | Range:bytes=5001-10000 |
| User-Agent | 创建请求的浏览器和用户代理名称等信息 | User-Agent:Mozilla/5.0(Windows NT 6.1;WOW64;rv:13.0)Gec |
3.通用首部字段（请求和响应报文都可使用）
| 类型 | 说明 | 格式 |
|---|---|---|
| Cache-Control | 控制缓存行为 | Cache-Control:private,max-age=0,no-cache 具体参数见下表 |
| Connection | 控制不再转发给代理的首部字段 管理持久连接 | Connection:不再转发的首部字段名 Connection:Keep-Alive/close |
| Date | 创建报文的日期时间 | Date:Thu,15 Apr 2004 00:00:00 GMT |
| Trailer | 实现说明报文主体后记录了哪些首部字段 | Trailer:Expires ----------------报文主体-------------------- Expires:Thu,15 Apr 2004 00:00:00 GMT |
| Transfer-Encoding | 指定报文主体的传输编码方式 | Transfer-Encoding:chunked |
| Upgrade | 升级为其他协议 | Upgrade:TLS/1.0 |
| Via | 追踪请求和响应之间的传输路径 | |
| Warning | 错误通知 |
| 指令 | 参数 | 说明 |
|---|---|---|
| no-cache | 无 | 强制向源服务器再次验证 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| max-age=[秒] | 必需 | 响应的最大Age值 |
| max-stale=[秒] | 可省略 | 接收已过期的响应 |
| min-fresh=[秒] | 必需 | 期望在指定时间内的响应仍有效 |
| no-transform | 无 | 代理不可更改媒体类型 |
| only-if-cached | 无 | 从缓存获取资源 |
| cache-extension | - | 新指令标记 |
4.实体字段（请求和响应报文都可使用）
实体字段用于补充内容的更新时间等与实体相关的信息。
| 类型 | 说明 | 格式 |
|---|---|---|
| Allow | 服务器支持的HTTP方法 | Allow:GET,HEAD |
| Content-Encoding | 服务器对实体主体的内容编码方式 | Content-Encoding:gzip |
| Content-Language | 服务器对实体主体的语言集 | Content-Language:zh-CN |
| Content-Length | 实体主体的大小（单位字节） | Content-Length：15000 |
| Content-Location | 返回的URI | Content-Location：http://www.hack.ip/index.html |
| Content-MD5 | MD5算法是对报文进行完整性检测 ，类似CRC算法 | Content-MD5：VSD6VS6V6D6DV== |
| Content-Range | 表示返回的实体主体部分范围 及整个实体大小 | Content-Range:bytes 5001-10000/10000 |
| Content-Type | 返回的媒体类型、字符集 | Content-Type:text/html;charset=UTF-8 |
| Last-Modified | URI被修改时间 | Last-Modified:Thu,15 Apr 2004 00:00:00 GMT |
5.实例
下面是访问http://hackr.jp时，请求报文的首部信息。
三、HTTP响应报文首部字段
上面是响应报文的结构。由报文首部、空行和报文主体组成。报文首部由状态行、响应首部字段、通用首部字段、实体首部字段和其他字段。
1.响应行
响应行包括HTTP版本、状态码。
1）HTTP版本
目前只有1.0和1.1版本。
2）状态码
状态码负责当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。
| 类别 | 说明 | |
|---|---|---|
| 2XX 正常处理完毕 | 200 OK | 随状态码返回的信息因请求方法 不同而发生改变 |
| 200 No Content | 返回报文中不包含实体部分 | |
| 206 Partical Content | 客户端进行范围请求，返回部分 包含指定范围的内容 | |
| 3XX 重定向 | 301 Moved Permanently | 表示请求的资源已经重新分配 了新的URI（永久性重定向）， 希望以后都更新URI |
| 302 Found | 表示请求的资源已经重新分配 了新的URI（暂时性重定向）， 希望本次使用该URI | |
| 303 See Other | 请求资源存在另一个URI，客户 端应使用GET方式定向资源 | |
| 304 Not Modified | 资源不符合请求条件 | |
| 307 Temporary Redirect | 与302类似 | |
| 4XX 客户端错误 | 400 Bad Request | 表示请求报文中出现语法错误 |
| 401 Unauthorized | 表示发送信息需要有通过 HTTP认证的认证信息 | |
| 403 Forbidden | 表示访问被服务器拒绝 | |
| 404 Not Found | 未找到请求资源 | |
| 5XX 服务器错误 | 500 Internal Server Error | 表示服务器执行时发生错误 |
| 503 Service Unavailable | 表示服务器暂时处于超负载或 维护状态，无法处理请求 |
2.响应首部字段
响应首部字段是由服务器端向客户端返回响应报文所使用的字段。
| 类型 | 说明 | 格式 |
|---|---|---|
| Accept-Ranges | 处理范围请求 | Accept-Ranges:bytes/none |
| Age | 告知客户端服务器多久 前创建的响应 | Age:600 |
| ETag | 告知客户端实体标识 | ETag:"cd88ccc4c466" |
| Location | 告知客户端另一个URI | Location:http://www.hackr.jp/index.html |
| Proxy-Authenticate | 把代理服务器需要认证 信息发送给客户端 | Proxy-Authenticate：Basic realm="Ucds sdc" |
| Retry-After | 告知客户端应该在多久 后再次发送请求 | Retry-After:120 |
| Server | 告知客户端服务器安装 的HTTP程序的信息 | Server:Apache/2.217(Unix) |
3.通用字段和实体字段
与请求通用字段、请求实体字段一样。
4.实例
下面是请求访问hhtp://hackr.jp时，返回的响应报文的首部信息。
四、HTTPS
1.HTTP的不足
HTTP主要有以下不足：
1）通信使用明文（不加密），内容可能会被窃听；
2）不验证通信方的身份，因此有可能遭遇伪装；
3）无法证明报文的完整性，有可能遭到篡改；
2.通信使用明文
由于HTTP本身不具备加密功能，所以无法做到对通信整体进行加密；同时，TCP/IP是可能被窃听的网络。针对以上两点，可以对通信加密或者对内容加密。
1）对通信加密
HTTP通过和SSL（安全套接层）组合使用，建立安全通信线路。这被称为HTTPS。
2）对内容加密
客户端对HTTP报文进行加密处理后再发送。前提是客户端和服务器同时具备加密的解密机制。
但由于该方式不同于SSL将整个通信线路加密，所以内容仍有被篡改风险。
3.不验证通信方的身份
任何人都可发起请求，所以服务器不管对方身份都会返回一个请求。
SSL不仅提供加密处理，还使用证书来确认对方。证书由可信任的第三方机构颁发，用以证明客户端和服务器是实际存在的，而伪造证书从技术角度来说异常困难。所以只有确认通信方（客户端或服务器）持有的证书，可以判断通信方的真实意图。
4.无法证明报文的完整性
从web网站下载内容，无法确定在传输过程中是否被篡改。
可使用MD5和SHA-1等散列值校验的方法来确认文件的数字签名。
参考资料：《图解HTTP》 【日】上野宣 著 人民邮电出版社
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
