{"id":749,"date":"2015-10-18T18:31:10","date_gmt":"2015-10-18T21:31:10","guid":{"rendered":"http:\/\/thesqltimes.com\/blog\/?p=749"},"modified":"2018-12-18T22:06:52","modified_gmt":"2018-12-19T01:06:52","slug":"instancia-default-e-conectividade-nao-default-parte-2","status":"publish","type":"post","link":"https:\/\/thesqltimes.com\/blog\/2015\/10\/18\/instancia-default-e-conectividade-nao-default-parte-2\/","title":{"rendered":"Inst\u00e2ncia DEFAULT e conectividade n\u00e3o default – Parte 2"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>
Post 2\/3. Este post \u00e9 parte da s\u00e9rie: Inst\u00e2ncia DEFAULT e conectividade n\u00e3o default<\/a>\r\n<\/div>\r\nTempo de Leitura:<\/span> 4<\/span> minutos<\/span><\/span>

Ol\u00e1! Tempos de calor, hor\u00e1rio de ver\u00e3o, e n\u00e3o podemos parar de estudar, aprender e compartilhar! Ent\u00e3o, aqui estamos, com a segunda, e pen\u00faltima, parte sobre conectividade no SQL Server. No \u00faltimo post,<\/a> vimos que acontece quando voc\u00ea configura uma inst\u00e2ncia DEFAULT para aceitar conex\u00f5es em um porta que n\u00e3o seja a default. Para os exemplos, estou usando um SQL chamado SQL1, cujo o IP \u00e9 50.50.50.11, partindo de um client cujo IP \u00e9 50.50.50.10. Vamos ver agora, o que ocorre quando temos um firewall no meio de uma situa\u00e7\u00e3o destas!<\/p>\n

Cen\u00e1rio\u00a0Firewall no meio!<\/strong><\/h2>\n

Este \u00e9 outro caso que pode dar um pouco mais de dor de cabe\u00e7a. A maioria dos firewalls n\u00e3o s\u00e3o t\u00e3o amig\u00e1veis como o Sistema Operacional que apenas devolve um RESET na porta. Eles descartam o pacote e n\u00e3o respondem nada ao client. Isso faz com o que o pobre infeliz do client fique esperando uma resposta at\u00e9 que o timeout do TCP entre em a\u00e7\u00e3o. O efeito colateral aqui ser\u00e1 o mesmo cen\u00e1rio anterior, por\u00e9m o tempo de espera, somado \u00e0s retransmiss\u00f5es, ainda na camada do TCP, pode ocupar todo o precioso tempo de timeout pra conex\u00e3o (que \u00e9 uma coisa diferente do timeout do TCP), fazendo com que nem o pr\u00f3ximo protocolo tenha chance… E o que voc\u00ea tem neste caso? Aquele famoso erro de conex\u00e3o relacionado \u00e0 rede depois de uma longa espera!<\/p>\n

Pra ilustrar isso eu apenas liguei o firewall do Windows no servidor onde est\u00e1 a inst\u00e2ncia SQL1 e bloqueei a porta 1433. Os efeitos foram bem legais. O c\u00f3digo que executei foi este:<\/p>\n

$start = (Get-Date); #Pega a data atual!\r\nsqlcmd -S SQL1 -U Rodrigo -P rrg -Q \"DECLARE @i int = 1;\"; #Conecta com o SQL1 e faz algo simples\r\n((Get-Date) - $start).totalMilliseconds #Exibe o tempo gasto\r\n\r\n<\/pre>\n
\u00a0E l\u00e1 vamos n\u00f3s:<\/div>\n
<\/div>\n
\"Tempo<\/a><\/div>\n
<\/div>\n
Uau! Incr\u00edveis 21 segundos e o que temos na resposta? Um erro! O que ocorreu foi exatamente o que explicamos acima. Aqui est\u00e1 o trace que n\u00e3o me deixa mentir:<\/p>\n
\"Trace<\/a><\/p>\n
Olha o que o trace no mostra:<\/p>\n
    \n
  1. Linha 1: O Three Way Handshake come\u00e7a e um solicita\u00e7\u00e3o de conex\u00e3o na porta 1433 \u00e9 enviada (devido ao fato de estarmos usando uma inst\u00e2ncia DEFAULT)<\/li>\n
  2. Linha 2: 3 segundos depois do in\u00edcio da captura \u00e9 feito um retransmission. Note que n\u00e3o houve um RESET por parte do servidor. O firewall simplesmente descartou o pacote e n\u00e3o enviou qualquer resposta.<\/li>\n
  3. Linha 3: 9 segundos depois do in\u00edcio da captura (e 6 segundos depois do retransmission anterior) \u00e9 feito um novo retransmission. De novo o firewall eliminou o pacote sem qualquer considera\u00e7\u00e3o #Coitado<\/strong><\/li>\n
  4. Linha 4: 21 segundos depois vemos um ind\u00edcio de uma outra tentativa de conex\u00e3o. Neste ponto j\u00e1 \u00e9 poss\u00edvel perceber o client tentando usar o pr\u00f3ximo protocolo.<\/li>\n<\/ol>\n
    Note que o intervalo entre o RETRANSMISSION vai dobrando!\u00a0Primeiro, ele esperou 3 segundos para fazer um retranmission. Depois esperou 6. Pela l\u00f3gica, ele iria aguardar mais 12 para dar como encerrado. E podemos perceber que se voc\u00ea somar 9 + 12, temos exatamente os 21 segundos. Isto \u00e9 um comportamento do protocolo TCP e estes links te d\u00e3o mais detalhes sobre isto.<\/p>\n