Graphs of user counts from Iran since the onset of shutdowns

There have been protests, daily Internet shutdowns, and increased censorship in Iran since 2022-09-21, about 5 days ago. The increased censorship have caused people to use Tor and its pluggable transports more than before. Here is a graph of the users of each kind of transport in Iran. See below for commentary and caveats.

This graph—and all Tor Metrics graphs—does not show unique daily IP addresses, as you might expect; instead it shows an estimate of concurrent users, averaged per day. For example, if you see a data point at 44751 on September 21, that means that if you were to count the number of users connected at random times during the 24 hours of September 21, on average you would count 44751 connections.

The reason I’ve made a special graph, instead of just linking to some Tor Metrics graphs, is that Tor Metrics currently undercounts Snowflake users. The problem is that the Snowflake bridge has an unusual multi-instance tor setup for scaling reasons. Tor Metrics only counts 1 out of N descriptors published by the bridge, where N was recently increased from 4 to 8 and then to 12. To make this graph, I reimplemented the user estimation algorithm from Tor Metrics, except taking all the Snowflake instances into account. That said, you can get pretty much the same graph by mentally combining Directly connecting users from Iran and Bridge users by transport from Iran—just know that the Snowflake counts will be too low in the latter.

Source code for graph

The first caveat is that the most recent points on the graph are subject to change as relays publish their descriptors. The 24 Sep column may change a little as it settles.

The second caveat is that the meek counts are unbelievably high, in my opinion. Just knowing how the pluggable transport protocol works, it is hard for a server to support more than about 64000 concurrent users, because it will run out of localhost port numbers. (It may be possible to work around this limitation, but as far as I know the meek bridge has not done anything special in that regard.) Also, with my experience scaling the Snowflake bridge, I know that a tor process simply cannot support that many users on one CPU core A further piece of evidence against the meek counts is the bridge’s own bandwidth and client graphs. As the client count increased, the bandwidth went down. This may be an artifact of the way client counts are estimated, which has been suspected of inflating counts in the past.

cymrubridge02 read/written bytes per second cymrubridge02 average number of connected clients

The Snowflake bridge has had a lot of measurement and engineering in the past few days to be able to keep up with the increased load. These are the changes that have been made so far:


Ignore my questions. I found that answers to my questions.

Intersting that from US come more ussers than in Iran+Russia+China where the internet is filtred Users – Tor Metrics that

Source code for graph

An updated graph. For some reason, Tor Metrics is missing a lot of data in graphs lately (maybe it was to do with !42?), which you can see as gaps in the graph. There’s no “total” line in this graph, because of the missing data. As before, the snowflake line does not use preprocessed data from Tor Metrics, but is separately calculated from the descriptors.

As I stated before, I think the high numbers in the meek graph are probably bogus. Besides that, it looks like meek may have been blocked somehow between 30 Sep and 05 Oct.

The reduction in snowflake users on 05 Oct is being investigated in Sudden reduction in snowflake-01 bridge bandwidth, 2022-10-04 17:15 (#40207) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab.