KR101114229B1 - Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법 - Google Patents

Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법 Download PDF

Info

Publication number
KR101114229B1
KR101114229B1 KR20090064082A KR20090064082A KR101114229B1 KR 101114229 B1 KR101114229 B1 KR 101114229B1 KR 20090064082 A KR20090064082 A KR 20090064082A KR 20090064082 A KR20090064082 A KR 20090064082A KR 101114229 B1 KR101114229 B1 KR 101114229B1
Authority
KR
South Korea
Prior art keywords
packet
flow
japanese
korean
payload
Prior art date
Application number
KR20090064082A
Other languages
English (en)
Other versions
KR20110006447A (ko
Inventor
이영석
김기수
권택근
손현구
강원철
Original Assignee
충남대학교산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 충남대학교산학협력단 filed Critical 충남대학교산학협력단
Priority to KR20090064082A priority Critical patent/KR101114229B1/ko
Priority to JP2009210495A priority patent/JP2011024179A/ja
Publication of KR20110006447A publication Critical patent/KR20110006447A/ko
Application granted granted Critical
Publication of KR101114229B1 publication Critical patent/KR101114229B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/126—Character encoding
    • G06F40/129—Handling non-Latin characters, e.g. kana-to-kanji conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

본 발명은 트래픽 모니터링 장비에서 HTTP 트래픽 분석을 수행할 때 수신된 HTTP 패킷 페이로드 내에 한글 또는 일본어가 인코딩되어 있는지를 탐지하고 이를 해독하는 방법/장치 및 이 방법에 의해 해독된 웹 컨텐츠의 내용을 분석하는 방법에 관한 것으로, 트래픽 모니터링 장비에서 HTTP 트래픽 분석을 수행할 때 HTTP 패킷 페이로드 내에 인코딩되어 있는 한글 또는 일본어 문자열을 탐지하여 해독하는 방법/장치와, 이를 이용하여 찾아낸 HTML 혹은 XML과 같은 웹 문서의 내용을 분석하여 사용자가 어떤 종류의 컨텐츠에 관심이 있는지를 분석하는 방법에 관한 것이다.
본 발명에 의해, HTTP 패킷에 인코딩되어 있는 한글 또는 일본어 문자열을 탐지하여 해독할 때 한글 완성형 코드 값과 비교하여 그 값에 해당하는 한글 또는 일본어 문자를 출력하는 것이 가능하게 된다. 또한 한글 또는 일본어 문자열이 여러 개의 패킷에 걸쳐 있을 경우 동일한 출발지와 목적지 IP 주소/포트번호를 갖는 연속적인 HTTP 패킷에 대해서도 인코딩 정보가 없더라도 한글 또는 일본어 문자열을 탐지하고 해독할 수 있도록 한다.
HTTP, 응답, 패킷, 플로우, 한글, 일본어, 인코딩, 디코딩, 압축, 웹, 컨텐츠, 카테고리, 키워드, 분류

Description

ＨＴＴＰ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법{Method for analyzing Korean or Janpanese web contents in HTTP packets}
본 발명은 트래픽 모니터링 장비에서 HTTP 트래픽 분석을 수행할 때 수신된 HTTP 패킷 페이로드 내에 한글 또는 일본어가 인코딩되어 있는지를 탐지하고 이를 해독하는 방법/장치 및 이 방법에 의해 해독된 웹 컨텐츠의 내용을 분석하는 방법에 관한 것이다. 즉, 본 발명은, 트래픽 모니터링 장비에서 HTTP 트래픽 분석을 수행할 때 HTTP 패킷 페이로드 내에 인코딩되어 있는 한글 또는 일본어 문자열을 탐지하여 해독하는 방법/장치와, 이를 이용하여 찾아낸 HTML 혹은 XML과 같은 웹 문서의 내용을 분석하여 사용자가 어떤 종류의 컨텐츠에 관심이 있는지를 분석하는 방법에 관한 것이다.
인터넷으로 대표되는 네트워크의 활성화에 따라 네트워크의 속성과 특징을 정확히 이해하고, 각종 네트워크상에서 발생하는 문제(트래픽 문제, 보안문제 등)의 원인을 명확히 밝히고 해결하기 위하여 트래픽분석 또는 패킷분석이 이루어지고 있다.
port번호를 이용한 트래픽분석 방법은 간단하기 때문에 많이 활용되고 있지만 분석의 정확성이 낮다는 문제가 있다. 보다 정확성이 있는 분석방법으로, 패킷 페이로드에서 어플리케이션의 특정 시그니쳐의 존재 유무를 판단하여 분석하는 방법이 있다. 그러나 특정 시그니쳐를 찾는 것이 쉽지 않으며, 시그니쳐가 바뀔 때마다 업데이트를 해줘야 한다는 단점이 있다. 그 밖에도 아이피 주소 혹은 tcp 포트번호와 같은 필드와 패킷 사이즈 같은 특징들을 SVM(Support Vector Machine)같은 기계학습(Machine Learning)에 적용시켜 트래픽을 분석하는 방법들도 있다. 그렇지만 이와 같은 방법론들은 인터넷 어플리케이션을 분류하는 것이 주된 목적이다.
한편, 이러한 기존의 연구 및 분석관점에서 벗어나 네트워크에 흐르는 HTTP 프로토콜을 이용하는 웹 어플리케이션 패킷들을 대상으로 한글 또는 일본어 HTML 혹은 XML 문서들을 추출하여 컨텐츠별로 분류함으로써 사용자들이 인터넷에서 어떤 종류의 컨텐츠에 관심이 많으며 어떠한 행동패턴을 보이는지 등을 파악할 필요성이 증대되고 있다.
현재 인터넷 상에서는 패킷분석을 쉽고도 정확하게 해주는 다양한 툴(Ethereal, Wireshark, Sniffer 등)들이 존재한다. 그러나 이러한 툴들은 패킷 의 페이로드의 내용을 ASCII코드 문자열로 보여주는 것에 그치고 있어 한글로 된 문자열이 HTTP 패킷에 포함되어 있을 경우 그 내용을 알 수 없다. 한국이나 일본의 경우 인터넷상의 정보는 대부분 한글이나 일본어로 인코딩된 웹 컨텐츠이기 때문에, 인터넷 트래픽의 내용을 정밀하게 분석하고, 사용자들의 행위를 파악하기 위한 컨텐츠 분석을 위해서는 ASCII 코드가 아닌 한글 또는 일본어 문자열로 자동으로 인식하고 해독하는 것의 필요성이 증대되고 있다.
현재 HTTP에서 쓰이는 한글 인코딩 방법은 한글완성형코드(KS완성형 표준한글코드, KS C 5601)를 이용한 인코딩, UTF-8, UTF-8, UTF-16으로 구분할 수 있다. 하지만 현재 거의 모든 웹서버가 한글완성형코드(KS C 5601), 특히 UTF-8과 UTF-8을 이용하여 웹페이지를 전송하고 있는 상황이다.
한글완성형코드는 2바이트 완성형 코드이며 2350자의 한글을 지원한다(KS C 5601). UTF-8은 Bell Lab.에서 유닉스상에서 영문자 이외의 문자를 지원하기 위해 제안한 확장 유닉스 코드(Extened UNIX code)중 한글 인코딩 방식으로서 영문은 KS C 5636(새 이름은 KS × 1003)으로 처리하고 한글은 KS C 5601(새 이름은 KS × 1001)로 처리한다. 여기서 KSC5636은 영문자에 대한 표준으로서 한국공업표준 정보처리분야(C)의 5636번 표준안을 말하며 기존 ASCII Code에서 역슬래쉬(＼)를 원(￦) 표시로 대체한 코드이다. 즉, UTF-8은 KS C 5601과 KS C 5636을 합친 코드를 사용하는 8비트 문자 인코딩이라고 생각하면 된다.
UTF-8과 UTF-16은 유니코드를 위한 가변길이 문자 인코딩 방식의 하나이 다(ISO/IEC 10646). UTF-8인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들면 U+0000부터 U+007F 범위에 있는 ASCII 문자들은 UTF-8에서 1바이트만으로 표시된다. 마찬가지로 U+0080부터 U+07FF까지는 2바이트이며, U+0800부터 U+FFFF사이에 들어가는 한글은 3바이트로 인코딩된다. UTF-16은 기본 다국어 평면(BMP, Basic Multilingual Plane)에 속하는 문자들은 그대로 16비트 값으로 인코딩하고 그 이상의 문자는 특별히 정해진 방식으로 32비트로 인코딩한다.
현재 HTTP에서 쓰이는 일본어 인코딩 방법은 SHIFT-JIS, EUC-JP, UTF-8, UTF-16으로 구분할 수 있다.
SHIFT-JIS(JIS × 0208:1997 Appendix 1)는 JIS × 0201과 JIS × 0208등을 사용하는 일본어 문자 인코딩이며, SJIS로 줄여 부르기도 한다. 1982년에 개발되었으나, 일본 내에서 널리 쓰이게 되자 JIS×0208:1997의 부속서 1로 표준화 되었다. 바이트 코드로 이루어진 SHIFT-JIS는 여러 확장들이 만들어 졌으나, 이중 JIS×0208의 확장으로 만들어진 마이크로소프트의 코드 페이지932가 가장 많이 쓰인다. 이중 히라가나(Hiragana)는 0x829F ~ 0x82F1, 가타카나(Katakana)는 0x8340 ~ 0x8396이며, 마지막으로 한자(kanji)는 몇 개를 제외하고 0x889F ~ 0xEEEC, 0xFA5C ~ 0xFC4B의 범위에 속한다.
EUC-JP는 Bell Lab.에서 유닉스 상에서 영문자 이외의 문자를 지원하기 위해 제안한 확장 유닉스 코드(Extened UNIX code)중 일본어 인코딩 방식으로서 EUC의 인코딩 방식위에 ASCII와 JIS×0208문자 집합을 배치한 것으로, 반각 가나(JIS×0201)와 JIS보조 한자(JIS×0212)도 포함할 수 있다. 이중 히라가나(Hiragana)는 0xA4A1 ~ 0xA4F3, 가타카나(Katakana)는 0xA5A1 ~ 0xA5F6이며, 마지막으로 한자(kanji)는 2바이트의 0xB0A1 ~ 0xFCED와 0x8FA2A0 ~ 0x8FFEFE 범위의 3바이트의 보조한자로 구성되어 있다.
UTF-8과 UTF-16은 유니코드를 위한 가변길이 문자 인코딩 방식의 하나이다(ISO/IEC 10646). UTF-8인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. 예를 들면 U+0000부터 U+007F 범위에 있는 ASCII 문자들은 UTF-8에서 1바이트만으로 표시된다. 마찬가지로 U+0080부터 U+07FF까지는 2바이트이며, U+0800부터 U+FFFF사이에 들어가는 일본어는 3바이트로 인코딩된다. UTF-16은 기본 다국어 평면(BMP, Basic Multilingual Plane)에 속하는 문자들은 그대로 16비트 값으로 인코딩하고 그 이상의 문자는 특별히 정해진 방식으로 32비트로 인코딩한다.
본 발명은 HTTP 패킷에서 한글 또는 일본어가 인코딩되어 있는지를 확인하고, 인코딩되어 있는 경우 이를 한글 또는 일본어 문자열로 디코딩하여 표현(출력)할 수 있는 방법 및 장치를 제공하는 것을 목적으로 한다.
또한 본 발명은 상기 한글 또는 일본어 디코딩 방법에 따라 디코딩된 HTML/XML 문서 단위로 해독된 한글 또는 일본어 컨텐츠를 카테고리 별로 저장된 한글 또는 일본어 키워드들과의 매칭을 통해 해당 문서를 특정 컨텐츠 카테고리로 분류하여, 웹 컨텐츠 분석뿐만 아니라, 해당 망에서의 사용자의 행위까지도 파악할 수 있도록 하는 것을 목적으로 한다.
이하에서 설명의 편의를 위해 몇가지 용어를 정의한다.
"플로우(flow)"란 공통의 주소쌍(송신자 주소, 송신자 포트 번호, 수신자 주소, 수신자 포트), 호스트 쌍(송신자 호스트 주소, 수신자 호스트 주소), 네트워크 주소 쌍(송신자 네트워크 주소, 수신자 네트워크 주소), AS 번호 쌍(송신자 AS 번호, 수신자 AS 번호) 등으로 주어지는 조건을 만족시키는 제한된 시간 내에 도착하는 IP 패킷들의 흐름으로 정의된다. 따라서 수신된 패킷의 헤더를 분석하면 그 패킷이 특정 플로우에 속하는지, 속한다면 플로우의 몇 번째 패킷인지 또는 마지막 패킷인지 등을 확인할 수 있다. IP 패킷 헤더분석은 종래 널리 알려진 사항이므로 상세한 설명을 생략한다.
"페이로드(payload=message body)"는 패킷의 헤더에 대응되는 개념으로, 사용자 정보(컨텐츠)를 보유하는 패킷의 부분을 의미한다. 페이로드는 압축되어 있을 수도 있다.
전술한 과제를 해결하기 위한 본 발명은, 플로우정보 등이 저장되는 플로우 테이블이 개재된 한글 또는 일본어 디코딩 방법/장치, 이에 의해 디코딩된 한글 또는 일본어 웹 컨텐츠의 분석방법에 관한 것이다.
(1) 플로우에 해당하는 패킷의 페이로드를 조립한 후 디코딩하는 방법
본 발명에 의한 한글 또는 일본어 디코딩 방법은, 플로우정보 등이 저장되는 플로우테이블이 개재된 한글 또는 일본어 디코딩 방법에 있어서, (A) 수신된 패킷의 헤더를 분석하여 상기 패킷이 플로우의 첫 패킷인지를 확인하여 ① 첫 패킷인 경우 하기 제2단계(적합성분석단계)로 이동하고, ② 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하지 않으면 종료하고, 존재하면 하기 제3단계(페이로드조립단계)로 이동하는 제1단계(플로우분석단계); (B) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 패킷이면 상기 패킷에 대한 플로우테이블을 생성한 후 하기 제3단계(페이로드조립단계)로 이동하고, HTTP 응답패킷이 아니거나 한글 또는 일본어 디코딩이 불가능한 패킷이면 종료하는 제2단계(적합성분석단계); (C) 상기 단계(B)에서 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 것으로 분석된 패킷의 페이로드부분을 저장하고, 상기 단계(A)에서 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하는 것으로 확인된 패킷의 페이로드를 기존에 저장되어 있는 해당 플로우의 페이로드에 연결하여 플로우를 조립하는 제3단계(페이로드조립단계); (D) 상기 패킷이 플로우의 마지막 패킷인 경우 플로우테이블을 초기화하고, 마지막 패킷이 아닌 경우 플로우테이블을 업데이트하고 상기 제1단 계로 이동하는 제4단계(플로우테이블관리단계); (E) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 ① 상기 패킷이 압축된 것이라면 플로우의 마지막 패킷까지 조립된 플로우의 페이로드의 압축을 해제한 후, ② 압축된 것이 아니라면 그대로, 상기 플로우의 HTTP 페이로드의 스트링으로부터 한글 또는 일본어를 디코딩하는 제5단계(압축해제/디코딩단계);를 포함하여 이루어지는 HTTP 패킷에서 한글 또는 일본어 디코딩 방법이다.
별도의 상세한 부가설명이 없더라도, 본 발명의 특성상 통신상의 하자 등에 의해 더 이상 수신 또는 분석할 패킷이 없는 경우 상기 디코딩 방법의 수행이 중단됨은 당연하다(이하 동일함).
본 발명에서 상기 플로우테이블은 플로우를 식별할 수 있는 정보 필드와, 삭제예약플래그 필드, 플로우유지시간 필드, 한글 또는 일본어 인코딩 타입 필드, HTTP 패킷의 페이로드 길이 필드 및 압축유무플래그 정보 필드를 포함하는 것이 바람직하다. 만일 플로우유지시간 필드가 있는 경우, 후속 패킷이 소정의 플로우유지시간(예컨대 30초) 내에 수신되지 않으면 디코딩을 종료하도록 할 수 있을 것이다. 삭제예약 플래그 필드가 있는 경우, 초기 플로우분석단계에서 패킷이 마지막 패킷인 경우(즉 패킷의 TCP 헤더에 FIN 플래그가 설정된 경우) 이를 삭제예약 플래그에 기록해 두고, 이 기록의 유무를 확인함으로써 패킷이 마지막 패킷인지를 확인하도록 할 수도 있다. 즉, 플로우테이블에 설정된 삭제예약 플래그가 있는지, 또는 소정의 플로우유지시간을 넘긴 플로우가 있는지를 체크하여 있다면 플로우테이 블을 삭제(초기화)한다.
본 발명의 상기 제2단계(적합성분석단계)에서, HTTP 헤더에 시그니쳐1("Content-Type: XXX" 및 {"charset=YYY" 또는 "encoding=YYY"}, 여기서 XXX가 "text/html" 또는 "text/xml")이 존재하고, YYY가 ① 한글 인코딩 타입인 UTF-8, utf-8, UTF-8, utf-8, KS_C_5601 또는 ks_c_5601이거나 ② 일본어 인코딩 타입인 UTF-8, utf-8, EUC-JP, euc-jp, SHIFT-JIS 또는 shift-jis인 경우에 플로우테이블을 생성하고 제3단계(페이로드조립단계)로 이동하는 것이 바람직하다.
(2) 또한 본 발명에 의한 한글 및 일본어 디코딩 장치는, 전술한 방법을 수행하기 위한 장치로서, (A) 수신된 패킷의 IP헤더를 분석하여 첫 패킷인지를 확인하는 헤더분석부; (B) 상기 HTTP 패킷헤더와 페이로드의 일부정보를 참조하여 HTTP 응답패킷인지, 한글 또는 일본어 디코딩이 가능한 패킷인지를 판단하는 적합성분석부; (C) 적합성이 확인된 패킷의 페이로드를 조립하는 페이로드조립저장부; (D) 플로우정보를 생성, 관리하는 플로우테이블관리부; 및 (E) 조립이 완료된 플로우의 페이로드를 파싱을 통하여 디코딩하는 압축해제/디코딩부;를 포함하는 HTTP 패킷에서 한글 또는 일본어 디코딩 장치이다.
(3) 본 발명에 의한 한글 또는 일본어 웹 컨텐츠의 분석방법 1은, 전술한 방법에 따라 디코딩된 한글 또는 일본어 웹 컨텐츠를 소정의 키워드 세트와 패턴매칭 을 수행하여 상기 웹 컨텐츠의 내용을 분석하는 것을 특징으로 하는 한글 또는 일본어 웹 컨텐츠의 분석방법이다.
(4) 패킷마다 페이로드를 순차적으로 디코딩한 후 컨텐츠 분석하는 방법(페이로드조립단계가 없는 방법)
본 발명에 의한 한글 또는 일본어 웹 컨텐츠의 분석방법 2는, 플로우정보 등이 저장되는 플로우테이블이 개재된 한글 또는 일본어 웹 컨텐츠의 분석방법에 있어서, (A) 수신된 패킷의 헤더를 분석하여 상기 패킷이 플로우의 첫 패킷인지를 확인하여 ① 첫 패킷인 경우 하기 제2단계(적합성분석단계)로 이동하고, ② 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하지 않으면 종료하고, 존재하면 하기 제3단계(압축해제/디코딩단계)로 이동하는 제1단계(플로우분석단계); (B) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 패킷이면 상기 패킷에 대한 플로우테이블을 생성한 후 하기 제3단계(압축해제/디코딩단계)로 이동하고, HTTP 응답패킷이 아니거나 한글 또는 일본어 디코딩이 불가능한 패킷이면 종료하는 제2단계(적합성분석단계); (C) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 ① 상기 패킷이 압축된 것이라면 패킷 페이로드의 압축을 해제한 후, ② 압축된 것이 아니라면 그대로, 상기 패킷의 HTTP 페이로드의 스트링으로부터 한글 또는 일본어를 디코딩하는 제3단계(압축해제/디코딩단계); (D) 디코딩된 한글 또는 일본어 웹 컨텐츠를 소정의 키워드 세트와 패턴매칭을 수행하여 상기 웹 컨텐츠의 내용을 분석하는 제4-1단계(패턴매칭단계); (E) 상기 패킷이 플로우의 마지막 패킷인 경우 플로우테이블을 초기화하고, 마지막 패킷이 아닌 경우 플로우테이블을 업데이트하고 상기 제1단계로 이동하는 제4-2단계(플로우테이블관리단계);를 포함하는 HTTP 패킷에서 한글 또는 일본어 웹 컨텐츠의 분석방법이다.
이 경우 상기 플로우테이블에는, 전술한 (1)에서의 필드에 1바이트저장공간 필드가 추가되는 것이 바람직하다. 1바이트저장공간은 한글과 일본어의 2바이트 인코딩방식을 반영한 것으로서 다음과 같이 활용된다.
즉, 상기 제3단계(압축해제/디코딩단계) 및 제4-2단계 (플로우테이블관리단계)에서, (a) 상기 패킷(n)이 플로우의 마지막 패킷이 아닌 경우, 한글 또는 일본어 디코딩을 수행하고 마지막 1바이트가 잔류할 때 이를 플로우테이블의 1바이트저장공간에 임시로 저장하고, (b) 다음 패킷(n+1) 처리시 상기 임시 저장된 1바이트 정보를 다음 패킷(n+1)의 페이로드 전단에 첨부한 후 디코딩하게 되는 것이다.
상기 제2단계(적합성분석단계)는 전술한 (1)과 동일할 수 있다.
본 발명에 의해, HTTP 패킷에 인코딩되어 있는 한글 또는 일본어 문자열을 탐지하여 해독할 때 한글 완성형 코드 값과 비교하여 그 값에 해당하는 한글 또는 일본어 문자를 출력하는 것이 가능하게 된다.
또한 본 발명에 의해, 한글 또는 일본어 문자열이 여러 개의 패킷에 걸쳐 있을 경우 동일한 출발지와 목적지 IP 주소/포트번호를 갖는 연속적인 HTTP 패킷에 대해서도 인코딩 정보가 없더라도 한글 또는 일본어 문자열을 탐지하고 해독할 수 있도록 한다.
또한 본 발명에 의해, 탐지된 한글 또는 일본어 문자열 정보를 이용할 수 있게 되어 HTTP 트래픽의 상세한 분석을 가능하게 한다.
본 발명에 의하면, 탐지된 한글 또는 일본어 문자열 정보를 이용하여 트래픽 모니터링 시스템이 설치된 네트워크 내의 사용자들이 어떠한 웹 컨텐츠를 즐기는지 파악할 수 있다. 이러한 정보를 바탕으로 웹 컨텐츠 제작자는 특정 웹 포탈에서의 인기 컨텐츠 결과가 아닌 다양한 웹 포털을 이용하는 종합적인 결과를 얻을 수 있을 것이며, 네트워크 관리자나 새로 네트워크를 설계하는 엔지니어는 네트워크 우선순위 경로의 설정 등의 네트워크 관리를 최적화 하는 데 활용할 수 있을 것이다.
이하 첨부된 도면을 참조하여 본 발명을 보다 상세히 설명한다. 그러나 이러한 도면은 본 발명의 기술적 사상의 내용과 범위를 쉽게 설명하기 위한 예시일 뿐, 이에 의해 본 발명의 기술적 범위가 한정되거나 변경되는 것은 아니다. 또한 이러한 예시에 기초하여 본 발명의 기술적 사상의 범위 안에서 다양한 변형과 변경이 가능함은 당업자에게는 당연할 것이다.
도 1은 본 발명에 따른 한글 또는 일본어 디코딩 방법 및 그 결과 얻어진 웹 컨텐츠를 분석하는 방법의 일예를 보여주는 전체 흐름도이고, 도 2 본 발명에 따른 한글 또는 일본어 디코딩 방법의 다른 예를 보여주는 흐름도이다. 도 1 및 도 2의 예는, 플로우에 해당하는 모든 패킷의 페이로드를 조립한 후 디코딩하는 방식이다.
먼저 도 1에 관해 설명한다. 도 1에 의한 방법은 크게 [플로우분석단계→적합성분석단계→페이로드조립단계→플로우테이블관리단계→압축해제/디코딩단계]를 포함하여 구성된다. 이때 발명의 전 취지 상, 플로우테이블관리단계는 흐름상 적합성분석단계 이후라면 어느 때 수행되더라도 동일한 결과를 나타냄은 당업자에게 있어 당연한 것이다. 따라서 본 발명 및 그 설명/도면에서 플로우테이블관리단계를 비록 제4단계로 표현하였으나, 이는 순서를 나타내는 것이 아니다(이하 동일하다).
(A) 제1단계(플로우분석단계)에서는 수신한 TCP/IP 패킷이 여러 개의 HTTP 패킷들 중에서 이미 받은 HTTP 응답 패킷들과 관련된 나머지 패킷인지(즉, 플로우에 해당하는지)를 판단한다. [물론 플로우의 첫 패킷이면서 적합성(한글/일본어디코딩가능성)이 확인된 경우에는 플로우테이블이 생성된다.]
본 단계에서는 수신된 패킷이 플로우의 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하지 않으면 HTTP 응답패킷이 아닌 플로우거나 한글/일본어디코딩이 불가능한 플로우임이 첫 패킷에 의해 이미 확인된 것이므로 추가조치 없이 종료한다. 물론 헤더 정보가 없는 패킷이면서 플로우테이블에도 없는 패킷이라 면 어떠한 처리 없이 종료한 후 바로 다음 패킷이 있는지를 조사하는 식의 순서를 따른다.
첫 패킷이 아니면서 해당 플로우테이블이 존재하면, HTTP 응답패킷이면서 한글/일본어 디코딩이 가능한 플로우임이 첫 패킷에 의해 이미 확인된 것이므로, 상기 플로우에 해당하는 연속된 패킷으로 인식하고 제2단계(적합성분석단계)를 거치지 않고 바로 제3단계(페이로드조립단계)로 이동한다. 여기서 "패킷의 해당 플로우테이블"이란 패킷과 같은 출발/목적 IP주소, 출발/목적 포트를 갖는 선행 패킷의 정보가 저장된 플로우테이블을 의미한다.
수신된 패킷이 플로우의 첫 패킷이면 제2단계(적합성분석단계)로 이동한다.
(B) 제2단계(적합성분석단계)에서는 플로우의 첫 패킷인 경우, 수신 패킷이 응답패킷인지와, 한글 또는 일본어 디코딩이 가능한지를 확인하여 그에 대한 플로우테이블을 생성하는 단계이다.
즉, 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 HTTP 응답패킷이면서 동시에 2바이트 한글 또는 일본어 디코딩이 가능한 패킷이면 플로우테이블을 생성한 후 제3단계(페이로드조립단계)로 이동한다. 한편 HTTP 응답패킷이 아니거나 2바이트 한글 또는 일본어 디코딩이 불가능한 패킷이면 추가적 조치없이 종료한다.
상기 플로우테이블에는 플로우를 식별할 수 있는 정보(출발 IP 주소, 목적 IP 주소, 출발 port, 목적 port, 수신한 시간, 식별자, 플래그, 단편화옵셋 등의 전부 또는 일부) 및 삭제예약플래그 및 플로우유지시간 등의 필드로 구성되도록 할 수 있다.
이렇게 생성된 플로우테이블은 제1단계(플로우분석단계)에서 플로우의 첫 번째가 아닌 패킷의 플로우테이블인지를 확인하는 용도로 활용되며, 하기 제4단계(플로우테이블관리단계)에서 관리된다.
한편, 본 발명은, 상기 플로우테이블을 제2단계 전에 생성하였다가 적합성이 없는 것으로 판단되면 초기화하는 것을 배제하지 않는다.
제2단계에 대해서는 뒤에서 다시 상세히 설명한다.
(C) 제3단계(페이로드조립단계)에서는 한글 또는 일본어 디코딩 적합성이 확인된 플로우의 패킷 HTTP 페이로드의 스트링을 조립/저장하는 단계이다.
즉, HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 것으로 분석된 패킷의 페이로드를 저장한다. 이때 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하는 것으로 확인된 패킷(n번째 패킷)의 페이로드(pn)을 기존에 저장되어 있는 해당 플로우의 페이로드가 조립된 스트링(p1+p2+…pn-1)에 연결하여 추가된 페이로드가 조립된 스트링(p1+p2+…pn-1+pn)을 생성하는 것이다.
(D) 제4단계(플로우테이블관리단계)는 한글 또는 일본어 문자열이 여러 개의 HTTP 패킷에 걸쳐있을 때(즉, 패킷이 플로우로 전달될 때), 첫 HTTP 패킷이 응답패 킷이고 한글 또는 일본어 변환이 가능한 경우 뒤에 계속적으로 오게 될 동일 플로우의 패킷들을 곧바로 페이로드조립하기 위해 플로우테이블을 삽입, 유지, 삭제하는 단계이다. 즉, 패킷이 플로우의 마지막 패킷인 경우 플로우테이블을 초기화하고 종료하며, 마지막 패킷이 아닌 경우 플로우테이블을 업데이트하고 상기 1단계(플로우분석단계)로 이동하는 단계이다.
수신된 패킷이 마지막 패킷인 경우(즉 패킷의 TCP 헤더에 FIN 플래그가 설정된 경우) 이를 플로우테이블의 삭제예약 플래그에 기록해 두고, 이 기록의 유무를 확인함으로써 패킷이 마지막 패킷인 경우 플로우테이블을 삭제(초기화)한다. 또한 만일 플로우유지시간 필드가 있는 경우, 후속 패킷이 소정의 플로우유지시간(예컨데, 30초) 내에 수신되지 않으면 디코딩을 종료하고 플로우테이블을 삭제(초기화)할 수 있을 것이다.
이상의 과정을 통하여 수신된 패킷들의 페이로드를 조립하는 것이 가능하게 되고, 플로우의 마지막 패킷의 페이로드까지 조립된 후에는 플로우테이블의 모든 정보가 삭제(초기화)되는 것이다.
(E) 제5단계(압축해제/디코딩단계)는 소정 플로우의 페이로드조립이 완료된 후에 이를 일괄해서 디코딩하는 단계이다.
즉, 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 압축된 것이라면 플로우의 마지막 패킷까지 조립된 플로우의 페이로드의 압축을 해제한 다음 한글 또는 일본어로 디코딩하고, 압축된 것이 아니라면 바디를 그대로 한글 또는 일본어를 디코딩한다. 구체적 디코딩 방법에 대하여는 뒤에서 다시 상세히 설명한다.
본 발명의 제1항은 제5단계까지에 관한 것이고, 제5항은 제6단계(컨텐츠분석단계)가 추가된 것이다.
(F) 제6단계(컨텐츠분석단계)는 전술한 과정에 따라 디코딩된 한글 또는 일본어 웹 컨텐츠를 소정의 키워드 세트와 패턴매칭을 수행하여 상기 웹 컨텐츠의 내용을 분석하는 단계이다. 상세한 것은 뒤에 설명한다.
도시하지는 않았지만, 전술한 한글 또는 일본어 디코딩 방법(제1단계~제5단계)은, (A) 수신된 패킷의 헤더를 분석하여 상기 패킷이 플로우의 첫 패킷인지를 확인하여 ① 첫 패킷인 경우 하기 적합성분석부로 전달하고, ② 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하지 않으면 종료하고, 존재하면 하기 페이로드조립저장부로 전달하는 헤더분석부; (B) 상기 패킷의 HTTP 헤더 또는 바디의 정보를 참조하여 상기 패킷이 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 패킷이면 상기 패킷에 대한 플로우테이블을 생성한 후 하기 페이로드조립저장부로 전달하고, HTTP 응답패킷이 아니거나 한글 또는 일본어 디코딩이 불가능한 패킷이면 종료하는 적합성분석부; (C) 상기 적합성분석부에서 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 것으로 분석된 패킷의 페이로드를 저장하고, 상기 헤더분석부에서 첫 패킷이 아니면서 상기 패킷에 대한 플로우 테이블이 존재하는 것으로 확인된 패킷의 페이로드를 기존에 저장되어 있는 해당 플로우의 조립된 페이로드에 연결하여 플로우를 조립하는 페이로드조립저장부; (D) 상기 패킷이 플로우의 마지막 패킷인 경우 플로우테이블을 초기화하고, 마지막 패킷이 아닌 경우 플로우테이블을 업데이트하는 플로우테이블관리부; (E) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 압축된 것이라면 플로우의 마지막 패킷까지 조립된 플로우의 페이로드의 압축을 해제한 후 상기 플로우의 HTTP 페이로드의 스트링으로부터 한글 또는 일본어를 디코딩하는 압축해제/디코딩부;를 포함하는 HTTP 패킷의 한글 또는 일본어 디코딩 장치에 의해 수행될 수 있다.
한편, 본 발명에서는 ① 전술한 바와 같이 일단 소정의 플로우에 해당하는 패킷의 모든 페이로드를 조립한 후에 압축여부를 확인하여 압축을 해제하는 방식(도 1)도 가능하지만 ② 소정의 플로우가 압축패킷인지를 먼저 확인하여 두고 패킷의 페이로드를 조립한 후에 압축을 해제하는 방식도 가능할 것이다. 후자의 방식에 관한 흐름도를 도 2에 도시하였다. 도 2에 예시된 방식은 도 1의 방식에 비해 다소 복잡한 구성을 보이지만, 궁극적으로 동일한 개념에 기반한 것이고, 동일한 결과를 얻을 수 있다. 도 1에 대한 설명부분을 참조하면 도 2를 용이하게 이해할 수 있으므로 추가적인 설명을 생략한다.
도 3은 본 발명에 따른 한글 또는 일본어 디코딩 방법 및 그 결과 얻어진 웹 컨텐츠를 분석하는 방법의 또 다른 예를 보여주는 전체 흐름도이다. 이것은 패킷마다 페이로드를 순차적으로 디코딩하고 즉시 패턴매칭 등의 방법으로 컨텐츠를 분석하는 방식이다.
도 3의 예에서 플로우분석단계, 적합성분석단계 및 플로우테이블관리단계는 도 1의 예에서와 동일하므로 그에 대한 설명을 생략하고 압축해제/디코딩단계(제3단계) 및 패턴매칭단계(제4-1단계)에 대해서만 설명한다.
(A) 제1단계(플로우분석단계)는 도 1에서와 동일하다.
(B) 제2단계(적합성분석단계)는 도 1에서와 동일하다.
(C) 제3단계(압축해제/디코딩단계)는 패킷이 압축된 것이라면 패킷 페이로드의 압축을 해제한 후, 압축된 것이 아니라면 그대로, 상기 패킷의 HTTP 페이로드의 스트링으로부터 한글 또는 일본어를 디코딩하는 단계이다. 즉, 플로우를 조립하지 않고 패킷별로 즉시 디코딩하는 것이다. 따라서 이 단계에서 디코딩된 컨텐츠는 플로우 전체가 보유한 컨텐츠의 일부(부분)가 된다.
(D) 제4-1단계(패턴매칭단계)는 패킷별 페이로드가 디코딩된 한글 또는 일본어 웹 컨텐츠의 일부에 대해 소정의 키워드 세트와 패턴매칭을 수행하여 상기 웹 컨텐츠의 내용을 분석하는 것이다.
(E) 제4-2단계(플로우테이블관리단계)는 도 1에서와 동일하다.
이 예에 따르면, 특정 시점에서는 컨텐츠의 일부에 대한 내용이 분석되는 것이지만, 소정의 플로우에 해당하는 모든 패킷이 제3단계와 제4-1단계를 거치게 되 면 결국은 플로우 전체가 가진 웹 컨텐츠에 대한 내용이 분석되게 된다. 이에 따라 결과는 도 1에 예시된 방식에 의한 결과와 동일하게 된다.
한편, 2바이트로 인코딩된 한글 또는 일본어 문자열의 상위 1바이트와 하위 1바이트가 나뉘어 서로 다른 패킷의 페이로드에 실려 전달될 경우가 생긴다. 이러한 경우를 감안하여 플로우테이블의 필드에는 1바이트저장공간이 추가되는 것이 바람직하다. 이 경우, 전 패킷(n-1번째)에서 디코딩 후 마지막 1 바이트가 남게 되면 이를 플로우테이블의 1바이트저장공간에 저장해 둔다. 이어서 다음 패킷(n번째)을 디코딩할 때 플로우테이블의 1바이트저장공간에 상위 1바이트가 저장되어 있는지를 확인하고, 상위 1 바이트가 존재하면 현재 패킷(n번째)의 맨 처음에 추가한 후 디코딩을 수행한다.
본 발명의 제2단계(적합성분석단계)에서는 플로우의 첫 패킷이면서 상기 패킷에 대한 플로우테이블이 존재하지 않는 수신 패킷이 응답패킷인지와, 한글 또는 일본어 디코딩이 가능한지를 확인하고, 둘 다 만족하는 경우 그 패킷에 대한 플로우테이블을 생성한다. 물론 헤더 정보도 없고 플로우테이블도 없는 패킷이라면 어떠한 조치 없이 흐름을 종료한다.
먼저 플로우의 첫 패킷이 HTTP 응답패킷인지를 확인해야 한다.
즉, HTTP 헤더에 "HTTP/1.1 200 OK"라는 스트링을 찾아 HTTP 응답 패킷 여부를 조사한다. 참고로 TCP 연결을 위한 3 단계 핸드쉐이킹(3-way handshaking) 방법에 따라 HTTP 요구 패킷, 그에 대한 서버측의 ACK가 온 뒤에 사용자가 요청한 HTTP 응답 패킷이 오게 된다.
이어서 수신된 HTTP 응답 패킷에 대해서 HTTP의 헤더와 페이로드의 정보 중 일부를 추출하여 한글 또는 일본어 디코딩이 가능한지와, 가능하다면 어떤 인코딩 타입인지를 조사한다. 확인된 인코딩 타입은 플로우테이블의 해당 필드에 기록된다.
예컨데, HTTP 헤더에 시그니쳐1("Content-Type: XXX" 및 {"charset=YYY" 또는 "encoding=YYY"}, 여기서 XXX가 "text/html" 또는 "text/xml")이 존재하고, YYY가 ① 한글 인코딩 타입인 UTF-8, utf-8, UTF-8, utf-8, KS_C_5601 또는 ks_c_5601이거나 ② 일본어 인코딩 타입인 UTF-8, utf-8, EUC-JP, euc-jp, SHIFT-JIS, Shift-JIS 또는 shift-jis인 경우에 각각 한글 또는 일본어 인코딩이 가능한 패킷으로 해석한다. 한글 또는 일본어 인코딩이 가능한 패킷으로 인정된 경우 상기 패킷의 정보를 저장하는 플로우테이블을 생성하고 제3단계(페이로드조립단계)로 이동한다. 그 이외의 경우 아무런 조치 없이 종료한다.
한편, 디코딩되는 컨텐츠의 크기(길이)를 알아야 할 경우가 있다. 컨텐츠의 크기는 "Content-Length:"와 "Transfer-Encoding: chunked"를 통해서 구할 수 있다. 전자로부터는 컨텐츠의 길이를 바로 구할 수 있는 반면, 후자의 경우는 컨텐츠와 관련된 패킷(즉 플로우)을 다 수신한 뒤에 구할 수 있다. 예를 들면, Content-Length는 HTTP 헤더필드 중 컨텐츠의 길이를 직접적으로 나타내는 필드로써 "Content-Length: ZZZ"와 같이 표현되며 컨텐츠의 길이가 "ZZZ" 바이트임을 의미한다. Transfer-Encoding에 대해서는 압축해제와 관련한 부분에서 설명하도록 한다.
정리하면, 본 발명에서 디코딩 적합성분석단계는, 수신된 패킷이 응답패킷인지, 한글 또는 일본어 디코딩이 가능한지 여부를 조사하여 이에 해당하는 패킷들만을 걸러내는 과정이다. 한글 또는 일본어를 어떤 인코딩방식을 써서 인코딩했는지를 알아내고, 소정의 조건을 만족하는 패킷에 대해서는 출발지 IP 주소, 목적지 IP 주소, 출발지 포트번호, 목적지 포트번호, 삭제 예약 플래그, 플로우 유지시간, 사용된 인코딩 타입, HTTP 패킷의 페이로드 길이, 압축 유무 플래그 정보 등이 저장된 플로우테이블을 생성한다.
본 발명에서 페이로드조립단계는 전술한 적합성분석단계를 통과한 패킷의 플로우에 해당하는 모든 패킷의 페이로드를 패킷 순서에 따라 연결하여 저장하는 단계이다. 구체적인 내용은 위에서 설명한 바 있다.
도 4는 본 발명의 압축해제/디코딩단계의 일예를 보여주는 세부 흐름도이다.
도 1 또는 도 2의 경우는 해당 플로우의 모든 정보가 조립된 후에 압축해제/디코딩되고, 도 3의 경우는 해당 플로우의 패킷별로 순차적으로 압축해제/디코딩되는 점에서 차이가 있으나 실제 "압축해제/디코딩"은 동일하게 이루어지므로 묶어서 설명한다.
① (압축해제과정) 압축해제/디코딩단계에서는, 먼저 현재 패킷이 압축된 패킷인지를 검사한다. 이는 시그니쳐3("Content-Encoding: YYY", YYY = "gzip" or "deflate")의 존재 유무로써 판단한다. "gzip" 이라는 문자열 대신에 "x-gzip", "deflate" 대신에 "x-deflate"이 라는 문자열이 왔을 때도 각각 gzip, deflate와 같은 압축 알고리즘으로 이해한다. 시그니쳐3이 존재할 경우 플로우테이블에 압축플래그를 설정하고, 이용된 압축 알고리즘을 기록한다.
압축되어 있는 데이터를 해제하는데 있어서 가장 중요한 것은 데이터의 무결성과 그 사이즈이다. 또한 압축이 되어있지 않은 HTTP 플로우라 할지라도 온전한 HTML/XML 문서단위로 분석을 하기 위해서는 데이터의 사이즈를 알아내는 것은 필요하다.
HTTP에서 전달하려는 데이터의 사이즈는 위에서도 잠깐 언급했지만, "Content-Length"(도 4의 시그니쳐1) 필드와 "Transfer-Encoding"(도 4의 시그니쳐2) 필드를 이용하여 웹브라우저에게 알린다. 만약 HTTP 헤더에 시그니쳐 1이 설정되어 있다면, 바로 그 사이즈를 알 수 있기에 다음 단계로 진행할 수 있다(400). 하지만 시그니쳐 2가 설정되어 있다면, 전체적으로 데이터를 검사해 가면서 chunk 데이터의 사이즈와 실제 데이터, chunk 구분자를 구분하여 저장해야 한다(410). 즉, 시그니쳐 2가 설정되어 있는 HTTP 패킷의 경우에는 헤더와 페이로드를 구분하는 구분자인 "￦r￦n￦r￦n"이후에 "SIZE￦r￦n" + "데이터" + "￦r￦n"의 형태로 전달된다. 따라서 하나의 플로우 내에서 각각의 chunk데이터마다 16진수형태의 사이즈 값들을 추출하여 더한 값이 실제 전송하고자 하는 총 데이터의 사이즈가 된다(420). 그리고 보내는 데이터가 마지막이라는 것을 알리기 위해 해당 패킷의 마지막 부분에 시그니쳐3을 같이 실어 보내게 된다. 만약 시그니쳐 3이 없다면 해당 플로우가 패킷을 완전하게 받지 않은 것으로 판단하고 해당 플로우는 폐기한다(430). 위 과정을 거치게 되면 웹서버에서 보내고자 하는 데이터의 사이즈를 알아 낼 수 있게 된다.
데이터의 사이즈를 알아낸 다음, 압축알고리즘이 적용된 데이터에 대해 압축 해제 과정을 거치게 된다. HTTP에서 가장 많이 사용되는 압축 알고리즘인 gzip은 10바이트의 gzip 헤더필드와 압축된 데이터, 4바이트의 CRC32 필드, 4바이트의 ISIZE 필드로 구성되어 있다. 10바이트의 헤더필드 중 플래그의 설정 여부에 따라 헤더와 압축 데이터 사이에 추가적으로 옵션필드가 있을 수 있지만, HTML/XML을 전송하는 HTTP에서는 위에 설명한 기본적인 부분만 고려하면 된다. 또한 gzip은 내부의 압축 데이터를 생성하기 위해서 deflate 알고리즘을 사용한다. 즉 거기에 gzip헤더와 기타 필드들이 더해져서 gzip 포맷의 압축 데이터가 생성되는 것이다. 대부분의 gzip과 deflate은 Zlib library (http://www.zlib.net, RFC 1950)를 이용하여 압축을 수행하고 해제한다. 본 발명에서도 Zlib library를 적용하여 압축을 해제할 수 있다.
HTTP 패킷에 적용된 압축 알고리즘이 deflate인 경우, 압축된 데이터와 그 데이터 사이즈가 정확하다면 Zlib library에서 지원하는 함수를 이용하여 압축을 해제할 수 있다(450). 다만, 몇몇 zlib 헤더를 포함하지 않고 데이터를 전송하는 웹서버들이 있어 2바이트의 Zlib 헤더를 압축 데이터 맨 앞에 삽입하여 압축해제를 하는 경우도 있다.
이와 같은 과정으로 압축되어 있던 페이로드가 압축해제된다. 물론 수신된 패킷이 압축된 것이 아니라면 압축해제과정은 생략된다.
② (디코딩과정) 압축해제되거나, 처음부터 압축되지 않은 페이로드를 한글 또는 일본어로 디코딩하게 된다. 도 1 또는 도 2의 경우 조립이 완료된 플로우 전체를 디코딩한 후에 패턴매칭하는 것도 가능하지만, 플로우를 디코딩 하는 것과 동시에 패턴매칭을 수행하여 컨텐츠분석을 하는 것도 가능할 것이다. 물론 도 3의 경우에는 당연히 패킷별로 순차적으로 디코딩된 부분을 즉시 패턴매칭하게 된다.
물론, 패킷이 UTF-8과 같은 다국어를 지원하는 인코딩 타입이면 인코딩된 3바이트를 2바이트의 유니코드 값으로 변환한다.
한글 또는 일본어 유무는 변환된 2바이트 값으로 판단한다. ⓐ 유니코드 문자코드 차트(http://www.unicode.org/charts/)를 참조하면, 0x1100~0x11FF(Hangul Jamo), 0xFFA1~0xFFDC(Halfwidth Jamo), 0x3130~0x318F(Hangul Compatibility Jamo), 0xAC00~0xD7AF(Hangul Syllables)이 한글을 나타내는 코드 범위이고, ⓑ 0x3040~0x309F(Hiragana), 0x30A0~0x30FF(Katakana), 0xFF00~0xFFEF(Full-width roman characters and half-width Katakana), 0x4E00~0x9FAF(CJK unified ideographs - Common and uncommon kanji), 0x3400~0x4DBF(CJK unified ideographs Extentsion A - Rare Kanji)이 일본어를 나타내는 코드 범위이다.
디코딩된 2바이트가 이 범위내의 코드 값을 가지고 있다면, 혹은 유니코드 테이블을 참조 할 수 있다면 UTF-8로 인코딩된 문서가 한글 또는 일본어를 포함하고 있는지를 알 수 있다. 즉, 아래 표 1과 같은 방식으로 인코딩이 이루어지게 된 다.
Figure 112009042769809-pat00001
예를 들면, 패킷 내에서 "위"라는 글자는 EC 9C 84의 3바이트로 표현되며 이진수로는 11101100 10011100 10000100로 표현된다. 굵게 표시된 부분만을 조합하면 1100-0111-0000-0100과 같으며 16진수로 표현하게 되면 C704의 "위"(U+C704)라는 유니코드 값을 갖는 것을 알 수 있다. 이러한 방식으로 UTF-8에서 한글로 디코딩할 수 있다.
압축해제/디코딩을 거친 데이터에 대해 패턴매칭을 거치는 컨텐츠분석단계가 이루어진다.
패턴매칭은 전술한 바와 같이, 조립이 완료된 플로우 전체를 디코딩한 후에 수행하는 것도 가능하지만, 플로우를 디코딩 하는 것과 동시에 수행하는 것도 가능하다. 이 과정은 크게 키워드들을 저장, 관리하는 컨텐츠분류사전과, 컨텐츠 분류 함수 혹은 알고리즘을 활용하여 이루어진다.
① (컨텐츠분류사전) 컨텐츠 분류를 위한 카테고리의 구분방법, 구분수, 각 카테고리에 대응하는 키워드의 종류 및 수 등은 사용자가 임의로 설정할 수 있다.
예를 들면, 대형 포털사이트들의 분류를 참조하여 쇼핑/택배, 성인, 주식/금융, 인터넷커뮤니티, 게임, 음악, 영화, 메일/메신저, 교육, 뉴스/웹서비스 등으로 카테고리를 분류할 수 있을 것이다. 이어서 각 카테고리별로 키워드를 상호배타적으로(즉, 하나의 키워드는 하나의 카테고리에 배당되도록) 선정하고 저장한다.
이렇게 선정/저장된 데이터베이스를 "컨텐츠분류사전"이라 칭한다.
여기서는, 예시적으로 간단한 카테고리 분류 방법을 제시(표 2)하고 예를 참조하여 설명한다. 표 2에서는 한글로만 표현하였지만, 일본어로도 동일한 컨텐츠분류사전을 작성할 수 있음은 당연하다. 필요하다면 영어 등 다른 언어로된 키워드도 추가될 수 있을 것이다. 키워드는 카테고리 당 15~20개 정도로 선정하는 것이 좋다.
Figure 112009042769809-pat00002
② (분류함수/알고리즘) 이어서 키워드 패턴매칭을 통한 컨텐츠 분류가 이루어진다.
패킷 페이로드의 데이터를 바탕으로 컨텐츠를 분류하는 이 방법은 기본적으로 텍스트 데이터의 문서 분류와 일맥상통한다고 할 수 있다. 즉, 각각의 카테고리에 속한 키워드들이 텍스트 문서에 얼마나 많이 속해있는지의 정보를 바탕으로 베이시안 학습(Baysian Learning) 혹은 SVM(Support Vector Machine)과 같은 기계학습을 이용하여 컨텐츠를 분석한다. 즉 HTML/XML 문서 단위로 합쳐진 패킷들의 페이로드에서 키워드 매칭을 통해 카테고리별 키워드 매칭 빈도수를 계산한다. 이 정보를 바탕으로 텍스트 데이터들을 분류하는데 가장 좋은 성능을 발휘한다고 알려진 알고리즘 중 하나인 베이시안 학습(Baysian Learning)과 SVM(Support Vector Machine)방법을 이용하여 해당 HTML/XML 문서단위의 패킷들이 어떠한 컨텐츠를 저장하고 있는지 기계적으로 판단하게 된다.
일반적으로, 텍스트 데이터 마이닝에서는 머신러닝 알고리즘에 넣을 데이터를 bags-of-words와 같은 방법을 이용한다. 이런 방법은 높은 정확도를 제공하지만 상당한 연산 시간을 요구한다.
카테고리 당 키워드 개수 차이가 심할 경우, 정규화(normalization)의 개념을 적용시켜 키워드 hit수(매칭된 카운트)를 해당 카테고리의 총 키워드 수로 나누어 다음 표 3과 같은 데이터를 얻을 수 있다.
- N: 한글 디코딩을 통한 총 문서 수(마지막 문서 번호)
- K: 컨텐츠 카테고리 총 수(마지막 카테고리 번호)
- Fsimple: 해당 문서 내에서 가장 먼저 발견된 키워드가 속한 카테고리
- 문서의 실제 카테고리 번호: Optional. 검증을 위해 매뉴얼하게 구한 해당 문서의 실제 카테고리.
위와 같은 데이터를 얻은 경우, 다음과 같은 컨텐츠 분류 함수를 이용할 수 있다.
Fsimple: 해당 문서 내에서 가장 먼저 발견된 키워드가 속한 카테고리
Fmax: 해당 문서 내에서 가장 많은 키워드 hit를 기록한 카테고리
Fsvm: 위의 카테고리별 hit수 정보를 바탕으로 SVM 머신러닝 알고리즘을 통해 분류된 결과
실제 필요한 정보(정확도 혹은 속도 등)에 맞춰 분류 함수를 이용할 수 있다. 이는 전수 조사 혹은 샘플링을 통해서 검증된 데이터와의 비교를 통해 결정하면 된다.
도 1은 본 발명에 따른 한글 또는 일본어 디코딩 방법 및 그 결과 얻어진 웹 컨텐츠를 분석하는 방법의 일예를 보여주는 전체 흐름도이다.
도 2 본 발명에 따른 한글 또는 일본어 디코딩 방법의 다른 예를 보여주는 흐름도이다.
도 3은 본 발명에 따른 한글 또는 일본어 디코딩 방법 및 그 결과 얻어진 웹 컨텐츠를 분석하는 방법의 또 다른 예를 보여주는 전체 흐름도이다.
도 4는 본 발명의 압축해제/디코딩단계의 일예를 보여주는 세부 흐름도이다.

Claims (9)

  1. 삭제
  2. 삭제
  3. 삭제
  4. 삭제
  5. 플로우정보가 저장되는 플로우테이블이 개재된 한글 또는 일본어 웹 컨텐츠의 분석방법에 있어서,
    (A) 수신된 패킷의 헤더를 분석하여 상기 패킷이 플로우의 첫 패킷인지를 확인하여 ① 첫 패킷인 경우 하기 제2단계(적합성분석단계)로 이동하고, ② 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하지 않으면 종료하고, 존재하면 하기 제3단계(페이로드조립단계)로 이동하는 제1단계(플로우분석단계);
    (B) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 패킷이면 상기 패킷에 대한 플로우테이블을 생성한 후 하기 제3단계(페이로드조립단계)로 이동하고, HTTP 응답패킷이 아니거나 한글 또는 일본어 디코딩이 불가능한 패킷이면 종료하는 제2단계(적합성분석단계);
    (C) 상기 단계(B)에서 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 것으로 분석된 패킷의 페이로드를 저장하고, 상기 단계(A)에서 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하는 것으로 확인된 패킷의 페이로드를 기존에 저장되어 있는 해당 플로우의 페이로드에 연결하여 플로우를 조립하는 제3단계(페이로드조립단계);
    (D) 상기 패킷이 플로우의 마지막 패킷인 경우 플로우테이블을 초기화하고, 마지막 패킷이 아닌 경우 플로우테이블을 업데이트하고 상기 제1단계로 이동하는 제4단계(플로우테이블관리단계);
    (E) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 ① 상기 패킷이 압축된 것이라면 플로우의 마지막 패킷까지 조립된 플로우의 페이로드의 압축을 해제한 후, ② 압축된 것이 아니라면 그대로, 상기 플로우의 HTTP 페이로드의 스트링으로부터 한글 또는 일본어를 디코딩하는 제5단계(압축해제/디코딩단계);를 포함하여 이루어지는 HTTP 패킷에서 한글 또는 일본어 디코딩 방법에 따라 디코딩된 한글 또는 일본어 웹 컨텐츠를 소정의 키워드 세트와 패턴매칭을 수행하여 상기 웹 컨텐츠의 내용을 분석하는 것을 특징으로 하는 한글 또는 일본어 웹 컨텐츠의 분석방법.
  6. 플로우정보가 저장되는 플로우테이블이 개재된 한글 또는 일본어 웹 컨텐츠의 분석방법에 있어서,
    (A) 수신된 패킷의 헤더를 분석하여 상기 패킷이 플로우의 첫 패킷인지를 확 인하여 ① 첫 패킷인 경우 하기 제2단계(적합성분석단계)로 이동하고, ② 첫 패킷이 아니면서 상기 패킷에 대한 플로우테이블이 존재하지 않으면 종료하고, 존재하면 하기 제3단계(압축해제/디코딩단계)로 이동하는 제1단계(플로우분석단계);
    (B) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 상기 패킷이 HTTP 응답패킷이면서 동시에 한글 또는 일본어 디코딩이 가능한 패킷이면 상기 패킷에 대한 플로우테이블을 생성한 후 하기 제3단계(압축해제/디코딩단계)로 이동하고, HTTP 응답패킷이 아니거나 한글 또는 일본어 디코딩이 불가능한 패킷이면 종료하는 제2단계(적합성분석단계);
    (C) 상기 패킷의 HTTP 헤더 또는 페이로드의 정보를 참조하여 ① 상기 패킷이 압축된 것이라면 패킷 페이로드의 압축을 해제한 후, ② 압축된 것이 아니라면 그대로, 상기 패킷의 HTTP 페이로드의 스트링으로부터 한글 또는 일본어를 디코딩하는 제3단계(압축해제/디코딩단계);
    (D) 디코딩된 한글 또는 일본어 웹 컨텐츠를 소정의 키워드 세트와 패턴매칭을 수행하여 상기 웹 컨텐츠의 내용을 분석하는 제4-1단계(패턴매칭단계);
    (E) 상기 패킷이 플로우의 마지막 패킷인 경우 플로우테이블을 초기화하고, 마지막 패킷이 아닌 경우 플로우테이블을 업데이트하고 상기 제1단계로 이동하는 제4-2단계(플로우테이블관리단계);를 포함하여 이루어지는 것을 특징으로 하는 HTTP 패킷에서 한글 또는 일본어 웹 컨텐츠의 분석방법.
  7. 제 6 항에 있어서,
    상기 플로우테이블은 플로우를 식별할 수 있는 정보 필드, 삭제예약플래그 필드, 플로우유지시간 필드, 1바이트저장공간 필드, 한글 또는 일본어 인코딩 타입 필드, HTTP 패킷의 페이로드 길이 필드및 압축유무플래그 정보 필드를 포함하는 것을 특징으로 하는 HTTP 패킷에서 한글 또는 일본어 웹 컨텐츠의 분석방법.
  8. 제 6 항에 있어서,
    상기 제2단계(적합성분석단계)에서,
    HTTP 헤더에 시그니쳐1("Content-Type: XXX" 및 {"charset=YYY" 또는 "encoding=YYY"}, 여기서 XXX가 "text/html" 또는 "text/xml")이 존재하고, YYY가 ① 한글 인코딩 타입인 UTF-8, utf-8, UTF-8, utf-8, KS_C_5601 또는 ks_c_5601이거나 ② 일본어 인코딩 타입인 UTF-8, utf-8, EUC-JP, euc-jp, SHIFT-JIS, shift-JIS 또는 shift-jis인 경우에 플로우테이블을 생성하고 제3단계(압축해제/디코딩단계)로 이동하는 것을 특징으로 하는 HTTP 패킷에서 한글 또는 일본어 웹 컨텐츠의 분석방법.
  9. 제 6 항에 있어서,
    상기 제3단계(압축해제/디코딩단계) 및 제4-2단계(플로우테이블관리단계)에서,
    (a) 상기 패킷이 플로우의 마지막 패킷이 아닌 경우, 한글 또는 일본어 디코딩을 수행하고 마지막 1바이트가 잔류할 때 이를 플로우테이블의 1바이트저장공간에 임시로 저장하고,
    (b) 다음 패킷 처리시 상기 임시 저장된 1바이트 정보를 다음 패킷의 페이로드 전단에 첨부한 후 디코딩하는 것을 특징으로 하는 HTTP 패킷에서 한글 또는 일본어 웹 컨텐츠의 분석방법.
KR20090064082A 2009-07-14 2009-07-14 Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법 KR101114229B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR20090064082A KR101114229B1 (ko) 2009-07-14 2009-07-14 Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법
JP2009210495A JP2011024179A (ja) 2009-07-14 2009-09-11 Ｈｔｔｐパケットにおけるハングルまたは日本語のデコード方法と装置、及びこれを用いたハングルまたは日本語ウェブコンテンツの分析方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR20090064082A KR101114229B1 (ko) 2009-07-14 2009-07-14 Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법

Publications (2)

Publication Number Publication Date
KR20110006447A KR20110006447A (ko) 2011-01-20
KR101114229B1 true KR101114229B1 (ko) 2012-04-12

Family

ID=43613287

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20090064082A KR101114229B1 (ko) 2009-07-14 2009-07-14 Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법

Country Status (2)

Country Link
JP (1) JP2011024179A (ko)
KR (1) KR101114229B1 (ko)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011102312A1 (ja) 2010-02-16 2011-08-25 日本電気株式会社 パケット転送装置、通信システム、処理規則の更新方法およびプログラム
KR101985579B1 (ko) * 2016-12-21 2019-09-03 정승화 선택 디코딩 알고리즘을 구비한 패킷 분석장치
US10326245B1 (en) 2018-03-29 2019-06-18 Cosemi Technologies, Inc. Light illuminating data communication cable
US10734768B2 (en) 2018-05-16 2020-08-04 Cosemi Technologies, Inc. Data communication cable assembly including electromagnetic shielding features
US11057074B2 (en) 2019-07-18 2021-07-06 Cosemi Technologies, Inc. Data and power communication cable with galvanic isolation protection

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030053452A (ko) * 2001-12-21 2003-06-28 에이저 시스템즈 인크 네트워크 프로세서 내에서 데이터 블록들의 재조합 방법및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030053452A (ko) * 2001-12-21 2003-06-28 에이저 시스템즈 인크 네트워크 프로세서 내에서 데이터 블록들의 재조합 방법및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
."Encoding identification of Internet packets", Proceedings of IEEE Canadian Conference on Electrical and Computer Engineering, Xue Chen 외 1인, Vol.1, pp.454-458 (2000.03.10.) 1부.. *

Also Published As

Publication number Publication date
KR20110006447A (ko) 2011-01-20
JP2011024179A (ja) 2011-02-03

Similar Documents

Publication Publication Date Title
US7242681B1 (en) System and method for intercepting and authenticating packets during one or more communication sessions and automatically recognizing content
JP3859313B2 (ja) タグ文書の圧縮装置および復元装置，圧縮方法および復元方法，圧縮／復元装置および圧縮／復元方法並びに圧縮，復元もしくは圧縮／復元プログラムを記録したコンピュータ読み取り可能な記録媒体
US7821427B2 (en) Data processing system and method
KR100271861B1 (ko) 데이타압축, 신장방법 및 장치와 이것을 사용한 데이타처리장치 및 네트워크시스템
KR101114229B1 (ko) Ｈｔｔｐ 패킷에서 한글 또는 일본어 웹 컨텐츠 분석방법
CN109818930B (zh) 一种基于tcp协议的通讯文本数据传输方法
US20160055213A1 (en) System and method for performing longest common prefix strings searches
KR20080084974A (ko) 웹 서비스 통신의 히스토리 구동 최적화를 위한 시스템 및방법
US8120515B2 (en) Knowledge based encoding of data with multiplexing to facilitate compression
JP2003030030A (ja) データ処理方法及びその手法を用いたエンコーダ、デコーダ並びにｘｍｌパーサ
US20130262486A1 (en) Encoding and Decoding of Small Amounts of Text
CN108259415A (zh) 一种邮件检测的方法及装置
US20020199121A1 (en) Method and apparatus for message routing in a computer system
US6701320B1 (en) System and method for determining a character encoding scheme
CN115242896B (zh) 动态报文解析方法、装置、电子设备及计算机可读存储介质
JP2007520112A (ja) Ｘｍｌファイルのための迅速にクエリ可能なデータ圧縮フォーマット
KR20020069229A (ko) 텍스트 도큐먼트들을 압축하기 위한 방법 및 장치
WO2013097812A1 (zh) 一种下载字库文件的方法和系统
US20130173248A1 (en) Leveraging language structure to dynamically compress a short message service (sms) message
US8271263B2 (en) Multi-language text fragment transcoding and featurization
US7814408B1 (en) Pre-computing and encoding techniques for an electronic document to improve run-time processing
WO2018226221A1 (en) Context-dependent shared dictionaries
KR100959877B1 (ko) Ｈｔｔｐ 패킷에서 한글 디코딩 방법 및 장치
US6571292B1 (en) Integration of structured document content with legacy 3270 applications
US20070300147A1 (en) Compression of mark-up language data

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20150130

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20160201

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20170126

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20180118

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20190131

Year of fee payment: 8