[HTTP 완벽가이드] 04. 커넥션 관리

TCP 커넥션

HTTP 통신은 패킷 교환 네트워크 프로토콜의 계층화된 집합인 TCP/IP를 통해 이뤄진다.

커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 주고 받은 메시지는 안전하게 전달된다.

 

브라우저에 http://www.joes-hardware.com:80/power-tools.html을 입력하면 아래와 같이 실행된다. 

웹 브라우저가 TCP 커넥션을 통해서 웹 서버에 요청을 보낸다.

 

1) 신뢰할 수 있는 데이터 전송 통로인 TCP

TCP는 HTTP에게 신뢰할만한 통신 방식을 제공한다.

TCP 커넥션 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확하게 전달된다.

 

2) TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송된다.

TCP는 IP 패킷이라 불리는 작은 조각을 통해 데이터를 전송한다.

HTTP가 메시지를 전송하고자 할 때, 현재 연결되어 있는 TCP 커넥션을 통해 메시지 데이터의 내용을 순서대로 보낸다.

TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷에 담아서 인터넷을 통해 데이터를 전달한다. 

각 세그먼트는 하나의 IP 주소에서 다른 IP 주소로 IP 패킷에 담겨 전달된다.

 

IP 패킷의 요소

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

 

 

3) TCP 커넥션 유지하기

TCP는 포트 번호를 통해 여러 개의 커넥션을 유지한다.

 

TCP 커넥션은 4가지 값으로 식별한다.

`<발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>` 값을 통해 유일한 커넥션을 생성한다. 

 

4) TCP 소켓프로그래밍

운영체제는 TCP 커넥션의 생성과 관련된 여러 기능을 제공한다.

소켓 API를 사용하면, TCP 종단 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다.

 

클라이언트와 서버가 TCP 소켓 인터페이스를 사용하여 상호작용하는 방법

 

TCP의 성능에 대한 고려

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

 

 

1) HTTP 트랜잭션 지연

 

HTTP 트랜잭션이 처리되는 과정

트랜잭션 처리 시간은 TCP 커넥션 설정, 요청, 응답에 비해 짧은 편이다. 

대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.

 

트랜잭션 지연의 원인은 여러가지가 있다.

1. 클라이언트는 URI에서 웹 서버의 IP 주소와 포트 번호를 알아내야 한다. 
   만약 최근에 해당 호스트에 방문한 적이 없으면, DNS를 통해 호스트명을 IP 주소로 변환한다.
2. 클라이언트는 TCP 커넥션 요청을 서버에게 보내고, 서버가 커넥션 허가 응답을 회신하기를 기다린다.
   커넥션 설정 시간은 새로운 TCP 커넥션에서 항상 발생한다.
3. 커넥션이 맺어지면 클라이언트는 HTTP 요청을 새로 생성된 TCP 파이프를 통해 전송한다.
   웹 서버는 데이터가 도착하는 대로 TCP 커넥션에서 요청 메시지를 읽고 처리한다.
4. 웹 서버가 HTTP 응답을 보낼 때도 시간이 소요된다.

 

2) 성능 관련 중요 요소

 

일반적인 TCP 관련 지연

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

 

3) TCP 커넥션 핸드셰이크 지연

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

작은 크기의 데이터 전송에 커넥션이 사용된다면 패킷 교환은 HTTP 성능을 크게 저하시킬 수 있다.

 

1. 클라이언트는 새로운 TCP 커넥션을 생성하기 위해 작은 TCP 패킷을 서버에게 보내고 패킷에는 'SYN' 플래그를 붙인다. 
   'SYN'은 커넥션 생성 요청이라는 뜻이다.
2. 서버가 커넥션을 받으면 몇 가지 커넥션 매개변수를 산출하고, 커넥션 요청이 받아들여졌음을 의미하는 'SYN'+'ACK' 플래그를 포함한 TCP 패킷을 클라이언트에게 보낸다.
3. 클라이언트는 커넥션이 잘 맺어졌음을 알리기 위해 다시 서버에게 확인 응답 신호를 보낸다.

크기가 작은 데이터의 경우 SYN, SYN +ACK 핸드셰이크로 인해 많은 지연이 발생하게 된다. 

 

