[Network] HTTP Persistance Connection 지속 커넥션

안녕하세요.

오늘은 HTTP의 지속 커넥션에 대해서 알아보도록 하겠습니다.

🔸 HTTP Connectionless

HTTP는 서버 자원을 효율적으로 사용하기 위해 연결을 유지하지 않는다는 특징이 있습니다. 이 특징 때문에 데이터를 요청할 때마다 TCP 연결을 다시 해야 합니다.

위 그림을 보시면, TCP 커넥션을 설정하는 시간이 다른 작업에 비해 상당히 긴 것을 보실 수 있습니다. 연결을 유지하지 않는다면, 요청마다 새로운 TCP 커넥션을 설정하는데 시간이 많이 소요될 것입니다.

🔸 지속 커넥션

이를 해결하기 위해 지속 커넥션이라는 개념이 등장합니다.

 

HTTP/1.0의 Keep-Alive 커넥션

keep-alive 커넥션의 장점은 아래 그림에서 볼 수 있습니다.

4개의 HTTP 트랜잭션에 대해서 지속 커넥션으로 요청을 처리할 때는 커넥션을 맺고 끊은 데 필요한 작업이 없어서 시간을 단축할 수 있습니다.

 

Keep-Alive 동작

HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 Connection:Keep-Alive 헤더를 포함합니다. 서버에서 그다음 요청도 이 커넥션을 통해 받을 것이면, 응답 메시지에 같은 헤더를 포함해서 보냅니다.

Keep-Alive 옵션

- timeout : 응답 헤더를 통해 이 커넥션이 얼마간 유지될 것인지 알려줍니다. 

- max : 응답 헤더를 통해 커넥션이 몇 개의 HTTP 트랜잭션을 처리할 때까지 유지될 것인지 알려줍니다.

 

ex) 서버가 5개의 추가 트랜잭션이 처리될 동안 커넥션을 유지하거나, 2분 동안 유지하라 

Connection : Keep-Alive

Keep-Alive: max=5, timeout=120

 

 

Keep-Alive 커넥션 사용 시 주의할 점

지속 커넥션을 지원하지 않는 Proxy를 사용하면 에러가 발생하여 주의해야 합니다.

a) 클라이언트는 proxy에 Connection:Keep-Alive 헤더를 보내 커넥션 유지를 요청합니다.

b) proxy는 keep-alive가 무엇인지 모르기 때문에 서버에 메시지를 그대로 전달합니다.

c) 웹 서버는 proxy가 커넥션을 유지하자고 요청하는 것으로 판단하여, Connection: Keep-Alive 헤더를 proxy에 보냅니다.

d) proxy는 서버에서 받은 응답을 그대로 전달합니다. 클라이언트는 서버와 커넥션을 유지하고 있다고 생각하게 됩니다.

    proxy는 데이터 전달이 끝났기 때문에 서버가 커넥션을 끊기를 기다립니다.

이 상황에서 클라이언트가 서버에 요청 메시지를 보내면, 해당 proxy에 그 요청을 보내게 됩니다. proxy는 같은 커넥션 상에서 다른 요청이 오는 것을 예상하지 못하여 그 요청은 무시되고, 브라우저는 응답 없이 로드 중이라는 표시만 나오게 됩니다. 

 

Proxy-Connection

위의 상황을 해결하기 위해 Proxy-Connection이라는 헤더가 등장합니다. 

Connection 헤더를 지원하지 않는 proxy는 해당 헤더를 그대로 전달하지만, 서버는 그 헤더를 무시하기 때문에 에러가 나지 않게 됩니다. 

하지만 Connection 헤더를 지원하는 proxy의 경우, Proxy-Connection을 Connection으로 바꿔서 전달하고 정상적으로 keep-alive 커넥션이 형성됩니다.

 

HTTP/1.1의 지속 커넥션

HTTP/1.1에서는 keep-alive 커넥션을 지원하지 않는 대신, 더 개선된 지속 커넥션을 지원합니다.

HTTP/1.0의 keep-alive 커넥션과는 달리 HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있기 때문에, 별도로 설정하지 않아도 지속 커넥션을 제공합니다.

커넥션을 끊기 위해서는 Connection: close 헤더를 명시해주면 되고, 해당 헤더가 없으면 커넥션을 계속 유지하는 것을 뜻하게 됩니다.

 

파이프라인 커넥션

HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝 할 수 있습니다. 응답을 기다리지 않고 요청을 연속적으로 보내어 지연 시간을 줄일 수 있습니다.

하지만 응답 순서를 보장해야 하기 때문에 앞의 요청을 처리할 때 많은 시간이 소요되면 뒤의 요청들이 늦게 응답을 받게 되는 Head Of Line Blocking이 발생합니다.

 

HTTP/2.0의 멀티플렉싱

HTTP/2.0에서는 파이프라이닝을 멀티플렉싱(Multiplexing) 알고리즘으로 대체하여, 단일 TCP 연결로 다수의 요청과 응답을 Stream 형태로 받습니다. 

앞선 요청의 응답이 오래 걸리더라도, HTTP/1.1처럼 기다리는 것이 아니라 먼저 응답받은 대로 클라이언트에 전달하게 됩니다. 이를 통해 Head Of Line Blocking 문제를 해결하게 됩니다. 

 

하지만 HTTP/2.0도 TCP 기반이기 때문에, TCP의 특징 때문에 발생하는 지연 문제는 해결하지 못했습니다. (ex. 한 패킷이 손실되면 이 패킷이 재전송될 때까지 기다림.)

이를 해결하기 위해 UDP를 사용한 QUIC 프로토콜도 등장합니다. 이 프로토콜에 대해서는 다음 시간에 다루도록 하겠습니다.

 

감사합니다.

 

출처 : 책 - HTTP 완벽 가이드

        https://www.whatap.io/ko/blog/38/

        https://web.dev/performance-http2/