diz que um cliente tem vários arquivos para postar em um servidor por meio do método HTTP Post, haverá duas chamadas de API. como não quero criar duas conexões TCP e quero reutilizar a conexão TCP, então uso o cabeçalho Http keep-alive para a primeira solicitação, agora só preciso de uma única conexão TCP estabelecida na primeira solicitação para enviar vários arquivos
Mas como o servidor distingue entre esses dois arquivos? Quando não usamos keep alive, o SO do cliente envia sinalizador EOF (fim do arquivo) para indicar ao servidor que a transmissão do arquivo foi concluída
abaixo está minha suposição, não tenho certeza se está correta:
Agora usamos keep-alive, para que um EOF no servidor não feche a conexão, então um segundo arquivo pode ser enviado pela mesma conexão e terminar com EOF. Mas como o cliente fecha a conexão TCP quando não deseja enviar mais nenhum arquivo? se o cliente enviar outro EOF, o servidor pode pensar que vai enviar outro arquivo?
a única coisa que consigo pensar é que, digamos que você tenha apenas 5 arquivos para enviar, na 5ª solicitação HTTP, você não envia o cabeçalho keep-alive, mas a 1ª, a 2ª, a 3ª e a 4ª solicitações precisam ser enviadas com cabeçalho keep-alive, meu entendimento está correto?
Não, isso não acontece. O final de uma solicitação HTTP é detectado pelo recebimento da linha delimitadora vazia (para solicitações sem corpo) ou pela leitura da quantidade exata de bytes especificada no cabeçalho "Content-Length" da solicitação (para solicitações com corpo de comprimento fixo ) ou lendo um bloco de 0 bytes (para solicitações em blocos).
O RFC 9112 vinculado à outra resposta fala detalhadamente sobre o enquadramento da mensagem, a seção 6.3 "Comprimento do corpo da mensagem" em particular.
Isso não está correto. O TCP não tem outra maneira de "enviar um sinalizador EOF", exceto fechando o lado do remetente da conexão (a operação shutdown(SHUT_WR)), que é final - nenhum dado mais pode ser enviado nessa direção, e isso geralmente leva a um desligamento na outra direção também.
De forma mais geral, "EOF" não é uma mensagem real; em linguagens de programação é determinado pela ausência de mensagem – EOF é gerado após obter um resultado de 0 byte da operação read(). Mas o TCP não tem como sinalizar isso arbitrariamente, porque não informa os limites da mensagem ao receptor; ele literalmente não pode entregar uma mensagem de 0 byte. (Na verdade, segmentos TCP vazios são frequentemente usados como um mecanismo de "keep-alive" especificamente porque não fazem com que o receptor veja uma leitura de 0 byte.)
(Em outras palavras: você não fecha uma conexão TCP sinalizando EOF – você sinaliza EOF fechando a conexão TCP.)
É por isso que a RFC 9112 usa o termo 'fechar', por exemplo, em "As mensagens de solicitação nunca são delimitadas por perto [...]" em vez de "delimitadas por EOF".
O
Connection: keep-alive
cabeçalho está implícito no HTTP/1.1, ou seja, é necessário apenas no HTTP/1.0. E no HTTP/1 persistente, uma solicitação é enviada após a outra e as respostas voltam na mesma ordem. O HTTP/1 também define claramente onde uma mensagem (solicitação, resposta) termina (cabeçalhos Content-Length, Transfer-Encoding) para que um aplicativo que implemente corretamente o HTTP/1 possa detectar os limites da mensagem.Para detalhes técnicos específicos consulte a norma