Tags:
Node Thumbnail

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

Comments

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 19 June 2012 - 09:44 #434038
Invisible Force's picture

"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 แทน เพื่อแลกส่วนที่ไม่ค่อยได้ใช้มาเพิ่มส่วนที่ใช้งานหลักแทน

By: pittaya
WriterAndroidUbuntuIn Love
on 19 June 2012 - 10:43 #434080 Reply to:434038
pittaya's picture

ลด "page load time" ครับ ไม่ใช่ raw TCP speed

ปัจจุบัน HTTP/1.1 มันยังมี overhead เยอะ SPDY นี่ออกแบบมาเพื่อแก้ปัญหาพวกนี้และใช้ TCP ให้มีประสิทธิภาพมากกว่าเดิมครับ


pittaya.com

By: lancaster
ContributorUbuntuWindows
on 19 June 2012 - 18:34 #434329 Reply to:434038

protocol http มีแต่ขยะเต็มไปหมดครับ

spdy พยายามตัดขยะทิ้่ง มันเลยเร็วขึ้น

ก็แค่นั้น

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 19 June 2012 - 19:11 #434351 Reply to:434329
Invisible Force's picture

หลายปีก่อน ผมเคยพยายามลดขนาดไฟล์ โดยการบีบอัด html code ให้เยอะที่สุดเท่าที่จะได้ .. น่าจะสัก 10% (ตอนนี้ใช้ gzip compression ไม่เป็น แต่เชื่อว่ามันต้องมี delay จากการถอดด้วย browser ด้วย)

แต่สุดท้ายมาพบว่า Tune Database, ทำ caching ให้ผลเป็นเท่าๆ เยอะกว่ามาก

แต่โอเคนะ จะตัดขยะสัก 100ตัวอักษรของ header ต่อ request (ไม่ใช่ต่อ frame) ถ้ามองระดับประเทศคงได้เยอะอยู่ ส่วนจะเห็นผลเป็น page load time นั้น ผมยังอยากรู้เหมือนกัน

By: lancaster
ContributorUbuntuWindows
on 19 June 2012 - 19:14 #434355 Reply to:434351

ถ้าเว็บมีแค่ html + css + js อย่างละไฟล์ มันก็ไม่เห็นผลหรอกครับ

แต่อย่าลืมว่าเว็บใหญ่ๆอย่าง facebook นี่ มี static file เป็นร้อยครับ

ป.ล. spdy เปิด gzip ข้างในมาเป็น default

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 19 June 2012 - 19:17 #434358 Reply to:434355
Invisible Force's picture

แหม คุณ lancaster ตอบได้เข้าที .. ว่างๆ ทิ้ง contact (fb ก็ได้) จะขอคำแนะนำบ้างได้มั๊ยครับ

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 19 June 2012 - 19:21 #434360 Reply to:434355
Invisible Force's picture

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

By: lancaster
ContributorUbuntuWindows
on 19 June 2012 - 19:22 #434361 Reply to:434360

chrome นี่ผมว่าปัญหาหลักน่าจะเป็นเรื่อง preload ครับ

ผมเองก็ปิดทิ้งไปเหมือนกันไม่งั้นเปลือง data มาก (tether ผ่านมือถือ)

By: McKay
ContributorAndroidWindowsIn Love
on 19 June 2012 - 19:42 #434372 Reply to:434361
McKay's picture

+1 chrome ใช้ preload ครับ เอาจริงๆ firefox ก็ใช้ preload นะครับแต่ไม่ได้ใช้เยอะ


In Soviet Warcraft, Argus comes to you.

By: McKay
ContributorAndroidWindowsIn Love
on 19 June 2012 - 19:44 #434371 Reply to:434351
McKay's picture

SPDY เป็นการเพิ่มความเร็วของการโหลดเพจโดยการ mux, รวมถึง compress ข้อมูลเป็นอันเดียวครับ

วิธีนี้นอกจากจะลด header ที่จะต้องโหลดได้แล้วยังทำให้ข้อมูลไหลลื่นขึ้นมาก เนื่องจากข้อมูลไม่ต้องรอให้คิว concurrent connection ว่าง(และ latency/ping ที่มากับการร้องขอข้อมูลแต่ละครั้ง)

