[CS] 면접 질문 준비 - 네트워크 3

ssunn·2024년 12월 30일

CS

목록 보기

3/5

이 깃허브 레파지토리의 질문들에 대한 답변 위주로 준비하였습니다.
계정주의 귀찮음 이슈로 가장 최근에 진행한 스터디의 질문들을 먼저 업로드해 순서가 뒤죽박죽일 수 있습니다.

14. DNS에 대해 설명해 주세요.

DNS 서버는 사용자가 웹 브라우저에서 검색하는 웹사이트 도메인 이름을 컴퓨터가 네트워크에서 서로를 식별하는 데 사용하는 숫자 IP 주소로 변환한다. 이 프로세스를 DNS 확인이라고 한다.
DNS 서버는 사용자가 이 프로세스를 원활하게 처리하면서 동시에 많은 트래픽을 수용하고 도메인 이름과 IP 주소를 변경할 수 있게 설계되었다.

DNS(Domain Name System)
도메인 이름 시스템(DNS)은 사용자에게 친숙한 도메인 이름을 컴퓨터가 네트워크에서 서로를 식별하는 데 사용하는 인터넷 프로토콜(IP) 주소로 변환하는 인터넷 표준 프로토콜의 구성 요소입니다.
출처: IBM

*DNS 서버란?

DNS 서버는 사용자가 웹 브라우저에서 검색하는 웹사이트 도메인 이름을 해당하는 숫자 IP 주소로 변환한다. 이 프로세스를 DNS 확인이라고 한다.
DNS 서버는 사용자가 이 프로세스를 원활하게 처리하는 동시에 많은 트래픽을 수용하고 도메인 이름과 IP 주소를 변경할 수 있도록 설계되었다. DNS 확인 프로세스는 부하분산, 서버 및 사용자 위치, 인터넷 연결 강도 등의 변수에 따라 달라진다.

DNS는 몇 계층 프로토콜인가요?

7계층 프로토콜이라 할 수 있다.
DNS는 도메인 주소를 IP 주소로 변환하는 서비스로, 사용자가 직접 다루는 애플리케이션과 네트워크 통신을 연결해주는 역할을 한다. 이 때, 클라이언트 서버 간의 요청/응답을 수행하고, 이는 7계층에서 이루어진다.

UDP와 TCP 중 어떤 것을 사용하나요?

DNS는 기본적으로 UDP를 사용해 통신한다. 단, 데이터 크기가 512바이트를 초과하거나 특정 조건에서는 TCP를 사용할 수 있다.
UDP를 사용하는 이유는 상대적으로 신뢰성 보장이 필요 없으며, 빠른 속도를 보장하기 위해서이다. 또, UDP는 병렬처리가 가능한데, 다수의 클라이언트 요청을 빠르게 처리해야하는 DNS에 적합한 프로토콜이다.

DNS Recursive Query, Iterative Query가 무엇인가요?

recursive query는 dns recursor와 클라이언트를 연결한다. 도메인 이름을 확인해 해당하는 IP 주소를 클라이언트에게 반환하거나, IP 주소를 찾을 수 없음을 알리는 오류 메시지를 반환한다.

iterative query는 dns recursor와 같은 로컬 dns 서버와 root, TLD, 권한 있는 이름 서버와 같은 비로컬 dns 서버를 연결한다. iterative query의 경우 도메인 확인이 필요하지 않다. 단순히 서버에 도메인에 해당하는 정보를 조회하며, root 서버에서는 TLD 서버를, TLD 서버에서는 권한 있는 이름 서버를 참조해 응답을 받는다. 이 때 각 서버에서 받은 응답을 사용할 수 있는 경우에만 단계적으로 참조를 해 검색을 진행한다.

예를 들자면, root 서버에서는 확장자에 따라 어떤 확장자의 TLD 서버를 참조해야하는지 응답을 반환한다. 응답에 해당하는 TLD 서버가 있다면 TLD 서버에서 해당하는 권한 있는 이름 서버를 반환한다. 유효한 경우, 권한 있는 이름 서버에서 최종적으로 IP 주소를 반환받는다.

외에 비재귀적 쿼리도 있다. 비재귀적 쿼리는 dns recursor에서 쿼리에 대한 응답을 찾을 위치를 알고 있는 경우이다. recursive dns server에서 캐시된 응답을 찾거나, root 및 TLD 서버를 건너뛰고 적절한 권한 있는 서버로 직접 이동해 검색 시간을 절약한다.

DNS 쿼리 과정에서 손실이 발생한다면, 어떻게 처리하나요?

재전송을 통해 문제를 해결한다.
DNS 클라이언트는 응답이 지정된 시간 내에 도착하지 않으면 쿼리를 다시 전송한다. 혹은 DNS 리졸버 설정에 따라 다른 DNS 서버로 요청을 전송해 응답을 받을 수도 있다. 몇 차례 재시도한 뒤에도 응답을 받지 못하면 DNS 서버를 찾을 수 없다는 오류를 사용자에게 표시한다.

DNS 서버 간 통신에서도 손실이 발생할 수 있는데, 이 때도 마찬가지로 상위 레벨 DNS 서버가 응답을 기다리다가 일정 시간이 지나면 쿼리를 재시도한다. 이 때의 시간과 재시도는 TTL과 재시도 전략에 따라 이루어진다.

손실이 발생했더라도 캐시에서 유효한 값을 갖고 있는 경우 캐시 데이터를 활용해 결과를 반환한다.

캐싱된 DNS 쿼리가 잘못 될 수도 있습니다. 이 경우, 어떻게 에러를 보정할 수 있나요?

