HTTP的复盘与整理

参考笔记

概述

HTTP即超文本传输协议( HyperText Transfer Protocol),用以浏览器和服务器之间传递数据,HTTP1.0版本是无状态(stateless)的,即同一个客户第二次访问同一个服务器上的页面时,服务器的响应与第一次被访问时相同,服务器不维护任何有关客户端过去所发请求的信息。

HTTP的操作过程

  • 用户点击链接后浏览器分析URL,与对应的服务器建立TCP链接(耗费1RTT);
  • 服务器持续监听80端口,监听到请求后同意建立连接,与浏览器建立起TCP连接;
  • 浏览器发起HTTP请求文档数据,服务器响应后通过HTTP响应报文返回给浏览器;
  • 浏览器接收到HTTP报文,解析后将数据渲染到页面,显示给用户并释放TCP连接。

 

非持久性连接

  • 每个TCP连接最多允许传输一个对象
  • HTTP 1.0版本使用非持久性连接
  • 响应时间:建立TCP连接(1RTT)+ 发送HTTP请求消息到HTTP响应消息的前几个字节到达(1个RTT) = 2RTT

持久性连接

 HTTP消息格式

请求消息:

ASCII:人直接可读,carriage return为回车;line feed为换行

HTTP请求消息的通用格式,下图中“SP”代表“空格”;而“cr”表示“回车”;“lf”为“换行”

 

响应消息:

下图中第一行中的“200”表示网页被正常获取,常用的​​响应码​​包括:301 Moved Permanently(资源已被移动),400 Bad Request,404 Not Found,505 HTTP Version Not Supported等

HTTP2

二进制分帧:

帧:HTTP/2 数据通信的最小单位

消息:指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等,消息由一个或多个帧组成。

流:存在于连接中的一个虚拟通道。流可以承载双向消息,每个流都有一个唯一的整数ID。

HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文,都是由起始行,首部和实体正文(可选)组成,各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧,并且它们采用二进制编码

HTTP/2 中,同域名下所有通信都在单个连接上完成,该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,根据帧首部的流标识可以重新组装。

多路复用:

代替原来的序列和阻塞机制,所有就是请求的都是通过一个 TCP连接并发完成(HTTP1.1虽然支持长连接,但不支持高并发,当请求数量过多时,仍会使用多个TCP链接)

  • 同域名下所有通信都在单个连接上完成。
  • 单个连接可以承载任意数量的双向数据流。
  • 数据流以消息的形式发送,而消息又由一个或多个帧组成,多个帧之间可以乱序发送,因为根据帧首部的流标识可以重新组装。
  • 同个域名只需要占用一个 TCP 连接,消除了因多个 TCP 连接而带来的延时和内存消耗。
  • 单个连接上可以并行交错的请求和响应,之间互不干扰。
  • 在HTTP/2中,每个请求都可以带一个31bit的优先值,0表示最高优先级, 数值越大优先级越低。有了这个优先值,客户端和服务器就可以在处理不同的流时采取不同的策略,以最优的方式发送流、消息和帧。

服务器推送:

服务端可以在发送页面HTML时主动推送其它资源,而不用等到浏览器解析到相应位置,发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端,而不需要客户端解析HTML时再发送这些请求。

服务端可以主动推送,客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过,浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略,服务器不会随便推送第三方资源给客户端。​​了解更多 Server Push 特性​

头部压缩:

  • HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对,对于相同的数据,不再通过每次请求和响应发送;
  • 首部表在HTTP/2的连接存续期内始终存在,由客户端和服务器共同渐进地更新;
  • 每个新的首部键-值对要么被追加到当前表的末尾,要么替换表中之前的值。

HTTP3 & QUIC

HTTP VS HTTP2:

  • 多路复用:多路复用时,多文件传输有时只需维护一个 TCP 连接。如果是 HTTP1 协议下,每份资源的传输对应一个 TCP 连接,一般最多只能开启 6 个 TCP 连接来传输多路数据,后续每增加一个新链接就会因为拥堵问题卡死,进而导致整个进程无法运行。因此HTTP/2解决了 HTTP 的队头阻塞问题。
  • 头部压缩和 Server Push:HTTP2 会通过 HPACK 做头部压缩。同时 HTTP2 是二进制协议,在解析上相比基于文本的 HTTP解析效率上有所提升,并且 HTTP2 还增加了 Server Push。
  • 在 TCP 下,依然无法解决延迟问题,比如为防止初始阻塞而引入的慢启动;TCP 队头阻塞,比如由于发生丢包,整个连接涉及的传输数据都需要重传而引起的阻塞。

