운영체제는 복수의 프로세스들을 관리하는 과정에서 여러 문제에 직면하게 되는데
그중 가장 큰 문제는 race condition(경쟁상태), 쉽게 말해 동기화이다.

두 개 이상의 프로세스가 동시에 공유 자원에 접근할 경우 명령어 실행 순서(프로세스 수행 순서라고도 볼 수 있다.)에 따라 결과값이 달라질 수 있고, 이는 시스템의 신뢰도를 떨어트린다. 이러한 문제를 해결하기 위해 하나의 프로세스가 공유 자원에 접근하는 동안 다른 프로세스의 접근을 막는, 이른바 상호 배제에 대한 노력이 이루어져 왔다.

 

다음은 상호 배제를 위한 요구 조건이다.

1. 임계 자원 또는 임계 영역(critical section)에 대한 접근은 한 순간에 반드시 하나의 프로세스에게만 허용되어야 한다. (상호 배제)
   - 임계 자원, 임계 영역 : 두 개 이상의 프로세스가 동시에 사용할 수 없는 자원(동시에 사용할 경우 문제 발생)을 임계 자원이라 하고, 임계 자원을 사용할 수 있도록 하는 코드 상의 영역을 임계 영역이라고 한다.

2. 임계 영역을 사용할 의향이 없는 프로세스에 의해 다른 프로세스의 수행이 간섭받아서는 안된다.
    ex. 교대 진입 : 프로세스 P1의 임계 영역 실행이 끝난 후 프로세스 P0의 실행 순서가 오도록 설계할 경우, P0은 P1이 반드시 임계 영역을 실행해야만 자신의 차례를 받을 수 있다. 만약 임계 영역에 대한 P1의 실행 의사가 없는 경우 P0은 P1이 임계 영역을 실행하고 싶어 할 때까지 기다려야 하고 P1의 임계 영역 실행이 끝나야만 자신의 차례를 받을 수 있다.
     즉, 임계 영역에 진입한 프로세스가 없음에도 불구하고 다른 프로세스에 의해 임계 영역에 대한 진입이 제한되는 경우를 말한다. 기타 다른 이유로라도 프로세스 간 간섭이 발생해서는 안된다.

 

3. 교착 상태(deadlock)나 기아(starvation)가 발생하지 않아야 한다.
   - 교착 상태 : 상호 배제가 이루어지고 있는 상황에서 두 프로세스가 서로 상대방이 사용 중인 자원을 요구하며 계속 대기만 하는 상황. 어느 프로세스도 수행을 이어나갈 수 없다.
   - 기아 : "특정" 프로세스가 오랫동안 자원을 사용하지 못해 실행되지 못하고 있는 상태.
                프로세스 수행 순서가 골고루 배분되지 않아 특정 프로세스가 소외되는 것. (교착 상태 X)

4. 알고리즘 설계 시, 프로세서의 개수나 상대적인 수행 속도에 대한 가정이 없어야 한다.

5. 임계 영역에 들어간 프로세스는 그 안에서 무한정 있을 수 없다. (일정한 시간 내에 임계 영역에서 나와야 한다.)

 

이후부터는 Dekker와 Peterson의 알고리즘을 보면서, 각각의 알고리즘이 위 요구조건을 만족하는지 확인할 것이다.
이 중 알고리즘 적용 상황에 따라 달라질 수 있는 조건들은 확인할 항목에서 제외시켰다.


Dekker's Algorithm

dekker의 알고리즘은 2개의 프로세스 간 상호 배제를 위한 알고리즘이다.
또한 flag[2]와 turn이라는 두 개의 공유 변수를 사용하는데, 각각의 용도는 다음과 같다.

  • flag[2] : 각 인덱스 번호에 해당하는 프로세스가 자신의 임계 영역 사용 의사 표시 (true : 원함, false : 원하지 않음)
  • turn : 어떤 프로세스에게 임계 영역 진입에 대한 우선권을 줄지 표시 (0 : P0 차례, 1 : P1 차례)


이들을 사용하여 구현된 알고리즘은 다음과 같다. (P0은 process 0을 의미하고 P1은 process 1을 의미한다.)

Dekker's Algorithm

