V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
cuishuang
V2EX  ›  Redis

Redis 加上密码后,整体性能下降 20%?

  •  
  •   cuishuang · 2024-05-12 17:19:17 +08:00 · 8290 次点击
    这是一个创建于 371 天前的主题,其中的信息可能已经有所发展或是发生改变。

    这太震惊了...(图片来自极客时间 安全攻防技能 30 讲)

    难道每次执行什么 get,set 操作,都会检测一遍密码吗? 我理解不能像 mysql 一样,有个连接池,初始化一些长连接,之后就不用再认证/鉴权什么的了

    43 条回复    2024-05-13 20:01:55 +08:00
    R4rvZ6agNVWr56V0
        1
    R4rvZ6agNVWr56V0  
       2024-05-12 17:26:07 +08:00
    支持 TLS 啊,为啥一定要用密码
    Yadomin
        2
    Yadomin  
       2024-05-12 17:47:58 +08:00   ❤️ 5
    真的吗?我本地测了一下,不保证正确
    qsnow6
        3
    qsnow6  
       2024-05-12 17:53:10 +08:00
    校验个密码能有多大的损失,扯蛋呢
    mohumohu
        4
    mohumohu  
       2024-05-12 17:55:30 +08:00
    那不如直接用 unix domain socket
    lsk569937453
        5
    lsk569937453  
       2024-05-12 18:00:10 +08:00
    redis 是基于 TCP 协议的啊,握手(验证密码)之后就一直保持长连接,后续都是处理指令了啊。
    zed1018
        6
    zed1018  
       2024-05-12 18:00:14 +08:00
    首先后来版本的 redis 默认是没密码没错,但是也默认有保护模式,无密码账户只能在本机登录。

    所以这文章纯属扯淡。
    LeeReamond
        7
    LeeReamond  
       2024-05-12 18:07:13 +08:00
    @qsnow6 如果协议里每条请求都带验证头的话确实会降性能,就像 http 上如果带鉴权插件就是会降一样,不过照我的记忆 RESP 是通过 auth 命令单次校验的。
    yalin
        8
    yalin  
       2024-05-12 18:09:43 +08:00
    毕竟生成的内容
    kneo
        9
    kneo  
       2024-05-12 18:12:54 +08:00 via Android
    没测试过,不好说。redis 操作比起普通的业务操作来说可以认为是超级快,理论上有可能因为增加一个验证环节就导致极端性能测试的吞吐量下降的。
    k9982874
        10
    k9982874  
       2024-05-12 18:23:24 +08:00 via Android
    啊?根据 redis-cli 的行为来看,感觉有点扯淡。redis-cli 也只是首次登陆时验证,建立连接后执行命令不需要再次验证,要是说 redis-cli 记录了用户密码每次附在请求中一起提交我是不信的。
    想验证是否是真的像文中所说只要查一下各编程语言中的 redis client 实现即可。
    ixiaohei
        11
    ixiaohei  
       2024-05-12 18:35:41 +08:00
    使用 redis 密码建议使用长连接;保持 session 。短连接每次新建连接都都需要 auth
    cuishuang
        12
    cuishuang  
    OP
       2024-05-12 19:38:47 +08:00
    @Yadomin 我去,厉害了...怎么做到的,老哥有脚本啥的吗
    cuishuang
        13
    cuishuang  
    OP
       2024-05-12 19:39:14 +08:00
    @yalin 当时还没有 chatgpt
    Yadomin
        14
    Yadomin  
       2024-05-12 19:44:15 +08:00 via Android
    @cuishuang redis 自带的 redis-benchmark
    devliu1
        15
    devliu1  
       2024-05-12 19:59:10 +08:00
    长连接就好了,只需要第一次发送 AUTH 命令
    hefish
        16
    hefish  
       2024-05-12 21:11:52 +08:00
    很多贩卖安全的人,本身是不懂具体事务的,基本上只是照搬条例而已。
    fkdtz
        17
    fkdtz  
       2024-05-12 21:53:54 +08:00
    无论从实际使用经验,还是 Redis 的设计原则、还是 client server 通信原理来看,好像都不大可能啊。
    他没说具体什么原因导致的吗?
    极客时间上的课不都是付费的么,应该很严谨才对,评论中没有提出疑问的么。
    Kinnice
        18
    Kinnice  
       2024-05-12 21:59:43 +08:00 via Android   ❤️ 4
    他该不是每次操作的时候都先 auth 一下吧
    ETiV
        19
    ETiV  
       2024-05-12 22:02:45 +08:00 via iPhone
    用 PHP 测得的数据?以 req/s 为单位
    pluto1
        20
    pluto1  
       2024-05-13 00:25:02 +08:00 via iPhone
    去看看 RESP 协议就知道了,非常简单的,就是一来一回,没有额外的东西的,密码验证只需要 tcp 连接建立后 auth 一下,后面跟没有密码是一样的
    Zzdex
        21
    Zzdex  
       2024-05-13 00:30:55 +08:00
    有点扯
    tomczhen
        22
    tomczhen  
       2024-05-13 01:42:42 +08:00
    IT 民科
    WonderCc
        23
    WonderCc  
       2024-05-13 07:44:19 +08:00
    这不扯淡吗
    flyqie
        24
    flyqie  
       2024-05-13 08:07:27 +08:00 via Android
    每次链接都 auth 一下这玩法太智障了,redis 这么用了怕不是被人笑话一辈子。。

    极客时间的课水到这种程度了吗?
    flyqie
        25
    flyqie  
       2024-05-13 08:08:26 +08:00 via Android
    @flyqie #24

    打错了。。

    应该是每次操作
    Rehtt
        26
    Rehtt  
       2024-05-13 08:23:19 +08:00 via Android
    @GeekGao 零信任模型
    shakeyo
        27
    shakeyo  
       2024-05-13 09:04:03 +08:00
    他这是每次执行命令都用新连接?
    whoosy
        28
    whoosy  
       2024-05-13 09:04:13 +08:00
    用脚趾头想想都不可能
    crystom
        29
    crystom  
       2024-05-13 09:07:01 +08:00   ❤️ 1
    php 传统 fpm 模式是这样的,不过一般也用在性能敏感的场景像后台管理,没问题的
    me1onsoda
        30
    me1onsoda  
       2024-05-13 09:10:34 +08:00
    要连接池这个,jedis 不就是吗
    cheng6563
        31
    cheng6563  
       2024-05-13 09:42:28 +08:00
    没搞连接池吧,每次发指令都重新验密码
    8355
        32
    8355  
       2024-05-13 09:47:23 +08:00
    我没看源码。。。但是我觉得如果 redis 是这样设计的 那连接的意义在哪里? 这不符合常规认知。。。。。
    vczyh
        33
    vczyh  
       2024-05-13 10:01:03 +08:00
    别的不清楚,我写过 RESP 协议,客户端认证的时候只需要发送 AUTH command ,这个之后不会每次发送认证信息,只需要发送执行的 command 就可以,所以理论上不会影响性能。
    InDom
        35
    InDom  
       2024-05-13 10:12:29 +08:00
    作为一个经常使用 telnet 当 redis-cli 的人表示,起码 auth 只会在创建链接的时候发一次密钥后续是不需要发的。

    至于每次请求服务端会检查,我觉得一个稍微成熟的开发都不会出现这个问题。

    至于测试环境,是不是每次都 new Redis 了?

    如果是,那结果就算是 50% 我也理解。
    tingyunsay
        36
    tingyunsay  
       2024-05-13 10:18:55 +08:00
    csdn 即视感
    wetalk
        37
    wetalk  
       2024-05-13 10:23:51 +08:00
    极客时间很多作者纸上谈兵,根本没有实操经验,信他们不如信坛子里的老哥
    Dream95
        38
    Dream95  
       2024-05-13 11:11:39 +08:00
    这样的也能卖课
    error0
        39
    error0  
       2024-05-13 11:20:55 +08:00
    在 server.c 的 processCommand() 方法执行命令之前 会执行 authRequired() , 判断 client 的 authenticated 是否为 1 (如果开启认证)。执行 authCommand 的时候如果账号密码正确就标识为 1 。


    processCommand: https://github.com/redis/redis/blob/8a05f0092b0e291498b8fdb8dd93355467ceab25/src/server.c#L3948

    authCommand: https://github.com/redis/redis/blob/8a05f0092b0e291498b8fdb8dd93355467ceab25/src/acl.c#L1490
    nothingistrue
        40
    nothingistrue  
       2024-05-13 11:31:48 +08:00
    这大概是「几十年」前的销售推广,因为很早就把技术人员开了只剩商务人员,就一直这么往外面忽悠人。代码安全审查领域,你只要见得多了,就总会碰到这样的坑爹玩意,客户资质越高,越容易碰到。
    julyclyde
        41
    julyclyde  
       2024-05-13 11:38:56 +08:00
    如果前边有代理服务器,而代理服务器和 redis 本身维持了长连接,那么,
    单次验密之后信任整个连接后续指令,是不是会导致其它未验证身份的客户端发给代理服务器的命令也被执行呢?
    R4rvZ6agNVWr56V0
        42
    R4rvZ6agNVWr56V0  
       2024-05-13 11:40:55 +08:00
    @Rehtt ???
    googol2chen
        43
    googol2chen  
       2024-05-13 20:01:55 +08:00
    redis 的第三方库应该都有提供长连接方式
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5566 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 01:27 · PVG 09:27 · LAX 18:27 · JFK 21:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.