『HTTP 완벽 가이드』 교재와 다른 레퍼런스를 참고하여 작성하였습니다.

커넥션 관리

TCP 커넥션

전 세계 모든 HTTP 통신은, 패킷 교환 네트워크 프로토콜들의 계층화된 집합인 TCP/IP를 통해 이루어집니다. 세계 어디서든 클라이언트 애플리케이션은 서버 애플리케이션으로 TCP/IP 커넥션을 맺을 수 있습니다. 일단 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 주고받는 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달됩니다.

웹브라우저 TCP 커넥션 

(1) 브라우저가 호스트 명을 추출한다.
(2) 브라우저가 이 호스트 명에 대한 IP 주소를 찾는다.
(3) 브라우저가 포트 번호를 얻는다.
(4) 브라우저가 IP 주소의 포트 번호로 TCP 커넥션을 생성한다.
(5) 브라우저가 서버로 HTTP GET 요청 메시지를 보낸다.
(6) 브라우저가 서버에서 온 HTTP 응답 메시지를 읽는다.
(7) 브라우저가 커넥션을 끊는다.

TCP 커넥션은 인터넷을 안정적으로 연결해줍니다. TCP는 HTTP에게 신뢰할 만한 통신 방식을 제공합니다. TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달됩니다.

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

• IP 패킷 헤더(보통 20바이트)
• TCP 세그먼트 헤더(보통 20바이트)
• TCP 데이터 조각(0 혹은 그 이상의 바이트)

IP 헤더는 발신지의 목적지 IP주소, 크기, 기타 플래그를 가집니다. TCP 세그먼트 헤더는 TCP 포트 번호, TCP 제어 플래그, 그리고 데이터의 순서와 무결성을 검사하기 위해 사용되는 숫자 값을 포함합니다.

IP 패킷은 TCP 데이터 스트림의 덩어리를 운반하는 TCP 세그먼트를 실어 나릅니다.

컴퓨터는 항상 TCP 커넥션을 여러 개 가지고 있습니다. TCP는 포트 번호를 통해서 이런 여러 개의 커넥션을 유지합니다. IP 주소는 해당 컴퓨터에 연결되고 포트 번호는 해당 애플리케이션으로 연결됩니다. TCP 커넥션은 네 가지 값으로 식별합니다.
<발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>
이 네 가지 값으로 유일한 커넥션을 생성합니다. 서로 다른 두 개의 TCP 커넥션은 네 가지 주소 구성요소의 값이 모두 같을 수 없습니다.

어떤 커넥션들은 같은 목적지 포트 번호를 가리킬 수 있습니다. 하지만 네 가지 커넥션 구성요소를 모두 똑같이 가리키고 있는 커넥션은 있을 수 없습니다.

TCP의 성능에 대한 고려

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

HTTP 트랜잭션 지연

트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메시지를 보내는 것에 비하면 상당히 짧습니다. 클라이언트나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생합니다.

1. 클라이언트는 URI에서 웹 서버의 IP 주소와 포트 번호를 알아내야 합니다. 만약 URI에 기술되어 있는 호스트에 방문한 적이 최근에 없으면, DNS 이름 분석 인프라를 사용하여 URI에 있는 호스트 명을 IP 주소로 변환하는데 수십 초의 시간이 걸릴 것입니다.
2. 클라이언트는 TCP 커넥션 요청을 서버에게 보내고 서버가 커넥션 허가 응답을 회신하기를 기다립니다. 커넥션 설정 시간은 새로운 TCP 커넥션에서 항상 발생합니다. 이는 보통 1~2초의 시간이 소요되지만, 수백 개의 HTTP 트랜잭션이 만들어지면 소요시간이 크게 증가될 것입니다.
3. 커넥션이 맺어지면 클라이언트는 HTTP 요청을 새로 생성된 TCP 파이프를 통해 전송합니다. 웹 서버는 데이터가 도착하는 대로 TCP 커넥션에서 요청 메시지를 읽고 처리합니다. 요청 메시지가 인터넷을 통해 전달되고 서버에 의해서 처리되는 데까지는 시간이 소요됩니다.
4. 웹 서버가 HTTP 응답을 보내는 것 역시 시간이 소요됩니다.

