wi11iamZ 最近的时间轴更新 wi11iamZ 最近的时间轴更新 |
wi11iamZV2EX 第 502761 号会员，加入于 2020-08-07 14:01:36 +08:00今日活跃度排名 12862 |
wi11iamZ 最近回复了
13 天前 回复了 MFWT 创建的主题 › 宽带症候群 › 目前小微企业/酒店之类的，宽带一般会怎么拉？ |
各地的运营商都会推酒店套餐，内容大概等于削弱版的家宽，PON 接入，每个房间一个高级程度的光猫，提供 IPTV+无线+有线（带宽通常比家宽低不少），大部分情况下没有 IPv4 公网，配置正确的话会下发 IPv6 公网。虽然这种套餐费用比家宽低不少，但是运营商仍然很愿意推，甚至规模很小的酒店都愿意接。
当然这种方案成本对于房价不高的酒店来说并不便宜，成本更敏感且规模较小的酒店需要更便宜的方案。最简单粗暴的就是拉多条家宽，但是有可能被运营商 ban 或者卡连接数，一个变通的方案是拉 PON 接入的商宽。
高档酒店的情况则更复杂一些，遇到过拉双网的，也有非常豪横地直接拉大带宽专线的，甚至会为了保证境外访问质量接入 CN2/CUII 。
当然这种方案成本对于房价不高的酒店来说并不便宜，成本更敏感且规模较小的酒店需要更便宜的方案。最简单粗暴的就是拉多条家宽，但是有可能被运营商 ban 或者卡连接数，一个变通的方案是拉 PON 接入的商宽。
高档酒店的情况则更复杂一些，遇到过拉双网的，也有非常豪横地直接拉大带宽专线的，甚至会为了保证境外访问质量接入 CN2/CUII 。
146 天前 回复了 wu67 创建的主题 › 宽带症候群 › 疑似出现了新的 BT 流量恶意攻击, 这个 ip 段的 ip 一直在疯狂连接, 并且出现了使用相同 ip 的不同端口来连接的情况 |
有没有什么办法反向耗这些 PCDN 的流量或者资源……你不仁别怪我不义
PCDN 比一般用户脆弱很多
PCDN 比一般用户脆弱很多
151 天前 回复了 ixixi 创建的主题 › 宽带症候群 › 为何很多人对 tplink 的评价这么差呢，我用的感觉一直很好啊 ? |
TP 的东西可能最初的设计不存在问题（软硬件），但是“缩水迭代”之后就会逐渐变差。然而网络设备最重要的就是稳定性。自己也没空折腾这些，去研究各个版本的区别以及影响。
买过的 TP 产品中最烂的是 TL-ST1008 万兆交换机，用一段时间必坏接口，虽然售后给换新，但是换完还是接着坏。
买过的 TP 产品中最烂的是 TL-ST1008 万兆交换机，用一段时间必坏接口，虽然售后给换新，但是换完还是接着坏。
151 天前 回复了 nbsn 创建的主题 › 宽带症候群 › [匪夷所思] 国外线路经由移动回国，居然绕行中国电信？ |
@linzh 后面这台机晚上高峰期到浙江移动能稳定超过 300Mbps 并且不丢包，可以确定买了 CMI transit ，不过延迟上确实奇怪
151 天前 回复了 nbsn 创建的主题 › 宽带症候群 › [匪夷所思] 国外线路经由移动回国，居然绕行中国电信？ |
@bclerdx 买了 CMI 的应该会有一跳显示为境内的 CMI ，而不是直接进 AS9808 。没有买 CMI 的话标准流程就是境外走 CMI ，一落地直接进 AS9808 ，没有境内 CMI 那一跳。
152 天前 回复了 nbsn 创建的主题 › 宽带症候群 › [匪夷所思] 国外线路经由移动回国，居然绕行中国电信？ |
感觉更像是对方买了电信 163 的 transit
一般没买 CMI 的正常回程是这样的：
0. 128.199.126.0 Loss% Snt Last Avg Best Wrst StDev AS Name PTR
1. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 -
2. 10.76.195.152 0.0% 20 0.6 0.9 0.3 3.4 0.9 -
3. 143.198.252.0 0.0% 20 0.3 0.3 0.3 0.5 0.1 -
4. 143.244.192.90 0.0% 20 0.4 0.4 0.2 0.7 0.1 -
5. 143.244.224.232 0.0% 20 1.0 0.9 0.7 1.2 0.1 -
6. 143.244.224.209 0.0% 20 0.6 0.6 0.5 0.8 0.1 -
7. 210.57.30.238 0.0% 20 1.3 10.2 1.1 71.9 20.3 4637 HK ASN-TELSTRA-GLOB unknown.telstraglobal.net
8. 223.119.48.2 0.0% 20 1.1 1.0 0.8 1.3 0.1 58453 HK CMI-INT-HK China
9. 223.120.22.214 0.0% 20 94.8 95.1 94.8 100.0 1.1 58453 HK CMI-INT-HK China
10. 221.183.92.197 0.0% 20 92.1 92.0 92.0 92.2 0.1 9808 CN CHINAMOBILE-CN
11. 221.183.92.213 0.0% 20 93.6 93.6 93.5 94.0 0.1 9808 CN CHINAMOBILE-CN
12. 221.183.167.33 30.0% 20 101.3 101.6 101.3 103.6 0.6 9808 CN CHINAMOBILE-CN
13. 221.183.137.82 90.0% 20 109.5 110.5 109.5 111.6 1.4 9808 CN CHINAMOBILE-CN
14. 221.183.122.194 95.0% 20 114.1 114.1 114.1 114.1 0.0 9808 CN CHINAMOBILE-CN
15. 223.87.26.29 80.0% 20 109.7 109.7 109.6 109.7 0.0 9808 CN CHINAMOBILE-CN
16. 223.87.26.174 0.0% 20 112.8 112.8 112.7 113.0 0.1 9808 CN CHINAMOBILE-CN
17. 223.85.135.154 0.0% 20 110.7 110.6 110.4 110.9 0.1 139080 CN CMNET-SCIDC-CN
18. 183.220.6.1 5.0% 20 114.7 114.6 114.5 114.7 0.1 9808 CN CHINAMOBILE-CN
如果当地没有 CMI ，就在 HK 进 CMI ，然后一落地就走 AS9808 。
买了 CMI 的则是这样：
traceroute to 183.247.7.1, 30 hops max, 52 bytes payload
1 172.22.85.200 *
2.67 ms
2 103.193.131.133 AS9312 Hong Kong China xtom.com.hk
hk85-2-1.it7.net 0.88 ms
3 103.193.131.89 AS9312 Hong Kong China xtom.com.hk
103.193.131.89.static.xtom.com 0.56 ms
4 103.193.131.77 AS9312 Hong Kong China xtom.com.hk
103.193.131.77.static.xtom.com 0.88 ms
5 223.119.81.186 AS58453 [CMI-INT] Hong Kong China cmi.chinamobile.com 移动
0.81 ms
6 223.119.81.185 AS58453 [CMI-INT] Hong Kong China cmi.chinamobile.com 移动
0.72 ms
7 223.120.3.205 AS58453 [CMI-INT] Hong Kong China cmi.chinamobile.com
2.00 ms
8 223.120.3.178 AS58453 [CMI-INT] Shanghai China cmi.chinamobile.com 移动
28.36 ms
9 221.183.89.170 AS9808 [CMNET] Shanghai China 回国到达层 chinamobileltd.com 移动
29.61 ms
13 183.248.135.130 AS56041 [APNIC-AP] Hangzhou Zhejiang China zj.10086.cn
34.53 ms
落地后还有一跳属于 AS58453 ，之后才走 AS9808 。
直接走 AS4134 回来得是接入了电信 163 的 transit ，结果本来口子就堵，到移动还有二次跨网损耗。
一般没买 CMI 的正常回程是这样的：
0. 128.199.126.0 Loss% Snt Last Avg Best Wrst StDev AS Name PTR
1. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 -
2. 10.76.195.152 0.0% 20 0.6 0.9 0.3 3.4 0.9 -
3. 143.198.252.0 0.0% 20 0.3 0.3 0.3 0.5 0.1 -
4. 143.244.192.90 0.0% 20 0.4 0.4 0.2 0.7 0.1 -
5. 143.244.224.232 0.0% 20 1.0 0.9 0.7 1.2 0.1 -
6. 143.244.224.209 0.0% 20 0.6 0.6 0.5 0.8 0.1 -
7. 210.57.30.238 0.0% 20 1.3 10.2 1.1 71.9 20.3 4637 HK ASN-TELSTRA-GLOB unknown.telstraglobal.net
8. 223.119.48.2 0.0% 20 1.1 1.0 0.8 1.3 0.1 58453 HK CMI-INT-HK China
9. 223.120.22.214 0.0% 20 94.8 95.1 94.8 100.0 1.1 58453 HK CMI-INT-HK China
10. 221.183.92.197 0.0% 20 92.1 92.0 92.0 92.2 0.1 9808 CN CHINAMOBILE-CN
11. 221.183.92.213 0.0% 20 93.6 93.6 93.5 94.0 0.1 9808 CN CHINAMOBILE-CN
12. 221.183.167.33 30.0% 20 101.3 101.6 101.3 103.6 0.6 9808 CN CHINAMOBILE-CN
13. 221.183.137.82 90.0% 20 109.5 110.5 109.5 111.6 1.4 9808 CN CHINAMOBILE-CN
14. 221.183.122.194 95.0% 20 114.1 114.1 114.1 114.1 0.0 9808 CN CHINAMOBILE-CN
15. 223.87.26.29 80.0% 20 109.7 109.7 109.6 109.7 0.0 9808 CN CHINAMOBILE-CN
16. 223.87.26.174 0.0% 20 112.8 112.8 112.7 113.0 0.1 9808 CN CHINAMOBILE-CN
17. 223.85.135.154 0.0% 20 110.7 110.6 110.4 110.9 0.1 139080 CN CMNET-SCIDC-CN
18. 183.220.6.1 5.0% 20 114.7 114.6 114.5 114.7 0.1 9808 CN CHINAMOBILE-CN
如果当地没有 CMI ，就在 HK 进 CMI ，然后一落地就走 AS9808 。
买了 CMI 的则是这样：
traceroute to 183.247.7.1, 30 hops max, 52 bytes payload
1 172.22.85.200 *
2.67 ms
2 103.193.131.133 AS9312 Hong Kong China xtom.com.hk
hk85-2-1.it7.net 0.88 ms
3 103.193.131.89 AS9312 Hong Kong China xtom.com.hk
103.193.131.89.static.xtom.com 0.56 ms
4 103.193.131.77 AS9312 Hong Kong China xtom.com.hk
103.193.131.77.static.xtom.com 0.88 ms
5 223.119.81.186 AS58453 [CMI-INT] Hong Kong China cmi.chinamobile.com 移动
0.81 ms
6 223.119.81.185 AS58453 [CMI-INT] Hong Kong China cmi.chinamobile.com 移动
0.72 ms
7 223.120.3.205 AS58453 [CMI-INT] Hong Kong China cmi.chinamobile.com
2.00 ms
8 223.120.3.178 AS58453 [CMI-INT] Shanghai China cmi.chinamobile.com 移动
28.36 ms
9 221.183.89.170 AS9808 [CMNET] Shanghai China 回国到达层 chinamobileltd.com 移动
29.61 ms
13 183.248.135.130 AS56041 [APNIC-AP] Hangzhou Zhejiang China zj.10086.cn
34.53 ms
落地后还有一跳属于 AS58453 ，之后才走 AS9808 。
直接走 AS4134 回来得是接入了电信 163 的 transit ，结果本来口子就堵，到移动还有二次跨网损耗。
165 天前 回复了 Jacquesx 创建的主题 › 宽带症候群 › Cloudflare 的 DNS 连通性现在是什么情况，比 8.8.8.8 还抽象呐？ |
如果是直接发送 UDP 向 53 端口请求，国内几乎 100%被劫持，通常会发现延迟异常低。
DoT 不太用，知名的应该都被 ban 了，目前唯一可用的是 DoH ，目前的技术手段仍然难以区分 DoH 请求和普通的 HTTPS 访问。
cloudflare 由于 warp 的存在以及 CDN 被滥用于梯，其所属 IP 通常都被“特殊照顾”。不过好在由于使用的网站众多目前还没被彻底 ban 掉，相当部分的省市目前仍然可以直接访问 https://1.1.1.1 。但是因为被特殊照顾请求的稍微频繁一点就会被阻断再加上 cf 的非精选 IP 到中国的连接质量不佳，很大概率会出现连接失败的问题。
因此对于国内域名解析，通常不建议直接使用 cloudflare dns ，如果一定要用也仅仅作为备用或者应急使用，除非网络环境能保证访问国际互联网的质量。如果需要完全避免 DNS 污染必须要用可靠的 DNS ，建议在境外的 VPS 上自建支持 DoH 的 DNS 服务器，或者至少用 DoH 访问 Level3/Quad9/OpenDNS 之类没被盯的那么紧的服务商。
无特殊需求的话，一个比较理想的 DNS 实践是使用 MosDNS 之类支持分流的方案在本地自建 DNS 服务器，本地域名使用 DoH 向国内的公共 DNS 请求解析，境外域名使用 DoH 向国外的公共 DNS 请求解析。
DoT 不太用，知名的应该都被 ban 了，目前唯一可用的是 DoH ，目前的技术手段仍然难以区分 DoH 请求和普通的 HTTPS 访问。
cloudflare 由于 warp 的存在以及 CDN 被滥用于梯，其所属 IP 通常都被“特殊照顾”。不过好在由于使用的网站众多目前还没被彻底 ban 掉，相当部分的省市目前仍然可以直接访问 https://1.1.1.1 。但是因为被特殊照顾请求的稍微频繁一点就会被阻断再加上 cf 的非精选 IP 到中国的连接质量不佳，很大概率会出现连接失败的问题。
因此对于国内域名解析，通常不建议直接使用 cloudflare dns ，如果一定要用也仅仅作为备用或者应急使用，除非网络环境能保证访问国际互联网的质量。如果需要完全避免 DNS 污染必须要用可靠的 DNS ，建议在境外的 VPS 上自建支持 DoH 的 DNS 服务器，或者至少用 DoH 访问 Level3/Quad9/OpenDNS 之类没被盯的那么紧的服务商。
无特殊需求的话，一个比较理想的 DNS 实践是使用 MosDNS 之类支持分流的方案在本地自建 DNS 服务器，本地域名使用 DoH 向国内的公共 DNS 请求解析，境外域名使用 DoH 向国外的公共 DNS 请求解析。
329 天前 回复了 youx 创建的主题 › 宽带症候群 › 上海电信 5000M 宽带 |
有没有出国线路优化…对家宽来说高上行意义不大
2023-10-23 00:37:13 +08:00 回复了 janebooom 创建的主题 › 宽带症候群 › 电信的 QOS 好迷 |
西南某省电信 1000Mbps GPON ，有公网 IP 无单独 ASN 。
手里只有 DC6 的，2C2G 款，0 点左右试了下自己的站点浏览器单线程下载能跑满 100Mbps （ nginx 限速 100Mbps ），
最近 DC6 似乎改了线路不走 dmit 应该和 DC9 差不多，不至于差这么多
手里只有 DC6 的，2C2G 款，0 点左右试了下自己的站点浏览器单线程下载能跑满 100Mbps （ nginx 限速 100Mbps ），
最近 DC6 似乎改了线路不走 dmit 应该和 DC9 差不多，不至于差这么多
关掉 DHCPv6 改成 SLAAC 试试？
Select Language