Re: AW: AW: [5.0] Connector default configuration + connection timeout
Section 14.45 of HTTP 1.1 states: The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses.. This means that if a proxy is involved there will be a Via header. Moreover there is the X-Forwarded-For header (NOT part of the standard) used for example by squid proxy, which indicates the original host issuing the request. Of course nothing prohibits a DoS host to insert these headers to fake a proxy!! Stefanos Fischer, Ilona wrote: IMHO it's the definition of a proxy to send/recive requests instead of client... that means only the proxy was talking with the webserver - in the HTTP-header was only the IP of the Proxy Regards :o) Ilona -Ursprüngliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED] Gesendet: Montag, 28. Juli 2003 18:01 An: Tomcat Developers List Betreff: Re: AW: [5.0] Connector default configuration + connection timeout Fischer, Ilona a écrit : Protection against DOS attack should also have some glues like : - Max clients from the same IP (ie DOS attack from the same host). How would you distinguish between users coming from big proxy and a DOS-attack? Our access.logs shows that approx. 30% acesses comes from t-online (a big ISP in germany) and AOL That's right (T-ONLINE and AOL) are big hackers ;) More seriously, in such case there must be the original IP somewhere in the HTTP header isn't it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- == Stefanos Karasavvidis Electronic Computer Engineer e-mail : [EMAIL PROTECTED] Multimedia Systems Center S.A. Kissamou 178 73100 Chania - Crete - Hellas http://www.msc.gr Tel : +30 2821 0 88447 Fax : +30 2821 0 88427 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: [5.0] Connector default configuration + connection timeout
Fischer, Ilona a écrit : IMHO it's the definition of a proxy to send/recive requests instead of client... that means only the proxy was talking with the webserver - in the HTTP-header was only the IP of the Proxy And what about the Via: header ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
Bill Barker wrote:
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 28, 2003 8:16 AM
Subject: [5.0] Connector default configuration + connection timeout
Hi,
What would be the best connector default configuration ?
I switched HTTP/1.1 to be:
maxThreads: 100
minSpare: 1
maxSpare: 10
That should be ok for a small/medium site, and bad for a large site. It
should be decent for benchmarking if there's a warmup period. Should the
default config be large site compliant ?
Jk-Coyote should probably match the Apache2 defaults, since with the
pre-fork MPM, connections are 1-1 with Apache2 children.
Also, in order to conserve processors for useful tasks when the load
increases (and also twart DoS attacks), I was thinking about introducing
dynamic scaling for the HTTP connection timeout for keepalive.
The formula would be something like this.
ratio = maxThreads / currentBusyThreads;
if (ratio between 0 and 0.33) {
normal timeout
} else if (ratio between 0.33 and 0.66) {
half timeout
} else if (ratio between 0.66 and 1) {
no keepalive (so only one request is processed per connection),
timeout / 4 (or maybe more)
}
No keepalive sounds like a bad idea: You are going to free-up connections
much faster if you get the image files out the pipe then if the browser is
immediately turning around and re-establishing a connection. It might also
be a good idea if there was an option to disable this, for the few cases
where you care more about the the connected user's experience then the
new-connection speed (Applet classloading comes to mind).
I found the opposite to be true, turning keepalive off is a better solution
for the server. There was a very good explanation why this is so at the
last ApacheCon in an Apache httpd performance tuning session.
Regards,
Glenn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
Glenn Nielsen wrote: Bill Barker wrote: No keepalive sounds like a bad idea: You are going to free-up connections much faster if you get the image files out the pipe then if the browser is immediately turning around and re-establishing a connection. It might also be a good idea if there was an option to disable this, for the few cases where you care more about the the connected user's experience then the new-connection speed (Applet classloading comes to mind). I found the opposite to be true, turning keepalive off is a better solution for the server. There was a very good explanation why this is so at the last ApacheCon in an Apache httpd performance tuning session. Ok, but keepalive in general helps server performance IMO (through reduced bandwidth usage). When the number of available processors gets low, then it could be worth it to disable it (that's what I was proposing at least). Of course, I don't think it is the buisness of the TC HTTP/1.1 conector to implement stuff aimed at avoiding serious DoS attacks, so the idea right now is just to avoid minor problems and to handle traffic surges better. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] Connector default configuration + connection timeout
Hi,
What would be the best connector default configuration ?
I switched HTTP/1.1 to be:
maxThreads: 100
minSpare: 1
maxSpare: 10
That should be ok for a small/medium site, and bad for a large site. It
should be decent for benchmarking if there's a warmup period. Should the
default config be large site compliant ?
Also, in order to conserve processors for useful tasks when the load
increases (and also twart DoS attacks), I was thinking about introducing
dynamic scaling for the HTTP connection timeout for keepalive.
The formula would be something like this.
ratio = maxThreads / currentBusyThreads;
if (ratio between 0 and 0.33) {
normal timeout
} else if (ratio between 0.33 and 0.66) {
half timeout
} else if (ratio between 0.66 and 1) {
no keepalive (so only one request is processed per connection),
timeout / 4 (or maybe more)
}
Comments ?
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
Remy Maucherat a écrit :
Hi,
What would be the best connector default configuration ?
I switched HTTP/1.1 to be:
maxThreads: 100
minSpare: 1
maxSpare: 10
That should be ok for a small/medium site, and bad for a large site. It
should be decent for benchmarking if there's a warmup period. Should the
default config be large site compliant ?
May be you should mimic the defaults settings of Apache 2.0 :
150 Threads, 25 MinSpare, 75 MaxSpare.
Also, in order to conserve processors for useful tasks when the load
increases (and also twart DoS attacks), I was thinking about introducing
dynamic scaling for the HTTP connection timeout for keepalive.
The formula would be something like this.
ratio = maxThreads / currentBusyThreads;
if (ratio between 0 and 0.33) {
normal timeout
} else if (ratio between 0.33 and 0.66) {
half timeout
} else if (ratio between 0.66 and 1) {
no keepalive (so only one request is processed per connection),
timeout / 4 (or maybe more)
}
Comments ?
Protection against DOS attack should also have some glues like :
- Max clients from the same IP (ie DOS attack from the same host).
- Max request by minutes or seconds (slow down attackers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: [5.0] Connector default configuration + connection timeout
Protection against DOS attack should also have some glues like : - Max clients from the same IP (ie DOS attack from the same host). How would you distinguish between users coming from big proxy and a DOS-attack? Our access.logs shows that approx. 30% acesses comes from t-online (a big ISP in germany) and AOL Greetings :o) Ilona - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
Henri Gomez wrote:
Remy Maucherat a écrit :
Hi,
What would be the best connector default configuration ?
I switched HTTP/1.1 to be:
maxThreads: 100
minSpare: 1
maxSpare: 10
That should be ok for a small/medium site, and bad for a large site.
It should be decent for benchmarking if there's a warmup period.
Should the default config be large site compliant ?
May be you should mimic the defaults settings of Apache 2.0 :
150 Threads, 25 MinSpare, 75 MaxSpare.
Ok, thanks.
I forgot to mention JK 2 in my email ;-) What should be the default
configuration for that connector (including jk2.properties if any) ?
Also, in order to conserve processors for useful tasks when the load
increases (and also twart DoS attacks), I was thinking about
introducing dynamic scaling for the HTTP connection timeout for
keepalive.
The formula would be something like this.
ratio = maxThreads / currentBusyThreads;
if (ratio between 0 and 0.33) {
normal timeout
} else if (ratio between 0.33 and 0.66) {
half timeout
} else if (ratio between 0.66 and 1) {
no keepalive (so only one request is processed per connection),
timeout / 4 (or maybe more)
}
Comments ?
Protection against DOS attack should also have some glues like :
- Max clients from the same IP (ie DOS attack from the same host).
- Max request by minutes or seconds (slow down attackers)
I don't think those work too well except in very specific cases, as
pointed out by Ilona.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [5.0] Connector default configuration + connection timeout
Fischer, Ilona a écrit : Protection against DOS attack should also have some glues like : - Max clients from the same IP (ie DOS attack from the same host). How would you distinguish between users coming from big proxy and a DOS-attack? Our access.logs shows that approx. 30% acesses comes from t-online (a big ISP in germany) and AOL That's right (T-ONLINE and AOL) are big hackers ;) More seriously, in such case there must be the original IP somewhere in the HTTP header isn't it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
On Mon, 28 Jul 2003, Henri Gomez wrote: May be you should mimic the defaults settings of Apache 2.0 : 150 Threads, 25 MinSpare, 75 MaxSpare. Shouldn't one assume that a servlet container's application is different from that of a webserver ? I.e. less static files, more computation ? I always feel tempted to pull the threads down to something like 20. After all, all I have is 2 CPUs. Weblogic ships with 35 threads. Matthias -- Matthias Ernst Software Engineer CoreMedia - Smart Content Technology - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
[EMAIL PROTECTED] a écrit : On Mon, 28 Jul 2003, Henri Gomez wrote: May be you should mimic the defaults settings of Apache 2.0 : 150 Threads, 25 MinSpare, 75 MaxSpare. Shouldn't one assume that a servlet container's application is different from that of a webserver ? I.e. less static files, more computation ? I always feel tempted to pull the threads down to something like 20. After all, all I have is 2 CPUs. Weblogic ships with 35 threads. I think Remy want a configuration settings where TC 5.0 is acting as a real web-server (for example to serve a major OSS web-site ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: [5.0] Connector default configuration + connection timeout
IMHO it's the definition of a proxy to send/recive requests instead of client... that means only the proxy was talking with the webserver - in the HTTP-header was only the IP of the Proxy Regards :o) Ilona -Ursprüngliche Nachricht- Von: Henri Gomez [mailto:[EMAIL PROTECTED] Gesendet: Montag, 28. Juli 2003 18:01 An: Tomcat Developers List Betreff: Re: AW: [5.0] Connector default configuration + connection timeout Fischer, Ilona a écrit : Protection against DOS attack should also have some glues like : - Max clients from the same IP (ie DOS attack from the same host). How would you distinguish between users coming from big proxy and a DOS-attack? Our access.logs shows that approx. 30% acesses comes from t-online (a big ISP in germany) and AOL That's right (T-ONLINE and AOL) are big hackers ;) More seriously, in such case there must be the original IP somewhere in the HTTP header isn't it ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
Henri Gomez wrote: [EMAIL PROTECTED] a écrit : On Mon, 28 Jul 2003, Henri Gomez wrote: May be you should mimic the defaults settings of Apache 2.0 : 150 Threads, 25 MinSpare, 75 MaxSpare. Shouldn't one assume that a servlet container's application is different from that of a webserver ? I.e. less static files, more computation ? I always feel tempted to pull the threads down to something like 20. After all, all I have is 2 CPUs. Weblogic ships with 35 threads. I think Remy want a configuration settings where TC 5.0 is acting as a real web-server (for example to serve a major OSS web-site ;) Not quite :) For that kind of use, I think more processors are needed. We only need a balanced and decent default configuration (and I'll implement my timeout and keepalive tweaks, since I think this is important for a threaded web server like Tomcat). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Connector default configuration + connection timeout
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 28, 2003 8:16 AM
Subject: [5.0] Connector default configuration + connection timeout
Hi,
What would be the best connector default configuration ?
I switched HTTP/1.1 to be:
maxThreads: 100
minSpare: 1
maxSpare: 10
That should be ok for a small/medium site, and bad for a large site. It
should be decent for benchmarking if there's a warmup period. Should the
default config be large site compliant ?
Jk-Coyote should probably match the Apache2 defaults, since with the
pre-fork MPM, connections are 1-1 with Apache2 children.
Also, in order to conserve processors for useful tasks when the load
increases (and also twart DoS attacks), I was thinking about introducing
dynamic scaling for the HTTP connection timeout for keepalive.
The formula would be something like this.
ratio = maxThreads / currentBusyThreads;
if (ratio between 0 and 0.33) {
normal timeout
} else if (ratio between 0.33 and 0.66) {
half timeout
} else if (ratio between 0.66 and 1) {
no keepalive (so only one request is processed per connection),
timeout / 4 (or maybe more)
}
No keepalive sounds like a bad idea: You are going to free-up connections
much faster if you get the image files out the pipe then if the browser is
immediately turning around and re-establishing a connection. It might also
be a good idea if there was an option to disable this, for the few cases
where you care more about the the connected user's experience then the
new-connection speed (Applet classloading comes to mind).
Comments ?
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