이 알고리즘은 다음의 과정으로 수행된다.

  1. 자신의 flag를 true로 설정한다. (사용 의사 밝힘)
  2. 상대편 flag을 확인하고, 상대편이 임계 영역 사용 의사를 보일 경우 turn 값을 확인한다.
    2-1. 상대편이 실행될 차례일 경우 자신의 사용 의사를 잠시 false로 설정해둔다. (상대편에게 양보)
    2-2. 상대편의 임계 영역 사용이 끝날 때까지 대기(while)한다.
    2-3. 사용이 끝난 뒤 다시 사용 의사를 true로 설정한다.
  3. 상대편이 사용 의사를 보이지만 turn 값이 자신의 차례를 가리킬 경우, 양보하지 않고 상대편이 양보할 때까지 기다린다.
  4. 상대편이 자신의 사용 의사를 false로 설정할 경우(양보해줄 경우) 임계 영역(critical section)에 진입할 수 있다.
  5. 임계 영역 실행 후 차례를 상대편으로 넘기고, 자신의 사용 의사를 false로 설정한다.

 

요구 조건 만족도 체크

1. 상호 배제가 지켜지는지 : O
-> 하나의 프로세스가 임계 영역에 진입한 경우 이 프로세스가 임계 영역을 빠져나와 turn값과 flag를 바꿔주지 않는 한 다른 프로세스가 임계 영역에 접근할 수 없다. 또한 두 프로세스가 모두 임계 영역에 진입하기 전 경쟁 상태일 때, 1 또는 0의 상태만 가질 수 있는 turn값을 확인하는 것에 의해 둘 중 하나의 프로세스만 임계 영역으로 진입할 수 있게 된다.

2. 교대 진입이 필요 없는지 : O
-> while(flag [상대])에 의해 상대편이 임계 영역에 진입할 의사가 없다면 turn값에 관계없이 임계 영역에 진입할 수 있다.

3. deadlock이 일어나지 않는지 : O
-> 상대편이 사용 의사를 밝힌다고 무조건 양보하는 게 아니라, if(turn ==?)에 의해 차례를 확인하면서 한 번에 하나의 프로세스만 양보하도록 한다. 따라서 동시에 두 프로세스가 서로의 양보를 기다리는 deadlock은 발생하지 않는다.

3-1. livelock이 일어나지 않는지 : O
-> deadlock에 걸리면 두 프로세스가 그대로 멈춰버리는 것을 떠올리면 된다. 그러나 livelock은 프로세스가 작업을 계속 하기는 하지만, 상대방이 자원을 줄 때까지 일정 루틴을 무한히 반복하며 무의미한 코드만 실행하는 식으로 lock이 걸리는 것을 말한다. 현재 코드에서는 상대 프로세스가 자원 사용을 양보할 때까지 계속 반복문을 돌기는 하지만 그 안에서 무의미하게 상태를 변경하는 것과 같은 작업은 하지 않는다. 또한 3번의 이유와 마찬가지로 한 번에 하나의 프로세스만 양보하도록 하기 때문에 서로의 양보를 기다릴 필요도 없게 된다.

4. 프로세서의 개수나 속도에 대한 가정이 없는지 : X
-> 위 알고리즘은 프로세서가 2개인 상황을 가정하고 작성된 알고리즘으로, 3개 이상인 경우에 대해서도 적용되는지는 확인할 수 없다.


Peterson's Algorithm

peterson의 알고리즘도 dekker의 알고리즘과 마찬가지로 2개의 프로세스 간의 상호 배제만을 가정하고 만들어진 알고리즘이다.
또한 dekker와 마찬가지로 flag[2]와 turn이라는 공유 변수를 사용하며, 각각의 용도는 dekker와 동일하므로 생략한다.

이를 사용하여 만들어진 알고리즘은 다음과 같다.

Peterson's Algorithm

이 알고리즘은 다음의 과정으로 수행된다.

  1. 자신의 flag를 true로 설정한다. (사용 의사 밝힘)
  2. turn값을 일단 상대방의 차례로 설정한다.
  3. 상대방 차례에 상대방의 사용 의사가 있을 경우 대기한다.
  4. 상대방의 임계 영역 사용 의사가 없거나, 자신에게로 차례가 있을 경우 임계 영역에 진입할 수 있다.
  5. 임계 영역의 실행이 끝난 후 자신의 사용 의사를 false로 설정한다.

 

요구 조건 만족도 체크

