맨위로가기

형식-길이-값

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

형식-길이-값(TLV)은 타입(Type), 길이(Length), 값(Value) 필드로 구성된 데이터 표현 방식이다. 타입 필드는 데이터의 종류를 나타내는 바이너리 코드이고, 길이 필드는 값 필드의 크기를 나타내며, 값 필드는 실제 데이터를 포함한다. TLV는 유연성과 확장성이 뛰어나고, 효율적인 구문 분석 및 순서 독립성을 제공하여 다양한 프로토콜에서 사용된다. 주요 사용 사례로는 링크 계층 발견 프로토콜(LLDP), 공통 오픈 정책 서비스(COPS), IS-IS, RADIUS 등이 있으며, TLS, SSH, DHCP 등에서도 활용된다. 다른 데이터 표현 방식으로는 고정 필드를 사용하는 TCP/IP 프로토콜, "필드: 값" 쌍 형식의 텍스트를 사용하는 HTTP, ASN.1, XML 등이 있다.

더 읽어볼만한 페이지

  • 데이터 직렬화 포맷 - XML
    XML은 태그 중첩 방식 구문을 사용하는 범용 언어로서, 인터넷을 통한 구조화된 문서 및 데이터 공유를 용이하게 하고, 웰 폼 및 유효 XML 문서 개념을 통해 구문 정확성을 검사하며, 데이터 교환 등 다양한 분야에서 널리 사용된다.
  • 데이터 직렬화 포맷 - S-표현식
    S-표현식은 Lisp 구문에서 소스 코드와 데이터를 표현하는 기본 구조로, 원자와 `(x . y)` 형태의 표현식으로 정의되며, 이진 트리 표현, 다양한 데이터 형식 지원, 그리고 여러 분야에서 활용된다.
  • 데이터 전송 - 대역폭 제한
    대역폭 제한은 네트워크 혼잡 방지, 특정 사용자 과도한 사용 방지, 서비스 품질 관리 등을 위해 컴퓨터 네트워크에서 데이터 전송 속도를 인위적으로 제한하는 기술이다.
  • 데이터 전송 - 데이터 링크
    데이터 링크는 데이터를 송수신하기 위한 통신 연결로, 단방향, 반이중, 전이중 통신으로 나뉘며, 다양한 분야에서 활용되고 특히 항공 분야에서 항공 교통 관제 및 정보 교환, 무인 시스템 제어에 사용된다.
  • 인터넷 표준 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
  • 인터넷 표준 - IPv6
    IPv6는 IPv4 주소 고갈 문제를 해결하고자 개발된 차세대 인터넷 프로토콜로, 128비트 주소 체계를 통해 사실상 무한대에 가까운 IP 주소를 제공하며, 주소 자동 설정, 패킷 처리 효율성 향상, 보안 기능 강화 등의 특징을 갖는다.
형식-길이-값

2. 상세

형식-길이-값(TLV)은 데이터를 표현하는 방식으로, 이름처럼 타입(Type), 길이(Length), 값(Value) 세 가지 필드로 구성된다. 일반적으로 타입과 길이 필드는 1~4바이트 정도의 고정된 크기를 가지며, 값 필드는 가변적인 크기를 가진다.

각 필드는 다음과 같은 역할을 한다:


  • '''타입(Type)''': 해당 데이터 부분이 어떤 종류의 정보인지를 나타내는 바이너리 코드. 간단한 영숫자로 표현되기도 한다.
  • '''길이(Length)''': 이어지는 값(Value) 필드의 크기를 (주로 바이트 단위로) 나타낸다.
  • '''값(Value)''': 실제 데이터 내용을 담고 있는 가변 크기의 바이트 배열이다.


TLV 방식을 사용하면 다음과 같은 장점이 있다:

  • 정해진 규칙에 따라 메시지를 쉽게 해석(파싱)할 수 있다.
  • 메시지를 받는 쪽에서 모르는 타입의 데이터가 있더라도, 길이 정보를 이용해 해당 부분을 건너뛰고 나머지 부분을 계속 처리할 수 있다. 이는 XML에서 알 수 없는 태그를 건너뛰는 것과 유사하며, 프로토콜 버전이 업데이트되어 새로운 요소가 추가되더라도 이전 버전 시스템과의 호환성을 유지하는 데 도움이 된다.
  • TLV 요소들은 메시지 내에서 순서에 구애받지 않고 유연하게 배치될 수 있다.
  • 주로 이진 프로토콜에서 사용되어, 텍스트 기반 프로토콜에 비해 데이터를 더 작게 표현하고 처리 속도도 빠르다.


