JJ BLOG

Ruby on Rails로 웹개발을 하고있는 웹개발자입니다.

HTTP 완벽가이드::Connection

18 Aug 2019 »

book

이 포스팅은 책 ‘HTTP 완벽가이드’를 읽고 작성하였습니다.


4. 커넥션 관리

4.1 TCP 커넥션

전 세계 모든 HTTP 통신은, 패킷 교환 네트워크 프로토콜들의 계층화된 집합인 TCP/IP를 통해 이루어집니다.

  • 웹 브라우저가 TCP 커넥션을 통해 웹서버에 요청을 보냅니다.
    URL : http://jongjineee.github.io:80/2019/08/18/http-connection.html
    1) 브라우저가 jongjineee.github.io라는 호스트 명을 추출합니다.
    2) 브라우저가 이 호스트 명에 대한 IP 주소를 찾습니다.
    3) 브라우저가 포트 번호 80번을 얻습니다.
    4) 브라우저가 202.43.78.3의 80포트로 TCP 커넥션을 생성합니다.
    5) 브라우저가 서버로 HTTP GET 요청 메시지를 보냅니다.
    6) 브라우저가 서버에서 온 HTTP 응답 메시지를 읽습니다.
    7) 브라우저가 커넥션을 끊습니다.

4.1.1 신뢰할 수 있는 데이터 전송 통로 TCP

HTTP 커넥션은 몇몇 사용 규칙을 제외하고는 TCP 커넥션에 불과합니다. TCP 커넥션은 인터넷을 안정적으로 연결해줍니다. TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달됩니다.

4.1.2 TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송됩니다.

TCP는 IP 패킷(혹은 IP 데이터그램)이라고 불리는 작은 조각을 통해 데이터를 전송합니다. HTTP가 메시지를 전송하고자 할 경우, 현재 연결되어 있는 TCP 커넥션을 통해서 메시지 데이터의 내용을 순서대로 보냅니다. TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달합니다. 각 TCP 세그먼트는 하나의 IP 주소에서 다른 IP 주소로 IP 패킷에 담겨 전달됩니다.

IP 패킷은 다음을 포함합니다.

  • IP 패킷 헤더
  • TCP 세그먼트 헤더
  • TCP 데이터 조각

4.1.3 TCP 커넥션 유지하기

컴퓨터는 항상 TCP 커넥션을 여러 개 가지고 있습니다. TCP는 포트 번호를 통해서 이런 여러 개의 커넥션을 유지합니다. TCP 커넥션은 네 가지 값으로 식별합니다.

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

이 네 가지 값으로 유일한 커넥션을 생성합니다.

4.1.4 TCP 소켓 프로그래밍

운영체제는 TCP 커넥션의 생성과 관련된 여러 기능을 제공합니다. 소켓 API는 HTTP 프로그래머에게 TCP와 IP의 세부사항들을 숨깁니다. 소켓 API는 유닉스 운영체제용으로 먼저 개발되었지만, 지금은 소켓 API의 다양한 구현체들 덕분에 대부분의 운영체제와 프로그램 언어에서 이를 사용할 수 있게 되었습니다.

소켓 API를 사용하면, TCP endpoint 데이터 구조를 생성하고, 원격 서버의 TCP endpoin에 그 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있습니다. TCP API는, 기본적인 네트워크 프로토콜의 핸드셰이킹, 그리고 TCP 데이터 스트림과 IP 패킷 간의 분할 및 재조립에 대한 모든 세부사항을 외부로부터 숨깁니다.

일단 커넥션이 맺어지면 클라이언트는 HTTP 요청을 보내고 서버는 이를 읽습니다. 서버가 요청 메시지를 다 받으면, 그 요청을 분석하여 클라이언트가 원하는 동작을 수행합니다. 클라이언트에게 데이터를 보내고 클라이언트는 이를 받아 응답 데이터를 처리합니다.

4.2 TCP의 성능에 대한 고려

HTTP는 TCP 바로 위에 있는 계층이기 때문에 HTTP 트랜잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받습니다.

4.2.1 HTTP 트랜잭션 지연

트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메시지를 보내는 것에 비하면 상당히 짧다는 것을 알 수 있습니다. 클라이언트나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 네트워크 지연 때문에 발생합니다. 이런 TCP 네트워크 지연은 하드웨어의 성능, 네트워크와 서버의 전송 속도, 요청과 응답 메시지의 크기, 클라이언트와 서버 간의 거리에 따라 크게 달라집니다. 또한 TCP 프로토콜의 기술적인 복잡성도 지연에 큰 영향을 끼칩니다.

