Fabio's answer is right. I wrote a multiplayer Command & Conquer: Red Alert 2 clone back in college, in Java using NIO for multiplayer. I came up with or read somewhere about the concept of "frames", which is basically the same as what Fabio refers to as "ticks." Frames or ticks should be controlled on the server in a timer. I think I spaced them 100ms apart, but I don't remember. The server should keep in memory (like a javascript object or array) the positions of all mutable/changeable objects (characters, tanks, buildings etc), on a given map. For development purposes or an alpha version (just to get a feel for how it works), the server should serialize the javascript object into JSON representing the assets on the map and send it to the clients on every frame (every 100ms or so). Each client should only update its view of the map when it receives the JSON from the server (again, about every 100ms it will receive a new JSON object). When the client wants to move a character, fire a bullet, etc, it should send a JSON request to the server describing the attempted action, but no change should happen on the client's view directly (except maybe a red x showing where a character is going to move). The server will then receive the JSON action and compute the movement or interaction, interacting with the timer so that the event happens over time. The client will see the action (along with other clients) because the server will be sending out the frames every tick.
To improve this as far as bandwidth concerns, you could only send out changes/updates (updates to the javascript object tracking game state) to the clients every frame. I would still send the entire javascript object every 5 minutes or so in case there are bugs in your changes/updates code or dropped packets if you're using UDP.
There are more advanced ways to deal with latency than this, which you may need to explore as you improve your game out of alpha version, but this should get you started.