예를 들어 "전화 걸기" 명령을 TLV로 표현해 보자.

시스템 첫 버전(버전 1)에서는 "명령"과 "수신 전화번호" 두 정보만 사용한다고 가정하면, 메시지는 다음과 같을 수 있다:

: 'command_c'/4/'makeCall_c'/'phoneNumberToCall_c'/8/"722-4246"

여기서 'command_c', 'makeCall_c', 'phoneNumberToCall_c'는 타입을 나타내는 식별자(정수 값 등)이고, 4와 8은 각 값 필드의 길이를 의미한다.

이후 시스템이 업데이트되어(버전 2) "발신 전화번호" 정보가 추가되면 메시지는 다음과 같이 확장될 수 있다:

: 'command_c'/4/'makeCall_c'/'callingNumber_c'/14/"1-613-715-9719"/'phoneNumberToCall_c'/8/"722-4246"

만약 버전 1 시스템이 이 버전 2 메시지를 받게 되면, 먼저 아는 타입인 'command_c'를 처리한다. 다음으로 모르는 타입인 'callingNumber_c'를 만나면, 해당 타입 필드를 읽고 이해할 수 없음을 인지한다. 하지만 바로 뒤의 길이 필드 값(14)을 읽고, 그 길이만큼(14바이트) 건너뛴다. 그 후 다시 아는 타입인 'phoneNumberToCall_c'를 만나 정상적으로 처리할 수 있다.

이러한 TLV 형식은 링크 계층 발견 프로토콜(LLDP)에서 조직 고유 정보를 패킷에 추가하는 데 사용되는 등 실제 네트워크 환경에서 널리 쓰인다. LLDP 외에도 공통 오픈 정책 서비스(COPS), IS-IS, RADIUS와 같은 여러 프로토콜에서 TLV 구조를 활용하고 있다.

2. 1. 타입 (Type)

타입(Type) 필드는 메시지의 특정 부분이 어떤 종류의 데이터를 나타내는지 알려주는 바이너리 코드이다.[1] 예를 들어, 해당 데이터가 정수, 문자열, 또는 IP 주소인지를 식별하는 데 사용된다. 이 코드는 종종 간단한 영숫자로 표현되기도 한다.[1] 타입 필드는 일반적으로 1바이트에서 4바이트 사이의 고정된 크기를 가진다.[1]

예시로 사용된 "전화 걸기" 명령에서는 command_c, makeCall_c, phoneNumberToCall_c 와 같은 식별자들이 타입에 해당하며, 이들은 특정 동작이나 데이터 종류(예: 명령어, 수신 전화번호)를 나타내는 정수 값으로 표현될 수 있다.[1]

2. 2. 길이 (Length)

길이(Length) 필드는 이어지는 값(Value) 필드의 크기를 나타내며, 일반적으로 바이트 단위로 표현된다. 유형(Type) 필드와 마찬가지로 길이 필드 자체의 크기는 보통 1~4바이트 정도로 고정되어 있다.

이 필드는 메시지를 해석(파싱)할 때 중요한 역할을 한다. 특히, 메시지를 수신한 시스템이 특정 유형(Type)의 요소를 알지 못할 경우, 길이 필드의 값을 읽어 해당 요소의 값(Value) 부분이 끝나는 지점까지 건너뛸 수 있게 해준다. 이를 통해 새로운 요소가 추가된 최신 버전의 메시지라도 이전 버전의 시스템에서 안전하게 처리할 수 있다.

예를 들어, 전화 걸기 명령에서 버전 1 시스템은 "명령"과 "수신 전화번호" 요소만 알고 있다고 가정하자. 만약 "발신 전화번호" 요소가 추가된 버전 2 메시지를 받으면, 버전 1 시스템은 먼저 "명령" 요소를 처리한다. 다음으로 알 수 없는 "발신 전화번호" 유형을 만나면, 해당 요소의 길이 필드 값(예: 14)을 읽고, 그 길이만큼 건너뛴 후 다음 요소인 "수신 전화번호"를 정상적으로 처리할 수 있다. 이러한 방식은 링크 계층 발견 프로토콜(LLDP) 등 다양한 이진 프로토콜에서 활용된다.

