04. 커넥션 관리

이 챕터에서 배우는 것

HTTP는 어떻게 TCP 커넥션을 사용하는가
TCP 커넥션의 지연, 병목, 막힘
병렬 커넥션, keep-alive 커넥션, 커넥션 파이프라인을 활용한 HTTP의 최적화
커넥션 관리를 위해 따라야 할 규칙들

4.1 TCP 커넥션

전 세계 모든 http 통신은 지구상의 컴퓨터와 네트워크 장비에서 널리 쓰이고 있는 패킷 교환 네트워크 프로토콜의 계층화된 집합인 TCP/IP 통해 이루어진다. 일단 커넥션이 맺어지면 클라와 서버 컴퓨터 간에 주고받는 메시지들은 손실 혹은 손상되거나 순서가 바뀌지 않고 안전하게 전달된다.

브라우저에 url 입력시 수행하는 단계. http://www.ex.com:80/ex.html

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

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

HTTP 커넥션도 존재하는데 이건 몇몇 사용 규칙을 제외하고는 TCP 커넥션에 불과하다. tcp는 인터넷을 안정적으로 연결해준다. 신속 정확하게 데이터를 보내고자 한다면 TCP의 기초적 내용을 알아야 한다.

tcp는 http에게 신뢰할 만한 통신 방식을 제공한다. tcp 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달된다.

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

TCP는 IP 패킷(혹은 IP 데이터그램)이라 불리는 작은 조각을 통해 데이터를 전송한다. http는 최상위 계층이고 http에 보안 기능을 더한 HTTPS는 TLS or SSL 이라 불리기도 하며 HTTP와 TCP 사이에 있는 암호화(cryptographic encryption) 계층이다.

TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라 불리는 봉투에 담아 인터넷을 통해 데이터를 전달한다. 이 모든 것은 TCP/IP 소프트웨어에 의해 처리되며 그 과정은 http 프로그래머에게 보이지 않는다.

? 여러 세그먼트를 네트워크 계층의 데이터그램에 묶어 하위 계층으로 전달하는가?

각 TCP 세그먼트는 하나의 IP 주소에서 다른 IP 주소로 IP 패킷에 담겨 전달된다. 각 IP 패킷들 각각은 다음을 포함한다.

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

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

4.1.3 TCP 커넥션 유지하기

컴퓨터는 항상 TCP 커넥션을 여러 개 가지고 있다. TCP는 포트 번호를 통해서 이런 여러 개의 커넥션을 유지한다.

IP주소는 해당 컴퓨터에 연결되고 포트 번호는 해당 애플리케이션으로 연결된다. TCP 커넥션은 4 가지 값으로 식별한다.

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

이 네 가지 값으로 유일한 커넥션을 생성한다. 즉 UNIQUE 해야하는것임.

4.1.4 TCP 소켓 프로그래밍

운영체제는 TCP 커넥션의 생성과 관련된 여러 기능을 제공한다. 어떤 기능들이 있는지 TCP 프로그래밍 인터페이스를 간단히 살펴보자. 다음 표는 소켓 API의 주요 인터페이스다. 이 소켓 API는 http 프로그래머에서 TCP와 IP의 세부사항들을 숨긴다. 소켓 API는 유닉스 운영체제용으로 먼저 개발되었지만, 지금은 소켓 API의 다양한 구현체들 덕에 대부분 운영체제와 프로그램 언어에서 이를 사용할 수 있게 되었다.

소켓 API 호출	설명
s = socket(<params>)	연결 되지 않은 익명의 새 소켓 생성
bind(s, <local IP:port>)	소켓에 로컬 포트 번호와 인터페이스 할당
connect(s, <remote IP:port>)	로컬의 소켓과 원격 호스트 및 포트 사이에 TCP 커넥션 생성
listen(s, …)	커넥션을 받아들이기 위해 로컬 소켓에 허용함을 표시
s2 = accept(s)	누군가 로컬 포트에 커넥션 맺기를 기다림
n = read(s, buffer, n)	소켓으로부터 버퍼에 n바이트 읽기 시도
n = write(s, buffer, n)	소켓으로부터 버퍼에 n바이트 쓰기 시도
close(s)	TCP 커넥션 완전히 끊음
shutdown(s, <side>)	TCP 커넥션의 입출력만 닫음
getsockopt(s, …)	내부 소켓 설정 옵션값을 읽음
setsockopt(s, …)	내부 소켓 설정 옵션값을 변경
소켓 api를 쓰면, TCP 종단(endpoint) 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다. TCP API는, 기본적인 네트워크 프로토콜의 핸드셰이킹, 그리고 TCP 데이터 스트림과 IP 패킷 간의 분할 및 재조립에 대한 모든 세부사항을 외부로부터 숨긴다.

4.2 TCP의 성능에 대한 고려

http는 TCP 바로 위의 계층이기에 http 트랜잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받는다. 기본적인 TCP 성능의 특성을 이해함으로써, http 의 커넥션 최적화 요소들을 더 잘 알게되고 더 좋은 성능의 http 애플리케이션을 설계하고 구현할 수 있게 될 것이다.

이 절을 이해하려면 TCP 프로토콜 내부를 자세히 알아야 한다. TCP는 매우 복잡한 주제이기에 여기서는 TCP 성능에 대한 내용은 간략히 다룬다.

4.2.1 HTTP 트랜잭션 지연

http 요청 과정에서 어떤 네트워크 지연이 발생하는지 살펴보면서 TCP 성능에 대해 이야기해보자. 다음 그림은 http의 주요 커넥션, 전송, 처리의 지연을 보여준다. 트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청 전송하고, 응답 메시지 보내는 것에 비하면 상단히 짧은걸 알 수 있다. 클라나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 http 지연은 TCP 네트워크 지연 때문에 발생한다.

http 트랜잭션을 지연시키는 원인은 여러 가지 있다.

