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 ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=241 time=212 ms
64 bytes from icmp_seq=2 ttl=241 time=243 ms
64 bytes from icmp_seq=3 ttl=241 time=216 ms
64 bytes from 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.)?


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>

Reply via email to