이제 컴퓨터를 나와서 ..
자 ! 지난 시간까지, OSI 7 Layer의 1 계층인 물리 계층까지 내려와서 변환후 랜선을 타고 이동하는 것 까지 완료하였습니다.
이제 목표한 IP 까지 데이터를 전달하는 과정이 남았습니다.
패킷
패킷 분할
자 그럼 데이터를 이동시킬때, 무작위로 혹은 대용량의 크기를 한번에 보낼 수 없고, 패킷이라는 조그만 단위로 쪼개서 보내야 합니다.
않이 ; 그냥 보내면 안되나요?
굳이 데이터를 쪼갰다가 다시 서버에서 재조합을 하는 리소스가 더 들지 않나요?
NO !
일부분 그런 경우는 있겠지만, 패킷 분할(데이터를 패킷 단위로 쪼개는 것)은 다양한 장점이 있습니다.
패킷 분할의 이유
1. 네트워크 트래픽의 균등 분산
작은 패킷들은 네트워크 내의 다양한 경로를 통해 전송될 수 있습니다.
이는 네트워크 트래픽을 여러 경로에 균등하게 분산시켜 각 경로의 부하를 줄이고, 결과적으로 네트워크 혼잡을 감소시킵니다.
예를 들어 보겠습니다.
1개의 서버에 3개의 네트워크 인터페이스가 있다고 가정해봅시다.
이때, 패킷 분할로 인해 3개의 네트워크 인터페이스로 로드밸런싱을 통해 균등한 자원의 분배를 할 수 있습니다!
(로드 밸런싱은 중요한 개념이므로 따로 포스팅을 하도록 하겠습니다!)
2. 오류 복구의 간소화
전체 파일을 패킷 분할을 하지 않고 보낼 경우, 100MB 크기의 파일을 모두 다시 보내야하지만,
패킷 분할을 할 경우, 패킷에 index가 쓰여있어서 해당 패킷만 재 발송하면 됩니다!
3. 보안 측면 이점
보안적으로도 역시 이점이 있습니다.
n개로 패킷 분할을 해서 보낼 때, 다양한 네트워크 경로 중 하나가 보안이 취약하여 데이터가 탈취당했다고 가정해보겠습니다.
데이터를 탈취한 사람 입장에서는 나머지 정보에 대해서 알 수 없고, 탈취한 해당 부분만 알 수 있기 때문에 보안적인 측면에서도 유리합니다.
패킷을 쪼개서 보내는 것도 알았으니, 이제 진짜로 컴퓨터를 빠져나가 봅시다!
라우터
컴퓨터의 랜선을 타고 가장 첫번째 마주치는 장치가 바로 라우터 입니다.
라우터(router[a] 혹은 라우팅 기능을 갖는 공유기)는 컴퓨터 네트워크 간에 데이터 패킷을 전송하는 네트워크 장치다. 패킷의 위치를 추출하여, 그 위치에 대한 최적의 경로를 지정하며, 이 경로를 따라 데이터 패킷을 다음 장치로 전달한다. 이때 최적의 경로는 일반적으로는 가장 빠르게 통신이 가능한 경로이므로, 일반적으로는 최단 거리일 수 있지만, 돌아가는 경우라도 고속의 전송로를 통하여 전달이 될 수도 있다. 간단히 말해, 서로 다른 네트워크 간에 최적의 경로를 찾아내는 알고리즘을 활용해 중계 역할을 해주는 장치다. 라우터는 게이트웨이의 역할을 수행하기도 한다. (출처 : 위키피디아)
인데 .. 자 중간중간에 걸리는 단어와 개념들이 있죠?!
대충 넘어가지 말고 하나하나 뜯어봅시당.
최적의 경로
?? 아니 그렇게 조그만 라우터가 뭘 어떻게 알고 최적의 경로를 찾아주나여 ..
자 그럴 줄 알고 준비했습니다.
사실 이 부분은 backend 기술 면접에서 여기까지 물어보시진 않을 것 같습니다.
네트워크 엔지니어 분들이 주로 알고 있는 영역인데,
근데 .. 궁금하잖아 ㅋㅋ
가봅시다.
라우팅 프로토콜 !
라우팅 프로토콜이란,
라우터들이 네트워크 내에서 정보를 교환하고 최적의 데이터 경로를 결정하는 데 도움을 주는 규칙과 절차를 제공하는 프로토콜입니다.
이때 두 가지의 방법을 사용할 수 있습니다.
정적 라우팅
정적 라우팅은 말 그대로 정적입니다.
라우팅을 네트워크 관리자가 직접 설정하는 방법 입니다.
- 장점 :
- 네트워크 관리자가 직접 설정하기 때문에 오버헤드가 낮음. - 단점 :
- 네트워크 관리자가 직접 설정하기 때문에 변화에 유동적이지 못함.
주로 작은 네트워크나, 네트워크 경로를 보안 등의 이유로 반드시 설정해야하는 경우 사용합니다.
동적 라우팅
동적 라우팅은 네트워크 상태의 변화를 자동으로 감지하고, 이에 따라 라우팅 테이블(라우팅에 대한 정보를 써놓는 테이블)을 동적으로 조정하는 방식입니다.
동적 라우팅 방법(RIP, OSPF, BGP) 등을 다루려 했으나 .. 진짜 글이 너무너무 길어질 것 같아서 따로 포스팅 하겠습니다.
어찌되었든, 우리가 여기서 방법을 알았다고 가정하는 것은,
"라우터를 통해 다른 라우터로 이동하였다." 라는 가정입니다.
서버 도착 !
Rendering의 종류
드디어 사용자가 보낸 요청이 서버에 도착하였습니다.
이때, 서버는 개발자가 선택한 Rendering의 종류에 따라 반환하는 데이터가 달라집니다.
SSR(Server Side Rendering)
서버 사이드 렌더링은
- 요청을 받아서
- 필요한 로직과 데이터베이스 관련 쿼리를 모두 처리한 뒤,
- 완성된 HTML 파일을 만들고,
- HTML 을 전달해서
- 사용자의 브라우저에 띄움
는 절차를 가지고 있다.
CSR(Clinet Side Rendering)
클라이언트 사이드 렌더링은
- 요청을 받아서
- 기본적인 Skeleton HTML(기본 뼈대만 있음) 과 내부 Javascript들을 전달하고,
- Client 가 이를 받아서, 다시 필요한 리소스들을 서버에 요청한 후
- 요청한 리소스를 다시 서버에서 반환해주고,
- 받은 리소스들을 활용하여 HTML 을 완성
하는 절차를 가지고 있다.
SSR 과 CSR
CSR
장점:
- 동적인 상호작용 가능
- 사용자의 입력에 따라 비동기적으로 데이터를 요청하므로, 동적인 상호작용이 가능합니다. - 서버 부하 감소
- 렌더링이 Client Side에서 이루어 지기 때문에, 서버측의 부하가 감소합니다.
단점:
- 초기 로딩 지연
- 모든 자바스크립트가 로드되고 실행될 때까지 사용자가 페이지를 볼 수 없어 초기 로딩이 지연됩니다.
사용 처:
- 사용자와 동적 interaction인 요소가 많은 환경에 적합합니다.
SSR의 특징
장점
- 빠른 초기 로딩:
- 사용자가 서버로부터 완성된 HTML을 받기 때문에 초기 콘텐츠가 빠르게 로드됩니다. - SEO 최적화:
- 서버에서 렌더링된 페이지는 검색 엔진이 쉽게 크롤링하고 인덱싱할 수 있습니다. (모든 콘텐츠가 HTML에 포함되어 전송되기 때문에) - 초기 페이지 로드 시 서버에서 데이터를 미리 처리:
- 데이터를 서버에서 미리 처리하고 최종 HTML을 생성하여 전송하기 때문에 클라이언트의 자바스크립트 처리 부담이 줄어듭니다.
단점:
- 서버 부하 증가:
- 모든 사용자 요청을 서버에서 렌더링해야 하므로, 사용자 수가 많은 경우 서버에 부하가 증가할 수 있습니다.
- 유연성 감소: 클라이언트 사이드에서 동적으로 페이지를 조정하는 것이 제한적일 수 있습니다.
사용 처:
- SEO에 민감한 웹 사이트: 뉴스 사이트, 블로그, 마케팅 웹사이트 등.
- 초기 콘텐츠 로딩 시간을 최소화해야 하는 웹 애플리케이션.
네이버의 경우?
네이버의 경우 상당히 동적으로 작동하기 때문에 CSR 방법은 선택하고 있습니다.
따라서
- 첫번째 통신
- skeleton HTML 및 기본 Javascript
- 두번째, 세번째, 네번째 .. 통신
- 추가 JavaScript 파일들
- CSS 파일들
- 이미지 및 미디어 파일들
- API 요청을 통한 데이터
- 웹 폰트
의 과정을 거치게 됩니다.
서버에서 다시 로컬으로 ..
자 이제 서버에서 발송하였으니, 다시 로컬로 이동하게 됩니다!
이동할때는 이전 시간에 말한 Source IP Address 로 보내져왔던 통신의 역순으로 전달되게 됩니다.
다음 시간에는 www.naver.com 에 접속한 후,
이후에 벌어지는 동기/비동기 통신에 대해서 이야기를 해보겠습니다!텍스트
