[네트워크/프로토콜] BOOTP 에 대해서. BOOTP 패킷 형식(BOOTP Packet Format)

by Blogger 하얀쿠아
2017. 5. 7. 12:36 소프트웨어 Note/Embedded Linux

BOOTP 에 대해서. BOOTP 패킷 형식(BOOTP Packet Format)


위의 BOOTP 특성에서 알아봤듯이, BOOTP에서 정보를 교환한다는 것은 클라이언트가 보낸 요청과 서버가 보내는 답장 쌍을 이루는 것이다.

BOOTP도 일반적인 다른 '요청 / 응답 프로토콜'들과 마찬가지로 요청 및 응답에 사용되는 공통된 메시지 형식을 정의해서 사용하고 있다.


구현하기 나름이겠지만, 일반적으로 클라이언트는 요청메시지의 크기만큼의 메모리 공간을 모두 0으로 초기화 하는 것 부터 시작한다.

그런 다음 이전 항목에서 보았던 것처럼 각각의 메시지 필드를 채운 다음 요청을 서버로 보낸다.


사실 역시 구현하기 나름이겠지만, 일반적으로 서버측은 메세지를 처음부터 다시 작성하지 않고, 클라이언트로 부터 받은 요청을 메모리에 복사하고 특정 필드를 변경하여 응답을 작성한다.

BOOTP 메시지는 상당한 수의 필드를 포함하므로 메시지 형식이 상당히 크다.


UDP 데이터그램 내부의 BOOTP 메세지를 간단히 살펴보자.






IP패킷에 의해 캡슐화 된 UDP데이터그램이 있고,

UDP 데이터그램에 의해 캡슐화 된 BOOTP Message가 있다.



300 바이트, BOOTP Message의 전체 형식은 천천히 살펴보자.

아래 그림과 같다.





Field Name

Size(bytes)

Description

Op

1

Operation Code: 메시지의 타입을 지정함. 1은 요청, 2는 응답

HType

1

Hardware Type: 로컬 네트워크에서 사용하는 하드웨어 유형을 지정한다. ARP 메시지의 HRD필드와 동등한 방식으로 사용된다. 몇가지 공통된 값은 아래와 같다.

1 : Ethernet(10MB)

6 : IEEE 802 Networks

7 : ARCNET

15 : Frame Relay

16 : Asynchronous Transfer Mode(ATM)

17 : HDLC

18 : Fibre Channel

19 : Asynchronous Transfer Mode(ATM)

20 : Serial Line

HLen

1

Hardware Address Length: 이 메시지 내에서 하드웨어 주소의 길이를 지정함. 이더넷 혹은, IEEE 802 MAC 주소를 사용하는 다른 네트워크에서, 이 값은 6임.

이것은 ARP 필드 형식에서 비슷한 이름 (HLN)을 가진 필드와 동일함.

Hops

1

요청을 전달하기 전에 클라이언트에 의해 0으로 설정되고, BOOTP relay agent가 BOOTP 메시지를 포워딩 제어하는데 사용함

XID

4

Transaction Identifier: 클라이언트가 생성한 32비트  식별 값. BOOTP서버에서 받은 응답과 요청을 매칭시키기 위해 사용함.

Secs

2

Seconds: RFC 951에 의하면, 클라이언트는 이 필드에 “클라이언트가 부트를 시도한 시점부터 경과된 초단위 시간 값"을 넣는다. 이것은 BOOTP 서버에 정보를 제공함으로써, 어느것부터 응답해야 할지를 결정하는데 도움을 준다.

불행히도 이 정의는 다소 모호했기에, 전원이 켜진 직후부터의 시간값의 양인지 혹은 첫번째 BOOTREQUEST 메시지가 보내진 이후부터를 의미하는지 명확하지 않았다. 게다가 몇몇 장치는 이 필드를 잘못 구현하기까지 했다. 결론적으로 이 필드는 항상 사용되는 것이 아니다.

Flags

2

Flags: 원래 BOOTP 표준(RFC 951)에서는, 이 필드는 2바이트의 공백이었다.

RFC1542에서는 하나의 flag를 포함하는 ‘flags’ 필드로 변경되었다.

CIAddr

4

Client IP Address: 클라이언트가 계속 사용하려는 현재 IP 주소를 가지고 있으면, 이 필드에 그 원하는 IP 주소를 넣는다. 이 필드를 채우면 클라이언트는이 주소로 전송 된 유니 캐스트 IP 데이터 그램에 응답하기 위해 커밋합니다. 그렇지 않으면 이 필드를 모두 0으로 설정하여 서버에 주소 할당을 원한다는 것을 알려준다.

