qos 패킷 스케줄러는 어디에 있습니까? QoS의 신화

로딩할 때 웹 페이지를 여는 데 시간이 오래 걸리고 원하는 수준에서 파일 다운로드가 발생하지 않는 것은 아무도 좋아하지 않습니다. 공급자로부터 서비스를 주문할 때 20 또는 100Mb / s를 명확하게 표시했지만 실제로는 그러한 속도를 얻지 못합니다.

물론 이에 대한 설명도 있다. 첫째, 시스템이 필요로 하는 데 약 20%가 소요되고 두 번째로 시간이 걸리지만 브라우저가 DNS 서버로부터 응답을 받습니다.

그것이 무엇이든 우리는 이제 인터넷 속도를 여러 번 높이는 방법을 알아낼 것입니다.

QoS 속도 제한 비활성화

일반적으로 시스템의 속도 제한은 20%이지만 사람마다 다를 수 있습니다. 인터넷 속도를 높이려면 이 설정을 비활성화해야 합니다. 이를 위해 로컬 그룹 정책을 사용합니다. 안타깝게도 이 기능은 Windows Pro 버전에서만 사용할 수 있습니다.

조합을 사용하여 "실행" 창을 엽니다. 승+R표시되는 창에서 다음 명령을 작성하십시오. gpedit.msc .

열리는 창의 왼쪽에서 다음 섹션으로 이동합니다. 컴퓨터 구성 – 관리 템플릿- 그물 - QoS 패킷 스케줄러 – 예약된 대역폭 제한.

거기에서 "예약 대역폭 제한" 항목을 찾습니다. 두 번 클릭하고 매개 변수를 다음으로 설정하십시오. "포함"숫자를 입력한 다음 “0” "대역폭 제한"에서. 적용을 클릭합니다.

네트워크 장치가 QoS 패킷 스케줄러와 함께 작동하는지 확인하려면 네트워크 및 공유 센터로 이동해야 합니다. 작업 표시줄에서 Wi-Fi 아이콘을 클릭하거나 유선 연결을 마우스 오른쪽 버튼으로 클릭하면 이동할 수 있습니다. 왼쪽에서 "어댑터 설정 변경" 섹션으로 이동합니다. 연결을 마우스 오른쪽 버튼으로 클릭하고 "속성"을 선택하십시오. 옵션이 있어야 합니다 QoS 패킷 스케줄러, 확인 표시로 표시됩니다.

레지스트리를 통해 QoS 비활성화

PRO 이외의 Windows 버전이 있는 경우 이 지침이 적합할 수 있습니다. 레지스트리로 이동하여 Win + R 조합을 사용하고 명령을 입력합니다. regedit.

다음 섹션으로 이동합니다.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft

여기에서 섹션을 찾습니다. 창, 마우스 오른쪽 버튼으로 클릭하고 이름으로 새 파티션을 만듭니다. psched.

생성된 섹션으로 이동하고 오른쪽에 다음 이름으로 32비트 DWORD 매개변수를 생성합니다. NonBestEffortLimit. 이 매개변수에 값을 할당합니다. «0» .

작업이 끝나면 컴퓨터를 다시 시작하십시오.

소프트웨어에서 인터넷 속도 제한 비활성화

인터넷이 필요한 프로그램(예: 토렌트 클라이언트)을 사용할 때 활성화된 속도 제한 기능이 있는 경우가 있습니다.

예를 들어 토렌트 클라이언트를 보자. 활성 다운로드를 마우스 오른쪽 버튼으로 클릭하면 항목이 있습니다. "접수 제한". 우리는 마우스를 가리키고 봅니다. 모드가 활성화되어 있어야 합니다. "제한 없는".

다른 토렌트 클라이언트도 마찬가지입니다. 다른 유형의 프로그램에서는 유사한 것을 파헤쳐야 합니다.

속도를 높이기 위해 DNS 캐시를 늘리는 방법은 무엇입니까?

많은 사람들이 알고 있듯이 DNS 캐시를 사용하면 이미 방문한 리소스의 IP 주소를 저장할 수 있으며 재방문 시 DNS 캐시를 사용하므로 페이지를 훨씬 빠르게 열 수 있습니다. 불행히도 그 양은 무한하지 않지만 늘릴 수 있습니다.

가다! Win + R을 누르고 레지스트리를 입력하는 명령을 입력하십시오 - regedit. 왼쪽의 이 섹션으로 이동해야 하는 창이 열립니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNScache\Parameters

오른쪽에서 빈 공간을 마우스 오른쪽 버튼으로 클릭하고 4개의 "DWORD" 매개변수를 만들고 다음과 같은 이름을 지정해야 합니다. CacheHashTableBucketSize, 캐시 해시 테이블 크기, MaxCacheEntryTtlLimit, MaxSOACacheEntryTtlLimit.

각각은 1, 384, 64000 및 301의 값을 가져야 합니다.

작업을 성공적으로 완료하려면 컴퓨터를 다시 시작하십시오.

TCP 자동 조정 - 비활성화

시스템에 웹페이지 로딩이 느려지는 기능이 있는데, 이는 일부 서버에서는 성능이 좋지 않기 때문입니다. 그래서 우리는 그것을 끄겠습니다.

이 작업을 수행하려면 관리자 권한 명령 프롬프트를 열고 다음 명령을 실행해야 합니다.

사이트 로딩 속도를 높이는 브라우저의 터보 모드

많은 브라우저에는 페이지 열기 속도를 높이는 "터보 모드" 기능이 있습니다. 지금까지 다음과 같은 인기 있는 브라우저에서 사용할 수 있습니다. Opera 및 Yandex 브라우저. 다른 사용자의 경우 특수 확장을 다운로드할 수 있습니다.

Opera에서 이 기능은 왼쪽 상단 모서리에 있는 "Opera" 버튼을 클릭하면 활성화됩니다. 기능 찾기 오페라 터보활성화합니다.

Yandex 브라우저에서 이 기능은 설정 - 고급 설정 표시에서 활성화됩니다. "터보" 섹션 옆에 "항상 켜짐".

페이지 로딩을 증가시키는 NameBench 유틸리티

많은 공급자, 특히 상업용 공급자는 항상 장비를 절약하기를 원합니다. 그리고 웹사이트를 방문하기 시작하면 DNS 서버(제공업체의 장비)에 액세스합니다. 가격이 저렴하면 페이지 로딩 속도가 매우 느려집니다. 이 문제를 해결하려면 빠른 DNS 서버가 필요하며 NameBench 프로그램이 이를 찾는 데 도움이 됩니다.벤치마크를 시작합니다. 프로그램은 많은 수의 DNS 서버 테스트를 시작하고 가장 빠른 서버를 선택합니다.

NameBench가 원하는 서버를 찾으면 연결 설정에서 지정해야 하는 해당 IP 주소가 표시됩니다.

라우터의 펌웨어 업데이트

이것은 마지막 요점이지만 덜 중요하지는 않습니다. 펌웨어가 매우 오래된 라우터를 사용하는 경우 기적을 기대하지 마십시오. 인터넷에서 라우터의 펌웨어를 찾아 설치 지침을 찾고 문제를 방지하기 위해 이전 펌웨어를 저장합니다.