이런 TCP 네트워크 지연은 하드웨어의 성능, 네트워크와 서버의 전송 속도, 요청과 응답 메시지의 크기, 클라이언트와 서버 간의 거리에 다라 크게 달라집니다. 또한 TCP 프로토콜의 기술적인 복잡성도 지연에 큰 영향을 끼칩니다.

성능 관련 중요 요소

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

TCP 커넥션 핸드셰이크 지연

어떤 데이터를 전송하든 새로운 TCP 커넥션을 열 때면, TCP 소프트웨어는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환합니다. 작은 크기의 데이터 전송에 커넥션이 사용된다면 이런 패킷 교환은 HTTP 성능을 크게 저하시킬 수 있습니다.

TCP 커넥션 핸드셰이크 순서

1. 클라이언트는 새로운 TCP 커넥션을 생성하기 위해 작은 TCP 패킷을 서버에게 보냅니다. 그 패킷은 'SYN'라는 특별한 플래그를 가지는데, 이 요청이 커넥션 생성 요청이라는 뜻입니다.
2. 서버가 그 커넥션을 받으면 몇 가지 커넥션 매개변수를 산출하고, 커넥션 요청이 받아들여졌음을 의미하는 'SYN'과 'ACK' 플래그를 포함한 TCP 패킷을 클라이언트에게 보냅니다.
3. 마지막으로 클라이언트는 커넥션이 잘 맺어졌음을 알리기 위해서 서버에게 다시 확인응답 신호를 보냅니다. 오늘날의 TCP는 클라이언트가 이 확인응답 패킷과 함께 데이터를 보낼 수 있습니다.

HTTP 프로그래머는 이 패킷들을 보지 못하고 새로운 TCP 커넥션이 생성될 때 발생하는 지연만을 볼 수 있습니다.
HTTP 트랜잭션이 아주 큰 데이터를 주고받지 않는 평범한 경우에는, SYN/SYN+ACK 핸드셰이크가 눈에 띄는 지연을 발생시킵니다. TCP의 ACK 패킷은 HTTP 요청 메시지 전체를 전달할 수 있을 만큼 큰 경우가 많고, 많은 HTTP 서버 응답 메시지는 하나의 IP 패킷에도 담길 수 있습니다.
결국, 크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는 데 씁니다.

확인응답 지연

인터넷 자체가 패킷 전송을 완벽히 보장하지는 않기 때문에, TCP는 성공적인 데이터 전송을 보장하기 위해서 자체적인 확인 체계를 가집니다.
각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가집니다. 각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환합니다. 만약 송신자가 특정 시간 안에 확인응답 메시지를 받지 못하면 패킷이 파기되었거나 오류가 있는 것으로 판단하고 데이터를 다시 전송합니다.

확인응답은 그 크기가 작기 때문에, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답을 '편승(piggyback)' 시킵니다.(네트워크를 좀 더 효율적으로 사용) 송출할 확인응답을 특정 시간 동안 버퍼에 저장해 두고, 확인응답을 편승시키기 위한 송출 데이터 패킷을 찾습니다. 만약 일정 시간 안에 송출 데이터 패킷을 찾지 못하면 확인응답은 별도 패킷을 만들어 전송합니다(확인응답 지연 알고리즘).

요청과 응답 두 가지 형식으로만 이루어지는 HTTP 동작 방식에서 막상 편승할 패킷을 찾으려고 하면 해당 방향으로 송출될 패킷이 많지 않기 때문에, 확인응답 지연 알고리즘으로 인한 지연이 자주 발생합니다.

TCP 느린 시작(slow start)

