เหตุใดจึงใช้การยุบแทน gzip สำหรับไฟล์ข้อความที่ให้บริการโดย Apache

215

ข้อดีข้อใดบ้างที่เสนอวิธีการสำหรับไฟล์ html, css และ javascript ที่ให้บริการโดยเซิร์ฟเวอร์ LAMP มีทางเลือกที่ดีกว่านี้ไหม?

เซิร์ฟเวอร์ให้ข้อมูลกับแอปพลิเคชันแผนที่โดยใช้ Json ดังนั้นจึงมีไฟล์ขนาดเล็กจำนวนมาก

ดูเพิ่มเติมมีประสิทธิภาพใดที่เกี่ยวข้องในการเลือก gzip มากกว่าการยุบสำหรับการบีบอัด http หรือไม่

— เคน
แหล่งที่มา

เปลี่ยนคำตอบที่ยอมรับ ... ฉันทามติปัจจุบันเป็นสองต่อหนึ่งเพื่อประโยชน์ของ gzip

— Ken

1

mod_deflate สำหรับ Apache 2, mod_gzip สำหรับ Apache 1.3

— SPRBRN

315

เหตุใดจึงใช้การยุบแทน gzip สำหรับไฟล์ข้อความที่ให้บริการโดย Apache

คำตอบง่ายๆคือทำไม่ได้

RFC 2616กำหนด deflate เป็น:

deflate รูปแบบ "zlib" ที่กำหนดใน RFC 1950 ร่วมกับกลไกการบีบอัด "deflate" ที่อธิบายไว้ใน RFC 1951

รูปแบบ zlib ถูกกำหนดในRFC 1950เป็น:

     0   1
     +---+---+
     |CMF|FLG|   (more-->)
     +---+---+

       0   1   2   3
     +---+---+---+---+
     |     DICTID    |   (more-->)
     +---+---+---+---+

     +=====================+---+---+---+---+
     |...compressed data...|    ADLER32    |
     +=====================+---+---+---+---+

ดังนั้นส่วนหัวบางส่วนและการตรวจสอบ ADLER32

RFC 2616 กำหนด gzip เป็น:

gzip รูปแบบการเข้ารหัสที่สร้างโดยโปรแกรมบีบอัดไฟล์ "gzip" (zip GNU) ตามที่อธิบายไว้ใน RFC 1952 [25] รูปแบบนี้เป็นการเข้ารหัส Lempel-Ziv (LZ77) ด้วย CRC 32 บิต

RFC 1952กำหนดข้อมูลที่บีบอัดเป็น:

รูปแบบปัจจุบันใช้วิธีการบีบอัด DEFLATE แต่สามารถขยายได้อย่างง่ายดายเพื่อใช้วิธีการบีบอัดอื่น ๆ

CRC-32 ช้ากว่า ADLER32

เมื่อเทียบกับการตรวจสอบความซ้ำซ้อนแบบวนซ้ำที่มีความยาวเท่ากันจะทำการแลกเปลี่ยนความน่าเชื่อถือสำหรับความเร็ว (เลือกแบบหลัง)

ดังนั้น ... เรามี 2 กลไกการบีบอัดที่ใช้อัลกอริทึมเดียวกันสำหรับการบีบอัด แต่อัลกอริทึมที่แตกต่างกันสำหรับส่วนหัวและการตรวจสอบ

ตอนนี้แพ็กเก็ต TCP พื้นฐานน่าเชื่อถืออยู่แล้วดังนั้นปัญหาที่นี่ไม่ใช่ Adler 32 เทียบกับCRC-32ที่ GZIP ใช้

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

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

ผลของการมีตรรกะที่ซับซ้อนเช่นนั้นคือมันมักจะเสีย Verve Studio มีส่วนทดสอบของผู้ใช้ที่แสดงให้เห็นว่าสถานการณ์เลวร้ายเพียงใด

