Wireshark – חזרה לעקרונות דוגמא ל- TCP Connection עם בקשות HTTP

מבוא:

במאמרים הקודמים דיברתי בעיקר על כלים מעניינים, על בעיות טיפוסיות, וקצת תעל פרוטוקולים. במאמר זה אחזור קצת לבסיס, ונראה דוגמא פשוטה מאוד של עבודה של HTTP מעל TCP, ב- TCP Connection קצר, ונראה לאילו דברים יש לשים לב. בהמשך אביא כמובן דוגמאות מורכבות יותר.

איך זה עובד:

אז קודם כל בואו נראה תמונה כללית של ה- TCP Stream שעליו נדבר. תפתחו את הקובץ ונתחיל לעבוד עליו.

בשלב הראשון (1) נפתח ה- Connection, בשלב השני (2) ניתנת בקשת HTTP GET ראשונה, מידע עובר, ונשלח HTTP OK, ובשלב השלישי (3) נשלחת בקשת HTTP GET  שניה ואחרי מספר Packets  מתקבל HTTP OK.

הקמת ה- Connection:

קודם כל, יש לנו את פתיחת ה- TCP Connection ב- Packets 1-2-3:

  • ב- Packet 1 נשלח SYN – בקשה לפתיחת Connection מיוזם התקשורת, בדוגמא – 180.72.131
  • ב- Packet 2 מתקבלת תשובת SYN-ACK – אישור על הבקשה לפתיחת ה- Connection – בדוגמא 188.165.249
  • ב- Packet 3 מתקבל ACK – אישור שמתחילים לדבר – בדוגמא – יוזם הקשר 180.72.131 מודיע שמתחילים לדבר.

בהקמת ה- Connection נקבעים גם:

  • ה- Sequence number ההתחלתי של שני הצדדים. ברירת המחדל של Wireshark היא נירמול ל- 0, כלומר איפוס ה- Sequence numbers האמיתיים, והתחלה מ-0. אפשר להציג את המספרים האמיתיים בשינוי הגדרת Relative Sequence Numbers תחת הגדרות TCP ב- Preferences.
  • גודל החלון – ה- Buffer שכל אחד מהצדדים מקצה לתהליך. כל אחד מהצדדים יכול לשנות את ה- Buffer במהלך ה- Connection, מה שישפיע על מהירות העבודה.

בקשת HTTP  ראשונה (Packets 4-11)

ב- Packet 4 אנחנו רואים בקשת HTTP GET. בואו נראה מה רואים כאן.

מה שאנחנו רואים זה:

  • את סוג הבקשה (HTTP GET), לאיזה URI פנינו ולאיזה קובץ (adsWrapper.js) ומכאן אנחנו גם יודעים שהבאנו אלינו Java Script. איך אנחנו יודעים מה זה וגם מורידים את הקובץ אלינו, עוד מעט נראה.
  • הרשת שאליו פנינו – atwola.com. חיפוש קצר ב- Google יראה לנו מה הקובץ, במקרה הזה חוסם פרסומות.
  • אנחנו גם רואים שזאת בקשה 1 מתוך 2 (HTTP request 1/2), שהתשובה עליה תהיה ב- Packet 11 ושב- Packet 13 תהיה בקשה נוספת.

אם נרצה לראות את הקבצים עצמם, אפשר להשתמש בתפריט FileàExport ObjectsàHTTP, לשמור את הקבצים, לפתוח אותם ב- Editor  ולראות במה מדובר.

בקשת HTTP  שניה (Packets 4-11)

בבקשה השנייה, Packet 13 עם בקשת HTTP GET עד Packet 20  עם קבלת ה- 200 OK (200 זה קוד תשובה שאומר OK), אנחנו מקבלים את אותה הבקשה לאותו הקובץ, וגם מקבלים את הקובץ שוב. אנחנו גם רואים שהזמן בין קבלת התשובה על הבקשה הראשונה (Packet 4)  לבקשה השנייה (Packet 13)  הוא כ- 15 שניות, וזאת כנראה הסיבה לבקשה החוזרת. Google קצר על שם הקובץ יגלה לכם על מה מדובר, אבל לא ניכנס לזה כי הנושא שלנו הוא תקשורת ולא HTTP.