우선 dns가 변경되었을 경우에 발생할 수 있는 에러를 최소화하기 위한 최적화로 TTL 값을 1~5분 정도로 줄여 변경사항 반영을 빠르게 한다. 변경 완료 후 다시 TTL 값을 1~24시간 정도의 정상 수준으로 설정한다.

이미 오류가 발생했다면 클라이언트와 서버에서 dns cache flushing을 실행한다. 그러면 서버 측에서 DNS 서비스 제공업체에 캐시 갱신을 요청할 것이다. 또, DNSSEC 및 Anycast 기반 서비스를 사용해 무결성과 최신 데이터를 보장하는 방법도 있다. DNSSEC을 활성화 함으로써 권한 있는 네임서버가 서명한 DNS 데이터를 제공해 클라이언트에서 데이터 무결성을 검증하고 위조된 데이터를 무시할 수 있다. Anycast 기반 DNS 서비스를 활용하는 경우, 전세계의 여러 서버를 통해 요청을 분산 처리할 수 있으며, 최신 데이터를 제공하도록 지원할 수 있다.

캐싱된 DNS 쿼리에 대해 지속적인 모니터링을 위해 DNS 요청/응답 상태를 실시간으로 모니터링하는 도구를 활용하는 방법도 있다.

DNS 레코드 타입 중 A, CNAME, AAAA의 차이에 대해서 설명해주세요.

A 레코드는 도메인을 IPv4 주소로 매핑하며, AAAA는 도메인을 IPv6 주소로 매핑한다. CNAME은 도메인을 다른 도메인으로 매핑한다.

CNAME에 대해 조금 더 자세히 설명하자면, 별칭 도메인을 사용해도 실제 정식 도메인으로 요청을 전달할 수 있도록 설정하는 데 사용한다.

ex)

www.example.com → example.com
blog.example.com → hostingplatform.example.net

그래서 CNAME은 항상 도메인 이름끼리 매핑하며, 직접 IP 주소로 매핑할 수 없다. IP 주소를 매핑하려면 A 레코드나 AAAA 레코드를 사용해야한다.

[참고]
DNS에 저장된 데이터 유형:

A 레코드: 도메인을 IPv4 주소로 매핑.
AAAA 레코드: 도메인을 IPv6 주소로 매핑.
CNAME 레코드: 도메인을 다른 도메인으로 매핑.
MX 레코드: 메일 서버 정보를 지정.

hosts 파일은 어떤 역할을 하나요? DNS와 비교하였을 때 어떤 것이 우선순위가 더 높나요?

hosts 파일은 dns가 나오기 이전 도메인 이름과 IP 주소를 수동으로 매핑하기 위해 사용했던 파일이다. 모든 컴퓨터가 hosts 파일에 인터넷에 연결된 모든 컴퓨터 이름과 IP 주소를 수동으로 기록해야했고, 인터넷 규모가 커지고 네트워크 노드가 급증하면서 hosts 파일로 모든 IP 주소를 관리하는 것이 어려워 DNS가 나오게 되었다.

현재 hosts 파일은 주로 특정 목적을 위해 제한적으로 사용된다.

로컬 개발 환경
- 로컬에서 특정 도메인을 테스트하기 위해 IP 주소 매핑
- 개발자들이 DNS 설정 없이도 도메인 기반 테스트를 쉽게 할 수 있음
도메인 차단
- 특정 도메인을 차단하기 위해 hosts 파일에 매핑
DNS 장애 시 백업
- DNS 서버가 일시적으로 장애를 겪을 경우, 특정 도메인을 수동으로 매핑해 문제를 회피
보안 목적
- 악성 도메인을 localhost로 리디렉션 해 피해 방지
네트워크 성능 개선
- DNS 요청을 우회하고 직접 IP를 매핑해 특정 서비스에 더 빠르게 접근

hosts 파일은 운영체제의 네임 리졸루션 순서에서 DNS 보다 우선한다. 즉, hosts 파일에 매핑된 도메인이 있으면 DNS를 조회하기 전에 hosts 파일의 IP 주소를 사용한다.

그래서 hosts 파일에 매핑된 도메인이 존재하는 경우, 다음 순서로 IP 주소를 검색하게 된다.

hosts 파일 확인
캐시된 DNS 레코드 확인
DNS 서버 쿼리

다만 OS에 따라 설정을 통해 우선순위를 조정할 수 있다.

15. SOP 정책에 대해 설명해 주세요.

SOP(Same-Origin Policy)는 웹 브라우저에서 실행 중인 스크립트가 동일한 출처(origin)에 속하지 않는 리소스에 액세스 하는 것을 제한하는 보안 메커니즘이다.

이 때 출처(origin)라 함은, URL의 세가지 구성 요소를 기준으로 정의된다. 프로토콜(http, https), 호스트(naver.com), 포트(:80, :443)

ex) 다음 URL은 동일한 출처로 간주된다.

https://example.com
https://example.com:443

그러나 다음은 출처가 다르다.

http://example.com //프로토콜이 다름
https://example.org //호스트가 다름
https://example.com:8080 //포트가 다름

CORS 정책이 무엇인가요?

Cross-Origin Resource Sharing

교차 출처 요청을 허용하거나 제한하는 정책이다. 이는 HTTP 헤더 기반 메커니즘으로, 브라우저에서 SOP에 의해 차단될 수 있는 요청을 서버가 허용하도록 설정할 수 있게 한다. 이를 통해 서로 다른 출처의 리소스 간 상호작용을 제어하고 필요할 경우 안전하게 데이터를 공유할 수 있다.

Preflight에 대해 설명해 주세요.

클라이언트가 민감한 요청을 보내려 할 때, 브라우저가 사전 확인을 수행하는 절차이다. 클라이언트가 민감한 교차 출처 요청을 하기 전에 브라우저는 서버에 OPTIONS 요청을 보내 요청이 허용되는지 확인할 수 있다.