크기가 작은 HTTP 트랜잭션은 많은 시간을 TCP를 구성하는데 쓰며, 이러한 TCP 구성으로 인한 지연을 제거하기 위해 이미 존재하는 커넥션을 재활용한다.

 

4) 확인 응답 지연

라우터는 과부하가 걸렸을 때, 패킷을 마음대로 파기할 수 있기 때문에 TCP는 성공적인 데이터 전송을 보장하기 위해 자체적인 확인 체계를 갖는다.

 

각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 갖고, 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환한다. 송신자가 특정 시간 내에 확인 응답 메시지를 받지 못한 경우 데이터를 다시 전송한다.

 

확인 응답은 크기가 작으므로, 같은 방향으로 송출되는 데이터 패킷에 확인응답을 편승시킨다. TCP는 송출 데이터 패킷과 확인응답을 하나로 묶어 네트워크를 효율적으로 사용한다. 확인응답이 같은 방향으로 가는 데이터 패킷에 편승되는 경우를 늘리기 위해, '확인응답 지연' 알고리즘을 구현한다. 

 

요청과 응답 2가지 형식으로만 이루어진 HTTP 동작 방식은 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킨다. 때문에, 오히려 확인응답 지연 알고리즘으로 인한 지연이 자주 발생한다.

확인 응답 지연 알고리즘이란?
송출할 확인응답을 특정 시간동안 버퍼에 저장해두고, 확인 응답을 편승시키기 위한 송출 데이터 패킷을 찾는다. 
만약 일정 시간 안에 송출 데이터 패킷을 찾지 못하면 확인응답은 별도 패킷을 만들어 전송된다.

 

5) TCP 느린 시작(slow start)

TCP 커넥션은 시간이 지나면서 자체적으로 튜닝되어 속도 제한을 높여 나간다. 이렇게 조율하는 것을 TCP 느린 시작이라 부르며, 이는 인터넷의 급작스러운 부하와 혼잡을 방지하는데 쓰인다.

 

이 혼잡제어 기능 때문에 새로운 커넥션은 이미 어느정도 데이터를 주고 받은 "튜닝"된 커넥션보다 느리다. "튜닝"된 커넥션은 더 빠르므로 HTTP에는 이미 존재하는 커넥션을 재사용하는 기능이 있다.

 

6) 네이글 알고리즘과 TCP_NODELAY

네이글 알고리즘은 네트워크의 효율을 위해서 패킷을 전소하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합친다.

네이글 알고리즘은 세그먼트의 최대 크기가 되지 않으면 전송을 하지 않는다. 다만 모든 패킷이 확인 응답을 받았을 경우, 최대 크기보다 작은 패킷의 전송을 허락한다. 다른 패킷이 아직 전송 중이면 데이터는 버퍼에 저장된다. 

 

전송되고 나서 확인응답을 기다리던 패킷이 확인응답을 받았거나 전송하기 충분한 만큼의 패킷이 쌓였을 때 버퍼에 저장되어 있던 데이터가 전송된다.

 

네이글 알고리즘으로 인한 문제점

1. 크기가 작은 HTTP 메시지는 패킷을 채우지 못하므로, 추가적인 데이터를 기다리며 지연된다.
2. 확인응답 알고리즘과 함께 쓰일 경우 성능이 더 떨어지게 된다.
   네이글 알고리즘: 확인 응답이 도착할 때까지 데이터 전송을 멈춘다.
   확인응답 지연 알고리즘: 확인응답을 100~200ms 지연시킨다.

HTTP 애플리케이션은 성능 향상을 위해 HTTP 스택에 TCP_NODELAY 파라미터를 통해 네이글 알고리즘을 비활성화하기도 한다.

 

7) TIME_WAIT의 누적과 포트 고갈

TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어 영역에 기록해 둔다. 이를 TIME_WAIT 상태라고 부르며, 이 정보는 같은 주소와 포트번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안 생성되지 않게 하기 위한 것이다. 보통 세그먼트의 최대 생명주기(TTL)에 2배 정도의 시간만 유지된다. 이는 이전(오래된) 커넥션과 관련된 패킷이 그 커넥션과 같은 주소와 포트 번호를 가지는 새로운 커넥션에 삽입되는 문제를 방지한다. 

 