TCP의 데이터 전송 속도는 TCP 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라질 수 있습니다. TCP 커넥션은 시간이 지나면서 자체적으로 '튜닝'되어서, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나갑니다. 이렇게 조율하는 것을 TCP 느린 시작이라고 부르며 인터넷의 급작스러운 부하와 혼잡을 방지하는 데 쓰입니다.

What is TCP Slow Start?
"... 느린 시작은 네트워크를 통해 전송되는 데이터의 양을 조절하여 네트워크가 혼잡해지는 것을 방지합니다. 각 패킷으로 전송할 수 있는 데이터의 양을 정의하여 발신자와 수신자 간의 연결을 협상하고 네트워크 용량에 도달할 때까지 데이터 양을 천천히 늘립니다."

혼잡제어 기능 때문에, 새로운 커넥션은 이미 어느 정도 데이터를 주고받은 '튜닝'된 커넥션보다 느립니다.

네이글(Nagle) 알고리즘과 TCP_NODELAY

네이글 알고리즘은 네트워크 효율을 위해서, 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합칩니다. 세그먼트가 최대 크기가 되지 않으면 전송을 하지 않고 다만, 다른 모든 패킷이 확인응답을 받았을 경우에는 최대 크기보다 작은 패킷의 전송을 허락합니다.
네이글 알고리즘은 HTTP 성능 관련해 여러 문제를 발생시킵니다.

• 크기가 작은 HTTP 메시지는 패킷을 채우지 못하기 때문에, 앞으로 생길지 생기지 않을지 모르는 추가적인 데이터를 기다리며 지연될 것입니다.
• 네이글 알고리즘은 확인응답 지연과 함께 쓰일 경우 확인응답이 도착할 때까지 데이터 전송을 멈추고 있는 반면, 확인응답 지연 알고리즘은 확인응답을 100~200밀리초 지연시킵니다.

TIME_WAIT의 누적과 포트 고갈

TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영역에 기록해 놓습니다. 이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안에는 생성되지 않게 하기 위한 것입니다.

HTTP 커넥션 관리

Connection 헤더

HTT는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락합니다. HTTP 메시지는 클라이언트에서 서버까지 중개 서버들을 하나하나 거치면서 전달됩니다.
간혹 두 개의 인접한 HTTP 애플리케이션이 현재 맺고 있는 커넥션에만 적용될 옵션을 지정해야 할 때가 있습니다. Connection 헤더는 전송자가 특정 커넥션에만 해당되는 옵션을 지정하게 해줍니다. Connection 헤더에는 홉별(hop-by-hop) 헤더 명을 기술하는데, 이것을 '헤더 보호하기'라고 합니다. Connection 헤더에 명시된 헤더들이 전달되는 것을 방지하기 때문입니다.

홉 (네트워크)
홉(hop)은 컴퓨터 네트워크에서 출발지와 목적지 사이에 위치한 경로의 한 부분이다. 데이터 패킷은 브리지, 라우터, 게이트웨이를 거치면서 출발지에서 목적지로 경유한다. 패킷이 다음 네트워크 장비로 이동할 때마다 홉이 하나 발생한다.
https://ko.wikipedia.org/wiki/%ED%99%89_(%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)

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

커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 안 좋아질 수 있습니다. 각 트랜잭션이 새로운 커넥션을 피룡로 한다면, 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생할 것입니다. 순차적인 처리로 인한 지연에는 물리적인 지연뿐 아니라, 심리적인 지연도 있습니다. 사용자는 여러 개의 이미지가 동시에 로드되는 것을 더 좋아합니다.

순차적으로 로드하는 방식의 또 하나의 단점은, 특정 브라우저의 경우 객체를 화면에 배치하려면 객체의 크기를 알아야 하기 때문에, 모든 객체를 내려받기 전까지는 텅 빈 화면을 보여준다는 것입니다.

병렬 커넥션

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