이것이 실제로 최신 버전의 Windows에서 사용할 수 있는 모든 방법입니다. 다른 것이 있을 수 있지만, 만약 그렇다면 우리는 그것을 우회하지 않을 것입니다.

이 기사 시리즈의 첫 번째 부분에서 QoS가 무엇을 하고 무엇을 위해 사용되는지에 대해 이야기했습니다. 이 부분에서는 QoS가 어떻게 작동하는지 설명하면서 대화를 계속할 것입니다. 이 기사를 읽을 때 여기에 제공된 정보는 Windows 2000 Server QoS 적용과 다른 Windows Server 2003 QoS 적용을 기반으로 한다는 점을 유의하십시오.

트래픽 관리 API

네트워크 트래픽의 우선 순위를 지정할 때의 주요 문제 중 하나는 트래픽을 생성하는 컴퓨터를 기반으로 트래픽의 우선 순위를 지정할 수 없다는 것입니다. 단일 컴퓨터에서 여러 응용 프로그램을 실행하고 각 응용 프로그램(및 운영 체제)에 대해 별도의 트래픽 흐름을 만드는 것이 일반적입니다. 이 경우 각 트래픽 흐름의 우선 순위를 개별적으로 지정해야 합니다. 결국 한 응용 프로그램에는 여분의 대역폭이 필요할 수 있지만 다른 응용 프로그램은 최상의 전달을 위해 이상적으로 적합합니다.

여기서 Traffic Control API(Traffic Control Programming Interface)가 작동합니다. 트래픽 제어 API는 개별 패킷에 QoS 설정을 적용할 수 있는 애플리케이션 프로그래밍 인터페이스입니다. Traffic Control API는 개별 트래픽 흐름을 정의하고 이러한 흐름에 다양한 QoS 제어 방법을 적용하여 작동합니다.

Traffic Control API가 가장 먼저 하는 일은 filterspec으로 알려진 것을 생성하는 것입니다. filterspec은 본질적으로 패킷이 특정 스트림에 속한다는 의미를 정의하는 필터입니다. filterspec에서 사용하는 일부 속성에는 패킷의 소스 및 대상 IP 주소와 포트 번호가 포함됩니다.

filterspec이 정의되면 API를 사용하여 flowspec을 만들 수 있습니다. flowspec은 패킷 시퀀스에 적용될 QoS 매개변수를 정의합니다. flowspec에 정의된 일부 매개변수에는 비트 전송률(허용 가능한 비트 전송률) 및 서비스 유형이 포함됩니다.

Traffic Control API에서 정의한 세 번째 개념은 흐름 개념입니다. 흐름은 동일한 흐름 사양이 적용되는 간단한 패킷 시퀀스입니다. 간단히 말해서 filterspec은 flowspec에 포함될 패킷을 결정합니다. flowspec은 패킷이 더 높은 우선 순위로 처리되는지 여부를 결정하며, flow는 flowspec이 적용되는 패킷의 실제 전송입니다. 스트림의 모든 패킷은 동일하게 처리됩니다.

Windows 2000에서 사용되는 일반 QoS API에 비해 Traffic Control API의 장점 중 하나는 집계(병합)를 사용할 수 있다는 점입니다. 노드에 여러 데이터 스트림을 공통 대상으로 보내는 여러 애플리케이션이 있는 경우 이러한 패킷을 공통 스트림으로 결합할 수 있습니다. 이는 소스 및 대상 IP 주소가 동일한 한 응용 프로그램이 다른 포트 번호를 사용하는 경우에도 작동합니다.

일반 패킷 분류기

이전 섹션에서 flowspec, filterspec 및 흐름 간의 관계에 대해 이야기했습니다. 그러나 Traffic Control API는 단지 애플리케이션 프로그래밍 인터페이스라는 것을 기억하는 것이 중요합니다. 따라서 트래픽 흐름을 생성하는 것이 아니라 트래픽 흐름을 식별하고 우선 순위를 지정하는 것이 그 역할입니다.

Generic Packet Classifier는 스트림 생성을 담당합니다. 마지막 섹션에서 기억하듯이 flowspec에 정의된 속성 중 하나는 서비스 유형이었습니다. 서비스 유형은 본질적으로 스레드의 우선 순위를 결정합니다. Generic Packet Classifier는 flowspec에 할당된 서비스 유형을 결정하는 역할을 하며, 그 후에 서비스 유형에 적합한 대기열에 연결된 패킷을 배치합니다. 각 스레드는 별도의 대기열에 배치됩니다.

QoS 패킷 스케줄러

알아야 할 세 번째 QoS 구성 요소는 QoS 패킷 스케줄러입니다. 간단히 말해서 QoS 패킷 스케줄러의 주요 작업은 트래픽 형성입니다. 이를 위해 패킷 스케줄러는 다양한 대기열에서 패킷을 수신한 다음 이러한 패킷에 우선 순위와 흐름 속도를 표시합니다.

이 기사 시리즈의 첫 번째 부분에서 논의한 것처럼 QoS가 올바르게 작동하려면 패킷의 소스와 목적지 사이의 다양한 구성 요소가 QoS를 지원해야 합니다(즉, 인식해야 함). 이러한 장치는 QoS를 처리하는 방법을 알아야 하지만 우선 순위 지정 없이 일반 트래픽을 처리하는 방법도 알아야 합니다. 이를 가능하게 하기 위해 QoS는 태깅이라는 기술을 사용합니다.

실제로 여기에는 두 가지 유형의 표시가 있습니다. QoS 패킷 스케줄러는 Layer 3 장치에서 인식되는 Diffserv 표시와 Layer 2 장치에서 인식되는 802.1p 표시를 사용합니다.

QoS 패킷 스케줄러 구성

마킹이 작동하는 방식을 보여주기 전에 모든 것이 작동하려면 QoS 패킷 스케줄러를 설정해야 합니다. Windows Server 2003에서 QoS 패킷 스케줄러는 Microsoft 네트워크용 클라이언트나 TCP/IP 프로토콜과 마찬가지로 선택적 네트워킹 구성 요소입니다. QoS 패킷 스케줄러를 활성화하려면 서버 네트워크 연결의 속성 페이지를 열고 그림 A와 같이 QoS 패킷 스케줄러 옆의 확인란을 선택합니다. QoS 패킷 스케줄러가 목록에 없으면 설치 버튼을 클릭하고 지침을 따릅니다.

그림 A: QoS를 사용하려면 먼저 QoS 패킷 스케줄러를 활성화해야 합니다.

QoS 패킷 스케줄러에 대해 알아야 할 또 다른 사항은 네트워크 어댑터가 올바르게 작동하려면 802.1p 태그 지정을 지원해야 한다는 것입니다. 어댑터를 확인하려면 구성 버튼(그림 A)을 클릭하면 Windows에 네트워크 어댑터의 속성이 표시됩니다. 속성 페이지의 "고급" 탭을 보면 네트워크 어댑터가 지원하는 다양한 속성을 볼 수 있습니다.

그림 B를 보면 목록의 속성 중 하나가 802.1Q/1P VLAN 태깅임을 알 수 있습니다. 또한 이 속성은 기본적으로 비활성화되어 있습니다. 802.1p 태깅을 활성화하려면 이 기능을 활성화하고 확인을 클릭하기만 하면 됩니다.

