[스터디] HTTP 커넥션 관리

본 게시글은 CS 지식 스터디에서 HTTP에 관해 발표하기 위해 'HTTP 완벽 가이드(인사이트)'의 4장 내용을 요약한 게시물입니다.

학습 목표

HTTP는 어떻게 TCP 커넥션을 사용하는가

TCP 커넥션의 지연, 병목, 막힘

병렬 커넥션, keep-alive 커넥션, 커넥션 파이프라인을 통한 HTTP 최적화

TCP 커넥션

HTTP 통신은 TCP/IP 프로토콜을 통해 이루어진다.

TCP

HTTP 커넥션은 몇몇 사용 규칙을 제외하고는 TCP 커넥션에 불과하다.

TCP 커넥션은 인터넷을 안정적으로 연결해주는 신뢰할 수 있는 통신 방식을 제공한다.

 

HTTP가 메시지를 전송하고자 할 경우 현재 연결된 TCP 커넥션을 통해 메시지 내용을 순서대로 보낸다.

TCP는 세그먼트 단위로 데이터를 잘게 나누고, IP 패킷에 담아 전달한다.

 

TCP 커넥션 유지하기

TCP는 서로 다른 포트 번호를 이용해 여러 개의 커넥션을 동시에 유지할 수 있다.

TCP 커넥션은 발신지와 수신지의 IP 주소 및 포트 번호 4가지 값으로 고유하게 식별되며, 이 값이 완전히 같은 두 커넥션은 존재할 수 없다.

<발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>

 

TCP 성능에 영향을 끼치는 요소

HTTP 요청 과정 중 어떤 네트워크 지연이 발생하는지 보자. 트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메시지를 보내는 것에 비해 상당히 짧다.

 

지연의 주요 원인

HTTP에 영향을 주는 가장 일반적인 TCP 관련 지연은 아래와 같다.

• TCP 커넥션 핸드셰이크 설정
• 혼잡 제어를 위한 TCP 느린 시작(slow-start)
• 데이터를 모아 한번에 전송하는 네이글(nagle) 알고리즘
• TCP의 편승(piggyback) 확인응답(acknowledgment)을 위한 확인응답 지연
• TIME_WAIT 지연과 포트고갈

 

TCP 커넥션 핸드셰이크 지연

 

새로운 TCP 커넥션을 열 때면 TCP 소프트웨어는 커넥션을 맺기 위해 연속으로 IP 패킷을 교환한다.

HTTP 트랜잭션이 아주 큰 데이터를 주고 받지 않는 평범한 경우 3-way 핸드쉐이크는 눈에 띄는 지연을 발생시킨다.

(패킷 하나는 수백 바이트의 HTTP 요청을 담을 수 있다.)

→ 커넥션 연결 과정 지연을 제거하기 위해 이미 존재하는 커넥션을 재활용할 필요가 있다.

 

참고: TCP Fast Open은 무엇일까?

"3-way handshake 도중에 데이터를 같이 보내버리자!"

즉,

1. 클라이언트가 SYN 패킷에 데이터를 같이 실어서 보냄
2. 서버가 SYN-ACK 응답과 동시에 데이터를 처리
3. 클라이언트가 ACK를 보내며 통신 계속 진행

이러면 첫 요청부터 데이터가 전달되고 처리되기 때문에, 초기 지연(latency)이 줄어듭니다.

보안을 위해 TFO Cookie라는 걸 사용한다. (신뢰 가능한 클라이언트 판단)

TCP 느린 시작(slow start)

TCP의 데이터 전송 속도는 TCP 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라진다.

TCP 커넥션은 처음에 최대 속도를 제한하고, 데이터 전송이 성공함에 따라 점차 속도 제한을 높인다. 이를 TCP 느린 시작(slow start) 라 부르며 이는 인터넷의 급작스러운 부하와 혼잡을 방지한다.

이로 인해 새로운 커넥션은 오래된 커넥션보다 느리다.

→ 그래서 HTTP에는 이미 존재하는 커넥션을 재활용하는 기능이 있다.

확인응답 지연

 

각 TCP 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 수신자에게 반환한다.

확인 응답은 크기가 작기 때문에, (네트워크를 효율적으로 사용하기 위해) TCP는 같은 방향으로 송출되는 데이터 패킷에 확인 응답을 편승(piggyback) 시킨다.

그러나 해당 방향으로 편승할 패킷이 없으면 지연이 발생한다.

네이글(Nagle) 알고리즘