4.3.1 흔히 잘못 이해하는 커넥션 헤더

HTTP는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락한다. HTTP 메시지는 클라이언트에서 서버까지 중개 서버들을 하나하나 거치면서 전달됩니다. HTTP 커넥션 헤더 필드는 커넥션 토큰을 쉼표로 구분하여 가지고 있으며, 그 값들은 다른 커넥션에 전달되지 않습니다. 커넥션 헤더는 다음 세 가지 종류의 토큰이 전달될 수 있습니다.

  • HTTP 헤더 필드명으너 이 커넥션에만 해당되는 헤더들을 나열합니다.
  • 임시적인 토큰 값은 커넥션에 대한 비표준 옵션을 의미합니다.
  • close 값은 커넥션이 작업이 완료되면 종료되어야 함을 의미합니다.

커넥션 토큰이 HTTP 헤더 필드 명을 가지고 있으면, 해당 필드들은 현재 커넥션만을 위한 정보이므로 다음 커넥션에 전달하면 안됩니다. 커넥션 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳으로 전달하는 시점에서 삭제되어야합니다.

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

커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 나빠질 수 있습니다. 순차적인 처리로 지연에는 물리적인 지연 뿐만 아니라 하나의 데이터를 내려받는 중에는 웹페이지에 아무런 변화가 없어서 느끼는 심리적인 지연이 있습니다. 순차적인 처리 방식에는 특정 브라우저의 경우 객체를 화면에 배치하려면 객체의 크리를 알아야하기 때문에 모든 객체를 내려받기 전까지 텅 빈 화면을 보여주는 단점이 있습니다.

4.4 병렬 커넥션

병렬 커넥션은 순차적 처리 방식의 단점을 해결해줍니다.
HTTP는 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 합니다.

4.4.1 병렬 커넥션은 페이지를 더 빠르게 내려받는다

단일 커넥션의 대역폭 제한과 커넥션이 동작하고 있지 않은 시간을 활용하면, 객체가 여러 개 있는 웹페이지를 더 빠르게 내려받을 수 있습니다. 다수의 트랜잭션 발생시, 별도의 커넥션에서 동시에 처리되어 총 지연시간이 줄어듭니다.

4.4.2 병렬 커넥션이 항상 더 빠르지는 않다

일반적으로 병렬 커넥션이 더 빠르지만, 항상 그렇지는 않습니다. 클라이언트 네트워크 대역폭이 좁을 때, 제한된 대역폭 내에서 여러 개의 커넥션을 생성하면서 생기는 부하 때문에 순차적으로 내려받는 것보다 더 오래 걸릴 수 있습니다.

4.4.3 병렬 커넥션은 더 빠르게 ‘느껴질 수’ 있다

병렬 커넥션이 페이지를 항상 더 빠르게 로드하지는 않습니다. 하지만 화면에 여러 개의 객체가 동시에 보이면서 내려받고 있는 상황을 볼 수 있기 때문에 사용자는 더 빠르다고 느낍니다. 사람들은 총 다운로드 시간이 더 많이 걸린다 하더라도 눈으로 작업을 확인할 수 있으면 더 빠르다고 여기기 때문입니다.

4.5 지속 커넥션

웹 클라이언트는 보통 같은 사이트에 여러 개의 커넥션을 맺습니다. 따라서 트랜잭션 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있습니다. 이는 커넥션 맺기 위한 준비작업 시간을 절약해주고 느린 시작으로 인한 지연을 회피하도록 해줍니다.

4.5.1 지속 커넥션 vs 병렬 커넥션

병렬 커넥션에도 몇 가지 단점이 있습니다.

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

또한 지속 커넥션의 장점이 있습니다.

  • 커넥션을 맺기 위한 사전 작업과 지연을 줄여줍니다.
  • 튜닝된 커넥션을 유지하며 커넥션의 수를 줄여줍니다.

하지만 지속 켜넥션을 잘못 관리할 경우, 계속 연결된 상태로 있는 수많은 커넥션이 쌓게 될 것입니다.

4.5.2 HTTP/1.0+의 Keep-Alive 커넥션

