Vivo 짧은 비디오 사용자 액세스 경험 최적화 실습

작성자: Vivo 인터넷 운영 팀 - Hu Tao

이 기사에서는 vivo 짧은 비디오 사용자 액세스 경험 최적화의 실용적인 아이디어를 소개하고 실행 이면의 몇 가지 원칙을 간략하게 설명합니다.

1. 배경

우리가 평소 Douyin Kuaishou 비디오를 볼 때 특정 비디오 화면으로 스 와이프하고 몇 초 동안 움직이지 않으면 스 와이프 될 확률이 높습니다.따라서 짧은 비디오 프로젝트에서 화면 정지 사용자 경험에 큰 영향을 미칠 것입니다. , 실행 속도가 빠를수록 더 많은 사용자를 유지할 수 있습니다.

간단히 말해서 시작 속도는 호출 시작부터 화면의 첫 번째 프레임까지의 시간이며 크게 두 부분으로 나눌 수 있습니다.

• 시간이 많이 걸리는 비디오 파일 다운로드

• 시간 소모적인 비디오 디코딩

이 기사는 주로 운영 및 유지 보수 문제 해결의 관점에서 시작하고 네트워크의 각 링크에서 시작하며 특정 사례를 결합한 vivo 짧은 비디오를 통해 최적화 프로세스를 공유합니다.

2. 사용자 액세스 링크

다음 그림과 같이 클라이언트 관점을 예로 들어 다음 전체 네트워크 요청 프로세스를 먼저 분류해 보겠습니다.

CDN에 대한 액세스의 경우 여러 단계로 나눌 수 있습니다.

1. DNS 도메인 이름 확인 : 서버의 IP 주소를 얻습니다.

2. TCP 연결 설정 : 서버 IP와 연결, 즉 tcp three-way handshake를 설정합니다.

3. TLS 핸드셰이크 : 클라이언트는 서버에게 서버의 공개 키를 요청하고 확인하며, 두 당사자는 협상하여 "세션 키"를 생성하고 암호화된 통신을 수행합니다.

4. CDN 응답 : 콘텐츠 리소스를 여러 지리적 위치에 있는 서버에 배포하고 클라이언트에 반환합니다.

위의 단계에서 비보 쇼트 비디오가 어떻게 최적화되는지 이야기해 봅시다.

3. DNS 도메인 이름 확인

우리는 인터넷 서핑을 할 때 일반적으로 IP 주소 대신 도메인 이름을 사용합니다. 도메인 이름은 인간의 기억에 편리하기 때문입니다. 그러면 이 기술을 실현하는 것이 DNS 도메인 이름 확인이며, DNS는 도메인 이름 URL을 특정 IP 주소로 자동 변환할 수 있습니다.

3.1 도메인 이름의 계층적 관계

DNS의 도메인 이름은 www.server.com 과 같이 점 으로 구분  되며 여기서 점은 서로 다른 수준 간의 경계를 나타냅니다 . 도메인 이름에서 오른쪽으로 갈수록 레벨이 높아집니다 . 루트 도메인은 최상위 수준에 있고 그 다음 수준은 com 최상위 수준 도메인이며 그 아래는  server.com 입니다 .

따라서 도메인 이름의 계층적 관계는 트리 구조와 유사합니다.

• 루트 DNS 서버

• 최상위 도메인 DNS 서버(com)

• 신뢰할 수 있는 DNS 서버( server.com )

루트 도메인의 DNS 서버 정보는 인터넷의 모든 DNS 서버에 저장됩니다. 이렇게 하면 모든 DNS 서버가 루트 도메인 DNS 서버를 찾아 액세스할 수 있습니다.

따라서 클라이언트가 DNS 서버를 찾을 수 있는 한 이를 통해 루트 도메인 DNS 서버를 찾은 다음 하위 계층에 있는 대상 DNS 서버를 찾을 수 있습니다.

3.2 도메인 이름 확인 작업 흐름

