รหัสสถานะ HTTP 200 (แคช) กับรหัสสถานะ 304 ต่างกันอย่างไร


201

ฉันใช้ปลั๊กอิน "Page Speed" ของ Google สำหรับ Firefox เพื่อเข้าถึงเว็บไซต์ของฉัน

ส่วนประกอบบางอย่างในหน้าของฉันถูกระบุว่าเป็นสถานะ HTTP:

200 200 (แคช) 304

ด้วย "ความเร็วหน้า" ของ Google

สิ่งที่ฉันสับสนคือความแตกต่างระหว่าง 200 (แคช) กับ 304

ฉันรีเฟรชหน้าเว็บหลายครั้ง (แต่ยังไม่ได้ล้างแคช) และดูเหมือนว่า favicon.ico ของฉันและภาพไม่กี่ภาพจะเป็นสถานะ = 200 (แคช) ในขณะที่ภาพอื่น ๆ เป็นสถานะ http 304

ฉันไม่เข้าใจว่าทำไมถึงแตกต่าง

อัปเดต :

ใช้ Google "Page Speed" ฉันได้รับ "200 (แคช)" สำหรับhttp://example.com/favicon.icoรวมถึงhttp://cdn.example.com/js/ga.js

แต่ฉันได้รับสถานะ http "304" สำหรับhttp://cdn.example.com/js/combined.min.js

ฉันไม่เข้าใจว่าเพราะเหตุใดฉันจึงมีไฟล์ JavaScript สองไฟล์อยู่ในไดเรกทอรี / js / เดียวกันหนึ่งรายการส่งคืนสถานะ http 304 และอีกไฟล์หนึ่งส่งคืนรหัสสถานะ 200 (แคช)

คำตอบ:


220

รายการที่มีรหัส "200 (แคช)" ได้รับการตอบสนองโดยตรงจากแคชเบราว์เซอร์ของคุณซึ่งหมายความว่าคำขอต้นฉบับสำหรับรายการนั้นถูกส่งคืนโดยมีส่วนหัวที่ระบุว่าเบราว์เซอร์สามารถแคชได้ (เช่นวันที่ในอนาคตExpiresหรือCache-Control: max-ageส่วนหัว) เวลาที่คุณทริกเกอร์คำขอใหม่วัตถุแคชเหล่านั้นยังคงถูกเก็บไว้ในแคชในเครื่องและยังไม่หมดอายุ

ในทางกลับกัน 304s เป็นการตอบสนองของเซิร์ฟเวอร์หลังจากที่เบราว์เซอร์ตรวจสอบว่ามีการแก้ไขไฟล์ตั้งแต่รุ่นสุดท้ายที่แคชหรือไม่ (คำตอบคือ "ไม่")

เพื่อประสิทธิภาพเว็บที่ดีที่สุดคุณควรปิดการใช้งานอนาคตExpires:หรือCache-Control: max-ageส่วนหัวสำหรับเนื้อหาทั้งหมดและเมื่อจำเป็นต้องเปลี่ยนเนื้อหาเปลี่ยนชื่อไฟล์จริงของเนื้อหาหรือต่อท้ายสตริงเวอร์ชันเพื่อขอเนื้อหานั้น สิ่งนี้ไม่จำเป็นต้องมีการร้องขอใด ๆ เว้นแต่จะมีการเปลี่ยนแปลงเนื้อหาจากแคชในเวอร์ชันแน่นอน (ไม่จำเป็นต้องตอบกลับ 304) Google มีรายละเอียดเพิ่มเติมเกี่ยวกับการใช้แคชอย่างถูกต้องในระยะยาว


2
ดังนั้นจะมีอะไรดีไปกว่านี้จากมุมมองความเร็ว ... "200 (แคช)" หรือ "304" ข้อความสถานะ http
แฮงค์

22
200 แคช บางบันทึกที่ดีเกี่ยวกับเรื่องนี้ที่นี่: developer.yahoo.com/performance/rules.html#expires คุณต้องการเวลาที่หมดอายุให้นานที่สุดเท่าที่จะเป็นไปได้สำหรับสินทรัพย์ของคุณ แต่ต้องสมดุลกับความจริงที่ว่าคุณสูญเสียการควบคุมด้วยวิธีนี้ สิ่งหนึ่งที่คุณสามารถทำได้คือการตั้งค่าการหมดอายุที่ยาวนานในไฟล์จากนั้นเมื่อต้องการเพิ่มหมายเลขเวอร์ชันเนื้อหาสำหรับไฟล์เหล่านั้น ตัวอย่างเช่นคุณสามารถรวม style.css? v1 และการเพิ่มขึ้นในองค์ประกอบ <link> เพื่อ style.css? v2 เมื่อมีการเปลี่ยนแปลง
30490 Ben Regenspan

