ในขณะนี้เป็นช่วงที่มีการแปลี่ยนแปลงอะไรหลายๆ อย่างเกี่ยวกับ Internet ซึ่งอาจส่งผลกับเราไปอีกเป็นร้อยปี เรื่องเด่นๆ ได้แก่

• New gTLDs ที่ทำให้เราไม่ได้มีแต่ domain .com, .net, .org และ .info ให้เลือกใช้อีกต่อไป แต่จะมี domain .อื่นๆ โผล่ออกมาอีกมากมาย เราอาจจะได้เห็น blognone.com เปลี่ยนชื่อเป็น blogn.one อาจจะได้เห็นศูนย์หนังสือจุฬาใช้ชื่อเว็บ chula.book และมีความเป็นไปได้ ของชื่อ creative อื่นๆ ที่ creative จนเราคาดไม่ถึง
• IPv6 ที่อาจทำให้อุปกรณ์ทุกๆ อันบนโลกนี้ สามารถมี Public IP Address เป็นของตัวเองได้ และลดปริมาณการใช้งาน NAT device และลดความจำเป็นในการทำ Port Forwarding ลง
• การใช้งาน DNSSEC ที่ทำให้ domain name มีความปลอดภัยมากขึ้น
• และสุดท้ายคือ HTTP 2.0 ที่เป็นประเด็นหลัก ที่เราจะมาทำความเข้าใจกันไปพร้อมๆ กันในวันนี้

เรื่องที่ผมกำลังจะเขียนนี้ มีความสำคัญกับคุณผู้อ่านมาก แต่ก่อนที่เราจะไปดูในรายละเอียดกัน ขอผมพูดรวมๆ เกี่ยวกับ HTTP 2.0 สักหน่อย ถ้าอยากเข้าประเด็นเลย สามารอ่านข้ามจากตรงนี้ไปที่หัวข้อที่เป็นตัวหนาถัดไปได้เลยนะครับ

ที่ผมเลือก HTTP 2.0 มาเป็นประเด็น มีหลายเหตุผล แต่ข้อแตกต่างหลักของประเด็นนี้เทียบกับการเปลี่ยนแปลงในเรื่องอื่นๆ แล้ว คือ HTTP 2.0 ยังไม่มีความแน่นอนครับ กล่าวคือ New gTLDs มาแน่ๆ และมี list ค่อนข้างตายตัวแล้ว, IPv6 ต้องถูกงัดออกมาใช้แน่ๆ เพราะ IPv4 หมดไปแล้ว และการนำมาใช้นี้ผมค่อนข้างแน่ใจว่า เราจะได้ใช้ IPv6 ในรูปแบบ protocol 6rd เพราะมันเป็นมาตรฐานเดียวที่ทำให้ ผู้ให้บริการ Internet หรือ ISP สามารถบริการ IPv6 บน hardware ของ IPv4 ที่มีอยู่เดิมได้ โดยไม่มีปัญหาเพิ่มเติมมากมายนัก และบริษัททำ router ก็เพียงแก้ไข software นิดหน่อย ก็สามารถทำงานกับ 6rd ได้ (แต่เราเอามาใช้เองไม่ได้นะครับ ต้องให้ ISP ดำเนินการให้), DNSSEC เริ่มใช้งานแล้ว แค่ต้องการความแพร่หลาย, แต่ HTTP 2.0 นี้ มีตัวเต็ง 2 ตัวที่ทำให้ เสียงตอบรับ แตกออกเป็นสองกลุ่มใหญ่ คือ
Google's SPDY และ Microsoft S+M (Microsoft Speed + Mobility) ครับ
อันที่จริงแล้วมีของเจ้าอื่นที่เสนอมาด้วย แต่เรื่องที่น่าสนใจและมีผลกับเรามาก ปรากฏให้เห็นเด่นชัดใน protocol ทั้งสองนี้ครับ

ถ้าว่ากันตรงๆ แล้วก็คือ ผมจะมาเขียนเชียร์ SPDY ของ Google ครับ แม้ผมจะไม่ค่อยชอบเจ้าองค์กรยักษ์ใหญ่นี้นัก ในแง่ของการผูกขาดตลาด แต่ผมก็ชอบในเรื่องของวิสัยทัศน์ที่กว้างไกล (ทำนองเดียวกับที่ผมไม่ชอบบริษัทด้านการสื่อสารและรูปแบบการทำธุรกิจผูกขาดบางธุรกิจของCP แต่ผมก็ชอบไส้กรอกของเขา อาหารอีกหลายๆ อย่าง และเรื่องอื่นๆ อีกหลายเรื่องที่เขาทำครับ) ดังนั้นผมบอกได้เลยว่าเนื้อหาต่อจากนี้ ผมจะ bias ให้คุณเห็นด้วยกับ SPDY ของ Google ผมจะวิเคราะห์ให้คุณได้เห็นแนวคิดเบื้องหลังของ protocol ดังกล่าว และที่สำคัญคือ ผมจะไม่อธิบายข้ามขั้นครับ ดังนั้นคุณแน่ใจได้เลยว่าถึงแม้คุณจะแค่เล่น Internet เป็น แบบธรรมดาๆ คุณก็จะอ่านมันเข้าใจครับ