CORS는 브라우저와 서버 간의 HTTP 헤더 교환을 통해 동작하는데, 이 때 Preflight 요청을 통해 요청이 허용되는지 확인할 수 있다.

[참고]
Preflight 요청은 CORS의 일환으로, 브라우저가 실제 요청을 보내기 전에 서버에 해당 요청이 안전한지 확인하기 위해 보내는 사전 요청이다. 이는 주로 단순 요청이 아닌 복잡한 요청(Preflighted Requests)에 해당하는 경우에 발생한다.

*Preflight 요청의 목적

보안 강화: 서버가 실제 요청을 허용할지 결정하기 전에 브라우저가 서버의 정책을 확인할 수 있도록 합니다.
서버 리소스 보호: 서버가 예상치 못한 출처로부터의 요청을 사전에 차단할 수 있습니다.

*동작 방식

Preflight 요청 (OPTIONS 메서드):
- 브라우저는 실제 요청을 보내기 전에 OPTIONS 메서드를 사용하여 Preflight 요청을 보냅니다.
- 요청 헤더에는 Access-Control-Request-Method와 Access-Control-Request-Headers가 포함되어 있어 서버가 실제 요청에서 사용될 메서드와 헤더를 미리 알 수 있습니다. 예시:
```
OPTIONS /resource HTTP/1.1
Host: api.example.com
Origin: <https://www.mywebsite.com>
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
```
서버의 응답:
- 서버는 Access-Control-Allow-Methods와 Access-Control-Allow-Headers 헤더를 포함하여 어떤 메서드와 헤더를 허용하는지 명시합니다.
- 또한, Access-Control-Allow-Origin 헤더를 사용하여 허용된 출처를 지정합니다. 예시:
```
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: <https://www.mywebsite.com>
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
```

16. Stateless와 Connectionless에 대해 설명해 주세요.

Stateless
각 요청과 응답이 독립적으로 처리되며, 서버는 이전 요청의 상태를 기억하지 않는다.
이는 서버 간 부하 분산에 유리하며, 상태를 관리하는 작업이 없기 때문에 설계와 구현이 단순하다.
그러나 상태를 유지하지 않기 때문에 사용자 인증과 같은 상태 유지가 필요한 기능 구현이 어렵다는 단점이 있는데, 이는 쿠키나 세션과 같은 상태 정보를 저장할 수 있는 기능들로 보완 가능하다.

Connectionless
클라이언트가 서버에 요청을 보내고 서버가 응답을 반환하면 연결을 바로 종료한다.
불필요한 연결 유지를 하지 않기 때문에 자원 낭비를 방지할 수 있으며, 대규모 트래픽 환경에서 더 많은 사용자 요청을 처리할 수 있어 효율적이다.
그러나 요청마다 새롭게 연결을 생성하기 때문에 연결 설정/해제에 따른 오버헤드가 발생할 수 있으며, 여러 요청을 처리할 때 연결 생성이 반복적으로 이루어져 성능이 저하될 수 있다. 이를 해결하기 위해 HTTP/1.1에서는 keep-alive를 도입했으며, HTTP/2.0과 HTTP/3.0에서는 여러 요청을 하나의 연결에서 동시에 처리하는 multiplexing을 도입해 연결 성능과 효율성을 극대화 하였다.

왜 HTTP는 Stateless 구조를 채택하고 있을까요?

서버 간 부하 분산에 유리하기 때문이다. 서버 간 부하 분산에 유리한 이유는 상태를 유지할 필요가 없기 때문에 모든 요청을 독립적으로 처리할 수 있기 때문이다. 즉, 특정 서버에 클라이언트를 고정시키지 않아도 되는 유연성이 보장된다는 것이며, 이는 부하 분산-load balancing을 가능하게 한다.

Connectionless의 논리대로면 성능이 되게 좋지 않을 것으로 보이는데, 해결 방법이 있을까요?

해결책으로 HTTP/1.1에서는 keep-alive를 도입했고, HTTP/2.0과 HTTP/3.0에서는 멀티플렉싱을 지원한다.

HTTP/1.1의 keep-alive는 하나의 TCP 연결을 통해 여러 요청을 처리할 수 있다. 다만 문제는 여러 요청을 동시에 처리할 수 없기 때문에 요청이 들어온 순서대로 순차 처리할 수 밖에 없다는 것이다. 이렇게 되면 앞의 요청 처리가 늦어져 완료되지 않으면 뒤의 요청들이 모두 대기 상태에 빠지는 HOL Blocking을 초래할 수 있다.

이를 해결하기 위해 HTTP/2.0과 HTTP/3.0에서 멀티플렉싱을 지원한다. 멀티플렉싱은 여러 요청을 하나의 연결에서 동시에 처리하는 작업이다. 멀티플렉싱에서 각 요청과 응답은 독립적인 스트림을 통해 전송되므로 서로 간섭하지 않게 된다.

*보충해서 공부해 볼 내용: CDN

TCP의 keep-alive와 HTTP의 keep-alive의 차이는 무엇인가요?

TCP의 keep-alive는 네트워크 연결이 끊어지지 않도록 유지하는 데에 초점이 맞춰져 있으며, 주로 MQ, Kafka 등 지속적인 연결이 필요한 TCP 기반 서비스에서 사용된다.
TCP keep-alive는 유휴 상태에서만 동작한다. 즉, 데이터 전송이 없는 유휴 상태에서 연결이 여전히 살아있는지 확인하기 위해 작동하는 것이다. 데이터가 지속적으로 교환되고 있는 동안에는 keep-alive 패킷이 필요하지 않으며, TCP 연결은 데이터를 주고받는 과정에서 자연스럽게 유지된다.

