Hello Ryan, Thanks for that update.
currently I can ping twitter.com but I can't access http on it tpi...@vm:~/app$ ping twitter.com -c4 PING twitter.com (168.143.162.116) 56(84) bytes of data. 64 bytes from 168.143.162.116: icmp_seq=1 ttl=241 time=212 ms 64 bytes from 168.143.162.116: icmp_seq=2 ttl=241 time=243 ms 64 bytes from 168.143.162.116: icmp_seq=3 ttl=241 time=216 ms 64 bytes from 168.143.162.116: icmp_seq=4 ttl=241 time=214 ms --- twitter.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3017ms rtt min/avg/max/mdev = 212.389/221.455/243.174/12.611 ms tpi...@vm:~/app$ curl http://twitter.com curl: (7) couldn't connect to host This app/ip is whitelisted and we're using mbleigh's twitter-auth. Any thoughts on this one? Is it a problem on our end (i.e. our network, dns cache etc.)? Thanks, Tiago On Aug 7, 7:05 pm, Ryan Sarver <rsar...@twitter.com> wrote: > I wanted to send everyone an update to let you know what has been happening, > the known issues, some suggestions on how to resolve them and some idea of > how to move forward. > > *Whats been happening* > As you know all too well Twitter, among other services, has been getting hit > pretty hard with a DDoS attack over the past 24+ hours. Yesterday we saw the > attack come in a number of waves and from a number of different vectors > increasing in intensity along the way. We were able to stabilize our own > service for a bit, hence Biz's post saying all was > well<http://blog.twitter.com/2009/08/update-on-todays-dos-attacks.html>, > but that didn't mean the attacks had ceased. In fact, at around 3am PST > today the attacks intensified to almost 10x of what it was yesterday. In > order for us to defend from the attack we have had to put a number of > services in place and we know that some of you have gotten caught in the > crossfire. Please know we are as frustrated as you are and wish there was > more we could have communicated along the way. > > *Known Issues* > * - HTTP 300 response codes* - One of the measures in thwarting the > onslaught requires that all traffic respect HTTP 30x response codes. This > will help us identify the good traffic from the bad. > * - General throttling* - Try to throttle your services back as much as > possible for you to continue operating. We are working on our end to better > understand the logic used in throttling traffic on the edge of the network > and will communicate what we can, but the best idea is to just throttle back > as much as you can in the mean time. > * - Streaming API* - as part of the edge throttling we know requests to the > Streaming API with lists of keywords or uses are getting dropped because the > request is too large. We are working to get this filter removed and will > update the list when we know more. > - *Unexpected HTTP response codes* - we know people are seeing a lot of > other weirdness and we aren't exactly sure what to attribute the various > issues to, but know that you aren't alone. > > As the attacks change our tactics for defense will likely need to change as > well, so stay active on the list and let us know what problems you are > seeing and we will do our best to help guide you along. > > *Moving forward * > We will try to communicate as much as we can so you guys are up to speed as > things change and progress. I personally apologize for not communicating > more in the mean time but there hasn't been much guidance we have been able > to give other than hold tight with us. We fully appreciate all the long > hours you are putting in to keep your apps running and supporting your users > and know we are frustrated with you. Continue to watch this list, > status.twitter.com and @twitterapi for updates > > Thanks for your patience, Ryan > > PM, Platform Team > @rsarver <http://twitter.com/rsarver>
