CEX交易模式

Smt订单流(极简版)

介绍

STM 是一种用于交易分析的技术工具，专注于通过识别订单流和支撑/阻力区域来辅助交易决策

实战:

在4段中，第1~3段走出了下跌趋势，并且①产生区域成为阻力区
③因为②产生的阻力区而无法上行
所以在④中，很可能会因为③的阻力区域而无法上行 ==可以考虑短线介入做空==

正如这个图所显示的，在④中走到了订单块的支撑区域，所以它会短暂向上 (而不是直接向下)

总结：

此模式仅能提高成功率，而不是==完全就能成功==

Web3安全意识

观前FAQ

Q：我不知道关于Web3的任何信息，本文的Web3内容对我有帮助吗?

  • A：我不能保证本文的帮助效用，但是它应该能帮你提高安全意识

Q：本文具有专业性 or 准确性吗?

  • A：专业性和准确性只有链上安全审计公司（例如SlowMist）能保证，世上没有绝对，只能相对。我想安全意识应该不存在所谓的“专业性”，虽然本文旨在提高安全意识，但是我们都不能保证下一个被盗的不是自己（防不胜防）。

Q：看起来内容不是很多的样子

  • A：本贴打算做成以后会不定时更新，因此目前没有计划填充所有内容

引入

从近期多发的各种安全事故（无论是Web3还是传统Web） 包括以下事件：

  • 币圈地震事件（史上最大盗窃案）：ByBit被盗15亿美元（原因是操作恶意合约盗取资产，这里不做详细概述，感兴趣的朋友可以自行查阅相关资料）

  • Infini官方被盗近5000万美元链上资产（盗走后被迅速转换为DAI(稳定币)）

  • Chris Larsen (Ripple的联合创始人) 被盗2.83亿XRP(一个热门币，价值约合1.5亿美元，原因是把私钥存在了LastPass密码管理器中(22年泄露过数据))

虽然这些看似宏观叙事的事件，却反映了Web3普遍用户的一个问题：安全意识不足而导致自己的数字资产丢失。

数字资产的安全性

从设计之初，区块链本意是想避免第三方机构的介入（详见BTC白皮书），实现更安全 / 匿名 / 去中心化的交易系统

但是这就能说明它是不惧任何风险的吗? 答案肯定是否定的。

Uniswap闪电贷攻击

Uniswap采用自动化做市商（AMM模型），在一个流动性池，通过闪电贷协议进行套利交易。 可以让其他协议损失资产

闪电贷：可以不抵押任何资产进行借入资金，但是在交易结束时必须归还（本意是为了提供更多的流动性）

省流版：通过多个流动性池来回倒进行套利

这里假设存在1 / 2流动性市场，以及ABC 可以这样理解为：

  • 你在1号市场借出了都为50个的A币和B币（这里假设A币是稳定币，并且使用闪电贷）

  • 在2号市场用25个A币购买了10个B币（这时候推动了B币的价格上涨）

  • 然后再用60个B币去购买30个C币（这时候我们还有25个A币和30个C币）

  • 卖出剩余的25个A币（导致A币价格下跌）

  • 然后可以用30个C币买入比原来更多的B币

  • 重复操作完成套利

Poly Network丢失6亿美元资产

省流版：智能合约出现了漏洞

智能合约：如果不知道的是什么的话可以理解成一个沙箱，区块链用于执行代码的载体

智能合约真的安全吗?

我们的数字资产和智能合约有什么关系？ 可以这么说，智能合约是区块链生态和DeFi的基石。 通过 质押 和 再质押 等协议，你可以通过DeFi来赚取收益 通过智能合约，你可以做出各种各样的Dapp

但是智能合约终究是存在“一定”的漏洞（因为是人为编写的） 无论是代码漏洞还是逻辑漏洞，他总是有问题的。

所以没有绝对的安全。

那上面的内容和我们又有什么关系?

就像闪电贷和Poly Network一样，他们跟我们又有什么关系呢?

  1. 从事DeFi活动的时候，肯定会接触这些协议和链，比如你质押了一些币在流动性池中赚取收益，但是有一天这个池如果被闪电贷攻击了，那么损失的资产最终还是进行质押的人的亏损。（即自己的亏损）

  2. 通过理解原理提高自己的安全意识

  3. 在自己编写智能合约或者某个协议的时候，通过学习其他项目的问题来保证自己的项目稳定运行

