ขนาดแพ็คเก็ตในสตรีม TCP

ฉันเป็นทราฟฟิกเครือข่ายและต้องการแบ่งเซสชัน TCP แต่ละครั้งเป็นชุดของคำขอและการตอบกลับ (โปรโตคอลที่ฉันใช้งานด้วยวิธีนั้นทั้งหมดเช่น HTTP หรือ SSL)

ฉันมีสมมติฐานง่าย ๆ (ไม่สนใจคำสั่งซื้อและแพ็กเก็ตที่ส่งใหม่) - เนื่องจากข้อมูลจำนวนหนึ่งที่ต้องส่งมันจะถูกส่งโดยใช้แพ็กเก็ตที่ใหญ่ที่สุดที่เป็นไปได้และแพ็คเก็ตสุดท้ายจะเล็กกว่าขนาดสูงสุดหรือตาม โดยแพ็กเก็ตจากอีกด้านหนึ่ง (ละเว้นแพ็กเก็ต ACK ที่ว่างเปล่า) ดังนั้นในเซสชัน HTTP ฉันคาดว่าจะเห็นสิ่งที่ต้องการ (อีกครั้งโดยไม่สนใจ acks) -

Packet 1 - ร้องขอ "รับ ... "

Packet 2 - Response ขนาด 1434

Packet 3 - Response ขนาด 1434

Packet 4 - Response ขนาด 1434

Packet 5 - Response ขนาด 500

ซึ่งเป็นสิ่งที่ฉันได้รับในช่วงเวลาส่วนใหญ่อย่างไรก็ตามมีอย่างน้อยหนึ่งครั้งที่ฉันเห็นสิ่งที่ดูเหมือน

Packet 1 - ร้องขอ "รับ ... "

Packet 2 - Response ขนาด 1434

Packet 3 - Response ขนาด 1080

Packet 4 - Response ขนาด 1434

Packet 5 - Response ขนาด 500

ไม่มีการส่งสัญญาณซ้ำแพ็คเก็ตที่นี่หรือไม่มีความล่าช้าที่ยอดเยี่ยมบนเซิร์ฟเวอร์

ฉันต้องการที่จะรู้ - สิ่งที่สามารถทำให้เกิดสิ่งนี้และเมื่อมันจะเกิดขึ้น? สมมติฐานของฉันเป็นอย่างไร

UPDATE

ฉันใส่ตัวอย่างไฟล์ pcap ที่นี่

อัพเดท 2

รวมการtsharkดัมพ์กับฟิลด์ที่เกี่ยวข้อง ...

$ tshark -r http_1082.pcap -T fields -e frame.number -e frame.len \
    -e ip.src -e ip.dst -e tcp.flags.push -e http.request.method \
    -e http.request.uri -e http.response.code | head -n 47
1     66      192.168.1.103    206.33.49.126    0            
2     62      206.33.49.126    192.168.1.103    0            
3     64      192.168.1.103    206.33.49.126    0            
4     411     192.168.1.103    206.33.49.126    1    GET    /money/.element/script/3.0/video/xmp/xmp_playlistapi.js    
5     54      206.33.49.126    192.168.1.103    0            
6     1434    206.33.49.126    192.168.1.103    0            
7     1434    206.33.49.126    192.168.1.103    0            
8     64      192.168.1.103    206.33.49.126    0            
9     1434    206.33.49.126    192.168.1.103    0            
10    1434    206.33.49.126    192.168.1.103    0            
11    1434    206.33.49.126    192.168.1.103    0            
12    64      192.168.1.103    206.33.49.126    0            
13    1434    206.33.49.126    192.168.1.103    0            
14    1434    206.33.49.126    192.168.1.103    0            
15    1434    206.33.49.126    192.168.1.103    0            
16    1434    206.33.49.126    192.168.1.103    0            
17    64      192.168.1.103    206.33.49.126    0            
18    1434    206.33.49.126    192.168.1.103    0            
19    1434    206.33.49.126    192.168.1.103    0            
20    1434    206.33.49.126    192.168.1.103    0            
21    1434    206.33.49.126    192.168.1.103    0            
22    1434    206.33.49.126    192.168.1.103    0            
23    64      192.168.1.103    206.33.49.126    0            
24    1434    206.33.49.126    192.168.1.103    0            
25    1434    206.33.49.126    192.168.1.103    0            
26    1434    206.33.49.126    192.168.1.103    0            
27    1434    206.33.49.126    192.168.1.103    0            
28    1434    206.33.49.126    192.168.1.103    0            
29    1434    206.33.49.126    192.168.1.103    0            
30    64      192.168.1.103    206.33.49.126    0            
31    1434    206.33.49.126    192.168.1.103    0            
32    1434    206.33.49.126    192.168.1.103    0            
33    1434    206.33.49.126    192.168.1.103    0            
34    1082    206.33.49.126    192.168.1.103    1     <------ Packet in question        
35    1434    206.33.49.126    192.168.1.103    0            
36    1434    206.33.49.126    192.168.1.103    0            
37    1434    206.33.49.126    192.168.1.103    0            
38    64      192.168.1.103    206.33.49.126    0            
39    1434    206.33.49.126    192.168.1.103    0            
40    1434    206.33.49.126    192.168.1.103    0            
41    1434    206.33.49.126    192.168.1.103    0            
42    1434    206.33.49.126    192.168.1.103    0            
43    1434    206.33.49.126    192.168.1.103    0            
44    1434    206.33.49.126    192.168.1.103    0            
45    1434    206.33.49.126    192.168.1.103    0            
46    626     206.33.49.126    192.168.1.103    1            200
47    64      192.168.1.103    206.33.49.126    0 