YIAddr

4

“Your” IP Address: 서버가 클라이언트에 지정하는 IP 주소. 이는 클라이언트가 현재 사용하는 IP 주소와 다를 수 있다.

SIAddr

4

Server IP Address: BOOTREPLY 메시지를 보내는 BOOTP 서버의 IP주소

GIAddr

4

Gateway IP Address: 이 필드는 BOOTP 릴레이 에이전트가 BOOTP 요청의 통신을 용이하게 하고 다른 서브넷이나 네트워크에있는 클라이언트와 서버간에 회신 할 때 BOOTP 메시지를 라우팅하는 데 사용된다. 이름을 이해하려면 "router"에 대한 이전 TCP / IP 용어는 "gateway"입니다. BOOTP 릴레이 에이전트는 일반적으로 라우터이다.

이 필드는 클라이언트가 0으로 설정하고 BOOTREPLY를 처리 할 때 클라이언트가 무시해야 한다. 이것은 특히 일반적인 IP 라우팅 용도로 사용될 기본 라우터 주소의 주소를 클라이언트에 제공하는 서버를 나타내지는 않는다.

CHAddr

16

Client Hardware Address: BOOTREPLY를 보내는 클라이언트의 L2 계층 하드웨어 주소. 장치의 할당 된 IP 주소를 검색하고 응답 메시지를 전달하는 데 사용된다.

SName

64

Server Name: BOOTREPLY를 보내는 서버는 이 필드에 서버이름을 지정하거나 지정하지 않을 수 있다. 이것은 간단한 텍스트로 "nickname"와 같은 게 될 수도 있고, 아니면 완전한 DNS 도메인 이름 (예 : "myserver.organization.org") 이 될 수도 있다.

클라이언트는 요청을 만들때, 이 필드값을 지정할 수 있다. 만약 지정한다면, 그것은 이 이름을 가진 BOOTP서버로부터만 응답을 원한다는 의미이다. 이것은 클라이언트가 한 서버에만 저장된 특정 부트 파일에 액세스 할 수 있도록하기 위해 수행 될 수 있다.

File

128

Boot Filename: 부트스트랩 과정을 완료하기 위해 클라이언트가 다운로드 받을 수 있는 부트 파일의 전체 디렉토리 경로와 파일이름을 포함하는 필드. 클라이언트는 여기에 텍스트로 설명을 입력하여 특정 유형의 파일을 요청할 수 있다. 혹은 이 필드를 공백으로 남겨두고, 서버가 기본 파일의 이름을 제공하게 할 수 있다.

Vend

64

Vendor-Specific Area: 원래는 제조사(공급업체)로 하여금 BOOTP를 다른 유형의 하드웨어 요구에 맞게 수정할 수 있도록 허용하는 필드다. 이 필드는 지금은 제조사 독립적인 설정 정보를 보관하는데에도 사용한다.



앞서 언급했지만, BOOTP 서버/클라이언트의 양측의 요청 및 응답 메세지는 UDP 메시지로 캡슐화되어 전송된다.

BOOTP 표준(rfc951)에서는 UDP checksum 사용을 'optional'로 정의하고 있다.

UDP checksum을 사용하면 데이터 무결성 오류를 방지 할 수 있으므로 권장된다.

그러나 이 기능은 종종 아주간단히 구현된 클라이언트 측에서는 받아 들일 수없는 처리 요구를 유발할 수도 있기때문에, checksum을 합법적으로 생략할 수도 있다.


참고로, 간결함을 위해, BOOTP는 메세지 패킷이 분할(fragmented) 되지 않는다고 가정한다.

이를통해 BOOTP 클라이언트는 분할된 메세지를 모으고, 시퀀스 넘버순서대로 다시 합치는 복잡한 과정을 피할수 있다.

패킷의 분할을 지원하지 않으면, 각 레이어 별로 길이가 초과되는 경우에 어떻게 처리되어야 하는가 고민이 생길수도 있다. 

하지만, BOOTP메세지는 모든 TCP/IP연결에서 요구되는 최소 MTU보다도 작은, 겨우 300바이트 길이이기 때문에, 일반적으로 이는 문제가 되지 않는다.




이 댓글을 비밀 댓글로