그림 B: 802.1Q/1P VLAN 태깅을 활성화해야 합니다.

그림 B에서 활성화한 속성이 패킷 태깅이 아니라 VLAN 태깅과 관련되어 있음을 알 수 있습니다. 그 이유는 VLAN 태그에 우선순위 마커가 포함되어 있기 때문입니다. 802.1Q 표준은 VLAN 및 VLAN 태그를 정의합니다. 이 표준은 실제로 우선 순위 코드를 작성하는 데 사용되는 VLAN 패킷의 3비트를 예약합니다. 불행히도 802.1Q 표준은 이러한 우선 순위 코드가 무엇인지 정의하지 않습니다.

802.1P는 802.1Q를 보완하기 위해 만들어졌습니다. 802.1P는 VLAN 태그로 래핑될 수 있는 우선 순위 표시를 정의합니다. 이 두 가지 표준이 세 번째 부분에서 어떻게 작동하는지 알려 드리겠습니다.

결론

이 기사에서는 Windows Server 2003의 QoS 아키텍처에 있는 몇 가지 기본 개념에 대해 논의했습니다. 세 번째 부분에서는 QoS 패킷 스케줄러가 패킷을 표시하는 방법에 대해 자세히 설명합니다. 또한 낮은 대역폭 네트워크 환경에서 QoS가 작동하는 방식에 대해서도 설명합니다.

오늘날 네트워킹에서 가장 인기 있는 영역 중 하나는 기존 데이터 네트워크를 통한 음성 및 비디오 융합입니다. 이러한 종류의 수렴의 문제점 중 하나는 비디오 및 오디오 데이터 패킷이 제대로 작동하기 위해 중단이나 너무 긴 지연 없이 수신자에게 빠르고 안정적으로 전송되어야 한다는 것입니다. 그러나 동시에 이러한 유형의 트래픽은 보다 전통적인 데이터 패킷의 전송을 방해해서는 안 됩니다.

이 문제에 대한 한 가지 가능한 솔루션은 QoS입니다. QoS 또는 서비스 품질은 데이터 패킷의 우선 순위를 지정하는 기술입니다. QoS를 사용하면 다른 패킷보다 우선 순위가 높은 타이밍에 민감한 패킷을 보낼 수 있습니다.

QoS는 Microsoft가 소유한 표준이 아니라 산업 표준입니다. 그러나 Microsoft는 Windows 2000에서 이 QoS 표준을 처음 도입했습니다. 그 이후로 Microsoft의 QoS 버전은 상당히 발전했지만 여전히 업계 표준에 부합합니다.

Windows XP Professional에서 QoS는 주로 대역폭 예약 메커니즘으로 작동합니다. QoS가 활성화되면 애플리케이션은 각 시스템의 네트워크 어댑터가 제공하는 모든 네트워크 대역폭의 최대 20%를 예약할 수 있습니다. 그러나 응용 프로그램에서 예약한 네트워크 대역폭의 양은 구성할 수 있습니다. 예약된 대역폭의 양을 변경하는 방법은 3부에서 보여드리겠습니다.

여분의 대역폭이 어떻게 사용되는지 확인하기 위해 우선 대역폭이 제대로 작동해야 하는 화상 회의 응용 프로그램이 있다고 가정해 보겠습니다. 이 응용 프로그램에 대해 QoS가 활성화되어 있다고 가정하면 시스템 전체 대역폭의 20%를 예약하고 나머지 네트워크 트래픽에 대해 대역폭의 80%를 남겨 둡니다.

화상 회의 응용 프로그램을 제외한 모든 응용 프로그램은 최선의 전달이라는 기술을 사용합니다. 이는 패킷이 동일한 "먼저 전달된 패킷이 먼저 제공됨" 우선순위로 전송됨을 의미합니다. 반면에 화상 회의 애플리케이션 트래픽은 항상 다른 트래픽보다 우선하지만 애플리케이션은 총 대역폭의 20% 이상을 소비할 수 없습니다.

그러나 Windows XP가 우선 순위 트래픽을 위해 일부 대역폭을 예약한다고 해서 정상적인 우선 순위를 가진 응용 프로그램이 여분의 대역폭을 사용할 수 없다는 의미는 아닙니다. 화상 회의 응용 프로그램은 우선 순위가 더 높고 예약된 대역폭의 이점이 있지만 이러한 응용 프로그램이 일관되게 사용될 가능성은 매우 낮습니다. 이 경우 Windows는 네트워크 대역폭의 일부가 예약된 응용 프로그램이 사용되지 않을 때까지 다른 응용 프로그램이 가능한 최상의 배달을 위해 예비 및 예약되지 않은 대역폭을 사용하도록 허용합니다.

화상 회의 응용 프로그램이 시작되자마자 Windows는 강제로 대체를 시작합니다. 그러나 이 경우에도 중복성은 절대적이지 않습니다. Windows가 화상 회의 응용 프로그램을 위해 네트워크 대역폭의 20%를 예약했지만 해당 응용 프로그램에는 전체 20%가 필요하지 않다고 가정해 보겠습니다. 이러한 경우 Windows는 다른 응용 프로그램이 나머지 대역폭을 사용하도록 허용하지만 우선 순위가 더 높은 응용 프로그램의 요구 사항을 지속적으로 모니터링합니다. 애플리케이션에 더 많은 대역폭이 필요한 경우 최대 20%까지 대역폭이 할당됩니다.

내가 말했듯이 QoS는 Microsoft 기술이 아니라 업계 표준입니다. 따라서 QoS는 Windows에서 사용되지만 Windows는 자체적으로 작업을 수행할 수 없습니다. QoS가 작동하려면 발신자와 수신자 사이의 모든 장비가 QoS를 지원해야 합니다. 이는 네트워크 어댑터, 스위치, 라우터 및 사용 중인 기타 모든 장치가 QoS와 수신자 및 발신자의 운영 체제를 인식해야 함을 의미합니다.

궁금한 경우 QoS를 사용하기 위해 이상한 네트워크 인프라를 설정할 필요가 없습니다. ATM(Asynchronous Transfer Mode)은 연결 지향 기술이기 때문에 QoS를 사용하기 위한 훌륭한 네트워크 기술이지만 프레임 릴레이, 이더넷 및 Wi-FI(802.11 x)와 같은 다른 기술과 함께 QoS를 사용할 수도 있습니다.

ATM이 QoS를 위한 이상적인 선택인 이유는 대역폭 예약을 구현하고 하드웨어 수준에서 리소스를 할당할 수 있기 때문입니다. 이러한 유형의 배포는 이더넷 및 유사한 네트워크 기술의 기능을 초월합니다. QoS를 사용할 수 없다는 의미는 아닙니다. QoS가 ATM 환경과 다르게 적용되어야 함을 의미합니다.

ATM 환경에서 자원은 물리적 장치 수준에서 즉시 할당됩니다. 이더넷 및 유사 기술은 이러한 방식으로 리소스를 할당할 수 없기 때문에 이러한 유형의 기술은 실제 리소스 할당보다는 우선 순위 지정에 의존합니다. 이것은 대역폭 예약이 OSI 모델의 상위 수준에서 발생함을 의미합니다. 대역폭이 예약되면 우선 순위가 더 높은 패킷이 먼저 전송됩니다.