และถ้าคุณเคยได้อ่าน ข่าวเก่าของผม ที่ว่าด้วยเรื่อง ปัญหาของ ISP; ข่าวใหม่นี้จะเป็นทิศทางของอีกสิ่งหนึ่ง ที่ช่วยบรรเทาปัญหานั้นครับ (ปัญหาของ Internet ไม่ได้หมดแค่นี้นะครับมันยังเหลืออยู่อีกมาก)

ถ้าเตรียมใจพร้อมแล้ว ก็ไปดูรายละเอียดกันได้เลย

Google's SPDY กับ Microsoft S+M มันคืออะไร? แตกต่างกันยังไง?

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

ถ้าคุณเล่น Internet มาได้สักระยะแล้ว HTTP อาจไม่ใช่ตัวอักษรแปลกใหม่สำหรับคุณเลย มันอยู่ใน address bar ของ browser ที่คุณใช้นั่นเอง บ่อยครั้งที่คุณจะเห็น address bar ขึ้นต้นด้วย http:// นั่นเป็นการบอกให้ browser คุยกับ web server ด้วย HTTP (มันก็คล้ายๆ ภาษาอยู่นะครับ แต่ว่ามันคล้ายกับข้อตกลงการสื่อสารมากกว่าที่จะเป็นภาษา) ตอนนี้ผมอยากให้คุณลองเข้าไปที่เว็บนี้ครับ
http://ifconfig.me/port
ถ้าไม่มีปัญหาอะไรคุณจะเห็นตัวเลขมั่วๆ ขึ้นมาชุดหนึ่ง (สมมุติว่าเป็นเลข 12345) คำถามที่น่าสนใจคือ browser ที่เราใช้งานอยู่ คุยอะไรกับ server ifconfig.me บ้าง ใช่แบบนี้หรือเปล่าครับ คือคอมพิวเตอร์ของคุณ เงียบ ไม่บอกอะไร ifconfig.me เลย อยู่ดีๆ มันก็ส่ง 12345 มาให้คุณ?
นั่นเป็นไปไม่ได้แน่ๆ เรามาดูบทสนทนาของมันกันครับ

browser พูดว่า:

GET /port HTTP/1.1
Host: ifconfig.me
Connection: Close
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)

 

web server ตอบว่า:

HTTP/1.1 200 OK
Date: Xxx, 32 Jul 2013 01:02:03 GMT
Server: Apache
Content-Length: 5
Content-Type: text/plain
X-Cnection: close

12345

ซึ่งคุณจะเห็นได้ว่า ไม่ได้มีเพียงข้อมูล 12345 ที่เป็นข้อมูลที่คุณต้องการถูกส่งมาเท่านั้น แต่ คอมพิวเตอร์ของคุณกับ ifconfig.me ยังคุยอะไรกันอีกหลายอย่าง ทุกๆ บรรทัดที่มันคุยกันมีความหมาย ยกตัวอย่างเช่น
คุณเคยสงสัยหรือเปล่าว่า browser มันรู้ได้ไงว่า file ไหนต้อง download; file ไหนต้องเปิดดูใน browser เลย? browser มันตัดสินใจจาก file extension หรือเปล่า? เช่นถ้าไฟล์ไหนมีชื่อลงท้ายด้วย .zip ก็ให้ download ไฟล์ไหนชื่อลงท้ายด้วย .html ก็ให้เปิดดูใน browser เลย; ไฟล์ไหนเป็น .txt ก็แสดงเป็นข้อมูลธรรมดาไม่ใช่หน้าเว็บ อย่างนี้หรือเปล่า? ถ้ามันเป็นแบบนั้นจริง แสดงว่าไฟล์ที่ลงท้ายด้วย .html จะต้องเป็นหน้าเว็บเท่านั้น?
แต่ว่ามันไม่ใช่แบบนั้นน่ะสิครับ ผมเชื่อว่าถ้าคุณเล่น Internet มาพักใหญ่ คงเคยเห็น อะไรแบบนี้มาไม่น้อย
https://raw.github.com/ned14/nedmalloc/master/Readme.html
ไฟล์นี้มี extension เป็น .html แต่พอเปิดเข้าไปดูกลับเป็นตัวหนังสือธรรมดา หรือว่าเวลาเข้าเว็บ download จำพวก rapidshare บางครั้งก็เห็นหน้าที่มี extension เป็น .zip ด้วย

แสดงว่า browser ไม่ได้แยกแยะชนิดของ file ด้วย extension ของ file นะครับ มันรู้จากตรงนี้ครับ (ย้อนไปดูข้างบน)
Content-Type: text/plain
อันนี้ หมายความว่า file ที่ web server ส่งมามีลักษณะเป็น ข้อมูล text ธรรมดา ไม่ใช่หน้าเว็บครับ ถ้ามีไฟล์ .zip ที่ web server บอกว่าเป็น text/plain เหมือนกัน มันก็มักจะถูกแสดงผลออกมาแบบเดียวกันนี้นะครับ

ที่ผ่านมาเป็นการยกตัวอย่างให้คุณได้เห็นถึง หน้าที่และความจำเป็นรวมถึงหน้าตา ของ HTTP ที่เราใช้กันอย่างแพร่หลายในปัจจุบันนะครับ ทีนี้ มันเกี่ยวกับพวก SPDY กับ S+M ยังไง?

