Hello, I may have missed something, but it was to my understanding that nginx continuously send data to clients, thus fill up buffers whil the client empties it at the same time (FIFO). Thus, to me, backend upload was stopping when the allocated buffer(s) was(were) full, waiting for space being available in it(them).
That is how/why, to my understanding (again), nginx was supposed to be able to handle slow clients. The intuitive solution if it was to happen to me, would have been to reduce buffer(s) size + number to ensure they fill up quickier (and thus stop downloading from upstream with the same velocity). In the end, the computation of the 'lost' resource is done: - in space with number of 'attackers' * num buffers * size buffer - in time with space calculated above / upstream sownloading speed (an average would be enough) Is not your patch redundant with existing capabilities? You just added another caluclation, competing with the one above, multiplying the above values per 10%. You could as much have reduced the settings above to meet the same result, could not you? Not talking about the risk of introducing vulnerabilities/instabilities with custom patch. What if the attacker modifies its client to ensure downloading 50% of the file (thanks to his /dev/null)? Your patch becomes useless and the resources grow back to what they used to be... on the other hand, the standard way of having modified how you handle upstream data would have been resisting, whatever amount of data any client grabs. What have I missed here? --- *B. R.*
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
