Office 365 성능 문제 해결 계획

SharePoint, OneDrive, Exchange Online 또는 비즈니스용 Skype Online과 클라이언트 컴퓨터 간의 지연, 중단 및 성능 저하를 식별하고 수정하기 위해 수행해야 하는 단계를 알아야 하나요? 지원을 호출하기 전에 이 문서는 Office 365 성능 문제를 해결하고 가장 일반적인 몇 가지 문제를 해결하는 데 도움이 될 수 있습니다.

이 문서는 실제로 발생하는 성능 문제에 대한 중요한 데이터를 캡처하는 데 사용할 수 있는 샘플 작업 계획입니다. 이 문서에는 몇 가지 주요 문제도 포함되어 있습니다.

네트워크 성능을 익숙하지 않고 클라이언트 컴퓨터와 Office 365 간의 성능을 모니터링하기 위한 장기 계획을 세우고 싶다면 관리 및 IT Pro와 Office 365 성능 조정 및 문제 해결을 살펴보세요.

샘플 성능 문제 해결 작업 계획

이 작업 계획에는 두 부분으로 구성됩니다. 준비 단계 및 로깅 단계 지금 성능 문제가 있고 데이터 수집을 수행해야 하는 경우 이 계획을 즉시 사용할 수 있습니다.

클라이언트 컴퓨터 준비

• 성능 문제를 재현할 수 있는 클라이언트 컴퓨터를 찾습니다. 이 컴퓨터는 문제 해결 중에 사용됩니다.
• 테스트할 때 준비가 되도록 성능 문제가 발생하는 단계를 적어 씁니다.
• 정보를 수집하고 기록하기 위한 도구를 설치합니다.
  • Netmon 3.4를 설치하거나 동등한 네트워크 추적 도구를 사용합니다.
  • 무료 기본 버전의 HTTPWatch를 설치하거나 동등한 네트워크 추적 도구를 사용합니다.
  • 테스트 중에 수행하는 단계를 기록하기 위해 화면 레코더를 사용하거나 Windows Vista 이상과 함께 제공되는 단계 레코더(PSR.exe)를 실행합니다.

성능 문제 기록

• 모든 불필요한 인터넷 브라우저를 닫습니다.

• 단계 레코더 또는 다른 화면 레코더를 시작합니다.

• Netmon 캡처(또는 네트워크 추적 도구)를 시작합니다.

• ipconfig /flushdns를 입력하여 명령줄에서 클라이언트 컴퓨터의 DNS 캐시를 지웁니다.

• 새 브라우저 세션을 시작하고 HTTPWatch를 켭니다.

• 선택 사항: Exchange Online 테스트하는 경우 Office 365 관리 콘솔에서 Exchange 클라이언트 성능 분석기 도구를 실행합니다.

• 성능 문제를 일으키는 정확한 단계를 재현합니다.

• Netmon 또는 다른 도구의 추적을 중지합니다.

• 명령줄에서 다음 명령을 입력한 다음 Enter 키를 눌러 Office 365 구독에 대한 추적 경로를 실행합니다.

  tracert <subscriptionname>.onmicrosoft.com
  

• 단계 레코더를 중지하고 비디오를 저장합니다. 캡처의 날짜와 시간 및 성능이 양선인지 나쁜지 여부를 포함해야 합니다.

• 추적 파일을 저장합니다. 다시 말하지만 캡처 날짜와 시간을 포함하고 성능이 양수인지 나쁜지를 확인해야 합니다.

이 문서에 언급된 도구를 실행하는 데 익숙하지 않은 경우 다음 단계를 제공하므로 걱정하지 마세요. 이러한 종류의 네트워크 캡처를 수행하는 데 익숙한 경우 로그 필터링 및 읽기를 설명하는 기준을 수집하는 방법으로 건너뛸 수 있습니다.

DNS 캐시를 먼저 플러시

이유 DNS 캐시를 플러시하면 클린 슬레이트로 테스트를 시작합니다. 캐시를 지우면 DNS 확인자 콘텐츠를 최신 항목으로 다시 설정합니다. 플러시에서 HOST 파일 항목은 제거되지 않습니다. HOST 파일 항목을 광범위하게 사용하는 경우 해당 항목을 다른 디렉터리의 파일에 복사한 다음 HOST 파일을 비워야 합니다.

DNS 확인자 캐시 플러시

1. 명령 프롬프트(cmd실행>시작> 또는 Windows 키>cmd)를 엽니다.

2. 다음 명령을 입력한 후 Enter 키를 누릅니다.

   ipconfig /flushdns
   

Netmon

Microsoft의 네트워크 모니터링 도구(Netmon)는 네트워크의 컴퓨터 간에 전달되는 패킷(네트워크 트래픽)을 분석합니다. Netmon을 사용하여 패킷 헤더를 캡처, 보기 및 읽고, 중간 디바이스를 식별하고, 네트워크 하드웨어에서 중요한 설정을 검사, 삭제된 패킷을 찾고, 회사 네트워크와 Office 365 컴퓨터 간의 트래픽 흐름을 따를 수 있는 Office 365 사용하여 트래픽을 추적합니다. 트래픽의 실제 본문은 암호화되므로 SSL/TLS를 통해 포트 443으로 이동하므로 전송되는 파일을 읽을 수 없습니다. 대신 패킷이 사용하는 경로의 필터링되지 않은 추적을 가져와서 문제 동작을 추적하는 데 도움이 됩니다.

현재 필터를 적용하지 마세요. 대신, 단계를 실행하고 추적을 중지하고 저장하기 전에 문제를 보여 줍니다.

Netmon 3.4를 설치한 후 도구를 열고 다음 단계를 수행합니다.

Netmon 추적을 수행하고 문제를 재현합니다.

1. Netmon 3.4를 시작합니다. 시작 페이지에는 최근 캡처, 네트워크 선택 및 Microsoft 네트워크 모니터 3.4를 사용하는 시작 세 개의 창이 있습니다. 참고 사항입니다. 네트워크 선택 패널에는 캡처할 수 있는 기본 네트워크 목록도 제공됩니다. 여기에서 네트워크 카드가 선택되어 있는지 확인합니다.

