개념 사전 · 프로토콜

NTP

Network Time Protocol · 네트워크 시간 프로토콜

는 네트워크로 주고받은 시각 정보를 이용해 컴퓨터 시계의 오차와 지연을 추정하고 동기화를 지원하는 프로토콜이다. 단일 서버 시각을 무조건 복사하는 방식이 아니며 여러 표본·원천 선택·의 영향을 고려한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 분산 시스템이 공통 시각 기준에 가까워지도록 돕는다.
  • 왕복 지연과 시계 offset을 별도로 추정한다.
  • 로그 상관분석·인증·예약 작업의 시각 기반을 제공한다.

02어떤 순서로 동작하나

  1. 요청 송신

    클라이언트가 자신의 시계에서 송신 시각 t1을 기록하고 서버에 요청한다.

  2. 서버 시각 기록

    서버가 수신 t2와 송신 t3를 자신의 시계 기준으로 응답에 넣는다.

  3. 응답 수신·계산

    클라이언트가 수신 t4를 기록하고 지연=(t4−t1)−(t3−t2), offset=((t2−t1)+(t3−t4))/2를 계산한다.

  4. ·조정

    구현이 여러 표본과 원천 품질을 평가해 시계 속도 또는 시각을 조정한다. 대칭 경로 가정의 오차는 남을 수 있다.

03먼저 알아둘 용어와 구성요소

는 클라이언트 송신 t1, 서버 수신 t2, 서버 송신 t3, 클라이언트 수신 t4를 사용해 서버가 클라이언트보다 얼마나 앞서 있는지와 왕복 지연을 추정한다.
오차 θ=((t2−t1)+(t3−t4))/2, 지연 δ=(t4−t1)−(t3−t2)다.
t1·t4는 클라이언트 시계, t2·t3은 서버 시계로 기록된다. 네 숫자를 한 장비의 연속 시각처럼 정렬하면 앞선 서버 시계 때문에 수신 시각이 더 작게 보이는 현상을 오해할 수 있다.
왕로 지연을 d1, 복로 지연을 d2, 실제 서버 시계 차이를 θ0라 하면 단순 추정 θ에는 (d1−d2)/2가 섞인다. 두 방향 지연이 같다는 가정이 깨지면 왕복 측정만으로 이를 모두 제거할 수 없다.
시간 동기화 구현은 여러 표본의 지연·흔들림과 여러 소스를 평가하여 시계 조정에 쓸 근거를 고른다. 단 한 번 작은 offset이 나온 사실과 안정적인 동기화는 다르다.
은 기준 시계와의 계층 관계이지 정확도를 보장하는 점수는 아니다.
LEARN THROUGH PRACTICE

시간 서버 설정과 클라이언트의 동기화 상태 대조하기

상위 시간원, 내부 제공 범위, 클라이언트의 ·offset·지연 지표를 연결해 시간 동기화의 상태를 읽는다.

