2010-04-19 2 views
1

나는 지금까지 다음과 같은 방법으로 시도했다 :패킷 추적을 감안할 때 이들을 플로우로 그룹화하는 방법은 무엇입니까?

1) 소스 IP/포트와 목적지 IP/포트를 키로하여 해쉬를 ​​만든다. 해시의 각 위치는 패킷 목록입니다. 해시는 파일에 저장되며 각 흐름은 특수 문자/줄로 구분됩니다. 문제점 : 큰 트레이스에 대한 메모리가 충분하지 않습니다.

2) 위와 동일한 키로 해시를 만들고 파일 핸들을 메모리에 유지하십시오. 그런 다음 각 패킷은 올바른 파일을 가리키는 해시 [키]에 저장됩니다. 문제점 : 너무 많은 플로우/파일 (~ 200k)은 메모리가 부족할 수 있습니다.

3) 소스 IP/포트와 대상 IP/포트를 해시 한 다음 정보를 파일에 넣습니다. 2와 3의 차이점은 파일이 각 작업에 대해 열리고 닫히기 때문에 동시에 너무 많은 파일을 열었 기 때문에 메모리 부족에 대해 걱정할 필요가 없다는 것입니다. 문제 : 너무 느려서 2와 같은 파일 수가 너무 비실용적입니다.

4) 원본 IP/포트 쌍의 해시를 만든 다음 각 흐름에 대해 전체 추적을 반복합니다. 흐름의 일부인 패킷을 가져 와서 출력 파일에 저장하십시오. 문제점 : 200k 플로우가있는 60MB 트레이스가 있다고 가정하십시오. 이렇게하면 60MB 파일을 200k 번 처리 할 수 ​​있습니다. 어쩌면 반복하면서 패킷을 제거하는 것은 그렇게 고통스럽지 않을 것입니다.하지만 지금까지는 이것이 좋은 해결책이 될지 모르겠습니다.

5) IP 원본/대상별로 분할 한 다음 각각에 대해 하나의 파일을 만들어 특수 문자로 구분합니다. 여전히 너무 많은 파일 (+ 50k).

지금 당장은 Ruby를 사용하고 있습니다. 나쁜 생각 이었을지도 모릅니다. 현재 tshark로 추적을 필터링 했으므로 관련 정보 만 포함되어 있으므로 더 작게 만들 수는 없습니다.

나는 C#/Java/C++를 사용하여 1)에서 설명한대로 메모리에있는 모든 것을로드하는 것에 대해 생각했지만 나중에 더 나은 메모리를 사용할 수 없기 때문에 여기서는 더 나은 접근 방법이 없을지 궁금해하고있었습니다. 더 큰 흔적을 사용해야 할 경우 더 효율적인 언어로

요약하면 문제는 내가 너무 많은 파일을 가지고 있거나 메모리가 부족하다는 것입니다.

나는 또한 정보를 필터링하는 도구를 검색해 보았지만 그 중 하나가 있다고는 생각하지 않습니다. 내가 찾은 것은 통계 만 반환하고 필요한 모든 흐름을 검사하지 않습니다.

답변

1

주어진 시나리오에서 필자는 파일에 추적을 기록 할 수 있지만 한 번에 제한된 수의 파일을 열 수 있도록 LRU (least-recently-used) 캐싱 메커니즘을 사용합니다. 현재 열려 있지 않은 파일에 액세스해야하는 경우 가장 활동을 보지 못한 파일을 닫고 현재 파일을 엽니 다.

최상의 성능을 얻으려면 LRU 캐시에서 파일 수를 조정해야 할 수도 있습니다. 이 기법은 짧은 수명의 연결이 많은 경우 특히 유용합니다.

관련 문제