Re: SSL downloads faster than non SSL?
Nick Kew wrote: William A. Rowe, Jr. wrote: At 09:01 PM 8/3/2005, Bill Stoddard wrote: A monitor thread would periodically check for a transmitfile completion status; if the completion status is too slow in coming, the monitor thread cancels the io and closes the socket. We really need not wait ;-) Driving home from your neck of the woods in NC (well, a bit west in fact, near Fontana) it struck me that for all the individuals wishing for 'absolute' timeouts on unix platforms, it would be rather cool to cache the start time and run a parent thread against the scoreboard, killing all the lingering processes subject to byte-at-a-time DoS attacks in the headers. We would obviously need to be careful of lengthy req bodies which would take more time than the 'absolute' timeout, but your comment reminded me that perhaps, we can kill two birds with one stone :) We can kill processes/threads that have spent too long in any given scoreboard state: that's exactly what I needed to do when I proposed what is now ap_hook_monitor. But as for byte-at-a-time DOS attacks, I don't think (OTTOMH) it's a good solution. Of course your right, anything we do at the HTTP layer against DoS attacks is easy for a clever attacker to circumvent. Need to go into deeper into the TCP stack to mount an effective defense against DoS attacks. OTOH, blocking the simple stuff at the HTTP layer is often 'good enough' in practice.
Re: SSL downloads faster than non SSL?
On 3-Aug-05, at 8:11 AM, William A. Rowe, Jr. wrote: In the APR library, yes, we translate 'apr_sendfile' to TransmitFile() on win32. Some other magic occurs to obtain a file handle which can be passed to TransmitFile. But there are enough flaws in the TF() api that perhaps this would be better defaulted to 'off'. +1
Re: SSL downloads faster than non SSL?
Phillip Susi wrote: My understanding is that the current code will memory map the data file, optionally encrypt it with SSL, and then call a conventional send(). Using send() on a memory mapped file view instead of read() eliminates It does not change the file in place. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: SSL downloads faster than non SSL?
At 10:48 AM 8/3/2005, Phillip Susi wrote: William A. Rowe, Jr. wrote: In the APR library, yes, we translate 'apr_sendfile' to TransmitFile() on win32. Some other magic occurs to obtain a file handle which can be passed to TransmitFile. But there are enough flaws in the TF() api that perhaps this would be better defaulted to 'off'. Really? Are you quite sure? I wonder what's hosing it all up. Once you hand TransmitFile() the socket and file handles, it should blast the file over the network nice and fast. Yes of course :) However, sadly, Microsoft has a number of bugs in various versions of Windows NT kernels which have 1) messed up any transmissions from NFS files mounted from other network file stores, 2) corrupted the output from TransmitFile() on specific kernel builds, and 3) have some indeterminate behaviors when additional third party drivers are injected into the socket stack. The principal is wonderful, the practice has led to many bug reports and inquires over the users@ support channel. Bill
Re: SSL downloads faster than non SSL?
William A. Rowe, Jr. wrote: At 10:48 AM 8/3/2005, Phillip Susi wrote: William A. Rowe, Jr. wrote: In the APR library, yes, we translate 'apr_sendfile' to TransmitFile() on win32. Some other magic occurs to obtain a file handle which can be passed to TransmitFile. But there are enough flaws in the TF() api that perhaps this would be better defaulted to 'off'. Really? Are you quite sure? I wonder what's hosing it all up. Once you hand TransmitFile() the socket and file handles, it should blast the file over the network nice and fast. Yes of course :) However, sadly, Microsoft has a number of bugs Search the archives of this or the apr mailing list... other than bugs (which can be reported to MS with reasonable expectation that they will be fixed. maybe :-), the most serious flaw is that there is no way to timeout calls to TransmitFile. If I call TransmitFile to send a file and the client chooses to not read any of the bytes I send him, transmitfile will fill-up the send buffers in the TCP stack then block forever. I've never found a way to check the 'status' of the call to TransmitFile, to see if it was making 'acceptable' progress sending bytes to the client. To solve (by some definition of solve) this timeout problem, we made TransmitFile (under apr_sendfile) send no more than 64K bytes at a time. The call to transmitfile is non-blocking and the calling thread blocks on WaitForSingleObject for 'timeout' seconds. If the call completes before the WaitFor call times out, we send the next 64K byte chunk of the file. Repeat until all the file is sent. Whoever came up with the brilliant idea of making multiple calls to TransmitFile to send files over 64K bytes needs to be dragged behind a bus ;-) Now if Apache 2 supported asynchronous (or event driven) writes to the network (like IIS), we could just call apr_sendfile/TransmitFile once to send the whole shaboozie and not worry (too much) about whether the client is broken or is running a DoS attack. A monitor thread would periodically check for a transmitfile completion status; if the completion status is too slow in coming, the monitor thread cancels the io and closes the socket.
Re: SSL downloads faster than non SSL?
Phillip Susi wrote: I decided to do some informal benchmark comparisons between using windows SMBFS and apache/webdav for file transfers. I ended up finding that apache is actually faster at sending files over an SSL connection than a plain connection. I downloaded a ~600 meg test file from the server using windows explorer webfolders, IE, and firefox. Firefox downloads the file in the 4000-5000 KB/s range when using an SSL connection. IE gets over 10,000 KB/s downloading over the secure connection. Both only are able to download at 300-600 KB/s using the non SSL connection though. This is, of course, all done over a 100 Mbps ethernet network that is minimally loaded, and I repeated the test a few times, clearing the browsers caches each time. Did you restart Apache too, to clear the memory cache of the OS? Joost
