웹 성능 최적화 네트워크 환경 4가지

우리는 웹페이지를 볼 때 마치 책을 펼쳐 보는 것 마냥 쉽게 내용을 확인하지만 컴퓨터는 이 과정을 매우 복잡한 절차를 거쳐 수행합니다. 그리고 갈수록 늘어나는 데이터량을 빠르게 화면에 보여주기 위해 많은 전문가들이 고심하고 있습니다. 이번 글은 어떤 부분을 고려하여 웹 성능이 최적화 되는지에 대해서 말하고자 합니다.

웹 성능을 좌우하는 요소는 정말 다양합니다. 그러나 중요한 요소를 뽑는다면 크게 2가지가 있습니다. 첫 번째 네트워크 환경, 두 번째 서버 성능입니다. 그 외에 데이터 수 증가와 호스트(host) 수 증가 등 인터넷 통신상에 병목을 일으키는 요소를 예로 들 수 있습니다.

오늘은 네트워크 환경에 대해 구체적으로 어떤 것들이 있는지 다음 내용에서 같이 알아보겠습니다.

✔네트워크 환경

웹 페이지를 로딩(loading)하는 데 가장 많은 영향을 끼치는 요소는 네트워크입니다. 흔히 “인터넷 왜 이렇게 느려?” 라고 말하는 것처럼 온라인 상에서 가장 먼저 삶의 와 닿는 부분입니다. 그럼 네트워크 수준에서 어떤 지표를 살펴볼지 알아보겠습니다.

1. 지연시간

지연 시간이란 IP(Internet Protocol) 패킷이 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간을 말합니다. 헤더(header)와 페이로드(payload)로 이뤄진 패킷은 지연 시간이 길어질수록 데이터 전송 속도가 느려지고 사용자 경험이 저하되는 현상을 겪게 된다.

1.1 패킷 구성 요소

IP 패킷은 헤더(Header)와 페이로드(Payload)로 구성됩니다.

1. 헤더(Header)
   • 패킷의 제어 정보가 포함되어 있습니다.
   • 주요 내용
     • 송신자 및 수신자의 IP 주소
     • 패킷 번호
     • 프로토콜 정보
     • 데이터 전송 경로를 지정하기 위한 정보
2. 페이로드(Payload)
   • 실제 데이터가 포함된 부분입니다.
   • 사용자가 요청하거나 전달받는 콘텐츠, 예를 들어 웹페이지 데이터, 이메일 내용 등.

1.2 지연 시간의 주요 원인

1. 전송 지연(Transmission Delay)
   • 데이터 패킷이 송신 장치에서 네트워크로 이동하는 데 걸리는 시간.
   • 패킷 크기와 전송 속도에 영향을 받음.
2. 처리 지연(Processing Delay)
   • 라우터 또는 네트워크 장치에서 패킷을 분석하고 다음 경로를 결정하는 데 걸리는 시간.
3. 전파 지연(Propagation Delay)
   • 신호가 네트워크를 통해 이동하는 물리적인 시간.
   • 케이블 길이와 신호 전송 속도에 따라 결정됩니다.
4. 대기 지연(Queuing Delay)
   • 네트워크 장치에서 패킷이 처리되기 위해 대기하는 시간.
   • 네트워크 트래픽과 혼잡도가 클수록 지연 시간이 늘어날 수 있습니다.

2. 대역폭(Bandwidth)

대역폭(Bandwidth)은 두 지점 사이의 네트워크 연결이 처리할 수 있는 최대 데이터 전송 용량을 의미합니다. 웹 페이지 로딩 속도와 사용자 경험에 직접적인 영향을 미치는 것으로 흔히 단말기 요금제의 3g, LTE 혹은 5G 같은 것으로 이해하면 된다. 대역폭이 클 수록 단위 당(초) 처리할 수 있는 데이터 양이 늘어 나기 때문에 쾌적하게 인터넷을 이용할 수 있다. 다음 구체적으로 대역폭과 웹 페이지 관계에 대해서 설명해보겠습니다.

2.1 대역폭의 특성과 웹 페이지와의 관계

1. 대역폭의 정의
   • 데이터 전송 용량: 네트워크가 포화 상태가 되기 직전까지 동시에 처리할 수 있는 데이터의 최대량으로 데이터 전송 용량보다 큰 웹 페이지를 로딩 할 경우 굉장히 속도가 저하됨을 느낄 수 있습니다.
   • 단위: Mbps(메가비트/초) 또는 Gbps(기가비트/초).
