2009-05-22 4 views
2

TCP/IP에서 클라이언트에서 서버로 고정 크기 데이터를 전송하는 동안 전체 데이터 전송을 계산해야합니다. 그것은 서버에 연결, 요청, 헤더, 응답 수신, 데이터 수신 등을 포함합니다.TCP/IP에서 전체 데이터 업로드 + 다운로드를 결정하는 방법

더 정확하게, POST 및 GET 메소드를 사용하는 동안 전체 데이터 전송을 얻는 방법은 무엇입니까?

어떤 공식이 있습니까? 이론적 인 것조차도 괜찮을 것입니다 (패킷 손실이나 연결 재 시도 등을 고려하지 않음)

참고로 RFC2616과 RFC1180을 시도했습니다. 그러나 그것들은 내 머리 위로 가고있다.

의견이 있으십니까?

미리 감사드립니다.

+0

특정 거래 수나 사용 된 특정 포트의 트래픽 속도를 찾고 계십니까? –

+0

특정 트랜잭션 수입니다.클라이언트에서 서버로 보낼 데이터 크기를 알고 있습니다. URI를 알기 때문에 직접 POST 메서드를 사용할 것이므로 클라이언트 측 요청 헤더 크기도 알 수 있습니다. 응답 헤더 크기를 가정 할 수 있습니다. 이제 데이터 전송으로 고려해야 할 다른 것들은 무엇입니까? – fireball003

답변

0

평균적으로 요청 및 응답에는 약 8 줄의 머리글과 한 줄당 약 30 자의 글자가 있습니다. 업로드 된 바이너리를 Base64로 변환 할 때 크기를 늘릴 수 있습니다.

당신은 또한 너무

마지막으로 1500 데이터 바이트 당 16 바이트 (TCP 헤더), 당신은 할 수 추가하는 경우에 당신은 약 1500의 MTU를 가정 할 수 TCP 패킷 헤더를 계산하려면 당신은 말하지 않았다 항상 패킷 스니퍼를 설정하고 데이터 샘플에 대한 실제 바이트 수를 계산하십시오.

오, 그렇습니다. 또한 deflate/gzip 인코딩을 허용해야 할 수도 있습니다.

3

재전송을 무시하더라도 총 전송 크기를 미리 알 수 없습니다.

  • TCP 옵션은 연결이 설정 될 때 호스트간에 협상됩니다. 일부 옵션 (예 : 타임 스탬프)이 TCP 헤더에 추가 데이터를 추가합니다.
  • "전체 데이터 전송 크기"가 명확하지 않습니다. 예를 들어, 이더넷은 사용 된 IP가 무엇이든간에 상당히 많은 비트를 추가합니다. 802.11 (무선)은 더 많은 것을 추가 할 것입니다. 그렇다면 HDLC 또는 PPP가 T1을 지나치게됩니다. 프레임 릴레이에 대해서 생각조차하지 마라. 일부 링크는 압축을 사용하여 전체 크기를 줄입니다. 전체 크기는 단일 패킷의 경우에도 측정 위치에 따라 다릅니다.
  • 레이어 2의 총 옥텟 크기에 관심이 있고 미리 협상 할 TCP 옵션을 알고 있다고 가정하면 여전히 경로 MTU를 알 수 없습니다. 연결이 진행 중일 때도 변경 될 수 있습니다. 또는 경로 MTU 검색 (wierd)을 수행하지 않으면 패킷이 어딘가에 조각화 될 수 있으며 원격 엔드는 사용자와 다른 양의 데이터 전송을 보게됩니다.

나는 당신이 알아야 할 이유는 모르겠지만, 제안 : 당신은 그냥 견적을 원하는 경우

  • 는, 와이어 샤크의 일반적인 연결을보십시오. % 오버 헤드를 계산하십시오 (TCP에 대해주고 TCP로부터 수신 한 데이터의 크기와 비교). 그 숫자를 이용하여 추정하십시오. 병적 인 상황을 제외하고는 충분히 가깝습니다.
  • 엔드 톱이 얼마나 많은 양의 데이터를 송수신했는지 알 필요가있는 경우 libpcap을 사용하여 패킷 스트림을 캡처하고 확인하십시오.
+0

GPRS/EDGE 기반 연결에 대한 총 데이터 전송을 계산할 것입니다. KB 단위로 청구됩니다. 그렇다면 고려해야 할 사항은 무엇입니까? 클라이언트 측에서 업로드 할 데이터 크기를 알고 있습니다. POST 메서드를 사용하여 요청 헤더 크기를 알 수 있으므로 응답 헤더를 사용할 수도 있습니다. 내 질문은 입니다. 1. 데이터 전송시 고려해야 할 다른 사항은 무엇입니까? 2. 데이터 크기에 따라 변하는 변수 (각 패킷의 데이터 패킷 헤더 제외)는 무엇입니까? – fireball003