Re:Twitter Is DDOSing Itself
by dcunit3d on Sunday July 02, 2023 @10:29AM
(#36561808)
This web developer thinks Twitter is DDoSing itself ... but those are 429 status codes. In that case, I'm not sure this guy is capable of tying his own shoes in web development, although there's definitely a problem in the Javascript client.
It doesn't matter though because the left will simply go along with whatever seems to support their stance. I guess Elon is their new object of derision, replacing Trump.
For apps as large as Twitter, they use CDN's or PoP to scale, which means that request returning 429 isn't actually hitting the datacenter.
Of course, "one does not simply use a CDN..." so actually determining how this guy is wrong is another question entirely.
Twitter uses Anycast with VIP's proxy TLS sessions to its data center via VM's in Google Cloud. However, it's likely that the GCP VM's are getting the DDoS, depending on which of TLS terminations it hits. Based on the VIP used to reach the GCP VM, it determines how to proxy the traffic, implicitly determining the routes taken.
It's unlikely that the traffic makes it beyond this, though it depends on proxy configuration. Some pass through and others don't. The first article below indicates Twitter terminates at GCP and, overall, implies a secondary TLS connection to their data center.
The rate of requests in the article's video implies the TLS session doesn't time out. The GCP load balancer is simply handling the traffic and staving off DDoS. This is what you're paying for anyways.
It doesn't matter though because the left will simply go along with whatever seems to support their stance. I guess Elon is their new object of derision, replacing Trump.
For apps as large as Twitter, they use CDN's or PoP to scale, which means that request returning 429 isn't actually hitting the datacenter.
Of course, "one does not simply use a CDN..." so actually determining how this guy is wrong is another question entirely.
Twitter uses Anycast with VIP's proxy TLS sessions to its data center via VM's in Google Cloud. However, it's likely that the GCP VM's are getting the DDoS, depending on which of TLS terminations it hits. Based on the VIP used to reach the GCP VM, it determines how to proxy the traffic, implicitly determining the routes taken.
It's unlikely that the traffic makes it beyond this, though it depends on proxy configuration. Some pass through and others don't. The first article below indicates Twitter terminates at GCP and, overall, implies a secondary TLS connection to their data center.
The rate of requests in the article's video implies the TLS session doesn't time out. The GCP load balancer is simply handling the traffic and staving off DDoS. This is what you're paying for anyways.
Google SSL Load Balancing: https://cloud.google.com/load-balancing/docs/ssl
Cloud Flare TLS Session Resumption: https://blog.cloudflare.com/tls-session-resumption-full-spee...
See the following Twitter Engineering blogs for more info:
Sept 2019: Expanding the edge (Twitter PoP deployment)
https://blog.twitter.com/engineering/en_us/topics/infrastruc...
Aug 2020: Rebuilding Twitter's Public API
https://blog.twitter.com/engineering/en_us/topics/infrastruc...
Jan 2017: The Infrastructure Behind Twitter: Scale
https://blog.twitter.com/engineering/en_us/topics/infrastruc...
Sparrow is used for scaling microservices that need load balancing strategies.
Jun 2022: Twitter Sparrow Tackles Data Storage Challenges of Scale
https://blog.twitter.com/engineering/en_us/topics/infrastruc...