HTTP基本原理

发表于 | 分类于

网络模型

应用层，（表现层，会话层），传输层，网络层，网络接口层（链路层+物理层）

0. HTTP 的特性

HTTP 协议构建于 TCP/IP 协议之上，是一个应用层协议，默认端口号是 80 (HTTPS: 443)

HTTP 是无连接无状态的

  1. 无连接：服务器处理完客户的请求，并收到客户的应答后，即断开连接 （keep-alive :Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接 tcp连接）

  2. 无状态：对于事务处理没有记忆能力 (Cookie 客户端， Session 服务端)

长连接与短连接
短连接 : 为每一次的数据传输准备了一个传输通道，会先建立连接，然后传递数据，最后关闭连接
长连接 : 建立了一条可以连接通道，并一直保持，每一次传输数据时会复用同一条连接通道。

Connection: keep-alive 字段表示启用了长连接；

报文头里如果有 Connection: close 就意味着长连接即将关闭；

cookie

响应报文使用 Set-Cookie 字段发送“key=value”形式的 Cookie 值；

请求报文里用 Cookie 字段发送多个 Cookie 值；

为了保护 Cookie，还要给它设置有效期、作用域等属性，常用的有 Max-Age、Expires、Domain、HttpOnly 等；

1. URL 与 URI

URI : 统一资源标识符

URL : 统一资源定位符

(URN : 统一资源名称 只命名资源 而不指定如何定位资源)

URL 是 URI 的子集

2. 超文本

Hypertext ,用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本。

网页源代码 HTML 可以称之为超文本。

3. HTTP HTTPS

HTTP : 超文本传输协议，用于从网络传输超文本数据到本地浏览器的传送协议

HTTPS ： 以安全为目标的 HTTP通道。 HTTP over TLS。

  1. 建立一个安全信息通道，来保证数据传输的安全。

  2. 确认网站的真实性。

TLS : 传输安全层

使用数字签名 非对称加密 公钥加密，只有私钥才能解密。私钥加密，公钥才能解密。证书机构为 公钥提供方 提供证书

4. HTTP 请求过程

https://imwl.ml/blog....

https: 访问数组的协议
imwl.ml 服务器域名或 ip地址 DNS 服务器保存了 ip和 域名 的对应关系
blog... 数据源路径,后面没有内容时，显示设置的 默认文件

浏览器（客户端） 输入 URL ,向服务器发送一个 Request (请求), 服务器收到 Request 后，返回对应的一个 Response(响应), Response 中包含页面的源代码等内容，浏览器再进行解析，便将网页呈现出来。

客户端 → 本地DNS服务器 → 根域 → eg:com → server.com → 本地DNS服务器 → 客户端

5. Request

Request 可分为四部分

  1. Request Method (请求方式)
  2. Request URL （请求连接）
  3. Request Headers （请求头）
  4. Request Body （请求体）

5.1 Request Method

请求方式，常见有 GET , POST

GET 请求参数会直接包含在URL里， （eg:https://www.baidu.com/s?wd=Python wd 就是要搜寻的关键字）

POST 一般用于表单提交发起，数据常以 Form Data 即表单形式传输，不会体现在 URL 中。（包含在 Request Body 中）

GET 请求提交的数据最多只有1024字节。

8 bit = 1 Byte

其他请求方式

  1. HEAD
  2. PUT
  3. DELETE
  4. CONNECT
  5. OPTIONS
  6. TRACE

5.2 Request URL

请求的网址，即统一资源定位符，可以唯一确定我们想请求的资源

5.3 Request Headers

请求头， 用来说明服务器要使用的附加信息，比较重要的有Cookie,Refer,User-Agent等

  1. Accept : 请求报头域，用于指定客户端可接受的语言类型
  2. Accept-Language : 指定客户端可接受的语言类型
  3. Accept-Encoding : 指定客户端可接受的内容编码
  4. HOST : 用于指定请求资源的主机和端口号
  5. Cookie : 是网站为了辨别用户进行 Session 跟踪而储存在用户本地的数据。
  6. Referer : 用来标识这个请求是从哪个页面发出来的
  7. User-Agent : UA,特殊的字符串头，使得服务器能够识别客户使用的操作系统及版本、浏览器及版本等信息。（爬虫时可加次信息伪装成浏览器）
  8. Content-type : 互联网媒体类型，在 HTTP 协议消息中，使用它来表示具体请求中的媒体类型信息。（Application/josn ,image/gif, text/html等）