ตัวอย่างเช่น: deflate ทำงานใน Safari 4.0 แต่ใช้งานไม่ได้ใน Safari 5.1 ก็ยังมีปัญหาใน IE เสมอ

ดังนั้นสิ่งที่ดีที่สุดที่ควรทำคือหลีกเลี่ยงการยุบตัวโดยรวมการเพิ่มความเร็วเล็กน้อย (เนื่องจาก adler 32) ไม่คุ้มกับความเสี่ยงของ payload ที่เสีย

— แซมซัฟฟรอน
แหล่งที่มา

ไม่ควรมีมาตรฐานใหม่ที่รวม adler32 กับ gzip หรือไม่?

— Pacerier

1

@Sam Saffron สิ่งนี้หมายความว่าหากเว็บเบราว์เซอร์ไม่อยู่ในรูปภาพฉันสามารถใช้การยุบเกิน gzip ได้หรือไม่ ตัวอย่างเช่นถ้าฉันจะอัปโหลดไฟล์บีบอัดไปยังเซิร์ฟเวอร์ FTP ของฉัน

— Xegara

1

ข้อแตกต่างเล็ก ๆ น้อย ๆ อีกอย่างคือ zlib wrapper คือหกไบต์เทียบกับ 18 ไบต์สำหรับ gzip ดังนั้นสำหรับแพ็กเก็ตที่มีขนาดเล็กมากอาจมีข้อได้เปรียบในการส่ง 12 ไบต์ที่น้อยลง ข้อสรุปไม่เปลี่ยนแปลงอย่างไรก็ตามเนื่องจาก Microsoft คาดคั้นทุกคนโดยการตีความสิ่งที่ "ยุบ" หมายถึงสิ่งที่พวกเขาส่งบนเซิร์ฟเวอร์ IIS ของพวกเขามันง่ายกว่าที่จะใช้รูปแบบ gzip

— Mark Adler

แต่เพย์โหลดอาจเสียได้อย่างไรถ้ามันถูกส่งโดยใช้ TCP? แนวคิดทั้งหมดของ TCP คือการส่ง payloads ที่ไม่เสียหาย

— user1095108

วันที่คำตอบนี้เริ่มต้นในปี 2012 ดังนั้นเบราว์เซอร์รุ่นใหม่ยังคงประสบปัญหาการใช้อัลกอริทึมแบบยุบหรือไม่ปลอดภัยหรือไม่ คำตอบส่วนนี้ยังคงเป็นปัจจุบันหรือไม่?

— ihebiheb

172

GZip เรียบง่ายพร้อมการตรวจสอบและส่วนหัว / ส่วนท้าย ถึงแม้ว่าการยุบจะเร็วกว่าขณะที่ฉันเรียนรู้วิธีที่ยากลำบาก

gzip เทียบกับกราฟยุบ

— Jeff Atwood
แหล่งที่มา

13

ไม่ต้องพูดถึงว่า zlib ไม่ได้รับการสนับสนุนสำหรับส่วนขยายและแม้ว่าจะเป็นเช่นนั้นคำสั่ง CRC32 ใน SSE 4.2 ใช้พหุนาม 1EDC6F41 พหุนามและรูปแบบ gzip ใช้พหุนาม EDB88320 - อัลกอริธึมที่แตกต่างกันอย่างมีประสิทธิภาพ

— Jack Lloyd

7

และเนื่องจากการยุบเร็วกว่าเหตุใดจึงใช้ gzip

— David Murdoch

40

คำตอบนี้ออกจะไม่ถูกต้อง ... ดู: zoompf.com/blog/2012/02/lose-the-wait-http-compression ... โดยเฉพาะลูกค้ามี 2 วิธีที่พวกเขาสามารถ "ตีความ" ยุบ, ไม่มีส่วนหัว / checksumless และมีส่วนหัว zlib การติดตั้งข้ามเบราว์เซอร์ที่มีการยุบถูกต้องนั้นไม่ดี ควรหลีกเลี่ยงการยุบ

— แซมซัฟฟรอน

4