ก่อนที่เราจะไปดูว่า Google คิด SPDY ขึ้นมาทำไม เราย้อนไปดูอดีตของ HTTP 1 สักหน่อย ว่าเขามีแนวคิดยังไง?
ถ้าจะให้เห็นภาพคุณอาจลองนึกถึง มนุษย์โครมันยอง (Cro-Magnon) นั่งประชุมกัน วาระประชุมนี้ว่ากันด้วยเรื่องมีมนุษย์คนหนึ่งไปเก็บหินออบซิเดียน (Obsidian) ที่มีลักษณะคล้ายแก้วได้ หินนี้มีความคมถ้าถือไม่ดีมันจะบาดมือได้ ประเด็นของวันนี้คือพวกเราจะเอาหินออบซิเดียนมาใช้กันยังไงดี มีมนุษย์คนหนึ่งเสนอว่า "เอ้ยเพื่อนอย่างนี้เราเอามาผูกไว้ที่ปลายไม้ยาวๆ แล้วเอาไปขว้างเป็นอาวุธดีมั้ย เราอาจจะเรียกมันว่าหอกก็ได้นะ" มีมนุษย์อีกคนหนึ่งบอกว่า "ถ้าอย่างนั้น เราน่าจะเอามาใช้กับสิ่งที่เรียกว่าคันธนู มันน่าจะแม่นยำกว่าขว้างนะ เราอาจเรียกมันรวมกันว่าเกาทัณฑ์" มีอีกคนหนึ่งบอกว่า "ถ้าอย่างนั้นเกรงว่าจะช้าไป กลัวจะเกาไม่ทัน เราน่าจะเอาไปทำอะไรที่มีหน้าตาคล้ายๆ ปืน เราอาจจะเรียกมันว่าหน้าไม้ก็ได้" การประชุมดำเนินต่อไปเช่นนี้เรื่อยๆ ในที่สุดแล้วมนุษย์โครมันยองกลุ่มนี้ก็ได้ไอเดียอะไรที่เจ๋งมากๆ ออกมา เขาสามารถใช้หินออบซิเดียนให้มีประโยชน์มากๆ แต่พวกเขามองข้ามปัญหาไปหลายปัญหา; หลายๆ ปัญหาเกิดจากตัวหินออบซิเดียนเองไม่ใช่ปัญหาเนื่องจากความคิดของพวกเขา ตอนคิดกันเขาคิดแต่ว่ามันคม ไม่ได้คิดถึงเรื่องความเปราะ แต่นั่นก็ไม่เป็นปัญหาใหญ่ ตัวหินและสิ่งประดิษฐ์นั้นยังใช้งานได้ดีเรื่อยมา เพียงแต่มันใช้ได้ไม่ดีในบางสถานการณ์ก็เท่านั้น

เหตุการณ์คล้ายๆ กันนี้เกิดขึ้นกับ HTTP 1 เขาเอา TCP มาตั้งไว้บนโต๊ะ ประชุมกันว่าจะเอา TCP ไปใช้ยังไง และมันก็ใช้งานได้เสมอมา แม้จะเจอปัญหาที่เกิดขึ้นเพราะตัว TCP เองรวมถึงความต้องการในการใช้งานในรูปแบบใหม่ๆ แต่จนปัจจุบันนี้ก็ยังไม่มีเหตุผลที่ดีพอที่เราจะเลิกใช้งานมันเลยครับ

จนวันหนึ่งใครคนหนึ่งใน Google จับปัญหาของ HTTP ที่เราใช้กันอยู่มา list รวมกัน รวมถึงคิด features ใหม่ๆ ใส่รวมไปใน list ด้วย พัฒนา protocol ออกมาใช้จริง กับ website ของ Google และ Browser Google Chrome รวมถึงเสนอให้ protocol นี้เป็น version ถัดไปของ HTTP (ยังไม่ถูกกำหนดเป็นมาตรฐานอย่างเป็นทางการแต่เริ่มใช้งานเรียบร้อยแล้ว) ตั้งชื่อมันว่า SPDY มันก็เหมือนกับเป็นตัว upgrade ของ HTTP นั่นเอง

ผมคิดว่าหัวข้อนั้ชักจะยาวเกินไปแล้ว แต่ประเด็นยังไม่หมด ต่อไปเรามาดูว่า

Microsoft S+M มันเจ๋งกว่า SPDY ยังไง?

ใช่แล้วครับคุณอ่านไม่ผิด ผมกำลังมาเชียร์ SPDY แต่กำลังจะเขียนว่า S+M เจ๋งกว่า SPDY ยังไง เรื่องเล่าต่อจากการกระทำของ Google คือ SPDY ดังเป็นพลุแตก มีคนอีกมากมายเสนอ draft HTTP 2.0 โดยยึด protocol ของ Google เป็นหลัก หนึ่งในนั้นเป็นบริษัทยักษ์ใหญ่ที่เราคุ้นชื่อกันดี Microsoft ครับ

