[Swift] WWDC21 Analyze HTTP traffic in Instruments

애플에서 추천해주기까지하는 네트워크 트래픽을 검사하는 툴이있어요

https://developer.apple.com/documentation/network/taking_advantage_of_third-party_network_debugging_tools

Apple Developer Documentation

저도 Charles를 쓰는데요 ㅎㅎ

 

Xcode13 부터

이젠! 

자체적으로 만들었고 이것을 이용해서 트래픽을 검사할 수 있다를 소개하는 세션입니다!

 

사용방법은

Product → Profile → Network 에서 사용할 수 있는 기능입니다

분명..

릴리즈 노트를 보면...

시뮬레이터에서 이제 사용할 수 있다면서...ㅠ

베타 3버전에서는 안돼던게 돼는건 맞는데

기록이 되지않습니다... → 나중에.. Xcode13 배포되면 사용해보세요..!

 

세션내용을 번역한거라 어색한 문장이 있을수도 있어요 ㅎㅎ...

 

개요

• On all Apple devices
• Supports HTTP/3, VPN
• Integration on the framework level:
  • Process attribution
  • Cached on-disk requests
  • Networking errors
  • Explores API concepts: URLSession and URLSessionTask

이 Instrument를 사용하면 Apple 네트워킹 스택을 통해 프로그램에서 전송되는 HTTP트래픽을 검사할 수 있습니다.

모든 애플기기에서 작동하며

새로운 HTTP/3프로토콜, VPN을 통해 전송되는 트래픽, URL로딩 시스템을 통과하는 전체 트래픽이 노출됩니다.

(Because of the system integration, it attributes traffic to processes running on it,)
시스템 통합으로 인해 트래픽을 해당 프로세스에서 실행되는 프로세스로 귀속시킵니다? → 프로세스 단위로 추적가능

그리고 Apple네트워킹 프레임워크를 계측하고 있기 때문에 on-disk 캐시 또는 네트워크에러를 발생시키는 요청도 볼 수 있습니다.

이 모든것은 ULRSession과 URLSessionTasks와 같이 익숙한 상위 수준의 API개념의 컨텍스트에서 노출됩니다.

이 도구는 API사용이 네트워크 요청의 수명으로 변환되는 방식을 이해하는데 도움이 됩니다.

 

HTTP instrument UI overview

네트워킹API가 instrument에 어떻게 매핑되서 보여지는지에 대해 알아보겠습니다.

네트워크 템플릿을 사용해서 시스템 트래픽을 기록할때 HTTP트래픽 추적이 계측기에 표시되는 방식입니다

제일위에 있는 HTTP Traffic Instrument는 지정된 시간에 추적에서 실행중인 URLSession task수에 대한 개요를 보여줍니다

앱수명동안 HTTP Traffic활동이 증가한 스팟을 탐지하는데 이상적입니다

 

 

그아래는 프로세스별 활동 내역을 보여줍니다

모든 디버깅 가능 프로세스의 트래픽뿐만 아니라 디버깅이 시작한 백그라운드 트래픽을 검사 할 수 있습니다.

 

 

각 프로세스에는 이 프로세스에서 사용하는 모든 URL세션이 포함되어 있습니다.

그리고 이것은 코드에서 작성하는 URLSession객체에 해당합니다.

이 단계에서 그 그래프는 모든 개별 task 간격을 검사 할 수 있습니다.

 

 

세션개체와 시각화 간에 더 나은 매핑을 얻으려면 sessionDescription프로퍼티를 설정하여 이름을 코드로 지정할 수 있습니다

 

 

전 단계에서, 트래픽이 요청된 도메인에 의해 차단됩니다.(보라색영역)

이 단계의 그래프는 작업과 상태를 구성하는 개별 트랜잭션을 포함하여 task에 대한 상세한 내용을 보여줍니다.

 

 

작업과 트랜잭션이 무엇인지 더 잘이해하기위해 예를 분석해봅시다.

선택한 도메인에서 데이터를 로딩하는 몇가지 작업이 있습니다.

그중 한가지에 초첨에 맞춰 작업의 구조를 분석해봅시다

 

 

이 단일 작업 구간에는 많은 정보가 있습니다.

우리는 API호출이 instruments시각화가 되도록 어떻게 매핑되는지를 이해하기위해 이것을 보다 추상적인 방법으로 나타낼 수 있습니다.

 

 

최상위 단계에서는 task 객체가 있습니다.

task는 하나이상의 트랜잭션으로 구성됩니다.