이더넷, Wi-Fi 또는 기타 유사한 기술을 통해 QoS를 적용하려는 경우 고려해야 할 한 가지는 이러한 기술이 연결이 없다는 것입니다. 즉, 발신자는 수신자의 상태나 발신자와 수신자 간의 네트워크 상태를 확인할 수 있는 방법이 없습니다. 이것은 차례로 발신자가 더 높은 우선 순위의 패킷이 먼저 전송되도록 보장할 수 있지만 해당 패킷이 특정 시간 내에 배달된다는 보장은 할 수 없음을 의미합니다. 반면에 QoS는 ATM이 연결 지향 기술이기 때문에 ATM 네트워크에서 이러한 종류의 보증을 제공할 수 있습니다.

윈도우 2000 vs. 윈도우 서버 2003

Microsoft가 Windows 2000에서 처음으로 QoS를 도입했으며 그 이후로 이 QoS 응용 프로그램이 크게 발전했다고 앞서 언급한 바 있습니다. 따라서 Windows 2000과 Windows XP 및 Windows Server 2003(이 표준을 거의 같은 방식으로 사용)의 QoS 간의 차이점에 대해 조금 이야기하고자 합니다.

Windows 2000에서 QoS는 Windows XP 또는 Windows Server 2003에서 지원되지 않는 Intserv 아키텍처를 기반으로 했습니다. Microsoft가 이 아키텍처를 사용하지 않기로 선택한 이유는 기본 API를 사용하기 어렵고 아키텍처에 문제가 있었기 때문입니다. .

일부 조직에서는 여전히 Windows 2000을 사용하고 있으므로 Windows 2000 QoS 아키텍처가 작동하는 방식에 대한 약간의 배경 지식을 제공하고자 합니다. Windows 2000은 RSVP라는 프로토콜을 사용하여 대역폭 리소스를 예약합니다. 대역폭이 요청되면 Windows는 패킷을 전송할 수 있는 시기를 결정해야 합니다. 이를 위해 Windows 2000은 SBM(Sunbelt Bandwidth Manager)이라는 신호 프로토콜을 사용하여 보낸 사람에게 패킷을 수락할 준비가 되었음을 알립니다. ACS(Admission Control Service)는 유효한 대역폭을 사용할 수 있는지 확인한 다음 대역폭 요청을 승인하거나 거부합니다.

트래픽 관리 API

여기서 Traffic Control API(Traffic Control Programming Interface)가 작동합니다. 트래픽 제어 API는 QoS 설정을 개별 패킷에 적용할 수 있는 애플리케이션 프로그래밍 인터페이스입니다. Traffic Control API는 개별 트래픽 흐름을 정의하고 이러한 흐름에 다양한 QoS 제어 방법을 적용하여 작동합니다.

일반 패킷 분류기

QoS 패킷 스케줄러

QoS 패킷 스케줄러 구성

그림 A: QoS를 사용하려면 먼저 QoS 패킷 스케줄러를 활성화해야 합니다.

그림 B: 802.1Q/1P VLAN 태깅을 활성화해야 합니다.

802.1P는 802.1Q를 보완하기 위해 만들어졌습니다. 802.1P는 VLAN 태그로 래핑될 수 있는 우선 순위 표시를 정의합니다.

802.1P 신호

이전 파트에서 말했듯이 802.1p 시그널링은 OSI 모델의 두 번째 레이어에서 수행됩니다. 이 계층은 스위치와 같은 물리적 장치에서 사용됩니다. 802.1p를 지원하는 레이어 2 장치는 패킷에 할당된 우선 순위 표시를 확인한 다음 해당 패킷을 별도의 트래픽 클래스로 그룹화할 수 있습니다.

이더넷 네트워크에서 우선 순위 태깅은 VLAN 태그에 포함됩니다. VLAN 및 VLAN 태그는 3비트 우선순위 필드를 정의하는 802.1Q 표준에 의해 정의되지만 실제로 이 우선순위 필드가 어떻게 사용되어야 하는지는 정의하지 않습니다. 여기에서 802.1P 표준이 적용됩니다.

802.1P는 802.1Q 표준과 함께 사용할 수 있는 다양한 우선 순위 클래스를 정의합니다. 궁극적으로 802.1Q는 우선 순위를 표시하는 선택을 관리자에게 맡기므로 기술적으로 802.1P의 지침을 따를 필요는 없지만 802.1P는 모두가 선택하는 것 같습니다.

802.1P 표준을 사용하여 레이어 2 표시를 제공한다는 아이디어는 순수한 이론처럼 들리지만 실제로는 그룹 정책 설정을 통해 결정할 수 있습니다. 802.1P 표준은 8가지 우선 순위 등급(0~7 범위)을 제공합니다. 더 높은 클래스 우선 순위를 가진 패킷은 더 높은 전달 우선 순위를 가진 QoS에 의해 처리됩니다.

기본적으로 Microsoft는 다음과 같은 우선 순위 표시를 할당합니다.

그러나 앞서 언급했듯이 다양한 그룹 정책 설정을 수정하여 이러한 우선 순위를 변경할 수 있습니다. 이렇게 하려면 그룹 정책 편집기를 열고 Computer Configuration\Administrative Templates\Networks\QoS Packet Scheduler\Second 수준 우선 순위 값 분기를 따라 콘솔 트리로 이동합니다. 그림 A에서 볼 수 있듯이 위에 나열된 각 우선 순위 표시에 해당하는 그룹 정책 설정이 있습니다. 이러한 서비스 유형에 고유한 우선 순위 표시 수준을 할당할 수 있습니다. 그러나 이러한 그룹 정책 설정은 Windows XP, 2003 또는 Vista를 실행하는 호스트에만 적용됩니다.

그림 A: 그룹 정책 편집기를 사용하여 두 번째 수준 우선 순위 표시를 사용자 지정할 수 있습니다.

별도 서비스

이전 기사에서 설명했듯이 QoS는 OSI 모델의 두 번째 및 세 번째 계층에서 우선 순위 표시를 수행합니다. 이렇게 하면 패킷 전달 프로세스 전반에 걸쳐 우선 순위가 고려됩니다. 예를 들어 스위치는 OSI 모델의 레이어 2에서 작동하지만 라우터는 일반적으로 레이어 3에서 작동합니다. 따라서 패킷이 802.1p 우선 순위 표시만 사용하는 경우 스위치는 이러한 패킷에 우선 순위를 할당하지만 네트워크 라우터에서는 이러한 우선 순위를 무시합니다. 이를 방지하기 위해 QoS는 차별화된 서비스 프로토콜(Diffserv)을 사용하여 OSI 모델의 세 번째 계층에서 트래픽의 우선 순위를 지정합니다. Diffserv 표시는 TCP/IP를 사용하는 IP 패킷 헤더에 포함됩니다.

Diffserv에서 사용하는 아키텍처는 원래 RFC 2475에 의해 정의되었습니다. 그러나 많은 아키텍처 사양이 RFC 2474에서 다시 작성되었습니다. RFC 2474는 IPv4 및 IPv6 모두에 대해 Diffserv 아키텍처를 정의합니다.