클라는 URI에서 웹 서버의 IP 주소와 포트 번호를 알아내야한다. 만약 URI에 기술되어있는 호스트에 방문한 적이 없으면 DNS resolution 인프라를 써서 URI에 있는 호스트 명을 IP 주소로 변환하는데 꽤 시간이 걸릴것이다.(상대적인것 오늘날은 대부분 1초 미만)
다음으로, 클라는 TCP 커넥션 요청을 서버에 보내고 서버가 커넥션 허가 응답을 회신하길 기다린다. 커넥션 설정 시간은 새로운 TCP 커넥션에서 항상 발생한다. 이는 1~2초 시간이 소요(옛날 기준)되지만, 수백 개의 http 트랜잭션이 만들어지면 소요시간은 크게 증가 할 것.
커넥션이 맺어지면 클라는 http 요청을 새로 생성된 TCP 파이프를 통해 전송한다. 웹 서버는 데이터가 도착하는 대로 TCP 커넥션에서 요청 메시지를 처리한다. 요청 메시지가 인터넷을 통해 전달되고 서버에서 처리되는데까지는 시간이 소요된다
웹 서버가 http 응답 보내는거 역시 시간이 소요된다.

원인은 여러가지인데, 하드웨어 성능, 네트워크 전송 속도, 메시지 크기, 거리, TCP 의 기술적 복잡성 등…

4.2.2 성능 관련 중요 요소

여기서 부터는 다음과 같은 요인과 그로 인한 성능상 문제를 포함해서 http 프로그래머에게 영향을 주는 가장 일반적인 TCP 관련 지연들에 관해 간략히 다룰것이다.

TCP 커넥션 핸드셰이크 설정
인터넷 혼잡을 제어하기 위한 TCP의 느린 시작(slow start)
데이터를 한데 모아 한 번에 전송하기 위한 네이글(nagle) 알고리즘
TCP의 편승(piggyback) 확인 응답(acknowledgment) 위한 확인응답 지연 알고리즘
TIME_WAIT 지연과 포트 고갈 고성능 http 솦웨어 개발하고 있다면 위 각각을 모두 이해해야한다.

4.2.3 TCP 커넥션 핸드셰이크 지연

새로운 TCP 커넥션 열 때면, TCP 솦웨는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환한다. 작은 크기의 데이터 전송에 커넥션이 사용된다면 일너 패킷 교환은 http 성능을 크게 저하 시킬수있다.

다음은 TCP 커넥션이 핸드셰이크하는 순서다.

클라는 새로운 TCP 커넥션 생성위해 작은 TCP 패킷(40~60 바이트)를 서버에 보낸다. 그 패킷은 SYN이라는 특별한 플래그를 가지는데, 이 요청이 커넥션 생성 요청이라는 뜻이다.
서버가 그 커넥션을 받으면 몇 가지 커넥션 매개변수를 산출하고, 커넥션 요청이 받아들여졌음을 의미하는 SYN, ACK 플래그를 포함한 TCP 패킷을 클라에 보낸다.
마지막으로 클라는 커넥션이 잘 맺어졌음을 알리기 위해 서버에게 다시 확인 응답신호를 보낸다. 오늘날의 TCP는 클라가 이 확인응답 패킷과 함께 데이터를 보낼 수 있다. http 개발자는 이 패킷들을 보지 못한다. 보이지 않게 TCP 솦웨어가 관리함. http 개발자가 보는건 새로운 TCP 커넥션이 생성될때 발생하는 지연이 전부.

http 트랜잭션이 아주 큰 데이터 주고받지 않는 평범한 경우에는, SYN/SYN+ACK 핸드쎼이크(그림 4-8a, 4-8b)가 눈에 띄는 지연을 발생시킨다. TCP의 ACK 패킷(4-8c)는 http 요청 메시지 전체를 전달할 수 있을 만큼 큰 경우가 많고, 많은 http 서버 응답 메시지는 하나의 IP 패킷에도 담길 수 있다(예르 들어 응답이 장식용 이미지가 있는 크기의 html 파일이거나 브라우저의 캐시요청에대한 응답이 304 Not Modified 일 경우)

결국 크기가 작은 http 트랜잭션은 50% 이상의 시간을 TCP를 구성하는데 쓴다. 이후 절에서는 이러한 TCP 구성으로 인한 지연 제거를 위해 http 가 이미 존재하는 커넥션을 어떻게 재활용하는지 알아 볼 것이다.

4.2.4 확인응답 지연

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

각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가진다. 각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환한다. 만약 송신자가 특정 시간안에 확인응답 메시지를 받지 못하면 패킷이 파기되었거나 오류가 있는것으로 판단하고 다시 전송한다.

확인응답은 크기가 작기에, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답을 ‘편승’시킨다. TCP는 송출 데이터 패킷과 확인응답을 하나로 묶음으로써 네트웍을 좀더 효율적으로 사용한다. 확인응답이 같은 방향으로 가는 데이터 패킷에 편승되는 경우를 늘리기위해서 많은 TCP 스택은 ‘확인응답 지연’ 알고리즘을 구현한다. 확인응답 지연은 송출할 확인응답을 특정 시간동안 버퍼에 저장해 두고, 확인응답을 편승시키기 위한 송출 데이터 패킷을 찾는다. 만약 일정 시간안에 송출 데이터 패킷 못 찾으면 확인응답은 별도 패킷을 만들어 전송된다.

안타깝게도 요청, 응답 두 가지 형식으로만 이루어지는 http 동작 방식은 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킨다. 막상 편승할 패킷을 찾으려 하면 해당 방향으로 송출될 패킷이 적기에, 확인응답 지연 알고리즘으로 인한 지연이 자주 발생한다. 운영체제에따라 다르지만, 지연의 원인이 되는 확인응답 지연 관련 기능을 수정하거나 비활성화 할 수 있다.

TCP 스택에 있는 매개변수 수정할 때는 지금 무엇을 하고 있는지 항상 잘 알고 수정해야한다. TCP의 내부 알고리즘은 잘못 만들어진 애플리게키션으로 부터 인터넷을 보호하도록 설계되어 있다. TCP 설정을 수정하려한다면 TCP 내부의 알고리즘이 피하려하는 문제를 애플리케이션이 발생 시키지 않을것이라고 확싱할 수 있어야한다.

