网络性能四大指标：带宽、时延、抖动、丢包率协同分析

1. 网络性能四大关键指标带宽、时延、抖动和丢包率——不是概念是真实业务的“血压计”你有没有遇到过这样的情况视频会议里同事的脸突然卡成马赛克但网速测试显示“100Mbps满格”远程桌面操作鼠标拖拽像在泥潭里划船ping值却只有12ms直播推流明明开了千兆光纤观众端却频繁提示“缓冲中”……这些不是玄学而是网络性能四大核心指标——带宽、时延、抖动、丢包率——在真实业务场景中集体“报警”的典型表现。它们不是教科书里抽象的术语而是像血压计之于医生、示波器之于电子工程师那样直接决定一个应用能否跑通、是否流畅、会不会崩溃的底层生命体征。我做过三年网络质量保障支撑过教育直播平台、远程医疗系统和工业IoT数据采集项目最深的体会是只看带宽等于只量体温不查心电图只盯时延就像只测血压不看血氧饱和度。这四个指标彼此耦合、相互影响单独优化任何一个都可能适得其反。比如盲目提升带宽若底层路由策略没调好抖动反而更大强行压低时延若牺牲了重传机制丢包率就飙升。本文不讲定义复述而是从一线实测现场出发拆解这四个指标在真实链路中如何被测量、如何被干扰、如何被协同优化。无论你是前端开发者调试WebSocket连接还是运维工程师排查CDN回源异常或是产品经理评估新功能的网络兼容性都能在这里找到可直接套用的判断逻辑和实操方法。全文所有案例、参数、命令、工具配置均来自某高校在线实验平台的真实压测记录已脱敏处理可直接复现。2. 四大指标的本质解析为什么它们必须一起看2.1 带宽不是“管道粗细”而是“单位时间能通过多少有效载荷”很多人把带宽简单理解为“网线有多粗”这是最大误区。带宽Bandwidth在TCP/IP语境下特指物理链路或协议栈在理想无损条件下单位时间内能传输的最大数据量单位是bpsbit per second。但关键在于“理想无损”——现实中根本不存在。我曾用iperf3在两台千兆服务器间直连测试理论带宽1Gbps实测稳定吞吐仅850Mbps。为什么因为以太网帧头14字节、IP头20字节、TCP头20字节、校验和4字节等协议开销占用了约5%带宽更关键的是TCP滑动窗口机制、ACK确认延迟、接收方缓冲区大小都会动态限制实际吞吐。所以带宽从来不是静态值而是链路能力上限与协议效率、应用行为共同作用的动态结果。举个生活化类比带宽像高速公路的车道数但实际车流量不仅取决于车道数还取决于红绿灯配时协议机制、司机反应时间时延、车辆是否频繁变道抖动、是否有车辆抛锚占道丢包。某次教育平台升级后学生反馈课件加载慢我们第一反应是带宽不足结果发现CDN节点到学校出口的链路带宽充足问题出在校园防火墙对HTTP/2连接数做了严苛限制导致大量并发请求排队——这本质是协议层资源调度问题而非物理带宽瓶颈。因此诊断带宽问题绝不能只跑个speedtest必须结合应用层协议行为分析。2.2 时延不是“单程飞行时间”而是“端到端全链路响应周期”时延Latency常被误认为就是ping值。但ping用的是ICMP协议而真实业务走的是TCP或UDP。两者路径可能不同某些运营商会对ICMP做优先级降级导致ping值虚低而TCP建连三次握手、TLS握手通常2-3轮RTT、应用层协议交互如HTTP GET响应会叠加多层时延。真正的业务时延是从用户触发动作如点击按钮到收到有效响应如页面渲染完成的完整耗时。我们曾为某远程手术指导系统做网络评估要求端到端时延≤50ms。实验室环境ping值15ms但实际手术视频流首帧显示耗时达120ms。排查发现手术终端使用H.264编码关键帧I帧间隔设为2秒而网络抖动导致首个I帧丢失解码器必须等待下一个I帧才能开始渲染——这120ms里有80ms是编码策略缺陷30ms是网络传输10ms是终端解码。所以时延必须分层测量L1物理层光模块收发延迟、L2/L3转发延迟交换机/路由器查表、L4传输层TCP队列等待、L7应用层服务端处理编码。工具上单纯ping不够需用mtrmtr -r -c 100 target.com看每跳延迟分布对TCP应用用tcpdump抓包分析SYN/SYN-ACK/ACK时间戳计算各阶段耗时对Web应用用Chrome DevTools的Network面板看TTFBTime to First Byte和Content Download时间。记住时延不是标量是向量——它有方向上行/下行、有层级各协议栈、有上下文不同业务动作。2.3 抖动不是“时延忽高忽低”而是“时延变化率对实时业务的致命冲击”抖动Jitter常被简化为“ping值波动大”这完全误解了它的危害本质。抖动定义为连续数据包到达时间间隔的统计方差通常用标准差表示单位是毫秒。它的杀伤力不在于绝对值大小而在于破坏实时业务的时间同步机制。以VoIP通话为例语音编码器每20ms生成一个RTP包接收端按固定20ms间隔播放。如果网络抖动导致第1包延迟30ms到达第2包延迟50ms到达第3包延迟10ms到达——到达间隔变成20ms、-40ms、-40ms接收端缓冲区无法平滑输出必然产生断续或静音。更隐蔽的问题是抖动会触发TCP的拥塞控制算法如CUBIC导致发送窗口剧烈收缩进一步放大时延和丢包。我们曾遇到某工业传感器数据上报异常设备每秒上报10条JSON数据但监控显示数据到达时间戳呈“脉冲式”聚集如1秒内到50条随后3秒无数据。抓包分析发现企业出口防火墙启用了深度包检测DPI对小包128字节做额外特征分析导致小包处理时延随机增加20-80ms而大包含多个JSON则快速放行——这就是典型的由中间设备引入的、与包长强相关的抖动。因此测量抖动必须用专业工具Wireshark中过滤RTP流右键“Protocol Preferences”→“RTP”→“Analyze RTP Stream”自动生成抖动直方图或用iperf3的-jitter选项iperf3 -c server -u -b 10M -l 1200 -J获取UDP流抖动统计。关键提醒抖动容忍度与业务类型强相关——文件下载可容忍100ms抖动而金融高频交易要求抖动100μs。2.4 丢包率不是“数据包消失”而是“网络健康度的终极判据”丢包率Packet Loss Rate常被当作“网络差”的代名词但它的深层意义远超于此。丢包率发送包数-接收包数/发送包数×100%看似简单但丢包位置、丢包模式、丢包原因决定了它是可恢复的“毛刺”还是不可逆的“系统性崩溃”。TCP协议有重传机制少量丢包1%可通过SACK选择性确认快速恢复用户几乎无感但若丢包集中在关键帧如视频I帧、游戏状态同步包或丢包率持续2%TCP会大幅降低发送窗口吞吐骤降。更危险的是UDP丢包DNS查询丢包直接导致域名解析失败QUIC协议虽内置前向纠错但高丢包下仍会退化为TCP行为。我们曾为某在线考试系统做压力测试模拟5000人同时提交试卷。系统在98%成功率下运行平稳但当丢包率从0.1%升至0.5%时提交失败率飙升至15%。根因分析发现考试服务器集群使用Kubernetes Service而某个Node节点的网卡驱动存在bug在高并发下偶发DMA缓冲区溢出导致特定时间段内该节点所有出向包丢弃——这是硬件层丢包非网络拥塞所致传统QoS策略完全无效。因此丢包诊断必须分层用ethtool -S eth0检查网卡驱动级丢包rx_missed_errors用netstat -s | grep -i retrans看TCP重传统计用tcpreplay重放抓包文件隔离测试特定链路。记住丢包率是结果不是原因它像发烧背后可能是病毒链路故障、炎症路由环路、还是免疫系统紊乱配置错误。3. 四大指标的协同关系与实测验证3.1 带宽与时延的“虚假繁荣”陷阱为什么千兆宽带看不了4K直播带宽和时延常被误认为正相关——带宽越大时延越低。但真实网络中二者关系复杂且常呈负相关。我们设计了一个对照实验在某高校实验室用两台服务器A、B通过万兆交换机直连部署iperf3服务端B和客户端A。首先用iperf3 -c B -t 30 -P 1 测试单流TCP吞吐结果为9.2Gbps平均时延mtr测0.08ms。接着启动100个并行流iperf3 -c B -t 30 -P 100总吞吐升至9.8Gbps但单流平均时延飙升至1.2ms。为什么因为多流竞争交换机内部缓存和背板带宽每个数据包在交换芯片队列中等待时间增加。更关键的是当我们在链路中加入一台QoS策略严格的防火墙模拟企业出口设置带宽上限为1Gbps再测单流吞吐降至950Mbps但时延反而从0.08ms降到0.05ms——因为防火墙的流量整形Traffic Shaping强制平滑了突发流量减少了队列堆积。这个实验揭示了核心规律带宽提升在无拥塞时降低时延但在拥塞场景下会加剧队列等待反而抬高时延而合理的带宽限制如QoS限速可能通过抑制突发意外改善时延稳定性。因此给业务分配带宽时不能只看峰值需求更要分析流量模型是恒定流如视频监控还是突发流如网页浏览恒定流适合保证带宽Guaranteed Bandwidth突发流则需预留突发带宽Burst Bandwidth并配合RED随机早期检测等主动队列管理机制。3.2 抖动与丢包的“蝴蝶效应”一个毫秒级抖动如何引发雪崩式失败抖动和丢包看似独立实则互为因果。我们复现了一个经典场景某在线协作白板应用用户反馈“笔迹不同步”。抓包分析显示客户端到服务器的UDP心跳包每500ms一个丢包率仅0.3%但抖动标准差高达45ms。深入追踪发现心跳包丢失本身影响不大但高抖动导致服务器端的心跳超时检测Timeout3×RTT频繁误判。服务器将短暂抖动误认为客户端离线主动关闭其WebSocket连接触发客户端重连流程。重连期间用户所有绘图操作被丢弃造成“笔迹消失”。更糟的是重连风暴Reconnection Storm使服务器连接数瞬间翻倍CPU飙升进一步恶化网络服务质量形成正反馈循环。我们用tcTraffic Control工具在服务器端模拟此场景tc qdisc add dev eth0 root netem delay 20ms 10ms distribution normal即添加20ms均值、10ms标准差的正态分布延迟。结果原始丢包率0%但应用失败率从0%升至35%。当我们将抖动标准差降至5mstc qdisc change dev eth0 root netem delay 20ms 5ms失败率回落至2%。这个案例证明对于依赖定时器的应用抖动是比丢包更隐蔽的杀手它不直接摧毁数据而是通过破坏时间确定性间接触发系统级连锁故障。解决方案不是增加带宽而是1客户端采用指数退避重连Exponential Backoff2服务器心跳超时改为基于滑动窗口的动态计算如取最近10次RTT的P95值3关键业务改用TCPKeepalive利用其更稳健的保活机制。3.3 四指标联合诊断一次真实的教育平台卡顿根因分析某高校在线实验平台上线后学生反馈“电路仿真软件卡顿严重”。我们按四指标框架进行系统排查第一步带宽基线测试用iperf3 -c cdn-server -t 60 测得下行带宽850Mbps千兆链路正常排除带宽瓶颈。第二步时延分层定位mtr -r -c 50 cdn-server显示第3跳校园网出口路由器平均延迟42msP95延迟120ms远高于其他跳均5mstcpdump抓取HTTPS建连SYN到SYN-ACK耗时45ms确认问题在出口路由登录该路由器show interface GigabitEthernet0/1发现input queue drops计数每秒增长证实入口队列拥塞。第三步抖动与丢包关联分析在出口路由器镜像端口抓包用Wireshark分析RTP流抖动标准差达68ms且抖动峰值与input queue drops计数高峰完全同步统计丢包ICMP丢包率0.8%但TCP重传率高达5.2%说明丢包主要发生在TCP层与队列溢出一致。第四步协同优化实施调整出口路由器QoS为实验平台流量DSCPEF配置优先队列Priority Queue保证其最小带宽500Mbps启用WRED加权随机早期检测对非优先流量当队列长度70%时开始随机丢包避免尾部丢弃Tail Drop导致TCP全局同步客户端优化将仿真软件的UDP心跳间隔从200ms延长至500ms减少小包冲击。优化后P95时延降至25ms抖动标准差降至12msTCP重传率降至0.3%卡顿投诉归零。这个案例印证了单一指标优化是徒劳的必须将四指标视为一个动态系统——带宽是资源池时延是响应速度抖动是时间稳定性丢包率是健康度四者共同构成网络性能的“四维坐标系”。4. 实操工具链与参数配置详解4.1 基础测量Linux命令行三剑客的深度用法网络性能诊断的起点永远是命令行但多数人只停留在表面。以下是我在生产环境中打磨出的进阶用法ping不止于连通性测试标准用法ping -c 10 target只返回平均延迟。实战中需ping -c 100 -i 0.1 -s 1472 target发送100个包间隔0.1秒包长1472字节1500MTU-20IP-8ICMP1472逼近链路实际负载ping -c 100 -D target | awk {print $7} | cut -d -f2 | sort -n | head -10提取延迟值排序后取最低10个排除瞬时抖动干扰反映链路基础时延ping -c 100 -q target静默模式末尾汇总丢包率和延迟统计适合脚本集成。mtr网络路径的“CT扫描仪”mtr -r -c 50 target是基础但关键在解读关注“Loss%”列某跳丢包率高说明该节点或其上游链路有问题关注“Avg”和“StDev”列“Avg”突增且“StDev”也大表明该跳存在严重抖动高级技巧mtr --report-cycles 100 --interval 1 target mtr.log生成100次探测日志用Python脚本分析各跳延迟分布如P95、P99比单次报告更可靠。iperf3带宽与抖动的精准标尺TCP吞吐测试iperf3 -c server -t 60 -P 4 -w 2M-P 4启用4并行流模拟多用户-w 2M显式设置TCP窗口大小避免自动缩放干扰UDP抖动测试iperf3 -c server -u -b 100M -l 1200 -t 60 -J-u启用UDP-b 100M设定目标速率-l 1200指定包长模拟典型应用包-J输出JSON格式便于解析解析JSON结果iperf3 -c server -u -b 100M -l 1200 -t 60 -J | jq .intervals[].streams[0].jitter_ms | sort -n | tail -1提取最大抖动值。提示所有命令务必在业务低峰期执行避免测试流量本身成为拥塞源。UDP测试尤其谨慎建议先用10%带宽试测。4.2 深度分析Wireshark与tcpreplay的实战组合Wireshark是网络世界的“显微镜”但90%的用户只用它看包。我的工作流是Wireshark抓包 tcpreplay重放 自定义脚本分析。抓包策略不要tcpdump -i any而要用tcpdump -i eth0 -s 0 -w capture.pcap port 443 and host target.com限定接口、截全包、过滤端口和主机避免海量无关包对实时业务开启-G 300 -W 5参数每300秒生成一个新文件最多保留5个防止磁盘写满。Wireshark深度分析过滤TCP重传tcp.analysis.retransmission查看TCP流图右键TCP包 → “Follow” → “TCP Stream”再点“Graph a TCP Stream”生成时序图直观看到重传、乱序、零窗口等事件分析抖动过滤RTP流rtp右键 → “Prepare a Filter” → “Selected”然后“Statistics” → “IO Graphs”添加Y轴为rtp.time_delta即可绘制到达间隔直方图。tcpreplay重放与注入将抓包文件重放至测试环境tcpreplay -i eth0 -M 100 capture.pcap-M 100表示100倍速重放模拟高负载注入特定丢包tcpreplay-edit -e ip.src192.168.1.100,ip.dst192.168.1.200 -x 0.05 capture.pcap-x 0.05表示5%丢包率用于验证应用容错能力。注意tcpreplay重放需在隔离网络进行避免影响生产。重放前务必用tcpreplay --stats capture.pcap预览包数和时长。4.3 主动干预tcTraffic Control构建可控实验环境tc是Linux内核的流量控制工具堪称网络性能的“手术刀”。它能精确模拟任何网络损伤是验证四指标关系的黄金标准。基础队列规则# 清空现有规则 tc qdisc del dev eth0 root # 添加HTB分层令牌桶根队列限速100Mbps tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit # 添加子类为SSH流量端口22分配高优先级 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit ceil 100mbit tc filter add dev eth0 parent 1: protocol ip u32 match ip dport 22 0xffff flowid 1:10模拟核心损伤时延tc qdisc add dev eth0 root netem delay 50ms抖动tc qdisc add dev eth0 root netem delay 50ms 10ms distribution normal50ms均值10ms标准差丢包tc qdisc add dev eth0 root netem loss 2%组合损伤tc qdisc add dev eth0 root netem delay 50ms 10ms loss 2% duplicate 1%同时模拟时延、抖动、丢包、重复包。关键技巧使用tc qdisc show dev eth0实时查看规则用tc -s qdisc show dev eth0查看统计信息如dropped包数模拟完成后用tc qdisc del dev eth0 root彻底清除避免残留影响。实操心得tc规则生效极快但修改时需先删除再添加直接change可能不生效。模拟高抖动50ms时务必监控系统负载避免CPU被netem消耗过多。5. 常见问题与独家排查技巧实录5.1 “带宽测试满格业务却卡顿”——90%的误判源于测试方法错误这是最常被问到的问题。根源在于通用带宽测试工具如speedtest与真实业务流量模型不匹配。Speedtest用大块TCP流通常1MB测试而网页浏览是大量小包HTTP请求头1KB、视频流是固定包长RTP、IoT设备是超小包MQTT心跳100字节。我们的排查清单确认业务流量特征用iftop -P或nethogs实时观察业务进程的实际包长和频率针对性重放测试用tcpreplay重放真实业务抓包文件而非speedtest检查MTU路径ping -s 1472 -M do target.com若不通说明路径MTU1500需调整TCP MSSsysctl -w net.ipv4.tcp_base_mss1400排查中间设备企业防火墙/代理常对小包做深度检测导致时延激增用mtr看哪一跳延迟突增验证TCP栈参数sysctl net.ipv4.tcp_rmem和net.ipv4.tcp_wmem若接收/发送缓冲区过小如4096在高时延链路上会严重限制吞吐。我踩过的坑某次为教育平台优化反复测试iperf3都显示带宽充足直到用Wireshark抓取学生浏览器的HTTP/2流才发现Chrome对同一域名的并发连接数限制为6而课件加载需20个资源——这是应用层限制与网络带宽无关。解决方案是启用HTTP/2 Server Push或合并资源。5.2 “ping值很低但视频一直卡”——抖动才是实时业务的隐形杀手视频卡顿90%以上与抖动相关而非时延。排查抖动的独门技巧用Wireshark的“IO Graphs”功能过滤rtp.time_delta设置Y轴为“Max”X轴为“Time”观察到达间隔的峰谷。健康流应是平直线条如20ms±2ms卡顿时会出现尖峰如20ms→150ms计算“抖动容忍度”视频编解码器的Jitter Buffer大小是关键。H.264默认Jitter Buffer为200ms若网络抖动P95150ms缓冲区必然溢出。用ffprobe -v quiet -show_entries format_tagsduration input.mp4查看媒体文件关键帧间隔据此反推所需Jitter Buffer区分“网络抖动”与“终端抖动”在终端设备上运行stress-ng --cpu 8 --timeout 60s制造CPU压力再测视频若卡顿加剧说明是终端解码能力不足非网络问题验证QoS标记用tcpdump -i eth0 ip[1] 0xfc 0xe0抓取DSCPEF101110的包确认QoS策略是否真正生效。独家技巧在Linux终端用watch -n 1 cat /proc/net/dev | grep eth0实时监控网卡RX/TX错误计数rx_errors, tx_errors若这些值随抖动增大而增长说明是物理层问题如光纤衰减、网线接触不良。5.3 “丢包率1%但应用频繁断连”——丢包模式比丢包率更重要少量丢包不可怕可怕的是丢包模式。我们总结了三种高危丢包模式丢包模式特征描述典型影响排查方法周期性丢包每N秒固定丢包如每30秒丢1包NTP时间同步失败、心跳超时ping -c 300 -i 1 target.com | awk {print NR,$7} | grep time分析丢包时间戳规律突发性丢包短时间内集中丢包如1秒内丢10%TCP窗口崩溃、吞吐骤降tcpreplay -i eth0 -M 10 capture.pcap重放观察丢包是否随流量爆发出现关键帧丢包丢包集中在I帧或PSI/SI表视频/广播视频黑屏、音频中断Wireshark中过滤rtp rtp.marker1RTP marker bit置位检查I帧到达率根因定位流程用ethtool -S eth0检查网卡驱动级错误rx_missed_errors, tx_aborted_errors若驱动错误高升级网卡驱动或更换硬件若驱动正常用tcpdump抓包用tshark -r capture.pcap -qz io,stat,1,ip.addrtarget分析各IP的丢包分布若丢包集中在某IP检查该IP对应设备的ARP表ip neigh show和路由表ip route get target。实战案例某次丢包率0.5%但Websocket频繁断开抓包发现所有丢包都发生在SYN包TCP建连第一包。最终定位为云服务商安全组对SYN Flood攻击的防护策略过于激进将正常建连SYN误判为攻击。解决方案是调整安全组的SYN阈值或改用连接池复用长连接。5.4 “四指标都正常业务还是慢”——跳出网络层检查应用与协议栈当网络层指标全部达标问题往往藏在更高层。我们的“三层穿透法”L4传输层检查ss -i查看TCP连接的详细信息重点关注retrans重传次数、rto重传超时、rwnd接收窗口cat /proc/net/snmp | grep Tcp:查看TCP统计TcpRetransSegs值高说明重传频繁sysctl net.ipv4.tcp_congestion_control确认拥塞控制算法BBR比CUBIC在高时延链路上表现更好。L7应用层检查Web应用用curl -w curl-format.txt -o /dev/null -s http://target.com其中curl-format.txt包含time_namelookup、time_connect、time_starttransfer等字段分离DNS、建连、首字节时间数据库mysqladmin extended-status | grep -E Threads_connected|Slow_queries检查连接数和慢查询API服务用ab -n 1000 -c 100 http://target.com/api/Apache Bench压测对比QPS和错误率。协议栈调优启用TCP Fast Opensysctl -w net.ipv4.tcp_fastopen3减少建连时延调整TIME_WAITsysctl -w net.ipv4.tcp_fin_timeout30net.ipv4.tcp_tw_reuse1加速端口回收优化内存sysctl -w vm.swappiness1减少交换分区使用避免I/O阻塞。最后提醒所有sysctl调优需写入/etc/sysctl.conf并sysctl -p持久化且必须在业务低峰期测试避免参数不当引发新问题。我曾因将net.core.somaxconn设得过大导致内核内存碎片化反而降低了连接处理能力。6. 个人实操经验与延伸思考我在某高校网络中心驻场支持的三年里处理过上百起网络性能问题最深刻的体会是四大指标不是孤立的数字而是业务逻辑在网络空间的投影。比如一个在线考试系统其核心诉求是“确定性”——题目下发时间必须精确到毫秒级答案提交必须100%可靠。这时时延的P99值比平均值重要十倍丢包率必须趋近于零而带宽只需满足基本需求。相反一个视频点播平台核心是“吞吐”和“平滑性”可以容忍较高时延只要缓冲区够大但抖动必须严格控制否则缓冲区会频繁下溢卡顿或上溢延迟增大。因此没有普适的“好网络”只有匹配业务DNA的“对网络”。另一个被低估的维度是“时间尺度”。网络性能问题常具有时间局部性校园网在早8点上课前出现抖动是因为大量学生同时开机、DHCP请求洪泛企业网在午休后丢包率升高是因为员工集中访问视频网站触发防火墙深度检测。我们后来开发了一个简易的“时间指纹”分析脚本用Prometheus收集node_network_receive_bytes_total等指标用Grafana绘制24小时热力图自动识别异常时段并关联日志系统如ELK搜索该时段的系统告警。这个方法让我们将80%的问题从“被动救火”转为“主动预防”。最后分享一个小技巧当面对一个全新网络环境我习惯先做“三分钟快筛”ping -c 10 target.com看基础连通性和平均延迟mtr -r -c 20 target.com看路径各跳延迟和丢包iperf3 -c target.com -u -b 10M -l 1200 -t 10 -J 2/dev/null | jq .end.sum.jitter_ms直接提取UDP抖动值。这三个命令能在三分钟内给出带宽、时延、抖动、丢包的全景快照准确率超过70%。剩下的30%交给Wireshark和tc深度挖掘。网络性能的世界没有银弹但有清晰的逻辑链条。当你能把“卡顿”翻译成“抖动P9550ms”把“连接失败”映射到“TCP重传率5%”你就已经站在了问题解决的正确起点上。