트랜잭션은 HTTP요청 및 대응하는 응답의 쌍입니다.

 

 

작업 수준(task level)은 코드가 URL 로딩 시스템의 API와 상호작용하는 방식을 나타내는 것입니다.

작업을 작성하고 이에 resume을 call하면 작업구간이 시작됩니다.

그리고 completion 블럭이 호출되기 직전에 종료됩니다.

 

 

각 task에 taskDescription 프로퍼티를 이용해서 의미있는이름을 지정할 수 있고, 이 속성은 instruments구간 라벨로 사용됩니다.

또한 task identifier을 task label의 일부로 표시합니다

이 task를 다른 데이터와 상호참조하는데 사용할 수 있습니다.

 

 

task가 오류로 완료되면, 해당 설명이 간격라벨에 표시되어 디버깅이 쉬워집니다.

앞서 언급했듯이, task는 여러 트랜잭션으로 구성될 수 있습니다.

 

 

예제를 통해서 더 이해해봅시다!

apple.com의 시작페이지를 로드해야하는 작업이 있습니다.

그러나 이 URL은 표준URL이 아니라서 apple.com을 요청하지만 선호하는 도메인은 www.apple.com 입니다.

이 task를 만들때 URL로딩시스템은 처음에 apple.com에 요청을 작성합니다.

짧은시간후 그것은 서버로부터 리다이랙트 응답을 수신했고 선호URL이 실제로 www.apple.com이라는 것을 명시합니다

기본적으로 리다이랙트를 따르므로, 301응답을 반환하는 대신에 선호하는 URL을 로드하는 새로운 트랜잭션을 생성합니다.

이는 두번째 성공적인 트랙잭션응답은 task로 다시 반환되는 것입니다.

 

 

앞서 언급했듯이 트랜잭션은 HTTP요청과 응답의 조합을 나타냅니다.

당신의 task를 처리하기위해 hood아래에서 URLSession이 하는것과 일치하고 요청된 URL과 같은 전송된 데이터에 대한 정보등을 포함합니다.

 

 

task와 마찬가지로 트랜잭션 라벨은 트랜잭션 개요를 알려줍니다.

주로 요청과 응답에대한 정보를 얻습니다.

 

 

트랙 계층 구조는 요청된 도메인을 알려주고 라벨자체에서 경로 및 쿼리를 찾을 수 있습니다.

그외에도 (요청부분)interval라벨은 HTTP버전, HTTP메소드 및 요쳥이 인증 또는 쿠키 헤더를 보냈는지 여부가 표시됩니다.

이런 것들은 종종 한눈에 인증흐름을 이해하는데 유용합니다.

 

응답의 경우 stateCode, 응답에 쿠키가 포함되어 있는지 여부 및 응답content type을 얻습니다.

 

 

요청과 응답이 얼마나 오래 걸렸는지 뿐만아니라 트랜잭션의 일부인 다른 작업에대한 보다 자세한 타이밍 정보는 트랜잭션 상태에 의해 캡처됩니다.

트랜잭션의 시작은 URL로딩시스템이 요청을 하기위한 트랜잭션을 만드는 시점입니다.

먼저 유효한 캐시된 응답이 있는지 확인하고 그리고 만약 그렇지 않다면, 그것은 연결에 대한 요청을 스케줄링 하려고 할 것입니다.

 

 

다음으로 트랜잭션은 차단 상태에서 잠시 기다려야하며 사용 가능한 연결을 기다려야합니다.

 

 

전송요청 상태는 트랜잭션이 연결에 의해 최종처리될 때 시작됩니다.

요청의 마지막 바이트를 네트워크로 전송하면 종료됩니다.

 

 

다음으로 트랜잭션은 응답대기 상태로 이동하고 수신 응답이 뒤따르며 서버에서 수신한 첫번째 바이트에서 마지막 바이트 까지 범위를 추적합니다.

 

 

URL로딩시스템이 이것이 성공적인 응답인지 여부를 결정하면 마지막 바이트가 수신된 직후 전체 트랜잭션이 완료됩니다.

 

 

실제로 get요청에 대한 캐시조회 및 전송상태는 대개 훨씬 짧기 때문에 이렇게 나타날 가능 성이 높습니다.

 

instrument가 성능과 정확성 문제를 해결하는데 어떻게 도움이되는지를 알아봅시다

 

이 도구를 사용하기 좋은 대표적인 예시와 함께 유용한 부분을 보여줍니다!

