เมื่อเว็บเซอร์ส่งหน้าทำไมพวกเขาไม่ส่ง CSS, JS และรูปภาพที่จำเป็นทั้งหมดโดยไม่ถาม

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

1. เบราว์เซอร์ส่งคำขอ GET เริ่มต้นสำหรับหน้าเว็บและรอการตอบกลับจากเซิร์ฟเวอร์
2. เบราว์เซอร์ส่งคำขอ GET อีกครั้งสำหรับไฟล์ css และรอการตอบกลับจากเซิร์ฟเวอร์
3. เบราว์เซอร์ส่งคำขอ GET อีกครั้งสำหรับไฟล์รูปภาพและรอการตอบกลับจากเซิร์ฟเวอร์

เมื่อใดที่พวกเขาสามารถใช้เส้นทางสั้น ๆ ที่ตรงและประหยัดเวลานี้แทน

1. เบราว์เซอร์ส่งคำขอ GET สำหรับหน้าเว็บ
2. เว็บเซิร์ฟเวอร์ตอบสนองด้วย ( index.htmlตามด้วยstyle.cssและimage.jpg )

คำตอบสั้น ๆ คือ "เพราะ HTTP ไม่ได้ถูกออกแบบมาเพื่อมัน"

Tim Berners-Leeไม่ได้ออกแบบโปรโตคอลเครือข่ายที่มีประสิทธิภาพและขยายได้ เป้าหมายการออกแบบเดียวของเขาคือความเรียบง่าย (อาจารย์ของชั้นเรียนเครือข่ายของฉันในวิทยาลัยกล่าวว่าเขาควรจะละทิ้งงานให้กับมืออาชีพ) ปัญหาที่คุณร่างไว้เป็นเพียงหนึ่งในปัญหามากมายที่มีโปรโตคอล HTTP ในรูปแบบดั้งเดิม:

• ไม่มีรุ่นโปรโตคอลเพียงแค่ขอทรัพยากร
• ไม่มีส่วนหัว
• แต่ละคำขอต้องมีการเชื่อมต่อ TCP ใหม่
• ไม่มีการบีบอัด

โปรโตคอลได้รับการแก้ไขในภายหลังเพื่อแก้ไขปัญหาเหล่านี้:

• การร้องขอถูกรุ่นแล้วตอนนี้การร้องขอมีลักษณะเหมือน GET /foo.html HTTP/1.1
• มีการเพิ่มส่วนหัวสำหรับข้อมูลเมตาที่มีทั้งคำขอและการตอบกลับ
• การเชื่อมต่อได้รับอนุญาตให้ใช้ซ้ำได้ Connection: keep-alive
• การตอบสนองแบบ Chunked ถูกนำมาใช้เพื่อให้การเชื่อมต่อสามารถนำกลับมาใช้ใหม่ได้แม้ว่าจะไม่ทราบขนาดของเอกสารล่วงหน้า
• เพิ่มการบีบอัด Gzip

ณ จุดนี้ HTTP ได้รับการดำเนินการเท่าที่จะทำได้โดยไม่ทำลายความเข้ากันได้ย้อนหลัง

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

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

• SPDY ช่วยให้ไคลเอนต์และเซิร์ฟเวอร์บีบอัดคำขอและส่วนหัวการตอบสนองซึ่งลดการใช้แบนด์วิดท์เมื่อส่วนหัวที่คล้ายกัน (เช่นคุกกี้) ถูกส่งซ้ำไปซ้ำมาหลายคำขอ
• SPDY อนุญาตการร้องขอมัลติเพล็กซ์พร้อมกันผ่านการเชื่อมต่อเดียวช่วยประหยัดการเดินทางไปกลับระหว่างไคลเอนต์และเซิร์ฟเวอร์และป้องกันไม่ให้ทรัพยากรที่มีลำดับความสำคัญต่ำปิดกั้นคำขอที่มีลำดับความสำคัญสูงกว่า
• SPDY อนุญาตให้เซิร์ฟเวอร์ส่งทรัพยากรไปยังไคลเอนต์ที่รู้ว่าไคลเอ็นต์ต้องการ (เช่นไฟล์ JavaScript และ CSS) โดยไม่ต้องรอให้ไคลเอนต์ร้องขอพวกเขาทำให้เซิร์ฟเวอร์ใช้แบนด์วิดท์ที่ไม่มีการใช้งานอย่างมีประสิทธิภาพ

