6주차 후기
어제는 3명이서 진행했다
어제 질문중에 "본인이 새로운 통신 프로토콜을 TCP나 UDP를 사용해서 구현한다고 하면, 어떤 기준으로 프로토콜을 선택하시겠어요?"라는 질문이 있었는데 각자의 상황설정 및 의견이 달라서 질문에 답하는 과정이 재미있었다
IP
DHCP가 무엇인지 설명해 주세요.
DHCP는 Dynamic Host Configuration Protocol의 약자로, 네트워크에 연결된 장치들에게 IP 주소와 같은 네트워크 구성 정보를 제공하는 프로토콜입니다.
DHCP는 몇 계층 프로토콜인가요?
DHCP는 OSI 모델에서 7계층(Application Layer)에 속합니다.
DHCP는 어떻게 동작하나요?
DHCP는 클라이언트와 서버 간의 통신을 통해 동작합니다. 클라이언트는 DHCP 서버에 IP 주소 할당을 요청하고, DHCP 서버는 IP 주소와 함께 클라이언트에게 필요한 추가 구성 정보(예: 서브넷 마스크, 기본 게이트웨이, DNS 서버 등)를 제공합니다.
DHCP에서 UDP를 사용하는 이유가 무엇인가요?
DHCP는 UDP(User Datagram Protocol)를 사용하는 이유는, UDP가 더 작은 오버헤드와 더 빠른 전송 속도를 가지고 있기 때문입니다. 또한, DHCP는 데이터 전송 중에 손실되더라도 재전송을 요구할 필요가 없는 데이터에 대한 신뢰성이 중요하지 않기 때문에 UDP를 선택합니다.
DHCP에서, IP 주소 말고 추가로 제공해주는 정보가 있나요?
DHCP에서 IP 주소 외에도, DHCP 서버는 클라이언트에게 제공할 수 있는 다양한 구성 정보를 가지고 있습니다. 이 정보에는 서브넷 마스크, 기본 게이트웨이, DNS 서버, NTP 서버, SMTP 서버 등이 포함될 수 있습니다.
DHCP의 유효기간은 얼마나 긴가요?
DHCP의 유효기간은 DHCP 서버에서 설정된 값에 따라 다르지만, 일반적으로 몇 시간에서 몇 일까지인 경우가 많습니다. 이 기간이 지나면 클라이언트는 새로운 IP 주소 할당을 요청해야 합니다.
내 컴퓨터에서 DHCP로 IP 요청 한 후에 어떻게 DHCP서버가 내 컴퓨터로 IP를 응답하는지 말해보세요
클라이언트는 네트워크 부팅 시 DHCP 서버에 IP 주소 요청을 보내고, DHCP 서버는 DHCP DISCOVER 메시지를 보내어 응답합니다. 클라이언트는 DHCP 서버에서 받은 OFFER 메시지를 확인하고, ACCEPT 메시지를 보내어 IP 주소 할당을 요청합니다. DHCP 서버는 ACK 메시지를 보내어 클라이언트에게 IP 주소와 구성 정보를 제공합니다. 클라이언트는 이 정보를 사용하여 네트워크에 연결됩니다.
IP 주소는 무엇이며, 어떤 기능을 하고 있나요?
IP 주소는 인터넷 프로토콜(Internet Protocol)에서 사용되는 고유한 식별자입니다. IP 주소는 인터넷에서 패킷이 전송될 때, 송신자와 수신자를 식별하기 위해 사용됩니다.
IPv6는 IPv4의 주소 고갈 문제를 해결하기 위해 만들어졌지만, 아직도 수많은 기기가 IPv4를 사용하고 있습니다. 고갈 문제를 어떻게 해결할 수 있을까요?
IPv6는 128비트 주소 체계를 사용하여 주소 고갈 문제를 해결하였습니다. 이러한 방식으로 더 많은 주소가 생성되어 기존 IPv4 주소 고갈 문제를 완화시키고 새로운 기기들도 IPv6 주소를 사용할 수 있습니다.
IPv4와 IPv6의 차이에 대해 설명해 주세요.
- 주소 크기: IPv4는 32비트 주소 체계를 사용하며, IPv6는 128비트 주소 체계를 사용합니다.
- 주소 할당 방법: IPv4는 주소를 수동으로 할당하거나 DHCP(Dynamic Host Configuration Protocol)를 사용하여 동적으로 할당합니다. 반면, IPv6는 대부분의 경우 자동으로 할당됩니다.
- 보안 기능: IPv6는 IPSec 기능이 내장되어 있어서 네트워크 보안에 대한 보호 기능이 더욱 강화되어 있습니다.
IPv4를 사용하는 장비와 IPv6를 사용하는 같은 네트워크 내에서 통신이 가능한가요? 가능하다면 어떤 방법을 사용하나요?
IPv4와 IPv6를 사용하는 기기들은 서로 다른 주소 체계를 사용하기 때문에 직접적인 통신이 불가능합니다. 그러나 IPv4와 IPv6간의 통신이 필요한 경우에는 중계 기능을 수행하는 특수한 라우터를 사용하여 통신을 연결할 수 있습니다.
IP가 송신자와 수신자를 정확하게 전송되는 것을 보장해 주나요?
IP가 송신자와 수신자를 정확하게 전송되는 것을 보장하지만, 패킷의 전송 여부나 중복 여부를 보장하지 않습니다. 이러한 기능은 상위 프로토콜인 TCP(Transmission Control Protocol)에서 처리됩니다.
IPv4에서 수행하는 Checksum과 TCP에서 수행하는 Checksum은 어떤 차이가 있나요?
IPv4 체크섬은 IP 패킷의 헤더를 위한 체크섬으로, 패킷의 데이터에 대해서는 계산하지 않습니다. IPv4 체크섬은 송신자에서 패킷을 보낼 때 계산되고, 수신자에서 패킷을 받을 때 다시 검증됩니다. IPv4 체크섬은 패킷의 헤더 정보가 올바르게 전송되었는지 확인하는 역할을 합니다.
반면, TCP 체크섬은 TCP 세그먼트의 데이터 전체에 대한 체크섬으로, 세그먼트에 포함된 모든 데이터를 계산합니다. TCP 체크섬은 데이터의 무결성을 검증하는 역할을 합니다. TCP 체크섬은 송신자에서 세그먼트를 보낼 때 계산되고, 수신자에서 세그먼트를 받을 때 다시 검증됩니다.
TTL(Hop Limit)이란 무엇인가요?
TTL(Hop Limit)은 IP 패킷이 라우터를 통해 전송될 때 라우터가 패킷을 처리할 때마다 1씩 감소되는 값입니다. 이 값은 라우팅 루프를 방지하고, IP 패킷이 무한정으로 네트워크를 돌아다니지 않도록 하기 위한 것입니다. TTL이 0이 되면 패킷은 폐기됩니다.
IP 주소와 MAC 주소의 차이에 대해 설명해 주세요.
IP 주소와 MAC 주소는 네트워크에서 각각 다른 역할을 합니다. IP 주소는 인터넷 프로토콜(IP)을 사용하여 통신하는 데 사용되는 주소입니다. 이는 인터넷에서 서로 다른 기기를 식별하는 데 사용됩니다. MAC 주소는 물리적인 주소로, 이더넷과 같은 로컬 네트워크에서 각각의 네트워크 인터페이스를 식별하는 데 사용됩니다. 따라서, MAC 주소는 로컬 네트워크에서 통신을 위해 사용되는 주소이며, IP 주소는 인터넷에서 통신을 위해 사용되는 주소입니다.
또한, MAC 주소는 고유하게 할당되는 반면, IP 주소는 네트워크 관리자에 의해 할당됩니다. MAC 주소는 48비트로 구성되며, 앞 24비트는 제조업체 식별자이고, 뒤 24비트는 제조업체가 할당한 식별 번호입니다. IP 주소는 IPv4에서 32비트로 구성되며, IPv6에서는 128비트로 구성됩니다.
여전히 ipv4가 많이 사용되고 있음 → 이렇기 위해 어떤 방식을 사용하나요?
IPv4가 여전히 많이 사용되고 있는 이유는 이미 구축된 인프라와 장비, 시스템들이 IPv4를 사용하기 때문입니다. 이를 해결하기 위해 IPv6로의 전환이 필요하지만, 전체적인 전환이 시간과 비용이 많이 들어가는 작업이기 때문에 대규모로 이루어지지 않고 있습니다.
그러나 IPv4 주소 고갈 문제를 해결하기 위해 여러 가지 방법이 제시되고 있습니다. 예를 들어, IPv4 주소를 동적으로 할당하고 회수하기 위해 DHCP와 NAT(Network Address Translation)를 사용할 수 있습니다. 또한 IPv4 대역을 효율적으로 사용하기 위해 CIDR(Classless Inter-Domain Routing)을 적용하여 대역을 분할하고 할당할 수 있습니다.
또한, IPv6를 사용하지 않더라도 IPv4에서 사용하는 방식을 최적화하는 방법도 있습니다. 예를 들어, DNS(Domain Name System) 서버를 통해 여러 대의 서버를 단일 IPv4 주소에 매핑하여 가상 호스팅(Virtual Hosting)을 구현할 수 있습니다. 또한, IPv4 주소를 동적으로 재사용하여 새로운 장비에 할당할 수 있습니다. 이러한 방법들을 사용하여 IPv4 주소 고갈 문제를 최소화할 수 있습니다.
웹 접속과정
www.google.com 을 브라우저에 입력하고 엔터를 쳤을 때, 네트워크상 어떤 일이 일어나는지 설명해 주세요.
- 브라우저는 입력한 URL(Uniform Resource Locator)을 이용해 HTTP(Hypertext Transfer Protocol) 요청을 생성합니다.
- 브라우저는 DNS(Domain Name System) 서버에 www.google.com 도메인 이름을 IP 주소로 변환해 달라는 요청을 보냅니다.
- DNS 서버는 www.google.com 도메인 이름에 해당하는 IP 주소를 응답으로 전송합니다.
- 브라우저는 HTTP 요청을 해당 IP 주소의 서버에 보냅니다.
- Google 서버는 요청을 받고, 요청에 따른 응답을 생성하여 클라이언트(브라우저)에 전송합니다.
- 브라우저는 서버에서 받은 응답을 해석하여 웹 페이지를 렌더링합니다.
DNS 쿼리를 통해 얻어진 IP는 어디를 가리키고 있는가?
DNS 쿼리를 통해 얻어진 IP 주소는 해당 도메인 이름을 가지고 있는 웹 서버의 IP 주소를 가리킵니다.
Web Server와 Web Application Server의 차이에 대해 설명해 주세요.
Web Server는 정적인 컨텐츠(HTML 파일, 이미지 파일, 동영상 파일 등)를 처리하는 서버입니다. 웹 브라우저가 요청하는 파일을 전송하는 역할을 합니다. Web Application Server는 동적인 컨텐츠(동적 HTML 페이지, 서버 사이드 스크립트 등)를 처리하는 서버입니다. 데이터베이스와 연결되어 데이터를 처리하고, 비즈니스 로직을 수행합니다.
URL, URI, URN은 어떤 차이가 있나요?
URL(Uniform Resource Locator)은 인터넷에서 어떤 자원의 위치를 지정하는 주소입니다.
예를 들어, http://www.example.com/index.html 은 http 프로토콜을 사용하며, www.example.com 도메인의 index.html 파일을 가리킵니다.
URI(Uniform Resource Identifier)는 인터넷에서 특정 자원을 식별하는 데 사용되는 식별자입니다. URL은 URI의 일종으로, URI는 URL뿐만 아니라, URN(Uniform Resource Name)도 포함합니다.
URN은 인터넷에서 특정 자원을 이름으로 식별하는 식별자입니다. 예를 들어, urn:isbn:9788983920837은 ISBN(국제 표준 도서번호) 9788983920837을 가리킵니다.
Cookie & Session
쿠키와 세션의 차이는 무엇인가요?
쿠키와 세션은 둘 다 클라이언트와 서버 간의 상태를 유지하기 위한 기술입니다. 주요한 차이점은 저장되는 위치와 보안 수준입니다.
쿠키는 클라이언트(웹 브라우저)에 저장되는 작은 텍스트 파일입니다. 서버는 쿠키를 사용하여 클라이언트의 정보(로그인 정보, 사용자 환경 설정 등)를 저장합니다. 클라이언트는 쿠키를 요청 헤더에 포함하여 서버에 전송하고, 서버는 이를 사용하여 클라이언트를 식별하고 필요한 정보를 반환합니다. 쿠키는 브라우저를 종료해도 유지될 수 있으며, 만료일을 지정하여 일정 기간 동안 유지될 수 있습니다. 쿠키는 사용자가 삭제할 수 있기 때문에 보안성이 낮은 데이터(예: 사용자 환경 설정)에 적합합니다.
세션은 서버 측에서 유지되는 정보입니다. 서버는 클라이언트가 연결을 요청하면 고유한 세션 ID를 생성하고, 이를 쿠키를 통해 클라이언트에 전달합니다. 클라이언트는 이 세션 ID를 쿠키로 저장하고, 서버에 요청할 때마다 세션 ID를 전송합니다. 서버는 이를 사용하여 클라이언트를 식별하고, 해당 클라이언트에 대한 정보(로그인 정보, 장바구니 등)를 유지합니다. 세션은 보안성이 높은 데이터(예: 로그인 정보)에 적합합니다. 세션은 일정 시간이 지나면 만료됩니다.
세션 방식의 로그인 방식
- 사용자가 로그인 페이지에 로그인 정보를 입력합니다.
- 서버는 이를 검증하고, 세션 ID를 생성합니다.
- 서버는 이 세션 ID를 쿠키로 클라이언트에 전송합니다.
- 클라이언트는 이 세션 ID를 저장하고, 요청할 때마다 서버에 전송합니다.
- 서버는 이 세션 ID를 사용하여 사용자를 식별하고, 해당 사용자에 대한 정보를 유지합니다.
- 로그아웃할 때, 클라이언트는 세션 ID를 삭제하고, 서버에서도 해당 세션 ID에 대한 정보를 삭제합니다.
HTTP의 특성인 Stateless에 대해 설명해 주세요.
HTTP의 특성인 Stateless는 서버가 클라이언트의 상태를 유지하지 않는 것을 의미합니다. 즉, 클라이언트가 서버에 요청을 보낼 때마다 서버는 이전 요청과 상태를 전혀 인식하지 않습니다. 이러한 Stateless의 특성 때문에 클라이언트의 상태를 유지하기 위해서는 다른 방법이 필요합니다.
HTTP Stateless → 세션이 맞는 방식인가?
HTTP는 Stateless 프로토콜이기 때문에 클라이언트의 상태를 기억하지 않습니다. 이는 서버와 클라이언트가 요청과 응답을 주고받을 때마다 매번 새로운 연결이 생성되기 때문입니다. 따라서 HTTP는 클라이언트의 상태 정보를 서버가 기억하지 않기 때문에 클라이언트가 다음 요청을 보낼 때마다 인증 정보를 매번 전달해야 합니다.
세션은 HTTP Stateless의 한계를 극복하기 위한 방법 중 하나입니다. 세션은 클라이언트가 서버에 최초로 요청을 보낼 때 서버에서 클라이언트를 구별할 수 있는 고유한 세션 ID를 발급하고, 이후의 요청에서 이 세션 ID를 이용해 클라이언트를 구별합니다. 이를 통해 서버는 클라이언트의 상태 정보를 일시적으로 기억할 수 있습니다.
Stateless의 의미를 살펴보면, 세션은 적절하지 않은 인증 방법 아닌가요?
세션은 Stateless한 HTTP 프로토콜에서 인증 정보를 유지하기 위한 대표적인 방법 중 하나이지만, 세션을 사용하면 서버에 부담이 발생할 수 있습니다. 세션은 서버 메모리에 정보를 저장하므로 세션 정보가 많아지면 서버의 메모리 부담도 커집니다. 또한 세션 정보가 분산되어 있는 경우 서버 간의 정보 공유도 필요합니다.
규모가 커져 서버가 여러 개가 된다면, 세션을 어떻게 관리할 수 있을까요?
세션 관리를 위한 기술로는 로드 밸런싱과 세션 클러스터링이 있습니다. 로드 밸런싱은 서버의 부하를 분산시켜주는 역할을 합니다. 세션 클러스터링은 여러 대의 서버가 클러스터를 구성하고, 세션 정보를 서버 간에 공유하여 로드 밸런싱된 각각의 서버에서 클라이언트의 요청을 처리할 때 세션 정보를 공유합니다.
Session 인증 방식과 Token 인증 방식의 차이점
Token 인증 방식은 Stateless한 HTTP 프로토콜에서 인증 정보를 유지하기 위한 다른 방법입니다. 토큰은 클라이언트의 요청과 함께 발급되며, 이 토큰을 이용해 클라이언트의 인증 정보를 확인합니다. 서버는 이 토큰을 이용해 클라이언트를 식별하며, 토큰은 클라이언트와 서버 간에 암호화되어 전송됩니다. 이 방식은 세션 방식과 달리 서버 메모리에 정보를 저장하지 않아도 되므로 서버 부담이 적습니다.
REST API
REST API가 무엇이며, 어떤 메서드가 있나요?
REST(Representational State Transfer)는 웹 서비스 디자인의 아키텍처 스타일 중 하나로, 클라이언트와 서버 간의 통신을 위한 인터페이스입니다. REST API는 REST 아키텍처 스타일을 따르는 API를 의미합니다.
- GET: 리소스의 조회
- POST: 리소스의 생성
- PUT: 리소스의 수정
- DELETE: 리소스의 삭제
REST가 뭔가요?
REST는 클라이언트와 서버 간의 통신에 있어 상태를 유지하지 않는(stateless) 특성을 가지고 있습니다. 즉, 서버는 각각의 요청을 별개의 것으로 인식하고, 클라이언트는 서버로부터 필요한 정보를 모두 포함하는 요청을 보내야 합니다.
CORS → 처리할 수 있는가?
CORS(Cross-Origin Resource Sharing)는 웹 브라우저에서 발생하는 보안상의 이슈로, 다른 도메인으로부터 리소스가 요청될 때 브라우저에서 보안을 위해 요청을 차단하는 것을 의미합니다. 이는 서버에서 처리할 수 있지만, REST API에서는 보통 클라이언트에서 처리합니다.
REST 장단점
장점
- 경량화된 데이터 형식을 사용하여 대역폭 사용을 줄일 수 있습니다.
- 각 리소스에 대한 고유한 URI를 가지므로, 검색 엔진 최적화(SEO)가 용이합니다.
- 서로 다른 클라이언트에서도 사용이 가능하도록 하기 때문에, 확장성이 용이합니다.
단점
- 복잡한 구현이 필요하다는 점입니다.
- 표준이 없으므로, 설계 및 개발 시에 다른 팀원 간의 협업이 중요합니다.
REST가 필요한 이유
REST API를 사용하는 이유로는, 클라이언트와 서버 간의 통신을 표준화하고, 재사용성과 상호 운용성을 높이기 위해서입니다. 또한, REST API는 HTTP 프로토콜을 사용하므로, 웹 개발자가 익숙한 프로토콜을 사용하여 개발할 수 있습니다.
REST 구성 요소
- 자원(Resources): API의 URI는 자원을 나타내야 하며, 각 자원은 고유한 ID를 가지고 있어야 함.
- 행위(Verbs): HTTP 프로토콜의 메서드(GET, POST, PUT, DELETE)를 사용하여 자원에 대한 행위를 표현함.
- 표현(Representation): 클라이언트와 서버 간에 자원에 대한 표현을 전달하기 위한 데이터 형식으로 XML, JSON 등이 사용됨.
REST 특징
- 클라이언트/서버 구조: 클라이언트와 서버가 독립적으로 개발될 수 있어야 함.
- 무상태(Stateless): 서버는 클라이언트의 상태를 보존하지 않아야 함.
- 캐시 처리 가능(Cacheable): HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 활용 가능함.
- 자체 표현 구조(Self-descriptiveness): REST API 메시지만으로 쉽게 이해할 수 있는 자체 표현 구조를 사용해야 함.
- 계층화(Layered System): 클라이언트는 API 서버만 호출하며, 서버는 다른 서버에 요청을 보내는 등 계층화된 구조를 가질 수 있음.
- Code-On-Demand: 서버에서 전송해주는 프로그램을 클라이언트에서 실행할 수 있어야 함.
RESTful API
REST 아키텍처 스타일을 따르는 API를 RESTful API라고 합니다. 자원을 URI로 표현하고, HTTP 메서드를 이용하여 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하는 API를 의미합니다.
REST API의 정의
REST API는 REST 아키텍처 스타일을 따르는 API를 말하며, 자원을 URI로 표현하고, HTTP 메서드를 이용하여 자원에 대한 CRUD 작업을 수행하는 API를 의미합니다.
REST API의 특징
- 각 자원은 고유한 URI를 가지고 있어야 함.
- URI는 단순하고 직관적이어야 함.
- HTTP 메서드를 이용하여 자원에 대한 행위를 표현함.
- RESTful API는 자체 표현 구조를 사용해야 함.
- RESTful API는 Stateful 하지 않아야 함.
- RESTful API는 캐시 처리 가능해야 함.
REST API 설계 규칙
- 자원(URI)은 명사로 표현해야 합니다.
- HTTP 메서드(GET, POST, PUT, DELETE 등)를 활용하여 행위를 표현합니다.
- 슬래시(/)로 계층 관계를 나타냅니다.
- 하나의 자원에 대해 하나의 URL을 사용합니다.
- 불필요한 정보를 제외하고 최소한의 데이터만 전송합니다.
- HTTP 응답 코드를 사용하여 성공/실패 여부를 나타냅니다.
- API 버전을 관리합니다.
- 보안성을 고려하여 HTTPS 프로토콜을 사용합니다.
- API 문서를 작성하여 사용자가 쉽게 이해할 수 있도록 합니다.
- RESTful한 API를 설계합니다.
DNS(Domain Name System)
DNS에 대해 설명해 주세요.
DNS는 인터넷에서 도메인 이름과 IP 주소를 서로 매핑해주는 분산형 데이터베이스 시스템입니다. 인터넷 사용자는 URL을 입력하면, DNS에서 해당 도메인 이름의 IP 주소를 찾아 해당 서버로 접속하게 됩니다.
DNS는 몇 계층 프로토콜인가요?
DNS는 3계층 프로토콜로 구성되어 있습니다. 1계층은 루트 DNS 서버, 2계층은 최상위 도메인(TLD) DNS 서버, 3계층은 하위 도메인 DNS 서버입니다.
UDP와 TCP 중 어떤 것을 사용하나요?
UDP와 TCP 중에는 주로 UDP를 사용합니다. UDP는 일반적으로 작은 크기의 데이터를 빠르게 전송하는 데 사용됩니다. DNS 쿼리와 응답은 작은 크기의 데이터 패킷으로 전송되므로 UDP를 사용하는 것이 더 효율적입니다.
DNS Recursive Query, Iterative Query가 무엇인가요?
DNS Recursive Query는 DNS 서버가 DNS 계층 구조를 따라 답변을 찾을 때 다른 DNS 서버에 쿼리를 보내는 것입니다. 반면, DNS Iterative Query는 DNS 서버가 질문에 대한 답변이 없을 경우 다음에 연락할 DNS 서버를 찾기 위해 노력하는 것입니다.
DNS 쿼리 과정에서 손실이 발생한다면, 어떻게 처리하나요?
DNS 쿼리 과정에서 패킷이 손실될 경우, 클라이언트는 일정 시간 동안 대기하고 패킷 재전송을 시도합니다. 일정 시간이 경과한 후에도 답변이 없는 경우, 클라이언트는 다른 DNS 서버에 쿼리를 보냅니다.
DNS 레코드 타입 중 A, CNAME, AAAA의 차이에 대해서 설명해주세요.
DNS 레코드 타입 중 A는 도메인 이름을 IPv4 주소로 매핑하고, CNAME은 도메인 이름을 다른 도메인 이름에 매핑합니다. AAAA는 IPv6 주소를 나타냅니다.
hosts 파일은 어떤 역할을 하나요? DNS와 비교하였을 때 어떤 것이 우선순위가 더 높나요?
hosts 파일은 로컬 시스템에서 도메인 이름과 IP 주소를 매핑하는 파일입니다. DNS는 인터넷에서 사용되는 분산형 데이터베이스 시스템이므로 hosts 파일은 DNS보다 우선순위가 높습니다.
DNS over TLS
DNS over TLS는 DNS 쿼리를 암호화하는 보안 기술입니다. DNS Round Robin 방식은 여러 개의 IP 주소를 가진 동일한 도메인 이름을 가진 서버를 사용하는 방식입니다. 하지만 서버에 부하가 집중될 수 있으므로, 로드 밸런서 등 다른 기술과 함께 사용해야 합니다.
DNS Round Robin 방식의 문제점
첫째, 클라이언트의 DNS 캐시에 따라 라운드로빈이 의미 없어질 수 있습니다. DNS 캐시는 TTL(Time-To-Live) 값에 따라 일정 시간동안 캐싱되는데, 이 시간동안에는 해당 DNS 레코드를 요청한 클라이언트는 항상 같은 IP 주소를 받게 됩니다.
둘째, 모든 서버에 대해 균등한 부하 분산이 이루어지지 않을 수 있습니다. 예를 들어, 서버 1과 2의 IP 주소를 가진 두 서버가 있을 때, 서버 1의 성능이 더 좋다면 서버 2보다 더 많은 요청을 처리해야 할 것입니다. 하지만 DNS Round Robin 방식은 둘 다 같은 확률로 IP 주소를 반환하기 때문에 서버 1에 더 많은 요청이 발생하지 않을 수 있습니다.
셋째, 서버가 다운될 경우, DNS 서버는 해당 서버의 IP 주소를 반환하지 않지만, 클라이언트는 DNS 캐시에 해당 IP 주소가 남아 있을 수 있습니다. 이 경우, 클라이언트는 다운된 서버에 요청을 계속 보내기 때문에 서비스 불가능한 상황이 발생할 수 있습니다.
따라서, DNS Round Robin 방식은 단순하고 쉽게 구현할 수 있지만, 부하 분산의 효율성과 신뢰성 측면에서는 한계가 있습니다. 이를 보완하기 위해 로드 밸런서 등 다른 방식의 부하 분산 기술을 사용하는 것이 좋습니다.
'프로그래밍 > CS' 카테고리의 다른 글
| CS스터디 9주차 - 데이터베이스(DB) 2/2 (1) | 2023.05.04 |
|---|---|
| CS스터디 8주차 - 데이터베이스(DB) 1/2 (0) | 2023.04.27 |
| 2023 정처기(정보처리기사) 시험 신청 후기 및 좋은 자료 (1) | 2023.04.19 |
| CS스터디 6주차 - 네트워크1(TCP~CORS) (1) | 2023.04.13 |
| CS스터디 5주차 - 알고리즘 (0) | 2023.04.06 |
댓글