HTTP keep-alive는 요청과 응답 간의 TCP 연결 재사용을 목적으로 하며, 애플리케이션 계층의 명시적 동작이 포함된다. HTTP keep-alive가 타임아웃 또는 설정에 따라 능동적으로 연결을 종료하는 것과 달리 TCP keep-alive는 단순히 연결 상태를 점검하며, 종료의 주도권은 네트워크 계층에 있다. (따라서 수동적이라고 한다)

*HTTP keep-alive VS websocket
HTTP Keep-Alive는 클라이언트가 서버와 한 번 연결되면, 제한 시간 내에는 신뢰할 수 있는 연결을 위해 3-way Handshake의 반복 작업으로 발생시킬 수 있는 오버헤드가 없어지는 것이다.
하지만 연결이 되어 있는 동안 결국 Keep-Alive도 HTTP의 요청 및 응답 방식을 따르기 때문에, 클라이언트가 서버에 데이터를 요청하고 응답받는 것은 가능하지만, 서버가 원할 때에 클라이언트에게 데이터를 보내줄 수는 없다. (여전히 단방향)
하지만 WS 프로토콜은 양방향이므로, 서버 또한 언제든 원할때 클라이언트에게 데이터를 보내줄 수 있다.

17. 라우터 내의 포워딩 과정에 대해 설명해 주세요.

라우터 내의 forwarding 과정은 입력된 네트워크 패킷을 적절한 출력 포트로 전달하는 작업을 의미한다. 즉, routing이 네트워크 경로를 결정하는 작업이라면 forwarding은 이미 결정된 경로를 따라 실제로 패킷을 전달하는 작업이다.

forwarding은 다음 과정을 거친다.
수신한 패킷의 헤더를 확인하고, 헤더의 목적지 IP 주소를 기반으로 라우팅 테이블을 조회해 다음 홉과 출력 포트를 결정한다. 이후 TTL을 감소하고 ARP를 사용해 해당 IP 주소에 대한 MAC 주소를 알아낸다. 이후 적절한 출력 포트를 통해 패킷을 전송한다.

패킷 수신: 라우터의 입력 포트에서 네트워크 패킷을 수신한다.
헤더 분석: 네트워크 계층에서 IP 패킷의 IP 헤더를 확인한다. 이 때 IP 헤더에는 목적지 IP 주소, TTL(패킷의 수명이 남은 시간)과 같은 필드가 포함된다.
라우팅 테이블 조회: 라우터는 목적지 IP 주소를 기반으로 라우팅 테이블을 조회하여 다음 홉과 출력 포트를 결정한다.
- 목적지 네트워크 주소
- 서브넷 마스크
- 게이트웨이
- 출력 포트
TTL 감소: 패킷의 TTL을 1 감소시킨다. 만약 TTL이 0이 되면 패킷을 폐기하고 ICMP Time Exceeded 메시지를 송신한다.
ARP 사용: 다음 홉의 IP 주소를 확인한 후, 해당 IP 주소에 대한 MAC 주소를 알아낸다. 이 때 ARP 캐시를 확인하거나 ARP 요청을 통해 MAC 주소를 조회한다.
출력 포트로 전달: 적절한 출력 포트를 통해 패킷을 전송한다. 이 때 패킷을 데이터 링크 계층의 프레임으로 캡슐화해 네트워크로 보낸다.

라우팅과 포워딩의 차이는 무엇인가요?

라우팅(Routing)
출발지에서 목적지까지의 경로를 결정하는 것

포워딩(Forwarding)
라우터의 입력 포트에서 출력 포트로 패킷을 이동시키는 것

라우팅은 출발지에서 목적지까지의 최적의 경로를 결정해 라우팅 테이블을 생성하는 것이다. 목적은 경로를 탐색하고 라우팅 정보를 학습하는 것이라 할 수 있다.

포워딩은 수신한 패킷을 헤더 정보 기반으로 적절한 출력 포트로 전달하는 과정으로 라우팅 테이블에 기록된 정보를 바탕으로 결정된 경로를 따라 패킷을 전달하는 것이 목적이다.

라우팅 알고리즘에 대해 설명해 주세요.

라우팅 알고리즘은 네트워크에서 데이터를 전달하기 위한 최적의 경로를 결정하는 데 사용되는 알고리즘이다. 최적의 경로를 탐색하면서도 특정 경로에 트래픽이 집중되지 않도록 부하를 분산해야한다.

라우팅 알고리즘에는 정적 라우팅과 동적 라우팅이 있다.
정적 라우팅은 관리자에 의해 수동으로 경로를 결정해야한다. 단순하고 네트워크 부하가 적으나 네트워크 변경 시 관리자가 수동으로 수정해야하므로 주로 소규모 네트워크에서 사용한다.
동적 라우팅은 라우터가 자동으로 경로를 계산하고 갱신한다. 네트워크 변화에 동적으로 적응 가능하지만 라우팅 프로토콜 실행으로 추가적인 오버헤드가 발생할 수 있다. 동적 라우팅은 대규모 및 동적으로 변하는 네트워크 환경에서 사용한다.

보편적으로 많이 사용하는 알고리즘에는 거리 벡터 알고리즘과 링크 상태 알고리즘이 있다.

[단계별 답변을 위한 준비, 라우팅 알고리즘으로 사용되는 알고리즘의 종류와 특징에 대한 서술을 원할 경우 아래 답변 참고]