실습 구성과 전제

  • 서버·클라이언트 설정과 Cisco 장비 상태 화면을 비교한다. 정지 화면의 시각이 서로 같다는 가정은 하지 않는다.
  • 서버와 클라이언트가 연결된 허용 실습망을 가정한다. 실제 시계를 변경하는 명령은 실행하지 않고 상태 조회로 해석한다.
  1. 상위 동기화와 내부 서비스 제공을 구분한다

    • 첫 설정의 pool은 상위 시간원을 선택하고 iburst는 초기 측정 자료를 빠르게 얻도록 요청을 묶어 보낸다. allow는 지정한 네트워크에서 오는 클라이언트 요청을 허용하는 설정이다.
    • makestep 1.0 3은 초기 세 번의 시계 갱신 동안 오차가 1초보다 크면 step을 허용하는 조건이다. 3초마다 시계를 강제로 바꾸라는 뜻이 아니다.
    ntp · 실습·개념 참고 화면 1원본 크기로 보기 ↗
    • pool 뒤 iburst가 붙고 driftfile, makestep 1.0 3, rtcsync 행이 보인다.
    • 별도의 allow 대역 설정이 있어 상위 시간 동기화와 내부 제공 범위를 나누어 읽을 수 있다.
    확인 기준

    allow만으로 네트워크 방화벽이나 서버의 상위 시간원이 정상이라고 결론내리지 않는다. 시계 step은 예약 작업·로그 시각에 영향을 줄 수 있다.

  2. 클라이언트가 선택한 시간원을 확인한다

    • 두 번째 설정은 pool 대신 특정 내부 서버를 server 지시어로 지정한다. 서버의 주소를 설정한 사실과 실제 응답을 받아 선택한 상태는 별개다.
    • 클라이언트에서는 chronyc sources와 tracking으로 현재 선택된 원천과 동기화 정보를 본다. chronyd는 동작하는 데몬이고 chronyc는 그 상태를 조회·관리하는 클라이언트다.
    bash
    chronyc sources -v
    chronyc tracking

    chronyd가 동작하는 클라이언트에서 시간원과 추정 상태를 조회한다.

    ntp · 실습·개념 참고 화면 2원본 크기로 보기 ↗
    • 기존 pool 행이 주석 처리되어 있다.
    • 내부 NTP 서버 하나를 server ... iburst로 지정한 행이 보인다.
    확인 기준

    chronyc 출력에서 선택된 원천 표시와 도달 상태를 확인한다. 설정 파일만으로 동기화 성공을 말하지 않는다.

  3. 동기화 표시와 시간 품질 지표를 함께 읽는다

    • Cisco 화면은 clock is synchronized와 11을 표시한다. 은 기준 시계로부터의 시간 계층이며 IP 라우터 홉 수나 오차 밀리초 값이 아니다.
    • offset 약 0.5635ms, root delay 약 23.93ms, root dispersion 약 3941.70ms를 구별한다. 작은 offset 하나만으로 절대 시각 정확도를 보장할 수 없고 상위 시간원의 품질과 불확실성도 함께 봐야 한다.
    text
    show clock
    show ntp status
    show ntp associations

    지원되는 계열 실습 장비의 상태 조회 명령이다.

    ntp · 명령·상태 출력 7원본 크기로 보기 ↗
    • show ntp status는 synchronized와 stratum 11 및 참조 서버를 표시한다.
    • offset, root delay, root dispersion이 서로 다른 밀리초 값으로 나열되고 poll interval도 별도로 보인다.
    확인 기준

    동기화됨은 현재 선택한 시간원과 동기화 관계가 있다는 상태다. 조직의 허용 오차나 믿을 수 있는 기준 시각을 만족하는지는 별도 기준으로 판단한다.

실습에서 확인한 동작 원리

  • 상위 시간원 선택, 내부 제공 허용, 클라이언트의 실제 동기화는 별도 단계다.
  • 동기화 상태··offset·delay·dispersion을 함께 읽어야 로그와 예약 작업의 시간 신뢰도를 설명할 수 있다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 왕로 8ms·복로 2ms, 실제 시계 차이 0인 단순 모델에서는 계산된 offset이 +3ms여서 이 시계 오차처럼 보일 수 있다.
  • 서버 처리 시간이 길어도 지연 공식은 t3−t2를 빼므로 전체 왕복 시간과 네트워크 지연 추정치를 구분한다.
  • 서로 다른 시간대의 로그는 동일 UTC 기준으로 맞춰 비교할 수 있지만 시스템 시계 자체의 동기화 오차는 시간대 표시 변경으로 해결되지 않는다.

05혼동하기 쉬운 점과 확인 기준

  • chronyc tracking의 offset·frequency·root delay·root dispersion은 서로 다른 관찰값이다. 이 낮다는 이유만으로 네트워크 지연이나 시계 오차가 항상 더 작다고 판정하지 않는다.
  • 시작 02:15, 끝 02:14처럼 보이는 로그는 시계 조정·다른 시간대·수집 순서 차이도 조사해야 한다. 작업 duration은 적절한 단조 시계로 측정해 벽시각의 변화와 구분한다.
  • chronyd가 실행 중인데도 소스가 선택되지 않으면 sources와 tracking의 선택 상태·도달성·최근 측정 정보를 함께 읽는다. 예약 누락을 하나의 탓으로 결론내리기 전에 timer/의 실제 기동 기록도 대조한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.