1
ความยุติธรรมเหตุใดจึงต้องรายงาน Firebug ว่าสำหรับ ga.js นั้นถูกดึงมาจากแคชในท้องถิ่น (สถานะ = 200 แคช) ในขณะที่ collab.min.js รายงานสถานะ 304 http สิ่งที่แปลกคือไฟล์ทั้งสองเป็นไฟล์ประเภทเดียวกัน (JavaScript) และอยู่ในไดเรกทอรีเซิร์ฟเวอร์เดียวกัน คุณจะคิดว่าทั้งสองจะเป็นได้ทั้ง 200 หรือ 304 และไม่แตกต่างกัน
แฮงค์

8
max-ageและageหัวรวมยังสามารถทำให้ 200 (แคช) ผลถ้ามีค่าน้อยกว่าage max-ageข้อยกเว้นหนึ่งคือเมื่อผู้ใช้คลิกที่ปุ่มรีเฟรชเบราว์เซอร์ซึ่งในกรณีนี้จะมีการส่งส่วนหัว 304
yitwail

2
HTML5 Boilerplate แนะนำกับการใช้วิธีการสตริงแบบสอบถามของแคช - จะดีกว่าที่จะเปลี่ยนhref, url,และsrcการอ้างอิงไปยังแต่ละไฟล์ที่จะรวมถึง 'ลายนิ้วมือ' (ทั้งกัญชาของไฟล์หรือจำนวนเพิ่มขึ้นง่าย) แล้วบอกเซิร์ฟเวอร์ เพื่อตัดลายนิ้วมือนั้นและเพียงแค่ให้บริการstyle.cssหรืออะไรก็ตาม หากคุณไม่สามารถทำได้บนเซิร์ฟเวอร์ให้ระบบสร้างของคุณเปลี่ยนชื่อไฟล์จริงด้วยลายนิ้วมือ
iono

62

200 (แคช) หมายถึง Firefox กำลังใช้งานเวอร์ชันแคชในเครื่อง สิ่งนี้เร็วที่สุดเพราะไม่มีการร้องขอไปยังเว็บเซิร์ฟเวอร์

304 หมายความว่า Firefox กำลังส่งคำขอแบบมีเงื่อนไข "If-Modified-Since" ไปยังเว็บเซิร์ฟเวอร์ หากไฟล์นั้นไม่ได้รับการอัพเดตนับตั้งแต่วันที่ส่งโดยเบราว์เซอร์เว็บเซิร์ฟเวอร์จะส่งคืนการตอบกลับ 304 ซึ่งบอกให้ Firefox ใช้แคชเวอร์ชันของมันเป็นหลัก มันไม่เร็วเท่า 200 (แคช) เพราะคำขอยังคงถูกส่งไปยังเว็บเซิร์ฟเวอร์ แต่เซิร์ฟเวอร์ไม่ต้องส่งเนื้อหาของไฟล์

สำหรับคำถามสุดท้ายของคุณฉันไม่รู้ว่าทำไมไฟล์ JavaScript สองไฟล์ในไดเรกทอรีเดียวกันจึงแสดงผลลัพธ์ที่ต่างกัน


18

เรื่องนี้ทำให้ฉันเป็นเวลานานเกินไป สิ่งแรกที่ฉันจะยืนยันคือคุณไม่ได้โหลดหน้าเว็บซ้ำโดยคลิกที่ปุ่มรีเฟรชซึ่งจะออกคำขอแบบมีเงื่อนไขสำหรับทรัพยากรและจะส่งคืน 304s สำหรับองค์ประกอบของหน้าหลาย ๆ หน้า แทนที่จะขึ้นไปที่แถบ url ให้เลือกหน้าและกด Enter ราวกับว่าคุณเพิ่งพิมพ์ URL เดียวกันอีกครั้งซึ่งจะช่วยให้คุณทราบถึงสิ่งที่แคชได้ดีขึ้น บทความนี้อธิบายถึงความแตกต่างระหว่างคำขอแบบมีเงื่อนไขและไม่มีเงื่อนไขและวิธีการที่ปุ่มรีเฟรชส่งผลกระทบต่อพวกเขา: http://blogs.msdn.com/b/ieinternals/archive/2010/07/08/technical-information-about- เงื่อนไข-http ร้องขอและที่รีเฟรช button.aspx


