0

My Question: Does anybody know why an apache2 server can act as an iperf server? I thought that an apache2 server does only answer HTTP requests.

My Situation: I accidentally realized that an apache2 server can act as a iperf server when connecting an iperf client to port 80.

My setup: Two Ubuntu Server 14.03 directly connected to each other.

Commands:

On Server1:
user@server1:~$ sudo service apache2 status 
 * apache2 is running
user@server1:~$ sudo netstat -aple | grep http
tcp6       0      0 [::]:http               [::]:*                  LISTEN      root       18567325    21985/apache2   
user@server1:~$ 

and on the other side:

On Server2:
user@server2:~$ iperf -c 192.168.2.2 -p 80
------------------------------------------------------------
Client connecting to 192.168.2.2, TCP port 80
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.3 port 60267 connected with 192.168.2.2 port 80
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  29.1 MBytes  24.4 Mbits/sec
user@server2:~$ 
Jimmy88
  • 341
  • 1
  • 2
  • 10

1 Answers1

3

It doesn't. iperf doesn't care though, it just blasts the data out anyway. Apache will react with a "414 Request URI too large" error page, which will be answered with even more useless data by iperf.

iperf doesn't need an iperf server on the other end, just a willing "victim" that doesn't cut the connection.

Sven
  • 98,649
  • 14
  • 180
  • 226
  • Okay, but why does Apache send so many packets back such that it ends up with such a bandwidth? – Jimmy88 Oct 19 '15 at 16:38
  • It doesn't. The transfer rate is from your machine to the server. You really need an `iperf` server on the other end to get the bidrectional bandwith. Look into it with Wireshark or tcpdump so see what's going on. – Sven Oct 19 '15 at 16:39
  • Okay thanks. Now I saw that apache is just ACKing the packets. But why? – Jimmy88 Oct 20 '15 at 07:29
  • It's not Apache ACKing the packages, this is done by the OS kernel/network stack. It does this because it correctly received the TCP packets (the kernel doesn't know or need to know about HTTP) and then sends them up the stack to Apache, which will try its best to make sense out of it. – Sven Oct 20 '15 at 07:52
  • But why is there no TCP RST? – Jimmy88 Oct 20 '15 at 13:31
  • Why should there be? Apache is trying it's best to establish a working HTTP connection. Also, does it really matter? It should be absolutely clear what happens now and the finer point of how to react to this malformed data is mainly philosophical... – Sven Oct 20 '15 at 13:40
  • There could (maybe should?) be a TCP RST because there is no HTTP (GET request) in the payload of the iperf packets. – Jimmy88 Oct 21 '15 at 09:29
  • Really, I don't care. Your question has been answered and maybe you can discuss with the Apache developers why they chose to handle this case the way they did. – Sven Oct 21 '15 at 10:17