2. 3. 값 (Value)

값(Value) 필드는 형식-길이-값(TLV) 구조에서 실제 데이터를 담는 부분이다. 이 필드는 가변 크기를 가지며, 메시지의 해당 부분에 대한 데이터를 포함하는 일련의 바이트로 구성된다. 값 필드의 구체적인 크기는 바로 앞의 길이(Length) 필드에 명시된 값(일반적으로 바이트 단위)에 의해 결정된다.

예를 들어, 전화 걸기 명령을 TLV 형식으로 표현할 때, "수신 전화번호"에 해당하는 값은 실제 전화번호 문자열이 된다. 만약 값이 `"722-4246"`이라면, 이 8개의 문자(바이트)가 값 필드의 내용이며, 길이 필드에는 8이 기록된다. 마찬가지로 "발신 전화번호" 값이 `"1-613-715-9719"`라면, 이 14개의 문자(바이트)가 값 필드를 구성하고 길이 필드에는 14가 기록된다.

3. 장점

TLV(Type-Length-Value) 표현 방식은 데이터 구조화 및 전송에 있어 여러 가지 이점을 제공한다. 주요 장점으로는 메시지 구조의 유연성과 확장성을 높여 새로운 정보 유형을 쉽게 추가하고 버전 간 호환성을 유지할 수 있다는 점, 이진 프로토콜 환경에서의 효율적인 구문 분석과 데이터 처리 속도 향상, 그리고 메시지 내 요소들의 순서에 제약을 덜 받는다는 점 등을 들 수 있다. 이러한 특징 덕분에 다양한 통신 프로토콜에서 널리 활용된다.

3. 1. 유연성 및 확장성

형식-길이-값(TLV) 방식은 메시지 구조를 유연하게 만들고 프로토콜을 확장하기 쉽게 하는 여러 장점을 제공한다.
새로운 요소 추가의 용이성TLV 구조에서는 새로운 종류의 정보(타입)를 기존 메시지 형식에 쉽게 추가할 수 있다. 예를 들어, 어떤 통신 프로토콜의 초기 버전(버전 1)에서는 "전화 걸기" 명령을 위해 '명령'과 '수신 전화번호' 정보만 사용했다고 가정해 보자.

  • 버전 1: `command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246"`
  • 여기서 `command_c`, `makeCall_c`, `phoneNumberToCall_c`는 각 필드의 종류(타입)를 나타내는 정수 값이고, 4와 8은 값(데이터)의 길이를 바이트 단위로 나타낸다.


이후 프로토콜 버전 2에서 '발신 전화번호'라는 새로운 정보를 추가해야 할 경우, 단순히 해당 TLV 요소를 메시지 중간에 삽입하면 된다.

  • 버전 2: `command_c/4/makeCall_c/callingNumber_c/14/"1-613-715-9719"/phoneNumberToCall_c/8/"722-4246"`

버전 호환성이러한 확장 방식은 버전 간 호환성을 유지하는 데 유리하다. 구 버전(버전 1) 시스템이 새로운 버전(버전 2)의 메시지를 받더라도 문제를 일으키지 않는다.

구 버전 시스템이 버전 2 메시지를 수신하는 과정은 다음과 같다.

1. 먼저 `command_c` 요소를 해석한다.

2. 다음으로 `callingNumber_c` 요소를 만나지만, 이 타입은 버전 1 시스템이 알지 못하는 정보다.

3. 이때 시스템은 타입(`callingNumber_c`)을 인식하지 못하더라도 길이 필드(14)를 읽고, 해당 길이만큼의 데이터(값)를 건너뛴다.

4. 그 후 다음 요소인 `phoneNumberToCall_c`를 정상적으로 읽고 처리할 수 있다.

이처럼 알 수 없는 타입의 정보는 건너뛸 수 있기 때문에, 새로운 기능이 추가된 프로토콜에서도 구 버전 시스템이 기본적인 동작을 유지할 수 있다. 이는 마치 웹 페이지에서 알 수 없는 XML 태그를 브라우저가 무시하고 넘어가는 방식과 유사하다.
기타 유연성

  • TLV 요소들은 메시지 내에서 반드시 정해진 순서대로 올 필요 없이, 비교적 자유로운 순서로 배치될 수 있다.
  • 이러한 특징 덕분에 TLV는 LLDP, COPS, IS-IS, RADIUS 등 다양한 이진 프로토콜에서 활용된다. LLDP의 경우, 조직 고유의 정보를 TLV 형식으로 패킷에 넣어 확장성을 확보하기도 한다.