오래된 커넥션과 관련된 패킷이 같은 주소와 포트번호를 가진 새로운 커넥션에 들어오면 어떤 문제가 발생할까?

TCP 연결은 순차적인 데이터 전송을 기반으로 동작한다. 만약 이전 연결에서 보낸 오래된 패킷이 새로운 연결로 들어오면, 데이터의 순서가 뒤섞이거나 잘못된 데이터가 수신될 수 있으며 이는 데이터 무결성과 통신의 신뢰성을 깨뜨리게 된다.

 

요즘은 빠른 라우터들 덕분에, 커넥션이 닫힌 후 중복되는 패킷이 생기는 경우는 거의 없어졌다.

 

HTTP 커넥션 관리

 

1) Connection 헤더

HTTP는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락한다.

HTTP 메시지는 클라이언트에서 서버까지 중개 서버를 거치면서 전달된다.

 

HTTP Connection 헤더 필드는 커넥션 토큰을 쉼표로 구분하여 가지고 있으며, 그 값들은 다른 커넥션에 전달되지 않는다. 

커넥션 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳에 전달하는 시점에 삭제되어야 하며, 홉별 헤더 명을 기술한다.

Connection 헤더에는 3가지 종류의 토큰이 전달될 수 있다.

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

 

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

 

커넥션 관리가 이뤄지지 않으면 TCP 성능이 매우 안좋아질 수 있다. 3개의 이미지가 있는 웹페이지가 있다고 가정해보면, 4개의 HTTP 트랜잭션이 필요하다 (1개의 HTML과 3개의 이미지를 위한 트랜잭션) 각 트랜잭션이 새로운 커넥션을 필요로 한다면 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생한다.

 

 

병렬 커넥션

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

 

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

단일 커넥션의 대역폭 제한과 커넥션이 동작하고 있지 않는 시간을 활용하면 객체가 여러 개 있는 웹 페이지를 더 빠르게 다운받을 수 있다.

하나의 커넥션으로 객체들을 로드할 때의 대역폭 제한과 대기 시간을 줄일 수 있다면 더 빠르게 로드할 수 있다.

HTML 페이지를 먼저 내려받고 남은 3 개의 트랜잭션이 각각 별도의 커넥션에서 동시에 처리된다. 이미지들을 병렬로 내려받아 커넥션 지연이 겹쳐짐으로써 총 지연시간이 줄어든다.

 

2) 병렬 커넥션이 항상 더 빠르지는 않다.

병렬 커넥션이 일반적으로 더 빠르지만 항상 그렇지는 않다. 

클라이언트의 네트워크 대역폭이 좁을 때는 대부분 시간을 데이터를 전송하는데만 쓸 것이다. 여러 개의 객체를 병렬로 내려받는 경우, 제한받는 경우, 제한된 대역폭 내에서 각 객체를 전송받는 것은 느리므로 성능상 장점은 거의 없다.

많은 커넥션은 메모리를 소모하고, 서버의 성능에 문제가 발생할 수 있다. 

 

브라우저는 실제로 병렬 커넥션을 사용하긴 하지만 적은 수의 병렬 커넥션만을 허용한다. 서버는 특정 클라이언트로부터 과도한 수의 커넥션의 맺어졌을 경우, 그것을 임의로 끊어버릴 수 있다.

 

3) 병렬 커넥션은 더 빠르게 '느껴질 수' 있다.

병럴 커넥션이 페이지를 항상 더 빠르게 로드하지 않지만, 여러개의 객체가 동시에 보이면서 내려받고 있는 상황을 볼 수 있으므로, 사용자는 더 빠르게 다운 받는 것처럼 느낄 수 있다. 저해상도에서 해상도를 높여가는 형태의 이미지를 사용하여 효과를 극대화할 수 있다.

지속 커넥션

웹 클라이언트는 같은 사이트에 여러 개의 커넥션을 맺는다. 이러한 속성을 사이트 지역성이라고 부른다. 

따라서 HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있으며, 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 한다.

 

해당 서버에 이미 맺어져 있는 지속 커넥션을 재사용함으로써, 커넥션을 맺기 위해 준비작업을 하는데 걸리는 시간을 절약할 수 있다. 