4.2.5 TCP 느린 시작(slow start)

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

TCP 느린 시작은 TCP가 한 번에 전송할 수 있는 패킷 수를 제한한다. 간단히 말해서, 패킷이 성공적으로 전달되는 각 시점에 송신자는 추가로 2개의 패킷을 더 전송할 수 있는 권한 얻는다. http 트랜재션에 전송할 데이터 양이 많으면 한번에 모든 패킷을 전송할수 없다. 대신 한 개의 패킷만 전송하고 확인응답을 기다려야한다. 확인응답 받으면 2개의 패킷 보낼 수 있으며 그 패킷 각각에대한 확인응답을 받으면 총 4개의 패킷을 보낼 수 있게된다. 이를 ‘혼잡 윈도를 연다 opening the congetion window’라 한다.

이 혼잡제어 기능 덕에, 새로운 커넥션은 이미 어느 정도 데이터를 주고받은 ‘튜닝’된 커넥션보다 느리다. 이 튜닝된 커넥션은 빠르기 때문에 http에는 이미 존재하는 커넥션을 재사용하는 기능이 있다. 바로 지속 커넥션인대 이후에 공부 ㄱㄱ

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

어떤 크기의 데이터든지 TCP 스택으로 전송할 수 있도록, TCP 는 데이터 스트림 인터페이스를 제공한다. 하지만 각 TCP 세그먼트는 40 바이트 상당의 플래그와 헤더를 포함하여 전송하기 때문에, TCP가 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트웍 성능은 크게 떨어질 것이다.

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

네이글 알고리즘은 세그먼트가 최대 크기(패킷의 최대 크기는 LAN 상에서 1,500 바이트 정도, 인터넷 상에서는 수백 바이트 정도)가 되지 않으면 전송하지 않는다. 다만 다른 모든 패킷이 확인응답을 받았을 경우엔 최대 크기보다 작은 패킷의 전송을 허락한다. 다른 패킷들이 아직 전송중이면 데이터는 버퍼에 저장된다. 전송되고 나서 확인응답을 기다리던 패킷이 확인응답을 받았거나 전송하기 충분할 만큼의 패킷이 쌓였을때 버퍼에 저장되어 있던 데이터가 전송된다.

네이글 알고리즘은 http 성능과 관련해 여러 문제 일으킨다. 먼저, 크기가 작은 http 메시지는 패킷을 못채우기 때문에, 앞으로 생길지 안생길지도 모르는 추가적 데이터를 기다리며 지연될 것이다. 두 번째로, 네이글 알고리즘은 확인응답 지연과 함께 쓰일 경우 형편없이 동작하낟. 네이글 알고리즘은 확인응답이 도착할 때 까지 전송을 멈추는 반면, 확인응답 지연 알고리즘은 확인응답을 100~200 밀리초 지연시킨다.

http 애플리케이션은 성능 향상 위해 http 스택에 TCP_NODELAY 파라미터값을 설정해 네이글 알고리즘을 비활성화 하기도 한다. 이 설정을 했으면 작은 크기의 패킷이 너무 많이 생기지 않도록 큰 크기의 데이터 덩어리를 만들어야 한다.

4.2.7 TIME_WAIT의 누적과 포트 고갈

TIME_WAIT 포트 고갈은 성능 측정 시 심각한 성능 저하를 발생시키지만, 보통 실제 상황에서는 문제를 발생시키지 않는다. 하지만 성능 측정을 하는 사람이라면, 결국 이 문제에 봉착하게 될 것이고 생각지도 못했던 성능상의 문제가 생긴 것으로 오해할 수 있으니 특별히 조심해야한다.

TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영역(controll block)에 기록해 놓는다. 이 정보는 같은 주소와 포트 번호를 쓰는 새로운 TCP 커넥션이 일정 시간 동안에는 생성되지 않게 하기 위한 것. 보통 세그먼트 최대 생명주기의 두배 정보(2MSL 2분정도)의 시간동안 유지된다. 이는 이전 커넥션과 관련된 패킷이 그 커넥션과 같은 주소와 포트번호를 가지는 새로운 커넥션에 삽입되는 문제를 방지한다. 실제로 이 알고리즘은 특정 커넥션이 생성되고 닫힌 다음, 그와 같은 IP주소와 포트 번호를 가지는 커네션이 2분 이내에 또 생성되는걸 막아준다.

현대의 빠른 라우터들 덕에 커넥션이 닫힌 후 중복되는 패킷이 생기는 경우는 거의 없어졌다. 2MSL을 더 짧게하는 운영체제도 있지만, 이 값의 수정은 조심해야한다. 만약 이전 커넥션의 패킷이 그 커넥션과 같은 연결 값으로 새로 생성된 커넥션에 삽입되면, 패킷은 중복되고 TCP 데이터는 충돌할 것이다.

일반적으로 2MSL의 커넥션 종료 지연이 문제가 되지는 않지만, 성능시험을 하는 상황에서는 이슈가 발생할 수 있다. 성능 측정 대상 서버는 클라가 접속할 수 있는 Ip 주소의 개수를 제한하고, 그 서버에 접속하여 부하를 발생 시킬 컴퓨터 수는 적기 때문. 또한 http 서버는 TCP 포트인 80을 사용. 이런 상황에서는 가능한 연결의 조합이 제한되고, TIME_WAIT로 인해 순간순간 포트 재활용하는것이 불가능해진다.

각각 한 개의 클라와 웹 서버가 있고 TCP 커넥션을 맺기 위한 네 개의 값이 있다 해보자.

<발신지 ip 주소, 발신지 포트, 목적지 ip 주소, 목적지 포트>

