背景：我正在开发一个移动应用程序（在线聊天），它使用与后端服务器的持久 TCP 连接。在之前的版本中，我们使用了众所周知的加密方案来保护有效负载并使用共享密钥进行签名。这提供了足够的保护，防止数据篡改和逆向工程。但流量仍然容易受到重放攻击：有人可以捕获网络流量并重放它，服务器会接受请求，因为它不知道它是真实的还是重放的。为了解决这个问题，我们引入了时间戳和随机数，它们提供了针对重放攻击的保护。
一切都很好。后来决定使用TLS（传输层安全）来保护客户端和服务器之间的所有通信。实施了 TLS 并提供针对中间人攻击的额外保护层，我们将服务器的公共证书固定在客户端上。
这让我想到一个问题：既然 TLS 已经提供了针对这些攻击的保护，是否仍然有必要使用自定义加密并防范重放攻击？在我的研究中，我发现 TLS 在传输过程中提供保护，即防止中间人，但如果发起者本身想要欺骗系统并修改有效负载或重放流量怎么办？TLS 是否可以防止故意作弊者试图以某种方式拦截其操作系统网络层的流量？我的理解是 TLS 提供端到端加密，但我怀疑如果发起者愿意，TLS 流量实际上可以被重放。
我还知道基于内存的攻击，攻击者会修改设备上的内存，从而修改有效负载（甚至可能是记录和重放）。但即使我们的自定义加密+重放防护也无法防范这些攻击。
来自： https: //www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Benefits
“TLS 还提供了两个通常被忽视的额外好处：完整性保证和重放预防。TLS 通信流包含内置控件，以防止篡改加密数据的任何部分。此外，还内置控件以防止加密数据被篡改。捕获的 TLS 数据流，以免稍后重放。
需要说明的是，TLS在传输过程中为数据提供了上述保证。TLS 不会为静态数据提供任何这些安全优势。因此，必须添加适当的安全控制来保护应用程序或数据存储中静态的数据。”
有没有一种方法可以严格确保每个Hashmap存储桶中的条目数，而又不会破坏object.hashcode()Java中的功能？
负载因子是平均值：（条目数）/（桶数）。本质上，假设我有一个容量为1000的Hashmap。为便于说明，在本示例中，我将负载因子设为1。要存储在HashMap中的100个对象具有错误的哈希码函数，这些函数始终返回每个对象都具有相同的值。当我完成100个对象的存储后，它们将全部映射到同一HashMap存储桶，最终我获得了LinkedList性能。负载因数将保持沉默，因为100个条目/ 1000个存储桶= 0.1 <1。现在，如果我放入1 M个相同的对象，会发生什么。HashMap将永远不会被调整大小（无论如何都不会使用），因为LF将永远不会被触发。
我知道这是现实世界中不常见的情况，但我想增进我的理解。HashMap中是否有一种方法可以防止这种情况发生，或者至少可以从结构本身中得到一些警告？