TCP Slow Start로 인한 지연을 피함으로써 더 빠르게 데이터를 전송할 수 있다.

 

1) 지속 커넥션 vs 병렬 커넥션

병렬 커넥션은 여러 객체가 있는 페이지를 빠르게 전송하지만, 몇 가지 단점이 존재한다.

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

지속 커넥션은 병렬 커넥션에 비해 몇 가지 장점이 존재한다.

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

다만, 지속 커넥션을 잘못 관리할 경우, 연결된 상태로 있는 커넥션이 쌓이게 되므로 불필요한 소모를 발생시킬 수 있다.

지속 커넥션은 병렬 커넥션과 함께 사용할 때, 가장 효과적이다. 오늘 날 애플리케이션은 적은 수의 병렬 커넥션만을 맺고, 그것을 유지한다.

 

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

 

 

2) HTTP/1.0+의 Keep-Alive 커넥션

같은 4개의 HTTP 트랜잭션에 대해, 연속적으로 4개의 커넥션을 생성하여 처리하는 방식과 하나의 지속 커넥션으로만 처리하는 방식을 비교하였다. 커넥션을 맺고 끊는데 필요한 작업이 없어서 시간이 단축되었다.

 

3) Keep-Alive 동작

keep-alive는 HTTP/1.1 명세에서 빠졌지만 오랫동안 사용되고 있으므로 HTTP 애플리케이션은 이것을 처리할 수 있게 개발해야 한다.

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

응답에 Connection:Kepp-Alive 헤더가 없으면 클라이언트는 서버가 keep-alive를 지원하지 않으며, 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라고 추정한다.

 

4) Keep-Alive 옵션

Keep-Alive 헤더는 커넥션을 유지하기를 바라는 요청일 뿐이다. 클라이언트나 서버가 keep-alive 요청을 받았다고 해서 무조건 따를 필요는 없다. 언제든지 현재의 keep-alive 커넥션을 끊을 수 있으며, keep-alive 커넥션에서 처리되는 트랜잭션의 수를 제한할 수 있다.

• timeout 파라미터: 커넥션이 얼마동안 유지될 것인지를 의미한다.
• max 파라미터: 커넥션이 몇 개의 트랜잭션을 처리할 때까지 유지될 것인지는 의미한다.

다만 이러한 파라미터는 희망사항일 뿐, 이대로 동작한다는 보장은 없다.

 

Keep-Alive 헤더 사용은 선택 사항이지만 Connection:Keep-Alive 헤더가 있을 때만 사용할 수 있다. 

아래의 예시는 서버가 5개의 추가 트랜잭션이 처리될 동안 커넥션을 유지하거나 2분 동안 커넥션을 유지하라는 내용의 Keep-Alive 응답 헤더다.

Connection: Keep-Alive
Keep-Alive: max=5, timeout=120

 

5) Keep-Alive 커넥션 제한과 규칙

keep-alive 커넥션에 대한 몇 가지 제한과 사용 방법들

• keep-alive는 HTTP/1.0에서 기본으로 사용되지는 않는다.
  클라이언트는 keep-alive 커넥션을 사용하기 위해 Connection:Keep-Alive 요청 헤더를 보내야 한다.
• 커넥션을 계속 유지하려면 모든 메시지에 Connection: Keep-Alive 헤더를 포함해 보내야 한다.
  만약 요청을 Connection: Keep-Alive 헤더를 보내지 않으면 서버는 요청을 처리한 후 커넥션을 끊는다.
• 커넥션이 끊어지기 전, 엔티티 본문의 길이를 알 수 있어야 커넥션을 유지할 수 있다.
  즉, 엔티티 본문이 정확한 Content-Length 값과 함께 멀티파트 미디어 형식을 가지거나 청크 전송 인코딩으로 인코드 되어야 한다.
• 프락시와 게이트웨이는 Connection 헤더의 규칙을 철저히 지켜야 한다.프락시와 게이트웨이는 메시지를 전달하거나 캐시에 넣기 전에 Connection 헤더에 명시된 모든 헤더 필드와 Connection 헤더를 제거해야 한다.
• 정석대로라면 keep-alive 커넥션은 Connection 헤더를 인식하지 못하는 프락시 서버와는 맺어지면 안되지만 이는 쉽지 않다.

