初识HTTP协议 | 青训营笔记

富鑫伟
67 阅读17分钟

这是我参与第五届青训营笔记创作活动的第1天，希望各位大佬多多关照，对HTTP的部分进行了笔记。

一、引言：地址栏搜索

当我们从浏览器地址栏输入字符串后，经过了什么过程使得我们可以访问一个页面呢？

  • 首先，地址栏输入字符串

  • 浏览器对输入信息进行处理

    • 比如输入toutiao.com，浏览器会判断我们要访问www.toutiao.com的地址；输入今日头条，浏览器会识别出我们要使用浏览器默认的搜索功能

  • 处理之后，浏览器获得了完整的请求地址，向浏览器发送真实请求，经过网络到达服务器，服务器处理请求，经过网络传给浏览器响应，在经过渲染，就出现我们看到的界面了。

什么是HTTP呢？

二、什么是HTTP

  • HTTP（Hyper Text Transfer Protocol），超文本传输协议，超文本可以承载多种体裁：

    • 常见的HTML、CSS、JavaScript的内容
    • 与Server通信的一些API的传输
    • 是应用层协议，底层以TCP作为传输层协议

  • 请求和响应：每个HTTP协议都会分为请求和响应两个部分，并且语义比较简单

  • 简单可扩展：可以在Header中自定义扩展，只要Client和Server能够互相理解即可。

  • 无状态：没有记忆能力，每个请求都是独立的，当前请求并不知道上一请求的内容，但我们使用中通常会想办法让它带上一点状态信息。

三、协议分析

HTTP协议的目的就是为了解决Client和Server的通信

1. 历史

  1. HTTP/0.9，单行协议：
  • 请求：只有“GET+目标地址”这么一行
  • 响应：只有HTML文档
  1. HTTP/1.0，构建可扩展性：
  • 增加了Header
  • 有了状态码
  • 支持多种文档类型（CSS、JS等）……
  1. HTTP/1.1，标准化协议： 由于底层是TCP，为了更好表现TCP连接过程
  • 链接复用
  • 缓存
  • 内容协商……
  • 目前为止使用最久的版本，97年至今
  1. HTTP/2，更优异的表现： 让HTTP传输更加快速、更加稳定
  • 二进制协议
  • 压缩header
  • 服务器推送……
  1. HTTP/3尚在草案

2. 报文，以HTTP/1.1为例

Requests和Responses有一部分语义相同，有一部分是独自的，都有Header和实体Body，不同之处在与Requests中要指明Method，也就是请求的类型，而Responses中则要指明请求的状态码，来表示请求的结果

  • Method

    • Safe（安全的）：不会修改服务器的数据的方法

      • GET HEAD OPTIONS

    • Idempotent（幂等）：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的

      • 所有safe的方法都是Idempotent的
      • GET HEAD OPTIONS PUT DELETE
类型说明
GET请求一个指定资源的表示形式，使用GET的请求应该只被用于获取数据
POST用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用
PUT用请求有效载荷替换目标资源的所有当前表示
DELETE删除指定的资源
HEAD请求一个与GET请求的响应相同的响应，但没有响应体
CONNECT建立一个到由目标资源标识的服务器的隧道
OPTIONS用于描述目标资源的通信选项
TRACE沿着到目标资源的路径执行一个消息环回测试
PATCH用于对资源应用部分修改
  • 状态码

常见的HTTP状态有以下五类：

  • 1** 信息响应：表示请求已接收，继续处理

  • 2** 成功响应：表示请求已被成功接收、理解、接受

  • 3** 重定向：要完成请求必须进行更进一步的操作

  • 4** 客户端错误：请求有语法错误或请求无法实现

  • 5** 服务器错误：服务器未能实现合法的请求

  • 典型的状态码

    • 200 OK - 客户端请求成功
    • 301 - 资源（网页等）被永久转移到其它URL
    • 302 - 临时跳转
    • 401 Unauthorized - 请求未经授权
    • 404 - 请求资源不存在，可能是输入了错误的URL
    • 500 - 服务器内部发生了不可预期的错误
    • 504 Gateway Timeout - 网关或者代理的服务器无法在规定的时间内获得想要的响应

3. RESTful API

  • 一种API设计风格；REST - Representational State Transfer（表现层状态转化）

    • 每一个URI代表一种资源；
    • 客户端和服务器之间，传递这种资源的某种表现层；
    • 客户端通过HTTP method，对服务器端资源进行操作，实现“表现层状态转化”