经典骗局&陷阱

如果说上面的内容都是空讲和宏大叙事，那么现在开始讲点实际的了。

波场多签钱包

朋友们可能经常会见到这样的人在求救：

  • 救命，有没有币圈大佬，我的巨款提现不出来

  • 不玩币圈了，助记词放这里了，送给有缘人

乍一看是那种天上掉馅饼的好事。 不过一切免费的事物在背后早已被标注了价格。

什么是多签?

波场区块链提供了一种多签钱包，这种多签多签是一种更高安全性的钱包。 一般的钱包只需要持有者私钥的授权，即可进行交易（这就诞生了一个问题：如果私钥丢失或者交给别人用一下，那么是不是我就失去了对钱包的控制权了？） 所以多签钱包诞生了。

那么问题在哪里呢？ 那么还原一下，你确实相信了他的言论，并且导入了私钥或助记词，打开一看也许还确实有点资金。 这时候你可能会很惊喜，然后开始向钱包中转账（提供Gas费用） 然后等你高高兴兴地想转出资金时你才会发现你上当了！

在没有绝对的控制权下，不要想去掌握一个别人的钱包。

那么其他链我是不是可以直接用呢?

这还真不一定，有些地址是监控了你的资金，当你一转入，他的自动化程序就会转出到他真正的钱包。

所以这些“掉馅饼”的事情还是别相信为好。

空气币

又称：貔貅币

这个也是广为流传的”骗局”之一。 原理是什么呢?

比如我发了M币 10万枚，这个时候将其中1w枚进行公共空投等操作。 然后为M币添加A币(假设为稳定币或热门币)的流动性，让它拥有了第一个”价值”。 这时候对其他人拥有了1W枚的持有，更多人或者部分持仓者如果认为它具备潜力 会进行购买，这时候因为这类币缺乏 流动性，价格会冲击很高。

从而产生巨大的收益（看到了1000%+的涨幅，这不用我多说了吧）

但是没有天上掉馅饼的事情，那么古尔丹，代价是什么呢?

代价是你花费了部分财力和精力进入它的所谓的“空投” 在你心心念念的时候大额买入 最后砸在自己手里的最后也是这些“无价值”的空气币。

空气在哪里?

答案是：归零的风险 币的开发者可以通过”增发” / “代理机制” / “冻结权限“等操作控制币的流通等 甚至可以在大家用某币大量买入等待暴涨的时候 — 开发者用它的 LP ( 流动性池的权益证明 )，直接提取池中的全部资产和撤销流动性池 还可以通过最开始持有的9w个M币，直接在市场进行大宗交易，让币价大跌(几乎为0)

甚至极端一点的，会直接对所有代币进行”锁定”，让你无法进行出售，烂在手里

这类币的特征?

  • 缺乏流动性，滑点高

  • 无融资，机构背书

  • 智能合约不公开，无法进行安全审计

钓鱼攻击

这个是Web时代的老骗局了 攻击方式：通过发恶意邮件 / 发送链接 对输入进行窃取的钓鱼操作，泄露自己的信息，密钥等

私钥触网

我们都知道加密钱包在创建钱包时会提示你不要打开摄像头 / 网络环境下进行操作 触网操作会导致你的私钥被网络传输，最后丢失资产。

MEV攻击

这个词汇比较陌生，但是在没有”防御 MEV“的情况下可能遭受资产的损失

攻击原理一般是由 Gas 和 交易顺序 导致的。 比如以下几个 前向攻击：在你提交一笔交易购买某币时，攻击者会支付更高的 Gas 来进行购买，等到处理你的交易时，会以更高的价格成交。 后向攻击：你在 CEX 中提交交易大量购买某币后，攻击者会用 Gas 来在 DEX 上购买大量相同的币，转入 CEX 后直接卖出，赚取套利利润。

夹击（又称被夹，是上面两个的结合体） 通过在你购买某币后先比你成交，再你交易成功后再进行卖出，你亏损了，他得到利润了

无限授权

在授权交易时，切记不要授权”无限”。 并且在授权时，审计相关智能合约的代码，否则遇到了恶意合约，很可能导致你的钱包权限丢失等资产损失。

