And you are here why?

________________________________________________________________ This is part of a series on Direct Server Return 1.  A Quick Primer 2.  SYN Floods 3.  The Real World ________________________________________________________________ DSR can be remarkably useful in asymmetric traffic environments, where the traffic  to  you is a lot less than the traffic  from  you (think Netflix, YouTube, and, well, pretty much any streaming service you can think of. Packet Rewrites In  a previous article , I used the above diagram to show how, with DSR, the response traffic went directly back to the Client. Mind you, there  is  a little bit of chicanery going on here — even though the traffic is originating from t the packet now looks like it is addressed to  Server B IP:Server B Port , the actual network packets show that they are originating from  Router IP:Router Port . Where did that happen? The answer is, well,  it depend...

________________________________________________________________ This is part of a series on Direct Server Return 1.  A Quick Primer 2.  SYN Floods 3.  The Real World ________________________________________________________________ SYN Flood Before we get into it, let’s take a quick look at the way  TCP connections get setup using a three-way handshake .  1. The Client initiates the request by sending a  SYN  ( synchronize ) message to the Server. 2. The server responds by sending  SYN-ACK  ( acknowledge ) back to the client. 3. The client, in turn, sends an  ACK , and we’re all setup. What an UnGood Client can do, however is the following 1. The UnGood person sends a bunch of  SYN  messages to the server,  each of which has a fake source address . 2. The server responds by sending  SYN-ACK  for each of these to the fake address. 3. Importantly, the server keeps waiting for the ACK ...

So you’ve got an app that you put up on a server. It’s something important, say, a place where people can get advice from each other on making their own wood-fired pizza ovens. A) Direct Access In a very simple scenario, once you set things up, people would access the app by going directly to your server as shown below If you looked at the actual packets, they would show the source as the client’s IP:Port and the destination as the   ServerIP:ServerPort B) Multiple Servers You’ve now got a whole bunch-a people using your app, and you need multiple servers to handle the load. You’re still keeping this simple, and you just tell people to go directly to one of your servers (and if it’s overloaded, pick a different one). If you looked at the actual packets, they would show the source as the client’s IP:Port and the destination as either   Server A IP:Server A Port or   Server B IP:Server B Port depending on which server the packet is going to. C) Router Now, y...