💻 HTTP #8: HTTP 조건부 요청

HTTP는 리소스들을 검사기 값을 이용해 비교함으로써 성공했을 지라도 요청의 결과가 변경될 수 있는 조건부 요청의 컨셉을 갖고 있다. 조건부 요청은 캐시를 갱신할 때, 다운로드를 이어할 때, 서버 상의 문서를 업로드/수정할 때 유용하다.

원칙

HTTP 조건부 요청은 특정 헤더 값에 의존하여 기존과는 다르게 실행되는 요청이다. 이 헤더들은 전제 조건을 정의하고 있는데, 요청의 결과는 전제 조건의 일치 여부에 따라 달라진다.

조건부 요청은 요청 메서드 그리고 전제 조건을 위해 사용되는 헤더 집합에 의해 정의된다.

• GET과 같은 safe 메서드의 경우, 오직 연관되어 있는 경우에만 조건부 요청이 회신하는데 사용될 수 있어 대역폭을 아끼게 된다.
• PUT와 같은 unsafe 메서드들의 경우, 그 요청의 원본 문서가 서버에 저장되어 있는 것과 동일한 경우에만 조건부 요청이 문서 업로드에 사용될 수 있다.

검사기

모든 조건부 요청들은 서버 상에 저장되어 있는 리소스가 특정 버전과 일치하는지를 검사하려고 한다. 따라서 조건부 요청은 리소스의 버전을 명시할 필요가 있습니다. 전체 리소스를 바이트 대 바이트로 비교하는 것은 불가능하기 때문에 요청은 버전을 뜻하는 값을 함께 전송한다: 이 값을 검사기라고 부른며 다음의 두 종류가 존재한다:

• last-modified 날짜: 문서의 최종 수정 일자
• entity tag (etag): 각 버전을 고유하게 나타내는 읽을 수 없는 문자열

동일 리소스의 버전 비교는 강한 검사와 약한 검사로 나뉘어진다. Last-Modified와 ETag는 검사의 두 종류를 모두 지원한다(검사기가 서버 상에서 구현되는 복잡도는 매우 다양하다). HTTP는 기본적으로 강한 검사를 사용하며, 약한 검사기가 사용될 수 있는 경우에는 W/를 붙여 이를 명시한다.

강한 검사

강한 검사는 리소스가 비교하려는 다른 리소스와 바이트 대 바이트로 동일한지를 보장한다. 예를 들어 다운로드를 이어할 때 사용된다. 조건부 헤더에 대해서 의무적이며, 다른 헤더들에 대해서는 기본값이다. 강한 검사는 매우 엄격하고 서버 레벨에서 보장하기는 매우 어려울 수도 있으나, 때로는 성능의 손실을 감수하더라도 어떤 경우에도 데이터 무손실을 보장한다. Last-Modified만을 이용해 강한 검사를 하기는 어렵다. 보통 리소스의 MD5 해시(혹은 유도물)를 가지고 ETag를 사용한다.

약한 검사

약한 검사는 강한 검사와 달리 두 리소스가 유사한 컨텐츠를 가지고 있으면 두 문서의 버전이 동일하다고 간주한다. 예를 들어, 기존의 페이지에서 날짜 혹은 광고만 다른 페이지가 있다고 가정할 때, 그 페이지는 강한 검사에서는 다르다고 판단되겠지만, 약한 검사에서는 기존의 페이지와 동일하다고 간주될 수 있다. 약한 검사를 만들어내는 etag 체계를 세우는 것은 페이지의 요소들의 중요성 인지를 끌어들이는 순간부터 복잡해질 수 있지만, 캐싱 성능을 최적화하는데 유용하다.

조건부 헤더

조건부 헤더는 조건부 요청을 이끌어 낸다.

• If-Match: 원격지 리소스의 ETag가 이 헤더에 나열된 것과 일치한다면 성공
• If-None-Match
• If-Modified-Since: 원격지의 리소스의 Last-Modified 날짜가 이 헤더 내에 주어진 것보다 좀 더 최근인 경우 성공
• If-Unmodified-Since
• If-Range: 하나의 단일 etag 혹은 하나의 날짜만을 가질 수 있다. 실패하면 범위 요청이 실패하고, 206 Partial Content 응답 대신 200 OK가 완전한 리소스와 함께 전송될 것이다.

유스 케이스

캐시 갱신

1. 캐시가 비어 있거나 없는 경우, 요청된 리소스는 200 OK의 상태로 회신된다. 리소스와 함께, 검사기가 헤더 내에 전송됩니다. 검사기는 해당 리소스와 함께 캐시되고, 캐시가 신선하지 않게 되었을 때 조건부 요청을 만들어 내는 데 사용될 것이다.
2. 캐시가 신선한 동안에는, 어떤 요청도 발급되지 않는다.
3. 캐시가 신선하지 않게 되면, 클라이언트는 캐시된 값을 직접 사용하지 않고, If-Modified-Since와 If-Match 헤더의 파라미터로 사용되는 검사기값을 이용해 조건부 요청을 전송한다.
   1. 리소스가 변경되지 않았다면, 서버는 304 Not Modified 응답을 회신하고, 이는 캐시를 다시 신선한 것으로 만들어주며, 클라이언트는 캐시된 리소스를 사용하게 된다. 추가적인 응답/요청 왕복이 이루어지지만, 연결을 통해 다시 전체 리소스를 받는 것보다는 효율적이다.
   2. 리소스가 변경되었다면, 서버는 리소스의 새로운 버전과 함께, 200 OK 응답을 회신한다.

