• 关于嗅探上的漏洞,Shadowsocks repo 中被讨论过多次。有关于OTA的,有关于 AEAD 的。这些都是官方讨论之后修复了的问题,我不知道你是从哪得出的 你跟我说 SS 的缺陷是嗅探?,但这些问题确实是存在的,而且直到最近几个月才刚被修复。 至于所谓 SS 在加密方面没有缺陷,也跟 SS 作者说得相反 Shadowsocks 一旦建立握手使用的加密 Cipher,官方目前默认推荐的 chacha20-ietf-poly1305AES-256-GCM 是 OpenSSL 的一部分,尚没有任何 vulnerability 出现。你说的 跟 SS 作者说得相反 建议你找到相关的 Issue。

    至于 IKEv2,根据 RFC4306 定义的标准,其实是一个密钥交换协议,至于传输过程,使用的 Cipher 也是可选的,见 StrongSwan 文档(云梯就是基于这个进行搭建的),你可以看到里面已经有数个加密方式别标记了 broken,也就是因安全性问题而不再被推荐。实际上常用的加密协议还是 chacha20poly1305aes256gcm128 ,这两个都是 Shadowsocks 支持的加密 Cipher,和 Shadowsocks 的加密流一模一样。他们的主要区别在于 IKEv2 使用了 X.509 作为安全认证。而 Shadowsocks 使用长密钥作为安全认证。

    密码学是个严肃的数学问题,不是靠我说它有缺陷或者我说它很安全它就安全了。

  • 100% 是把一个核心吃满还是把所有核心吃满了?如果是后者那肯定是 handle_thread 方法里线程相关的问题了。如果是前者我读了一圈觉得有几个可能出现死循环问题的地方,但这脚本不太方便部署调试。

  • 量产型炮灰工程师 at 2017年06月27日

    你怎么解决用人单位的要求和普通本科毕业生之间的最后一公里 这不是你口口声声 进高校说这个估计你会被群殴 的高校教育的问题吗?自学你想学理论学理论,想碰工程碰工程,根本没人拦着你。

    知道为啥ruby在国内发展的没有php火吗,就是这样的贵族思维在作怪 本来就是 Ruby 没有 PHP 好学啊。那全世界范围内 Ruby 都没 PHP 火啊,所以全世界 Ruby 工程师都是贵族思维;那 Haskell 也没 PHP 火啊,所以 Haskell 工程师也是贵族思维了?显然不是啊。一个语言的流行程度,要考虑到自身的奋斗,也要考虑到历史的进程,考虑到其设计目的和适合的场景。

    Ruby 社区从各种角度上来说都是新手友好的。达○、北○○鸟那样的机构去培训 Java、Objective-C、PHP 搞定招和校企合作,使中国 PHP 工程师的数量确实是 Ruby 的数倍甚至数十倍。这是因为 PHP 社区没有贵族思维产生的吗?如果是的话,那 Python 现在市场占有率越来越高已经超过 PHP 好几个百分点了,怎么这些培训机构还是在执着于 PHP 呢?

    这是由于 PHP 语言比起 Python 也好 Ruby 也好更容易教学,成为了这些培训班的选择。Ruby 这门语言根本就不会被这些市场选择到,它缺乏这种可以量产的基数,所以要有才会有那种全○培训营这种打着高端旗号收智商税的东西出来。

    但反过来问,数倍数十倍于 Ruby 的工程师,但国内的 PHP 社区贡献者的数量呢?国内绝大多数的 PHP 开发者与 PHP 社区本身完全是极大隔离的。这到底对 PHP 发展是好事还是坏事,这里多少 PHP 工程师是只能做重复劳动性的外包业务工作的,多少人是技术主管口中「天天做负功」的人?

    这些问题的原因怎么扯也扯不上什么「贵族思维」吧。

  • 量产型炮灰工程师 at 2017年06月27日

    没有懂 有经验的人自学 有什么冲突的地方,自学又不是闭门造车。我也不懂 压根儿不信明白吗你这想法太主观了 这两点哪个想法更主观。进高校说这个估计你会被群殴,只要不去武术学校,应该讲这个都没有什么问题。😩

  • 加密的 PPTP 至少比 SS 安全

    没有明白这个结论是怎么的出来的,PPTP 握手时候的 MS-CHAPv2 的破解复杂度已经降低到破解一个 DES 56-bit key 的难度了。几秒钟就干掉了。握手阶段就可以利用这个漏洞实现 MITM Attack,从而监听到通讯的全部内容。

    而 SS 的安全性问题主要集中在「嗅探」上,也就是所谓通过畸形包探查这是不是一个 Shadowsocks 服务器,至少整个流加密过程是不会被监听的。最早被发现的问题是,由于使用了流加密,可以暴力尝试握手包后的一个字节,如果服务器在 2^8 次尝试中有一到三次没有主动关闭链接就可以证明是 Shadowsocks 服务器。然而这样也并不能监听到内容。之后提出了一个 OTA 的防御,但 OTA 协议本身 Length 上也有缺陷,并没有解决问题,最近新版本则是引入了 AEAD,从原理上避免了 MAC 和加密分离被嗅探的情况。

    但无论如何这都是在嗅探层面上的安全性问题,一旦握手后则进入一个流加密的过程,只要选择的 cipher 得当,目前没有合适的攻击手段。而 PPTP 直接被 MITM 已经是无法解决的问题了,是整个通讯被监听的问题了。

  • 这个段子好冷啊。。。😂

  • 👍

  • 我有个问题:

    其实可以将尼特值简单理解为亮度值。 白天,人的眼睛能适应亮度的值高于 3.4 尼特;夜晚,主体颜色接近 0.034 尼特,最亮元素低于 3.4 尼特的亮度眼睛会比较舒适。将尼特值换算成 HSB 颜色模式。也就是说主色调颜色(一般指背景色或最暗的颜色)的亮度不超过 20 ( 0<B<20 ),避免使用极端颜色(纯黑),最亮的颜色亮度尽量不超过 50 。

    这个 nit 到 brightness 的转换是怎么实现的。这是假定了屏幕亮度是 17.34 nits 吗?另外如果屏幕的对比度很差,特别是一些糟糕的 TN-TFT 屏幕的话,限定 B 在 20-50 会不会造成阅读的困难?

  • 申请删帖 at 2017年06月04日

    我百行的 WebSocket 就把 rfc6455 标准中提到的错误情况全处理了,只有一个 Continuous Frame 没有实现,并且在遇到时会抛出,也不会让程序 crash。你以为写个框架这几十页几百页的标准文档是不用看的?你看看 nginx 处理 WebSocket 长连接的部分,除了兼容试验性版本所以加了一堆代码,实际部分也就这么多代码。

    我 HTTP/1.1 标准已经几乎全部兼容了,除了标准中非 Web 服务器的部分。你要说「读完 Apache 的 Souce 你能一天写完吗」,答案当然是不能。但也没有就写了一天,就跑到论坛上各种帖子下回复我比你强比你棒的,你这不是拱火是什么?

    「我说的路由规则是指根据 URL 来反射对应的 Controller 处理」 你 URL 怎么处理的?你自己好意思说这句话吗。

  • 申请删帖 at 2017年06月04日

    我说的「当 TCP 包不能一次性读回来的时候」是正常的包,我甚至都没有在讨论「发了个错包」或者有意的攻击。你的包解析整个都是一片糊涂账,路由匹配啥都没有现在来说「我的路有我自己的规则」,你连 TCP 的规则都不遵守,现在连 HTTP 路由的规则也不遵守,你倒是继续规则啊。你不是还号称

    「我读过 Lighttpd / Nginx 的 sources」

    你写的这玩意像是读过 sources 的情况吗?

  • 申请删帖 at 2017年06月04日

    解析 TCP 包 crash 是由你 Objective-C 写的问题导致的,别没事就怪人家 C unsafe,人家提供的 API 好好的。

    「其实你并不知道,整个 Route 过程是对象反射,而不是 Sinatra 那样的捆绑。」

    路由匹配和你怎么 call 毫无关系,你现在的代码连路由匹配都没有你知道是什么意思吗?

  • 申请删帖 at 2017年06月04日

    还没看源码,你的框架我两天前就反编译把所有代码都读完了。还 ThinkPHP,你的这段代码水平是和 ThinkPHP 一较高下了。

    对,你的 Controller 层是要被覆盖,因为连路由匹配都没有 Controller 也不知道是拿来干什么的。拿 PHP 来比较,我听说吹 Laravel 的,ThinkPHP 这种也能拿来吹的,你还是第一个勇士。

  • 申请删帖 at 2017年06月04日

    要是真要目标 get "/" method 目标一致,该用的是 C++ 11 的 std::function 的一些用法,用 std::bind 属于用错刀了。

  • 申请删帖 at 2017年06月04日

    你的纯原生实现连 TCP 的基础概念的实现都是错的,丢人吧你,还给点建议。你当初第一次找我怎么说的?

    我写的,基于 Objective-C 的自制框架,我没用 NIO,而是直接用 TCP + 非阻模型,另外业务比你的强,你这个只有骨架。
    

    TCP 是写错的,非阻模型是阻塞的,Controller 里 return body 直接写死 Hello World,牛逼啊这框架。 接下来又说不想给我看源码,这叫给建议? 还不停追着我喷,我现在是真生气了,然后说我怎么这性格?

  • 申请删帖 at 2017年06月04日

    别说性能优化了,你的服务器根本是不能用的。当 TCP 包不能一次性读回来的时候你的程序会直接奔溃。而且你所谓有业务模型的 Controller 连路由匹配都没有实现,View 层是一个字符串替换。你看了我的实现,你要真看了我的实现还会说我没有 Controller 吗?

  • 申请删帖 at 2017年06月04日

    「讨论 idris,好歹我写过 !」 我记下来了。你现在告诉我用 Idris 实现一个 a+b 的函数需要哪几步。

  • 申请删帖 at 2017年06月04日

    你看,你以为你用了 accept_nonblock 就认为不阻塞了。要真这样,Ruby 下的 Web Adapter 几乎全是不阻塞的。把你代码的 accept_nonblock 改成 accept,性能不会发生任何变化,这个 accept_nonblock 用得完全是错的。

  • 申请删帖 at 2017年06月04日

    如果今天还认为 Objective-C 比 Swift 好的,至少在 Type-safe 的问题上是落后于时代十年的。

  • 申请删帖 at 2017年06月04日

    我觉得以楼主现在 Objective-C 的理解,看 Idris 大概是看天书吧。。。

  • challenge #1 - #6 update 06/03 at 2017年06月04日

    Nim Game 的 AI 如果无关输赢的话那就是乱写也可以。因为 Nim Game 从一开始就可以证明是必赢或者必输的。所以一个好的 AI 可以在必输时直接投降,必赢时不会输。

  • 申请删帖 at 2017年06月04日

    这篇文章的错误已经发展到了就算放到上世纪末也会被喷。顺便一说,之前反编译完那个楼主巨牛逼的 Autumn 框架后,我就发现这个所谓的使用了「非阻塞」设计的框架完全就是阻塞的,性能非常差,稍微跑个 benchmark 就能发现。之前只是知道结果,读完这篇文章我不难找到了原因,因为楼主对所有涉及到闭包概念的理解全部都是错误的。把 yield 认为是 goto 的,从算法导论到数据结构到编译原理都需要重新学习一遍。如果不是被点名了我都不想回复这篇文章。

  • mark,最近正好在思考给 midori 添加性能监控的功能,但因为不支持 rack 中间件,没有现成的方案。开源的方案也不好找,没什么可以参考的思路。感觉这个很适合,可以抽空读一下代码。

  • 你的 controller 很轻量,fmdb 实现得很轮子,model 很业务逻辑。我用了才知道好和不好,在下自愧不如。

  • 别的我先不说。

    噢对了,Rails 只是框架,是否 IO 阻塞,你可以换服务器的,就像 Perl - Plack,你可以跑在 HTTP::Server::Simple ,也可以跑在 Starman。
    

    建议你重新读一遍这文章。

    事件模型服务器是 Node 本身设计了一套事件调度,我觉得,你是不是爱屋及乌然后又异想天开把它用 Ruby 重新制造?
    

    EventLoop 从上古世纪的 C 代码里就有了,还变成 Node 设计的了,我看连 Erlang 都不想说话。

    然后,我并不打算重写 Rails 那么多的业务逻辑,所以,我的原文意思是我不打算重复制造齿轮,实际我写的部分几乎也只有 PHP CodeIgniter 业务的一半,我还是喜欢轻量级。
    

    一头声称自己搞了有业务逻辑的 Controller,一头又说自己喜欢轻量级,我没有见过这么分裂的想法。

    我还重复制造了用于这个框架的“FMDB”(做过移动开发的应该知道这个),作为数据模型数据连接的底层。我看你的源码,mysql2.rb 都只不过实现了数据库的 exec。
    

    建议你回头重新认识一下元编程,再看看什么叫不过实现了数据库的 exec

    说到自己没有的东西,一口一个轻量级;说到自己有的东西,一口一个你没有。一边说自己已经实现了业务逻辑,和 Rails 对比又说自己不打算重复造轮子。反而到了数据库的时候,又说自己重新造了 FMDB 的轮子而我只实现了 exec。

    双标也不带这么玩的。

    你要真觉得自己框架好,我觉得无所谓。但不能自己打自己脸地瞎搞啊。

    因为是内部的东西,而且,我没有你们这么爱分享
    

    你跑来说你的框架实现得更好,既不说好在哪里有不说实现细节也不开源最后告诉我是内部的东西。这和「这个世界上有神,但神是不可知的」有什么区别?

    我喜欢低调,多做少说,我预测你这套东西,迟早可能会放弃的
    

    那我来预测几件事吧。

    1. 微软,迟早可能会倒闭的。
    2. 上海房价,迟早可能会跌的。
  • challenge #1 - #6 update 06/03 at 2017年06月02日

    challenge 4 intermediate 对新手来说相当难,我给个大致思路吧。

    方法一:扫描表达式,把所有 * / 都算了,然后重新扫描算 + -,遇到括号递归执行

    方法二:处理成抽象语法树(AST)以支持更多符号的自由添加

    challenge 3 hard 最快速的做法是字符排序然后哈希,复杂度可以做到 O(m+n) m 是 word list 的长度,n 是查询的数量。如果需要输出排序还需要加一个 O(n*p) p 是字符串的长度