lesismal's repos on GitHub
Go · 2039 人关注
nbio
Pure Go 1000k+ connections solution, support tls/http1.x/websocket and basically compatible with net/http, with high-performance and low memory cost, non-blocking, event-driven, easy-to-use.
Go · 891 人关注
arpc
More effective network communication, two-way calling, notify and broadcast supported.
Go · 104 人关注
go-websocket-benchmark
Go · 42 人关注
nbio-examples
Go · 11 人关注
llib
Go · 6 人关注
pipe
Go · 5 人关注
cbuffer
Go · 5 人关注
go-net-benchmark
Go · 3 人关注
go-http-server-benchmark
Go · 2 人关注
noleak
1 人关注
conc
Better structured concurrency for go
1 人关注
Developer-Books
编程开发相关书籍整理分享,持续更新...
Go · 1 人关注
perf
Go · 0 人关注
awesome-go
A curated list of awesome Go frameworks, libraries and software
0 人关注
cli
GitHub’s official command line tool
0 人关注
emoji-cheat-sheet
A markdown version emoji cheat sheet
0 人关注
engineering-blogs
A curated list of engineering blogs
Go · 0 人关注
gevent-benchmark
Go · 0 人关注
gin
Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
Go · 0 人关注
go
The Go programming language
Go · 0 人关注
gopkg
Universal Utilities for Go
0 人关注
guide
The Uber Go Style Guide.
Go · 0 人关注
gws
High-Performance Go WebSocket Server & Client
0 人关注
http-parser
http request/response parser for c
Go · 0 人关注
kcp-go
A Crypto-Secure, Production-Grade Reliable-UDP Library for golang with FEC
Go · 0 人关注
kitex-benchmark
0 人关注
lesismal
HTML · 0 人关注
lesismal.github.io
Go · 0 人关注
melody
:notes: Minimalist websocket framework for Go
Go · 0 人关注
mempooldebug
lesismal

lesismal

