애플리케이션 QoS
AppQoS를 사용하면 특정 애플리케이션에 대한 액세스를 식별 및 제어할 수 있으며 상태 저장 방화벽 규칙 기반의 세분성을 제공하여 애플리케이션 레이어에서 서비스 품질(QoS)을 일치하고 적용합니다. 자세한 내용은 다음 항목을 참조하십시오.
애플리케이션 서비스 품질(AppQoS) 이해
애플리케이션 서비스 품질 (AppQoS) 기능은 레이어 7 애플리케이션 유형에 기반한 DSCP 값 표시, 손실 우선순위 설정을 통한 애플리케이션 기반 트래픽 준수, 레이어 7 애플리케이션 유형에 기반한 송신 PIC의 전송 속도 제어 등을 포함하도록 Junos OS 서비스 등급 (CoS)의 기능을 확장합니다.
보안 디바이스에서 DSCP 값을 표시하는 방법에는 네 가지가 있습니다.
IDP 공격 작업 기반 DSCP 재작성기
레이어 7 애플리케이션 기반 DSCP 재작성기
ALG 기반 DSCP 재작성기
방화벽 필터 기반 DSCP 재작성기
IDP 설명은 IDP 규칙에 따라 수신 포트에서 수행됩니다. 애플리케이션 설명은 애플리케이션 규칙에 따라 송신 포트에서 수행됩니다. 인터페이스 기반 설명은 방화벽 필터 규칙에 따라 송신 포트에서도 발생합니다. (Junos OS CoS 기능에 대한 자세한 설명은 서비스 등급 사용자 가이드(보안 디바이스) 를 참조하십시오.)
이 세 재작성자의 발언 결정은 다를 수 있습니다. 패킷이 세 가지를 모두 트리거하면, 우선 순위가 되는 방법은 패킷 내용 깊숙이 일치가 수행되는지에 따라 결정됩니다. IDP 설명은 인터페이스 기반 설명보다 우선하는 애플리케이션 설명보다 우선합니다.
패킷이 AppQoS 및 ALG 기반 DSCP 재작성기를 모두 트리거하는 경우 AppQoS가 ALG 기반 DSCP 재작성기보다 우선합니다.
AppQoS DSCP 재작성기는 포워딩 클래스와 손실 우선순위 모두를 통해 패킷의 서비스 품질을 전달합니다. AppQoS 속도 제한 매개 변수는 관련 대기열의 전송 속도와 볼륨을 제어합니다.
- 애플리케이션 QoS의 이점
- 고유한 포워딩 클래스 및 대기열 할당
- 애플리케이션 인식 DSCP 코드 포인트 및 손실 우선 순위 설정
- 속도 제한기 및 프로필
- 속도 제한기 할당
- 속도 제한기 동작
- AppQoS 보안 정책 구성
애플리케이션 QoS의 이점
AppQoS는 애플리케이션 트래픽의 우선순위를 지정하고 측정하여 비즈니스 크리티컬 또는 우선 순위가 높은 애플리케이션 트래픽에 더 나은 서비스를 제공하는 기능을 제공합니다.
고유한 포워딩 클래스 및 대기열 할당
포워딩 클래스는 다음 세 가지 기능을 제공합니다.
유사한 특성을 가진 패킷 그룹
출력 대기열 할당
기존 Junos OS 방화벽 필터 기반 재작성기와의 충돌 해결
고유한 포워딩 클래스 이름은 AppQoS 설명이 인터페이스 기반 재작성 규칙에 의해 덮어쓰기되지 않도록 보호합니다. 방화벽 필터 기반 재작성기는 패킷의 전달 클래스가 이 재작성기에 대해 특별히 정의된 클래스와 일치하는 경우 패킷의 DSCP 값을 설명합니다. 패킷의 포워딩 클래스가 방화벽 필터 기반 재작성기의 클래스와 일치하지 않으면 DSCP 값은 언급되지 않습니다. 따라서 AppQoS 값을 덮어쓰지 않도록 보호하려면 방화벽 필터 기반 재작성기에서 알 수 없는 포워딩 클래스 이름을 사용합니다.
각 포워딩 클래스는 적절한 수준의 향상된 또는 표준 처리를 제공하는 송신 대기열에 할당됩니다. 많은 포워딩 클래스를 단일 대기열에 할당할 수 있습니다. 따라서 디바이스에 정의된 모든 대기열은 IDP, AppQoS 및 방화벽 필터 기반 재작성기에서 사용할 수 있습니다. 전송 우선순위를 구분하는 것은 대기열이 아니라 포워딩 클래스 이름입니다. (대기열 및 스케줄러 구성에 대한 정보는 서비스 등급 사용자 가이드(보안 디바이스) 를 참조하십시오.)
애플리케이션 인식 DSCP 코드 포인트 및 손실 우선 순위 설정
AppQoS의 경우, 트래픽은 정의된 포워딩 클래스를 선택한 애플리케이션과 연결하는 규칙에 따라 그룹화됩니다. 규칙의 일치 기준에는 하나 이상의 애플리케이션이 포함됩니다. 일치하는 애플리케이션의 트래픽이 규칙을 발견하면 규칙 동작이 포워딩 클래스를 설정하고 DSCP 값과 손실 우선순위를 애플리케이션에 적합한 값으로 설명합니다.
DSCP(Differentiated Services) 코드 포인트(DSCP) 값은 6비트 비트맵 값이나 사용자 정의 또는 기본 별칭으로 규칙에 지정됩니다. 표 1 은 Junos OS 기본 DSCP 별칭 이름 및 비트맵 값 목록을 제공합니다.
별칭 |
비트 값 |
|---|---|
ef |
101110 |
AF11 |
001010 |
AF12 |
001100 |
AF13 |
001110 |
AF21 |
010010 |
AF22 |
010100 |
AF23 |
010110 |
AF31 |
011010 |
AF32 |
011100 |
AF33 |
011110 |
AF41 |
100010 |
AF42 |
100100 |
AF43 |
100110 |
되다 |
000000 |
CS1 |
001000 |
CS2 |
010000 |
CS3 |
011000 |
CS4 |
100000 |
CS5 |
101000 |
NC1/CS6 |
110000 |
NC2/CS7 |
111000 |
자세한 내용은 기본 CoS 값 및 별칭을 참조하십시오.
대기열의 스케줄러는 손실 우선순위를 사용하여 드롭 프로필을 특정 손실 우선순위 값과 연결하여 혼잡 기간 동안 패킷 폐기를 제어합니다. (대기열 및 스케줄러 구성에 대한 정보는 서비스 등급 사용자 가이드(보안 디바이스) 를 참조하십시오.)
이 규칙은 트래픽 그룹에 손실 우선순위를 적용합니다. 손실 우선순위가 높다는 것은 혼잡 기간 동안 패킷이 삭제될 가능성이 높다는 것을 의미합니다. 4가지 수준의 손실 우선순위를 사용할 수 있습니다.
highmedium-highmedium-lowlow
규칙 세트는 구성 명령에 정의되어 있습니다.class-of-service application-traffic-control
[edit class-of-service] user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application application-name application-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 match application-group application-group-name application-group-name ... user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then forwarding-class fc-name user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then dscp-code-point bitmap user@host# set application-traffic-control rule-sets ruleset-name rule rule-name1 then loss-priority loss-pri-value
속도 제한기 및 프로필
혼잡이 발생하면 AppQoS는 디바이스의 모든 송신 PIC에 대한 속도 제한을 구현합니다. 패킷이 할당된 제한을 초과하면 패킷이 삭제됩니다. 속도 제한기는 다양한 트래픽 클래스에 대해 일관된 수준의 처리량과 패킷 손실 민감도를 유지합니다. 모든 송신 PIC는 동일한 속도 제한 체계를 사용합니다.
PIC의 총 대역폭은 약 10Gbps입니다. PIC용 속도 제한기 하드웨어는 최대 2Gbps를 프로비저닝할 수 있습니다. 따라서 속도 제한을 위한 대역폭 상한은 231bps 입니다.
속도 제한기 프로필은 제한을 정의합니다. 그것은 사양과 사양의 bandwidth-limit burst-size-limit 독특한 조합입니다. 포트 bandwidth-limit 를 통과할 수 있는 초당 최대 킬로비트 수를 정의합니다. 은 burst-size-limit 단일 버스트에서 포트를 트래버스할 수 있는 최대 바이트 수를 정의합니다. 각 burst-size-limit 버스트에 대해 유한한 크기를 보장함으로써 우선 순위가 낮은 트래픽의 고갈을 줄입니다.
AppQoS는 디바이스당 최대 16개의 프로필과 최대 1,000개의 속도 제한기를 허용합니다. 여러 속도 제한기가 동일한 프로필을 사용할 수 있습니다. 다음 예에서는 두 개의 프로필을 사용하여 5개의 속도 제한기가 정의됩니다.
속도 제한기 이름 |
프로필 |
|
|---|---|---|
대역폭 제한 |
버스트 크기 제한 |
|
리미터-1 |
200 |
26000 |
리미터-2 |
200 |
26000 |
리미터-3 |
200 |
26000 |
리미터-4 |
400 |
52000 |
리미터-5 |
400 |
52000 |
속도 제한기는 구성 명령으로 정의됩니다 class-of-service application-traffic-control .
[edit class-of-service] user@host# set application-traffic-control rate-limiters rate-limiter-name bandwidth-limit value-in-Kbps burst-rate-limit value-in-bytes
속도 제한기 할당
속도 제한기는 트래픽 적용에 따라 규칙에 적용됩니다. 각 세션 client-to-server server-to-client에 대해 두 개의 속도 제한기가 적용됩니다. 이렇게 사용하면 각 방향의 트래픽을 별도로 프로비저닝할 수 있습니다.
속도 제한기에 의한 트래픽 대역폭 처리는 트래픽 방향에 관계없이 패킷 수준에서 수행됩니다. 예를 들어, 10G의 속도 제한기가 하나만 구성된 경우를 생각해보겠습니다. 수신 및 송신 트래픽이 동일한 라인 카드에서 오는 경우, 처리량(수신 및 송신 방향을 합친 최대 트래픽)은 20G가 아닌 최대 10G까지만 가능합니다. 그러나 디바이스가 IOC 지원(I/O 카드(IOC))을 가지고 있고 수신 트래픽이 하나의 IOC를 통과하고 송신 트래픽이 다른 IOC를 통해 전송되는 경우, 10G의 단일 속도 제한기를 구성하면 20G의 처리량을 기대할 수 있습니다.
동일한 규칙 세트 내의 서로 다른 AppQoS 규칙은 속도 제한기를 공유할 수 있습니다. 이 경우 해당 규칙의 적용은 동일한 대역폭을 공유합니다. 동일한 속도 제한기를 할당할 수 있는 하나의 규칙 집합의 규칙 수에는 제한이 없습니다.
다음 예는 이전 섹션에서 정의한 속도 제한기를 할당하는 방법을 보여줍니다. 예를 들어, 규칙 세트는 여러 규칙과 한 방향 또는 두 가지 흐름 방향 모두에서 속도 제한기를 재사용할 수 있습니다.
규칙 세트-1
규칙-1A
클라이언트-서버 리미터-1
서버-클라이언트 리미터-1
규칙-1B
클라이언트-서버 리미터-1
서버-클라이언트 리미터-1
여러 규칙 세트에서 동일한 프로필이 필요한 경우, 동일한 bandwidth-limit 및 burst-size-limit를 지정하여 충분한 수의 속도 제한기를 정의해야 합니다. 다음 예제의 두 규칙 세트는 다르지만 비슷한 속도 제한기를 할당하여 동일한 프로필을 구현합니다.
규칙 세트-2
규칙-2A
클라이언트-서버 리미터-2
서버-클라이언트 리미터-2
규칙-2B
클라이언트-서버 리미터-2
서버-클라이언트 리미터-4
규칙 세트-3
규칙-3A
클라이언트-서버 리미터-3
서버-클라이언트 리미터-3
규칙-3B
클라이언트-서버 리미터-3
서버-클라이언트 리미터-5
속도 제한기는 포워딩 클래스, DSCP 값 및 손실 우선순위가 설정된 것과 동일한 방식으로 명령을 사용하여 edit class-of-service application-traffic-control rule-sets 적용됩니다.
[edit class-of-service] user@host# set application-traffic-control rule-sets rule-set-name rule rule-name1 then rate-limit client-to-server rate-limiter1 server-to-client rate-limiter2
AppQoS 및 방화벽 필터 기반 속도 제한이 모두 송신 PIC에서 구현되면 둘 다 고려됩니다. AppQoS 속도 제한이 먼저 고려됩니다. 방화벽 필터 기반 속도 제한은 그 이후에 발생합니다.
PIC에서 패킷이 손실되면, 디바이스는 클라이언트 또는 서버에 알림을 보내지 않습니다. 클라이언트 및 서버 디바이스의 상위 수준 애플리케이션은 재전송 및 오류 처리를 담당합니다.
속도 제한기 동작
보안 디바이스 유형에 따라 AppQoS 규칙은 다양한 속도 제한기 작업으로 구성할 수 있습니다.
폐기
이 옵션을 선택하면 프로파일 외 패킷이 그냥 삭제됩니다.
이는 기본 작업 유형이므로 구성할 필요가 없습니다.
이 옵션은 모든 보안 디바이스에서 지원됩니다
손실 우선 순위 높음
이 옵션을 선택하면 손실 우선순위가 최대로 올라갑니다. 즉, 지연된 드롭입니다. 즉, 폐기 결정은 송신 출력 대기열 수준에서 이루어집니다. 혼잡이 없으면 최대 손실 우선순위로도 트래픽을 허용합니다. 그러나 혼잡이 발생하면 이러한 최대 손실 우선순위 패킷이 먼저 삭제됩니다.
이 옵션은 다음 명령을 사용하여 AppQoS 규칙 내에서 구성해야 합니다(기본 작업을 재정의하려면).
[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high
-
이 옵션은 선택한 디바이스에서 지원됩니다. 플랫폼별 AppQoS 동작 표를 참조하십시오.
AppQoS 보안 정책 구성
AppQoS 규칙 세트는 기존 정책 또는 특정 애플리케이션 정책에서 구현할 수 있습니다.
[edit security policies from-zone zone-name to-zone zone-name]
user@host# set policy policy-name match source-address IP-address
user@host# set policy policy-name match destination-address IP-address
user@host# set policy policy-name match application application-name application-name
user@host# set policy policy-name then permit application-services application-traffic-control rule-set app-rule-set-name
또한보십시오
예: 애플리케이션 서비스 품질 구성
이 예는 정책 내에서 AppQoS 우선 순위 지정 및 속도 제한을 활성화하는 방법을 보여줍니다.
요구 사항
이 기능을 구성하기 전에 디바이스 초기화 이외의 특별한 구성은 필요하지 않습니다.
개요
이 예에서는 FTP 애플리케이션이 지정된 처리량 미만 수준으로 제한되는 반면 다른 애플리케이션은 보다 일반적인 속도 및 손실 우선 순위 수준으로 전송되도록 AppQoS가 구현됩니다.
구성
절차
이 예제를 빠르게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여 넣고 줄 바꿈을 제거한 다음 네트워크 구성과 일치하는 데 필요한 세부 정보를 변경한 다음 명령을 복사하여 [edit] 계층 수준의 CLI에 붙여넣습니다.
set class-of-service forwarding-classes queue 4 my-app-fc set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000 set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log set security policies from-zone trust to-zone untrust policy p1 match source-address any set security policies from-zone trust to-zone untrust policy p1 match destination-address any set security policies from-zone trust to-zone untrust policy p1 match application any set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set ftp-test1
단계별 절차
보안 디바이스에서 AppQoS를 구성하려면:
-
AppQoS 마킹 전용 포워딩 클래스를 하나 이상 정의합니다. 이 예에서는 단일 포워딩 클래스 my-app-fc가 정의되고 대기열 4에 할당됩니다.
[edit] user@host# set class-of-service forwarding-classes queue 4 my-app-fc
[edit] user@host# set class-of-service forwarding-classes class my-app-fc queue 4
주니퍼 네트웍스 디바이스는 8개의 대기열(0에서 7까지)을 지원합니다. 기본 대기열 0에서 3은 기본 포워딩 클래스에 할당됩니다. 대기열 4에서 7은 FC에 대한 기본 할당이 없으며 매핑되지 않습니다. 큐 4부터 7까지 사용하려면 사용자 정의 FC 이름을 작성하고 큐에 맵핑해야 합니다. 자세한 내용은 포워딩 클래스 개요를 참조하십시오.
속도 제한기를 정의합니다. 이 예에서는 두 개의 속도 제한기가 정의됩니다.
[edit] user@host# set class-of-service application-traffic-control rate-limiters test-rl bandwidth-limit 100 user@host# set class-of-service application-traffic-control rate-limiters test-rl burst-size-limit 13000 user@host# set class-of-service application-traffic-control rate-limiters test-r2 bandwidth-limit 200 user@host# set class-of-service application-traffic-control rate-limiters test-r2 burst-size-limit 26000
-
AppQos 규칙 및 애플리케이션 일치 기준을 정의합니다.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:FTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 match application junos:HTTP user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then forwarding-class my-app-fc user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then dscp-code-point af22 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then loss-priority low user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit client-to-server test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then rate-limit server-to-client test-r1 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 0 then log
이 예에서 일치하면 패킷은 포워딩 클래스 my-app-fc, DSCP 값 af22, 손실 우선순위 low로 표시됩니다. 양방향에 동일한 속도 제한기를 할당했습니다.
단일 규칙에서 하나 또는 두 가지 트래픽 방향 모두에 속도 제한기를 할당할 수 있습니다. 또한 규칙 집합 내의 다른 규칙에 동일한 속도 제한기를 할당할 수 있습니다. 그러나 동일한 속도 제한기를 다른 규칙 집합에 할당할 수는 없습니다.
-
이전 규칙과 일치하지 않는 애플리케이션 패킷을 처리하는 다른 규칙을 정의합니다. 이 예에서는 두 번째이자 마지막 규칙이 나머지 모든 애플리케이션에 적용됩니다.
[edit] user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 match application-any user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit client-to-server test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then rate-limit server-to-client test-r2 user@host# set class-of-service application-traffic-control rule-sets app-test1 rule 1 then log
-
보안 정책에 AppQoS 설정을 추가합니다.
[edit] user@host# set security policies from-zone trust to-zone untrust policy p1 match source-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match destination-address any user@host# set security policies from-zone trust to-zone untrust policy p1 match application any user@host# set security policies from-zone trust to-zone untrust policy p1 then permit application-services application-traffic-control rule-set app-test1
결과
구성 모드에서 and show class-of-service 명령을 입력 show security policies 하여 정책 구성을 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.
간결성을 위해 이 show 명령 출력은 이 예와 관련된 구성만 포함합니다. 시스템의 다른 구성은 생략 부호(...)로 대체되었습니다.
...
policy p1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-traffic-control {
rule-set app-test1
}
}
}
}
}
...
user@host# show class-of-service
forwarding-classes {
queue 4 my-app-fc;
}
application-traffic-control {
rate-limiters test-rl {
bandwidth-limit 100;
burst-size-limit 13000;
}
rate-limiters test-r2 {
bandwidth-limit 200;
burst-size-limit 26000;
}
rule-sets app-test1 {
rule 0 {
match {
application [junos:FTP junos:HTTP];
}
then {
forwarding-class my-app-fc;
dscp-code-point af22;
loss-priority low;
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
rule 1 {
match {
application-any;
}
then {
rate-limit {
client-to-server test-r2;
server-to-client test-r2;
}
log;
}
}
}
}
디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .
검증
구성이 제대로 작동하고 있는지 확인합니다.
플로우 세션 구성 확인
목적
AppQoS가 활성화되어 있는지 확인합니다.
작업
운영 모드에서 명령을 입력합니다.show security flow session application-traffic-control extensive
user@host> show security flow session application-traffic-control extensive
Session ID: 3729, Status: Normal, State: Active
Flag: 0x40
Policy name: p1
Source NAT pool: Null
Dynamic application: junos:FTP
Application traffic control rule-set: app-test1, Rule: rule0
Maximum timeout: 300, Current timeout: 276
Session State: Valid
Start time: 18292, Duration: 603536
In: 192.0.2.1/1 --> 203.0.113.0/1;pim,
Interface: reth1.0,
Session token: 0x1c0, Flag: 0x0x21
Route: 0x0, Gateway: 192.0.2.4, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 21043, Bytes: 1136322
Out: 203.0.113.0/1 --> 192.0.2.0/1;pim,
Interface: .local..0,
Session token: 0x80, Flag: 0x0x30
Route: 0xfffd0000, Gateway: 192.0.2.0, Tunnel: 0
Port sequence: 0, FIN sequence: 0,
FIN state: 0,
Pkts: 0, Bytes: 0
의미
애플리케이션 트래픽 제어 항목은 현재 세션의 규칙 세트와 규칙을 식별합니다.
세션 통계 확인
목적
AppQoS 세션 통계가 각 송신 노드에서 누적되고 있는지 확인합니다.
작업
운영 모드에서 명령을 입력합니다.show class-of-service application-traffic-control counter
user@host> show class-of-service application-traffic-control counter pic: 2/1 Counter type Value Sessions processed 300 Sessions marked 200 Sessions honored 0 Sessions rate limited 100 Client-to-server flows rate limited 100 Server-to-client flows rate limited 100 pic: 2/0 Counter type Value Sessions processed 400 Sessions marked 300 Sessions honored 0 Sessions rate limited 200 Client-to-server flows rate limited 200 Server-to-client flows rate limited 200
의미
AppQoS 통계는 application-traffic-control 서비스가 활성화된 경우에만 유지됩니다. 처리, 표시 및 준수된 세션 수는 구성된 AppQoS 기능을 기반으로 세션이 전달되고 있음을 보여줍니다. 속도 제한 통계는 속도 제한된 방향 세션 흐름의 수를 계산합니다.
속도 제한기 통계 확인
목적
FTP 애플리케이션이 발견될 때 대역폭이 예상대로 제한되고 있는지 확인합니다.
작업
운영 모드에서 명령을 입력합니다.show class-of-service application-traffic-control statistics rate-limiter
user@host> show class-of-service application-traffic-control statistics rate-limiter pic: 2/1 Ruleset Application Client-to-server Rate(kbps) Server-to-client Rate(kbps) app-test1 HTTP test-r2 200 test-r2 200 app-test1 HTTP test-r2 200 test-r2 200 appp–test1 FTP test-r1 100 test-r1 100
의미
각 PIC에 대한 실시간 애플리케이션 대역폭 제한 정보는 규칙 세트별로 표시됩니다. 이 명령은 속도가 제한되는 애플리케이션과 적용 중인 프로필을 나타냅니다.
규칙 통계 확인
목적
규칙이 규칙 통계와 일치하는지 확인합니다.
작업
운영 모드에서 명령을 입력합니다.show class-of-service application-traffic-control statistics rule
user@host>show class-of-service application-traffic-control statistics rule pic: 2/1 Ruleset Rule Hits app-test1 0 100 app-test1 1 200 ... pic: 2/0 Ruleset Rule Hits app-test1 0 100 app-test1 1 200
의미
이 명령은 각 규칙 세트에 따른 규칙에 대한 (세션) 적중 수에 대한 정보를 제공합니다.
통합 정책에 대한 애플리케이션 QoS(Quality of Service) 지원
통합 정책은 기존 5-튜플 또는 6-튜플(사용자 방화벽이 있는 5-튜플) 일치 조건의 일부로 동적 애플리케이션을 사용하여 시간 경과에 따른 애플리케이션 변경을 감지할 수 있는 보안 정책입니다.
AppQoS(Application Quality of Service)는 보안 디바이스가 통합 정책으로 구성될 때 지원됩니다. 여러 보안 정책이 트래픽과 일치하는 경우 통합 정책 충돌을 관리하도록 기본 AppQoS 규칙 세트를 구성할 수 있습니다.
AppQoS 규칙 세트는 애플리케이션 인식 서비스 품질 제어를 구현하기 위한 통합 정책에 포함되어 있습니다. 옵션 아래의 규칙으로 규칙 세트를 application-traffic-control 구성하고 AppQoS 규칙 세트를 애플리케이션 서비스로 통합 보안 정책에 연결할 수 있습니다. 트래픽이 지정된 동적 애플리케이션과 일치하고 정책 작업이 허용되면, 애플리케이션 인식 서비스 품질이 적용됩니다.
통합 정책에서 다음 AppQoS 기능을 참고하십시오.
기존 보안 정책에서 통합 정책으로 업그레이드 - 통합 정책에서 옵션을 로
none구성dynamic-application하면 보안 정책 일치 중에 AppQoS 규칙 세트가 적용되고 AppQoS는 식별된 트래픽에 대한 해당 규칙을 찾습니다. 이는 릴리스 18.2R1 이전 Junos OS 릴리스의 AppQoS 기능에 대한 동일한 동작입니다.통합 정책을 사용하는 AppQoS 규칙—애플리케이션 트래픽 제어 구성에서 AppQoS 규칙 세트는 일치 조건
application-any으로 구성되며 통합 정책에서 특정 동적 애플리케이션이 일치 조건으로 사용되며, AppQoS 기능은 통합 정책의 규칙에 따라 작동합니다.
통합 정책에 대한 기본 애플리케이션 서비스 품질 규칙 집합 이해
AppQoS 기본 규칙 세트를 구성하여 보안 정책 충돌을 관리할 수 있습니다.
초기 정책 조회 단계는 동적 애플리케이션을 식별하기 전에 발생합니다. 잠재적 정책 목록에 다른 AppQoS 규칙 세트를 포함하는 여러 정책이 있는 경우, 보안 디바이스는 보다 명시적인 일치가 발생할 때까지 기본 AppQoS 규칙 세트를 적용합니다.
계층 수준에서 edit security ngfw AppQoS를 기본 AppQoS 규칙 세트로 설정할 수 있습니다. 기본 AppQoS 규칙 세트는 계층 수준에서 구성된 기존 AppQoS 규칙 세트 중 하나에서 활용됩니다.[edit class-of-service application-traffic-control]
표 2 에는 통합 정책의 다양한 시나리오에서 기본 AppQoS 규칙 세트의 사용법이 요약되어 있습니다.
애플리케이션 식별 상태 |
AppQoS 규칙 세트 사용 |
작업 |
|---|---|---|
보안 정책 충돌이 없습니다. |
[ |
AppQoS는 AppQoS 규칙 집합에서와 같이 적용됩니다. |
보안 정책 충돌 및 충돌하는 정책에는 고유한 AppQoS 규칙 세트가 있습니다. |
기본 AppQoS 규칙 세트가 구성되지 않았거나 찾을 수 없습니다. |
기본 AppQoS 프로필이 구성되지 않았으므로 세션은 무시됩니다. 따라서 정책 충돌 시나리오에서 마지막으로 일치하는 정책에 AppQoS 규칙 세트가 있더라도 이 규칙 세트는 적용되지 않습니다. 기본 AppQoS 규칙 세트를 구성하여 보안 정책 충돌을 관리하는 것이 좋습니다. |
기본 AppQoS 규칙 세트가 구성됩니다. |
AppQoS는 기본 AppQoS 규칙 세트에서와 같이 적용됩니다. |
|
최종 응용 프로그램 식별 |
일치하는 보안 정책에는 기본 AppQoS 규칙 세트와 동일한 AppQoS 규칙 세트가 있습니다. |
AppQoS는 기본 AppQoS 규칙 세트에서와 같이 적용됩니다. |
일치하는 보안 정책에는 AppQoS 규칙 세트가 없습니다. |
기본 AppQoS 규칙 집합이 적용되지 않으며 AppQoS는 세션에 적용되지 않습니다. |
|
일치하는 보안 정책에는 이미 적용된 기본 AppQoS 규칙 세트와 다른 AppQoS 규칙 세트가 있습니다. |
기본 AppQoS 규칙 세트는 기본 AppQoS 규칙 세트로 유지됩니다. |
기본 AppQoS 규칙 세트가 트래픽에 적용되고 최종 보안 정책에 다른 AppQoS 규칙 세트가 있는 경우, 이러한 경우 기본 AppQoS 규칙 세트에서 최종 보안 정책의 AppQoS 규칙 세트로 전환하는 것은 지원되지 않습니다.
다른 시나리오에서 설정된 기본 애플리케이션 서비스 품질 규칙
다음 링크는 다양한 시나리오에서 기본 AppQoS 규칙 세트에 대해 논의하는 예입니다.
표 3 에는 동적 애플리케이션을 일치 조건으로 사용하는 통합 정책에 대해 구성된 다양한 AppQoS 규칙 세트가 나와 있습니다.
보안 정책 |
소스 영역 |
소스 IP 주소 |
대상 영역 |
대상 IP 주소 |
포트 번호 |
프로토콜 |
동적 애플리케이션 |
서비스 |
AppQoS 규칙 세트 |
|---|---|---|---|---|---|---|---|---|---|
정책-P1 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
페이스북 |
AppQoS |
AppQoS-1 |
정책-P2 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
구글 |
AppQoS |
앱QoS-2 |
정책-P3 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
유튜브 |
AppQoS |
AppQoS-3 |
이 예에서는 모든 AppQoS 규칙 세트(AppQoS-1, AppQoS-2, AppQoS-3)를 계층 수준에서 기본 AppQoS 규칙 세트로 구성할 수 있습니다. [security ngfw] 기본 규칙 세트가 보안 정책 구성의 일부가 될 필요는 없습니다. 계층 수준 아래의 [edit class-of-service application-traffic-control] 모든 AppQoS 규칙 세트는 기본 AppQoS 규칙 세트로 할당될 수 있습니다.
- 정책 충돌 없음—모든 정책에 동일한 AppQoS 규칙 세트가 있습니다
- 정책 충돌 없음—모든 정책에는 동일한 AppQoS 규칙 세트가 있으며 최종 정책에는 AppQoS 규칙 세트가 없습니다.
- 정책 충돌 - 최종 정책에 대해 AppQoS 규칙 세트가 구성되지 않습니다.
- 정책 충돌 - 기본 AppQoS 규칙 세트 및 최종 정책에 대한 다른 AppQoS 규칙 세트
정책 충돌 없음—모든 정책에 동일한 AppQoS 규칙 세트가 있습니다
일치하는 모든 정책에는 표 4와 같이 동일한 AppQoS 규칙 세트가 있습니다.
보안 정책 |
소스 영역 |
소스 IP 주소 |
대상 영역 |
대상 IP 주소 |
포트 번호 |
프로토콜 |
동적 애플리케이션 |
서비스 |
AppQoS 규칙 세트 |
|---|---|---|---|---|---|---|---|---|---|
정책-P1 |
S1 |
모두 |
1일 |
모두 |
모두 |
모두 |
페이스북 |
AppQoS |
AppQoS-1 |
정책-P2 |
S1 |
모두 |
1일 |
모두 |
모두 |
모두 |
구글 |
AppQoS |
AppQoS-1 |
이 시나리오에서 정책-P1 및 정책-P2는 동일한 AppQoS 규칙 세트를 갖습니다. 즉, AppQoS-1입니다. 규칙 집합 AppQoS-1이 적용됩니다. 이 시나리오에서는 Policy-P3이 구성되지 않습니다.
규칙 세트 AppQoS-2를 기본 규칙 세트로 구성한 경우 적용되지 않습니다. 충돌하는 정책(Policy-P1 및 Policy-P2)의 AppQoS 규칙 세트에 충돌이 없기 때문입니다.
정책 충돌 없음—모든 정책에는 동일한 AppQoS 규칙 세트가 있으며 최종 정책에는 AppQoS 규칙 세트가 없습니다.
일치하는 모든 정책에는 표 5 와 같이 동일한 AppQoS 규칙 세트가 있으며 최종 정책에는 AppQoS 규칙 세트가 없습니다.
보안 정책 |
소스 영역 |
소스 IP 주소 |
대상 영역 |
대상 IP 주소 |
포트 번호 |
프로토콜 |
동적 애플리케이션 |
서비스 |
AppQoS 규칙 세트 |
|---|---|---|---|---|---|---|---|---|---|
정책-P1 |
S1 |
모두 |
1일 |
모두 |
모두 |
모두 |
페이스북 |
AppQoS |
AppQoS-1 |
정책-P2 |
S1 |
모두 |
1일 |
모두 |
모두 |
모두 |
구글 |
AppQoS |
AppQoS-1 |
정책-P3 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
유튜브 |
기타 |
없음 |
이 시나리오에서 Policy-P1과 Policy-P2 모두 동일한 AppQoS 규칙 세트, 즉 AppQoS-1을 갖습니다. 이 경우 규칙 집합 AppQoS-1이 적용됩니다.
최종 정책 Policy-P3가 일치하면 AppQoS 규칙 세트가 Policy-P3에 대해 구성되지 않았기 때문에 AppQoS는 세션을 무시합니다.
최종 보안 정책에 AppQoS 규칙 세트가 없는 경우 AppQoS는 트래픽에 적용되지 않습니다. 사전 일치 단계에서 적용된 모든 AppQoS 설정이 원래 값으로 되돌아갑니다.
정책 충돌 - 최종 정책에 대해 AppQoS 규칙 세트가 구성되지 않습니다.
기본 AppQoS 규칙 세트(이 시나리오에서는 AppQoS-1)는 표 6과 같이 잠재적인 정책 일치 중에 적용됩니다. 마지막 정책 Policy-P3에는 AppQoS 규칙 세트가 없습니다.
보안 정책 |
소스 영역 |
소스 IP 주소 |
대상 영역 |
대상 IP 주소 |
포트 번호 |
프로토콜 |
동적 애플리케이션 |
서비스 |
AppQoS 규칙 세트 |
|---|---|---|---|---|---|---|---|---|---|
정책-P1 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
페이스북 |
AppQoS |
AppQoS-1 |
정책-P2 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
구글 |
AppQoS |
앱QoS-2 |
정책-P3 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
유튜브 |
기타 |
NA |
AppQoS는 최종 일치하는 정책 Policy-P3이 적용되는 경우 세션을 무시합니다.
최종 보안 정책에 AppQoS 규칙 세트가 없는 경우 AppQoS는 트래픽에 적용되지 않습니다. 이 경우 사전 일치 단계에서 적용된 모든 AppQoS 설정이 원래 값으로 되돌아갑니다.
정책 충돌 - 기본 AppQoS 규칙 세트 및 최종 정책에 대한 다른 AppQoS 규칙 세트
규칙 세트 AppQoS-1은 기본 규칙 세트로 구성되며 최종 애플리케이션이 아직 식별되지 않을 때 적용됩니다. 마지막 정책 Policy-P3에는 표 7과 같이 다른 AppQoS 규칙 세트(AppQoS-3)가 있습니다.
보안 정책 |
소스 영역 |
소스 IP 주소 |
대상 영역 |
대상 IP 주소 |
포트 번호 |
프로토콜 |
동적 애플리케이션 |
서비스 |
AppQoS 규칙 세트 |
|---|---|---|---|---|---|---|---|---|---|
정책-P1 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
페이스북 |
AppQoS |
AppQoS-1 |
정책-P2 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
구글 |
AppQoS |
앱QoS-2 |
정책-P3 |
S1 |
50.1.1.1 |
1일 |
모두 |
모두 |
모두 |
유튜브 |
AppQoS |
AppQoS-3 |
최종 애플리케이션이 식별되면 정책 Policy-P3이 일치하고 적용됩니다. 이 경우 규칙 세트 AppQoS-3이 적용되지 않습니다. 대신 규칙 세트 AppQoS-1이 기본 규칙 세트로 적용되고 기본 규칙 세트로 유지됩니다.
통합 정책으로 AppQoS의 한계
일치하는 트래픽에 보안 정책이 적용되면 AppQoS 규칙 세트가 허용된 트래픽에 적용됩니다. 보안 정책과 적용된 AppQoS 규칙 세트에 서로 다른 동적 애플리케이션이 있는 경우 다음 예와 같이 충돌이 발생할 수 있습니다.
user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 match application junos:GOOGLEuser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then forwarding-class network-controluser@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then dscp-code-point 110001user@host#set class-of-service application-traffic-control rule-sets AQ2 rule 1 then loss-priority high
user@host#set security policies from-zone trust to-zone untrust policy 1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy 1 match dynamic-application junos:FTPuser@host#set security policies from-zone trust to-zone untrust policy 1 then permit application-services application-traffic-control rule-set AQ2
이 예에서 애플리케이션 트래픽 제어 규칙은 junos:GOOGLE에 대해 구성되며 동적 애플리케이션에 대한 보안 정책 일치 조건은 junos: FTP입니다. 이러한 경우 최종 정책을 적용할 때 충돌이 발생할 수 있습니다.
또한보십시오
예: 통합 정책으로 애플리케이션 서비스 품질 구성
이 예에서는 통합 정책 내에서 애플리케이션 서비스 품질(AppQoS)을 활성화하여 트래픽에 대한 우선 순위 지정 및 속도 제한을 제공하는 방법을 보여줍니다.
요구 사항
이 예에서 사용되는 하드웨어 및 소프트웨어 구성 요소는 다음과 같습니다.
Junos OS 릴리스 18.2R1 이상을 실행하는 SRX 시리즈 방화벽입니다. 이 구성 예는 Junos OS 릴리스 18.2R1에 대해 테스트되었습니다.
이 기능을 구성하기 전에 디바이스 초기화 이외의 특별한 구성은 필요하지 않습니다.
개요
이 예에서는 AppQoS 규칙 세트를 구성하고 Facebook 애플리케이션의 보안 정책에서 AppQoS를 애플리케이션 서비스로 호출합니다.
[] 계층 수준에서edit security ngfw 기본 AppQoS 규칙 세트를 정의하여 보안 정책 충돌(있는 경우)을 관리합니다.
구성
절차
단계별 절차
통합 정책으로 AppQoS를 구성하려면:
AppQoS 규칙 세트를 정의합니다.
[edit] user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 match application junos:FACEBOOK-APP user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then forwarding-class fc-appqos loss-priority medium-low dscp-code-point 101110 log user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then rate-limit client-to-server Ratelimit1 user@host# set class-of-service application-traffic-control rate-limiters Ratelimit1 bandwidth-limit 1000
기본 AppQoS 규칙 세트를 구성합니다. 애플리케이션 트래픽 제어에서 생성된 규칙 세트
RS1를 기본 AppQoS 규칙 세트로 선택합니다.[edit] user@host# set security ngfw default-profile application-traffic-control rule-set RS1
서비스 등급 규칙 세트를 통합 정책에 연결합니다.
[edit] user@host# set security policies from-zone untrust to-zone trust policy from_internet match source-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match destination-address any user@host# set security policies from-zone untrust to-zone trust policy from_internet match application any user@host# set security policies from-zone untrust to-zone trust policy from_internet match dynamic-application junos:FACEBOOK-APP user@host# set security policies from-zone untrust to-zone trust policy from_internet then permit application-services application-traffic-control rule-set RS1
결과
구성 모드에서 명령을 입력하여 정책 구성을 확인합니다. show security policies 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정합니다.
간결성을 위해 이 show 명령 출력은 이 예와 관련된 구성만 포함합니다. 시스템의 다른 구성은 생략 부호(...)로 대체되었습니다.
...
policies {
from-zone trust to-zone untrust {
policy permit-all {
match {
source-address any;
destination-address any;
application any;
dynamic-application junos:FACEBOOK-APP;
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
}
...
ngfw {
default-profile {
application-traffic-control {
rule-set RS1;
}
}
}
디바이스 구성이 완료되면 구성 모드에서 들어갑니다 commit .
검증
구성이 제대로 작동하고 있는지 확인합니다.
플로우 세션 구성 확인
목적
AppQoS 세션 통계를 표시합니다.
작업
운영 모드에서 명령을 입력합니다.show class-of-service application-traffic-control counter
샘플 출력
명령 이름
pic: 0/0 Counter type Value Sessions processed 2 Sessions marked 1 Sessions honored 1 Sessions rate limited 1 Client-to-server flows rate limited 0 Server-to-client flows rate limited 1 Session default ruleset hit 1 Session ignored no default ruleset 1
의미
출력에는 처리되고, 표시되고, 준수된 세션 수가 표시됩니다. 속도 제한 통계는 속도 제한된 방향 세션 흐름의 수를 계산합니다.
HTTP2: AppQoS DSCP 지원
HTTP/2 AppQoS(Application Quality of Service) DSCP(Differentiated Services Code Point) 지원은 첫 번째 스트림 분류를 활용하여 HTTP/2 세션에서 QoS(Quality of Service) 규칙 적용을 향상시킵니다. 이러한 개선 사항을 통해 QoS 규칙을 HTTP/2 세션에 적용할 수 있으므로 애플리케이션 유형에 따라 트래픽이 분류되고 우선 순위가 지정됩니다. 이 기능을 사용하면 HTTP/2 트래픽에 세분화된 AppQoS 정책을 적용할 수 있으며, 이는 서로 다른 애플리케이션으로 분류된 여러 스트림을 처리할 때 매우 중요합니다. 첫 번째 스트림 세션의 분류를 기반으로 AppQoS 규칙을 적용하면 지정되지 않은 규칙으로 인해 폴백 로직이 호출되는 경우에도 일관된 QoS 관리를 보장할 수 있습니다. 이 기능은 기존 HTTP/2 트래픽 관리 프레임워크에 통합되어 기존 및 통합 정책 사례 전반에 걸친 시나리오를 해결하고, 추가 CLI 구성 없이 암호화된 세션에서 효과적인 QoS 적용을 유지합니다.
개요
이제 HTTP/2 트래픽은 특정 HTTP/2 규칙이 없을 때 DSCP 표시에 대한 HTTP AppQoS 규칙을 상속하여 일관된 QoS 동작을 보장합니다.
HTTP는 여러 앱(예: facebook, twitter)이 별도의 세션으로 표시되고 세션별로 AppQoS가 적용되어 독립적으로 분류되는 포괄적인 애플리케이션입니다. 이전에는 HTTP/2 세션이 하위 스트림 애플리케이션 분류 없이 http2로만 분류되었습니다
즉, HTTP/2 세션의 경우 상위 세션의 AppQoS 규칙만 적용할 수 있습니다. 그러나 HTTP/2는 각각 다른 애플리케이션으로 분류되는 여러 스트림을 사용합니다. AppQoS 규칙 일치에 대해 하위 세션 분류는 무시되었습니다.
새 업데이트에서는 첫 번째 스트림 세션의 애플리케이션 분류를 사용하여 AppQoS 규칙을 일치시키고 HTTP/2 상위 세션에 적용합니다. 첫 번째 스트림의 최종 분류 애플리케이션에 AppQoS 규칙이 없는 경우 세션은 상위 HTTP/2 AppQoS 규칙으로 대체됩니다.
예:
여러 스트림을 포함하는 HTTP/2 세션을 고려하십시오.
- 첫 번째 스트림은 twitter로 식별됩니다.
- 트위터에 대한 AppQoS 규칙이 적용됩니다.
- HTTP/2 상위 세션의 모든 스트림은 규칙을 상속합니다.
여기서 패킷은 더 이상 일반 http2 대기열로 이동하지 않습니다. 그들은 전적으로 First Stream의 애플리케이션 대기열(Twitter)으로 이동합니다.
폴백 로직
HTTP/2 트래픽은 HTTP 트래픽의 일부로 처리됩니다. HTTP/2 규칙이 누락된 경우 트래픽은 DSCP 표시를 위한 HTTP AppQoS 규칙으로 폴백됩니다. 이러한 폴백을 달성하기 위해 다음 예와 같이 분류 경로를 조정합니다.
학부모 세션
- 이전 동작:
ip.tcp.ssl.http2 - 새로운 동작:
ip.tcp.ssl.http.http2
하위 세션
- 이전 동작:
ip.tcp.ssl.http.facebook - 새로운 동작:
ip.tcp.ssl.http.http2.facebook
분류 논리
HTTP/2용 AppQoS는 가장 구체적인 앱에서 시작하여 HTTP2, HTTP, SSL 및 application-any를 통해 폴백하는 하향식 규칙 조회를 사용합니다. 이제 첫 번째 스트림 세션의 분류가 상위 세션 규칙 일치에 사용되어 정확한 QoS 할당 및 로깅을 보장합니다.
규칙 집합 및 애플리케이션 매핑- 각 보안 정책은 다양한 애플리케이션(예: http, http2, facebook)에 대해 특정 AppQoS 규칙이 포함된 규칙 세트를 사용합니다.
- 각 규칙은 포워딩 클래스(Best Effort, Assured Forwarding, Expedited Forwarding, Network Control)와 CoS 대기열을 할당합니다.
- AppQoS 규칙 조회는 가장 구체적인 애플리케이션(중첩 앱)에서 시작하여 계층 위로 이동합니다. 세션(상위/자위)은 계층 경로를 사용하여 분류됩니다(예:
ip.tcp.ssl.http.http2.facebook).이 예에서 조회 시퀀스는 다음과 같습니다.
- 중첩된 앱(
facebook-chat)이 규칙 집합에 구성되지 않은 경우 규칙이http2적용됩니다. - 구성되지 않은
http경우http2규칙이 적용됩니다. - 구성되지 않은
ssl경우http규칙이 적용됩니다. - 분류된 앱
application-any에 대한 AppQoS 규칙이 없는 경우 규칙이 적용됩니다. - 구성되지 않은 경우
application-any세션은 이전에 적용된 DSCP 규칙으로 계속됩니다.
이 분류를 통해 HTTP/2 세션은 절대 무시되지 않고 항상 QoS 처리를 받게 됩니다.
- 중첩된 앱(
예: AppQoS 프로필에는 특정 애플리케이션에 대한 규칙과 "모두" catch-all 규칙이 포함되어 있습니다. 예를 들어 프로필에는 HTTP, Facebook, Yahoo 및 Any에 대한 규칙 세트가 포함되어 있으며 첫 번째 스트림은 Http.http2.twitter로 분류됩니다.
사례 A — "모든" 규칙 구성
- 명시적인 트위터 규칙은 존재하지 않습니다.
- Any 규칙이 있기 때문에 AppQoS는 Any를 선택합니다.
- 결과: Any 규칙이 적용됩니다.
사례 B — "모든" 규칙이 구성되지 않음
- 명시적인 트위터 규칙은 존재하지 않습니다.
- 사용할 수 있는 규칙이 없습니다.
- 이 경우 시스템은 구체성 내림차순에 따라 다음으로 가장 좋은 일치 항목으로 다시 폴백합니다.
- HTTP2 규칙(있는 경우)
- http2 규칙이 없는 경우 http로 폴백→
- 기본 대기열을 사용할 → http 규칙이 없는 경우
- 결과: 위의 대체 순서에 따라 가장 가까운 일치 규칙이 선택됩니다.
- 상위 세션: 일반적으로 상위 수준(예: http2)으로 분류됩니다.
- 자식 세션: 보다 구체적인 중첩 앱(예: facebook, twitter)으로 분류됩니다.
이제 첫 번째 스트림 세션의 분류가 상위 세션의 규칙 일치에 고려됩니다.
포워딩 및 로깅- 각 세션의 트래픽에는 일치하는 규칙에 따라 포워딩 클래스와 대기열이 할당됩니다.
- Syslog 항목은 세션 및 스트림 폐쇄 모두에 대한 분류 및 규칙 일치를 반영합니다
제한 사항
- HTTP/2의 경우 상위 세션에서 AppQoS 규칙 일치에는 첫 번째 스트림의 애플리케이션 분류만 사용됩니다.
- 수명이 긴 세션에서 미드스트림 앱 스위치(HTTP/1 또는 HTTP/2)로 인해 CoS 대기열이 변경되어 패킷이 재정렬될 수 있습니다. 최종 디바이스의 TCP 리어셈블리는 시퀀스 번호를 사용하여 이를 처리합니다.
- AppQoS용 HTTP/2는 섀시 클러스터 및 멀티노드 고가용성 시나리오에서 지원되지 않습니다.
- SSL 전달 프록시가 구성된 경우 HTTP/1.1 및 HTTP/2 트래픽 설정 모두에서 HTTPS 트래픽에 대해 AppQoS 속도 제한기가 제대로 작동하지 않습니다.
HTTP2 암호화된 트래픽
암호화된 트래픽의 경우 HTTP/2 모듈이 비활성화되므로 HTTP/2 하위 세션이 생성되지 않습니다. AppQoS는 상위 세션에만 적용됩니다.
플랫폼별 AppQoS 동작
AppQoS 및 기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인합니다.
다음 표를 사용하여 플랫폼의 플랫폼별 동작을 검토하십시오.
| 플랫폼 |
차이 |
|---|---|
| SRX 시리즈 |
SRX5400, SRX5600 및 SRX5800은 포워딩 클래스 이름 및 대기열 할당을 정의하기 위해 다음 구성 문을 사용합니다. [edit class-of-service] user@host# set forwarding-classes class forwarding-class-name queue-num queue-number |
| SRX 시리즈 | SRX300, SRX320, SRX340, SRX345, SRX380, SRX400, SRX440, SRX550M, SRX1500, SRX4100, SRX4200, SRX4600 및 vSRX 포워딩 클래스 이름 및 대기열 할당을 정의하기 위해 다음 구성 문을 사용합니다. [edit class-of-service] user@host# set forwarding-classes queue queue-number forwarding-class-name |
| SRX 시리즈 | SRX300, SRX320, SRX340, SRX345, SRX400, SRX440은 AppQoS 규칙의 옵션을 사용하여 loss-priority-high기본 작업을 재정의합니다.[edit] user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1 then rate-limit loss-priority-high |
| SRX 시리즈 | SRX5400, SRX5600 및 SRX5800은 디바이스당 최대 1000개의 속도 제한기를 지원합니다. 그러나 각각 bandwidth-limit 및 burst-size-limit 매개 변수의 고유한 조합으로 정의되는 16개의 개별 프로필만 허용합니다. |
변경 내역 표
기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.