HTTP 커넥션 관리 :: 마이구미

이번 글은 HTTP 커넥션 관리에 대해 다뤄본다.

HTTP 완벽 가이드 서적을 참고하여 작성한 글이다.

순차적인 트랜잭션 처리에 의한 지연

커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 안 좋아진다.

예를 들어 3개의 이미지가 있는 웹페이지가 있다고 한다면,

페이지를 보여주기 위해서는 네 개의 HTTP 트랜잭션이 만들어야 한다.

(하나는 HTML, 나머지 세 개는 첨부되 이미지에 관련된 트랜잭션)

*트랜잭션 - 요청 명령(클라이언트->서버)과 응답 결과(서버->클라이언트)로 구성

각 트랜잭션이 새로운 커넥션을 맺는데 발생하는 지연과 느린 시작 지연이 발생한다.

느린 시작 지연 - TCP 커넥션은 시간이 지나면서 자체적으로 튜닝된다.

처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라 제한을 높여간다.

급작스러운 부하와 혼잡을 방지하기 위해 이러한 방법으로 조율해나간다.

그렇기에 새로운 커넥션은 어느 정도 데이터를 주고 받은 커넥션보다 느리다.

그렇기에 커넥션을 재사용하는 것으로 지속 커넥션이란 용어 및 방법이 존재한다. (밑에서 다룬다)

위와 같은 결과로, 순차적인 처리로 인한 지연에는 물리적인 지연과 심리적인 지연이 있다.

사용자는 페이지가 듬성듬성 보여지는 것보다, 한번에 로딩되는 것을 선호한다.

그렇다고 순차적인 로드 방식에서의 한번에 보여주기 위한 방식은 단점이 존재한다.

모든 트랜잭션이 완료되기까지 텅빈화면만 보이게 된다. (물론 로딩 관련 이미지를 사용하면 되겠지만 성능 측면에서 너무 느리다)

이를 해결하기 위해 HTTP 커넥션의 성능을 향상시킬 수 있는 기술을 다뤄본다.

• 병렬 커넥션
• 지속 커넥션
• 파이프라인 커넥션

병렬 커넥션

위처럼 순차적으로 트랜잭션 처리와는 반대로, 트랜잭션을 병렬로 처리할 수 있게 한다.

그림처럼 웹페이지의 컴포넌트들은 각각의 커넥션에서 병렬로 처리된다.

그 결과, 단일 커넥션일 때의 대역폭 제한과 커넥션의 대기 시간을 낭비하지 않게 된다.

위 그림은 HTML을 받아오는 트랜잭션을 먼저 처리한 후, 이미지들을 병렬로 내려받는다.

이로써, 순차적인 처리보다 월등히 빠른 것을 볼 수 있다.

하지만 병렬 커넥션이 항상 빠른 것은 아니다.

네트워크의 대역폭이 좁을 때는 각 객체를 전송받는 것이 느리기 때문이다.

또한 다수의 커넥션을 통해 메모리를 많이 소모한다.

백 명의 사용자가 100개의 커넥션을 맺고 있다면, 서버는 총 10,000개의 커넥션을 떠안게 됨으로써 성능을 크게 떨어뜨린다.

실제로 브라우저는 병렬 커넥션을 사용하지만, 6~8개의 커넥션만을 허용한다고 한다.

과도한 커넥션의 경우에 서버는 임의적으로 끊어버릴 수 있다.

병렬 커넥션의 단점은 아래와 같다.

• 각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
• 각각의 새로운 커넥션은 TCP 느린 시작 때문에 성능이 떨어진다.
• 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있다.

지속 커넥션

위에서도 살짝 언급을 했다.

간단히 정의하자면, 커넥션을 재사용하는 것을 의미한다.

재사용함으로써 얻는 이점은 아래와 같다.

• 커넥션을 맺기 위한 작업과 지연을 줄여준다. (=TCP 느린 시작이 일어나지 않는다)
• 튜닝된 커넥션을 유지한다.
• 커넥션의 수를 줄여준다.

단점으로는 잘못 관리할 경우, 연결된 커넥션들이 계속해서 쌓일 경우 불필요한 리소스가 발생한다.

지속 커넥션과 병렬 커넥션을 함께 사용하면 가장 효과적이다.

현재에도 많은 웹페이지에서 활용되고 있다.

Connection:Keep-Alive

일반적으로 keep-alive 헤더를 포함하여 지속 커넥션을 구현할 수 있다.

관련 헤더는 제한과 규칙이 존재하기에, 충분히 알아야한다.

그렇지 않으면, 많은 경우에서 오류가 발생할 것이다.

자세한 건 관련 링크를 참고하길 바란다.

파이프라인 커넥션

지속 커넥션을 통해서 요청을 파이프라이닝할 수 있다.

이로써, 지속 커넥션의 성능을 더 높여준다.

그림을 보다시피, 첫번째 요청이 서버에 전달되면, 이어서 두 번째 세번째 요청이 전달되게 된다.

이로써, 여러 개의 요청은 응답이 도착하기 전에 큐에 쌓여 네트워크 상 왕복 시간을 줄여준다.

하지만 에러가 발생한다면, 파이프라인을 통한 요청 중에 어떤 것들이 서버에서 처리 되었는지 클라이언트에서 알 방법이 없다.

그렇기에, POST와 같은 비멱등 요청은 보내서는 안된다.