3. 2. 효율적인 구문 분석

TLV 표현 방식의 장점은 다음과 같다.

  • TLV 시퀀스는 일반화된 구문 분석 함수를 사용하여 쉽게 검색할 수 있다.
  • 이전 노드에서 수신된 새로운 메시지 요소는 안전하게 건너뛸 수 있으며 나머지 메시지를 구문 분석할 수 있다. 이는 알 수 없는 XML 태그를 안전하게 건너뛸 수 있는 방식과 유사하다.
  • TLV 요소는 메시지 본문 내에서 어떤 순서로든 배치될 수 있다.
  • TLV 요소는 일반적으로 바이너리 형식 및 이진 프로토콜에서 사용되므로, 텍스트 기반 프로토콜에 비해 구문 분석 속도가 빠르고 데이터 크기가 작다는 장점이 있다.

3. 3. 순서 독립성

TLV 요소는 메시지 본문 내에서 어떤 순서로든 배치할 수 있다.

4. 예시

형식-길이-값(TLV) 인코딩 방식은 통신 프로토콜에서 메시지를 구조화할 때 유용하게 사용된다. 예를 들어, 특정 통신 시스템의 버전이 업데이트되어 메시지에 새로운 정보 필드가 추가되더라도, 이전 버전의 시스템은 자신이 인식하지 못하는 새로운 필드를 만났을 때 해당 필드의 길이 정보(Length)를 읽어 그만큼 건너뛰고 다음 필드를 처리할 수 있다. 이러한 방식은 시스템 버전 간의 하위 호환성을 유지하는 데 큰 장점을 가진다.

대표적인 예로 링크 계층 발견 프로토콜(LLDP)는 조직 고유의 정보를 TLV 형식을 사용하여 패킷에 포함시키는 것을 허용한다. 이 외에도 공통 오픈 정책 서비스(COPS), IS-IS, RADIUS 등 다양한 네트워크 프로토콜에서 TLV 형식이 활용되고 있다.

4. 1. 실제 사용 예시

형식-길이-값(TLV) 인코딩의 실제 사용 예시로 "전화 걸기" 명령을 들 수 있다.

초기 버전(버전 1)의 시스템에서는 "전화 걸기" 명령이 '명령'과 '수신 전화번호'라는 두 가지 요소로 구성된다고 가정해 보자. 이는 다음과 같이 표현될 수 있다.

: `command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246"`

여기서 `command_c`, `makeCall_c`, `phoneNumberToCall_c`는 각 데이터의 종류(Type)를 나타내는 정수 값이며, 4와 8은 해당 데이터 값(Value)의 길이(Length)를 의미한다.

이후 시스템이 개선되어 새로운 요소인 '발신 전화번호'가 추가된 버전 2가 나왔다고 가정하자. 버전 2 시스템의 메시지는 다음과 같은 형식이 될 수 있다.

: `command_c/4/makeCall_c/callingNumber_c/14/"1-613-715-9719"/phoneNumberToCall_c/8/"722-4246"`

만약 버전 1 시스템이 버전 2 시스템에서 보낸 이 메시지를 받는다면, 먼저 자신이 이해할 수 있는 `command_c` 요소를 읽어 처리한다. 다음으로 `callingNumber_c` 요소를 만나지만, 버전 1 시스템은 이 요소의 종류(Type)를 알지 못한다. 이때 TLV 방식 덕분에 시스템은 해당 요소의 길이 필드(14)를 읽고, 그 길이만큼 데이터를 건너뛸 수 있다. 그리고 나서 자신이 이해할 수 있는 다음 요소인 `phoneNumberToCall_c`를 정상적으로 읽어 처리하게 된다. 이러한 방식은 링크 계층 발견 프로토콜(LLDP) 등에서 활용된다.

4. 1. 1. 전송 프로토콜