@ Sam นอกจากนี้ฉันเพิ่งรันมาตรฐานและบนชิป Intel ที่ทันสมัยฉันได้รับ gzip 1441/692 และยุบ 1286/531 ตัวเลขที่สองคือคลายการบีบอัดแรกคือการบีบอัด ดังนั้นการยุบจึงยังเร็วกว่ามาตรฐานของคุณแสดงเป็นอย่างอื่นหรือไม่? (ผมเห็นมันอาจจะไม่เป็นประโยชน์สำหรับเหตุผลอื่น ๆ แต่คำตอบที่ถูกต้อง , ยุบเร็ว .. )

— เจฟฟ์แอด

6

@JeffAtwood แต่คำถามไม่ได้เร็วขึ้น?

— เคน

16

คุณอาจไม่สามารถเลือกใช้ตัวเลือกยุบได้ ตรงกันข้ามกับสิ่งที่คุณคาดว่าmod_deflateไม่ได้ใช้ deflate แต่ gzip ดังนั้นในขณะที่คะแนนส่วนใหญ่ทำถูกต้อง แต่ก็ไม่น่าจะเกี่ยวข้องมากที่สุด

— Amblyopius
แหล่งที่มา

4

ฉันคิดว่าไม่มีความแตกต่างใหญ่ระหว่างการยุบและ gzip เนื่องจากโดยทั่วไป gzip เป็นเพียงส่วนหัวที่ล้อมรอบการยุบ (ดู RFCs 1951 และ 1952)

— schnaader
แหล่งที่มา

3

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

— Joachim Sauer
แหล่งที่มา

น่าจะเป็นด้วย gzip คุณไม่สามารถเริ่มส่งข้อมูลส่วนหัวจนกว่าคุณจะได้รับจัดเก็บและบีบอัดข้อมูลทั้งหมดหรือไม่ (เพราะคุณจะต้องตรวจสอบในการสร้างส่วนหัว)

— OJW

8

ในรูปแบบ gzip การตรวจสอบจะมาที่ท้ายไฟล์โดยเฉพาะเพื่อให้สามารถเริ่มเขียนบล็อกแบบยุบตามที่ได้รับการประมวลผลโดยไม่ต้องเก็บทุกอย่างไว้

— Jack Lloyd

2

mod_deflate ต้องการทรัพยากรน้อยลงบนเซิร์ฟเวอร์ของคุณแม้ว่าคุณอาจจ่ายค่าปรับเล็กน้อยในแง่ของปริมาณการบีบอัดข้อมูล

หากคุณให้บริการไฟล์ขนาดเล็กจำนวนมากฉันขอแนะนำให้ทำการเปรียบเทียบและโหลดการทดสอบโซลูชันที่ถูกบีบอัดและไม่บีบอัดของคุณ - คุณอาจพบว่าบางกรณีที่การเปิดใช้งานการบีบอัดจะไม่ส่งผลให้ประหยัด

— เดฟอาร์
แหล่งที่มา

สำหรับใครก็ตามที่สงสัยด้วยการย่อไฟล์ข้อความของฉันไปจาก 30KB ถึง 10KB - ดังนั้นไฟล์จะต้องมีขนาดเล็กกว่านั้นเพื่อไม่ให้ประหยัด ฉันคาดเดาน้อยกว่า 1KB หรือสิ่งที่คล้ายกัน

— Hextech

0