[네트워크/프로토콜] BOOTP 에 대해서. BOOTP 클라이언트/서버의 메세지전송과 주소설정 방법

by Blogger 하얀쿠아
2017. 5. 7. 11:57 소프트웨어 Note/Embedded Linux

BOOTP 에 대해서: BOOTP 클라이언트/서버의 메세지전송과 주소설정

BOOTP는 다양한 장치에 사용할 수 있지만, 최초 개발의 주된 동기 중 하나는 저장 장치가 없는 "멍청한"장치를 자동으로 구성하는 방법을 제공하는 것이었다.

대부분 이러한 멍청한 장치들은, 비교적 제한된 기능만을 가지고 있기때문에, 근사한 부팅 프로토콜을 지원하도록 요구하는 것은 사실 말이 되지않았다.

따라서 BOOTP는 복잡한 개념이나 근사한 개념 혹은 근사한 구현 요구사항 없이, 호스트 구성을 수행하는 복잡하지 않은 프로토콜이다.



BOOTP 클라이언트 및 서버

다른 많은 TCP / IP 프로토콜과 마찬가지로 BOOTP는 실제로 클라이언트 / 서버이다.
프로토콜의 작동은 BOOTP 클라이언트와 BOOTP 서버 간의 단일 메시지 교환으로 구성된다.

BOOTP 클라이언트는 구성해야하는 모든 유형의 장치가 될 수 있다.
BOOTP 서버는 BOOTP 클라이언트 요청에 응답하도록 특별히 설정된 네트워크 장치이며, 주소 지정 및 필요한 경우 클라이언트에 제공 할 수 있는 기타 정보로 프로그램이 구현된다.

BOOTP 서버는 서비스를 제공하는 클라이언트에 대한 특별한 정보 집합을 유지 관리한다.
여기에서 하나의 핵심 부분은 테이블이다.
이 테이블은 각 클라이언트의 하드웨어 (Layer 2, 데이터 링크 계층) 주소, 즉 MAC주소를 해당 장치에 할당 하고자 하는 IP 주소로 매핑하는 테이블이다.

클라이언트는 요청에서 하드웨어 주소를 지정하고, 서버는 이 주소를 사용하여 클라이언트의 IP 주소를 찾아서 클라이언트로 응답한다.
물론, 구현하기에 따라 다르고, 다른 기술도 사용할 수도 있겠지만, 매핑 테이블이 가장 일반적인 구현방법이다.


메시지 및 전송

그런데, BOOTP 메시징은 몇 가지 이유로인해, 계층 4 전송 프로토콜로 TCP가 아닌 UDP (User Datagram Protocol)를 사용한다. 

첫째, UDP는 다른 레이어 4 전송 프로토콜인 TCP보다 훨씬 덜 복잡하며, BOOTP와 같은 간단한 "요청 / 응답"프로토콜에 이상적이다.

둘째, 클라이언트가 분명히 BOOTP 서버의 주소를 알지 못하기 때문에 요청은 로컬 네트워크에서 브로드 캐스팅되야 한다.
UDP는 브로드 캐스트를 지원하지만 TCP는 브로드 캐스트를 지원하지 않는다.
BOOTP를 공부하는 정도라면 여러분들은 이미 알고 있을 것이다.

UDP는 BOOTP 서버에 대해 잘 알려진 (예약 된) 포트 번호 인 UDP 포트 67을 사용한다.
BOOTP 서버는 클라이언트가 보낸 이러한 브로드 캐스트 BOOTP 요청에 대해 포트 67에서 "수신 대기"한다.
요청을 처리 한 후 서버는 클라이언트에게 응답을 보낸다.
이 처리 방법은 클라이언트가 자체 주소를 알고 있는지 여부에 따라 다르다.


◎ 클라이언트가 주소를 알고 있는 경우
BOOTP 클라이언트가 이미 자신의 주소를 알고있는 경우가 있다. 이 경우는, BOOTP 서버가 이 주소를 직접 응답을 다시 보낼 때 사용할 수 있다.


◎ 클라이언트는 자신의 주소를 모르는 경우
물론 BOOTP는 주소를 모르는 클라이언트에게 IP 주소를 제공하기 위해 흔히 사용 된다. 
이것은 종종 "닭고기와 계란"문제라고 불리는데, 그 이유는 "닭고기와 계란"이라는 오래된 수수께끼와 같은 종류의 "고리"를 나타내기 때문이다.
이 딜레마를 해결하기 위해 BOOTP 서버에는 두 가지 선택지가 있다.
운영체제가 이를 지원하면 서버는 클라이언트의 하드웨어 주소를 사용하여 장치에 대한 ARP 항목을 만든 다음 레이어 2 유니 캐스트를 사용하여 응답을 전달할 수 있다.
그렇지 않으면 회신을 로컬 네트워크에서 브로드 캐스트로 전송해야한다.