병렬 커넥션은 페이지를 더 빠르게 내려받습니다.
하나의 커넥션으로 객체들을 로드할 때의 대역폭 제한과 대기 시간을 줄일 수 있다면 더 빠르게 로드할 수 있을 것입니다. 각 커넥션의 지연 시간을 겹치게 하면 총 지연 시간을 줄일 수 있고, 클라이언트의 인터넷 대역폭을 한 개의 커넥션이 다 써버리는 것이 아니라면 나머지 객체를 내려받는 데에 남은 대역폭을 사용할 수 있습니다.

병렬 커넥션이 항상 더 빠르지는 않다.
클라이언트의 네트워크 대역폭이 좁을 때는 대부분 시간을 데이터를 전송하는 데만 쓸 것입니다. 이 제한된 대역폭 내에서 각 객체를 전송받는 것은 느리기 때문에 성능상의 장점은 거의 없어집니다.
또한 다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킵니다. 백 명의 가상 사용자가 각각 100개의 커넥션을 맺고 있다면, 서버는 총 10,000개의 커넥션을 떠안게 되는 것이므로 이는 서버의 성능을 크게 떨어트립니다.

병렬 커넥션은 더 빠르게 '느껴질 수' 있습니다.
병렬 커넥션이 실제로 페이지를 더 빠르게 내려받는 것은 아니지만, 화면에 여러 개의 객체가 동시에 보이면서 내려받고 있는 상황을 볼 수 있기 때문에 사용자는 더 빠르게 내려받고 있는 것처럼 느낄 수 있습니다.

지속 커넥션

웹 클라이언트는 보통 같은 사이트에 여러 개의 커넥션을 맺습니다. 서버에 HTTP 요청을 하기 시작한 애플리케이션은 웹페이지 내의 이미지 등을 가져오기 위해서 그 서버에 또 요청하게 될 것입니다. 이 속성을 사이트 지역성(site locality)라 부릅니다.
처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 부릅니다. 비지속 커넥션은 각 처리가 끝날 때마다 커넥션을 끊지만, 지속 커넥션은 클라이언트나 서버가 커넥션을 끊기 전까지는 트랜잭션 간에도 커넥션을 유지합니다.
해당 서버에 이미 맺어져 있는 지속 커넥션을 재사용함으로써, 커넥션을 맺기 위한 준비작업에 따르는 시간을 절약할 수 있습니다.

지속 커넥션 vs 병렬 커넥션

병렬 커넥션의 단점

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

지속 커넥션의 병렬 커넥션에 비교한 장점

• 커넥션을 맺기 위한 사전작업과 지연 축소
• 튜닝된 커넥션을 유지하며, 커넥션의 수 축소

하지만 지속 커넥션을 잘못 관리할 경우, 계속 연결된 상태로 있는 수많은 커넥션이 쌓이게 되어 로컬의 리소스 그리고 원격의 클라이언트와 서버의 리소스에 불필요한 소모를 발생시킵니다.
지속 커넥션은 병렬 커넥션과 함께 사용될 때에 가장 효과적입니다. 오늘날 많은 웹 애플리케이션은 적은 수의 병렬 커넥션만을 맺고 그것을 유지하기 때문입니다.

HTTP/1.0+의 Keep-Alive 커넥션

keep-alive 커넥션의 성능상 장점으로 아래와 같이 커넥션을 맺고 끊는 데 필요한 작업이 없어서 시간이 단축된 것을 볼 수 있습니다.

Keep-Alive 동작

keep-alive는 사용하지 않기로 결정되어 HTTP/1.1 명세에서 빠졌습니다. 하지만 아직도 브라우저와 서버 간에 keep-alive 핸드셰이크가 널리 사용되고 있기 때문에, HTTP 애플리케이션은 그것을 처리할 수 있게 개발해야 합니다.
HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection:Keep-Alive 헤더를 포함시킵니다. 이 요청을 받은 서버는 그다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답합니다.

Keep-Alive 옵션

