ทำให้เซิร์ฟเวอร์ส่งข้อมูลแบบบีบอัด: คู่มือทีละขั้นตอนเพื่อประหยัดแบนด์วิดท์

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

บทนำ: หัวข้อเดียวสามารถลดแบนด์วิดท์ได้หลายเท่า

การบีบอัด HTTP ทำงานง่ายอย่างน่าประหลาดใจ ไคลเอนต์บอกเซิร์ฟเวอร์ว่ามันรองรับอัลกอริทึมการบีบอัดตัวใดบ้าง เซิร์ฟเวอร์เลือกอัลกอริทึมที่เหมาะสม บีบอัดเนื้อหาของคำตอบ แล้วส่งให้ ไคลเอนต์คลายการบีบอัดข้อมูลฝั่งตัวเอง ผลลัพธ์คือ สิ่งที่ส่งผ่านเครือข่ายไม่ใช่ HTML หรือ JSON ต้นฉบับ แต่เป็นเวอร์ชันบีบอัด ซึ่งมักมีขนาดเล็กกว่าสามถึงห้าเท่า

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

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

สิ่งที่ต้องรู้ล่วงหน้า แค่มีความเข้าใจพื้นฐานว่า HTTP request และ response คืออะไร หัวข้อ (headers) คืออะไร และวิธีรันคำสั่งในเทอร์มินัล หากคุณเคยส่งคำขอผ่าน curl หรือเขียนสคริปต์ Python หรือ Node.js มาก่อน คุณจะทำได้ไม่ยาก

ใช้เวลาเท่าไร การอ่านและทำตามตัวอย่างทั้งหมดจะใช้เวลาประมาณหกสิบนาที คุณจะเห็นผลลัพธ์จริงภายในสิบนาทีแรก เมื่อคุณเปรียบเทียบขนาดของคำตอบที่บีบอัดและไม่บีบอัดด้วยตาตัวเอง

การเตรียมตัวล่วงหน้า

ก่อนเริ่ม ตรวจสอบว่าคุณมีทุกอย่างที่จำเป็น ซึ่งจะช่วยประหยัดเวลาและหลีกเลี่ยงข้อผิดพลาดระหว่างทาง

เครื่องมือที่จำเป็น

• curl เวอร์ชัน 7.72 หรือใหม่กว่า ในบิลด์ปี 2026 brotli และ zstd รองรับได้ทันทีบนระบบส่วนใหญ่
• Python เวอร์ชัน 3.10 หรือใหม่กว่า พร้อมติดตั้งไลบรารี requests และสำหรับ brotli เพิ่มแพ็กเกจ brotli หรือ brotlicffi
• Node.js เวอร์ชัน 18 หรือใหม่กว่า โมดูล zlib ในตัวรองรับ gzip, deflate, brotli
• การเข้าถึงพร็อกซี Proxeon หากคุณต้องการวัดการประหยัดในสภาพแวดล้อมที่คุณทำงานทุกวัน
• โปรแกรมแก้ไขข้อความสำหรับเขียนสคริปต์

ข้อกำหนดของระบบ

ระบบปฏิบัติการที่ทันสมัยใดก็ได้: Windows, macOS หรือ Linux ตัวอย่างทั้งหมดใช้ได้ทุกแพลตฟอร์ม แรม 2 กิกะไบต์ก็เพียงพอ ไม่มีข้อกำหนดพิเศษเกี่ยวกับ CPU แม้ว่าการบีบอัดข้อมูลปริมาณมากด้วย brotli ที่ระดับสูงสุดอาจทำให้คอร์เดียวทำงานหนัก

สิ่งที่ต้องติดตั้งและตรวจสอบ

1. เปิดเทอร์มินัลแล้วรันคำสั่งตรวจสอบเวอร์ชัน curl:

   curl --version

2. ดูบรรทัดแรกของผลลัพธ์ ซึ่งระบุเวอร์ชัน ตรวจสอบว่าในรายการคุณสมบัติมี brotli และถ้าเป็นไปได้ zstd
3. ตรวจสอบ Python ด้วยคำสั่ง

   python --version

   และติดตั้ง dependencies:

   pip install requests brotli

4. ตรวจสอบ Node.js ด้วยคำสั่ง

   node --version

เคล็ดลับ: หาก curl ในระบบของคุณคอมไพล์โดยไม่มี brotli ให้ติดตั้งผ่านตัวจัดการแพ็กเกจอย่างเป็นทางการของ OS ของคุณ ในบิลด์องค์กรปี 2026 brotli มักเปิดใช้งานเป็นค่าเริ่มต้นเกือบตลอด

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

✅ ตรวจสอบ: เครื่องมือทั้งสามตอบสนองต่อคำสั่งตรวจสอบเวอร์ชันและแสดงหมายเลข แสดงว่าการเตรียมตัวเสร็จสมบูรณ์ เดินหน้าต่อไปได้

แนวคิดพื้นฐานในภาษาง่ายๆ