브라우저는 먼저 자신의 캐시에 파일이 있는지 확인하고 없으면 운영 체제의 캐시에 묻고 없으면 로컬 도메인 이름 확인 파일 호스트를 확인하고 여전히 없으면 DNS 서버에 쿼리합니다. . 조회 프로세스는 다음과 같습니다.

1. 클라이언트는 먼저  www.server.com 의 IP가 무엇인지 묻는 DNS 요청을 보내고  로컬 DNS 서버(즉, 클라이언트의 TCP/IP 설정에 채워진 DNS 서버 주소)로 보냅니다.

2. 로컬 도메인 이름 서버가 클라이언트의 요청을 받은 후 캐시의 테이블이  www.server.com을 찾을 수 있으면 IP 주소를 직접 반환합니다. 그렇지 않은 경우 로컬 DNS는 루트 도메인 이름 서버에 "보스님, www.server.com  의 IP 주소 를 알려주시겠습니까  ?"라고 묻습니다. 루트 도메인 이름 서버는 최상위 수준이며 도메인 이름에 직접 사용되지 않습니다. 해상도이지만 도로를 지정할 수 있습니다.

3. 루트 DNS는 로컬 DNS로부터 요청을 받은 후 접미사가 .com임을 확인하고 " 도메인 이름 www.server.com  은 .com 영역에서 관리합니다"라고 말합니다. 주소를 알려드리겠습니다. .com의 최상위 도메인 네임서버에 문의하시면 됩니다. "

4. 로컬 DNS는 최상위 도메인 이름 서버의 주소를 수신한 후 요청을 시작하고 "두 번째 자식,  www.server.com 의 IP 주소를 알려주시겠습니까   ?" 라고 묻습니다.

5. 최상위 도메인 네임서버는 "  www.server.com  영역을 담당하는 권한 있는 DNS 서버의 주소를 알려드리니, 요청하시면 물어보실 수 있을 것"이라고 말했다.

6. 로컬 DNS는 권한 있는 DNS 서버에게 다음과 같이 묻습니다. "내 세 번째 자녀, www.server.com 에 해당하는 IP는 무엇입니까  ?" server.com 의 권한 있는 DNS 서버는  도메인 이름 확인 결과의 원본 소스입니다. 권위라고 불리는 이유는 무엇입니까? 그것은 내 도메인 이름이고 나는 샷을 부릅니다.

7. 신뢰할 수 있는 DNS 서버는 쿼리 후 해당 IP 주소 XXXX를 로컬 DNS에 알립니다.

8. 그런 다음 로컬 DNS는 클라이언트에 IP 주소를 반환하고 클라이언트는 대상과의 연결을 설정합니다.동시에 로컬 DNS는 IP 주소를 캐시하므로 동일한 도메인 이름의 다음 확인이 필요하지 않습니다. DNS 반복 쿼리.

지금까지 DNS 확인 프로세스를 완료했습니다. 이제 요약하면 전체 프로세스가 그림으로 그려집니다.

DNS 도메인 이름 확인 과정은 매우 흥미롭습니다.전체 과정은 일상 생활에서 길을 물어볼 사람을 찾는 과정과 유사하며 길을 보여줄 뿐 앞장서는 것은 아닙니다 .

3.3 생체 내 짧은 동영상 최적화

도메인네임 해석의 워크플로우를 명확히 하고, vivo 도메인네임과 상위 제조사의 도메인네임을 비교 분석한 결과, vivo 쇼트 비디오의 도메인네임 해석에 시간이 많이 걸리고 불안정한 것이 변동 폭이 크다는 것을 발견했다. 일부 지역의 사용자 수가 적고 로컬 DNS 서버의 캐시 적중률이 낮으므로 최적화 아이디어는  로컬 DNS 캐시 적중률을 향상시키는 것입니다 .

