브라우저에 www.google.com을 입력했을 때 일어나는 과정

틀린 부분이 있으면 댓글로 알려주세요!

1. 주소창에 www.google.com  검색

• 클라이언트(브라우저)에서 해당 url을 통해 GET 요청을 보내려고 합니다.

2. 캐싱

(Broswer 캐시 > OS 캐시 > router 캐시 > ISP 캐시)

• 브라우저는 해당 도메인 주소에 대한 4가지의 캐싱된 DNS 기록들을 확인합니다. 
• 확인 후 캐시가 존재해면, DNS 서버로 연결하지 않고 바로 IP 주소를 반환합니다.
• 반대로 캐시가 존재하지 않으면, DNS 서버로 요청이 넘어갑니다.

3. DNS, 포트번호

• DNS(Domain Name System): 사람이 쉽게 기억하기 위해서 IP 주소와 도메인 이름을 연결하는 수직적인 체계
• Iterative Query(반복적 질의): Recursive DNS 서버가 도메인을 관리하는 각각의 Authritative DNS 서버로 질의할 때 사용하는 순차적 반복질의
• Recursive Query(재귀적 질의): Recursive DNS 서버가 자신의 캐시 데이터에 요청 도메인 정보가 있으면, 정보를 반환, 없을 시에는 최상위 Root 네임서버부터, 순차적으로 Iterative Query를 수행하여 결과를 반환
• HTTP를 사용하여 가장 가까운 DNS 서버가 호스팅하고 있는 도메인 이름 중에 있는지 확인을 요청합니다.
•  

https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/jsp/resources/dns/dnsInfo.jsp

4. HTTP, TCP/IP

HTTP: 웹에서 이루어지는 모든 데이터 교환의 기초, 프로토콜. 

브라우저가 서버의 IP 주소를 이용해서 HTTP Connection으로 서버와 연결을 시도합니다.

브라우저와 서버는 HTTP Connection을 위해서 TCP/IP 프로토콜을 이용합니다.

TCP의 3 way handshake 과정을 거쳐서 연결하고, 4 way handshake 과정으로 연결을 해제합니다.

브라우저는 서버와 연결되면 GET 방식으로 서버에게 요청을 합니다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

5. 방화벽(Firewall)

서버에서 악의적인 트래픽을 일으키는 클라이언트를 차단하기 위해, 미리 정의된 보안 규칙에 따라 네트워크 트래픽을 모니터링하는 네트워크 보안 시스템입니다.

6. HTTPS, SSL/TLS

• Transport Layer Security(TLS): 넷스케이프가 Secure Sockets Layer(SSL) 암호화 기반 인터넷 보안 프로토콜로 1995년에 개발. 그 후 2000년대에 넷스케이프와 마이크로소프트와의 브라우저 경쟁으로 TLS와 SSL이라는 용어를 혼용해서 쓰다보니 사람들도 헷갈리게 되었고, 결국 넷스케이프는 IETF에 SSL 프로토콜에 대한 제어권을 넘기면서 사실은 TLS가 맞습니다.
• TLS는 현재 1.3 버전까지 나왔으며 여러 브라우저들은 현재 1.2, 1.3 을 대부분 지원하고 있습니다.
• HTTPS: HTTP 프로토콜과 동일하지만 추가로 SSL/TLS를 사용한 데이터 암호화 기능이 있습니다. 이를 통해 클라이언트와 서버 사이 데이터를 주고받을 때 암호화를 통해서 중간에 해커가 패킷을 엿드는 것을 차단할 수 있습니다.

7. Proxy Server

Proxy Server: proxy의 뜻 자체가 중계라는 뜻으로, Client와 Server 사이에서 요청과 응답을 관리하는 역할을 합니다.

Nginx: Reverse Proxy Server이자 Web Server(WS) 역할을 합니다. Proxy Server의 장점은 아래와 같습니다. 

Reverse Proxy Server: 서버 단에 가까이 붙어있는 중계기로서, 서버의 정보를 은닉하여 보안을 높이고, 서버들의 로드 벨런싱 역할, 캐싱 역할 등을 수행합니다.

프록시 서버 - 위키피디아

https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

8. WAS

• Web Application Server(WAS): Database 서버에서의 데이터, 다른 서버와의 소통, 프로그래밍 언어를 활용한 연산, 동적 처리, 비동기 처리 등 클라이언트에게 원하는 정보를 주기 위해서 동적인 데이터와 다양한 로직을 처리하는 서버를 의미합니다.
• Web Server(WS): HTML, CSS, JS과 같은 정적 파일(리소스)들을 빠르게 Serving 하는데에 목적을 둔 서버를 의미합니다.
• WAS 또한 WS의 역할을 수행할 수 있지만! 역할과 목적에 따라서 서버를 분리하는면 큰 장점이 있기 때문에 사용합니다. 예를 들어, 장점은 로드벨런싱 역할, 로그 관리, 모니터링, 요청과 응답에 대한 제한 설정, 서버 부하 감소, 등이 있습니다.

9. 랜더링 방식에 따른 응답 차이