거리 벡터 알고리즘은 라우터가 목적지 네트워크까지의 최소 홉 수를 계산하여 경로를 선택하는 방식으로 주기적으로 인접 라우터와 정보를 교환해야한다. 대표적인 예로 RIP 프로토콜이 있다. 링크 상태 알고리즘은 모든 라우터가 네트워크의 전체 토폴로지를 수집하는데, 다익스트라 알고리즘을 사용해 최단 경로 트리를 생성해 목적지까지의 경로를 라우팅 테이블에 저장한다. 대표적인 예로 OSPF 프로토콜이 있다.

링크 상태 알고리즘은 주로 기업 네트워크, 대규모 데이터 센터와 같은 내부 라우팅에 사용하며, 경로 벡터 알고리즘은 사로 다른 자율 시스템 간 라우팅 즉, 외부 라우팅에 사용한다.

RIP 예시 (거리 벡터 알고리즘):
- 라우터가 목적지 네트워크까지의 최소 홉 수를 계산하여 경로 선택.
- 주기적으로 인접 라우터와 정보를 교환.
OSPF 예시 (링크 상태 알고리즘):
- 모든 라우터가 네트워크의 전체 토폴로지를 수집.
- 다익스트라 알고리즘을 사용해 최단 경로 트리(SPT)를 생성.
- 목적지까지의 경로를 라우팅 테이블에 저장.

거리 벡터 알고리즘(Distance Vector Algorithm) vs 링크 상태 알고리즘(Link State Algorithm)

(1) 거리 벡터 알고리즘

개념:
- 라우터가 인접 라우터로부터의 거리 정보를 기반으로 경로를 계산.
- 각 라우터는 자신이 알고 있는 목적지까지의 거리와 방향(벡터)을 인접 라우터와 주기적으로 공유.
특징:
- 경로 계산 시 벨만-포드(Bellman-Ford) 알고리즘을 사용.
- 전체 네트워크 정보를 알지 못하며, 인접 라우터의 정보에 의존.
- 라우팅 테이블 갱신이 느리며, 카운트-투-인피니티 문제가 발생할 수 있음.
예시:
- RIP(Routing Information Protocol).

(2) 링크 상태 알고리즘

개념:
- 라우터가 전체 네트워크 토폴로지 정보를 수집하여 경로를 계산.
- 모든 라우터가 동일한 네트워크 맵을 가지고 있으며, 이를 기반으로 다익스트라 알고리즘으로 최단 경로를 계산.
특징:
- 더 빠르고 정확한 경로 계산이 가능.
- 네트워크 부하가 증가할 가능성 있음(토폴로지 정보 전송 및 저장 필요).
예시:
- OSPF(Open Shortest Path First), IS-IS(Intermediate System to Intermediate System).

포워딩 테이블의 구조에 대해 설명해 주세요.

포워딩 테이블은 라우터나 스위치가 패킷을 목적지로 전달하기 위해 사용하는 데이터 구조이다. 포워딩 테이블은 라우팅 테이블을 기반으로 생성되며, 라우터의 주요 역할 중 하나인 패킷 포워딩을 빠르게 수행할 수 있도록 최적화된 형태로 저장된다.

포워딩 테이블의 구조는 네트워크 계층(IP 주소 기반)인지, 데이터 링크 계층(MAC 주소 기반)인지에 따라 다르지만, 일반적으로 다음과 같은 필드를 포함한다.

네트워크 계층 포워딩 테이블(IP 주소 기반)
- 목적지 네트워크 주소: 목적지 IP 주소 또는 네트워크 범위
- 서브넷 마스크: 네트워크 범위를 결정하기 위한 비트 마스크
- 다음 홉: 패킷이 전달될 다음 라우터의 IP 주소
- 출력 인터페이스: 패킷을 전송할 라우터의 물리적 포트
- 메트릭: 경로 비용 또는 우선순위
데이터 링크 계층 포워딩 테이블(MAC 기반)
- MAC 주소: 목적지 장치의 물리적 주소
- 출력 포트: 패킷을 전송할 스위치 포트
- VLAN 정보: 가상 LAN 환경에서 VLAN ID를 포함

*홉(Hop): 네트워크 경로에서 패킷이 한 네트워크 장치에서 다음 네트워크 장치로 이동하는 과정
패킷이 출발지에서 목적지까지 도달하는 동안 거치는 네트워크 장치 간의 점프 횟수

포워딩 테이블과 라우팅 테이블의 차이

라우팅 테이블은 경로를 계산하고, 네트워크의 전반적인 경로 정보(Next Hop, 메트릭 등)를 포함합니다.
포워딩 테이블은 라우팅 테이블에서 생성된 정보를 기반으로, 패킷 포워딩에 최적화된 형태로 저장된 데이터 구조입니다.

특징	라우팅 테이블	포워딩 테이블
목적	최적 경로를 계산하고 저장	실시간 패킷 전송을 위한 포트 결정
관리 주체	라우팅 프로토콜(OSPF, BGP 등)	포워딩 엔진
내용	목적지 네트워크, 메트릭, Next Hop 등	목적지 주소와 출력 포트의 매핑
동작 위치	제어 평면(Control Plane)	데이터 평면(Data Plane)

18. 로드밸런서가 무엇인가요?

로드 밸런서는 여러 서버로 들어오는 네트워크 트래픽을 분산하여 서버의 부하를 균등하게 분배하는 장치 또는 소프트웨어이다. 로드밸런서는 클라이언트 요청을 여러 서버로 분산해 서버 간 부하를 균등하게 유지하며, 특정 서버에 문제가 발생하면 요청을 자동으로 다른 서버로 전환해 장애를 조치할 수 있다.

*로드 밸런싱
애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법이다. 로드밸런서는 대규모 트래픽을 처리하기 위해 사용자와 서버 그룹 사이에 위치해 서버에 가해지는 트래픽을 여러 대의 서버에 고르게 분배하는 디바이스이다. 동시에 모든 리소스 서버가 동일하게 사용되도록 한다.

