git clone git://bpf.tcpdump.org/tcpdump

يحتوي هذا الدليل أيضاً على بعض برامج awk القصيرة المخصصة كأمثلة لطرق تقليل بيانات tcpdump عندما تتعقب مشاكل شبكة معينة:

send-ack.awk
	يبسط تتبع tcpdump لـ ftp (أو نقل tcp أحادي الاتجاه آخر). نظراً لأننا نفترض أن مضيفاً واحداً فقط يرسل والآخر يستقبل فقط إقرارات (acks)، يتم حذف جميع معلومات العنوان ونلاحظ فقط إذا كانت الحزمة "إرسال" (send) أو "إقرار" (ack).

	يوجد سطر إخراج واحد لكل سطر من التتبع الأصلي.
	الحقل 1 هو وقت الحزمة بالثواني العشرية، بالنسبة لبداية المحادثة. الحقل 2 هو الوقت التفاضلي من آخر حزمة. الحقل 3 هو نوع/اتجاه الحزمة.
	"Send" تعني بيانات تنتقل من المرسل إلى المستقبل، "ack" تعني إقراراً ينتقل من المستقبل إلى المرسل. تشير "*" السابقة إلى أن البيانات هي إعادة إرسال. تشير "-" السابقة إلى وجود فجوة في مساحة التسلسل (أي حزمة (حزم) مفقودة)، "#" تعني حزمة ذات حجم فردي (ليس الحجم الأقصى للقطعة). الحقل 4 يحتوي على علامات الحزمة (نفس تنسيق التتبع الخام). الحقل 5 هو رقم التسلسل (رقم التسلسل البداية للمرسل، رقم التسلسل المتوقع التالي للإقرارات). الرقم بين أقواس بعد الإقرار هو الوقت التفاضلي من أول إرسال للحزمة إلى الإقرار. الرقم بين أقواس بعد الإرسال هو الوقت التفاضلي من أول إرسال للحزمة إلى الإرسال الحالي (فقط على الحزم المكررة). الإرسالات أو الإقرارات المكررة لها رقم بين قوسين مربعين يوضح عدد التكرارات حتى الآن.

	هذا مثال قصير من قرب بداية ftp:
		3.00    0.20   send . 512
		3.20    0.20    ack . 1024  (0.20)
		3.20    0.00   send P 1024
		3.40    0.20    ack . 1536  (0.20)
		3.80    0.40 * send . 0  (3.80) [2]
		3.82    0.02 *  ack . 1536  (0.62) [2]
	بعد ثلاث ثوان من بدء المحادثة، تم إرسال البايتات من 512 إلى 1023. بعد 200 مللي ثانية تم إقرارها. بعد ذلك بوقت قصير تم إرسال البايتات 1024-1535 وإقرارها مرة أخرى بعد 200 مللي ثانية.
	ثم، بدون سبب واضح، تم إعادة إرسال 0-511، بعد 3.8 ثانية من إرسالها الأولي (زمن الرحلة ذهاباً وإياباً لهذا ftp كان 1 ثانية، +-500 مللي ثانية). نظراً لأن المستقبل يتوقع 1536، يتم إعادة إقرار 1536 عند وصول 0.