2. 대역폭이 웹 페이지 성능에 미치는 영향
   • 높은 대역폭: 더 많은 데이터를 동시에 처리 가능 → 빠른 웹 페이지 로딩.
   • 낮은 대역폭: 데이터 병목 현상이 발생 → 웹 페이지 로딩 시간이 길어짐.
   • 특히, 이미지, 동영상, 스크립트 등 리소스가 많은 웹 페이지일수록 더 높은 대역폭이 요구됩니다.
3. 포화 상태의 의미
   • 포화 상태: 네트워크가 처리할 수 있는 최대 용량을 초과한 상태.
   • 결과: 데이터 지연 증가, 패킷 손실 발생, 웹 페이지 로딩 지연.

2.2 대역폭 최적화를 위한 웹 페이지 개선 방법

1. 리소스 최소화
   • 이미지 압축: 불필요하게 큰 이미지 파일 크기를 줄여 대역폭 소비 감소.
   • 코드 최적화: HTML, CSS, JavaScript를 최소화 및 병합(Minification).
2. 콘텐츠 전송 네트워크(CDN) 활용
   • 웹 페이지 콘텐츠를 사용자와 가까운 서버에서 제공해 전송 거리를 줄이고, 네트워크 부하를 분산.
3. HTTP/2 또는 HTTP/3 프로토콜 사용
   • 동시 다중 요청 처리와 전송 속도 최적화를 통해 대역폭 효율성을 개선.
4. Lazy Loading(지연 로딩)
   • 사용자가 필요로 하는 콘텐츠만 로드하여 초기 대역폭 사용을 절약.
5. 압축 기술 사용
   • Gzip 또는 Brotli 압축을 통해 전송되는 파일 크기를 줄임.

3. DNS 조회

DNS 조회는 사용자가 브라우저 창에 인터넷 주소(도메인 이름)를 입력하면, 해당 주소를 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 과정을 말합니다. 이 과정은 다음 단계를 거칩니다.

3.1 DNS 조회 과정

1. 사용자의 도메인 입력
   • 사용자가 브라우저에 www.gsixplus.com과 같이 도메인 이름을 포함한 주소를 입력하면
2. 브라우저의 캐시 확인
   • 브라우저는 가장 먼저 로컬 캐시를 확인 후
   • 이전에 같은 도메인을 조회한 기록이 있다면 캐시에서 해당 IP 주소를 가져옵니다.
3. 운영 체제의 DNS 캐시 확인
   • 브라우저 캐시에 정보가 없다면, 운영 체제의 DNS 캐시를 확인합니다.
4. 로컬 DNS 서버 요청
   • 운영 체제 캐시에도 정보가 없다면, 로컬 DNS 서버(ISP 제공)에 요청을 보냅니다. 여기서 로컬 DNS 서버라는 것은 기지국 DNS 서버를 말하며 흔히 KT, SKT, LG U 등의 각 통신사의 서버를 말합니다.
   • 로컬 DNS 서버는 해당 요청을 처리할 수 있는 정보(캐시)를 가지고 있습니다.
5. 재귀적 DNS 조회
   • 로컬 DNS 서버에 정보가 없으면, DNS 서버는 재귀적 조회를 시작합니다 여기서 재귀적 조회라는 것은 특정 DNS 서버에서 다른 여러 DNS 서버와 통신하여 IP 주소를 찾아내고 클라이언트에 반환하는 것을 말합니다.
     • Root 서버: “.com”, “.org”와 같은 최상위 도메인을 관리하는 루트 네임 서버를 조회합니다.
     • TLD 네임 서버: 도메인의 최상위 레벨(예: .com, .net)의 정보를 가진 서버를 조회합니다.
     • 권한 네임 서버(Authoritative Name Server): 도메인의 IP 주소를 최종적으로 제공하는 서버입니다.
6. IP 주소 반환
   • 권한 네임 서버가 해당 도메인의 IP 주소(예: 192.0.7.1)를 반환합니다.
   • 이 IP 주소는 브라우저로 전달되어 웹사이트에 연결됩니다.
7. 브라우저와 웹 서버 연결
   • 브라우저는 반환된 IP 주소를 사용해 해당 웹 서버와 연결을 설정합니다.
   • 이 과정에서 TCP/IP 프로토콜과 HTTP/HTTPS 요청이 사용됩니다.

3.2 DNS 조회의 최적화

1. DNS 캐싱
   • 브라우저, 운영 체제, ISP의 로컬 DNS 서버에 캐싱된 결과를 사용해 조회 시간을 단축합니다.
2. CDN(Content Delivery Network)
   • CDN은 가까운 서버의 IP 주소를 반환해 데이터 전송 속도를 높이고 네트워크 부하를 줄입니다.
3. DNS 프리페치(DNS Prefetch)
   • 브라우저가 페이지 로딩 전에 미리 DNS를 조회해 성능을 개선합니다.

4. TCP 3방향 핸드셰이크와 TLS 협상(TLS Handshake) 통신 시간