SPDY ปรับปรุง HTTP ไปมากมายหลายส่วน เรื่องราวส่วนใหญ่เป็นเรื่องที่คนในวงการ Internet ต้องสนใจ แต่ถ้าคุณผู้อ่านแค่ใช้ Internet ก็ไม่ต้องกังวลมากครับ คุณก็ใช้งาน website ต่างๆ อย่างที่คุณเคยใช้นั่นแหละครับ แต่มีอยู่ feature หนึ่งที่สำคัญมากๆ และส่งผลโดยตรงกับคุณ ซึ่งผมคิดจะยกมาอธิบายเจาะจงเฉพาะ feature นี้ครับ

Google บอกว่า เว็บใดก็ตามที่จะใช้ SPDY จะต้องเป็น web ที่ทำงานบน HTTPS เท่านั้น ไม่มีมาตรฐาน SPDY ที่ใช้กับ HTTP ธรรมดา (HTTPS เป็นระบบรักษาความปลอดภัยที่ใช้ใน website ที่ต้องส้งข้อมูลสำคัญเช่นธนาคารครับ มันช่วยให้การรับส่งข้อมูลของต้นทางและปลายทางไม่สามารถถูกแอบอ่านหรือดัดแปลงแก้ไขได้ ถ้าอยากเข้าใจมากกว่านี้ผมแนะนำให้ลองอ่านดูว่า Internet มีหลักการทำงานยังไง ในข่าวเก่าที่ผมเขียนครับ)

นั่นคือ ในปัจจุบันนี้ website จะใช้ HTTP หรือ HTTPS มันเป็น options ล้วนๆ website ไหน ข้อมูลไม่สำคัญ เป็นแค่หน้าเว็บแสดงข้อมูล ก็ใช้ HTTP ไป หน้าเว็บไหนสำคัญๆ อย่าง Paypal ก็ใช้ HTTPS ได้ไม่มีปัญหา แต่ถ้า SPDY ถูกเลือกเป็น HTTP 2.0 เว็บไหนจะใช้ก็ต้องเป็นเว็บที่มีความปลอดภัยสูงเท่านั้น เรื่องเว็บที่ไม่ปลอดภัย ควรจะเป็นนิทานก่อนนอนที่ไปเล่าให้หลานฟังตอนเป็นคุณปู่ ไม่ควรจะใช้กันต่อไปเรื่อยๆ อีกต่อไป

Microsoft บอกว่า ทำงั้นไม่ได้นะ คนบางคนใช้โทรศัพท์มือถือในการเข้าถึง Internet ต้องเสียพลังประมวลผลให้กับการเข้ารหัส การเข้ารหัสจะเพิ่ม Load ให้กับ Device ต่างๆ รวมถึง Infrastructure ที่ใช้อยู่ในปัจจุบันด้วยซึ่งมันไม่ใช่เรื่องจำเป็นเลย ทำไมเราไม่ทำให้มันเป็น option เหมือนเดิม อะไรที่ต้องปลอดภัยก็ปลอดภัยไป อะไรที่ไม่จำเป็นต้องปลอดภัยก็ไม่เห็นต้องไปบังคับเลยนี่ Microsoft ก็เอาเจ้า SPDY มาแก้ไข เป็น Microsoft S+M เรียกใจของใครหลายคนไปได้มากทีเดียว (รวมถึงผมด้วย)

ใครฟังเหตุผลของ Microsoft ก็ต้องเห็นด้วยทั้งนั้นแหละครับ บริษัทนี้ไม่ค่อยทำอะไรเป็นที่ถูกใจผมนัก แต่นี่เป็นอีกมาตรฐานจาก Microsoft ที่ได้ใจไปเลย (อีกอันเป็น XPS) Microsoft เสนอมาตรฐานที่เกือบทุกฝ่าย happy ทุกๆ อย่างสามารถทำงานบนมาตรฐานนี้ได้

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

security สำคัญแค่ไหน?

หลายครั้งที่ผมแนะนำให้ผู้ใช้ Android ใช้ browser จำพวก Opera Mobile Classic แทนการใช้งาน browser ของ Android ด้วยเหตุผลด้าน security และการแสดงผล หลายครั้งที่ผมได้คำตอบประมาณว่า browser ของ Android มันเร็วกว่า และไม่ได้ใช้เข้าเว็บสำคัญอะไร หรือก็คือมีผู้ใช้จำนวนมาก ที่ต้องการอะไรบางอย่างที่ใช้ได้ แต่ไม่สนกลไกเบื้องหลังของมัน

ถ้าคุณเป็นหนึ่งในนั้น คุณรู้หรือเปล่าว่าผม (และคนอีกหลายๆ คน) ทำอะไรได้มั่ง คุณอาจจะไปนั่งเล่น true wifi ในร้านกาแฟ login เข้า blognone ตามปกติ สมมุติว่าผมไม่ชอบขี้หน้าคุณนึกสนุกนั่งดัก password อยู่หน้าร้านกาแฟ (ผมไม่จำเป็นต้องใช้ true wifi ก็ดักได้) และถ้าคุณเป็นพวกชอบใช้ password ซ้ำๆ กันด้วยแล้ว วันถัดมาคุณอาจพบว่า ข้อมูลใน email ของคุณหายเกลี้ยงไปเลยก็ได้