형식-길이-값(TLV) 인코딩은 다양한 통신 프로토콜에서 메시지나 데이터 요소를 구조화하는 데 사용된다. 주요 사용 예는 다음과 같다.

  • TLS (이전 버전인 SSL 포함): TLV 인코딩된 메시지를 사용한다.
  • SSH
  • COPS
  • IS-IS
  • RADIUS
  • LLDP: LLDP 패킷 내에서 TLV 요소를 사용하여 조직별 정보를 전송할 수 있도록 한다.
  • MRP: 조직별 정보를 TLV 형식으로 허용한다.
  • DHCP: 옵션 정보를 TLV 형식으로 인코딩하여 사용한다.
  • GSM 휴대폰의 RR 프로토콜 (3GPP 04.18): 각 메시지를 정보 요소(TLV)의 순서로 정의한다.


TLV 방식의 장점 중 하나는 하위 호환성이다. 예를 들어, 특정 통신 시스템의 초기 버전(버전 1)에서는 '명령'과 '수신 전화번호'라는 두 가지 정보 요소(TLV)만 사용한다고 가정하자. 메시지 형식은 대략 `명령_종류/길이/값/수신번호_종류/길이/값` 과 같을 것이다.

이후 시스템이 개선되어(버전 2) 새로운 정보 요소인 '발신 전화번호'가 추가되었다고 하자. 버전 2 시스템이 보내는 메시지는 `명령_종류/길이/값/발신번호_종류/길이/값/수신번호_종류/길이/값` 형식이 된다.

만약 버전 1 시스템이 버전 2 시스템에서 보낸 이 메시지를 받는다면, 먼저 '명령' 요소를 읽어 처리한다. 다음으로 '발신 전화번호' 요소를 만나지만, 버전 1 시스템은 이 요소의 종류(Type)를 알지 못한다. 이때 TLV 방식 덕분에 시스템은 해당 요소의 길이(Length) 필드를 읽고, 그 길이만큼 데이터를 건너뛸 수 있다. 그리고 나서 자신이 이해할 수 있는 다음 요소인 '수신 전화번호'를 정상적으로 읽어 처리하게 된다. 이처럼 TLV는 프로토콜 확장에 유연성을 제공한다. 이러한 방식은 LLDP 등에서 활용된다.

4. 1. 2. 데이터 저장 형식


  • IFF
  • 매트 로스카는 마크업 태그에 TLV를 사용한다.
  • QTFF (MPEG-4 컨테이너의 기반)

4. 1. 3. 기타

ubus는 OpenWrt에서 IPC에 사용된다.[1]

4. 2. 예시 설명

형식-길이-값(TLV) 인코딩 방식은 특정 메시지를 예로 들어 설명할 수 있다. 가령 "전화 걸기" 명령을 처리하는 시스템을 생각해 볼 수 있다. 초기 버전(버전 1)에서는 단순히 "명령"과 "수신 전화번호" 정보만 포함하여 메시지를 구성할 수 있다.

이후 시스템이 업데이트되어 새로운 기능(예: "발신 전화번호" 표시)이 추가되면(버전 2), 해당 정보를 새로운 요소로 메시지에 포함시킬 수 있다. 이때 TLV 방식의 장점이 드러난다. 버전 1 시스템이 버전 2에서 온 메시지를 받더라도, 자신이 이해하지 못하는 새로운 요소("발신 전화번호")를 만나면 해당 요소의 '길이' 정보만을 읽어 그만큼 건너뛰고, 자신이 아는 다음 요소("수신 전화번호")를 정상적으로 처리할 수 있다. 이러한 방식으로 서로 다른 버전의 시스템 간 호환성을 유지하는 것이 가능하다.

이러한 TLV 형식은 링크 계층 발견 프로토콜(LLDP)에서 조직 고유 정보를 패킷에 포함시키는 데 사용되며, 공통 오픈 정책 서비스(COPS), IS-IS, RADIUS와 같은 다른 네트워크 프로토콜에서도 활용된다.

4. 2. 1. 버전 1

전화 걸기 메시지를 예로 들면, 시스템의 첫 번째 버전(버전 1)에서는 "명령"과 "수신 전화번호"라는 두 가지 메시지 요소를 사용할 수 있다. 예를 들어 다음과 같은 형식이다.

command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246"

여기서 command_c, makeCall_c, phoneNumberToCall_c는 특정 작업을 나타내는 정수 값이며, 숫자 4와 8은 각각 뒤따르는 "값" 필드, 즉 makeCall_c와 "722-4246"의 길이를 바이트 단위로 나타낸다.

4. 2. 2. 버전 2