이 메커니즘에서는 모든 브라우저가 캐시를 관리하고 있고, 조건부 요청을 보내, 웹 개발자는 추가조치를 취할 필요가 없다.

부분 다운로드의 통합

파일들의 부분적인 다운로드는 이전 동작을 계속하게 이어주는 HTTP의 기능으로, 이미 받아놓은 정보를 유지함으로써 대역폭과 시간을 절약해준다. 부분적인 다운로드를 지원하는 서버는 Accept-Ranges 헤더를 보냄으로써 이를 알린다. 클라이언트는 아직 전송받지 못한 범위와 함께 Ranges을 전송하여 다운로드를 이어나갈 수 있다.

이 원칙은 간단하지만 한 가지 문제점이 있다: 다운로드된 리소스가 두 다운로드 사이에 수정될 경우, 수신받던 범위는 리소스의 두 개의 서로 다른 버전과 상응하게 될 것이며 최종적인 문서는 오염될 것이다.

이를 방지하기 위해 조건부 요청이 사용되는데, 두 가지 방법이 있다.

1. If-Modified-Since와 If-Match 헤더를 사용하는 방법: 전제 조건이 실패할 경우 서버는 오류를 반환하고, 클라이언트는 다운로드를 처음부터 다시 시작한다. 그러라 이 방법은 추가적인 응답/요청 교환을 필요로 하고, 이는 성능 감소의 원인이 된다.
2. HTTP는 이것을 피하기 위한 특별한 헤더인 If-Range를 가지고 있다. If-Range를 사용할 경우 리소스가 변경되었을 때 1번처럼 서버에서 오류를 반환하고 클라이언트에서 다시 리소스 요청을 하는 과정이 생략된다. 클라이언트가 변경할 시 바로 처음부터 다운로드를 시작한다.

최적화된 잠금으로 업데이트 손실 문제 피하기

PUT 메서드를 이용해 원격 문서를 갱신하는 기능을 구현할 수 있다. 클라이언트는 원본 파일을 읽어들인 후 그것을 수정하고 최종적으로 서버로 수정된 파일을 내보낸다.

문제는 하나의 클라이언트가 리소스의 새로운 복사본을 지역적으로 수정하고 있는 동안에도, 두번째 클라이언트가 동일한 리소스를 내려받고 자신의 영역 내에서 동일한 작업을 할 수 있다. 어떤 클라이언트의 변경 사항이 유지될 지는 커밋하는 시점, 클라이언트와 서버의 성능, 클라이언트에서 문서를 수정하는 속도에 의해서도 달라진다. 중요한 것은 받아들여진 클라이언트의 변경 사항으로 모두 변경된다는 것이다. 이것을 race condition(경쟁상태)라고 하며 감지하고 디버깅하기 어려운 불확실한 동작을 유발한다.

두 클라이언트 중 하나를 불편하게 만들지 않고는 이를 해결할 수 있는 방법은 없다. 다만 업데이트 손실과 경쟁 상태는 피할 수는 있다. 조건부 요청은 최적화 잠금 알고리즘을 구현할 수 있도록 합니다. 잠금 메커니즘은 클라이언트들이 리소스의 복사본들을 갖고 로컬에서 그것을 수정하며 첫번째 클라이언트가 그 수정된 내용을 성공적으로 제출하고 나서 이전 버전이 된 리소스가 거절되도록 하여 모든 업데이트가 순차적으로 이루어질 수 있도록 하여 동시성을 제어할 수 있도록 해준다.

이 메커니즘은 If-Match나 If-Unmodified-Since 헤더를 사용해 구현한다. etag가 원본 파일과 일치하지 않거나 혹은 파일을 수신한 이후에 파일이 수정된 경우, 해당 변경 사항은 412 Precondition Failed 오류와 함께 거절될 것이다. 이후 현재 가장 최신의 버전으로부터 다시 시작하도록 클라이언트에게 알려주거나 “diff”를 보여주고 변경된 내용을 유지하도록 선택할 수 있게 도움을 줄 수 있다.

diff: 두 개의 파일 간 차이에 대한 정보를 출력하는 파일 비교 유틸리티이다. 일반적으로 하나의 파일 버전과 동일한 파일의 다른 버전 간의 변경 사항을 보여주는 데 쓰인다. diff는 문서 파일의 줄 사이 변경사항을 보여준다.

리소스의 첫번째 업로드 다루기

두 클라이언트가 업데이트를 동시에 실행하려고 하는 경우도 경쟁상태이다. 이를 방지하기 위해 조건부 요청을 사용할 수 있다: 어떤 etag든지 나타내는 '*'라고 하는 특별한 값을 If-None-Match에 추가하여, 리소스가 이전에 존재하지 않은 경우에만 요청이 성공하게 할 수 있다.