Office 365 성능 문제 해결 계획

식별 하 고 저하, 중단, SharePoint Online, OneDrive for Business, Exchange Online 또는 비즈니스용 Skype Online, 및 클라이언트 컴퓨터 간의 성능이 느려지는 문제를 해결 하기 위해 수행할 단계를 알아야 할 사항 지원에 문의 하기 전에이 문서의 Office 365 성능 문제를 해결 하 고도 몇 가지 가장 일반적인 문제를 해결할 수 있습니다.

참고:  사용자 언어로 가능한 한 빨리 가장 최신의 도움말 콘텐츠를 제공하고자 합니다. 이 페이지는 자동화를 통해 번역되었으며 문법 오류나 부정확한 설명을 포함할 수 있습니다. 이 목적은 콘텐츠가 사용자에게 유용하다는 것입니다. 이 페이지 하단의 정보가 도움이 되었다면 알려주세요. 쉽게 참조할 수 있는 영어 문서 가 여기 있습니다.

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

네트워크 성능을 처음 사용하는 경우 클라이언트 컴퓨터와 Office 365 간에 성능을 모니터링할 장기 계획을 수립하려면 Office 365 성능 조정 및 문제 해결 - 관리자 및 IT 전문가를 참조하세요.

샘플 성능 문제 해결 실행 계획

이 작업 계획은 준비 단계와 기록 단계의 두 부분으로 구성됩니다. 현재 현재 성능 문제를 겪고 있으며 데이터를 수집해야 하는 경우, 이 계획을 즉시 사용할 수 있습니다.

클라이언트 컴퓨터 준비

  • 성능 문제를 재현할 수 있는 클라이언트 컴퓨터를 찾습니다. 문제 해결 과정에서 이 컴퓨터를 사용합니다.

  • 성능 문제가 발생한 단계를 기록하여 테스트에 대비합니다.

  • 정보 수집 및 기록을 위한 도구를 설치합니다.

    • Netmon 3.4를 설치하거나 동급의 네트워크 추적 도구를 사용합니다.

    • 무료 HTTPWatch Basic Edition을 설치하거나 동급의 네트워크 추적 도구를 사용합니다.

    • 테스트 중 단계를 기록하려면 화면 레코더를 사용하거나 Windows Vista 이상 버전에 기본 제공되는 단계 레코더를 실행합니다.

성능 문제 기록

  • 관련 없는 인터넷 브라우저를 모두 닫습니다.

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

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

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

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

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

  • 성능 문제를 일으킨 단계를 정확히 재현합니다.

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

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

    tracert <구독 이름>.onmicrosoft.com

  • 단계 레코더를 중지하고 비디오를 저장합니다. 캡처한 날짜 및 시간과 성능이 양호했는지 또는 나빴는지 여부를 포함합니다.

  • 추적 파일을 저장합니다. 이번에도 캡처한 날짜 및 시간과 성능이 양호했는지 또는 나빴는지 여부를 포함합니다.

이 문서에서 소개한 도구의 실행 방법을 잘 모르는 경우 뒷부분에 제공되는 단계를 참조하세요. 이러한 유형의 네트워크 캡처에 익숙할 경우 로그 필터링 및 읽기에 대해 설명하는 추적 해석 방법 섹션으로 건너뛸 수 있습니다.

먼저 DNS 캐시 지우기

그 이유는 무엇일까요? DNS 캐시를 지우면 깨끗한 상태에서 테스트를 시작하는 것입니다. 캐시를 지우면 DNS 확인자 내용이 최신 항목으로 다시 설정됩니다. 지우기를 수행해도 HOST 파일 항목은 제거되지 않습니다. HOST 파일 항목을 광범위하게 사용하는 경우 해당 항목을 다른 디렉터리에 있는 파일로 복사한 다음 HOST 파일의 내용을 모두 지웁니다.

DNS 확인자 캐시 지우기

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

  2. 다음 명령을 입력하고 Enter 키를 누릅니다.

    ipconfig /flushdns

Netmon

