본문 바로가기
임베디드 개발/펌웨어

TFTP 프로토콜

by eteo 2023. 4. 10.

 

TFTP 프로토콜

 

 

 

 

TFTP 프로토콜

 

Trivial File Transfer Protocol의 약자로, 인터넷 프로토콜 스위트(IP Suite)*의 일부로서 파일 전송 프로토콜이다. TFTP는 TCP/IP 프로토콜 스택을 기반으로 하며, 그 중 UDP(User Datagram Protocol)를 이용하여 작동한다.

기본적으로 UDP 포트 69번을 사용하며, 전송할 파일의 이름과 위치를 포함하는 요청 메시지를 TFTP 서버에 보낸다. 이후 TFTP 서버는 파일을 찾아서 클라이언트에게 전송하는데, 전송 과정에서는 오류 검사와 재전송을 처리하는 기능이 내장되어 있다.

TFTP는 파일 전송 속도가 느리고 오류 처리 기능이 FTP와 비교해 상대적으로 취약하다는 단점이 있지만, 작은 파일을 빠르고 쉽게 전송할 수 있다는 장점이 있어 임베디드 시스템이나 네트워크 장비 등에서 파일을 전송하고나 펌웨어를 업데이트하기 위한 방법으로 사용될 수 있다.

 

 

 

 

📝 IP Suite란?

인터넷 프로토콜 스위트(Internet Protocol Suite) 또는 TCP/IP 프로토콜 스위트(TCP/IP Protocol Suite)라고도 불리는 네트워크 프로토콜의 모음이다. 이는 인터넷에서 데이터 통신을 위해 사용되는 프로토콜의 표준화된 집합이며, IP, TCP, UDP, ICMP, IGMP, ARP, DHCP, NAT 등을 포함한다.

 

 

 

 

 

 

TFTP와 FTP의 차이

 

TFTP와 FTP는 모두 파일 전송 프로토콜이지만, 다음과 같은 차이점이 있니다.

1. 포트 번호: TFTP는 포트 번호 69를 사용하고, FTP는 포트 번호 21을 사용한다.

2. 전송 방식: TFTP는 비교적 간단한 데이터 전송 프로토콜로, UDP 프로토콜을 사용하여 전송한다. 반면, FTP는 TCP 프로토콜을 사용하여 데이터 전송을 보장한다. 그리고 둘 다 오류검사와 재전송 기능이 제공되지만 TFTP는 데이터 블록에 블록 번호를 사용하여 중복과 누락을 방지하고, UDP에 내장된 체크섬 오류 검사를 사용하는 반면, FTP에서는 TCP 흐름 제어 기술 등을 이용한다. 

 

3. 보안: TFTP는 인증 기능이 제공되지 않으며, 패스워드 등 중요한 정보를 암호화하지 않기 때문에 보안성이 낮다. 반면, FTP는 인증 기능이 제공되며, SSL/TLS 등의 암호화 기능을 사용하여 보안성을 높일 수 있다.

4. 파일 전송 용량: TFTP는 32MB를 초과하는 파일은 전송할 수 없다는 제한이 있다. 반면, FTP는 기본적으로 파일크기에 대한 제한이 없다.

5. 구현 난이도: TFTP는 간단한 구조를 가지고 있어 비교적 구현이 쉽기 때문에 임베디드 시스템에서 많이 쓰이며, FTP는 보다 복잡한 구조를 가지고 있어 구현하기 어려울 수 있다.


 

 

 

 

 

 

 

 

TFTP 패킷 구조

 

+-----------------------------------+
|  IP Header   | UDP Header | TFTP  |
+-----------------------------------+

 

데이터 전송을 위해 TFTP는 앞에 IP 헤더와 UDP 헤더를 추가한다. IP 헤더는 IP 프로토콜에서 사용하는 헤더로, 출발지 IP 주소와 목적지 IP 주소 등의 정보를 담고 있고, UDP 헤더는 UDP 프로토콜에서 사용하는 헤더로, 출발지 포트 번호와 목적지 포트 번호 등의 정보를 담고 있다.

