TCP/IP 성능의 알려진 문제

참고 항목

이 문서는 3부로 구성된 시리즈에 포함되어 있습니다. 1부: TCP/IP 성능 개요 및 2부: TCP/IP 성능 기본 네트워크 문제를 검토할 수 있습니다.

이 문서에서는 다음과 같은 TCP/IP 성능 문제를 설명합니다.

• 대기 시간이 높고 대역폭이 높은 네트워크의 느린 처리량
• 대기 시간이 낮고 대역폭이 높은 네트워크의 느린 처리량
• 기본 네트워크 문제

대기 시간 및 대역폭 네트워크의 느린 처리량 속도

서로 다른 사이트에 있는 두 서버는 대기 시간이 긴 네트워크를 통해 연결됩니다. ctsTraffic 도구로 측정된 처리량이 기준선보다 낮습니다.

이는 TCP 창 크기 조정 옵션이 어느 서버에서나 사용하도록 설정되지 않았기 때문입니다. Windows 명령 프롬프트 또는 Windows PowerShell을 사용하여 TCP 수신 창 자동 조정 수준을 설정하여 옵션을 사용하도록 설정합니다.

명령 프롬프트를 사용하여 자동 조정 수준 사용

다음 명령을 실행합니다.

netsh int tcp set global autotuninglevel=normal 

자동 조정 수준을 사용할 수 있는지 확인하려면 다음 명령을 사용합니다.

netsh int tcp show global

PowerShell을 사용하여 자동 조정 수준 사용

다음 cmdlet을 실행합니다.

Get-NetTCPSetting | Set-NetTCPSetting -AutoTuningLevelLocal Normal

자동 조정 수준을 사용할 수 있는지 확인하려면 다음 cmdlet을 사용합니다.

Get-NetTCPSetting | Format-List SettingName,Autotuninglevel*

참고 항목

수신 창 자동 조정에는 사용 안 함, 매우 제한됨, 제한됨, 표준 및 실험적 5가지 수준이 있습니다. 자동 조정이 처리량에 미치는 영향에 대한 자세한 내용은 성능 튜닝 네트워크 어댑터를 참조 하세요.

짧은 대기 시간 및 높은 대역폭 네트워크의 느린 처리량 속도

대기 시간이 짧고 대역폭이 높은 동일한 네트워크에 두 서버가 연결됩니다. ctsTraffic 도구를 사용하여 기준선을 만들거나 TCP 성능을 테스트하는 경우 다중 코어 CPU 서버에서만 CPU 0이 급증합니다.

이 문제는 RSS(수신 쪽 크기 조정) 또는 VMQ(가상 머신 큐) 기능이 사용하도록 설정되지 않았거나 올바르게 구성되지 않았기 때문에 발생합니다. 물리적 컴퓨터가 하이퍼바이저인 경우 VMQ를 사용합니다. 그렇지 않은 경우 운영 체제(OS) 및 네트워크 카드 모두에서 RSS를 사용하도록 설정합니다.

참고 항목

무선 네트워크 카드는 RSS 또는 VMQ 기능을 지원하지 않습니다.

OS에 RSS 사용

다음과 같이 명령 프롬프트 또는 PowerShell을 사용하여 RSS를 사용하도록 설정합니다.

명령 프롬프트: netsh int tcp set global rss=enabled

PowerShell: Set-NetAdapterRss -Name <interface name> -Enabled $True

네트워크 카드에 RSS 사용

먼저 RSS 기능이 사용하도록 설정되어 있는지 확인합니다. 다음 cmdlet을 사용하여 관련 구성에 대한 네트워크 카드 고급 속성을 확인합니다.

Get-NetAdapterAdvancedProperty | Where-Object -property RegistryKeyword -Like *rss* | format-table -AutoSize

참고 항목

고급 속성을 변경하면 네트워크 연결이 중단되거나 손실될 수 있습니다. 변경하기 전에 NIC 공급업체 설명서를 참조하세요.

다음 단계에 따라 네트워크 카드에 RSS를 사용하도록 설정합니다.

1. 실행 ncpa.cpl 하여 네트워크 연결을 엽니다.
2. 대상 연결을 마우스 오른쪽 단추로 클릭한 다음 속성>구성을 선택합니다.
3. 고급 탭의 속성 목록에서 수신측 배율을 찾은 다음 값을 사용으로 설정합니다.
4. 확인을 선택합니다.

PowerShell cmdlet을 사용하여 RSS를 사용하도록 설정할 수도 있습니다.

Set-NetAdapterAdvancedProperty -Name <Interface name> -RegistryKeyword *RSS -RegistryValue 1

기본 네트워크 문제

이 섹션에서는 처리량 기준을 측정하거나 처리량 문제를 해결하는 동안 기본 네트워크 문제를 확인하는 방법을 설명합니다.

패킷 수준 로그 분석을 얻으려면 네트워크 패킷 캡처 도구(예: Microsoft 네트워크 모니터, Wireshark 또는 ctsTraffic)를 사용하여 기본 네트워크 문제를 확인합니다.

네트워크 패킷 캡처 도구를 사용하여 로그를 수행하는 단계