위의 그림과 같이 DNS 캐시 적중률을 향상시키는 간단한 방법은 전국 전화 접속 테스트 작업을 추가하여 DNS 히팅을 수행하는 것입니다 .

조정 전과 후의 DNS 확인 시간을 비교하면 소요 시간이 약 30ms 정도 감소한 것을 알 수 있습니다.

4. HTTP 성능

다음은 HTTP/1, HTTP/2 및 HTTP/3의 성능에 대한 간략한 비교입니다.

HTTP 프로토콜은 TCP/IP를 기반으로 하며 " 요청-응답 " 통신 모드를 사용하므로 성능의 핵심은 이 두 지점 에 있습니다 .

1. 긴 연결

초기 HTTP/1.0 성능의 큰 문제는 요청이 시작될 때마다 새로운 TCP 연결(3방향 핸드셰이크)을 생성해야 하며 직렬 요청이므로 불필요한 TCP 연결 설정 및 연결 해제가 발생한다는 것입니다. 통신 오버 헤드가 증가합니다.

위의 TCP 연결 문제를 해결하기 위해 HTTP/1.1은 영구 연결이라고도 하는 긴 연결 통신 방법을 제안합니다. 이 방법의 장점은 TCP 연결 설정과 연결 해제를 반복하여 발생하는 추가 오버헤드를 줄이고 서버 측의 부하를 줄이는 것입니다.

영구 연결의 특징은 한쪽 끝이 명시적으로 연결 해제를 요청하지 않는 한 TCP 연결 상태를 유지한다는 것입니다.

2. 파이프라인 네트워크 전송

HTTP/1.1은 파이프라인 네트워크 전송을 가능하게 하는 긴 연결 방법을 채택합니다.

즉, 동일한 TCP 연결에서 클라이언트는 여러 요청을 시작할 수 있으며, 첫 번째 요청을 보내는 한 두 번째 요청이 돌아올 때까지 기다리지 않고 보낼 수 있으므로 전체 응답 시간을 줄일 수 있습니다 .

예를 들어 클라이언트는 두 개의 리소스를 요청해야 합니다. 이전 방법은 동일한 TCP 연결에서 먼저 A 요청을 보내고 서버가 응답할 때까지 기다린 다음 B 요청을 받은 후 보내는 것이었습니다. 파이프라인 메커니즘은 브라우저가 A 요청과 B 요청을 동시에 발행할 수 있도록 하는 것입니다.

그러나 서버는 여전히 A 요청에 순서대로 응답하고 완료 후 B 요청에 응답합니다. 이전 응답이 특히 느리면 나중에 줄을 서서 기다리는 요청이 많이 있을 것입니다. 이것을 "헤드 오브 라인 블로킹"이라고 합니다.

3. 헤드 오브 라인 차단

"요청-응답" 모델은 HTTP 성능 문제를 악화시킵니다.

순차적으로 전송된 요청 시퀀스의 요청이 어떤 이유로 차단되면 나중에 대기열에 있는 모든 요청도 함께 차단되어 클라이언트가 데이터를 요청하지 않는 "헤드 오브 라인 차단"이 발생하기 때문 입니다 . 출근길 교통 체증과 같습니다.

4.1 HTTP/1.0에 비해 HTTP/1.1 성능 향상:

• TCP 긴 연결을 사용하는 방법은 HTTP/1.0 짧은 연결로 인한 성능 오버헤드를 개선합니다.

• 파이프라인 네트워크 전송을 지원하며 첫 번째 요청을 보내는 한 두 번째 요청이 돌아올 때까지 기다리지 않고 보낼 수 있어 전체 응답 시간을 줄일 수 있습니다.

그러나 HTTP/1.1에는 여전히 성능 병목 현상이 있습니다.

• 요청/응답 헤더(Header)는 압축 없이 전송되며, 헤더 정보가 많을수록 지연이 커집니다. Body 부분만 압축할 수 있습니다.

• 긴 헤더를 보냅니다. 매번 같은 헤더를 보내면 더 많은 낭비가 발생합니다.