초기의 keep-alive 커넥션은 상호 운용과 관련된 설계에 문제가 있었지만 아직 많은 클라이언트와 서버는 이 초기 keep-alive 커넥션을 사용하고 있습니다. 그리고 그 설계상의 문제는 HTTP/1.1에서 수정되었습니다.

4.5.3 Keep-Alive 동작

클라이언트는 커넥션을 유지하기 위해서 요청에 Connection:Keep-Alive 헤더를 호함시킵니다. 이 요청을 받은 서버는 그 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답합니다.

4.5.4 Keep-Alive 옵션

Keep-Alive 헤더는 커넥션을 유지하기를 바라는 요청일 뿐입니다. 클라이언트나 서버가 이를 요청 받았다고 모조건 따를 필요는 없습니다. 언제든지 커넥션을 끊을 수 있으며 트랜잭션의 수를 제한할 수도 있습니다.

4.5.6 Keep-Alive와 dumb 프락시

dumb 프락시에서 keep-alive를 사용할 때 생기는 문제가 있습니다. 웹 클라이언트 요청에 Connection:Keep-Alive 헤더가 있으면, 클라이언트가 현재 연결하고 있는 TCP 커넥션을 끊지 않고 계속 유지하려는 것입니다.

Connection 헤더의 무조건 전달

프락시는 Connection 헤더를 이해하지 못해서 해당 헤더를 삭제하지 않고 요청 그대로를 다음 프락시에 전달 프락시는 keep-alive를 전혀 모르지만, 받았던 모든 데이터를 그대로 클라이언트에게 전달하고 나서 서버가 커넥션 끊기를 기다림. 그러나 서버는 프락시가 커넥션을 유지하길 요청한 것으로 알고 있기 때문에 커넥션을 끊지 않음. 따라서 프락시는 커넥션이 끊어지기 전까지 무작정 기다리게 됨. 이런 잘못된 통신 때문에 브라우저는 타임아웃이 나서 커넥션이 끊길 때까지 기다림 이런 종류의 잘못된 통신을 피하려면, 프락시는 Connection 헤더들을 절대 전달하면 안 됨

특히 문제는 프락시에서 시작되는데, 프락시는 Connection 헤더를 이해하지 못해서 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프락시에 전달합니다.
프락시는 keep-alive를 그대로 클라이언트에게 전달하고 서버가 커넥션 끊기를 기다립니다. 하지만 서버는 프락시가 커넥션을 유지하길 요청한 것으로 알고 있고 때문에 커넥션을 끊지 않습니다.
서버는 keep-alive 응답을 프락시에게 전달하고 프락시는 이를 다시 클라이언트에게 보냅니다.
응답을 받은 클라이언트는 서버와 커넥션을 유지하고 있다고 생각하지만 정작 프락시는 이를 알지 못합니다.
클라이언트가 다음 요청을 보내기 시작하면 커넥션이 유지되고 있는 프락시에 그 요청을 보냅니다.
프락시는 같은 커넥션상에서 다른 요청이 오는 경우는 예상하지 못하기 때문에 그 요청은 프락시로부터 무시되고 브라우저는 아무런 응답도 받지 못하고 로드 중이라는 표시만 나옵니다.

4.5.7 Proxy-Connection 살펴보기

Proxy-Connection은 클라이언트의 요청이 중개서버를 통해 이어지는 경우 모든 헤더를 무조건 전달하는 문제를 해결하기 위해 사용됩니다. 브라우저에서 일반적으로 전달하는 Connection 헤더 대신에 비표준인 Proxy-Connection 확장 헤더를 프락시에게 전달합니다. 프락시가 Proxy-Connection 헤더를 무조건 전달하더라도 웹 서버는 이를 무시하기 때문에 별문제가 되지 않습니다. 또한 영리한 프락시라면, 의미 없는 Proxy-Connection 헤더를 Connection 헤더로 바꿈으로써 원하던 효과를 얻게 됩니다.

4.5.8 HTTP/1.1의 지속 커넥션

HTTP/1.1 에서는 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 사용합니다. 이 목적은 keep-alive 커넥션과 같지만 더 잘 작동합니다. HTTP/1.1 에서 지속 커넥션은 기본으로 활성화되어 있습니다. 이는 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 명시해야 합니다.

4.6 파이프라인 커넥션

HTTP/1.1은 지속 커넥션을 통해 요청을 파이프라이닝할 수 있습니다. 여러 개의 요청은 응답이 도착하기 전까지 큐에 쌓입니다. 이는 대기 시간이 긴 네트워크 상황에서 네트워크상의 왕복으로 인한 시간을 줄여서 성능을 높여줍니다.