1. 상호 배제가 지켜지는지 : O
-> 상호 배제를 지키기 위해서는 결국 임계 영역에 한 번에 하나의 프로세스만 진입하도록 하면 된다. 따라서 임계 영역에 진입한 프로세스가 없는 상황이라면 언제 들어가든 상관이 없다. 이를 고려한다면 프로세스는 상대방의 사용 의사가 있을 때에만 turn값을 확인하여 차례를 기다리면 된다. 여기서 차례를 나타내는 turn값은 한 번에 0 또는 1의 값만 가질 수 있기 때문에 상호 배제 조건을 만족한다.

2. 교대 진입이 필요 없는지 : O
-> 자신의 차례가 아니더라도 상대방이 임계 영역에 진입할 의사가 없으면 언제든 임계 영역에 진입할 수 있다.

3. deadlock이 일어나지 않는지 : O
-> 어떤 코드의 실행이 먼저 일어나든 turn값에는 0 또는 1만 들어갈 수 있다. 따라서 두 프로세스가 동시에 서로의 자원을 요구할 일이 없어 deadlock이 일어나지 않는다. 

3-1. livelock이 일어나지 않는지 : O
-> 반복문 안에서 상태(flag나 turn) 변경 작업을 하지 않는다. (while(true)는 대기를 위한 반복문이라기보다 프로세스가 수행할 다른 작업들을 가리킨다. 실제 알고리즘 상으로 반복을 하도록 의도한 게 아니라는 의미.)

4. 프로세서의 개수나 속도에 대한 가정이 없는지 : X
-> dekker의 알고리즘과 마찬가지로 2개의 프로세스에 대한 알고리즘이므로, 3개 이상의 프로세스에 대해서도 적용되는지는 별도로 확인해봐야 한다.


요구 조건 체크만 보더라도 Dekker의 알고리즘을 보완한 것이 Peterson의 알고리즘인 것을 알 수 있다.
문제는 두 알고리즘이 매우 비슷해 보여서 어떤 차이인지 헷갈린다는 것이다.

따라서 두 알고리즘의 차이점만 정리해본다면, Dekker의 알고리즘은 임계 영역을 실행한 후 turn값을 상대방에게 넘겨주고 Peterson의 알고리즘은 아예 조건 체크를 하기 이전에 turn값을 상대방에게 먼저 넘겨주고 시작한다.

위 두 알고리즘은 각종 요구 조건을 만족시키면서 소프트웨어적으로 상호 배제를 구현한 알고리즘이라고 볼 수 있다. 그러나, 2개의 프로세스를 가정하고 구현한 것이기 때문에 자체로는 한계점이 있다. 이를 해결하기 위해 하드웨어적인 방법, 운영체제와 프로그래밍 언어 수준에서 지원하는 상호 배제 방법 등을 사용할 수 있다.

'Algorithm' 카테고리의 다른 글