형식-길이-값(TLV) 인코딩 방식은 시스템 버전이 업데이트되면서 새로운 필드가 추가되더라도 이전 버전 시스템과의 호환성을 유지할 수 있다는 장점이 있다. "전화 걸기" 명령을 예로 들어 설명하면 다음과 같다.

시스템의 첫 번째 버전(버전 1)에서는 "명령"과 "수신 전화번호" 두 가지 요소만 사용한다.

`command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246"`

여기서 `command_c`, `makeCall_c`, `phoneNumberToCall_c`는 각 필드를 나타내는 식별자(정수 상수 등)이고, 숫자 4와 8은 뒤따르는 값("makeCall_c", "722-4246")의 길이를 바이트 단위로 나타낸다.

이후 시스템이 업데이트되어 버전 2에서는 "발신 전화번호" 필드를 새로 추가할 수 있다.

`command_c/4/makeCall_c/callingNumber_c/14/"1-613-715-9719"/phoneNumberToCall_c/8/"722-4246"`

만약 버전 2 시스템에서 보낸 이 메시지를 버전 1 시스템이 받게 되면, 버전 1 시스템은 먼저 아는 필드인 `command_c`와 그 값 `makeCall_c`를 읽는다. 다음으로 `callingNumber_c` 필드를 만나지만, 버전 1 시스템은 이 필드를 알지 못한다. 이때 TLV 방식의 장점이 나타나는데, 시스템은 모르는 필드 식별자(`callingNumber_c`)를 확인한 후, 바로 뒤에 오는 길이 정보(14)를 읽는다. 그리고 그 길이만큼(14바이트) 데이터를 건너뛴다. 그러면 자연스럽게 다음 필드인 `phoneNumberToCall_c`에 도달하게 되고, 이 필드는 버전 1 시스템도 알고 있으므로 정상적으로 값을 읽어 메시지 처리를 계속할 수 있다.

이러한 TLV 형식은 링크 계층 발견 프로토콜(LLDP)에서 조직 고유 정보를 패킷에 포함시키는 데 사용되며, 공통 오픈 정책 서비스(COPS), IS-IS, RADIUS와 같은 다른 네트워크 프로토콜에서도 활용된다.

5. 다른 데이터 표현 방식

TLV 외에도 데이터를 표현하는 다양한 방식이 존재한다.

핵심적인 TCP/IP 프로토콜(IP, TCP, UDP)에서는 미리 정의된 고정 길이 필드를 사용하는 방식이 있다. 응용 계층 프로토콜 중 일부(HTTP, FTP, SMTP, POP3, SIP 등)는 RFC 2822에 따라 "필드: 값" 쌍 형식의 텍스트를 사용하기도 한다.

ASN.1은 TLV 기반 인코딩 규칙(BER, DER)과 비-TLV 기반 규칙(PER, XER)을 모두 지정하며, CSN.1은 비-TLV 의미 체계를 사용하여 인코딩 규칙을 설명한다. 또한, XML도 네트워크의 서로 다른 노드 간 메시징 구현에 사용되는 방식 중 하나이다.

5. 1. 고정 필드 방식

핵심적인 TCP/IP 프로토콜, 특히 IP, TCP, UDP는 미리 정의된 고정 길이 필드를 사용한다.

5. 2. 텍스트 기반 "필드: 값" 쌍

응용 계층 프로토콜 중 일부, 예를 들어 HTTP/1.1 (및 표준화되지 않은 이전 버전), FTP, SMTP, POP3, SIP 등은 RFC 2822에 따라 "필드: 값" 쌍 형식의 텍스트를 사용한다. HTTP는 'Content-Length' 헤더로 페이로드의 길이를 나타내고, 빈 줄로 헤더와 페이로드를, 새 줄로 헤더를 서로 구분한다.

5. 3. ASN.1 및 CSN.1

ASN.1은, TLV 형식(BER, DER)과 비TLV 형식(PER, XER)의 포맷을 병용하고 있다.

CSN.1은 비-TLV 의미 체계를 사용하여 인코딩 규칙을 설명한다.

5. 4. XML

더 최근에는 XML이 네트워크의 서로 다른 노드 간의 메시징을 구현하는 데 사용되었다. 이러한 메시지에는 일반적으로 BEEP와 같이 줄 기반 텍스트 명령이 앞에 붙는다.


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com