图解HTTP 读书笔记

一.Web基础

      Web 基础

• WWW（World Wide Web）的三种技术：HTML、HTTP、URL
• HTML（HyperText Markup Language，超文本标记语言）
• HTTP（HyperText Transfer Protocol，超文本传输协议）
• RFC（Request for Comments，征求修正意见书），互联网的设计文档。

    URL

• URI（Uniform Resource Indentifier，统一资源标识符）
• URL（Uniform Resource Locator，统一资源定位符）
• URN（Uniform Resource Name，统一资源名称），例如 urn:isbn:0-486-27557-4。

URI 包含 URL 和 URN，目前 WEB 只有 URL 比较流行，所以见到的基本都是 URL。

       使用HTTP访问Web流程

   客户端向指定的URL发送请求，通过返回来的信息加载成Web页面。

    发送请求的称为客户端，请求对象成为服务器。它们的通信是建立在HTTP通信上的。

    与其他协议的关系   

 如果你了解过计算机网络，你就会知道，HTTP并不能单独使用，它还需要其他协议的帮助才能成功传送信息。比如需要TCP/IP协议去建立链接，并传输数据。需要DNS服务去知道目标IP地址。

二.简单的HTTP协议

          客户端和服务器通过请求和响应的交换达成协议

                

        他们发送的信息也分别被称为请求报文，和响应报文。不同的报文各自拥有各种的格式。        

   HTTP报文结构

        

请求报文：

               

响应报文：  

                

      可以看到他们的首部和主体都会以空行分开。

一些请求报文方法：

GET

获取资源

当前网络请求中，绝大部分使用的是 GET 方法。

HEAD

获取报文首部

和 GET 方法一样，但是不返回报文实体主体部分。

主要用于确认 URL 的有效性以及资源更新的日期时间等。

POST

传输实体主体

POST 主要用来传输数据，而 GET 主要用来获取资源。

更多 POST 与 GET 的比较请见第八章。

PUT

上传文件

由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>

PATCH

对资源进行部分修改

PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]

DELETE

删除文件

与 PUT 功能相反，并且同样不带验证机制。

DELETE /file.html HTTP/1.1

OPTIONS

查询支持的方法

查询指定的 URL 能够支持的方法。

会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。

CONNECT

要求用隧道协议连接代理

要求在与代理服务器通信时建立隧道，使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

CONNECT www.example.com:443 HTTP/1.1

TRACE

追踪路径

服务器会将通信路径返回给客户端。

发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。

通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪），因此更不会去使用它。

响应报文的状态：

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。

状态码	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

1XX 信息

• 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

• 200 OK

• 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。

• 206 Partial Content ：表示客户端进行了范围请求。响应报文包含由 Content-Range 指定范围的实体内容。

3XX 重定向

• 301 Moved Permanently ：永久性重定向

• 302 Found ：临时性重定向

• 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。

• 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。

• 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。

• 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

4XX 客户端错误

• 400 Bad Request ：请求报文中存在语法错误。

• 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。

• 403 Forbidden ：请求被拒绝，服务器端没有必要给出拒绝的详细理由。

• 404 Not Found

5XX 服务器错误

• 500 Internal Server Error ：服务器正在执行请求时发生错误。

• 503 Service Unavilable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

HTTP首部信息

有 4 种类型的首部字段：通用首部字段、请求首部字段、响应首部字段和实体首部字段。

各种首部字段及其含义如下（不需要全记，仅供查阅）：

通用首部字段

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	控制不再转发给代理的首部字段、管理持久连接
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末端的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其他协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段

首部字段名	说明
Accept	用户代理可处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言（自然语言）
Authorization	Web 认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求资源所在服务器
If-Match	比较实体标记（ETag）
If-Modified-Since	比较资源的更新时间
If-None-Match	比较实体标记（与 If-Match 相反）
If-Range	资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since	比较资源的更新时间（与 If-Modified-Since 相反）
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中 URI 的原始获取方
TE	传输编码的优先级
User-Agent	HTTP 客户端程序的信息

响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
ETag	资源的匹配信息
Location	令客户端重定向至指定 URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP 服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段

首部字段名	说明
Allow	资源可支持的 HTTP 方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的自然语言
Content-Length	实体主体的大小
Content-Location	替代对应资源的 URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modified	资源的最后修改日期时间

     

