http学习2

一、HTTP缓存

01.http缓存有何控制
- Http的缓存主要利用header里的两个字段来控制：Cache-control，ETag

02.Cache-control介绍
- **Cache-control主要包含以及几个字段：**
    ```
    private:则只有客户端可以缓存
    public:客户端和代理服务器都可以缓存
    max-age:缓存的过期时间
    no-cache:需要使用对比缓存来验证缓存数据
    no-store:所有内存都不会进行缓存
    ```
- 实际上就是在这里面设置了一个缓存策略，由服务端第一次通过header下发给客户端，可以看到：
    - max-age即缓存过期的时间，则之后再次请求，如果没有超过缓存失效的时间则可以直接使用缓存。
    - no-cache:表示需要使用对比缓存来验证缓存数据，如果这个字段是打开的，则就算max-age缓存没有失效，则还是需要发起一次请求向服务端确认一下资源是否有更新，是否需要重新请求数据，至于怎么做对比缓存，就是下面要说的Etag的作用。如果服务端确认资源没有更新，则返回304，取本地缓存即可，如果有更新，则返回最新的资源。
    - no-store:这个字段打开，则不会进行缓存，也不会取缓存。
- Cache-Control
    - HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。
- 禁止进行缓存
    - no-store 指令规定不能对请求或响应的任何一部分进行缓存。
    ```html
    Cache-Control: no-store
    ```
- 强制确认缓存
    - no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效才将能使用该缓存对客户端的请求进行响应。
    ```html
    Cache-Control: no-cache
    ```
- 私有缓存和公共缓存
    - private指令规定了将资源作为私有缓存，只能被单独用户所使用，一般存储在用户浏览器中。
    ```html
    Cache-Control: private
    ```
    - public 指令规定了将资源作为公共缓存，可以被多个用户所使用，一般存储在代理服务器中。
    ```html
    Cache-Control: public
    ```
- 缓存过期机制
    - max-age指令出现在请求报文中，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。
    - max-age指令出现在响应报文中，表示缓存资源在缓存服务器中保存的时间。
    ```html
    Cache-Control: max-age=31536000
    ```
    - Expires首部字段也可以用于告知缓存服务器该资源什么时候会过期。
    ```html
    Expires: Wed, 04 Jul 2012 08:26:05 GMT
    ```
    - 在 HTTP/1.1 中，会优先处理 max-age 指令；
    - 在 HTTP/1.0 中，max-age 指令会被忽略掉。

03.ETag介绍
- ETag:即用来进行对比缓存，Etag是服务端资源的一个标识码
    - 当客户端发送第一次请求时服务端会下发当前请求资源的标识码Etag，下次再请求时，客户端则会通过header里的If-None-Match将这个标识码Etag带上，服务端将客户端传来的Etag与最新的资源Etag做对比，如果一样，则表示资源没有更新，返回304。
    - 通过Cache-control和Etag的配合来实现Http的缓存机制。
- URL 不能唯一表示资源，例如 http://www.google.com/ 有中文和英文两个资源，只有 ETag 才能对这两个资源进行唯一标识。
    ```
    ETag: "82e22293907ce725faf67773957acd12"
    ```
    - 可以将缓存资源的ETag值放入If-None-Match 首部，服务器收到该请求后，判断缓存资源的 ETag 值和资源的最新ETag值是否一致，如果一致则表示缓存资源有效，返回 304 Not Modified。
    ```
    If-None-Match: "82e22293907ce725faf67773957acd12"
    ```
    - Last-Modified首部字段也可以用于缓存验证，它包含在源服务器发送的响应报文中，指示源服务器对资源的最后修改时间。但是它是一种弱校验器，因为只能精确到一秒，所以它通常作为 ETag 的备用方案。如果响应首部字段里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 OK。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 Not Modified 响应。
    ```
    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
    If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
    ```

 04.缓存优点
- 优点
    - 缓解服务器压力；
    - 降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存在地理位置上也有可能比源服务器来得近，例如浏览器缓存。

 05.缓存实现方法
- 实现方法
    - 让代理服务器进行缓存；
    - 让客户端浏览器进行缓存。

 

二、无连接，无状态

 01.什么是无连接
- 无连接并不是说不需要连接
    - Http协议只是一个应用层协议，最终还是要靠运输层的如TCP协议向上提供的服务进行连接。
