选TCP还是UDP取决于日志场景瓶颈：UDP低延迟高吞吐但丢包率高，适合内部轻量设备；TCP可靠但有连接开销，适合需保序防丢的生产环境；RELP基于TCP增强确认机制，适用于金融等零丢失要求场景。
选 TCP 还是 UDP，关键看你的日志场景卡在哪——不是“哪个更好”，而是“哪个更匹配当前瓶颈”。性能问题往往藏在协议特性与实际部署条件的错配里。
UDP 适合低延迟、高吞吐但容忍丢包的场景
UDP 没连接开销、头部仅 8 字节、无确认重传，实测比 TCP 快 15–20%，端到端延迟低 30ms 以上。适合内部网络中轻量设备（如嵌入式传感器、IoT 终端）高频发日志，且日志本身价值不高、丢失几条不影响整体判断的情况。
- 典型配置：用
*.* @192.168.1.100:514（单个 @ 符号）启用 UDP 转发 - 必须确保防火墙放行 UDP 514 端口，且接收端 rsyslog 已加载
$ModLoad imudp并运行$UDPServerRun 514 - 不建议用于跨公网、高丢包率链路或审计类日志——UDP 不会告诉你哪条丢了
TCP 解决丢包和乱序，但引入连接与确认开销
TCP 提供有序、可靠交付，自带流量控制与拥塞避免，能应对网络抖动。当出现日志堆积、重复、缺失或顺序错乱时，大概率是 UDP 在丢包，换 TCP 往往立竿见影。不过它三次握手、ACK 机制、滑动窗口管理会增加 CPU 和内存压力，尤其在每秒数千条日志的并发下，连接数可能成为新瓶颈。
- 典型配置：用
*.* @@192.168.1.100:514（双 @ 符号）启用 TCP 转发 - 接收端需加载
$ModLoad imtcp并启用$InputTCPServerRun 514 - 注意调整系统级参数：如
net.core.somaxconn、net.ipv4.tcp_max_syn_backlog，避免连接队列溢出
RELP 是 TCP 的增强版，适合关键业务日志
RELP 基于 TCP，但增加了反向确认通道——发送端能明确知道某条日志是否被服务器成功写入磁盘，而非仅“抵达 TCP 缓冲区”。它解决了 TCP 断连时“消息是否落地”的歧义，特别适用于金融、支付、合规等不允许日志丢失的场景。缺点是客户端和服务端都需 RELP 支持（rsyslog ≥8.0），部署稍复杂。
- 发送端配置示例：
*.* :omrelp:192.168.1.100:20514 - 服务端需加载
$ModLoad omrelp和$ModLoad imrelp，并监听 RELP 端口（非 514） - 不推荐在资源受限的小型设备上启用，因 RELP 协议解析开销高于原生 TCP
真实瓶颈常不在协议层，而在配套配置
协议只是传输管道，真正压垮性能的往往是下游环节：rsyslog 默认使用同步写入，每条日志都 fsync 到磁盘；日志模板含大量解析字段（如 JSON 解析、正则提取）；或远程服务器磁盘 I/O 已饱和。这些都会让 TCP 或 UDP 都变慢，甚至掩盖协议差异。
- 先检查
rsyslog.conf是否启用了$ActionFileEnableSync off（异步写入） - 用
rsyslogd -N1验证配置语法，并观察启动日志中的性能提示 - 用
ss -s和netstat -s | grep -i "packet retrans"查看实际丢包与重传率，比理论选型更有说服力