Tim sort 알고리즘  (2) 2023.02.04

 

  • CDN을 사용하지 않고 하나의 데이터 센터만 사용할 경우 문제점
    1. 지역적으로 먼 거리 ⇒ 거쳐가는 라우터의 수 증가 ⇒ 병목 지점의 링크를 거쳐갈 확률 증가 ⇒ 전송용량이 낮아질 가능성이 높아진다.
    2. 많은 이들이 여러번 시청하는 콘텐츠는 그만큼 자주 전송해야하고 이로 인해 전송 비용이 중복적으로 발생한다.
    3. 한번의 장애로 전체 서비스가 중단될 위험이 있다.
  • CDN(Contents Distribution Network)
    : 여러 서버 클러스터를 두고 이들 서버에 콘텐츠의 복사본을 저장해두고 사용하는 방식
    • 대부분의 비디오 스트리밍 서비스에서 사용하는 방식
    • 이용하려는 서버 클러스터에 콘텐츠의 복사본이 없는 경우, 중앙 서버나 다른 클러스터로부터 해당 콘텐츠를 전송 받아 제공하는 동시에 복사본을 만든다.
      • PULL 방식을 사용하여, 요청이 들어오는 비디오에 대한 처리만 한다.
      • 복사본을 저장할 공간이 가득찬 경우 인터넷 캐시처럼 자주 이용되지 않은 것을 삭제
    • 사설 CDN 또는 제3자가 운영하는 CDN을 사용할 수 있다.
    • CDN 서버 클러스터를 구축하는 방식 (아래 두 가지 중 하나 선택 사용)
      1. 서버 클러스터를 최대한 사용자에 가까이 두어 전송 속도를 높이기 위해, 수많은 서버 클러스터들을 ISP의 접속 네트워크 안에 위치시키는 방법
        1. 장점 : 지연 시간 및 처리율이 향상된다.
        2. 단점 : 고도로 분산된 설계로 인해 유지 관리 비용이 증가한다.
      2. 보다 적은 수의 핵심 지점(IXPs)에만 큰 규모의 서버 클러스터를 위치 시키는 방법
        1. 장점 : 유지 관리 비용이 줄어든다.
        2. 단점 : 지연 시간 및 처리율이 상대적으로 저하된다.
  • CDN 동작
    • CDN이 사용자의 요청을 가로채 해당 사용자에게 가장 적절한 서버 클러스터를 찾아 그 서버로 요청을 보낸다. 요청을 가로챌 때 DNS를 사용한다.
    • 동작 단계

  • 서버 클러스터 선택 정책
    • LDNS(로컬 DNS)에서 CDN 책임 서버로 요청을 보내는 과정에 의해 CDN은 LDNS의 IP를 알게 되고 이 주소를 바탕으로 사용자에게 가장 적합한 콘텐츠 서버를 선택한다.
    • 각 CDN 별로 고유한 클러스터 선택 정책을 사용한다.
    • 일반적으로 사용하는 정책은 “클라이언트에게 지리적으로 가장 가까운 클러스터"를 선택하는 것
      • 일부 클라이언트에게는 지리적으로 가장 가까운 클러스터가 가장 가까운 클러스터가 아닐 수 있다. (네트워크 경로 상의 홉 수에 의해)
      • 클라이언트가 멀리 떨어진 LDNS를 사용할 경우 LDNS의 IP를 기반으로 한 선택이 최선이 아닐 수 있다.
      • 같은 위치라면 매번 같은 클러스터가 배정되는데, 이 때 경로의 지연이나 가용 대역폭의 변화 등은 고려하지 않는다.
    • CDN은 네트워크 트래픽 상황을 고려하여 클러스터를 선택하기 위해 클러스터와 클라이언트 간 경로 상의 지연 및 손실 성능을 실시간으로 측정하도록 할 수 있다.
      • 다만, 대부분의 LDNS에서 실시간 측정을 위해 사용되는 메시지에 응답하지 않도록 설정되어 있는 것이 문제...

'Network' 카테고리의 다른 글

Tracert와 Traceroute  (0) 2023.05.26
DNS(Domain Name System)  (0) 2022.03.28
Network 개요  (0) 2022.03.01

호스트 식별 방법

  • 호스트 네임(hostname)
    • (ex. www.naver.com, www.google.com)
    • 가변 길이의 알파뉴메릭 문자로 구성된다.
    • 호스트의 위치에 대한 정보는 제공하지 않는다.
  • IP 주소
    • 4바이트 (32비트)
    • xxx.xxx.xxx.xxx 형태의 계층 구조
    • 호스트가 속한 네트워크의 위치와 호스트의 위치에 대한 정보를 제공한다.

 

DNS가 제공하는 서비스

  • DNS(Domain Name System)
    1. DNS 서버가 계층 구조로 구현된 분산형 데이터베이스
      • 서버 : BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스 컴퓨터
    2. 호스트가 분산형 데이터베이스에 질의할 수 있게 하는 애플리케이션 계층 프로토콜
      • 프로토콜 : UDP 기반으로 수행되고, 포트 번호 53번을 사용한다.
  • 사용자가 제공한 호스트 네임을 IP 주소로 변환하는데 사용된다.
    • 인터넷 애플리케이션에서 URL로의 요청을 보낼 때 우선 DNS 클라이언트를 이용하여 DNS 서버에 호스트 이름에 대한 질의를 보내 IP 주소를 얻는다.
    • 가까운 DNS 서버에 원하는 IP 주소가 캐시되어 있어 평균 지연 시간을 줄여준다.
  • 호스트 엘리어싱(host aliasing) : 복잡한 호스트 네임을 가진 호스트에 대해 하나 이상의 별칭도 함께 저장한다.
    • 원래 호스트 네임을 **정식 호스트 네임(canonical hostname)**이라고 한다.
    • 별칭 호스트 네임으로부터 정식 호스트 네임을 얻을 수 있도록 한다. (google.com 별칭 이름 → www.google.com 정식 이름)
  • 메일 서버 엘리어싱(mail server aliasing) : 메일 애플리케이션으로부터 메일 서버에 대한 정식 호스트 네임을 얻기 위해 사용된다.
    • 기억하기 쉬운 전자메일 주소를 위해 주소로는 별칭을 사용하고 정식 호스트 네임이 필요할 때 DNS에 질의한다.
  • 부하 분산(load distribution) : 여러 중복 서버 사이에 부하를 분산하는 데에 사용한다.
    • 여러 중복된 서버는 서로 다른 IP 주소를 가지고 있는데, 이들 모두 하나의 연관된 호스트 네임을 가진다.
    • 해당 호스트 네임으로 질의를 받은 DNS 서버는 서로 다른 IP 주소들을 모두 응답해준다.
    • 이 때 응답하는 IP 주소의 순서를 순환되도록 하여, 가장 앞에 있는 IP 주소를 사용하는 클라이언트가 분산된 여러 서버에 순환적으로 요청을 보낼 수 있도록 한다.

 