1. Microsoft 네트워크 모니터 또는 Wireshark로 로깅을 시작하여 두 엔드포인트에서 트래픽을 캡처합니다. 다음과 같이 Windows 기본 제공 캡처 도구를 사용할 수도 있습니다.

   1. 관리자 권한으로 명령 프롬프트를 엽니다.

   2. 다음 명령을 실행합니다.

      NETSH TRACE START CAPTURE=YES REPORT=DISABLED TRACEFILE=<FILEPATH>.ETL MAXSIZE=512
      

      참고 항목

      명령을 사용하는 동안 여러 캡처가 netsh trace 필요할 수 있습니다.

2. CTStraffic.exe 도구를 실행하여 .csv 파일을 생성합니다.

3. 로깅을 중지합니다. Windows 기본 제공 캡처 도구의 경우 명령 프롬프트를 관리자로 입력 NETSH TRACE STOP 합니다.

캡처 파일 분석

다음은 필터링된 결과를 분석하는 방법을 보여 주는 예제입니다. 이 시나리오에서 ctsTraffic 도구는 푸시 패턴(기본 패턴)을 사용합니다. 즉, 패킷이 클라이언트에서 서버로 전송됩니다.

1. Microsoft 네트워크 모니터에서 캡처 파일을 엽니다.

2. 재전송 패킷을 Property.TCPRetransmit==1 && tcp.Port==4444 찾는 필터를 사용하여 네트워크 추적을 필터링합니다. 패킷 재전송은 보낸 사람으로부터 지정된 TCP 시퀀스의 TCP 승인을 받지 못함을 의미합니다.

   참고 항목

   ETL 파일을 분석하려면 도구>옵션>파서 프로필>Windows>Set As Active>OK로 이동합니다.

   

   스크린샷에 표시된 것처럼 프레임 #441 은 두 번 다시 전송됩니다. 즉, 보낸 사람에서 세 번 전송됩니다. 동일한 TCP 시퀀스 번호(2278877548)를 사용하여 이 프레임을 식별합니다.

3. 프레임 세부 정보에서 SequenceNumber를 마우스 오른쪽 단추로 클릭하고 선택한 값 추가를 선택하여 필터를 표시합니다.

   

4. 다음과 같이 "//"를 추가하여 이전 필터를 사용하지 않도록 설정합니다.

   

5. 적용을 선택합니다. 이 시퀀스 번호가 있는 전체 TCP 시퀀스는 다음과 같이 표시됩니다.

   

   이 결과는 원래 프레임 #441 이 서버에서 수신되지 않고 보낸 사람에서 다시 전송됨을 보여 줍니다. 시퀀스에 대한 승인이 수신되지 않으면 프레임 재전송이 발생합니다. TCP 작동 방식을 이해하려면 TCP/IP 를 통한 3방향 핸드셰이크 및 Windows TCP 기능에 대한 설명을 참조하세요. 그런 다음, 클라이언트 추적에서 시퀀스 필터를 복사 TCP.SequenceNumber == <value> 하여 서버 추적에 붙여넣습니다.

   다음 결과와 같이 서버에서 지정된 시퀀스의 패킷 하나만 수신됩니다.

   

   이 결과는 중간 네트워크 디바이스에서 보낸 사람에서 받는 사람에게 패킷 손실이 있음을 증명합니다. 패킷은 발신자를 떠나지만 수신기에 도달하지 않습니다. 이는 기본 네트워킹의 문제이며 네트워크 관리자가 해결해야 합니다.

TCP 루프백 성능

Windows Server 2019 릴리스에서는 이전 Windows 릴리스에 있던 특정 성능 병목 상태를 해결하기 위해 TCP/IP 루프백 처리 모델이 변경되었습니다. 이 섹션에서는 TCP/IP 루프백 처리의 동작을 변경하는 데 사용할 수 있는 구성 옵션에 대해 설명합니다.

구성 매개 변수는 netsh 구성 도구를 통해 사용할 수 있습니다. 각 설정은 IPv4 및 IPv6에 대해 개별적으로 설정할 수 있습니다. 기본값은 Windows 버전마다 다를 수 있습니다.

참고 항목

범용 Windows 컴퓨터에서는 기본값을 변경하지 않아야 합니다.

애플리케이션 개발자가 루프백 데이터 경로가 애플리케이션 성능 부족의 근본 원인이라고 판단하는 경우 다음 명령을 사용하여 애플리케이션의 개별 요구 사항에 맞게 구성을 조정할 수 있습니다.

netsh int ipv6|ipv4 set gl loopbackexecutionmode=adaptive|inline|worker
netsh int ipv6|ipv4 set gl loopbackworkercount=<value>
netsh int ipv6|ipv4 set gl loopbacklargemtu=enable|disable

설명

Loopbackexecutionmode
Worker

이 모드에서는 패킷이 보낸 사람 쪽에서 큐에 대기되고 수신자 쪽의 작업자 스레드에 의해 처리됩니다. 이 모드는 대기 시간보다 처리량을 선호합니다.

Inline

이 모드에서 처리는 보낸 사람 및 수신자 쪽의 애플리케이션 스레드 컨텍스트에서 수행됩니다. 이 모드는 처리량보다 대기 시간을 선호합니다.

Adaptive

데이터 흐름의 첫 번째 패킷은 인라인으로 처리되고 패킷은 작업자 스레드로 지연됩니다. 이 모드는 대기 시간과 처리량의 균형을 맞추려고 합니다.

Loopbackworkercount

사용된 작업자 스레드 수를 구성할 수 있습니다.

Loopbacklargemtu

큰 MTU의 사용을 구성할 수 있습니다. 이 기능을 사용하도록 설정해야 합니다.