POST의 헤더와 본문 간의 무작위 대기 시간

Question

NSUrlConnection sendAsynchronousRequest를 사용하여 노드 POST 서버에 간단한 POST 요청을 보냅니다. tcpdumps를 분석하여 요청 헤더와 요청 본문이 2 개의 개별 TCP 패킷으로 분할되는 경우가 있음을 알았습니다.

NSMutableURLRequest *request = [[NSMutableURLRequest alloc] init]; 
[request setURL:[NSURL URLWithString:url]]; 
[request setTimeoutInterval:3]; 
[request setHTTPMethod:@"POST"]; 
[request setValue:postLength forHTTPHeaderField:@"Content-Length"]; 
[request setValue:@"application/json" forHTTPHeaderField:@"Content-type"]; 
[request setHTTPBody:postData]; 

[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler: ^(NSURLResponse *response, NSData *POSTReply, NSError *error) { }]; 

문제점은 때때로 헤더 우리 API 연결을 열고, 그리고 여러 초 후에 신체 패킷을 전송하는 서버로 전송된다는 것이다. 헤더와 본문간에 1 초 이상 지연이 발생하며 서버 측에서 100 건의 요청이 무작위로 발생합니다. Google API의 대기 시간 중 가장 큰 단일 소스입니다.

대부분의 요청에서 헤더와 본문은 거의 같은 크기 (각각 200 바이트)입니다.

이전에 본 사람이 있습니까?

Answer 1

신속한 API (NSUrlConnection 등)에 대한 구체적인 통찰력은 없지만 일반적으로 HTTP 데이터는 큰 패킷 (200 바이트를 하나의 패킷으로 수용 할 수 있음)으로 보내지 만보다 세부적인 결정 기본 TCP 레벨에서 가져 오며, 더 작은 크기의 덩어리로 나누기로 결정할 수 있습니다.

TCP가 비논리적 인 경계에서 패킷을 분할하는 특정 플랫폼 (예 : AIX)에서 노드 (송신 측 및 수신 측)에서이를 관찰했습니다. TCP 사양에 따라 응용 프로그램은 저레벨 데이터 전송의 특정 순서 또는 크기에 의존해서는 안되며 최종 단계에서 데이터 무결성을 보장합니다.

하나의 용의자는 TCP에 Nagile의 알고리즘이 존재한다는 것입니다.

클라이언트를 다른 플랫폼 (예 : Linux)으로 변경하고 코드를 이식하기 쉬운 경우 동작을 비교하는 것이 좋습니다.

희망이 도움이됩니다.