O iperf permite que o usuário especifique as portas em três locais - um onde o servidor escuta, um onde o cliente se conecta e outro em que o cliente gera um mini servidor para a opção -d / --dualtest . Precisamos de todos os três para isso.
Embora seja possível fazer isso com menos, descobri que era mais fácil especificar todas as portas para que eu pudesse rastreá-las. Nesta configuração, assumirei uma configuração parecida com esta:
----------- ------- -------
| Control | SSH #1,2 | Box | SSH #3 | Box |
| Box | ---------> | #1 | -------> | #2 |
----------- ------- -------
A "caixa de controle" também pode ter acesso direto ao SSH na caixa 2, mas não é necessário. Para isso, o Box # 2 será o servidor iperf em escuta no 7001 e o box 2 será um cliente ouvindo a porta 7002. Essas podem ser quaisquer portas acessíveis, eu escolhi aquelas duas aleatoriamente.
Primeiro, conecte-se à caixa 1. Em seguida, você precisa se conectar à Caixa 2. Nesta sessão aninhada, você precisará criar dois túneis de porta: um para frente e um reverso. As opções ssh que fazem isso são -L7001:localhost:7001 para o encaminhamento e -R7002:localhost:7002 para o reverso. Como o iperf espera que as portas estejam localizadas em um host remoto, cada túnel deve ser simétrico (o mesmo número de porta nas duas extremidades do túnel). Em seguida, inicie o servidor iperf ouvindo na porta 7001 ( iperf -s -p 7001 ).
Pode parecer algo assim:
me@control$ ssh box1.example.com
box1$ ssh -L7001:localhost:7001 -R7002:localhost:7002 box2.example.com
box2$ iperf -s -p 7001
------------------------------------------------------------
Server listening on TCP port 7001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Depois de iniciado, abra uma segunda sessão na Caixa 1. Aqui, inicie um cliente iperf para localhost na porta 7001, com a porta de retorno de retorno em 7002 (a porta de retorno padrão é 5001 como o servidor). Isso significa que o cliente tentará se conectar com um servidor iperf no localhost: 7001, que o SSH agarra e envia para a caixa 2. Em seguida, ele inicia um servidor iperf "mini" escutando em 7002. Uma vez que a conexão do cliente para o servidor é iniciada, o cliente iperf informa o servidor iperf para se conectar novamente na porta 7002. O servidor observa que a conexão de entrada está vindo de 127.0 .0.1 (ou :: 1 dependendo da configuração), então ele inicia um "mini" cliente que se conectará ao 127.0.0.1:7002. Como também temos o avanço inverso no lugar, o ssh também conecta essa conexão e a envia para a caixa 1.
Sua segunda sessão pode ser algo assim:
(nota lateral para este exemplo: eu defini o tempo para 30s para um teste diferente; o padrão será suficiente)
me@control$ ssh box1.example.com
box1$ iperf -c localhost -p 7001 -L 7002 -d -t 30
------------------------------------------------------------
Server listening on TCP port 7002
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to localhost, TCP port 7001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 37014 connected with 127.0.0.1 port 7001
[ 5] local 127.0.0.1 port 7002 connected with 127.0.0.1 port 51806
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 1.26 GBytes 361 Mbits/sec
[ 5] 0.0-30.2 sec 1.23 GBytes 349 Mbits/sec
Quando o cliente terminar o teste, a janela do seu servidor poderá ser algo como isto:
...
box2$ iperf -s -p 7001
------------------------------------------------------------
Server listening on TCP port 7001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 127.0.0.1 port 7001 connected with 127.0.0.1 port 41997
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 7002
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[ 6] local 127.0.0.1 port 46864 connected with 127.0.0.1 port 7002
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-30.0 sec 1.23 GBytes 351 Mbits/sec
[ 4] 0.0-30.2 sec 1.26 GBytes 359 Mbits/sec
AVISO: SSH distorcerá as velocidades de conexão percebidas. Rodar iperf sem SSH entre as mesmas duas caixas gerou isso (as caixas estão nas mesmas funções):
Cliente:
box1$ iperf -c box2.example.com -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to box2.example.com, TCP port 5001
TCP window size: 306 KByte (default)
------------------------------------------------------------
[ 3] local 172.20.0.1 port 45722 connected with 172.20.0.2 port 5001
[ 5] local 172.20.0.1 port 5001 connected with 172.20.0.2 port 60909
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.01 GBytes 866 Mbits/sec
[ 5] 0.0-10.0 sec 823 MBytes 689 Mbits/sec
Servidor:
box2$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 172.20.0.2 port 5001 connected with 172.20.0.1 port 45722
------------------------------------------------------------
Client connecting to 172.20.0.1, TCP port 5001
TCP window size: 306 KByte (default)
------------------------------------------------------------
[ 6] local 172.20.0.2 port 60909 connected with 172.20.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-10.0 sec 823 MBytes 690 Mbits/sec
[ 4] 0.0-10.0 sec 1.01 GBytes 864 Mbits/sec
Eu tentei brincar com as configurações da janela TCP, o comprimento do buffer, TCP_NODELAY e usando várias sessões SSH, mas a sobrecarga ainda estava presente. Eu também tentei o HPN-SSH, mas na verdade obtive um desempenho melhor do que o SSH regular, então acho que há um cenário que perdi quando estava configurando o HPN. Executar as conexões iperf em simplex em vez de duplex (a opção -r / --tradeoff (Faça um teste bidirecional individualmente)) obteve resultados mais próximos da velocidade do link, mas ainda com significativa sobrecarga de SSH.
Dito tudo, se você precisar criar uma ponte entre essas duas máquinas e medir a capacidade dessa ponte, essa solução é perfeita. Se você estiver tentando medir a taxa de transferência bruta entre essas máquinas, os números que esses testes fornecerão serão menores (e provavelmente muito menos) que a velocidade do link.