ผลต่างระหว่างรุ่นของ "การเข้ารหัสขนส่งเป็นชิ้นส่วน"
เนื้อหาที่ลบ เนื้อหาที่เพิ่ม
ไม่มีความย่อการแก้ไข ป้ายระบุ: ย้อนด้วยมือ ถูกย้อนกลับแล้ว แก้ไขจากอุปกรณ์เคลื่อนที่ แก้ไขจากเว็บสำหรับอุปกรณ์เคลื่อนที่ |
ล ย้อนการแก้ไขที่อาจเป็นการทดลอง หรือก่อกวนด้วยบอต ไม่ควรย้อน? แจ้งที่นี่ ป้ายระบุ: ย้อนด้วยมือ ลิงก์แก้ความกำกวม |
||
บรรทัด 2:
บางครั้งเครื่องให้บริการเอชทีทีพีใช้[[การบีบอัดข้อมูล]] ([[gzip]] หรือ [[deflate]]) เพื่อลดเวลาที่ใช้ในการส่งถ่ายข้อมูล แม้ว่าการเข้ารหัสขนส่งเป็นชิ้นส่วนสามารถใช้ได้กับทรัพยากรที่บีบอัดเพื่อลดปริมาณชิ้นส่วนที่ส่ง แต่หลังจากแบ่งแล้ว ชิ้นส่วนต่าง ๆ ที่ไม่ได้มีการบีบอัดในตัวเองก็จะไม่มีประโยชน์อะไร แถมยังทำให้เซิร์ฟเวอร์เสียเวลาในการบีบอัดอย่างเต็มที่ แล้วข้อมูลบีบอัดที่ออกมาจึงค่อยถูกตัดแบ่งตามแผน ส่วนกรณีที่มีการตัดแบ่งเป็นชิ้นส่วนก่อนแล้วค่อยนำไปบีบอัด มีข้อดีตรงที่สามารถบีบอัดได้ทันทีในขณะที่ข้อมูลกำลังส่ง เพราะข้อมูลที่นำมาบีบอัดมีขนาดเล็ก แต่ก็มีข้อเสียคือไม่สามารถทราบถึงขนาดข้อมูลสุดท้ายที่บีบอัดแล้วได้โดยง่าย
== รูปแบบ ==
เครื่องแม่ข่ายจะส่งส่วนหัวของการตอบรับ <tt>Transfer-Encoding<tt> โดยกำหนดค่าเป็น <tt>chunked</tt> แต่ละชิ้นส่วนจะขึ้นต้นด้วยขนาดของข้อมูลในชิ้นส่วนนั้นเป็น[[เลขฐานสิบหก]] ตามด้วยอักขระ[[ปัดแคร่]] (carriage return) อักขระ[[ป้อนบรรทัด]] (line feed) และข้อมูลในส่วนนั้น ในการนำไปใช้บางอย่าง จะมีอักขระ[[ช่องว่าง]] (0x20) เพิ่มเข้ามาระหว่างขนาดของชิ้นส่วน กับอักขระปัดแคร่ป้อนบรรทัด และเมื่อไม่มีข้อมูลที่จะส่งต่อแล้ว ชิ้นส่วนตอบรับสุดท้ายจะจบด้วยขนาดที่เท่ากับ 0
=== ตัวอย่างข้อความตอบรับ ===
<pre>
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
23
This is the data in the first chunk
1A
and this is the second one
0
</pre>
== แหล่งข้อมูลอื่น ==
* RFC 2616 ส่วนที่ 3.6.1
[[หมวดหมู่:เอชทีทีพี]]
[[หมวดหมู่:การจัดการข้อมูล]]
| |||