4.7 커넥션 끊기에 대한 미스터리

커넥션 관리에는 명확한 기준이 없습니다. 이 이슈는 수많은 개발자가 알고 있는 것보다 더 미묘하며, 그에 관한 기술 문서도 별로 없습니다.

4.7.1 ‘마음대로’ 커넥션 끊기

어떠한 HTTP 클라이언트, 서버, 혹은 프락시든 언제든지 TCP 전송 커넥션을 끊을 수 있습니다. 보통 커넥션은 메시지를 다 보낸 다음 끊지만, 에러가 있는 상황에서는 헤더의 중간이나 다른 엉뚱한 곳에서 끊길 수 있습니다.

4.7.2 Content-Length와 Truncation

각 HTTP 응답은 본문의 정확한 크기 값을 가지는 Content-Length 헤더를 가지고 있어야 합니다. 클라이언트나 프락시가 커넥션이 끊어졌다는 HTTP 응답을 받은 후, 실제 전달 된 엔터티의 길이와 Content-Length의 값이 일치하는지, 존재하는지를 확인해야 합니다.

4.7.3 커넥션 끊기의 허용, 재시도, 멱등성

커넥션은 에러가 없더라도 언제든 끊을 수 있습니다. 때문에 HTTP 애플리케이션은 예상치 못하게 커넥션이 끊어졌을 때 적절히 대응할 수 있는 준비가 되어야합니다. 클라이언트는 수행 중 전송 커넥션이 끊기면 재시도를 해도 되는 지 확인 한 후 재시도를 해야합니다. 이는 파이프라인 커넥션에서 좀 어렵습니다. 한 번 혹은 여러 번 실행됐는지에 상관없이 같은 결과를 반환한다면 이 트랜잭션은 멱등(idempotent)하다고 이해합니다. 클라이언트는 POST와 같이 멱등이 아닌 요청은 파이프라인을 통해 요청하면 안됩니다. 그렇지 않으면 전송 커넥션이 예상치 못하게 끊어져 버렸을 때, 알 수 없는 결과를 초래할 수 있습니다. 때문에 대부분의 브라우저는 캐시된 POST 요청 페이지를 다시 로드하려고 할 때, 요청을 다시 보내기를 원하는지 묻는 대화상자를 보여줍니다.

4.7.4 우아한 커넥션 끊기

전체 끊기와 절반 끊기

close()를 호출하면 TCP 커넥션의 입력 채널과 출력 채널의 커넥션은 모두 끊어집니다. 이를 ‘전체 끊기’라고 합니다. 입력 채널이나 출력 채널 중 하나를 개별적으로 끊으려면 shutdown()을 호출합니다. 이를 ‘절반 끊기’라고 합니다.

TCP 끊기와 리셋 에러

단순한 HTTP 애플리케이션은 전체 끊기만을 사용할 수 있습니다. 하지만 각기 다른 HTTP 클라이언트, 서버, 프락시와 통신할 때 기기들에 예상치 못한 쓰기 에러를 발생하는 것을 예방하기 위해 ‘절반 끊기’를 사용해야 합니다. 보통은 커넥션의 출력 채널을 끊는 것이 안전합니다. 만약 클라이언트에서 이미 끊긴 입력 채널에 데이터를 전송하면, 서버의 운영체제는 TCP ‘connection reset by peer’ 메시지를 클라이언트에게 보냅니다. 대부분 운영체제는 이를 심각한 에러로 취급하여 버퍼에 저장된, 아직 읽히지 않은 데이터를 모두 삭제합니다.

우아하게 커넥션 끊기

일반적으로 애플리케이션이 우아한 커넥션 끊기를 구현하는 것은 애플리케이션 자신의 출력 채널을 먼저 끊고 다른 쪽에 있는 기기의 출력 채널이 끊기는 것을 기다리는 겁입니다. 양쪽에서 더는 데이터를 전송하지 않을 것이라고 알려주면 커넥션은 리셋의 위험 없이 온전히 종료됩니다. 상대방이 절반 끊기를 구현한다는 보장이 없기 때문에 커넥션을 끊고자 하는 애플리케이션은 출력 채널에 절반 끊기를 하고 난 후에도 데이터나 스트림의 끝을 식별하기 위해 입력 채널에 대해 상태 검사를 주기적으로 해야합니다.