市内迁移会掉，但我当时是跟上门移机的师傅让他帮忙加上公网

24u 长焦光圈是要比 23u 大一些的，从几个月前群友试的结果来看，效果略好于 23u

想开点，在信息安全前提下，未来教育网应该已经或逐渐关闭入站连接了，你出去是不是 NAT 都无所谓了

ipv4 10/8 、172.16/12 、192.168/16 -> ipv6 fc00::/7 ，就是通常说的，内网可安全使用、外网不可使用的地址段
ipv4 169.254/16 -> fe80::/10 ，只在网卡接口两端有效的地址，使用时一般需要指明网卡名称，在同机器不同网卡之间可同时使用同一地址

@dafuyang 你没发现它算得也没错，算的是 node_memory_MemTotal_bytes-node_memory_MemAvailable_bytes
total 1.8G ，建议 free -m ，不然算不太清
avail 545M
1.8G-545M 不就差不多是 1.3G 左右
面板不管是复制的还是自己写的，结果看起来是没有问题的，只不过你对这一语句对应的意义自己有不同的理解罢了

frrouting

是否为同一网段，本质在于本侧是否认为对侧是 on-link ，也就是可以通过 arp 包获得对端的地址
首先你这样的配置，必然导致某一小段路由不互通，或存在其它连接性问题，又或者某些 host 是不可达的
本地 IP 肯定是认为对端是 on-link 的，因此会在局域网直接访问对方
反过来，对端在回包的时候的，是不能直接连接到本地 IP 的，必须要通过你所设置的网关转发流量，除非目的 IP 为本地 IP 设置了 onlink 路由

1 、去程路由和回程路由不是对称的，这在互联网上极为常见
2 、traceroute 提供的是去程路径信息，对应去程路径上的每个节点，但如果中间设备配置有多个地址，你所看到的路径上的 IP 地址<很可能是>该设备到源 IP （也就是发起 traceroute 机器的外网 IP ）时所使用路由出口的接口的 IP 地址
亦即想表达的意思是，假设你的机器 A 访问机器 B 时通过<路径 1>时经过 C 节点，此时你的去程流量是从 C 节点网卡 C1 进入的流量，C 此时把 TTL=0 的包返给机器 A 时查询自己的路由表，发现应该从网卡 C2 出去，此时 C 走的可能是<路径 2>，假设 C 在出口网卡 C2 配置了 IP 地址，你在 traceroute 上看到的地址其实是 C2 网卡的地址而不是 C1 ，如果 C2 没配置问题就复杂一些。
对应的，你下一跳、上一跳以及任意链路上中间设备，在返包给机器 A 时，都是根据自己的路由表得出应往哪个出口网卡发送，对应的可能就不是<路径 1>、<路径 2>，而是<路径 3>、<路径 N>之类的了
你所看到的延迟，是<路径 1>上 A 到中间设备 C 的时延+<路径 N>的时延，不对称，所以可能中间延迟就高很多

我以为你想喷 zenlayer 的 CPU 垃圾，毕竟我自己试了下跑两三百兆的单核 CPU 就满了，这点比其它同行的机器都要差得多
没想到是喷路线和退费
路线方面这家有给 looking glass 的，事前先测试或看点评测不是买小鸡前必做的功课吗

在 model 写个能复现问题的单元测试吧，实在看不懂什么叫能复现

hairpin nat

没有 ipv6 ，需要公网的建议再办一路普通的

毕竟 S23U 是唯一 12G 内存的型号，如果不是贵我也想上
不过这回倒是国行 plus 有 512G 存储了，无印则是看到港行有 512G

根据 cppref 上 atomic 章节的原话
除了 ms vc++的 volatile 是携带有部分原子语义的，其它的编译器你均不能认为有原子语义
另外，不要试图在 C 类语言上做自以为是的性能优化，C 的 atomic 库已经帮你在基于处理架构的优化了
普通写是否原子，和体系结构有关

java 不了解

10000.gd.cn 显示签约的是多少？
我半年多前升的千兆是给的 100 上行
不过后来推销的口径都是 50 上行了

这代码槽点确实很多
改成这样至少是能跑的
核心问题就是 5 楼所说的


#include <iostream>

class Widget{
private:
int n;
public:
Widget(int v):n(v) {std::cout<<"第"<<n<<"已经构造"<< std::endl;}
~Widget(){std::cout<<"第"<<n<<"已经析构"<< std::endl;}
void show_n()const{std::cout<<"当前值为"<<n << std::endl;}
};


int main() {
Widget** widget = static_cast<Widget**>(::operator new(sizeof(Widget*)*10));
for(int i = 0 ; i < 10 ; ++i){
*(widget+i) = new Widget(i); //语句 2
}

(*(widget + 5)) -> show_n();

return 0;
}

请注意，原代码里的
Widget* widget = static_cast<Widget*>(::operator new(sizeof(Widget)*10));
它所执行的操作是分配一个可以供 10 个 Widget 存放的内存空间，一个 Widget 是 4 字节
而你思路上试图做的是 widget=new Widget(i)是试图在把这 10 个 Widget 空间的前两块（ 64 位系统指针是 8 字节）赋给一个新的指针，当 widget+=1 的时候，再做 widget=new Widget(i)的时候是把这个空间块的第 2 、3 块赋给一个新的指针
请特别注意，之前第一步操作的时候存的指针值已经被破坏了！

你这个方法应该不防重放

不考虑 VRF 等稍微复杂的情况的前提下
subnet 的语义是 scope link 上，在主路由表上添加一条到该网段的路由
即 ip route add 192.168.1.0/24 dev <interface> scope link table main ，可能后面还会带着一条 src x.x.x.x
并在 local 路由表上添加对应广播路由
ipv4 地址填写的语义的是，在 scope host 上，为 local 路由表上，把该地址视作由本机处理的流量进行拦截
即 ip route add local 192.168.1.5 dev <interface>
ubuntu 新版本这么做其实并无不可

你可以想像一下，如果一家 VPS 服务商（比如 online ），它提供了 fallback ip 的，如果你想用于本机，我印象中官方的推荐做法其实是往这个 interface 加一个独立的 IP ，这种情况下，你依然保留了原有 IP 及其 subnet 和 gateway ，但你不必为这个新增的 fallback ip 建立对应的 subnet （又或者其实是建立的 fallback_ip/32 的 subnet ），建立额外的 subnet 反而是不正确的路由方式
这种场景下，ubuntu 的这种方式是有一定意义的，但这毕竟是一个有些反直觉且不常用的功能