gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

年度归档2025

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 2025
  • ( 页面14 )
面试 1月 5,2025

面试高频问题:说一下 HTTP 1.0、HTTP 1.1、HTTP 2 以及 HTTP 3 的发展以及变化

1. HTTP 1.0:基础协议的诞生(1991年)

HTTP 1.0 是最早的 HTTP 协议版本,由万维网的发明人蒂姆·伯纳斯-李(Tim Berners-Lee)在 1991 年提出并应用于最初的 Web 服务。作为一个简单的基于文本的协议,HTTP 1.0 在当时的互联网环境下解决了浏览器和服务器之间的数据传输问题。

特点
  • 请求/响应模型:HTTP 1.0 是基于请求-响应模型的。当客户端向服务器发送请求时,服务器会根据请求返回响应。这是 HTTP 协议的核心理念。
  • 无状态性:HTTP 是无状态的,即每一次请求都是独立的,服务器不会记住上一次请求的状态。
  • 文本协议:所有的 HTTP 消息都是纯文本的,便于人类阅读和调试。
  • 一次请求/一次响应:HTTP 1.0 协议设计中,客户端发起请求时,服务器处理该请求并返回响应后,连接就会关闭。如果客户端需要请求多个资源(如 HTML 页面中的图片、CSS 文件、JavaScript 文件等),就需要建立多个连接。
限制与问题
  • 每个请求需要建立新连接:在 HTTP 1.0 中,每个请求和响应都需要建立一个新的 TCP 连接。随着 Web 内容日益复杂,页面上需要加载的资源数量增加,每个请求都要重新建立连接,导致了大量的网络开销和性能瓶颈。
  • 头部冗余:每个 HTTP 请求和响应都带有完整的头部信息,但这些头部信息往往重复,增加了传输的数据量。

2. HTTP 1.1:改进与优化(1997年)

HTTP 1.1 是对 HTTP 1.0 的重要改进,由 IETF(互联网工程任务组)在 1997 年发布,并迅速成为 Web 上的标准协议。与 HTTP 1.0 相比,HTTP 1.1 引入了多个优化和新特性,主要是为了解决性能瓶颈和提高多用户的并发性能。

主要特点
  • 持久连接(Persistent Connection):HTTP 1.1 引入了持久连接的概念。通过将“Connection: close”头去除,HTTP 1.1 默认为持久连接。这样,客户端和服务器之间可以复用同一个连接,减少了每个请求都建立新连接的开销。一个 TCP 连接可以处理多个请求和响应,直到客户端或服务器主动关闭连接。
  • 管道化(Pipelining):管道化技术允许客户端在等待服务器响应之前,先后发送多个请求,而无需等待每个请求的响应。这有助于减少请求延迟,提升性能。然而,管道化存在问题,比如响应顺序问题,当一个请求的响应延迟时,后续请求的响应也会被阻塞。
  • 缓存控制:HTTP 1.1 引入了更加精细的缓存控制机制,包括 Cache-Control、ETag、Last-Modified 等头部字段,使得浏览器能够更好地控制缓存,从而减少不必要的请求和数据传输。
  • 更多的状态码:HTTP 1.1 扩展了状态码的定义,增加了一些新的响应状态码,例如 409 Conflict、411 Length Required 和 416 Range Not Satisfiable 等,提供了更好的错误处理机制。
  • Chunked Transfer Encoding:HTTP 1.1 支持分块传输编码(Chunked Transfer Encoding),允许服务器分块发送响应数据,客户端可以在接收到部分数据时开始处理,提升了响应的速度。
限制与问题
  • Head-of-line Blocking(HOLB):尽管 HTTP 1.1 引入了持久连接和管道化技术,管道化模式存在一个重大问题:如果其中一个请求的响应延迟,则后续的请求也会被阻塞,这被称为“Head-of-line Blocking”。这种情况在请求较多时会显著影响性能。
  • TCP 连接的限制:虽然持久连接降低了每个请求的连接开销,但仍然受到 TCP 的限制,浏览器通常会为每个域名建立有限数量的连接,导致需要加载多个资源时性能依然受限。

3. HTTP 2:性能革命(2015年)

随着 Web 技术的发展和用户需求的提升,HTTP 1.1 逐渐暴露出一些性能瓶颈,尤其是在处理复杂页面和高并发场景时。为了提升性能,HTTP 2 在 2015 年正式发布,成为现代 Web 上广泛采用的协议。HTTP 2 主要通过优化传输层、提高并发性和减少延迟来改进 HTTP 1.1 的局限。