HTTP3 VS HTTP2:

HTTP3 本质不是对 HTTP 协议本身的改进,它主要是集中在如何提高传输效率。上图是相比 HTTP2 而言 HTTP3 提升的点:

  • HTTP3 使用 stream 进一步扩展了 HTTP2 的多路复用。在 HTTP3 模式下,一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时,你只需要重传丢包文件的对应 stream 即可。
  • HTTP3 不再是基于 TCP 建立的,而是通过 UDP 建立,在用户空间保证传输的可靠性,相比 TCP,UDP 之上的 QUIC 协议提高了连接建立的速度,降低了延迟。
  • 通过引入 Connection ID,使得 HTTP3 支持连接迁移以及 NAT 的重绑定。
  • HTTP3 含有一个包括验证、加密、数据及负载的 built-in 的TLS安全机制。
  • 拥塞控制。TCP 是在内核区实现的,而 HTTP3 将拥塞控制移出了内核,通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代。
  • 头部压缩。HTTP2 使用的 HPACK,HTTP3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持,也优化了压缩率。

QUIC:

QUIC使用UDP而不再是TCP,

  • 避免 ossification(僵化):QUIC 协议加密负载,也是避免协议僵化一种方式,比如当中间层处理 UDP 数据时,只需要按照数据包的方式去处理即可,不需要去关注内部层的具体信息。
  • 放弃改进 TCP 本身
  • 创新方向:QUIC 是由谷歌提出的,所以 UDP 是以浏览器为出发点,从协议、从浏览器方向来进行创新。
  • 这些年性能的优化提升都针对 TCP ,使得 UDP 性能没有任何改进。当然随着 QUIC3 的发布,相信后续应该会有相对的投入。
  • 安全问题,也就是反射攻击,即伪造原地址。这个指发送数据包时的原地址是伪造的,不是真正的地址,会引起放大攻击。原因是 QUIC 握手过程是不对称的,特别是第一次请求时,客户端只需要发送几个字节的信息到服务器,而服务器则需要把证书等很多东西返还给客户端,这个不对称的机会造成了放大。草案 27 定义了两个规则和机制来限制反射攻击:客户端发送Initial包,即第一个数据包时,其长度必须在 1200 bytes以上,不足部分用 Padding 帧填充,同时,当服务端不确定客户端可靠性时,可以发送 Retry 包要求客户端再次提供验证信息。