其他的网络安全

在CEX交易，我不得不使用梯子，那我的信息会丢失或者说被传输给第三方吗?

一般来说，使用开源并审计后的软件以及普遍采用的协议是不会被盗取的。 HTTPS = HTTP + TLS 在 SSL证书 和 HTTP地址 是正确(即你真正要访问的服务的地址)的情况下，在传输过程中不会有人能看到数据。 过程： 你的加密数据包 <-> 代理 <-> 服务器节点 而加密的数据是由 端到端 的，所以不必太担心这个问题. （特别注意：上文强调的正确的SSL证书是指，指向的域名是你要访问的地址，而不是搜索栏那个地址）

附录

这里放了一些参考资料和相关链接，感兴趣的朋友可以继续进行阅读

一位佬在TG中被提到用TON交易： https://linux.do/t/topic/494798/10

infini资金丢失后的官方发言：https://x.com/0xinfini/status/1894401496508502099

TLS加密： https://en.wikipedia.org/wiki/Transport_Layer_Security

【C语言】代码抽象技巧

让你变得更加不可替代 (更抽象)

1. 全加器代替加法

1
2
3
4
int add(int a, int b){
	if(!a) return b;
	return add((a & b) << 1, a ^ b);
}

2. 使用更多的趋近符号

1
2
3
4
int i = 100;
do{
	//something
}while(i --> 0);

3. 变更数组运算(一维)

1
2
3
4
5
int a[5] = {1, 2, 3, 4, 5};
for(int i = 0;i < 5;i++){
	printf("%d\n", i[a]);
	printf("%d\n", (i - 1)[a + 1]);
}

4. 奇偶判断

1
2
3
int num = 11;
printf("%d\n", num % 2 == 0);
printf("%d\n", num & 1);

5. 使用16进制数值 (-1的表示)

1
0xffffffff

6. x * N

1
2
3
x <<= 1; //x *= 2
x >>= 1; //x /= 2
x = (x << 1) + (x << 3); //x *= 10

7. 交换变量 (a ≠ b)

1
2
3
4
5
6
7
8
int a = 2,b = 3;
a ^= b;
b ^= a;
a ^= b;

//or

a^=b^=a^=b

8. 不等于 [该方法可能会出现问题]

a ≠ b <=> a ^ b

9. int 转 char

1
2
3
4
int a, b;
char ch;
ch = a ^ 48;
b  = ch ^ 48;

妖车测评 - 瑞典1欧鸡

引入

最近逛其他测评记录时发现如此神鸡

1c4g 100M 无限流量神鸡！一个月才1欧
这还等什么，直接入手

注意：这家是 Aeza，毛子家的，感觉有点灵。
本文不会贴任何相关链接以及AFF（当然你实在想要可以私信我）
不放的具体原因是：

  • 奇怪的支付方式 （我看了眼似乎并不支持Paypal以及其他常用方式，都是奇奇怪怪的线上支付）
  • Steam支付 (没错就是那个steam，考虑到账号安全不选择此方式)
  • 加密货币支付 (如果你不知道这是什么或者不知道怎么操作请无视)
  • 手续费高的吓死人（如果第一个国际银行卡支付会有至少10%的损耗，我用的某币支付，充值15U手续费收了我2.5U【我走的BEP20】 [6]）
  • IP很脏 （不建议朋友们入手）

支付方式：

嗯，看来出师未捷身先死了

什么拉跨IP，比Claw家的还脏。

考虑到是毛子家的无限流量鸡，也无所谓了吧

配置详情

CPU：1核 5950X（3.6 ~ 4.2Ghz）
内存：4G （实际3.82G）
硬盘：10G （看到这个配置都懂了是什么类型了）
IP：1个IPv4 和 /48的IPv6子网
宽带：100Mbps
流量：无限
其他：标准DDOS清洗（个人很怀疑这个）

测评记录

融合怪：
https://paste.spiritlhl.net/#/show/ydQMD.txt

IP-Check（v4&v6）：

BGP测试：

