vus520
V2EX  ›  问与答

求一个高效的 api 加密及压缩方案,可付费

  •  
  •   vus520 · Apr 20, 2016 · 2397 views
    This topic created in 3764 days ago, the information mentioned may be changed or developed.
    业务现状
    1 ,纯 api 请求
    2 ,内容 50KB 左右
    3 ,日均 200 万请求,目前宽带峰值 50-80M
    4 , php 语言, php 实现最好,接受 c 扩展, nginx+lua 方案

    目前的方案
    1 , api 返回的 json 整体加密,再使用 nginx gzip ,压缩率 20%左右,不加密能有 70%的压缩率
    2 ,部分核心字段加密,压缩能到 50%左右

    期望的方案
    1 ,整体加密,压缩率在 50 以上
    2 ,加密效率在 1ms 以内

    可付费。
    9 replies    2016-04-21 10:33:59 +08:00
    raptium
        1
    raptium  
       Apr 20, 2016   ❤️ 1
    先压缩再加密比较合理吧
    加密的一个特性就是会让熵变大,于是就没什么压缩效果了
    honeycomb
        2
    honeycomb  
       Apr 20, 2016
    @raptium
    是啊,先加密便没法压缩了
    66450146
        3
    66450146  
       Apr 20, 2016   ❤️ 1
    这种情况不是应该 https 吗……
    scourgen
        4
    scourgen  
       Apr 20, 2016
    简单, zephir 随便写一个都行
    vus520
        5
    vus520  
    OP
       Apr 20, 2016
    @66450146 想加密内容,不想被抓包暴露原文,防篡改是次需求
    billlee
        6
    billlee  
       Apr 20, 2016
    你这种要的只是混淆,不是为了保证数据安全的加密,可以先压缩,再加密, 加密算法就用 rc4 这样比较快的就好了, IV 还是要的。
    另外,加密不能比避免篡改!!!要放篡改请用数字签名或 MAC, 或者,就是直接上 HTTPS.
    vinsa
        7
    vinsa  
       Apr 20, 2016 via iPhone
    @vus520 没明白, https 哪不符要求?能窃听原文?如中间人纂改证书会导致会话失效。
    billlee
        8
    billlee  
       Apr 20, 2016
    @vinsa 他像防的不是中间人,而是用户
    vus520
        9
    vus520  
    OP
       Apr 21, 2016
    @billlee 我们之前的经验,压缩后加密,长度又增加到加密前的长度了
    昨天听朋友提到一个方案,加密可以保持原有长度,目前正在测试

    期待更多方案
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1473 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 16:37 · PVG 00:37 · LAX 09:37 · JFK 12:37
    ♥ Do have faith in what you're doing.