브로드 캐스트 및 포트 사용

BOOTP 서버가 클라이언트로 다시 브로드캐스트 해야한다는 사실은 대부분의 TCP/IP 프로토콜이 클라이언트 포트를 사용하는 방식에서 약간의 변화가 필요하다.
일반적으로 클라이언트/서버 트랜잭션에 UDP 또는 TCP를 사용하는 클라이언트는 임시 또는 잠시사용하기 위한 포트 번호를 생성하여 요청메세지의 소스포트로 사용한다.

서버는 그 임시 포트 번호를 사용하여 클라이언트의 IP 주소로 응답을 보낸다.
임시 포트 번호는 특정 IP 주소에 대해 고유해야하지만, 네트워크의 모든 장치에서 고유하지는 않는다.

이해하기 쉽게 한가지 예를 들어 보면, 이런것이다.
하나의 네트워크상에 두 장치 A, B가 있다.
장치 A는 웹 서버에 대한 HTTP 요청에 임시 포트 번호 1248을 사용하고, 장치 B는 TCP/IP 스택에서 포트 번호 1248을 사용하여 DNS 요청을 보낼 수 있다.
서로다른 장치가, 동일한 네트워크상에 있다 하더라도, 동일한 포트 1248을 사용할 수 있다는 것이다.

BOOTP의 서버가 브로드캐스트이기 때문에 유니캐스트 전송을 사용하는 특정 장치를 대상으로하지 않는다.
즉, 일시적인 포트 번호로 안전하게 보낼 수 없다는 것을 의미한다.

네트워크상의 다른 장치는 다른 트랜잭션에 대해 동일한 임시 포트 번호를 선택했을 수 있으며 BOOTP 서버의 응답을 실수로 자기에게 보낸것으로 오인 할 수 있다.
이 문제를 피하기 위해 잘 알려진 다른 포트 번호가 BOOTP 클라이언트에만 사용된다.
UDP 포트 68 이 바로 그것이다.

클라이언트는 브로드캐스트 또는 유니캐스트 전송을 위해서 이 포트에서 수신 대기하지만, BOOTP 요청을 보낸적이 없는 클라이언트는 무시할 것이다. 
이 "이중 브로드 캐스트"BOOTP 통신 프로세스는 아래 그림에 나와 있으니 참고하자.

General Operation Of the Boot Protocol

이 그림을 간단히 설명하겠다.

장치 A는 IP 주소 및 기타 매개 변수를 확인하려고 시도하고 있다.

UDP 포트 67을 사용하여 로컬 네트워크에서 BOOTP 요청을 브로드캐스트 한 다음 포트 68에서 응답을 수신한다.

장치 D는 BOOTP 서버로 구성되어있고, 67 포트에서 수신 대기한다.

요청을 받으면 포트 68에서 A에게 IP 주소가 무엇인지 알려주는 브로드캐스트를 보낸다.

BOOTP는 브로드 캐스트를 사용하여 할당 된 IP 주소가없는 장치와의 통신을 허용하는 비교적 간단한 클라이언트/서버 프로토콜임을 생각하면 매우 간단한 과정이다.



세줄 요약 주요 개념

  1. BOOTP 클라이언트는 브로드 캐스트를 사용하여 청취 BOOTP 서버에 요청을 보낸다.
  2. 대부분의 경우 BOOTP 클라이언트 장치는 프로토콜을 사용할 때 자체 IP 주소를 알지 못한다. 
  3. 이런 이유 때문에 BOOTP 서버는 일반적으로 응답을 전송할 때 브로드 캐스트를 사용하여 클라이언트에 도달하는지 확인한다.

손실 된 메시지의 재전송

BOOTP 메시지 전송을 단순하게 하기위해 UDP를 사용할때의 단점은 전송 품질을 보장할 수 없다는 것이다.

UDP특성을 이미 알고 있겠지만, UDP는 신뢰할 수 없다.

즉, BOOTP 클라이언트로부터 전송된 요청메세지가 서버에 도착하기 전에 손실될수도 있고, 운좋게 서버에 도착했더라도, 클라이언트 방향으로 전송된 서버의 응답 메세지가  도착하지 않을 수 있다. 