主要特点
  • 二进制协议:HTTP 2 完全摒弃了 HTTP 1.x 的文本协议,采用了二进制协议。二进制协议相比文本协议具有更高的传输效率,并且解析更为简便,可以避免出现由于文本格式导致的错误和性能损失。
  • 多路复用(Multiplexing):HTTP 2 允许在一个 TCP 连接上并发地发送多个请求和响应,并且它们的顺序不会相互干扰。这样可以有效解决 HTTP 1.1 中的 Head-of-line Blocking 问题,多个请求可以同时发出并独立处理。
  • 流控制:HTTP 2 引入了流控制机制,可以有效控制数据流的传输速率,防止一方发送数据过快导致另一方处理不过来,从而避免网络阻塞。
  • 头部压缩:HTTP 2 使用 HPACK 压缩算法来压缩 HTTP 请求和响应的头部信息,减少了由于重复的头部信息造成的开销,提高了传输效率。
  • 服务器推送(Server Push):HTTP 2 支持服务器推送机制,允许服务器主动向客户端推送资源,而不需要客户端明确请求。这有助于减少延迟,特别是在页面加载时,服务器可以提前将客户端可能需要的资源推送到浏览器中。
  • 优先级和依赖关系:HTTP 2 允许客户端指定请求的优先级,服务器可以根据优先级来处理请求,这对于高性能的应用尤为重要,能够显著提升页面加载速度。
限制与问题
  • 依然依赖 TCP:HTTP 2 尽管引入了多路复用和流控制等优化机制,但它仍然基于 TCP 连接,这意味着它仍然无法克服 TCP 协议在高延迟和网络丢包情况下的局限性。
  • 服务器推送的问题:虽然服务器推送可以减少某些情况下的请求次数,但它也存在一定的问题,例如推送资源可能没有被客户端需要,从而浪费带宽。

4. HTTP 3:基于 QUIC 协议的新时代(2020年)

HTTP 3 是基于 Google 提出的 QUIC(Quick UDP Internet Connections)协议的 HTTP 协议新版本,旨在进一步提升 Web 性能,特别是在高延迟和不稳定网络环境下。HTTP 3 仍然基于 HTTP 2 的多路复用和流控制等特性,但它摒弃了传统的 TCP 协议,转而使用 QUIC 协议。

主要特点
  • 基于 QUIC 协议:HTTP 3 使用 QUIC 协议而不是 TCP。QUIC 是一个基于 UDP 的传输协议,具有低延迟和更快连接建立的优势。由于 QUIC 可以在用户端和服务器之间建立加密的传输通道,并且实现了多路复用和流控制机制,它能够有效解决 HTTP 2 中 TCP 带来的瓶颈。
  • 更快的连接建立:QUIC 协议比 TCP 协议建立连接的速度更快,因为它集成了 TLS(传输层安全协议)和握手过程,减少了连接时延。QUIC 在首次连接时仅需一次握手就可以完成加密,避免了 TCP 中多次握手的延迟。
  • 内建加密:QUIC 协议内建加密功能,确保了 HTTP 3 传输的数据始终是加密的,这比传统的 HTTP 协议更加安全。
  • 更强的抗丢包能力:由于QUIC 基于 UDP 协议,它比 TCP 更加高效地处理丢包和网络延迟问题。在 TCP 中,丢包会导致整个连接的阻塞(因为 TCP 是面向流的协议,每次丢包都需要等待重传),而 QUIC 可以独立地重传丢失的数据包,不会影响到其他数据流的传输,因此在不稳定网络环境下性能更好。
  • 减少的延迟:QUIC 支持快速恢复连接,它在中断后可以快速恢复,并且减少了重新握手的延迟。在传统的 TCP 中,每次建立新连接时需要经过三次握手,TLS 也需要额外的加密和握手过程,而 QUIC 能够在同一连接中直接进行加密和身份验证,大大减少了延迟。
  • 多路复用与流控制:与 HTTP 2 类似,HTTP 3 支持多路复用,在同一个连接上同时传输多个数据流,而且每个流可以独立地处理,避免了 HTTP 2 中的 Head-of-Line Blocking 问题。每个数据流在 QUIC 中是独立的,即使一个流丢包或出现延迟,其他流也不会受到影响。
  • 内建加密:HTTP 3 默认启用了加密,使用的是 TLS 1.3 协议。这意味着所有的 HTTP 3 流量都是加密的,确保了更高的安全性和隐私保护。
  • 更快的连接恢复和更低的延迟:相比于传统的 TCP + TLS,QUIC 协议能够提供更快速的连接建立和恢复,因为它减少了多个协议层之间的交互和握手过程。QUIC 采用了基于 UDP 的流量控制和拥塞控制,减少了连接建立的时延,特别是在需要频繁断开和重新连接的移动网络环境中表现尤为突出。
  • 抗丢包能力更强:QUIC 可以更好地应对丢包情况,在不影响其他流的情况下重传丢失的包,极大地提升了数据传输的可靠性和稳定性。
  • 自动加密:HTTP 3 强制使用加密连接,这使得 Web 安全性得到更大的提升,同时也避免了多次加密层的开销,提升了性能。
  • 广泛的支持尚需时间:虽然主要浏览器和服务器已经开始支持 HTTP 3,但因为 QUIC 协议基于 UDP,这意味着防火墙和网络运营商的支持仍然是一个挑战。某些网络可能会阻止 UDP 流量,这可能影响到 HTTP 3 的普及程度。
  • 过渡期的兼容性问题:虽然大多数现代浏览器和服务器已经开始支持 HTTP 3,但对于仍然使用 HTTP 1.1 和 HTTP 2 的环境,仍然需要维持向后兼容。服务器和客户端需要根据协议版本的支持情况选择适当的协议版本,可能会导致一些额外的复杂性。
  • HTTP 1.0 为 Web 的初步发展奠定了基础,但它的局限性很快暴露,尤其是每次请求都需要建立一个新的连接的问题。
  • HTTP 1.1 通过引入持久连接、管道化和缓存控制等特性,显著提高了性能,尤其是在客户端与服务器之间频繁通信的情况下。
  • HTTP 2 则通过采用二进制协议、支持多路复用和服务器推送等技术,进一步提高了 Web 应用的响应速度和效率。
  • HTTP 3 采用基于 UDP 的 QUIC 协议,解决了 HTTP 2 中的 TCP 拥塞问题,进一步降低了延迟,并提高了抗丢包能力,尤其在移动网络和高延迟环境下表现尤为出色。
