1분 이상(또는 N 바이트 또는 M 패킷 이상) 열려 있는 TCP 연결을 감지하여 이를 대량 트래픽("다운로드")으로 분류하고 우선 순위를 해제하고 싶습니다.
iptables/netfilter/conntrack을 사용하여 장기 실행 스트림을 감지하고 tc로 셰이핑하도록 표시할 수 있습니까?
나는 스트림 길이를 측정하기 위해 TCP "시퀀스 번호"를 사용할 수 있을 것이라고 생각했지만 불행하게도 0에서 시작하지 않습니다! 아마도 netfilter/conntrack을 사용한 연결 추적을 통해 올바른 시퀀스 번호나 총 바이트 수, 연결 지속 시간을 확인하고 패킷 표시 여부를 선택할 수 있을 것입니다.
(내가 이 일을 하고 있다고 말할 수도 있습니다.입구ifb0 가상 인터페이스를 사용합니다. 나는 현재 우선순위가 낮은 데이터를 제한하기 위해 tbf 대기열(sfq 포함)을 사용하고 있습니다. 그럼에도 불구하고 어떤 솔루션이라도 적용할 수 있습니다.출구, 예를 들어 작은 요청의 속도를 높이기 위해 다운로드 우선 순위를 낮추려는 제한된 연결의 웹 서버의 경우입니다.)
업데이트: conntrackd를 사용하면 연결 목록과 각 연결이 시작된 시간을 볼 수 있습니다. 나는 이 목록을 사용하여 제한하려는 IP/포트 쌍을 검색하기 시작했습니다(60초 후). 그러나 다음과 같은 문제가 많이 있습니다.
- conntrack(d)은 연결이 닫혔을 때 목록에서 즉시 연결을 지우지 않는 것 같습니다! 그래서 나는 모든 연결을 제한하도록 표시하게 됩니다. 심지어 완료된 연결도 마찬가지입니다.
- conntrack에 표시를 설정해도 패킷에 표시가 설정되지 않는 것 같습니다(tc가 볼 수 있는 한). (이것은 단지 conntrack이 ifb0 이후의 패킷을 보기 때문이 아닙니다. 송신 패킷에서도 어떤 표시도 볼 수 없습니다.) 그래서 저는 제한을 위해 tc에 새로운 필터를 추가했는데, 이는 장기적으로 이상적이지 않습니다.
- conntrack(d)는 각 연결이 얼마나 많은 대역폭을 사용했는지 알려주지 않습니다. 따라서 간헐적인(예: iosocket) 세션과 과도한 다운로드를 구별할 수 없습니다. (어쨌든 이것은 어려운 문제입니다. 이미 5개의 다운로드가 있고 새로운 다운로드가 시작되면 그가 홍수를 일으키려고 한다는 것을 어떻게 알 수 있습니까? 그는 최대 속도 근처에도 도달하지 못할 것입니다.)
위와 관련된 제안을 주시면 감사하겠습니다.
(밝은 면에서는 다운로드를 올바르게 분류할 수 없더라도 tfb를 사용하여 수신 데이터를 최대 다운레이트의 80%로 제한하기만 하면 연결 오버플로가 방지되고 이전보다 훨씬 쉽게 새 연결을 설정할 수 있게 되었습니다.)
답변1
연결의 기대 수명과 실제 수명은 연결을 특수하게 형성해야 하는지 여부와 ZERO 관계가 있습니다.
몇 가지 예:
SSH는 수명이 길며 분, 시간, 일, 주, 심지어 월까지 가능합니다. 사용자 상호작용에 반응하려면 여전히 높은 우선순위가 필요합니다.
Bittorrent(또는 유사한 프로토콜)는 무작위로 실행되며 일부는 몇 초 동안 연결이 끊어지고 다른 일부는 몇 분 또는 몇 시간 동안 연결이 끊어졌습니다. 한 번에 하루 이상 지속되는 경우는 거의 없습니다.
요약: 연결 길이는 연결이 "대량"인지 여부 및 연결을 대량으로 처리해야 하는지 여부와 아무 관련이 없습니다.
반드시 직접적으로 관련될 필요는 없지만 유용합니다.