V4：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
********************************************************************************
一、BGP信息（BGP.TOOLS & HE.NET）
注册信息：          RIPE, AS210644, Aéza International Limited, Prefix/24
注册/修改日期：     2025-01-15 / NoRecord
地区：              [SE]Sweden, Northern Europe, Europe
地址：              Dummy address for ORG-AGL38-RIPE
地理数据共给：      https //aeza.net/static/ipv4_f.csv
活跃邻居：          Prefix/24  256 / 256 
二、本地策略
NAT类型：         开放网络无NAT 
TCP拥塞控制算法：bbr          TCP接收缓冲区（rmem）：4096 131072 6291456
队列调度算法：   fq_codel     TCP发送缓冲区（wmem）：4096 16384 4194304
三、接入信息（*=Tier1 *=非Tier1 *=上游）
互联网交换点接入数：0         上游数量：1         对等互联数量：5
AS174   AS701  AS1299  AS2914 AS3257 AS3320 AS3356 AS3491 AS5511 AS6453 AS6461 
Cogent Verizon Arelion   NTT    GTT   DTAG   Lumen  PCCW  Orange  TATA   Zayo  
AS6762  AS6830  AS7018 AS12956 AS35598 
Sparkle Liberty  AT&T  Telxius INETCOM 
四、三网TCP大包延迟（依次为电信|联通|移动 ⠂=80ms）    京⣾⡇⢰⣿⣾240⣾⣷⣷⣿⣷234⣶⣶⣶⣶⣶172
津⣿⣿⣿⣿⣿283⣶⣶⣶⣶⣶190⣶⣶⣶⣶⣶204 冀⣿⣿⣿⣿⣿287⣶⣶⣶⣶⣶187⣿⣿⣿⣿⣿294 晋⣿⣿⣿⣿⣿290⣿⣿⣿⣿⣿265⣿⡇⣿⣿⣿242
蒙⣿⣿⣿⣿⣿288⣶⣶⣶⣶⣶220⣿⣿⣿⢸⣿245 辽⣿⣿⣿⣿⣿295⣶⣶⣶⣶⣶199⢸⣿⣿⣿⢸252 吉⣿⡇⣿⣿⣿303⣶⣶⣾⣶⣶234⣶⣶⣶⣶⣶187
黑⣿⣿⣿⣿⣿300⣿⣿⣿⣿⣿250⣶⠀⣶⣶⣶187 沪⡇⣶⣿⣿⣾254⣶⣶⣶⣶⣶192⣿⣿⣿⣿⣿271 苏⠀⠀⠀⠀⠀0  ⣶⣾⣿⣾⣶244⣿⣿⣿⣿⣿261
浙⣿⣿⡇⣿⣿248⣾⣶⣶⣶⣷224⣶⣶⣶⣶⣶225 皖⣿⣿⣿⣿⣿288⣶⣶⣶⣶⣶195⣿⣿⣿⣿⣿302 闽⣿⣿⣿⣿⣿287⣶⣶⣶⣶⣶205⣿⣿⣿⣿⣿280
赣⣿⣿⣿⣿⣿304⣶⣶⣶⣶⣶194⣿⣿⣿⣿⣿265 鲁⡇⠀⠀⠀⠀271⣶⣶⣶⣶⣶211⣿⣿⣿⣿⣿257 豫⣿⣿⡇⣿⣿269⣷⣾⣶⣶⣶227⣿⣿⣿⣿⣿255
鄂⣿⢸⣿⣿⣿276⣿⣿⣿⣿⣿278⣿⣿⣿⣿⣿287 湘⣿⡇⣿⣿⣿280⣶⣶⣶⣶⣶190⣿⣿⣿⣿⣿265 粤⣿⣿⣿⣿⣿276⣶⣶⣶⣶⣶195⣿⣿⣿⣿⣿286
桂⣿⣿⣿⣿⣿291⣾⣷⣶⣾⣾233⣿⣿⣿⣿⣿262 琼⣿⡇⣿⢸⡇273⣶⣶⣶⣶⣶212⣿⣿⣿⣿⣿253 渝⣿⣿⣿⣿⣿308⣶⣶⣶⣶⣶219⣿⡇⣿⣿⣿265
川⣿⠀⣿⠀⣿301⣶⣶⣶⣶⣶199⣿⣿⣿⣿⣿267 贵⣿⣿⣿⣿⣿280⣷⣶⣶⣶⣾215⣿⣿⣿⣿⣿265 云⣿⢸⣿⣿⣿276⣶⣿⣷⣿⣶238⢸⣿⣿⣿⣿275
藏⣿⣿⣿⣿⣿286⣶⣶⣶⣶⣶212⣿⣿⣿⣿⣿273 陕⣿⣿⣿⣿⣿297⣾⣿⣶⣷⣿246⣿⣿⣿⣿⣿309 甘⣿⣿⣿⣿⣿305⣶⣶⣶⣶⣶210⣶⣶⣶⣶⣾238
青⣿⣿⣿⣿⣿307⣾⣾⣶⣶⣶228⣿⣿⣿⣿⣿250 宁⢸⣿⣿⣿⣿300⣿⣿⣿⣿⣿256⣿⣿⣿⣿⣿274 新⣿⣿⣿⣿⢸328⣿⣿⣿⣿⣿242⢸⣿⣿⣿⣿250
五、三网回程路由（线路可能随网络负载动态变化）
北京TCP：电信  Arelion->163    || 联通   Cogent->4837   || 移动   Cogent->CMI   
北京UDP：电信  Arelion->163    || 联通   Cogent->4837   || 移动   Cogent->CMI   
上海TCP：电信   Cogent->163    || 联通  Arelion->4837   || 移动   Cogent->CMI   
上海UDP：电信   Cogent->163    || 联通  Arelion->4837   || 移动   Cogent->CMI   
广州TCP：电信   Cogent->163    || 联通  Arelion->4837   || 移动  Arelion->CMI   
广州UDP：电信   Cogent->163    || 联通  Arelion->4837   || 移动  Arelion->CMI   
六、国内测速   发送  延迟    接收  延迟||单位：ms Mbps  发送  延迟    接收  延迟
杭州电信          ERROR         ERROR  ||宁波电信          ERROR         ERROR  
上海联通          ERROR         ERROR  ||香港联通          ERROR         ERROR  
苏州移动          ERROR         ERROR  ||深圳移动          ERROR         ERROR  
七、国际互连   延迟 发送 重传 接收 重传||单位：ms Mbps  延迟 发送 重传 接收 重传
香港      ⣿⢸⣿⡇⠀⣿298    44   0    29  29||东京      ⣿⣿⣿⣿⣿⣿262    53   0    15   2
新加坡    ⣿⣿⣿⣿⣿⣿251    40  44    15  14||悉尼      ⣿⣿⣿⣿⣿⣿307    39   0    60   0
洛杉矶    ⣶⣶⣶⣶⣶⣶164    88  15    11   6||纽约      ⣤⣤⣤⣤⣤⣤ 93   105  5k    50 147
法兰克福  ⣀⣀⣀⢀⣀⣀ 31   114  9k    43  84||伦敦      ⣀⣀⣀⣀⣀⣀ 35   114  7k    91  1k
阿姆斯特丹⣀⣀⣀⣀⣀⣀ 28   115  8k    95  11||圣保罗    ⣶⣶⣶⣶⣶⣶220    68   0    36  2k
================================================================================