이 중 발신지 포트를 제외한 나머지 3개는 고정되어있다. 클라가 서버에 접속할 때마다 유일한 커넥션 생성 위해 새로운 발신지 포트를 쓴다. 하지만 쓸 수 있는 발신지 포트는 제한되어있고(60000개로 가정) 2MSL(120s 가정) 커넥션이 재사용 불가하므로, 초당 500(60000/120)으로 커넥션이 제한된다. 서버가 초당 500개 이상의 트랜잭션을 처리할 만큼 빠르지 않다면 time_wait 포트 고갈은 일어나지 않는다. 이 문제를 해결하기 위해 부하를 생성하는 장비를 더 사용하거나 클라와 서버가 더 많은 커넥션 맺을 수 있도록 가상 ip를 여러개 쓸 수도 있다.

포트 고갈 문제를 겪지 않더라도, 커넥션을 너무 많이 맺거나 대기상태로 있는 제어 블록이 너무 많아지는건 주의. 그런게 많아지면 느려지는 운영체제도 있기때문.

이해가 좀 안감 126페이지

4.3 HTTP 커넥션 관리

TCP가 아닌 HTTP! HTTP 커넥션의 최적화 기술에대해 앏아보자.

4.3.1 흔히 잘못 이해하는 Connection 헤더

http는 클라와 서버 사이에 프락시, 캐시 등 중개 서버가 놓이는 것을 허락한다.

어떤 경우에는, 두 개의 인접한 http 앱이 현재 맺고 있는 커넥션에만 적용될 옵션을 지정해야 할 때가 있다. HTTP Connection 헤더 필드는 커넥션 토큰을 쉼표로 구분하여 가지고 있으며, 그 값들은 다른 커넥션에 전달되지 않는다. 예를 들어, 다음 메시지를 보낸 다음 끊어져야 할 커넥션은 Conncection: close 라 명시할 수 있다.

Connection 헤더에는 다음 3 가지 종류의 토큰이 전달될 수 있기에 다소 혼란스러울 수 있다.

HTTP 헤더 필드 명은, 이 커넥션에만 해당되는 헤더들을 나열
임시적인 토큰 값은, 커넥션에 대한 비표준 옵션 의미
close 값은, 커넥션이 작업이 완료되면 종료되어야 함을 의미 커넥션 토큰이 http 헤더 필드 명을 가지고 있으면, 해당 필드들은 현재 커넥션만을 위한 정보이므로 다음 커넥션에 전달하면 안 된다. Connection 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳으로 전달하는 시점에 삭제되야한다. Connection 헤더에는 홉별(hop by hop) 헤더 명을 기술하는데, 이것을 ‘헤더 보호하기’라 한다. Connection 헤더에 명시된 헤더들이 전달되는 것을 방지하기 때문이다.

http 애플리케이션이 Connection 헤더와 함께 메시지를 전달받으면, 수신자는 송신자에게서 온 요청에 기술되어 있는 모든 옵션을 적용한다. 그리고 다음 홉에 메시지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술되어 있던 모든 헤더를 삭제한다. 예를들면 Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade 같은 것.

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

커넥션 관리가 제대로 이루어 지지 않으면 TCP 성능이 매우 안 좋아질 수 있다. 예를 들어 3개의 이미지가 있는 웹페이지가 있다 해보자. 브라우저가 이 페이즈를 보여주려면 4 개의 http 트랜잭션을 만들어야 한다. 하나는 해당 html을 받기위해, 나머지 세 개는 첨부된 이미지를 받기 위한 것이다. 각 트랜잭션이 새로운 커넥션을 필요로 한다면, 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생할 것이다.

순차적인 처리로 인한 지연에는 물리적인 지연뿐 아니라, 하나의 이미지를 내려받고 있는 중에는 웹페이지의 나머지 공간에 아무런 변화가 없어서 느껴지는 심리적 지연도 있다.

순차적 로드하는 방식의 또 하나의 단점은, 특정 브라우저의 경우 객체를 화면에 배치하려면 객체의 크기를 알아야해서 모든 객체를 내려받기 전까지 텅빈화면을 보여준다는 것. 이 경우 브라우저는 객체들을 연속해서 하나씩 받는게 효율적이겠으나 사용자는 어떻게 진행되고 있는지 모르는 상태로 텅 빈 화면만 보고있게된다.

HTTP 커넥션의 성능을 향상 시킬 수 있는 여러 기술이 있다. 4가지를 알아보자.

병렬 커넥션

여러 개의 TCP 커넥션을 통한 동시 http 요청

지속 커넥션

커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션의 재활용

파이프라인 커넥션

공유 TCP 커넥션을 통한 병렬 HTTP 요청

다중(multiplexed) 커넥션

요청과 응답들에 대한 중재(실험적 기술)

4.4 병렬 커넥션

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

단일 커넥션의 대역폭 제한과 커넥션이 동작하지 않고 있는 시간을 활용하면, 객체가 여러 개 있는 웹페이지를 더 빠르게 내려받을 수 있을 것이다. 하나의 커넥션으로 객체들을 로드할 때의 대역폭 제한과 대기 시간을 줄일 수 있다면 더 빠르게 로드할 수 있을 것이다.

각 커넥션의 지연 시간을 겹치게 하면 총 지연 시간을 줄일 수 있고, 클라의 인터넷 대역폭을 한 개의 커넥션이 다 써버리는게 아니라면 나머지 객체를 내려받는데 남은 대역폭을 사용할 수 있다

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

일반적으로 더 빠르긴한데 항상 그런건 아니다. 클라의 네트워크 대역폭이 좁을 때는 대부분의 시간을 데이터 전송에 쓸 것이다. 여러 객체를 병렬로 내려받는 경우 이 제한된 대역폭 내에서 객체를 전송받는건 느리기때문에 성능상의 장점은 거의 없어진다.

또한 다수의 커넥션은 메모리 많이 소모하고 자체적인 성능문제를 야기한다. 복잡한 웹사이트는 수백개의 객체가 있는데 서버는 다른 여러 사용자의 요청도 함께 처리해야되서 한 클라에 수백개의 커넥션을 허용하는 건 드물다.