• 서버는 요청 순서대로 응답하는데 서버가 느리게 응답하면 클라이언트는 데이터를 요청할 수 없습니다. 즉, 큐의 헤드가 차단됩니다.

• 요청 우선 순위 제어가 없습니다.

• 요청은 클라이언트에서만 시작할 수 있으며 서버는 수동적으로만 응답할 수 있습니다.

위의 HTTP/1.1의 성능 병목 현상에 대해 HTTP/2는 일부 최적화를 수행했습니다. 그리고 HTTP/2 프로토콜은 HTTPS를 기반으로 하기 때문에 HTTP/2의 보안도 보장됩니다.

4.2 HTTP/1.1에 비해 HTTP/2 성능 향상:

1. 머리 압박

HTTP/2는 헤더(헤더)를 압축합니다.동시에 여러 요청을 보내고 헤더가 동일하거나 유사하면 프로토콜이 중복 부분을 제거하는 데 도움이 됩니다 .

이것은 소위 HPACK 알고리즘입니다. 클라이언트와 서버에서 동시에 헤더 정보 테이블을 유지하고 모든 필드가 이 테이블에 저장되고 인덱스 번호가 생성되며 동일한 필드가 전송되지 않습니다. 앞으로는 색인 번호만 전송되므로 속도가 빨라 집니다 .

2. 바이너리 형식

HTTP/2는 더 이상 HTTP/1.1과 같은 일반 텍스트 메시지가 아니지만 이진 형식이 완전히 채택되었습니다 .

헤더 정보와 데이터 본문은 모두 바이너리이며 프레임: 헤더 정보 프레임과 데이터 프레임 으로 통칭됩니다 .

이것은 사람들에게 친숙하지 않지만 컴퓨터에는 매우 친숙합니다. 컴퓨터는 바이너리만 이해하기 때문에 메시지를 받은 후 일반 텍스트 메시지를 바이너리로 변환할 필요가 없으며 바이너리 메시지를 직접 구문 분석하여 데이터 전송을 증가시킵니다. . 효율성 .

3. 데이터 흐름

HTTP/2 데이터 패킷은 순서대로 전송되지 않으며 동일한 연결에서 연속적인 데이터 패킷은 다른 응답에 속할 수 있습니다. 따라서 패킷은 그것이 속한 응답을 나타내기 위해 표시되어야 합니다.

각 요청 또는 응답의 모든 데이터 패킷을 데이터 스트림(Stream)이라고 합니다.

각 데이터 스트림에는 클라이언트가 보낸 데이터 스트림의 수가 홀수이고 서버가 보낸 데이터 스트림의 수가 짝수임을 규정하는 고유 번호가 표시됩니다.

클라이언트는 또한 데이터 스트림의 우선 순위를 지정할 수 있습니다 . 우선 순위가 높은 요청의 경우 서버가 먼저 요청에 응답합니다.

4. 다중화

HTTP/2를 사용하면 순차적으로 일대일 대응하는 대신 하나의 연결에서 여러 요청 또는 응답을 동시에 보낼 수 있습니다 .

HTTP/1.1의 직렬 요청이 제거되어 줄을 서서 기다릴 필요가 없으며 "헤드 오브 라인 차단" 문제가 더 이상 발생하지 않아 지연이 줄어들고 연결 사용률이 크게 향상 됩니다 .

예를 들어, TCP 연결에서 서버는 클라이언트 A와 B로부터 두 가지 요청을 받습니다. A의 처리 프로세스가 시간이 많이 걸리는 경우 A의 요청 처리 부분에 응답한 다음 B의 요청에 응답합니다. . 완료 후 A의 나머지 요청에 응답합니다.

5. 서버 푸시

HTTP/2는 또한 전통적인 "요청-응답" 작업 모드를 어느 정도 개선하여 서비스가 더 이상 수동적으로 응답하지 않고 클라이언트에 능동적으로 메시지를 보낼 수도 있습니다.