HTTP连接的发展

    在HTTP协议的初始阶段，每进行一次HTTP通信就要断开一次TCP连接。

            

 为了解决这个问题，提出了持久连接的方法， 旨在建立一次TCP连接后进行多次请求和相应的交互

            

    因为有了持久连接，是多数请求以管线化方式发送成为可能。即同时并行发送多个请求，而不需要一个接一个的等待相应。

            

   总的来说，技术一直在朝着更短的响应速度进步。

    HTTP状态

    我们在前面就知道了 HTTP是无状态协议。它不对之前发生过的请求和相应状态进行管理。

 也就是说，无法根据之前的状态进行本次的请求处理。

     想象一个场景，一个web页面需要认证才能访问，但是由于是无状态的，所以每一次刷新界面就要重新认证一遍。这对客户的体验很不好。

      但是如果让服务器去保存每个用户的状态，对服务器的CPU及内存资源有很大的压力。

     基于上面两个问题，引入了Cookie技术。

      Coolie技术通过在请求和相应报文中写入Cookie信息来控制客户端的状态。

      

        第一次没有Cookie访问，响应报文会在首部上加入一个Set-Cookie的信息，通知客户端保存Cookie.

       

        在第二次访问，客户端就带着Cookie去访问服务器。这样服务器就能辨认出客户端是谁了。

与HTTP协作的Web服务器

        一台 Web 服务器可搭建多个独立域名的 Web 网站，也可作为通信路径上的中转服务器提升传输效率。

            HTTP/1.1允许一台HTTP服务器搭建多个Web站点。其主要是利用了虚拟主机（Vritual host）的功能。

            

    由于在一台主机上，所以IP地址相同，因此在发送HTTP请求时，必须在Host首部内完整的指定主机名或域名的URL。

确保HTTP安全的HTTPS

        HTTP三大不足之处：

• 通信使用明文，内容可能会被窃听

            

  因为TCP/IP协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。

    想要窥视的话，只需要使用抓包或嗅探器工具就可以了。例如wireshark。

   解决办法：加密处理防止被窃听。

       1.通信的加密

                HTTP本身没有加密机制，但可以通过和SSL或TLS的组合使用，加密HTTP的通信内容。

                 使用SSL建立安全通信线路后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS。

            

      2.内容的加密

                在发送信息之前先对信息进行加密，等接收方接收到后，再进行解密。

                

         但是这种方法仍有被篡改的风险，下文加以说明。

•         不验证通信方的身份，可能遭遇伪装

              HTTP 协议中的请求和响应不会对通信方进行确认。也就是说存在“服务器是否就是发送请求中 URI 真正指定的主机，返回的响应是所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。否真的返回到实际提出请求的客户端”等类似问题

                

           解决办法：

            虽然HTTP无法确定通信方，但是如果使用SSL则可以。SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。

            证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书，即可判断通信方的真实意图。

               

• 无法证明报文完整性，可能已遭篡改

   所谓完整性是指信息的准确度，若无法证明其完整性，通常也就意味着无法判断信息是否准确。

   接受的信息可能是已经被篡改过的。

   受到中间人攻击

 解决办法：散列值校验

            常用 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。

解决了上述三个问题。

我们可以说

HTTP+ 加密 + 认证 + 完整性保护 =HTTPS

下面我们具体了解一下加密方式：

     

1. 对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密的加密和解密使用同一密钥。

• 优点：运算速度快；
• 缺点：密钥容易被获取。

2. 公开密钥加密

公开密钥加密（Public-Key Encryption），也称为非对称密钥加密，使用一对密钥用于加密和解密，分别为公开密钥和私有密钥。公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

• 优点：更为安全；
• 缺点：运算速度慢；

    

3. HTTPs 采用的加密方式

HTTPS 采用的是混合加密方式，即 使用非对称密钥来传输对称密钥，然后再使用对称密钥进行内容的加密通信。

    

        但是最严格的说 ，公开加密还是存在一些问题，就是无法证明公开密钥本身就是货真价实的公开密钥。公开密钥在传输过程中被替换掉是有可能的。

使用证书

        为了解决上述问题，可以引用第三方机构，使用公开密钥证书来证明。 

    

    服务器将自己的公钥发给数字认证机构，认证机构用自己的私钥签名，并颁发证书。

    待客户端请求时，服务器就把有签名和证书的公钥发给客户端。

    客户端便可以自己验证服务器公钥是否真实。

    为了保证安全机构的公钥安全的转交给客户，所以多数浏览器开发商会事先在内部植入常用的认证机关的公开密钥。

为什么不一直使用HTTPS

    其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的 CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。因此，如果是非敏感信息则使用 HTTP 通信，只有在包含个人信息等敏感数据时，才利用 HTTPS 加密通信。

        ·