图解HTTP--笔记

1.IP 协议、TCP 协议和 DNS 服务在使用

HTTP 协议的通信过程中各自发挥了哪些作用

2.HTTP 是无状态协议

它不对之前发生过的请求和响应的状态进行管
理。 也就是说， 无法根据之前的状态进行本次的请求处理。

保留无状态协议这个特征的同时又要解决类似的矛盾问题， 于是引入
了 Cookie 技术。 Cookie 技术通过在请求和响应报文中写入 Cookie 信
息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的
首部字段信息， 通知客户端保存 Cookie。 当下次客户端再往该服务器
发送请求时， 客户端会自动在请求报文中加入 Cookie 值后发送出
去。
服务器端发现客户端发送过来的 Cookie 后， 会去检查究竟是从哪一
个客户端发来的连接请求， 然后对比服务器上的记录， 最后得到之前
的状态信息。

3.告知服务器意图的 HTTP 方法

GET ： 获取资源
GET 方法用来请求访问已被 URI 识别的资源。 指定的资源经服务器
端解析后返回响应内容。 也就是说， 如果请求的资源是文本， 那就保持原样返回； 如果是像 CGI（ Common Gateway Interface， 通用网关接口） 那样的程序， 则返回经过执行后的输出结果

POST： 传输实体主体
POST 方法用来传输实体的主体。
虽然用 GET 方法也可以传输实体的主体， 但一般不用 GET 方法进行
传输， 而是用 POST 方法。 虽说 POST 的功能与 GET 很相似， 但
POST 的主要目的并不是获取响应的主体内容

PUT： 传输文件
PUT 方法用来传输文件。 就像 FTP 协议的文件上传一样， 要求在请
求报文的主体中包含文件内容， 然后保存到请求 URI 指定的位置。
但是， 鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制， 任何人都可以上传文件 , 存在安全性问题， 因此一般的 Web 网站不使用该方法。 若配合 Web 应用程序的验证机制， 或架构设计采用REST（ REpresentational State Transfer， 表征状态转移） 标准的同类
Web 网站， 就可能会开放使用 PUT 方法。

HEAD： 获得报文首部
HEAD 方法和 GET 方法一样， 只是不返回报文主体部分。 用于确认
URI 的有效性及资源更新的日期时间等。

DELETE： 删除文件
DELETE 方法用来删除文件， 是与 PUT 相反的方法。 DELETE 方法按请求 URI 删除指定的资源。
但是， HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机
制， 所以一般的 Web 网站也不使用 DELETE 方法。 当配合 Web 应用程序的验证机制， 或遵守 REST 标准时还是有可能会开放使用的。

4.请求报文及响应报文的结构

5.通信数据转发程序 ： 代理、 网关、 隧道

代理
有多种使用方法， 按两种基准分类。 一种是是否使用缓存， 另一种是是否会修改报文。
(1)缓存代理
代理转发响应时， 缓存代理（ Caching Proxy） 会预先将资源的副本
（ 缓存） 保存在代理服务器上。当代理再次接收到对相同资源的请求时， 就可以不从源服务器那里获取资源， 而是将之前缓存的资源作为响应返回。
(2)透明代理
转发请求或响应时， 不对报文做任何加工的代理类型被称为透明代理
（ Transparent Proxy） 。 反之， 对报文内容进行加工的代理被称为非透明代理。

隧道
可按要求建立起一条与其他服务器的通信线路， 届时使用 SSL等
加密手段进行通信。 隧道的目的是确保客户端能与服务器进行安全的
通信。
隧道本身不会去解析 HTTP 请求。 也就是说， 请求保持原样中转给之
后的服务器。 隧道会在通信双方断开连接时结束。

6.HTTP 的缺点

到现在为止， 我们已了解到 HTTP 具有相当优秀和方便的一面， 然而HTTP 并非只有好的一面， 事物皆具两面性， 它也是有不足之处的。HTTP 主要有这些不足， 例举如下。
(1)通信使用明文（ 不加密） ， 内容可能会被窃听
(2)不验证通信方的身份， 因此有可能遭遇伪装
(3)无法证明报文的完整性， 所以有可能已遭篡改

这些问题不仅在 HTTP 上出现， 其他未加密的协议中也会存在这类问
题。除此之外， HTTP 本身还有很多缺点。 而且， 还有像某些特定的 Web服务器和特定的 Web 浏览器在实际应用中存在的不足（ 也可以说成是脆弱性或安全漏洞),另外,用 Java 和 PHP 等编程语言开发的
Web 应用也可能存在安全漏洞。

HTTP 加上加密处理和认证以及完整性保护后即是HTTPS
如果在 HTTP 协议通信过程中使用未经加密的明文， 比如在 Web 页
面中输入信用卡号， 如果这条通信线路遭到窃听， 那么信用卡号就暴露了。另外， 对于 HTTP 来说， 服务器也好， 客户端也好， 都是没有办法确认通信方的。 因为很有可能并不是和原本预想的通信方在实际通信。并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。为了统一解决上述这些问题， 需要在 HTTP 上再加入加密处理和认证等机制。 我们把添加了加密及认证机制的 HTTP 称为 HTTPS(HTTPSecure).