เรื่องพวกนี้มีวิธีพลิกแพลงใช้งานอีกมากมายนะครับ ถ้าจะใช้ทำเรื่องที่ไม่ค่อยดีมันมีวิธีอื่นอีกเป็นร้อยๆ อันนี้แค่ยกตัวอย่างการใช้งานแบบตรงไปตรงมามาแค่วิธีเดียวเท่านั้นครับ

ที่สำคัญคือ มันไม่ใช่ปัญหาที่ไม่มีทางแก้ แต่มันเป็นปัญหาที่จะไม่ถูกแก้ เพราะเป็นการแก้ปัญหาไม่ตรงกับตลาดครับ มีมาตรฐาน WPA2 Enterprise ให้ใช้งานกับ public hotspot แต่มีค่าใช้จ่ายเพิ่มขึ้น ถ้า true ใช้การเข้ารหัสแบบนั้น เขาจะเก็บเงินคุณเดือนละ 99 บาทไม่ได้แล้วนะครับ ราคามันจะขึ้นไปอีก เพื่อแลกกับ security ที่เผอิญว่าคนส่วนใหญ่ไม่ต้องการ (แต่ต้องการราคาถูก) และคนที่รู้เรื่อง security ก็มีวิธีจัดการของตัวเองต่างๆ นาๆ ขึ้นกับสถานการณ์

และถึงแม้จะใช้ ระบบ WPA2 Enterprise แล้วก็ตาม นั่นช่วยเพิ่มความปลอดภัยระหว่างคอมพิวเตอร์ของคุณกับ access point เท่านั้น ยังมี weaklink ส่วนอื่นๆ อีกมากมาย ดังที่เคยมีหลักฐานที่ตรวจสอบได้โผล่ขึ้นมาว่า ISP ประเทศไทยมีการดัดแปลงแก้ไขข้อมูลของ website ซ้ำร้ายยังมีข้อมูลมาว่า การแก้ไขข้อมูล website ส่วนหนึ่งเป็นคำสั่งศาล (และบางส่วนเป็นเหตุผลทางการเมือง) ด้วย

ทั้งเรื่อง แค่นั่งใกล้ๆ ก็ได้ password กับเรื่องผู้มีอำนาจสั่งบิดเบือนข้อมูล เป็นเรื่องที่ผมยืนยันได้ว่าทำได้ และเป็นแบบนั้นจริงๆ และแม้ผมจะไม่มีหลักฐาน แต่ผมก็เชื่อว่ามีการดักจับข้อมูลส่วนตัวของคุณผู้อ่านด้วย (ซึ่งผมคาดว่าบุคคลใดก็ตามที่ทำอยู่ จะให้เหตุผลว่า ถ้าคุณไม่ได้ทำอะไรผิดกฎหมายก็ไม่มีข้อมูลอะไรต้องปกปิด นะครับ แต่ผมชอบเหตุผลของคุณคิมดอทคอมมากกว่า เขาบอกว่า ถ้าคุณไม่ได้ทำอะไรผิดกฎหมายทำไมจะต้องถูกแอบดูข้อมูลส่วนตัวด้วย)

ปัญหาทั้งหมดนี้จะไม่เกิดขึ้นกับ website ที่ใช้ HTTPS นะครับ หรืออย่างน้อยที่สุดถ้าปัญหามันจะเกิดขึ้น ก็จะมีสัญญาณเตือนมาบอกคุณครับ

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

ถ้า HTTPS มันดีอย่างที่ผมว่าจริง ทำไมคนถึงใช้ HTTP มากกว่า HTTPS?

คำถามนี้ใครก็สงสัยได้ แม้แต่ blognone ก็ยังไม่ใช้ HTTPS เลยใช่มั้ยครับ ปัญหาคือต้นทุนที่สูงขึ้นครับ เรามาดูต้นทุนการใช้งาน HTTPS ในอดีตกันดีกว่า การจะใช้ HTTPS กับ website นั้นมีต้นทุนหลักเลยคือ
- ค่า sign digital certificate อธิบายง่ายๆ คือเป็นค่าดำเนินการของบริษัทรับรองความน่าเชื่อถือครับ
- ค่า dedicated IP Address อันนี้ซับซ้อนไว้ค่อยอธิบายนะครับ
- ค่า web server ที่ต้องใช้ computer spec สูงขึ้นเพื่อรองรับการเข้ารหัสข้อมูลต่างๆ

ไอ้ข้อหนึ่งกับข้อสามนี่ผมเข้าใจว่าอธิบายแบบนี้ OK แล้ว ถ้าอยากรู้ราคาโดยประมาณก็ติดตามอ่านต่อไปได้เลยครับ แต่ตอนนี้ขอเคลียร์ประเด็น ข้อ 2 ก่อน dedicated IP Address มันคืออะไร? กะอีแค่จะเข้ารหัสข้อมูลทำไมไปเกี่ยวกับ IP Address ด้วย?

