DevLog 😶

🌱 들어가기 전 드디어 기나긴 패킷 여행의 마지막이다. 이번 포스팅에서는 웹 서버측에서 어떤 식으로 패킷을 받아오는지 알아볼 것이다! 클라이언트에서 패킷을 전송하는 단계를 반대로 뒤집은 것과 동일하기 때문에 크게 어렵지 않을 것이다. 🌱 클라이언트가 보낸 패킷이 서버로 도착한 직후 다시 돌아와서, 클라이언트에서 보낸 패킷이 서버로 도착한 직후 어떤 일이 발생하는지 간단하게만 알아보자. (이 부분은 크게 중요한 건 아니라서 간단하게 짚고 넘어가고자 한다.) 우선, 서버 측으로 들어온 패킷의 경우 사실 '전기 신호'의 형태로 들어온다. 전기 신호는 LAN 어댑터에서 수신되며, 여기서 1과 0의 디지털 데이터로 바뀌게 된다. 위 그림은 전기 신호에서 디지털 데이터로 변환되었을 때 패킷의 형태이다. 변경된 디지..

🌱 CDS (Content Delivery Service) 만약, 내가 배포한 서버가 한국에만 존재하지만 전세계 다양한 곳에서 액세스되고 있다고 생각해보자. 수많은 파일과 데이터에 대해 전세계에 응답해야 하는 상황에서, 멀리 있는 국가의 사용자와 대해서 전달해야 한다면? 한국 사용자에게는 빠르게 전달할 수 있지만, 멀리 있는 사용자의 요청을 받아서 한국에서 처리하고, 또 다시 데이터를 곳곳에 존재하는 사용자에게 전달해야 하기 때문에 어느 정도 지연이 발생할 수밖에 없다. 이러한 상황에서 다수의 캐시 서버를 여러 개의 지역에 배치하여 트래픽을 분산시키는 방법이 필요하다! 그렇다면 캐시 서버는 어디에 둬야 할까? 1. 웹 서버 직전에 두기 웹 서버 직전에 두게 되면 서버 자체의 부하는 줄어들게 되지만, 인터..

🌱 DNS 서버를 통해 다중 서버로 분산 처리하기 서버의 액세스가 증가한다면 단순히 회선을 빠르게 하는 것으로도 부족할 수 있다. 단일 서버의 한계를 극복하기 위해서는, 여러 대의 서버를 이용하여 처리를 분산시킬 수 있는데 이를 '분산 처리'라고 한다. 클라이언트의 리퀘스트를 어떻게 하면 여러 대의 서버로 분배할 수 있을까? 바로, DNS 서버를 통해 분배하는 것이다. DNS 서버에 동일한 이름으로 여러 대의 웹 서버를 등록해둔다면, 조회가 있을 때마다 조회된 IP 서버를 차례로 반환한다. 이때, 라운드 로빈 방식을 통해 균등하게 액세스를 분산시킬 수 있도록 돕는다. 💡 aaa.com이라는 도메인에 대해 192.0.2.60, 192.0.2.70, 192.0.2.80이 있다면 아래와 같은 순서로 반환한다...

🌱 들어가기 전 지난 포스팅까지는 클라이언트 측 LAN에서 라우터까지 어떻게 패킷이 흘렀는지 알아보았었다. 그 이후로도 전기 신호로 변환되고, 패킷이 중계되고, 통신 회선이나 프로바이더의 네트워크를 통해 서버 측으로 어떻게 이동하는지 그러한 과정이 있지만 내용이 너무 깊은 것 같아서 생략했다. 이번 포스팅에서는 웹 서버에서 어떤 식으로 요청이 처리되는지 알아보고자 한다. 🌱 웹 서버는 어디에 설치될까요? 과거에는 사내의 LAN에 서버를 설치한 다음, 인터넷에서 직접적으로 액세스했다. 이러면 패킷은 액세스 회선, 서버측 라우터를 경유해서 서버 머신에 도착하여 패킷이 흐르게 된다. 하지만, 이 방법은 서버와 클라이언트 모두에 글로벌 주소를 할당해야 돼서 IP 주소가 부족해진다. 또한, 서버가 직접적으로 노..

🍀 들어가기 전 지난 포스팅에서는 라우터의 패킷 중계 동작에 대해서 알아보았다. 이번 포스팅에서는 라우터의 주소 변환 기능과 패킷 필터링 기능에 대해서 알아보자! 🍀 주소 변환이 나온 이유 라우터는 다양한 일을 하지만, 그중 핵심은 주소 변환 및 패킷 필터링 기능이다. 주소 변환은 왜 나왔을까? 이전에는 IP주소를 관리 기관에 신청서를 내서 할당받았지만, 인터넷에 접속하는 기기가 많아지면서 할당해줄 주소가 부족해지는 현상이 발생했었다. 이를 해결하기 위해서 동일한 회사에서 사용하는 주소는 다른 회사의 주소와 동일할 수 있도록 만들었다. 이는 어차피 다른 회사의 패킷은 서로 왕래할 일이 없으며, 같은 회사에서끼리 별도의 사내망으로 통신하기 때문에 다른 회사와 겹쳐도 상관없는 것이다. 덕분에 같은 회사에 있..