作者 east
Flink, tdengine 1月 3,2025

Flink读取TDEngine数据实例,解决com.taosdata.jdbc.rs.RestfulDatabaseMetaData@38af9828 is not serializable. The object probably contains or references non serializable fields错误

用flink读取TDEngine,运行报错:
com.taosdata.jdbc.rs.RestfulDatabaseMetaData@38af9828 is not serializable. The object probably contains or references non serializable fields

这意味着 com.taosdata.jdbc.rs.RestfulDatabaseMetaData 类的对象无法被序列化,而 Flink 的作业中涉及到的某些操作需要将对象传递到不同的任务中,这就要求对象是可序列化的(即实现了 Serializable 接口)。在 Flink 中,所有要在分布式环境中传输或持久化的对象都必须是可序列化的。

  • RestfulDatabaseMetaData 是 TDengine JDBC 驱动中的一个类,它可能没有实现 Serializable 接口,因此在需要将该类对象传输到其他机器时,Flink 无法进行序列化。

解决方法是

使用 transient 关键字避免对不可序列化对象进行传递。

通过标记 connection、preparedStatement 和 resultSet 为 transient,这些对象不会被 Flink 传递到 Task Manager。

完整可执行代码如下:


import org.apache.flink.streaming.api.functions.source.RichParallelSourceFunction;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

public class TDengineSourceFunction extends RichParallelSourceFunction<RunData> {

    private transient Connection connection;        // 使用 transient 避免序列化
    private transient PreparedStatement preparedStatement;
    private transient ResultSet resultSet;
    private String query;
    private volatile boolean isRunning = true;

    private String jdbcUrl;
    private String user;

    private String password;


    public TDengineSourceFunction(String jdbcUrl, String user, String password, String query) {
        this.query = query;
        this.jdbcUrl = jdbcUrl;
        this.user = user;
        this.password = password;

        // JDBC连接参数在open()方法中初始化
    }

    @Override
    public void open(org.apache.flink.configuration.Configuration parameters) throws Exception {
        super.open(parameters);
        Class.forName("com.taosdata.jdbc.rs.RestfulDriver");
        // 在这里初始化数据库连接
        this.connection = DriverManager.getConnection(jdbcUrl, user, password);
        // 准备SQL查询语句
        this.preparedStatement = connection.prepareStatement(query);
        this.resultSet = preparedStatement.executeQuery();
    }

    @Override
    public void run(SourceContext<RunData> sourceContext) throws Exception {
        while (isRunning && resultSet.next()) {
            // 从ResultSet中提取数据并转换为RunData对象
            RunData data = convertResultSetToData(resultSet);
            // 将数据发送到Flink的处理流中
            if (data != null) {
                sourceContext.collect(data);
            }
        }
    }

