SPDY เป็นโพรโตคอลที่กูเกิลออกแบบมาเพื่อเร่งความเร็วในการส่งข้อมูลไปยังเบราว์เซอร์ ปัจจุบันนอกจากเว็บของกูเกิลเองแล้ว ก็เริ่มมีเว็บอื่นหันมาใช้ SPDY มากขึ้น (เช่น Twitter) ล่าสุดทาง Matt Mullenweg ผู้ก่อตั้ง Wordpress.com ได้ออกมาประกาศว่าเริ่มใช้งาน SPDY แล้วเหมือนกัน
สิ่งที่น่าสนใจคือทางซอฟต์แวร์ฝั่งเซิร์ฟเวอร์ซึ่ง Wordpress.com นั้นใช้งาน nginx เป็นตัวหลักในการให้บริการอยู่ และเป็นสปอนเซอร์ให้นักพัฒนาของ nginx พัฒนาโมดูลสำหรับ SPDY นี้ขึ้น
ถ้าใครที่ใช้ nginx อยู่แล้ว อยากเปิดใช้งาน SPDY ด้วย ตอนนี้ต้องโหลดแพตช์มาคอมไพล์เองไปก่อน (ใช้กับ nginx เวอร์ชัน 1.3.x)
สำหรับฝั่งเบราว์เซอร์ Chrome เวอร์ชันหลังๆ สนับสนุน SPDY หมดแล้ว หรือถ้าใช้ Firefox ต้องเป็นรุ่น 11 ขึ้นไปครับ
ที่มา: บล็อกของ Matt, nginx mailinglist
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
Comments
"Goals for SPDY":
"1) To target a 50% reduction in page load time."
ค่อนข้างยากที่จะเชื่อว่าจะเป็นไปได้ .. หากมองว่า TCP มันโบราณ มองแบบนี้มันก็สร้างแรงจูงใจได้อยู่
แต่การจะ Optimize สิ่งที่เสริมอยู่ปัจจุบัน เช่น การลด tcp handshake, ทำ compression, pipelining, multiple connections,.. .etc แล้วให้เห็นผลชัดคือที่ 50% improvement แบบนี้ ถือว่าเป็นงานยากมาก .. เพราะปกติงานวิจัยในโลกนี้ก็พยายามหาช่องทางใหม่อยู่ตลอดเวลา แค่ปรับปรุงได้ 10% - 20% ก็ดังแล้ว
ในยุคที่ยากจะ Optimize กว่าเดิมแล้ว .. จะขยับมาเป็นการทำ Trade off แทน เพื่อแลกส่วนที่ไม่ค่อยได้ใช้มาเพิ่มส่วนที่ใช้งานหลักแทน
ลด "page load time" ครับ ไม่ใช่ raw TCP speed
ปัจจุบัน HTTP/1.1 มันยังมี overhead เยอะ SPDY นี่ออกแบบมาเพื่อแก้ปัญหาพวกนี้และใช้ TCP ให้มีประสิทธิภาพมากกว่าเดิมครับ
pittaya.com
protocol http มีแต่ขยะเต็มไปหมดครับ
spdy พยายามตัดขยะทิ้่ง มันเลยเร็วขึ้น
ก็แค่นั้น
หลายปีก่อน ผมเคยพยายามลดขนาดไฟล์ โดยการบีบอัด html code ให้เยอะที่สุดเท่าที่จะได้ .. น่าจะสัก 10% (ตอนนี้ใช้ gzip compression ไม่เป็น แต่เชื่อว่ามันต้องมี delay จากการถอดด้วย browser ด้วย)
แต่สุดท้ายมาพบว่า Tune Database, ทำ caching ให้ผลเป็นเท่าๆ เยอะกว่ามาก
แต่โอเคนะ จะตัดขยะสัก 100ตัวอักษรของ header ต่อ request (ไม่ใช่ต่อ frame) ถ้ามองระดับประเทศคงได้เยอะอยู่ ส่วนจะเห็นผลเป็น page load time นั้น ผมยังอยากรู้เหมือนกัน
ถ้าเว็บมีแค่ html + css + js อย่างละไฟล์ มันก็ไม่เห็นผลหรอกครับ
แต่อย่าลืมว่าเว็บใหญ่ๆอย่าง facebook นี่ มี static file เป็นร้อยครับ
ป.ล. spdy เปิด gzip ข้างในมาเป็น default
แหม คุณ lancaster ตอบได้เข้าที .. ว่างๆ ทิ้ง contact (fb ก็ได้) จะขอคำแนะนำบ้างได้มั๊ยครับ
แต่ถ้าทำแบบ Chrome browser ผมไม่เอานะเล่นเปิด connection สูบข้อมูลจนเครื่อง notebook ผมค้างไปพักหนึ่งเลย เป็นเอาบ่อยจนต้องกลับมาใช้ Firefox อีกครั้ง ซึ่ง FF ตัวใหม่ไม่มีปัญหาเลยแจ่มมาก
chrome นี่ผมว่าปัญหาหลักน่าจะเป็นเรื่อง preload ครับ
ผมเองก็ปิดทิ้งไปเหมือนกันไม่งั้นเปลือง data มาก (tether ผ่านมือถือ)
+1 chrome ใช้ preload ครับ เอาจริงๆ firefox ก็ใช้ preload นะครับแต่ไม่ได้ใช้เยอะ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
SPDY เป็นการเพิ่มความเร็วของการโหลดเพจโดยการ mux, รวมถึง compress ข้อมูลเป็นอันเดียวครับ
วิธีนี้นอกจากจะลด header ที่จะต้องโหลดได้แล้วยังทำให้ข้อมูลไหลลื่นขึ้นมาก เนื่องจากข้อมูลไม่ต้องรอให้คิว concurrent connection ว่าง(และ latency/ping ที่มากับการร้องขอข้อมูลแต่ละครั้ง)
ในอดีต(รวมถึงปัจจุบัน) software ที่เรียกตัวเองว่าตัว tuneup/optimize ต่างๆมักจะเพิ่มความเร็วในการเรียกโหลดเพจโดยการเพิ่มจำนวน concurrent connection ขึ้น แต่วิธีนี้มีข้อเสียหลายอย่างคือ ไม่ได้ลดขนาด header ที่ต้องเรียก/ไม่ได้มีการบีบอัดข้อมูล/ไม่มีการจัดลำดับดับความสำคัญของข้อมูล/การเพิ่ม concurrent c มากเกินไปอาจทำให้ข้อมูลโหลดมาไม่สมบูรณ์ได้ครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
แหม ยกฉายาให้เป็น Macgyver เลยดีมั๊ย
เมื่อ 3 ปีที่แล้ว ผมได้ยินอาจารย์ network ที่จุฬา ซึ่งท่านจบจากมหาลัยชื่อดังในอเมริกา อ. บอกว่ายังไม่สามารถสรุปได้ชัดเจนในระดับภาพรวมการใช้งาน ว่า HTTP 1.1 ที่ลด hand shake ทำ pipeline contents นั้นจะดีกว่า parallel connections ครับ
คือข้อเสียผมก็ยังไม่รู้เหมือนกันว่าเยอะหรือไม่ เพราะยังใช้ไม่แพร่หลาย แต่จากการทดลองและใช้จริง(โดย Google) มันก็ได้ผลดีขึ้นนะครับ (คืออย่างน้อยก็ดีกว่าการหาจุดสมดุลระหว่างจำนวน concurrent connection กับความเร็วเน็ตแต่ละคน+ขนาดและจำนวนของข้อมูล ซึ่งส่วนตัวผมคิดว่ามันไม่เป็น practical เท่าไหร่ อันนี้อาจจะผิดก็ได้ ความเห็นส่วนตัวล้วนๆครับ)
ส่วน cc นั้นถ้าจะทำในปัจจุบันผมว่าต้องระดับ 20+ ขึ้นไป เพราะแต่ละเว็บใช้รูป profile เยอะมาก แถมแยก .js .css แยกนู่นแยกนี่อีก
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ผมว่าที่ http/1.1 มันไม่ได้เร็วขึ้นมาก เพราะมันทำแค่ pipeline เฉยๆน่ะครับ ซึ่งมันก็ลดไปได้แค่ตอน tcp handshake อย่างเดียว อย่างอื่นยังต้องวิ่งเท่าเดิมอยู่อะครับ
ซึ่งถ้าวาดเป็น timeline ก็คงจะเห็นว่าทำ parallel ต่อให้มี handshake ก็ยังมีภาษีดีกว่ามาก (อีกทั้งยังมี keep-alive คอยช่วยอีกด้วยแล้ว)
ดังนั้นเมื่อทำอะไรไม่ได้มาก .. จึงมีคนพยายามสร้างของใหม่โดยจะไปปรับไอเจ้า tcp slow-start reduce-half เพื่อให้ไปควบคุมเร่งปริมาณการส่งข้อมูลต่อ connection แทน แทนการอาศัยหลาย connections ในปัจจุบัน (ซึ่งหลาย connection นั้นก็ได้ประโยชน์ในการเป็น dynamic bandwidth ด้วยในตัวแล้ว)
ในจุดของ tcp slow-start reduce-half ตรงนี้เป็นข้อดีมากเพราะใช้แก้ปัญหาวิกฤต traffic ชนกันครั้งยิ่งใหญ่ในประวัติศาสตร์ .. ซึ่งผมเข้าใจว่า UDP ยังไม่มี จึงไม่มีใครกล้าลงมาเล่น HTTP over UDP !
LinkedIn
แก้แล้วครับ ขอบคุณครับ
pittaya.com
badge in love นี่เพิ่งเคยเห็ฯแฮะ
onedd.net
เสียใจ ;w ;
Google SPDY ไม่ยักจะมี logo จริงจังแฮ่ะ