neko-rooms 网络原理揭秘从 SDP 协商到 UDP 端口转发的完整链路【免费下载链接】neko-roomsSelfhosted collaborative browser - room management for n.eko项目地址: https://gitcode.com/gh_mirrors/ne/neko-roomsneko-rooms 是一个基于 n.eko 的自托管协同浏览器房间管理系统它把 WebRTC 实时流、Docker 容器调度和 UDP 端口转发串成一条完整链路。本文用通俗的语言拆解 neko-rooms 网络原理带你理解从你在浏览器点开链接、完成 SDP 协商到数据包最终通过宿主机的 UDP 端口转发进入容器房间的每一步无论你是新手还是自托管玩家都能看懂。一图看懂 neko-rooms 的整体网络架构先建立整体印象neko-rooms 负责管房间n.eko 负责跑浏览器。数据流大致是用户浏览器访问房间 URL如https://你的域名/房间名/请求经反向代理Traefik 或 neko-rooms 内置代理到达房间容器浏览器与容器内的 n.eko 服务通过WebRTC进行 SDP 协商协商成功后音视频和屏幕画面走UDP 端口实时传输核心概念为什么协同浏览器需要 UDP 端口池n.eko 依赖 WebRTC 传输屏幕画面而 WebRTC 的底层传输是 UDP。为了让每个房间都能对外提供服务neko-rooms 在宿主机上划出一段动态端口范围EPREphemeral Port Range默认是59000-59999一共 1000 个可用端口相关配置见 internal/config/room.go。端口池可按需调整启动参数--epr可以改范围端口池按房间切分互不干扰所有分配都记录在 Docker 容器标签里方便随时查询房间创建时如何分配 UDP 端口当你在管理界面新建房间并填写最大连接数后neko-rooms 会调用allocatePorts为这个房间分配一段连续的 UDP 端口实现代码在 internal/room/ports.go扫描当前所有已占用端口区间排序后找空闲段若设置最大连接数为 5就分配 5 个连续端口如59000-59004超出端口池上限时返回端口不足错误如果开启了Mux 多路复用模式则整个房间只需要 1 个 UDP 端口 1 个 TCP 端口所有用户的连接都复用在同一个端口上大幅节省端口资源。环境变量如何把端口信息传递给 n.eko端口分配完成后neko-rooms 通过环境变量把网络配置注入房间容器见 internal/types/room_api_v2.go环境变量作用NEKO_EPR59000-59004普通模式下房间可用的 UDP 端口区间NEKO_UDPMUX/NEKO_TCPMUXMux 模式下复用的 UDP/TCP 端口NEKO_NAT1TO1指定 NAT 后的公网 IP 地址NEKO_ICELITE启用 ICE Lite 模式只做应答方NEKO_PROXY开启代理支持配合反向代理使用其中NEKO_NAT1TO1是关键配置如果你的服务器在 NAT 后面必须把公网 IP 写进去否则浏览器拿到的是内网地址SDP 协商出来的 ICE 候选根本无法连通。SDP 协商与 ICE 候选连接是如何建立的WebRTC 的建立过程简单说就是交换名片 选路SDP 协商浏览器和 n.eko 交换 SDP含编解码器、带宽、ICE 候选地址ICE 候选收集n.eko 作为 ICE Lite 端把服务器IP NEKO_EPR 分配的端口作为候选地址告诉浏览器连通性检查浏览器用 STUN 探测候选地址找到能通的路径建立连接打通后屏幕画面、声音、鼠标键盘事件都通过这条 UDP 通道实时往返由于 n.eko 运行在 Docker 容器内宿主机上的端口映射0.0.0.0:59000/udp让 UDP 数据包能顺利穿透进容器这就是UDP 端口转发在这条链路中的核心作用。从浏览器到房间反向代理与路径匹配访问房间时请求怎么找到正确的容器neko-rooms 支持两种方式见 internal/proxy/manager.goTraefik 模式为每个容器生成PathPrefix或Host路由规则内置代理模式通过m1k1o.neko_rooms.proxy.path等标签注册路径用前缀树prefix tree做精确匹配代理层还实现了房间等待机制房间未就绪时显示等待页就绪后自动刷新进入体验很顺滑。房间生命周期Docker 事件如何驱动网络状态网络状态不是静态的neko-rooms 通过监听 Docker 事件实时感知房间变化见 internal/room/events.gocreate登记房间占好端口start轮询容器内 8080 端口探测 n.eko 服务是否就绪health_status: healthy标记房间可用代理开始转发流量stop/destroy释放端口移除路由常见问题与排查思路连不上房间检查NEKO_NAT1TO1是否填了公网 IP提示端口不足在 internal/config/room.go 中调大--epr范围大量用户加入慢开启 Mux 模式减少端口占用和连接数请求 502确认容器已 healthy且代理标签配置正确写在最后neko-rooms 的网络链路并不神秘Docker 事件驱动端口分配环境变量传递网络配置反向代理负责路由WebRTC 负责实时传输四者环环相扣。理解了这条链路无论是排查连接问题还是优化端口规划你都能事半功倍。【免费下载链接】neko-roomsSelfhosted collaborative browser - room management for n.eko项目地址: https://gitcode.com/gh_mirrors/ne/neko-rooms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 neko-rooms 网络原理揭秘：从 SDP 协商到 UDP 端口转发的完整链路
neko-rooms 网络原理揭秘从 SDP 协商到 UDP 端口转发的完整链路【免费下载链接】neko-roomsSelfhosted collaborative browser - room management for n.eko项目地址: https://gitcode.com/gh_mirrors/ne/neko-roomsneko-rooms 是一个基于 n.eko 的自托管协同浏览器房间管理系统它把 WebRTC 实时流、Docker 容器调度和 UDP 端口转发串成一条完整链路。本文用通俗的语言拆解 neko-rooms 网络原理带你理解从你在浏览器点开链接、完成 SDP 协商到数据包最终通过宿主机的 UDP 端口转发进入容器房间的每一步无论你是新手还是自托管玩家都能看懂。一图看懂 neko-rooms 的整体网络架构先建立整体印象neko-rooms 负责管房间n.eko 负责跑浏览器。数据流大致是用户浏览器访问房间 URL如https://你的域名/房间名/请求经反向代理Traefik 或 neko-rooms 内置代理到达房间容器浏览器与容器内的 n.eko 服务通过WebRTC进行 SDP 协商协商成功后音视频和屏幕画面走UDP 端口实时传输核心概念为什么协同浏览器需要 UDP 端口池n.eko 依赖 WebRTC 传输屏幕画面而 WebRTC 的底层传输是 UDP。为了让每个房间都能对外提供服务neko-rooms 在宿主机上划出一段动态端口范围EPREphemeral Port Range默认是59000-59999一共 1000 个可用端口相关配置见 internal/config/room.go。端口池可按需调整启动参数--epr可以改范围端口池按房间切分互不干扰所有分配都记录在 Docker 容器标签里方便随时查询房间创建时如何分配 UDP 端口当你在管理界面新建房间并填写最大连接数后neko-rooms 会调用allocatePorts为这个房间分配一段连续的 UDP 端口实现代码在 internal/room/ports.go扫描当前所有已占用端口区间排序后找空闲段若设置最大连接数为 5就分配 5 个连续端口如59000-59004超出端口池上限时返回端口不足错误如果开启了Mux 多路复用模式则整个房间只需要 1 个 UDP 端口 1 个 TCP 端口所有用户的连接都复用在同一个端口上大幅节省端口资源。环境变量如何把端口信息传递给 n.eko端口分配完成后neko-rooms 通过环境变量把网络配置注入房间容器见 internal/types/room_api_v2.go环境变量作用NEKO_EPR59000-59004普通模式下房间可用的 UDP 端口区间NEKO_UDPMUX/NEKO_TCPMUXMux 模式下复用的 UDP/TCP 端口NEKO_NAT1TO1指定 NAT 后的公网 IP 地址NEKO_ICELITE启用 ICE Lite 模式只做应答方NEKO_PROXY开启代理支持配合反向代理使用其中NEKO_NAT1TO1是关键配置如果你的服务器在 NAT 后面必须把公网 IP 写进去否则浏览器拿到的是内网地址SDP 协商出来的 ICE 候选根本无法连通。SDP 协商与 ICE 候选连接是如何建立的WebRTC 的建立过程简单说就是交换名片 选路SDP 协商浏览器和 n.eko 交换 SDP含编解码器、带宽、ICE 候选地址ICE 候选收集n.eko 作为 ICE Lite 端把服务器IP NEKO_EPR 分配的端口作为候选地址告诉浏览器连通性检查浏览器用 STUN 探测候选地址找到能通的路径建立连接打通后屏幕画面、声音、鼠标键盘事件都通过这条 UDP 通道实时往返由于 n.eko 运行在 Docker 容器内宿主机上的端口映射0.0.0.0:59000/udp让 UDP 数据包能顺利穿透进容器这就是UDP 端口转发在这条链路中的核心作用。从浏览器到房间反向代理与路径匹配访问房间时请求怎么找到正确的容器neko-rooms 支持两种方式见 internal/proxy/manager.goTraefik 模式为每个容器生成PathPrefix或Host路由规则内置代理模式通过m1k1o.neko_rooms.proxy.path等标签注册路径用前缀树prefix tree做精确匹配代理层还实现了房间等待机制房间未就绪时显示等待页就绪后自动刷新进入体验很顺滑。房间生命周期Docker 事件如何驱动网络状态网络状态不是静态的neko-rooms 通过监听 Docker 事件实时感知房间变化见 internal/room/events.gocreate登记房间占好端口start轮询容器内 8080 端口探测 n.eko 服务是否就绪health_status: healthy标记房间可用代理开始转发流量stop/destroy释放端口移除路由常见问题与排查思路连不上房间检查NEKO_NAT1TO1是否填了公网 IP提示端口不足在 internal/config/room.go 中调大--epr范围大量用户加入慢开启 Mux 模式减少端口占用和连接数请求 502确认容器已 healthy且代理标签配置正确写在最后neko-rooms 的网络链路并不神秘Docker 事件驱动端口分配环境变量传递网络配置反向代理负责路由WebRTC 负责实时传输四者环环相扣。理解了这条链路无论是排查连接问题还是优化端口规划你都能事半功倍。【免费下载链接】neko-roomsSelfhosted collaborative browser - room management for n.eko项目地址: https://gitcode.com/gh_mirrors/ne/neko-rooms创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考