    @Override
    public void cancel() {
        isRunning = false;
        // 关闭资源
        try {
            if (resultSet != null) resultSet.close();
            if (preparedStatement != null) preparedStatement.close();
            if (connection != null) connection.close();
        } catch (SQLException e) {
            // 处理关闭资源时的异常
            e.printStackTrace();
        }
    }

    private RunData convertResultSetToData(ResultSet resultSet) throws SQLException {
        // 提取单行数据
      
        // 将数据转换为 RunData 对象


      //  return new RunData(......);
        return null;
    }
}
作者 east
Flink 1月 3,2025

解决flink读取TDEngine的数据Could not initialize class com.taosdata.jdbc.TSDBJNIConnector

需要用flink读取TDEngine的数据,用jdbc方式连接,运行报错:Could not initialize class com.taosdata.jdbc.TSDBJNIConnector

JDBC-JNI的方式需要 TDengine-client(使用JDBC-JNI时必须,使用JDBC-RESTful时非必须),所以采用JDBC-RESTful 的方式,原因是一开始想用
JDBC-JNI 的方式,想改用 JDBC-RESTful 代码没改干净。



通过指定URL获取连接,如下所示:

Class.forName("com.taosdata.jdbc.rs.RestfulDriver");
String jdbcUrl = "jdbc:TAOS-RS://taosdemo.com:6041/test?user=root&password=taosdata";
Connection conn = DriverManager.getConnection(jdbcUrl);
Class.forName("com.taosdata.jdbc.rs.RestfulDriver");String jdbcUrl = "jdbc:TAOS-RS://taosdemo.com:6041/test?user=root&password=taosdata";Connection conn = DriverManager.getConnection(jdbcUrl);

以上示例,使用 JDBC-RESTful 的 driver,建立了到 hostname 为 taosdemo.com,端口为 6041,数据库名为 test 的连接。这个 URL 中指定用户名(user)为 root,密码(password)为 taosdata。

使用 JDBC-RESTful 接口,不需要依赖本地函数库。与 JDBC-JNI 相比,仅需要:

  1. driverClass 指定为“com.taosdata.jdbc.rs.RestfulDriver”;
  2. jdbcUrl 以“jdbc:TAOS-RS://”开头;
  3. 使用 6041 作为连接端口。

按上面的方式修改,果然没有再报上面的错误。

作者 east
Flink 1月 3,2025

flink运行报错:java.lang.IllegalStateException: No ExecutorFactory found to execute the application

在本地运行flink代码,报错“
java.lang.IllegalStateException: No ExecutorFactory found to execute the application ”

通常是由于缺少必要的 Flink 依赖项导致的。具体来说,Flink 需要特定的执行器工厂来运行应用程序,而这些依赖项可能未正确包含在您的项目中。

原因分析

  1. 缺少 Flink 运行时依赖:
    • 您的代码片段看起来是基于 Flink 的流处理 API 编写的。如果项目缺少 Flink 运行时的相关依赖(例如 flink-java, flink-streaming-java, 和 flink-clients),Flink 将无法找到执行器工厂来启动作业。
  2. 依赖版本不匹配:
    • 如果您使用的 Flink 版本与代码不兼容,也可能导致类似的问题。确保所有 Flink 相关依赖的版本一致。
  3. 缺少必要的插件或扩展:
    • 某些情况下,特定的 Flink 插件或扩展可能缺失,导致执行器工厂无法加载。

解决方案

确保您的项目中包含了所有必要的 Flink 依赖项。以下是使用 Maven 的示例 pom.xml 配置,确保包含了 Flink 的核心和流处理依赖:

<dependencies>
    <!-- Flink 核心依赖 -->
    <dependency>
        <groupId>org.apache.flink</groupId>
        <artifactId>flink-java</artifactId>
        <version>1.16.2</version> <!-- 请根据需要替换为合适的版本 -->
    </dependency>

    <!-- Flink 流处理依赖 -->
    <dependency>
        <groupId>org.apache.flink</groupId>
        <artifactId>flink-streaming-java_2.12</artifactId>
        <version>1.16.2</version> <!-- 版本需与 flink-java 一致 -->
    </dependency>

    <!-- Flink 客户端依赖(如果需要远程提交作业) -->
    <dependency>
        <groupId>org.apache.flink</groupId>
        <artifactId>flink-clients_2.12</artifactId>
        <version>1.16.2</version>
    </dependency>



    <!-- 如果使用自定义 Source 和 Sink,确保它们所在的依赖已添加 -->
</dependencies>
作者 east

上一 1 … 13 14

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (43)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (4)
  • 大数据开发 (488)
    • CDH (6)
    • datax (4)
    • doris (30)
    • Elasticsearch (15)
    • Flink (78)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (40)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (99)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (34)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (70)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (6)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.