Hacker News 의견

• Cloudflare의 내부 헤더 저장 및 제거 방식에 대해 여러 가지 추측을 했음

  • 별도의 사전이나 데이터 구조 사용
  • 모든 내부 메타데이터를 포함하는 단일 헤더
  • 모든 헤더에 접두사를 붙여 내부는 'I', 외부는 'E'로 시작
  • 모든 내부 헤더는 "CFInt"로 시작
  • 특정 목록의 헤더가 내부 헤더라는 방식은 예상하지 못했음
  • 웹은 이미 모호한 신호와 헤더 명칭으로 가득 차 있음
  • Cloudflare 같은 대규모 회사가 이런 오류가 발생하기 쉬운 메커니즘을 사용하는 것이 이상함

• UTF-8 문자를 비트마스크로 매핑하는 것에 대해 처음에는 비효율적이라고 생각했음

  • 32비트로 a-z와 여섯 개의 특수 문자를 포함할 수 있음
  • 64비트로 대문자 A-Z와 여섯 개의 특수 문자를 포함할 수 있음
  • HTTP 헤더에 충분한 공간을 제공하며 빠른 매칭 알고리즘을 가능하게 함
  • 이 기술은 Bloom Filter임
  • 1970년대에 자원이 제한된 시기에 개발된 기술이지만 여전히 유용하게 사용되고 있음

• Cloudflare의 최적화가 가치 있는지에 대한 의문

  • 약 500개의 CPU 코어를 절약했음
  • Cloudflare의 비용을 모르지만, 몇 만 달러 정도의 절약이 예상됨
  • 엔지니어링에 대한 긍정적인 ROI를 기대할 수 있는지 의문
  • 필터를 역직렬화 단계에서 적용하여 헤더가 생성되지 않도록 하는 것이 더 나을 수 있음

• 데이터 구조 최적화에 대해 잘 알지 못하지만 해시 테이블을 빠르게 무시한 것이 놀라움

  • 정적 테이블을 검색할 때 해시 테이블이 더 빠를 것이라고 생각함

• fancy한 데이터 구조를 사용하여 제거할 항목을 구성하고 이를 기반으로 헤더 맵에서 제거함

  • "remove_header" 호출이 관련된 코드 링크를 제공함

• 트라이(Trie)를 사용한 블로그 포스트가 드디어 나옴

  • 트라이 관련 문제들이 헛되지 않았음

• 작은 Bloom Filter를 시도해봤는지 궁금함

  • 헤더 키에 대한 빠른 컨볼루션과 Bloom Filter 테스트가 트라이를 걷는 것을 피할 수 있음

• 정적 항목 집합을 매칭하는 경우 완벽한 해시 테이블을 시도했는지 궁금함

  • 몇 가지 산술 연산과 단일 문자열 비교로 줄일 수 있음

• 최적화가 흥미로움

  • 요청 생성 시 헤더를 내부로 태그하는 것이 가능했는지 궁금함
  • 출력 시 필터링이 간단해짐

• regex crate가 더 잘 작동하지 않은 이유가 궁금함

  • 여러 리터럴 문자열 검색을 Aho-Corasick 자동자로 컴파일해야 함