Robert Kisteleki

HTTP Measurements with RIPE Atlas

Robert Kisteleki
5 You have liked this article 0 times.

After a discussion with the community about HTTP measurements, we'll start implementing this as a publicly available measurement type.


The topic of publicly available HTTP measurements in RIPE Atlas has been raised by a number of people in the RIPE Atlas community at different times, and several discussions about the pros and cons of this feature have taken place over the years. RIPE Atlas is primarily geared towards measuring the network layer, and HTTP measurements go somewhat beyond this. We therefore felt that, in order to add this as a public feature, there should be enough demand for it, and the implemented functionality should address the expressed concerns and requests.

Taking into account the points raised in discussions on the RIPE Atlas and MAT Working Group Mailing Lists, we will implement the following approach:

  1. The targets of such measurements will only be RIPE Atlas anchors, which already run HTTP servers (you can learn more in the documentation , see a list and a map of current anchors, or find out how you can host one ). The anchors only serve very small and well-defined pages, so this is not expected to cause bandwidth problems. (As always, there will be no possibility of listening in on the host's private, local traffic.)
  2. We will enable HTTP measurements for all users and from any probes.
  3. Parameters such as costs, minimum frequency, maximum number of probes involved, etc. will be set by the RIPE Atlas development team, just as with the other measurement types.
  4. The RIPE NCC will still be able to support other, vetted HTTP measurements towards other targets as well, as long as it benefits the community, as well as other HTTP measurements that we deem operationally useful. These will be evaluated on a case-by-case basis.

We're also considering adding HTTP measurements to the list of "anchoring measurements" (i.e. to the set of measurements we automatically execute towards anchors) with a relatively low frequency.

We believe this approach provides a good balance between utility and security. It will be possible to extend this functionality later with additional features, as long as they maintain this trade-off.

We plan to develop and deploy this functionality over the summer period.


You can leave a comment at the bottom of this article or send a message to the , which is followed by the RIPE Atlas developers. You can also join the MAT Working Group Mailing List .

5 You have liked this article 0 times.

You may also like

View more

About the author

I am the leader of the Research and Development team at the RIPE NCC leading a dedicated team of thinkers to support the RIPE community by providing network research, data analysis and prototype tool development and services including RIPE Atlas and RIPEstat.

Comments 2