ก็ต้องขอเล่าเรื่องอ้างอิงถึงยุคก่อนนู้น สมัยนั้น ยังไม่มี shared web hosting ราคาถูกๆ ให้ใช้กันเหมือนสมัยนี้ ใครอยากทำ website ก็ต้องตั้ง web server ขึ้นมา 1 เครื่องเพื่อใช้งานกับ website 1 website นี้เท่านั้น (หรืออย่างน้อยการ share web server; คือหลายๆ web ใช้คอมพิวเตอร์แค่ 1 เครื่อง ก็ยังไม่แพร่หลายเหมือนในสมัยนี้) ในยุคนั้นรูปแบบการเข้ารหัสเครือข่าย แบบ Secure Socket Layer (SSL) ถูกคิดค้นขึ้น และนำไปใช้งานโดยมันจะทำการเข้ารหัสข้อมูลทั้งหมดที่รับส่งกันระหว่างต้นทางและปลายทางครับ

วันเวลาผ่านไป จนมาในยุคหนึ่งที่คนเริ่มใช้งาน computer เครื่องเดียวทำเว็บหลายเว็บ ก่อนที่เราจะเห็นปัญหาเราต้องย้อนกลับไปดูข้างบนอีกครั้งหนึ่ง ตรงที่ผมยกตัวอย่างไว้ว่า
GET /port HTTP/1.1
ถ้ายังจำได้อยู่ เราเข้าเว็บนี้ใช่มั้ยครับ http://ifconfig.me/port แต่ request string ดันมีแค่ที่เห็น แสดงว่าถ้าเราเปลี่ยน ifconfig.me เป็น blognone.com อย่างนี้ http://blognone.com/port browser มันก็จะส่ง request string เดียวกันไปหา Blognone ก็คืออันนี้แหละครับ
GET /port HTTP/1.1
แต่ที่ผ่านมาไม่เคยมีปัญหา เพราะ คอมพิวเตอร์ 1 เครื่องใช้ทำเว็บแค่ 1 เว็บ ใช่มั้ยครับ เอามาแค่ /port ก็รู้แล้วว่าต้องเอาข้อมูลอะไรส่งให้; แต่พอมีหลายๆ เว็บอยู่เครื่องเดียวกัน จะเอา /port ของเว็บไหนส่งให้ผู้ใช้ล่ะทีนี้ และก็มีคนปิ๊ง idea ให้ browser ส่งชื่อเว็บมาด้วย ซึ่งก็อย่างที่เราเห็นว่าจะมีตัวนี้ Host: ifconfig.me โผล่ขึ้นมาใน HTTP header ด้วย ทำให้เรามีหลายๆ เว็บในเครื่องเดียวได้ ทุกคน happy และเขาตั้งชื่อให้วิธีการนี้ว่า Virtual Host

แต่ SSL ล่ะเป็นไงทีนี้ มันเข้ารหัสข้อมูลทั้งหมดใช่มั้ยครับ ซึ่งไม่เคยมีปัญหาในยุด 1 เครื่อง:1 web ปัญหาคือตามมารตฐานเดิม ไอ้เจ้านี่ Host: ifconfig.me มันจะต้องถูกเข้ารหัสไปด้วย และพอมันถูกเข้ารหัสจนอ่านไม่รู้เรื่องแล้ว web server มันจะไปรู้ได้ไงว่าจะเอา key ของเว็บไหนมาถอดรหัส (จริงๆ แล้วผมเล่าแบบง่ายๆ อ่ะนะ สำหรับคนที่สงสัยว่าทำไม่ไม่ลองถอดรหัสด้วย key ทุก key ที่มี ให้ลองอ่านเกี่ยวกับวิธีการเชื่อมต่อของ SSL/TLS ดูนะครับ)

แสดงว่าถ้าจะใช้ SSL จะต้องกลับไปใช้วิธี 1 เครื่อง:1 web งั้นเหรอ? เผอิญว่ามีคนมีทางออกที่ดีกว่านั้นครับ โดยการให้คอมพิวเตอร์ 1 เครื่อง มีหลายๆ IP Address พอมีการเชื่อมต่อมาที่ IP Address นี้ ก็รู้เลยว่า จะต้องใช้ key ของเว็บไหน ถอดรหัส ทำให้แทนที่จะเป็น 1 เครื่อง:1 web เหลือแค่ 1 IP Address:1 Digital Certificate ซึ่งทำให้ราคาถูกลงมาก

จะบอกว่า ที่เราต้องใช้ dedicated IP Address ใน SSL เพราะจังหวะและลำดับการคิดค้นก็ว่าได้ ราคาค่า IP Address ในประเทศไทยผมไม่แน่ใจ แต่รู้ว่าแพงกว่าใน USA ส่วนที่ USA ราคาอยู่ที่ประมาณ $1-$3 ต่อเดือน (แต่ปัจจุบันนี้ dedicated IP Address ไม่มีความจำเป็นอีกต่อไป เพราะมารตฐาน Server Name Indication (SNI) เริ่มแพร่หลายและถูกนำมาใช้มากแล้ว มารตฐานนี้ บอกให้ browser ส่ง Host: ifconfig.me มาสองครั้ง ครั้งแรกส่งมาแบบไม่เข้ารหัส ครั้งที่สองส่งแบบเข้ารหัสตามปกติ)

