이번 강좌에서 배울 내용은 프로토콜을 만들려면 어떻게 해야 하는가에 대한 간단한 튜토리얼이라고 생각 해 주시기 바랍니다. 실제 프로그램을 만들고 하나하나 따라하기 식으로 한참동안 글을 작성했지만, 글을 쓰고 보니 이건 초보자를 위한 글도 아니요, 중급자를 위한 글도 아닌 애매한 글이 되어버리더군요. 조금 딱딱하지만 간단하게 정리하도록 하겠습니다.
프로토콜을 한 번 만들어 볼까요? 메신저 프로그램을 만든다고 가정하겠습니다.
구성도는 다음과 같습니다.
메신저 서버 --- 클라이언트
--- 클라이언트
--- 클라이언트
1. 원하는 기능 리스트 만들기
대표적인 기능 몇 가지만을 추려보도록 합니다.
(S는 Server, C는 Client를.. B는 Broadcast를 의미합니다)
- 채팅 기능 (1:1 채팅 , N:N 채팅) (C-> S-> C)
- 개인 설정내용 전송기능 (S-> C)
- 파일 전송하기 (C-> S-> C)
- 접속 알림 기능 (C-> S-> B)
2. 프로토콜 만들기
프로토콜을 만들 경우 패킷의 형태를 다음과 같이 만들도록 합니다. 대부분의 프로토콜은 다음의 형태를 가지고 있지만 프로그램에 따라서 전혀 다른 프로토콜 형식을 가지는 프로그램도 많습니다.
BUFFER (1450 byte max)
|
Buffer Header |
Buffer Data |
Buffer Header 항목에는 보통 다음에 올 Buffer Data가 어떠한 형태의 데이터인지를 구분해 줄 수 있는 항목이 들어오게 되며 그 외에 기록해야 할 항목들을 기록하게 됩니다.
프로토콜을 만들 때에는 다음을 유념 해 주셔야 합니다.
① 전체 기능을 포함할 수 있는 내용을 작성하도록 한다.
즉, 정해진 형태의 프로토콜만을 보고도 이것이 무슨 역할을 하는지를 알아낼 수 있어야 합니다.
② 특정 기능을 빼고는 Fixed Size로 작성하도록 하고 되도록 Fixed Size 프로토콜은 별도로 보내도록 한다.
한 번에 여러 개의 내용을 담아서 쏘게 되면 받아들이는 쪽에서 한 번에 그만큼 더 많은 작업을 한번에 해야 합니다. 하긴 이러한 부분은 사소한 부분일 테고 받아들이는 쪽에서 조금 더 안전한, 안정적인 작업을 할 수 있게 하는 경험상의 노하우라고 해 두죠.
물론 한 번에 많은 양의 정보를 보내게 되면 패킷의 전송율이 줄어드는 장점도 있겠지만 실제 패킷의 양이 늘어난다고 해서 네트워크 시스템에 부하가 걸릴 정도의 부담은 없습니다.
③ 보내야 하는 내용이 ON/OFF 정도의 내용일 때는 BIT로 보내도록 한다.
Char의 경우에는 8가지 정보를, Short int의 경우에는 총 16가지의 정보를 표시하는 것이 가능합니다. 조합한다면 더 많은 정보도 가능하겠지요. 1바이트에서 2바이트 정도면 많은 정보를 표시할 수 있는데 string 값을 넣는 일은 하지 마시기 바랍니다.
④ Variable 값의 경우는 반드시 내용 앞에 별도의 Length를 기록하도록 한다.
Fixed Size가 아닌 경우에는 모든 대상항목 앞에 별도로 Length를 기록해야 합니다. 여기서 얘기하는 부분은 위에서 언급한 Buffer Header 항목이 아닌 Buffer Data 항목도 포함되는 부분입니다.
⑤ 추후 프로그램의 확장을 고려하여 작성하도록 한다.
많은 분들이 간과하고 지나가시는 부분입니다. 프로토콜의 확장성을 고려하지 않는다면, 버전별 하위호환은 그냥 포기해야 한다는 얘기와 마찬가지입니다. 꼭 이부분도 신경 써 주시기 바랍니다.
이제 실제 사용할 프로토콜과 구조체를 만들어 봅니다.
먼저 Buffer Header 입니다
Length = 8 byte
Field { 타입 , 상태, 버젼 , 길이, 패킷 순번, reserved }
Type (타입) : 1 byte { 메시지, 파일, 개인별 설정내용, 온라인, ping }
Status (상태) : 1 byte { 서버 전송, 클라이언트 전송, Broadcast 전송 }
Version (버전) : 2 byte { Main Version , Minor Version }
Length (길이) : 2 byte – unsigned short
Packet no : 1 byte (max 4)
Reserved : 1 byte
위 내용을 그대로 구조체로 만들어 보겠습니다.
typedef struct _BUF_GHEADER
{
BYTE pkType;
BYTE pkStatus;
USHORT Version;
USHORT pkLength;
BYTE pkNo;
BYTE reserved;
} BUF_GHEADER, *pBUF_GHEADER;
Buffer Data 항목은 만들려면 실제로는 더 복잡합니다만, 이곳에서는 기능 구현의 목적보다는 프로토콜 작성에 의미를 두기 위해 간단하게 만들도록 하겠습니다.
Length = variable or fixed
Field { message format, file format, personal setting format }
각 필드에 대한 형식은 다음과 같습니다.
message format :
|
전체길이 |
길이 |
타입 |
데이터 |
길이 |
타입 |
데이터 |
File format :
|
전체 길이 |
세부 길이 |
데이터 |
Personal setting format
|
전체 길이 |
세부 길이 |
데이터 |
세부 길이 |
데이터 |
단순하게 만들긴 했습니다만, 조금 더 부연설명을 하겠습니다.
Message format의 경우에는 세부 항목으로 나뉘어진 이유가 이모티콘 등의 삽입으로 인한 것입니다. 다음과 같은 메시지를 보낸다고 해 볼까요?
“사랑해 자기. 쪽~ 알라븅”
여기에서 쪽~ 이 이모티콘의 그림이라고 할 경우 상대방 컴퓨터에서 움직이는 입술이 움찔움찔 하고 보여져야 한다면 위의 message format 같은 방식으로 해결해야 하는 것이 좋을 것입니다. 텍스트 + 이모티콘 + 텍스트의 형태로 전송되어져야 합니다. 대충 이해가 되시죠? 위와 같이 할 경우 파싱에 도움을 주는 프로토콜이 됩니다.
Personal setting도 마찬가지입니다. 네이트온의 경우에는 어디에서 설치해서 접속하던지, 자신의 친구목록이 저장되어져 나타나는 것을 알 수 있죠. 이것을 위한 기능이라고 생각하시면 됩니다. 그것을 전송하기 위한 포맷이 대충 저렇다고 보시면 됩니다.
자, 이제 위의 포맷을 어떻게 헤더로 정의할 것이냐.. 하는 문제가 남았는데요. 일부러 프로토콜을 만들면서 통일시키려고 한 것이 보일 것입니다. 즉 [전체길이] [세부길이] [내용] 의 경우인데요. 물론, buffer header에 뒤에 따라 나오는 데이터의 타입이 정해져 있긴 하지만, 각자의 포맷에 맞춰서 각자의 헤더를 만드는 것도 약간 비효율적이라 생각되죠. 같은 형식이 존재하니까요.. 그래서 다음과 같이 하나로 만들어 보겠습니다.
typedef struct _BUF_DATA
{
UINT tLength;
char* Data;
} BUF_DATA, *pBUF_DATA;
이전 강좌에서 variable length를 가지는 프로토콜의 경우에 어떻게 만들어야 하는지에 대해서 설명하겠다고 한 부분이 이것입니다. 즉, 통일되는 부분을 빼내어 구조체로 만들어 버리게 되면 그 다음은 타입에 의해서 구분만 해 주면 되는 것이지요. 위의 예는 사실 너무 간단해서 이렇게 작성하는 것에 대한 이점을 찾을 수 없을 지 몰라도 프로토콜이 좀 더 복잡해 지는 순간 제가 하고자 하는 이야기를 뼈져리게 느끼실 수 있을 겁니다.
헤더를 두 개로 나누어도 상관은 없습니다만, BUFDATA 자체가 반복되는 것이 아니므로 하나의 헤더로 처리하도록 하겠습니다.
typedef struct _HMSG_BUFFER
{
BYTE pkType;
BYTE pkStatus;
USHORT Version;
USHORT pkLength;
BYTE pkNo;
BYTE reserved;
UINT tLength;
char* Data;
} HMSG_BUFFER, *pHMSG_BUFFER;
실제 프로토콜은 위의 구조와는 비교도 안 될 정도로 복잡합니다만, 거의 모든 프로토콜은 위와 같은 골격을 가지고 있다고 생각하셔도 됩니다. 물론 BUFFER DATA 부분에서도 프로토콜안에 다른 종류의 프로토콜이 다중으로 포함되는 등의 아주 쉣한 경우도 많이 있지만 처음 배우는 입장에서 그런 것은 신경쓰지 않으셔도 됩니다.
저번에 약속드렸던 wireshark 대신에 사용한다던 프로그램을 자료실에 올려드리도록 하겠습니다. 오늘은 아니구.. 다음주 까지는 올려 드리겠습니다.
해당 프로그램에 기능 리스트를 정리 해 봅니다.
1. ethereal이나 wireshark에서 dump 한 파일 읽어들이는 기능
2. 엄청나게 빠른 속도로 파일을 읽는 기능 (1G 이상의 파일을 wireshark에서 읽어들이신다면 뭔 말인지 알게 됩니다)
3. 내부적으로 내용은 변경할 수 없으나 Hexa Editor의 Data View 기능을 능가하는 변환기능 (내부적 패킷 검색은 안됨)
4. 내맘대로, 원하는 형식대로 파일 쪼개주는 기능 (이 기능은 없을 수도 있습니다)
저처럼 덤프 패킷을 껴안고 살아가는 사람들에게는 가뭄에 단비와도 같은 희망을 던져주는 프로그램입니다. 실제 이 프로그램 때문에 작업시간을 하루에서 1시간으로 단축시켰다면 믿어지시겠는지요.. 꼭 필요하신 분이 있으실 거라 믿습니다.
다음 시간에는 많이들 사용하고 계시는 MS-SQL 서버의 공개된 프로토콜 분석 자료를 통한 Parsing 강좌를 하도록 하겠습니다. 좋은 정보가 되길 바랍니다.
