小菜鸟

广告行业核心业务知识：平台、结算与运营体系详解

广告行业涉及复杂的角色分工、技术体系和业务模式，从广告主的投放需求到用户的最终触达，需经过多个平台协同与多层级的业务处理。本文系统梳理广告行业的核心业务知识，包括关键平台类型、结算方式、数据体系及广告形式等，帮助理解广告业务的完整生态。

核心平台类型（供需两端的连接枢纽）

广告行业的平台体系围绕 “需求方（广告主）” 和 “供应方（媒体 / 流量方）” 展开，各平台承担不同角色，共同完成广告的投放与变现。

1. SSP（供应方平台，Supply Side Platform）

• 定位：面向媒体（流量供应方），帮助媒体管理广告资源并实现收益最大化。
• 核心功能：
  • 整合媒体的广告位资源（如 App 开屏、信息流、网站横幅），统一管理库存。
  • 对接 ADX 或直接对接 DSP，将流量推向需求方，参与竞价。
  • 提供定价策略（如底价设置）、流量筛选（如过滤低质请求）等功能，优化变现效率。
• 典型用户：App 开发者、网站站长、短视频平台等拥有流量的主体。

2. DSP（需求方平台，Demand Side Platform）

• 定位：面向广告主（需求方），帮助广告主自动化投放广告并优化效果。
• 核心功能：
  • 接收广告主的投放需求（预算、定向条件、出价方式等）。
  • 对接 ADX 或直接对接 SSP，获取流量并参与实时竞价（RTB）。
  • 通过算法优化投放策略，如根据用户标签选择目标人群，提升转化效率。
• 典型用户：电商平台、游戏厂商、教育机构等有推广需求的广告主。

3. ADX（广告交易平台，Ad Exchange）

• 定位：连接 DSP 与 SSP 的中间交易市场，是广告流量的 “拍卖场”。
• 核心功能：
  • 接收 SSP 推送的流量请求，将用户标签、广告位信息等传递给 DSP。
  • 组织实时竞价（RTB），根据 DSP 的出价（价高者得）或其他规则（如广告质量）选择获胜者。
  • 负责创意审核、流量过滤（如设置底价，低于底价的出价不参与竞价），保障交易合规性。
• 特点：中立性平台，不直接参与供需双方的利益分配，仅提供交易基础设施。

Tomcat Web 应用加载机制详解

Tomcat 作为主流的 Servlet 容器，其 Web 应用的加载过程是核心功能之一。这一过程主要由 StandardHost、HostConfig、StandardContext、ContextConfig、StandardWrapper 五个核心类协同完成，涵盖了从应用部署到初始化的全流程。本文将详细解析这一机制。

核心组件角色概述

在 Web 应用加载过程中，五个核心类的职责如下：

StandardHost：Web 应用加载的入口

StandardHost 是虚拟主机的实现类，作为 Web 应用（StandardContext）的父容器，提供了两种 Web 应用加载入口：

1. 基于 server.xml 配置的静态加载

当在 server.xml 的 <Host> 标签中直接配置 <Context> 子元素时，Tomcat 会在启动时将其作为子容器添加到 Host 并启动。

配置示例：

1
2
3
4

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
  <!-- docBase：Web应用根目录路径；path：访问路径 -->
  <Context docBase="myApp" path="/myApp" reloadable="true"/>
</Host>

特点：

• 需手动修改 server.xml，不适合动态部署。
• reloadable="true" 表示当应用类或配置文件变化时，自动重新加载。

2. StandardHost 启动加载流程

StandardHost 的启动过程（startInternal() 方法）是 Web 应用加载的触发点，关键步骤包括：

Tomcat 之 Connector 连接器深度解析

在 Tomcat 架构中，Connector（连接器） 是负责与客户端通信的核心组件，它封装了底层网络通信细节，为上层容器（Catalina）提供统一的请求入口。本文将详细解析 Connector 的功能、结构及工作原理。

Connector 概述

Connector 是 Tomcat 对外提供服务的接口，基于 Coyote 框架实现，主要功能包括：

• 网络通信：监听端口，接收客户端连接（如 HTTP 请求）。
• 协议解析：根据 HTTP、AJP 等协议解析请求数据。
• 数据转换：将字节流转换为 Tomcat 内部的 Request 对象，再转换为标准的 ServletRequest 供容器处理；处理完成后将响应反向转换为字节流返回客户端。

核心目标：使 Catalina 容器与具体的协议和 I/O 模型解耦，提高灵活性和可扩展性。

支持的协议与 I/O 模型

1. 传输协议

Connector 支持三种主要协议：

2. I/O 模型

Tomcat 8.5 后移除了对 BIO（阻塞 I/O）的支持，保留以下三种 I/O 模型：

Connector 配置示例

Connector 的配置通常在 conf/server.xml 中，以下是一个 HTTP/1.1 协议的 NIO 连接器配置：

Tomcat 之 Container 容器深度解析

在 Tomcat 架构中，Container（容器） 是负责处理内部请求、封装 Servlet 并管理其生命周期的核心组件。与连接器（Connector）负责对外通信不同，容器专注于请求的内部处理流程。本文将详细解析 Container 容器的层级结构、核心接口及工作机制。

Container 容器的层级结构

Container 是一个接口，其下分为四个子接口，形成层级化的容器结构，从上到下依次为：

• Engine：最顶层容器，代表整个 Servlet 引擎
• Host：表示一个虚拟主机（站点）
• Context：表示一个 Web 应用程序
• Wrapper：表示一个具体的 Servlet

它们的装配关系为：
Engine → Host（多个） → Context（多个） → Wrapper（多个）

核心接口解析

1. 顶层接口 Container

Container 接口定义了所有容器的通用行为，包括父子容器管理、生命周期控制等。核心方法如下：

Catalina：Tomcat 的核心 Servlet 容器解析

Catalina 是 Tomcat 的核心组件，负责管理 Servlet 的生命周期、处理 HTTP 请求并协调各组件工作。自 Tomcat 4.0 起，Catalina 成为 Servlet 容器的正式名称，其设计采用模块化架构，通过解析server.xml配置文件构建服务器实例，协调连接器（Connector）与容器（Container）的协作。本文深入解析 Catalina 的工作原理、组件解析流程及核心配置逻辑。

Catalina 的核心定位与架构

Catalina 是 Tomcat 的 “大脑”，承担以下核心职责：

• 解析server.xml配置文件，创建并管理 Server、Service、Connector、Container 等组件；
• 协调连接器（接收请求）与容器（处理请求）的交互；
• 管理 Servlet 的加载、初始化、请求处理及销毁全生命周期；
• 集成其他模块（如 Coyote 负责通信、Jasper 处理 JSP、JNDI 提供命名服务）。

其架构可简化为：

1

Catalina → Server → Service → (Connector + Container)  

• Server：顶层组件，代表整个 Tomcat 实例；
• Service：关联 Connector 与 Container，实现 “接收请求 - 处理请求” 的链路；
• Connector：处理网络通信，解析 HTTP 请求；
• Container：处理请求的核心，包含 Engine、Host、Context、Wrapper 四级容器。

Catalina 的启动流程：从配置到组件初始化

Catalina 的启动始于org.apache.catalina.startup.Catalina类，核心步骤包括：