V6：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
                   网络质量体检报告：2a01:e5c0:6748:*:*:*:*:*
                        bash <(curl -sL Net.Check.Place)
                       https://github.com/xykt/NetQuality
            报告时间：2025-03-17 22:20:53 CST  脚本版本：v2025-03-15
********************************************************************************
一、BGP信息（BGP.TOOLS & HE.NET）
注册信息：          RIPE, AS210644, Aéza International Limited, Prefix/36
注册/修改日期：     2024-12-27 / NoRecord
地区：              [SE]Sweden, Northern Europe, Europe
地址：              311 Shoreham Street, Sheffield, S2 4FA, United Kingdom
二、本地策略
TCP拥塞控制算法：bbr          TCP接收缓冲区（rmem）：4096 131072 6291456
队列调度算法：   fq_codel     TCP发送缓冲区（wmem）：4096 16384 4194304
三、接入信息（*=Tier1 *=非Tier1 *=上游）
互联网交换点接入数：28        上游数量：1         对等互联数量：24
AS174   AS701  AS1299  AS2914 AS3257 AS3320 AS3356 AS3491 AS5511 AS6453 AS6461 
Cogent Verizon Arelion   NTT    GTT   DTAG   Lumen  PCCW  Orange  TATA   Zayo  
AS6762  AS6830   AS6939   AS7018 AS12956   AS5405   AS6204  AS9002  AS30823  
Sparkle Liberty Hurricane  AT&T  Telxius Inter.link ZET.NET  RETN  aurologic 
AS44592 AS199524 
SkyLink   Gcore  
四、三网TCP大包延迟（依次为电信|联通|移动 ⠂=80ms）    京⣿⣿⣿⣿⣿327⣶⣶⣶⣶⣶173⣿⡇⣿⢸⡇329
津⡇⣿⣿⢸⣿317⣶⣶⣶⣶⣶178⣿⢸⣿⢸⣿329 冀⣿⣿⣿⣿⣿318⣶⣶⣶⣶⣶179⣿⡇⣿⣿⣿335 晋⣿⢸⣿⣿⣿342⣶⣶⣶⣶⣶180⣿⡇⣿⣿⢸329
蒙⣿⣿⣿⣿⣿323⣶⣶⣶⣶⣶193⣿⣿⢸⠀⣿333 辽⣿⣿⡇⣿⣿326⣶⣶⣶⣶⣶196⣿⣿⢸⢸⡇339 吉⣿⣿⣿⣿⣿357⣶⣶⣶⣶⣶175⣿⣿⣿⣿⣿332
黑⣿⣿⢸⣿⣿345⣶⣶⣶⣶⣶198⣿⣿⣿⣿⣿273 沪⡇⣿⣿⣿⣿302⣶⣶⣶⣶⣶176⣿⣿⣿⣿⣿299 苏⣿⣿⣿⣿⣿322⣶⣶⣶⣶⣶175⡇⢸⣿⡇⢸308
浙⣿⣿⣿⣿⣿321⣶⣶⣶⣶⣶177⣿⠀⣿⢸⡇307 皖⣿⣿⣿⣿⣿335⣶⣶⣶⣶⣶179⣿⣿⢸⣿⣿316 闽⣿⣿⣿⣿⣿338⣶⣶⣶⣶⣶208⣿⣿⣿⣿⣿302
赣⣿⣿⣿⣿⣿318⣶⣶⣶⣶⣶168⣿⣿⡇⢸⣿310 鲁⣿⣿⣿⣿⣿332⣶⣶⣶⣶⣶196⣿⣿⣿⣿⣿330 豫⢸⣿⣿⣿⣿323⣶⣶⣶⣶⣶171⣿⣿⣿⡇⢸330
鄂⣿⢸⣿⣿⣿358⣶⣶⣶⣶⣶198⣿⣿⢸⣿⣿315 湘⣿⣿⣿⣿⣿356⣶⣶⣶⣶⣶181⣿⣿⣿⣿⣿308 粤⣿⣿⣿⣿⣿353⣶⣶⣶⣶⣶204⣿⣿⣿⣿⣿296
桂⣿⣿⣿⣿⣿340⣶⣶⣶⣾⣾228⣿⣿⢸⣿⣿325 琼⣿⣿⢸⡇⣿371⣶⣶⣶⣶⣶221⣿⣿⢸⣿⣿298 渝⣿⣿⣿⣿⣿337⣶⣶⣶⣶⣶193⣿⢸⡇⣿⣿314
川⣿⣿⣿⣿⣿353⣶⣶⣶⣶⣶219⢸⡇⣿⣿⣿319 贵⣿⣿⣿⣿⣿332⣶⣶⣶⣶⣶194⣿⣿⣿⣿⣿308 云⣿⣿⢸⢸⣿357⣾⣶⣶⣶⣶234⢸⣿⣿⣿⡇316
藏⣿⣿⣿⣿⣿366⣶⣶⣶⣶⣶220⣿⣿⣿⢸⣿321 陕⣿⣿⣿⣿⣿338⣶⣶⣶⣶⣶199⣿⢸⣿⣿⣿320 甘⣿⣿⣿⣿⣿354⣶⣶⣶⣶⣶179⢸⣿⣿⣿⣿339
青⣿⣿⣿⣿⣿338⣶⣶⣶⣶⣶210⡇⢸⣿⢸⣿346 宁⣿⣿⣿⣿⣿335⣶⣶⣶⣶⣶184⣿⣿⣿⣿⣿334 新⣿⣿⣿⣿⣿375⣶⣶⣶⣶⣶220⡇⢸⣿⣿⣿366
五、三网回程路由（线路可能随网络负载动态变化）
北京TCP：电信   NoData->NoData || 联通   NoData->NoData || 移动   NoData->NoData
北京UDP：电信     PCCW->163    || 联通   NoData->NoData || 移动     PCCW->CMI   
上海TCP：电信   NoData->NoData || 联通   NoData->NoData || 移动   NoData->NoData
上海UDP：电信  Arelion->163    || 联通   NoData->NoData || 移动     PCCW->CMI   
广州TCP：电信   NoData->NoData || 联通   NoData->NoData || 移动   NoData->NoData
广州UDP：电信     PCCW->163    || 联通   NoData->NoData || 移动     PCCW->CMI   
七、国际互连   延迟 发送 重传 接收 重传||单位：ms Mbps  延迟 发送 重传 接收 重传
香港      ⣶⣿⣷⣿⣷⣿291    49   0    58   0||东京      ⣿⣿⣿⣿⣿⣿265    49   0    65   0
新加坡    ⣶⣶⣶⣶⣶⣶192    82   0    65 514||悉尼      ⣿⣿⣿⣿⣿⣿315    27 547    58   0
洛杉矶    ⣶⣶⣶⣴⣤⣶162    96  1k    73 938||纽约      ⣤⣤⣤⣤⣤⣤101   105  6k    86  12
法兰克福  ⣀⣀⣀⣀⣀⣀ 23   116  6k    94  56||伦敦      ⣀⣀⣀⣀⣀⣀ 38   113  6k    92  2k
阿姆斯特丹⣀⣀⣀⣀⣀⣀ 29   115  8k    94   0||圣保罗    ⣶⣶⣶⣶⣶⣶223    66   0    32  23
================================================================================