1
ฉันไม่สามารถอธิบายได้ว่าฉันใช้เวลานานแค่ไหนในการพยายามพิจารณา 304 สถานะของคำขอไปยัง CDN แม้ว่าคุณจะตอบบิตคำถามที่แตกต่างคุณสมควรได้รับรางวัล :-)
Peeech

คุณพูดถูก: ความแตกต่างในรหัสเกี่ยวข้องกับความจริงที่ว่าคุณกำลังโหลดซ้ำหรือไม่หน้าเดียวกัน หากฉันโหลดหน้าเว็บอีกครั้งฉันเห็นในเครือข่ายของเบราว์เซอร์ตรวจสอบรหัส 304 แต่ถ้าฉันเข้าถึง URL อื่นซึ่งใช้ไฟล์เดียวกันนี้ฉันเห็นในเครือข่ายของเบราว์เซอร์ตรวจสอบรหัส 200 (จากแคช) ในกรณีของฉัน URL อื่น ๆ เป็นเพียงสตริงแบบสอบถามต่อท้าย URL ดั้งเดิม (หน้านั้นคือ เป็นหลักเดียวกัน)
aldemarcalazans

8

HTTP 304 คือ "ไม่แก้ไข" เว็บเซิร์ฟเวอร์ของคุณบอกเบราว์เซอร์ว่า "ไฟล์นี้ไม่เปลี่ยนแปลงตั้งแต่ครั้งสุดท้ายที่คุณขอ" ในขณะที่ HTTP 200 บอกเบราว์เซอร์ว่า "นี่เป็นการตอบสนองที่สำเร็จ" ซึ่งควรส่งคืนเมื่อเป็นครั้งแรกที่เบราว์เซอร์ของคุณเข้าถึงไฟล์หรือครั้งแรกที่มีการเข้าถึงสำเนาที่แก้ไข

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับรหัสสถานะตรวจสอบhttp://en.wikipedia.org/wiki/List_of_HTTP_status_codes


นั่นคือความเข้าใจของฉันเช่นกัน ... ซึ่งเป็นเหตุผลที่ฉันระบุไว้ในโพสต์ดั้งเดิมของฉันว่าฉันได้รีเฟรชหน้าเว็บของฉันหลายครั้งและยังคงได้รับ "200 (แคช)" สำหรับ favicon.ico เดียวกันและ JavaScript เฉพาะที่ฉันมี แปลกมาก
แฮงค์

2
200 จริง ๆ แล้วไม่ได้หมายความว่าแคช แต่มันก็หมายความว่าตกลง มีโอกาสเกิดขึ้นที่การกำหนดค่าเซิร์ฟเวอร์ของคุณไม่ได้บอกเบราว์เซอร์ให้แคชไฟล์ ico และ js ของคุณอย่างชัดเจนซึ่งจะทำให้มันส่งคืนรหัสสถานะ 200
richleland

นี่ไม่ใช่กรณี b / c ใน JavaScript บางอันของฉันฉันได้รับ 304 และ JavaScript อื่น ๆ ที่ฉันได้รับ "200 (แคช)" JavaScript ทั้งหมดอยู่ในไดเรกทอรีเว็บเซิร์ฟเวอร์เดียวกัน example.com/js/
Hank

ฉันควรเพิ่ม 200 (แคช) เพียงหมายความว่าแคชในเครื่องและไม่ทำการร้องขอไปยังเซิร์ฟเวอร์ซึ่งจะเร็วกว่าไปที่เซิร์ฟเวอร์และรับการตอบสนอง 304
richleland

ฉันได้อัปเดตโพสต์ดั้งเดิมของฉันเพื่อแสดงไซต์สดและ JavaScript ที่เป็นปัญหา โปรดดูโพสต์ต้นฉบับที่อัปเดตของฉัน
แฮงค์

2

สำหรับคำถามสุดท้ายของคุณทำไม ฉันจะพยายามอธิบายสิ่งที่ฉันรู้

