3 ms·

...except people also browse HN from behind corporate gateway's/firewall's.

ck2 14y ago
It won't ban them, it just throttles simultaneous connections from the same IP. Unless there are dozens of people from the exact same IP and not an IP pool, it won't be a problem. The worst case is they will see a longer delay for an initial page load in their browser by half a second. But it helps the server tremendously, especially since HN seems to use Apache.
- cbhl 14y ago
  In this age of NAT and IPv4 address exhaustion, it's not uncommon to have dozens of people from the exact same IP.
  - ck2 14y ago
    ...and if they are all hitting HN at the exact same millisecond, then their connection should be delayed HN serves with connection-close, not keep-alive, so as soon as one request is done, the connection is freed for the next visitor on the same IP. This would just force them to be in single file on a very quickly moving line instead of requiring dozens of connections to be served all at the same time. Think of grocery store with one super-fast express lane vs no express lane and a dozen very slow cashiers and people with full carts ahead of you. Don't knock connlimit until you try it. Again, it's not a ban, just backlogs the requests.
    - cbhl 14y ago
      That sounds better, but it feels like a band-aid solution to me. For example, I worry about whether it will actually fix the load problems if a bad network has lots of requests, resulting in a very long queue and lots of open connections. It sounds like it's worth trying, at least.
  - saurik 14y ago
    As it currently stands, they would simply be unable to use HN if they were loading it at the same time, as the server would just ban them; do you feel that is really a better solution to the proposed delay?
    - cbhl 14y ago
      I think that the proposed solution gives preferential treatment to users who were around long enough (or have enough money) to be on a network where they are assigned their very own personal IPv4 address. If IP addresses mapped 1:1 to users or machines, then I'd be all for using xt_connlimit to throttle users who perform excess requests. Even if you add a proposed delay, a user behind one of these NATted networks could (unintentionally, I hope) cause a DoS by sending lots of requests to make the queue unreasonably long, which, to someone behind the NAT, is just as bad as a server ban.

ck2 14y ago

It won't ban them, it just throttles simultaneous connections from the same IP. Unless there are dozens of people from the exact same IP and not an IP pool, it won't be a problem. The worst case is they will see a longer delay for an initial page load in their browser by half a second. But it helps the server tremendously, especially since HN seems to use Apache.

cbhl 14y ago
In this age of NAT and IPv4 address exhaustion, it's not uncommon to have dozens of people from the exact same IP.
- ck2 14y ago
  ...and if they are all hitting HN at the exact same millisecond, then their connection should be delayed HN serves with connection-close, not keep-alive, so as soon as one request is done, the connection is freed for the next visitor on the same IP. This would just force them to be in single file on a very quickly moving line instead of requiring dozens of connections to be served all at the same time. Think of grocery store with one super-fast express lane vs no express lane and a dozen very slow cashiers and people with full carts ahead of you. Don't knock connlimit until you try it. Again, it's not a ban, just backlogs the requests.
  - cbhl 14y ago
    That sounds better, but it feels like a band-aid solution to me. For example, I worry about whether it will actually fix the load problems if a bad network has lots of requests, resulting in a very long queue and lots of open connections. It sounds like it's worth trying, at least.
- saurik 14y ago
  As it currently stands, they would simply be unable to use HN if they were loading it at the same time, as the server would just ban them; do you feel that is really a better solution to the proposed delay?
  - cbhl 14y ago
    I think that the proposed solution gives preferential treatment to users who were around long enough (or have enough money) to be on a network where they are assigned their very own personal IPv4 address. If IP addresses mapped 1:1 to users or machines, then I'd be all for using xt_connlimit to throttle users who perform excess requests. Even if you add a proposed delay, a user behind one of these NATted networks could (unintentionally, I hope) cause a DoS by sending lots of requests to make the queue unreasonably long, which, to someone behind the NAT, is just as bad as a server ban.