RFC 2474의 IPv4 구현에 대한 흥미로운 점은 Diffserv가 완전히 재정의되었지만 여전히 원래 RFC 2475 사양과 역호환된다는 것입니다. 이것은 새로운 사양을 지원하지 않는 구형 라우터가 할당된 우선 순위를 인식할 수 있음을 의미합니다.

현재 Diffserv 애플리케이션은 TOS(Type of Service) 옥텟을 사용하여 Diffserv 값(DSCP 값이라고 함)을 저장합니다. 이 옥텟 내에서 처음 6비트는 DSCP 값을 저장하고 마지막 2비트는 사용되지 않습니다. 이러한 표시가 RFC 2475 사양과 역호환되는 이유는 RFC 2475가 IP 시퀀스 정보에 사용되는 동일한 옥텟의 처음 세 비트를 요구했기 때문입니다. DSCP 값의 길이는 6비트이지만 처음 3비트는 여전히 IP 시퀀스를 반영합니다.

앞에서 설명한 802.1p 표시와 마찬가지로 다양한 그룹 정책 설정을 통해 Diffserv 우선 순위를 구성할 수 있습니다. 방법을 보여주기 전에 Windows에서 사용되는 표준 Diffserv 우선 순위를 소개하겠습니다.

Diffserv 우선 순위 표시가 802.1P와 완전히 다른 범위를 사용한다는 것을 눈치채셨을 것입니다. 0 - 7 범위를 지원하는 대신 Diffserv는 0에서 63까지의 우선 순위 표시 범위를 지원하며 숫자가 클수록 우선 순위가 높습니다.

앞서 말했듯이 Windows에서는 그룹 정책 설정을 통해 Diffserv 우선 순위 표시를 정의할 수 있습니다. 그러나 일부 고급 라우터는 Windows에서 할당한 항목에 관계없이 패킷에 자체 Diffserv 값을 할당합니다.

이를 염두에 두고 그룹 정책 편집기를 열고 컴퓨터 구성\관리 템플릿\네트워크\QoS 패킷 스케줄러 아래의 콘솔 트리로 이동하여 Diffserv 우선 순위 표시를 구성할 수 있습니다.

그림 B를 보면 QoS 패킷 스케줄러 탭 아래에 두 개의 DSCP 관련 탭이 있음을 알 수 있습니다. 이 탭 중 하나를 사용하면 흐름 사양과 일치하는 패킷에 DSCP 우선 순위 표시를 할당할 수 있고, 두 번째 탭에서는 DSCP 우선 순위 표시를 비준수 패킷에 설정할 수 있습니다. 실제 옵션 자체는 그림 C와 같이 두 탭에서 비슷합니다.

그림 B: Windows는 흐름 사양과 일치하는 패킷과 일치하지 않는 패킷에 대해 별도로 DSCP 우선 순위 표시를 관리합니다.

그림 C: DSCP 우선 순위 표시를 다양한 서비스 유형에 수동으로 할당할 수 있습니다.

기타 그룹 정책 설정

그림 B를 보면 내가 말하지 않은 세 가지 그룹 정책 설정이 있음을 알 수 있습니다. 이러한 옵션이 무엇이며 관심이 있는 사람들을 위해 무엇을 하는지 간략하게 언급하고 싶었습니다.

Limit Outstanding Packets 매개변수는 본질적으로 서비스 임계값입니다. 나가는 패킷 수가 특정 값에 도달하면 QoS는 값이 최대 허용 임계값 아래로 떨어질 때까지 네트워크 어댑터에 대한 추가 대역폭 할당을 거부합니다.

예약 가능한 대역폭 제한 설정은 QoS 지원 응용 프로그램이 예약할 수 있는 총 대역폭의 백분율을 제어합니다. 기본적으로 QoS 지원 응용 프로그램은 네트워크 대역폭의 최대 80%를 예약할 수 있습니다. 물론 QoS 애플리케이션에서 예약되어 있고 현재 사용하지 않는 대역폭의 일부는 다른 애플리케이션에서 사용할 수 있습니다.

Set Timer Resolution 매개변수는 QoS 패킷 스케줄러가 패킷을 예약하는 데 사용할 최소 시간 단위(마이크로초)를 제어합니다. 기본적으로 이 설정은 패킷이 배달을 위해 대기할 수 있는 최대 빈도를 제어합니다.

QoS 및 모뎀

거의 보편화된 광대역 기술의 시대에 모뎀에 대해 이야기하는 것조차 이상하게 보입니다. 그러나 모뎀을 인터넷 연결 메커니즘으로 사용하는 소규모 기업과 가정 사용자가 여전히 많이 있습니다. 최근에는 광대역 기술에 액세스할 수 없는 원격 위치에 있는 위성 사무실과 통신하기 위해 모뎀을 사용하는 대기업도 보았습니다.

물론 모뎀 사용의 가장 큰 문제는 모뎀이 제공하는 제한된 대역폭입니다. 덜 분명하지만 덜 중요한 문제는 사용자가 일반적으로 전화 접속 연결을 사용할 때 온라인 동작을 변경하지 않는다는 것입니다. 물론 사용자는 모뎀을 통해 인터넷에 연결할 때 대용량 파일을 다운로드하는 것에 대해 크게 느끼지 않을 수 있지만 나머지 사용자 동작은 광대역 연결을 통해 연결된 것처럼 동일하게 유지됩니다.

일반적으로 사용자는 Microsoft Outlook을 항상 열어 두거나 파일이 백그라운드에서 다운로드되는 동안 탐색하는 것에 대해 너무 걱정하지 않습니다. 일부 사용자는 인스턴트 메시징 시스템을 지속적으로 열어 둡니다. 이러한 유형의 동작의 문제는 이러한 각 응용 프로그램 또는 작업이 특정 양의 인터넷 연결 대역폭을 소비한다는 것입니다.

QoS가 어떻게 도움이 되는지 알아보기 위해 QoS가 사용되지 않는 일반적인 상황에서 어떤 일이 발생하는지 살펴보겠습니다. 일반적으로 인터넷에 액세스를 시도하는 첫 번째 응용 프로그램이 연결 사용 권한이 가장 많습니다. 이것은 다른 응용 프로그램이 연결을 사용할 수 없다는 것을 의미하는 것이 아니라 Windows가 다른 응용 프로그램이 연결을 사용하지 않을 것이라고 가정한다는 의미입니다.

연결이 생성되면 Windows는 TCP 수신 창 크기를 동적으로 조정하기 시작합니다. TCP 수신 창 크기는 데이터가 수신되었다는 확인을 기다리기 전에 보낼 수 있는 데이터의 양입니다. TCP 수신 창 크기가 클수록 발신자가 성공적인 전달 확인을 기다리기 전에 더 많은 패킷을 전송할 수 있습니다.

TCP 수신 창 크기는 신중하게 구성해야 합니다. TCP 수신 창이 너무 작으면 TCP가 매우 자주 확인을 요구하기 때문에 효율성도 저하됩니다. 그러나 TCP 수신 창이 너무 크면 시스템이 전송 중에 문제가 있다는 것을 알기 전에 너무 많은 데이터를 보낼 수 있습니다. 그 결과 많은 양의 데이터를 재전송해야 하며 이는 효율성에도 영향을 미칩니다.

