Try some buffertstream. On these browser that have this "fault" can be very quick when it comes to HTTPS (https have a different packagestructure).
/Peter -----Ursprungligt meddelande----- Från: Robert Walther [mailto:[EMAIL PROTECTED] Skickat: den 13 december 2004 11:25 Till: [EMAIL PROTECTED] Ämne: FW: Tomcat JK2 Connector/IIS Slowdown For those of you who saw my original posting of this issue, you may remember that my IIS6/Tomcat 5.028 server was very slow at downloading files from an online cart to a Windows 2000, IE6 browser. But the same IIS6/Tomcat server would download files very quickly to all Netscape / Mozilla and Safari browsers. Also, I should mention, my Linux/Tomcat server did not have any speed issues with downloading files to any of the browsers, including IE6. Well, after collecting and analyzing many network packet captures, it turns out the slowness is due to the fact that Microsoft has interpreted an RFC regarding how to respond to TCP packets, differently than Netscape / Mozilla and Safari. This causes some IE6 browsers to respond very poorly to in some situations, So, ultimately it is a client-side / browser issue. They did give me a suggestion on how to fix it on the client side, but they did not know of anything that could be done to IIS or Tomcat to speed-up the file downloads. Here is their response. start quote CASE_ID_NUM: SRX041018608346 MESSAGE: ********************** The message for you follows ************************ Good Afternoon Rob, Thank you for using Microsoft Support and Microsoft Internet Products. I am confirming the closing of your case concerning the delay we were seeing when downloading a 1MB file to some clients. We confirmed this can be corrected by adding the TcpAckFrequency registry key described in article 328890 New registry entry for controlling the TCP Acknowledgment (ACK) behavior http://support.microsoft.com/?id=328890 <http://support.microsoft.com/?id=328890> . We set TcpAckFrequency to a value of 1, rebooted the XP client machine and when we tested again all worked fine. If you have Windows 2000 clients that experience the issue, the parameter is called TCPDelAckTicks and you can set the value to 0. For the 2000 platform, please refer to article 311833 The TcpDelAckTicks Registry Value Has No Effects on Ack Timeouts http://support.microsoft.com/?id=311833 <http://support.microsoft.com/?id=311833> . There is also a white paper you may want to review located at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolog ies/networking/tcpip03.mspx#XSLTsection129121120120 <http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolo gies/networking/tcpip03.mspx> . Lastly, the RFC which discusses the delayed ack can be located at http://www.faqs.org/rfcs/rfc1122.html <http://www.faqs.org/rfcs/rfc1122.html> specifically, you may want to review section 4.2.3.2. This section states the following which seems to be relevant to what we were experiencing: "A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment." Notice the keyword should which leaves some room for interpretation. Thanks again for calling Microsoft and have a great week! end quote I do not believe that Netscape and Mozilla respond with a delayed ACK when the stream of data is not padded to a full-sized segment. Also, I think that IIS6 does not pad packets but Apache does. Thus, because IIS6 + Tomcat together send out non-full-sized packets, the IE6 browser will delay the ACK until multiple partial packets are received. This delay causes the slowness. IF Apache + Tomcat packets ARE full sized there is no delayed ACK. It was distressing that Microsoft did not indicate a fix on the server side. I was hoping in light of this information, it could be fixed by padding packets coming out of Tomcat through the jk connector. Well, I will continue to research this and any feedback or additional insight would be appreciated, Also, I may be able to coordinate Microsoft to help us fix this issue if any one wishes to help me investigate the jk / Tomcat Source code. One thing I did not investigate, are other java methods for downloading files. It is possible that other java methods would be faster than the one we used for our online cart. FYI to all, Rob Walther Senior System Architect InterchangeDigital, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
