Regulating Big Tech. This Time, for sure!
There is a growing unease within the US and elsewhere over the extraordinary rise of these technology giants, not just in monetary terms but in terms of their social power as well. There is a growing sentiment that the current situation looks like it will never be adequately corrected by just competitive pressures within market itself. Some further forms of regulatory intervention will be needed to force a fundamental realignment of these players. In so doing, it appears that regulators appear to be finally catching up with the online world in the US, in Europe and in China.Government Aims for Equitable Network Connectivity for Education
The CARES Act and other government programs seek to provide equitable educational opportunities via improved network connectivity.Early Hints: How Cloudflare Can Improve Website Load Times by 30%
Want to know a secret about Internet performance? Browsers spend an inordinate amount of time twiddling their thumbs waiting to be told what to do. This waiting impacts page load performance. Today, we’re excited to announce support for Early Hints, which dramatically improves browser page load performance and reduces thumb-twiddling time.
In initial tests using Early Hints, we have observed more than 30% improvement to page load time for browsers visiting a website for the first time.
Early Hints is available in beta today — Cloudflare customers can request access to Early Hints in the dashboard’s Speed tab. It’s free for all customers because we think the web should be fast!
Early Hints in a nutshell
Browsers need instructions for what to render and what resources need to be fetched to complete “painting” a given web page. These instructions come from a server response. But the servers sending these responses often need time to compile these resources — this is known as “server think time.” While the servers are busy during this time… browsers sit idle and wait.
Early Hints takes advantage of “server think time” to asynchronously send instructions to the browser to begin loading resources while the Continue reading
The Zero Trust platform built for speed
Cloudflare for Teams secures your company’s users, devices, and data — without slowing you down. Your team should not need to sacrifice performance in order to be secure. Unlike other vendors in the market, Cloudflare’s products not only avoid back hauling traffic and adding latency — they make your team faster.
We’ve accomplished this by building Cloudflare for Teams on Cloudflare. All the products in the Zero Trust platform build on the improvements and features we’re highlighting as part of Speed Week:
- Cloudflare for Teams replaces legacy private networks with Cloudflare’s network, a faster way to connect users to applications.
- Cloudflare’s Zero Trust decisions are enforced in Cloudflare Workers, the performant serverless platform that runs in every Cloudflare data center.
- The DNS filtering features in Cloudflare Gateway run on the same technology that powers 1.1.1.1, the world’s fastest recursive DNS resolver.
- Cloudflare’s Secure Web Gateway accelerates connections to the applications your team uses.
- The technology that powers Cloudflare Browser Isolation is fundamentally different compared to other approaches and the speed advantages demonstrate that.
We’re excited to share how each of these components work together to deliver a comprehensive Zero Trust platform that makes your team faster. Continue reading
Magic makes your network faster
We launched Magic Transit two years ago, followed more recently by its siblings Magic WAN and Magic Firewall, and have talked at length about how this suite of products helps security teams sleep better at night by protecting entire networks from malicious traffic. Today, as part of Speed Week, we’ll break down the other side of the Magic: how using Cloudflare can automatically make your entire network faster. Our scale and interconnectivity, use of data to make more intelligent routing decisions, and inherent architecture differences versus traditional networks all contribute to performance improvements across all IP traffic.
What is Magic?
Cloudflare’s “Magic” services help customers connect and secure their networks without the cost and complexity of maintaining legacy hardware. Magic Transit provides connectivity and DDoS protection for Internet-facing networks; Magic WAN enables customers to replace legacy WAN architectures by routing private traffic through Cloudflare; and Magic Firewall protects all connected traffic with a built-in firewall-as-a-service. All three share underlying architecture principles that form the basis of the performance improvements we’ll dive deeper into below.
Anycast everything
In contrast to traditional “point-to-point” architecture, Cloudflare uses Anycast GRE or IPsec (coming soon) tunnels to send and receive traffic for customer Continue reading
Cloudflare Backbone: A Fast Lane on the Busy Internet Highway
The Internet is an amazing place. It’s a communication superhighway, allowing people and machines to exchange exabytes of information every day. But it's not without its share of issues: whether it’s DDoS attacks, route leaks, cable cuts, or packet loss, the components of the Internet do not always work as intended.
The reason Cloudflare exists is to help solve these problems. As we continue to grow our rapidly expanding global network in more than 250 cities, while directly connecting with more than 9,800 networks, it’s important that our network continues to help bring improved performance and resiliency to the Internet. To accomplish this, we built our own backbone. Other than improving redundancy, the immediate advantage to you as a Cloudflare user? It can reduce your website loading times by up to 45% — and you don’t have to do a thing.
The Cloudflare Backbone
We began building out our global backbone in 2018. It comprises a network of long-distance fiber optic cables connecting various Cloudflare data centers across North America, South America, Europe, and Asia. This also includes Cloudflare’s metro fiber network, directly connecting data centers within a metropolitan area.
Our backbone is a dedicated network, Continue reading
Unboxing the Last Mile: Introducing Last Mile Insights
“The last 20% of the work requires 80% of the effort.” The Pareto Principle applies in many domains — nowhere more so on the Internet, however, than on the Last Mile. Last Mile networks are heterogeneous and independent of each other, but all of them need to be running to allow for everyone to use the Internet. They’re typically the responsibility of Internet Service Providers (ISPs). However, if you’re an organization running a mission-critical service on the Internet, not paying attention to Last Mile networks is in effect handing off responsibility for the uptime and performance of your service over to those ISPs.
Probably not the best idea.
When a customer puts a service on Cloudflare, part of our job is to offer a good experience across the whole Internet. We couldn’t do that without focusing on Last Mile networks. In particular, we’re focused on two things:
- Cloudflare needs to have strong connectivity to Last Mile ISPs and needs to be as close as possible to every Internet-connected person on the planet.
- Cloudflare needs good observability tools to know when something goes wrong, and needs to be able to surface that data to you so that you can be Continue reading
LSA/LSP Flooding in OSPF and IS-IS
Peter Paluch loves blogging in microchunks on Twitter ;) This time, he described the differences between OSPF and IS-IS, and gracefully allowed me to repost the explanation in a more traditional format.
My friends, I happen to have a different opinion. It will take a while to explain it and I will have to seemingly go off on a tangent. Please have patience. As a teaser, though: The 2Way state between DRothers does not improve flooding efficiency – in fact, it worsens it.
LSA/LSP Flooding in OSPF and IS-IS
Peter Paluch loves blogging in microchunks on Twitter ;) This time, he described the differences between OSPF and IS-IS, and gracefully allowed me to repost the explanation in a more traditional format.
My friends, I happen to have a different opinion. It will take a while to explain it and I will have to seemingly go off on a tangent. Please have patience. As a teaser, though: The 2Way state between DRothers does not improve flooding efficiency – in fact, it worsens it.
Hedge 100: Supply Chain Diversity with Brooks Westbrook and Mike Bushong
Most network engineers don’t spend a lot of time thinking about their supply chain—you must call your favorite vendor, order, and a few weeks later the hardware shows up on your loading dock. It’s not so simple any more. If you disaggregate, you need to manage your software and hardware supply chains separately. You need to think about security in your supply chain—is that software package backdoored? Moving to the cloud might seem to solve these problems, but they don’t. Even virtual networks have physical limits.
Listen in as Mike Bushong, Brooks Westbrook, Eyvonne Sharp, Tom Ammon, and Russ White discuss supply chain diversity and security.
AWS Networking – Part I: Virtual Private Cloud (VPC) Introduction
AWS Virtual Private Cloud (VPC) is a virtual network for Amazon Elastic Cloud Compute instances (EC2) within AWS Region. AWS Regions, in turn, belongs to the global AWS Cloud environment. Each AWS Region consists of three or more physical data centers, Availability Zones (AZ). At the time of writing, Seoul and Tokyo have four, and Northern Virginia has six AZs. All other regions have three AZs. VPC spans over regional AZs but not between AWS Regions. In other words, VPCs are region-specific virtual networks.
A VPC has to have a CIDR (Classless Interdomain Routing) IP block attached to it. The VPC CIDR defines the IP range that we can use when creating subnets to VPC. CIDR range is VPC specific and can overlap with other VPC’s CIRD range. If there should be VPC-to-VPC inter-connection, VPC CIDR IP ranges have to be unique per VPC.
We can allocate subnets for EC2 instances from the VPC’s CIDR range. Subnets are AZ-specific, and they can’t be span from one AZ to another. Subnets are classified either as Public Subnets or Private Subnets. Public Subnet has a route to Internet GW (Internet Gateway) in its Routing Table (RT). EC2 instances launched in a Public Subnet have to have a public IPv4 address in order to have an Internet connection. Note that IPv6 addresses are always assigned from the public address space. EC2 launched in a Private Subnet doesn’t need a public IPv4 address, they can have an Internet connection through the NAT GW. To allow Internet connection to EC2 instances in Private Subnet, we need to add a route to NAT GW into the Private Subnet Routing Table. We can allow a stateful egress-only Internet connection for EC2 instances with IPv6 addresses in Private Subnet by using Egress-Only Internet GW. This way EC2 instance has an Internet connection but hosts on the internet can’t initiate a connection to EC2. IP connectivity between EC2 instances within VPC is established between private IP address even if one of the EC2s is attached to Public Subnet and has a Public IP address. VPC has a main Routing Table that is used with subnets which we don’t define subnet-specific RT.
Each VPC also has a default Network Access Control List (NACL). The default NACL is bind to all subnets in VPC by default. NACL is stateless by nature, traffic to and from the subnet has to be allowed in both inbound and outbound directions. The default NACL allows all ingress/egress traffic.
Figure 1-1 illustrates our example VPC and its relationship to AWS Availability Zones, AWS Regions, and AWS Account. When we create VPC, we first have to log on to our AWS account. Next, we select an AWS Region, in our case Europe (London) eu-west-2. Then we choose Availability Zones for subnets. In our case, network 10.10.0.0/24 is a Public Subnet in the AZ eu-west-2c, and network 10.10.1.0/24 is a Private Subnet in the AZ eu-west-2a. As the last step, we create subnet-specific Routing Tables where we can later add subnet-specific routes.
Figure 1-1: Virtual Private Cloud (VPC) Basic Building Blocks.
Continue reading
Optimizing “Middle Mile” Network Performance for The Cloud Age
Optimizing the middle mile provides measurable performance improvement as businesses create an IT infrastructure that’s built on the cloud.Day Two Cloud 115: Software-Defined Interconnects With Console Connect (Sponsored)
Today's Day Two Cloud sponsored episode dives into software-defined interconnects. The big idea is that you go up to a Web browser, click a few times, and now you've got a circuit stood up between your data center and AWS, or between you and a business partner, and so on. We'll get into the details about how it's done with Console Connect, a PCCW Global company.
The post Day Two Cloud 115: Software-Defined Interconnects With Console Connect (Sponsored) appeared first on Packet Pushers.