로드 밸런서의 작동 방식 - 클라이언트 요청 처리 과정

사용자가 웹사이트에 접속하거나 API를 호출합니다.
클라이언트 요청은 로드 밸런서로 전달됩니다.
로드 밸런서는 설정된 분산 알고리즘을 기반으로 트래픽을 적절한 서버로 전달합니다.
선택된 서버가 요청을 처리하고, 응답을 클라이언트에게 전달합니다.

L4 로드밸런서와, L7 로드밸런서의 차이에 대해 설명해 주세요.

L4 로드밸런서는 4계층에서 작동하고, L7 로드밸런서는 7계층에서 작동한다. 둘 모두 트래픽 분산에 사용하지만 L4 로드밸런서는 단순한 트래픽 분산과 고성능이 필요한 환경에 사용하며, TCP/UDP 기반 서비스에 적합하다. L7 로드밸런서는 HTTP/HTTPS 트래픽을 세밀하게 분석하고 제어해야하는 환경에 적합하며 특정 요청 유형별로 분산이 필요한 복잡한 애플리케이션에 적합하다.

즉, L4 로드밸런서는 고성능과 단순한 트래픽 분산에 적합하고, L7 로드밸런서는 HTTP/HTTPS 기반 서비스에서 정교한 제어가 필요한 경우에 주로 사용된다. 환경과 요구사항에 따라 적절히 선택하거나 둘을 조합해 사용하는 경우도 많다.

*L4 로드밸런서가 L7 로드밸런서보다 더 빠른 이유?

L7 로드밸런서는 7계층까지 헤더를 까봐야하는데 L4 로드밸런서는 4계층까지만 까도 됨. 7계층에서는 헤더를 까서 그 안의 HTTP 헤더, URL, 쿠키 같은 정보들을 모두 확인해봐야하는 반면 L4 로드밸런서에서는 IP 주소, 포트 번호 외의 상세 정보 확인까지 필요하지 않기 때문에 비교적 속도가 빠름

항목	L4 로드 밸런서	L7 로드 밸런서
작동 계층	OSI 4계층 (TCP/UDP)	OSI 7계층 (HTTP/HTTPS 등 애플리케이션 데이터)
트래픽 기준	IP 주소, 포트 번호	HTTP 헤더, URL, 쿠키, 메서드 등
트래픽 제어 세밀도	낮음	높음
성능	고속, 처리량이 많음	처리량 낮을 수 있음 (데이터 분석 오버헤드)
설정 난이도	상대적으로 간단	복잡
사용 사례	TCP/UDP 기반 서비스 (VoIP, 게임, 스트리밍 등)	HTTP/HTTPS 기반 서비스 (웹 애플리케이션, API)
고급 기능 지원	제한적 (데이터 분석 불가)	SSL 오프로드, 경로 기반 분배, 세션 유지 등

로드밸런서 알고리즘에 대해 설명해 주세요.

로드밸런서 알고리즘은 클라이언트로부터 들어오는 요청을 여러 서버로 어떻게 분배할지 결정하는 방식이다.

*정적 알고리즘

특징
- 서버의 현재 상태와 관계없이 미리 정의된 규칙에 따라 요청을 분배
- 간단하고 설정이 쉬움
사용 사례
- 서버의 성능이 동일하고 부하 변화가 크지 않은 환경
알고리즘 종류
- 라운드 로빈
- 가중 라운드 로빈
- IP 해싱

*동적 알고리즘

특징
- 서버의 실시간 상태(현재 부하, 응답 속도 등)를 기반으로 요청을 분배
- 서버의 성능과 네트워크 상황이 자주 변하는 환경에서 적합
사용 사례
- 트래픽 패턴이 변화하거나 서버 성능이 다양한 환경
알고리즘 종류
- 최소 연결
- 최소 응답 시간
- 리소스 기반

로드밸런싱 대상이 되는 장치중 일부 장치가 문제가 생겨 접속이 불가능하다고 가정해 봅시다. 이 경우, 로드밸런서가 해당 장비로 요청을 보내지 않도록 하려면 어떻게 해야 할까요?

헬스 체크(Health Check)
로드 밸런서가 주기적으로 대상 서버의 상태를 확인하여 비정상적인 서버를 트래픽 분산 대상에서 제외한다

*헬스 체크 설정 방법
1. 작동 원리
- 로드 밸런서는 주기적으로 각 서버에 요청을 보내 서버 상태를 확인한다.
- 서버가 응답하지 않거나 비정상적인 상태일 경우 로드 밸런서는 해당 서버를 비활서오하하고 트래픽을 다른 서버로 분배한다.
- 서버가 정상적으로 복구되면 로드 밸런서가 이를 감지하여 다시 트래픽 대상에 포함시킨다.
2. 유형
- TCP 헬스 체크: 서버의 특정 포트가 열려 있는지 확인, 간단한 네트워크 연결 상태 확인에 적합
- HTTP/HTTPS 헬스 체크: 특정 URL로 HTTP/HTTPS 요청을 보내고, 상태 코드를 확인한다. 서버 애플리케이션이 정상적으로 작동하는지 확인 가능하다.
- 커스텀 헬스 체크: 서버에서 특정 상태를 반환하도록 구성한 스크립트나 엔드포인트를 호출한다.

*헬스 체크 설정 방법 예시
1. Nginx
2. AWS Elastic Load Balancer(ELB)
3. HAProxy