2. 시작 페이지 위쪽에서 새 캡처를 클릭합니다. 그러면 캡처 1이라는 시작 페이지 탭 옆에 새 탭이 추가됩니다.

3. 간단한 캡처를 수행하려면 도구 모음에서 시작을 클릭합니다.

4. 성능 문제가 발생하는 단계를 재현합니다.

5. 파일>다른 이름으로 저장중지>를 클릭합니다. 표준 시간대를 사용하여 날짜와 시간을 지정하고 성능이 좋지 않거나 좋은 경우 멘션 합니다.

HTTPWatch

HTTPWatch 는 요금이 청구되고 무료 버전이 제공됩니다. 무료 Basic Edition은 이 테스트에 필요한 모든 것을 다룹니다. HTTPWatch는 브라우저 창에서 네트워크 트래픽 및 페이지 로드 시간을 모니터링합니다. HTTPWatch는 성능을 그래픽으로 설명하는 Microsoft Edge에 대한 플러그 인입니다. 분석은 HTTPWatch Studio에서 저장하고 볼 수 있습니다.

참고

Firefox, Google Chrome과 같은 다른 브라우저를 사용하거나 Edge에 HTTPWatch를 설치할 수 없는 경우 새 브라우저 창을 열고 키보드에서 F12 키를 누릅니다. 브라우저 아래쪽에 개발자 도구 팝업이 표시됩니다. Opera를 사용하는 경우 Ctrl+Shift+I for Web Inspector를 누른 다음 네트워크 탭을 클릭하고 아래에 설명된 테스트를 완료합니다. 정보는 약간 다르지만 로드 시간은 여전히 밀리초 단위로 표시됩니다. > HTTPWatch는 SharePoint 페이지 로드 시간 문제에도 매우 유용합니다.

HTTPWatch를 실행하고 문제를 재현합니다.

HTTPWatch는 브라우저 플러그 인이므로 브라우저에서 도구를 노출하는 것은 Microsoft Edge의 각 버전에 대해 약간 다릅니다. 일반적으로 Microsoft Edge 브라우저의 명령 모음에서 HTTPWatch를 찾을 수 있습니다. 브라우저 창에 HTTPWatch 플러그 인이 표시되지 않으면 도움말>정보를 클릭하거나 이후 버전의 Microsoft Edge에서 기어 기호 및 Edge 정보를 클릭하여 브라우저 버전을 검사. 명령 모음을 시작하려면 Microsoft Edge의 메뉴 모음을 마우스 오른쪽 단추로 클릭하고 명령 모음을 클릭합니다.

과거에 HTTPWatch는 명령 및 Explorer 막대 모두와 연결되었으므로 설치한 후에는 도구 검사 아이콘과 아이콘에 대한 도구 모음이 즉시 표시되지 않습니다. 도구 모음을 사용자 지정할 수 있으며 옵션을 추가할 수 있습니다.

1. Microsoft Edge 브라우저 창에서 HTTPWatch를 시작합니다. 해당 창의 아래쪽에 있는 브라우저에 도킹된 것처럼 보입니다. 레코드를 클릭합니다.

2. 성능 문제와 관련된 정확한 단계를 재현합니다. HTTPWatch에서 중지 단추를 클릭합니다.

3. HTTPWatch 또는 send by Email저장합니다. 날짜 및 시간 정보와 시계에 성능 저하 데모가 포함되어 있는지 여부를 표시하도록 파일 이름을 지정해야 합니다.

이 스크린샷은 전문 버전의 HTTPWatch에서 찍은 것입니다. Professional 버전이 있는 컴퓨터에서 기본 버전에서 가져온 추적을 열고 해당 컴퓨터에서 읽을 수 있습니다. 추적에서 해당 메서드를 통해 추가 정보를 사용할 수 있습니다.

문제 단계 레코더

단계 레코더 또는 PSR.exe 문제를 기록할 수 있습니다. 매우 유용한 도구이며 실행이 간단합니다.

문제 단계 레코더(PSR.exe)를 실행하여 작업 기록

1. 실행>시작> 유형 PSR.exe>확인을 사용하거나 windows 키> 유형 PSR.exe> 클릭한 다음 Enter 키를 누릅니다.

2. 작은 PSR.exe 창이 나타나면 레코드 시작을 클릭하고 성능 문제를 재현하는 단계를 재현합니다. 필요에 따라 메모 추가를 클릭하여 주석을 추가할 수 있습니다.

3. 단계를 완료하면 레코드 중지 를 클릭합니다. 성능 문제가 페이지 렌더링인 경우 기록을 중지하기 전에 페이지가 렌더링되기를 기다립니다.

4. 저장을 클릭합니다.

날짜와 시간이 기록됩니다. 이렇게 하면 PSR을 Netmon 추적 및 HTTPWatch에 시간에 연결하고 전체적인 문제 해결에 도움이 됩니다. 예를 들어 PSR 레코드의 날짜와 시간은 URL의 로그인과 검색 사이에 1분이 경과하고 관리 사이트의 부분 렌더링을 표시할 수 있습니다.

추적 읽기

누군가가 문서를 통해 알아야 할 네트워크 및 성능 문제 해결에 대한 모든 것을 가르칠 수는 없습니다. 성능을 잘 활용하려면 경험이 필요하며 네트워크의 작동 방식과 일반적으로 수행되는 방식에 대한 지식이 필요합니다. 그러나 주요 문제 목록을 정리하고 도구가 가장 일반적인 문제를 더 쉽게 제거할 수 있는 방법을 보여 줄 수 있습니다.

Office 365 사이트에 대한 네트워크 추적을 읽는 기술을 선택하려는 경우 페이지 로드 추적을 정기적으로 만들고 읽는 경험을 얻는 것보다 더 좋은 교사는 없습니다. 예를 들어 기회가 있는 경우 Office 365 서비스를 로드하고 프로세스를 추적합니다. DNS 트래픽에 대한 추적을 필터링하거나 FrameData에서 검색한 서비스의 이름을 검색합니다. 추적을 검사하여 서비스가 로드할 때 발생하는 단계를 파악합니다. 이렇게 하면 일반적인 페이지 로드의 모양을 파악할 수 있으며, 특히 성능과 관련된 문제 해결의 경우 좋은 추적과 나쁜 추적을 비교하면 많은 것을 배울 수 있습니다.