응용 프로그램이 전화 접속 인터넷 연결을 사용하여 시작하면 Windows는 패킷이 전송될 때 TCP 수신 창의 크기를 동적으로 조정합니다. 여기서 Windows의 목표는 TCP 수신 창 크기가 최적으로 조정되는 안정적인 상태에 도달하는 것입니다.

이제 사용자가 인터넷 연결이 필요한 두 번째 응용 프로그램을 엽니다. 그렇게 하면 Windows는 TCP 수신 창 크기를 최적의 값으로 조정하는 알고리즘인 TCP 느린 시작 알고리즘을 시작합니다. 문제는 TCP가 이전에 시작된 응용 프로그램에서 이미 사용 중이라는 것입니다. 이는 두 가지 방식으로 두 번째 응용 프로그램에 영향을 줍니다. 첫째, 두 번째 응용 프로그램은 최적의 TCP 수신 창 크기에 도달하는 데 훨씬 더 오래 걸립니다. 둘째, 두 번째 응용 프로그램의 데이터 속도는 항상 앞서 실행 중인 응용 프로그램의 데이터 속도보다 느립니다.

좋은 소식은 QOS 패킷 스케줄러를 실행하기만 하면 Windows XP와 Windows Server 2003에서 이러한 문제를 피할 수 있다는 것입니다. 그 후 QOS 패킷 스케줄러는 Windows가 느린 연결 속도를 감지할 때마다 Deficit Round Robin이라는 기술을 자동으로 사용합니다.

적자 라운드 로빈은 인터넷 액세스가 필요한 각 애플리케이션에 대해 별도의 대기열을 동적으로 생성하여 작동합니다. Windows는 라운드 로빈 방식으로 이러한 대기열을 서비스하므로 인터넷에 액세스해야 하는 모든 응용 프로그램의 효율성이 크게 향상됩니다. 궁금한 점이 있으시면 Windows 2000 Server에서도 적자 라운드 로빈을 사용할 수 있지만 자동으로 활성화되지는 않습니다.

인터넷 연결 공유

Windows XP 및 Windows Server 2003에서 QoS는 인터넷 연결 공유도 용이하게 합니다. 아시다시피 인터넷 연결 공유는 NAT 기반 라우터를 만드는 단순화된 버전입니다. 인터넷이 연결된 컴퓨터는 네트워크 상의 다른 컴퓨터에 대해 라우터 및 DHCP 서버 역할을 하여 이 호스트를 통해 인터넷에 액세스할 수 있도록 합니다. 인터넷 연결 공유는 일반적으로 도메인 인프라가 부족한 소규모 P2P 네트워크에서만 사용됩니다. 대규모 네트워크는 일반적으로 물리적 장치 라우터 또는 라우팅 및 전화 접속 서비스를 사용합니다.

위의 섹션에서 Windows가 TCP 수신 창 크기를 동적으로 조정하는 방법을 이미 설명했습니다. 그러나 이 동적 설정은 인터넷 연결을 공유할 때 문제를 일으킬 수 있습니다. 그 이유는 로컬 네트워크에 있는 컴퓨터 간의 연결이 일반적으로 상대적으로 빠르기 때문입니다. 일반적으로 이 연결은 100Mb 이더넷 또는 802.11G 무선 연결로 구성됩니다. 이러한 유형의 연결은 가장 빠른 것과는 거리가 멀지만 미국에서 사용 가능한 대부분의 인터넷 연결보다 훨씬 빠릅니다. 여기에 문제가 있습니다.

클라이언트 컴퓨터는 인터넷을 통해 통신해야 하지만 직접 통신할 수는 없습니다. 대신 인터넷 연결 공유 호스트를 액세스 모듈로 사용합니다. Windows가 최적의 TCP 수신 창 크기를 계산할 때 로컬 시스템과 인터넷 연결 공유 시스템 간의 연결 속도를 기반으로 계산합니다. 로컬 시스템이 인터넷에서 실제로 얻을 수 있는 데이터의 양과 인터넷 연결 공유 호스트에 대한 연결 속도를 기반으로 얻을 수 있다고 생각하는 양의 차이가 문제가 될 수 있습니다. 보다 구체적으로, 연결 속도의 차이로 인해 느린 연결에 연결된 대기열에 데이터가 백업되는 상황이 발생할 수 있습니다.

여기서 QoS가 작동합니다. 인터넷 연결 공유 호스트에 QOS 패킷 스케줄러를 설치하면 인터넷 연결 공유 호스트가 TCP 수신 창 크기를 무효화합니다. 이것은 인터넷 연결 공유 호스트가 로컬 호스트의 TCP 수신 창 크기를 인터넷에 직접 연결된 경우와 동일한 값으로 설정함을 의미합니다. 이것은 네트워크 연결 속도 불일치로 인한 문제를 수정합니다.

결론

이 일련의 기사에서 저는 QoS와 다양한 유형의 네트워크 연결에서 트래픽 흐름을 형성하는 데 QoS를 사용하는 방법에 대해 이야기했습니다. 보시다시피 QoS는 네트워크의 가장 바쁜 순간을 활용하고 우선 순위가 더 높은 트래픽이 빠르게 전달되도록 하는 방식으로 트래픽을 형성하여 네트워크가 훨씬 더 효율적으로 작동하도록 할 수 있습니다.

브라이언 포시

QoS의 신화

Windows XP에 대한 FAQ를 한 번 이상 읽지 않은 사람은 한 명도 없습니다. 그렇다면 모든 사람은 그렇게 해로운 서비스 품질(QoS)이 있다는 것을 알고 있습니다. 기본적으로 네트워크 대역폭을 20%로 제한하고 Windows 2000에서도 이 문제가 있는 것 같기 때문에 시스템 구성 시 끄기를 적극 권장합니다.