请求返回码含义
GET /zoos200 OK列出所有动物园，服务器成功返回了
POST /zoos201 CREATED新建一个动物园，服务器创建成功
PUT /zoos/ID400 INVALID REQUEST更新某个指定动物园的信息（提供该动物园的全部信息），但用户发出的请求有错误，服务器没有进行新建或修改数据的操作
DELETE /zoos/ID204 NO CONTENT删除某个动物园，删除数据成功

4. 常用请求头

类型说明
Accept接受类型，表示浏览器支持的MIME类型（对标服务端返回的Content-Type）
Content-Type客户端发送出去实体内容的类型
Cache-Control指定请求和响应遵循的缓存机制，如no-cache
If-Modefied-Since对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内
Expires缓存控制，在这个时间内不会请求，直接使用缓存，服务端时间
Max-age代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存
If-None-Match对应服务端的ETag，用来匹配文件内容是否改变（非常精确）
Cookie有cookie并且同域访问时会自动带上
Referer该页面的来源URL（适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段）
Origin最初的请求是从哪里发起的（只会精确到端口），Origin比Referer更尊重隐私
User-Agent用户客户端的一些必要信息，如UA头部等，IOS安卓这些的标识

5. 常用接收头

类型说明
Content-Type服务端返回的实体内容的类型
Cache-Control指定请求和响应遵循的缓存机制，如no-cache
Last-Modified请求资源的最后修改时间
Expires应该在什么时候认为文档已经过期，从而不再缓存它
Max-age客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag资源的特定版本的标识符，ETags类似于指纹
Set-Cookie设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Server服务器的一些相关信息
Access-Control-Allow-Origin服务器端允许的请求Origin头部（譬如为*）（跨域的痛苦再度袭来）

6. 缓存

  • 强缓存：资源直接在本地缓存中读取，并返回状态码200OK

    • Expires（到期时间） ，时间戳

    • Cache-Control（下面是一些典型属性）

      • 可缓存性

        • no-cache：协商缓存验证
        • no-store：不使用任何缓存

      • 到期

        • max-age：单位是秒，存储的最大周期，相对于请求的时间

      • 重新验证、重新加载

        • must-revalidate：一般与max-age一起用，一旦资源过期，必须向服务器通信一下，在成功向原始服务器验证之前，不能使用；

          • 经典使用，在浏览器和Server断开连接时，若本地有缓存，且没有must-revalidate，那么我们是可以使用本地缓存的。一旦设置了must-revalidate，那么一旦资源过期，也是没有办法使用本地缓存。

  • 协商缓存：向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果命中，则返回304状态码并带上新的response header通知浏览器从缓存中读取资源；

    • 由于有一个请求的过程，因此有一对对应的请求头和接收头
    • Etag/If-None-Match：资源的特定版本的标识符，类似于指纹
    • Last-Modified/If-Modified-Since：最后修改时间，绝对时间

下面我们来看缓存的一般使用过程

1.png

7. cookie

响应标头Set-Cookie被用来由服务器端向用户代理发送cookie

属性说明
Name=value各种cookie的名称和值
Expires=DateCookie的有效期，缺省时Cookie仅在浏览器关闭之前有效
Path=Path限制指定Cookie的发送范围的文件目录，默认为当前
Domain=domain限制cookie生效的域名，默认为创建cookie的服务域名
secure仅在HTTPS安全连接时，才可以发送Cookie
HttpOnlyJavaScript脚本wufahuodeCookie
SameSite=[None|Strict|Lax]- None同站、跨站请求都可发送
- Strict仅在同站发送
- 允许与顶级导航一起发送，并将与第三方网站发起的GET请求一起发送

三、HTTP/2概述：更快、更稳定、更简单

  • 帧(frame)：HTTP/2通信的最小单位，每个帧都包含帧头，至少也会表示出当前帧所属的数据流。帧的传输采用二进制编码形式，二进制编码形式效率更高

  • 在HTTP/1.1中，数据都是完整传输的，而HTTP/2中将每个数据划分为帧，加快传输，并且采用了压缩技术，也能加快速率

  • 消息：与逻辑请求或响应消息对应的完整的一系列帧

  • 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息

  • 帧是可以交错发送的，由接收方重组织，类似于计算机网络分组交换

  • 特性：

    • 鉴于TCP需要连接的过程，若每次请求都需要重新连接，消耗太大，HTTP/2中，每一个来源和目标地址，一旦建立连接之后，这个连接可以永久利用。

    • 流控制：可以主动阻止发送方向接收方发送大量数据的机制

      • 例如：当你视频暂停时，浏览器也会暂时视频的缓存。

    • 服务器推送：例如，我们向服务器请求html文件，而html文件中带有css和js，那么服务器会智能推断出我们之后会请求css和js，然后把html、css、js直接一起返回。

