Tại sao lại phân phát dữ liệu GIF (lỗi web) 1x1 pixel?

Nhiều công cụ phân tích và theo dõi đang yêu cầu hình ảnh GIF 1x1 (lỗi web, ẩn đối với người dùng) để lưu trữ / xử lý sự kiện trên nhiều miền.

Tại sao phải phân phát ảnh GIF này? Sẽ không hiệu quả hơn nếu chỉ trả lại một số mã lỗi như 503 Dịch vụ Tạm thời Không khả dụng hoặc tệp trống?

Cập nhật: Để rõ ràng hơn, tôi đang hỏi tại sao phải phân phát dữ liệu ảnh GIF khi tất cả thông tin cần thiết đã được gửi trong tiêu đề yêu cầu. Bản thân ảnh GIF không trả về bất kỳ thông tin hữu ích nào.

Câu trả lời của Doug khá toàn diện; Tôi nghĩ rằng tôi sẽ thêm một ghi chú bổ sung (theo yêu cầu của OP, ngoài bình luận của tôi)

Câu trả lời của Doug giải thích tại sao đèn hiệu 1x1 pixel được sử dụng cho mục đích mà chúng được sử dụng; Tôi nghĩ rằng tôi sẽ phác thảo một phương pháp thay thế tiềm năng, đó là sử dụng Mã trạng thái HTTP 204, Không có nội dung, để phản hồi và không gửi nội dung hình ảnh.

204 Không có nội dung

Máy chủ đã hoàn thành yêu cầu nhưng không cần trả lại phần thân thực thể và có thể muốn trả về thông tin cập nhật. Phản hồi CÓ THỂ bao gồm siêu thông tin mới hoặc cập nhật ở dạng tiêu đề thực thể, nếu có thì NÊN được liên kết với biến thể được yêu cầu.

Về cơ bản, máy chủ nhận được yêu cầu và quyết định không gửi nội dung (trong trường hợp này là không gửi hình ảnh). Nhưng nó trả lời bằng một mã để thông báo cho đại lý rằng đây là một quyết định có ý thức; về cơ bản, nó chỉ là một cách ngắn gọn hơn để trả lời khẳng định.

Từ tài liệu Tốc độ trang của Google :

Một cách phổ biến để ghi lại lượt xem trang theo kiểu không đồng bộ là bao gồm đoạn mã JavaScript ở cuối trang đích (hoặc dưới dạng trình xử lý sự kiện khi tải), thông báo cho máy chủ ghi nhật ký khi người dùng tải trang. Cách phổ biến nhất để thực hiện việc này là tạo một yêu cầu tới máy chủ cho một "beacon" và mã hóa tất cả dữ liệu quan tâm dưới dạng các tham số trong URL cho tài nguyên beacon. Để giữ cho phản hồi HTTP rất nhỏ, hình ảnh 1x1 pixel trong suốt là một ứng cử viên tốt cho yêu cầu báo hiệu. Báo hiệu tối ưu hơn một chút sẽ sử dụng phản hồi HTTP 204 ("không có nội dung") nhỏ hơn một chút so với GIF 1x1.

Tôi chưa bao giờ thử nó, nhưng về lý thuyết, nó sẽ phục vụ cùng một mục đích mà không yêu cầu truyền bản thân gif, giúp bạn tiết kiệm 35 byte, trong trường hợp của Google Analytics. (Trong sơ đồ của mọi thứ, trừ khi Google Analytics của bạn đang phục vụ hàng nghìn tỷ lượt truy cập mỗi ngày, thì 35 byte thực sự không là gì cả.)

Bạn có thể kiểm tra nó bằng mã này:

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

Đầu tiên, tôi không đồng ý với hai câu trả lời trước - cả hai đều không liên quan đến câu hỏi.

Hình ảnh một pixel giải quyết vấn đề nội tại đối với các ứng dụng phân tích dựa trên web (như Google Analytics) khi làm việc trong Giao thức HTTP - cách chuyển dữ liệu (chỉ số web) từ máy khách đến máy chủ .

Phương thức đơn giản nhất trong số các phương thức được mô tả bởi Giao thức, phương thức đơn giản nhất (ít nhất là phương thức đơn giản nhất bao gồm phần thân yêu cầu) là yêu cầu GET . Theo phương thức Giao thức này, máy khách khởi tạo yêu cầu tới máy chủ về tài nguyên; máy chủ xử lý các yêu cầu đó và trả lại các phản hồi thích hợp.

Đối với một ứng dụng phân tích dựa trên web, như GA, lược đồ đơn hướng này là một tin xấu, vì nó dường như không cho phép máy chủ truy xuất dữ liệu từ máy khách theo yêu cầu - một lần nữa, tất cả các máy chủ có thể làm là cung cấp tài nguyên không yêu cầu họ.