ราคาค่า Sign Certificate เมื่อก่อนมีราคาค่อนข้างสูง แต่ปัจจุบันอยู่ที่ ฟรี (StartSSL) จนถึง หลายร้อย USD ต่อปี แบบเก็บตังแบบถูกๆ ก็มี ผมเคยคุยกับ sales ของ GoGetSSL เขาอ้างว่าเขาเป็น reseller SSL ที่ขาย Positive SSL ถูกที่สุดในโลก และผมยังไม่เคยเห็นเจ้าอื่นถูกกว่านี้ ราคาของเจ้านี้ อยู่ที่ ประมาณ 125 บาทต่อปี ซึ่งใช้ไม่ดีกับเว็บที่มี subdomain เยอะๆ อย่าง exteen.com เป็นต้น เพราะต้องซื้อให้กับทุก subdomain ในกรณีนั้น ถ้าใช้ wildcard SSL ของ StartSSL ราคาจะอยู่ที่ปีละไม่เกิน 2000 บาทต่อปีครับ ที่ตอนนี้ราคาถูกลงกว่าเมื่อก่อนเพราะมีคนใช้งาน SSL มากขึ้น

คอมพิวเตอร์ประสิทธิภาพสูงขึ้น และราคาถูกลงอย่างต่อเนื่อง

ที่คนใช้ HTTP มากกว่า HTTPS เพราะ เมื่อก่อน HTTPS ราคาแพง (แต่ในปัจจุบันนี้ก็ราคาถูกลงมากแล้ว) แต่แม้ในปัจจุบันนี้การนำ HTTPS มาใช้ให้มีประสิทธิภาพดีก็มีรายละเอียดนั่นนิดนี่หน่อย ต้องใช้คนที่มีความรู้มากในการ setup (แต่ถ้าเอาแบบธรรมดา มันก็ง่ายๆ นะครับ แต่ว่า HTTP ธรรมดานี่ง่ายกว่า ใครทำก็ไม่ต่างกันมากมาย ขึ้นอยู่กับการเลือก software เป็นหลัก) อีกเหตุผลคือ เจ้าของเว็บคิดว่าไม่มีความจำเป็นต้องใช้ เพราะ เว็บนั้น เว็บนี้ ที่ดังกว่า ยังไม่เห็นใช้เลย หรือเหตุผลประมาณนี้อีกร้อยแปดครับ

Google's SPDY vs. Microsoft S+M เราได้อะไรเราเสียอะไร?

เรามาดูกันอีกครังว่า SPDY ที่บังคับให้ HTTP 2.0 ต้องใช้ HTTPS จะก่อให้เกิดอะไรขึ้นในอนาคตครับ (ถ้าส่วนที่บังคับใช้นี้ ไม่ถูกแก้ไขไปนะครับ)
- ปัญหาการแก้ข้อมูลโดยผู้มีอำนาจของประเทศต่างๆ จะลดลงจนเกือบหมด SPDY ใช้อำนาจได้เหนือกฎหมาย แต่ในที่นี้ก็คือมันถูกใช้เพื่อทุกๆ คนนะครับ
- ปัญหา wifi ไม่ปลอดภัย (ถ้าทุกๆ เว็บใช้ HTTPS wifi access point ก็จะปลอดภัยไปโดยปริยาย)
- ปัญหา Censorship และ การดักจับข้อมูลจะลดลง จนเกือบหมด
- ถ้าทุก website ใช้ SSL ราคาค่ารับรอง certificate จะถูกลงกว่านี้อีกครับ เราอาจได้เห็นโปรเหมา SSL เป็นโหล หรืออาจมีโปร จด domain แถม certificate ก็ได้ ทำให้ต้นทุนหลักของการใช้งาน SPDY เหลือแค่พลังประมวลผลของ web server เท่านั้นและตัว SPDY เองยังช่วยเพิ่มประสิทธิภาพในส่วนนี้ด้วย

ข้อเสียคือ
- ISP สร้าง cache โดยพลการ โดยไม่ตกลงอะไรกับผู้ใช้หรือไม่บอกไม่ได้แล้วนะ (นี่เป็นข้อเสียสำหรับ ISP แต่ธุรกิจ CDN น่าจะบูมขึ้น ให้ไปจับจุดนั้นแทน อาจช่วยชดเชยกันได้)
- device เก่าๆ จะใช้งานไม่ได้ ไม่ได้หมายถึง PC นะครับ ผมหมายถึงพวก microcontroller ตัวเล็กๆ น่ะครับ และคิดว่ามี device อื่นๆ ที่จะใช้งานไม่ได้อีกเยอะ
- มีแค่ TCP stack จะต่อ HTTP 2.0 ไม่ได้ อย่างน้อยต้องมี TLS รวมอยู่ใน stack ด้วย (ซึ่งไม่เป็นปัญหากับ PC แต่ microcontroller อาจเข้ารหัส SPDY ได้ช้ากว่าที่ผู้ใช้จะรับได้ครับ)
- ปัญหาแนวๆ นี้แหละครับ ส่วนใหญ่เกี่ยวกับ พลังประมวลผล CPU