Netmon은 디스플레이 필터 필드에서 Microsoft Intellisense를 사용합니다. Intellisense 또는 지능형 코드 완성은 마침표에 입력하고 사용 가능한 모든 옵션이 드롭다운 선택 상자에 표시되는 트릭입니다. 예를 들어 TCP 창 크기 조정이 걱정되는 경우 이를 통해 필터(예: )로 .protocol.tcp.window < 100가는 방법을 찾을 수 있습니다.

Netmon 추적에는 많은 트래픽이 있을 수 있습니다. 읽는 경험이 없는 경우 처음으로 추적을 여는 데 압도될 수 있습니다. 가장 먼저 해야 할 일은 추적의 배경 노이즈에서 신호를 분리하는 것입니다. Office 365 대해 테스트했으며, 이것이 보려는 트래픽입니다. 추적을 탐색하는 데 익숙한 경우 이 목록이 필요하지 않을 수 있습니다.

클라이언트와 Office 365 간의 트래픽은 TLS를 통해 이동합니다. 즉, 트래픽 본문이 암호화되고 일반 Netmon 추적에서 읽을 수 없습니다. 성능 분석은 패킷에 있는 정보의 세부 정보를 알 필요가 없습니다. 그러나 패킷 헤더 및 패킷 헤더에 포함된 정보에 매우 관심이 있습니다.

좋은 추적을 위한 팁

• 클라이언트 컴퓨터의 IPv4 또는 IPv6 주소 값을 알고 있습니다. IPConfig를 입력한 다음 Enter 키를 눌러 명령 프롬프트에서 이를 가져올 수 있습니다. 이 주소를 알면 추적의 트래픽이 클라이언트 컴퓨터와 직접 관련된지 여부를 한눈에 알 수 있습니다. 알려진 프록시가 있는 경우 ping하고 해당 IP 주소도 가져옵니다.

• DNS 확인자 캐시를 플러시하고 가능하면 테스트를 실행하는 브라우저를 제외한 모든 브라우저를 닫습니다. 이 작업을 수행할 수 없는 경우 instance 지원에서 일부 브라우저 기반 도구를 사용하여 클라이언트 컴퓨터의 데스크톱을 확인하는 경우 추적을 필터링할 준비를 해야 합니다.

• 사용 중인 추적에서 사용 중인 Office 365 서비스를 찾습니다. 이전에 트래픽을 본 적이 없거나 거의 본 적이 없는 경우 성능 문제를 다른 네트워크 노이즈에서 분리하는 데 도움이 되는 단계입니다. 이 작업을 수행하는 몇 가지 방법이 있습니다. 테스트 바로 전에 특정 서비스(또는 )ping outlook.office365.com의 URL에 대해 ping 또는 psping -4 microsoft-my.sharepoint.com:443PsPing을 사용할 수 있습니다. Netmon 추적에서 ping 또는 PsPing을 프로세스 이름으로 쉽게 찾을 수도 있습니다. 그것은 당신에게 찾고 시작할 수있는 장소를 제공 할 것입니다.

문제가 발생할 때 Netmon 추적만 사용하는 경우 괜찮습니다. 방향을 지정하려면 또는 ContainsBin(FrameData, ASCII, "outlook")와 같은 ContainsBin(FrameData, ASCII, "office") 필터를 사용합니다. 추적 파일에서 프레임 번호를 기록할 수 있습니다. 프레임 요약 창을 오른쪽으로 스크롤하고 대화 ID 열을 찾을 수도 있습니다. 이 특정 대화의 ID에 대한 숫자가 표시되어 있으며 나중에 격리된 상태로 기록하고 살펴볼 수도 있습니다. 다른 필터링을 적용하기 전에 이 필터를 제거해야 합니다.

팁

Netmon에는 유용한 기본 제공 필터가 많이 있습니다. 필터 표시 창 맨 위에 있는 필터 로드 단추를 사용해 보세요.

트래픽에 익숙해지고 필요한 정보를 찾는 방법을 알아봅니다. 예를 들어 추적에서 사용 중인 Office 365 서비스에 대한 첫 번째 참조가 있는 패킷(예: "Outlook")을 확인하는 방법을 알아봅니다.

Outlook Online을 예로 Office 365 트래픽은 다음과 같이 시작됩니다.

• 일치하는 Query ID를 사용하는 outlook.office365.com 대한 DNS 표준 쿼리 및 DNS 응답입니다. 이 전환에 대한 시간 오프셋과 Office 365 전역 DNS가 이름 확인 요청을 보내는 위치에 유의해야 합니다. 이상적으로, 가능한 한 로컬로, 오히려 전 세계 절반보다.

• 상태 보고서가 영구적으로 이동된 HTTP GET 요청(301)

• RWS Connect 요청 및 연결 회신을 포함한 RWS 트래픽입니다. (원격 Winsock이 자동으로 연결됩니다.)

• TCP SYN 및 TCP SYN/ACK 대화. 이 대화의 많은 설정은 성능에 영향을 줍니다.

• 그런 다음 TLS 핸드셰이크 및 TLS 인증서 대화가 이루어지는 일련의 TLS:TLS 트래픽입니다. (데이터는 SSL/TLS를 통해 암호화됩니다.)

트래픽의 모든 부분이 중요하고 연결되지만 추적의 작은 부분에는 성능 문제 해결 측면에서 중요한 정보가 포함되어 있으므로 해당 영역에 집중하겠습니다. 또한 Microsoft에서 성능 문제 해결을 충분히 Office 365 일반적인 문제 상위 10개 목록을 컴파일했기 때문에 이러한 문제와 다음에 이를 근절해야 하는 도구를 사용하는 방법에 초점을 맞출 것입니다.

아직 설치하지 않은 경우 아래 행렬은 가능한 여러 도구를 사용합니다. 설치 지점에 대한 링크가 제공됩니다. 목록에는 Netmon 및 Wireshark와 같은 일반적인 네트워크 추적 도구가 포함되어 있지만 익숙한 추적 도구와 네트워크 트래픽 필터링에 익숙한 모든 추적 도구를 사용합니다. 테스트할 때는 다음을 기억하세요.