패킷이 도착하면 IP 헤더는 Network Layer에서 처리되고, UDP헤더는 Transport Layer에서 처리된다. TFTP는 UDP 페이로드에 포함된다.

 

 

 

 

 

 

 

 

 

TFTP 패킷의 종류

 

TFTP에는 다섯가지 종류의 패킷이 있다. 이 패킷들은 모두 패킷의 맨 앞에 2 byte 크기의 opcode가 포함되며, 이 opcode에 따라 결정되는 패킷의 종류는 다음과 같다.

그리고 TFTP 패킷에 포함되는 2 bytes 이상의 필드는 big endian 바이트 오더를 따른다.

 

opcode operation
1 RRQ (Read Request)
2 WRQ (Write Request)
3 DATA
4 ACK
5 ERROR

 

 

 

 

 

RRQ와 WRQ 패킷의 구조

 

2 bytes     string    1 byte     string   1 byte
------------------------------------------------
| Opcode |  Filename  |   0  |    Mode    |   0  |
------------------------------------------------

 

RRQ 패킷인경우 Opcode는 1, WRQ 패킷인 경우 Opcode는 2로 고정이다.

 

Filename과 Mode는 문자열 형태의 값이고 NULL문자(\0)로 끝나야 한다. 위 도식에도 그 점이 나타나있다.

 

Filename은 요청하는 파일 이름을 나타내는 값이고, Mode는 파일 전송 방식을 지정하는 값으로 "netascii", "octet", "mail" 중 하나를 선택할 수 있다.

 

TFTP에서 가장 일반적으로 사용되는 Mode는 "octet"이다. 이 모드는 8비트(1바이트) 바이너리 데이터를 전송할 수 있도록 지원된다. "netascii"모드는 ASCII 문자집합을 사용하는 텍스트 데이터 전송에 최적화되어 있는데, 운영체제에 맞게 개행문자를 변환해준다는 차이가 있다. 그리고 "mail" 모드는 거의 사용되지 않는다.

 

 

 

 

 

DATA 패킷의 구조

 

2 bytes     2 bytes      n bytes
----------------------------------
| Opcode |   Block #  |   Data     |
----------------------------------

 

DATA 패킷의 Opcode는 3으로 고정이고, Block Number 와 Data 필드로 구성되어 있다.

 

Block Number 필드는 해당 블록의 번호를 나타낸다. 블록 번호는 1로 시작해서 새로운 데이터 블록마다 하나씩 증가하여 새 패킷과 중복 패킷을 구별할 수 있도록 한다.

 

Data 필드의 길이는 0~512바이트이다. 길이가 512바이트인 경우 해당 블록은 마지막 데이터 블록이 아닌 것으로 간주되고, 길이가 0~511바이트 사이이면 이를 전송완료 신호로 처리한다.

 

 

 

 

 

 

 

ACK 패킷의 구조

 

 2 bytes     2 bytes
 ---------------------
| Opcode |  Block #  |
 ---------------------

 

ACK 패킷은 Opcode는 4로 고정이며, Block Number 필드로 구성되어 있다.

 

모는 패킷은 확인될 필요가 있으며, ACK 패킷의 Block Number는 확인된 데이터 패킷의 블록 번호를 반영한다.

 

다음 데이터 패킷을 보내는 행위는 이전 데이터 패킷에 대한 ACK 패킷이 확인된 것으로 간주된다.

서버가 클라이언트로부터 RRQ를 수신하면 바로 DATA 패킷(Block 1)을 보내거나 ERROR 패킷을 보내 확인하고, 서버가 WRQ를 수신하면 Block Number가 0인 ACK 패킷 또는 ERROR 패킷을 보내 확인한다.

 

 

 

 

 

 

 

 

 

ERROR 패킷의 구조

 

2 bytes     2 bytes      string    1 byte
-----------------------------------------
| Opcode |  ErrorCode |   ErrMsg   |   0  |
-----------------------------------------

 

ERROR 패킷의 Opcode는 5로 고정이며, ErrorCode, ErrMsg, NULL 바이트(0) 필드로 구성되어 있다. 

 