백명의 사용자가 100개의 커넥션 맺고 있다면, 서버는 총 10,000개의 커넥션을 떠 안게 되는 것이다. 이는 서버의 성능을 크게 저하시킨다.

브라우저는 실제로 병렬 커넥션을 사용하긴 하지만 적은 수(5개정도)의 병렬 커넥션만 허용한다.

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

벙렬 커넥션이 항상 웹페이지를 빠르게 로드하지 않는다. 실제로는 더 빨리 내려받지 않지만 사용자입장에서 화면에 여러 객체가 동시에 보이며 내려받고 있는 상황을 볼 수 있기에 더 빠르게 느껴질수는 있다.

4.5 지속 커넥션

http 1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 http 요청에 재사용할 수 있다. 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 부른다. 지속 커넥션은 클라이언트나 서버가 커넥션을 끊기 전까지는 트랜잭션 간에도 커넥션을 유지한다.

재사용함으로써 커넥션 맺기 위한 준비작업에 따르는 시간을 절약할 수 있다. 게다가 이미 맺어져 있는 커넥션은 TCP의 느린 시작으로 인한 지연을 피함으로써 더 빠르게 데이터를 전송할 수 있다.

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

병렬 커넥션에는 다음과 같은 몇 가지 단점이 있다.

각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요됨
각각의 새로운 커넥션은 TCP 느린 시작 때문에 성능이 느려진다
실제로 연결할 수 있는 병렬 커넥션의 수는 제한이 있다 지속 커넥션은 병렬에 비해 몇가지 장점이 있다.
커넥션 맺기 위한 사전 작업과 지연을 줄여준다
튜닝된 커넥션을 유지한다
커넥션의 수를 줄여준다 하지만, 지속 커넥션을 잘못 관리할 경우 계속 연결된 상태로 있는 수많은 커넥션이 쌓이게 될 것이다. 이는 로컬의 리소스 그리고 원격의 클라이언트와 서버의 리소스에 불필요한 소모를 발생시킨다.

애플리케이션은 적은 수의 병렬 커넥션만 맺고 이를 유지한다. 두 가지 지속 커넥션 타입이 있는데, HTTP/2.0+에서는 ‘keep-alive’ 커넥션이 있고 HTTP/1.1 에서는 ‘지속’커넥션이 있다.

이 두개가 다른거였나?

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

많은 HTTP/1.0 브라우저와 서버들은 일찍부터 다소 실험적이었던 keep-alive 커넥션이라는 지속 커넥션을 지원하기 위해 확장되었다. 이 초기의 지속 커넥션은 상호 운용과 관련된 설계에 문제가 있었지만, 아직 많은 클라이언트와 서버는 이 초기 keep-alive 커넥션을 쓰고 있다. 그리고 그 설계상의 문제는 1.1에서 수정됨.

keep alive 커넥션의 성능상 이점은 다음 그림을 보면 이해가능하다. 같은 4개의 http트랜잭션에 대해, 연속적으로 4개의 커넥션을 생성하여 처리하는 방식과 하나의 지속 커넥션을 처리하는 방식을 비교하였다. 커넥션을 맺고 끊는 작업이 없어서 시간이 단축되었다.

4.5.3 Keep-Alive 동작

keep alive 는 사용하지 않기로 결정되어 1.1 명세에서 빠졌다. 하지만 아직도 브라우저와 서버 간에 keep alive 핸드 셰이크가 널리 사용되기에 http 애플리케이션은 그것을 처리할 수 있게 개발해야된다. 이제 keep alive 가 동작하는 방식 간단히 살펴보자. keep alive 핸드셰이크에 대한 자세한 설명은 RFC 2068 같은 HTTP/1.1 이전 버전의 명세를 참고.

HTTP/1.0 keep alive 커넥션을 구현한 클라는 커넥션을 유지하기 위해 요청에 Connection:Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 응답에 Connection:Keep-Alive 헤더가 없으면, 클라는 서버가 keep alive르 지원하지 않으며, 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라 추정한다.

4.5.4 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 헤더가 있을때만 사용가능하다.

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

4.5.5 Keep-Alive 커넥션 제한과 규칙

keep-alive는 1.0 에서 기본으로 사용되지 않는다. 클라는 keep-alive 커넥션 계속 쓰기위해 Connection:Keep-Alive 요청 헤더를 보내야한다.
커넥션 계속 유지하려면 모든 메시지에 Connection:Keep-Alive 헤더를 포함해 보내야함. 만약 Connection:Keep-Alive 헤더가 없으면 서버는 응답후 바로 커넥션 끊는다
커넥션이 끊어 지기 전에 엔터티 본문의 길이를 알 수 있어야 커넥션을 유지할 수 있다. 본문이 정확한 Content-Length 값과 함께 멀티파트 미디어 형식을 가지거나 청크 전송 인코딩으로 인코드 되어야 함을 의미한다. 이 길이를 모르면 트랜잭션이 끝나는 지점에 기존메시지의 끝과 다른 메시지의 시작을 정확히 모르게된다.
프락시와 게이트웨이는 Connection 헤더의 규칙을 철저히 지켜야한다. 프락시와 게이트웨이는 메시지를 전달하거나 캐시에 넣기전에 Connection 헤더에 명시된 모든 헤더 필드와 Connection 헤더를 제거해야한다.
기술적으로 1.0을 따르는 기기로 부터 받는 모든 Connection 헤더 필드는 무시해야한다. 오래도니 프락시 서버로 부터 실수로 전달될수 있기 때문.
클라는 응답 전체를 모두 받기전에 커넥션이 끊어졌을 경우, 별다른 문제가 없으면 요청을 다시 보낼 수 있게 준비되어야한다.

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

Connection 헤더의 무조건 전달

프락시는 Connection 헤더를 이해 못해서 해당 헤더들을 삭제하지 않고 요청 그대로를 그 다암 프락시에 전달한다. 오래되고 단순한 수많은 프락시들이 Connection 헤더에 대한 처리 없이 요청을 그대로 전달한다. 웹 클라가 무조건 전달하는 멍청한 프락시를 거쳐 웹 서버에 메시지를 전송한다 생각해보자.

