매우 큰 HTTP 요청 대 다수의 작은 요청

Question

서버에서 클라이언트로 전송할 2D 배열 (Json)이 필요합니다. 크기는 약 400x400이고 텍스트는 4 자 정도입니다. 이렇게하면 약 640KB의 데이터가됩니다.

다음과 같은 극단적 인 접근법이 더 좋습니다.

1. 나는 한 번에 모든 데이터의 큰 HTTP 요청을합니다.
2. 나는 400 개 요청을 - 각 (1.6 KB 주위에) 하나의 행을 요청

내가 최적의 접근 방식은 중간에 어딘가에있을 것이라고 생각합니다. 누구든지이 데이터에 대해 최적의 단일 요청 크기가 무엇인지 생각해 볼 수 있습니까?

감사합니다.

Answer 1

당신이 (오늘날의 기준에 의해 매우 느린) 속도가 느린 처리하지 않는 연결 정말 필요 증분 업데이트는 하나 개의 요청에 그것을 할.

이렇게하면 compressing the response의 효율성이 향상되고 extra HTTP requests and response headers의 오버 헤드가 방지됩니다. 대 큰 하나를 선택을위한 고려 사항의

이

Answer 2

커플 여러 개의 작은 : 데이터가 도착하는대로

단일 요청 경우

• , 당신은 진보적 인 데이터 처리를 할 수 없다; 당신은 아무것도 할 수 있기 전에 전체 패킷이 도착하기를 기다려야합니다. 실패하면 처음부터 모든 것을 시작해야합니다.
• 여러 요청의 경우 점진적 데이터 처리를 수행 할 수 있습니다. 그러나 다중 실패의 가능성과이를 복구하는 방법을 고려해야합니다.
• 각 요청마다 여러 요청에 오버 헤드가 발생합니다. 이것은 앱에서 소비 할 추가 대역폭입니다.
• 일부 HTTP 에이전트는 동일한 서버에 동시 요청 수를 제한하므로이를 해결하려면 일부 논리를 수행해야 할 수 있습니다.
• 응답 압축은 단일 요청의 경우 더 잘 작동합니다.
• 여러 요청에서 데이터의 전체 메모리를 할당 할 필요가 없습니다. 640KB는 그다지 큰 메모리가 아니기 때문에 할당 할 빈도에 따라 큰 고려 사항이 아닐 수도 있습니다.
• 프로세스의 조기 종료 (취소 버튼 또는 앱 종료 또는 브라우저에서 페이지로 이동)의 경우 단일 요청은 여전히 ​​전체 응답 다운로드를 완료합니다. 그러나 여러 요청의 경우 코드가 아직 시작되지 않은 요청은 실행되지 않습니다.

정직하게 말하면, 나는 마지막 두 가지를 걱정하지 않을 것이며, 1) 내 진보적 인 데이터 처리가 중요합니다. 2) 귀하의 앱 허용 오차가 오류 및 부분 데이터에 대한 것입니다.

Answer 3

그리고 서버에는 vulnerabilities with large requests이있을 수 있습니다.