Keep-alive 헤더는 커넥션을 유지하기를 바라는 요청일 뿐입니다. 언제든지 현재의 keep-alive 커넥션을 끊을 수 있으며 keep-alive 커넥션에서 처리되는 트랜잭션의 수를 제한할 수도 있습니다.
keep-alive의 동작은 Keep-Alive 헤더의 쉼표로 구분된 옵션들로 제어할 수 있습니다.

• timeout 파라미터: Keep-Alive 응답 헤더를 통해 보냅니다. 이는 커넥션이 얼마간 유지될 것인지를 의미하지만 이대로 동작한다는 보장은 없습니다.
• max 파라미터: Keep-Alive 응답 헤더를 통해 보냅니다. 커넥션이 몇 개의 HTTP 트랜잭션을 처리할 때까지 유지될 것인지를 의미하지만 이대로 동작한다는 보장은 없습니다.
• Keep-Alive 헤더: 진단이나 디버깅을 주목적으로 하는, 처리되지는 않은 임의의 속성들을 지원하기도 합니다. 이름[=값]

Keep-Alive 헤더 사용은 선택 사항이지만, Connection: 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 헤더를 인식하지 못하는 프락시 서버와는 맺어지면 안됩니다.
• 기술적으로 HTTP/1.0을 따르는 기기로부터 받은 모든 Connection 헤더 필드는 무시해야 합니다.
• 클라이언트는, 응답 전체를 모두 받기 전에 커넥션이 끊어졌을 경우, 별다른 문제가 없으면 요청을 다시 보낼 수 있게 준비되어 있어야 합니다.

Keep-Alive와 멍청한(dumb) 프락시

웹 ㅍ클라이언트의 요청에 Connection: Keep-Alive 헤더가 있으면, 클라이언트가 현재 연결하고 있는 TCP 커넥션을 끊지 않고 계속 유지하려는 것입니다. 서버가 keep-alive를 지원한다면 Connection: Keep-Alive를 응답에 포함할 것이고, 지원하지 않으면 포함하지 않을 것입니다.

Connection 헤더의 무조건 전달
특히 문제는 프락시에서 시작되는데, 프락시는 Connection 헤더를 이해하지 못해서 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프락시에 전달합니다. 오래되고 단순한 수많은 프락시들이 Connection 헤더에 대한 처리 없이 요청을 그대로 전달합니다.

프락시와 홉별 헤더
프락시는 Connection 헤더와 Connection 헤더에 명시된 헤더들은 절대 전달하면 안 됩니다. 따라서 프락시가 Connection: Keep-Alive 헤더를 받으면 Connection 헤더뿐만 아니라 Keep-Alive란 이름의 헤더도 전달하면 안됩니다.
또한, Connection 헤더의 값으로 명시되지 않는, Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade와 같은 홉별 헤더들 역시 전달하거나 캐시하면 안 됩니다.

Proxy-Connection 살펴보기

홉별 헤더들은 한 개의 특정 커넥션에서 쓰이고 그 이후에는 전달하면 안 됩니다. 홉별 헤더를 전달받은 서버가 그 헤더를 자신과 프락시 간의 커넥션에 대한 것으로 오해하면서 문제가 생기는 것입니다.
넷스케이프는 멍청한 프락시 문제를 해결하기 위해 브라우저에서 일반적으로 전달하는 Connection 헤더 대신에 비표준인 Proxy-Connection 확장 헤더를 프락시에게 전달합니다. 프락시가 Proxy-Connection 헤더를 무조건 전달하더라도 웹 서버는 그것을 무시하기 때문에 문제가 되지 않습니다. 영리한 프락시는 의미 없는 Proxy-Connection 헤더를 Connection 헤더로 바꿈으로써 원하던 효과를 얻게 될 것입니다.
이 방식은 클라이언트와 서버 사이에 한 개의 프락시만 있는 경우에서만 동작합니다.

HTTP/1.1의 지속 커넥션