四、HTTPS

在HTTP基础上，加上了TSL/SSL加密

  • 对称加密：加密和解密都是使用同一个密钥
  • 非对称加密：加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）
  • HTTPS中一般两种加密混合使用

2.png

  • 这里的证书是由权威机构颁发

    • 证书需要包含密钥

五、场景分析

1. 场景分析——静态资源

我们以访问toutiao.com为例子进行场景分析

  • 打开Chrome，地址栏输入toutiao.com搜索
  • 鼠标右键，点击检查，查看网络
  • 点击CSS，查看index.****.css

3.png 我们可以看到来自磁盘缓存，并没有发送请求，为了寻求原因，我们可以查看响应头的内容

4.png 那么静态资源的部署有没有什么方案呢？

2. 静态资源部署方案

用户肯定优先从本地缓存获取数据，但如果第一次打开本站，并没有缓存，又怎样快速让用户获得资源呢？

静态资源方案：缓存 + CDN + 文件名hash

  • CDN：Content Delivery Network（内容分发网络）
  • 通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务

5.png 如上图，各地用户优先向就近CDN获取资源，如果就近不能获取到资源，CDN会回溯找别的结点直到获取到资源。

3. 保证用户获取新的资源

现在有了缓存，用户拿到数据速度快了，但是怎么保证用户拿到的够新呢？

比如，网站的CSS做了改动，样式改变了，但是更新了之后，由于缓存的有效期是1年，那么我们怎么让用户获得最新的CSS呢，按照上面说用户肯定还在用旧的缓存好的CSS。

我们可以通过改变文件名的方法，这样缓存就无法与新的CSS文件匹配，自然要重新适配。

常见的是使用文件名+哈希或者Vue、React项目文件名+版本号

4. 场景分析——动态资源

我们以登录为例，先进行左边的表单登录

6.png 我们还是打开检查，网络界面，点击保留日志和过滤quick_login，查看结果

7.png

我们会发现一个是POST请求，一个是OPTION请求。为什么会有OPTIONS请求呢？

因为这里发生了跨域

5. 什么是跨域（cross-origin）呢？

首先介绍一下同源：协议、域名、端口都相同

那么顾名思义，跨域是指一个请求url的协议、域名、端口三者任意一个与当前页面不同

8.png

  • https默认端口号为443
  • http默认端口号为80

6. 跨域的处理过程

首先要理解，即使发生了跨域，服务器仍然会返回给浏览器数据，只是浏览器发现跨域后，就扣留了数据，因此跨域并不是发不出请求，也不是服务器无响应。

第一种：CORS

  • CORS（Cross-Origin Resource Sharing）跨域资源共享

  • 简单请求

    • 请求方法为三种之一：HEAD、GET、POST
    • HTTP头信息限于以下字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type
    • Content-Type限于以下字段：application/x-www-form-urlencoded、multipart/form-data、text/plain
    • 请求中的任意XMLHttpRequestUpload 对象均没有注册任何事件监听器；XMLHttpRequestUpload 对象可以使用 XMLHttpRequest.upload 属性访问
    • 请求中没有使用 ReadableStream 对象

  • 复杂请求

    • 所有非简单请求都是复杂请求

  • 当有跨域请求时，先发送预请求，以OPTIONS形式发送

    • 预请求：获知服务端是否允许该跨源请求（只有在复杂请求情况下才会发起预请求，一般大部分请求都是复杂请求）

  • 访问控制的相关协议头

    • Access-Control-Allow-Origin：不可省略。控制数据的可见范围，如果希望数据对任何人都可见，可以填写"*"
    • Access-Control-Expose-Headers
    • Access-Control-Max-Age
    • Access-Control-Allow-Credentials
    • Access-Control-Allow-Methods
    • Access-Control-Allow-Headers
    • Access-Control-Request-Method
    • Access-Control-Request-Headers
    • Origin

第二种：代理服务器

  • 跨域的本质是浏览器的同源策略，而同源策略是浏览器的安全策略，不是HTTP的
  • 因此，我们可以部署一个与当前域名在同域下的代理服务器，当发送请求时，首先像代理服务器发送请求，这时不会跨域。
  • 代理服务器再进行请求的代理转发(代理服务器与服务器之间是非同源，但不存在跨域问题，是因为服务器之间采用的是http请求，服务器端调用HTTP接口只是使用HTTP协议，不需要同源策略，也就不存在跨域问题。 )