เลเยอร์ TCP ใช้อัลกอริทึม Nagle ในการบัฟเฟอร์การรับส่งข้อมูล (ส่งแพ็คเก็ตขนาดใหญ่น้อยลงแทนที่จะเป็นแพ็คเก็ตขนาดเล็ก ... ทำให้มีประสิทธิภาพมากขึ้น); มีวิธีสำหรับแอปพลิเคชันที่จะพูดว่า 'ส่งทันที' คุณเห็นว่าในส่วนหัว TCP ที่มีการตั้งค่าสถานะที่เรียกว่าบิต PSH (push) ในขณะที่บิตถูกตั้งค่าโดยสแต็กการพุชจะทำตามคำร้องขอของแอ็พพลิเคชัน

ดังนั้นนี่คือพฤติกรรมที่ตั้งใจและปกติ

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

ขนาดแพ็คเก็ตถูกกำหนดโดยระบบปฏิบัติการ (โดยทั่วไป) และเกี่ยวข้องกับบัฟเฟอร์จำนวนข้อมูลที่ได้รับจากแอปพลิเคชัน ฯลฯ กลยุทธ์มากมายสามารถใช้เพื่อให้ได้ประสิทธิภาพสูงสุดและบางครั้งการส่งแพ็กเก็ตขนาดเล็กอาจเร็วกว่ารอสร้าง แพ็คเก็ตที่ใหญ่กว่า

บางครั้งปริมาณแอปที่ทำงานอยู่สามารถเรียกร้องให้ระบบปฏิบัติการเร็วขึ้น (ส่งทุกอย่างที่มีอยู่ในบัฟเฟอร์จนถึงตอนนี้) แทนที่จะทำให้บัฟเฟอร์อิ่มตัว

บางทีคุณอาจให้รายละเอียดเพิ่มเติมเกี่ยวกับสถานการณ์ที่คุณทำงานกับเรา (เช่น: ระบบปฏิบัติการเซิร์ฟเวอร์แอปที่ทำงานอยู่)

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

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

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

ถ้าคุณดูที่เฟรม 34 คุณจะเห็นว่าเซิร์ฟเวอร์ส่งบัฟเฟอร์ 32kB และตั้งค่าบิต PSH ถ้าคุณดูที่ 82 คุณจะเห็นเหมือนกัน 32 kB จากบิต PSH ก่อนหน้า Packet 52 มีบิต PSH แม้ว่าจะมีการตอบสนองน้อยกว่า 2kB

โดยทั่วไปบิต PSH จะถูกตั้งค่าโดยสแต็ก TCP สำหรับส่วนสุดท้ายของแอปพลิเคชัน PDU ที่เขียนไปยังเครือข่าย ดังนั้นแอปพลิเคชันจะใช้บัฟเฟอร์ 32kB และเมื่อมีข้อมูลจำนวนมากให้เขียนลงใน TCP socket 32kB ในแต่ละครั้ง เมื่อมีข้อมูลน้อยลงเช่นเดียวกับในเฟรมที่ 51-52 นั่นเป็นเพราะแอปพลิเคชันเขียนบันทึกนั้นเป็นครั้งแรกในการตอบสนองและมันเป็นเพียง 1820 ไบต์

โปรดสังเกตว่าแอปพลิเคชันที่ฉันอ้างถึงอาจไม่ใช่แอพพลิเคชันเซิร์ฟเวอร์ แต่เป็นซอฟต์แวร์ระดับกลางบางอย่างเช่น Java Virtual Machine (JVM) หรืออะไรก็ตาม ไม่ชัดเจนจากเนื้อหาข้อมูลเหตุใดจึงส่ง 1820 ไบต์ PDU บางทีบัฟเฟอร์ 32kB ไม่พร้อมใช้งานในเวลา

ประเด็นก็คือว่ามันไม่สำคัญว่าจะไม่มีการลงโทษตามผลงานที่สำคัญ