예를 들어 브라우저가 HTML만 요청하면 지연 대기 즉, 서버 푸시(Server Push, Cache Push라고도 함)를 줄이기 위해 클라이언트에서 사용할 수 있는 JS 및 CSS 파일과 같은 정적 리소스를 미리 적극적으로 보냅니다.

4.3 그렇다면 HTTP/2의 결함은 무엇입니까? HTTP/3은 어떤 최적화를 수행했습니까?

HTTP/2는 헤더 압축, 바이너리 인코딩, 다중화 및 서버 푸시와 같은 새로운 기능을 통해 HTTP/1.1의 성능을 크게 향상시키지만 연고의 비행은 HTTP/2 프로토콜이 TCP를 기반으로 구현된다는 것입니다. 세 가지 결함: 개인.

• TCP와 TLS 간의 핸드셰이크 지연

• 헤드오브라인 블로킹;

• 네트워크 마이그레이션에는 다시 연결이 필요합니다.

1. TCP와 TLS 간의 핸드셰이크 지연

HTTP/1 및 HTTP/2 프로토콜의 경우 TCP와 TLS가 계층화되어 각각 커널에서 구현한 전송 계층과 openssl 라이브러리에서 구현한 프레젠테이션 계층에 속하므로 병합이 어렵고 핸드셰이크가 필요합니다. 일괄적으로 먼저 TCP 핸드셰이크를 한 다음 TLS 핸드셰이크를 합니다.

HTTP 요청을 시작할 때 TCP 3방향 핸드셰이크와 TLS 4방향 핸드셰이크(TLS 1.2) 과정을 거쳐야 하므로 요청 데이터를 전송하는 데 총 3 RTT 지연이 걸립니다.

또한 TCP는 "혼잡 제어"의 특성을 가지고 있기 때문에 방금 연결을 설정한 TCP는 "느린 시작" 프로세스를 가지게 되며 이는 TCP 연결에 "느리게" 영향을 미칩니다.

2. 헤드 오브 라인 차단

HTTP/2는 스트림 동시성을 실현하고 여러 스트림은 하나의 TCP 연결만 다중화하면 되며 TCP 및 TLS 핸드셰이크 시간을 절약하고 TCP 느린 시작 단계가 트래픽에 미치는 영향을 줄입니다. 서로 다른 스트림 ID만 동시적일 수 있습니다. 프레임이 순서 없이 전송되더라도 문제는 없지만 동일한 스트림의 프레임은 엄격한 순서를 따라야 합니다. 또한 리소스의 렌더링 순서에 따라 Stream의 우선 순위를 설정할 수 있으므로 사용자 경험을 향상시킬 수 있습니다.

HTTP/2는 완벽해 보이는 Stream의 동시성 기능을 통해 HTTP/1의 head-of-line 차단 문제를 해결하지만 HTTP/2에는 여전히 "head-of-line 차단" 문제가 있지만 문제는 HTTP 수준이 아니라 TCP 계층입니다.

여러 HTTP/2 요청이 하나의 TCP 연결에서 실행되므로 TCP 패킷이 손실되면 전체 TCP가 재전송을 기다려야 하며 TCP 연결의 모든 요청이 차단됩니다.

TCP는 바이트 스트림 프로토콜이기 때문에 TCP 계층은 수신된 바이트 데이터가 완전하고 순서대로 있는지 확인해야 합니다 네트워크 전송 중에 시퀀스 번호가 낮은 TCP 세그먼트가 손실되면 시퀀스 번호가 높은 TCP 세그먼트가 받은 후 애플리케이션 계층은 커널에서 데이터의 이 부분을 읽을 수 없으며 HTTP의 관점에서 요청이 차단됩니다.

예를 들어, 아래와 같이 표시됩니다.

