Inconsistência no gerenciamento de conexões TCP e HTTP

1

Observo o seguinte cenário no WireShark:

Oproblemaquevejoaquiéquedepoisdereceber[FIN,ACK]doservidor(4090)ereconhecê-lo(4092),oclientehttptentaenviaroutrasolicitaçãoHTTPemvezdeimediatamentefechar(eprovavelmenterestabelecer)aconexãoTCP.Pareceque[FIN,ACK]ésimplesmenteignoradopelosclientesHTTP.

DeacordocomaRFC7230(6.3),oprotocoloHTTPespecificaseumecanismodefornoparagerenciamentodeconexãopersistenteusandoConnectionheaders.Funcionamuitobem,jáqueésuportadoporclienteseservidores.

Noentanto,oHTTPgeralmenteéexecutadoemcimadoTCP.OgerenciamentodeconexãoTCPnãotemidéiasobreoprotocolonapartesuperiorepodeserusadoindependentementedoHTTP.MasosclientesHTTPnãosuportamomanuseio(eprovavelmenteelesnãodeveriam,eledeveriasersuportadononíveldosoquete).Noentanto,osservidoresoutilizam,porquepermitefecharaconexãosemenviarsolicitaçãoHTTPadicional.Porexemplo,nginxenviaFINpackage,quandoaconexãoéexpiradaouem atualização de configuração .

NOTA Quando o cliente HTTP recebe RST do servidor, ele fecha a conexão. E parece ser feito no nível do socket, já que não consigo encontrar nada relacionado a isso no código-fonte dos clientes HTTP.

  1. O meu entendimento da situação é correto? Ignorar a mensagem FIN pelos clientes, enquanto os servidores a usam, parece estar completamente errado.
  2. Por que RST é tratado no nível do soquete, mas FIN não é?
  3. Existe algum padrão RFC / outro sobre como os clientes HTTP devem lidar com o fechamento da conexão TCP?
  4. O nginx está fazendo algo não padrão ou os clientes HTTP não seguem o padrão?

PS Eu sou capaz de reproduzi-lo usando clientes HTTP em Python 2/3, Java e httperf utilitário escrito em C. Então eu acredito que é comum para clientes HTTP ignorar FIN message. Eu quero entender o porquê.

    
por Yaroslav Admin 13.08.2015 / 13:07

0 respostas