ก่อนที่จะกดปุ่ม มาทำความเข้าใจศัพท์เทคนิคก่อน ใช้เวลาห้านาที แต่จะช่วยให้ไม่สับสนในภายหลัง

การเจรจาตกลงการบีบอัดทำงานอย่างไร

การบีบอัด HTTP ขึ้นอยู่กับหัวข้อสามตัว การเข้าใจบทบาทของมันช่วยแก้ปัญหาส่วนใหญ่ได้

Accept-Encoding ฝั่งไคลเอนต์ นี่คือหัวข้อที่ไคลเอนต์ของคุณส่งพร้อมกับคำขอ มันระบุอัลกอริทึมการบีบอัดที่ไคลเอนต์สามารถคลายได้ ตัวอย่างเช่น สตริง

Accept-Encoding: gzip, br, zstd

Content-Encoding ในคำตอบ นี่คือหัวข้อที่เซิร์ฟเวอร์เพิ่มในคำตอบ มันบอกว่าตัวเนื้อหาถูกบีบอัดด้วยอัลกอริทึมใด หากคุณเห็น

Content-Encoding: br

Vary ฝั่งเซิร์ฟเวอร์ หัวข้อ Vary บอกแคชและพร็อกซีว่าคำตอบขึ้นอยู่กับหัวข้อบางหัวข้อของคำขอ สำหรับการบีบอัด ค่าที่สำคัญคือ

Vary: Accept-Encoding

แนวคิดหลักของการเจรจาตกลง

จำลำดับนี้ไว้ ไคลเอนต์ขอผ่าน Accept-Encoding เซิร์ฟเวอร์ตัดสินใจและตอบผ่าน Content-Encoding ตัวกลางใช้ Vary เป็นตัวชี้นำ หากหนึ่งในสามส่วนนี้เสียหาย คุณจะได้รับคำตอบที่ไม่บีบอัดและจ่ายแบนด์วิดท์เกิน

เคล็ดลับ: แม้ว่าไลบรารี HTTP ของคุณจะเพิ่ม Accept-Encoding อัตโนมัติ ให้ตรวจสอบหัวข้อจริงในคำตอบเสมอ ระบบอัตโนมัติบางครั้งเงียบ แต่แบนด์วิดท์หายไป

gzip, deflate, brotli, zstd: เปรียบเทียบอัลกอริทึม

มีอัลกอริทึมการบีบอัดสำหรับ HTTP ที่ใช้กันทั่วไปสี่ตัว พวกมันแตกต่างกันที่อัตราส่วนการบีบอัดและภาระ CPU มาดูแต่ละตัวและสรุปเป็นตารางกัน

gzip

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

deflate

เป็นญาติใกล้ชิดกับ gzip ใช้อัลกอริทึมเดียวกันภายใน แต่มีรูปแบบห่อหุ้มต่างกัน ในทางปฏิบัติพบได้น้อยกว่าและบางครั้งเซิร์ฟเวอร์ก็ implement ผิดพลาด อัตราส่วนการบีบอัดใกล้เคียงกับ gzip ไม่มีเหตุผลพิเศษที่จะเลือก deflate แทน gzip

brotli

อัลกอริทึมสมัยใหม่ที่พัฒนาขึ้นสำหรับเว็บโดยเฉพาะ บีบอัดข้อมูลข้อความได้ดีกว่า gzip อย่างเห็นได้ชัด โดยเฉพาะ HTML, CSS และ JSON ราคาที่ต้องจ่ายคือภาระ CPU ที่สูงขึ้นเมื่อบีบอัดที่ระดับสูงสุด การคลายการบีบอัดทำได้รวดเร็ว ใช้ตัวย่อ br ในหัวข้อ

zstd

อัลกอริทึมสมัยใหม่ที่รวดเร็วพร้อมการปรับระดับที่ยืดหยุ่น ให้อัตราส่วนการบีบอัดใกล้เคียงกับ brotli แต่ทำงานเร็วกว่าในการบีบอัด การรองรับในเว็บเพิ่มขึ้นเรื่อยๆ ภายในปี 2026 เซิร์ฟเวอร์และไคลเอนต์ส่วนใหญ่รู้จักมัน ใช้ตัวย่อ zstd

ตารางเปรียบเทียบกับคำตอบข้อความทั่วไป

สมมติว่าคำตอบ JSON ขนาด 1000 กิโลไบต์ในรูปแบบไม่บีบอัด ตัวเลขเป็นเพียงประมาณการ ขึ้นอยู่กับเนื้อหา แต่สัดส่วนค่อนข้างแม่นยำ

• ไม่บีบอัด: 1000 KB ประหยัด 0 เปอร์เซ็นต์ โหลด CPU น้อยมาก
• gzip ระดับ 6: ประมาณ 190 KB ประหยัดประมาณ 81 เปอร์เซ็นต์ โหลดต่ำ
• deflate ระดับ 6: ประมาณ 195 KB ประหยัดประมาณ 80 เปอร์เซ็นต์ โหลดต่ำ
• brotli ระดับ 5: ประมาณ 165 KB ประหยัดประมาณ 83 เปอร์เซ็นต์ โหลดปานกลาง
• brotli ระดับ 11: ประมาณ 140 KB ประหยัดประมาณ 86 เปอร์เซ็นต์ โหลดสูง
• zstd ระดับ 3: ประมาณ 175 KB ประหยัดประมาณ 82 เปอร์เซ็นต์ โหลดต่ำ
• zstd ระดับ 19: ประมาณ 150 KB ประหยัดประมาณ 85 เปอร์เซ็นต์ โหลดปานกลาง

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

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