HTTP/1.1에서는 별도 설정을 하지 않는 한, 모든 커넥션을 지속 커넥션으로 취급합니다. HTTP/1.1 애플리케이션은 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 명시해야 합니다.
HTTP/1.1 클라이언트는 응답에 Connection: close 헤더가 없으면 응답 후에도 HTTP/1.1 커넥션을 계속 유지하자는 것으로 추정합니다. 하지만 클라이언트와 서버는 언제든지 커넥션을 끊을 수 있습니다.

지속 커넥션의 제한과 규칙

• 클라이언트가 요청에 Connection: close 헤더를 포함해 보냈으면, 클라이언트는 그 커넥션으로 추가적인 요청을 보낼 수 없습니다.
• 클라이언트가 해당 커넥션으로 추가적인 요청을 보내지 않을 것이라면, 마지막 요청에 Connection: close 헤더를 보내야 합니다.
• 커넥션에 있는 모든 메시지가 자신의 길이 정보를 명확히 가지고 있을 때에만 커넥션을 지속시킬 수 있습니다.
• HTTP/1.1 프락시는 클라이언트와 서버 각각에 대해 별도의 지속 커넥션을 맺고 관리해야 합니다.
• HTTP/1.1 프락시 서버는 클라이언트가 커넥션 관련 기능에 대한 클라이언트의 지원 범위를 알고 있지 않은 한 지속 커넥션을 맺으면 안 됩니다. 오래된 프락시가 Connection 헤더를 전달하는 문제가 발생할 수 있기 때문
• 서버는 메시지를 전송하는 중간에 커넥션을 끊지 않을 것이고 커넥션을 끊기 전에 적어도 한 개의 요청에 대해 응답을 할 것이긴 하지만, HTTP/1.1 기기는 CoNNECTION 헤더의 값과는 상관없이 언제든지 커넥션을 끊을 수 있습니다.
• HTTP/1.1 애플리케이션은 중간에 끊어지는 커넥션을 복구할 수 있어야만 합니다.
• 클라이언트는 전체 응답을 받기 전에 커넥션이 끊어지면, 요청을 반복해서 보내도 문제가 없는 경우에는 요청을 다시 보낼 준비가 되어 있어야 합니다.
• 하나의 사용자 클라이언트는 서버의 과부하를 방지하기 위해서, 넉넉잡아 두 개의 지속 커넥션만을 유지해야 합니다.

파이프라인 커넥션

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

파이프라이닝이란 같은 영속적인 커넥션을 통해서, 응답을 기다리지 않고 요청을 연속적으로 보내는 기능입니다. 이것은 커넥션의 지연를 회피하고자 하는 방법입니다.
https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_HTTP_1.x

파이프라인의 제약 사항

• HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안 됩니다.
• HTTP 응답은 요청 순서와 같게 와야 합니다.
• HTTP 클라이언트는 커넥션이 언제 끊어지더라도, 완료되지 않은 요청이 파이프라인에 있으면 언제든 다시 요청을 보낼 준비가 되어 있어야 합니다.
• HTTP 클라이언트는 POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안 됩니다.

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

커넥션 관리에는 명확한 기준이 없습니다.

'마음대로' 커넥션 끊기

어떠한 HTTP 클라이언트, 서버, 혹은 프락시든 언제든지 TCP 전송 커넥션을 끊을 수 있습니다. 보통 커넥션은 메시지를 다 보낸 다음 끊지만, 에러가 있는 상황에서는 헤더의 중간이나 다른 엉뚱한 곳에서 끊길 수 있습니다.
지속 커넥션이 일정 시간 동안 요청을 전송하지 않고 유휴 상태에 있으면 서버는 그 커넥션을 끊을 수 있습니다. 그 때 클라이언트가 요청 메시지를 보낸다면 문제가 발생하게 될 것입니다.

Content-Length와 Truncation