TCP 3방향 핸드셰이크와 TLS 협상(TLS Handshake)의 연결 수립은 네트워크 연결에서 데이터 전송의 신뢰성과 보안을 보장하기 위한 중요한 과정이지만 이 두 과정은 연결 시간에 영향을 미칩니다. 아래에서 각 과정과 연결 시간의 관계를 설명하겠습니다.

4.1 TCP 3방향 핸드셰이크

TCP 3방향 핸드셰이크는 두 장치 간의 연결을 설정하는 기본 과정입니다. 이 과정은 신뢰성 있는 데이터 전송을 보장하기 위해 수행됩니다.

4.1.1 과정

1. SYN (Synchronize)
   클라이언트가 서버로 연결 요청을 보냅니다.
   → 클라이언트 → 서버: SYN
2. SYN-ACK (Synchronize-Acknowledgment)
   서버가 요청을 받고 응답하며, 동시에 자신의 연결 요청을 보냅니다.
   → 서버 → 클라이언트: SYN + ACK
3. ACK (Acknowledgment)
   클라이언트가 서버의 응답을 확인하고, 연결이 설정됩니다.
   → 클라이언트 → 서버: ACK

4.1.2 연결 시간

• TCP 핸드셰이크는 왕복 지연 시간(RTT: Round Trip Time)의 영향을 받습니다.
• 보통 1 RTT가 소요됩니다. 만약 로컬 네트워크 RTT가 5ms이라면1 RTT = 0.005초 걸린다고 생각하면 됩니다.

4.2 TLS 협상 (TLS Handshake)

TLS역시 데이터 전송 시 보안을 보장하기 위해 사용되며, TCP 연결 위에서 동작합니다. 해당 웹이 HTTPS 연결을 필요로 하면 SSL 후속 프로토콜 TLS협상이 요구됩니다. TLS 핸드셰이크는 클라이언트와 서버가 암호화된 통신을 설정하기 위해 수행되기 때문에 시간 소요가 더 늘어나게 됩니다.

4.2.1 과정 (TLS 1.2 기준)

1. ClientHello
   클라이언트가 서버로 지원 가능한 암호화 알고리즘(예: RSA, AES)과 난수를 보냅니다.
2. ServerHello
   서버가 사용할 암호화 알고리즘을 선택하고, 자신의 인증서와 난수를 보냅니다.
3. Key Exchange
   • 서버는 클라이언트와 키 교환을 수행하여 세션 키를 생성합니다(예: RSA, DH).
   • 클라이언트는 서버의 인증서를 검증하고, 세션 키를 생성합니다.
4. Finished Messages
   클라이언트와 서버는 세션 키로 암호화된 “Finished” 메시지를 주고받아 핸드셰이크를 종료합니다.

4.2.2 연결 시간

• TLS 핸드셰이크는 보통 1~2 RTT가 추가적으로 소요됩니다.
• 최신 TLS 1.3에서는 핸드셰이크 과정을 단축하여 1 RTT로 줄였습니다.

4.3 최적화 방법

1. TLS 1.3 사용
   • 핸드셰이크를 단축하여 연결 시간을 줄입니다.
2. TCP Fast Open(TFO)
   • TCP 연결 초기화 과정을 줄여 핸드셰이크를 가속화합니다.
3. HTTP/2 혹은 HTTP/3 사용
   • 더 적은 연결과 빠른 데이터 전송을 지원합니다.
4. Keep-Alive 설정
   • 기존 연결을 유지하여 새 핸드셰이크 과정을 줄입니다.
5. CDN(Content Delivery Network) 활용
   • 사용자와 가까운 서버로 연결하여 네트워크 지연 시간을 단축합니다.

여기에서 TLS 1.3은 TLS 프로토콜 최신버전으로 알고 있으면 됩니다.

지금까지 클라이언트에서 특정 웹페이지를 불러오는 요청을 보내기 전 과정을 살펴보았습니다. 해당 서버를 찾아가기 위한 DNS 조회부터 해당 서버와 안정적인 연결 수립을 위한 TCP와 TLS를 위한 시간이 소요된 다는 것을 이 번 내용을 통해서 대략적으로 알 수 있을 것입니다. 또한 이러한 시간을 최소화 하기 위해 각 부분마다 어떤 것을 고려 해야 할지 간단하게 살펴봤습니다.

다음 포스팅에서는 실질적으로 특정 웹페이지에 있는 소스를 갖고 가져와 렌더링 하는 서버 자체 내용과 성능 그리고 어떻게 최적화 하면 좋을지에 대해서 알아보겠습니다.

✔추가 참고 문서

1. 🍳웹 성능이란?
2. Learning HTTP/2 (한빛미디어 출판)