✅ ตรวจสอบ: คุณเข้าใจว่า brotli และ zstd มักมีประสิทธิภาพกว่า gzip เล็กน้อยสำหรับข้อความ แต่ gzip เข้ากันได้ที่สุด แค่นี้พอสำหรับการปฏิบัติ

ขั้นตอนที่ 1: ส่งคำขอและดูว่าคำตอบถูกบีบอัดหรือไม่

เป้าหมายของขั้นตอนนี้ เรียนรู้ที่จะเห็นหัวข้อ Content-Encoding และขนาดจริงของเนื้อหา หากไม่มีสิ่งนี้ คุณจะไม่สามารถวัดการประหยัดได้

ตรวจสอบผ่าน curl

1. เปิดเทอร์มินัล
2. ขั้นแรก ขอทรัพยากรโดยไม่บีบอัดเพื่อทราบขนาดเดิม รัน:

   curl -s -o /dev/null -w "%{size_download}" https://example.com/api/data

3. จดตัวเลข นี่คือขนาดของคำตอบที่ไม่บีบอัดเป็นไบต์
4. ตอนนี้ขอการบีบอัด แฟล็ก --compressed เพิ่ม Accept-Encoding อัตโนมัติและคลายการบีบอัดคำตอบ:

   curl -s --compressed -o /dev/null -w "%{size_download}" https://example.com/api/data

5. เปรียบเทียบสองตัวเลข ตัวที่สองควรน้อยกว่าอย่างเห็นได้ชัดเมื่อเนื้อหาเหมือนกัน

สำคัญ: ตัววัด size_download ใน curl เมื่อใช้ --compressed จะแสดงขนาดของข้อมูลที่คลายการบีบอัดแล้ว ไม่ใช่ขนาดที่ส่งผ่านเครือข่าย หากต้องการเห็นปริมาณเครือข่ายจริง ให้ใช้หัวข้อในคำตอบและการวัดระดับกลางซึ่งเราจะพูดถึงในขั้นตอนการวัด

ดูหัวข้อคำตอบ

1. รันคำขอพร้อมแฟล็กแสดงหัวข้อ:

   curl -s -I --compressed https://example.com/api/data

2. ค้นหาบรรทัด Content-Encoding ในผลลัพธ์ หากมี gzip, br หรือ zstd แสดงว่าเซิร์ฟเวอร์ส่งคำตอบแบบบีบอัด
3. ค้นหาบรรทัด Vary หากมี Accept-Encoding แสดงว่าการตั้งค่าแคชถูกต้อง

เคล็ดลับ: เพื่อระบุอัลกอริทึมที่ต้องการอย่างชัดเจน เพิ่มหัวข้อด้วยตนเอง:

curl -s -H "Accept-Encoding: br" -I https://example.com/api/data

ทำงานผ่านพร็อกซี Proxeon

เพื่อวัดการประหยัดในสภาพจริง ให้ส่งคำขอผ่านพร็อกซี ใน curl ใช้แฟล็ก -x:

curl -s --compressed -x http://ชื่อผู้ใช้:รหัสผ่าน@ที่อยู่_proxeon:พอร์ต -o /dev/null -w "%{size_download}" https://example.com/api/data

วิธีนี้จะบอกได้ว่าการบีบอัดผ่านพร็อกซีไปถึงหรือไม่ และมีอะไรตัดหัวข้อระหว่างทางหรือไม่

ผลลัพธ์ที่คาดหวัง คุณเห็นตัวเลขสองตัว: ขนาดที่ไม่บีบอัดและขนาดที่บีบอัด และคุณเห็นหัวข้อ Content-Encoding ในคำตอบ นี่หมายความว่ากลไกทำงาน

ปัญหาที่อาจเกิดขึ้น: หากตัวเลขทั้งสองเท่ากันและไม่มี Content-Encoding แสดงว่าเซิร์ฟเวอร์ไม่ได้บีบอัดคำตอบ เราจะพูดถึงสาเหตุในส่วนแยก

✅ ตรวจสอบ: ในคำตอบที่มีแฟล็ก --compressed มีบรรทัด Content-Encoding พร้อมอัลกอริทึมใดอัลกอริทึมหนึ่ง แสดงว่าขั้นตอนนี้สำเร็จ

ขั้นตอนที่ 2: วัดการประหยัดจริงด้วย Python

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

วัดง่ายๆ ด้วย requests

ไลบรารี requests เพิ่ม Accept-Encoding และคลายการบีบอัดคำตอบให้อัตโนมัติตามค่าเริ่มต้น เพื่อวัดขนาดเครือข่ายจริง เราจะดูความยาวของเนื้อหาดิบก่อนคลายการบีบอัด