6) Keep-Alive와 멍청한 프락시

 

Connection 헤더의 무조건 전달

프락시는 Connection 헤더를 이해하지 못해 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프락시에 전달한다. 

많은 프락시들이 Connection 헤더에 대한 처리 없이 요청을 그대로 전달한다. 웹 클라이언트가 무조건 전달을 하는 멍청한 프락시를 거쳐 웹 서버에 메시지를 전송한다고 가정해보자

 

1. 웹 클라이언트는 프락시에 Connection: Keep-Alive 헤더와 함께 메시지를 보내고, 커넥션을 유지하기를 요청한다. 클라이언트는 커넥션을 유지하자는 요청이 받아들여졌는지 확인하기 위해 응답을 기다린다.
2. 멍청한 프락시는 요청받은 HTTP의 Connection 헤더를 이해하지 못하고, 확장 헤더로만 인식한다. 
   프락시는 keep-alive가 무엇인지 모르므로, 다음 서버에 메시지를 그대로 전달한다. 그러나 Connection 헤더는 홉별 헤더이라 문제가 발생할 수 있게 된다.
3. 프락시로부터 전달된 HTTP 요청이 서버에 도착한다. 웹서버는 프락시가 커넥션을 유지하자고 잘못 판단하게 된다.
   웹 서버는 문제될 것이 없으므로 프락시와 커넥션을 유지하는 것에 동의하고, Connection: Keep-Alive 헤더를 포함하여 응답하지만 프락시는 이 옵션을 전혀 이해하지 못한다.
4. 멍청한 프락시는 Connection: Keep-Alive 헤더를 포함하고 있는 응답 메시지를 클라이언트에게 전달한다.
   클라이언트는 이 헤더를 통해 프락시가 커넥션을 유지하는 것에 동의했다고 추정한다. 
   이 시점에 클라이언트와 서버는 커넥션을 유지하고 있다고 생각하지만 프락시는 keep-alive를 전혀 이해하지 못한다.
5. 프락시는 keep-alive를 모르지만 받았던 모든 데이터를 그대로 클라이언트에게 전달하고나서 서버가 커넥션을 끊기를 기다린다.
   하지만 서버는 프락시가 커넥션을 유지하기를 요청한 것으로 알고 있어서 커넥션을 끊지 않는다. 프락시는 커넥션이 끊어지기 전까지는 커넥션이 끊어지기를 기다리게 된다.
6. 클라이언트가 응답 메시지를 받으면 다음 요청을 보내기 시작하는데 커넥션이 유지되고 있는 프락시에 요청을 본낸다. 
   프락시는 같은 커넥션 상에서 다른 요청이 오는 경우는 예상하지 못하므로 그 요청을 프락시로부터 무시되고 브라우저는 아무런 응답없이 대기를 한다.
7. 잘못된 통신으로 인해 브라우저는 자신이나 서버가 타임아웃이 나서 커넥션이 끊길 때까지 기다린다.

프락시와 홉별 헤더

잘못된 통신을 피하려면 프락시는 Connection 헤더와 Connection 헤더에 명시된 헤더들은 절대 전달해서는 안된다. 

프락시가 Connection: Keep-Alive 헤더를 받으면 Connection 헤더 뿐만 아니라 Keep-Alive란 이름의 헤더, 심지어는 홉별 헤더도 전달하면 안된다.

 

7) Proxy-Connection 살펴보기

넷스케이프의 브라우저 및 프락시 개발자들은 모든 웹 애플리케이션이 HTTP 최신 버전을 지원하지 않아도 모든 헤더들을 무조건 전달하는 문제를 해결할 수 있는 차선책을 제시하였으며 이는 Proxy-Connection 헤더이다.

Proxy-Connection은 프락시를 별도로 설정할 수 있는 현대의 브라우저들에서 지원하고 있으며, 많은 프락시들도 이를 인식한다. 

영리한 프락시는 의미없는 Proxy-Connection 헤더를 Connection 헤더로 변경하여 원하는 효과를 얻게 될 수 있다.

