363 与隧道中的 RSVP
363 的登记名是 rsvp-tunnel，旧写法 rsvp_tunnel。RSVP 是 IP 层的资源预留协议（IP 协议号 46），让主机或路由器为特定流量预留带宽、时延等服务质量指标。问题在于两端若通过隧道（IP-in-IP、GRE 等）互联，隧道中间节点看不到内层报文里的 RSVP 信令，资源预留会断链。RFC 2746（RSVP over IP Tunnels）规定了隧道场景下传递与处理 RSVP 的规程，363 就是为这类部署登记的名称。它属于 QoS 专有场景，主机上的普通应用不会用到。
基本信息
| 服务名 | rsvp-tunnel（旧名 rsvp_tunnel，互为别名） |
|---|---|
| 传输层 | TCP/UDP |
| 标准 | RFC 2746（隧道中的 RSVP 规程） |
| 关联协议 | RSVP 使用 IP 协议号 46 |
| 现状 | QoS 专用场景，通用网络少见 |
典型使用场景
- QoS 架构核查：确认网络是否还在使用 RSVP 预留，或已改用标记与流量工程方案
- 隧道排障：端到端预留失败时检查隧道终结点是否按 RFC 2746 处理信令
- 资产台账：登记承载 QoS 的老设备与端口，避免升级时漏改
- 安全评估：RSVP 信令可能被伪造用于耗尽资源，需限制可信来源
- 架构演进规划：把专用预留迁移到差异化服务或流量工程的实际评估
RSVP 相关端口
| 端口 | 名称 | 场景 |
|---|---|---|
| 46 | rsvp | IP 层资源预留协议本身的登记 |
| 363 | rsvp-tunnel | 隧道中的 RSVP 信令（RFC 2746） |
| 1698/1699 | rsvp-encap-1/2 | IANA 登记的封装端口 |
核查与定位
核查与定位
ss -lntu | grep -E ':(46|363|1698|1699) ' # 对照几个相关端口是否在监听
getent services rsvp-tunnel # 名称登记
sudo lsof -i :363 # 占用进程
# QoS 排障抓包要在隧道终结设备上做，主机侧抓不到内层信令
ip -d link show # 核对隧道与封装接口类型先分清 QoS 模型：RSVP 是主机或路由器向网络申请预留，信令走控制面；MPLS 流量工程与差异化服务走的是另一套思路。主机上看到应用监听该端口，通常说明有自研程序占用了这个名字。
隧道场景的核查要点：确认设备用的是 IP-in-IP 还是 GRE，再对照 RFC 2746 的封装要求；两端配置不对称是这类故障最常见的来源。