TCP 스트림의 패킷 크기

나는 네트워크 트래픽이며 각 TCP 세션을 일련의 요청과 응답으로 나눕니다 (HTTP 또는 SSL과 같은 방식으로 모든 작업을 수행하는 프로토콜).

전송해야 할 데이터 청크가 주어지면 가능한 가장 큰 패킷을 사용하여 전송되며 마지막 패킷은 최대 크기보다 작거나 따라갑니다. 다른 쪽의 패킷에 의해 (ACK 빈 패킷을 무시). 따라서 HTTP 세션에서 (다시 무시하고 acks 무시)와 같은 것을 기대합니다.

패킷 1-요청 "Get ..."

패킷 2-응답, 크기 1434

패킷 3-응답, 크기 1434

패킷 4-응답, 크기 1434

패킷 5-응답, 크기 500

대부분의 세션에서 얻는 것이지만, 적어도 한 번은 다음과 같은 모습을 보았습니다.

패킷 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 알고리즘을 사용하여 트래픽을 버퍼링합니다 (더 작은 패킷 대신 더 적은 수의 큰 패킷을 전송합니다 ... 더 효율적 임). 애플리케이션이 '지금 보내기'라고 말하는 방법이 있습니다. TCP 헤더에는 PSH (푸시) 비트라는 플래그가 있습니다. 비트가 스택에 의해 설정되는 동안 푸시는 응용 프로그램의 요청에 따라 수행됩니다.

이것은 정상적인 동작입니다.

패킷 크기는 응용 프로그램 및 / 또는 OS가 네트워크 데이터를 버퍼링하고 보내는 방법에 따라 다릅니다. 애플리케이션 및 / 또는 OS가 1080 바이트가 버퍼에있는 후 데이터를 전송하기로 결정하면 패킷은 1080 바이트 (플러스 헤더)가됩니다. 그렇게하는 데는 여러 가지 이유가있을 수 있습니다. 귀하의 경우 웹 서버 소스 코드 및 / 또는 OS 네트워크 스택을 봐야합니다.

패킷 크기는 OS (일반적으로)에 의해 정의되며 버퍼, 응용 프로그램에서 제공하는 데이터 양 등과 관련이 있습니다. 많은 전략을 사용하여 최대 성능을 달성 할 수 있으며, 때로는 작은 패킷을 전송하는 것이 생성 대기 시간보다 빠를 수 있습니다 더 큰 패킷.

때때로 실행되는 앱의 양은 버퍼를 포화시키는 대신 OS가 더 빠른 버퍼를 요구할 수 있습니다.

아마도 작업중인 시나리오 (예 : 서버 OS, 실행중인 앱)에 대한 자세한 정보를 제공 할 수 있습니다.

근본적으로 문제는 TCP 구현이 응용 프로그램이 다음에 무엇을할지 알지 못한다는 것입니다. 서버 응용 프로그램에서 일련의 쓰기 작업을 수행하면 스택은 지금까지 수신 한 쓰기가 전체 시퀀스인지 또는 일부인지를 알 수 없습니다.

대부분의 경우 서버 응용 프로그램은 네트워크 스택이 버퍼를 비울 수있는 것보다 더 빠르게 버퍼에 기록합니다. 따라서 버퍼가 가득 차서 전체 크기의 패킷이 나옵니다.

그러나 때로는 다른 무언가로 인해 서버 응용 프로그램이 느려집니다. 과부하 된 디스크 어레이 또는 디스크에서 디스크 읽기를 기다리는 중일 수 있습니다. 따라서 버퍼가 비워지고 네트워크 스택은 더 작은 패킷을 보내거나 (더 많은 오버 헤드), 올 수없는 데이터를 기다리는 중 (지연 추가) 중에서 선택해야합니다.

프레임 34를 보면 서버가 32kB 버퍼를 전송했으며 PSH 비트가 설정되어 있음을 알 수 있습니다. 82를 보면 이전 PSH 비트와 동일한 32kB가 표시됩니다. 패킷 (52)은 2kB 미만의 응답이 있었지만 PSH 비트를 갖는다.

PSH 비트는 일반적으로 네트워크에 쓰여진 응용 프로그램 PDU의 마지막 세그먼트에 대한 TCP 스택에 의해 설정됩니다. 따라서 응용 프로그램은 32kB 버퍼를 사용하고 많은 데이터가있을 때 한 번에 TCP 소켓 32kB에 씁니다. 프레임 51-52에서와 같이 데이터가 적을 때 응용 프로그램이 응답에서 해당 레코드를 먼저 기록하고 1820 바이트에 불과했기 때문입니다.

내가 언급 한 응용 프로그램은 실제로 서버 응용 프로그램 자체가 아니라 JVM (Java Virtual Machine)과 같은 일부 중간 소프트웨어 일 수 있습니다. 왜 1820 바이트 PDU가 전송되었는지, 왜 당시에는 32kB 버퍼를 사용할 수 없었는지 데이터 내용에서 명확하지 않습니까?

요점은 중요하지 않으며 실질적인 성능 저하가 없다는 것입니다.