그림에서 보낸 사람은 많은 패킷을 보냈고 각 패킷에는 고유한 시퀀스 번호가 있으므로 TCP의 시퀀스 번호라고 할 수 있습니다.그 중 패킷 3은 패킷 4-6을 수신한 후에도 네트워크에서 손실되었습니다. 수신자, 커널로 인해 TCP 데이터 입력이 연속적이지 않기 때문에 수신자의 응용 계층은 커널에서 읽을 수 없습니다. 패킷 3이 재전송된 후에야 수신자의 응용 계층이 커널에서 데이터를 읽을 수 있습니다. 이것은 HTTP/입니다. 2, TCP 레벨에서 헤드 오브 라인 블로킹 문제가 발생합니다.

3. 네트워크 마이그레이션에는 재연결이 필요합니다.

TCP 연결은 4개의 튜플(소스 IP 주소, 소스 포트, 대상 IP 주소, 대상 포트)에 의해 결정됩니다. 즉, IP 주소 또는 포트가 변경되면 TCP와 TLS 간에 다시 핸드셰이크가 발생합니다. 이는 4G 네트워크 환경에서 WIFI로 전환하는 것과 같이 모바일 장치가 네트워크를 전환하는 시나리오에 도움이 되지 않습니다.

이러한 문제는 TCP 프로토콜에 내재되어 있으며 애플리케이션 계층에서 HTTP/2가 어떻게 설계되더라도 벗어날 수 없습니다.

이 문제를 해결하기 위해 HTTP/3는 전송 계층 프로토콜을 TCP에서 UDP로 대체하고 안정적인 데이터 전송을 보장하기 위해 UDP 프로토콜에서 QUIC 프로토콜을 개발했습니다.

4.4 QUIC 프로토콜의 특징

• HOL(head-of-line) 블로킹이 없고 QUIC 연결에서 여러 스트림 간에 종속성이 없으며 모두 독립적이며 기본 프로토콜 제한이 없습니다. 특정 스트림에서 패킷 손실이 발생하면 이 스트림만 영향을 받습니다. , 다른 스트림은 영향을 받지 않습니다.

• QUIC 내부에 TLS1.3이 포함되어 있으므로 연결 설정이 빠릅니다 . 따라서 연결 설정과 TLS 키 협상을 "동시에" 완료하는 데 1 RTT만 필요하며, 두 번째 연결에서도 응용 프로그램 데이터 패킷이 다음과 정보를 교환할 수 있습니다. QUIC(연결 정보 + TLS 정보)를 함께 전송하여 0-RTT의 효과를 얻습니다.

• 연결 마이그레이션 , QUIC 프로토콜은 연결을 "바인딩"하기 위해 4 중을 사용하지 않고 연결 ID를 통해 통신의 두 끝점을 표시합니다.클라이언트와 서버는 각각 자신을 표시하기 위해 일련의 ID를 선택할 수 있으므로 모바일 장치가 네트워크가 변경된 후 IP 주소가 변경되면 컨텍스트 정보(예: 연결 ID, TLS 키 등)가 계속 유지되는 한 원래 연결을 "원활하게" 재사용하여 비용을 제거할 수 있습니다. 재연결.

또한 HTTP/3의 QPACK은 두 개의 특별한 단방향 스트림을 통해 양 당사자의 동적 테이블을 동기화하여 HTTP/2의 HPACK의 대기열 헤드 차단 문제를 해결합니다.

그러나 QUIC는 UDP 전송 프로토콜을 사용하기 때문에 UDP는 "2급 시민"입니다. 대부분의 라우터는 네트워크가 사용 중일 때 UDP 패킷을 삭제하고 TCP 패킷에 "공간"을 제공합니다. 따라서 QUIC의 홍보는 어렵지 않아야 합니다. . 너무 간단합니다. HTTP/3가 공식적으로 출시되는 날을 기대합니다 !

4.5 생체 내 짧은 동영상 최적화

다양한 기간에 걸쳐 생체 내 짧은 동영상이 개발됨에 따라 다음과 같이 다양한 최적화 작업을 수행했습니다.

