India is home to 400 million Internet users, second only to China, and will add more new users this year than any other country in the world. CloudFlare protects and accelerates 4 million websites, mobile apps and APIs, and is trusted by over 10,000 new customers each day. Combine these forces, and we are positioned to connect hundreds of millions of Indian users with the millions of internet applications they use each day.
Today, we accelerate this momentum with the announcement of three new points of presence (PoPs) in Mumbai, Chennai and New Delhi. These new sites represent the 66th, 67th and 68th data centers respectively across our global network.
The beginnings of the “internet” in India as we know it started in 1986 when the country launched ERNET (the Education and Research Network). Six years later, a 64 Kbps digital leased line was commissioned from the National Centre for Software Technology in Mumbai to UUNet in Virginia to connect India with the rest of the internet. By comparison, a single port on our router in each of Mumbai, Chennai and New Delhi has nearly 160,000 times the capacity today.
The pace of progress has Continue reading
The post Worth Reading: Connecting the next billion users appeared first on 'net work.
A customer reported an unusual problem with our CloudFlare CDN: our servers were responding to some HTTP requests slowly. Extremely slowly. 30 seconds slowly. This happened very rarely and wasn't easily reproducible. To make things worse all our usual monitoring hadn't caught the problem. At the application layer everything was fine: our NGINX servers were not reporting any long running requests.
Time to send in The Wolf.
He solves problems.
First, we attempted to reproduce what the customer reported—long HTTP responses. Here is a chart of of test HTTP requests time measured against our CDN:
We ran thousands of HTTP queries against one server over a couple of hours. Almost all the requests finished in milliseconds, but, as you can clearly, see 5 requests out of thousands took as long as 1000ms to finish. When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet loss since the SYN packets are usually retransmitted at times 1s, 3s, 7s, 15, 31s.
At first we thought the spikes in HTTP load times might indicate some sort of network problem. To be sure we ran ICMP pings against two IPs over many Continue reading
IT professionals need to expand their horizons to IoT and the cloud.
One of the engineers listening to my DMVPN webinars sent me a follow-up question (yes, I always try to reply to them) asking how to implement direct Internet access from the spoke sites (aka local exit) in combination with split default routing you have to use in DMVPN Phase 2 or Phase 3 networks.
It’s really simple: either you have a design requirement that requires split default routing, or you don’t.
Read more ...