Http 프로토콜은 TCP 프로토콜을 기반으로 합니다. 브라우저가 서버에서 웹 페이지 데이터를 가져와야 할 때 Http 요청을 발행합니다. Http는 TCP를 통해 서버에 대한 연결 채널을 설정합니다. 이 요청에 필요한 데이터가 완료되면 Http는 즉시 TCP 연결을 끊습니다

TCP 프로토콜은 FIN 패킷을 전송하여 연결을 해제하므로 FIN 패킷이 끝 표시이므로 연결이 끊어질 때까지 수신된다는 의미입니다.

하지만

시간이 지날수록 HTML 페이지는 더욱 복잡해지고, 많은 그림이 삽입될 수 있습니다. 이때 그림에 액세스하기 위해 매번 TCP 연결을 설정하는 것은 비효율적입니다. 따라서 낮은 효율성 문제를 해결하기 위해 Keep-Alive가 제안되었습니다. HTTP/1.1부터는 연결 기능을 유지하기 위해 기본적으로 Keep-Alive가 활성화됩니다. 간단히 말해서 웹 페이지가 열릴 때 클라이언트와 서버 간에 HTTP 데이터를 전송하는 데 사용되는 TCP 연결이 닫히지 않습니다. 클라이언트 이 서버의 웹페이지를 다시 방문하면 설정된 연결을 계속 사용하게 됩니다. 연결 유지는 연결을 영구적으로 유지하지 않으며 다른 서버 소프트웨어(예: Apache)에서 설정할 수 있습니다. 여기에서는 일정 시간 동안 TCP 연결이 유지되지만 이 시간은 제한되어 있으며 해당 시점에서는 여전히 닫혀 있으므로 각 연결이 완료된 후에도 닫히는 것으로 간주합니다.

그럼 Keep-Alive를 켠 후 종료를 어떻게 판단해야 할까요?
실제로 HTTP 헤더에는 HTTP 패킷 본문의 길이인 content-length가 있습니다

물론 콘텐츠 길이가 없는 경우, 즉 청크 인코딩을 사용하는 경우도 있습니다. 데이터를 일련의 블록으로 나누어 전송하며, 각 블록에는 크기 설명이 있습니다. 헤더를 생성할 때 서버가 전체 엔터티의 크기를 알지 못하더라도(일반적으로 엔터티는 동적으로 생성되기 때문에) 청크 분할 인코딩을 사용하여 알려진 크기의 여러 청크를 전송할 수 있습니다.

인코딩은 여러 개의 청크를 사용하며 길이가 0으로 표시된 청크로 끝납니다. 각 청크는 두 부분으로 구성됩니다. 첫 번째 부분은 청크의 길이와 길이 단위(일반적으로 작성되지 않음)이고 두 번째 부분은 길이, 내용, 각 부분은 CRLF(전체 이름 캐리지
return/라인 피드 캐리지 리턴/라인 피드)로 구분됩니다. 길이가 0인 마지막 청크의 콘텐츠를 바닥글이라고 하며 이는 추가 헤더 정보입니다(일반적으로 직접 무시할 수 있음).

또한 HTTP 메시지 헤더와 메시지 본문은 CRLF(캐리지 리턴 및 줄 바꿈)로 구분됩니다. rnrn