왜 1x1 픽셀 GIF (웹 버그) 데이터를 제공합니까?

왜 1x1 픽셀 GIF (웹 버그) 데이터를 제공합니까?

---

많은 분석 및 추적 도구가 도메인 간 이벤트 저장 / 처리를 위해 1x1 GIF 이미지 (웹 버그, 사용자에게 보이지 않음)를 요청하고 있습니다.

이 GIF 이미지를 제공하는 이유는 무엇입니까? 503 Service Temporary Unavailable 또는 빈 파일 과 같은 일부 오류 코드를 단순히 반환 하는 것이 더 효율적이지 않습니까?

업데이트 : 더 명확히하기 위해 필요한 모든 정보 가 이미 요청 헤더에 전송 된 경우 GIF 이미지 데이터를 제공해야하는 이유를 묻습니다 . GIF 이미지 자체는 유용한 정보를 반환하지 않습니다.

---

Doug의 대답은 매우 포괄적입니다. 나는 추가 메모를 추가 할 것이라고 생각했습니다 (OP의 요청에 따라 내 의견에서)

Doug의 답변은 1x1 픽셀 비콘이 사용 목적으로 사용되는 이유를 설명합니다. 응답을 위해 HTTP 상태 코드 204, 콘텐츠 없음을 사용하고 이미지 본문을 보내지 않는 잠재적 인 대안 접근 방식을 설명 할 것이라고 생각했습니다.

204 내용 없음

서버가 요청을 수행했지만 엔티티 본문을 반환 할 필요가 없으며 업데이트 된 메타 정보를 반환 할 수 있습니다. 응답은 엔티티 헤더 형태의 새로운 또는 업데이트 된 메타 정보를 포함 할 수 있으며, 존재하는 경우 요청 된 변형과 연관되어야합니다.

기본적으로 서버는 요청을 수신하고 본문을 보내지 않기로 결정합니다 (이 경우 이미지를 보내지 않음). 그러나 에이전트에게 이것이 의식적인 결정임을 알리는 코드로 응답합니다. 기본적으로 긍정 응답하는 짧은 방법입니다.

에서 구글의 페이지 속도 문서 :

비동기 방식으로 페이지 뷰를 기록하는 한 가지 인기있는 방법은 사용자가 페이지를로드 할 때 로깅 서버에 알리는 JavaScript 스 니펫을 대상 페이지 하단 (또는 onload 이벤트 핸들러로)에 포함하는 것입니다. 이를 수행하는 가장 일반적인 방법은 "비콘"을 위해 서버에 요청을 구성하고 관심있는 모든 데이터를 비콘 리소스의 URL에 매개 변수로 인코딩하는 것입니다. HTTP 응답을 매우 작게 유지하려면 투명한 1x1 픽셀 이미지가 비콘 요청에 적합합니다. 약간 더 최적의 비콘은 1x1 GIF보다 약간 작은 HTTP 204 응답 ( "콘텐츠 없음")을 사용합니다.

시도해 본 적이 없지만 이론적으로는 Google Analytics의 경우 gif 자체를 전송하지 않고도 동일한 용도로 사용되므로 35 바이트를 절약 할 수 있습니다. (사물의 계획에서 Google Analytics가 하루에 수조 건의 조회수를 제공하지 않는 한 35 바이트는 실제로 아무것도 아닙니다.)

다음 코드로 테스트 할 수 있습니다.

var i = new Image(); 
i.src = "http://httpstat.us/204";

---

첫째, 나는 이전의 두 답변에 동의하지 않으며 둘 다 질문에 관여하지 않습니다.

1 픽셀 이미지는 HTTP 프로토콜에서 작업 할 때 웹 기반 분석 앱 (예 : Google Analytics)의 본질적인 문제 (클라이언트에서 서버로 데이터 전송 방법)를 해결합니다 .

프로토콜에서 설명하는 가장 간단한 방법은 가장 간단한 방법 (요청 본문을 포함하는 가장 간단한 방법)은 GET 요청 입니다. 이 프로토콜 방법에 따라 클라이언트는 서버에 리소스 요청을 시작합니다. 서버는 이러한 요청을 처리하고 적절한 응답을 반환합니다.