그림에서 웹 클라는 프락시에 Connection: Keep-Alive 헤더와 함께 메시지를 보내고 커넥션 유지를 요청한다. 클라는 커넥션 유지 요청이 받아들여 졌는지 확인 위해 응답 기다린다.
멍청한 프락시는 요청받는 Connection 헤더를 이해하지 못한다. 프라시는 keep alive가 뭔지 모르기에 다음 서버에 그대로 전달한다. 하지만 Connection 헤더는 홉별(hop by hop) 헤더다(이는 오직 한 개의 전송 링크에만 적용되며 다음 서버로 전달되어선 안된다). 여기서 부터 이슈가 발생한다.
4-15b 처럼 전달된 요청이 서버에 도착한다. 웹 서버가 프락시로 부터 Connection: Keep Alive 헤더를 받으면, 웹 서버는 프락시(기존에 클라로부터 받았을 때와 같이)가 커넥션을 유지하자고 요청하는 것으로 잘 못 판단하게 된다. c와 같이 웹서버는 문제될 게 없기에 프락지와 커넥션을 유지하는것에 동의하고 Connection: keep alive 헤더를 포함하여 응답한다. 웹 서버는 프락시와 keep alive 커넥션이 맺어져 잇는 상태로 keep alive 규칙에 맞게 통신을 하는 것으로 판단한다. 하지만 다시말하지만 프락시는 keep alive 이해르 못했다.
b에서 멍청한 프락시는 서버로부터 받은 Connection 헤더를 포함하고 있는 응답 메시지를 클라에게 전달한다. 클라는 이 헤더를 통해 프락시가 커넥션을 동의했다 추정한다. 이 시점에 클라와 서버는 커넥션을 유지하고 있다고 생각하지만, 정작 프락시는 keep alive를 전혀 이해못함
프락시는 keep alive 전혀 모르지만, 받았던 데이터 전부를 그대로 클라에게 전달하고나서 서버가 커넥션을 끊기를 기다린다. 하지만 서버는 프락시가 자신에게 커넥션을 유지하기를 요청한것으로 알고있기에 커넥션을 끊지 않는다. 따라서 프락시는 커넥션이 끊어지기 전까지는 계속 커넥션이 끊어지기를 기다리게 된다.
d와 같이 클라가 응답을 받으면 다음 요청을 보내기 시작하는데 커넥션이 유지되고 있는 그 프락시에 보낸다. 프락시는 같은 커넥션 상에서 다른 요청이 오는 경우는 예상 못해서 그 요청은 프락시로부터 무시디고 브라우저는 아무 응답 없이 로드 중단이라는 표시만 뜬다.
이런 잘못된 통신때문에, 브라우저는 자신이나 서버가 타임아웃 나서 커넥션이 끊길 때까지 기다린다.

프락시와 홉별 헤더

이런 종류 통신 피하려면 프락시는 Connection 헤더와 Connection 헤더에 명시된 헤더들은 절대 전달해선 안된다. 따라서 프락시가 Connection 헤더를 받으면 Connection 헤더 뿐만 아니라 Keep-Alive란 이름의 헤더도 전달하면 안된다.

4.5.7 Proxy-Connection 살펴보기

넷스케이프의 브라우저 및 프락시 개발자들은 보든 웹 앱이 http 최신버전을 지원하지 않아도 모든 헤더를 무조건 전달하는 문제를 해결할 수 있는 차선책을 제시했다. 그 차선책은, 클라의 요청이 중개서버를 통해 이어지는 경우 모든 헤더를 무조건 전달하는 문제 해결을 위해 Proxy-Connection 이라는 헤더를 사용하는 것이다.

멍청한 프락시는 Connection keep alive 같은 홉별 헤더를 무조건 전달해서 문제를 일으킨다. 홉별 헤더들은 한 개의 특정 커넥션에서 쓰이고 이후에는 전달하면 안된다. 홉별 헤더를 전달받은 서버가 그 헤더를 자신과 프락시 간의 커넥션에 대한 것으로 오해하면서 문제가 생기는 것이다.

넷스케이프는 멍청한 프록시 문제 해결위해 비표준인 Proxy-Connection 확장 헤더를 프락시에게 전달한다. 프락시가 Proxy-Connection헤더를 무조건 전달하더라고 웹서버는 이를 무시해서 문제가 되지 않는다. 하지만 영리한 프락시라면 의미없는 Proxy-Connection를 Connection헤더로 바꿈으로서 원하던 효과 얻을것이다.

이 방식은 클라와 서버 사이에 한 개의 프락시만 있는 경우에서만 동작한다. 하지만 멍청한 프락시 양옆에 영리한 프락시가 있다면 다음 그림과 같이 잘못된 헤더를 만들어내는 문제가 다시 발생한다.

게다가 문제를 발생시키는 프락시들은 방화벽, 캐시 서버, 혹은 리버스 프락시 서버 가속기와 같이 네트워크 상에서 ‘보이지 않는’경우가 많다. 브라우저는 이런 기기들을 볼 수 없으므로 Proxy Connection 헤더를 보내지 못한다. 보이지 않는 웹 앱들이 지속 커넥션을 명확히 구현하는 것은 중요하다.

4.5.8 HTTP/1.1의 지속 커넥션

1.1 에서는 keep-alive 커넥션을 지원 않는 대신, 설계가 더 개선된 지속 커넥션을 지원한다. 지속 커넥션의 목적은 keep-alive 커넥션과 같지만 보다 더 잘 작동한다.

1.0의 keep-alive 커넥션과 달리 1.1의 지속 커넥션은 기본으로 활성화되어 있다. 1.1 에서는 별도 설정 하지 않는한, 모든 커넥션을 지속 커넥션으로 취급한다. 1.1 애플리케이션은 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 명시해야한다. 이는 keep-alive 커넥션 이 선택사항이 아닐 뿐만 아니라 지원 자체를 하지 않는다는 점에서 이전 HTTP 와 크게 다르다.