Microsoft의 네트워크 모니터링 도구 (Netmon) 트래픽이 네트워크의 컴퓨터 간에 전달 되는 패킷을 분석 합니다. Office 365 캡처할 수 있는 보기를 사용 하 여 트래픽을 추적 하 고 패킷 헤더 읽기, 중간에 다른 장치를 확인, 네트워크 하드웨어에서 중요 한 설정을 확인 하려면 Netmon을 사용 하 여 삭제 된 패킷 찾아 회사의 컴퓨터 간 통신 흐름을 팔 로우 Office 365 및 네트워크입니다. 실제 트래픽 본문 암호화 되어 있기 때문에 즉, (SSL/TLS를 통해 포트 443 여행 읽을 수 없습니다 파일 전송 합니다. 대신 문제 동작 추적 하는 데 도움이 되는 패킷 되려면 경로의 필터링 되지 않은 추적을 가져옵니다.

지금은 필터를 적용하지 않아야 합니다. 대신, 추적을 중지 및 저장하기 전에 단계를 실행하여 문제를 재현해야 합니다.

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

Netmon 추적 실행 및 문제 재현

  1. Netmon 3.4를 시작합니다.

    시작 페이지에는 세 개의 창이: 최근 캡처, 네트워크 선택Microsoft 네트워크 모니터 3.4 시작 합니다. 알림을 합니다. 또한 네트워크 선택 패널 캡처할 수 있는 기본 네트워크 목록이 제공 합니다. 네트워크 카드 여기 선택 되어 있어야 합니다.

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

    새 캡처, 시작, 중지 단추가 강조 표시된 Nemon의 사용자 인터페이스

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

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

  5. 중지 > 파일 > 다른 이름으로 저장을 클릭합니다. 표준 시간대와 함께 날짜 및 시간을 지정하고 성능이 양호했는지 또는 나빴는지 여부를 포함합니다.

HTTPWatch

HTTPWatch 걸려올 충전, 무료 edition 합니다. 무료 기본 Edition이이 테스트를 위해 필요한 모든 항목을 다룹니다. HTTPWatch 모니터 브라우저 창에서 바로 트래픽과 페이지 로드 시를 네트워크입니다. HTTPWatch는 플러그 인을 시각적으로 성능에 설명 하는 Internet Explorer입니다. 분석 저장 하 고 HTTPWatch Studio에서 볼 수 있습니다.

참고 사항: 

  • Firefox, Google Chrome 등의 다른 브라우저를 사용하거나 Internet Explorer에 HTTPWatch를 설치할 수 없는 경우, 새 브라우저 창을 열고 키보드에서 F12를 누릅니다. 브라우저 아래쪽에 개발자 도구 팝업이 나타납니다. Opera를 사용하는 경우 Ctrl+Shift+I를 눌러 Web Inspector를 실행한 다음 네트워크 탭을 눌러 아래 요약된 테스트를 완료합니다. 정보는 약간 다르지만 여기에서도 로드 시간은 밀리초 단위로 표시됩니다.

  • HTTPWatch는 SharePoint Online 페이지 로드 시간과 관련된 문제에도 매우 유용합니다.

HTTPWatch 실행 및 문제 재현

  1. HTTPWatch는 브라우저 플러그 인이므로 브라우저에서 도구를 노출하는 방법은 각 버전의 Internet Explorer마다 약간씩 다릅니다. 일반적으로, Internet Explorer 브라우저의 명령 모음에서 HTTPWatch를 찾을 수 있습니다.

    브라우저 창에 HTTPWatch 플러그 인이 없는 경우 '도움말' > '정보'를 클릭하여 브라우저 버전을 확인합니다. 최신 버전 Internet Explorer에서는 톱니 바퀴 기호와 'Internet Explorer 정보'를 차례로 클릭합니다. 명령 모음을 시작하려면 Internet Explorer에서 마우스 오른쪽 단추로 메뉴 모음을 클릭한 다음 명령 모음을 클릭합니다. 이전에는 HTTPWatch가 명령 모음 및 탐색 창과 연결되어 있었습니다. 따라서, 설치 후 재부팅한 다음에도 바로 아이콘이 표시되지 않을 경우 도구에서 아이콘 도구 모음을 확인합니다. 도구 모음은 사용자 지정할 수 있으며 옵션을 추가할 수 있습니다.

    HTTPWatch 아이콘이 표시된 Internet Explorer의 명령 모음

  2. Internet Explorer 브라우저 창에서 HTTPWatch를 실행합니다. HTTPWatch가 브라우저 창 하단에 고정되어 나타납니다. 기록을 클릭합니다.

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

  4. HTTPWatch를 저장하거나 전자 메일로 보냅니다. 날짜 및 시간 정보와 Watch에 성능이 양호했는지 또는 나빴는지 여부를 나타내는 문구를 포함하여 파일 이름을 지정합니다.

    Office 365 홈 페이지의 페이지 로드에 대한 네트워크 탭을 보여 주는 HTTPWatch

    이 스크린샷은 HTTPWatch Professional 버전입니다. Professional 버전이 설치된 컴퓨터에서는 Basic 버전으로 수집한 추적을 열고 읽을 수 있습니다. 이 방법으로 추적에서 추가 정보를 사용할 수 있습니다.

문제 단계 레코더

단계 레코더(PSR.exe)를 사용하면 발생하는 문제를 그대로 기록할 수 있습니다. 이 도구는 매우 유용하며 간편하게 실행할 수 있습니다.

문제 단계 레코더 (PSR.exe) 작업을 녹음 하 실행

  1. 시작 > 실행을 클릭한 다음 PSR.exe를 입력하고 확인을 클릭하거나 Windows 키를 클릭하고 PSR.exe를 입력한 다음 Enter 키를 누릅니다.

  2. 작은 PSR.exe 창이 나타나면 녹화 시작을 클릭하고 성능 문제가 발생하는 단계를 재현합니다.

    설명 추가 클릭 하 여 필요에 따라 메모를 추가할 수 있습니다.

  3. 단계를 완료 하면 레코드 중지 를 클릭 합니다. 성능 문제는 페이지 렌더링, 녹음/녹화를 중지 하기 전에 렌더링 페이지 기다립니다.

  4. 저장을 클릭합니다.

단계 레코더 또는 PSR.exe 스크린샷

날짜 및 시간을 기록 됩니다. 이 시간 내에 Netmon 추적 및 HTTPWatch에 프로그램 PSR를 연결 하 고 정밀도 문제를 해결 하는 데 도움이 됩니다. 날짜 및 시간 PSR 레코드에서 몇 분 전달 표시할 수 로그인 하 고 예를 들어 URL 및 관리자 사이트의 부분 렌더링 브라우징 사이입니다.

추적 해석

하나의 문서를 통해 필요한 네트워크 및 성능 문제 해결에 대한 모든 내용을 교육하는 것은 불가능합니다. 양호한 성능을 유지하려면 네트워크가 어떻게 작동하고 일반적으로 어떤 성능을 제공하는지에 대한 경험과 지식이 필요합니다. 하지만 가장 중요한 문제를 요약해서 정리하고 도구를 사용하여 가장 일반적인 문제를 손쉽게 해결하는 방법은 보여줄 수 있습니다.

Office 365 사이트에 대 한 네트워크 추적 읽기 능력을 선택할 수 있도록 하려는 경우에 정기적으로 페이지 로드의 추적 만들고 충분히 경험 읽기 보다 더 나은 없는 교사. 예를 들어 가능성이 있는 경우 Office 365 서비스를 로드 하 고 프로세스를 추적 합니다. DNS 트래픽에 대 한 추적 필터링 하거나 찾은 서비스의 이름에 대 한 FrameData를 검색 합니다. 서비스를 로드할 때 발생 하는 단계에 대 한 개념을 파악 하 여 추적을 검사 합니다. 이렇게 하면 어떤 기본 자세한 페이지 로드 같습니다 고 성능, 주위 특히 문제 해결의 경우 적절 하 게 잘못 된 추적 비교 수 알려 많은 합니다.

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

IntelliSense를 사용하는 표시 필터 필드를 보여 주는 Netmon 스크린샷

Netmon 추적 트래픽 많은를 가질 수 있습니다. 읽기 경험이 많은 하지 않은 경우 처음으로 추적을 열고 무력화 될 됩니다. 가장 먼저 할 일은 추적에서 배경 소음에서 신호를 구분 합니다. Office 365에 대 한 테스트 하 고 보려는 트래픽을입니다. 탐색을 통해 추적을 사용 하는 경우이 목록이 아닌 할 수 있습니다.

클라이언트와 Office 365 간 트래픽은 TLS를 통해 이동합니다. 즉, 트래픽 본문이 암호화되고 일반 Netmon 추적으로 읽을 수 없습니다. 성능 분석 시 패킷에 포함된 구체적 정보는 확인할 필요가 없습니다. 히지만, 패킷 헤더와 그 안에 포함된 정보는 매우 유용합니다.

좋은 추적을 얻는 팁

  • 클라이언트 컴퓨터의 IPv4 또는 IPv6 값을 알아야 합니다. 이 정보는 명령 프롬프트에 IPConfig를 입력하고 Enter 키를 눌러 확인할 수 있습니다. 이 주소를 알면 추적에 포함된 트래픽이 클라이언트 컴퓨터와 직접 관련되어 있는지 여부를 확인할 수 있습니다. 알려진 프록시가 있는 경우, ping을 실행하여 IP 주소도 함께 확인합니다.

  • DNS 확인자 캐시를 지우고, 가능한 경우 테스트를 실행 중인 브라우저를 제외한 모든 브라우저를 닫습니다. 지원 팀에서 브라우저 기반 도구를 사용하여 클라이언트 컴퓨터의 데스크톱을 보는 경우와 같이 이렇게 할 수 없는 경우에는 추적을 필터링할 준비를 합니다.

  • 다른 용무 중 추적에서 사용 중인 Office 365 서비스를 찾습니다. 적이 없거나 거의 하였습니다 하기 전에 트래픽을,이 성능 문제를 구분 하 여 다른 네트워크 노이즈에서의 유용한 단계입니다. 몇 가지 방법으로이 작업을 수행 합니다. 테스트를 바로 앞 ping 또는 (ping outlook.office365.com 및/또는 psping -4 microsoft-my.sharepoint.com:443, 예) 특정 서비스의 URL로 PsPing을 사용할 수 있습니다. 또한 쉽게 찾을 수 이름 사용 하 여 해당 프로세스 Netmon 추적에서 해당 PsPing 합니다. 찾고 시작 위치를 제공 합니다.

    문제가 발생할 당시 Netmon 추적만 사용하고 있었던 경우에도 문제는 없습니다. 직접 익숙해지는 연습을 하려면 ContainsBin(FrameData, ASCII, "office") 또는 ContainsBin(FrameData, ASCII, "outlook") 등의 필터를 사용합니다. 추적 파일에서 프레임 번호를 기록할 수 있습니다. 프레임 요약 창을 오른쪽 끝까지 스크롤하여 대화 ID 열을 찾을 수도 있습니다. 이러한 특정 대화의 ID를 나타내는 번호를 기록해 두면 나중에 분리하여 확인할 수 있습니다. 다른 필터링을 적용하기 전에 이 필터를 반드시 제거해야 합니다.

    팁: Netmon에는 여러 개의 유용한 필터가 기본 제공됩니다. 표시 필터 창의 위쪽에 있는 "필터 로드" 단추를 사용해 보세요.

    클라이언트 컴퓨터의 명령줄에서 PSPing을 사용하여 IP 찾기

    TCP.Flags.Syn == 1 필터를 통해 PSPing 명령과 동일한 결과를 보여 주는 클라이언트의 Netmon 추적

    트래픽에 대해 알아보고 필요한 정보를 찾는 방법을 배웁니다. 예를 들어, 추적의 어떤 패킷이 사용 중인 Office 365 서비스(예: "Outlook")를 가장 먼저 참조하는지 확인하는 방법을 익힙니다.

예로 들어, Office 365 Outlook Online의 트래픽은 다음과 유사한 방식으로 시작됩니다.

  • outlook.office365.com에 대해 일치하는 QueryID가 있는 DNS 표준 쿼리 및 DNS 응답. 반환 시간 오프셋과 Office 365 Global DNS가 이름 확인을 위해 요청을 보내는 위치를 확인하는 것이 중요합니다. 지구 반대편보다는 가능한 현재 있는 위치가 좋습니다. 이 다음에 온라인 로그인의 DNS 트래픽이 올 수 있습니다.

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

  • RWS 연결 요청 및 연결 응답이 포함된 RWS 트래픽. 이 트래픽은 자동으로 연결을 구축하는 원격 Winsock입니다.

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

  • TLS 핸드셰이크 및 TLS 인증서 변환이 이루어지는 일련의 TLS:TLS 트래픽. 데이터는 SSL/TLS를 통해 암호화됩니다.

트래픽의 모든 부분이 중요하고 관련되어 있지만, 추적의 작은 부분에 성능 문제 해결과 관련된 특히 중요한 정보가 포함되어 있으므로 이 영역에 집중해야 합니다. 또한, 지금까지 가장 일반적인 주요 10개 문제 목록을 요약하기 위해 Microsoft에서 Office 365 성능 문제에 대해 충분히 다루었으므로 도구를 사용하여 이러한 문제를 완전히 제거하는 방법을 자세히 살펴보겠습니다.

아직 도구를 설치하지 않은 경우 아래 매트릭스에서 여러 도구를 참조할 수 있습니다. 가능한 경우, 설치 지점에 대한 링크가 제공됩니다. 이 목록에는 NetmonWireshark와 같은 일반적인 네트워크 추적 도구가 포함되어 있지만, 잘 알고 있으며 네트워크 트래픽 필터링에 익숙한 추적 도구를 사용해도 됩니다. 테스트 시에는 다음 사항에 유의합니다.

  • 브라우저를 닫고 테스트 하 여 실행 중인 브라우저를 하나만 -이렇게 하면 캡처한 전체 트래픽을 줄일 수 있습니다. 도 낮은 추적에 대 한 은합니다.

  • 클라이언트 컴퓨터에서 DNS 확인자 캐시를 지웁니다. - 이렇게 하면 깨끗한 상태로 캡처를 시작하여 더 정돈된 추적을 얻을 수 있습니다.

몇 가지 주요 문제

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

주요 문제

도구

찾을 항목

TCP 창 크기 조정

  • SYN - SYN/ACK에서 찾을 수 있습니다.

  • 기존 또는 오래된 하드웨어는 TCP 창 크기 조정을 활용하지 못할 수 있습니다.

  • 적절한 TCP 창 크기 조정 설정이 없으면 TCP 헤더의 기본 16비트 버퍼가 밀리초 단위로 채워집니다.

  • 클라이언트에서 원본 데이터 수신 확인을 받을 때까지 트래픽을 계속 전송할 수 없으므로 지연이 발생합니다.

Netmon

Wireshark

네트워크 추적에서 SYN - SYN/ACK 트래픽을 찾습니다.

Netmon에서 tcp.flags.syn == 1같은 필터를 사용 합니다. 이 필터는 Wireshark에서 동일 합니다.

Netmon 또는 Wireshark에서 Syn 패킷에 대해 TCP.Flags.Syn == 1로 필터링

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

네트워크 연결에서 사용하는 창 크기 조정 값을 확인하려면 첫 번째 SYN을 확장한 다음 관련 SYN/ACK를 확장합니다.

시간 간격을 가져오기 위해 추적에서 SrcPort를 DstPort와 일치시키는 방법을 보여 주는 그래픽

TCP 유휴 시간 설정

  • 대부분의 경계 네트워크는 임시 연결을 위해 구성되므로 유휴 연결은 일반적으로 종료됩니다.

  • 100~300초보다 긴 유휴 TCP 세션은 프록시 및 방화벽에 의해 종료될 수 있습니다.

  • Outlook Online의 경우 유휴 여부와 상관없이 장시간 연결을 만들고 사용하므로 문제가 발생할 수 잇습니다.

  • 프록시 또는 방화벽 장치에 의해 연결이 종료된 경우에도 클라이언트는 알림을 받지 못하므로 Outlook Online을 사용하려고 시도할 경우 클라이언트 컴퓨터는 새 연결을 만들기 전에 반복적으로 연결을 회복하려고 시도합니다.

  • 페이지 로드 시 제품이나 프롬프트가 응답하지 않거나 성능이 느려질 수 있습니다.

Netmon

Wireshark

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

예를 들어, Netmon의 필터 .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12같은 또는 ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12Wireshark에 표시 될 수 있습니다.

팁: 

  • 추적의 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 공식 사이트Pingtest 사이트(또는 유사 사이트)를 사용해 보세요.

Ping

PsPing

Netmon

Wireshark

추적에서 지연 시간을 추적할 경우 클라이언트 컴퓨터 IP 주소와 Office 365의 DNS 서버 IP 주소를 기록해 두면 도움이 됩니다. 이렇게 하면 추적 필터링을 손쉽게 수행할 수 있습니다. 프록시를 통해 연결할 경우 클라이언트 컴퓨터 IP 주소, 프록시/송신 주소, Office 365 DNS IP 주소가 있으면 작업을 손쉽게 수행할 수 있습니다.

outlook.office365.com으로 ping 요청을 보내면 요청을 수신한 데이터 센터의 이름을 확인할 수 있으며, ping을 통해 연결해서 연속 ICMP 패킷을 보낼 수 없는 경우에도 마찬가지입니다. PsPing(무료 다운로드 도구)과 특정 포트(443) 또는 IPv4(-4)를 사용할 경우 전송된 패킷의 평균 왕복 시간을 확인할 수 있습니다. 이 방법은 psping -4 yourSite.sharepoint.com:443과 같이 Office 365 서비스의 다른 URL에도 사용할 수 있습니다. 실제로, 많은 ping을 지정해서 더 큰 샘플로 평균값을 얻을 수 있습니다. psping -4 -n 20 yourSite-my.sharepoint.com:443을 시도해 보세요.

참고: PsPing은 ICMP 패킷을 전송하지 않습니다. PsPing은 특정 포트에서 TCP 패킷으로 ping을 수행하므로 열린 상태로 확인된 모든 포트를 사용할 수 있습니다. SSL/TLS를 사용하는 Office 365의 경우 PsPing에 포트 :443을 추가해 보세요.

outlook.office365.com을 확인하는 Ping과 6.5ms의 평균 RTT를 보고하는 포트 443을 사용하여 동일한 작업을 수행한 PSPing을 보여 주는 스크린샷

네트워크 추적 중 느린 성능의 Office 365 페이지를 로드한 경우, Netmon 또는 Wireshark 추적을 필터링하여 DNS를 확인해야 합니다. 이 IP가 우리가 찾고 있는 IP 중 하나입니다.

IP 주소와 DNS 지연 시간을 확인하기 위해 Netmon을 필터링하는 단계는 다음과 같습니다. 이 예제에서는 outlook.office365.com을 사용하지만, SharePoint Online 테넌트의 URL(hithere.sharepoint.com)을 사용할 수도 있습니다.

  1. URL ping outlook.office365.com에 대해 ping을 실행하고, 그 결과에서 ping 요청이 전송된 DNS 서버의 이름과 IP 주소를 기록합니다.

    namnorthwest의 DNS 및 IP 주소를 보여 주는 outlook.office365.com에 대한 Ping 요청

  2. 네트워크 추적 하는 페이지를 열 또는 성능 문제를 제공 하는 작업을 수행 하 또는, 네트워크 추적 하기 지연 시간이 긴 ping 자체에 표시 됩니다.

  3. Netmon에서 추적을 열고 DNS를 필터링합니다. 이 필터는 Wireshark에서도 작동하지만 대소문자를 구분합니다(dns). ping을 통해 DNS 서버의 이름을 확인했으므로 Netmon에서 DNS AND ContainsBin(FrameData, ASCII, "namnorthwest")를 사용하여 더 빠르게 필터링할 수 있습니다. Wireshark에서는 dns and frame contains "namnorthwest"를 사용합니다.

    응답 패킷을 열고 Netmon의 '프레임 세부 정보' 창에서 DNS를 클릭하여 확장하면 자세한 정보가 표시됩니다. DNS 정보에서 Office 365에서 요청이 전송된 DNS의 IP 주소를 확인할 수 있습니다. 이 IP 주소는 다음 단계(PsPing 도구)에 필요합니다. 필터를 제거하고 Netmon의 '프레임 요약' > '대화 찾기' > 'DNS'에서 DNS 응답을 마우스 오른쪽 단추로 클릭하면 DNS 쿼리와 응답이 나란히 표시됩니다.

    대화 찾기 > DNS로 필터링된 추적

  4. Netmon에서 DNS 요청과 응답 사이의 시간 오프셋 열도 기록합니다.

    요청과 응답 간에 매우 낮은 시간 오프셋을 보여 주는 DNS AND CONTAINSBIN(Framedata, ASCII, "namnorthwest")로 필터링된 추가 Netmon 결과

다음 단계에서 간단한 설치 및 사용 PsPing 도구 제공 매우 유용한, ICMP 자주 방화벽에서 차단 된와 PsPing 세련 되 대기 시간 (밀리초)을 추적 합니다. PsPing 주소 및 포트 (우리 대/소문자에 열려 있는 포트 443)에 대 한 TCP 연결을 완료합니다.

  1. PsPing을 설치합니다.

  2. 명령 프롬프트를 열고(시작 > 실행 > cmd 입력, 또는 Windows 키 > cmd 입력) PsPing이 설치된 디럭터리로 이동하여 PsPing 명령을 실행합니다. 이 예제에서는 루트 C에 'Perf' 폴더를 만든 것을 확인할 수 있습니다. 바로 가기에 대해서도 같은 작업을 수행할 수 있습니다.

  3. 이전 Netmon 추적에서 확인한 Office 365 DNS 서버의 IP 주소에 대해 PsPing을 실행하는 명령을 입력합니다. 포트 번호를 추가하는 것을 잊지 마세요. 즉, psping -n 20 132.245.24.82:445를 입력합니다. PsPing이 중지되면 20개 ping의 샘플링과 평균 지연 시간을 확인할 수 있습니다.

    25.51ms의 평균 대기 시간을 반환하는 PSPing 명령(psping -n 20 132.245.24.82:443)

프록시 서버를 통해 Office 365에 연결하는 경우에는 단계가 약간 다릅니다. 가장 먼저 프록시 서버에 대해 PsPing을 수행하여 프록시/송신 지점까지의 왕복 지연 시간 값(밀리초)을 얻은 다음, 프록시 또는 인터넷에 직접 연결된 컴퓨터에서 PsPing을 실행하여 누락된 값을 가져옵니다(Office 365까지의 왕복 시간).

프록시에서 PsPing을 실행할 경우 클라이언트 컴퓨터에서 프록시 서버 또는 송신 지점까지의 밀리초 값과 프록시 서버에서 Office 365까지의 밀리초 값 두 개가 반환됩니다. 이제 작업을 완료했으며 값을 기록합니다.

인터넷에 직접 연결 되어 있는 다른 클라이언트 컴퓨터에서 PsPing을 실행 하는 경우, 즉 프록시, 없이 주어 두 밀리초 값: 프록시 서버 또는 송신 지점와 Office 365에 클라이언트 컴퓨터에 클라이언트 컴퓨터가 합니다. 이 경우 Office 365에 클라이언트 컴퓨터의 값에서 프록시 서버 또는 송신 지점에 클라이언트 컴퓨터의 값을 뺍니다 및 해야 RTT 숫자 클라이언트 컴퓨터에서 프록시 서버 또는 송신 지점에서 프록시 서버 또는 송신 지점 및에 ce 365 합니다.

하지만, 직접 연결되거나 프록시를 우회하는 위치에 클라이언트 컴퓨터가 있을 경우 해당 위치에서 재현된 문제부터 시작해서 테스트할 것인지 선택할 수 있습니다.

대기 시간을 Netmon 추적에서 살펴보았듯이 몇 밀리초 추가할 수를 경우 심각 해질 하 든 특정된 세션에 있습니다.

프레임 요약에 Netmon 기본 시간 간격 열이 추가되어 있는 Netmon의 일반 대기 시간

참고: 사용자의 IP 주소는 위 화면의 IP 주소와 다를 수 있지만, ping을 실행할 경우 157.56.0.0/16 또는 이와 유사한 범위가 반환될 수 있습니다. Office 365에서 사용하는 범위 목록은 Office 365 URL 및 IP 주소 범위를 참조하세요. 예를 들어 132.245를 검색하려는 경우 맨 위에 있는 단추를 눌러 모든 노드를 확장합니다.

프록시 인증

  • 프록시 인증은 프록시 서버를 통해 연결할 경우에만 적용됩니다. 그렇지 않은 경우 이 단계를 건너뛸 수 있습니다.

  • 정상적으로 작동할 경우 프록시 인증은 일관적으로 수 밀리초 이내에 수행되어야 합니다. 예를 들어 피크 사용 기간 동안 간헐적으로 나쁜 성능이 나타나지 않아야 합니다.

  • 프록시 인증이 설정된 경우 정보를 얻기 위해 Office 365에 대해 새로운 TCP 연결을 만들 때마다 이면에서 인증 프로세스를 거쳐야 합니다. 예를 들어 Outlook Online에서 일정에서 메일로 전환할 경우 인증이 수행됩니다. SharePoint Online의 페이지에 여러 사이트 또는 위치의 미디어 또는 데이터가 표시될 경우 데이터를 렌더링하는 데 필요한 각각의 다른 TCP 연결에 대해 인증이 수행됩니다.

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

    프록시 인증 송신 프록시 서버 설정입니다. Office 365와 함께 성능 문제를 일으키는 것을 네트워킹 팀에 문의 해야 합니다.

Netmon

Wireshark

프록시 인증 되려면 새 TCP 세션은 서버에서 파일이 나 정보를 요청 하는 일반적으로 사용 하거나 정보를 제공 하기 위해 위, 된 해야 때마다 배치 합니다. 예를 들어 HTTP GET 또는 HTTP POST 요청 주위 프록시 인증을 볼 수 있습니다. 추적에서 요청을 인증 된 프레임을 표시 하려는 경우 ' NTLMSSP 요약 ' 열 Netmon 및 .property.NTLMSSPSummary에 대 한 필터에 추가 합니다. 기간 인증 하는 데을 확인 하려면 시간 간격 열을 추가 합니다. Netmon에 열 추가:

  1. 설명 등의 열을 마우스 오른쪽 단추로 클릭합니다.

  2. 열 선택을 클릭합니다. 목록에서 'NTLMSSP 요약 및 시간 간격'을 찾고 추가를 클릭합니다.

  3. 새 열과 설명 열을 나란히 읽을 수 있도록 새 열을 설명 열의 앞 또는 뒤로 이동합니다. 확인을 클릭합니다.

열을 추가 하는 경우에 Netmon 필터가 작동 합니다. 하지만 문제 해결에 있는 인증 단계를 볼 수 하는 경우 훨씬 더 쉽게 됩니다. 때 프록시 인증 인스턴스 NTLM 챌린지가 아니면 인증 메시지 모든 프레임을 연구 해야을 찾는 표시 됩니다. 필요한 경우 트래픽과 찾기 대화의 특정 부분을 마우스 오른쪽 단추로 > TCP 합니다. 이러한 대화에서 시간 간격 값에 유의 합니다.

프록시 인증을 보여 주는 대화로 필터링된 Netmon 추적

아래 Wireshark에서 볼 수 있듯이 프록시 인증에 4초의 지연이 발생했습니다. 이전에 표시된 프레임과의 시간 간격 열은 '프레임 세부 정보'에서 동일한 이름의 필드를 마우스 오른쪽 단추로 클릭하고 '열로 추가'를 선택하여 만듭니다.

Wireshark에서 ‘이전에 표시된 프레임과의 시간 간격 열’은 프레임 세부 정보에서 동일한 이름의 필드를 마우스 오른쪽 단추로 클릭하고 ‘열로 추가’를 선택하여 만들 수 있습니다.

DNS 성능

  • 이름 확인은 클라이언트가 있는 국가와 가능한 가까운 위치에서 실행할 때 가장 빠르고 정확하게 실행됩니다.

  • 해외에서 DNS 이름 확인을 수행할 경우 페이지 로드에 몇 초가 더 소요될 수 있습니다.

  • 이름 확인은 100ms 이내에 수행되어야 합니다. 그렇지 않을 경우 추가 조사기 필요합니다.

팁: Office 365에서 클라이언트 연결이 어떻게 작동하는지 잘 모르시나요? 여기에서 클라이언트 연결 참조 문서를 참조하세요.

Netmon

Wireshark

PsPing

DNS 성능 분석은 일반적으로 네트워크 추적 시 추가적으로 필요한 작업입니다. 하지만, PsPing도 가능한 원인을 포함하거나 배제하는 데 유용합니다.

DNS 트래픽은 TCP 및 UDP 요청을 기준으로 하며 응답에는 특정 요청과 해당 특정 응답을 일치시키는 ID가 명확히 표시됩니다. 예를 들어, SharePoint Online이 네트워크 이름 또는 웹 페이지의 URL을 사용하는 경우 DNS 트래픽을 확인할 수 있습니다. 대체로, 다른 구역으로 전송할 경우를 제외하고 이 중 대부분의 트래픽은 UDP에서 실행됩니다.

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

Netmon의 DNS에 대한 기본 필터는 DNS입니다.

여기 오프셋 시간을 확인 하려고 합니다. 작업과 Netmon 다음이 단계를 완료 하 여 수행할 수 있는 시간 간격 열을 추가 하는 데 도움이 될 수 있습니다.

  1. 설명과 같은 열을 마우스 오른쪽 단추로 클릭합니다.

  2. 열 선택을 클릭합니다.

  3. 목록에서 시간 간격을 찾고 추가를 클릭합니다.

  4. 새 열과 설명 열을 나란히 읽을 수 있도록 새 열을 설명 열의 앞 또는 뒤로 이동합니다. 확인을 클릭합니다.

관심 있는 쿼리를 찾을 것이 좋습니다 대화 찾기 선택 프레임 세부 정보 창에서 쿼리를 마우스 오른쪽 단추로 클릭 하 여 격리 > DNS 입니다. 네트워크 대화 창 오른쪽의 UDP 트래픽 로그에서 특정 대화에 점프 알 수 있습니다.

DNS에 의해 필터링되고 대화 찾기 > DNS를 사용하여 결과 범위를 좁힌 Outlook Online 로드의 Netmon 추적

Wireshark에서 DNS 시간에 대 한 열을 만들 수 있습니다. 추적 (걸리거나 추적을 열고) Wireshark 및 dns또는 기타 끌기만 dns.time로 필터링 합니다. 모든 DNS 쿼리를 클릭 하 고 세부 정보를 보여 주는 패널에서 Domain Name System (response) 세부 정보를 확장 합니다. 시간 (예: [Time: 0.001111100 seconds]필드를 확인할 수 있습니다. 이 시간을 마우스 오른쪽 단추로 클릭 하 고 열으로 적용 을 선택 합니다. 이렇게 하면 시간 열 추적 빠른 정렬 합니다. 해결 하기 위해 가장 긴 데 사용 했던 보려면 DNS를 호출 하는 값을 내림차순으로 정렬 하려면 새 열을 클릭 합니다.

세부 정보의 시간이 열로 만들어지고 오름차순으로 정렬된 Wireshark에서 dns.time(소문자)으로 필터링된 SharePoint Online 탐색

DNS 해결 시간에 대 한 자세한 조사를 수행 하려는 경우 (예: psping <IP address of DNS server>:53) TCP에서 사용 되는 DNS 포트에 대해 PsPing을 실행 합니다. 여전히 표시 되어 성능 문제가 있나요? 수행 하지 않으면 문제는 할 일 해상도 달성 중인 DNS 응용 프로그램 특정 문제 보다 광범위 한 네트워크 문제 될 가능성이 높습니다. 또한 설명이, 다시는 ping outlook.office365.com 알 수 있는 Outlook Online에 대 한 DNS 이름 확인 하는 데 위치 (예: outlook-namnorthwest.office365.com)입니다.

DNS 관련 문제로 보이는 경우 IT 부서에 DNS 구성 및 DNS 전달자를 살펴보도록 문의하여 문제를 추가적으로 조사해야 합니다.

프록시 확장성

  • Office 365의 Outlook Online 등의 서비스에서는 클라이언트가 다수의 장시간 연결을 사용할 수 있도록 허용합니다.

  • 이에 따라 각 사용자가 장시간을 요구하는 연결을 더 많이 사용할 수 있습니다.

팁: Office 365에 많은 사용자를 추가할 예정이어서 대역폭 사용량을 계획해야 하나요? Office 365을 위한 인터넷 대역폭 사용량 계획을 시도해 보세요. 여기에서 대역폭 계산기를 사용할 수 있습니다.

수학

수학에 관련된 전용 네트워크 추적 또는 문제 해결 도구는 없습니다. 대신, 제한 사항 및 기타 변수 기준의 대역폭 계산을 기준으로 합니다.

TCP 최대 세그먼트 크기

  • SYN - SYN/ACK에서 찾을 수 있습니다.

  • 성능 네트워크 추적을 실행하면 항상 TCP 패킷이 가능한 최대 양의 데이터를 전송할 수 있도록 구성되었는지 확인합니다.

  • 목표는 데이터 전송 시 1460바이트의 MSS를 확인하는 것입니다.

  • 프록시가 있는 경우 또는 NAT를 사용하는 경우 최선의 결과를 위해 클라이언트에서 프록시/송신 지점/NAT로, 그리고 프록시/송신 지점/NAT에서 Office 365로 이 테스트를 실행합니다. 모두 다른 TCP 세션입니다.

Netmon

TCP 최대 세그먼트 크기 (MSS) SYN-SYN/ACK 패킷의에서 필요한 데이터를 찾을 수 있습니다를 의미 하 여 네트워크 추적의 세 가지 핸드셰이크의 다른 매개 변수입니다. MSS 실제로 방법은 매우 간단 하 게 표시 됩니다.

현재 성능 네트워크 추적을 열고 궁금하거나 성능 문제가 있는 연결을 검색합니다.

참고 사항: 

  • 추적을 확인하면서 대화와 관련된 트래픽을 검색해야 하는 경우, 클라이언트 IP 또는 프록시 서버/송신 지점의 IP 또는 두 IP 모두를 기준으로 필터링합니다. 즉, 추적에서 Office 365의 IP 주소를 테스트하는 경우 URL에 대해 ping을 수행하고 해당 IP 주소를 기준으로 필터링해야 합니다.

  • 중 추적을 보고? 사용자가 직접 방향을 지정 하려면 필터를 사용해 보세요. Containsbin(framedata, ascii, "sphybridExample")같은 URL을 기준으로 검색을 실행 Netmon에서 다음 사항을 프레임 번호입니다. Wireshark에서 다음과 같이 frame contains "sphybridExample"를 사용 합니다. 원격 Winsock (RWS) 트래픽을 (으로 표시 된 [PSH, ACK] Wireshark에서)를 찾은 발견 되 면 기억 RWS 연결 앞서 설명한 것 처럼 관련 SYN-SYN/Ack 직전 볼 수 있습니다. 현재 시점에 있습니다 수 프레임 번호를 기록, 필터를 가장 가까운 SYN. 살펴보려면 Netmon에서 네트워크 대화 ' 창에서 모든 트래픽이 클릭

  • 중요한 점은 추적 시 IP 주소 정보를 받지 못한 경우 추적에서 자신의 URL(예: sphybridExample-my.sharepoint.com의 일부)을 찾으면 필터링 기준으로 사용할 수 있는 IP 주소를 확인할 수 있다는 점입니다.

  1. 추적에서 확인하려는 연결을 찾습니다. 이렇게 하려면 IP 주소를 기준으로 필터링하거나 Netmon의 '네트워크 대화' 창에서 특정 '대화 ID'를 선택하여 추적을 검사합니다.

    대화별로 필터링. SYN 프레임을 마우스 오른쪽 단추로 클릭하고 대화 찾기, TCP를 클릭합니다.

  2. SYN 패킷을 찾았으면 Netmon에서 TCP를 확장합니다. Wireshark의 경우 '프레임 세부 정보' 패널에서 Transmission Control Protocol을 확장합니다.

  3. TCP 옵션 및 MaxSegementSize를 확장합니다.

  4. 관련 SYN-ACK 프레임을 찾고 TCP 옵션 및 MaxSegmentSize를 확장합니다.

  5. 둘 중 작은 값이 최대 세그먼트 크기입니다.

이 그림은 TCP 문제 해결 라는 Netmon에서 기본 제공 열을 사용 하 여 확인 합니다.

Netmon에서 기본 제공 열을 사용하여 필터링된 네트워크 추적

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

TCP 문제 해결 옵션이 있는 열 드롭다운의 위치(프레임 요약 창 상단)

Wireshark에서 필터링 된 추적 다음과 같습니다. 필터는 MSS 값 (tcp.options.mss) 관련이 있습니다. SYN, SYN/ACK, ACK 핸드셰이크 프레임 아래쪽 프레임 세부 정보에 해당 하는 Wireshark에 연결 된 (47 ACK, 46 SYN/ACK에 대 한 링크, 43 SYN에 대 한 링크에 따라서 프레임) 이러한 종류의 작업을 쉽게 수행할 수 있도록 합니다.

Wireshark에서 MSS(최대 세그먼트 크기)에 대해 tcp.options.mss로 필터링된 추적

선별적 확인(이 매트릭스의 다음 항목)를 검사해야 하는 경우 추적을 닫지 마세요.

선별적 확인

  • SYN - SYN/ACK에서 찾을 수 있습니다.

  • SYN 및 SYN/ACK 모두에서 '허용됨'으로 보고되어야 합니다.

  • SACK(선별적 확인)를 통해 하나 이상의 패킷이 누락된 경우에도 데이터를 원활하게 재전송할 수 있습니다.

  • 장치에서 이 기능을 사용하지 않도록 설정할 수 있지만, 그럴 경우 성능 문제가 발생할 수 있습니다.

  • 프록시가 있는 경우 또는 NAT를 사용하는 경우 최선의 결과를 위해 클라이언트에서 프록시/송신 지점/NAT로, 그리고 프록시/송신 지점/NAT에서 Office 365로 이 테스트를 실행합니다. 모두 다른 TCP 세션입니다.

Netmon

SACK(선별적 확인)는 SYN-SYN/ACK 핸드셰이크의 또 다른 매개 변수입니다. SYN - SYN/ACK에 대한 추적을 다양한 방법으로 필터링할 수 있습니다.

  1. 추적을 검사하거나, IP 주소를 기준으로 필터링하거나, Netmon의 '네트워크 대화' 창에서 '대화 ID'를 클릭하여 추적에서 확인하려는 연결을 찾습니다.

  2. SYN 패킷에 찾았으면 Netmon의 TCP 또는 Wireshark 프레임 세부 정보 섹션에서에서 전송 제어 프로토콜을 확장 합니다.

  3. TCP 옵션 및 SACK를 차례로 확장합니다.

  4. 관련 SYN-ACK 프레임을 찾고 TCP 옵션 및 해당 SACK 필드를 확장합니다.

  5. SYN 및 SYN/ACK 모두에서 SACK가 허용되었는지 확인합니다.

다음은 Netmon 및 Wireshark에 표시된 SACK 값입니다.

Netmon에서 tcp.flags.syn == 1의 결과인 SACK(Selective Acknowledgment)

tcp.flags.syn == 1 필터가 적용된 Wireshark에 표시된 SACK

DNS 지리적 위치

  • 전 세계 어디에 있는 Office 365에서 DNS 요청을 확인하는가에 따라 연결 속도가 달라집니다.

  • Outlook Online에서는 첫 번째 DNS 조회가 완료된 다음 해당 DNS의 위치를 사용하여 가장 가까운 데이터 센터에 연결합니다. 사용자는 Outlook Online CAS 서버로 연결되며, 이 서버는 백본 네트워크를 사용하여 사용자의 데이터가 저장된 DC(데이터 센터)로 연결합니다. 이렇게 하면 시간이 단축됩니다.

  • 해외 여행 중인 사용자가 SharePoint Online에 액세스할 경우 해당 활성 데이터 센터로 연결됩니다. 활성 데이터 센터란 SPO 테넌트의 홈 베이스를 기준으로 하는 위치의 dC를 말합니다(즉, 사용자가 미국 기준인 경우 미국 내 dC).

  • Lync Online에는 동시에 둘 이상의 dC의 활성 노드가 있습니다. Lync Online 인스턴스에 대한 요청을 보내면 Microsoft DNS에서 요청을 전송한 위치를 확인하고 가장 가까운 지역에서 Lync Online이 활성 상태인 dC의 IP 주소를 반환합니다.

팁: 클라이언트가 Office 365에 연결되는 방식에 대해 자세히 알아야 하는 경우 클라이언트 연결 참조 문서(및 유용한 그래픽)를 참조하세요.

Ping

PsPing

Microsoft DNS 서버는 클라이언트 DNS 서버의 이름 확인에 대 한 요청 (dC) 지역 데이터 센터의 IP 주소를 반환 하는 Microsoft DNS 대부분의 경우 레이블과에서 해야 합니다. 하면 영향이 있나요? 사용자 본사가 방갈로 르, 인도 하는 브라우저 Outlook Online에 대 한 요청 하면 미국, 출장 중인 경우 Microsoft DNS 서버 해야 하면 IP 주소를 전달할 미국-지역 데이터 센터에서에서 데이터 센터. Outlook에서 메일이 필요한 경우 해당 데이터는 서로 다른 Microsoft의 빠른 백본에 네트워크를 통해 데이터 센터입니다.

DNS는 사용자 위치와 가장 가까운 곳에서 이름 확인이 실행될 때 가장 빠르게 작동합니다. 유럽에 있는 사용자가 유럽 내 Microsoft DNS를 이용하려는 경우 유럽 내 데이터 센터로 처리하는 것이 가장 좋습니다. 유럽에 있는 클라이언트가 미국에 있는 DNS 및 데이터 센터를 이용하면 성능이 느려집니다.

DNS 요청이 세계 어느 위치로 라우팅되는지 확인하려면 outlook.office365.com에 대해 Ping 도구를 실행합니다. 유럽에 있는 경우 outlook-emeawest.office365.com 등의 응답이 표시됩니다. 미국에 있는 경우 outlook-namnorthwest.office365.com 등의 응답이 표시될 수 있습니다.

  1. 클라이언트 컴퓨터에서 명령 프롬프트를 엽니다(시작 > 실행 > cmd 또는 Windows 키 > cmd 입력).

  2. ping outlook.office365.com을 입력하고 Enter 키를 누릅니다.

    IPv4 통해 ping을 지정 하려면 -4 를 지정 하려면 저장 합니다. ICMP 패킷을에서 답을 얻을에 실패할 수 있음 있지만 요청 라우팅 되었습니다 DNS 이름이 표시 됩니다.

이 연결의 지연 시간을 확인하려면 ping을 통해 반환된 서버의 IP 주소에 대해 PsPing을 실행합니다.

outlook-namnorthwest로 확인된 outlook.office365.com의 Ping

평균 28ms의 대기 시간을 보여 주는 outlook.office365.com에 대한 Ping이 반환한 IP 주소에 대한 PSPing

Office 365 응용 프로그램 문제 해결

Netmon

HTTPWatch

브라우저의 F12 콘솔

이 네트워크 관련 문서에서는 응용 프로그램 관련 문제 해결에 사용되는 도구에 대해 다루지 않습니다. 그러나 사용할 수 있는 리소스를 이 페이지에서 찾을 수 있습니다.

관련 항목

Office 365 끝점 관리
문제 해결 Office 365 연결

Office 기술 확장
교육 살펴보기
새로운 기능 우선 가져오기
Office Insider 참여

이 정보가 유용한가요?

의견 주셔서 감사합니다!

피드백을 주셔서 감사합니다. Office 지원 에이전트와 연락하는 것이 도움이 될 것 같습니다.

×