각 HTTP 응답은 본문의 정확한 크기 값을 가지는 Content-Length 헤더를 가지고 있어야 합니다. 클라이언트나 프락시가 커넥션이 끊어졌다는 HTTP 응답을 받은 후, 실제 전달된 엔터티의 길이와 Content-Length의 값이 일치하지 않거나 Content-Length 자체가 존재하지 않으면 수신자는 데이터의 정확한 길이를 서버에게 물어봐야 합니다.
만약 수신자가 캐시 프락시일 경우 응답을 캐시하면 안 됩니다. 프락시는 Content-Length를 정정하려 하지 말고 메시지를 받은 그대로 전달해야 합니다.

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

HTTP 애플리케이션은 예상치 못하게 커넥션이 끊어졌을 때에 적절히 대응할 수 있는 준비가 되어 있어야 합니다. 클라이언트가 트랜잭션을 수행 중에 전송 커넥션이 끊기게 되면, 클라이언트는 그 트랜잭션을 재시도 하더라도 문제가 없다면 커넥션을 다시 맺고 한 번 더 전송을 시도해야 합니다. 파이프라인 커넥션에서 클라이언트는 여러 요청을 큐에 쌓아 놓을 수 있지만, 서버는 처리해야 할 요청들을 남겨둔 채로 커넥션을 끊어버릴 수도 있습니다. 응답이 오기 전에 커넥션이 끊기면 클라이언트는 실제로 서버에서 얼마만큼 요청이 처리되었는지 전혀 알 수 없습니다.
한 번 혹은 여러 번 실행됐는지에 상관없이 같은 결과를 반환한다면 그 트랜잭션은 멱등(idempotent) 하다고 합니다. 클라이언트는 POST와 같이 멱등이 아닌 요청은 파이프라인을 통해 요청하면 안 됩니다.

우아한 커넥션 끊기

TCP 커넥션은 양방향입니다. TCP 커넥션의 양쪽에는 데이터를 읽거나 쓰기 위한 입력 큐와 출력 큐가 있습니다. 한쪽 출력 큐에 있는 데이터는 다른 쪽의 입력 큐에 보내질 것입니다.

전체 끊기와 절반 끊기
애플리케이션은 TCP 입력 채널과 출력 채널 중 한 개만 끊거나 둘 다 끊을 수 있습니다. close()를 호출하면 TCP 커넥션의 입력 채널과 출력 채널의 커넥션을 모두 끊습니다. 이를 '전체 끊기'라고 합니다. 입력 채널이나 출력 채널 중에 하나를 개별적으로 끊으려면 shutdown()을 호출하면 됩니다. 이를 '절반 끊기'라고 부릅니다.

TCP 끊기와 리셋 에러
단순한 HTTP 애플리케이션은 전체 끊기만을 사용할 수 있습니다. 하지만 애플리케이션이 각기 다른 HTTP 클라이언트, 서버, 프락시와 통신할 때, 그리고 그들과 파이프라인 지속 커넥션을 사용할 때, 기기들에 예상치 못한 쓰기 에러를 발생하는 것을 예방하기 위해 '절반 끊기'를 사용해야 합니다.
보통은 커넥션의 출력 채널을 끊는 것이 안전합니다. 클라이언트에서 더는 데이터를 보내지 않을 것임을 확신할 수 없는 이상, 커넥션의 입력 채널을 끊는 것은 위험합니다. 클라이언트에서 이미 끊긴 입력 채널에 데이터를 전송하면 'connection reset by peer' 에러를 받게 될 것이고, 응답 데이터가 기기에 잘 도착하였어도 아직 읽히지 않은 버퍼에 있는 응답 데이터는 사라지게 됩니다.

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

Reference

📗 TCP에 대해
📗 커넥션 관리 - TCP 커넥션과 성능
📗 사이 좋게 네트워크를 나눠 쓰는 방법, TCP의 혼잡 제어
📗 HTTP/1.x의 커넥션 관리