• a~b는 무조건 전달로 인해 Proxy-Connection 헤더가 웹 서버에 전달되더라도, 서버는 이를 인식하지 못해 keep-alive 커넥션이 맺어지지 않는다는 것을 보여준다.
• e~h에서 영리한 프락시는 Proxy-Connection 헤더가 keep-alive를 요청하는 것임을 인식하여, keep-alive 커넥션을 맺기 위해 자체적으로 Connection: Keep-Alive 헤더를 웹 서버에 전송한다.

하지만 이 방식은 클라이언트와 서버 사이에 한 개의 프락시만 있는 경우에서만 존재한다. 즉, Proxy가 많은 구조에서는 Proxy-Connection을 사용하더라도 문제를 해결할 수 없다.

 

8) HTTP/1.1의 지속 커넥션

HTTP/1.1에서는 keep-alive 커넥션을 지원하지 않는 대신, 지속 커넥션을 지원한다. 

또한, HTTP/1.1에서 별도 설정을 하지 않는 한, 모든 커넥션을 지속 커넥션으로 취급한다. HTTP/1.1 애플리케이션은 트랜잭션이 끝난 다음, 커넥션을 끊으려면 Connection: close 헤더를 명시해야 한다.

 

HTTP/1.1 클라이언트는 응답에 Connection: close 헤더가 없으면 응답 후에도 HTTP/1.1 커넥션을 계속 유지하자는 것으로 추정한다. 하지만 클라이언트와 서버는 언제든지 커넥션을 끊을 수 있다. 즉, Connection: close를 보내지 않는 것이 서버가 커넥션을 계속 유지한다는 것은 아니다. 서버는 상황에 따라(예: 자원 관리나 연결 시간 초과 등) 언제든지 커넥션을 끊을 수 있다. 

 

9) 지속 커넥션의 제한과 규칙

지속 커넥션에 대한 몇 가지 제한과 사용 방법

• 클라이언트가 요청에 Connection: close 헤더를 포함해 보냈으면, 클라이언트는 그 커넥션으로 추가적으로 요청을 보낼 수 없다.
• 클라이언트가 해당 커넥션으로 추가적인 요청을 보내지 않을 것이라면 마지막 요청에 Connection: close 헤더를 보내야 한다.
• 커넥션에 있는 모든 메시지가 자신의 길이 정보를 정확히 가지고 있을 때만 커넥션을 지속시킬 수 있다. 
  예시) 엔티티 본문은 정확한 Content-Length 값을 갖거나 청크 전송 인코딩으로 인코드 되어 있어야 한다.
• 프락시는 클라이언트와 서버 각각에 대해 별도의 지속 커넥션을 맺고 관리해야 한다.
• 프락시 서버는 클라이언트가 커넥션 관련 기능에 대한 클라이언트의 지원 범위를 알고 있지 않은 한 지속 커넥션을 맺으면 안된다.

파이프라인 커넥션

HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝할 수 있다. 이는 keep-alive 커넥션의 성능을 더 높여준다.

여러 개의 요청은 응답이 도착하기 전까지 큐에 쌓인다. 첫 번째 요청이 네트워크를 통해 서버에 전달되면, 두 번째와 세 번째 요청이 전달될 수 있다. 이는 대기 시간이 긴 네트워크 상황에서 네트워크 상의 왕복으로 인한 시간을 줄여서 성능을 높여준다.

지속 커넥션은 TCP 커넥션 지연을 제거할 수 있고, 파이프라인을 통한 요청이 전송 대기 시간을 단축시킬 수 있다.

 

파이프라인에는 여러 가지 제약사항이 있다.

• HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안된다.
• HTTP 응답은 요청 순서와 같게 와야 한다.
  HTTP 메시지는 순번이 매겨져 있지 않아서 응답이 순서없이 오면 정렬시킬 방법이 없다.
• HTTP 클라이언트는 커넥션이 언제 끊어지더라도, 완료되지 않은 요청이 파이프라인에 있으면 언제든 다시 요청을 보낼 준비가 되어 있어야 한다.
• HTTP 클라이언트는 POST 요청처럼 반복해서 보냈을 때 문제가 생길 요청은 파이프라인을 통해 보내서는 안된다.
  비멱등 요청을 재차 보내면 문제가 생길 수 있으므로, 문제가 있는 상황에서 그런 위험한 메서드로 요청을 보내서 안된다.