- 无连接的含义是：
    - **http约定了每次连接只处理一个请求，一次请求完成后就断开连接**，这样主要是为了缓解服务器的压力，减小连接对服务器资源的占用。我的理解是，建立连接实际上是运输层的事，面向应用层的http来说的话，它就是无连接的，因为上层对下层无感知。

02.什么是无状态
- **无状态的指：**
    - HTTP 是一种不保存状态，即无状态（stateless）协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。
- **新请求新相应**
    - 使用 HTTP 协议，每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成如此简单的。
    - 也就是说，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。
    - 也就是说，当客户端一次HTTP请求完成以后，客户端再发送一次HTTP请求，HTTP并不知道当前客户端是一个”老用户“。
- **后来出现的弊端**
    - 随着 Web 的不断发展，因无状态而导致业务处理变得棘手的情况增多了。比如，用户登录到一家购物网站，即使他跳转到该站的其他页面后，也需要能继续保持登录状态。针对这个实例，网站为了能够掌握是谁送出的请求，需要保存用户的状态。
- **Cookie解决无状态困境**
    - 每个请求之间都是独立的，对于之前的请求事务没有记忆的能力。所以就出现了像Cookie这种，用来保存一些状态的东西。
    - Cookie就相当于一个通行证，第一次访问的时候给客户端发送一个Cookie，当客户端再次来的时候，拿着Cookie(通行证)，那么服务器就知道这个是”老用户“。

 

三、常见请求方法

1.GET获取资源
- 获取资源
    - 当前网络请求中，绝大部分使用的是 GET 方法。

2.POST传输实体主体
- 传输实体主体
    - POST 主要用来传输数据，而 GET 主要用来获取资源。

3.PUT传输文件
- 上传文件
    - 由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
        ```html
        PUT /new.html HTTP/1.1
        Host: example.com
        Content-type: text/html
        Content-length: 16
        
        <p>New File</p>
        ```

4.HEAD获取报文首部
- 获取报文首部
    - 和 GET方法一样，但是不返回报文实体主体部分。
    - 主要用于确认URL的有效性以及资源更新的日期时间等。

5.DELETE删除文件
- 删除文件
    - 与 PUT 功能相反，并且同样不带验证机制。
        ```html
        DELETE /file.html HTTP/1.1
        ```

6.TRACE追踪路径
- 追踪路径
    - 服务器会将通信路径返回给客户端。
    - 发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。
    - 通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

7.OPTIONS对资源进行部分修改
- 查询支持的方法
    - 查询指定的 URL 能够支持的方法。
    - 会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。

8.CONNECT与代理服务器通信时建立隧道
- 要求在与代理服务器通信时建立隧道
    - 使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
    ```html
    CONNECT www.example.com:443 HTTP/1.1
    ```