DNS 동작 원리

분산 계층 데이터베이스

  • DNS 서버 계층
    • 루트 DNS 서버
      • 13개의 다른 기관에서 관리하며 400개 이상의 루트 DNS 서버가 존재한다.
      • DNS 서버 계층으로 질의가 들어올 때 제일 먼저 루트 DNS 서버로 전달된다.
      • 호스트 네임의 TLD에 맞는 TLD 서버의 IP 주소를 응답한다.
    • TLD(Top-Level Domain) DNS 서버
      • com, org, net, edu 같은 TLD 서버와 kr, fr, ca 같은 모든 국가에 대한 TLD 서버가 존재한다.
      • 각 TLD 서버는 각각에 속한 책임 DNS 서버들의 IP 주소를 가지고 있고, 이를 응답한다.
    • 책임(authoritative) DNS 서버
      • 자신의 서버에서 관할하는 호스트 네임과 그의 IP 주소가 매핑된 공개적인 DNS 레코드를 가진다.
      • 웹 서버나 메일 서버들은 자신의 호스트 네임과 IP 주소가 매핑된 DNS 레코드를 책임 DNS 서버에 저장해야 한다.
      • 이를 위해 자신들이 직접 책임 DNS 서버를 구현하여 저장하는 방법과 책임 DNS 서버 서비스를 제공하는 제공자에게 비용을 지불하고 저장하는 방법(ex. 가비아, 카페24) 중 선택할 수 있다.
  • 로컬 DNS 서버
    • ISP들은 로컬 DNS 서버(default name server)를 갖는다.
    • 호스트가 ISP에 접속할 때 일반적으로 DHCP를 이용하여 호스트에게 IP 주소를 할당한다.
    • 호스트가 DNS 질의를 보낼 때 제일 먼저 로컬 DNS 서버로 보내고, 이 서버에 원하는 호스트명이 없을 경우 로컬 DNS 서버에서 DNS 서버 계층으로 DNS 질의를 보낸다.
    • 로컬 DNS 서버를 중심으로 DNS 서버 계층과의 질의가 이루어지며 이렇게 얻어진 DNS 레코드는 캐싱되어 로컬 DNS 서버에 저장된다.
    • 재귀적 질의(recursive query)반복적 질의(iterative query)
      • 재귀적 질의 : 요청 호스트 - LDNS - DNS 서버
      • 반복적 질의 : LDNS - DNS 서버

DNS 캐싱(caching)

  • 로컬 DNS 서버는 질의 결과로 얻은 DNS 레코드를 로컬 메모리에 저장할 수 있다.
    • 저장할 때 저장해 둘 기간(대게 2일)을 설정해두고, 이 기간이 지난 레코드는 삭제한다.
    • 저장된 DNS 레코드에 해당하는 질의가 들어올 경우 추가적인 질의 없이 곧바로 이 레코드의 정보를 이용하여 응답할 수 있다.
  • 로컬 DNS 서버는 호스트에 대한 정보 뿐만 아니라 TLD 서버의 IP 주소도 저장할 수 있다.
    • DNS 서버 계층으로 질의할 경우 루트 DNS 서버로의 질의를 우회할 수 있다.

 

DNS 레코드와 메시지

(RFC1034, RFC1035)