이쯤 읽으면 '응? 장난하냐??' 하는 생각이 들겠지만, 진정하고 계속 읽어보자.

BOOTP는 이에대한 대비책을 가지고 있다.



UDP를 사용하는 다른 프로토콜과 마찬가지로 BOOTP 클라이언트도 재전송 타이머를 사용하여이 문제를 처리한다.

클라이언트가 일정 기간 후에 응답을받지 못하면 클라이언트는 요청을 다시 보낸다.


그러나 BOOTP 클라이언트는 재전송 전략을 구현하는 방법에 주의를 기울여야 한다.

한가지 문제시나리오를 가정해보자.
200대의 BOOTP 클라이언트가 있는 네트워크에서, 200대의 모든 클라이언트 전원이 꺼진다고 가정하겠다.
이 기계들은 거의 모두 비슷하게(심지어 동일하게) BOOTP가 구현되었을 것이기 때문에 전원이 다시 켜지면, 모두 재시작되며 거의 동시에 BOOTP 요청을 보내려고 할것이다.
왜? 구현이 동일하니깐.

대부분 이러한 문제로 인해 문제가 발생할 수 있다.
BOOTP 요청 메세지 일부가 손실되기도 할것이고, 심지어 서버가 과부하로 인해 일부 메세지를 drop해야 할 수도 있다. 
서버의 패킷큐 overflow 등의 이유가 예상된다.

그런데 모든 클라이언트는 전송을 실패했으므로 재전송을 하려 할 것이다.
이때, 각각의 클라이언트가 재전송을 위해 동일한 시간을 기다렸다가 재전송을 하게된다면?
그 시간이 지나면 모든 기계가 요청을 다시 보낼것이므로, 동일한 문제를 반복하게 될것이다. ...야 이 멍청이들아!!??

이와 같은 상황을 회피하기 위해 BOOTP 표준에서는 재전송주기 시간 값을 4 초부터 시작해서, 연속 시도를 위해 이 값을 지수적인 증가, 즉 두 배로 증가, 시키는 백 오프(Back-off) 방식을 사용할 것을 권장한다.
재전송을 위해서 말이다.
또한, 여러대의 BOOTP 클라이언트가 동시에 재전송을 하는 중첩 상황을 피할 수 있게 임의성 요소가 추가된다.
이 아이디어는 이더넷(ethernet)에서 사용되는 백 오프 방법과 매우 유사하다. 실제로 BOOTP 표준은 이더넷의 사양서(Specification)를 참조한다.

예를 들어, 첫 번째 재전송은 0에서 4 초 사이의 임의의 시간 간격 후에 발생시킨다. (임의의 양을 더하거나 뺀 값). 
필요한 경우 두 번째 재전송에서는, 0과 8 초 사이의 임의의 시간 간격에서 플러스 또는 마이너스 하는 등...
이렇게하면 재전송이 손실되는 가능성을 줄이는 데 도움이 되며, BOOTP의 과도한 트래픽으로 인해 네트워크가 중단되지 않도록 할 수 있다.




이 댓글을 비밀 댓글로

[네트워크/프로토콜] BOOTP 에 대해서. BOOTP란? BOOTP 특성?

by Blogger 하얀쿠아
2016. 12. 30. 02:19 소프트웨어 Note/Embedded Linux

BOOTP란? (bootstrap protocol)


Bootp는 TCP/IP상에서 자동 부팅을 위한 최초의 표준프로토콜이다.

디스크 장치가 없는 클라이언트를 구동시키기 위한 목적으로 개발되었다.

여기서, 디스크 장치가 없는 클라이언트라고 하면, 과거 Unix머신과 연결해서 사용하던 'X터미널' 과 같은 장비쯤 되시겠다.

이 터미널 장비는 디스크 장치가 없으므로, 장치의 설정정보를 저장할 곳이 마땅치 않게된다. 


그러니깐, 디스크 장치를 가지고 있는 Main Unix머신이 이 정보를 가지고 있다가, X터미널이 실행되고 Unix머신에게 연결하려고 신호를 보내면, Unix머신은 Bootp 서버를 이용해서 X터미널에게 이런 정보들을 알려주게 된다.

그러면 X터미널은 BOOTP클라이언트 쯤이 된다.

정확하게 말하면 클라이언트는(X터미널) BOOTP를 통해 3가지 정보를 제공받는다.


  1. IP주소
  2. 부트 파일이 있는 서버 이름
  3. 부트 파일 이름

