我正在遇到一个间歇性HTTP连接中断的问题。虽然我了解断开连接的原因，但我不确定为什么会出现这一点。 background：

Question

问题：

toding获取对在Heroku上部署的服务的请求（我怀疑是根本原因，以下详细介绍），云NAT意外地分配了大量端口。一旦分配的端口数量达到1024，从POD到此服务的每个传出连接都会被Cloud NAT切断（GO Service中的典型错误：read tcp 10.10.0.50:50450->12.123.123.123:443: read: connection reset by peer

）

• 为什么我认为Heroku是问题？ 在我们的开发集群中，我用端点部署了一个稍微修改的应用程序，该版本接受以下示例参数：

• {
      "targetURL": "https://httpbin.org/delay/7",
      "idleConnections": 2,
      "numGoroutines": 10,
      "maxRequestsPerSecond": 100,
      "totalRequests": 3000,
      "disableKeepAlives": false,
      "maxConnsPerHost": 10000
  }

th这个端点以
• totalRequests
的速率发送

targetURL

至maxRequestsPerSecond。我为客户端和这些请求的运输设置添加了调整选项，以检查其影响。

我如何验证测试？ 我向各种测试API（例如httpbin.org，httpbin.dev）和流行的网站（例如Google.com，github.com）和其他一些随机网站发送了数千甚至数十万的获取请求。这些测试显示，在云NAT中没有重大端口分配问题的情况下，几乎100％成功的请求。即使闲置/最大连接和有限数量的Goroutines也可以实现高RPS。 wo，当请求在Heroku上部署的服务（例如，我们在生产和开发方面的下游服务，在Heroku环境中审查应用程序以及其他Heroku Deployed Services），几秒钟后，连接开始下降。在这些请求期间监视云NAT总是显示出分配的端口的急剧增加。 在本质上，我怀疑端口分配策略（Cloud NAT文档指出，它取决于A域的IPS数量）。但是，通过解决单个IP或多个IP的服务测试（最多4个）显示出类似的端口分配行为（我们的下游服务解决了2个IP）。

尽管这个问题似乎很小，但这显着影响了我们从GKE到Heroku服务的高通量的目标（例如，以每秒20个请求发送2000个请求，触发了这个问题，这相对较低）。

焦点：

我的目标是实现将请求从GKE发送到我们的Heroku服务的最高可能的吞吐量。 我不确定Heroku是否是直接原因，但这是一种强烈的怀疑（每当我要求在Heroku内部部署服务时，就会注意到这种行为）。

不仅可以，Heroku应用程序日志没有显示出删除请求的错误或证据（这很有意义，因为这发生在云NAT层中）。例如，在对Heroku的1000个请求中，有800个成功，但有200个连接重置错误 - 仅在Heroku服务方面提供800个成功的登录。
我已经审查了Heroku的网络文档，但没有发现与我们的下游Heroku App登录的相关错误（例如，Backlog太深了）。

有人遇到云Nat和Heroku的类似问题吗？任何有关为什么Cloud Nat在与Heroku服务互动时可能会分配如此多端口的任何见解以及对此问题的潜在解决方案都将受到高度赞赏。

谢谢你！

我在类似的设置中遇到非常相似的问题。您是否找到了有关原因的解决方案或更多信息？