อาทิตย์นี้กลับมาในเรื่องของ WireShark อีกรอบครับ
วันนี้เสนอเรื่อง TCP zerowindow กับปัญหาที่เกิดขึ้นใน network ปัญหาที่เกี่ยวกับเรื่องของ TCP window size ที่เคยเห็นมาจะเป็นเรื่องที่ต้องเกี่ยวกับการรับส่งข้อมูลในปริมาณที่มากในระดับหนึ่งและข้อมูลที่ต้องการจะนำมาใช้มีความต่อเนื่องสม่ำเสมอไม่ขาดตอน ยกตัวอย่าง เช่น Video streaming หรือ Youtube ก็ได้
TCP window size คืออะไร
จากรูปด้านบนจะเห็นได้ว่าก่อนที่มะมีการส่ง Packet หากันระหว่า Client และ Server จะต้องมีการกำหนดขนาดของ Window size กันก่อน โดยจะเป็นการตกลงกันว่าจ Client จะรอรับข้อมูลเป็นปริมาณเท่าไรจึงจะทำการส่ง Packet ACK ให้กับ Server หนึ่งครั้ง การทำงานแบบนี้จะช่วยเพิ่มประสิทธิภาพของ Protocol TCP ได้เนื่องจากไม่ต้องทำการส่ง Packet ACK กลับไปทุกครั้งเมื่อได้รับ Packet เข้ามานั่นเอง
สำหรับอาการเมื่อเกิดขึ้นเมื่อมีปัญหาเกี่ยวกี่ยวกับ TCP zerowindow คือโปรแกรมจะค้าง เนื่องจากจะมีมีการส่ง Packet request ออกไปขอข้อมูลใหม่เข้ามา เมื่อไม่รับข้อมูลเข้ามา Client จะเกิดอาการค้างอยู่ในช่วงระยะเวลาหนึ่ง จนกระทั่ง Windos size จะกลับมาเป็นปรกติ จึงทำให้เกิดอาการ Video สะดุดนั่งเอง 🙂
คราวนี้เราจะมาลองสร้างกราฟเพื่อแสดงค่า TCP zerowindow เพื่อให้เข้าใจการเกิดปัญหาได้ดียิ่งขึ้น ก่อนอื่นก็เปิดโปรแกรมขึ้นมาก่อนตามรูปนี้
ขั้นตอนต่อไปเราจะมาทำการสร้างกราฟโดยใช้เมนู TCP stream graph กันก่อน โดยให้ไปที่เมนู Statistics > TCP StreamGraph > Window Scaling Graph โดยเมื่อ WireShark ทำการสร้างกราฟขึ้นมาจะได้หน้าตามแบบในรูปด้านล่างนี้
จากรูปในส่วนที่มีลูกศรสีแดงชี้ไว้อยู่คือตำแหน่งที่มีขนาดของ TCP windows เป็น 0 ดังนั้นจากรูปก็จะพอสรุปได้ว่า ในช่วงเวลาที่ทำการ Capture packet อยู่นั้นจะเกิดอาการ Video กระตุกอยู่ที่ 4 ครั้ง และการแสดงผลจะเป็นไปในลักษณะทิศทางเดียว คือ จาก Source IP ไปที่ Destination IP โดยสังเกตุได้จากกรอบสีแดงในรูปครับ แต่จะเห็นได้ว่าการใช้ TCP Stream Graph นั้นจะแสดงค่าได้ไม่สวยงามและไม่สามารถทำการขยายหรือปรับแต่งกราฟให้เข้าใจได้ง่ายขึ้นเลย ดังนั้นเราจะใช้เครื่องมือในอีกเมนูนึงคือ IO graph มาเพื่อช่วยให้การแสดงผลมีความยืดหยุ่นมากขึ้น
การใช้ IO graph ให้ไปที่เมนู Statistics > IO Graph ตามรูป
จากนั้นให้ทำการใส่ Filter “tcp.window_size” ลงในช่องที่ 2 และก่อนหน้าที่จะกดปุ่มกราฟให้ทำการปรับค่าเพิ่มอีก 2 ตัวเพื่อให้การแสดงผลมีรายละเอียดมากยิ่งขึ้น คือ ให้แสดงช่วงเวลาที่เราได้ทำการ Capture packet มาแสดงผลในกราฟ โดยให้ทำการเลือก “View as time of day” ตรงที่ลูกศรสีฟ้าชี้อยู่ ส่วนต่อมาให้ทำการปรับ Scale ของกราฟให้เป็นแบบ “Logarithm” โดยประโยชน์ของการใช้ Scale แบบ Logarithm นี้คือ ในกรณีที่ค่าที่ต้องการแสดงผลมีค่าที่ต่างกันมากอาจจะทำให้การแสดงผลขาดรายละเอียดได้ ในกรณีนี้ให้ทำการเลือกการแสดงผลในแกน Y โดยให้ทำการเปลี่ยนค่าตามในกรอบสี่เหลี่ยมสีแดง จากจั้นให้ทำการกดปุ่ม Graph 1 เพื่อเอาค่าข้อมูลของ Graph 1 ออกไปก่อน หลังจากนั้นทำการกดปุ่ม Graph 2 เพื่อทำการแสดงผลของ TCP window scale ที่เกิดขึ้นในในช่วงเวลาที่เราได้ทำการ Capture packet มาวิเคราะห์ โดยจะได้ผลตามรูปด้านล่างนี้
โดยในส่วนที่มำลูกศรชี้ลงให้คือส่วนที่เกิด TCP zerowindow และเมื่อสังเกตุในช่องสีฟ้าจะเห็นว่ามีเวลาขึ้นมาด้วยทำให้การวิเคราะห์ปัญหาที่เกี่ยวข้องกับระยะเวลาที่เกิดปัญหาทำได้สะดวกขึ้นด้วยนั่นเอง
หวังว่าจะได้ Idea เพื่อนะไปลองวิเคราะห์ปัญหาที่อาจจะเกิดขึ้นได้บ้างนะครับ 🙂
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
กลับมาเขียน Blog อีกครั้งในรอบหลายอาทิตย์แล้วครับ วันนี้ขอนำเสนอการใช้งาน WireShark เพื่อแสดงค่า TCP Delay ก็แล้วกันครับ
ปัญหาโลกแตกของคนที่ทำงานสาย Network อย่างหนึ่งที่ทุกคนต้องเจอก็คือคำถามนี้ครับ “ทำไม Network ช้า???” คำถามนี้จะมาจากทั้งฝั่งที่ดูแล Application หรือผู้ใช้งานทั่วไปใน Office ของเรานั่นเอง และคำถามนี้ก็เป็นปัญหาที่น่าหนักใจสำหรับคนที่ทำงาน Network อย่างเราๆเสมอมา เพราะการที่จะยืนยันได้ว่า Network หรืออะไรก็แล้วแต่ที่เกี่ยวข้องทั้งปัจจัยภายในและภายนอกในการหาต้นตอของปัญหาทาง Network หรือทุกปัญหาก็คือการหาหลักฐานว่าปัญหาเกิดจากอะไรนั่นก็คือ “หลักฐาน” นั่นเอง เมื่อไม่มีหลักฐานไปแสดงก็จะไม่มีทางรู้ได้เลยว่าปัญหาที่เกิดขึ้นนั้นมาจากอะไร และเมื่อขาดหลักฐานก็จะนำไปสู่การแก้ปัญหาที่ไม่ถูกจุดต่อไปนั่นเอง
เมื่อปัญหาเกี่ยวกับ Network ช้าและคนทำ Network ตกเป็นจำเลยของ Office ดังนั้นเราจะมาหาหลักฐานกันว่าสิ่งที่เขาบอกว่านั้นมันช้าจริงหรือเปล่า เมื่อพูดถึงการสื่อการบน Network แล้ว Protocol หนึ่งที่เรามีการใช้งานเป็นส่วนใหญ่จะเกี่ยวข้องกับโปรโตคอล TCP ดังนั้นในบทความนี้เราจะเสนอแนะวิธีการให้ WireShark แสดงผลของค่า TCP delay ออกมาเป็น Column หนึ่งการการแสดงผลเพื่อที่เราจะได้ทำการ Sort หาค่า Delay ที่เกิดจากโปรโตคอล TCP และนำมาหาความสัมพันธ์และอาจจะนำมาใช้วิเคราะห์และเป็นหลักฐานในการแก้ปัญหาต่อไปได้สะดวกขึ้น
ก่อนอื่นก็มาดูการทำงานของโปรโตคอล TCP แบบง่ายๆกันก่อน เริ่มจากช่วงแรกก่อนที่จะมีการเริ่มส่งข้อมมูลระหว่าง Client-Server นั้นจะต้องการเปิด Connection เพื่อทำการตกลงในการส่งข้อมูลกันก่อนนั่นคือ 3 ways handshaking กันก่อน คือ ช่วงสาม Packet แรกในรูปคือส่ง Packet Sync, Sync Ack, Ack ก่อนที่จะทำการ Established connection เพื่อทำการส่งข้อมูลกัน และเมื่อทำการ Established connection กันเรียบร้อยแล้วระหว่าง Client-Server จะเริ่มมีการส่งข้อมูลระหว่างกัน เมื่อมีการส่งข้อมูลกันจะเกิดเวลาช่วงหนึ่งระหว่างข้อมูล Packet แรกที่ส่งออกไปและมีการส่ง Packet ที่สองตามออกไป เวลาที่เกิดขึ้นในช่วงนี้คือ Delta “T” หรือระยะเวลาที่ Packet ที่สองห่างจาก Packet เป็นระยะเวลาเท่าไรนั่นก็คือค่า TCP delay ที่เกิดขึ้นนั่นเอง
ก่อนอื่นเลยให้ทำการ Capture packet และเปิดขึ้นมาโดยโปรแกรม WireShark แล้วไปที่ Column protocol จากนั้นหา TCP และทำการเลือกขึ้นมาหนึ่ง Packet จากนั้นเข้าไปที่ Packet detail pane และทำการเลือก “Transmission Control Protocol” ตามตัวเลข “1” จากนั้นเลือก “Protocol preferences” ตามหมายเลขที่ “2” และสุดท้ายเลือก “Calculate conversation timestamps” ตามหมายเลข “3”
เมื่อทำตามขั้นตอนชุดแรกนี้แล้วในช่องของ Packet detail pane จะมีค่า “Timestamps” ขึ้นมาตามตัวเลขที่ “4” จากนั้นให้ทำการขยายช่องของ “Timestamps” ออกมาจะเจอ “Time since previous frame in this TCP stream” ตามหมายเลขที่ “5” ให้ทำการคลิกขวาและเลือก “Apply as column” ตามหมายเลข “6”
จากนั้นเราจะได้ Column ใหม่ขึ้นมาให้ทำการ Rename เป็น Delta Time หรือชื่ออื่นที่ต้องการ เมื่อทำการสังเกตค่าที่แสดงผลใน Column นี้เราก็จะพบค่าเวลาที่แตกต่างกันไปตามรูปดังนี้
และจากข้อมูลตัวเลขที่แสดงออกมาจะทำให้เราเห็นว่าค่า Delay ที่เกิดจาก Packet ก่อนหน้านี้แสดงออกมามีค่าสูงบ้างต่ำบ้าง เช่น 0.000xxxxxx และ 15.00xxxxxxx ซึ่งแสดงว่าโดยปกติแล้วค่าการ Delay ที่เกิดขึ้นระหว่าง Client-Server อยู่ในระดับที่ปกติคือมีค่า Delay 0.000000000 เป็นส่วนใหญ่แต่จะมีค่า 15.00xxxxxxx อยู่เป็นระยะ ซึ่งเราก็จะสามารถนำค่า Delay ที่มีค่าสูงนี้ไปหาความสัมพันธ์เพื่อวิเคราะห์ปัญหาต่อไปได้นั่นเองครับ และนี่ก็คือตัวอย่างหนึ่งในการหาหลักฐานว่า Network ที่เราดูแลอยู่นั้น “ช้า” จริงหรือไม่อย่างหนึ่งนั่นเอง
ถ้าอ่านแล้วถูกใจอยากมาลองเรียนเพิ่มเติมกับเราตั้งแต่พื้นฐานจนทำให้ได้ผลลัพธ์ออกมาเป็นรูปร่างได้เหมือนในบทความและยังสามารถนำความรู้ไปต่อยอดได้ ลองมาเรียนกับเราได้โดยดูรายละเอียดได้ ที่นี่ นะครับ ^^
ความเห็นล่าสุด