Tags:
Node Thumbnail

ข่าวส่วนใหญ่มักจะให้ข้อมูลในเรื่องราวที่เกิดขึ้นแล้ว แต่มีข่าวส่วนหนึ่งเล่าเรื่องราวของอนาคต

ข่าวที่ผมกำลังเขียนเป็นเรื่องว่าด้วยอนาคตของ Internet ประเทศไทย มันไม่ใช่อนาคตที่กำลังจะเกิดขึ้น แต่เป็นอนาคตที่เราช่วยกันทำให้มันเกิดขึ้นได้

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

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

เราจะรับมือกับปัญหาดังกล่าวได้อย่างไร?

คำถามนี้เป็นสิ่งที่ผมพยายามคิดหาทางออก ผมรวมทุกอย่างไว้ในสมการความคิดของผม ทั้งเรื่องราวด้านผู้ให้บริการ และผู้ใช้บริการ ปัญหาที่ ISP พบ การตลาด การแข่งขัน ปัญหาของผู้ใช้งาน และผมก็ได้ความคิดหนึ่งคือ เราอาจสร้างมาตรฐาน Internet ของประเทศไทยขึ้นมาเพื่อแก้ไขปัญหาที่เกิดขึ้นแล้วและปัญหาที่อาจเกิดขึ้นได้ แต่ทว่าผมเป็นคนธรรมดาไม่อาจบังคับใช้มาตรฐานใดๆ ได้ ดังนั้นสำหรับวันนี้ ขอให้ได้ฝันก่อนก็ยังดี

ผมเชื่อว่านั่นจะเป็นประโยชน์กับทุกคนนะครับ และถ้าวันนี้ฝนกำลังตกอยู่ ผมคนหนึ่งที่จะทำเรื่องที่ทำได้เพื่อให้ท้องฟ้าวันพรุ่งนี้งดงามกว่าท้องฟ้าใดๆ ที่เคยเห็นมาครับ

เราไปดูในบทความกันดีกว่าว่าผมฝันถึงมาตรฐานอะไรมั่ง

จุดเริ่มต้น: มาตรฐานเพื่อแก้ปัญหาการดัดแปลงแก้ไขข้อมูลโดย ISP โดยมิชอบ

alt="man-in-the-middle"
รูปภาพจาก: https://www.owasp.org/
ผู้ให้บริการ Internet หรือ ISP ของเรา กำลังเป็น attacker ดังภาพครับ แต่เขามีเหตุผลในการทำแบบนั้น (หรืออย่างน้อยเขาก็มีข้ออ้างที่ฟังขึ้นในการทำแบบนั้น) นั่นคือการสร้าง cache (รายละเอียดหาอ่านได้ในข่าวเก่านะครับ) และการ block website

ดังนั้นผมจึงเสนอให้มี มาตรฐานในการสร้าง HTTP cache และ มาตรฐานในการ block website ครับ
ผมคิดว่าเราไม่ควร block website ด้วยเหตุผลหนึ่งข้อ คือ เราไม่อาจ block website ได้ตั้งแต่แรกอยู่แล้ว ยกเว้นว่าเราจะ block secure protocol ทั้งหมดเหมือนประเทศจีน (ซึ่งรู้อยู่แล้วว่าไม่อาจทำได้) แต่ผมมีเหตุผลอีกข้อที่ทำให้คิดดูอีกที การ block website ได้ มันก็ดีไปอีกอย่าง คือ ทำเพื่อให้หน่วยงานภาครัฐบางส่วนที่ไม่เข้าใจเรื่องของคอมพิวเตอร์มากนัก สบายใจขึ้นได้ โดยทำให้เขาคิดว่าเขาสามารถ block website ได้ (ซึ่งจริงๆ แล้วทำไม่ได้) สรุปคือมันมีผลทางด้านจิตใจนั่นเอง ดังนั้นการ block website นั้นสำคัญมาก แต่เทคนิคที่นำมา block website รวมถึงเทคนิคที่นำมาใช้สร้าง cache ดันเป็นเทคนิคที่สามารถใช้ในการดัดแปลงแก้ไขหรือบิดเบือนข้อมูลบางส่วนของเว็บไซท์ได้ด้วย การกำหนดมาตรฐานของการทำงานดังกล่าวเพื่อไม่ให้ถูกใช้นอกลู่นอกทางจึงเป็นเรื่องสำคัญ

รายละเอียดการ block website

alt="censorship"
ผมเสนอให้เราสามารถ block website ได้ด้วย hostname (ข้อมูลที่อยู่ใน Header host: ของ HTTP) เท่านั้น และสามารถใช้ wildcard (*) ในการกำหนดกฎการ block ได้ เพื่อแทนข้อมูลในส่วนของ subdomain เท่านั้น ในกรณีตั้งกฎ block ทุก subdomain เช่น *.example.com ให้ถือเป็นการ block example.com ด้วย
ในกรณีที่ hostname เป็น IP address ห้ามใช้ wildcard ในการตั้งกฎ แต่จะใช้ CIDR notation ในการตั้งกฎแทน สรุปข้อความทั้งหมดเป็นตัวอย่างคือ เราจะเห็นกฎหน้าตาแบบนี้ *.example.com และแบบนี้ 127.0.0.1/16 ถูกตั้งขึ้นเพื่อ block website ต่างๆ ครับ list ของกฎที่ใช้ในการ block website ทั้งหมด ISP และประชาชนทั่วไปต้องสามารถเข้าถึงและตรวจสอบได้

รายละเอียดการสร้าง cache