1. HTTP/1.1 사용 : 클라이언트가 첫 번째 프레임 사진의 도메인 이름과 댓글 아바타의 도메인 이름을 병합하고 TCP 링크 재사용률이 4% 증가하고 평균 사진 로딩 시간이 약 40ms 감소합니다.

2. HTTP/2 사용 : 클라이언트가 일부 도메인 이름에 회색조로 H2를 사용하고 동결률이 0.5% 감소합니다.

3. QUIC 사용 : 약한 네트워크 시나리오에서 클라이언트는 QUIC 프로토콜을 우선적으로 사용하는 동시에 짧은 비디오 서비스의 특성에 맞게 QUIC의 성능을 특별히 최적화합니다.

5. CDN 가속화

CDN의 전체 이름은 Content Delivery Network이고 중국어 이름은 "Content Distribution Network"로 장거리로 인한 느린 네트워크 액세스 문제를 해결합니다.

간단히 말해 CDN은 여러 지리적 위치에 있는 전산실에 있는 서버에 콘텐츠 리소스를 배포하므로 콘텐츠 리소스에 액세스할 때 원본 서버를 방문할 필요가 없습니다. 대신 우리는 가장 가까운 CDN 노드에 직접 액세스하여 장거리 이동 시간 비용을 절약하고 네트워크 가속을 달성합니다.

CDN이 가속화하는 것은 콘텐츠 리소스가 정적 리소스라는 것입니다.

소위 "정적 리소스"는 데이터 콘텐츠가 정적이고 변경되지 않으며 사진 및 오디오와 같이 액세스가 항상 동일함을 의미합니다. 반대로 "동적 리소스"는 데이터 콘텐츠가 동적으로 변경되고 사용자 정보와 같이 방문할 때마다 다르다는 것을 의미합니다. 그러나 동적 자원도 캐싱하고 가속하려면 동적 CDN을 사용해야 하는데, 그 방법 중 하나가 데이터의 논리 연산을 CDN 노드에 두는 것인데, 이를 에지 컴퓨팅이라고 합니다.

CDN 가속 전략에는 " 푸시 모드 "와 " 풀 모드 " 의 두 가지 방법이 있습니다 .

대부분의 CDN 가속 전략은 "풀 모드"를 채택합니다. 요청된 데이터가 사용자가 액세스하는 가장 가까운 CDN 노드에 캐시되지 않으면 CDN은 소스 서버에서 데이터를 능동적으로 다운로드하여 CDN 노드의 캐시로 업데이트합니다. 풀 모드는 패시브 캐싱 방식이고 반대의 "푸시 모드"는 액티브 캐싱 방식임을 알 수 있습니다. 사용자가 리소스에 액세스하기 전에 CDN 노드에 리소스를 캐시하려는 경우 CDN 예열이라고도 하는 "푸시 모드"를 사용할 수 있습니다. CDN 서비스에서 제공하는 API 인터페이스를 통해 예열이 필요한 리소스의 주소, 예열이 필요한 영역 등의 정보를 제출하면 CDN이 수신한 후 해당 영역의 CDN 노드가 이동하도록 트리거합니다. 자원 예열을 달성하기 위해 소스로 돌아갑니다.

5.1 사용자에게 가장 가까운 CDN 노드를 찾는 방법은 무엇입니까?

사용자에게 가장 가까운 CDN 노드를 찾는 것은 CDN의 글로벌 로드 밸런서 (Global Sever Load Balance, GSLB) 의 책임 입니다. GSLB는 언제 작동합니까? 이 질문에 답하기 전에 CDN 없이 도메인 이름에 액세스할 때 어떤 일이 발생하는지 살펴보겠습니다. CDN이 없는 경우 도메인 이름을 방문하면 DNS 서버는 결국 원본 서버의 주소를 반환합니다. 예를 들어 브라우저에 www.server.com 도메인 이름을 입력 하고 로컬 호스트 파일에서 도메인 이름을 찾을 수 없는 경우 클라이언트는 로컬 DNS 서버에 액세스합니다.

