여러 가지 클래식 Linux 패킷 수집 엔진-리눅스 운영 및 유지 관리-php.cn

이 문서에는 네 가지 기본 Linux 패킷 수집 엔진이 나열되어 있습니다. 괜찮다고 생각하는 다른 엔진이 있으면 메시지를 남길 수 있습니다. 이 네 가지는 다음과 같습니다.

libpcap/libpcap-mmap
PF_RING
DPDK
xdp

libpcap

libpcap의 패킷 캡처 메커니즘은 데이터 링크 계층에 있습니다. 우회 추가 시스템 자체 네트워크 프로토콜 스택의 처리를 방해하지 않는 처리. 주고받은 데이터 패킷은 Linux 커널을 통해 필터링 및 버퍼링된 후 최종적으로 상위 계층 응용 프로그램으로 직접 전달됩니다.

데이터 패킷이 네트워크 카드 장치에 도착합니다.
네트워크 카드 장치는 구성에 따라 DMA 작업을 수행합니다. ("첫 번째 복사본": 네트워크 카드 등록 -> 네트워크 카드용 커널이 할당한 링 버퍼)
네트워크 카드는 인터럽트를 보내고 프로세서를 깨웁니다.
드라이버 소프트웨어는 링 버퍼에서 읽고 커널 skbuff 구조를 채웁니다( "두 번째 복사본" : 커널 네트워크 카드 버퍼 링 버퍼-> 커널별 데이터 구조 skbuff)
그런 다음 netif_receive_skb 함수를 호출합니다.

5.1 패킷 캡처 프로그램이 있는 경우 네트워크 하위 인터페이스를 통해 BPF 필터에 들어가서 규칙과 일치하는 패킷을 시스템 커널 캐시에 복사합니다( "3번째 복사). " ). BPF는 서비스가 필요한 각 패킷 캡처 프로그램에 필터와 두 개의 버퍼를 연결합니다. BPF는 버퍼를 할당하며 일반적으로 크기는 4KB입니다. 저장 버퍼는 어댑터에서 데이터를 수신하는 데 사용됩니다. 보류 버퍼는 패킷을 애플리케이션에 복사하는 데 사용됩니다.
5.2 데이터 링크 계층의 브리징 기능을 처리합니다.
5.3 skb->프로토콜 필드에 따라 상위 계층 프로토콜을 결정하고 이를 네트워크 계층에 제출하여 처리하고, 네트워크 프로토콜 스택에 입력합니다. 높은 수준의 처리를 수행합니다.
libpcap은 Linux 커널 패킷 수집 프로세스의 프로토콜 스택 부분 처리를 우회하여 사용자 공간 API가 소켓 PF_PACKET을 직접 호출하여 링크 계층 드라이버에서 데이터 패킷의 복사본을 얻고 이를 버퍼링할 수 있도록 합니다. 커널 영역이 사용자 공간 버퍼에 복사됩니다. ("The 4th copy")

libpcap-mmap

libpcap-mmap은 이전 libpcap 구현을 개선한 것이며 기본적으로 새로운 버전에서 사용됩니다. libpcap packet_mmap 메커니즘 버전. PACKET_MMAP은 mmap을 통해 하나의 메모리 복사본을 줄이고("네 번째 복사본이 사라졌습니다"), 잦은 시스템 호출을 줄여 패킷 캡처 효율성을 크게 향상시킵니다.

PF_RING

우리는 이전에 libpcap에 4개의 메모리 복사본이 있었던 것을 보았습니다. libpcap_mmap에는 3개의 메모리 복사본이 있습니다. PF_RING이 제안하는 핵심 솔루션은 전송 중 메시지 복사본 수를 줄이는 것입니다.

libpcap_mmap과 비교하여 pfring을 사용하면 rx_buffer를 사용하여 사용자 공간 메모리를 직접 mmap할 수 있다는 것을 알 수 있습니다. 이렇게 하면 또 다른 복사본이 줄어듭니다( "libpcap_mmap의 두 번째 복사본" : rx_buffer->skb)

PF-RING ZC는 사용자 메모리 공간을 드라이버 메모리에 매핑하는 DNA(직접 NIC 액세스 직접 네트워크 카드 액세스) 기술을 구현합니다. 사용자의 응용 프로그램이 네트워크 카드의 레지스터와 데이터에 직접 액세스할 수 있도록 공간을 확보합니다.

이런 방식으로 커널에서 데이터 패킷의 버퍼링을 방지하고 복사본 하나를 줄입니다("libpcap의 첫 번째 복사본", DMA에서 커널 버퍼 복사본으로). 이것은 완전히 제로 카피입니다.

