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

Question

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ê.