在设计服务器和iOS / Android客户端之间的通信协议时，我处于两难境地。
我想制定协议：
我甚至通过HTTP REST接口起草了一些带有加密/编码/压缩算法的解决方案。简而言之，使用DH算法或RSA来保护对称密钥的传输，以便稍后加密会话中的消息。有点像iOS官方示例CryptoExercise
然而，当我在Stackoverflow中搜索类似的问题时，我发现几乎所有的建议都是使用HTTPS＆＃39;而不是自己重新发明轮子。
我同意重新发明轮子并不明智，但我不确定HTTPS是否可以在移动应用程序通常面临的恶劣网络条件下正常工作？ 每次连接建立时，HTTPS都会传输密钥。它是否真的适合HTTP REST API，它快速且只有很小的有效载荷？ 还有其他错误吗？
提前感谢您的回复。
答案 0 :(得分：1)
...或RSA以确保对称密钥的传输
你应该坚持使用提供前瞻性保密的密码套件。它的标准做法是使用像DHE和ECDHE这样的短暂密钥交换。我相信TLS工作组正在弃用TLS 1.3中的RSA密钥传输。请参阅TLS WG的TLS: Clarifications and questions: TLS1.3 - Static RSA and AEAD。
轻量级：让iOS / Android客户端响应更好的用户体验
痛点是密钥交换，你可能无法避免。
对于批量加密，您可能应该使用新的ChaCha / Poly1305密码套件，例如TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305，TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305，TLS_DHE_RSA_WITH_CHACHA20_POLY1305和TLS_RSA_WITH_CHACHA20_POLY1305。它们的速度提高了4倍左右。请参阅Speeding up and strengthening HTTPS connections for Chrome on Android。
我甚至已经通过HTTP REST接口起草了一些带有加密/编码/压缩算法的解决方案
WebCrypto距离标准化还有几个月的时间。之后，浏览器必须采用它。所以你可能几个月到几年都没有基元。
对于自定义DH，您将缺少BigIntegers。即使WebCrypto发布其第一个标准，也不会包含BigIntegers。见WebCrypto: Question on BigInteger operations。 （顺便说一句，我有一个用于多因素身份验证的自定义DH方案。这也是我需要那些BigIntegers的原因。）
我甚至已经用一些加密/编码/压缩算法起草了一个解决方案
我希望您在更高层中实现压缩泄漏信息。例如，参见Rizzo和Duong关于HTTP和SPDY协议的CRIME Attack。
然而，当我在Stackoverflow中搜索类似的问题时，我发现几乎所有的建议都是“使用HTTPS”，而不是“自己重新发明轮子”。
您可能应该在Google学术搜索上查看有关mTCP和mUDP，移动VPN，移动TLS，无线TLS等的文章。
加密不是你的问题。快速恢复将成为您的问题。
我同意重新发明轮子并不明智，但我不确定HTTPS是否能在恶劣的网络条件下正常工作......
好吧，就像Jon Bentley博士所说的那样：如果它不一定是正确的，我可以按照你希望的那样快速地做到。你可能应该坚持使用SSL / TLS，在有缺陷的情况下加强它，然后在密码套件中选择加速它。
如果HTTPS在恶劣的网络条件下可以正常工作，这通常是移动ApP所面临的
移动在实践中并没有那么糟糕。删除连接没什么可以做的。如果漫游时未传输IP，则无法执行任何操作。即使您知道自己没有覆盖，设备的ConnectionManager声称write成功也无法做到。
您可以做的就是确保快速恢复。
也许你应该研究UDP和DTLS。
它是否真的适合HTTP REST API，它很快且只有很小的有效载荷？
见本特利的报价。
不要使用该死的浏览器安全模型。这是一个诅咒。 （当然，除非您的模型中可以接受Diginotar和Trustwave类故障）。
答案 1 :(得分：0)
我做了一个测试来比较“典型”网络条件下的HTTP和HTTPS性能：
测试结果： HTTP调用：2138次成功，13次失败，平均获取时间：492毫秒 HTTPS调用：1957次成功，5次失败，平均获取时间：778毫秒
测试结果显示获取一个小的有效负载： 1. HTTPS与HTTP一样稳定 2.主要短缺是延迟，比HTTP慢58％
我认为这是可以接受的，所以我正在考虑转向HTTPS。
毕竟，尽管发明一个轮子并不困难，但发明一个更好的东西并不容易，就像@jww的评论一样。
我将继续进行另一项测试，以了解具有更大负载的HTTPS性能。
谢谢大家。