ERROR 패킷은 모든 패킷에 대한 확인응답으로 사용될 수 있으며, ErrorCode는 오류의 종류를 나타내는 integer값으로 RFC 1350 문서 appendix에 정의되어 있다. ErrorMsg의 경우 사람이 읽을 수 있는 문자열 형태로 마지막은 NULL byte로 끝나야한다.

 

 

   Value     Meaning

   0         Not defined, see error message (if any).
   1         File not found.
   2         Access violation.
   3         Disk full or allocation exceeded.
   4         Illegal TFTP operation.
   5         Unknown transfer ID.
   6         File already exists.
   7         No such user.

 

 

 

 

 

 

 

 

 

서버에 파일 읽기 요청(RRQ)을 보내고 파일을 전송받는 과정

 

    Client                             Server
     |                                  |
     |       RRQ (Opcode 1)             |
     |--------------------------------->|
     |      Data Packet (Block 1)       |
     |<---------------------------------|
     |      ACK (Block 1)               |
     |--------------------------------->|
     |      Data Packet (Block 2)       |
     |<---------------------------------|
     |      ACK (Block 2)               |
     |--------------------------------->|
     |      ...                         |
     |--------------------------------->|
     |      Data Packet (Last Block)    |
     |<---------------------------------|
     |      ACK (Last Block)            |
     |--------------------------------->|

 

1. 먼저 클라이언트가 파일 읽기 요청(RRQ) 패킷을 서버에 전송한다.

2. 서버는 해당 파일을 찾아서 첫 번째 데이터 패킷을 전송한다.

3. 클라이언트는 데이터 패킷을 받고, ACK 패킷을 서버에 전송하여 데이터 패킷이 제대로 도착했음을 알린다. 이 과정을 반복한다.

4. 클라이언트가 마지막 데이터 패킷(512바이트 미만)을 전송받으면 마지막 ACK 패킷을 서버에 전송한다.

마지막 데이터 패킷은 0~511바이트 데이터를 가지며, 클라이언트는 이를 전송 완료 신호로 인식하게 된다.

 

 

 

 

 

 

 

 

 

 

서버에 파일 쓰기 요청(WRQ)을 보내고 파일을 전송하는 과정

 

   Client                             Server
     |                                  |
     |       WRQ (Opcode 2)             |
     |--------------------------------->|
     |      ACK (Block 0)               |
     |<---------------------------------|
     |      Data Packet (Block 1)       |
     |--------------------------------->|
     |      ACK (Block 1)               |
     |<---------------------------------|
     |      Data Packet (Block 2)       |
     |--------------------------------->|
     |      ACK (Block 2)               |
     |<---------------------------------|
     |      ...                         |
     |--------------------------------->|
     |      Data Packet (Last Block)    |
     |--------------------------------->|
     |      ACK (Last Block)            |
     |<---------------------------------|

 

1. 먼저 클라이언트가 파일 쓰기 요청(WRQ) 패킷을 서버에 전송한다. 

2. 서버는 해당 파일을 생성하고, 첫 번째 ACK 패킷을 전송한다.

3. 클라이언트는 ACK 패킷을 받고, 첫 번째 데이터 패킷을 전송하고, 서버는 데이터 패킷을 받으면, ACK 패킷을 전송하여 데이터 패킷이 제대로 도착했음을 알린다. 이 과정을 반복한다.

4. 서버가 클라이언트로부터 마지막 데이터 패킷을 전송받으면, 마지막 ACK 패킷을 전송한다.

 

 

 

 

 

Reference : 

https://www.freesoft.org/CIE/RFC/1350/index.htm

 

RFC 1350

Connected: An Internet Encyclopedia RFC 1350 Up: Connected: An Internet Encyclopedia Up: Requests For Comments Next: 1. Purpose RFC 1350 RFC 1350 Network Working Group Request For Comments: 1350 STD: 33 Obsoletes: RFC 783 K. Sollins MIT July 1992 THE TFTP

www.freesoft.org

 

'임베디드 개발 > 펌웨어' 카테고리의 다른 글

CRC-32  (2) 2023.05.07
Online CRC 계산 사이트  (0) 2023.05.07
SoC와 MCU의 차이  (0) 2023.04.09
SBC(Single-Board Computer)  (0) 2023.04.09
Analog Multiplexer/Demultiplexer  (0) 2023.03.31