第三种：Iframe：复杂难用且少用

7. 场景分析——登陆

我们来看看登录过程中都发生了什么

先来看请求头

9.png 其实还有cookie的信息，太多了，大家可以自己去看看

再来看响应头

10.png

我们之前说过，HTTP请求是一个无状态的请求，但是我们登陆后，刷新界面仍然处于登录状态，那么这个状态是怎么保留的呢？

8. 鉴权

第一种：Session + cookie（大部分网站使用）

  • 服务器接收请求后判断正确性，正确的话服务器会产生一个Session，同时在响应头中服务器会把session放在set-Cookie保留到域名地址里。等到下一次访问时，浏览器自动携带cookie的策略把session携带出来，服务器通过与本地存储相比较解析，就能得到刚才登陆的用户信息。

第二种：JWT（JSON web token）

  • 请求正确后，Server会返回一个Token，Token有一些约定的格式，Server不存储Token，而是直接返回给浏览器。在下一次请求时，浏览器会把Token放在请求头中发送给Server，Server解析其有效性和用户信息，然后返回。

  • 适合使用jwt的场景:

    • 有效期短
    • 只希望被使用一次
    • 比如，用户注册后发一封邮件让其激活账户，通常邮件中需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时内激活），不能被篡改以激活其他可能的账户，一次性的。这种场景就适合使用jwt。

  • 而由于jwt具有一次性的特性。单点登录和会话管理非常不适合用jwt，如果在服务端部署额外的逻辑存储jwt的状态，那还不如使用session, 基于session有很多成熟的框架可以开箱即用，但是用jwt还要自己实现逻辑。

11.png

现在我们尝试点击写文章

12.png

我们会进入头条号的网站，但是发现登录态仍然存在，域名已经换了但是登录态却转移过来了，这是怎么回事呢？

9.SSO（Single Sign On）：单点登录

我们把整个头条看成一个大应用，那么首页是一个子应用，记为a，头条号是子应用b，我们希望用户登录一个子应用后其余子应用也会获得登录态，这样方便了用户体验。

流程如下图，已经很清晰了。

13.png

六、实战分析

1. 浏览器环境中

AJAX之XHR（XMLHttpRequest）

  • 专门用来发起请求
  • xhr.readyState属性
数字状态说明
0UNSENT代理被创建，但尚未调用open()方法
1OPENEDopen()方法已经被调用
2HEADERS_RECEIVEDsend()方法已经被调用，并且头部和状态已经可获得
3LOADING下载中；responseText属性
4DONE下载操作已完成

AJAX之Fetch

  • XMLHttpRequest的升级版
  • 使用Promise
  • 模块化设计，Response、Request、Header对象
  • 通过数据流处理对象，支持分块读取

2. node篇

标准库：HTTP/HTTPS

  • 默认模块，无需安装其他依赖
  • 功能有限/不是十分友好

常用的请求库：axios

  • 支持浏览器、nodejs环境
  • 很多api，丰富的拦截器

3. 网络优化

14.png

4. 稳定性

  • 当请求超市或错误时，会重新发送请求。重试是保证稳定的有效手段，但要防止加剧恶劣情况
  • 缓存合理使用，作为最后一道防线
  • 数据被劫持，类似网站被植入广告

15.png

七、扩展

1. 通信方式

除了HTTP，在特殊场景，比如实时性要求特别高的网络聊天室中，会使用WebSocket

  • 浏览器与服务器进行全双工通讯的网络技术
  • 典型场景：实时性要求高，例如聊天室
  • URL使用ws://或wss://等开头

16.png

2.QUIC：Quick UDP Internet Connection

QUIC不使用TCP，而是使用传输层另一重要协议UDP，而且经过一系列封装，具有了类似TCP协议的可靠传输，还实现了加密传输。

QUIC也是HTTP/3草案的一部分。

17.png

  • 0-RTT建联（首次建联除外)
  • 类似TCP的可靠传输。
  • 类似TLS的加密传输，支持完美前向安全。
  • 用户空间的拥塞控制，最新的BBR算法。
  • 支持h2的基于流的多路复用,但没有TCP的HOL问题。
  • 前向纠错FEC。
  • 类似MPTCP的Connection migration。

八、引用

  • 字节录播课 - 初识 HTTP 协议
  • 字节录播课 - HTTP 协议的应用场景分析
  • 字节录播课 - HTTP 协议实战分析
avatar
文章
阅读
粉丝