I saw someone say that the new Twitter update was causing it to essentially DDoS itself. Is this true? I have a very basic understanding of what DDoS is but I don’t understand how the two are connected. Thanks in advance.
In: 64
It’s not a great analogy, but the idea is now you can only access tweets while logged in, previously you could not have an account at all and still see things.
But a lot of people don’t know that or still don’t have accounts, when you accessed the Twitter homepage not logged it would attempt to access tweets and fail…over and over and over. So it just keeps sending requests, effectively DDoSing it
When they changed it so that only logged-in users can access tweets they also accidentally caused it to DDOS themselves, because they didn’t handle this case correctly.
Someone would want to look at a tweet, but as they weren’t logged in they got an error message. The website would then again try it, only to get another error message. So every non-logged in user would make hundreds of requests over and over again.
Twitter: “You are past your limit, I won’t serve you any more tweets”.
App in confusion:”I don’t understand, give me more tweets!”.
Repeat this thousand times per second. For hundreds of thousands of users. Servers are busy replying to them, so they can’t serve “normal” customers
Normal operation:
User: give me a tweet.
Server: here you go.
User: lets see, interesting….
[Server free to serve others while user is reading]
User: okay, give me another.
Server: here you go.
Broken:
User: give me a tweet.
Server: no.
User: give me a tweet.
Server: no.
User: give me a tweet.
Server: no.
[Server tied up serving one user.]
[The change was due to Elon choosing to not pay their google cloud services bill.](https://www.independent.co.uk/tech/elon-musk-twitter-google-cloud-b2355804.html) Limiting the number of tweets a user can see per day was data rationing. Elon more or less tried to hide this fact behind a profit argument.
All the explanations about people accessing twitter and failing to load tweets DDoSing it are missing this fact. This is an infrastructure problem caused directly by Elon downgrading their cloud services for the platform.
Twitter has a front-end and a back-end. The front-end is what you see when you go to twitter.com, all the UI and text and so on. However, it has no tweets or data by itself, it just knows how to display them nicely and how to ask the back-end for the tweets.
The back-end has all the tweets in a database, and has certain specific ways to ask it for information. It’s expecting the front-end to send a nicely formatted request asking for so-and-so tweets for so-and-so users, which it then returns. Once the front-end gets the returned request with the tweets, it displays them.
Normally, the front-end asks for a tweet, and then the back-end gives it a tweet. However, with the new changes, the front-end asks for tweets, and the back-end says no. The front-end doesn’t know how to handle this, so it just asks again. And again.
Each time the back-end says no, but the front-end is now calling a dozen times a second per user instead of once every few seconds. This swamps the back-end with meaningless requests, and now it can’t handle requests fast enough. They pile up, and now users who should have access can’t get their requests answered over all the noise.
The defacto solution to this is something called exponential backoff. Whenever the back-end returns a failing request, it returns a code that says what the failure was. The front-end reads that code, knows it failed, and waits for a little bit before trying again.
Each time it fails, it multiplies the time it waits by two. So it’ll try again after a second, then two, then four, and so on. That way, the server is never flooded with requests. Usually, after a few failures, it’ll give up and ask the user to refresh the page. Reloading the page might help solve the error, but if it doesn’t, no harm.
Twitters failure is that they didn’t envision a scenario where the server would be throwing an error when the front-end asked for tweets in a specific way. The front page is coded to ask for tweets when it runs out of tweets. But when it makes the request, it gets no tweets. It’s out of tweets. It make a request to get more tweets. It gets no tweets. On and on.
Their more fundamental failure is how this wasn’t caught in testing. Usually, you push changes to a testing environment that mirrors production. If someone has done this and fiddled around a bit, this issue would have come up and been fixed. The fact it wasn’t is really telling of the state of twitter.
[Here’s an explanation](https://sfba.social/@sysop408/110639435788921057)
TL;DR: Modern sites like Twitter have two parts: Frontend and Backend.
When you go to twitter.com, your browser loads and runs code which queries the twitter.com backend service. If your browser loaded this code successfully it can keep on running no matter what happens afterwards — your computer downloaded it, your computer is all that is needed for it to work and try and do something. For instance this code periodically checks whether anything new happened.
Apparently this code was retrying too aggressively, so when the backend broke, the frontend kept trying. So any person with a browser pointed at twitter.com is constantly firing off a mass of requests at Twitter’s servers. Apparently at the rate of 10 requests per second.
This technically works as a DDoS — it’s distributed, in that it’s something being done by lots of computers world-wide. And it causes a further denial of service because it floods Twitter’s servers with a huge volume of requests.
I think by now this problem is likely already gone. This is two days old news, so I’m sure by now they already patched it up.
Just a little more on why this would happen, clearly this new tweet view limiting feature was added in a rush so the app / website wasn’t updated to know about it, so when the server tells the app the user has run out of views the app doesn’t know how to handle this error so gets stuck in a loop still trying to read the tweets that the server refuses to give them.
Either the limit was implemented hastily by higher ups or someone just messed up because the experienced developers were fired.
DDoS attacks are anything that can cause the service to not respond… In the malicious case, a lot of computers are made to try to access a service increasing the load to when the server can’t handle any more requests. Either keeping the server busy or make it shutdown.
Technically the limit doesn’t caused overall service outage, but for individual users.
The limit what they put in place didn’t considered that twitter itself is gonna call home automatically.
When you load the twitter page, you get a website that runs in your browser. That is a separate program from twitter servers. That program can communicate with the home server and ask for data, tweets pictures etc. That program can make a lot of requests in the background, like loading tweets in the background while you scroll so don’t have to wait for each tweet to load.
This a common practice to load a bunch of small data instead of one big chunk.
These background requests were counted as normal tweet requests by the limit monitor system. Essentially the twitter program itself made too much requests and locked itself out, because it hit the limit.
Poor execution that normal website calls and background API calls were not diffrerentiated.
Twitter’s like a buffet saying ‘no more food!’ while people keep asking for seconds. Recipe for chaos!
Latest Answers