1. สร้างไฟล์ measure.py
2. วางโค้ดต่อไปนี้:

import requests
url = "https://example.com/api/data"
# คำขอที่ไม่บีบอัด
r_plain = requests.get(url, headers={"Accept-Encoding": "identity"})
size_plain = len(r_plain.content)
# คำขอที่บีบอัด
r_comp = requests.get(url, headers={"Accept-Encoding": "gzip, br, zstd"})
encoding = r_comp.headers.get("Content-Encoding", "ไม่มี")
size_wire = int(r_comp.headers.get("Content-Length", 0))
size_body = len(r_comp.content)
print("ไม่บีบอัด, ไบต์:", size_plain)
print("อัลกอริทึมการบีบอัด:", encoding)
print("ผ่านเครือข่ายประมาณ, ไบต์:", size_wire)
print("หลังคลายการบีบอัด, ไบต์:", size_body)
if size_plain and size_wire:
saved = 100 - size_wire * 100 
print("ประหยัดแบนด์วิดท์, เปอร์เซ็นต์:", saved)

ข้อควรระวัง: ค่า Content-Length อาจไม่มี โดยเฉพาะเมื่อส่งแบบ chunked หากไม่มี ให้ใช้วิธีที่แม่นยำกว่าด้านล่าง

วัดปริมาณเครือข่ายที่แม่นยำ

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

import requests
url = "https://example.com/api/data"
sess = requests.Session()
# ปิดการคลายการบีบอัดอัตโนมัติเพื่อดูขนาดดิบ
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, stream=True)
raw_bytes = 0
for chunk in r.raw.stream(8192, decode_content=False):
raw_bytes += len(chunk)
print("อัลกอริทึม:", r.headers.get("Content-Encoding", "ไม่มี"))
print("ไบต์ดิบผ่านเครือข่าย:", raw_bytes)

เปรียบเทียบ raw_bytes กับขนาดของคำขอที่ไม่บีบอัด ความแตกต่างคือการประหยัดจริงของคุณ

วัดผ่านพร็อกซี Proxeon

เพิ่มพารามิเตอร์ proxies เพื่อรับตัวเลขในสภาพการใช้งานจริง:

proxies = {
"http": "http://ชื่อผู้ใช้:รหัสผ่าน@ที่อยู่_proxeon:พอร์ต",
"https": "http://ชื่อผู้ใช้:รหัสผ่าน@ที่อยู่_proxeon:พอร์ต",
}
r = sess.get(url, headers={"Accept-Encoding": "gzip, br, zstd"}, proxies=proxies, stream=True)

เคล็ดลับ: รันการวัดหลายครั้งแล้วหาค่าเฉลี่ย คำตอบแบบไดนามิกมีขนาดเปลี่ยนแปลงได้ การวัดครั้งเดียวอาจทำให้เข้าใจผิด

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

✅ ตรวจสอบ: ในผลลัพธ์ อัลกอริทึมไม่ใช่คำว่า "ไม่มี" และไบต์ดิบน้อยกว่าไม่บีบอัด เยี่ยมมาก

ขั้นตอนที่ 3: วัดเดียวกันด้วย Node.js

เป้าหมายของขั้นตอนนี้ รับเครื่องมือวัดที่ใช้งานได้ใน JavaScript สำหรับผู้ที่เขียนไคลเอนต์บน Node

วัดสตรีมดิบ

1. สร้างไฟล์ measure.js
2. วางโค้ดที่นับไบต์ก่อนคลายการบีบอัด:

const https = require('https');
const url = 'https://example.com/api/data';
function measure(acceptEncoding) {
 return new Promise((resolve) => {
const req = https.get(url, { headers: { 'Accept-Encoding': acceptEncoding } }, (res) => {
 let bytes = 0;
 res.on('data', (chunk) => { bytes += chunk.length; });
 res.on('end', () => {
resolve({ enc: res.headers['content-encoding'] || 'ไม่มี', bytes });
 });
});
req.end();
 });
}
(async () => {
 const plain = await measure('identity');
 const comp = await measure('gzip, br, zstd');
 console.log('ไม่บีบอัด, ไบต์:', plain.bytes);
 console.log('อัลกอริทึม:', comp.enc);
 console.log('บีบอัดผ่านเครือข่าย, ไบต์:', comp.bytes);
 const saved = Math.round(100 - (comp.bytes * 100) / plain.bytes);
 console.log('ประหยัด, เปอร์เซ็นต์:', saved);
})();

สำคัญ: ในตัวอย่างนี้ เราอ่านสตรีมดิบจาก res และไม่ได้เชื่อมต่อ zlib ดังนั้นตัวนับ bytes จึงแสดงปริมาณเครือข่ายจริง นี่คือสิ่งที่คุณจ่ายให้ผู้ให้บริการพร็อกซี

คลายการบีบอัดด้วยตนเองบน Node

หากคุณต้องอ่านเนื้อหาด้วย ให้คลายสตรีมผ่านโมดูล zlib ในตัว:

const zlib = require('zlib');
let stream = res;
const enc = res.headers['content-encoding'];
if (enc === 'gzip') stream = res.pipe(zlib.createGunzip());
else if (enc === 'br') stream = res.pipe(zlib.createBrotliDecompress());
else if (enc === 'deflate') stream = res.pipe(zlib.createInflate());

เคล็ดลับ: สำหรับ zstd ใน Node.js เวอร์ชันใหม่ มี zlib.createZstdDecompress หากเวอร์ชันของคุณไม่มี ให้อัปเดต Node หรือใช้แพ็กเกจ npm แยกต่างหาก

ผลลัพธ์ที่คาดหวัง Node พิมพ์การประหยัดเป็นเปอร์เซ็นต์ ซึ่งใกล้เคียงกับที่คุณได้จาก Python และ curl

✅ ตรวจสอบ: เครื่องมือสามตัวให้ตัวเลขการประหยัดใกล้เคียงกัน แสดงว่าการวัดของคุณน่าเชื่อถือ

ขั้นตอนที่ 4: ทำไมคำตอบถึงมาแบบไม่บีบอัด

เป้าหมายของขั้นตอนนี้ เรียนรู้ที่จะวินิจฉัยว่าทำไมการบีบอัดไม่ทำงาน และแก้ไขสาเหตุ นี่เป็นปัญหาที่พบบ่อยที่สุดในทางปฏิบัติ

กรณีที่หนึ่ง: ไคลเอนต์ไม่ได้ขอ

สาเหตุที่พบบ่อยที่สุด ไคลเอนต์ HTTP ของคุณไม่ได้ส่งหัวข้อ Accept-Encoding และเซิร์ฟเวอร์ก็ส่งคำตอบที่ไม่บีบอัดตามตรง สิ่งนี้เกิดขึ้นเมื่อคุณสร้างหัวข้อด้วยตนเองและลืมเรื่องการบีบอัด หรือเมื่อคุณใช้ซ็อกเก็ตระดับต่ำ

1. ตรวจสอบสิ่งที่ส่งไปยังเซิร์ฟเวอร์ ใน curl เพิ่มแฟล็ก -v และค้นหาบรรทัด Accept-Encoding ในหัวข้อขาออก
2. หากไม่มีบรรทัดนี้ ให้เพิ่มด้วยตนเองผ่าน -H หรือแฟล็ก --compressed
3. ใน Python ตรวจสอบว่าคุณไม่ได้เขียนทับหัวข้อด้วยค่าว่าง

ข้อควรระวัง: ไลบรารีบางตัวเมื่อคุณตั้งค่าหัวข้อใดๆ ด้วยตนเอง จะหยุดเพิ่มค่าที่ตั้งไว้ตามค่าเริ่มต้น หากคุณตั้ง User-Agent ด้วยมือ ให้ตรวจสอบว่า Accept-Encoding ไม่หายไปด้วย

กรณีที่สอง: เซิร์ฟเวอร์ไม่รองรับ

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

1. ขออัลกอริทึมต่างๆ ทีละตัว: เริ่มด้วย gzip, ตามด้วย br, ตามด้วย zstd
2. ดูว่าอัลกอริทึมใดทำให้มี Content-Encoding ในคำตอบ
3. หากไม่มีเลย แสดงว่าเซิร์ฟเวอร์ไม่บีบอัด คุณไม่สามารถเปลี่ยนเซิร์ฟเวอร์ของคนอื่นได้ แต่สามารถเลือก endpoint หรือ API อื่นได้หากมี

เคล็ดลับ: API หลายตัวบีบอัดเฉพาะคำตอบที่มีขนาดใหญ่เกินระดับหนึ่ง คำตอบเล็กๆ เซิร์ฟเวอร์มักปล่อยไม่บีบอัดโดยตั้งใจ เพราะค่าใช้จ่ายในการบีบอัดอาจมากกว่าประโยชน์

กรณีที่สาม: ตัวกลางตัดหัวข้อ

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

1. ส่งคำขอโดยตรงและผ่านพร็อกซี แล้วเปรียบเทียบหัวข้อ Content-Encoding
2. หากทางตรงมีการบีบอัด แต่ผ่านตัวกลางไม่มี แสดงว่าตัวกลางเข้ามาแทรกแซง
3. เมื่อใช้พร็อกซี Proxeon การบีบอัดถูกส่งผ่านอย่างโปร่งใส ดังนั้นหากคุณเห็นความแตกต่าง ให้หาปัญหาที่ฝั่งเซิร์ฟเวอร์เป้าหมายหรือ CDN ของมัน

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

✅ ตรวจสอบ: คุณสามารถอธิบายได้ในหนึ่งประโยคว่าทำไมคำตอบที่ระบุถึงมาแบบไม่บีบอัด การวินิจฉัยสำเร็จ

ขั้นตอนที่ 5: ข้อผิดพลาดที่ซ่อนอยู่ในการบีบอัด