단점은 한 번에 하나의 응용 프로그램만 DMA 링을 열 수 있다는 것입니다(현재의 네트워크 카드에는 여러 개의 RX/TX 대기열이 있을 수 있으므로 하나의 응용 프로그램이 동시에 각 대기열에 있을 수 있음). , 사용자 모드의 여러 응용 프로그램은 데이터 패킷을 배포하기 위해 서로 통신해야 합니다.

DPDK

pf-ring zc와 dpdk는 둘 다 커널을 우회하지만 구현 원칙은 약간 다릅니다. PF-링 zc는 zc 드라이버(애플리케이션 계층에서도 마찬가지)를 통해 데이터 패킷을 인수하고 dpdk는 UIO를 기반으로 구현됩니다.

1 UIO+mmap은 Zero Copy를 구현합니다

UIO(Userspace I/O)는 사용자 공간에서 실행되는 I/O 기술입니다. 일반적으로 Linux 시스템의 드라이버 장치는 커널 공간에서 실행되며 사용자 공간의 애플리케이션에 의해 호출될 수 있습니다. 그러나 UIO는 커널 공간에서 드라이버의 작은 부분을 실행하고 사용자 공간에서 대부분의 드라이버를 구현합니다. 기능. Linux에서 제공하는 UIO 메커니즘을 사용하면 커널을 우회할 수 있으며 모든 패킷 처리 작업은 사용자 공간에서 완료됩니다.

2 UIO+PMD는 인터럽트 및 CPU 컨텍스트 전환을 줄입니다.

DPDK의 UIO 드라이버는 하드웨어에서 발생한 인터럽트를 차단한 다음 사용자 모드에서 활성 폴링을 사용합니다. 이 모드를 PMD(Poll Mode Driver)라고 합니다.

DPDK와 비교했을 때 pf-ring(zc 없음)은 NAPI 폴링 및 애플리케이션 계층 폴링을 사용하는 반면, pf-ring zc는 DPDK와 유사하며 애플리케이션 계층 폴링만 사용합니다.

3 HugePages Reduce TLB miss

운영 체제에 MMU(Memory Management Unit)가 도입된 후 CPU는 메모리 데이터를 읽으려면 메모리에 두 번 액세스해야 합니다. 첫 번째는 페이지 테이블을 쿼리하여 논리 주소를 물리 주소로 변환한 다음 물리 주소에 액세스하여 데이터나 명령을 읽는 것입니다.

페이지가 너무 많고 페이지 테이블이 너무 커서 쿼리 시간이 길어지는 문제를 줄이기 위해 주소 변환 버퍼로 변환할 수 있는 TLB(Translation Lookaside Buffer)가 도입되었습니다. TLB는 일반적으로 레지스터에 저장되는 메모리 관리 장치로, 현재 액세스될 가능성이 가장 높은 페이지 테이블 항목의 작은 부분을 저장합니다.

TLB가 도입된 후 CPU는 주소를 지정하기 위해 먼저 TLB로 이동합니다. TLB는 레지스터에 저장되고 페이지 테이블 항목의 작은 부분만 포함하므로 쿼리 속도가 매우 빠릅니다. TLB의 주소 지정이 성공하면(TLB hit) RAM의 페이지 테이블을 쿼리할 필요가 없습니다. TLB의 주소 지정이 실패하면(TLB miss) 쿼리 후 RAM의 페이지 테이블을 쿼리해야 합니다. 페이지가 TLB로 업데이트됩니다.

DPDK는 x86-64에서 2MB와 1GB의 페이지 크기를 지원하는 HugePages를 사용하므로 총 페이지 수와 페이지 테이블 크기가 크게 줄어들어 TLB 누락 가능성이 크게 줄어들고 CPU 주소 지정 성능이 향상됩니다.

4 기타 최적화

SNA(Shared-Nothing Architecture), 소프트웨어 아키텍처는 분산화되어 글로벌 공유를 피하려고 하며 글로벌 경쟁을 초래하고 수평 확장 능력을 상실합니다. NUMA 시스템에서는 메모리가 노드 전체에서 원격으로 사용되지 않습니다.
SIMD(Single Instruction Multiple Data)는 초기 mmx/sse부터 최신 avx2까지 SIMD의 기능이 향상되었습니다. DPDK는 동시에 여러 패킷의 일괄 처리를 사용한 다음 벡터 프로그래밍을 사용하여 모든 패킷을 한 주기로 처리합니다. 예를 들어 memcpy는 SIMD를 사용하여 속도를 높입니다.
cpu Affinity: 즉, CPU Affinity