为什么要提供1x1像素的GIF（网络臭虫）数据呢？ [英] Why serve 1x1 pixel GIF (web bugs) data at all?
问题描述
为什么为什么要服务这个GIF图像？简单地返回一些错误代码，比如<503> Service Temporary Unavailable 或空文件 / p>
更新：为了更清楚一点，我问为什么在所有必需的信息已被发送时为GIF图像数据提供服务在请求标题中。 GIF图片本身并没有返回任何有用的信息。
Doug的回答非常全面;我想我会添加一个附加说明（在OP的请求中，关于我的评论）
Doug的答案解释了为什么1x1像素信标被用于他们的目的用于;我想我会概述一种潜在的替代方法，即使用HTTP状态代码204，无内容作为响应，而不发送图像主体。
204无内容
完成请求
，但不需要返回
实体主体，并且可能想要返回
更新的元信息。响应
可以包含新的或更新的
元信息，形式为
实体标题，如果存在的话
应该与
请求的变体相关联。
基本上，服务器接收到请求，并决定不发送一个正文（在这种情况下，不发送图像）。但它回复了一个代码，告知代理人这是一个有意识的决定;基本上，它只是一个较短的方式来回应肯定。
从 Google's Page Speed文档：
$ b
一种以异步方式记录页面
视图的流行方式是
在目标页面的
底部包含JavaScript片段（或者作为
onload事件处理程序），当用户加载
页面时通知
日志记录服务器。执行
的最常见方法是为
服务器构建一个beacon请求，并将所有
感兴趣的数据编码为
中的参数信标资源。为了使b $ b保持HTTP响应非常小，
透明1x1像素图像对于信标请求来说是好的
候选者。
稍微更优的信标将使用
和HTTP 204响应（无内容）
，它比1x1
GIF略小。
我从来没有尝试过它，但理论上它应该达到相同的目的，而不需要传输gif本身，从而节省了35个字节，就Google而言Analytics（分析）。 （在这个计划中，除非您的Google Analytics每天提供数万亿次点击，否则35个字节实际上什么都没有。）
您可以使用此代码对其进行测试：
var i = new Image（）;
i.src =http://httpstat.us/204;
Many analytic and tracking tools are requesting 1x1 GIF image (web bug, invisible for the user) for cross-domain event storing/processing.
Why to serve this GIF image at all? Wouldn't it be more efficient to simply return some error code such as 503 Service Temporary Unavailable or empty file?
Update: To be more clear, I'm asking why to serve GIF image data when all information required has been already sent in request headers. The GIF image itself does not return any useful information.
Doug's answer is pretty comprehensive; I thought I'd add in an additional note (at the OP's request, off of my comment)
Doug's answer explains why 1x1 pixel beacons are used for the purpose they are used for; I thought I'd outline a potential alternative approach, which is to use HTTP Status Code 204, No Content, for a response, and not send an image body.
204 No Content
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
Basically, the server receives the request, and decides to not send a body (in this case, to not send an image). But it replies with a code to inform the agent that this was a conscious decision; basically, its just a shorter way to respond affirmatively.
From Google's Page Speed documentation:
One popular way of recording page views in an asynchronous fashion is to include a JavaScript snippet at the bottom of the target page (or as an onload event handler), that notifies a logging server when a user loads the page. The most common way of doing this is to construct a request to the server for a "beacon", and encode all the data of interest as parameters in the URL for the beacon resource. To keep the HTTP response very small, a transparent 1x1-pixel image is a good candidate for a beacon request. A slightly more optimal beacon would use an HTTP 204 response ("no content") which is marginally smaller than a 1x1 GIF.
I've never tried it, but in theory it should serve the same purpose without requiring the gif itself to be transmitted, saving you 35 bytes, in the case of Google Analytics. (In the scheme of things, unless you're Google Analytics serving many trillions of hits per day, 35 bytes is really nothing.)
You can test it with this code:
var i = new Image();
i.src = "http://httpstat.us/204";
这篇关于为什么要提供1x1像素的GIF（网络臭虫）数据呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