• 브라우저를 닫고 하나의 브라우저만 실행 중인 상태에서 테스트 합니다. 이렇게 하면 캡처하는 전체 트래픽이 줄어듭니다. 그것은 덜 바쁜 추적에 대 한 합니다.
• 클라이언트 컴퓨터에서 DNS 확인자 캐시 플러시 - 더 깨끗한 추적을 위해 캡처를 시작할 때 클린 슬레이트를 제공합니다.

일반적인 문제

발생할 수 있는 몇 가지 일반적인 문제와 네트워크 추적에서 이러한 문제를 찾는 방법입니다.

TCP Windows 크기 조정

SYN - SYN/ACK에서 찾을 수 있습니다. 레거시 또는 노후화된 하드웨어는 TCP 창 크기 조정을 활용하지 못할 수 있습니다. 적절한 TCP 창 크기 조정 설정이 없으면 TCP 헤더의 기본 16비트 버퍼가 밀리초 단위로 채워됩니다. 클라이언트가 원래 데이터가 수신되었다는 승인을 받을 때까지 트래픽을 계속 보낼 수 없으므로 지연이 발생합니다.

도구

• Netmon
• Wireshark

찾을 내용

네트워크 추적에서 SYN - SYN/ACK 트래픽을 찾습니다. Netmon에서 와 같은 tcp.flags.syn == 1필터를 사용합니다. 이 필터는 Wireshark에서 동일합니다.

모든 SYN에 대해 관련 승인(SYN/ACK)의 대상 포트(DstPort)에 일치하는 원본 포트(SrcPort) 번호가 있습니다.

네트워크 연결에서 사용되는 Windows 크기 조정 값을 보려면 먼저 SYN을 확장한 다음 관련 SYN/ACK를 확장합니다.

TCP 유휴 시간 설정

지금까지 대부분의 경계 네트워크는 일시적인 연결에 대해 구성됩니다. 즉, 유휴 연결이 일반적으로 종료됩니다. 유휴 TCP 세션은 100~300초보다 큰 프록시 및 방화벽에 의해 종료될 수 있습니다. 이는 유휴 상태이든 아니든 장기 연결을 만들고 사용하기 때문에 Outlook Online에 문제가 있습니다.

프록시 또는 방화벽 디바이스에 의해 연결이 종료되면 클라이언트에 알림이 표시되지 않으며 Outlook Online을 사용하려고 하면 클라이언트 컴퓨터가 새 연결을 만들기 전에 연결을 다시 시작하려고 반복적으로 시도합니다. 제품에서 중단, 프롬프트 또는 페이지 로드 시 성능 저하가 표시될 수 있습니다.

도구

• Netmon
• Wireshark

찾을 내용

Netmon에서 왕복에 대한 시간 오프셋 필드를 확인합니다. 왕복은 클라이언트가 서버에 요청을 보내고 응답을 다시 받는 시간입니다. 클라이언트와 송신 지점(예: 클라이언트 --> 프록시) 또는 클라이언트에서 Office 365(클라이언트 --> Office 365) 간에 확인합니다. 여러 유형의 패킷에서 이를 볼 수 있습니다.

예를 들어 Netmon의 필터는 Wiresharkip.addr == 10.102.14.112 && ip.addr == 10.201.114.12에서 또는 와 같.Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12을 수 있습니다.

팁

추적의 IP 주소가 DNS 서버에 속하는지 모르나요? 명령줄에서 찾습니다. 실행>시작을> 클릭하고 cmd를 입력하거나 Windows 키를> 누르고 cmd를 입력합니다. 프롬프트에서 를 입력합니다 nslookup <the IP address from the network trace>. 테스트하려면 컴퓨터의 IP 주소에 대해 nslookup을 사용합니다. >Microsoft의 IP 범위 목록을 보려면 Office 365 URL 및 IP 주소 범위를 참조하세요.