GA와 같은 웹 기반 분석 앱의 경우이 단방향 체계는 서버가 요청시 클라이언트에서 데이터를 검색하는 것을 허용하지 않는 것처럼 보이기 때문에 나쁜 소식입니다. 다시 말하지만 모든 서버가 할 수있는 것은 리소스를 공급하는 것뿐입니다. 요청하십시오.

그렇다면 클라이언트에서 서버로 데이터를 가져 오는 문제에 대한 해결책은 무엇일까요? HTTP 컨텍스트 내에는 GET (예 : POST) 이외의 다른 프로토콜 메서드가 있지만 여러 가지 이유로 제한된 옵션입니다 (양식 데이터 제출과 같은 드물고 전문적인 사용으로 입증 됨).

브라우저에서 GET 요청을 보면 요청 URL과 요청 헤더 (예 : Referer 및 User-Agent 헤더)로 구성되어 있고, 후자는 클라이언트에 대한 정보 (예 : 브라우저 유형 및 버전, 브라우저 언어, 운영 체제 등

다시 말하지만, 이것은 클라이언트가 서버로 보내는 요청의 일부입니다. 따라서 1 픽셀 gif에 동기를 부여하는 아이디어는 클라이언트가 웹 메트릭 데이터를 요청 헤더 안에 래핑 된 서버로 보내는 것입니다.

그렇다면 클라이언트가 리소스를 요청하여 메트릭 데이터를 전송하도록 "속일"수 있도록하는 방법은 무엇입니까? 그리고 클라이언트가 서버가 원하는 실제 데이터를 보내도록하는 방법은 무엇입니까?

Google Analytics가 좋은 예입니다. ga.js 파일 (웹 페이지의 작은 스크립트에 의해 클라이언트로의 다운로드가 트리거되는 큰 파일)에는 클라이언트가 특정 리소스에서 특정 리소스를 요청하도록 지시 하는 몇 줄의 코드가 포함되어 있습니다. 서버 (GA 서버) 및 요청 헤더에 래핑 된 특정 데이터를 전송합니다.

그러나이 요청의 목적은 실제로 리소스를 가져 오는 것이 아니라 서버로 데이터를 보내는 것이므로이 리소스는 가능한 한 작아야하며 웹 페이지에서 렌더링 될 때 표시되지 않아야합니다. 따라서 1 x 1 픽셀 투명 gif. 크기는 가능한 가장 작은 크기이고 형식 (gif)은 이미지 형식 중 가장 작습니다.

보다 정확하게는 모든 GA 데이터 (모든 단일 항목)가 조립되어 요청 URL의 쿼리 문자열 ( '?'뒤의 모든 항목)에 압축됩니다 . 그러나 해당 데이터가 클라이언트 (생성 된 위치)에서 GA 서버 (로그되고 집계되는 위치)로 이동하려면 HTTP 요청이 있어야합니다. 따라서 ga.js (다운로드되는 Google 애널리틱스 스크립트)는 페이지가로드 될 때 호출되는 함수의 결과로 클라이언트에 의해 캐시 됨)은 클라이언트에게 모든 분석 데이터 (예 : 쿠키, 위치 표시 줄, 요청 헤더 등)를 조립하도록 지시합니다.이를 단일 문자열로 연결합니다. URL ( * http : //www.google-analytics.com/__utm.gif* ?)에 검색어 문자열로 추가 하면 요청 URL이 됩니다.

브라우저에 표시된 웹 페이지에 대한 HTTP 요청을 볼 수있는 웹 브라우저 (예 : Safari의 Web Inspector , Firefox / Chrome Firebug 등)를 사용하여이를 증명하는 것은 쉽습니다 .

예를 들어, 회사 홈페이지에 대한 유효한 URL을 내 브라우저의 위치 표시 줄에 입력하면 해당 홈페이지가 반환되고 내 브라우저에 표시됩니다 (주요 분석 앱 중 하나 인 GA를 사용하는 웹 사이트 / 페이지를 선택했을 수 있습니다. , Omniture, Coremetrics 등)

내가 사용한 브라우저는 Safari 였기 때문에 메뉴 막대에서 Develop 을 클릭 한 다음 Show Web Inspector를 클릭했습니다 . Web Inspector의 맨 위 행에서 Resources 를 클릭하고 왼쪽 열에 표시된 리소스 목록에서 utm.gif 리소스를 찾아 클릭 한 다음 Headers 탭 을 클릭합니다 . 다음과 같은 내용이 표시됩니다.

Request URL:http://www.google-analytics.com/__utm.gif?
           utmwv=1&utmn=1520570865&
           utmcs=UTF-8&
           utmsr=1280x800&
           utmsc=24-bit&
           utmul=enus&
           utmje=1&
           utmfl=10.3%20r181&

Request Method:GET
Status Code:200 OK

Request Headers
    User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/533.21.1 
                 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

Response Headers
    Cache-Control:private, no-cache, no-cache=Set-Cookie, proxy-revalidate
    Content-Length:35
    Content-Type:image/gif
    Date:Wed, 06 Jul 2011 21:31:28 GMT

주목해야 할 핵심 사항은 다음과 같습니다.

1. 실제로 요청은 위의 첫 번째 줄인 * Request URL : http : //www.google-analytics.com/__utm.gif*에서 알 수 있듯이 utm.gif에 대한 요청이었습니다.

2. The Google Analytics parameters are clearly visible in the query string appended to the Request URL: e.g., utmsr is GA's variable name to refer to the client screen resolution, for me, shows a value of 1280x800; utmfl is the variable name for flash version, which has a value of 10.3, etc.

3. The Response Header called Content-Type (sent by the server back to the client) also confirms that the resource requested and returned was a 1x1 pixel gif: Content-Type:image/gif

This general scheme for transferring data between a client and a server has been around forever; there could very well be a better way of doing this, but it's the only way i know of (that satisfies the constraints imposed by a hosted analytics service).

---

Some browsers may display an error icon if the resource could not load. It makes debugging/monitoring the service also a little bit more complicated, you have to make sure that your monitoring tools treat the error as a good result.

OTOH you don't gain anything. The error message returned by the server/framework is typically bigger then the 1x1 image. This means you increase your network traffic for basically nothing.

---

Because such a GIF has a known presentation in a browser - it's a single pixel, period. Anything else presents a risk of visually interfering with the actual content of the page.

HTTP errors could appear as oversized frames of error text or even as a pop-up window. Some browsers may also complain if they receive empty replies.

In addition, in-page images are one of the very few data types allowed by default in all broswers. Anything else may require explicit user action to be downloaded.

---

This is to answer the OP's question - "why to serve GIF image data..."

Some users will put a simple img tag to call your event logging service -

<img src="http://www.example.com/logger?event_id=1234">

In this case, if you don't serve an image, the browser will show a placeholder icon that will look ugly and give the impression that your service is broken!

What I do is, look for the Accept header field. When your script is called via an img tag like this, you will see something like following in the header of the request -

Accept: image/gif, image/*
Accept-Encoding:gzip,deflate
...

When there is "image/"* string in the Accept header field, I supply the image, otherwise I just reply with 204.

---

Well the major reason is to attach the cookie to it so if users go from one side to another we still have the same element to attach cookie to.

---

You don't have to serve an image if you are using the Beacon API (https://w3c.github.io/beacon/) implementation method.

An error code would work if you have access to the log files of your server. The purpose of serving the image is to obtain more data about the user than you normally would with a log file.

---

@Maciej Perliński is basically correct, but I feel a detailed answer will be beneficial.

why 1x1 GIF and not a 204 No-Content status code?

204 No-Content enables the server to omit all response headers (Content-Type, Content-Length, Content-Encoding, Cache-Control etc...) and return an empty response body with 0 bytes (and saving a lot of unneeded bandwidth).

Browsers know to respect 204 No-Content responses, and not to expect/wait for response headers and response body.

if the server needs to set any response header (e.g. cache-control or cookie), he cannot use 204 No-Content because browsers will ignore any response header by design (according to the HTTP protocol spec).

why 1x1 GIF and not a Content-Length: 0 header with 200 OK status code?

Probably a mix of several issues, just to name a few:

• legacy browsers compatibility
• MIME type checks on browsers, 0 bytes is not a valid image.
• 200 OK with 0 bytes might not be fully supported by intermediate proxy servers and VPNs

참고URL : https://stackoverflow.com/questions/6638504/why-serve-1x1-pixel-gif-web-bugs-data-at-all