TFTP RFC를 확인하면 패킷 크기는 512 바이트로 고정이라고 되어있다.
하지만 TFTP 확장 RFC를 보면 협상을 통해 바꿀 수 있음을 확인할 수 있다.
512 바이트의 패킷 크기로 대용량의 파일을 전송하는 일은 비효율적임은 당연하다.
패킷 처리에 대한 오버헤드는 물론이고,
TFTP는 데이터마다 ACK를 확인 후에 다음 데이터를 보내는 동기 방식이기 때문에
패킷 개수 * RRT의 시간이 네트워크에서 소요된다.
따라서 이를 최소화하기 위해서는 해당 매체의 MTU까지 채워서 보내는 것이 효율적이다.
Ethernet의 MTU는 1500바이트이고,
이 중에서 TFTP, UDP, IP 헤더를 제외하면,
최대 1428 바이트의 데이터를 하나의 프레임에 담아서 보낼 수 있다.
RFC 2348을 보면 패킷 크기 별 전송 소요 시간 비교가 나와있으니 참고하기 바란다.
하지만 패킷이 MTU 크기를 넘어가면,
IP 수준에서 fragmentation이 일어나기 때문에
이에 대한 부하가 발생한다.
fragmentation/defragmentation은
중간 경로 상에 IP 수준으로 처리하는 게이트웨이의 수가 많을수록 부하는 커진다.
MTU를 넘지 않는 수준에서 적당한 크기를 찾아야 할 것이다.
Reference:
ftp://ftp.rfc-editor.org/in-notes/rfc2348.txt
하지만 TFTP 확장 RFC를 보면 협상을 통해 바꿀 수 있음을 확인할 수 있다.
512 바이트의 패킷 크기로 대용량의 파일을 전송하는 일은 비효율적임은 당연하다.
패킷 처리에 대한 오버헤드는 물론이고,
TFTP는 데이터마다 ACK를 확인 후에 다음 데이터를 보내는 동기 방식이기 때문에
패킷 개수 * RRT의 시간이 네트워크에서 소요된다.
따라서 이를 최소화하기 위해서는 해당 매체의 MTU까지 채워서 보내는 것이 효율적이다.
Ethernet의 MTU는 1500바이트이고,
이 중에서 TFTP, UDP, IP 헤더를 제외하면,
최대 1428 바이트의 데이터를 하나의 프레임에 담아서 보낼 수 있다.
RFC 2348을 보면 패킷 크기 별 전송 소요 시간 비교가 나와있으니 참고하기 바란다.
하지만 패킷이 MTU 크기를 넘어가면,
IP 수준에서 fragmentation이 일어나기 때문에
이에 대한 부하가 발생한다.
fragmentation/defragmentation은
중간 경로 상에 IP 수준으로 처리하는 게이트웨이의 수가 많을수록 부하는 커진다.
MTU를 넘지 않는 수준에서 적당한 크기를 찾아야 할 것이다.
Reference:
ftp://ftp.rfc-editor.org/in-notes/rfc2348.txt