packetdat.awk
	يحسب بيانات ملخص القطعة (chunk) لـ ftp (أو نقل tcp أحادي الاتجاه مشابه). [تشير "قطعة" إلى قطعة من مساحة التسلسل -- بشكل أساسي رقم تسلسل الحزمة مقسوماً على الحجم الأقصى للقطعة.]

	يتم طباعة سطر ملخص يوضح عدد القطع، عدد الحزم التي استغرقتها لإرسال هذا العدد من القطع (إذا لم تكن هناك حزم مفقودة أو مكررة، يجب أن يساوي عدد الحزم عدد القطع) وعدد الإقرارات.

	بعد سطر الملخص يوجد سطر معلومات واحد لكل قطعة. يحتوي السطر على ثمانية حقول:
	   1 - رقم القطعة
	   2 - رقم التسلسل البداية لهذه القطعة
	   3 - وقت الإرسال الأول
	   4 - وقت الإرسال الأخير
	   5 - وقت الإقرار الأول
	   6 - وقت الإقرار الأخير
	   7 - عدد مرات إرسال القطعة
	   8 - عدد مرات إقرار القطعة
	(جميع الأوقات بالثواني العشرية، بالنسبة لبداية المحادثة.)

	كمثال، هذا هو الجزء الأول من الإخراج لتتبع ftp:

	# 134 chunks.  536 packets sent.  508 acks.
	1       1       0.00    5.80    0.20    0.20    4       1
	2       513     0.28    6.20    0.40    0.40    4       1
	3       1025    1.16    6.32    1.20    1.20    4       1
	4       1561    1.86    15.00   2.00    2.00    6       1
	5       2049    2.16    15.44   2.20    2.20    5       1
	6       2585    2.64    16.44   2.80    2.80    5       1
	7       3073    3.00    16.66   3.20    3.20    4       1
	8       3609    3.20    17.24   3.40    5.82    4       11
	9       4097    6.02    6.58    6.20    6.80    2       5

	هذا يعني أنه تم نقل 134 قطعة (حوالي 70 كيلوبايت لأن متوسط حجم الحزمة كان 512 بايت). استغرق نقل البيانات 536 حزمة (أي في المتوسط تم إرسال كل قطعة أربع مرات). بالنظر إلى، على سبيل المثال، القطعة 4، نرى أنها تمثل 512 بايت من مساحة التسلسل من 1561 إلى 2048. تم إرسالها أولاً بعد 1.86 ثانية من بدء المحادثة. تم إرسالها آخر مرة بعد 15 ثانية من بدء المحادثة وتم إرسالها إجمالاً 6 مرات (أي تم إعادة إرسالها كل 2 ثانية في المتوسط). تم إقرارها مرة واحدة، بعد 140 مللي ثانية من وصولها الأول.

stime.awk
atime.awk
	يخرج سطراً واحداً لكل إرسال أو إقرار، على التوالي، بالشكل
		<time> <seq. number>
	حيث <time> هو الوقت بالثواني منذ بدء النقل و <seq. number> هو رقم التسلسل الذي يتم إرساله أو إقراره. عادةً ما أرسم هذه البيانات بحثاً عن أنماط مشبوهة.


المشكلة التي كنت أنظر إليها كانت إنتاجية نقل البيانات الضخمة عبر مسارات شبكة ذات تأخير متوسط (زمن رحلة ذهاباً وإياباً 1-6 ثانية) تحت ظروف الإنترنت DARPA النموذجية. تم استخدام تتبع نقل ftp لملف كبير كمصدر بيانات خام.
كانت الطريقة:

  - على مضيف محلي (ولكن ليس Sun الذي يشغل tcpdump)، اتصل بـ ftp البعيد.

  - على Sun المراقب، ابدأ التتبع. مثلاً،
      tcpdump host local-host and remote-host and port ftp-data >tracefile

  - محلياً، قم إما بـ get أو put لملف كبير (~500 كيلوبايت)، ويفضل أن يكون على جهاز null (لتقليل التأثيرات مثل إغلاق نافذة الاستقبال أثناء انتظار كتابة قرص).

  - عندما ينتهي النقل، أوقف tcpdump. استخدم awk لإنشاء ملفين من بيانات الملخص (maxsize هو الحد الأقصى لحجم الحزمة، tracedata هو ملف بيانات تتبع tcpdump):
      awk -f send-ack.awk packetsize=avgsize tracedata >sa
      awk -f packetdat.awk packetsize=avgsize tracedata >pd

  - أثناء طباعة ملفات بيانات الملخص، ألق نظرة على كيفية تصرف النقل:
      awk -f stime.awk tracedata | xgraph
    (يبدو أن 90% مما تتعلمه يحدث في هذه الخطوة).

  - قم بجميع الخطوات المذكورة أعلاه عدة مرات، في كلا الاتجاهين، في أوقات مختلفة من اليوم، مع تطبيقات بروتوكول مختلفة على الطرف الآخر.

  - باستخدام أحد حزم تحليل بيانات Unix (في حالتي، S و Unix|Stat لجاري بيرلمان)، اقضِ بضعة أشهر في التحديق في البيانات.

  - غيّر شيئاً في تطبيق البروتوكول المحلي وأعد الخطوات المذكورة أعلاه.

  - مرة في الأسبوع، أخبر وكيل التمويل الخاص بك أنك تكتشف أشياء رائعة وأنك ستكتب تقرير البحث هذا "قريباً جداً".