叠加之后还是卡：全光网出口瓶颈在带宽还是在连接数

晚上八点，酒店前台又来报修：新网页刷不开，收银偶尔超时，可打开测速软件，出口带宽明明还剩一大截。运维把几条宽带又查了一遍，灯都亮、单线测速都达标，愣是找不出卡在哪。带宽没跑满却还在卡，多半不是带宽的问题，是连接数先见了底。这一篇不急着加线，先给一套排查顺序。

一、接着测单线，先把线路本身排除掉

排查起步不是看总带宽，是把每条外线单独拎出来测。单台终端逐条接、逐条测速与试业务，确认每条线自己的通断、时延、上行都正常。

叠加扩的是总量，救不了一条本身就在抖的线；几条线里只要有一条质量不稳，走在它上面的业务照样卡。这一步还能顺带看清一个常被忽略的事实：几条线是不是同一根入户光纤分出来的，WAN 口是不是分属不同网段与 IP。线没排干净，后面的判断都立在流沙上。

二、看并发终端与会话量，别只盯兆数

单线都正常，就数"同时在跑多少对话"。一个终端连上 WiFi 后，网页、IM、系统更新、后台心跳会同时挂着一批会话，终端一多，出口要维护的并发会话量就会成倍涨。

带宽是水管，连接数是服务员——水管再粗，服务员不够，新来的请求照样没人接。这里有个很准的判别：新连接建不起来、老连接还能用——新网页打不开、微信一直转圈、前台偶尔超时，已经打开的页面却还能刷，测速软件偏偏显示带宽没跑满。这不是带宽瓶颈，用测速是看不出来的，是典型的连接数瓶颈。

三、看每条线的会话上限，把会话摊匀

每条外线自带一份 NAT 会话表，能同时维持的连接数有限，还受光猫、路由器与运营商侧每用户会话上限一起约束。家宽、商宽、专线的会话余量本就不在一个档上，便宜线的会话表往往先满。这时候如果调度只算"这条线还剩多少兆"、不算"还能接多少会话"，分到便宜线上的请求就会集体超时，成了"加了线反而更卡"。正确做法是带宽与连接数一起叠：按会话数摊到各条线上，每条都留余量，不让哪条线先撑爆。会话摊匀之外，还要核算出口网关自身的 NAT 会话数、DNS 处理、认证与日志处理能力——网关自己也是一台设备，别让它反过来成了瓶颈。

四、看业务类型，最后才怀疑带宽不够

再用 DPI 认业务看卡的是全体还是某一类：只有会议、收银这类长连接卡，多半是线路分配与会话保持没配好；全员一起慢，才回头看总带宽够不够。

一条连接从头到尾走一条线，去回同路，配合 DNS 解析跟着出口走，会议、收银、VPN 这些绑源 IP 的业务才不会一换线就重新认证。

智慧光迅的全光网多线汇聚方案把上面几步直接落成配置：外线带宽与外线连接数一起叠，按会话数把并发摊匀到各条线路、每条留余量；DPI 识别到应用级、链路质量探测、会话保持、DNS 跟出口、关键业务带宽预留一并纳入汇聚策略。按规模在融合路由、梦想网关两档之间选型，路由、交换、无线、电话、流控与安全防护一体化承载，少一层对接就少一类瓶颈——一体化不是把能力圈死在某台设备上，而是让会话、认证、转发在同一套体系里跑顺。把这些都排完，若确属总带宽不足，再一根一根加线也不迟；顺序反了，钱就花在不是瓶颈的地方了。

叠加之后还是卡，别急着加兆数。按先测单线、再看并发与会话量、再看每条线会话上限、再看业务类型、最后才怀疑带宽的顺序走一遍，多数"测速没跑满却卡"的答案都落在连接数上。智慧光迅的全光网多线汇聚方案带宽与连接数一起叠、会话摊匀、策略配齐，出口网关自身的会话与 DNS 能力按现场勘测与设备规格核算，让扩容的钱花在真正的瓶颈上。

FAQ

Q：怎么快速分辨是带宽不够还是连接数见底？

A：看测速与用户感知是否背离——带宽没跑满却新连接建不起来、老连接还能用，指向连接数；测速贴顶、全员一起慢，才更像带宽不足。

Q：加一条便宜宽带能解吗？

A：未必。若调度只按带宽比例分流，便宜线的会话表先满，分过去的请求仍会超时；要按会话数摊匀、每条留余量，并核算网关自身会话与 DNS 处理能力，具体按现场勘测与设备规格核算。