*헬스 체크 구현 시 고려사항
1. 헬스 체크 주기: 너무 짧으면 서버에 부하를 줄 수 있고, 너무 길면 문제 감지가 지연될 수 있으므로 일반적으로 5~30초 사이로 설정한다.
2. 상태 확인 조건: HTTP 상태 코드 뿐만 아니라 응답 내용까지 확인하는 커스텀 로직을 구현할 수 있다.
3. 복구 확인: 서버가 복구되었을 때 다시 활성화되도록 설정한다.
4. Failover와 복구: 장애 발생 시 다른 서버로 트래픽을 빠르게 전환(Failover)하는 것과 복구된 서버를 다시 대상에 포함시키는 로직이 필요하다.

로드밸런서 장치를 사용하지 않고, DNS를 활용해서 유사하게 로드밸런싱을 하는 방법에 대해 설명해 주세요.

로드밸런싱 알고리즘을 DNS 서버에 적용하는 방식으로 사용할 수 있는 것으로 알고 있다.

라운드로빈 DNS, 가중 라운드로빈 DNS 등으로 로드밸런싱 할 수 있으며 정상 작동하는 서버로만 트래픽을 보낼 수 있는 DNS Failover도 구현할 수 있다. 다만 규모가 큰 서비스에는 적합하지 않고 트래픽이 많지 않거나 간단한 부하 분산만 필요한 경우에 적합하다.

위 같은 기능은 자체 DNS 서버를 사용해 구현할 수 있으며, Cloudflare, AWS Route 53, Google Cloud DNS와 같은 관리형 DNS 서비스를 사용하는 방식도 있다.

*헬스 체크가 어렵다?
DNS 서버는 단순히 도메인에 해당하는 IP 주소를 검색하고 반환해주는 역할만을 하기 때문에 해당 IP 주소의 서버가 유효한지를 확인하는 헬스 체크는 어렵다.

19. 서브넷 마스크와, 게이트웨이에 대해 설명해 주세요.

서브넷 마스크
IP 주소를 네트워크 주소와 호스트 주소로 구분하는 데 사용된다. 네트워크가 더 작은 서브넷으로 나뉠 때, 서브넷 마스크는 각 서브넷의 범위를 정의한다.

게이트웨이
게이트웨이는 다른 네트워크와의 통신 경로를 제공하는 장치로 로컬 네트워크에서 외부 네트워크로 데이터를 보내는 출구 역할을 한다.
게이트웨이는 보통 로컬 네트워크 내에서 라우터의 IP 주소로 설정된다.

NAT에 대해 설명해 주세요.

NAT(Network Address Translation)
네트워크의 IP 주소를 변환하는 기술로 내부 네트워크의 프라이빗 IP 주소를 외부 네트워크에서 사용하는 공인 IP 주소로 변환하거나 그 반대로 변환하는 데 사용한다. NAT는 IPv4 주소 부족 문제를 해결하고 네트워크 보안을 강화하며 특정 네트워크 구조 관리를 가능하게 한다.

static NAT VS dynamic NAT
static NAT는 사설망과 공인망이 1:1 매핑
dynamic NAT도 1:1 매핑이 되긴 하지만 동적으로 할당, 사용하지 않으면 반납

서브넷 마스크의 표현 방식에 대해 설명해 주세요.

2가지 주요 방식으로 표현된다.

점-십진수 표기
서브넷 마스크를 IPv4 주소와 같은 형식으로 표현한 것으로 32비트 이진수로 이루어진 서브넷 마스크를 8비트씩 끊어 십진수로 변환 후 점으로 구분한다.
ex) 255.255.255.0
CIDR 표기(Classless Inter-Domain Routing)
서브넷 마스크를 슬래시와 함께 네트워크 부분의 비트 수로 표현한다.
네트워크 주소 뒤에 /네트워크 비트 수를 붙이는 방식
ex) 192.168.1.0/24 → 서브넷 마스크는 255.255.255.0

그렇다면, 255.0.255.0 같은 꼴의 서브넷 마스크도 가능한가요?

255.0.255.0은 올바른 서브넷 마스크 형식이 아니다.

서브넷 마스크는 32비트 길이의 이진수로 표현되는데 1로 채워진 비트는 반드시 연속적이어야 하며, 1뒤에 0이 나오기 시작하면 이후 비트는 모두 0이어야 한다.

20. 멀티플렉싱과 디멀티플렉싱에 대해 설명해 주세요.

멀티플렉싱(Multiplexing)
여러 데이터 스트림을 하나의 물리적 링크 또는 논리적 채널로 결합해 전송하는 기능이다.
즉, 네트워크 자원을 효율적으로 사용하기 위해 여러 데이터 스트림을 합쳐 전송하는 기능이다.

디멀티플렉싱(Demultiplexing)
멀티플렉싱된 데이터를 원래의 개별 데이터 스트림으로 복원하는 기술이다.
수신측에서 수행되며, 데이터 패킷의 식별자를 사용해 각 스트림을 올바른 애플리케이션이나 프로세스로 전달한다.

즉, 송신측에서 여러 데이터 스트림을 하나로 합쳐 전송하는 것이 멀티플렉싱이고 수신측에서 이를 받아 멀티플렉싱된 데이터를 원래의 개별 데이터 스트림으로 복원해 올바른 애플리케이션으로 전달하는 과정이 디멀티플렉싱이다.

디멀티플렉싱의 과정에 대해 설명해 주세요.

데이터 수신: 수신측은 네트워크를 통해 멀티플렉싱된 데이터 패킷을 받는다. 이 때 각 데이터 패킷에는 송신자와 수신자의 IP 주소, 포트 번호와 같은 식별 정보가 포함되어 있다.
데이터 식별: 수신된 패킷에서 헤더 정보를 분석해 각 데이터 스트림을 구분한다.
- 네트워크 계층: IP 주소 확인
- 전송 계층: 포트 번호 확인
- 응용 계층: 프로토콜
디멀티플렉싱 과정에서 중요한 정보는 다음과 같습니다:
1. 네트워크 계층(IP):
  - 수신된 패킷의 IP 주소를 확인하여 패킷이 올바른 장치에 도착했는지 확인.