아래부턴 예시에대한 내용이기때문에 개념만 보고싶다면 윗부분만 보셔도 무방해요

 

 

 

 

(앱을 열면 많은 개이미지를 불러오는 로딩이 끝나는데 꽤 시간이 걸리는걸 알수있다)

이상황을 개선할 수 있도록 새로운 HTTP Traffic instrument로 앱을 프로파일해봅시다

 

 

위와 같이 HTTP Traffic을 클릭하면 전체 트랙계층 구조가 나타나고

 

 

트래픽을 확대를 해서 많은 요청을 볼 수있다.

또한 영역을 드래그해서 지속시간을 표시할 수 있고 전체적으로 몇초 걸렸는지 확인도 할 수 있다.

 

 

처음 몇개의 이미지는 상당히 빠르게 로드됬지만, 아래로 스크롤 하면서 보면 보라색으로 막힌 상태가 증가함에 따라 나중에 시작된 작업은 완료하는데 오래걸린 것을 볼 수 있습니다.

우리가 너무 많은 요청을 병행하는 혼잡문제처럼 보입니다.

 

 

툴팁을 보면 작업의 걸린시간과 멈춰서 맴돌고 있는 시간들을 보여준다.

이작업을 보면 대부분 차단되었다.

차단된 이유를 이해하려면 track display를 HTTP Transactions by Connection 보기로 전환하세요

 

 

왼쪽 트랙사이드바에 도메인이름으로 track display를 전환하기위해 클릭할 수 있는 화살표가 있습니다.(자세히 보기옵션)

트랜잭션만 표시하고 task별로 그룹화하는 대신 이제 트랜잭션이 어떤 연결에 예약되었는지 확인 할 수 있습니다.

 

 

트랜잭션을 처리 할 수 있는 6개의 Connection이 있는것을 확인했습니다.

Connection1에서의 트랜잭션을 이슈를 분석하고 썸네일 로딩 트랜잭션중 일부를 더 조사해봅시다

 

 

위에서 아래로 보면 트랜잭션이 완료되는데 시간이 더 오래걸리는 것이 보이고

각 트랜잭션에 대한 보라색 차단 상태가 증가 하고 있습니다.

여기에 계단 패턴이 있습니다.

 

동일한 Connection에 대한 이전 트랜잭션이 완료될때 까지 각 트랜잭션이 차단됩니다.

그래야만 요청을 보낼 수 있습니다.

이 패턴은 후속 트랜잭션 마다 반복됩니다.

 

이것을 Head of Line Blocking 이라고 부르며 HTTP/1 을 사용하는 문제중 하나입니다.

 

실망스러운 부분은 트랜잭션들이 대부분 시간동안 아무것도 하지않는다는 것입니다.

대신 그들은 대부분의 시간을 차단하거나 서버응답을 기다리는데 보냅니다.

동일한 Connection에서 이전 트랜잭션의 응답을 기다리는동안 다음 트랜잭션에 대한 다른 요청을 line에 보낼 수도 있지만 HTTP/1은 지원하지않습니다.

동일한 서버에 여러 요청을 다중화하여 단일연결에 적용함으로써 이러한 효과를 피한것이 HTTP/2의 주요 개선사항중 하나입니다.

 

 

HTTP/2에서는 첫번째요청이 응답을 기다리는동안 실제로 두번째 요청을 보낼 수 있습니다.

모든 애플플랫폼은 HTTP/2를 지원하며 iOS15, macOS Monterey에서 부터는 HTTP/3도 지원됩니다.

 

위의 문제를 서버사람들에게 보여주었고 HTTP/2를 지원해야한다고 설득할 수 있었다! 개선된 서버로 다시 내앱을 실행해보자!

wow, 더 빨리 느껴진다!!

 

새로운 Connection에 의한 트랜잭션을 보면 차단된 상태에서 시간을 보내지 않는다는 것을 알 수 있다

차단된 시간의 양이 너무작아서 줌수준에서 보이지않는다.

결국 모든 트랜잭션은 요청을 보내고 응답을 기다린다.

기존 7초에서 3초안에 모든 요청을 끝낸다 2배가 빨라졌다!

 

 

이렇듯 HTTP traffic 도구를 이용해서 HTTP/1버전 문제인것을 발견하고 

서버개발자에게 이를 근거로 설득해서 버전을 올려서

해결한 경우를 설명하는 예시에요

 

재밌게 설명하는것 같더라구요 ㅎㅎ

 

Xcode13이 나오면 꼭 한번 써보세요!