Vậy đâu là giải pháp cho vấn đề lấy dữ liệu từ máy khách về máy chủ? Trong ngữ cảnh HTTP có các phương thức Giao thức khác ngoài GET (ví dụ: POST) nhưng đó là một tùy chọn hạn chế vì nhiều lý do (bằng chứng là nó được sử dụng không thường xuyên và chuyên biệt như gửi dữ liệu biểu mẫu).

Nếu bạn nhìn vào Yêu cầu GET từ trình duyệt, bạn sẽ thấy nó bao gồm URL yêu cầu và Tiêu đề yêu cầu (ví dụ: Người giới thiệu và Tiêu đề tác nhân người dùng), phần sau chứa thông tin về máy khách - ví dụ: loại trình duyệt và phiên bản, ngôn ngữ trình duyệt, hệ điều hành, v.v.

Một lần nữa, đây là một phần của Yêu cầu mà máy khách gửi đến máy chủ. Vì vậy, ý tưởng thúc đẩy gif một pixel là để khách hàng gửi dữ liệu chỉ số web đến máy chủ, được bao bọc bên trong Tiêu đề yêu cầu.

Nhưng sau đó làm thế nào để khách hàng Yêu cầu một tài nguyên để nó có thể bị "lừa" gửi dữ liệu số liệu? Và làm thế nào để máy khách gửi dữ liệu thực tế mà máy chủ muốn?

Google Analytics là một ví dụ điển hình: tệp ga.js (tệp lớn có tải xuống khách hàng được kích hoạt bởi một tập lệnh nhỏ trong trang web) bao gồm một vài dòng mã hướng khách hàng yêu cầu một tài nguyên cụ thể từ một máy chủ (máy chủ GA) và để gửi dữ liệu nhất định được bao bọc trong Tiêu đề yêu cầu.

Nhưng vì mục đích của Yêu cầu này không thực sự là để lấy tài nguyên mà là để gửi dữ liệu đến máy chủ, tài nguyên này phải càng nhỏ càng tốt và nó sẽ không hiển thị khi được hiển thị trong trang web - do đó, 1 x 1 pixel gif trong suốt. Kích thước là kích thước nhỏ nhất có thể và định dạng (gif) là nhỏ nhất trong số các định dạng hình ảnh.