alt="dam"
เรื่องการสร้าง cache นั้น เป็นเรื่องละเอียดอ่อน ไม่ควรปล่อยให้ต่างคน (ต่าง ISP) ต่างทำ (หรืออย่างน้อยต้องสร้างกลไกให้แต่ละ ISP ยันกันเองได้) เพราะผู้รับเคราะห์คือผู้ใช้งานครับ
ในเบื้องต้น ผมเสนอว่าควรกำหนดขึ้นมาว่า cache จะถูกเก็บได้ในกรณีไหนบ้าง โดยตั้งกฎในการเก็บ cache เป็นข้อๆ คล้ายกฎการ block website การตั้งกฎจะยึดตามมาตรฐาน HTTP เป็นหลัก ในทางกลับกันผมก็รู้ด้วยว่า ISP มีปัญหากับ traffic จำพวก Youtube ดังนั้นควรจะเปิดโอกาสให้ ISP เสนอเพิ่มกฎการเก็บ cache ลงไปเองได้ ด้วยเงื่อนไขคือ กฎดังกล่าวต้องมีความแม่นยำ ข้อมูลที่ได้จาก cache ต้องไม่ถูกบิดเบือนไปจากข้อมูลของ server ปลายทาง หรือทำให้การทำงานของ website นั้นๆ ผิดจุดประสงค์ไป และมีกลไกให้ประชาชนทั่วไปสามารถยกเลิกกฎ (หรือปรับปรุงกฎ) ของ cache ได้ ซึ่งจะได้พูดถึงกันต่อไปครับ
ข้อมูลนอกเหนือจากกฎการเก็บ cache ถือว่าไม่สามารถเก็บเป็น cache ได้ ต้อง request จาก server ปลายทางเท่านั้น

ผมเพิ่งจะมาบอกตรงนี้ด้วยชื่อ ordinaryone เป็นครั้งแรก แต่ผมขออ้างถึงตัวเองว่า ผมเขียนโปรแกรมทางด้านระบบเครือข่ายมาตั้งแต่สมัยมัธยม แม้เวลาที่ผ่านมาจะทำเรื่องนั้นเรื่องนี้ที่ไม่ใช่เรื่องเกี่ยวกับระบบเครือข่าย ผมก็มีประสบการณ์มากพอที่จะบอกถึงหลุมพรางต่างๆ ที่อยู่ในระบบ proxy คือ
- HTTP proxy ที่ไม่ได้ออกแบบมาเฉพาะ จะทำ IP address ปลายทางหาย เนื่องจากในการใช้งาน HTTP proxy
URL ของปลายทางทั้งหมด(รวมถึง domain name) จะถูกส่งเป็น URI ของ HTTP proxy แต่ระบบ HTTP proxy ทั่วไปจะไม่มีช่องทางให้ส่ง IP address ทำให้ DNS ถูก proxy server query ใหม่ด้วยตัวเอง หรือมีผลเทียบเท่าการ เปลี่ยน IP address ปลายทาง ทำให้เทคนิคทำเว็บจำพวก roundrobin DNS ทำงานผิดพลาด ปัญหานี้เคยเกิดขึ้นจริงกับเครือข่ายของค่าย "ถูกต้อง" ผมจึงได้โทรคุยเถียงกับพนักงานค่ายนี้ที่ไม่ค่อยรู้เรื่องที่ผมพูดอยู่เป็นชั่วโมง (ปัจจุบันค่ายนี้ได้แก้ไขปัญหานี้แล้ว)
- HTTP proxy จะมี request header ที่เป็น de facto standard ตัวหนึ่งชื่อว่า "X-Forwarded-For" ทำให้ HTTP proxy ที่ไม่ได้ออกแบบมาให้ใช้ร่วมกับเทคนิค IP address spoofing จะใส่ header ตัวนี้ลงไปโดยไม่ได้ตั้งใจ
- HTTP proxy ที่ไม่ได้ออกแบบมาเฉพาะ จะคิดว่า ทุก request ที่ผ่านเข้ามา เป็น HTTP request

จากปัญหาทั้งหมดที่พบใน HTTP proxy ทั่วไป ผมอยากให้คำนึงถึงมาตรฐาน software ที่ใช้ในการ cache ข้อมูลด้วย อย่างน้อยควรมีมาตรฐานดังต่อไปนี้
- ระบบ cache ข้อมูลที่ใช้โดย ISP ห้ามเปลี่ยนแปลง IP address ปลายทางที่กำหนดโดยผู้ใช้
- ระบบ cache ข้อมูลที่ใช้โดย ISP ต้อง spoof IP address เป็นผู้ใช้เพื่อหลอกปลายทาง โดยห้ามแก้ไข HTTP request header ที่ส่งโดยผู้ใช้
- ระบบ cache ข้อมูลที่ใช้โดย ISP จะต้องยอมให้ traffic ที่ไม่ใช่ HTTP ทำงานผ่าน port 80 ได้ด้วย โดยสามารถแยกแยะระหว่าง HTTP traffic และ non-HTTP traffic โดยการตรวจหา request method ของ HTTP โดยในการทำงาน mode non-HTTP traffic จะทำได้โดยการ relay ข้อมูล TCP ทั้งหมด ระหว่างต้นทางและปลายทาง

จุดสำคัญที่เป็นแก่นของมาตรฐานที่ผมคิดขึ้นคือ กลไกตรวจสอบข้อมูลจาก ISP โดยผู้ใช้ เพื่อให้ผู้ใช้สามารถเสนอยกเลิก หรือปรับปรุงกฎการ cache ที่กำหนดขึ้นโดย ISP ได้

