Not knowing the details of your setup, it is difficult to answer the question “why” with certainty. However, you also ask “How can this be possible?”, and I can give you some possibilities. They are not ”fiber“-specific.
You are downloading through HTTP, which is a TCP/IP protocol. This protocol is bi-directional, i.e. every packet that is received by your HTTP client is also acknowledged to the server. Thus upload and download are not totally separate(able) traffic.
You are downloading from a remote server (vagrantcloud.com), probably not located in your room, building, city, maybe not even state or continent. There are many different network components involved, which have different wire speed and buffer size, and you share them with “the Internet” typically … which you cannot control.
You are monitoring the system under observation with a tool running on the system itself. Nobody would do this in professional context (I hope) or at least draw conclusions very carefully from the measurements. It may give wrong results for two reasons.
- You will influence the behaviour of your host and at least some of the network components which are used by the running download.
- Your tool may be buggy, because it counts (to be fast and efficient, without decoding/unpacking) incoming packets regardless of their destination or origin, thus assuming that unrelated traffic is a result of its own test traffic.
You can use Wireshark in a pure observer mode to monitor your upload/download traffic and generate the traffic itself by contacting several (geographically separated) servers with other tools (like you did) in order to try to saturate your DSL link. Such a measurement should be rather objective. Again, you would ideally run it on another computer that you put on the same network as your “download test sink.“
PS: Think of your room/housemate and neighbours, who share the bandwidth and will notice that their “internet is slow again today” when you are doing your tests.
