Back
We tried several solutions to deal with DDoS attacks before we arrived at one that worked. Initially, we attempted to filter the traffic with a powerful network switch. Unfortunately, this type of filtering is inherently difficult to do with game traffic. It is the nature of game servers to receive unsolicited UDP (User Datagram Protocol) traffic from arbitrary IP addresses. Imagine you had a post office that weeded out unwanted junk mail for you. But now imagine your job is as an advice columnist, and you receive tons of legitimate mail from random strangers all the time. For you, the post office doesn't know what's junk mail and what isn't. That's how traffic to game servers tends to look. Furthermore, the source IP in UDP packets is not secured, and can be easily spoofed. Our post office cannot even look at the return address on the envelope for clues, because the senders of junk mail forge that. Steam delivers a lot of bits for game content, and has built up a large network for doing so. We were already taking advantage of this network to deliver game traffic over dedicated links, obtaining good peering, ensuring that networking engineering best practices were used, etc. This kept player ping times low, but did not protect against DDoS attack. The problem is that UDP protocols are not secure, so while we had our own network, it wasn't private. To prevent attackers from using our own network to attack our servers, we needed to control all the entrances and secure them. We accomplished this by creating proxies for game traffic, routing every single packet of data transmitted across the network through relays. Now when a client wanted to talk to a game server, it had to do so through a relay that both authenticated it and proxied that traffic to the game server. This meant the IP address of the server was always hidden—the attacker simply had no idea where to attack. To re-use our antiquated post office metaphor from earlier, our spammer no longer had an address to send junk mail to. They could send it to every post office in the area and ask them to mail it, but without authorization, that post office isn’t going to. (Moreover, that post office would find it a little suspicious that someone was trying to send a single person 100,000 letters.) 
But couldn’t you just attack the relay? Technically, you could. But we have an essentially limitless number of them, and we built them to be attacked. A “relay” is just another word for a computer running software. You can attack it or take it offline, but the protocol was designed with that assumption in mind. If a client is trying to play a game and loses contact with a relay, it just switches to another. Relays are like hundreds of pawns scattered around the world with the singular purpose of guarding the game server. (Incidentally, taking out a relay is harder than it sounds. They’re engineered pretty well and positioned in a specific part of the network, so although they were built to be taken offline, we haven’t lost one yet.) The solution was straightforward but effective. Before, if someone wanted to disrupt a game, they could just overpower a single game server (a very low bar to clear). Now they had to overpower essentially the entire data center—a much, much, much higher bar. Are there attacks that could still accomplish this? Of course. Are there attacks that can do this that anyone online could buy for five dollars? No. An attack this sophisticated was officially out of the price range of most people. With this new system up and running, we had an epiphany: If we controlled our own private network, we wouldn’t be beholden to how the normal internet works. We could use it to make the customer experience even better. With the normal internet, when you send a packet from one IP address to another, the route you use is determined by Border Gateway Protocol (BGP). This is a routing algorithm that decides how your packet will travel across a network, and you have no choice in the route it picks. But with a virtual private network composed of hundreds of global relays and data centers, we could essentially choose our own route from the client to the game server—often a faster shortcut than the default route. If you’re using Steam Datagram Relay (SDR), the Steam overlay will show your ping time and what route we’re giving you, so you can see for yourself how it gets optimized. 
A feature that started as a way to protect Dota game servers has grown past what anyone could have expected. The SDR network routinely delivers as much as 140M packets and 550GBit per second. We have relays in 31 data centers with a capacity of over 5TBit. What we now call the Steam Datagram Relay not only protects against DDoS attacks, but also increases connectivity and lowers ping for every Dota customer. And it doesn’t just do this for Dota, but for any game on Steam that wants to take advantage of it. We hope you enjoyed another peek between the lanes of Dota. This was a pretty technical one, thanks for hanging in there for it! And feel free to let us know what you’d like us to cover next.