หากคุณต้องการให้บริการเว็บไซต์ของคุณด้วย SPDY ไปยังเบราว์เซอร์ที่สนับสนุนคุณสามารถทำได้ ยกตัวอย่างเช่นApache มี mod_spdy

SPDY เป็นพื้นฐานสำหรับHTTP เวอร์ชัน 2พร้อมเทคโนโลยีพุชเซิร์ฟเวอร์

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

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

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

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

เว็บเบราว์เซอร์สามารถสร้างคำขอ HTTP สองคำขอพร้อมกันได้ สิ่งนี้ไม่ต่างจาก AJAX - ทั้งสองวิธีการแบบอะซิงโครนัสสำหรับการโหลดหน้าเว็บ - การโหลดไฟล์แบบอะซิงโครนัสและการโหลดเนื้อหาแบบอะซิงโครนัส ด้วยการรักษาความปลอดภัยเราสามารถสร้างคำขอหลายคำขอโดยใช้การเชื่อมต่อเดียวและด้วยการวางท่อทำให้เราสามารถร้องขอได้หลายคำขอโดยไม่ต้องรอคำตอบ เทคนิคทั้งสองนี้เร็วมากเพราะค่าใช้จ่ายส่วนใหญ่มาจากการเปิด / ปิดการเชื่อมต่อ TCP:

ประวัติเว็บเล็กน้อย ...

หน้าเว็บเริ่มต้นเป็นอีเมลข้อความธรรมดาโดยระบบคอมพิวเตอร์ได้รับการออกแบบรอบความคิดนี้ทำให้เกิดแพลตฟอร์มการสื่อสารที่ไม่ต้องเสียค่าใช้จ่ายใด ๆ เว็บเซิร์ฟเวอร์ยังคงเป็นกรรมสิทธิ์อยู่ในขณะนั้น ต่อมาเลเยอร์เพิ่มเติมถูกเพิ่มลงใน "ข้อมูลจำเพาะอีเมล" ในรูปแบบของประเภท MIME เพิ่มเติมเช่นรูปภาพสไตล์สคริปต์ ฯลฯ หลังจากนั้นทั้งหมด MIME หมายถึงส่วนขยายจดหมายทางอินเทอร์เน็ตเอนกประสงค์ ไม่ช้าก็เร็วเรามีสิ่งที่เป็นหลักในการสื่อสารทางอีเมลมัลติมีเดียเว็บเซิร์ฟเวอร์มาตรฐานและหน้าเว็บ

HTTP กำหนดให้ส่งข้อมูลในบริบทของข้อความที่คล้ายอีเมลแม้ว่าข้อมูลส่วนใหญ่มักจะไม่ใช่อีเมลจริง

ในฐานะที่เป็นเทคโนโลยีเช่นนี้วิวัฒนาการมันจำเป็นต้องอนุญาตให้นักพัฒนาเพื่อรวมคุณสมบัติใหม่ ๆ โดยไม่ทำลายซอฟต์แวร์ที่มีอยู่ ตัวอย่างเช่นเมื่อมีการเพิ่มประเภท MIME ใหม่ลงในข้อมูลจำเพาะ - สมมุติว่า JPEG - มันจะใช้เวลาสักครู่สำหรับเว็บเซิร์ฟเวอร์และเว็บเบราว์เซอร์เพื่อนำไปใช้ คุณไม่เพียง แต่บังคับให้ JPEG เป็นข้อมูลจำเพาะและเริ่มส่งไปยังเว็บเบราว์เซอร์ทั้งหมดคุณอนุญาตให้เว็บเบราว์เซอร์ร้องขอทรัพยากรที่รองรับซึ่งทำให้ทุกคนมีความสุขและเทคโนโลยีก้าวไปข้างหน้า โปรแกรมอ่านหน้าจอจำเป็นต้องใช้ JPEG ทั้งหมดในหน้าเว็บหรือไม่ อาจจะไม่. คุณควรถูกบังคับให้ดาวน์โหลดไฟล์ Javascript จำนวนมากหากอุปกรณ์ของคุณไม่รองรับ Javascript? อาจจะไม่. Googlebot จำเป็นต้องดาวน์โหลดไฟล์ Javascript ทั้งหมดของคุณเพื่อสร้างดัชนีเว็บไซต์ของคุณอย่างถูกต้องหรือไม่? Nope