문제가 있는 경우 이 경우(Outlook Online), 특히 애플리케이션 데이터의 통과를 보여 주는 TLS:TLS 패킷에서 긴 시간 오프셋이 나타날 것으로 예상합니다(예: Netmon에서는 을 통해 .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"애플리케이션 데이터 패킷을 찾을 수 있음). 세션 전체의 시간에 원활한 진행이 표시됩니다. Outlook Online을 새로 고치는 동안 긴 지연이 표시되는 경우 높은 수준의 초기화가 전송되어 발생할 수 있습니다.

대기 시간/왕복 시간

대기 시간은 노후화된 디바이스 업그레이드, 네트워크에 많은 수의 사용자 추가, 네트워크 연결의 다른 작업에서 사용하는 전체 대역폭 비율 등 많은 변수에 따라 많이 변경될 수 있는 측정값입니다.

이 네트워크 계획 및 Office 365 페이지의 성능 조정에서 사용할 수 있는 Office 365 대역폭 계산기가 있습니다.

연결 속도 또는 ISP 연결의 대역폭을 측정해야 합니까? 이 사이트(또는 이와 같은 사이트): Speedtest 공식 사이트를 사용하거나 즐겨 찾는 검색 엔진에서 구 속도 테스트를 쿼리합니다.

도구

• Ping
• PsPing
• Netmon
• Wireshark

찾을 내용

추적의 대기 시간을 추적하려면 Office 365 DNS 서버의 IP 주소와 클라이언트 컴퓨터 IP 주소를 기록한 것이 도움이 됩니다. 이는 더 쉬운 추적 필터링을 위한 것입니다. 프록시를 통해 연결하는 경우 작업을 더 쉽게 수행하려면 클라이언트 컴퓨터 IP 주소, 프록시/송신 IP 주소 및 Office 365 DNS IP 주소가 필요합니다.

outlook.office365.com 전송된 ping 요청은 ping이 상표 연속 ICMP 패킷을 보내기 위해 연결하지 못할 수 있더라도 요청을 수신하는 데이터 센터의 이름을 알려줍니다. PsPing(다운로드용 무료 도구) 및 특정 포트(443)를 사용하고 IPv4(-4)를 사용하는 경우 전송된 패킷에 대한 평균 왕복 시간을 받게 됩니다. 이 작업은 Office 365 서비스의 다른 URL(예: psping -4 yourSite.sharepoint.com:443)에 대해 작동합니다. 실제로 평균에 대한 더 큰 샘플을 가져오기 위해 여러 ping을 지정할 수 있습니다. 와 같은 psping -4 -n 20 yourSite-my.sharepoint.com:443작업을 시도해 보세요.

참고

PsPing은 ICMP 패킷을 보내지 않습니다. 특정 포트를 통해 TCP 패킷을 사용하여 ping하므로 열려 있는 것으로 알고 있는 모든 패킷을 사용할 수 있습니다. SSL/TLS를 사용하는 Office 365 PsPing에 포트 :443을 연결해 보세요.

네트워크 추적을 수행하는 동안 성능이 느린 Office 365 페이지를 로드한 경우 에 대한 Netmon 또는 Wireshark 추적을 DNS필터링해야 합니다. 이것은 우리가 찾고있는 IP 중 하나입니다.

다음은 Netmon을 필터링하여 IP 주소를 가져오기 위해 수행하는 단계입니다(DNS 대기 시간 살펴보기). 이 예제에서는 outlook.office365.com 사용하지만 SharePoint 테넌트(예: hithere.sharepoint.com)의 URL을 사용할 수도 있습니다.

1. URL ping outlook.office365.com 을 Ping하고 결과에 ping 요청이 전송된 DNS 서버의 이름과 IP 주소를 기록합니다.
2. 네트워크 추적 페이지를 열거나 성능 문제를 제공하는 작업을 수행하거나 ping에 대기 시간이 긴 경우 네트워크 추적을 수행합니다.
3. Netmon에서 추적을 열고 DNS를 필터링합니다(이 필터는 Wireshark에서도 작동하지만 대/소문 -- dns자 구분). ping에서 DNS 서버의 이름을 알고 있으므로 다음과 같이 DNS AND ContainsBin(FrameData, ASCII, "namnorthwest")Netmon에서 더 빠르게 필터링할 수도 있습니다. Wireshark dns 및 프레임에는 "namnorthwest"가 포함되어 있습니다.
   응답 패킷을 열고 Netmon 프레임 세부 정보 창에서 DNS 를 클릭하여 자세한 내용을 확인합니다. DNS 정보에서 요청이 Office 365 갔던 DNS 서버의 IP 주소를 찾을 수 있습니다. 다음 단계(PsPing 도구)에는 이 IP 주소가 필요합니다. 필터를 제거하고 Netmon의 DNS 응답(프레임 요약>대화> 찾기DNS)을 마우스 오른쪽 단추로 클릭하여 DNS 쿼리 및 응답을 나란히 확인합니다.
4. Netmon에서는 DNS 요청과 응답 간의 시간 오프셋 열도 확인합니다. 다음 단계에서는 ICMP가 방화벽에서 차단되는 경우가 많고 PsPing이 대기 시간을 밀리초 단위로 우아하게 추적하기 때문에 PsPing 도구를 설치 및 사용하기가 매우 편리합니다. PsPing은 주소 및 포트에 대한 TCP 연결을 완료합니다(이 경우 포트 443 열기).
5. PsPing을 설치합니다.
6. 명령 프롬프트(실행 > 유형 cmd 또는 Windows 키 > 형식 cmd 시작>)를 열고 PsPing 명령을 실행하기 위해 PsPing을 설치한 디렉터리로 디렉터리를 변경합니다. 내 예제에서는 C의 루트에 'Perf' 폴더를 만든 것을 볼 수 있습니다. 빠른 액세스를 위해 동일한 작업을 수행할 수 있습니다.
7. 와 같은 psping -n 20 132.245.24.82:445포트 번호를 포함하여 이전 Netmon 추적에서 Office 365 DNS 서버의 IP 주소에 대해 PsPing을 만들도록 명령을 입력합니다. 이렇게 하면 20개의 ping 샘플링이 제공되고 PsPing이 중지될 때 평균 대기 시간이 발생합니다.

프록시 서버를 통해 Office 365 경우 단계는 약간 다릅니다. 먼저 프록시 서버로 PsPing을 실행하여 프록시/송신 및 백에 대한 평균 대기 시간 값을 밀리초 단위로 구한 다음 프록시 또는 직접 인터넷 연결이 있는 컴퓨터에서 PsPing을 실행하여 누락된 값(Office 365 및 뒤로)을 가져옵니다.

프록시에서 PsPing을 실행하도록 선택하면 클라이언트 컴퓨터에서 프록시 서버 또는 송신 지점으로, 프록시 서버에서 Office 365 두 밀리초 값이 있습니다. 그리고 당신은 끝났어! 음, 어쨌든 값을 기록합니다.

인터넷에 직접 연결되는 다른 클라이언트 컴퓨터, 즉 프록시 없이 PsPing을 실행하는 경우 클라이언트 컴퓨터에서 프록시 서버 또는 송신 지점으로, Office 365 클라이언트 컴퓨터의 두 밀리초 값이 있습니다. 이 경우 클라이언트 컴퓨터의 값을 프록시 서버 또는 송신 지점의 값을 클라이언트 컴퓨터 값에서 Office 365 빼면 클라이언트 컴퓨터에서 프록시 서버 또는 송신 지점으로, 프록시 서버 또는 송신 지점에서 Office 365 RTT 번호가 있습니다.

그러나 영향을 받는 위치에서 직접 연결되거나 프록시를 우회하는 클라이언트 컴퓨터를 찾을 수 있는 경우 문제가 해당 위치에서 재현되는지 확인하고 그 후에 이를 사용하여 테스트하도록 선택할 수 있습니다.

Netmon 추적에서 볼 수 있듯이 대기 시간은 지정된 세션에 충분한 경우 추가 밀리초가 더해질 수 있습니다.

참고

IP 주소는 여기에 표시된 IP와 다를 수 있습니다. 예를 들어 ping은 157.56.0.0/16 또는 유사한 범위를 반환할 수 있습니다. Office 365 사용하는 범위 목록은 Office 365 URL 및 IP 주소 범위를 검사.

검색하려는 경우(예: 132.245) 모든 노드(맨 위에 단추가 있습니다)를 확장해야 합니다.

프록시 인증

이는 프록시 서버를 통과하는 경우에만 적용됩니다. 그렇지 않은 경우 다음 단계를 건너뛸 수 있습니다. 제대로 작동할 때 프록시 인증은 일관되게 밀리초 단위로 수행되어야 합니다. 사용량이 많은 기간(예: ) 동안에는 일시적인 나쁜 성능이 표시되지 않아야 합니다.

프록시 인증이 켜진 경우 정보를 가져오기 위해 Office 365 새 TCP 연결을 만들 때마다 백그라운드에서 인증 프로세스를 통과해야 합니다. 예를 들어 Outlook Online에서 일정에서 메일로 전환하면 인증됩니다. 또한 SharePoint에서 페이지에 여러 사이트 또는 위치의 미디어 또는 데이터가 표시되는 경우 데이터를 렌더링하는 데 필요한 각 TCP 연결에 대해 인증합니다.

Outlook Online에서는 일정과 사서함 간에 전환할 때마다 로드 시간이 느려지거나 SharePoint에서 페이지 로드 속도가 느려질 수 있습니다. 그러나 여기에 나열되지 않은 다른 증상이 있습니다.

프록시 인증은 송신 프록시 서버의 설정입니다. Office 365 성능 문제가 발생하는 경우 네트워킹 팀에 문의해야 합니다.

도구

• Netmon
• Wireshark

찾을 내용

프록시 인증은 일반적으로 서버에서 파일 또는 정보를 요청하거나 정보를 제공하기 위해 새 TCP 세션을 회전해야 할 때마다 발생합니다. 예를 들어 HTTP GET 또는 HTTP POST 요청에 대한 프록시 인증이 표시될 수 있습니다. 추적에서 요청을 인증하는 프레임을 보려면 'NTLMSSP 요약' 열을 Netmon에 추가하고 를 .property.NTLMSSPSummary필터링합니다. 인증에 걸리는 시간을 확인하려면 Time Delta 열을 추가합니다.

Netmon에 열을 추가하려면 다음을 수행합니다.

1. 설명과 같은 열을 마우스 오른쪽 단추로 클릭합니다.
2. 열 선택을 클릭합니다.
3. 목록에서 NTLMSSP 요약 및 시간 델타 를 찾아 추가를 클릭합니다.
4. 새 열을 설명 열 앞이나 뒤로 이동하여 나란히 읽을 수 있습니다.
5. 확인을 클릭합니다.

열을 추가하지 않더라도 Netmon 필터가 작동합니다. 그러나 현재 사용 중인 인증 단계를 확인할 수 있는 경우 문제 해결이 훨씬 쉬워질 것입니다.

프록시 인증 인스턴스를 찾는 경우 NTLM 챌린지가 있거나 인증 메시지가 있는 모든 프레임을 연구해야 합니다. 필요한 경우 특정 트래픽 부분을 마우스 오른쪽 단추로 클릭하고 대화 > TCP 찾기를 클릭합니다. 이러한 대화에서 시간 델타 값을 알고 있어야 합니다.

Wireshark에서 볼 수 있듯이 프록시 인증이 4초 지연됩니다. 이전에 표시된 프레임 열의 시간 델타는 프레임 세부 정보에서 같은 이름의 필드를 마우스 오른쪽 단추로 클릭하고 열로 추가를 선택하여 만들어졌습니다.

DNS 성능

이름 확인은 가능한 한 클라이언트의 국가/지역에 가깝게 발생할 때 가장 빠르게 작동합니다.

DNS 이름 확인이 해외에서 이루어지는 경우 페이지 로드에 초를 추가할 수 있습니다. 이상적으로 이름 확인은 100ms 미만에서 발생합니다. 그렇지 않은 경우 추가 조사를 수행해야 합니다.

팁

Office 365 클라이언트 연결이 어떻게 작동하는지 확실하지 않나요? 여기에서 클라이언트 연결 참조 문서를 살펴보세요.

도구

• Netmon
• Wireshark
• PsPing

찾을 내용

DNS 성능 분석은 일반적으로 네트워크 추적에 대한 또 다른 작업입니다. 그러나 PsPing은 가능한 원인을 판결하거나 배제하는 데에도 유용합니다.

DNS 트래픽은 TCP 및 UDP 요청을 기반으로 하며 응답은 특정 요청을 특정 응답과 일치시키는 데 도움이 되는 ID로 명확하게 표시됩니다. 예를 들어 SharePoint가 웹 페이지에서 네트워크 이름 또는 URL을 사용하는 경우 DNS 트래픽이 표시됩니다. 일반적으로 영역을 전송할 때를 제외하고 이 트래픽의 대부분은 UDP를 통해 실행됩니다.

Netmon과 Wireshark 모두에서 DNS 트래픽을 볼 수 있는 가장 기본적인 필터는 단순히 dns입니다. 필터를 지정할 때 소문자를 사용해야 합니다. 클라이언트 컴퓨터에서 문제를 재현하기 전에 DNS 확인자 캐시를 플러시해야 합니다. 예를 들어 홈 페이지에 대한 SharePoint 페이지 로드가 느린 경우 모든 브라우저를 닫고, 새 브라우저를 열고, 추적을 시작하고, DNS 확인자 캐시를 플러시하고, SharePoint 사이트로 이동해야 합니다. 전체 페이지가 확인되면 추적을 중지하고 저장해야 합니다.

여기에서 시간 오프셋을 확인하려고 합니다. 또한 다음 단계를 완료하여 수행할 수 있는 Time Delta 열을 Netmon에 추가하는 것이 도움이 될 수 있습니다.

1. 설명과 같은 열을 마우스 오른쪽 단추로 클릭합니다.
2. 열 선택을 클릭합니다.
3. 목록에서 시간 델타 를 찾고 추가를 클릭합니다.
4. 새 열을 설명 열 앞이나 뒤로 이동하여 나란히 읽을 수 있습니다.
5. 확인을 클릭합니다.

관심 있는 쿼리를 찾으면 프레임 세부 정보 패널에서 해당 쿼리를 마우스 오른쪽 단추로 클릭하고 대화>DNS 찾기를 선택하여 격리하는 것이 좋습니다. 네트워크 대화 패널이 UDP 트래픽 로그의 특정 대화로 바로 이동합니다.

Wireshark에서 DNS 시간에 대한 열을 만들 수 있습니다. Wireshark에서 추적(또는 추적 열기)을 수행하고 , 또는 를 dns.time기준으로 dns필터링합니다. DNS 쿼리를 클릭하고 세부 정보를 보여 주는 패널에서 세부 정보를 확장합니다 Domain Name System (response) . 시간 필드가 표시됩니다(예: [Time: 0.001111100 seconds]). 이번에는 마우스 오른쪽 단추 로 클릭하고 열로 적용을 선택합니다. 이렇게 하면 추적을 더 빠르게 정렬할 수 있는 시간 열이 표시됩니다. 새 열을 클릭하여 내림차순 값을 기준으로 정렬하여 resolve 데 가장 오래 걸린 DNS 호출을 확인합니다.

세부 정보의 시간을 열로 만들고 오름차순으로 정렬하여 Wireshark에서 (소문자) dns.time으로 필터링된 SharePoint의 찾아보기입니다.

DNS 확인 시간을 더 자세히 조사하려면 TCP에서 사용하는 DNS 포트(예 psping <IP address of DNS server>:53: )에 대해 PsPing을 시도합니다. 성능 문제가 계속 표시되나요? 이렇게 하면 문제를 해결하기 위해 적중하는 특정 DNS 애플리케이션의 문제보다 더 광범위한 네트워크 문제가 될 가능성이 높습니다. 또한 outlook.office365.com 대한 ping은 Outlook Online의 DNS 이름 확인이 수행되는 위치(예: outlook-namnorthwest.office365.com)를 알려줍니다.

문제가 DNS별로 표시되는 경우 IT 부서에 문의하여 DNS 구성 및 DNS 전달자를 확인하여 이 문제를 추가로 조사해야 할 수 있습니다.

프록시 확장성

Office 365 Outlook Online과 같은 서비스는 클라이언트에 여러 장기 연결을 부여합니다. 따라서 각 사용자는 더 긴 수명이 필요한 더 많은 연결을 사용할 수 있습니다.

도구

수학

찾을 내용

이와 관련된 네트워크 추적 또는 문제 해결 도구는 없습니다. 대신 제한 사항 및 기타 변수가 지정된 대역폭 계산을 기반으로 합니다.

TCP 최대 세그먼트 크기

SYN - SYN/ACK에서 찾을 수 있습니다. TCP 패킷이 가능한 최대 데이터 양을 전달하도록 구성되어 있는지 확인하기 위해 수행한 모든 성능 네트워크 추적에서 이 검사 수행합니다.

목표는 데이터 전송을 위해 1,460바이트 MSS를 확인하는 것입니다. 프록시 뒤에 있거나 NAT를 사용하는 경우 최상의 결과를 얻으려면 클라이언트에서 프록시/송신/NAT로, 프록시/송신/NAT에서 Office 365 이 테스트를 실행해야 합니다. 서로 다른 TCP 세션입니다.

도구

Netmon

찾을 내용

TCP MSS(최대 세그먼트 크기)는 네트워크 추적에서 3방향 핸드셰이크의 또 다른 매개 변수로, SYN - SYN/ACK 패킷에서 필요한 데이터를 찾을 수 있습니다. MSS는 보기가 매우 간단합니다.

가지고 있는 성능 네트워크 추적을 열고 궁금한 연결을 찾거나 성능 문제를 보여 줍니다.

참고

추적을 보고 대화와 관련된 트래픽을 찾아야 하는 경우 클라이언트의 IP 또는 프록시 서버 또는 송신 지점의 IP 또는 둘 다를 기준으로 필터링합니다. 직접 진행하려면 추적에서 Office 365 IP 주소에 대해 테스트하는 URL을 ping하고 필터링해야 합니다.

추적 중고를 보고 계십니까? 필터를 사용하여 방향을 지정해 보세요. Netmon에서 와 같은 Containsbin(framedata, ascii, "sphybridExample")URL을 기반으로 검색을 실행하여 프레임 번호를 기록해 둡니다.

Wireshark에서 와 같은 frame contains "sphybridExample"항목을 사용합니다. RWS(원격 Winsock) 트래픽(Wireshark에서 [PSH, ACK]로 표시될 수 있음)을 발견한 경우 앞에서 설명한 대로 관련 SYN - SYN/ACK 직전에 RWS 연결을 볼 수 있습니다.

이 시점에서 프레임 번호를 기록하고 필터를 삭제한 다음 Netmon의 네트워크 대화 창에서 모든 트래픽 을 클릭하여 가장 가까운 SYN을 확인할 수 있습니다.

중요한 것은 추적 시 IP 주소 정보를 받지 못한 경우 추적에서 URL(예: 의 sphybridExample-my.sharepoint.com일부)을 찾으면 필터링할 IP 주소가 제공됩니다.

보고자 하는 추적에서 연결을 찾습니다. 추적을 검사하거나, IP 주소를 기준으로 필터링하거나, Netmon에서 네트워크 대화 창을 사용하여 특정 대화 ID를 선택하여 이 작업을 수행할 수 있습니다. SYN 패킷이 발견되면 프레임 세부 정보 패널에서 TCP(Netmon) 또는 전송 제어 프로토콜(Wireshark)을 확장합니다. TCP 옵션 및 MaxSegmentSize를 확장합니다. 관련 SYN-ACK 프레임을 찾고 TCP 옵션 및 MaxSegmentSize를 확장합니다. 두 값 중 작은 값은 최대 세그먼트 크기입니다. 이 그림에서는 TCP 문제 해결이라는 Netmon의 기본 제공 열을 사용합니다.

기본 제공 열은 프레임 세부 정보 패널의 맨 위에 있습니다. (기본 보기로 다시 전환하려면 열을 다시 클릭한 다음 표준 시간대를 선택합니다.)

Wireshark의 필터링된 추적은 다음과 같습니다. MSS 값()과 관련된 필터가tcp.options.mss 있습니다. SYN, SYN/ACK, ACK 핸드셰이크의 프레임은 프레임 세부 정보(프레임 47 ACK, 46 SYN/ACK에 대한 링크, 43 SYN에 대한 링크)와 동일한 Wireshark 아래쪽에 연결되어 이러한 종류의 작업을 더 쉽게 만듭니다.

선택적 승인(이 매트릭스의 다음 항목)을 검사 경우 추적을 닫지 마세요.

선택적 승인

SYN - SYN/ACK에서 찾을 수 있습니다. SYN 및 SYN/ACK 모두에서 허용됨으로 보고되어야 합니다. SACK(선택적 승인)을 사용하면 패킷 또는 패킷이 누락될 때 데이터를 보다 원활하게 다시 전송할 수 있습니다. 디바이스에서 이 기능을 사용하지 않도록 설정하면 성능 문제가 발생할 수 있습니다.

프록시 뒤에 있거나 NAT를 사용하는 경우 최상의 결과를 얻으려면 클라이언트에서 프록시/송신/NAT로, 프록시/송신/NAT에서 Office 365 이 테스트를 실행해야 합니다. 서로 다른 TCP 세션입니다.

도구

Netmon

찾을 내용

SACK(선택적 승인)은 SYN-SYN/ACK 핸드셰이크의 또 다른 매개 변수입니다. SYN - SYN/ACK에 대한 추적을 여러 가지 방법으로 필터링할 수 있습니다.

추적을 검사하거나, IP 주소를 기준으로 필터링하거나, Netmon의 네트워크 대화 창을 사용하여 대화 ID를 클릭하여 확인하려는 추적에서 연결을 찾습니다. SYN 패킷을 찾았으면 프레임 세부 정보 섹션에서 Netmon의 TCP 또는 Wireshark의 전송 제어 프로토콜을 확장합니다. TCP 옵션을 확장한 다음 SACK을 확장합니다. 관련 SYN-ACK 프레임을 찾고 TCP 옵션 및 해당 SACK 필드를 확장합니다. SYN 및 SYN/ACK 모두에서 특정 SACK이 허용되는지 확인합니다. 다음은 Netmon 및 Wireshark에서 볼 수 있는 SACK 값입니다.

DNS 지리적 위치

전 세계 Office 365 DNS 호출을 resolve 시도하면 연결 속도에 영향을 줍니다.

Outlook Online에서 첫 번째 DNS 조회가 완료되면 해당 DNS의 위치가 가장 가까운 데이터 센터에 연결하는 데 사용됩니다. 백본 네트워크를 사용하여 데이터가 저장된 dC(데이터 센터)에 연결하는 Outlook Online CAS 서버에 연결됩니다. 더 빠릅니다.

SharePoint에 액세스할 때 해외 여행하는 사용자는 활성 데이터 센터로 이동됩니다. 해당 위치는 SPO 테넌트의 홈베이스를 기반으로 하는 dC입니다(따라서 미국 기반인 경우 미국의 dC).

Lync Online에는 한 번에 둘 이상의 dC에 활성 노드가 있습니다. Lync 온라인 인스턴스에 대한 요청이 전송되면 Microsoft의 DNS는 전 세계에서 요청이 어디에서 왔는지 확인하고 Lync Online이 활성 상태인 가장 가까운 지역 dC에서 IP 주소를 반환합니다.

팁

클라이언트가 Office 365 연결하는 방법에 대해 자세히 알고 있어야 합니까? 클라이언트 연결 참조 문서(및 유용한 그래픽)를 살펴보세요.

도구

• Ping
• PsPing

찾을 내용

클라이언트의 DNS 서버에서 Microsoft의 DNS 서버로 이름 확인을 요청하면 대부분의 경우 Microsoft DNS가 지역 데이터 센터(dC)의 IP 주소를 반환해야 합니다. 이것은 당신을 위해 무엇을 의미합니까? 본사가 인도 벵갈루루에 있지만 미국 여행하는 경우 브라우저에서 Outlook Online을 요청할 때 Microsoft의 DNS 서버는 지역 데이터 센터인 미국 데이터 센터에 IP 주소를 전달해야 합니다. Outlook에서 메일이 필요한 경우 해당 데이터는 데이터 센터 간에 Microsoft의 빠른 백본 네트워크를 통해 이동합니다.

DNS는 이름 확인이 가능한 한 사용자 위치에 가깝게 수행되는 경우 가장 빠르게 작동합니다. 유럽에 있는 경우 유럽의 Microsoft DNS로 이동하여(이상적으로) 유럽의 데이터 센터를 처리하려고 합니다. DNS로 가는 유럽의 클라이언트와 미국의 데이터 센터의 성능은 느려집니다.

outlook.office365.com 대해 Ping 도구를 실행하여 DNS 요청이 라우팅되는 위치를 확인합니다. 유럽에 있는 경우 outlook-emeawest.office365.com 같은 회신이 표시됩니다. 미대륙에서는 outlook-namnorthwest.office365.com 같은 것을 기대하십시오.

클라이언트 컴퓨터에서 명령 프롬프트를 엽니다(시작 > 실행 > cmd 또는 Windows 키 > 형식 cmd를 통해). ping outlook.office365.com 입력하고 Enter 키를 누릅니다. IPv4를 통해 ping하도록 지정하려면 -4를 지정해야 합니다. ICMP 패킷에서 회신을 가져오지 못할 수 있지만 요청이 라우팅된 DNS의 이름이 표시됩니다. 이 연결의 대기 시간 번호를 보려면 ping에서 반환되는 서버의 IP 주소로 PsPing을 시도합니다.

Office 365 애플리케이션 문제 해결

도구

• Netmon
• HTTPWatch
• 브라우저의 F12 콘솔

이 네트워크 관련 문서에서 애플리케이션별 문제 해결에 사용되는 도구는 다루지 않습니다. 하지만 이 페이지에서 사용할 수 있는 리소스를 찾을 수 있습니다.

관련 문서

Office 365 끝점 관리

Office 365 끝점 FAQ