• Server Side Rendering(SSR): 백엔드 서버가 미리 웹 페이지의 HTML 코드를 생성하여 클라이언트(브라우저)에게 전달하는 방식입니다. 즉, 서버가 클라이언트에게 보낼 데이터를 HTML 형태로 만들어서 브라우저로 전송합니다. 이렇게 하면 브라우저는 HTML을 받자마자 바로 페이지를 렌더링하고 표시할 수 있습니다. 
  • SSR은 WAS에서 HTML을 생성(렌더링)해서 정적 파일과 함께 클라이언트로 보내줍니다.
• Cilent Side Rendering(CSR): 서버로부터 단순히 데이터만 받아온 후, 웹 페이지의 렌더링을 브라우저에서 JavaScript와 같은 클라이언트 측 코드를 사용하여 수행하는 방식입니다. 이후 클라이언트에서 이 데이터를 이용하여 HTML을 동적으로 생성하고 페이지를 구성합니다.
  • 비어있는 HTML과 JS 번들 파일들을 여러 종류의 서버(WS, WAS, CDN)를 통해 클라이언트로 보냅니다.
• Single Page Application(SPA): 단일 페이지로 구성된 애플리케이션. CSR을 통해서 동적으로 HTML을 생성하기 때문에 플리커 현상이 없어져서 사용자 경험이 좋다.
  • SPA는 CSR을 하기 때문에 위와 동일합니다.
• Static Site Generation(SSG): 애플리케이션을 빌드 과정에서 미리 렌더링 해놓아서 HTML을 서빙합니다.
  • 서버를 통해서 미리 랜더링을 합니다.

10. 브라우저에서 렌더링 과정으로 끝.

1. DOM Tree 생성
2. CSSOM Tree 생성
3. Render Tree 생성
4. 레이아웃 생성
5. 페인팅 진행

리플로우(Reflow)

웹 페이지의 레이아웃이 변경될 때 발생하는 과정

• 요소의 크기나 위치가 변경, 새로운 요소가 추가되거나 제거, 폰트 크기 변경, 윈도우 크기 변경 등

리페인트(Repaint)

웹 페이지의 레이아웃은 변화가 없지만, 색상, 배경, 텍스트 등의 시각적인 속성이 변경될 때 발생하는 과정

• 요소의 색상, 배경 등 시각적 스타일이 변경, CSS의 가상 클래스가 변경, 텍스트 내용, 텍스트 스타일 변경 등

---

번외. CDN? Edge Server?

 

번외. GET요청과 라우팅에 대한 나의 오해

URL을 통해서 WAS에게 GET요청을 보내던 것과 애플리케이션에서 URL을 통해 라우팅하는 것은 다릅니다. SPA의 라우팅 기능은 이 경로에 해당하는 컨텐츠를 렌더링하고 해당 뷰를 사용자에게 보여주는 역할을 합니다. 이 때, 페이지가 로딩된 이후에는 사용자가 다른 경로로 이동해도 서버로 추가적인 요청을 보내지 않고도 해당 컨텐츠를 변경하여 보여줍니다.

번외. 면접에서 프론트엔드 서버라고 잘못 사용한 나

왜 그랬을까? 무슨 의도에서 그렇게 질문하셨을까? 고민해보니 위 게시글을 정리하면서 이해했습니다. "Next.js는 마치 React를 기반으로 서버의 역할까지 한다." 라고 이해를 했다보니, 프론트엔드 서버가 따로 있는 것 아니야? 라는 식으로 생각했나봅니다.

 

다시 정리를 하자면, Next.js를 통해 standalone 옵션으로 빌드 후 서버를 실행하게 되는데, 이때 실행 명령이 "node server.js" 입니다. 이 힌트를 통해서 이해한 바는 Next.js 프로젝트에서 pages 폴더는 백엔드 코드와 프론트엔드 코드를 동시에 작업할 수 있는 곳이며, 그 중에 api 폴더는 백엔드로서 api 데이터를 주고 받을 때 사용하는 것으로 이해했습니다. 그래서 Next.js는 백엔드 서버를 통해서 SSR, SSG, CSR을 모두 다룰 수 있는 프레임워크라고 할 수 있습니다.

 

Vercel의 Next.js 공식 사이트에서도 바로 full-stack Web applications 라고 하는 것을 봤었지만, 이것이 의미하는 바를 전혀 인지하지 않고 있었나 봅니다!

 

프론트 서버(WS)라는 용어도 따로 사용하다보니 헷갈렸다고 위안을 합니다..ㅎㅎ

---

참고

https://velog.io/@tnehd1998/%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-www.google.com%EC%9D%84-%EC%9E%85%EB%A0%A5%ED%96%88%EC%9D%84-%EB%95%8C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95

주소창에 www.google.com을 입력했을 때 일어나는 과정

https://isc9511.tistory.com/24

DNS 보안

https://leeph.tistory.com/39

[웹 브라우저] 브라우저에 www.google.com을 치면 일어나는 일

https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

HTTP 개요 - HTTP | MDN

https://velog.io/@longroadhome/FE-SSRServer-Side-Rendering-%EA%B7%B8%EB%A6%AC%EA%B3%A0-SSGStatic-Site-Generation-feat.-NEXT%EB%A5%BC-%EC%A4%91%EC%8B%AC%EC%9C%BC%EB%A1%9C

[FE] SSR(Server-Side-Rendering) 그리고 SSG(Static-Site-Generation) (feat. NEXT를 중심으로)