ที่มา: ฉันได้พัฒนาเว็บเซิร์ฟเวอร์ตามเหตุการณ์เช่น Node.js. มันเรียกว่ารวดเร็วเซิร์ฟเวอร์

อ้างอิง:

• การเชื่อมต่อ HTTP แบบต่อเนื่อง (keep-alive)
• HTTP pipelining
• การเชื่อมต่อ HTTP / 1.1 (RFC 2616)

อ่านเพิ่มเติม:

• SPDY แตกต่างจากมัลติเพล็กซ์ http ของ Keep การเชื่อมต่อที่ยังมีชีวิตอยู่หรือไม่
• ทำไม HTTP / 2.0 จึงดูไม่น่าสนใจ

เพราะพวกเขาไม่รู้ว่าทรัพยากรเหล่านั้นคืออะไร เนื้อหาที่หน้าเว็บต้องการจะถูกเข้ารหัสลงใน HTML หลังจาก parser กำหนดสิ่งที่สินทรัพย์เหล่านั้นสามารถร้องขอ y โดยตัวแทนผู้ใช้

นอกจากนี้เมื่อทราบเนื้อหาเหล่านั้นแล้วพวกเขาจะต้องให้บริการทีละรายการเพื่อให้สามารถแสดงส่วนหัวที่เหมาะสม (เช่นประเภทเนื้อหา) เพื่อให้ตัวแทนผู้ใช้รู้วิธีจัดการ

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

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

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

จากนั้นรับเฉพาะไฟล์ที่ไม่ได้เปลี่ยนรับส่งผ่านการเชื่อมต่อ TCP เดียว (โดยใช้การไพพ์ไลน์ HTTP ผ่านการเชื่อมต่อแบบถาวร) และคาดเดาอะไร มันเป็นวิธีการทำงานแล้ว (คุณสามารถใช้If-Modified- เนื่องจากแทนที่จะเป็นIf-None-Match )

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

ในการทำเช่นนั้นคุณไม่จำเป็นต้องมี CSS หรือ JavaScript ในไฟล์แยกต่างหากคุณสามารถรวมไว้ในไฟล์ HTML หลักโดยใช้<style>และ<script>แท็ก (คุณอาจไม่จำเป็นต้องทำมันด้วยตนเองแม่แบบเครื่องยนต์ของคุณอาจทำโดยอัตโนมัติ) . คุณสามารถรวมภาพในไฟล์ HTML โดยใช้data URIเช่นนี้:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

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

ตอนนี้ถ้าคุณใส่ใจจริงๆคุณสามารถทำให้เว็บสคริปต์ของคุณฉลาดพอที่จะทำให้ทั้งสองโลกดีที่สุด: ตามคำขอแรก (ผู้ใช้ไม่มีคุกกี้) ส่งทุกอย่าง (CSS, JavaScript, ภาพ) ที่ฝังอยู่ใน HTML เดียว ไฟล์ตามที่อธิบายไว้ข้างต้นเพิ่มlink rel = "prefetch" แท็กสำหรับการคัดลอกไฟล์ภายนอกและเพิ่มคุกกี้ หากผู้ใช้มีอยู่แล้วคุกกี้ (เช่น. เขาได้ไปเยือนมาก่อน) แล้วส่งเขาเพียง HTML ปกติ<img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">ฯลฯ

