TCP RST 对 Javascript 脚本 src 标记的页面加载时间的影响
我想弃用（关闭/不发送 HTTP 响应）某些旧的 HTML 和 HTTP 响应。我的客户在他们的页面上安装了 JS 代码。并非所有客户都可以在我们弃用之前更新其所有网页，但我可以弃用。
代码的简单示例如下：
客户域 customer.com，具有 HTML 和 HTML 格式。他们页面上的 JS：
<script src="http://mycompany.com/?customer=customer.com&..."></script>
我们正在考虑将交换机配置为针对传入的已弃用请求发送 TCP RST 响应到 http://mycompany.com/...，所以我的问题是，将我们的交换机配置为在传入 TCP 连接上使用 TCP RST 进行响应的方法是否有任何副作用（例如，停止页面加载）？ 显然，我希望对客户的影响最小（即没有）地点。
I want to deprecate (turn off/not send HTTP responses) for some old HTML & JS code that my clients have installed on their pages. Not all clients can update all of their webpages prior to when we deprecate, but I have the OK to deprecate.
Simple example of what the code can look like:
Customer domain, customer.com, has HTML & JS on their pages:
<script src="http://mycompany.com/?customer=customer.com&..."></script>
We are considering configuring our switches to send a TCP RST response on incoming deprecated requests to http://mycompany.com/..., so my question is, are there any side-effects (stall page loading, for example) with the approach of configuring our switches to respond with a TCP RST on the incoming TCP connection? Obviously, I want the least (ie no) impact on a customer's site.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不得不认为 RST 是一种相当严格的机制，不会回复单个请求。此请求可能是呈现客户端页面之一所需的一百个资源之一，如果您断开连接，则无法重新使用该连接来请求更多资源。 （请参阅 HTTP1.1 RFC 中的 19.7.1：“持久连接是默认为
HTTP/1.1 消息；我们引入了一个新的关键字（
Connection: close）声明非持久性。”）
每个新连接都需要一个新的三路设置握手，这可能会使客户端用于从服务器检索资源的两个连接之一增加半秒每个失败的请求 您的服务器之间的平均延迟是多少。和你的 请将其乘以三以获得新的三向握手的时间。
如果您在 HTTP 协议级别失败了请求（
301？302？404？410？）您可以在现有 HTTP 连接中返回失败，并保存三个往返以生成新连接（这也可能适用于您的资源）我不再对服务感兴趣）。另外，
410应该表明浏览器不应该再次请求资源（但我不知道哪些浏览器会遵循这个建议。）RST-ed资源每次请求时可能都会重试。I have to think that
RSTis a fairly harsh mechanism to not reply to a single request. This request might be one of a hundred resources required to render one of your client pages, and if you tear down the connection, that connection cannot be re-used to request further resources. (See 19.7.1 in the HTTP1.1 RFC: "Persistent connections are the default forHTTP/1.1 messages; we introduce a new keyword (
Connection: close) fordeclaring non-persistence.")
Each new connection will require a new three-way handshake to set up, which might add half a second per failed request to one of the two connections the client is using to retrieve resources from your servers. What is the average latency between your servers and your customers? Multiply that by three to get the time for a new three-way handshake.
If you fail the requests at the HTTP protocol level instead (
301?302?404?410?) you can return a failure in the existing HTTP connection and save three-round-trips to generate a new connection (which might also be for a resource that you're no longer interested in serving).Plus,
410ought to indicate that the browser shouldn't bother requesting the resource again (but I have no idea which browsers will follow this advice.) AnRST-ed resource will probably be re-tried every single time it is requested.