<think>好的,我现在需要帮用户分析他们提到的培训评估分系统的技术方案。首先,用户已经详细描述了系统的功能和组成部分,我需要先理解这些内容,然后整理出一个结构清晰的技术方案。 首先,系统分为几个模块:培训数据管理、资源消耗分析、行动趋势分析、培训效果分析、复盘回放模块。每个模块都有特定的功能,比如数据采集、处理、存储,以及各种分析评估和可视化展示。用户还提到数据采集是通过网络接口获取侦检、去污洗消、医疗救治的数据,然后经过预处理(去噪、补位、去重、对齐)后存储,后续用于统计分析,并以图表形式展示。 接下来,我需要考虑技术架构的分层。通常系统会分为数据采集层、数据处理层、数据存储层、业务逻辑层和展示层。数据采集层需要支持多种接口,可能涉及API网关、消息队列等技术。数据处理层要做数据清洗和预处理,可能需要使用ETL工具或者编写自定义的清洗逻辑。数据存储层可能需要关系型数据库和时序数据库,或者大数据平台如Hadoop、Spark。业务逻辑层需要实现各个模块的分析算法,比如资源消耗模型、趋势预测模型等。展示层则需要前端框架来实现可视化,比如ECharts、D3.js,或者使用现成的BI工具。 然后,复盘回放模块需要记录操作步骤和数据,可能需要事件溯源模式,存储时间序列的数据,回放时要能按时间线重现操作。这里可能需要高精度的时间戳和高效的数据检索。 技术选型方面,后端可能用Java或Python,前端用Vue或React,数据库用MySQL、PostgreSQL或时序数据库InfluxDB,大数据处理用Hadoop/Spark,消息队列用Kafka或RabbitMQ。可视化库选ECharts或Highcharts,云计算平台可以用AWS或阿里云。 另外,用户提到预处理步骤包括去噪、补位、去重、对齐。去噪可能需要滤波算法或异常检测;补位是处理缺失数据,可以用插值方法;去重就是消除重复记录;对齐则是时间或数据字段的统一,可能需要时间戳同步或数据格式标准化。 安全性和扩展性也需要考虑,比如数据加密、权限控制,系统设计要模块化,方便后续功能扩展。 需要检查是否有遗漏的部分,比如网络接口的具体实现方式,数据存储的具体结构,分析模型的具体算法等。但用户可能不需要过于详细的算法描述,而是更关注整体架构和技术栈。 最后,整合这些思路,按照功能模块、技术架构、数据处理流程、可视化方案、关键技术的顺序组织内容,确保逻辑清晰,技术方案可行,并且符合用户的需求。</think>以下是对该培训评估分系统的技术方案分析,按功能模块技术实现分层说明: --- ### 一、系统功能模块划分 1. **培训数据管理模块** - **功能**:通过API/消息队列采集侦检、去污洗消、医疗救治等实操数据。 - **技术实现**: - 网络接口协议:HTTP/RESTful API、WebSocket实时传输 - 数据预处理:去噪(均值滤波/异常值剔除)、补位(线性插值)、去重(哈希比对)、对齐(时间戳同步) 2. **资源消耗分析模块** - **功能**:统计药品、装备、人力等消耗数据,生成直方图/饼状图。 - **技术实现**: - 动态聚合计算:基于SQL/Spark实时统计 - 模型支持:资源损耗预测(时间序列分析如ARIMA) 3. **行动趋势分析模块** - **功能**:二三维态势融合展示,结合曲线/柱状图实时反馈行动趋势。 - **技术实现**: - 可视化引擎:Cesium(三维地理空间)+ ECharts(二维图表) - 趋势算法:移动平均法、马尔可夫链状态转移预测 4. **培训效果分析模块** - **功能**:评估指挥决策合理性、操作规范性,输出折线图/雷达图。 - **技术实现**: - 评价模型:层次分析法(AHP)量化指标权重 - 比对基准:预设规则库(如SOP标准操作流程) 5. **复盘回放模块** - **功能**:按时间轴回放操作步骤,支持暂停/逐帧分析。 - **技术实现**: - 数据存储:时序数据库(InfluxDB)记录操作事件流 - 回放引擎:基于WebGL的时空轨迹渲染 --- ### 二、技术架构设计 1. **数据流架构** ```mermaid graph LR A[数据采集] -->|Kafka| B[预处理] B -->|清洗后数据| C[MySQL/时序库] C --> D[分析引擎] D -->|统计结果| E[可视化服务] ``` 2. **关键技术选型** - **后端框架**:Spring Boot(资源管理微服务)+ Python(数据分析服务) - **实时计算**:Flink流处理引擎(行动趋势动态分析) - **三维可视化**:Three.js + 地理信息系统(GIS)叠加热力图 - **安全机制**:OAuth2.0鉴权 + 数据脱敏(医疗敏感信息处理) --- ### 三、核心创新点 1. **多模态数据融合** - 实现实操传感器数据(IoT设备)人工录入数据的时空对齐 - 示例:洗消作业GPS轨迹物资消耗记录的毫秒级同步 2. **智能评估模型** - 引入强化学习算法,通过历史最优决策数据训练评估基准 - 异常操作检测:基于LSTM预测实际操作的偏离度计算 --- ### 四、部署方案 1. **云端架构** - 采用Kubernetes容器化部署,弹性扩展计算节点 - 灾备设计:跨可用区数据库主从复制(MySQL Group Replication) 2. **边缘计算支持** - 离线训练场景:通过SQLite轻量级数据库实现断网续传 --- 该系统通过分层解耦设计,在保证实时性的同时满足复杂分析需求,技术方案具备可扩展性实战适用性。是否需要针对某模块展开实现细节说明?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值