ส่วน S+M ก็ตรงกันข้ามครับ
มีดีคือให้อิสระทุกคนในการเลือก (ทุกฝ่าย happy) เมื่อทุกคนมีอีสระเลือกคนจะเลือกประหยัด cost ซะเยอะ (เพราะปัจจุบันก็เห็นมันยังใช้ได้) ปัญหาใหญ่ของ Internet อาจคงอยู่ต่อไปอีกหลายร้อยปี รอ event ที่ทำให้เกิดการเปลี่ยนแปลงขึ้นอีกครั้ง (อาจจะเป็น HTTP 3) SSL จะมีราคาเท่าเดิม microcontroller เล็กๆ ในปัจจุบันจะยังสามารถใช้งาน website ได้

พอคิดถึงตรงนี้แล้ว ผมอยากสรุปว่าในสองมาตรฐานนี้เรากำลังแลกอะไรกับอะไร
เรากำลังแลก ปัญหาการประมวลผลของ CPU ที่มีแนวโน้มว่า ประสิทธิภาพจะสูงขึ้นเรื่อยๆ ในอนาคต กับ ปัญหา Internet ที่มีมาตั้งแต่ในอดีต และในปัจจุบันยังแก้ไขไม่ได้ (และตรงจุดนี้เป็น event ที่จะแก้ไขปัญหาดังกล่าว) SPDY แก้ปัญหาใหญ่อันนี้ แต่จะสร้างปัญหาใหม่ที่พอจะแก้ไขในภายหลังได้ไว้ครับ ส่วน Microsoft S+M ปรับปรุงของเก่าให้ดีขึ้น ไม่แก้ปัญหาใหญ่โตอะไร และไม่ได้สร้างปัญหาใหม่มากมายครับ

ถ้ามองระยะใกล้ๆ แล้ว S+M น่าสนใจกว่า SPDY เยอะ แต่ถ้ามองยาวๆ มองไกลๆ อย่าลืมเชียร์ SPDY นะครับ และถ้ามีใครกำลังเชียร์ S+M อยู่ ก็อยากให้คุณไปอธิบายต่อให้คนอื่นๆ เข้าใจถึง วิสัยทัศน์เบื้องหลัง SPDY ด้วยนะครับ

ปัญหา Internet ยังไม่หมด

มีอีกหลายเรื่องที่ควรจับตา ตอนนี้มีเรื่องหลัก คือ การผูกขาดตลาดของ Webkit (Layout Engine ที่ใช้ใน Google Chrome, Safari, และ Opera 15+)
ผมขอพูดถึงแบบสรุปๆ ไม่อ้างอิงเหตุผลเลยนะครับ (แต่มันมีเหตุผลอยู่นะ) ว่า ตอนนี้ให้เชียร์ IE10+, กับ Firefox ให้เต็มที่ไปเลยครับ Webkit นี่มันเป็น Deja Vu ของ IE ชัดๆ (ดีกว่าหน่อยคืออย่างน้อยมันก็ opensource)

ผมเขียนบทความนี้ต้องการอะไร? (ถ้าไม่มีใครถามอันนี้ถือว่าผมถามเองก็ได้ครับ)
ผมรู้ว่าคนไทยส่วนใหญ่ ไม่มีปากมีเสียงกับการกำหนดมาตรฐานที่สำคัญกับโลกมากๆ (และสำคัญกับประเทศไทยมากๆ) อันนี้นะครับ ที่ผมใช้คำว่าส่วนใหญ่ เพราะผมไม่อาจบอกได้ว่าทุกคนครับ อาจมีคนที่กำลังพูดเพื่ออะไรบางอย่างกับ IETF หรืออาจมีคนกำลังอ่าน draft และออกความเห็นอะไรบางอย่างอยู่ก็ได้ ผมไม่แน่ใจว่าการที่ผมเขียนวิจารณ์ใน version ภาษาไทยนี้ มันจะทำให้เกิดอะไรขึ้นได้บ้าง ผมไม่รู้ว่าคุณผู้อ่านจะช่วยสนับสนุน SPDY แบบบังคับ HTTPS ยังไงได้บ้าง หรืออย่างน้อยที่สุด ถ้าคุณ no idea ไม่รู้จะช่วยยังไง การที่คุณได้มาอ่านและทำความเข้าใจ ก็อาจส่งผลอะไรบางอย่างก็ได้ ผมอยากให้คุณลอง check ความเข้าใจ โดยการไปเล่าคนอื่นๆ ต่อในรูปแบบของตัวเองดูครับ

ถ้าปาฎิหาริย์เกิดขึ้นหนึ่งในร้อยล้าน และมีคนใช้ภาษาไทยประมาณ 70ล้านคน บทความภาษาไทยของผมอันนี้ อาจทำให้เกิด (หรือเป็นส่วนหนึ่งของ) ปาฏิหาริย์ก็ได้นะ

มีประเด็นหรือปัญหาอะไรอยากให้ผมเพิ่มเติมลงไป หรือมีข้อสงสัยตรงไหนที่ยังไม่เคลียร์ แล้วไม่ได้เป็นสมาชิก blognone เลยไม่สามารถส่งความคิดเห็นเข้ามาได้ คุณสามารถส่งความคิดเห็นมาที่ผมทาง email: meet.again.somedayแอทaimดอทคอม ก็ได้นะครับ

สำหรับวันนี้ สวัสดีครับ
แล้วพบกันใหม่