warning:
这篇文章距离上次修改已过666天，其中的内容可能已经有所变动。
酸酸乳是什么
答：国际机场提供的清凉饮料,具有某种神奇力量的道具使用后的114秒内，滑翔时的移动速度提高514%
点击此处，展开目录前言SSR之殇混淆和协议无校验的流加密事实的另一方面外加的协议层无验证流加密：谁在乎呢写在最后前言在2023年写这篇博文似乎还是有些为时过晚了，毕竟如果你问『翻墙娱乐圈』的人，目前什么协议比较好，清一色回答几乎都是『不要用SS/SSR，用最新的VLESS+gRPC+Reality......』什么的，似乎使用SS和SSR在目前已经成为了某种怪异的事情一样
但是问题是，SS倒好说，毕竟一直都还在开发，有热心开发者持续跟进改进，以及我现在能更新这篇博文也是靠了SS的力量。
但是SSR呢？SSR在至少四五年之前就已经不是自建协议的主流选择，在两三年之前也基本很少在自建中使用了。但是，如果你购买成品节点，你会发现相当一部分（尤其是连续做了几年）的机场依然选择使用SSR来提供服务。难道正如网上的人所说，是鸡场老板不知道安全的重要性，亦或者是他手头的IP多到可以随便拿来挥霍吗？
笔者感觉，应该都不是
SSR之殇SSR的诞生，出现在SS的作者被迫放弃开发之后，另一位开发者主导起来的项目。至于SSR和SS之间的爱恨情仇，以及SSR作者的人品问题，以及到最后的被开盒事件，在这里就不多谈了，因为我们主要是谈技术，不想陷入到纠纷中。
info:翻墙娱乐圈（又名科学娱乐圈）
和前端娱乐圈一样，这个娱乐圈里面同样充满了撕逼。就笔者记得的有：
SS作者被请喝茶SSR作者违反开源协议SSR作者『被』开盒RixCloud等『高端机场』也跑路XTLS原因导致V2Ray分家（分成了现在的V2Fly和Xray）RPRX的Trojan-Killer的发布CFW删库，Clash删库，ClashVerge停止开发，TUIC删库混淆和协议SSR采用在原版SS上添加混淆和协议层的方式来实现，各个混淆协议都有其特点，但是其基本思路和目前的V2Ray传输协议什么的没有太大差别：都是利用分层的方法，让外层的协议消除掉里面的主协议的特征。当然，虽然说V2支持最基本的HTTP混淆，但是也不推荐使用（唯一一个用途可能大家已经想到了：免流）。
这个外加的混淆和协议层，具体能不能实现抗封锁，其实有待商榷。一方面，他致力于把SS数据流伪装为HTTP和TLS握手包等互联网上常见的协议，这个做法在某些地方已经观察到了欺骗运营商QoS设备的情况（说人话就是，直观感受到加了混淆之后『快了』）；但是另一方面，不论是最开始的http_simple等混淆，还是说后期的auth_chain_*系列协议，他们的重点都在于模仿，但是模仿总会有模仿地不像的地方，有可能成为一个强特征，导致流量可以被精确切断。
到了相对后期的一段时间内，很多SSR教程都推荐把混淆设置为plain，把协议设置为auth_chain_a/b/c，或者干脆设置为Origin。但是笔者不确定这些文章是不是都是抄来抄去的，因为plain+origin就已经是原版的SS了，此时还称呼为SSR已经意义不大了。
说到这个，这就不得不提到SSR的另一个问题：无校验的流加密
无校验的流加密就目前而言，不管是以前已经停止开发的SSR各客户端，还是说后期的Clash（似乎sing－box是个例外），他们在SSR选项中实现的加密方式依然是无校验的那几个，比如RC4(-MD5)，AES系的CFB/CTR，纯Chacha20等，因此这就给针对SS的主动探测等留下了空间。
虽然说，正确配置的混淆协议可能可以规避这个问题，但是当时有多少人懂得什么是正确配置呢？大多数都是跟着网上的教程，或者直接用一键脚本，乱配一通，通了就通了，别的安全措施就视若无物。
事实的另一方面SSR到目前来看，缺点很多，似乎应该消失了才对。但是近来的软件（包括V2系，Clash系等）的issues区里面，总会有人询问能不能提供SSR协议。问起她们原因来，基本上都能得到一个回答：机场还在用SSR。
老实说，这是事实。当然近两年来似乎少很多了，更多的机场转向VMess等协议。但是为什么会有这么奇怪的情况，按道理，机场不应该是用的人更多，更应该选择那些抗封锁能力强的协议上嘛？
这就是事情变得有趣的地方：上面SSR之殇中提到的缺点，反而成为了优点
外加的协议层先来看主流的协议有什么：SS, SSR, VMess, VLESS, Trojan再来看机场的需求是什么：通过服务器给多人提供服务，并实现权限控制和计费
现在就可以分析各个协议的情况了。
SS：SS一开始是作者开发来自己用的，因此并没有考虑到多用户区分和鉴权的问题，只要知道了密码谁都可以连接上。后来为了分销的需要，通常的一个做法是一个用户一个端口一个密码，用端口号作为账号。但是如果防火墙看到几千几万个TCP同时访问这个机器，而且端口还不一样的话.....我感觉不太妙SS单端口多用户：用是可以用的，但是毕竟这玩意是在原协议的基础上凑合出来的方法，它的基本原理是通过数据包提供的IV和服务器端本来存着的密码，轮流尝试对数据包进行验证，如果验证通过，那就是有效用户。很显然，这个方法相对来说比较吃资源，因此大机场使用的并不算多VMess：在数据包中插入了UUID，但是其协议（尤其是早期版本的协议）也非常吃资源，甚至当时还有鸡场老板宣称自己的机器被V2Ray吃光了资源Trojan、VLESS等：比较新，前两年也还没有这个比较下来，SSR就成为了一个很合适的选择：有明文或别的字段，能够实现单端口多用户下快速判断用户身份，而且对资源的消耗量也不大（以混淆单端口为例，有些会采用外面混淆头的Host字段改成比较特殊的，能够关联到用户ID的字符串，就可以在不解密内部数据包的情况下快速判断用户身份）
无验证流加密：谁在乎呢鸡场老板一般来说都是下了不少小聪明的，最基本的基本上都是全中转机场了。因为中转机是老板的，因此他可以上各种『更适合』过墙的协议，比如TLS隧道（而且此时单端口也比原版SS的多端口要方便得多），甚至有些能直接搞到专线（包括但不限于阿里云经典内网的Bug），接起来之后，里面跑什么协议都无伤大雅了，毕竟全都不过墙
info:一个很好玩的东西：NAT VPS
有一些小机场的端口号乱七八糟，大概率是因为使用了NAT VPS或者租用别的端口转发服务商的线路
卖这些玩意的商家是怎么搞到机器的，具体谁也不会说。但是笔者和一位业内朋友交谈过，大概有一种方式是：机房内鬼。
比如，机房是正规机房，拉了1G的专线（一般是移动，便宜量大，广州移动拉香港CMI，被称为穷人版CN2），但是正常业务用不完的，剩下的一般是冗余什么的。某个内鬼偷偷匀出来100-200M，然后搞台机器卖小鸡或者端口转发，每个用户分20个端口....然后，又有一个NAT VPS商家出现在了网络上。就这样。
写在最后本文很水，真的很水但是笔者有时候就是想写点什么，即使是自娱自乐也好，也算是一个乐趣了
（完）