네이글 알고리즘 은 네트워크 효율을 위해 패킷을 전송하기 전 많은 양의 TCP 데이터를 합친다.

세그먼트가 최대 크기가 되지 않으면 전송하지 않으며, 다른 모든 패킷의 확인응답을 받았을 경우에만 최대 크기보다 작은 패킷의 전송을 허락한다.

작은 HTTP 메시지는 세그먼트를 채우지 못해 전송이 지연되고, 확인 응답 지연과 함께 발생하면 성능 저하가 심해진다.

TIME_WAIT와 포트 고갈

 

TCP 커넥션을 끊으면, 커넥션의 IP 주소와 포트 번호를 메모리의 작은 영역에 기록해둔다. 이는 새로운 TCP 커넥션이 일정 시간 동안 생성되지 못하도록 막는 것으로 세그먼트의 최대 생명주기의 두 배 정도 시간동안 유지된다.

이는 이전 커넥션의 잔여 패킷이 새 커넥션에 혼입되는 것을 방지하기 위함이다.

일반적으로 문제되진 않지만, 서버가 초당 500개 이상 요청을 처리할 정도로 빠르고, 성능 시험 등 특수한 상황에선 TIME_WAIT 포트 고갈이 일어날 수 있다.

HTTP 커넥션 관리

HTTP의 커넥션 최적화 기술에 대해 알아보자.

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

 

커넥션 관리가 제대로 이뤄지지 않으면 TCP 성능이 매우 안 좋아질 수 있다. 예를 들어 3개의 이미지가 있는 웹페이지가 있다 가정하면, 네 개의 HTTP 트랜잭션이 만들어져야 한다. 각 트랜잭션이 새로운 커넥션을 만든다면, 매번 커넥션 지연과 느린 시작으로 인해 전체 성능이 저하된다.

HTTP 커넥션의 성능 향상을 위해 아래와 같은 기술이 이용된다.

• 병렬 커넥션 : 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청
• 지속 커넥션 : 커넥션을 맺고 끊는 데서 발생하는 지연 제거를 위해 TCP 커넥션 재활용
• 파이프라인 커넥션 : TCP 커넥션 공유를 통한 병렬 HTTP 요청

병렬 커넥션

HTTP 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 한다.

여러 커넥션의 지연을 겹치게 하여 전체 요청 처리 시간을 줄일 수 있다.

다만, 너무 많은 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 일으킨다. 현대 최신 브라우저는 대부분 6~8개의 병렬 커넥션을 지원한다.

지속 커넥션

HTTP 1.1을 지원하는 클라이언트는 TCP 커넥션을 유지하여 다음 HTTP 요청에 재활용할 수 있다. HTTP 요청을 처리한 후에도 연결 상태를 유지하는 TCP 커넥션을 지속 커넥션이라 한다.

이를 통해 커넥션을 맺는데 소요되는 시간을 절약할 수 있고, 느린 시작으로 인한 지연도 피할 수 있다.

두 가지 지속 커넥션 타입이 있는데 HTTP/1.0+에는 keep-alive 커넥션 이 있고, HTTP/1.1에는 지속 커넥션 이 있다.

HTTP/1.0+의 Keep-Alive 커넥션

많은 HTTP/1.0 브라우저와 서버들은 Keep-Alive 커넥션이라는 지속 커넥션을 지원하기 위해 확장되었다. (1996년 경 시작)

초기 지속 커넥션에는 상호 운용 관련 설계 오류가 있었다. HTTP/1.1 명세에서 빠졌지만 아직 초기 keep-alive 커넥션이 매우 많이 사용되고 있다.

HTTP/1.0에서 커넥션을 유지하려면 요청에 Connection: Keep-Alive 헤더를 명시해야 한다. 이 요청을 받은 서버는 같은 헤더를 포함시켜 응답한다.

HTTP/1.1의 지속 커넥션

HTTP/1.1는 설계가 더 개선된 지속 커넥션을 지원한다.

HTTP/1.0의 Keep-Alive 커넥션과 달리 HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있다. 모든 커넥션을 지속 커넥션으로 취급한다.

트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 추가해야 한다.

파이프라인 커넥션

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

HTTP 파이프라이닝이란 여러 개의 요청을 한 번에 보내고, 응답은 순서대로 받는 방식이다. (응답을 기다리지 않고 요청을 연달아 보내는 것)

이는 네트워크 상 왕복으로 인한 시간을 줄여 전송 효율을 높인다.

출처 및 참고
데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈 공저, 『HTTP 완벽 가이드』, 인사이트(2014)
HTTP 완벽 가이드 4장