เป้าหมายของขั้นตอนนี้ หลีกเลี่ยงข้อผิดพลาดเล็กน้อยที่ทำลายข้อมูลหรือทำให้การวัดคลาดเคลื่อน

การบีบอัดซ้ำซ้อน

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

1. ตรวจสอบว่าใน Content-Encoding มีค่าสองค่าซ้อนกัน เช่น gzip ใน br หรือไม่
2. อย่าบีบอัดด้วยตนเองในสิ่งที่ไลบรารีจะบีบอัดให้อัตโนมัติ
3. หากเห็นการเข้ารหัสแบบลูกโซ่ ให้คลายตามลำดับย้อนกลับ

สตรีมเสียหาย

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

1. ครอบการคลายการบีบอัดด้วยการจัดการข้อผิดพลาดเสมอ
2. เมื่อเกิดข้อผิดพลาดในการคลาย ให้ส่งคำขอใหม่ อย่าพยายามอ่านข้อมูลที่เสียหาย
3. เปรียบเทียบขนาดจริงกับ Content-Length หากมี

ข้อควรระวัง: อย่าบันทึกข้อมูลที่คลายบางส่วนเป็นผลลัพธ์ JSON ที่เสียหายอาจดูสมเหตุสมผล แต่จะทำให้เกิดข้อผิดพลาดซ่อนเร้นในขั้นตอนถัดไป

การคลายด้วยตนเองเมื่อไลบรารีไม่ทำ

หากคุณปิดการคลายอัตโนมัติเพื่อวัดที่แม่นยำ หรือใช้ไคลเอนต์ระดับต่ำ คุณจะต้องคลายด้วยตนเอง ตัวอย่างบน Python:

import gzip, brotli, zlib
def decompress(data, encoding):
if encoding == "gzip":
return gzip.decompress(data)
if encoding == "br":
return brotli.decompress(data)
if encoding == "deflate":
return zlib.decompress(data)
return data

เคล็ดลับ: หากการคลาย deflate ล้มเหลว ให้ลองเรียก zlib.decompress ด้วยพารามิเตอร์ wbits เป็นลบสิบห้า เซิร์ฟเวอร์บางตัวส่ง deflate ดิบโดยไม่มี wrapper ของ zlib

ผลลัพธ์ที่คาดหวัง คุณสามารถคลายรูปแบบที่รองรับได้ด้วยตนเอง และจัดการข้อผิดพลาดของสตรีมอย่างถูกต้อง

✅ ตรวจสอบ: สคริปต์ของคุณไม่พังเมื่อเจอคำตอบที่เสียหาย แต่ส่งคำขอใหม่ ความเสถียรสำเร็จ

ขั้นตอนที่ 6: สิ่งที่ไม่คุ้มที่จะบีบอัด

เป้าหมายของขั้นตอนนี้ อย่าเปลือง CPU และเวลากับการบีบอัดสิ่งที่บีบอัดแล้ว ซึ่งประหยัดทรัพยากรโดยไม่เสียประโยชน์ด้านแบนด์วิดท์

รูปแบบที่บีบอัดอยู่แล้ว

ข้อมูลบางประเภทเก็บในรูปแบบที่มีการบีบอัดภายในอยู่แล้ว การพยายามบีบอัดซ้ำไม่มีประโยชน์: ได้แค่เศษเสี้ยวเปอร์เซ็นต์ แต่เปลือง CPU

• รูปภาพ: JPEG, PNG, WebP, AVIF ถูกบีบอัดภายในรูปแบบของมันแล้ว
• วิดีโอ: MP4, WebM, MKV มีสตรีมวิดีโอที่บีบอัดสูง
• เสียง: MP3, AAC, OGG ถูกบีบอัดโดยธรรมชาติ
• ไฟล์เก็บถาวร: ZIP, RAR, 7z, gz เป็นคอนเทนเนอร์ที่บีบอัดแล้ว

สำหรับทรัพยากรเหล่านี้ Accept-Encoding ไม่ช่วยลดขนาดเนื้อหา ยิ่งไปกว่านั้น เซิร์ฟเวอร์มักจะไม่บีบอัดซ้ำอยู่แล้ว เพราะตั้งค่าตามรายการ MIME types

สิ่งที่ควรบีบอัด

• HTML, CSS, JavaScript
• JSON และ XML จาก API
• ข้อความธรรมดา, CSV, ไฟล์ล็อก
• SVG เพราะจริงๆ แล้วเป็นข้อความ

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

ผลลัพธ์ที่คาดหวัง คุณไม่เปลืองทรัพยากรกับการบีบอัดรูปแบบไบนารี และใช้การบีบอัดเฉพาะที่ได้ผลจริง

✅ ตรวจสอบ: คุณสามารถบอกได้ในทันทีว่าควรบีบอัดคำตอบประเภทใด ความเข้าใจเกิดขึ้นแล้ว

ตรวจสอบผลลัพธ์

ถึงเวลาตรวจสอบว่าคุณตั้งค่าทุกอย่างถูกต้องแล้ว ตรวจสอบตามรายการ

รายการตรวจสอบการทำงาน

