Generally this is a network-side problem (target server or proxy server).

You can capture a NetLog and attach it to the bug:
https://dev.chromium.org/for-testers/providing-network-details

I emailed the Canary network dump to you, and also the credentials for the monitoring page.

Thank you for providing more feedback. Adding requester "eroman@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

eroman@ feel free to forward the information to me. I'm on duty now.

The net log shows that every error occurs after the first bytes get sent (by us) on a reused socket.

Possibly, this could be a server that is killing unused sockets aggressively?
Removing @eroman from owner.

Thanks so much for investigating!

I forwarded your findings (and this page) to the hosting company.

Adding TE-NeedsFurtherTriage label as there is very little or nothing can be done from TE end.

Please report back if there is any news. It also might be worthwhile to see if this reproduces in any other browser besides Chrome.

Running the same monitoring page in Firefox right now. Will post the result.

Yesterday I ran PingPlotter, it showed several failures (100% packet loss) caused by the server side (tobireif.com).

Mailed the screenshots to the hosting company, haven't yet gotten an update form them.

Thank you for providing more feedback. Adding requester "csharrison@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sorry sheriffbot, wrong again.

Today I ran the monitoring page in Chrome and Firefox (for several hours), but couldn't reproduce the error often enough. (On some recent days I got ~10 "net::ERR_CONNECTION_RESET" errors in ~5 hours.) Will try again soon.

Thank you for providing more feedback. Adding requester "csharrison@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I ran the monitoring page (JS) simultaneously in Firefox and in Chrome for a few hours per AM/PM. The results:

Saturday July 2:
  In Chrome there was 1 "net::ERR_CONNECTION_RESET".
Sunday July 3:
  In Chrome there were 2 "net::ERR_CONNECTION_RESET".
Monday July 4:
  In Chrome there was 1 "net::ERR_CONNECTION_RESET".
  Later:
  In Firefox there was 1 "NetworkError when attempting to fetch resource".
  Later:
  In Chrome there was 1 "net::ERR_CONNECTION_RESET".
  Later:
  In Chrome there was 1 "net::ERR_CONNECTION_RESET".
  Later:
  In Firefox there was 1 "NetworkError when attempting to fetch resource".
  Later:
  In Chrome there was 1 "net::ERR_CONNECTION_RESET".

It seems that the cause for the errors is on the server side and should get fixed.

Perhaps the trigger is in Chrome and Firefox, eg the socket reuse you mentioned, and the server should get fixed to handle that reuse well.

There were many more errors in Chrome than in Firefox. It seems clear that (although the cause for the errors seems to be on the server side and needs to get fixed) there's something to be improved in Chrome as well.

On Monday there were many more errors than on the weekend, so perhaps the server-side issue is related to load.

Related to this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1284230 .

(One thing that's strange: I've never gotten an error at the same time in both browsers. But that might be irrelevant because the monitoring page most likely didn't run in sync in the two browser windows.)

This definitely looks like a server issue if Firefox is giving the same errors, though I'm not sure why the frequency would be different.

Removing myself from owners because I'm no longer on network triage rotation. There might be something Chrome can do better here, but I'm skeptical the change would be worthwhile if it will only alleviate a small class of buggy servers.

Given that there is consensus that this is a server side issue, I'm going to close this out. Please re-open if there is evidence that Chrome is doing something wrong here.

If I recall correctly, Chrome has never respected server-indicated timeout hints on sockets -- it caches sockets indiscriminately for 5 minutes, whereas I believe Firefox tries to respect these timeouts.

In this case the server is responding with:
    Keep-Alive: timeout=15

Suggesting the socket should only be kept idle for 15 seconds.

Depending on how and when the server closes its endpoint, this difference could account for more errors in Chrome vs Firefox, and historically has been the source of some differences.