http HEAD 대 GET 성능

가능한 한 빨리 예 또는 아니오로 대답하면되는 REST 웹 서비스를 설정하고 있습니다.

HEAD 서비스를 디자인하는 것이 가장 좋은 방법 인 것 같지만 GET 요청을 수행하는 것보다 시간이 많이 걸릴지 알고 싶습니다.

내 서버에서 열리거나 닫히지 않는 본문 스트림이 있다고 가정합니다 (약 1 밀리 초?). 반환 할 바이트의 양이 매우 적기 때문에 전송에서 IP 패킷 번호로 시간을 얻을 수 있습니까?

귀하의 답변에 미리 감사드립니다!

편집하다:

컨텍스트를 더 설명하려면 :

• 활성 상태 인 경우 일부 프로세스를 실행하는 REST 서비스 집합이 있습니다.
• 이 모든 첫 번째 서비스의 상태를 나타내는 또 다른 REST 서비스가 있습니다.

마지막 서비스는 매우 많은 클라이언트 집합에 의해 매우 자주 호출되기 때문에 (5ms마다 한 번의 호출이 예상 됨) HEAD 메서드를 사용하는 것이 유용한 최적화가 될 수 있는지 궁금합니다. 응답 본문에는 약 250자가 반환됩니다. HEAD 메서드는 최소한 이러한 250 개의 문자를 전송하지만 그 영향은 무엇입니까?

두 가지 방법 (HEAD 대 GET)의 차이를 벤치마킹하여 호출 횟수를 1000 번 실행했지만 전혀 이득이 없습니다 (<1ms) ...

RESTful URI는 서버에서 "자원"을 나타내야합니다. 리소스는 종종 데이터베이스의 레코드 또는 파일 시스템의 파일로 저장됩니다. 리소스가 크거나 서버에서 검색 속도가 느린 경우가 아니면 HEAD대신을 사용하여 측정 가능한 이득을 보지 못할 수 있습니다 GET. 메타 데이터를 검색하는 것이 전체 리소스를 검색하는 것보다 빠르지 않을 수 있습니다.

두 옵션을 모두 구현하고 벤치마킹하여 어느 것이 더 빠른지 확인할 수 있지만, 마이크로 최적화보다는 이상적인 REST 인터페이스를 설계하는 데 집중할 것입니다. 깨끗한 REST API는 일반적으로 더 빠르거나 빠르지 않을 수있는 kludgey API보다 장기적으로 더 가치가 있습니다. 나는의 사용을 권장하지 않고 HEAD단지 "올바른"디자인 인 경우에만 사용하도록 제안합니다.

필요한 정보가 실제로 HTTP 헤더에 멋지게 표현 될 수있는 리소스에 대한 메타 데이터이거나 리소스가 있는지 여부를 확인하는 경우 HEAD잘 작동 할 수 있습니다.

예를 들어 리소스 123이 존재하는지 확인한다고 가정합니다. A 200는 "예"를 404의미 하고 a 는 "아니오"를 의미합니다.

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

그러나 REST 서비스에서 원하는 "예"또는 "아니오"가 메타 데이터가 아닌 리소스 자체의 일부인 경우 GET.

요청자가 요청한 것과 동일한 질문을 찾을 때이 답변을 찾았습니다. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 에서도 이것을 찾았습니다 .

HEAD 메서드는 서버가 응답에서 메시지 본문을 반환하지 않아야한다는 점을 제외하고 GET과 동일합니다. HEAD 요청에 대한 응답으로 HTTP 헤더에 포함 된 메타 정보는 GET 요청에 대한 응답으로 전송 된 정보와 동일해야합니다 (SHOULD). 이 방법은 엔티티 바디 자체를 전송하지 않고 요청이 암시하는 엔티티에 대한 메타 정보를 얻는 데 사용할 수 있습니다. 이 방법은 유효성, 접근성 및 최근 수정을 위해 하이퍼 텍스트 링크를 테스트하는 데 자주 사용됩니다.

요청자의 질문에 대한 정답은 REST 프로토콜이 나타내는 내용에 따라 달라진다는 것 같습니다. 예를 들어, 내 특별한 경우에 내 REST 프로토콜은 상당히 큰 (10K 이상) 이미지를 검색하는 데 사용됩니다. 이러한 리소스를 지속적으로 확인하고 요청 헤더를 사용한다면 w3.org의 권장 사항에 따라 HEAD 요청을 사용하는 것이 합리적입니다.

이러한 접근 방식을 강력히 권장하지 않습니다.

RESTful 서비스는 HTTP 동사 의미를 존중해야합니다. GET 동사는 리소스의 콘텐츠를 검색하기위한 것이며 HEAD 동사는 콘텐츠를 반환하지 않으며 예를 들어 리소스가 변경되었는지 확인하고, 크기 또는 유형을 파악하고, 리소스가 있는지 확인하는 데 사용할 수 있습니다. 존재합니다.

그리고 기억하세요 : 초기 최적화는 모든 악의 근원입니다.

GET 요청 대신 HEAD 요청을 사용하면 성능이 거의 변하지 않습니다.

또한 REST-ful을 원하고 데이터를 GET하려는 경우 HEAD 요청 대신 GET 요청을 사용해야합니다.

GET은 머리 + 몸통을 가져오고 HEAD는 머리 만 가져옵니다. 어느 쪽이 더 빠른지는 의견의 문제가되어서는 안됩니다. 나는 위의 찬성 답변을 이해하지 않습니다. 이 목적을 위해 HEAD로 이동하는 것보다 META 정보를 찾고 있다면.

'바디 스트림이 열리고 닫히는'문제를 이해하지 못합니다. 응답 본문은 http 응답 헤더와 동일한 스트림에 있으며 두 번째 연결을 생성하지 않습니다 (그런데 3-6ms 범위에 더 가깝습니다).

이것은 중요하거나 측정 가능한 차이를 만들지 않는 무언가에 대한 매우 조기 최적화 시도처럼 보입니다. 실제 차이점은 일반적으로 REST와의 적합성이며 GET을 사용하여 데이터를 가져 오는 것이 좋습니다.

내 대답은 아니오입니다. GET을 사용하면 HEAD를 사용하면 성능이 향상되지 않습니다.

HEAD 요청은 응답 본문이 비어 있다는 점을 제외하면 GET 요청 과 같습니다 . 이러한 종류의 요청은 파일에 대한 메타 데이터 만 원하는 경우에 사용할 수 있지만 파일의 모든 데이터를 전송할 필요는 없습니다.

성능을 직접 측정하기 위해 작은 테스트를 쉽게 할 수 있습니다. 본문에 'Y'또는 'N'만 반환하면 이미 열린 스트림에 추가되는 단일 추가 바이트이기 때문에 성능 차이는 무시할 수 있다고 생각합니다.

더 정확하기 때문에 GET도 함께 갈 것입니다. HTTP 헤더로 콘텐츠를 반환해서는 안되며 메타 데이터 만 반환해야합니다.