5.4 Request Body

一般承载的内容为 POST 请求中的Form Data , 而对于 GET 请求 Request Body 则为空。

6. Response

由服务端返回给客服端。Response可以分为三部分

  1. Response Status Code (响应状态码)
  2. Response Headers （响应头）
  3. Response Body （响应体）

6.1 Request Status Code

200 表示正常。 404 表示页面未找到。 500 表示服务器内部异常。

一般情况下

2开头 （请求成功）表示成功处理了请求的状态代码。

3开头 （请求被重定向）表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

4开头 （请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理。

5开头（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

6.2 Response Headers

包含了服务器对请求的应答信息

部分信息

  1. date : 标识 Response 产生的时间
  2. Last-Modified : 指定资源的最后修改时间
  3. Content-Encoding ：指定 Response 内容的编码
  4. Server : 包含了服务器的信息
  5. Content-type ： 同Request
  6. Set-Cookie : 设置Cookie, 即告诉浏览器需要将此内容放到Cookies中，下次请求携带Cookies请求。

  7. Expires : 指定 Response 的过期时间，使用它可以控制代理服务器或浏览器将内容更新到缓存中，如再次访问，直接从缓存中加载，降低服务器荷载，缩短加载时间。

  8. Transfer-Encoding: chunked ： 分段传送

  9. Content-Length: 29921 ： 文本大小，与上面互斥

6.3 Response Body

响应的正文数据都是在响应体中
（爬虫请求网页后要解析的数据就是解析响应体）

在浏览器开发工具中点击Preview,就可以看到网页源代码、json数据等，然后从中做相应内容的提取

7 缓存

缓存就在服务器-客户端之间搞监控，监控请求，并且把请求输出的内容（统称为副本）另存一份；然后，如果下一个请求是相同的URL，则直接请求保存的副本，而不是再次麻烦源服务器。

7.1 使用缓存原因

  1. 降低延迟: 速度更快，网站就显得更灵敏。
  2. 降低网络传输：副本被重复使用，大大降低了用户的带宽使用

7.2 缓存类型

  1. 浏览器缓存 ： 一般 get 方法 会被缓存下来， post　方法不会
  2. HTTP　缓存　：　见下文

HTTP　缓存

cache-control

max-age=30 # 生存时间

no_store ：不允许缓存，用于某些变化非常频繁的数据，例如秒杀页面；

no_cache：而是可以缓存，但在使用之前必须要去服务器验证是否过期，用最新的版本；

must-revalidate：缓存不过期就可以继续使用，但过期了如果还想用就必须去服务器验证。

强制缓存： 当一个文件被强制缓存后，下一次请求会直接使用本地版本，而不会真的发出去。要求浏览器将文件缓存到本地，并且设置这个文件的失效时间（或者永久有效）

协商缓存： 协商缓存启用后，第一次获取接口数据，会将数据缓存到本地，并存储下数据的摘要。第二次请求时，浏览器检查到本地有缓存，将摘要发送给服务端。服务端会检查服务端数据的摘要和浏览器发送来的是否一致。如果不一致，说明服务端数据发生了更新，服务端会回传全部数据。如果一致，说明数据没有更新，服务端不需要回传数据

条件请求
Last-modified : 最后更新时间
ETag : 资源的一个唯一标识，主要是用来解决修改时间无法准确区分文件变化的问题

强 ETag 要求资源在字节级别必须完全相符，弱 ETag 在值前有个“W/”标记，只要求资源在语义上没有变化，但内部可能会有部分发生了改变

8. 代理