1. ไคลเอนต์ของคุณส่งหัวข้อ Accept-Encoding พร้อมอัลกอริทึมที่ต้องการ
2. ในคำตอบมี Content-Encoding พร้อมอัลกอริทึมใดอัลกอริทึมหนึ่งสำหรับทรัพยากรข้อความ
3. สคริปต์วัดแสดงปริมาณเครือข่ายน้อยกว่าไม่บีบอัดอย่างน้อยเจ็ดสิบเปอร์เซ็นต์สำหรับข้อความ
4. ผ่านพร็อกซี Proxeon การบีบอัดยังคงอยู่ ตัวเลขตรงกับคำขอโดยตรง
5. การคลายการบีบอัดไม่มีข้อผิดพลาด และข้อมูลอ่านได้ถูกต้อง
6. คุณไม่ได้พยายามบีบอัดรูปแบบไบนารี

วิธีทดสอบ

1. เลือก endpoint ที่แตกต่างกันสามแบบ: หนึ่ง JSON, หนึ่ง HTML, หนึ่งรูปภาพ
2. รันแต่ละแบบผ่านสคริปต์วัดของคุณ
3. ตรวจสอบว่าสองแบบแรกประหยัดมาก ส่วนแบบที่สามใกล้ศูนย์

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

✅ ตรวจสอบ: ครบทั้งหกข้อในรายการ แสดงว่าการบีบอัดถูกตั้งค่าและวัดอย่างถูกต้อง

ข้อผิดพลาดทั่วไปและวิธีแก้ไข

ด้านล่างเป็นปัญหาที่พบบ่อยในรูปแบบ ปัญหา สาเหตุ วิธีแก้

คำตอบไม่บีบอัดทั้งที่ส่ง Accept-Encoding ไปแล้ว

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

ไม่เห็นการประหยัดใน curl size_download ไม่เปลี่ยน

สาเหตุ: แฟล็ก --compressed แสดงขนาดหลังคลายการบีบอัด วิธีแก้: วัดปริมาณเครือข่ายด้วยสคริปต์แยกต่างหากโดยไม่คลายอัตโนมัติ เช่นในขั้นตอน Python และ Node

ไลบรารีส่งขยะแทนข้อความ

สาเหตุ: คุณปิดการคลายอัตโนมัติแต่ไม่ได้คลายสตรีมด้วยตนเอง วิธีแก้: ตรวจหา Content-Encoding แล้วใช้ฟังก์ชันคลายที่เหมาะสม

ข้อผิดพลาดในการคลาย deflate

สาเหตุ: เซิร์ฟเวอร์ส่ง deflate ดิบโดยไม่มี wrapper วิธีแก้: เรียกการคลายด้วยพารามิเตอร์ wbits เป็นลบสิบห้า

การบีบอัดหายไปเมื่อผ่านพร็อกซี

สาเหตุ: มีโหนดระหว่างทางที่เปลี่ยนแปลงหัวข้อ ซึ่งมักเป็น CDN ของเว็บไซต์เป้าหมาย วิธีแก้: เปรียบเทียบคำขอตรงและผ่านพร็อกซีเพื่อระบุจุดที่เกิด พร็อกซี Proxeon ส่งหัวข้ออย่างโปร่งใส ดังนั้นปัญหามักอยู่ที่ฝั่งเซิร์ฟเวอร์

ขนาดคำตอบต่างกันเมื่อวัดซ้ำ

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

ไม่มี Content-Length

สาเหตุ: การส่งแบบ chunked ไม่ระบุความยาวล่วงหน้า วิธีแก้: นับไบต์ด้วยตนเองขณะอ่านสตรีม เช่นในตัวอย่างสคริปต์

การบีบอัดซ้ำซ้อนทำให้ CPU ทำงานหนัก

สาเหตุ: เนื้อหาถูกบีบอัดสองครั้งในระดับที่ต่างกัน วิธีแก้: เอาการบีบอัดด้วยตนเองออกในที่ที่ไลบรารีหรือเซิร์ฟเวอร์ทำอยู่แล้ว

ความสามารถเพิ่มเติม

เมื่อเข้าใจพื้นฐานแล้ว ยังมีอะไรให้พัฒนาอีก

เลือกลำดับความสำคัญของอัลกอริทึม

ในหัวข้อ Accept-Encoding คุณสามารถระบุน้ำหนักผ่านค่า q เพื่อบอกความชอบแก่เซิร์ฟเวอร์ เช่น

Accept-Encoding: zstd;q=1.0, br;q=0.9, gzip;q=0.8

แคชข้อมูลที่คลายแล้ว

หากคุณเข้าถึงทรัพยากรเดิมซ้ำๆ ให้แคชผลลัพธ์ที่คลายแล้วฝั่งคุณ ซึ่งลดทั้งแบนด์วิดท์และภาระ CPU จากการคลายซ้ำ

วัดเป็นกลุ่มตามรายการ URL

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

