Kích thước gói trong luồng TCP

Tôi là lưu lượng truy cập mạng và muốn chia mỗi phiên TCP thành một loạt các yêu cầu và phản hồi (các giao thức tôi đang làm việc với tất cả các công việc theo cách đó, như HTTP hoặc SSL).

Tôi đã có một giả định đơn giản (bỏ qua các gói không theo thứ tự và bực bội) - được cung cấp một khối dữ liệu cần gửi, nó sẽ được gửi bằng các gói lớn nhất có thể và gói cuối cùng sẽ nhỏ hơn kích thước tối đa hoặc được theo dõi bởi một gói từ phía bên kia (bỏ qua các gói trống ACK). Vì vậy, trong một phiên HTTP, tôi hy vọng sẽ thấy một cái gì đó như (một lần nữa, không quan tâm đến acks) -

Gói 1 - Yêu cầu "Nhận ..."

Gói 2 - Phản hồi, kích thước 1434

Gói 3 - Phản hồi, kích thước 1434

Gói 4 - Phản hồi, kích thước 1434

Gói 5 - Phản hồi, kích thước 500

Đó là những gì tôi nhận được trong hầu hết các phiên, tuy nhiên có ít nhất một lần tôi thấy nó trông giống như

Gói 1 - Yêu cầu "Nhận ..."

Gói 2 - Phản hồi, kích thước 1434

Gói 3 - Phản hồi, kích thước 1080

Gói 4 - Phản hồi, kích thước 1434

Gói 5 - Phản hồi, kích thước 500

Không truyền lại, các gói ngoài đơn đặt hàng ở đây hoặc không có sự chậm trễ đặc biệt nào trên máy chủ.

Tôi muốn biết - điều gì có thể gây ra điều này và khi nào nó sẽ xảy ra? Làm thế nào sai là giả định của tôi?

CẬP NHẬT

Tôi đặt một tập tin pcap ví dụ ở đây

CẬP NHẬT 2

Bao gồm một tsharkbãi chứa với các lĩnh vực liên quan ...

$ 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 

Lớp TCP sử dụng thuật toán Nagle để lưu lượng đệm (nó gửi ít gói lớn hơn, thay vì nhiều gói nhỏ hơn ... làm cho nó hiệu quả hơn); có một cách để ứng dụng nói 'gửi ngay bây giờ'. Bạn thấy rằng trong tiêu đề TCP có cờ gọi là bit PSH (đẩy). Trong khi bit được đặt theo ngăn xếp, việc đẩy được thực hiện theo yêu cầu của ứng dụng.

Vì vậy, đây là dự định và hành vi bình thường.

Kích thước gói tùy thuộc vào cách ứng dụng và / hoặc bộ đệm hệ điều hành và gửi dữ liệu mạng. Nếu ứng dụng và / hoặc HĐH quyết định gửi dữ liệu sau khi 1080 byte nằm trong bộ đệm thì gói sẽ là 1080 byte (cộng với các tiêu đề). Có thể có nhiều lý do để nó làm điều đó. Trong trường hợp của bạn, bạn sẽ phải tìm trong mã nguồn máy chủ web và / hoặc ngăn xếp mạng OS.

Kích thước gói được xác định bởi HĐH (nói chung) và liên quan đến bộ đệm, lượng dữ liệu do ứng dụng cung cấp, v.v. Nhiều chiến lược có thể được sử dụng để đạt được hiệu suất tối đa và đôi khi gửi các gói nhỏ hơn có thể nhanh hơn chờ đợi để tạo một gói lớn hơn.

Đôi khi số lượng ứng dụng đang chạy có thể yêu cầu HĐH nhanh hơn (gửi bất cứ thứ gì nó có trong bộ đệm cho đến nay) thay vì bão hòa bộ đệm.

Có lẽ, bạn có thể cung cấp cho chúng tôi chi tiết hơn về kịch bản bạn đang làm việc (ví dụ: hệ điều hành máy chủ, các ứng dụng chạy trên nó).

Về cơ bản, vấn đề là việc triển khai TCP không biết ứng dụng sẽ làm gì tiếp theo. Khi ứng dụng máy chủ tạo một chuỗi ghi, ngăn xếp không biết liệu ghi mà nó đã nhận được cho đến nay là toàn bộ chuỗi hay chỉ là một phần của nó.

Hầu hết thời gian ứng dụng máy chủ thực hiện ghi vào bộ đệm nhanh hơn so với ngăn xếp mạng có thể làm trống nó. Vì vậy, bộ đệm là đầy đủ và các gói kích thước đầy đủ đi ra.

Nhưng đôi khi một cái gì đó khác làm chậm ứng dụng máy chủ. Có thể chờ đợi một đĩa đọc trên một mảng đĩa quá tải hoặc một cái gì đó. Vì vậy, bộ đệm trống và ngăn xếp mạng phải chọn giữa việc gửi một gói nhỏ hơn (nhiều chi phí hơn) hoặc chờ dữ liệu có thể không bao giờ đến (thêm độ trễ).

Nếu bạn nhìn vào khung 34, bạn sẽ thấy rằng máy chủ đã truyền bộ đệm 32kB và bit PSH được đặt. Nếu bạn nhìn vào 82 bạn sẽ thấy tương tự, 32 kB từ bit PSH trước đó. Gói 52 có bit PSH mặc dù đã có ít hơn 2kB phản hồi.

Bit PSH thường được đặt bởi ngăn xếp TCP cho đoạn cuối của PDU ứng dụng được ghi vào mạng. Vì vậy, ứng dụng sử dụng bộ đệm 32kB và khi có nhiều dữ liệu, hãy ghi nó vào ổ cắm TCP 32kB tại một thời điểm. Khi có ít dữ liệu như trong các khung 51-52, đó là do ứng dụng đã ghi ra bản ghi đó trước tiên trong phản hồi và nó chỉ có 1820 byte.

Lưu ý rằng ứng dụng mà tôi đề cập trong thực tế có thể không phải là ứng dụng máy chủ mà là một số phần mềm trung gian như Máy ảo Java (JVM) hoặc bất cứ thứ gì. Không rõ nội dung dữ liệu tại sao PDU 1820 byte được gửi, có lẽ bộ đệm 32kB không có sẵn tại thời điểm đó?

Vấn đề là nó không quan trọng, không có hình phạt hiệu suất đáng kể.