4-1 TCP 커넥션
전 세계 모든 HTTP 통신은, 지구상의 컴퓨터와 네트워크 장비에서 널리쓰이고 있는 패킷 교환 프로토콜들의 계층화된 집합인 TCP/IP를 통해 이루어진다.
•
클라이언트와 서버 컴퓨터간의 TCP커넥션이 맺어지면 메시지들은 손실 혹은 손상되거나 순서가 바뀌지않고 안전하게 전달된다.
•
URL을 입력받은 브라우저가 어떻게 작동하는지 단계별로 아래 사진으로 확인해보자
4.1.1 신뢰 할 수 있는 데이터 전송 통로인 TCP
•
TCP 커넥션은 인터넷을 안정적으로 연결해준다.
•
TCP는 HTTP에게 신뢰할만 한 통신방식 제공해준다.
•
TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확히 전달된다.
4.1.2 TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송된다.
TCP는 IP 패킷(혹은 IP 데이터그램)이라고 불리는 작은 조각을 통해 데이터를 전송한다.
•
HTTP와 HTTPS 네트워크 프로토콜 스택
ㅁ [ HTTP가 메시지를 전송하고자 할 경우 ]
1.
현재 연결되어있는 TCP 커넥션을 통해서 메시지 데이터의 내용을 순서대로 보낸다
2.
TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP패킷이라고 불리는 봉투에 담는다.
3.
인터넷을 통해 데이터를 전달한다.
위 모든 과정은 TCP/IP 소프트웨어에 의해 처리되며, 그 과정은 HTTP 프로그래머에게 보이지 않는다.
ㅁ [ 각 TCP 세그먼트는 하나의 IP주소 에서 다른 IP주소로 IP 패킷에 담겨 전달된다]
그렇다면 IP 패킷에는 어떠한 것들이 포함되어있을까? 크게 3가지 내용이 포함된다.
1.
IP 패킷헤더( 보통 20바이트 ) → 발신자와 목적지 IP주소, 크기 ,기타 플래그 정보 포함
2.
TCP 세그먼트 헤더 ( 보통20바이트 )
→ TCP 포트번호, TCP 제어플래그, 데이터 순서와 무결성을 검사하기위해 사용되는 숫자값을 포함
3.
TCP 데이터 조각( 0 혹은 그 이상의 바이트)
4.1.3 TCP 커넥션 유지하기
1.
IP주소 : 해당컴퓨터에 연결
2.
포트번호 : 해당 애플리케이션에 연결
3.
TCP 커넥션 : 4가지 값으로 식별 →<발신지 IP주소, 발신지 포트, 수신지 IP주소, 수신지 포트>
이 네 가지 값으로 유일한 커넥션을 생성한다. 서로 다른 두 개의 TCP 커넥션은 네 가지 주소 구성요소 값이 모두 같을 수 없다.
ex) 브라우저에서 한 탭에서 구글을 띄어놓고, 다른 탭에서 또 구글로 접속을 하려고 하면 새로운 포트 번호로 요청을 한다. 구글에서는 성능향상을 위해 다중커넥션을 만들어서 여러 데이터를 동시에 받게 되는데 이러한 경우엔 여러포트로 커넥션을 만들게 된다.
4.1.4 TCP 소켓 프로그래밍
운영체제는 TCP 커넥션의 생성과 관련된 여러기능을 제공한다.
어떤 기능들이 있는지 TCP 프로그래밍 인터페이스를 살펴보자.
소켓 API는 HTTP 프로그래머에게 TCP와 IP의 세부사항을 숨긴다.
ㅁ 소켓API를 사용하면 TCP 종단(endPoint)데이터 구조를 생성하고, 원격 서버의 TC 종단에 그 종단데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다.
TCP API는, 기본적인 네트워크의 프로토콜의 핸드셰이킹, 그리고 TCP 데이터 스트림과 IP 패킷간의 분할 및 재조립에 대한 모든 세부상항을 외부로부터 숨긴다.
4-2 TCP의 성능에 대한 고려
HTTP는 TCP 바로 위에 있는 계층이기 떄문에 HTTP 트랜잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받는다. 이 절에서는 TCP 커넥션의 성능에 관련된 주요 고려사항을 집중적으로 다룬다.
4.2.1 HTTP 트랜잭션 지연
아래 그림은 HTTP의 주요 커넥션, 전송, 처리의 지연을 보여준다.
트랜잭션을 처리하는 시간은 TCP 커넥션을 설정하고, 요청을 전송하고, 응답 메시지를 보내는 것에 비하면 상당히 짧다는 것을 알 수 있다. 클리아언트나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.
HTTP 트랜잭션을 지연시키는 원인은 여러 가지가 있다.
1.
클라이언트는 URI에서 웹 서버의 IP주소와 포트 번호를 알아내야 하는데, 해당 호스트에 방문한 적이 없으면 시간이 더 걸릴 것이다.
2.
클라이언트는 TCP 커넥션 요청을 서버에게 보내고 서버가 커넥션 허가 응답을 회신하기를 기다린다.
3.
커넥션이 맺어지면 클라이언트는 HTTP 요청을 새로 생성된 TCP 파이프를 통해 전송한다. 웹 서버는 데이터가 도착하는 데로 TCP 커넥션에서 요청 메시지를 읽고 처리한다. 요청 메시지가 인터넷을 통해 전달되고 서버에 의해서 처리되는 데 까지는 시간이 소요된다.
4.
웹 서버가 HTTP 응답을 보내는 것 역시 시간이 소요된다.
이런 TCP 네트워크 지연은 하드웨어의 성능, 네트워크와 서버의 전송 속도, 요청과 응답 메시지의 크기, 클라이언트와 서버 간의 거리에 따라 크게 달라진다. 또한 TCP 프로토콜의 기술적인 복잡성도 지연에 큰 영향을 끼친다.
4.2.2 성능 관련 중요 요소
여기서부터는 다음에 대해 알아볼 것이다.
•
TCP 커넥션의 핸드셰이크 설정
•
인터넷의 혼잡을 제어하기 위한 TCP의 느린 시작(slow-start)
•
데이터를 한데 모아 한 번에 전송하기 위한 네이글(nagle) 알고리즘
•
TCP의 편승(piggyback) 확인 응답(acknowledgment)을 위한 확인응답 지연 알고리즘
•
TIME_WAIT 지연과 포트 고갈
4.2.3 TCP 커넥션 핸드셰이크 지연
어떤 데이터를 전송하든 새로운 TCP 커넥션을 열 때면, TCP 소프트웨어는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환한다. 작은 크기의 데이터 전송에 커넥션이 사용된다면 이런 패킷 교환은 HTTP 성능을 크게 저하시킬 수 있다.
TCP 커넥션이 핸드셰이크를 하는 순서
1.
클라이언트는 새로운 TCP 커넥션을 생성하기 위해 작은 TCP 패킷을 서버에게 보낸다. 그 패킷은 'SYN'라는 특별한 프래그를 가지는데, 이 요청이 커넥션 생성 요청이라는 뜻이다. (a)
2.
서버가 그 커넥션을 받으면 몇 가지 커넥션 매개변수를 산출하고, 커넥션 요청이 받아들여졌음을 의미하는 'SYN'과 'ACK' 플래그를 포함한 TCP 패킷을 클라이언트에게 보낸다. (b)
3.
마지막으로 클라이언트는 커넥션이 잘 맺어졌음을 알리기 위해서 서버에게 다시 확인응답 신호를 보낸다. 오늘날의 TCP는 클라이언트가 이 확인응답 패킷과 함께 데이터를 보낼 수 있다. (c)
HTTP 트랜잭션이 아주 큰 데이터를 주고받지 않는 평범한 경우에는, SYN/SYN+ACK 핸드셰이크(그림에서 a,b)가 눈에 띄는 지연을 발생시킨다. TCP의 ACK 패킷(c)은 HTTP 요청 메시지 전체를 전달할 수 있을 만큼 큰 경우가 많고, 많은 HTTP 서버 응답 메시지는 하나의 IP 패킷에도 담길 수 있다.
결국, 크기가 작은 HTTP 트랜잭션은 50% 이상의 시간을 TCP를 구성하는 데 쓴다. 이후 절에서는 이러한 TCP 구성으로 인한 지연을 제거하기 위해서 HTTP가 이미 존재하는 커넥션을 어떻게 재활용하는지 알아볼 것이다.
4.2.4 확인응답 지연
인터넷 자체가 패킷 전송을 완벽히 보장하지는 않기 때문에, TCP는 성공적인 데이터 전송을 보장하기 위해서 자체적인 확인 체계를 가진다.
•
각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가진다.
•
각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인응답 패킷을 송신자에게 반환한다.
•
만약 송신자가 특정 시간 안에 확인응답 메시지를 받지 못하면 패킷이 파기되었거나 오류가 있는 것으로 판단하고 데이터를 다시 전송한다.
확인응답은 그 크기가 작기 때문에, TCP는 같은 방향으로 송출되는 데이터 패킷에 확인응답을 '편승(piggyback)' 시킨다. TCP는 송출 데이터 패킷과 확인응답을 하나로 묶음으로써 네트워크를 좀 더 효율적으로 사용한다. 확인응답이 같은 방향으로 가는 데이터 패킷에 편승되는 경우를 위해서, 많은 TCP 스택은 '확인응답 지연' 알고리즘을 구현한다. 확인응답 지연은 송출할 확인응답을 특정 시간동안 버퍼에 저장해 두고, 확인응답을 편승시키기 위한 송출 데이터 패킷을 찾는다. 만약 일정 시간 안에 송출 데이터 패킷을 찾지 못하면 확인응답은 별도 패킷을 만들어 전송된다.
하지만 요청과 응답 두 가지 형식으로만 이루어지는 HTTP 동작 방식은, 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시킨다. 따라서 확인응답 지연 알고리즘으로 인한 지연이 자주 발생한다. 운영체제에 따라 다르지만, 지연의 원이이 되는 확인응답 지연 관련 기능을 수정하거나 비활성화할 수 있다.
4.2.5 TCP 느린 시작(slow start)
•
TCP의 데이터 전송 속도는 TCP 커넥션이 만들어진 지 얼마나 지났는지에 따라 달라질 수 있다.
•
TCP 커넥션은 시간이 지나면서 자체적으로 '튜닝'되어서, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나간다.
•
이렇게 조율하는 것을 TCP 느린 시작이라고 부르며, 인터넷의 급작스러운 부하와 혼잡을 방지하는 데 쓰인다.
TCP 느린 시작은 TCP가 한 번에 전송할 수 있는 패킷의 수를 제한한다. 간단히 말해 패킷이 성공적으로 전달되는 각 시점에 송신자는 추가로 2개의 패킷을 더 전송할 수 있는 권한을 얻는다. 이를 '혼잡 윈도를 연다(opening the congestion window)'라고 한다.
이 혼잡제어 기능 때문에, 새로운 커넥션은 이미 어느 정도 데이터르르 주고받은 '튜닝'된 커넥션보다 느리다. '튜닝'된 커넥션은 더 빠르기 때문에, HTTP에는 이미 존재하는 커넥션을 재사용하는 기능이 있다. 이 장의 뒤에서 HTTP의 "지속 커넥션"을 다룰 것이다.
4.2.6 네이글(Nagle) 알고리즘과 TCP_NODELAY
•
애플리케이션이 어떤 크기의 데이터든지 TCP 스택으로 전송할 수 있도록, TCP는 데이터 스트림 인터페이스를 제공한다.
•
하지만 각 TCP 세그먼트는 40바이트 상당의 플래그와 헤더를 포함하여 전송하기 때문에, TCP가 작은 크기의 데이터를 포함한 많은 수의 패킷을 전송한다면 네트워크 성능은 크게 떨어진다.
네이글 알고리즘은 네트워크 효율을 위해서, 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합친다.
네이글 알고리즘은 세그먼트가 최대 크기가 되지 않으면 전송을 하지 않는다. 다만 다른 모든 패킷이 확인응답을 받았을 경우에는 최대 크기보다 작은 패킷의 전송을 허락한다. 다른 패킷들이 아직 전송 중이면 데이터는 버퍼에 저장된다. 전송되고 나서 확인응답을 기다리던 패킷이 확인응답을 받았거나 전송하기 충분할 만큼의 패킷이 쌓였을 때 버퍼에 저장되어 있던 데이터가 전송된다.
네이글 알고리즘은 HTTP 성능 관련해 여러 문제를 발생시킨다.
1.
크기가 작은 HTTP 메시지는 패킷을 채우지 못하기 때문에, 앞으로 생길지 생기지 않을지 모르는 추가적인 데이터를 기다리며 지연될 것이다.
2.
네이글 알고리즘은 확인응답 지연과 함께 쓰일 경우 형편없이 동작한다. 네이글 알고리즘은 확인응답이 도착할 때까지 데이터의 전송을 멈추고 있는 반면, 확인응답 지연 알고리즘은 확인응답을 100~200밀리초 지연시킨다.
HTTP 애플리케이션은 성능 향상을 위해서 HTTP 스택에 TCP_NODELAY 파라미터 값을 설정하여 네이글 알고리즘을 비활성화하기도 한다. 이 설정을 했다면, 작은 크기의 패킷이 너무 많이 생기지 않도록 큰 크기의 데이터 덩어리를 만들어야 한다.
4.2.7 TIME_WAIT의 누적과 포트 고갈
TIME_WAIT 포트 고갈은 성능 측정 시에 심각한 성능 저하를 발생시키지만, 보통 실제 상황에서는 문제를 발생시키지 않는다.
•
TCP 커넥션의 종단에서 TCP 커넥션을 끊으면, 종단에서는 커넥션의 IP 주소와 포트 번호를 메모리의 작은 제어영역(control block)에 기록해 놓는다.
•
이 정보는 같은 주소와 포트 번호를 사용하는 새로운 TCP 커넥션이 일정 시간 동안에는 생성되지 않게 하기 위한 것으로, 보통 세그먼트의 최대 생명주기에 두 배 정도(보통 2분)의 시간 동안만 유지된다.
•
이는 이전 커넥션과 관련된 패킷이 그 커넥션과 같은 주소와 포트 번호를 가지는 새로운 커넥션에 삽입되는 문제를 방지한다.
•
실제로 이 알고리즘은 특정 커넥션이 생성되고 닫힌 다음, 그와 같은 IP 주소와 포트 번호를 가지는 커넥션이 2분 이내에 또 생성되는 것을 막아준다.
클라이언트가 서버에 접속할 때마다, 유일한 커넥션을 생성하기 위해 새로운 발신지 포트를 쓴다. 하지만 사용할 수 있는 발신지 포트의 수는 제한되어 있고 2MSL초 동안 커넥션이 재사용될 수 없으므로, 초당 500개로 커넥션이 제한된다. 서버가 초당 500개 이상의 트랜잭션을 처리할 만큼 빠르지 않다면 TIME_WAIT 포트 고갈은 일어나지 않는다. 이 문제를 해결하기 위해 부하를 생성하는 장비를 더 많이 사용하거나 클라이언트와 서버가 더 많은 커넥션을 맺을 수 있도록 여러 개의 가상 IP 주소를 쓸 수도 있다.
4.3.1 흔히 잘못 이해하는 Connection 헤더
HTTP는 클라이언트와 서버 사이에 프록시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락한다. HTTP 메시지는 클라이언트에서 서버까지 중개 서버들을 하나하나 거치면서 전달 된다.
어떤 경우에는, 두 개의 인접한 HTTP 애플리케이션이 현재 맺고 있는 커넥션에만 적용될 옵션을 지정해야 할 때가 있다. HTTP Connection 헤더 필드는 커넥션 토큰을 쉼표로 구분하여 가지고 있으며, 그 값들은 다른 커넥션에 전달되지 않는다. 예를 들어, 다음 메시지를 보낸 다음 끊어져야 할 커넥션은 Connection: close 라고 명시할 수 있다.
Connection 헤더에는 다음 세 가지 종류의 토큰이 전달될 수 있기 때문에 혼란스러울 수 있다.
•
HTTP 헤더 필드 명은, 이 커넥션에만 해당되는 헤더들을 나열한다.
•
임시적인 토큰 값은, 커넥션에 대한 비표준 옵션을 의미한다.
•
close 값은, 커넥션이 작업이 완료되면 종료되어야 함을 의미한다.
커넥션 토큰이 HTTP 헤더 필드 명을 가지고 있으면, 해당 필드들은 현재 커넥션만을 위한 정보이므로 다음 커넥션에 전달하면 안 된다. Connection 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳으로 전달하는 시점에 삭제되어야 한다. Connection 헤더는 홉별(hop-by-hop) 헤더 명을 기술하는데, 이것을 '헤더 보호하기'라 한다. Connection 헤더에 명시된 헤더들이 전달되는 것을 방지하기 때문이다.
HTTP 애플리케이션이 Connection 헤더와 함께 메시지를 전달 받으면, 수신자는 송신자에게서 온 요청에 기술되어 있는 모든 옵션을 적용한다. 그리고 다음 홉(hop)이 메시지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술되어 있던 모든 헤더를 삭제한다.
4.3.2 순차적인 트랜잭션 처리에 의한 지연
커넥션 관리가 제대로 이루어지지 않으면 TCP 성능이 매우 안 좋아질 수 있다. 예를 들어 3개의 이미지가 있는 웹페이지가 있다고 해보자. 브라우저가 이 페이지를 보여주려면 네 개의 HTTP 트랜잭션을 만들어야 한다. 하나는 해당 HTML을 받기 위해, 나머지 세 개는 이미지를 받기 위한 것이다. 각 트랜잭션이 새로운 커넥션을 필요로 한다면, 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생할 것이다.
HTTP 커넥션의 성능을 향상시킬 수 있는 여러 최신 기술이 있다.
•
병렬(parallel) 커넥션: 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청
•
지속(persistent) 커넥션: 커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션의 재활용
•
파이프라인(pipelined) 커넥션: 공유 TCP 커넥션을 통한 병렬 HTTP 요청
•
다중(multiplexed) 커넥션: 요청과 응답들에 대한 중재
4.4 병렬 커넥션
HTTP는 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 한다.
4.4.1 병렬 커넥션은 페이지를 더 빠르게 내려 받는다
단일 커넥션의 대역폭 제한과 커넥션이 동작하지 않고 있는 시간을 활용하면, 객체가 여러 개 있는 웹페이지를 더 빠르게 내려받을 수 있을 것이다. 하나의 커넥션으로 객체들을 로드할 때의 대역폭 제한과 대기 시간을 줄일 수 있다면 더 빠르게 로드할 수 있을 것이다. 각 커넥션의 지연 시간을 겹치게 하면 총 지연 시간을 줄일 수 있고, 클라이언트의 인터넷 대역폭을 한 개의 커넥션이 다 써버리는 것이 아니라면 나머지 객체를 내려받는 데에 남은 대역폭을 사용할 수 있다.
4.4.2 병렬 커넥션이 항상 더 빠르지는 않다
클라이언트의 네트워크 대역폭이 좁을 때는 대부분 시간을 데이터를 전송하는 데만 쓸 것이다. 여러 개의 객체를 병렬로 내려받는 경우, 이 제한된 대역폭 내에서 각 객체를 전송받는 것은 느리기 때문에 성능상의 장점은 거의 없어진다.
또한 다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킨다. 복잡한 웹페이지는 수십 개에서 수 백 개의 객체를 포함한다. 클라이언트가 수백 개의 커넥션을 열 수도 있겠지만, 서버는 다른 여러 새용자의 요청도 함께 처리해야 하기 때문에 수백 개의 커넥션을 허용하는 경우는 드물다.
브라우저는 실제로 병렬 커넥션을 사용하긴 하지만 적은 수(6~8개)의 병렬 커넥션만을 허용한다. 서버는 특정 클라이언트로부터 과도한 수의 커넥션이 맺어졌을 경우, 그것을 임의로 끊어버릴 수 있다.
4.4.3 병렬 커넥션은 더 빠르게 '느껴질 수' 있다
병렬 커넥션이 페이지를 항상 더 빠르게 로드하지는 않는다. 병렬 커넥션이 실제로 페이지를 더 빠르게 내려받는 것은 아니지만, 화면에 여러 개의 객체가 동시에 보이면서 내려받고 있는 상황을 볼 수 있기 때문에 사용자들은 더 빠르게 내려받고 있는 것처럼 느낄 수 있다.
4.5 지속 커넥션
웹 클라이언트는 보통 같은 사이트에 여러 커넥션을 맺는다. 예를 들어 웹페이지에 첨부된 이미지들 대부분은 같은 웹 사이트에 있고, 상당수의 하이퍼링크도 같은 사이트를 가리킨다. 따라서 서버에 HTTP 요청을 하기 시작한 애플리케이션은 웹페이지 내의 이미지 등을 가져오기 위해서 그 서버에 또 요청하게 될 것이다. 이 속성을 사이트 지역성(site locality)라 부른다.
따라서 HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다. 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 부른다. 비지속 커넥션은 각 처리가 끝날 때마다 커넥션을 끊지만, 지속 커넥션은 클라이언트나 서버가 커넥션을 끊기 전까지는 트랜잭션 간에도 커넥션을 유지한다.
해당 서버에 이미 맺어져 있는 지속 커넥션을 재사용함으로써, 커넥션을 맺기 위한 준비작업에 따르는 시간을 절약할 수 있다. 게다가 이미 맺어져 있는 커넥션은 TCP의 느린 시작으로 인한 지연을 피함으로써 더 빠르게 데이터를 전송할 수 있다.
4.5.1 지속 커넥션 vs 병렬 커넥션
병렬 커넥션은 여러 객체가 있는 페이지를 더 빠르게 전송한다. 하지만 병렬 커넥션은 다음과 같은 몇 가지 단점이 있다.
•
각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
•
각각의 새로운 커넥션은 TCP 느린 시작 때문에 성능이 떨어진다.
•
실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있다.
지속 커넥션은 병렬 커넥션에 비해 몇 가지 장점이 있다. 커넥션을 맺기 위한 사전 작업과 지연을 줄여주고, 튜닝된 커넥션을 유지하며, 커넥션의 수를 줄여준다. 하지만 지속 커넥션을 잘못 관리할 경우, 계속 연결된 상태로 있는 수많은 커넥션이 쌓이게 될 것이다. 이는 로컬의 리소스 그리고 원격의 클라이언트와 서버의 리소스에 불필요한 소모를 발생시킨다.
두 가지 지속 커넥션 타입이 있는데, HTTP/1.0+에서는 'keep-alive' 커넥션이 있고 HTTP/1.1에는 '지속' 커넥션이 있다.
4.5.2 HTTP/1.0+의 Keep-Alive 커넥션
keep-alive 커넥션의 성능상의 장점은 아래 그림에서 볼 수 있다. 같은 네 개의 HTTP 트랜잭션에 대해서, 연속적으로 네 개의 커넥션을 생성하여 처리하는 방식과 하나의 지속 커넥션으로만 처리하는 방식을 비교하였다. 커넥션을 맺고 끊는 데 필요한 작업이 없어서 시간이 단축되었다.
4.5.3 Keep-Alive 동작
keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Coneection: Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 응답에 Coneection: Keep-Alive 헤더가 없으면, 클라이언트는 서버가 keep-alive를 지원하지 않으며, 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라 추정한다.
4.5.4 Keep-Alive 옵션
Keep-Alive 헤더는 커넥션을 유지하기를 바라는 요청일 뿐이다. 클라이언트나 서버가 keep-avlie 요청을 받았다고 해서 무조건 그것을 따를 필요는 없다. 언제든지 현재의 kepp-alive 커넥션을 끊을 수 있으며 keep-alive 커넥션에서 처리되는 트랜잭션의 수를 제한할 수도 있다.
keep-alive의 동작은 Keep-Alive 헤더의 쉼표로 구분된 옵션들로 제어할 수 있다.
•
timeout 파라미터는 Keep-Alive 응답 헤더를 통해 보낸다. 이는 커넥션이 얼마간 유지될 것인지를 의미한다.
•
max 파라미터는 Keep-Alive 응답 헤더를 통해 보낸다. 이는 커넥션이 몇 개의 HTTP 트랜잭션을 처리할 때까지 유지될 것인지를 의미한다.
•
Keep-Alive 헤더는 진단이나 디버깅을 주목적으로 하는, 처리되지는 않는 임의의 속성들을 지원하기도 한다. 그 문법은 이름[=값] 같은 식이다.
Keep-Alive 헤더 사용은 선택사항이지만, Connection: Keep-Alive 헤더가 있을 때만 사용할 수 있다.
// 서버가 약 5개의 추가 트랜잭션이 처리될 동안 커넥션을 유지하거나, 2분 동안 커넥션을 유지하라는 내용의 Keep-Alive 응답 헤더
Connection: Kepp-Alive
Keep-Alive: max=5, timeout=120
4.5.5 Keep-Alive 커넥션 제한과 규칙
•
keep-alive는 HTTP/1.0에서 기본으로 사용되지는 않는다. 클라이언트는 keep-alive 커넥션을 사용하기 위해 Connection: Keep-Alive 요청 ㅇ헤더를 보내야 한다.
•
커넥션을 계속 유지하려면 모든 메시지에 Connection: Keep-Alive 헤더를 포함해 보내야 한다.
•
클라이언트는 Connection: Keep-Alive 응답 헤더가 없는 것을 보고 서버가 응답 후에 커넥션을 끊은 것임을 알 수 있다.
•
커넥션이 끊어지기 전에 엔티티 본문의 길이를 알 수 있어야 커넥션을 유지할 수 있다. 이 말은 엔티티 본문이 정확한 Content-Length 값과 함께 멀티파트 미디어 형식을 가지거나 청크 전송 인코딩으로 인코드 되어야 함을 뜻한다. keep-alive 커넥션에서 잘못된 Content-length 값을 보내는 것은 좋지 않은데, 트랜잭션이 끝나는 시점에 기존 메시지의 끝과 새로운 메시지의 시작점을 정확히 알 수 없기 때문이다.
•
프락시와 게이트웨이는 Connection 헤더의 규칙을 철저히 지켜야 한다. 프락시와 게이트웨이는 메시지를 전달하거나 캐시에 넣기 전에 Connection 헤더에 명시된 모든 헤더 필드와 Connection 헤더를 제거해야 한다.
•
정석대로라면, keep-alive 커넥션은 Connection 헤더를 인식하지 못하는 프락시 서버와는 맺어지면 안 된다. 이는 뒤에서 설명할 멍청한(dumb) 프락시로 인해 발생할 문제를 예방하기 위한 것이지만, 현실적으로 그것이 쉽진 않다.
4.5.6 Keep-Alive와 멍청한(dumb) 프락시
웹 클라이언트의 요청에 Connection: Keep-Alive 헤더가 있으면, 클라이언트가 현재 연결하고 있는 TCP 커넥션을 끊지 않고 계속 유지하려는 것이다. 헤더 이름이 'connection'인 것도 이 때문이다. 클라이언트가 웹 서버에 요청을 보내는 중이라면, 그 요청으로 생긴 커넥션이 keep-alive가 되기를 원한다는 의미로 Connection: Keep-Alive 헤더를 전송한다. 서버가 keep-alive를 지원한다면 Connection: Keep-Alive를 응답에 포함할 것이고, 지원하지 않으면 포함하지 않을 것이다.
Connection 헤더의 무조건 전달
특히 문제는 프락시에서 시작되는데, 프락시는 Connection 헤더를 이해하지 못해서 해당 헤더들을 삭제하지 않고 요청 그대로를 다음 프락시에 전달한다. 오래되고 단순한 수많은 프락시들이 Connection 헤더에 대한 처리 없이 요청을 그대로 전달한다. 웹 클라이언트가 무조건 전달을 하는 멍청한 프락시를 거쳐 웹 서버에 메시지를 전송한다고 생각해보자. 그 상황은 아래 그림에서 볼 수 있다.
이 그림에서 일어나는 일은 다음과 같다.
1.
(a) 웹 클라이언트는 프락시에 Connection: Keep-Alive 헤더와 함께 메시지를 보내고, 커넥션을 유지하기를 요청한다. 클라이언트는 커넥션을 유지하자는 요청이 받아들여졌는지 확인하기 위해 응답을 기다린다.
2.
(b) 멍청한 프락시는 요청받은 HTTP의 Connection 헤더를 이해하지 못한다. 프락시는 keep-alive가 무엇인지 무르기 때문에, 다음 서버에 메시지를 그대로 전달한다. 하지만 Connection 헤더는 홉별(hop-by-hop) 헤더다(이는 오직 한 개의 전송 링크에만 적용되며 다음 서버로 전달되어서는 안된다). 여기서부터 문제가 시작된다.
3.
(b)에서 보이는 것처럼, 전달된 HTTP 요청이 서버에 도착한다. 웹 서버가 프락시로부터 Connection: Keep-Alive 헤더를 받으면, 웹 서버는 프락시(기존에 클라이언트로부터 받았을 때와 같이)가 커넥션으르 유지하자고 요청하는 것으로 잘못 판단하게 된다. (c)와 같이 웹 서버는 문제될 게 없기 때문에, 프락시와 커넥션을 유지하는 것에 동의를 하고 Connection: Keep-Alive 헤더를 포함하여 응답한다. 웹 서버는 프락시와 keep-alive 커넥션이 맺어져 있는 상태로 keep-alive 규칙에 맞게 통신을 하는 것으로 판단한다. 하지만 프락시는 keep-alive를 전혀 이해하지 못한다.
4.
(b)에서 멍청한(dumb) 프락시는 서버로부터 받은 Connection: Keep-Alive 헤더를 포함하고 있는 응답 메시지를 클라이언트에게 전달한다. 클라이언트는 이 헤더를 통해 프락시가 커넥션을 유지하는 것에 동의했다고 추정한다. 이 시점에 클라이언트와 서버는 커넥션을 유지하고 있다고 생각하지만, 정작 프락시는 keep-alive를 전혀 이해하지 못한다.
5.
프락시는 keep-alive를 전혀 모르지만, 받았던 모든 데이터를 그대로 클라이언트에게 전달하고 나서 서버가 커넥션을 끊기를 기다린다. 하지만 서버는 프락시가 자신에게 커넥션을 유지하기를 요청한 것으로 알고 있기 때문에 커넥션을 끊지 않는다. 따라서 프락시는 커넥션이 끊어지기 전까지는 계속 커넥션이 끊어지기를 기다리게 된다.
6.
(d)와 같이 클라이언트가 응답 메시지를 받으면, 다음 요청을 보내기 시작하는데, 커넥션이 유지되고 있는 프락시에 그 요청을 보낸다. 프락시는 같은 커넥션상에서 다른 요청이 오는 경우는 예상하지 못하기 때문에, 그 요청은 프락시로부터 무시 되고 브라우저는 아무런 응답 없이 로드 중이라는 표시만 나온다.
7.
이런 잘못된 통신 때문에, 브라우저는 자신이나 서버가 타임아웃이 나서 커넥션이 끊길 때까지 기다린다.
프락시와 홉별 헤더
이런 종류의 잘못된 통신을 피하려면, 프락시는 Connection 헤더와 Connection 헤더에 명시된 헤더들은 절대 전달하면 안 된다. 따라서 프락시가 Connection: Keep-Alive 헤더를 받으면 Connection 헤더뿐만 아니라 Keep-Alive란 이름의 헤더도 전달하면 안 된다.
또한, Connection 헤더 값으로 명시되지 않는, Proxy-Authenticate, Proxy-Connection, Transfer-Encoding, Upgrade와 같은 홉별 헤더들 역시 전달하거나 캐시하면 안 된다.
4.5.7 Proxy-Connection 살펴보기
넷스케이프의 브라우저 및 프락시 개발자들은 모든 웹 애플리케이션이 HTTP 최신 버전을 지원하지 않아도, 모든 헤더를 무조건 전달하는 문제를 해결할 수 있는 차선책을 제시하였다. 그 차선책은, 클라이언트의 요청이 중개서버를 통해 이어지는 경우 모든 헤더를 무조건 전달하는 문제를 해결하기 위해 Proxy-Connection이라는 헤더를 사용하는 것이다. Proxy-Connection은 프락시를 별도로 설정할 수 있는 현대의 브라우저들에서 지원하고 있으며, 많은 프락시들도 이것을 인식한다.
멍청한 프락시는 Connection: Keep-Alive 같은 홉별 헤더를 무조건 전달하기 때문에 문제를 일으킨다. 홉별 헤더들은 한 개의 특정 커넥션에서 쓰이고 그 이후에는 전달하면 안 된다. 홉별 헤더를 전달받은 서버가 그 헤더를 자신과 프락시 간의 커넥션에 대한 것으로 오해하면서 문제가 생기는 것이다.
넷스케이프는 멍청한 프락시 문제를 해결하기 위해 브라우저에서 일반적으로 전달하는 Connection 헤더 대신 비표준인 Proxy-Connection 확장 헤더를 프락시에게 전달한다. 프락시가 Proxy-Connection 헤더를 무조건 전달하더라도 웹 서버는 그것을 무시하기 때문에 별문제가 되지 않는다. 하지만 영리한 프락시(지속 커넥션 핸드셰이킹을 이해할 수 있는)라면, 의미 없는 Proxy-Connection 헤더를 Connection헤더로 바꿈으로써 원하던 효과를 얻게 될 것이다.
아래 그림의 ab는 무조건 전달로 인해 Proxy-Connection 헤더가 웹 서버에 전달되더라도 아무런 문제가 생기지 않는다는 것으르 보여준다. Proxy-Connection 헤더가 웹 서버에 전달되더라도 클라이언트와 프락시 사이 혹은 프락시와 서버 사이에 keep-alive 커넥션이 맺어지지 않는다. eh에서 영리한 프락시는 Proxy-Connection 헤더가 keep-alive를 요청하는 것임을 인식하여, keep-alive 커넥션을 맺기 위해 자체적으로 Connection: Keep-Alive 헤더를 웹 서버에 전송한다.
이 방식은 클라이언트와 서버 사이에 한 개의 프락시만 있는 경우에만 동작한다. 하지만 멍청한 프락시의 양옆에 영리한 프락시가 있다면 아래 그림과 같이 잘못된 헤더를 만들어내는 문제가 발생한다.
게다가 문제를 발생시키는 프락시들은 방화벽, 캐시 서버, 혹은 리버스 프락시 서버 가속기와 같이 네트워크상에서 '보이지 않는' 경우가 많다.
4.6 파이프라인 커넥션
•
HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝할 수 있다.
•
첫 번째 요청이 서버에 도착하면, 거기에 이어 두 번째와 세 번째 요청이 전달될 수 있다.
•
POST 요청과 같은 비멱등요청은 반복해서 보낼 경우 문제가 생기기 때문에 파이프라인을 통해서 보내면 안 된다.
◦
멱등(idempotent)한 요청 : GET, HEAD 와 같이 요청한 횟수와 상관없이 항상 같은 결과를 반환하는 요청
4.7 커넥션 끊기에 대한 미스터리
커넥션을 언제 끊는가에 관해선 명확한 기준이 없다.
•
우아한 커넥션 끊기
◦
TCP 커넥션은 양방향이다. 한쪽 출력 큐에 있는 데이터는 다른 쪽 입력 큐에 보내질 것이다.
◦
전체 끊기와 절반 끊기
▪
전체끊기 close() : 입력, 출력 채널의 모든 커넥션을 끊음
▪
절반끊기 shutdown() : 입력, 출력 채널 중 하나를 개별적으로 끊음
◦
우아하게 커넥션 끊기
▪
일반적으로 애플리케이션 자신의 출력 채널을 먼저 끊고 다른 쪽 기기의 출력 채널이 끊기는 것을 기다리는 것