🌱 들어가기 전 지난 포스팅까지는 클라이언트 측에서 발생하는 일, 브라우저 -> 소켓 라이브러리 -> 프로토콜 스택 -> LAN 드라이버 -> LAN 어댑터까지 어떻게 HTTP 요청이 처리되는지 알아보았다. 이번 포스팅에서는 [클라이언트 측 LAN]에서 일어나는 일 중, 트위스트 페어 케이블, 리피터 / 스위칭 허브를 지나 라우터에서 어떤 식으로 패킷을 중계하는지 알아보자. (케이블, 허브에서 일어나는 건 전기신호에 대한 내용이라 정리하지 않았다.) 🌱 라우터는 어떻게 생겼을까? 기본적으로 라우터의 경우 네트워크 간의 패킷을 중계하는 장치로, 이더넷 같은 링크 계층 프로토콜과 IP 같은 네트워크 계층 프로토콜을 모두 지원한다. 실제로는 훨씬 복잡하겠지만 간결하게 그리면 이런 구조로 생겼다. 여기서 '중계..

🌱 들어가기 전 지난 포스팅에서는 프로토콜 스택에서의 데이터 송/수신 및 말소 과정에 대해서 알아보았다. 이번 포스팅에서는 TCP / IP에서 패킷을 어떻게 처리하고 LAN 어댑터로 어떻게 송신되는지 알아보자. 그리고 간단하게 UDP에서의 송,수신 동작을 알아보자! 🌱 패킷은 어떻게 구성되어 있을까? 패킷은 크게 헤더와 데이터로 구성된다. 헤더에는 수신처를 나타내는 주소 같은 제어 정보가 들어있으며, 데이터에는 실제로 운반되는 데이터가 들어있다. 생성된 패킷은 중계 장치로 도착하고, 중계 장치는 헤더 정보를 바탕으로 패킷의 목적지를 판단한다. 이때, 중계 장치 내에는 어느 수신처가 어디에 있는지에 대해 기록된 표가 존재하며, 해당 표를 바탕으로 패킷의 목적지를 판단한다. 여러 개의 중계 장치를 거쳐서 패..

저번 포스팅에서는 프로토콜 스택 및, 위에서 소켓 작성에 대한 부분을 알아보았었다. 이번 포스팅에서는 구체적으로 프로토콜 스택의 데이터 송수신 및 말소 과정에 대해서 알아보고자 한다. ✔️ 소켓에 접속하기 소켓을 만들면 애플리케이션 (브라우저)는 connect()를 호출하고, 프로토콜 스택은 본인 쪽의 소켓을 서버 측에 접속한다. 이더넷이나 통신 회선은 기본적으로 항상 케이블이 연결되어 있기 때문에, 언제든지 신호를 보낼 수 있어서 데이터를 신호로만 변환하면 된다. 하지만 만약 소켓을 만든 다음에 애플리케이션에서 송신 의뢰가 온다면, 프로토콜 스택은 어떻게 될까? 우선, 기본적으로 소켓을 생성한 다음에는 아무것도 없기 때문에 통신 상대도 모른다. 그래서 의뢰가 온다면 데이터를 어디로 보내면 좋을지도 알 ..

지난 포스팅에서는, 클라이언트와 서버 사이에 어떤 식으로 소켓이 생성되는지 알아보았다. 그 사이에는 늘 '프로토콜 스택' 이라는 친구가 있었는데, 이번 포스팅에서는 프로토콜 스택이 뭔지 조금 더 구체적으로 알아보고자 한다. 앞으로 포스팅을 진행하면서 윗부분의 절차들을 하나하나씩 알아나갈 예정이다. ✔️ 프로토콜 스택이란? 위의 그림을 보자. 최상단의 네트워크 애플리케이션은 브라우저, 웹 서버 등의 프로그램이 해당하며, 여기서부터 아래로 향하게 된다. 우리가 이전 포스팅까지 다루었던 내용이 애플리케이션에서 소켓 라이브러리, 그리고 리졸버를 통해 DNS 서버에 조회하고 소켓을 만드는 과정까지 다룬 것이다. 그 다음 단계는 OS의 내부이며, 여기에 프로토콜 스택이 존재한다. 프로토콜 스택은 TCP / UDP라..

🌱 들어가기 전 지난 포스팅까지는 어떻게 도메인으로 IP 주소를 얻어오는지 배웠다. 이번 포스팅에서는 OS 내부에 있는 프로토콜 스택에 어떻게 메시지를 송신하도록 하는지, 그 플로우를 알아볼 예정이다. ✔️ 데이터의 송-수신은 어떻게 일어날까? 우선 기본적으로 DNS 서버에 IP 주소를 조회했던 것처럼, 이번에도 소켓 라이브러리를 활용한다. 위 그림을 보면, 어떤 파이프 같은 것을 통해서 데이터가 흐르고 있는 것을 볼 수 있다. 실체화된 것은 아니고, 그저 '데이터의 통로'로서 한쪽 끝에서 다른 쪽 끝까지 파이프를 통해서 데이터가 흐르는 것이다. 여기서 '소켓'이라는 친구가 있는 것을 볼 수 있다. 파이프의 양끝에 존재하는 데이터의 출입구이다. 서버가 소켓을 만들고, 클라이언트에서도 소켓을 만들어서 파이..