ในอดีต(รวมถึงปัจจุบัน) software ที่เรียกตัวเองว่าตัว tuneup/optimize ต่างๆมักจะเพิ่มความเร็วในการเรียกโหลดเพจโดยการเพิ่มจำนวน concurrent connection ขึ้น แต่วิธีนี้มีข้อเสียหลายอย่างคือ ไม่ได้ลดขนาด header ที่ต้องเรียก/ไม่ได้มีการบีบอัดข้อมูล/ไม่มีการจัดลำดับดับความสำคัญของข้อมูล/การเพิ่ม concurrent c มากเกินไปอาจทำให้ข้อมูลโหลดมาไม่สมบูรณ์ได้ครับ


In Soviet Warcraft, Argus comes to you.

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 19 June 2012 - 19:49 #434373 Reply to:434371
Invisible Force's picture

แหม ยกฉายาให้เป็น Macgyver เลยดีมั๊ย

เมื่อ 3 ปีที่แล้ว ผมได้ยินอาจารย์ network ที่จุฬา ซึ่งท่านจบจากมหาลัยชื่อดังในอเมริกา อ. บอกว่ายังไม่สามารถสรุปได้ชัดเจนในระดับภาพรวมการใช้งาน ว่า HTTP 1.1 ที่ลด hand shake ทำ pipeline contents นั้นจะดีกว่า parallel connections ครับ

By: McKay
ContributorAndroidWindowsIn Love
on 19 June 2012 - 20:02 #434376 Reply to:434373
McKay's picture

คือข้อเสียผมก็ยังไม่รู้เหมือนกันว่าเยอะหรือไม่ เพราะยังใช้ไม่แพร่หลาย แต่จากการทดลองและใช้จริง(โดย Google) มันก็ได้ผลดีขึ้นนะครับ (คืออย่างน้อยก็ดีกว่าการหาจุดสมดุลระหว่างจำนวน concurrent connection กับความเร็วเน็ตแต่ละคน+ขนาดและจำนวนของข้อมูล ซึ่งส่วนตัวผมคิดว่ามันไม่เป็น practical เท่าไหร่ อันนี้อาจจะผิดก็ได้ ความเห็นส่วนตัวล้วนๆครับ)

ส่วน cc นั้นถ้าจะทำในปัจจุบันผมว่าต้องระดับ 20+ ขึ้นไป เพราะแต่ละเว็บใช้รูป profile เยอะมาก แถมแยก .js .css แยกนู่นแยกนี่อีก


In Soviet Warcraft, Argus comes to you.

By: lancaster
ContributorUbuntuWindows
on 19 June 2012 - 23:53 #434482 Reply to:434373

ผมว่าที่ http/1.1 มันไม่ได้เร็วขึ้นมาก เพราะมันทำแค่ pipeline เฉยๆน่ะครับ ซึ่งมันก็ลดไปได้แค่ตอน tcp handshake อย่างเดียว อย่างอื่นยังต้องวิ่งเท่าเดิมอยู่อะครับ

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 20 June 2012 - 09:50 #434591 Reply to:434482
Invisible Force's picture

ซึ่งถ้าวาดเป็น 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 !

By: PaePae
WriteriPhoneAndroidWindows
on 19 June 2012 - 12:50 #434179
PaePae's picture
  • บราวเซอร์ => เบราว์เซอร์

LinkedIn

By: pittaya
WriterAndroidUbuntuIn Love
on 19 June 2012 - 18:50 #434343 Reply to:434179
pittaya's picture

แก้แล้วครับ ขอบคุณครับ


pittaya.com

By: wiennat
Writer
on 19 June 2012 - 14:12 #434216

badge in love นี่เพิ่งเคยเห็ฯแฮะ


onedd.net

By: neizod
ContributorTraineeIn Love
on 19 June 2012 - 18:19 #434320 Reply to:434216
neizod's picture

เสียใจ ;w ;

By: Invisible Force
ContributoriPhoneAndroidUbuntu
on 19 June 2012 - 19:14 #434356
Invisible Force's picture

Google SPDY ไม่ยักจะมี logo จริงจังแฮ่ะ