เคล็ดลับ: บันทึกการประหยัดเป็นไบต์ต่อวัน คูณด้วยราคาต่อกิกะไบต์ คุณจะเห็นผลประโยชน์เป็นตัวเงินจากการเปิดการบีบอัดเมื่อใช้พร็อกซี

✅ ตรวจสอบ: คุณสามารถรวบรวมตารางสรุปการประหยัดสำหรับหลายทรัพยากรด้วยการรันสคริปต์ครั้งเดียว

คำถามที่พบบ่อย

ควรขอ brotli แทน gzip เสมอหรือไม่?

หากคุณแค่ดาวน์โหลด การคลายการบีบอัดเร็วสำหรับทุกอัลกอริทึม ดังนั้นขอแบบที่มีประสิทธิภาพสูงสุดได้ ในทางปฏิบัติ ระบุทั้งสามใน Accept-Encoding: gzip, br, zstd เซิร์ฟเวอร์จะเลือกตัวที่ดีที่สุดที่มี

การบีบอัดประหยัดแบนด์วิดท์เท่าไรสำหรับ API ข้อความ?

โดยปกติเจ็ดสิบถึงเก้าสิบเปอร์เซ็นต์ นั่นคือ คำตอบที่หนักหนึ่งกิกะไบต์จะส่งผ่านเครือข่ายเป็นประมาณหนึ่งร้อยห้าสิบถึงสองร้อยเมกะไบต์ การประหยัดเมื่อจ่ายต่อกิกะไบต์ชัดเจนและเห็นผล

การบีบอัดมีผลต่อความเร็วในการตอบสนองหรือไม่?

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

ทำไม curl แสดงขนาดเท่ากันทั้งที่มีและไม่มีแฟล็กบีบอัด?

เพราะ --compressed แสดงขนาดของเนื้อหาที่คลายแล้ว ปริมาณเครือข่ายจริงน้อยกว่า วัดสตรีมดิบด้วยสคริปต์แยกต่างหาก

บีบอัดเนื้อหาของคำขอ POST ได้หรือไม่?

ได้ ไคลเอนต์ตั้ง Content-Encoding ในคำขอ แต่เซิร์ฟเวอร์ต้องรองรับการคลาย ไม่ใช่ทุกเซิร์ฟเวอร์ที่รองรับ ดังนั้นตรวจสอบเอกสาร API

การบีบอัดทำงานผ่านพร็อกซี Proxeon หรือไม่?

ได้ พร็อกซีส่งหัวข้อ Accept-Encoding และ Content-Encoding อย่างโปร่งใส ดังนั้นการประหยัดทั้งหมดจึงยังคงอยู่ นี่คือเหตุผลที่ควรวัดผ่านพร็อกซีในสภาพจริง

จะทำอย่างไรถ้าเซิร์ฟเวอร์ไม่บีบอัด?

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

ควรบีบอัดรูปภาพผ่าน Accept-Encoding หรือไม่?

ไม่ รูปแบบเช่น JPEG และ WebP บีบอัดอยู่แล้ว การบีบอัดเพิ่มไม่ได้ประโยชน์และเปลือง CPU

จะเลือกระหว่าง zstd และ brotli อย่างไร?

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

จำเป็นต้องใช้ Vary ในการทำงานฝั่งไคลเอนต์หรือไม่?

ในฐานะไคลเอนต์ คุณไม่ได้ตั้งค่า Vary เซิร์ฟเวอร์เป็นคนตั้ง แต่การเข้าใจมันมีประโยชน์: มันอธิบายว่าทำไมแคชบางครั้งส่งเวอร์ชันบีบอัด บางครั้งไม่บีบอัด

บทสรุป

คุณเดินทางจากทฤษฎีสู่การวัดจริง ตอนนี้คุณเข้าใจว่าการบีบอัดตกลงกันผ่าน Accept-Encoding, Content-Encoding และ Vary อย่างไร คุณสามารถขอการบีบอัดใน curl, Python และ Node.js และที่สำคัญคือวัดปริมาณเครือข่ายจริงก่อนและหลัง คุณรู้ว่าทำไมคำตอบบางครั้งไม่บีบอัดและวิธีวินิจฉัยสามสาเหตุหลัก คุณจัดการกับข้อผิดพลาดซ่อนเร้น เช่น การบีบอัดซ้ำ สตรีมเสียหาย และการคลายด้วยตนเอง และคุณไม่เปลืองทรัพยากรกับการบีบอัดรูปภาพ วิดีโอ และไฟล์เก็บถาวรอีกต่อไป

สิ่งที่ทำต่อไป รันสคริปต์วัดกับ endpoint หลักทั้งหมดในโปรเจกต์ของคุณ หาจุดที่ไม่ได้บีบอัดและขอการบีบอัดอย่างชัดเจน บันทึกไบต์ที่ประหยัดต่อวัน เพื่อให้เห็นประโยชน์เป็นตัวเงินเมื่อใช้พร็อกซี Proxeon เมื่อเข้าใจพื้นฐานแล้ว ไปต่อที่การวัดเป็นกลุ่มและลำดับความสำคัญของอัลกอริทึมผ่านค่า q

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