1.1 클라이언트는 응답에 Connection: close 헤더가 없으면 응답 후에도 1.1 커넥션을 계속 유지하자는 것으로 추정한다. 하지만 클라와 서버는 언제든 커넥션을 끊을 수 있다. Connection: close 를 보내지 않는 것이 서버가 커넥션을 영원히 유지하겠다는 것을 뜻하지는 않는다.

4.5.9 지속 커넥션의 제한과 규칙

클라이언트가 요청에 Connection: close 헤더를 포함해 보냈으면, 클라는 그 커넥션으로 추가적인 요청을 보낼 수 없다.
클라가 해당 커넥션으로 추가적 요청 보내지 않을거라면, 마지막요청에 Connection: close 헤더를 보내야 한다.
커넥션에 있는 모든 메시지가 자신의 길이 정보를 정확히 가지고 있을 때만 커넥션을 지속시킬 수 있다. 예를 들어 엔터티 본문은 정확한 Content Length 값을 가지거나 청크 전송 인코딩으로 인코드 되어 있어야한다.
1.1 프락시는 클라이언트와 서버 각각에 대해 별도의 지속 커넥션을 맺고 관리해야한다.
1.1 프락시 서버는 클라가 커넥션 관련 기능에 대한 클라의 지원 범위를 알고있지 않은 한 지속 커넥션 맺으면 안된다. 앞서 설명했듯 오래된 프락시가 Connection 헤더를 전달하는 문제가 발생할 수 있기 때문. 현실적으로 이건 쉽지 않으며 많음 벤더들이 이를 안지킨다.
서버는 메시지를 전송하는 중간에 커넥션을 끊지 않을 것이고 커넥션을 끊기전에 적어도 한 개의 요청에 대한 응답을 할 것이긴 하지만, 1.1 기기는 Connection 헤더 값과는 상관없이 언제든 커넥션 끊을 수 있다.
클라는 전체 응답을 받기 전에 커넥션이 끊어지면, 요청을 반복해서 보내도 문제가 없는 경우에는 요청을 다시 보낼 준비가 되어 있어야 한다.
하나의 사용자 클라는 서버의 과부하 방지를 위해, 넉넉잡아 두 개의 지속 커넥션만 유지해야한다. 따라서 N 명의 사용자가 서버로 접근하려한다면 프락시는 서버나 상위 프라시에 넉넉잡아 약 2N개의 커넥션을 유지해야한다.

4.6 파이프라인 커넥션

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

그림에서 a에서 c는 지속 커넥션이 어떻게 tcp 커넥션 지연을 제거하며, 파이프라인을 통한 요청이 어떻게 전송 대기 시간을 단축시키는지 보여준다.

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

http 클라이언트는 커넥션이 지속 커넥션인지 확인하기 전까지는 파이프라인을 이어서는 안된다.
http응답은 요청 순서와 같게 와야한다. http 메시지는 순번이 매겨져 있지 않아서 응답이 순서 없이오면 순서에 맞게 정렬 시킬 방법이 없다.
http 클라는 커넥션이 언제 끊어 지더라도, 완료되지 않은 요청이 파이프라인에 있다면 언제든 다시 요청을 보낼 준비가 되어 있어야한다. 클라가 지속 커넥션을 맺고 바로 10개의 요청을 보낸다 하더라도 서버는 5개의 요청만 처리하고 커넥션을 임의로 끊을 수 있다. 남은 5개 요청은 실패할거고 클라는 예상치 못하게 끊긴 커넥션 다시 맺고 요청을 보낼 수 있어야 한다.
http 클라는 POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안된다. 에러가 발생하면 파이프라인 통한 요청중 어떤것들이 서버에서 처리되었는지 클라가 알 방법이 없다. POST 같은 비멱등 요청을 재차 보내면 문제가 발생할수있기에, 문제가 있는 상황에서 그런 위험한 메서드로 요청 보내면 안된다.

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

커넥션 관리(특히 언제 끊는가)에는 명확한 기준이 없다.

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

어떠한 http 클라이언트, 서버, 프락시든 언제든지 TCP 전송 커넥션을 끊을 수 있다. 보통 커넥션은 메시지를 다 보낸다믕 끊지만 에러가 발생하면 헤더의 중간이나 다른 엉뚱한 곳에서 끊길 수 있다.

이 상황은 파이프라인 지속 커넥션에서와 같다. HTTP 앱은 언제든 지속 커넥션을 임의로 끊을 수 있다. 예를 들어, 지속 커넥셩이 일정시간동안 요청을 전송않고 유휴 상태에 있으면 서버는 그 커넥션을 끊을 수 있다.

하지만 서버가 그 유휴상태에 있는 커넥션을 끊는 시점에, 서버는 클라가 데이터를 전송하지 않을 것이라고 확신하지 못한다. 만약 이 일이 벌어지면 클라는 그 요청 메시지르 보내는 도중에 문제가 생긴다.

4.7.2 Content-Length와 Truncation

각 http 응답은 본문의 정확한 크기 값을 가지는 Content Length 헤더를 가지고 있어야 한다. 일부 오래된 http 서버는 자신이 커넥션을 끊으면 데이터 전송이 끝났음을 의미하는 형태로 개발되어 있기 때문에 Content Length 헤더를 생략하거나 잘못된 길이 정보로 응답하는 경우도 있다.

클라나 프락시가 커넥션이 끊어졌다는 http 응답 받은 후, 실제 전달된 엔티티 길이와 Content Length 값이 일치하지 않거나 Content Length 헤더 자체가 존재하지 않으면 수신자는 데이터의 정확한 길이을 서버에 물어봐야한다.

만약 수신자가 캐시 프락시라면 응답(잠재적 에러가 복합적으로 발생하는 것 최소화 하기 위해) 캐시하면 안된다. 프락시는 Content Length 정정하려 말고 메시지를 받은 그대로 전달해야 한다.

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