HTTP 代理就是客户端和服务器通信链路中的一个中间环节，为两端提供“代理服务”；

代理处于中间层，为 HTTP 处理增加了更多的灵活性，可以实现负载均衡、安全防护、数据过滤等功能；

代理服务器需要使用字段“Via”标记自己的身份，多个代理会形成一个列表；

如果想要知道客户端的真实 IP 地址，可以使用字段“X-Forwarded-For”和“X-Real-IP”；

专门的“代理协议”可以在不改动原始报文的情况下传递客户端的真实 IP。

8.1 缓存代理

缓存代理是增加了缓存功能的代理服务，缓存源服务器的数据，分发给下游的客户端；

“Cache-Control”字段也可以控制缓存代理，常用的有“private”“s-maxage”“no-transform”等，同样必须配合“Last-modified”“ETag”等字段才能使用；

缓存代理有时候也会带来负面影响，缓存不良数据，需要及时刷新或删除。

private public

9. CDN

CDN（Content Delivery Network 或 Content Distribution Network）： 内容分发网络

CDN 的最核心原则是“就近访问”

应用了 HTTP 协议里的缓存和代理技术，代替源站响应客户端的请求。CDN 是构建在现有网络基础之上的网络，它依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

为了让用户请求的是自己的网站，而使用的是 CDN 的服务，这里会使用 CNAME 让自己的域名作为 CDN 域名的一个别名。当请求到 CDN 服务的时候，会首先由 CDN 的 DNS 服务帮助用户选择一个最优的节点，这个 DNS 服务还充当了负载均衡的作用。接下来，用户开始向 CDN 节点请求资源。如果这个时候资源已经过期或者还没有在 CDN 节点上，就会从源站读取数据，这个步骤称为CDN 的回源Í

比如源站在 s.example.com 中发布静态资源，然后在 CDN 管理后台配置了这个源站。在使用 CDN 时，服务提供方会使用另一个域名，比如说 b.example.com。然后配置将 b.example.com 用 CNAME 记录指向 CDN 的智能 DNS。这个时候，如果用户下载b.example.com/a.jpg，CDN 的智能 DNS 会帮用户选择一个最优的 IP 地址（最优的 CDN 节点）响应这次资源的请求。如果这个 CDN 节点没有 a.jpg，CDN 就会到 s.example.com 源站去下载，缓存到 CDN 节点，然后再返回给用户。

CDN 回源有 3 种情况，一种是 CDN 节点没有对应资源时主动到源站获取资源；另一种是缓存失效后，CDN 节点到源站获取资源；还有一种情况是在 CDN 管理后台或者使用开放接口主动刷新触发回源。

10. WAF

WAF 是一种 Web 应用程序防护系统（Web Application Firewall，简称 WAF），它是一种通过执行一系列针对HTTP / HTTPS的安全策略来专门为Web应用提供保护的一款产品，它是应用层面的防火墙，专门检测 HTTP 流量，是防护 Web 应用的安全技术。
WAF 通常位于 Web 服务器之前，可以阻止如 SQL 注入、跨站脚本等攻击，目前应用较多的一个开源项目是 ModSecurity，它能够完全集成进 Apache 或 Nginx。

11. 连接池

连接池就是将应用所需的连接对象放在池中，每次访问时从池中获取，使用完毕再放回池中，以达到连接复用的目的，减少创建、销毁连接过程中不必要消耗的资源

通过连接池可以极大地提高服务间的通信性能。

HTTP/2 中的多路复用，指的是在一条连接中可以同时处理多个请求，这正是解决了 HTTP 中一个连接同时只能处理一个请求的问题。

HTTP 2 .0 还是基于 TCP 连接的，而 TCP 存在队头阻塞的问题，比如某条连接突然遇到了网络重传，此时会阻塞连接。另外在一些高并发场景，一条连接难以跑满带宽，也需要创建多条连接。

所以 HTTP/2 的连接池实现有所不同，新连接的创建条件往往是依据 maxConcurrentStreams 的参数，当同时请求中的 stream 的数量超过上限时，才创建新的连接