ผมขอเสนอ เวทย์มนต์เบื้องหลังหลักการทั้งหมด เป็นคำสัญญาว่าทำไม มันจะทำให้ internet โปร่งใสขึ้น (ไม่ได้โปร่งใสขึ้นทางเทคนิคแต่โปร่งใสในแง่ให้ผู้ใช้มีช่องทางตรวจสอบได้)
ถ้าทำตามมาตรฐานที่ผมเสนอไว้ข้างบนจนถึงตรงนี้ จะเห็นได้ว่าประชาชนทั่วไปสามารถเข้าถึง ข้อมูล blocked websites list และ cache rules list ได้
ใน cache rules list ผมเสนอให้ใส่ ID ที่ใช้ในการอ้างถึงกฎแต่ละข้อไว้ด้วย
ผมขอเสนอให้ HTTP response ที่ไม่ได้ relay จาก server ปลายทางโดยตรง (หรือพูดอีกนัยหนึ่งคือ cache ของ ISP) ใส่ HTTP header พิเศษเพื่อบอกกับผู้ใช้ว่า นี่ไม่ใช่ข้อมูลจากปลายทาง โดย header ที่ผมจะเสนอ มีชื่อว่า "X-Thai-ISP" โดยถ้าข้อมูลมาจาก cache ให้ส่ง header มาประมาณนี้ครับ
X-Thai-ISP: cachehit (#id)
โดย #id จะเป็นเลขหรือข้อมูลที่ใช้ อ้างถึง กฎการ cache ที่ทุกคนสามารถเข้าถึงได้ครับ
เน้นว่าไม่ยุ่งกับ request header แต่นี่เป็นการเปลี่ยนแปลง response header นะครับ
ในกรณีที่ HTTP server ปลายทาง ส่ง header "X-Thai-ISP" มาซะเอง ให้ ISP ลบออก เพื่อป้องกันการโยนความผิดให้ ISP ครับ ในกรณีที่ website ถูก block ให้ส่ง header มาว่า
X-Thai-ISP: blocked (#id)
หลักการอื่นๆ เหมือนกับการ cache ครับ

การเปิดให้คนเปลี่ยนแปลงกฎการ cache ได้ ในช่วงแรกนั้นจะเกิดการโต้เถียงกันมาก แต่ในที่สุดแล้วมันจะเสถียรครับ (ว่าง่ายๆ คือผมไม่ได้คิดมาตรฐานมาเพื่อเป็นผลลัพธ์ทันที แต่ผมคิดมาตรฐานเพื่อให้ลู่เข้าสู่ผลลัพธ์) โดยมีแนวทางการหาข้อยุติในการโต้เถียงตามที่ได้กำหนดไว้แล้วคือ กฎการ cache ทุกกฎต้องมีความแม่นยำ ข้อมูลที่ได้จาก cache ต้องไม่ถูกบิดเบือนไปจากข้อมูลของ server ปลายทาง หรือทำให้การทำงานของ website นั้นๆ ผิดจุดประสงค์ไป ข้อดีอีกข้อของการทำแบบนี้คือ การทำแบบนี้จะช่วยให้ ISP แต่ละเจ้า แทคทีมกันคิดกฎการ cache เพื่อประโยชน์ของทุกฝ่ายครับ รวมถึงจะไม่มี ISP ใดได้เปรียบเสียเปรียบกันที่ cache

สำหรับ ISP ที่คิดจะเล่นตุกติกโดย แอบ cache โดยไม่ส่ง "X-Thai-ISP" header
ผมคิดวิธีเขียนโปรแกรมตรวจสอบไว้เบื้องต้นแล้ว ถ้ามีใครสักคนเอามาตรฐานนี้ไปเป็นฉบับร่างของมาตรฐานจริง อยากให้เตรียมบทลงโทษไว้ด้วยครับ การดัดแปลงข้อมูลต่างๆ ใน website ก็เช่นกัน จะมีผู้ใช้บางส่วนจับได้ (เช่น ผู้ใช้ที่ต่อ VPN ไปต่างประเทศ หรือเช่า VPS มาใช้ SOCKS proxy หรือ SSH proxy เป็นต้น)

มาตรฐานอีกอย่างที่จะไม่พูดถึงไม่ได้เลยเพราะมันจะช่วยแก้ปัญหาการสื่อสารระหว่างผู้ใช้บริการ กับ ISP คือ มาตรฐานการวัดความเร็ว Internet

alt="flash"
คือตอนนี้ ตัวเลขที่ โฆษณากันทาง TV 9Mb/s มั่ง 10Mb/s มั่ง มันเป็นความเร็วของ bandwidth ก่อน share (อันนี้อย่างน้อยตามคำอ้างของ ISP นะครับ (ซึ่งน่าจะจริง)) แต่สำหรับผู้ใช้งานแล้ว ไม่มีทางได้ความเร็วดังกล่าวแน่นอนครับ
แต่พูดอีกนัยหนึ่งก็คือ สำหรับผู้ใช้แล้ว ISP จะกำหนดเลขพวกนี้มายังไงก็ได้ ยังไงผู้ใช้ก็ตรวจสอบไม่ได้อยู่แล้ว

ถ้า ISP มีปัญหากับ speedtest.net มากขนาดต้องไปโกงการทำงานของมัน (รายละเอียดหาอ่านได้ในข่าวเก่านะครับ) ผมคิดว่าเราน่าจะพลิกวิกฤตให้เป็นโอกาส โดย เอามันมาวัดความเร็ว Internet ซะเลย
ทำได้ยังไง?
ยกตัวอย่างนะครับเดิมทีหน่วยที่ใช้ในการโฆษณา เป็น 9Mb/s ใช่มั้ยครับ เราจะไม่ใช้หน่วยนี้ในการโฆษณาครับ เราอาจตั้งหน่วยใหม่ขึ้นมา อย่าง "โดริคิ" Internet เร็ว 237 โดริคิ อะไรประมาณนั้นน่ะครับ ยกตัวอย่างเฉยๆ นะ เวลาใช้จริงไม่ใช่อย่างนี้อยู่แล้ว ไอ้หน่วยโดริคิที่ผมยกตัวอย่างนี้ ก็วัดมาจากวิธีการเดียวกับที่ใช้ใน speedtest.net นั้นแหละครับ ถ้ากำหนดมาตรฐานการวัดมาจะมีคนเขียนโปรแกรมวัดให้ตามหลังให้แน่นอนครับ ทีนี้ข้อมูลที่ใช้ในการโฆษณา ต้องให้ ISP ทำการวัดตัวเลขโดริคิเพื่อบ่งบอกความเร็ว Internet ของตัวเอง โดยใช้หลักการทางสถิติ (เช่นการเฉลี่ย) มารวมข้อมูลตัวเลขต่างๆ ให้เหลือเลขเดียว
โดยการเก็บข้อมูลนั้น ต้องคำนึงถึง มิติในการเก็บข้อมูล ขั้นต่ำ 3 มิติ
มิติที่ 1 ตำแหน่งของผู้ใช้ และอัตราการ share bandwidth ในตำแหน่งที่เก็บข้อมูลครับ
มิติที่ 2 ตำแหน่งของ web server เช่นอยู่ที่ประเทศอะไร ทวีปไหน เป็นต้น
มิติที่ 3 มิติเวลาที่ใช้ในการเก็บข้อมูลครับ
พอเก็บข้อมูลได้ครบทุกมิติ ค่อยทำการเฉลี่ย (หรือการดำเนินการทางสถิติอื่นๆ) ทำให้ข้อมูลความเร็ว Internet ที่กระจายอยู่ในทุกมิติ รวมกันเป็นหน่วยโดริคิเพื่อใช้ในการโฆษณาครับ นอกจากจะเป็นความเร็วที่ตรวจสอบได้แล้ว ยังช่วยให้ผู้ใช้งาน เข้าใจ ISP มากขึ้นด้วย

อีกเรื่องเกี่ยวกับระบบเครือข่าย ที่อยากให้กำหนดแนวทางการปฏิบัติ

เรื่องนี้ไม่จำเป็นต้องบังคับหรือกำหนดเป็นมาตรฐานนะครับ แต่อยากให้กำหนดเป็นแนวทางการปฏิบัติคือ เรื่องช่องสัญญาณ Wi-Fi ครับ ผมจะไม่อธิบายแบบเข้าใจง่ายไว้ในข่าวนี้นะครับ ถ้าใครคิดว่าอธิบายแบบง่ายๆ ได้ ช่วยเขียนใหม่ทีนะ
คือสัญญาณ Wi-Fi ที่เราใช้กันอยู่นั้น ถ้าไปซื้อเสาสัญญาณ เราอาจจะเห็นว่ามันเขียนข้างกล่องว่า 2.4 GHz ซึ่งเป็นจุดเพียงจุดหนึ่งของความถี่เท่านั้นครับ เหมือนเวลาเรามองไม้บรรทัดแล้วเราดูที่จุด 2.4 cm นั่นแหละ มันเป็นแค่จุดๆ หนึ่งไม่มีระยะ แต่สิ่งที่เราต้องการในการส่งสัญญาณ Wi-Fi คือ bandwidth หรือก็คือ ช่วงของความถี่ครับ หรือถ้าคุณผู้อ่านกำลังมองไม้บรรทัดอยู่จริงๆ มันก็เปรียบเทียบได้กับระยะเช่น 5 mm บนไม้บรรทัด มันอาจจะเป็นระยะจากจุด 5.5 cm ถึง 6.0 cm หรือ จากจุด 6.2 cm ถึง 6.7 cm หรืออาจเป็นระยะ 5 mm ในส่วนอื่นๆ ของไม้บรรทัดก็ได้
เวลาเรา config router มันจะมีส่วนที่ให้เราใส่ channel ด้วยนะครับ อาจจะมีช่อง 1 ถึง 11 หรือ 1 ถึง 13 ให้เลือกก็แล้วแต่ยี่ห้อแล้วแต่รุ่นนะครับ ปัญหามันอยู่ตรงนี้ครับ คือ เราจะเลือกช่องไหนให้ถูกสัญญาณจากเพื่อนบ้านกวนน้อยที่สุด หรือ router เราไปกวนสัญญาณเพื่อนบ้านน้อยที่สุด การที่เราจะเลือกได้นั้นเราต้องเข้าใจก่อนว่าแต่ละช่องสัญญาณ มี bandwidth หรือระยะที่ทับกันครับ เช่น ช่อง 1 อาจจะเป็นจุด 0 ถึง 4 cm บนไม้บรรทัด ช่อง 2 อาจจะเป็น 1 ถึง 5 cm บนไม้บรรทัด ไล่ไปจนถึงช่อง 13 ซึ่งอาจถูกมองเป็น ระยะจากจุด 12 cm ถึง 16 cm บนไม้บรรทัดครับ การเลือกให้ไม่ถูกสัญญาณรบกวนคือการเลือกช่องที่ bandwidth ไม่ทับกับของคนอื่น เช่น มี router 3 เครื่อง ตั้งใกล้กัน ถ้ามันถูกตั้งค่าเป็นช่อง 1, 6, 11 ทั้งสามเครื่องก็จะทำงานได้อิสระจากกัน (ไม่ถูกเครื่องอื่นกวน) แล้วถ้ามีเครื่องที่สี่เข้ามาล่ะทำไง? หลายคนจะคิดว่าเราควรใช้ช่องที่ไม่มีคนใช้ เช่นช่อง 2, 3, 4 อะไรเทือกนี้ครับ แต่จริงๆ แล้วพลาด เราควรเลือก 1 ในสามความถี่ที่คนใช้อยู่ครับโดยดูว่าสัญญาณของ router เครื่องอื่น ความถี่ช่องไหน weak ที่สุดครับ

เกิดอะไรขึ้นถ้าเราเลือกช่อง 2?
อย่างที่บอก ถ้าช่อง 1 คือ 0 ถึง 4 cm ช่อง 2 คือ 1 ถึง 5 cm ทำให้ bandwidth เกิดการเหลื่อมกันครับ การเหลื่อมทางความถี่ดังกล่าวทำให้ router แบ่งเวลากันทำงานไม่ได้ แต่ถ้าใช้ความถี่เดียวกันไปเลยมันจะมี MAC layer เข้ามาจัดการแบ่งเวลากันทำงานครับ (พวก CSMA อะไรเทือกนั้น) US ก็ใช้ความถี่ ช่อง 1, 6, 11 เป็นมาตรฐานมานานตั้งแต่ 802.11b (เขาเลือก 3 ช่องนี้เพราะเป็นความถี่ที่ชิดที่สุดที่ไม่เหลื่อมกันใน b) พอเป็น g แล้วก็ยังใช้ได้ (แม้ g จะใช้ bandwidth แคบกว่า b) แต่พอมาถึงยุคของ n (ซึ่งแต่ละช่องมีขนาดเท่าช่องของ g) n คิดวิธีใช้ช่องคู่ที่อยู่ติดกันเพื่อเพิ่มความเร็วการส่งข้อมูล เช่นใช้ช่อง 1 กับช่อง 5 พร้อมกันเป็นต้น (หรือถ้ามองในไม้บรรทัดก็คือช่วง 0 ถึง 8 cm) ทำให้ เจ้า 1, 6, 11 นี่ชักไม่ค่อย work แล้ว น่าจะใช้ช่อง 1, 5, 9, 13 มากกว่า (ในกรณีแถวนั้นไม่มี router 802.11b) แต่ว่าแถวบ้านผมตั้งช่องกันมั่วนิ่มมาก ถ้ามีแนวทางปฏิบัติหน่อยก็คงดีกว่านี้

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

  • หาจุดอ่อนในมาตรฐานนี้ หรือควรมีอะไรเพิ่มเติม อยากให้ comment ทิ้งไว้ครับ (สมมุติเล่นๆ ว่าเราสามารถร่างมาตรฐานได้เอง ((อย่างน้อย) ขอให้ได้ฝัน))
  • share ไปให้ไกลที่สุด เผื่อว่าโอกาส 1 ในล้าน จะมีใครสักคนที่มีอำนาจบังคับใช้ ได้อ่านเข้า
  • ถ้าคุณเป็นคนหนึ่งที่นำเรื่องเข้าสู่การดำเนินการอย่างเป็นทางการได้ ขอให้พิจารณาเรื่องนี้ด้วยนะครับ

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

สวัสดีครับ

Get latest news from Blognone

Comments

By: mk
FounderAndroid
on 13 May 2013 - 08:02 #572380
mk's picture

ถ้าไม่แก้ข่าวเก่าให้เรียบร้อย ข่าวใหม่จะไม่มีวันได้ขึ้นหน้าแรกนะครับ

By: -Rookies-
ContributorAndroidWindowsIn Love
on 13 May 2013 - 09:55 #572412 Reply to:572380
  • เว้นหน้าวงเล็บเปิด หลังวงเล็บปิด
  • พิมพ์ไปเรื่อย ๆ ระบบจะตัดหน้าเอง ถ้าอยากขึ้นบรรทัดใหม่ค่อย enter 1 ที แต่จะให้ดีควน enter 2 ที ระบบจะขึ้นบรรทัดใหม่แบบเว้นให้ 1 บรรทัดด้วย จะอ่านง่ายขึ้น (ข่าวเก่าก็ยังไม่ได้แก้จุดนี้)

เทคโนโลยีไม่ผิด คนใช้มันในทางที่ผิดนั่นแหละที่ผิด!?!

By: churos
ContributorAndroidWindows
on 13 May 2013 - 13:34 #572498 Reply to:572380

ผมว่าตอนนี้ upcoming ดีกว่าหน้าแรกอีกครับ เพราะหน้าแรกเดี๋ยวก็หายไปเพราะข่าว blognone มีเยอะ แต่ upcoming มาคาอยู่หน้านี้หลายวันก่อนจะหายไป แถมไม่ใช่เฉพาะ Writer ที่สามารถเห็นเพื่อนำข่าวขึ้นหน้าแรก แต่เป็นสมาชิกทุกคนของ blognone เข้ามาเห็นได้ตลอด

By: mk
FounderAndroid
on 13 May 2013 - 13:40 #572499 Reply to:572498
mk's picture

ถ้าอยากเขียนเพื่อขึ้นแค่ upcoming เฉยๆ ผมก็ไม่มีปัญหาน่ะครับ ว่าแต่อยากได้แบบนั้นจริงๆ เหรอ?

By: sunback
Contributor
on 13 May 2013 - 14:23 #572515 Reply to:572498
sunback's picture

งั้นก็ย้ายไปฟอรั่มเลยครับ อยู่บนจนกว่าจะมีกระทู้ใหม่มา อาจยาวนานกว่าใน upcoming ครับ

By: nat3738
ContributorAndroidRed HatUbuntu
on 13 May 2013 - 14:44 #572531 Reply to:572498

ผมเชื่อว่า ถ้าบทความกลุ่มนี้ได้ขึ้นหน้าแรก จะได้เป็น Featured ครับ

By: nutmos
WriteriPhoneUbuntuWindows
on 13 May 2013 - 17:29 #572607 Reply to:572498

แต่จะเห็นเฉพาะสมาชิกนะครับ คนนอกไม่เห็น

By: deargerous
ContributoriPhoneAndroidWindows
on 14 May 2013 - 15:49 #572982 Reply to:572380
deargerous's picture

ตัวบทความเนื้อหาน่าสนใจ และมีประโยขน์มากครับ ชี้ให้เห็นปัญหาและเสนอทางออกพร้อม

อยากให้แก้ให้เรียบร้อยแล้ว จะได้ลงหน้าแรก ถ้าให้ดีเสนอให้เป็น Featured ด้วย

By: ordinaryone
AndroidRed HatWindows
on 16 May 2013 - 21:16 #574108 Reply to:572380

สวัสดีครับ
ผมใช้เวลากับ blognone ค่อนข้างมากครับ

การแก้ไขของผมนั้น
ได้ทำการ เว้นวรรคนอกวงเล็บ แต่ไม่เว้นวรรคในวงเล็บ (ตามที่ได้อ่านมา)
แต่ว่าในจุดที่เป็นทั้งนอกและในวงเล็บ ไม่ได้ระบุไว้ผมจึงไม่ได้เว้นวรรค

เรื่องการเคาะขึ้นบรรทัดใหม่ ผมใช้เฉพาะจุดที่ตั้งใจจะใช้เท่านั้นครับ ทั้งข่าวเก่าและข่าวใหม่
การขึ้นบรรทัดใหม่ 2 ครั้ง มีอยู่ใน markdown syntax เป็นการขึ้น paragraph ใหม่ ซึ่งจุดที่เหลืออยู่คือจุดที่ตั้งใจใส่เท่านั้นครับ

ผมจึงไม่แน่ใจว่าควรแก้ไขในส่วนไหนเพิ่มเติม

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

เพียงมีคนเข้าใจเพิ่มขึ้นสักหน่อยก็ไม่ถือว่าล้มเหลวแล้ว

ผมเห็นว่า Internet ประเทศไทยนั้นมี timebomb มันจะมีปัญหาขึ้นสักวันครับ

การดำเนินการของผมไม่ได้สิ้นสุด ตรงนี้ ที่นี่ ครับ
ด้านผมเองก็มีปัญหาเหมือนกัน และนี่อาจเป็นข่าวสุดท้ายที่ผมจะเขียนใน Blognone ก็ได้

ถ้าข่าวนี้มีอะไร update มีใครอยาก เรียกผมมาดูผลอะไรบางอย่างในอนาคต

ติดต่อ ผมได้ที่
meet.again.someday แอท aim ดอทคอม
ครับ

By: psemanssc
Blackberry
on 13 May 2013 - 08:44 #572389

ผมรู้สึกว่ามันงงๆอะครับอ่านไม่ลื่นไหล

By: I3assy on 13 May 2013 - 09:30 #572402
I3assy's picture

The flash มาไง

By: เดวิลแมน on 13 May 2013 - 11:25 #572442 Reply to:572402

เป็นสัญลักษณ์แห่งความเร็ว (ในการ์ตูนซูเปอร์ฮีโร่ทีม)

By: mr_tawan
ContributoriPhoneAndroidWindows
on 13 May 2013 - 12:06 #572463
mr_tawan's picture

ผมว่ามีหลายอย่างที่เข้าใจคลาดเคลื่อนนะ อย่าง ทุกวันนี้ผมใช้ Package ADSL ที่เป็น 10Mbps อยู่ก็ทำ Peek ได้ถึง 1MB/s (สังเกตหน่วย) ได้สบาย ๆ แล้วก็ถึงจะไม่ตลอดเวลา (เพราะขึ้นกับความเร็วของตัว server ด้วย) แต่ก็ทำได้นานเหมือนกันนะในแต่ละวัน


  • 9tawan.net บล็อกส่วนตัวฮับ
By: hisoft
ContributorWindows PhoneWindows
on 13 May 2013 - 12:27 #572476
hisoft's picture

แล้ว speedtest นี่แก้ง่าย ๆ ด้วยการทำเป็น https เลยไม่ได้หรือครับ?

By: ordinaryone
AndroidRed HatWindows
on 16 May 2013 - 21:25 #574114 Reply to:572476

ไม่ได้ครับ เพราะ speedtest.net ขอบริจาค bandwidth จาก web อื่น
การใช้ https นั้น จะเปลืองพลังประมวลผลของ server เก็บเว็บดังกล่าว (ที่ไม่ใช่ของ speedtest) ด้วยครับ
(ซึ่งผลต่อไปจะเป็นอย่างไรนั้นเป็นเรื่องที่คาดเดาได้)

อีกเรื่องคือสำหรับ Internet ที่มีความเร็วสูงมากๆ การเข้ารหัสอาจเป็น bottle neck ที่มีผลต่อความเร็วมาก ได้เช่นกันครับ

By: churos
ContributorAndroidWindows
on 13 May 2013 - 13:27 #572495

ขอแชร์เรื่องการ block เว็บไซท์ ปัจจุบันประเทศไทยมีการ block เว็บไซท์เยอะมาก ส่วนใหญ่เป็นคำสั่งศาลให้ ISP block ดังนั้นถ้า ISP ไม่ block ISP ก็ทำผิด การเผยแพร่ list ของการ block ผมว่ามันเหมือนการกระตุ้นให้คนที่เห็น list ยิ่งสนใจอยากเข้าไปดูเว็บไซท์นั้นๆเข้าไปอีก ผมเองก็ดันไปเคยเห็น list ซึ่งผมก็เหมือนคนอื่นๆ บางเว็บก็ไม่เห็นมีอะไรเลย แต่บางเว็บเข้าไปดูแล้วรู้สึกทำให้คนไทยแบ่งฝักแบ่งฝ่ายมากขึ้น

ปัจจุบันเว็บไซท์ที่ถูกสั่งให้ block มากที่สุดน่าจะเป็น facebook.com และ youtube.com เพราะใครก็โพสต์ได้ หาตัวคนโพสต์ก็ไม่ง่ายด้วย การ block ทั้งเว็บไซต์ประเทศไทยก็เคยทำกันไปแล้วแต่มีแต่ผลเสีย ดังนั้นปัจจุบันการ block เว็บไซต์ก็เลยต้อง block เฉพาะบางเพจครับ เป็นผลให้อุปกรณ์ปัจจุบันไม่ได้ดูแค่ host ครับดูไปถึง url เลยว่าอยู่หน้าไหน บางอุปกรณ์เข้าใจถึงตัวแปรที่ถูกส่งผ่าน POST และ GET ถ้าความหมายของกฏการ block เว็บไซท์ของแต่ ISP หมายถึง config ของอุปกรณ์ที่ ISP ทำละก็คงไม่เหมือนกันในแต่ละ ISP เพราะก็ขึ้นอยู่กับอุปกรณ์ที่ ISP ใช้ด้วยครับ ความเห็นผมกฏการ block เว็บไซท์ก็คำสั่งศาลนั่นแหละครับ

อีกอย่างที่พูดกันเยอะคือแก้ง่ายๆก็เข้าด้วย https เลยซิ ตอนนี้มันมีเทคนิค SSLStrip ลองอ่านรายละเอียดคร่าวๆได้ที่ http://www.iphoneapptube.com/2012/11/sslstripguard-free-wifi-thai-app-review.html ซึ่งมันดักข้อมูลคุณได้แม้ใช้ https ตอนนี้ยังไม่เจอว่าอุปกรณ์ใดใช้เทคนิคนี้ในการ block เว็บไซท์ เพราะมันใช้ทรัพยากรของเครื่องสูงมาก ถ้าอนาคตอันใกล้ spec เครื่องสูงขึ้นคงทำกันไหว วิธีส่วนมากน่าจะเจอใน WiFi ประเภทตั้ง Access Point ขึ้นมาตัวนึงแล้วตั้ง SSID เหมือนตัวที่คนนิยมใช้กันเช่น @TRUEWIFI, @dtac wifi เพื่อให้คนเข้าใจผิดคิดว่าเป็นของผู้ให้บริการรายนั้น แล้วก็ดักข้อมูล username, password หรืออื่นของคุณไปแม้คุณจะใช้ https ก็ตาม อนาคตเราอาจจะเจอการ caching HTTPS ด้วยมั้งเดาเอานะ

By: lew
FounderJusci's WriterMEconomicsAndroid
on 13 May 2013 - 19:20 #572644 Reply to:572495
lew's picture

SSL Strip โดยหลักการมันคือการไม่ให้ผู้ใช้เข้าไปใช้ HTTPS แต่แรก ถ้ามองลูกกุญแจตรง URL สักหน่อย กระบวนการพวกนี้ก็ไร้ผลครับ และการอ้างว่า SSL Strip ทำให้ดักฟัง HTTPS ได้ก็เป็นการอ้างที่ "เกินจริง"


lewcpe.com, @wasonliw

By: ordinaryone
AndroidRed HatWindows
on 16 May 2013 - 23:06 #574134 Reply to:572644

ถูกต้องแล้วครับ
เรื่องนี้มีการพยายามแก้ไข โดย ฝั่ง client มี https everywhere ช่วย

ส่วนฝั่ง server นั้น
มี DNSsec ช่วย ในกรณี ใช้หลักการไปยุ่งวุ่นวายกับ DNS (แต่ยังไม่ได้ใช้แพร่หลายมากนัก)

ในกรณีการเปลี่ยน route ใน layer ต่ำๆ นั้น
จริงๆ แล้วมีมาตรฐาน SRV record (ที่ไม่ถูกนำมาใช้มากนักครับ)

SRV record จะไม่ได้บอกแค่ว่า ชื่อนี้ชี้ไป IP Address ไหน
แต่จะบอกด้วยว่ามีบริการอะไร run อยู่บน IP Address นั้น รวมถึง port ที่ให้บริการด้วย
เช่นมันจะบอกได้ว่า มีแต่ https run อยู่ที่ IP address ปลายทางเท่านั้น ไม่มี http เป็นต้น

ถ้ามาตรฐานนี้ แทคทีมกับ DNSsec จะแก้ไขเรื่องดังกล่าวได้ครับ
แต่ปัจจุบันนี้ รอดู HTTP 2.0 ดีกว่ามีหวังกว่า เพราะ SRV Record ดันไปทำงานซ้ำกับส่วนมาตรฐานเก่า
(SRV record เลยไม่ถูกใช้งานร่วมกับ HTTP หรือ HTTPS ครับ)

By: ordinaryone
AndroidRed HatWindows
on 16 May 2013 - 22:24 #574168 Reply to:572495

เรื่องนี้เป็นปัญหาใหม่ที่ผมเพิ่งรู้ครับ

สรุปคือ มีการดัดแปลงแก้ไขข้อมูลบางส่วน (แก้ไขข้อมูลบางส่วนของเว็บไซต์ที่ไม่ใช่การ block) ที่เป็นคำสั่งศาลด้วย!!

ผมเริ่มคิดว่าผมดำเนินการสายเกินไปแล้วครับ Internet ประเทศไทยกู่กลับได้ยากมากแล้ว

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

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

สรุปว่ามีอีกปัญหา ซึ่งเชื่อว่าต้นเหตุเกิดจากความไม่เข้าใจของผู้มีอำนาจนะครับ
(ใช้อำนาจโดยไม่เข้าใจว่ามันจะส่งผลอย่างไร)

By: gotobanana
iPhoneAndroidBlackberrySymbian
on 13 May 2013 - 21:30 #572677
gotobanana's picture

อ่านแล้วงงนะคับ

By: ordinaryone
AndroidRed HatWindows
on 16 May 2013 - 21:48 #574140 Reply to:572677

ขออภัยครับ จริงๆ แล้วอยากเขียนให้อ่านง่ายอยู่เหมือนกัน
แต่ว่า ข่าวนี้ผมเน้นคนอ่านอีกกลุ่มครับ
เหมือนข่าวที่แล้ว ก็มีคนบ่นว่าผมยกตัวอย่างอ้อมโลกเกินไปเช่นกันครับ

อ่านไม่ค่อยรู้เรื่องก็ไม่เป็นไรนะ ขอเพียงเข้าใจว่ามีใครสักคนกำลังทำอะไรบางอย่าง เพื่อ Internet อยู่ก็พอแล้วครับ

ถ้าอยากอ่านรู้เรื่องจริงๆ ผมแนะนำว่าให้ลองเขียน HTTP proxy ง่ายๆ ขึ้นมาสักตัวครับ ถ้าเข้าใจหลักการนั้น จะเข้าใจเรื่องที่ผมเขียนขึ้นทั้งหมดครับ

By: SuperBancha
Android
on 14 May 2013 - 02:53 #572798
SuperBancha's picture

เรื่อง Block หรือ Spoof แบบเถื่อนๆ ใต้ดินนี่ สุดท้ายเขาก็ทำกันอยู่ดี อ้างเหตุผลกันคำเดียวว่า "เพื่อความมั่นคง"

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

แต่ก็นั่นแหละ ต้องทำเป็นว่าไม่รู้ หรือไม่มีเรื่องแบบนี้

แต่ผมก็สนับสนุนแนวคิดนะครับ อย่า Block หรือ Spoof อะไรกันมากนักเลย แค่นี้ internet ที่ใช้ ก็ประหลาดเพียงพออยู่แล้ว

ปล. ที่จริงผมก็สงสัยมานานแล้วว่า ยังไงคนที่เขาเกี่ยวข้องกับเรื่องแบบนี้ เขาต้องมี "อะไร" กันอยู่ที่ International Gateway แน่ๆ (เป็นผมมีหน้าที่ทำนองนี้ ผมก็ต้องทำ) แล้วก็แน่ใจ เมื่อเห็น youtube มีอาการแปลกๆ แล้วก็มีกรณีที่ช่วงแรกๆ ที่คนไทยเริ่มเล่น facebook กันเยอะขึ้น แล้วมีประเด็นโน่นนี่ (ส่วนมากก็เรื่องความมั่นคงทั้งหลายนั่นแหละ) จากนั้น facebook ก็มีอาการ "ช้า" อยู่ตั้งนาน ผมยังบอกเพื่อนๆเลยว่า ให้เขาติดตั้ง "ระบบ" ให้เสร็จก่อน เดี๋ยวก็เร็วเองแหละ

By: eol
Android
on 15 May 2013 - 15:28 #573430
eol's picture

เรื่อง Speedtest ผมมองว่า วัดเป็น Mbps แบบปกติก็ common sense สุดแล้วครับ เพิ่มตัวแปรอื่นขึ้นมาผมว่ามันจะปวดหัวปล่าวๆ (อย่างน้อยเราก็สามารถดูค่าคู่สายที่ router ได้เบื้องต้นอยู่แล้ว แต่คนทั่วไปเค้าจะดูไม่เป็นกัน 555+)

By: ordinaryone
AndroidRed HatWindows
on 16 May 2013 - 22:39 #574180 Reply to:573430

เรื่องค่านั้นแหละครับ ที่เป็นปัญหา
ถ้าเอาค่านั้นมาวัดกัน แล้วผมเป็น ISP แล้วอยากขึ้นค่านั้นออกโฆษณา
สรุปว่าผม เพิ่มโครงข่าย (bandwidth) ในประเทศก็พอ เรื่อง up link ออกนอกประเทศ จะเป็นยังไงก็ไม่สน เพราะมันเอาไปโฆษณาไม่ได้ <- ใช่หรือเปล่า?

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