하위 프로토콜로 UDP와 IP 프로토콜을 사용한다.


사실 BOOTP는 지금은 거의 사용되지 않는 구형 프로토콜이긴 하다.

이후 좀더 진보된 네트워크 관리 프로토콜이 DHCP의 기반이 된다.

게다가, BOOTP - DHCP가 완벽호환 되는 특징이 있어서,  BOOTP 클라이언트가 DHCP 서버와 통신이 가능하다.


만약 당신이 DHCP를 들어본적이 없다면, 당장은 간단히 설명하겠다.

DHCP는 '내가 누구?, 여긴 어디?' 에 대한 정보를 주는 프로토콜 쯤으로 이해해두자. 

즉, IP address, subnet mask address, DNS address, gateway address 와 같은 네트워크 그룹에 가입하기 위해 필요한 정보나, domain상에서 통용되는 터미널의 이름 등..을 전달해 준다고 보면 된다.


임베디드 개발보드에서는 tftp와 함께 사용되곤 한다.

즉, Bootloader에서 Kernel과 파일시스템 Image를 Host PC에서 Target board로 다운로드할 때, Host PC에 연결하기 위한 정보가 필요한데,

Bootp를 이용하면 Target board의 IP와 Host에 대한 정보를 Host PC에서 가져올 수 있도록 하는게 가능하다.



BOOTP 특성

몇가지 특성을 알면, BOOTP를 깊게 이해하는데 좀 더 수월할 것이다.


BOOTP는 클라이언트 - 서버 구조로 동작한다.


그리고 정적인 주소 설정 방식을 사용한다.

여기서 '정적인 주소 설정 방식' 이 무엇이냐면, 관리자에 의해 미리 정의되어있는 '물리주소 - IP주소' 간 매핑 테이블을 사용하는 방식이라고 생각하면된다.


또한 UDP에 의해 캡슐화 되고, 보통 TFTP와 함께 동작한다.

클라이언트 요청은 UDP 포트 68로 전달되고, 서버 응답은 UDP 포트 67로 전달된다.

요청메세지는 브로드캐스트로 전송되며, Source IP Address는 0.0.0.0 , Destination IP Address는 255.255.255.255 로 설정한다.


UDP로 전달되는 메세지 유실에 대한 대비책으로써, 재전송(Retransmission)과 시간초과(Timeout) 정책을 이용한다.

주소 설정 방식과, 재전송 등에 대해서는 아래 세부섹션에서 좀더 살펴보자.




BOOTP 의 RFC document

만약, 당신이 굉장히 네트워크에 관심이 많은 사람이어서, 

BOOTP에 대해 자세히 알고 싶다면 RFC 951와 RFC 1542를 참고하기 바란다.


일반적으로 RFC문서는 아래 주소에서 찾을 수 있다.


RFC문서 검색기 페이지 : https://www.rfc-editor.org/search/rfc_search.php




귀찮다면, 아래를 다운받자.


RFC 951 -- The Bootstrap Protocol (BOOTP) (ftp://nic.ddn.mil/rfc/rfc951.txt)

rfc951.txt


RFC 1542 Clarifications and Extensions for the Bootstrap ProtocolClarifications and Extensions for the Bootstrap Protocol

rfc1542.txt




또한, IETF라는 기구가 있다. '국제 인터넷 표준화 기구' 쯤으로 해석한다.

IETF는 Internet Engineering Task Force의 머릿글자이다.

이는 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 작업기구이다.

계속 관심이 간다면, 아래 홈페이지에서 rfc에 대한 몇몇 정보를 찾아보자.


IETF Homepage : http://www.ietf.org/rfc.html






Tftp 란


TFTP (Trivial File Transfer Protocol) 은 FTP와 같은 파일 전송 프로토콜이다.

하위 프로토콜로 IP, UDP프로토콜을 사용한다.

개발보드에서는 Bootloader에서 Kernel과 파일시스템 Image를 Host에서 Target으로 이더넷을 통하여 고속으로 다운로드하기 위해 사용한다.



Bootp와 Tftp를 활용한 개발보드의 초기 부팅방법


구체적인 활용 방법에 대해서는 기회가 된다면 내용을 추가하도록 하겠다.




이 댓글을 비밀 댓글로
    • 지나가던
    • 2019.11.21 12:35
    진정으로 저에게 도움되는 글 입니다. 감사합니다.