[면접 준비 - Network]웹 애플리케이션의 작동 흐름

목차

 

브라우저에서 요청을 보내거나 링크를 클릭하면 내부적으로 어떤 일이 일어날까?

 

에 대한 대답을 (하드웨어 쪽은 제외하고) 정리해 두려고 한다. 

 

예를 들어 https://google.com으로 접근하길 원한다고 치자. 이때 앱의 내부는 다음과 같이 동작한다.

 

 

Type https://google.com and press Enter

 

Protocol

 

https:// 는 통신 규약으로 Hypertext Transfer Protocol Secure의 약자이다.

 

데이터를 안전하게 전송하기 위해 기존의 HTTP에 TLS가 적용되어 있다.

 

Domain

 

google.com 은 웹 사이트의 도메인이다. 실제 IP 주소와 연결된 기억하기 쉬운 이름이라고 생각하면 편하다.

 

위 그림에서 볼 수 있듯이 리소스의 위치를 나타내는 추가 경로가 존재할 수 있다.

 

DNS Lookup

 

도메인 주소를 입력받은 브라우저는 서버의 IP 주소를 찾기 위해 먼저 캐시 메모리를 살핀다.

 

만약 존재한다면 주소를 바로 가져오고, 그렇지 않다면 DNS 서버에 요청을 보낸다.

 

이때 DNS 서버는 부하 분산과 공격 대비를 위해 하나의 도메인당 최소 두 개의 서버로 구성되며.

 

IP주소를 찾는 DNS Lookup은 아래와 같은 순서로 진행된다.

 

• 루트 네임 서버 - 모든 도메인을 관리. 탑 레벨 도메인에 대한 네임 서버 반환.
• TLD 네임 서버 - 탑 레벨 도메인(TLD)을 관리. 권한 있는 네임 서버를 반환.
• 권한 있는 네임 서버 - 실제로 DNS 리소스 레코드를 관리하는 서버. IP주소 반환.

방문 순서는 루트 네임 서버 → TLD 서버 → 권한 있는 네임 서버이며 순서대로 조회하며 IP주소를 완성해 준다.

 

추가로 DNS 리졸버는 보통 서버에 구현되는 재귀 요청 시스템이다.

 

TCP Connection

 

TCP와 UDP는 둘 다 IP의 한계인 비연결성과 비신뢰성을 극복하기 위해 등장한 기술이다.

 

같은 기기에서 여러 앱을 실행할 경우 그 특정을 위해 포트(Port)를 사용한다는 공통점이 있으며

 

TCP가 데이터(전송)의 신뢰성을 강조하는 반면 UDP는 빠르고 효율적이라는 차이점이 있다.

 

따라서 웹 앱 개발에선 일반적으로 TCP를, 게임 등 반응속도가 중요한 앱에선 UDP를 주로 사용한다.

 

계속해서 TCP(Transmission Control Protocol)에 대해 조금 더 살펴보면, 

 

HTTPS의 경우 TCP 3-Way HandShake를 보완한 TLD HandShake를 추가로 수행하게 된다.

 

과정은 아래와 같다.

 

• 클라이언트는 서버에게 통신을 시작하고 싶다는 알림을 보낸다.
• 서버는 받은 요청을 바탕으로 요청을 수락한다는 신호와 승인코드를 보낸다.
• 클라이언트가 승인 코드와 함께 요청을 보낸다. (HTTP의 경우 실제 데이터 전송이 시작된다.(여기까지가 TCP HandShake))
• HTTPS의 경우 클라이언트가 승인 코드와 함께 암호화에 필요한 정보를 서버로 전송한다.
  
  
  • 이때 보내는 정보는 클라이언트가 사용 가능한 암호화 알고리즘, 세션 ID TLS 버전 등이다.
• 서버가 받은 정보를 바탕으로 알고리즘을 선택한 후 TLS 버전과 함께 클라이언트에게 보낸다.
  
  
  • 이때 암호화된 TLS 인증서(서버의 공개키 포함)를 함께 전송한다.
  • TLS 인증서 내부에 공개키가 없다면 추가적인 절차를 사용해 클라이언트에게 전달한다.
• 클라이언트가 대칭키를 생성하여 전달받은 공개키를 이용해 암호화 후 서버에게 전달한다. 
  (이후의 데이터 교환에선 해당 대칭키를 이용해 주고받는 데이터를 암호화한다.)
  계속해서 통신할 준비가 완료되었다는 Finished 패킷을 주고받은 후 데이터 전송이 시작된다.

추가로 웹 서버의 위치에 따라 지연시간이 발생할 여지가 있으므로 많은 서비스는 컨텐츠 전송 네트워크(CDN)를 사용해

 

컨텐츠 배포 서버를 클라이언트 가까이 위치시킨다.

 

HTTP Request

 

준비를 모두 마친 클라이언트는 본격적으로 HTTP(s) 요청을 서버로 전송한다.

 

Request는 보통 요청 라인, 헤더, 본문으로 이루어지며

 

요청 라인에는 서버의 결정에 필요한 정보(HTTP 메서드 등)가, 헤더에는 요청에 대한 메타데이터(인증 정보) 등이 포함되어 있다.

 

우리의 예에서는 GET 요청을 보낸다.

 

HTTP Response

 

서버는 도착한 요청을 해석해 요청을 처리한다.

 

구체적으로는 앱 서버를 거쳐 DB에 필요한 작업(CRUD)을 수행하는데

 

이때 작용되는 것이 비즈리스 로직(데이터의 CRU 방식 정의)이다.

 

계속해서 요청을 모두 처리한 후 HTTP 응답을 생성해 클라이언트로 전달하는데, 이 응답에 담기는 정보는

 

요청 상태(200OK 등), 응답 처리 방식이 담긴 헤더, 요청받은 리소스 등이다.

 

Rendering

 

클라이언트는 응답받은 데이터와 JS, CSS, HTML을 사용해 사용자가 눈으로 볼 수 있는 웹페이지를 렌더링 한다.

 

백엔드에서는 더 이상 도와줄 수 있는 일이 없다.

 

Summary

 

 

1. 사용자의 입력 이벤트 발생
2. 브라우저(클라이언트)는 캐시 조회 후 저장된 IP주소가 없으면 DNS Lookup 실행
3. HTTPS의 경우 TLS Handshaking를 이용해 데이터 암호화 진행
4. HTTP Request
5. HTTP Response(비즈니스 로직 사용)
6. 렌더링