Instância DEFAULT e conectividade não default – Parte 2

Olá! Tempos de calor, horário de verão, e não podemos parar de estudar, aprender e compartilhar! Então, aqui estamos, com a segunda, e penúltima, parte sobre conectividade no SQL Server. No último post, vimos que acontece quando você configura uma instância DEFAULT para aceitar conexões em um porta que não seja a default. Para os exemplos, estou usando um SQL chamado SQL1, cujo o IP é 50.50.50.11, partindo de um client cujo IP é 50.50.50.10. Vamos ver agora, o que ocorre quando temos um firewall no meio de uma situação destas!

Cenário Firewall no meio!

Este é outro caso que pode dar um pouco mais de dor de cabeça. A maioria dos firewalls não são tão amigáveis como o Sistema Operacional que apenas devolve um RESET na porta. Eles descartam o pacote e não respondem nada ao client. Isso faz com o que o pobre infeliz do client fique esperando uma resposta até que o timeout do TCP entre em ação. O efeito colateral aqui será o mesmo cenário anterior, porém o tempo de espera, somado às retransmissões, ainda na camada do TCP, pode ocupar todo o precioso tempo de timeout pra conexão (que é uma coisa diferente do timeout do TCP), fazendo com que nem o próximo protocolo tenha chance… E o que você tem neste caso? Aquele famoso erro de conexão relacionado à rede depois de uma longa espera!

Pra ilustrar isso eu apenas liguei o firewall do Windows no servidor onde está a instância SQL1 e bloqueei a porta 1433. Os efeitos foram bem legais. O código que executei foi este:

$start = (Get-Date); #Pega a data atual!
sqlcmd -S SQL1 -U Rodrigo -P rrg -Q "DECLARE @i int = 1;"; #Conecta com o SQL1 e faz algo simples
((Get-Date) - $start).totalMilliseconds #Exibe o tempo gasto

Uau! Incríveis 21 segundos e o que temos na resposta? Um erro! O que ocorreu foi exatamente o que explicamos acima. Aqui está o trace que não me deixa mentir:

Olha o que o trace no mostra:

1. Linha 1: O Three Way Handshake começa e um solicitação de conexão na porta 1433 é enviada (devido ao fato de estarmos usando uma instância DEFAULT)
2. Linha 2: 3 segundos depois do início da captura é feito um retransmission. Note que não houve um RESET por parte do servidor. O firewall simplesmente descartou o pacote e não enviou qualquer resposta.
3. Linha 3: 9 segundos depois do início da captura (e 6 segundos depois do retransmission anterior) é feito um novo retransmission. De novo o firewall eliminou o pacote sem qualquer consideração #Coitado
4. Linha 4: 21 segundos depois vemos um indício de uma outra tentativa de conexão. Neste ponto já é possível perceber o client tentando usar o próximo protocolo.

Note que o intervalo entre o RETRANSMISSION vai dobrando! Primeiro, ele esperou 3 segundos para fazer um retranmission. Depois esperou 6. Pela lógica, ele iria aguardar mais 12 para dar como encerrado. E podemos perceber que se você somar 9 + 12, temos exatamente os 21 segundos. Isto é um comportamento do protocolo TCP e estes links te dão mais detalhes sobre isto.

• https://support.microsoft.com/en-us/kb/170359
• https://support.microsoft.com/en-us/kb/2786464

Os 21 segundos iniciais desta tentativa estão dedicados somente à tentativa usando TCP. Quando ele retorna com o status definitivo de falha, depois das tentativas de retransmissões, o client prossegue com o próximo protocolo. Porém, neste ponto, o timeout default de 8 segundos  do sqlcmd já bateu e por isso temos a mensagem de erro acima. Uma medida bem interessante, se você quer ver a conexão funcionar neste exemplo, é aumentar o tempo de timeout da conexão usando o parâmetro -l. Como no meu teste eu gastei 21 segundos só pro TCP, eu coloquei um timeout de 25 que, teoricamente, é mais do que suficiente.

$start = (Get-Date); #Pega a data atual!
sqlcmd -S SQL1 -l 25 -U Rodrigo -P rrg -Q "DECLARE @i int = 1;"; #Conecta com o SQL1 e faz algo simples com um timeout de 25 segundos
((Get-Date) - $start).totalMilliseconds #Exibe o tempo gasto

E voilà! Nenhuma mensagem de erro e a conexão foi feita com sucesso! Claro que isso seria facilmente resolvido de outras maneiras, sem ter que gastart todo este tempo de conexão.

Bom, por hoje é só! No próximo post vamos, enfim, ver como podemos se conectar na instância errada. Neste momento você já deve imaginar como!

Até lá!

Rodrigo Ribeiro Gomes
[]’s

————
Bom… antes de ir… #SQLSaturdayBSB #SQLSaturday469 #SQLSaturday #SQLSaturday!!!!!

https://www.sqlsaturday.com/469/RegisterNow.aspx

Rodrigo Ribeiro Gomes

DBA Team Leader na Power Tuning

Posts Relacionados:

Instância DEFAULT e conectividade não default – Parte 1 Instância DEFAULT e conectividade não default – Parte 3 Recuperando dados deletados do SQL Server sem Backup Full – Parte 1 Recuperando dados deletados do SQL Server sem Backup Full – Parte 2 Desempenho do Processador x Desempenho do SQL Server – Parte 4