ไม่ควรมีความแตกต่างใด ๆ ใน gzip & deflate สำหรับการคลายการบีบอัด Gzip เป็นเพียงแค่ส่วนขยายที่มีส่วนหัวไม่กี่สิบไบต์ล้อมรอบมันรวมถึงการตรวจสอบ การตรวจสอบเป็นเหตุผลสำหรับการบีบอัดช้าลง อย่างไรก็ตามเมื่อคุณทำการบีบอัดไฟล์ที่มีจำนวน zillions คุณต้องการให้ checksums เหล่านั้นเป็นการตรวจสอบที่มีสติในระบบไฟล์ของคุณ นอกจากนี้คุณสามารถใช้เครื่องมือ commandline เพื่อรับสถิติไฟล์ สำหรับเว็บไซต์ของเราเราได้ทำการบีบอัดข้อมูลคงที่จำนวนหนึ่ง (ทั้งไดเรกทอรีเปิดเกม 13,000 เกมการเติมข้อความอัตโนมัติสำหรับคำค้นหานับล้าน ๆ คำเป็นต้น) และเราได้รับการจัดอันดับให้เร็วกว่าเว็บไซต์ของ Alexa ถึง 95% ค้นหา Faxo. อย่างไรก็ตามเราใช้ประโยชน์จากเว็บเซิร์ฟเวอร์ที่เป็นกรรมสิทธิ์ของเรา Apache / mod_deflate ไม่ได้ทำการตัด เมื่อไฟล์เหล่านั้นถูกบีบอัดไว้ในระบบไฟล์ไม่เพียง แต่คุณจะได้รับไฟล์ที่มีขนาดบล็อกของระบบไฟล์ขั้นต่ำ แต่ยังมีค่าใช้จ่ายที่ไม่จำเป็นในการจัดการไฟล์ในระบบไฟล์ที่เว็บเซิร์ฟเวอร์สามารถดูแลได้ ข้อกังวลของคุณควรเป็นรอยเท้าดิสก์ทั้งหมดและเวลาในการเข้าถึง / คลายการบีบอัดและความเร็วที่สองในการได้รับข้อมูลนี้ถูกบีบอัดไว้ล่วงหน้า รอยเท้ามีความสำคัญเนื่องจากแม้ว่าพื้นที่ดิสก์มีราคาถูกคุณต้องการมากที่สุดเท่าที่จะทำได้เพื่อให้พอดีกับแคช

— สตีเว่น
แหล่งที่มา

GZip อาจตรวจสอบการตรวจสอบเกี่ยวกับการบีบอัดดังนั้นความแตกต่างของความเร็วสำหรับการบีบอัด

— Seun Osewa

-1

บน Ubuntu ที่มี Apache2 และโมดูล deflate ติดตั้งแล้ว (ซึ่งเป็นค่าเริ่มต้น) คุณสามารถเปิดใช้การบีบอัดแบบ~~ยุบ~~ gzip ในสองขั้นตอนง่าย ๆ :

a2enmod deflate
/etc/init.d/apache2 force-reload

และคุณไม่อยู่! ฉันพบหน้าเว็บที่ฉันแสดงผ่านการเชื่อมต่อ adsl ของฉันโหลดได้เร็วกว่ามาก

แก้ไข:ตามความคิดเห็นของ @ GertvandenBerg สิ่งนี้ช่วยให้การบีบอัด gzip ไม่ใช่การยุบ

— ดาน
แหล่งที่มา

6

ยกเว้นว่าจะเปิดใช้งาน gzip เนื่องจาก mod_deflate ใช้การบีบอัด gzip อย่างสับสนเท่านั้น ...

— Gert van den Berg

@GertvandenBerg ผมได้ปรับปรุงคำตอบของฉัน แต่สำหรับบันทึก gzip คือยุบเพียงมีส่วนหัวเป็นพิเศษและการตรวจสอบ

— ดาน

@enen yep แต่การตรวจสอบมีผลกระทบต่อประสิทธิภาพ ... (และการยุบแบบดิบไม่เป็นไปตามมาตรฐาน)

— Gert van den Berg

-4

ถ้าฉันจำได้ถูกต้อง

gzip จะบีบอัดมากกว่าเล็กน้อย
การยุบมีประสิทธิภาพมากขึ้น

— JimmyJ
แหล่งที่มา

2

gzip ยุบด้วยส่วนหัว และ HTTP 1.1 ยุบเป็นจริง zlib (ซึ่งยังเป็นห่อหุ้มรอบยุบ)

— เดวิดเมอร์ด็