Chính xác hơn, tất cả dữ liệu GA - mọi mục đơn lẻ - đều được tập hợp và đóng gói thành chuỗi truy vấn của URL yêu cầu (mọi thứ sau dấu '?'). Nhưng để dữ liệu đó đi từ máy khách (nơi nó được tạo) đến máy chủ GA (nơi nó được ghi lại và tổng hợp) thì phải có Yêu cầu HTTP, vì vậy ga.js (tập lệnh google analytics được tải xuống, trừ khi nó được khách hàng lưu vào bộ nhớ cache, do một hàm được gọi khi tải trang) hướng khách hàng tập hợp tất cả dữ liệu phân tích - ví dụ: cookie, thanh vị trí, tiêu đề yêu cầu, v.v. - nối nó thành một chuỗi duy nhất và nối nó dưới dạng một chuỗi truy vấn vào một URL ( * http: //www.google-analytics.com/__utm.gif* ?) và đó sẽ trở thành URL yêu cầu .

Thật dễ dàng để chứng minh điều này bằng cách sử dụng bất kỳ trình duyệt web nào cho phép bạn xem Yêu cầu HTTP cho trang web được hiển thị trong trình duyệt của bạn (ví dụ: Trình kiểm tra web của Safari , Firefox / Chrome Firebug , v.v.).

Ví dụ: tôi đã nhập url hợp lệ đến trang chủ của công ty vào thanh vị trí của trình duyệt, trang này sẽ trả về trang chủ đó và hiển thị nó trong trình duyệt của tôi (tôi có thể đã chọn bất kỳ trang web / trang nào sử dụng một trong những ứng dụng phân tích chính, GA , Omniture, Coremetrics, v.v.)

Trình duyệt tôi đã sử dụng là Safari, vì vậy tôi đã nhấp vào Phát triển trong thanh trình đơn, sau đó nhấp vào Hiển thị Trình kiểm tra web . Trên hàng trên cùng của Trình kiểm tra Web, bấm vào Tài nguyên , tìm và bấm vào tài nguyên utm.gif từ danh sách tài nguyên được hiển thị trên cột bên trái, sau đó bấm vào tab Tiêu đề . Điều đó sẽ cho bạn thấy một cái gì đó như thế này:

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

Những điểm chính cần lưu ý là:

1. Thực tế, Yêu cầu là một yêu cầu cho utm.gif, được chứng minh bằng dòng đầu tiên ở trên: * URL yêu cầu: http: //www.google-analytics.com/__utm.gif*.

2. Các thông số Google Analytics hiển thị rõ ràng trong chuỗi truy vấn được nối vào URL yêu cầu : ví dụ: utmsr là tên biến của GA để chỉ độ phân giải màn hình máy khách, đối với tôi, hiển thị giá trị 1280x800; utmfl là tên biến cho phiên bản flash, có giá trị 10,3, v.v.

3. Các đáp ứng Tiêu đề gọi là Content-Type (gửi qua các máy chủ lại cho khách hàng) cũng xác nhận rằng các tài nguyên được yêu cầu và trở lại là một gif 1x1 pixel: Content-Type: image / gif

Sơ đồ chung này để truyền dữ liệu giữa máy khách và máy chủ đã tồn tại vĩnh viễn; rất có thể có một cách tốt hơn để làm điều này, nhưng đó là cách duy nhất mà tôi biết (đáp ứng các ràng buộc do một dịch vụ phân tích được lưu trữ áp đặt).

Một số trình duyệt có thể hiển thị biểu tượng lỗi nếu tài nguyên không tải được. Nó làm cho việc gỡ lỗi / giám sát dịch vụ cũng phức tạp hơn một chút, bạn phải đảm bảo rằng các công cụ giám sát của bạn xử lý lỗi là một kết quả tốt.

OTOH bạn không đạt được gì cả. Thông báo lỗi do máy chủ / khung trả về thường lớn hơn hình ảnh 1x1. Điều này có nghĩa là bạn tăng lưu lượng truy cập mạng về cơ bản không có gì.

Bởi vì một GIF như vậy có một bản trình bày đã biết trong trình duyệt - đó là một pixel, dấu chấm. Bất kỳ thứ gì khác đều có nguy cơ can thiệp trực quan vào nội dung thực tế của trang.

Lỗi HTTP có thể xuất hiện dưới dạng khung văn bản lỗi quá khổ hoặc thậm chí dưới dạng cửa sổ bật lên. Một số trình duyệt cũng có thể phàn nàn nếu họ nhận được câu trả lời trống.

Ngoài ra, hình ảnh trong trang là một trong số rất ít kiểu dữ liệu được phép theo mặc định trong tất cả các nhà quảng cáo. Mọi thứ khác có thể yêu cầu hành động rõ ràng của người dùng để tải xuống.

Đây là câu trả lời cho câu hỏi của OP - "tại sao phải phân phát dữ liệu ảnh GIF ..."

Một số người dùng sẽ đặt một thẻ img đơn giản để gọi dịch vụ ghi sự kiện của bạn -

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

Trong trường hợp này, nếu bạn không phân phối hình ảnh, trình duyệt sẽ hiển thị biểu tượng giữ chỗ trông xấu xí và tạo ấn tượng rằng dịch vụ của bạn bị hỏng!

Điều tôi làm là tìm trường tiêu đề Chấp nhận . Khi tập lệnh của bạn được gọi qua thẻ img như thế này, bạn sẽ thấy thứ gì đó giống như sau trong tiêu đề của yêu cầu:

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

Khi có chuỗi "image / " * trong trường tiêu đề Chấp nhận , tôi cung cấp hình ảnh, nếu không, tôi chỉ trả lời bằng 204.

Lý do chính là để đính kèm cookie vào đó, vì vậy nếu người dùng đi từ bên này sang bên khác, chúng tôi vẫn có cùng một yếu tố để đính kèm cookie.

Bạn không phải phân phát hình ảnh nếu đang sử dụng Beacon API ( https://w3c.github.io/beacon/ phương pháp triển khai ).

Mã lỗi sẽ hoạt động nếu bạn có quyền truy cập vào tệp nhật ký của máy chủ của mình. Mục đích của việc cung cấp hình ảnh là thu được nhiều dữ liệu về người dùng hơn so với cách bạn làm với tệp nhật ký.

@Maciej Perliński về cơ bản là đúng, nhưng tôi cảm thấy một câu trả lời chi tiết sẽ có lợi.

tại sao lại là 1x1 GIF chứ không phải 204 No-Contentmã trạng thái?

204 No-Content cho phép máy chủ bỏ qua tất cả các tiêu đề phản hồi (Content-Type, Content-Length, Content-Encoding, Cache-Control, v.v.) và trả về nội dung phản hồi trống với 0 byte (và tiết kiệm nhiều băng thông không cần thiết).

Các trình duyệt biết tôn trọng 204 No-Contentphản hồi và không mong đợi / chờ đợi tiêu đề phản hồi và nội dung phản hồi.

nếu máy chủ cần đặt bất kỳ tiêu đề phản hồi nào (ví dụ cache-controlhoặc cookie), máy chủ không thể sử dụng 204 No-Contentvì trình duyệt sẽ bỏ qua bất kỳ tiêu đề phản hồi nào theo thiết kế (theo thông số giao thức HTTP).

tại sao lại là 1x1 GIF chứ không phải Content-Length: 0tiêu đề có 200 OKmã trạng thái?

Có thể là sự kết hợp của một số vấn đề, chỉ để kể tên một số:

• khả năng tương thích của các trình duyệt kế thừa
• Loại MIME kiểm tra trên các trình duyệt, 0 byte không phải là hình ảnh hợp lệ.
• 200 OK với 0 byte có thể không được máy chủ proxy trung gian và VPN hỗ trợ đầy đủ