赛后总结

最开始我还以为是稀有神鸡，结果没想到坑这么大（第一次用到ipdata 3个风险因素的鸡）

CPU确实比较可以 sysbeach: 4845昏

不过年付13.8欧，要啥自行车

软件架构的一些心得 - 重构篇

概念定义

完备性：

  • 指对当前需求所能提供的服务的覆盖率

架构的目标

架构是一个比较宽泛的概念
为了某个需求实现的一个或是一系列业务
旨在高效率地解决问题

重构

重构的本质就是：对当前架构的 完备性 不够充分而remake的

重构软件，意味着你可能会对某个模块 / 某个应用，甚至是某个系统进行再次覆写
这种行为一般产生于：

  • 原代码存在大量问题，修复成本巨大
  • 原系统性能不足以处理业务的不断增长情况
  • 新功能无法快速接入系统内
  • 架构本身存在缺陷

无论是什么原因，重构肯定是为了解决上一代产品出现的问题
重构无法避免，但是重构的频率一定要在 ==可控制的范围内==
否则三天一小改，一周一大改 (这样带来的时间成本和心智负担十分巨大)

  • 解决问题的最好方法就是解决出现问题的根源
    试想一个情景：

    你为某API（假定是一个天气接口，数据有温度/湿度/变化情况/地区）实现了封装
    而你认为目前不需要湿度这一参数，则可能会直接丢弃湿度这一数据
    当你某天自己实现的功能需要依赖湿度这一参数时，你要么直接从原代码中补上湿度（这无疑是增加心智负担，尤其是代码在一个系统中），要么就是实现一个新的封装来获取这一参数
    上面的两种方法，都会让系统变得更加 复杂
    那么如果一开始，你将参数保存在封装的内部（向外输出的数据仍没有湿度），而不是直接丢弃，那么实现新的功能时，只需要调用该API拿到湿度参数即可！

  • 以上例子显示了一个比较容易出现的情况，与其丢弃数据，不如直接封装在内部供下次使用

  • 当然可能会消耗更多的计算资源和带宽（对于稳定性和开发成本来说，这并不是太大，不是吗?）

生活中的实例

就拿B站作为例子，其Web端API接口中存在多个看起来”无用”的参数和重复项（比如bvid和bv_id）
这就是以兼容性换取开发的遍历，用bvid和bv_id可以减少混淆所带来的 隐式问题 和沟通成本