วิดีโอและคำบรรยาย · ตัวดาวน์โหลดสื่อโดยตรง
การเปลี่ยนเส้นทาง ความยาวเนื้อหา และไบต์แรก: อายุการใช้งานของการดาวน์โหลดโดยตรง
· มันทำงานอย่างไร
http ดาวน์โหลด นักพัฒนาเวิร์กโฟลว์
ตั้งแต่วินาทีที่การดาวน์โหลดเริ่มต้นจนถึงไบต์แรกมาถึง ขั้นตอน HTTP หลายขั้นตอนจะเกิดขึ้นอย่างมองไม่เห็น โพสต์นี้จะอธิบายการเปลี่ยนเส้นทาง ส่วนหัวการตอบกลับ และวิธีการดึงข้อมูลรายงาน และความหมายของเครื่องมือที่ตั้งชื่อโฮสต์ไว้ข้างหน้า
การดาวน์โหลดเริ่มต้นขึ้นและไม่มีอะไรเกิดขึ้นเป็นเวลาห้าวินาที — ขั้นตอนที่มองไม่เห็นระหว่างการคลิกและไบต์แรก
ห้าวินาทีที่เงียบสงบหลังจากการกดดาวน์โหลดอาจมีการตั้งค่าการเชื่อมต่อ การเปลี่ยนเส้นทาง การตรวจสอบการอนุญาตเซิร์ฟเวอร์ และการรอส่วนหัวการตอบกลับก่อนที่ส่วนเนื้อหาจะพร้อมใช้งาน แถบความคืบหน้าไม่สามารถเลื่อนไปได้จนกว่าจำนวนไบต์จะมาถึง ดังนั้นการหน่วงเวลาก่อนการอัปเดตครั้งแรกจึงไม่ใช่อินเทอร์เฟซที่ค้างโดยอัตโนมัติ
ลิงก์ตรวจสอบที่เป็นตัวเลือกสามารถแสดงสถานะ, ประเภทเนื้อหา, ความยาวเนื้อหา และช่วงไบต์ผ่าน HEAD เมื่อโฮสต์อนุญาตให้อ่านส่วนหัวแบบข้ามต้นทาง เป็นคำขอแยกต่างหาก ไม่ใช่การอุ่นเครื่องที่รับประกันว่าจะเร่งความเร็ว GET ในภายหลัง เนื่องจากการโทรทั้งสองใช้ `cache: no-store` การติดตามที่มีการแบ่งเวลามีประโยชน์มากกว่าการรอตามความรู้สึก เนื่องจากแยกการรอคิว การเชื่อมต่อ การรอของเซิร์ฟเวอร์ และขั้นตอนการดาวน์โหลดเนื้อหาที่เปิดเผยโดยเบราว์เซอร์
บรรทัดคำขอและส่วนหัว: สิ่งที่เบราว์เซอร์ส่ง — วิธีการ เส้นทาง ยอมรับ และสิ่งที่การดึงข้อมูลข้ามไซต์ระงับไว้ตามค่าเริ่มต้น
ดาวน์โหลดใช้ GET กับ HTTPS URL ที่ผ่านการตรวจสอบแล้ว การดึงข้อมูลและเบราว์เซอร์สร้างส่วนหัวคำขอจริง รหัสแอปพลิเคชันละเว้นข้อมูลประจำตัวอย่างชัดเจนและระงับผู้อ้างอิง ไม่ปลอมแปลงตัวแทนผู้ใช้หรือผู้อ้างอิง แนบคุกกี้การเข้าสู่ระบบ หรือเพิ่มโทเค็นแพลตฟอร์ม
คำขอข้ามไซต์ยังสามารถรวมบริบทที่ควบคุมโดยเบราว์เซอร์ เช่น Origin ส่วนหัวที่แน่นอนจะแตกต่างกันไปตามเบราว์เซอร์และสภาพแวดล้อม ดังนั้น DevTools จึงเป็นหลักฐานสำหรับการดำเนินการเฉพาะ แหล่งที่มาพิสูจน์วิธีที่กำหนดค่าไว้ โหมดข้อมูลรับรอง นโยบายผู้อ้างอิง โหมดแคช นโยบายการเปลี่ยนเส้นทาง และยกเลิกสัญญาณ การแสดงส่วนหัวเป็นทางเลือกในการตอบกลับ HTTP และ CORS สามารถจำกัดการมองเห็นสคริปต์ ดังนั้นการไม่มียอดรวมที่แสดงจึงไม่ใช่หลักฐานของไฟล์ว่าง
การเปลี่ยนเส้นทาง: เมื่อโฮสต์ที่คุณตั้งชื่อมอบคุณให้กับบุคคลอื่น - การดึงข้อมูลเป็นไปตามการตอบสนองของ 301, 302 และ 307 อย่างไร และ response.url เปิดเผยที่อยู่สุดท้ายอย่างไร
ทั้ง HEAD และ GET ระบุ `redirect: follow` 301, 302, 307 หรือการเปลี่ยนเส้นทางอื่นที่สนับสนุนจึงสามารถย้ายคำขอจาก URL เริ่มต้นที่ประกาศไปยังทรัพยากรสุดท้ายได้ การดึงข้อมูลจะได้รับการแก้ไขหลังจากที่ลูกโซ่ถึงการตอบสนองหรือล้มเหลวภายใต้นโยบายเบราว์เซอร์เท่านั้น
โปรแกรมดาวน์โหลดไม่แสดง `response.url` แม้ว่าการตอบกลับการดึงข้อมูลจะเปิดเผยที่อยู่สุดท้ายก็ตาม หากต้องการตรวจสอบฮอป ให้เก็บบันทึกเครือข่ายไว้และตรวจสอบแถวการเปลี่ยนเส้นทางที่นั่น เรื่องนี้สำคัญเนื่องจากการประกาศล่วงหน้าจะตั้งชื่อโฮสต์ที่ให้มา ไม่สามารถประกาศตำแหน่งที่เซิร์ฟเวอร์เลือกในภายหลังได้ สำหรับการเก็บรักษาสไตล์ 307 ความหมายของวิธีการจะแตกต่างจากพฤติกรรมการเขียนใหม่ทั่วไป ซึ่งเป็นอีกเหตุผลหนึ่งที่ทำให้เชื่อถือการติดตามเบราว์เซอร์แทนที่จะสรุปทุกการกระโดดว่าเหมือนกัน
ความยาวเนื้อหาและประเภทเนื้อหา: สิ่งที่ส่วนหัวการตอบกลับสัญญา — ขนาดและประเภททราบได้อย่างไรก่อนที่เนื้อหาจะเสร็จสิ้น
Content-Type ติดป้ายกำกับการตอบสนองและกลายเป็นประเภท Blob ในขณะที่ Content-Length ที่มีขีดจำกัดเชิงบวกจะให้ผลรวมที่คาดหวัง เส้นทาง GET ปฏิเสธผลรวมที่ประกาศไว้เกินกว่า 2 GiB ก่อนการสตรีม หากส่วนหัวหายไป ความคืบหน้าจะยังคงไม่แน่นอน และไบต์ที่ได้รับจริงจะบังคับใช้การป้องกัน
ส่วนหัวเป็นคำสั่งจากเซิร์ฟเวอร์ ไม่รับประกันว่าเนื้อหาจะครบถ้วนหรือตรงกับป้ายกำกับ การเชื่อมต่ออาจปิดก่อนกำหนด และแอปพลิเคชันสามารถกำหนดค่าข้อมูลเมตา MIME ไม่ถูกต้อง ToolAcre ใช้ค่าเหล่านี้สำหรับคำอธิบาย ความคืบหน้า และการตัดสินใจตั้งชื่อ โดยไม่อ้างว่าค่าเหล่านี้ตรวจสอบความถูกต้องภายในของสื่อ โค้ดยังตรวจสอบไบต์ที่สะสมอีกครั้งกับค่าสูงสุด เพื่อให้มั่นใจว่าความยาวที่ขาดไปหรือไม่ถูกต้องจะไม่ปิดขอบเขตหน่วยความจำของแอปพลิเคชัน
ตัวอย่างการทำงาน: ลิงก์ 'โดยตรง' ที่ตีกลับผ่านตัวย่อลิงก์ - อ่านแต่ละการกระโดดในแผงเครือข่าย
สำหรับลิงก์ที่อนุญาตแบบสั้น ให้เปิด DevTools เปิดใช้งานเก็บรักษาบันทึก และเริ่มต้นด้วยการตรวจสอบลิงก์หรือดาวน์โหลด ขยายแถวเริ่มต้นเพื่อดูสถานะการเปลี่ยนเส้นทางและตำแหน่งเมื่อถูกเปิดเผย จากนั้นเดินตามสายโซ่ไปยังการตอบกลับที่ร่างกายเป็นผู้ส่งไฟล์ เปรียบเทียบชื่อโฮสต์แต่ละชื่อกับโครงสร้างพื้นฐานของผู้เผยแพร่โฆษณาที่คาดหวัง
คอลัมน์เวลาไบต์แรกแยกระหว่างการรอและการถ่ายโอน เมื่อชิ้นส่วนมาถึง ToolAcre รายงานจำนวนไบต์ที่สะสม ด้วย Content-Length จึงสามารถคำนวณเศษส่วนได้ ไบต์แรกล่าช้าตามด้วยเนื้อหาที่เร็ว บ่งชี้ถึงปัญหาคอขวดที่แตกต่างจากการตอบสนองทันทีตามด้วยการถ่ายโอนที่ยั่งยืนอย่างช้าๆ การเปรียบเทียบระหว่างการลองใหม่ควรรักษาการตั้งค่าแคชและสภาวะเครือข่ายให้สอดคล้องกัน มิฉะนั้นโปรไฟล์เวลาที่เปลี่ยนแปลงอาจอธิบายการตั้งค่าการทดสอบมากกว่าที่มา
เหตุใดการเปลี่ยนเส้นทางจึงมีความสำคัญสำหรับโฮสต์ที่ประกาศ — เครื่องมือจะประกาศ URL ที่คุณมอบให้ การเปลี่ยนเส้นทางอาจนำไปสู่ที่อื่น และแผงเครือข่ายจะแสดงตำแหน่ง
การประกาศชื่อโฮสต์ที่ส่งมานั้นมีประโยชน์แต่จะไม่สมบูรณ์หากอนุญาตให้มีการเปลี่ยนเส้นทาง ตัวย่อที่เชื่อถือได้สามารถชี้ไปที่พื้นที่เก็บข้อมูล CDN ได้อย่างถูกต้องตามกฎหมาย ในขณะที่เครือข่ายที่ไม่คาดคิดสามารถข้ามองค์กรได้ อินเทอร์เฟซไม่ได้แก้ไขเชนนั้นล่วงหน้าเนื่องจากการทำเช่นนั้นจำเป็นต้องมีการติดต่อ
ผู้ตรวจสอบที่ต้องการรายการที่อนุญาตควรตรวจสอบชื่อโฮสต์ทุกชื่อที่สังเกต หรือหลีกเลี่ยงลิงก์ที่สั้นลงทั้งหมด ToolAcre บล็อกปลายทางส่วนตัวที่ชัดเจนใน URL ที่ส่งมา แต่ไม่ได้อ้างว่าจะตรวจสอบเป้าหมายการเปลี่ยนเส้นทางแต่ละรายการในรหัสแอปพลิเคชันอีกครั้ง การป้องกันเครือข่ายเบราว์เซอร์ยังคงเป็นอีกชั้นหนึ่ง CDN สุดท้ายอาจมีนโยบายความเป็นส่วนตัวและเขตอำนาจศาลที่แตกต่างจากตัวย่อ ดังนั้นการตรวจสอบปลายทางควรขยายเลยแบรนด์ที่มองเห็นได้ในลิงก์ที่ส่งมา
สิ่งนี้ไม่ครอบคลุม — คำขอช่วง การดำเนินการต่อ หรือเซิร์ฟเวอร์ที่สตรีมด้วยการเข้ารหัสแบบ chunked และไม่มีความยาว
เวิร์กโฟลว์นี้ไม่ส่งคำขอช่วง ดำเนินการไบต์ที่ถูกขัดจังหวะต่อ บังคับความยาวเนื้อหา หรือตีความเฟรมการถ่ายโอนแบบก้อนใหม่เป็นยอดรวมที่ทราบ HEAD สามารถรายงาน `Accept-Ranges: bytes` ได้ แต่การดาวน์โหลดปัจจุบันยังคงดำเนินการ GET ปกติหนึ่งครั้ง และรวบรวมการตอบสนองตั้งแต่ต้น
มันไม่รับรองความถูกต้องด้วย การเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้อาจทำให้เกิดการปฏิเสธ HTML หรือ HTTP เนื่องจากคุกกี้ถูกละเว้น การปฏิบัติต่อหน้านั้นเป็นสื่อที่ดาวน์โหลดได้อาจผิด ดังนั้นคำเตือน MIME ก่อนหน้าและการตรวจสอบส่วนหัวการตอบกลับขั้นสุดท้ายจึงเป็นประโยชน์ต่อการป้องกัน เซิร์ฟเวอร์ที่ใช้เฟรมแบบกลุ่มหรือระดับโปรโตคอลสามารถนำเสนอเนื้อหาที่สมบูรณ์โดยไม่มีความยาวเนื้อหา และ UI หลีกเลี่ยงการเปลี่ยนความไม่แน่นอนที่ถูกต้องตามกฎหมายให้เป็นศูนย์ได้อย่างถูกต้อง
ประเด็นสำคัญ: รู้จักฮ็อพของคุณ — วิธีใช้ Direct Media Downloader และแผงเครือข่ายร่วมกันเพื่อดูทุกโฮสต์ที่ติดต่อจริง
ลิงก์โดยตรงอธิบายการเริ่มต้นการเดินทาง HTTP ไม่จำเป็นต้องมีเซิร์ฟเวอร์จริงตัวเดียว ลำดับที่สังเกตได้คือ GET เริ่มต้น, การเปลี่ยนเส้นทางที่ตามมา, ส่วนหัวการตอบกลับ, ส่วนเนื้อหาแรก, ส่วนต่อมา, การสร้าง Blob และการดำเนินการบันทึกในเครื่องแยกต่างหากหลังจากเสร็จสิ้น
จับคู่การประกาศโฮสต์ครั้งแรกของ Direct Media Downloader กับแผงเครือข่ายเมื่อแหล่งที่มาของปลายทางมีความสำคัญ การรวมกันดังกล่าวจะแสดงสิ่งที่สัญญาไว้ก่อนการติดต่อและสิ่งที่เกิดขึ้นจริงในภายหลัง โดยไม่ต้องสร้างการสนับสนุนสำหรับการถ่ายโอนที่ดำเนินการต่อได้ พร็อกซีที่ซ่อนอยู่ หรือการทำนายการเปลี่ยนเส้นทาง ลำดับเหตุการณ์นี้ยังอธิบายด้วยว่าเหตุใดการบันทึกจึงปรากฏขึ้นหลังจากเสร็จสิ้นเท่านั้น: การใช้งานไม่ได้เปิดเผย Blob ที่ประกอบบางส่วนราวกับว่าเป็นการตอบสนองแบบเต็มที่ได้รับการยืนยัน