커넥션은 에러 없어도 지 맘대로 끊을 수 있다. http 앱은 예상치 못하게 커넥션이 끊어 지더라도 적절한 대응할 수 있게 준비를 해 놔야된다. 재전송 시나리오는 파이프라인 커넥션에서 좀 더 어렵다. 클라이언트는 여러 요청을 큐에 쌓아 놓을 수 있지만, 서버는 아직 처리되지 않고 스케줄이 조정되어야하는 요청들을 남겨둔 채로 커넥션을 끊어 버릴 수도 있다.

그로 인한 부작용을 조심. 어떤 요청 데이터가 전송됬지만, 응답이 오기 전에 커넥션 끊으면 클라는 실제로 서버에서 얼마만큼의 요청이 처리됬는지 전혀 모른다. 정적인 html 페이지를 GET 하는 부류의 요청들은 반복적으로 요청하더라도 결과에 아무런 영향이 없다. 반면 온라인 서점에 주문을 POST 하는 부류의 요청들은 반복될 경우 주문이 여러 번 중복될 것이기 때문에 반복은 피해야한다.

한 번 혹은 여러 번 실행됬는지에 상관없이 같은 결과를 반환한다면 그 트랜잭션은 멱등(idempotent)하다고 한다. GET, HEAD, PUT, DELETE, TRACE, OPTIONS 같은건 멱등하다고 이해하면 된다. 클라는 POST 같이 비 멱등인 요청은 파이프라인을 통해 요청하면 안된다. 그렇지 않으면 전송 커넥션이 예상치 못하게 끊어져버렸을때, 알 수 없는 결과를 초래할 수 있다. 비멱등인 요청을 다시 보내야 한다면, 이전 요청에 대한 응답을 받을 때 까지 기다려야한다.

비멱등인 메서드나 순서에 대해 에이전트가 요청을 다시 보낼 수 있도록 기능을 제공한다 해도, 자동으로 재시도하면 안된다. 예를 들어 대부분 브라우저는 캐시된 POST 요청 페이지 다시 로드하려할때, 요청을 다시 보내기를 원하는지 믇는 대화상자를 띄운다.

4.7.4 우아한 커넥션 끊기

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

전체 끊기와 절반 끊기

애플리케이션은 TCP 입력 채널과 출력 채널 중 한 개만 끊거나 둘 다 끊을 수 있다. close()를 호출하면 TCP 커넥션의 입력 채널과 출력 채널의 커넥션을 모두 끊는다.

이를 전체 끊기 라 한다. 입력 채널이나 출력 채널 중 하나를 개별적으로 끊으려면 shutdown()을 호출하면 된다. 이를 ‘절반 끊기’라 부른다.

TCP 끊기와 리셋 에러

단순한 http 앱은 전체 끊기만 사용 가능하다. 하지만 앱이 각기 다른 http 클라이언트, 서버, 프락시와 통신할 때, 그리고 그들과 파이프라인 지속 커넥션을 사용할 때, 기기들에 예상치 못한 쓰기 에러를 발생하는 것 예방 위해 절반 끊기를 사용해야한다.

보통 커넥션은 출력 채널을 끊는게 안전하다.커넥션의 반대편에 있는 기기는 모든 데이터를 버퍼로 부터 읽고 나서 데이터 전송이 끝남과 동시에 당신이 커넥션을 끊었다는걸 알게 될 것.

클라에서 더는 데이터를 보내지 않을 것임을 확신할 수 없는 이상, 커넥션의 입력 채널 끊는건 위험하다. 만약 클라에서 이미 끊긴 입력채널에 데이터 전송하면 4-21 그림같이 서버의 운영체제는 TCP ‘connection reset by peer’ 메시지를 클라에 보낼 것이다. 대부분 운영체제는 이것을 심각한 에러로 취급해 버퍼에 저장된, 아직 읽히지 않은 데이터 모두를 삭제한다. 이런 상황은 파이프라인 커넥션에서 더 악화됨.

10개의 요청을 파이프라인 지속 커넥션 통해 전송했고, 이미 응답은 운영체제의 버퍼에 있지만 아직은 앱이 읽지 않았다 가정하자. 그러고 나서 당신은 11번째 요청을 보냈지만, 서버는 이 커넥션이 오래 유지됬다 판단하고 연결을 끊어버렸다 해보자. 11번째 요청을 이미 종료된 커넥션에 보냈기에 서버는 요청을 처리 않고 connection reset by peer 메시지로 응답한다. 이 리셋 메시지는 입력 버퍼에 있는 데이터를 지운다.

결론적으로 데이터를 읽으려 하면, connection reset by peer 에러를 받게 될 것이고, 응답 데이터가 당신의 기기에 잘 도착하였어도 아직 읽히지 않은 버퍼에 있는 응답데이터는 사라지게 된다.

우아하게 커넥션 끊기

http 명세에는 클라나 서버가 예상치 않게 커넥션 끊어야 한다면 “우아하게 커넥션을 끊어야 한다”라 하지만, 정작 그 방법은 설명안한다.

일반적으로 우하한 끊기는 앱이 자신의 출력 채널을 먼저 끊고 다른 쪽에 있는 기기의 출력 채널이 끊기는 것을 기다리는 것. 양쪽에서 더는 데이터를 전송않을 것이라고 알려주면(예를 들어 출력 채널의 커넥션 끊기), 커넥션은 리셋의 위험없이 온전히 종료된다.

안타깝게도 상대방이 절반 끊기를 구현했다는 보장도 없고 절반 끊기를 했는지 검사해준다는 보장도 없다. 따라서 우아하게 끊고자 하는 앱은 출력 채널에 절반 끊기를 하고 난 후에도 데이터나 스트림 끝을 식별 위해 입력 채널에 대해 상태 검사를 주기적으로 해야한다. 만약 입력 채널이 특정 타임아웃 시간내에 끊어지지 않으면, 앱은 리소스 보호하기 위해 커넥션을 강제로 끊을 수 도 있다.

Notes

Explorer