V2EX 第 497905 号会员,加入于 2020-07-06 13:49:58 +08:00
美国宣布全面禁止竞业协议
程序员  •  lesismal  •  16 天前  •  最后回复来自 ChrisFreeMan
2
github 被人 at 说币安空投,是诈骗吗?
程序员  •  lesismal  •  150 天前  •  最后回复来自 lesismal
2
4C-2G 来战 [ Golang Websocket 百万连接测试 ]
程序员  •  lesismal  •  170 天前  •  最后回复来自 lesismal
34
nbio 近期的一些功能更新,来骗点 star
  •  1   
    Go 编程语言  •  lesismal  •  2023-04-18 14:04:25 PM  •  最后回复来自 lesismal
    2
    吃八分饱长寿与充电 85%能保护电池
  •  1   
    硬件  •  lesismal  •  2022-05-06 13:22:14 PM  •  最后回复来自 julyclyde
    22
    lesismal 最近回复了
    @msg7086 虽然可能 block 我了, 但说不定你 logout 能看到, 所以补几句吧, 你让我举例子, 我说黑产黑了的很多没曝光出来你又说我假大空, 那你可以看下 github 的例子, 可以看下 #158 cdn 脱裤的例子, 淘宝亚马逊以及#174 微信的推荐设计

    自己脑袋一热也不认真分析下我的回复, 就无脑喷我, 只会限制你提升自己的技术层次, 这跟我所理解的原因(病因)八九不离十, 就是舒适区和沉没成本, 另外一个词就是"聪明反被聪明误", 因为自己懂了一些, 所以拒绝接受不一致的. 但技术需要冷静分析, 论坛上讨论技术我多数时候是一就是一二就是二, 不喜欢模棱两可去赞成别人, 所以我的观点如果和你不一样的时候, 你可能会觉得我带着情绪, 但不是, 技术的东西是实在的, 谁也不给谁发工资, 不需要看脸色
    @viruscamp 跟前面好多层一样, 兄弟你这也是没 get 到
    @viruscamp

    我已经发现了, 讲的原则逻辑和道理各位基本都不怎么看, 所以我举例子请教各位, 淘宝亚马逊不用明文, 是为什么?

    github 日志输出明文的问题暴出来大家也"多数人"认为这是问题, 为什么? 我这里说"多数人"而不是说"所有人"认为这是问题, 因为我发现可能并不是"所有人"认为这是问题, 比如各位坚持明文的
    > 谁出钱谁说了算。你出钱吗?你不出,所以你说了不算。

    公开的技术讨论, 各自公司自己的事情自己负责, 你看见我什么时候说过我说了算了要求你们所有人都要按我说的做了?
    但是, 我公司的项目就是我说了算, 你也管不着

    > 你自始至终都没有对 Before 和 After 做过具体的案例分析,帖子里基本就是一些假大空的呐喊,什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

    哦哦, 和着我说的技术逻辑安全逻辑安全原则和举例子之类的, 都算是假大空是吧? 我说了那么多逻辑原则例子你思考吗?你不思考还狡辩解释那么多层然后被逼的我说你舒适区有错吗?

    > 这么高一层楼 200 来个回复,说句实话,非常给你面子了,因为讨论的过程还算礼貌,v 站大多数人也不愿意说脏话。

    怎么的, 有些个小孩子上来就说"你水平低"之类的, 你见我说几句脏话了吗? 聊个技术还怕别人喷, 那就不要出来聊

    > 换到激进点的论坛里,就不知道是你保卫家人在先,还是管理员看不下去直接 ban 号在先了。

    自己说不过了, 就改成威胁别人要骂人了是吧? 我不 care 低素质的人, 你随意

    @Livid 我感觉这是在威胁骂家人了

    > 帖子内容太过贫乏,甚至激不起我一点讨论技术的欲望。有句话叫,非蠢即坏。

    蠢和坏也是要以事实逻辑为依据, 我每一个点都有对应的解释, 如果你看不懂然后以为我蠢, 那你也随意, 你嫌烦的话可以直接 block 我

    > 看你讨论过程,好像也不像是坏,那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的,有一种老子说的才是对的,你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

    你看看你这两层的回复, 谁在假大空?

    @msg7086
    > 对于题主的不信任 https

    @mayli 我可是完全没说过这话啊兄弟, 你和其他很多楼一样, 几乎完全没 get 到我说的是什么...
    > 你不猜你怎么知道哪些厂为啥不加密?这两家都是你主导的还是你认识主导这个需求的人?

    @LuckyLauncher 我都是在按照逻辑讲安全的, 因为一些人举例子 github 说大厂用明文所以就该用明文所以我举大厂的反例

    > 你不过也只是在按照你的方向猜测罢了

    我不是靠猜测, 都是按道理按逻辑在讲. 我举例子反驳他们 github 的例子, 虽然我没有说原因, 但我相信不用猜测——因为大厂不用明文的原因就是为了更高的安全强度, 这些不需要认识他们主导这个的人
    5 天前
    回复了 yfixx 创建的主题 健康 你们有过心跳很快的经历吗
    这种事情还是听专业医生的靠谱
    @livin2 #186 对, 对于老项目是这样的. 但对于新项目可以避免这些
    @LuckyLauncher

    > 电商领域有没有可能考虑的不是安全性而是反爬机制

    都重要

    > 你看看他们的风控就知道了,以前淘宝的风控被诟病成人类都无法使用。

    这反到可能是因为他们反扒导致功能上频繁让用户验证导致用户诟病, 如果只是设计正常的登陆反倒可能不至于被诟病, 我用淘宝不多, 所以也不能确定是怎么回事

    > 当然这只是我的猜测,至于厂商为什么选择加密只有他们做加密的人知道了,可能亚马逊和淘宝选择加密的理由还不一样。

    不要随便猜了, 就不能看下我这么多发言的内容吗, 但凡大家能用冷静分析的态度来思考这个问题, 而不是一开始就拒绝观点, , 也不至于这么多人还坚持明文了...

    我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
    加上经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上的完整安全
    @qq135449773

    > 二次验证防止的是未经授权的用户登陆操作,防止的不是密码泄露。

    我也没说二次验证是防密码泄漏啊,就是因为密码(不论明文不明文)都可能泄漏,所以才要二次验证这些额外的打补丁。但不是说有了二次验证密码就可以不在乎了,否则还要密码干啥,都走 SMS/EMAILS 之类的 OTP 登陆更省事了但用户又说你强行要我私人手机号了。。

    > telegram 和 whatsapp 这类东西,包括微信,做扫码登陆,因为他们本来主打平台就是移动端,只是顺便做的其他平台而已,所以才敢这么做,至于安全与否完全只是顺便而已。

    是不是顺便我不知道,但安全问题,如果安全级别要求高,我们不应该用“顺便”的方式来思考

    > 给密码再加密一层,密码是安全了,返回给用户的 session 你也要加密返回给用户吗?

    例如 JWT 吧,它确实是 server 加密后返回给 client 的,你的用法或者理解是不是有什么误会


    > 像 CDN 、WAF 这些做 tls offloading 的东西,还有一些其他公有云设施,这种东西你只能默认信任。
    > 假设你以上所有东西都 ok ,你怎么确保你公有云 instance 的云盘或者云数据库不会被未经授权的读取?

    同样的,你的这些观点就像我回复其他人的以及 append 里讲的一样,不要只关注我所说的一两个 part
    用别人服务默认信任、别人也应该尽量提供保障,这个我没有否定过
    重要的是,各个流程链条上,各自尽量做好自己环节的事情,三方厂商做好自己这一层,出了问题它是要赔钱的,我们不能确保三方一定不出问题,所以自己方负责的链条也做得安全强度更高,有错吗?

    > 所以就不要自己骗自己了。

    这句话我建议你先送给自己,然后好好看下我、以及与我持相同相近观点的各个楼层或者其他地方的知识点
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1172 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 23:01 · PVG 07:01 · LAX 16:01 · JFK 19:01
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.