หนึ่งภาพสามารถแทนความหมายมากมาย ภาพที่เกิดจากการ monitor อุปกรณ์ network ก็ทำได้ในแนวเดียวกัน ^^
ภาพที่อยู่ด้านล่างเป็น graph ที่เกิดจากการ “ping” ไปที่ปลายทาง “แค่นั้น” แต่ความหมายที่แสดงอยู่มีค่ามากกว่านั้น ยกตัวอย่างที่เห็นจากภาพไม่ต้องคิดเลยก็มีประมาณนี้
1. ค่าเฉลี่ยของการตอบสนอง ping ไปที่ปลายทางคือ 30 ms.
2. มีบางช่วงที่ ping ไปที่ปลายทางไม่ได้
3. link ที่ใช้ไม่ค่อยจะเสถียรเท่าไร แต่ยอมรับได้
4. ต้องไปมีใครสักคนเปลี่ยนอะไรสักอย่างในช่วง week 20 – week 30
แล้วกราฟนี้มาจากไหน??
ตามหัวข้อ IP SLA เลยกราฟนี้มากจากการใช้ IP SLA command บน Catalyst 3750X ทำการส่งคำสั่ง ping ไปที่ปลายทางที่ต่างประเทศผ่าน internet ส่วน command ก็ประมาณนี้
เท่านี้ L3 ของเราก็จะ ping ไปที่ IP Y.Y.Y.Y แล้วก็เอามาพล็อตกราฟก็จบ แต่ประโยชน์ของมันไม่ได้มีแค่นั้นถ้าเรารู้เบื้องหลังและที่มาก็จะได้ข้อมูลเพื่อเอามาใช้ประโยชน์ได้อีกประมาณนี้
1. เนื่องจากการต่อใช้งาน internet แบบ BGP multihome ทำให้รู้ว่า Best path ไปที่ปลายทาง Y.Y.Y.Y ของ ISP1 แย่กว่า ISP2 จากกราฟในช่วงที่ใช้ ISP1 ทำงานเป็น default route ในหมายเลข 1 และ 4 มี respond time ที่เกิดจากการ ping สูงกว่าเมื่อช่วงที่ ISP2 ทำงานแทนในหมายเลข 3
2. ในช่วงหมายเลข 2 อาจจะมีการ cutoff ระบบแล้วเกิดปัญหากับ ISP1 ทำให้ ISP1 ไม่สามารถทำงานได้แต่ BGP ยังคงทำงานเมื่อ on ระบบขึ้นมาหลังจากทำงานเสร็จแล้ว ISP2 สามารถใช้งานได้ทำให้อุปกรณ์ใน site สามารถใช้งานได้เป็นปกติ
3. ในช่วงที่ ISP2 ทำงานพบว่า respond time ไปที่ IP Y.Y.Y.Y ต่ำกว่าตอนที่ ISP1 ทำงานแสดงว่า ISP2 มี Best path ไปที่ IP Y.Y.Y.Y ดีกว่า ISP1 จุดนี้สามารถนำไปทำ Optimize route ต่อได้อีก
4. เมื่ออุปกรณ์ของ ISP1 กลัมาทำงานได้เป็นปกติ Respond time ของ IP Y.Y.Y.Y กลับมาอยู่ที่ค่าเฉลี่ยประมาณ 70 ms เท่าเดิมแสดงว่าสำหรับ IP ปลายทางนี้ ISP2 มี best path ดีกว่า ISP1 แน่นอน
5. ถ้าลองตรวจสอบย้อนกลับไปที่ช่วงเวลา week ที่ 20 จะพบว่ามีการเปลี่ยนแปลงระบบทำให้สามารถ focus ความผิดพลาดที่เกิดขึ้นได้ว่าพอจะมาจากสาเหตุอะไรกันแน่ได้แม่นยำขึ้น
6. อันนี้ไม่ได้ใส่รูป graph ของ IP ปลายทางตัวอื่นแต่จะพบว่าถึงแม้ ISP2 จะทำงานแต่ Respond time ของ IP ปลายทางอื่นๆยังเท่าเดิมแสดงว่าไปทำการ optimize route แค่ชุดเดียวก็พอ
จะเห็นได้ว่าแค่การ ping ก็สามารถบอกข้อมูลได้เยอะแล้วดังนั้นใครที่ยังไม่ได้ทำระบบ monitor ก็ไปทำเพิ่มซะหน่อยดีกว่าปล่อยให้ระบบ network เป็น black box เวลามีปัญหาก็แก้ไขอะไรไม่ได้ จะเริ่มตรงไหนก็ไม่ถูก เมื่อตอบปัญหาไม่ได้ก็ต้องตกเป็นจำเลยของชาวบ้านเขาเรื่อยไป 😛
ผมคิดว่าเพื่อนๆที่ทำงานตำแหน่ง Network admin หรือ System admin ในบริษัทหลายท่านอาจจะมีความรู้สึกว่า “User ของท่านหลายๆคนจะรู้ว่าจะรบบที่ทำงานอยู่นั้นมีปัญหาได้เร็วกว่าคนที่ทำงานด้าน Network หรือ System ที่ดูแลระบบด้านนั้นๆอยู่เสมอ” ไม่ว่าจะเป็นเรื่องการใช้งานระบบ Database หรือการใช้งาน Internet จนทำให้เวลาที่ระบบมีปัญหาเรามาักจะใช้ “User เป็น Alert system ได้ดีกว่า” การเปิดหน้าจอโปรแกรม System monitor เพื่อดูสถานะของระบบไว้ซะอีก 🙂
ทำไม User จึงสามารถรับรู้ว่าระบบนั้นๆมีปัญหาได้เร็วกว่าเรา? ผู้ดูแลระบบหลายคนก็อาจจะคิดเช่นนั้น รวมทั้งผมเองในช่วงแรกๆ 🙂 แต่เมื่อมองถึงการใช้งานของ User ในด้านที่แตกต่างๆจากผู้ดูแลระบบก็จะพบว่าการที่ User นั้นรับรู้ปัญหาที่เกิดขึ้นได้เร็วกว่าเราก็คือ “พฤติกรรมการใช้งาน” ที่มีมากกว่าเรานั่นเอง เช่น ฝ่ายบัญชีมักจะมีการเรียกข้อมูลหรือเพิ่มข้อมูลลงไปที่ Database บ่อยๆ หรือกำลังดู Youtube อยู่แล้วภาพกระตุก 😛 ในขณที่เราอาจจะพิมพ์ Word อยู่ก็เป็นด้ายยยยย!!! จากพฤติกรรมการใช้งานที่เกี่ยวข้องกับระบบ Network นี้เองทำให้ User รับรู้ได้ถึงการเปลี่ยนแปลงบางอย่างที่เปลี่ยนแปลงไปจากเดิม ความแตกต่างที่ User สามารถรับรู้ได้นั้นจึงเป็นที่มาของการแจ้งความผิดปกติเข้ามาที่ผู้ดูแลระบบอย่างเราๆนั่นเอง
เมื่อเข้าใจถึงพฤติกรรมที่เกิดขึ้นดังนั้นผู้ผลิตอุปกรณ์หลายรายจึงได้ทำการพัฒนา Feature บนอุปกรณ์ขึ้นมาเพื่อให้ผู้ดูแลระบบมาไปใช้งานเพื่อนำค่าที่ได้มาเปรียบเทียบว่าทีอะไรเกิดขึ้นในระบบ Network บ้าง เช่น
ซึ่ง Feature ที่ได้กล่าวถึงไว้ที่ด้านบนจะทำหน้าที่เป็นตัว “สร้าง Traffic” การใช้งานระบบ Network แทน User นั่งเอง โดยเรามาสามารถกำหนดให้อุปกรณ์ทำการตรวจสอบ(หรือใช้งานระบบ) Network เป็นช่างเวลา หรือตรวจสอบการใช้งานตลอดเวลาก็ได้ในกรณีที่เราต้องการนำมาใช้งานเป็นระบบ Real-time monitor
ประโยชน์ของการนำ Feature เช่น IP SLA มาใช้งานเป็นระบบ Real-time monitor คือ Network หรือ System admin จะได้ทราบถึงพฤติกรรมบนระบบที่เกิดขึ้นและเปลี่ยนแปลงไปในช่วงเวลาต่างๆ ซึ่งการใช้งานระบบ Network monitor ทั่วไปที่ให้แต่ผลการใช้งานแค่เรื่อง Traffic (Bandwidth) ที่เกิดขึ้นในระบบทั่วๆไปไม่สามารถให้คำตอบได้ เช่น
1.การตอบสนองการ Query ของ DNS server ว่ามีการตอบสนองการ Query ได้เร็วหรือช้าเป็นเวลาเท่าใด
2.การตอบสนองของ WAN ที่เชื่อมต่อระหว่างสาขานั้นมีค่า Round Trip Time(RTT) ใน WAN เส้นนั้นๆเป็นเวลาเท่าใด
3. การตอบสนองของ Service port บน Server ที่เปิดใช้งานบน Server เครื่องหนึ่งนั้นมีค่าเป็นเท่าใด
4. ค่าเวลาตอบสนองในการทดสอบการ Download ไฟล์จาก FTP server มีค่าเป็นเท่าใด
5. การใช้งาน Web site หนึ่งมีค่าตอบสนองของ TCP/DNS/HTTP เพื่อทำให้โหลดข้อมูลหน้านั้นๆขึ้นมาได้มีค่าเป็นเท่าไร
จากตัวอย่างที่กล่าวมาด้านบนทั้ง 5 แบบเป็นข้อมูลที่ผู้ดูและระบบส่วนใหญ่ต้องการทราบเพื่อนำไปตรวจสอบความผิดปกติหรือทำให้ทราบถึงพฤติกรรมการใช้งานเชิงลึกในระบบ Network ได้มากขึ้นเพื่อให้สามารถนำไปปรับปรุงหรือตรวจสอบการใช้งานที่ผิดปกติได้นั่นเอง
ผมขอยกตัวอย่างสำหรับการนำใช้งานข้อมูลไปใช้งานในบางกรณีดังนี้
ระบบ Internet มีปัญหาในช่วงเวลา 9.30น. ทำให้ User ใช้งาน Internet ไม่ได้ ต่อมา Internet กลับมาใช้งานได้ในช่วงเวลา 9.35น. ในช่วงเวลาที่เหลื่อมกันนั้นเวลา 9.34น. Network admin ได้โทรไปที่ ISP ให้ทำการตรวจสอบ Internet ต้องรอสายจนเวลา 9.36น.จึงจะได้คุยกับ Engineer ของ ISP และ Engineer ได้ขอผล Ping และ Traceroute ไปเพื่อนำไปตรวจสอบ Network admin จึงได้ส่งผลไปให้แต่เป็นผลการ Ping และ Traceroute ที่เวลา 9.37น.
กรณีที่ 1 ไม่มี Proactive monitor: จากช่วงเวลาด้านบน เมื่อส่งผล Ping/Traceroute ไปให้ Engineer ของ ISP ตรวจสอบก็จะพบว่าไม่มีความผิดปกติเกิดขึ้นในการเชื่อมต่อ Internet และเมื่อใช้โปรแกรม Monitor ทั่วไปดูจะพบว่ามี Bandwidth ที่ Interface จากมี Traffic เกิดขึ้นที่ Interface ที่เชื่อมต่อกับ Router ของ ISP ซึ่งอาจจะมีข้อมูลหากันตามปกติ เช่น Routing protocol หรือ L2 protocol อื่นๆ
กรณีที่ 2 มี Proactive monitor: เราจะมีผลการเชื่อต่อของ WAN-to-WAN, การตอบสนองของ Web site ปลายทาง หรือเวลาในการตอบสนองของ DNS server แล้วส่งเป็นกราฟไปให้ ISP ดูซึ่งจำทำให้เกิดความชัดเจนมากกว่าเพราะการทำ Real-time monitor จะต้องมีการเก็บข้อมูลไว้เป็น History ในระดับชั่วโมง วัน เดือน และปี ดังนั้นการที่เราเห็นความผิดปกติที่เกิดขึ้นจะทำให้เรามองเห็นปัญหาได้ชัดเจนและรวดเร็วขึ้นได้เป็นอย่างมาก
จากการแนะนำ Feature pro-active monitor และตัวอย่างการนำไปใช้งานในบทความนี้หวังว่าจะทำให้เพื่อนๆหลานคนได้ Idea ในการทำ Pro-active monitor ไว้ใช้งานในบริษัทของตัวเองกันมากขึ้น เพื่อใช้ในการตรวจสอบและใช้ในการประกอบการวิเคราะห์ปัญหาที่เกิดขึ้นกันได้นะครับ 🙂
ลองหาข้อมูลเพิ่มเติมเกี่ยวกับ Cisco IP SLA เพื่อใช้งานต่อได้ที่
http://www.bloggang.com/mainblog.php?id=likecisco&month=09-07-2015&group=3&gblog=50
http://www.cisco.com/c/en/us/td/docs/ios/12_4/ip_sla/configuration/guide/hsla_c/hsoverv.html
ปล. รูปตัวอย่างในบทความมากจาก Cacti โดยใช้ Template ที่ Modify ใหม่เองครับ เพื่อนๆที่สนใจสามารถหา Software อื่นๆมาใช้งานได้เองเช่นเดียวกันนะครับ 🙂
หมายเหตู: การทำ Pro-active monitor ไม่สามารถตอบคำถามทุกอย่างที่เกิดขึ้นได้ จะต้องมีการทำงานที่เกี่ยวข้องกับ Resource monitor อื่นๆด้วยเพื่อทำให้การวิเคราห์ปัญหาทำได้สะดวกและชัดเจนมากขึ้นด้วย การใช้เครื่องที่ดีตัวหนึ่ง อาจจะไม่ได้เหมาะสมกับทุกปัญหาที่เกิดขึ้นครับ
Network engineer หลายๆท่านน่าจะเคยประสบปัญหาต่างๆดังนี้มาก่อน
ปัญหาหาที่เกิดขึ้นนี้อาจจะแก้ได้หลาก เช่น การเช่า Rack ต่างจากประเทศเพื่อใช้ทดลอง Lab หรือซื้ออุปกรณ์จริงมาลองใช้งาน แต่สิ่งที่จะกระทบต่อการแก้ปัญหาเหล่านี้คือ “การลงทุน” ซึ่งอาจจะไม่คุ้มกับการลงทุนก็ได้ เนื่องจากอุปกรณ์ที่ต้องการมีราคาสูงเกินไป หรือบริษัทไม่มีนโยบายสนับสนุนตัวอย่างคือ บริษัทขายอุปกรณ์ยี่ห้อ “J” แต่งานติดตั้งจะต้องนำไปใช้งานกับอุกรณ์ “C”
ทางออกสำหรับ Network engineer หลายๆท่านก็จะหันไปใช้งาน Emulator อย่าง GNS3 นำมาจำลองระบบเพื่อจำลองให้มีการทำงานใกล้เคียงกับระบบที่เราจะต้องไปทำงานด้วย การใช้งานก็สะดวกสบายเพราะมี GNS3 appliance ที่สามารถโหลดมาใช้งานได้อย่างง่ายดาย ซึ่งก็จะสามารถนำมาใช้แก้ปัญหาในการทำงานได้ส่วนหนึ่ง
แต่จะดีกว่าไหมถ้ามี Emulator ตัวอื่นที่สามารถทำงานได้ในฟังก์ชั่นที่ทำงานได้เหมือนกันและดีกว่า นั่นคือการใช้งาน UnetLab แทนการใช้งาน GNS3 เพียงอย่างเดียว โดยการใช้งาน UnetLab จะมีข้อดีที่เหนือกว่า GNS3 ในบางส่วนดังนี้
เมื่อเทียบกับ GNS3
จุดเด่นของ UnetLab
ทำไมต้องมาเรียน UnetLab กับเรา
จากตัวอย่างแนะนำมาข้างต้นผู้ที่สนใจ Workshop สามารถสมัครเรียน Workshop ได้ครับ
ค่าใช้จ่ายในการเรียน 2,000 บาท (1 วัน)
สิ่งที่จะได้รับในการเรียน: UnetLab VM พร้อมใช้งานที่มี Free image นำกลับไปใช้งานต่อได้ทันที
กรณีที่มีความสนใจ Workshop นี้สามารถติดต่อสอบถามได้ที่ Email: info@virtualnetsystems.com
Wireshark for network troubleshooting เป็นหัวข้อ Workshop ที่คิดขึ้นเพื่อให้ผู้เรียนที่เป็นผู้ดูและระบบ Network ให้มีความเข้าใจในการทำงานของพื้นฐานการทำงานของระบบ Network โดยใช้รูปแบบการทำงานของ Protocol TCP มาอธิบายให้เห็นว่าในระหว่างการทำงานในระบบ Network ถ้ามีปัญหาเกิดขึ้นกับส่วนใดในการสื่อสารแบบ TCP จะมีปัญหาอย่างไรเกิดขึ้น และจะนำไปสู่การวิเคราะห์ปัญหาที่เกิดขึ้นในลักษณะต่างๆต่อไปได้อย่างเป็นรูปธรรม
Workshop จะเน้นให้ลงมือทำโดยเนื้อหาจะถูกแบ่งออกเป็น 3 ส่วนที่สำคัญคือ
Workshop ทั้ง 3 ส่วนจะใช้เวลาทั้งหมด 2 วันเพื่อให้ผู้เรียนได้ทำความเข้าใจการนำโปรแกรม Wireshark ไปใช้งานได้อย่างมีประสิทธิภาพ เนื้อหาทั้งหมดได้ผ่านกระบวนการคิดทดสอบและลงมือทำผ่านโปรแกรมอย่าง EVE-NG จากผู้สอนก่อนที่จะลงมือทำเอกสารทุกขั้นตอน เพื่อให้แน่ใจว่าผู้เรียนจะสามารถกลับไปทำการทดลองซ้ำต่อที่บ้านหรือบริษัทต่อไปได้ ทำให้มีความสะดวกในการทบทวนเนื้อหาที่ได้เรียนผ่านไป โดยสามารถทำการทดลองซ้ำตามเอกสารเพื่อให้เกิดความชำนาญจนสามารถนำไปประยุกต์ใช้งานได้อย่างสะดวกตามความต้องการต่อไป
สำหรับเนื้อหาการใช้งานโปรแกรม Wireshark ที่ผู้สอนได้มีการเผยแพร่เป็นวิทยาทานแก่ผู้สนใจได้ทำการอ่านและศึกษาได้ฟรีมีตามหัวข้อดังต่อไปนี้
จากตัวอย่างบทความที่แนะนำมาข้างต้นผู้ที่สนใจ Workshop สามารถใช้อ่านและพิจารณาเนื้อหาเบื้อต้นก่อนสมัครเรียน Workshop ได้ทันทีครับ
ค่าใช้จ่ายในการเรียน 5,000 บาท
สิ่งที่จะได้รับในการเรียน
หมายเหตุุ: เนื่องจากมีการใช้งาน EVE-NG ในการทดลอง ดังนั้นผู้เรียนจึงควรมี Notebook ที่มี Spec ขั้นต่ำดังนี้ เพื่อให้การทดลองได้ประโยชน์สูงสุด
1. CPU Intel core i3
2. Free space on HDD 80G (SSD for best performance)
3. RAM 8G
ระยะเวลาในการอบรม : จะแจ้งให้ทราบผ่านหน้าเพจอีกครั้ง
จำนวนผู้เข้าอบรม : สูงสุด 12 ท่าน
ค่าอบรม : ท่านละ 5,000 บาท
สถานที่อบรม : Comscicafe ติดสถานีรถไฟฟ้า BTS แบริ่ง (มีที่จอดรถให้ผู้เข้าอบรมทุกท่าน)
แผนที่ของ ComSci cafe ใน Google maps คลิกดู ที่นี่
กรณีที่มีความสนใจ Workshop นี้สามารถติดต่อสอบถามได้ที่ Email: info@virtualnetsystems.com หรือ Dowload รายละเอียดเพื่อนำเสนอหน่วยงานได้ ที่นี่
หลังจากเขียนเรื่องเกี่ยวกับ Wireshark มาระยะหนึ่งแล้วหลายๆท่านก็น่าจะได้แนวคิดในการใช้งานโปรแกรมนี้กันมากขึ้นกันแล้ว วันนี้ผมขอเสนอการเอาโปรแกรม Wireshark มาใช้วิเคราะห์ความผิดปกติของ Application ที่เกิดขึ้นโดยใช้งาน Feature IO graph เพื่อแสดงให้เห็นการทำงานที่ผิดปกติได้ชัดเจนและเป็นรูปธรมมมากขึ้น
วันนี้จะขอสมมติเหตการณ์ที่เกิดขึ้นใน Office แห่งหนึ่งซึ่งมีปัญหาการใช้งาน Application server ดังนี้
จากการตรวจสอบปัญหาของโปรแกรมเมอร์ที่เขียนโปรแกรม App 1 ที่ติดตั้งลงใน Application server 1 และ 2 รายงานว่าโปรแกรมไม่มีความผิดปกติใดๆ คาดว่าการที่ App 1 บน Application server 2 ใช้งานไม่ได้นั้นน่าจะเกิดจากการที่ ผู้ดูแลระบบ Network มีการทำ QoS ทำให้เมื่อมีการใช้เข้าใช้งาน Network ในช่วงเช้าที่มีปริมาณข้อมูลจำนวนมากทำให้ App 1 บน Application server 2 มีปัญหา
จากรายงานของโปรแกรมเมอร์ที่ได้ส่งไปให้หัวหน้าทีม Network ทำให้ Network engineer ทำการหาสาเหตุของปัญหาที่เกิดขึ้นโดยใช้โปรแกรม Wireshark เพื่อหาสาเหตุที่แท้จริงมารายงานต่อไป
ตอนนี้เราจะใช้ข้อมูลจากบทความตอนที่แล้วนำมาแยกเป็นชุดการสื่อสารแบบ Client-server มาแยกเป็นชุดไว้จะทำให้ได้ชุด Filter string ดังต่อไปนี้
แต่ก่อนที่จะทำการแยกแยะการใช้งานเป็นแบบ Client-server ให้ลองทำการพิจารณาภาพรวมการใช้งานระบบ Network ก่อนโดยใช้ Feature IO graph จะได้ผลดังนี้
ต่อมาลองดูภาพรวมของการเชื่อมต่อไปที่ Application server 2 จากเครื่อง Front end จะได้ดังนี้ (Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.2)
จากกราฟภาพรวมของระบบ Network ในรูปแรกและการเชื่อมต่อไปที่ Application server 2 ไม่พบการทำงานของการทำงานของ QoS ซึ่ง Throughput จะต้องมีลักษณะราบเรียบลงในส่วนที่ QoS ทำงานอยู่
ต่อมาลองพิจารณาการทำงานของ App 1 และ App 2 ที่อยู่ที่เครื่อง Application server 2 โดยใช้ Filter string ดังนี้
จากกราฟที่ได้จะพบว่าที่เครื่อง Application server 2 จะมีความผิดปกติที่ App 1 เท่านั้นซึ่งตรงกับที่ User A, C รายงาน
ต่อมาให้ทำการเปรียบเทียบการทำงานของ App 1 และ App 2 ที่ติดตั้งลงบนเครื่อง Application server 2 จะได้ผลดังนี้
จะเห็นได้อย่างชัดเจนว่า App 1 บน Application server 2 มีปัญหาเกิดขึ้นเพียง App เดียวจริง
เพื่อความแน่ใจลองตรวจสอบการทำงานของ App 1 ที่เครื่อง Application server 1 เพื่อลองหาความผิดปกติที่อาจจะเกิดขึ้้นด้วย Filter string: ip.addr==172.16.4.115 && ip.addr==192.168.1.9 && tcp.port==2074 จะได้ผลดังนี้
จากผลที่ได้จะตรงกับที่ User B รายงานว่าสามารถใช้งาน App 1 บนเครื่อง Application server 1 ได้อย่างปกติ
ต่อมาลองทำการเปรียบเทียบค่า Throughput ของ App 1 บน Application server 1 และ Application server 2 เพื่อหาความแตกต่างว่าถ้า QoS เป็นต้นเหตุของปัญหาค่า Throughput ของทั้ง 2 server ควรจะมีค่าที่ต่างกันมากจนทำให้ QoS ทำงานจนตัด Connection ของ Application server 2
จากกกราฟที่ได้แสดงให้เห็นว่า Throughput ของ App 1 บน Application server 1 และ Application server 2 มีค่าใกล้เคียงกันมากในช่วงเข้าจนกระทั่งช่วงเวลาประมาณ 9.30น. App 1 บน Application server 2 จึงเกิดปัญหาไม่สามารถใช้งานได้ และหลังจากที่ App 1 กลับมาใช้งานได้ค่า Throughput ของ App 1 ก็ยังมีค่าใกล้เคียงกันทั้ง 2 server (มีค่าต่างกันบ้างอาจจะเกี่ยวกับการดึงข้อมูล) ดังนั้นการที่กล่าวว่า QoS เป็นสาเหตุของปัญหาที่เกิดขึ้นจึงเป็นเรื่องที่ไม่เป็นความจริงและไม่มีหลักฐานใดที่ระบุได้ว่าระบบ Network มีปัญหาในช่วงเวลาดังกล่าว
และเมื่ออพิจารณาจากภาพรวมที่ได้จากระบบ Network ทั้งหมดจะเห็นได้อย่างชัดเจนว่าปัญหาที่เกิดขึ้นนั้นน่าจะเกิดจาก App 1 ที่มีการใช้งานระหว่างเครื่อง Frontend (172.16.4.115) และ Backend (192.168.1.2) มากกว่าจะมาจากระบบ Network
ผมหวังว่าบทความนี้น่าจะเป็นตัวอย่างการนำโปรแกรม Wireshark ไปประยุกต์ใช้งานให้กับหลายๆท่านได้ต่อไปนะครับ
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
ความเห็นล่าสุด