据我了解，如果您尝试使用欺骗性 IP 地址发出 HTTP 请求，则 TCP 握手失败，因此无法完成 HTTP 请求，因为来自服务器的 SYN/ACK 没有到达邪恶的客户...
...在大多数情况下。但是现在让我们基本上忽略这四种情况：
- 中间人（MITM）攻击
- 恶意客户端控制 Web 服务器网络的
情况 - 恶意客户端在自己的本地网络上伪造另一个 IP 的情况
- BGP 攻击
那我真的可以信任一个HTTP请求的IP地址吗？
背景：我正在考虑建立一个IP地址和资源使用情况的地图，并阻止消耗过多资源的IP地址。但我想知道是否有某种方法可以伪造无限数量的 IP 地址（通过使用伪造的 IP 发出成功的 HTTP 请求），从而使 Web 服务器的IP 缓冲区资源使用量变得巨大并且导致内存不足错误。
（嗯，也许一个邪恶的互联网路由器可以伪造很多请求。但它们并不是邪恶的。（这将是 MITM 攻击？这就是为什么我在上面说的主要是无视））
是的（假设您忽略了客户端能够在欺骗性 IP 处拦截握手的返回），如果您正确地做事。HTTP 请求通过 TCP 完成；在握手完成之前，Web 服务器不会开始处理 HTTP 请求。授予随机用户可以尝试欺骗握手结束；但由于他们必须猜测服务器生成的 ACK，因此他们每次成功的机会只有 2^32 分之一（约 40 亿）。
正如 Ladadadada 评论的那样，确保您没有在 Web 应用程序中选择错误的远程 IP 地址值。您需要来自IP 数据报头的 IP 地址（特别是源 IP 地址）。您不希望像X-Forwarded-For / X-Real-IP这样可以轻易伪造的值，因为它们是在 HTTP 标头中设置的。绝对通过尝试欺骗某些IP地址来进行测试；使用浏览器插件或手动使用telnet yourserver.com 80.
这些字段的目的是使网络代理（可能会说缓存内容以更快地提供服务）可以与网络服务器通信用户的真实 IP 地址，而不是代理 IP 地址（可能用于数百个用户）。但是，由于任何人都可以设置此字段，因此不应信任它。
我可以信任 HTTP 请求的源 IP 吗？
您可以合理地确定 HTTP 请求的源 IP 地址是生成请求的 TCP 连接的源地址。
何时信任 IP 地址是一个复杂的特定于上下文的问题，但这并不是您真正要问的。
您是否担心在应用层使用/实施每 IP 速率限制的影响以及任何其他拒绝服务攻击的漏洞？
我想知道在应用层这样做是否会引入额外的漏洞，是的。
这完全取决于您的实施，包括政策和技术。
根据对这些问题的回答，速率限制可能更好地放置在服务基础设施的其他地方，例如专用防火墙、本地防火墙。或者，如果访问是经过身份验证的，那么经过身份验证的凭据可能是费率核算的更好密钥，并且您的界限将被定义。
如果您不打算继续 TCP 握手，那么向 HTTP 服务器发出欺骗的 SYN 有什么意义？除非（可能是伪造的）客户端获得 SYN/ACK，并继续建立 TCP 会话并发送 HTTP 请求，否则您的 Web 服务器不会看到 HTTP 请求。
将数据库存储在磁盘上，巧妙地构造它（像一棵树）以便快速查找。
无论客户是否被欺骗，这对您真的有影响吗？如果他们行为不端，他们就会行为不端，无论他们是否被欺骗。
从 Web 服务器的角度来看，我认为远程 IP 是真正的远程 IP。