2. 전송 계층(TCP/UDP):
  - 패킷의 포트 번호를 확인하여 데이터가 올바른 애플리케이션으로 전달되도록 함.
3. 응용 계층(HTTP, FTP 등):
  - 특정 애플리케이션의 프로토콜을 기반으로 데이터 처리.
데이터 스트림 분리: 식별된 정보를 기반으로 패킷을 개별 스트림으로 분리한다. 수신된 데이터는 네트워크 계층에서 전송 계층, 응용 계층 순으로 전달되며 각 단계에서 디멀티플렉싱이 수행된다.
데이터 전달: 분리된 각 데이터 스트림은 적절한 프로세스나 애플리케이션에 전달된다.

Demultiplexing:
- 수신된 여러 편지(데이터)를 열어 보고, 각 편지가 누구에게 가야 하는지 확인하고 전달.
- "누가 받을지"를 결정하는 우편 배달원 역할.
Peer-to-Peer Encapsulation:
- 편지를 봉투에 넣고 주소와 정보를 작성(캡슐화)한 후, 수신자가 봉투를 열어 확인(디캡슐화).
- 데이터를 전송 가능한 형태로 포장하거나 풀어내는 과정.

XSS에 대해서 설명해 주세요.

XSS(Cross-Site Scripting)은 웹 애플리케이션에서 악성 스크립트를 주입해 클라이언트 측에서 실행되도록 만드는 보안 취약점이다. 공격자는 XSS를 이용해 피해자의 브라우저에서 악성 코드를 실행해 세션 탈취, 사용자 데이터 도용, 피싱 공격 등을 수행할 수 있다.

CSRF랑 XSS는 어떤 차이가 있나요?

XSS는 사용자의 브라우저에서 악성 스크립트를 실행하는 것이고, CSRF는 사용자가 의도하지 않은 요청을 서버에 전송하는 것이다.

따라서 XSS는 클라이언트가 피해를 본다. 세션 탈취, 민감한 정보 도용 등의 피해를 입게 된다. CSRF는 서버가 피해를 본다. 피해 사용자의 권한으로 악의적인 요청을 서버에서 수행하기 때문이다.

XSS로 사용자는 쿠키, 세션, 브라우저 데이터를 탈취 당할 수 있으며, CSRF로 서버는 원치 않은 데이터 변경이나 서버 자원 삭제 또는 추가 등의 요청을 수행 당할 수 있다.

XSS와 CSRF의 주요 차이

특징	XSS (Cross-Site Scripting)	CSRF (Cross-Site Request Forgery)
공격 목적	사용자의 브라우저에서 악성 스크립트를 실행.	사용자가 의도하지 않은 요청을 서버에 전송.
주요 피해 대상	클라이언트(사용자): 세션 탈취, 민감한 정보 도용.	서버: 피해 사용자의 권한으로 악의적인 요청 수행.
공격 방식	- 웹 애플리케이션의 취약점을 이용해 악성 스크립트를 주입.- 스크립트는 브라우저에서 실행됨.	- 피해 사용자가 인증된 상태에서 악의적인 요청을 전송.- 요청은 피해자의 인증 세션을 이용.
주요 취약점 원인	사용자 입력이 제대로 검증되지 않고 클라이언트로 반환.	CSRF 토큰 미사용 또는 Referer 검증 미흡.
공격 성공 조건	- 공격자가 악성 스크립트를 삽입.- 사용자가 해당 스크립트를 실행.	- 사용자가 로그인된 상태.- 악의적인 요청을 수행할 수 있는 상태.
결과	- 쿠키, 세션, 브라우저 데이터 탈취.- 웹 페이지 변조.	- 데이터 변경(계정 수정, 송금 등).- 서버 자원 삭제 또는 추가.
방어 방법	- 입력 검증 및 출력 인코딩.- CSP(Content Security Policy) 설정.- HTTPOnly 쿠키 설정.	- CSRF 토큰 사용.- Referer 또는 Origin 헤더 검증.- SameSite 쿠키 설정.

XSS는 프론트엔드에서만 막을 수 있나요?

서버측에서도 막을 수 있다. 서버 측에서는 프론트에서 넘어오는 모든 사용자 입력을 신뢰하지말고 철저히 검증한다.

사용자 입력 검증을 위해 화이트리스트를 사용하고 입력 길이를 제한하고 특수 문자를 필터링 하는 등의 검증을 수행한다.

또 출력 시 적절한 인코딩을 거치거나 브라우저에 허용된 스크립트 소스를 지정하는 CSP를 사용하는 방법도 있다.

*요약: 서버에서 XSS를 막기 위한 단계
1. 입력 검증: 사용자 입력을 철저히 검증 및 필터링.
2. 출력 인코딩: 컨텍스트에 맞는 인코딩 적용.
3. CSP 설정: 스크립트 소스를 제한하여 XSS 방어.
4. HTTPOnly 쿠키 설정: JavaScript로 쿠키 접근 차단.
5. 보안 라이브러리 사용: OWASP Encoder, DOMPurify 등 활용.
6. 정규화 및 태그 제거: 중복 인코딩 방지 및 HTML 태그 제거.
7. 보안 테스트: 정기적으로 취약성을 점검.

참고

IBM - DNS 서버란 무엇인가요?
IBM - 도메인 이름 시스템(DNS)란 무엇인가요?
[DNS] 동작 원리를 꼼꼼하게 살펴보자!
로드밸런서(Load Balancer)란?
AWS - 로드 밸런싱이란 무엇인가요?

ssunn

다음 포스트