คำอธิบายสั้น ๆ เกี่ยวกับรหัสสถานะทั้งสามในเงื่อนไขของคนธรรมดา

  • 200 - สำเร็จ (คำขอของเบราว์เซอร์และรับไฟล์จากเซิร์ฟเวอร์)

หากการแคชถูกเปิดใช้งานในเซิร์ฟเวอร์

  • 200 (จากแคชหน่วยความจำ) - ไฟล์ที่พบในเบราว์เซอร์เบราว์เซอร์จึงไม่ได้รับการร้องขอจากเซิร์ฟเวอร์
  • 304 - เบราว์เซอร์ร้องขอไฟล์ แต่ถูกปฏิเสธโดยเซิร์ฟเวอร์

สำหรับเบราว์เซอร์บางไฟล์กำลังตัดสินใจที่จะร้องขอจากเซิร์ฟเวอร์และสำหรับบางเบราว์เซอร์กำลังตัดสินใจที่จะอ่านจากไฟล์ที่เก็บไว้ (แคช) ทำไมนี้ ทุกไฟล์มีวันหมดอายุดังนั้น

หากไฟล์ยังไม่หมดอายุเบราว์เซอร์จะใช้จากแคช (200 แคช)

หากไฟล์หมดอายุเบราว์เซอร์จะขอเซิร์ฟเวอร์สำหรับไฟล์ ไฟล์ตรวจสอบเซิร์ฟเวอร์ทั้งในสถานที่ (เบราว์เซอร์และเซิร์ฟเวอร์) หากพบไฟล์เดียวกันเซิร์ฟเวอร์ปฏิเสธคำขอ ตามเบราว์เซอร์โปรโตคอลใช้ไฟล์ที่มีอยู่

ดูการกำหนดค่า nginx นี้

location / {
    add_header Cache-Control must-revalidate;
    expires     60;
    etag on;

    ...
}

ที่นี่เวลาหมดอายุถูกตั้งค่าเป็น 60 วินาทีดังนั้นไฟล์สแตติกทั้งหมดจะถูกแคชเป็นเวลา 60 วินาที ดังนั้นหากคุณร้องขอไฟล์อีกครั้งภายใน 60 วินาทีเบราว์เซอร์จะอ่านจากหน่วยความจำ (200 หน่วยความจำ) หากคุณขอหลังจากเบราว์เซอร์ 60 วินาทีจะขอเซิร์ฟเวอร์ (304)

ฉันสันนิษฐานว่าไฟล์จะไม่เปลี่ยนแปลงหลังจาก 60 วินาทีในกรณีนี้คุณจะได้รับ 200 (เช่นไฟล์ที่อัปเดตจะถูกดึงมาจากเซิร์ฟเวอร์)

ดังนั้นหากเซิร์ฟเวอร์ถูกกำหนดค่าด้วยการหมดอายุและการแคชส่วนหัว (นโยบาย) ที่แตกต่างกันสถานะอาจแตกต่างกัน

ในกรณีของคุณคุณใช้ cdn วัตถุประสงค์หลักของ cdn คือความพร้อมใช้งานสูงและการจัดส่งที่รวดเร็ว ดังนั้นพวกเขาจึงใช้เซิร์ฟเวอร์หลายเครื่อง แม้ว่าดูเหมือนว่าไฟล์จะอยู่ในไดเรกทอรีเดียวกัน cdn อาจใช้เซิร์ฟเวอร์หลายเครื่องเพื่อจัดทำเนื้อหา u หากเซิร์ฟเวอร์เหล่านั้นมีการกำหนดค่าที่แตกต่างกัน จากนั้นสถานะเหล่านี้สามารถเปลี่ยนแปลงได้ หวังว่ามันจะช่วย


304 - Not Modified ไม่ใช่เซิร์ฟเวอร์ "ปฏิเสธ" เป็นเซิร์ฟเวอร์ที่ประกาศให้ลูกค้าทราบ "สำหรับรุ่นที่คุณต้องการฉันรู้ว่าไม่ได้มีการแก้ไขคุณไม่จำเป็นต้องใช้ไฟล์จริงๆ" ในทางเทคนิค 304 เป็นหนึ่งในรหัสตอบกลับ "การเปลี่ยนเส้นทาง" มันบอกลูกค้าว่า "เอามันออกมาจากแคชของคุณเอง"
Bob Kuhar
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.