다음은 라인입니다.
"Q: QoS(Quality of Service) 서비스를 어떻게 완전히 비활성화합니까? 어떻게 구성합니까? 네트워크 속도를 제한하는 것이 사실입니까?
A: 기본적으로 Quality of Service는 필요에 따라 채널 대역폭의 20%를 예약합니다(모든 - 최소 14400 모뎀, 최소 기가비트 이더넷). 또한 속성 연결에서 QoS 패킷 스케줄러 서비스를 제거하더라도 이 채널은 해제되지 않습니다. 여기에서 채널을 해제하거나 단순히 QoS를 구성할 수 있습니다. 그룹 정책 애플릿(gpedit.msc)을 시작합니다. 그룹 정책에서 로컬 컴퓨터 정책을 찾아 관리 템플릿을 클릭합니다. 네트워크 - QoS Packet Sheduler 항목을 선택하십시오. 예약 가능한 대역폭 제한을 활성화합니다. 이제 대역폭 제한을 20%에서 0%로 줄이거 나 그냥 끕니다. 원하는 경우 여기에서 다른 QoS 매개변수를 구성할 수도 있습니다. 변경 사항을 재부팅하는 일만 남았습니다."
물론 20%는 많다. 진정한 마이크로소프트는 마쓰다다. 이러한 종류의 진술은 FAQ에서 FAQ로, 포럼에서 포럼으로, 미디어에서 미디어에 이르기까지 모든 종류의 "조정"에 사용됩니다. Windows XP를 "구성"하기 위한 프로그램(그런데 "그룹 정책" 및 "로컬 보안 정책", 단일 "twikka"는 사용자 지정 옵션의 풍부함 측면에서 비교할 수 없습니다. 이러한 종류의 입증되지 않은 주장은 신중해야 합니다. 우리는 지금부터 체계적인 접근 방식을 적용할 것입니다. 즉, 공식 1차 출처에 의존하여 문제가 되는 문제를 철저히 연구할 것입니다.

양질의 서비스 네트워크란 무엇입니까?
네트워크 시스템에 대한 다음과 같은 단순화된 정의를 살펴보겠습니다. 응용 프로그램은 호스트에서 실행되고 실행되며 서로 통신합니다. 응용 프로그램은 네트워크를 통해 전송하기 위해 운영 체제에 데이터를 보냅니다. 데이터가 운영 체제로 전송되면 네트워크 트래픽이 됩니다.
네트워크 QoS는 일부 애플리케이션의 요청을 이행하도록 보장되는 방식으로 이 트래픽을 처리하는 네트워크의 기능에 의존합니다. 이를 위해서는 네트워크 트래픽을 처리하기 위한 기본 메커니즘이 필요하며 특수 처리 권한과 이러한 메커니즘을 제어할 수 있는 권한이 있는 트래픽을 식별할 수 있습니다.
QoS 기능은 네트워크 애플리케이션과 네트워크 관리자라는 두 가지 네트워크 행위자를 만족시키도록 설계되었습니다. 그들은 종종 동의하지 않습니다. 네트워크 관리자는 특정 응용 프로그램에서 사용하는 리소스를 제한하는 동시에 응용 프로그램이 가능한 한 많은 네트워크 리소스를 가져오려고 합니다. 네트워크 관리자가 모든 응용 프로그램 및 사용자와 관련하여 지배적인 역할을 한다는 사실을 고려하여 이해 관계를 조정할 수 있습니다.

기본 QoS 매개변수
애플리케이션마다 네트워크 트래픽을 처리하기 위한 요구 사항이 다릅니다. 애플리케이션은 지연 및 트래픽 손실에 대해 다소 관대합니다. 이러한 요구 사항은 다음 QoS 관련 매개변수에 적용됩니다.
대역폭(대역폭) - 애플리케이션에서 생성한 트래픽이 네트워크를 통해 전송되어야 하는 속도.
대기 시간 - 응용 프로그램이 데이터 패킷을 전달할 때 허용할 수 있는 지연입니다.
지터 - 지연 시간을 변경합니다.
손실 - 손실된 데이터의 백분율입니다.
무한한 네트워크 리소스를 사용할 수 있는 경우 모든 애플리케이션 트래픽은 대기 시간, 지연 변동 및 손실 없이 필요한 속도로 전송될 수 있습니다. 그러나 네트워크 리소스는 무제한이 아닙니다.
QoS 메커니즘은 전송 요구 사항을 충족하기 위해 애플리케이션 트래픽에 대한 네트워크 리소스 배포를 제어합니다.

기본 QoS 리소스 및 트래픽 처리 메커니즘
호스트를 연결하는 네트워크는 호스트 네트워크 어댑터, 라우터, 스위치 및 허브를 비롯한 다양한 네트워크 장치를 사용합니다. 각각에는 네트워크 인터페이스가 있습니다. 각 네트워크 인터페이스는 제한된 속도로 트래픽을 수신 및 전송할 수 있습니다. 트래픽이 인터페이스로 전달되는 속도가 인터페이스가 트래픽을 전달하는 속도보다 높으면 혼잡이 발생합니다.
네트워크 장치는 혼잡이 지나갈 때까지 장치의 메모리(버퍼)에 트래픽을 대기시켜 혼잡 상태를 처리할 수 있습니다. 다른 경우에는 네트워크 장비가 혼잡을 완화하기 위해 트래픽을 중단할 수 있습니다. 결과적으로 애플리케이션은 시간 초과 변경(트래픽이 인터페이스의 대기열에 유지되기 때문에) 또는 트래픽 손실을 경험합니다.
트래픽을 전달할 수 있는 네트워크 인터페이스의 기능과 네트워크 장치에 트래픽을 저장할 수 있는 메모리(트래픽이 전달될 수 있을 때까지)는 애플리케이션 트래픽 흐름에 QoS를 제공하는 데 필요한 기본 리소스입니다.

네트워크 장치 전반에 걸친 QoS 리소스 할당
QoS를 지원하는 장치는 지능적으로 네트워크 리소스를 사용하여 트래픽을 전송합니다. 즉, 지연에 더 관대한 응용 프로그램의 트래픽은 대기열에 저장되고(메모리의 버퍼에 저장), 지연에 중요한 응용 프로그램의 트래픽은 더 많이 전송됩니다.
이 작업을 수행하기 위해 네트워크 장치는 패킷을 분류하여 트래픽을 식별하고 이를 서비스하기 위한 대기열과 메커니즘을 가지고 있어야 합니다.

트래픽 처리 메커니즘
트래픽 처리 메커니즘에는 다음이 포함됩니다.
802.1p
홉 동작당 차별화된 서비스(diffserv PHB).
통합 서비스(intserv).
ATM 등
대부분의 LAN은 이더넷, 토큰링 등을 포함한 IEEE 802 기술을 기반으로 합니다. 802.1p는 이러한 네트워크에서 QoS를 지원하기 위한 트래픽 처리 메커니즘입니다.

802.1p는 8개의 우선 순위 값 중 하나를 전달할 수 있는 802 패킷 헤더의 필드(OSI 네트워킹 모델의 레이어 2)를 정의합니다. 일반적으로 호스트 또는 라우터는 트래픽을 로컬 네트워크로 보낼 때 전송된 각 패킷을 표시하고 특정 우선 순위 값을 할당합니다. 스위치, 브리지 및 허브와 같은 네트워크 장치는 대기열 메커니즘을 사용하여 패킷을 적절하게 처리해야 합니다. 802.1p의 범위는 근거리 통신망(LAN)으로 제한됩니다. 패킷이 OSI 계층 3을 통해 LAN을 통과하는 즉시 802.1p 우선 순위가 제거됩니다.
Diffserv는 계층 3 메커니즘으로, DSCP(diffserv codepoint)라고 하는 IP 패킷의 계층 3 헤더에 필드를 정의합니다.
Intserv는 보장된 서비스와 부하를 제어하는 서비스를 정의하는 서비스 집합입니다. 보장된 서비스는 측정 가능하고 제한된 대기 시간으로 일정량의 트래픽을 전달할 것을 약속합니다. 부하를 관리하는 서비스는 "가벼운 네트워크 트래픽의 모습"으로 일정량의 트래픽을 운반하는 데 동의합니다. 이들은 특정 트래픽 양에 측정 가능한 QoS를 제공하도록 정의되었다는 의미에서 측정 가능한 서비스입니다.

ATM은 패킷을 비교적 작은 셀로 조각화하기 때문에 매우 짧은 대기 시간을 제공할 수 있습니다. 패킷을 긴급하게 보내야 하는 경우 ATM 인터페이스는 하나의 셀을 보내는 데 걸리는 시간 동안 항상 자유롭게 보낼 수 있습니다.
QoS에는 이 기술을 작동시키는 다른 많은 복잡한 메커니즘이 있습니다. QoS가 작동하려면 시작 지점에서 끝까지 전송 전반에 걸쳐 이 기술과 적절한 구성을 지원해야 합니다.

명확성을 위해 Fig. 하나.
다음을 수락합니다.
모든 라우터는 필요한 프로토콜의 전송에 참여합니다.
64Kbps가 필요한 하나의 QoS 세션은 호스트 A와 호스트 B 사이에서 시작됩니다.
64Kbps가 필요한 다른 세션이 호스트 A와 호스트 D 사이에서 시작됩니다.
체계를 단순화하기 위해 라우터가 모든 네트워크 리소스를 예약할 수 있는 방식으로 구성되어 있다고 가정합니다.
우리의 경우 하나의 64Kbps 예약 요청은 호스트 A와 호스트 B 사이의 데이터 경로에 있는 3개의 라우터에 도달합니다. 또 다른 64Kbps 예약 요청은 호스트 A와 호스트 D 사이의 3개 라우터에 도달합니다. 라우터는 이러한 리소스 예약 요청을 존중합니다. 최대값을 초과하지 마십시오. 대신 호스트 B와 C 각각이 호스트 A와 동시에 64Kbps QoS 세션을 시작했다면 이 호스트(B와 C)에 서비스를 제공하는 라우터는 연결 중 하나를 거부합니다.

이제 네트워크 관리자가 호스트 B, C, D, E에 서비스를 제공하는 하위 3개의 라우터에서 QoS 처리를 비활성화한다고 가정합니다. 이 경우 연결에 참여하는 호스트의 위치에 관계없이 최대 128Kbps의 리소스 요청이 충족됩니다. 그러나 한 호스트에 대한 트래픽이 다른 호스트에 대한 트래픽을 손상시키므로 품질 보증이 낮습니다. 업스트림 라우터가 모든 요청을 64Kbps로 제한하면 QoS를 유지할 수 있지만 이는 네트워크 리소스를 비효율적으로 사용하게 됩니다.
반면에 모든 네트워크 링크의 대역폭은 128Kbps로 증가할 수 있습니다. 그러나 증가된 대역폭은 호스트 B와 C(또는 D와 E)가 동시에 리소스를 요청할 때만 사용됩니다. 그렇지 않으면 네트워크 리소스가 다시 비효율적으로 사용됩니다.

Microsoft QoS 구성 요소
Windows 98에는 다음과 같은 사용자 수준 QoS 구성 요소만 포함되어 있습니다.
응용 프로그램 구성 요소.
GQoS API(Winsock 2의 일부).
QoS 서비스 제공자.
Windows 2000/XP/2003 운영 체제에는 위에서 설명한 모든 것과 다음 구성 요소가 포함되어 있습니다.
리소스 예약 프로토콜 서비스 공급자(Rsvpsp.dll) 및 RSVP 서비스(Rsvp.exe) 및 QoS ACS. Windows XP, 2003에서는 사용되지 않습니다.
트래픽 관리(Traffic.dll).
일반 패킷 분류자(Msgpc.sys) 패킷 분류자는 패킷이 속한 서비스 클래스를 정의합니다. 그러면 패킷이 적절한 대기열에 배치됩니다. 대기열은 QoS 패킷 스케줄러에 의해 관리됩니다.
QoS 패킷 스케줄러(Psched.sys). 특정 데이터 스트림에 대한 QoS 매개변수를 지정합니다. 트래픽은 특정 우선 순위 값으로 표시됩니다. QoS 패킷 스케줄러는 각 패킷에 대한 대기열 일정을 결정하고 네트워크에 동시 액세스가 필요한 대기열에 있는 패킷 간의 경합 요청을 처리합니다.

그림 2의 다이어그램은 프로토콜 스택, Windows 구성 요소 및 호스트에서 상호 작용하는 방식을 보여줍니다. Windows 2000에서는 사용되지만 Windows XP/2003에서는 사용되지 않는 항목은 다이어그램에 표시되지 않습니다.
애플리케이션은 스택의 맨 위에 있습니다. QoS를 인지하거나 인지하지 못할 수 있습니다. QoS의 모든 기능을 활용하려면 응용 프로그램에서 일반 QoS API 호출을 사용하는 것이 좋습니다. 이는 고품질 서비스 보장이 필요한 애플리케이션에 특히 중요합니다. 일부 유틸리티는 QoS를 인식하지 못하는 애플리케이션을 대신하여 QoS를 호출하는 데 사용할 수 있습니다. 트래픽 관리 API를 통해 작동합니다. 예를 들어 NetMeeting은 GQoS API를 사용합니다. 그러나 이러한 응용 프로그램의 경우 품질이 보장되지 않습니다.

마지막 손톱
위의 이론적 요점은 악명 높은 20%가 어디로 가는지(아직 정확하게 측정한 사람이 아무도 없음)에 대한 질문에 대한 명확한 답을 제공하지 않습니다. 위의 내용에 따르면 이것은 사실이 아니어야 합니다. 그러나 반대자들은 새로운 주장을 내놓았습니다. QoS 시스템은 훌륭하지만 구현이 비뚤어졌습니다. 따라서 20%는 여전히 "뚱뚱"합니다. 이미 꽤 오랫동안 그러한 조작을 논박했기 때문에 소프트웨어 거인도 문제에 구워진 것처럼 보입니다.
그러나 개발자에게 바닥을 제공하고 문학 러시아어로 "316666 - Windows XP 서비스 품질(QoS) 향상 및 동작" 기사에서 선택한 요점을 제시하겠습니다.
"프로그램이 우선 순위 대역폭을 명시적으로 요청하지 않는 한 네트워크 대역폭의 100%를 모든 프로그램에 배포할 수 있습니다. 이 "예약된" 대역폭은 요청한 프로그램이 데이터를 전송하지 않는 경우 다른 프로그램에서 사용할 수 있습니다.

기본적으로 프로그램은 각 컴퓨터 인터페이스에서 기본 연결 속도의 최대 20%를 예약할 수 있습니다. 대역폭을 예약한 프로그램이 이를 완전히 사용하기에 충분한 데이터를 보내지 않으면 예약된 대역폭의 사용되지 않은 부분을 다른 데이터 스트림에서 사용할 수 있습니다.
다양한 기술 기사와 뉴스 그룹에서 Windows XP가 QoS에 사용 가능한 대역폭의 20%를 항상 예약한다는 주장이 있었습니다. 이러한 진술은 잘못된 것입니다."
지금 누군가가 여전히 대역폭의 20%를 "거짓"하고 있다면 더 다양한 조정과 비뚤어진 네트워크 드라이버를 계속 사용하라고 조언할 수 있습니다. 그리고 "뚱뚱"하지 않을 것입니다.
모두, QoS 신화, 죽어라!

유리 트로피모프,