This depends on if you want one-way or two-way replication. Also, collisions in file editing will make you want to gouge your face off with a rake (anything to get your mind off the pain of colliding file versions), so try to avoid any solution that doesn't handle versioning mismatches.
For Windows, you may want to look into what is likely to be your best two-way option (and in fact, your best option no matter what the replicaiton path is): DFS. You can use it in standalone mode (i.e. without Active Directory involved) or in a domain environment (do this if at all possible). DFS is rather advanced in keeping one namespace consistent across multiple servers. DFS replication replicates individual files, and since Server 2003 R2, file replication can replicate mere portions of files that have changed, thus saving more bandwidth.
A slightly (read: massively) ghetto way of performing replication across multiple servers would be to use a scheduled robocopy script to copy files from one master server down to the others. Robocopy has some limited form of bandwidth throttling using the
/ipg:n option, however don't expect fantastic results from it. You could cascade the replication in a stream topology; replicating from your head server down to a few important sub-servers, and then from the subs to further subs and down the line. That gets messy if you want to keep files consistent. Any use of robocopy in your situation will pretty much ensure that you have premature baldness and an ulcerated intestinal tract as you fight with bandwidth, hacked-up two way replication attempts, and/or lost data as files from downstream are overwritten from files upstream.