Re: web problem [solved]
- Date: Sun, 17 Feb 2019 13:34:47 -0700
- From: ghe <ghe@xxxxxxxxxxx>
- Subject: Re: web problem [solved]
On 2/17/19 12:45 PM, Alexander V. Makartsev wrote:
> By default "traceroute" command uses 0ms delay between requests. For the
> majority of ISPs this behavior is considered as flood and will be
> rate-limited (dropped).
> You have to use "sendwait" parameter set to at least 1 (second), to
> gather reliable information with "traceroute" command.
Didn't know that. Traceroute does seem somewhat more civilized with a
'-z 1' option. Useful knowledge. Thanks...
> For the situation you described the most possible cause is a packet loss
> on top of a "generous" T1 connection.
According to the ISP, the problem was a mildly misconfigured router
somewhere in Denver, CO. Seems to be all better now.
> The tcp/ip protocol is stateful by nature (it cares about packets
> consistency and reliability of send-receive operations), so if some
> packets got lost or become corrupted during send-receive exchange they
> have to be send again.
Yeah, I know. But it wasn't a matter of resending on error, it was that
the SSL handshake was taking longer than their web server considered
reasonable, so it quit waiting.
The Internet isn't as patient now as it was back in the dialup days.
Good thing, too, or I'd never have seen that there was a problem.
Thanks, list, for the replies to a confused admin :-)