TCPストリームのパケットサイズ

私はネットワークトラフィックであり、各TCPセッションを一連の要求と応答（HTTPやSSLなどのすべての方法で機能しているプロトコル）に分割したいと考えています。

私は単純な仮定をしました（順不同でパケットを再送信することは無視します）-送信する必要があるデータのチャンクが与えられると、それは可能な最大のパケットを使用して送信され、最後のパケットは最大サイズよりも小さいか、または従います反対側からのパケット（ACK空パケットを無視）。したがって、HTTPセッションでは、（再び、ackを無視して）のようなものが表示されることを期待しています-

パケット1-「Get ...」の要求

パケット2-応答、サイズ1434

パケット3-応答、サイズ1434

パケット4-応答、サイズ1434

パケット5-応答、サイズ500

ほとんどのセッションでこれが行われますが、少なくとも1回は次のようなことがありました。

パケット1-「Get ...」の要求

パケット2-応答、サイズ1434

パケット3-応答、サイズ1080

パケット4-応答、サイズ1434

パケット5-応答、サイズ500

ここでは再送信、順序正しくないパケット、サーバーでの例外的な遅延はありません。

知りたい-何が原因で、いつ発生するのか？私の仮定はどのように間違っていますか？

更新

ここに 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アルゴリズムを使用してトラフィックをバッファリングします（小さいパケットではなく、大きいパケットを少なく送信します... アプリケーションが「今すぐ送信」と言う方法があります。PSH（プッシュ）ビットと呼ばれるフラグを持つTCPヘッダーにそれが表示されます。スタックによってビットが設定されている間、アプリケーションの要求でプッシュが行われます。

したがって、これは意図された正常な動作です。

パケットサイズは、アプリケーションやOSがバッファリングしてネットワークデータを送信する方法によって異なります。アプリケーションまたはOS、あるいはその両方が、1080バイトがバッファーに入れられた後にデータを送信することを決定した場合、パケットは1080バイト（およびヘッダー）になります。それを行うには多くの理由が考えられます。あなたのケースでは、ウェブサーバーのソースコードやOSネットワークスタック、あるいはその両方を調べる必要があります。

パケットサイズはOS（一般的に）によって定義され、バッファ、アプリケーションによって提供されるデータの量などに関連します。最大のパフォーマンスを実現するために多くの戦略を使用できます。小さいパケットを送信すると、作成を待つよりも速くなる場合があります。より大きなパケット。

実行中のアプリの量によっては、バッファを飽和させるのではなく、OSに高速化（これまでにバッファにあるものを何でも送信する）を要求することがあります。

おそらく、使用していたシナリオについてより詳細な情報を提供できます（例：サーバーOS、その上で実行されているアプリ）。

基本的に問題は、TCP実装がアプリケーションが次に何をするかを知らないことです。サーバーアプリケーションが一連の書き込みを行う場合、スタックは、それまでに受け取った書き込みがシーケンス全体であるか、それとも一部であるかを認識していません。

ほとんどの場合、サーバーアプリケーションは、ネットワークスタックがバッファを空にできるよりも速くバッファに書き込みを行います。したがって、バッファがいっぱいになり、フルサイズのパケットが出てきます。

ただし、サーバーアプリケーションの速度が低下することがあります。おそらく、過負荷のディスクアレイなどでディスクの読み取りを待機しています。そのため、バッファが空になり、ネットワークスタックは、より小さなパケットを送信する（オーバーヘッドを増やす）か、決して到着しないデータを待つ（遅延を追加する）かを選択する必要があります。

フレーム34を見ると、サーバーが32kBのバッファーを送信し、PSHビットが設定されていることがわかります。82を見ると、前のPSHビットから同じ32 kBが表示されます。応答が2kB未満であっても、パケット52にはPSHビットがあります。

通常、PSHビットは、ネットワークに書き込まれたアプリケーションPDUの最後のセグメントのTCPスタックによって設定されます。そのため、アプリケーションは32kBのバッファを使用し、大量のデータがある場合は、一度にTCPソケット32kBに書き込みます。フレーム51から52のようにデータが少ない場合、それはアプリケーションが最初にそのレコードを応答で書き込み、それが1820バイトしかなかったためです。

私が言及しているアプリケーションは、実際にはサーバーアプリケーション自体ではなく、Java仮想マシン（JVM）などの中間ソフトウェアである場合があります。1820バイトのPDUが送信された理由がデータの内容から明らかではありません。おそらく32kBのバッファーが当時利用できなかったのでしょうか。

重要なのは、問題ではないということです。実質的なパフォーマンスの低下はありません。