ดังนั้นในการเยี่ยมชมเบราว์เซอร์ครั้งแรกจะขอเพียงไฟล์ HTML เดียวและได้รับและแสดงทุกอย่าง จากนั้นมันจะ (เมื่อไม่ได้ใช้งาน) โหลด CSS ภายนอกที่ระบุไว้ล่วงหน้า, JS, รูปภาพ ครั้งต่อไปที่ผู้ใช้เยี่ยมชมเบราว์เซอร์จะขอและรับทรัพยากรที่เปลี่ยนแปลงเท่านั้น (อาจเป็นเพียง HTML ใหม่)

ข้อมูลรูปภาพ CSS + JS + พิเศษจะถูกส่งสองครั้งเท่านั้นแม้ว่าคุณจะคลิกหลายร้อยครั้งบนเว็บไซต์ ดีกว่าหลายร้อยเท่าตามที่คุณแนะนำ และมันจะไม่เคย (ไม่ใช่ในครั้งแรกและในครั้งต่อไป) ใช้มากกว่าหนึ่งรอบการเดินทางที่เพิ่มความล่าช้า

ตอนนี้ถ้ามันฟังดูเหมือนทำงานมากเกินไปและคุณไม่ต้องการไปกับโพรโทคอลอื่นเช่นSPDYก็มีโมดูลเช่นmod_pagespeedสำหรับ Apache ซึ่งสามารถทำงานบางอย่างให้คุณโดยอัตโนมัติ (รวมไฟล์ CSS / JS หลายไฟล์ไว้ด้วยกัน) ให้เป็นหนึ่งเดียวปรับขนาดเล็ก CSS อัตโนมัติและย่อให้เล็กลงสร้างตัวยึดตำแหน่งเล็ก ๆ ของภาพที่แทรกไว้ในขณะที่รอให้ต้นฉบับโหลดภาพที่กำลังโหลดขี้เกียจ ฯลฯ ) โดยไม่จำเป็นต้องให้คุณแก้ไขบรรทัดเดียวของหน้าเว็บ

HTTP2 ขึ้นอยู่กับ SPDY และทำสิ่งที่คุณแนะนำ:

ในระดับสูง HTTP / 2:

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

มีให้ใช้มากกว่านี้ในHTTP 2 Faq

เพราะมันไม่ได้คิดว่าสิ่งเหล่านี้จำเป็นจริงๆ

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

ปัญหาแรกคือการที่ไม่มีมาตรฐานวิธีการที่มีประสิทธิภาพในการระบุประเภทไฟล์ที่สิ้นสุดเซิร์ฟเวอร์ HTTP จัดการผ่านกลไก Content-Type แต่ไม่ได้ช่วยเซิร์ฟเวอร์ที่ต้องคิดสิ่งนี้ด้วยตัวเอง (ส่วนหนึ่งเพื่อให้รู้ว่าจะใส่อะไรลงใน Content-Type) ส่วนขยายชื่อไฟล์ได้รับการสนับสนุนอย่างกว้างขวาง แต่บางครั้งก็เปราะบางและหลอกง่ายเพื่อจุดประสงค์ที่เป็นอันตราย ข้อมูลเมตาของระบบแฟ้มมีความบอบบางน้อยกว่า แต่ระบบส่วนใหญ่ไม่รองรับเป็นอย่างดีดังนั้นเซิร์ฟเวอร์จึงไม่ต้องกังวล การดมกลิ่นเนื้อหา (เนื่องจากเบราว์เซอร์บางตัวและfileคำสั่งUnix พยายามทำ) อาจมีประสิทธิภาพหากคุณยินดีที่จะทำให้มีราคาแพง แต่การดมกลิ่นที่แข็งแกร่งนั้นแพงเกินไปที่จะนำไปใช้กับฝั่งเซิร์ฟเวอร์ได้

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

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

บรรทัดล่างคือว่าการหาอ้างอิงเหล่านี้บนฝั่งเซิร์ฟเวอร์เป็นปัญหามากกว่าก็คุ้มค่า ดังนั้นพวกเขาปล่อยให้ลูกค้าหาสิ่งที่ต้องการ