概述
Tulip Cloud 部署需要高质量、稳定的网络连接，以维持实时性能和数据完整性。 本文定义了 Tulip 部署必须满足的可量化网络要求——带宽、延迟、抖动和数据包丢失，阐述了网络不稳定带来的技术风险（包括触发队列中的数据丢失和 ALCOA 合规性失败），并提供了物理层、逻辑层和应用层层面的建议以缓解这些风险。
稳定性比单纯的速度更为重要：即使在高带宽链路上，不稳定的连接（伴随高抖动或间歇性数据包丢失）也可能导致隐性且永久性的数据丢失。要满足本文中的要求，需要采取双管齐下的方法——即稳健的 IT/网络基础设施与弹性应用架构协同工作。
有关需将 Tulip Cloud 实例加入白名单的具体域名和 IP 地址列表，请参阅《Tulip Cloud 部署网络要求》。
本文适合哪些读者？
本文对在大型环境中部署 Tulip 的高级用户最为有用。如果您正在组织内新部署 Tulip 或目前处于试用阶段，本文中的信息可能超出了您的当前需求。
请使用右侧的链接跳转至您感兴趣的主题内容。
执行摘要
本文概述了确保 Tulip Cloud 部署性能、稳定性和数据完整性的关键网络要求。
关键要点
稳定性比速度更重要：一条 15 Mbps 的稳定有线连接，远胜于一条 100+ Mbps 但存在高抖动或数据包丢失的不稳定连接。
网络不稳定会导致数据丢失：间歇性连接、高延迟或数据包丢失不仅会导致“运行缓慢”，还会导致触发队列堵塞并丢弃事件，从而导致永久性数据丢失和关键数据完整性（ALCOA）故障。
缓解问题需要双管齐下的解决方案：既需要健壮的 IT 基础设施（满足以下要求），也需要弹性应用架构（例如，通过自动化实现逻辑解耦）。
| 指标 | 建议 | 绝对上限（故障点） |
|---|---|---|
| 带宽 | 15 Mbps | 10 Mbps（或计算得出的最小值） |
| 延迟 | < 80 毫秒 | 100 毫秒 |
| 抖动 | < 10 毫秒 | 30毫秒 |
| 数据包丢失率 | 0% | < 0.1% |
关键基础设施政策
默认使用有线以太网：所有固定式 Tulip 播放器必须使用有线、屏蔽以太网。
配置和监控代理及防火墙：白名单中列出的所有 Tulip 域必须配置为支持 SSL/TLS 直通（参见“白名单”）。应尽量减少深度数据包检测（DPI）的使用，并应主动监控防火墙和代理的性能。
每台终端的网络就绪检查清单
对于每个 Tulip Player 工作站，请验证：* [ ]连接类型：固定式播放器使用有线、屏蔽以太网（STP、Cat6a 或更高规格）。* [ ] 带宽：上下行可用带宽均不低于15 Mbps；每台在线终端的带宽不得低于10 Mbps或计算出的最低值（参见“可量化网络要求”）* [ ]延迟：到 your-instance.tulip.co 的平均往返延迟（RTT）< 80 毫秒；最大 RTT**< 100 毫秒*[ ]抖动： 抖动（$RTT_{max}-RTT_{avg}$）小于 10 毫秒（且始终小于 30 毫秒**）*[ ]数据包丢失率：正常运行期间测得的数据包丢失率为0%，最坏情况测试中小于 0.1%。* [ ]正常运行时间：从播放器到 Tulip Cloud 的路径不依赖于不稳定的链接（临时 Wi-Fi、访客网络、频繁断连的 VPN 等）* [ ]代理/防火墙：白名单中的所有 Tulip 域名均已配置为SSL/TLS 直通模式 ，不进行 SSL 拦截、协议重写、篡改或缓存，且最好不进行深度包检测（DPI）。* [ ]WebSockets：代理和防火墙允许通过443端口建立长效WebSocket连接，且不会出现空闲超时或连接重置问题。
[ ] 进程存活性*：设备（尤其是移动设备）应配置为* 避免激进的后台进程休眠*、电池优化，或会暂停 Tulip Player 的操作系统策略，同时在使用过程中避免对网络请求、TCP 连接或 WebSocket 连接进行限速。* [ ]* 弹性应用*：该工作站上的关键应用* *遵循弹性应用架构**模式 （在操作员工作流期间，尽量减少关键触发路径中的事件发生率和 API 调用，优先处理 Tulip 表格，并尽量减少长时间运行的连接器）。
不稳定性风险与数据完整性
本节阐述了为何稳定的连接至关重要，以及哪些技术风险会影响性能和数据完整性。
除了简单的消息延迟外，间歇性连接中断或数据包丢失还会导致两个主要问题：1.事件丢失和数据丢失当网络不稳定或离线时，操作员的操作（如按键、设备输入或条形码扫描）仍会生成事件。 这些事件会在队列中积压。由于该队列容量有限（默认限制为 100 个事件），如果在等待网络恢复期间超过了该限制，所有新到达的事件都将被丢弃并永久丢失。2.系统过载与“补发”导致的运行缓慢当断网后连接恢复时，队列中积压的所有事件（最多100个）将尝试快速连续执行。这可能会给Tulip平台以及任何通过Connector Functions 连接的第三方系统带来突然且巨大的负载。 特别是当多个站点因共享网络连接问题同时重新连接时，这种情况会更加明显。这种“补发”洪流可能是导致系统严重延迟和过载的原因，还可能引发 API 限流（HTTP 429 错误）以及进一步的故障。
网络问题如何导致触发队列中的数据丢失
要理解这一风险，必须了解触发器是如何执行的。 详情请参阅“触发器”。* 单线程队列：Tulip 的触发器运行时基于顺序的单线程队列。每个触发器事件（例如“按钮被按下”）都会被添加到该队列中，且必须完成所有操作后，队列中的下一个事件才能开始执行。*网络“堵塞”：网络中断或严重不稳定会导致触发器内的操作（如“创建表记录”或“运行Connector Function ”）挂起或进入长时间的重试状态。例如，截至 LTS15 版本，失败的表操作将重试长达 2 分钟。*瓶颈：这个单一且运行缓慢的触发器会阻塞整个队列。在阻塞期间，后续的操作员操作（例如，另外 99 次按钮点击）会填满队列。*丢弃的事件：一旦队列达到上限（默认 100 个事件），所有后续事件都将被取消并丢弃。这意味着，如果操作员在网络中断期间扫描了第 101 个商品，该事件将永久丢失，且在网络恢复后也不会被处理。
即使队列未满，一般的网络不稳定也会导致单个Connector Functions （API调用）失败。这些操作不会重试（与LTS15中的表操作不同），并可能导致隐性数据故障和数据完整性问题。
数据丢失的风险因素
在网络连接不佳时，数据丢失的风险并非均匀分布。对于“事件密集型”的应用架构，该风险会显著增加。点击此处了解此类应用的最佳实践。
如果您的应用程序具有以下特征，则面临的风险会高得多：*高事件率：在短时间内生成大量事件的应用程序。这包括快速条形码扫描、频繁的设备输入，或以短时间间隔（例如每 30 秒）触发的定时器。*复杂的触发器：会执行许多顺序操作的触发器，尤其是多次 API 调用（Connector Functions ）或表写入操作。 每次依赖网络的操作都会增加网络中断期间潜在的“堵塞”时间。*依赖Connector Functions ：使用Connector Functions 进行关键数据采集。若因网络波动导致Connector Function 调用失败，系统将不会重试，从而导致触发器失败，这可能使流程中断或导致数据丢失。请尽可能使用自动化流程（和/或函数）。
生命科学领域的 ALCOA 合规性
对于生命科学领域及其他受 GxP 法规监管环境的客户而言，这些网络风险不仅仅是性能问题；它们是对数据完整性和合规性的直接威胁。
上述技术风险与 ALCOA 原则直接相关：*不准确且不完整：当网络中断期间触发队列达到上限时，所有后续事件将被永久丢弃。如果操作员扫描了第 101 个项目，该事件将永远丢失。由此生成的批次记录在根本上是不准确且不完整的。*非实时： 当连接恢复时，“补发”数据洪流会处理积压的队列事件，这通常发生在操作员执行操作数分钟之后。审计员若审查到一组明显滞后于实际工艺过程的时间戳，将对记录的实时完整性提出质疑。*不准确（跨系统）：Connector Functions （API 调用）不具备内置重试机制。网络短暂中断可能导致触发器成功写入 Tulip 表（原始记录），却未能更新外部 MES 或 QMS。这将导致您已验证的系统之间出现数据不准确且不同步的情况。
| 技术问题 | ALCOA 影响 | 示例 |
|---|---|---|
| 停机后队列溢出 | 不完整/不准确 | 第101次扫描丢失 => 批次记录缺失一个单位 |
| 补执行时存在时间延迟 | 非实时 | 所有扫描的时间戳均比实际扫描时间晚了几分钟 |
| ERP更新失败，Tulip更新成功 | 跨系统数据不一致 | Tulip显示已释放，ERP显示“进行中” |
遵循下一节中的架构建议对于构建一个健壮且可验证的流程至关重要，该流程能够防范数据完整性故障。
可量化的网络要求
为防止前文所述的触发队列堵塞、事件丢失及数据完整性故障，每个 Tulip Player 工作站必须保持高质量的持久连接。以下四个维度定义了这一要求。
带宽（吞吐量）
这是连接的“规模”，用于防止网络饱和。尽管应用程序数据有效载荷通常较小，但带宽不足会导致延迟和数据包丢失，进而阻塞触发队列。
- 建议： 每个活动工作站 15 Mbps。
- 绝对最低值： 每个活动站 10 Mbps，或计算出的*“所需带宽*”，以较高者为准。
- 可量化阈值：最小带宽必须超过应用程序的基础数据速率（BDR），并乘以至少为2.0（100%） 的余量系数（$H$），以应对网络开销和重传。
- $R_{peak}$ = 峰值事件率（每秒事件数）
- $S_{event}$ = 每个事件的平均数据有效载荷（字节，包括触发器发送和接收的所有数据）
- $H$ = 裕量系数（无量纲），建议取 $H > 2.0$
首先计算基本数据速率 (BDR)，单位为比特每秒：* $BDR (bps)=R_{peak}\times S_{event}\times 8$
然后计算所需带宽：* $所需带宽 (bps)=BDR\times H=R_{peak}\times S_{event}\times 8\times H$
实际应用中，如果计算出的值小于10 Mbps，仍应为每个活动站分配至少 10 Mbps（最好为 15 Mbps），以确保未来扩展性、提供充足的余量，并考虑同一链路上的其他流量。
示例
如果您的应用程序最坏情况下的峰值事件速率为 $R_{peak}=2events/sec$，且每个事件的发送和接收数据量约为 $S_{event}=5,000 字节$，则：* $BDR=2\times 5,000\times 8=80,000 bps$* $所需带宽(H=2.0)=160,000 bps=0.16 Mbps$
尽管计算出的需求较低，我们仍为每个站点预留至少 10–15 Mbps 的带宽。
延迟（往返时间）
这是数据包往返服务器所需的延迟时间。高延迟会直接增加每个依赖网络的触发操作（如表写入或connector function ）的执行时间，导致整个队列容易发生阻塞。
- 建议值： < 80 毫秒
- 绝对上限： 100ms（至您的 [instance].tulip.co 域名）。
- 可量化限制：延迟直接决定了触发器内部依赖网络的操作所需的时间。为防止触发器队列积压，网络操作所贡献的“总触发器执行时间”必须远小于事件间隔时间。
设：* $R_{peak}$ = 峰值事件率（每秒事件数）* $T_{between}$ = 事件间隔时间（秒）。* $N_{net}$ = 触发器中连续网络操作的数量（例如，表写入、连接器调用）* $RTT_{avg}$ = 平均往返延迟（秒）
事件间隔时间为：* $T_{between}=\frac{1}{R_{peak}}$
网络延迟对触发时间贡献的简单近似公式为：* $T_{trigger,net}=N_{net}\times RTT_{avg}$
为了保持队列健康，我们要求由网络延迟导致的触发时间远低于事件间隔时间。一个实用的经验法则是：* $N_{net}\times RTT_{avg}\leq 0.25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0.25}{R_{peak}}$
通俗来说：一个触发器中所有连续网络往返时间的总和，应小于峰值负载下操作员事件之间预期间隔的四分之一。如果无法满足这一条件，队列将逐渐积压，最终达到 100 个事件的上限。 为了获得最可靠的性能，建议将 $N_{net}\times RTT_{avg}\lt \lt \frac{0.1}{R_{peak}}$
抖动（延迟波动）
这是指延迟的波动。高抖动连接不稳定；单个数据包的突然延迟激增，其影响与高平均延迟同样严重，会导致触发器挂起，阻塞队列，并引发“随机”的停滞和事件丢失。
- **可量化界限：**抖动是延迟随时间的变化。单次延迟突增对触发器的阻塞效果，与持续的高延迟同样显著。
设：* $RTT_{avg}$= 采样窗口内的平均往返时延（秒）* $RTT_{max}$ = 同一窗口内观测到的最大往返时延（秒）
我们定义：* $Jitter=RTT_{max}-RTT_{avg}$
为确保触发器性能可预测，该值必须保持较低。对于 Tulip 部署：*建议：$Jitter$< 10 毫秒*绝对上限：$Jitter$< 30 毫秒
如果测得的抖动接近或超过 30 毫秒，操作员将看到“随机”的卡顿，且触发器可能会长时间保持在运行状态，从而阻塞队列。
可靠性（数据包丢失与正常运行时间）
这是数据完整性的最关键维度。数据包丢失会强制进行重传，这可能导致触发器停滞数秒，从而造成严重的队列堵塞。连接中断（正常运行时间故障）后果极其严重，会导致队列满载（100 个事件）并永久丢失所有后续数据，从而必然导致记录不完整。
- 建议： 0% 数据包丢失率和持续在线。
- 绝对上限： < 0.1% 数据包丢失率。
- 可量化阈值：触发队列只能容纳有限数量的事件。当网络中断时，操作员的操作会持续生成事件，直到队列满为止。一旦队列达到上限，所有后续事件都将被丢弃并永久丢失。
设：* $Q_{max}$ = 最大队列容量（事件）。当前默认值为 $Q_{max}=100$。* $R_{peak}$ = 中断期间的峰值事件速率（每秒事件数）。
在事件开始被丢弃之前，可容忍的最长中断持续时间为：* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$
示例：对于事件速率较高的应用，其 $R_{peak}=2$ 事件/秒（例如，快速变化的扭矩值）：* $T_{outage,max}=\frac{100}{2}=50$ 秒
在此示例中，任何持续时间超过50 秒的网络中断都会导致数据丢失：前 100 个事件之后的所有事件都将被丢弃，且永远不会被处理，即使网络恢复后也是如此。
这一简单关系对于风险评估至关重要：高事件率应用程序只能容忍极短的网络中断，否则数据完整性就会受到损害。
物理基础设施建议
满足可量化的网络要求不仅取决于您的互联网服务提供商（ISP），还很大程度上取决于您设施内部的物理网络基础设施。
默认建议：有线以太网
为了实现上一节中定义的稳定性、可靠性和低延迟指标**，强烈建议所有固定式 Tulip Player 工作站采用有线以太网连接**。
然而，这并不是一种“设置后就无需再管”的解决方案。物理层是一个常见的、但往往被忽视的故障点，可能会导致间歇性且难以诊断的数据包丢失。
- **物理电缆完整性：**IT 和运维团队必须主动管理该基础设施。应定期检查电缆是否存在故障、磨损或连接松动。一个常见的故障源是推车反复碾压未屏蔽或布线不当的电缆。
- **电磁干扰（EMI）：在工厂车间内，高振动机械、电机或高压设备可能会造成显著干扰。在这些环境中，请使用屏蔽以太网电缆（例如 STP、Cat6a 或更高规格）**以防止信号退化。
关于 Wi-Fi 和移动设备的注意事项
我们了解到，许多客户在无法使用有线连接的情况下会使用移动设备（平板电脑、手机）或移动推车。在这些情况下，稳定的 Wi-Fi 连接是确保数据完整性的先决条件。
- 网络设计：必须确保无线网络设计专业且稳健。目标是实现无缝覆盖，避免覆盖盲区（会导致断连），并将接入点（AP）的重叠范围降至最低。 过度的覆盖重叠会导致设备在AP之间“游移”，从而迫使DHCP重新协商，并引发网络停滞，阻塞触发队列。
- **干扰：**Wi-Fi 还极易受到机械设备产生的电磁干扰（EMI）影响。您的网络设计必须考虑到这一点。
- 风险增加：由于无线连接本质上比有线连接不稳定，因此这些设备上的应用程序更应遵循“弹性应用架构”建议（如逻辑解耦），以防范不可避免的网络波动。
- 移动操作系统可能会为节省电量而积极暂停或限制后台应用。在使用过程中，应将 Tulip Player 排除在此类策略之外（建议使用信息亭/锁定应用模式）。
物理基础设施检查清单
有线站点
- [ ]电缆类型：在高电磁干扰（EMI）区域（如电机、驱动器、焊机等处），所有固定式 Tulip Player 均应使用屏蔽以太网电缆（STP、Cat6a 或更高规格）。
- [ ]线缆布线：避免将线缆铺设在推车、叉车或椅子经常碾压的区域；尽可能将线缆通过线槽、导管或架空方式布线。
- [ ]电缆完整性：应制定有记录在案的检查计划（例如每季度一次），以检查是否存在线头散开、扭结、护套压扁及连接松动等问题。
- [ ]终端处理：所有连接器和配线架均已正确终端处理并采取了应力消除措施；不得将“临时”跳线用作永久布线。
- [ ]交换机端口：终端设备端口应锁定在适当的速度/双工模式下，且不得共享经常饱和的超额订阅上行链路。
- [ ]电源/PoE：若使用PoE，交换机的功率预算不得超额分配；需对电压骤降或重启事件进行监控并触发告警。
- [ ]监控：已启用基本交换机监控（CPU、内存、接口错误及利用率），并定期进行审查。
Wi-Fi 和移动设备
- [ ]专业设计：无线网络已针对 Tulip 设备运行的生产区域进行了专业设计（或至少进行了现场勘测）。
- [ ]覆盖范围：沿操作员全程路径（即“行走路线”）测得的信号强度显示覆盖连续，不存在导致强制断连或漫游“自由落体”现象的信号盲区。
- [ ]AP 覆盖重叠：接入点（AP）的布置已将过度重叠降至最低；客户端在静止状态下不会在 AP 之间“游荡”。
- [ ]漫游行为：漫游阈值和频段引导已进行优化，确保设备在切换接入点时平稳过渡，不会出现反复的 DHCP 重新协商或短暂断连。
- [ ]干扰：在信道规划中已考虑已知的电磁干扰（EMI）源（如机械设备、焊机、大型电机、微波链路等）。
- [ ]网络分段：Tulip 设备位于生产系统专用的 SSID/VLAN上，不与访客 Wi-Fi 或高流失率的消费类设备混用。
- [ ]回程链路：接入点（AP）具备可靠且未拥塞的上行链路；控制器或云管理的 Wi-Fi 未接近容量上限。
- [ ]弹性应用：在 Wi-Fi/移动设备上运行的应用程序更严格地遵循弹性应用架构，以应对无线连接固有的更高风险。
测试
请让一名运行 networkCheck 工具的测试人员沿指定路线行走，并配合您自己的诊断工具，确保在 10 分钟内不会出现断连或超过阈值的流量峰值。
逻辑和安全基础设施（代理、防火墙和深度包检测）
除了物理电缆之外，您的逻辑网络安全基础设施是导致“神秘”延迟、抖动和连接失败的最常见来源。
- 代理和防火墙作为瓶颈：对所有流量执行深度数据包检测（DPI）或 SSL/TLS 解密的网络安全设备（防火墙、代理、CASB 等）是导致不稳定的主要原因。 这种检测过程本身会给每个网络请求增加显著且不稳定的延迟（抖动），这很容易导致无法满足<100ms延迟和<30ms抖动的要求。
- 监控设备运行状况：网络团队必须监控这些设备的 CPU 和内存使用率。过载的防火墙或代理会导致数据包丢失或引入延迟，从而引发导致数据丢失的系统不稳定。
- 请勿干预 Tulip 流量：Tulip 的客户端到云端通信依赖于特定的 Web 协议（包括安全的 WebSockets）来实现实时数据传输。 某些安全解决方案会试图拦截、重写或“干预”此类 HTTPS 流量。这种拦截可能会中断 WebSocket 连接，或错误地将标准 API 调用标记为跨源（CORS）请求，导致其失败。
- 要求：所有 Tulip 域名（列于“白名单”部分）必须配置为 SSL/TLS 直通模式。该流量应绕过任何深度包检测（DPI）、协议检查或缓存机制。
检查清单
- [ ]Tulip 域名已绕过：白名单中列出的所有 Tulip 域名均已配置为SSL/TLS 直通，且不被纳入 SSL 解密/拦截范围。
- [ ]优先禁用 DPI 和协议重写：针对 Tulip 流量（尤其是 WebSockets），已禁用深度数据包检测（DPI）、HTTP 协议重写和内容缓存。
- [ ]WebSocket 支持：防火墙和代理允许通过 443 端口建立长时 WebSocket 连接，且不会因短暂空闲而超时或被强制重置。
- [ ]容量监控：对安全设备的 CPU、内存和吞吐量进行监控；当持续高负载可能导致延迟或数据包丢失时，系统会触发警报。
- [ ]出站规则：出站规则明确允许 Tulip 的 IP 范围/主机名（按花园标识符），包括资产存储端点（S3/Blob）。
- [ ]故障开放行为：在可能的情况下，Tulip 流量配置为“故障开放”（或显示明确且被记录的错误），而非静默丢弃数据包。
- [ ]变更控制：对防火墙/代理配置的任何可能影响 Tulip 的变更均会受到追踪，且理想情况下应在变更窗口期间通过 https://your-account.tulip.co/networkCheck 进行测试。
弹性应用架构
本节说明开发人员如何缓解基础设施风险。
开发者必须设计出能够抵御间歇性网络问题的应用程序。确保留有应对网络延迟和轻微平台性能下降的余量至关重要。请使用自动化功能（并在可能的情况下使用函数）。
- **优先处理 Tulip 表写入：对于所有关键数据捕获，请在触发器中优先使用原生 Tulip 表的“Create Record”或“Store”**操作。这些操作对网络短暂中断具有更强的容错能力，并内置重试逻辑（在 LTS15 中最长可达 2 分钟）。
- **尽量降低事件发生率：**审查您的应用设计。如果操作员在 2 分钟的网络中断期间可能合理地生成 100 个事件（例如扫描），则您的架构面临高风险。请考虑对输入进行批处理或简化工作流。
- **遵循性能最佳实践：**请遵守此处关于高性能应用的文档指南。高频调用会导致平台不堪重负，从而产生类似网络状况不佳的内部延迟。
另请参阅：通过“虚拟”Tulip 机器实现基于事件的应用触发
检查清单
- [ ]优先使用表：所有关键数据捕获（扫描、操作员决策、测量值）均首先写入Tulip 表。
- [ ]操作员触发器中不包含耗时的 API 调用：面向操作员的触发器不包含长时间运行的Connector Functions 或复杂的外部 API 逻辑。
- [ ]解耦模式：在可能的情况下，建议优先使用自动化流程进行外部API调用。
- [ ]**状态字段：**处理表使用清晰的状态字段（待处理、处理中、已处理、错误），以便对失败操作进行重试或排查。
- [ ]受控事件速率：应用设计不允许操作员产生持续的事件速率，以免在短暂中断期间填满队列（参见上文关于中断的计算）。
- [ ]定时器和循环：除非绝对必要且经过验证，否则定时器触发器和循环不会以不必要的短间隔（例如每 1-5 秒）运行。
- [ ]连接器错误处理：可能因网络问题而失败的Connector Functions 具备错误处理和重试机制（最好通过自动化实现，而非操作员触发）。
- [ ]性能最佳实践：应用程序应遵循 Tulip 针对高性能应用程序的最佳实践。
技术配置与故障排除
如果您的网络未达到上述量化的要求，或者您遇到疑似与网络相关的性能问题，请按照我们的详细指南中的步骤操作。该指南提供了一个按优先级排序的流程图，用于诊断和解决网络性能问题，内容涵盖从基础检查到高级数据包级别的分析。
点击此处查看完整的网络故障排除指南。
网络和 WebSocket 测试工具
Tulip 广泛使用 WebSocket（一种长连接）来实现实时更新。这些 WebSocket 通过 443 端口使用 SSL 加密。某些代理不支持此类连接，而某些网络监控工具可能需要明确允许此类连接。请参阅上文了解兼容性信息。
我们提供了一个简单的工具，可帮助您测试网络连接的延迟和 WebSocket 兼容性：
- https://your-account.tulip.co/networkCheckOR
- https://your-account.dmgmori-tulip.com/networkCheckOR
- https://your-account.tulip-serendie.com/networkCheck
调试与持续监控检查清单
- [ ]初始测试：对于每个新站点，在正常生产负载下运行 https://your-account.tulip.co/networkCheck（或 DMG MORI / Serendie 的 URL）以及您自己的诊断工具，持续时间至少 10-15 分钟。
- [ ]记录指标：采集平均、最小和最大延迟、抖动以及任何观察到的数据包丢失情况；验证这些指标是否符合本文中的阈值要求。
- [ ]峰值负载测试：在工厂网络已知的峰值负载时段（如换班、大批量处理）重复进行测试，以确保系统在高负载下的稳定性。
- [ ]变更后的回归测试：在对网络、Wi-Fi、防火墙或代理配置进行任何可能影响 Tulip 的重大更改后，请重新运行测试。
- [ ]基准记录：将测试结果（截图或导出文件）作为验证/调试记录的一部分保存。
- [ ]定期重新验证：针对关键站点，或在部署事件发生率更高的新应用时，安排定期（例如每季度）重新测试。
您找到想要的内容了吗？
您也可以访问community.tulip.co发布您的问题，或查看其他人是否遇到过类似问题！