קצת על ביצועים ב- TCP

אם נסתכל לדוגמא על Packet 11, מה אנחנו נראה שם (ב- TCP)

ומה שכדאי לשים לב אליו זה:

  • כאן אנחנו רואים את גודל ה- Buffer שכל צד מקצה ל- TCP Connections. כאן אנחנו רואים שת זה ש- 188.165.249  מפרסם, אבל הוא זה ששולח את המידע, אז כדאי לראות אם גודל החלון מספיק בצד המקבל. כתבתי על זה במאמרים קודמים.
  • כאן רואים את ה- iRTT שהוא ה- Initial RTT (זמן בין SEC/ACK) ראשוני שנקבע עם הקמת ה- Connection. זמן יש יכול להשתנות במהלך התקשורת, ונובע ממספר גורמים שגם פורטו במאמרים קודמים. השדה שנקרא Bytes in Flight אומר מה מספר בה- Bytes ששודרו על ידי צד זה, ועדיים לא התקבל עליהם ACK. כמובן שעלייה, גם הדרגתית, בשדה זה אומרת שהשולח "חנוק" בגלל שרת/מחשב איטי או אפליקציה לא יעילה. אנחנו רואים כאן גם את מספר ה- Bytes שנשלחו מאז ה- Push Flag האחרון, כלומר Bytes הנמצאים עדיין ב- Buffer  של המקבל.
  • ואחרון כאן אנחנו רואים את הזמן מה- Packet הראשון ב- TCP Connection ובין ה- Packet הקודם. במאמרים הבאים ניכנס לזה יותר לעומק.

הערה: מה שאנחנו רואים בסוגריים מרובעים [] אומר שזאת אנליזה של התוכנה ולא מידע אמיתי שעובר בתוך ה- Packet.

במאמר הבא אדבר על ניתוח ביצועים של אפליקציות, ונראה Plugin נחמד וגם אתן כמה טיפים לנושא.

TCP PDUs מול Ethernet Frames

דבר אחרון למאמר קצר זה, זה נושא ה- TCP PDU Reassembly. אם תסתכלו בתמונה הבאה, נראה הודעה של Wireshark שנקראת TCP Segment of reassembled PDU.

ב- Packet 11, שהוא ה- Packet האחרון של הבקשה הראשונה, אנחנו רואים כי חמישה Frames מרכיבים את התשובה – Frames 5, 7, 8, 10, 11.

מה אנחנו רואים כאן – מכיוון שגודל של Ethernet Frame  המקסימלי הוא 1518Bytes כולל Headers (לא כולל Tagging  במידה ויש), ו- TCP PDU יכול להיות בגודל של עד 64KByets, מה שאנחנו רואים כאן זאת חלוקה של TCP PDU  באורך 6750Bytes   ל- 5 Ethernet Frames. בחישובי ביצועים של TCP, יש להכניס בחשבון את ה- TCP PDU  המקורי, כי זה מה שה- TCP  רואה. כמובן שיש כאן השפעות בין רמה 2 (Ethernet), רמה 3 (IP) ורמה 4 (TCP), ואדבר על זה בהמשך.

קצת על HTTP

אם נתסכל בתוך ה- HTTP, נוכל לראות גם דברים מעניינים.

אנחנו רואים למשל כי כמות המידע שהועבר ב- HTTP הוא 6592 Bytes (1), את הזמן מקבלת הבקשה (2), כאשר מכיוון שכאן זה סיום התשובה אז קיבלנו את מהירות התגובה לבקשה ונשאר רק לראות אם הייתה איטיות ממה היא נובעת (במאמרים הבאים..), וגם מידע על הבקשות והתשובות (3).

מקווה שעזרתי ואשמח לענות לכל שאלה או בעייה.