자원 레코드(resource record, RR) : DNS 서버에서 호스트명과 IP 주소를 매핑하는데 사용하는 레코드

  • 각 DNS는 DNS 질의에 대해 하나 이상의 자원 레코드를 가지는 메시지로 응답한다.
  • 자원 레코드가 갖는 필드
    • Name(16bits), Value, Type(16bits), TTL(32bits, 자원 레코드가 캐시에 남아있는 기간)
  • Type 값에 따른 Name과 Value의 값
    • Type = A
      • Name : 호스트 명
      • Value : 호스트 명에 대한 IP 주소
      • Type A의 레코드 예시 : (relay1.bar.foo.com, 145.37.93.126, A)
    • Type = NS
      • Name : 도메인
      • Value : 도메인에 대한 책임 DNS 서버의 호스트 네임
      • Type NS의 레코드 예시 : (foo.com, dns.foo.com, NS)
    • Type = CNAME
      • Name : 별칭 호스트 명
      • Value : 별칭 호스트 명에 대한 정식 호스트 명
      • Type CNAME의 레코드 예시 : (foo.com, relay1.bar.foo.com, CNAME)
    • Type = MX
      • Name : 별칭 호스트 명
      • Value : 별칭 호스트 명에 대한 메일 서버의 정식 이름
      • Type MX의 레코드 예시 : (foo.com, mail.bar.foo.com, MX)
      → 하나의 별칭이 해당 회사의 메일 서버와 다른 서버들을 통칭하는 이름으로 사용될 수 있음.

RFC1034, page 11 - 더 많은 타입 종류
RFC1034, page 12 - 타입별 Value 값

  • 하나 이상의 자원 레코드를 전송하는 경우
    • 요청을 받은 서버가 해당 호스트의 책임 DNS 서버일 경우
      1. 호스트의 IP 주소를 알기 때문에 이를 응답하기 위한 Type A 레코드를 응답
    • 요청을 받은 서버가 해당 호스트의 책임 DNS 서버가 아닐 경우
      1. 해당 호스트를 포함하고 있는 DNS 서버의 호스트 명을 응답하기 위한 Type NS 레코드를 응답
      2. 알려주려고 하는 DNS 서버의 IP 주소를 응답하기 위한 Type A 레코드를 응답

 

DNS 메시지

  • 헤더 영역 (12 bytes)
    • 질의 식별자 (16 bits) : 질의/응답 메시지에 동일한 값을 사용하는 것으로 질의/응답 간의 일치를 식별한다.
    • 플래그
      • 질의/응답 플래그(1 bit) : 메세지가 질의(0)인지 응답(1)인지 구분
      • 책임 플래그(1 bit) : 응답하는 DNS 서버가 책임 DNS 서버일 때 설정되는 플래그
      • 재귀 요구 플래그(1 bit) : DNS 서버가 질의에 맞는 레코드를 가지고 있지 않을 때 재귀적 질의를 수행하길 원할 경우 클라이언트 측에서 설정하는 플래그
      • 재귀 - 가능 플래그(1 bit) : DNS 서버가 재귀적 질의를 지원할 수 있는 경우 응답 메시지에 설정되는 플래그
    • 질문 수, 답변 RR 수, 책임 RR 수, 추가 RR 수(각 16 bits 씩 4개)
      : 헤더영역 이후에 오는 영역들에 대한 갯수 정보
  • 질문 영역
    : 현재 질의에 대한 정보
    • 이름 필드 : 질의되는 이름을 포함할 필드
    • 타입 필드 : 이름에 대해 문의되는 질문 타입을 지정할 필드
  • 답변 영역
    : (응답에 포함) 처음 질의된 이름에 대한 자원 레코드
    • 하나의 호스트 명에 대응되는 IP 주소가 여러 개가 존재할 수 있기 때문에 한 개 이상의 응답 레코드를 가진다.
  • 책임 영역
    : 다른 책임 서버의 레코드
  • 추가 영역
    : 그 밖에 도움이 되는 레코드
    • MX 질의에 대한 응답의 응답 필드로 MX 서버의 정식 호스트 네임을 가진다.
      → 이 때 추가 영역에는 정식 호스트 네임의 IP 주소를 제공하는 Type A 레코드가 있다.

 

