1. TCP 커넥션
HTTP는 IP, TCP, HTTP로 구성된 프로토콜 스택에서 최상위 계층입니다. HTTP에 보안 기능을 더한 HTTPS는 TLS 혹은 SSL이라 불리기도하며 HTTP와 TCP 사이에 있는 암호화(Cryptographic Encryption) 계층입니다.
HTTP가 메시지를 전송하고 할 경우, 현재 연결되어 있는 TCP 커넥션을 통해서 메시지 데이터의 내용을 순서대로 보냅니다. TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달합니다. 이 모든 것은 TCP/IP 소프트웨어에 의해 처리되며, 그 과정은 HTTP 프로그래머에게 보이지 않습니다.
2. TCP 성능에 대한 고려
HTTP는 TCP 바로 위에 있는 계층이기 때문에 HTTP 트랜잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받습니다. 트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메시지를 보내는 것에 비하여 상당히 짧습니다. 때문에 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생합니다.
2.1. TCP 커넥션 핸드셰이크 지연
어떤 데이터를 전송하든 새로운 TCP 커넥션을 열 때면, TCP 소프트웨어는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환합니다. 작은 크기의 데이터 전송에 커넥션이 사용된다면 이런 패킷 교환은 HTTP 성능을 크게 저하시킬 수 있습니다.
2.2. 확인응답 지연
인터넷 자체가 패킷 전송을 완벽히 보장하지는 않기 때문에, TCP는 성공적인 데이터 전송을 보장하기 위해서 자체적인 확인 체계를 가집니다. 각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가집니다. 각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환합니다. 만약 송신자가 특정 시간 안에 확인응답 메시지를 받지 못하면 패킷이 파기되었거나, 오류가 있는 것으로 판단하고 데이터를 다시 전송합니다.
확인응답은 그 크기가 작기 때문에, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답을 편승(Piggyback) 시킵니다. TCP는 송출 데이터 패킷과 확인응답을 하나로 묶음으로써 네트워크를 좀 더 효율적으로 사용합니다. 확인응답이 같은 방향으로 가는 데이터 패킷에 편승되는 경우를 늘리기 위해서, 많은 TCP 스택은 확인응답 지연 알고리즘을 구현합니다. 확인응답 지연은 송출할 확인응답을 특정 시간 동안 버퍼에 저장해 두고, 확인응답을 편승시키기 위한 송출 데이터 패킷을 찾습니다. 만약 일정 시간 안에 송출 데이터 패킷을 찾지 못하면 확인응답은 별도 패킷을 만들어 전송됩니다.
안타깝게도 요청과 응답 두 가지 형식으로만 이루어지는 HTTP 동작 방식은, 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킵니다. 막상 편승할 패킷을 찾으려고 하면 해당 방향으로 송출될 패킷이 많지 않기 때문에, 확인응답 지연 알고리즘으로 인한 지연이 자주 발생합니다. 운영체제에 따라 다르지만, 지연의 원인이 되는 확인응답 지연 관련 기능을 수정하거나 비활성활할 수 있습니다.
2.3. TCP 느린 시작
TCP의 데이터 전송 속도는 TCP 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라질 수 있습니다. TCP 커넥션은 시간이 지나면서 자체적으로 튜닝되어서, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나갑니다. 이렇게 조율하는 것을 TCP 느린 시작이라고 부르며, 이는 인터넷의 급작스러운 부하와 혼잡을 방지하는 데 쓰입니다. 이 혼잡제어 기능 때문에, 새로운 커넥션은 이미 어느 정도 데이터를 주고받은 튜닝된 커넥션보다 느립니다. 튜닝된 커넥션은 더 빠르기 때문에, HTTP에는 이미 존재하는 커넥션을 재사용하는 기능이 있습니다.
2.4. 네이글(Nagle)알고리즘
네이글 알고리즘은 네트워크 효율을 위해서, 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합칩니다. 네이글 알고리즘은 세그먼트가 최대 크기가 되지 않으면 전송을 하지 않습니다. 다만 다른 모든 패킷이 확인응답을 받았을 경우에는 최대 크기보다 작은 패킷의 전송을 허락합니다.
네이글 알고리즘은 HTTP 성능 관련해 여러 문제를 발생시킵니다. 첫 번째로, 크기가 작은 HTTP 메시지는 패킷을 채우지 못하기 때문에, 앞으로 생길지 생기지 않을지 모르는 추가적인 데이터를 기다리며 지연될 것입니다. 두 번째로, 네이글 알고리즘은 확인응답 지연과 함께 쓰일 경우 형편없이 동작합니다. HTTP 애플리케이션은 성능 향상을 위해서 HTTP 스택에 TCP_NODELAY 파라미터 값을 설정하여 네이글 알고리즘을 비활성화하기도 합니다.
2.5. TIME_WAIT의 누적과 포트 고갈
TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영역(Control Block)에 기록해 놓습니다. 이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안에는 생성되지 않게 하기 위한 것으로, 이전 커넥션과 관련된 패킷이 그 커넥션과 같은 주소와 포트 번호를 가지는 새로운 커넥션에 삽입되는 문제를 방지합니다.
TIME_WAIT 포트 고갈은 성능 측정 시에 심각한 성능 저하를 발생시키지만, 보통 실제 상황에서는 문제를 발생시키지 않습니다. 성능 측정 대상 서버는 클라이언트가 접속할 수 있는 IP 주소의 개수를 제한하고, 그 서버에 접속하여 부하를 발생시킬 컴퓨터의 수는 적기 때문입니다. 게다가 일반적으로 서버는 HTTP의 기본 TCP 포트인 80번을 사용합니다. 이런 상황에서는 가능한 연결의 조합이 제한되며, TIME_WAIT로 인해 서 순간순간 포트를 재활용하는 것이 불가능해집니다.
3. HTTP 커넥션 관리
커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 안 좋아질 수 있습니다. 각 트랜잭션이 새로운 커넥션을 필요로 한다면, 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생할 것입니다. 순차적인 처리로 인한 지연에는 물리적인 지연뿐 아니라, 하나의 이미지를 내려받고 있는 중에는 웹페이지의 나머지 공간에 아무런 변화가 없어서 느껴지는 심리적인 지연도 있습니다.
3.1. 병렬 커넥션
HTTP 클라이언트가 여러 개의 커넥션을 맺음으로서 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 합니다. 각 커넥션의 지연 시간을 겹치게 하면 총 지연 시간을 줄일 수 있고, 클라이언트의 인터넷 대역폭을 한 개의 커넥션이 다 써버리는 것이 아니라면 나버지 객체를 내려받는 데에 남은 대역폭을 사용할 수 있습니다.
병렬 커넥션이 일반적으로 더 빠르기는 하지만, 항상 그렇지는 않습니다. 클라이언트의 네트워크 대역폭이 좁을 때는 대부분 시간을 데이터를 전송하는 데만 쓸 것입니다. 여러 개의 객체를 병렬로 내려받는 경우, 이 제한된 대역폭 내에서 각 객체를 전송받는 것은 느리기 때문에 성능상의 장점은 거의 없어집니다. 또한 다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킵니다. 브라우저는 실제로 병렬 커넥션을 사용하기는 하지만 적은 수의 병렬 커넥션만을 허용합니다.
3.2. 지속 커넥션
웹 클라이언트는 보통 같은 사이트에 여러 개의 커넥션을 맺습니다. 서버에 HTTP 요청을 하기 시작한 애플리케이션은 웹페이지 내의 리소스를 가져오기 위해서 그 서버에 또 요청하게 될 것입니다. 이 속성을 사이트 지역성(Site Locality)라 부릅니다. 따라서 HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있습니다. 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 부릅니다.
3.2.1. Connection 헤더
HTTP 는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락합니다. 어떤 경우에는 두 개의 인접한 HTTP 애플리케이션이 현재 맺고 있는 커넥션에만 적용될 옵션을 지정해야 할 때가 있습니다. Connection 헤더에는 홉별(Hop-By-Hop) 헤더 명을 기술하는데, 이것을 헤더 보호하기라고 합니다. Connection 헤더에 명시된 헤더들이 전달되는 것을 방지하기 때문입니다. HTTP 애플리케이션이 Connection 헤더와 함께 메시지를 전달받으면, 수신자는 송신자에게 온 요청에 기술되어 있는 모든 옵션을 적용합니다. 그리고 다음 홉(Hop)에 메시지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술되어 있던 모든 헤더를 삭제합니다.
3.2.2. HTTP/1.0+의 Keep-Alive 커넥션
keep-alive는 사용하지 않기로 결정되어 HTTP/1.1 명세에서 빠졌습니다. 하지만 아직도 브라우저와 서버 간에 keep-alive 핸드셰이크가 널리 사용되고 있기 때문에, HTTP 애플리케이션은 그것을 처리할 수 있게 개발해야 합니다. HTTP/1.0 keep-alive 커넥션을 구현할 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection: Keep-Alive 헤더를 포함시킵니다. 이 요청을 받은 서버는 그다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답합니다. keep-alive는 HTTP/1.0에서 기본으로 사용되지는 않습니다. 응답에 Connection: Keep-Alive 헤더가 없으면, 클라이언트는 서버가 keep-alive를 지원하지 않으며, 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라 추정합니다.
keep-alive의 동작은 Keep-Alive 헤더의 쉼표로 구분된 옵션들로 제어할 수 있습니다. 다음 예는 서버가 약 5개의 추가 트랜잭션이 처리될 동안 커넥션을 유지하거나, 2분 동안 커넥션을 유지하라는 내용의 Keep-Alive 응답 헤더입니다.
Connection: Keep-Alive
Keep-Alive: max=5, timeout=1203.2.3. Keep-Alive와 멍청한(dumb) 프락시
오래되고 단순한 수많은 프락시들이 Connection 헤더에 대한 처리 없이 요청을 그대로 전달합니다. 여기서부터 문제가 시작됩니다. 프락시는 keep-alive를 전혀 모르지만, 받았던 모든 데이터를 그대로 클라이언트에게 전달하고 나서 서버가 커넥션을 끊기를 기다립니다. 하지만 서버는 프락시가 자신에게 커넥션을 유지하기를 요청한 것으로 알고 있기 때문에 커넥션을 끊지 않습니다. 클라이언트가 응답 메시지를 받으면, 다음 요청을 보내기 시작하는데, 커넥션이 유지되고 있는 프락시에 그 요청을 보냅니다. 프락시는 같은 커넥션상에서 다른 요청이 오는 경우는 예상하지 못하기 때문에, 그 요청은 프락시로부터 무시되고 브라우저는 아무런 응답 없이 로드 중 이라는 표시만 나옵니다.
3.2.4. HTTP/1.1의 지속 커넥션
HTTP/1.1에서는 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 지원합니다. HTTTP/1.0의 keep-alive 커넥션과 달리 HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있습니다. 클라이언트가 해당 커넥션으로 추가적인 요청을 보내지 않을 것이라면, 마지막 요청에 Connection: close 헤더를 보내야 합니다. 하지만 Connection: close를 보내지 않는 것이 서버가 커넥션을 영원히 유지하겠다는 것을 뜻하지는 않습니다. HTTP/1.1 기기는 Connection 헤더의 값과는 상관없이 언제든지 커넥션을 끊을 수 있습니다.
3.3. 파이프라인 커넥션
HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝할 수 있습니다. 여러 개의 요청은 응답이 도착하기 전까지 큐에 쌓입니다. 첫 번째 요청이 네트워크를 통해 서버로 전달되면, 거기에 이어 두 번째 세 번째 요청이 전달될 수 있습니다. 이는 대기 시간이 긴 네트워크 상황에 네트워크상의 왕복으로 인한 시간을 줄여서 성능을 높여줍니다. 파이프라인에는 여러 가지 제약 사항이 있습니다.
- HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안 됩니다.
- HTTP 응답을 요청 순서와 같게 와야 합니다. HTTP 메시지는 순번이 매겨져 있지 않아서 응답이 순서 없이 오면 순서에 맞게 정렬시킬 방법이 없습니다.
- HTTP 클라이언트는 커넥션이 언제 끊어지더라도, 완료되지 않은 요청이 파이프라인에 있으면 언제든 다시 요청을 보낼 준비가 되어 있어야 합니다.
- HTTP 클라이언트는 POST와 같은 비멱등(Nonidempotent) 요청을 반복해서 보낼 경우 문제가 생길 수 있기 때문에 파이프라인을 통해 보내면 안됩니다. 에러가 발생하면 파이프라인을 통한 요청 중에 어떤 것들이 서버에서 처리되었는지 클라이언트가 알 방법이 없습니다.
4. 커넥션 끊기
어떠한 HTTP 클라이어트, 서버, 혹은 프락시든 언제든지 TCP 전송 커넥션을 끊을 수 있습니다. 보통 커넥션은 메시지를 다 보낸 다음 끊지만, 에러가 있는 상황에서는 헤더의 중간이나 다른 엉뚱한 곳에서 끊길 수 있습니다.
4.1. Content-Length
각 HTTP 응답은 본문의 정확한 크기 값을 가지는 Content-Length 헤더를 가지고 있어야 합니다. 클라이언트나 플락시가 커넥션이 끊어졌다는 HTTP 응답을 받은 후, 실제 전달된 엔터티의 길이와 Content-Length의 길이가 일치하지 않거나 Content-Length 자체가 존재하지 않으면 수신자는 데이터의 정확한 길이를 서버에게 물어봐야 합니다.
4.2. Connection 재시도와 멱등성
HTTP 애플리케이션은 예상치 못하게 커넥션이 끊어졌을 때에 적절히 대응할 수 있는 준비가 되어 있어야 합니다. 클라이언트가 트랜잭션을 수행 중에 전송 커넥션이 끊기게 되면, 클라이언트는 그 트랜잭션을 재시도 하더라도 문제가 없다면 커넥션을 다시 맺고 한 번 더 전송을 시도해야 합니다.
그로 인한 부작용들을 조심해야 합니다. 어떤 요청 데이터가 전송되었지만, 응답이 오기 전에 커넥션이 끊기면 클라이언트는 실제로 서버에서 얼마만큼 요청이 처리되었는지 전형 알 수 없습니다. POST와 같은 부류의 요청들은 반복될 경우 주문이 여러 번 중복될 것이기 때문에 반복을 피해야 합니다.
4.3. 우아한 커넥션 끊기
애플리케이션이 각기 다른 HTTP 클라이언트, 서버, 프락시와 통신할 때, 그리고 그들과 파이프라인 지속 커넥션을 사용할 때, 기기들이 예상하지 못한 쓰기 에러를 발생하는 것을 예방하기 위해 절반 끊기를 사용해야 합니다. 입력 채널이나 출력 채널 중에 하나를 개별적으로 끊는 것을 절반 끊기라고 부릅니다.
보통은 커넥션의 출력 채널을 끊는 것이 안전합니다. 커넥션의 반대편에 있는 기기는 모든 데이터를 버퍼로부터 읽고 나서 데이터 전송이 끝남과 동시에 당신이 커넥션을 끊었다는 것을 알게 될 것입니다. 클라이언트에서 더는 데이터를 보내지 않을 것임을 확실할 수 없는 이상, 커넥션의 입력 채널을 끊는 것은 위험합니다. 만약 클라이언트에서 이미 끊긴 입력 채널에 데이터를 전송면, 서버의 운영체제는 TCP connection reset by peer 메시지를 클라이언트에 보낼 것입니다. 대부분 운영체제는 이것을 심각한 에러로 취급하여 버퍼에 저장된, 아직 읽히지 않은 데이터를 모두 삭제합니다. 이러한 상황은 파이프라인 커넥션에서는 더 악화됩니다. 응답 데이터가 기기에 잘 도착하였어도 아직 읽히지 않은 버퍼에 있는 응답 데이터는 사라지게 됩니다.
5. 출처
- [HTTP 완벽 가이드 - 웹은 어떻게 동작하는가] - 프로그래밍 인사이트
