인터페이스에서 냄새를 pcap_open_live를 사용하여, 나는 BUFSIZ (<stdio.h>)에 '매직 넘버'에 이르기까지, SNAPLEN 값으로 여러 번호를 사용하는 예를 많이 보아왔다.는 최적의 스냅 길이는 PCAP 라이브 캡처
캡처하는 인터페이스의 MTU를 SNAPLEN으로 설정하는 것이 더 바람직하지 않습니까? 이렇게하면 PCAP 버퍼에 한 번에 더 많은 패킷을 넣을 수 있습니다. MRU가 MTU와 같다고 가정하는 것이 안전합니까?
그렇지 않으면 SNAPLEN 값을 설정하는 비 이국적인 방법이 있습니까?
감사
MTU 값은 링크 계층을 물려 될 수있는 가장 큰 페이로드 크기입니다; 링크 계층 헤더를 포함하지 않으므로 예를 들어 이더넷의 경우 1514 또는 1518이 아닌 1500이되며 전체 크기의 이더넷 패킷을 캡처 할만큼 충분히 크지는 않습니다.
또한 802.11 무선 정보 용 라디오 태그 헤더와 같은 메타 데이터 헤더도 포함되어 있지 않습니다.
어댑터가 조각/분할/재 조립 오프 로딩을 수행하는 경우 어댑터로 전달되거나 어댑터에서 수신 된 패킷이 아직 조각 나지 않았거나 다시 조립되었을 수 있으며, 일 수도 있고 MTU보다 큰 일 수 있습니다.
고정 크기 패킷 슬롯을 가진 Linux의 메모리 매핑 된 TPACKET_V1 및 TPACKET_V2 캡처 메커니즘에만 적용되는 PCAP 버퍼에 더 많은 패킷을 맞추는 방법은 다음과 같습니다. 다른 캡처 메커니즘은 모든 패킷에 대해 최대 크기의 슬롯을 예약하지 않으므로 스냅 샷의 길이가 더 짧아도 상관 없습니다. TPACKET_V1과 TPACKET_V2의 경우 스냅 샷의 길이가 더 짧아 질 수 있습니다. 최소한 이더넷에서는 libpcap 1.2.1 시도가 가능한 한 이더넷에 적합한 버퍼 슬롯 크기를 선택할 수 있습니다. (TPACKET_V3는 패킷 당 고정 크기의 슬롯을 가지고 있지는 않습니다.이 경우에는이 문제가 없지만 공식적으로 릴리즈 된 커널에만 최근에 나타 났으며 아직 libpcap에 대한 지원이 없습니다.)
괜찮아요, 그래서 나는 모니터 할 트래픽에 대해 가능한 최대 크기를 추측해야합니다. – ziu
* libpcap의 최신 버전과 함께 Linux를 사용하고 있고 버전이 1.2.1 이상이 아니거나 이더넷에서 캡처하지 않거나 (조각화/분할/재 조립 오프 로딩으로 이더넷에서 캡처 중) , *와 * 거대한 공유 메모리 버퍼 ('pcap_create()'/'pcap_set_buffer_size()'/'pcap_activate()')를 할당하지 않고 패킷 방울을 피하기 원한다면, libpcap에 전달 된 패킷의 가능한 최대 크기를 추측합니다. –
새로운 문제를 만들기 전에 각 패킷을 분석하지 않기 때문에 두 가지 문제가 있습니다. 따라서 사용자 응용 프로그램 수준에서도 버퍼링해야합니다. 그래서 메모리 사용량을 줄이려고합니다. – ziu