DNS 데이터베이스에 레코드 삽입

  • 도메인 네임을 등록기관에 등록하는 절차
    1. 등록기관 : 도메인 네임의 유일성을 확인하고 해당 도메인 네임을 DNS 데이터베이스에 넣는다.
      (ICANN에 의해 승인된 등록기관의 리스트 확인 사이트 : http://www.internic.net)
    2. 등록 시 주책임 DNS서버와 부책임 DNS서버의 이름과 IP주소를 등록기관에 제공해야 한다.
      1. 이렇게 제공된 이름과 IP 주소를 각각 type NS와 type A RR을 이용하여 TLD DNS 서버에 저장한다.
      2. (ex) (networkutopia.com, dns1.networkutopia.com, NS)
                (dns1.networkutopia.com, 212.212.212.1, A)
    3. networkutopia.com이 책임 DNS 서버에 Type A RR 로 저장되는지 확인한다.
      → 최근에는 이를 DNS 동적 갱신 방식으로 기술하고 있다.
  • 등록된 도메인 네임을 불러오는 절차

'Network' 카테고리의 다른 글

Tracert와 Traceroute  (0) 2023.05.26
콘텐츠 분배 네트워크(CDN)  (0) 2022.03.28
Network 개요  (0) 2022.03.01

 

정보 기술이 발달함에 따라 뉴스의 매체가 종이에서 텔레비전, 그리고 인터넷으로 바뀌고 있다.
이에 더해, 최근에는 종이 신문을 디지털화한 형태인 뉴스레터라는 구독 서비스도 생기고 있는 추세이다.

많은 뉴스레터 서비스가 생기고 있는 와중에, 정보보안을 주제로 하여 꾸준히 뉴스레터를 발행하고 있는 곳이 있다.

 

 

바로 해킹짹짹이라고 하는 서비스인데, 이 서비스를 제공하고 있는 해키보이즈라는 팀에서 잠깐 같이 공부하며 뉴스레터를 써볼 수 있는 기회가 있었다. 그리고 그렇게 해서 쓴 글이 위 이미지에서 볼 수 있는 Digital Forensics Challenge ... (바로 지난주 금요일에 발행된 뉴스레터이다!)

디지털 포렌식에 관심을 가져왔기 때문에 관련 글을 써보고자 하는 마음에 정하게 된 주제였다.

주제를 정하고 글을 작성하던 와중에 한 팀원분의 인맥 덕분에 실제 DFC에서 우승하신 분까지 인터뷰 할 수 있는 기회를 얻었고,
그 결과 처음 주제를 정하면서 생각했던 것보다 훨씬 유익한 글을 쓸 수 있게 되어 기쁜 마음으로 발행했던 것 같다.

당시 작성했던 글은 아래 링크에서 확인할 수 있다!

 

🎙️ 포렌식 뉴비를 위해!

해커의 TMI 29화: 디지털 포렌식 챌린지 안녕하세요! 오늘은 조금 특별한 CTF를 소개해드리려고 합니다.

stibee.com

 

처음이자 마지막으로 작성해본 뉴스레터가 앞으로 하려고 하는 공부의 방향을 잡는데에도 많은 도움이 될 것 같아 여러 가지로 유익한 시간이었다고 생각한다.😊

네트워크를 제대로 공부해봐야지.. 라고 생각하며 네트워크 스터디를 시작했다.

네트워크 전반에 대해서 본격적으로 공부해보는게 처음이라 아직 엉성하지만 중간점검 한다고 생각하고 기록용으로 올려둔다.

이제부터는 여기에 살을 붙여가면서 공부할 예정이다. 파이팅!

 

Network 일반

데이터 통신 방식

obvious-phlox-33e.notion.site

 

'Network' 카테고리의 다른 글

Tracert와 Traceroute  (0) 2023.05.26
콘텐츠 분배 네트워크(CDN)  (0) 2022.03.28
DNS(Domain Name System)  (0) 2022.03.28

 

문제 파일로는 jpg 포멧의 사진 하나를 준다.

사진을 다운받아 열면 아래와 같은 사진을 볼 수 있다.

 

 

여기서 플래그를 찾아야되는건데..
자세히 보면, 가운데 무슨 글씨가 보인다.. jump..???

 

 

그냥 단순히 사진 확대를 해도 뭔가가 더 보이기는 하는데.. 여전히 확실하게 보기는 힘들다...

그러다 알게된 툴이 Forensically 인데, 온라인 이미지 포렌식 툴이라고 한다.

이 사이트에 접속한 후 파일을 오픈하고 돋보기 기능(Magnifier)을 사용하면 아래와 같이 플래그를 볼 수 있다.

 

 

+ 여기에서 돋보기 기능과 함께 Level Sweep도 적용하니 색상 구분이 좀 더 명확하여 구분하기 용이했다.

+ Recent posts