9.PATCH对资源进行部分修改
- 对资源进行部分修改
    - PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
        ```html
        PATCH /file.txt HTTP/1.1
        Host: www.example.com
        Content-Type: application/example
        If-Match: "e0023aa4e"
        Content-Length: 100
        
        [description of changes]

 

10.GET和POST区别
- GET和POST区别
    - Get请求的参数是直接放在url后面的，而Post请求是放在请求体中的
    - Get请求参数拼接的url的长度会根据浏览器的不同实现有一定限制，而Post请求参数长度没有限制
    - Get请求方便测试，直接输入地址即可，而Post请求不方便测试，需要借助代码或者工具进行发送
- 注意误解：
    - Get传递数据上限XXX；胡说。有限制的是浏览器中的url长度，不是Http协议，移动端请求无影响。Http服务器部分有限制的设置一下即可。
    - HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。
- GET产生一个TCP数据包；POST产生两个TCP数据包。
    - 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
    - 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
    - POST需要两步，时间上消耗一定要多一点吗？看起来GET比POST更有效吗？答案是不一定的。
        - GET与POST都有自己的语义，不能随便混用。
        - 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
        - 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
   

- 有关 GET 请求的其他一些注释：
    - GET 请求可被缓存
    - GET 请求保留在浏览器历史记录中
    - GET 请求可被收藏为书签
    - GET 请求不应在处理敏感数据时使用
    - GET 请求有长度限制
    - GET 请求只应当用于取回数据

- 有关 POST 请求的其他一些注释：
    - POST 请求不会被缓存
    - POST 请求不会保留在浏览器历史记录中
    - POST 不能被收藏为书签
    - POST 请求对数据长度没有要求

.POST请求场景
- 请注意，查询字符串（名称/值对）是在 POST 请求的 HTTP 消息主体中发送的：
    ```
    POST /test/demo_form.asp HTTP/1.1
    Host: taobao.com
    name1=value1&name2=value2
    ```

 

四、Http状态码

1.关于http状态码介绍
- 如果向您的服务器发出了某项请求要求显示您网站上的某个网页（例如，当用户通过浏览器访问您的网页或在检测工具抓取该网页时），那么，您的服务器会返回 HTTP 状态代码以响应该请求。
- 一些常见的状态代码为：
    * 200 - 服务器成功返回网页
    * 404 - 请求的网页不存在
    * 503 - 服务器暂时不可用

2.关于1xx【临时响应】
- 用于表示临时响应并需要请求者执行操作才能继续的状态代码。
- 100（继续）
    * 请求者应继续进行请求。服务器返回此代码以表示，服务器已收到某项请求的第一部分，正等待接收剩余部分。
- 101（切换协议）
    * 请求者已要求服务器切换协议，服务器已确认并准备进行切换。

3.关于2xx【成功】
- 用于表示服务器已成功处理相应请求的状态代码。
- 200（成功）
    * 服务器成功处理了相应请求。通常，这表示服务器已提供了请求的网页。如果您的 robots.txt 文件显示为此状态，则表示 检测工具 已成功检索到该文件。
- 201（已创建）
    * 请求成功且服务器已创建了新的资源。
- 202（已接受）
    * 服务器已接受相应请求，但尚未对其进行处理。
- 203（非授权信息）
    * 服务器已成功处理相应请求，但返回了可能来自另一来源的信息。
- 204（无内容）
    * 服务器已成功处理相应请求，但未返回任何内容。
- 205（重置内容）
    * 服务器已成功处理相应请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。
- 206（部分内容）
    * 服务器成功处理了部分 GET 请求。

 4.关于3xx【已重定向】
- 您需要进一步操作才能完成请求。此类状态代码通常可用于重定向。 建议您针对每一请求使用重定向的次数少于五次。您可以使用网站站长工具确定 检测工具 是否会在抓取重定向网页时遇到问题。抓取下的抓取错误页列出了由于重定向错误而导致 检测工具 无法抓取的网址。
- 300（多种选择）
    * 服务器可以根据请求来执行多项操作，例如：按照请求者（用户代理）的要求来选择某项操作或者展示列表以便请求者选择其中某项操作。
- 301（永久移动）
    * 请求的网页已永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码通知 检测工具 某个网页或网站已被永久移动到新位置。
- 302（临时移动）
    * 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 检测工具 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 检测工具 某个页面或网站已被移动。
- 303（查看其他位置）
    * 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。
- 304（未修改）
    * 请求的网页自上次请求后再也没有修改过。当服务器返回此响应时，不会返回相关网页的内容。
    * 如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。服务器可以告诉 检测工具 自从上次抓取后网页没有变更，进而节省带宽和开销。
- 305（使用代理）
    * 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
- 307（临时重定向）
    * 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 检测工具 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 检测工具 某个页面或网站已被移动。

 5.关于4xx【请求错误】
- 此类状态代码表示，相应请求可能出错，已阻止了服务器对请求的处理。
- 400（错误请求）
    * 服务器不理解相应请求的语法。
- 401（未授权）
    * 请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。
- 403（已禁止）
    * 服务器正在拒绝相应请求。如果 检测工具 在尝试抓取网站的有效网页时收到此状态代码（您可在  网站站长工具中运行工具下的抓取错误页上进行查看），则可能是因为您的服务器或主机正在阻止 检测工具 进行访问。
- 404（未找到）
    * 服务器找不到请求的网页。例如，如果相应请求是针对服务器上不存在的网页进行的，那么服务器通常会返回此代码。
    * 如果您的网站上没有 robots.txt 文件，而您在  网站站长工具中的已拦截的网址页上看到此状态，那么这就是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。（该文件应当位于顶级域名上，且应当名为 robots.txt）。
    * 如果您在 检测工具 尝试抓取的网址上看到此状态，那么这表示 检测工具 追踪的可能是另一网页中的无效链接（旧链接或输入有误的链接）。
- 405（方法禁用）
    * 禁用相应请求中所指定的方法。
- 406（不接受）
    * 无法使用相应请求的内容特性来响应请求的网页。
- 407（需要代理授权）
    * 此状态代码与 401（未授权）类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
- 408（请求超时）
    * 服务器在等待请求时超时。
- 409（冲突）
    * 服务器在完成请求时遇到冲突。服务器必须在响应中包含该冲突的相关信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。
- 410（已删除）
    * 如果请求的资源已被永久删除，那么服务器会返回此响应。该代码与 404（未找到）代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已永久删除，您应使用 301 指定资源的新位置。
- 411（需要有效长度）
    * 服务器不会接受包含无效内容长度标头字段的请求。
- 412（未满足前提条件）
    * 服务器未满足请求者在请求中设置的其中一个前提条件。
- 413（请求实体过大）
    * 服务器无法处理相应请求，因为请求实体过大，已超出服务器的处理能力。
- 414（请求的 URI 过长）
    * 请求的 URI（通常为网址）过长，服务器无法进行处理。
- 415（不支持的媒体类型）
    * 相应请求的格式不受请求页面的支持。
- 416（请求范围不符合要求）
    * 如果相应请求是针对网页的无效范围进行的，那么服务器会返回此状态代码。
- 417（未满足期望值）
    * 服务器未满足“期望”请求标头字段的要求。

 6.关于5xx【服务器错误】
- 此类状态代码表示，服务器在尝试处理相应请求时发生内部错误。此类错误往往与服务器本身有关（与请求无关）。
- 500（服务器内部错误）
    * 服务器遇到错误，无法完成相应请求。
- 501（尚未实施）
    * 服务器不具备完成相应请求的功能。例如，当服务器无法识别请求方法时，可能便会返回此代码。
- 502（错误网关）
    * 服务器作为网关或代理，从上游服务器收到了无效的响应。
- 503（服务不可用）
    * 目前无法使用服务器（由于超载或进行停机维护）。通常，这只是暂时状态。
- 504（网关超时）
    * 服务器作为网关或代理，未及时从上游服务器接收请求。
- 505（HTTP 版本不受支持）
    * 服务器不支持相应请求中所用的 HTTP 协议版本。

 

五、http风险问题

01.Http存在风险
- 你知道Http存在哪些风险吗？
    - 窃听风险：Http采用明文传输数据，第三方可以获知通信内容
    - 篡改风险：第三方可以修改通信内容
    - 冒充风险：第三方可以冒充他人身份进行通信

02.解决这些风险
- 如何解决这些风险
    - SSL/TLS协议就是为了解决这些风险而设计，希望达到：
    - 所有信息加密传输，三方窃听通信内容
    - 具有校验机制，内容一旦被篡改，通信双发立刻会发现
    - 配备身份证书，防止身份被冒充
- SSL原理及运行过程
    - SSL/TLS协议基本思路是采用公钥加密法（最有名的是RSA加密算法）。大概流程是，客户端向服务器索要公钥，然后用公钥加密信息，服务器收到密文，用自己的私钥解密。
    - 为了防止公钥被篡改，把公钥放在数字证书中，证书可信则公钥可信。公钥加密计算量很大，为了提高效率，服务端和客户端都生成对话秘钥，用它加密信息，而对话秘钥是对称加密，速度非常快。而公钥用来机密对话秘钥。

 

六、Keep-Alive

01.什么是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连接就看服务器设置情况。

 02.启用Keep-Alive的优点
- 启用Keep-Alive模式肯定更高效，性能更高。因为避免了建立/释放连接的开销。

 03.判断消息内容长度大小
- Keep-Alive方式下如何判断消息内容/长度的大小？
    - Keep-Alive模式，客户端如何判断请求所得到的响应数据已经接收完成（或者说如何知道服务器已经发生完了数据）？我们已经知道 了，Keep-Alive模式发送玩数据HTTP服务器不会自动断开连接，所有不能再使用返回EOF（-1）来判断（当然你一定要这样使用也没有办法，可 以想象那效率是何等的低）！下面我介绍两种来判断方法。
- 使用消息首部字段Conent-Length
    - Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。但是如果消息中没有Conent-Length，那该如何来判断呢？又在什么情况下会没有Conent-Length呢？请继续往下看……
- 使用消息首部字段Transfer-Encoding
    - 当客户端向服务器请求一个静态页面或者一张图片时，服务器可以很清楚的知道内容大小，然后通过Content-length消息首部字段告诉客户端 需要接收多少数据。但是如果是动态页面等时，服务器是不可能预先知道内容大小，这时就可以使用Transfer-Encoding：chunk模式来传输 数据了。即如果要一边产生数据，一边发给客户端，服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。
    - chunk编码将数据分成一块一块的发生。Chunked编码将使用若干个Chunk串连而成，由一个标明长度为0 的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字 ）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF) 隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。