지금이 순간:

• 로컬 DNS 서버가 웹사이트 주소를 캐싱한 경우 웹사이트 주소를 직접 반환합니다.

• 그렇지 않은 경우 먼저 재귀 쿼리를 통해 루트 하고 ) 하고 루트 DNS는 최상위 DNS(.com DNS를   www.server.com에 해당하는 IP 주소를 쿼리한 다음 이 IP 주소를 반환합니다. 동시에 로컬 DNS는 IP 주소를 캐시하므로 동일한 도메인 이름의 다음 확인은 DNS 반복 쿼리를 수행할 필요가 없습니다 .

하지만 CDN에 가입하고 나면 다릅니다.

CNAME 별칭은 다른 도메인 이름 www.server.cdn.com 을  가리키는  DNS 서버 server.com 에 설정되고 로컬 DNS 서버로 반환됩니다 . 그런 다음 도메인 이름을 계속 확인합니다. 이때 server.cdn.com  은 CDN 전용 DNS 서버입니다. 이 서버에서 CNAME은 다른 도메인 이름을 가리키도록 설정됩니다. 이번에 는  CDN의 GSLB. 다음으로 로컬 DNS 서버는 CDN의 GSLB 도메인 이름을 요청하고 GSLB는 적합한 CDN 노드를 선택하여 사용자에게 서비스를 제공합니다.선택 기준은 주로 다음 사항을 포함합니다.

• 사용자의 IP 주소를 보고, 테이블을 조회하여 지리적 위치를 파악하고, 상대적으로 가장 가까운 CDN 노드를 찾습니다.

• 사용자가 위치한 사업자 네트워크를 보고 동일한 네트워크의 CDN 노드를 찾습니다.

• 사용자가 요청한 리소스가 있는 서버를 확인하려면 사용자가 요청한 URL을 살펴보십시오.

• CDN 노드의 부하 상태를 쿼리하고 부하가 적은 노드를 찾습니다.

GSLB는 위의 조건을 기반으로 포괄적인 분석을 수행하고 가장 적합한 CDN 노드를 찾아 CDN 노드의 IP 주소를 로컬 DNS 서버에 반환한 다음 로컬 DNS 서버가 IP 주소를 캐시하고 IP를 반환합니다. 클라이언트에게 클라이언트는 이 CDN 노드에 액세스하고 리소스를 다운로드합니다.

5.2 생체 내 짧은 동영상 최적화

분석 결과, CDN에 연결된 일부 도메인 이름은 전국 일부 지방에서 근처에서 액세스되지 않으며 CDN 에지 노드의 교차 지역 커버리지 문제는 상대적으로 심각합니다. 그래서 CDN 제조사에 목표 조정을 요청했고, 조정 후 평균 요청 시간 소모가 약 300ms로 줄었고, 첫 번째 패킷 시간 소모도 100ms 이상으로 줄었습니다.

6. 요약 및 전망

비즈니스가 발전함에 따라 사용자 경험을 개선하는 것이 점점 더 중요해질 것입니다.사용자 액세스 경험 최적화는 끝없는 프로세스가 될 것입니다.위에서 언급한 방법 외에도 우리가 시도한 몇 가지 최적화가 있습니다.예를 들면 다음과 같습니다.

• 연결 최적화 : 동영상 재생 중 위아래로 슬라이드하면 연결이 자주 끊어지고 연결을 다시 사용할 수 없습니다.

• 사전 캐시 파일 : 시작 시간을 줄입니다.

• 콘텐츠 최적화 : 파일 전송 크기를 줄입니다.

이 기사가 일상 업무에서 사용자 액세스 환경을 최적화하는 데 도움이 되기를 바랍니다.

{{o.이름}}

{{이름}}