패킷·로그·지표 상관과 네트워크 장애진단

TCP·UDP·DNS·HTTP·TLS 프로토콜 분석에서 필드·상태·시간·방향을 먼저 읽는다. 이 절은 그 대화를 원본 시각·보정·불확실성과 두 지점의 손실 후보에 연결한다.

0. 느린 화면 하나에는 서로 다른 시간이 섞여 있다

사용자가 10초 걸렸다고 말해도 네트워크가 10초 동안 느렸다고 바로 결론 내릴 수 없다. 이름 해석, 연결 수립, 암호 협상, 서버 대기·처리, 데이터 전송과 브라우저 작업이 한 응답시간에 들어 있다. 패킷에는 통신 시각과 순서가 보이고, 로그에는 응용 사건과 이유가 남으며, 지표에는 일정 구간을 집계한 자원·대기 상태가 보인다. 어느 하나도 전체 사실은 아니다.

네트워크 분석은 이 조각을 한 시간축과 서비스 경로에 놓는 일이다. 중요한 질문은 패킷이 몇 개인가가 아니라 어디까지 정상으로 갔고, 어느 구간에서 시간이 늘거나 데이터가 사라졌으며, 그때 장치·호스트·응용 상태가 어떠했는가다.

네트워크 분석: 경로·시간·상태 증거로 원인범위를 줄인다

네트워크 분석은 서비스 통신경로의 여러 지점에서 얻은 패킷, 로그와 지표를 시간·방향·대화·구간에 맞춰 서로 연관 지어 도달성, 지연, 손실, 혼잡과 종단 처리의 정상·이상 경계를 판단하는 과정이다. 프로토콜 분석이 메시지 필드와 상태규칙에 초점을 둔다면 네트워크 분석은 그 결과를 전체 서비스 경로와 운영증거에 연결한다.

분석의 산출물은 원인 이름 하나가 아니다. 증상과 영향, 관찰경로, 마지막 정상과 최초 이상, 근거와 반증, 확신수준, 추가 검증, 복구·재발방지를 남겨 다른 사람이 같은 증거로 판단을 재현하게 한다.

전체에서 어디인가: 세 증거를 서비스 경로에 겹친다

정확한 원본·보정·불확실성과 전체 사건 기록은 아래 보존된 증거 표에서 확인한다. 마지막 정상/최초 이상과 가설 검증 절차로 연결한다.

증거가 많다고 자동으로 정확해지는 것은 아니다. 서로 다른 시계, 수집 간격, 포착 손실, 암호화와 식별자 부재 때문에 잘못 연결할 수 있다. 상관은 먼저 같은 사건일 가능성을 높일 뿐이며 원인·결과는 시간순서와 메커니즘, 반증으로 확인한다.

먼저 알아둘 것

지연시간은 한 작업의 경과시간, 대역폭은 전달용량 상한, 처리량은 실제 단위시간 완료량이다. 관측가능성은 외부 출력으로 내부상태를 추론하는 능력이고 사건대응은 증거를 모아 영향을 통제·복구·학습하는 과정이다. 앞 절의 프로토콜 분석은 TCP·DNS·HTTP·TLS의 필드·상태·시간관계를 읽는 일이며, 여기서는 그 결과를 패킷·로그·지표 상관에 사용한다.

1. 측정대상을 먼저 정의한다

지연과 손실: 시작·끝·패킷 유형·기다림을 선언한다

단방향 지연(one-way delay)은 정의한 출발지에서 특정 유형 패킷의 첫 비트를 보낸 사건부터 정의한 도착지에서 그 패킷의 마지막 비트를 받은 사건까지의 시간차다. 서로 다른 두 지점의 시각을 빼므로 시계 동기와 오차를 함께 보고해야 한다. 측정 패킷의 출발·도착, 유형, 시각과 오류범위를 정하지 않은 네트워크 지연 숫자는 재현하기 어렵다.

단방향 패킷 손실(one-way packet loss)은 출발지에서 보낸 특정 패킷이 정한 기다림과 관찰조건 안에 목적지에서 관찰되지 않은 사건이다. 늦게 도착한 패킷을 손실로 분류하는 경계, 송수신 포착 누락과 실제 네트워크 손실을 구분해야 한다. 손실률은 손실로 분류한 표본 수 / 유효하게 보낸 표본 수이며 표본 유형·기간·경로를 함께 쓴다.

왕복시간(Round-Trip Time, RTT)은 한 지점에서 메시지를 보내고 대응 응답이나 확인을 받을 때까지의 시간이다. 순방향·역방향 지연과 상대 처리시간이 섞일 수 있어 단순히 2로 나눈 값을 단방향 지연으로 단정하지 않는다.

지연은 전송·전파·처리·대기와 종단시간으로 분해한다

• 전송 지연: 패킷 비트를 링크에 밀어 넣는 시간으로 패킷 크기와 링크 전송률에 좌우된다.
• 전파 지연: 신호가 매체 거리를 이동하는 시간이다.
• 처리 지연: 장치·호스트가 머리와 정책을 검사하고 다음 동작을 정하는 시간이다.
• 대기열 지연: 먼저 온 데이터가 자원을 사용하는 동안 기다리는 시간이며 부하에 따라 크게 변한다.

사용자 응답시간에는 DNS·TCP·TLS·서버 큐·응용·DB가 더해진다. 평균 하나 대신 단계별 시작·종료, 중앙값과 높은 백분위, 표본 수와 구간을 본다. 백분위는 관측값을 작은 순서로 놓았을 때 일정 비율이 그 이하인 경계값이다.

서버별 p95의 평균을 내면 전체 p95가 되지 않는다. 서버마다 요청 수와 지연 분포가 다르기 때문이다. 전체를 구하려면 같은 관측 구간·대상·단위의 원래 표본을 합쳐 정렬하거나, 호환되는 구간 경계와 의미를 가진 히스토그램의 분포를 합쳐야 한다. 이미 계산한 백분위 숫자만으로 원래 분포를 복원할 수는 없다. 히스토그램에서 추정한 백분위에도 구간 폭에 따른 오차가 있으므로 표본 수와 계산 방식을 함께 남긴다.

혼잡: 들어오는 부하가 처리능력을 오래 넘어서 대기·손실이 커진다

네트워크 혼잡은 링크나 장치에 들어오는 트래픽 부하가 가용 처리·전달 능력에 비해 커져 대기열 증가, 지연 변동과 패킷 폐기가 나타나는 상태다. 패킷 폐기(drop)는 장치가 받은 패킷을 다음으로 전달하지 않고 버리는 사건이다. 순간적인 높은 이용률 하나와 지속 혼잡을 같게 보지 않는다. 시간에 따라 대기열·지연이 먼저 늘고 버퍼 한계를 만나 폐기·재전송이 늘며 유효 처리량이 악화되는지를 본다.

손실도 모두 혼잡은 아니다. 물리 오류, 정책 폐기, 경로 불일치, 수신 버퍼, 포착장치 과부하가 원인일 수 있다. 반대로 손실이 아직 없어도 커지는 대기열이 지연을 높일 수 있다. 따라서 지연, 손실, 혼잡은 서로 관련되지만 동의어가 아니다.

지연·손실·혼잡을 같은 표에서 구분한다

상관된 시간 변화 + 설명 가능한 메커니즘 + 대안 원인의 반증이 모일수록 판정이 강해진다.

2. 세 증거의 장점과 맹점을 안다

패킷 캡처: 선 위에 보인 메시지와 시간의 표본

패킷 캡처는 정한 인터페이스·지점에서 관찰된 프레임·패킷의 일부 또는 전부와 타임스탬프를 기록한 증거다. 캡처 필터는 수집할 패킷 자체를 제한하고, 디스플레이 필터는 이미 수집한 패킷 중 화면에 보일 것을 고른다. 전자를 잘못 쓰면 나중에 숨긴 패킷을 되살릴 수 없다.

패킷은 방향·순서·필드·간격을 잘 보여 주지만 포착지점 밖의 사건과 송신기 내부 cwnd, 서버 큐의 이유를 직접 보여 주지 않는다. 분석도구의 대화 따라가기(Follow Stream), 재조립과 전문가 정보(Expert Information)는 대화를 모으고 단서를 찾는 기능이지 원인을 확정하는 판정자가 아니다.

캡처 누락(capture drop)은 관측 장치나 수집 프로그램이 버퍼·처리용량 부족 때문에 관찰 대상 패킷을 기록하지 못한 상태다. 타임스탬프의 원천·정밀도·정확도, 잘린 캡처 길이와 캡처 누락 수를 기록한다. 호스트 송신 오프로딩 때문에 실제 선로로 나가기 전 큰 단위가 보이거나 체크섬이 아직 채워지지 않아 오류처럼 표시될 수 있으므로 다른 지점·인터페이스 통계와 대조한다.

로그: 구성요소가 해석한 사건 기록

로그는 구성요소가 관찰·판단한 사건을 시간·출처·종류·문맥과 함께 남긴 기록이다. syslog 구조에서 발신자(originator)는 메시지를 만들고 중계자(relay)는 전달하며 수집자(collector)는 모은다. 메시지는 우선순위와 버전, 타임스탬프, 호스트·응용·프로세스·메시지 식별정보, 구조화 데이터와 자유 메시지로 구성될 수 있다.

로그는 인증서 검증 실패, 요청 큐 진입, 경로 없음처럼 패킷만으로 모르는 내부 판단을 준다. 그러나 로그가 없다고 사건이 없었던 것은 아니다. 로그 수준·분기·버퍼·전송 손실·중계 과정의 변형·시계 오류가 있고, 메시지 출처·기밀성·무결성이 자동 보장되지 않는다. 원본·수집본과 전송경로, 시간 오차를 함께 보존한다.

사건 발생 시각과 수집기가 관측한 시각을 구별한다. 예를 들어 응용이 10:00:01에 기록한 사건을 버퍼에 모았다가 수집기에 10:00:04에 전달할 수 있다. OpenTelemetry 로그 모델의 Timestamp는 원천에서 사건이 발생한 시각이고, ObservedTimestamp는 수집 시스템이 관측한 시각이다. 후자를 기준으로 정렬하면 버퍼·전송 지연 때문에 원래 사건의 순서가 바뀔 수 있다. 시계 오프셋을 보정하는 일과 기록이 늦게 도착한 이유를 분석하는 일은 별개이며, 원천 시각이 없는 로그에 수집 시각만 있다고 정밀한 사건 순서를 확정해서는 안 된다.

관리 지표: 일정 구간의 상태와 추세

네트워크 관리 관측은 장치·호스트의 상태값과 사건을 수집해 용량·오류·가용성 변화를 판단하는 활동이다. 간이 네트워크 관리 프로토콜(Simple Network Management Protocol, SNMP)의 RFC 3411 관리구조는 관리 응용(manager), 관리대상 쪽 대리자(agent), SNMP 엔진의 분배기(dispatcher)·메시지 처리·보안·접근통제 기능을 분리한다.

이 절은 manager/agent와 보안·접근통제의 구조까지만 사용한다. SNMP PDU, 관리정보베이스(Management Information Base, MIB)와 관리정보구조(SMI)의 세부는 동반 RFC가 필요한 확인하지 못한 주장이므로 가르치지 않는다. 역사 문항의 SNMP 한 단어를 근거로 세부를 추측하지 않는다.

지표는 이용률, 큐 깊이, 오류·drop 계수, 처리량 같은 추세를 보여 주지만 수집주기 사이의 짧은 급증이 평균에서 사라질 수 있다. 누적 계수(counter)는 사건 수가 계속 더해지는 값이고, 초기화(reset)는 다시 시작하며 값이 작아지는 일, 되감김(wrap)은 정해진 최댓값을 넘은 계수가 처음 값으로 돌아가는 일이다. 증가량을 초당 비율(rate)로 바꿀 때 이 둘과 실제 경과시간을 확인한다. 메트릭 레이블(metric label)은 인터페이스·인스턴스처럼 시계열을 구별하는 이름표이고, 시간 버킷(time bucket)은 여러 표본을 한 값으로 집계한 시간구간이다. 합계·평균·최댓값·백분위, 레이블 범위와 버킷 길이를 함께 기록한다.

같은 인터페이스의 누적 폐기 수가 10:00:00에 1200, 10:00:05에 1450이고 그 사이 초기화·되감김이 없었다면 증가량은 1450−1200=250건, 관측 구간 평균은 250/5=50건/초다. 1450을 5로 나누면 장치가 오래전부터 센 사건까지 현재 구간에 넣는 오답이다. 또한 이 폐기 수는 특정 사용자 대화의 유효 송신 표본 수가 아니므로 곧바로 그 대화의 손실률로 사용하면 안 된다.

직접 풀어 보기 — 자체 조건 변경

확인 문제로 다음 값이 10:00:10에 100으로 작아졌다면 (100−1450)/5=−270건/초를 정상 비율로 보고할 수 있는가?

패킷·로그·지표는 서로를 대체하지 않는다

패킷이 지연된 시각에 서버 로그가 요청을 아직 받지 못했다면 네트워크·수신경계 후보가 커지고, 서버 로그가 처리 시작 후 오래 머물렀다면 종단 처리 후보가 커진다. 같은 시간의 중앙처리장치(CPU) 이용률 100%만으로 원인이라 하지 않고 해당 요청의 서버 체류시간과 큐·처리량을 맞춘다.

3. 증거 상관: 같은 사건을 시간·식별자·경로로 묶는다

증거 상관은 서로 다른 수집원에서 나온 기록이 같은 실제 사건 또는 인과사슬을 가리키는지 시간, 식별자, 방향, 위치와 상태전이로 대조하는 과정이다. 시계 오프셋(clock offset)은 같은 실제 순간을 두 시계가 서로 다른 값으로 표시하는 차이다. 공통 시간축은 원본 타임스탬프를 지우고 한 값으로 덮어쓰는 것이 아니다. 각 원본 시각, 시간대, 추정 오프셋, 동기상태와 불확실성 범위를 보존한 채 비교용 시각을 만든다.

상관키는 같은 사건 후보를 묶는 값이다. 요청·추적 식별자(request/trace ID)가 가장 직접적일 수 있지만 없으면 주소·포트, DNS 식별자와 질문, TCP 순서범위, HTTP 스트림 식별자, 호스트·프로세스, 메시지 식별자와 가까운 시각을 조합한다. 하나의 키는 재사용·변환될 수 있으므로 둘 이상을 맞춘다.

불확실성은 측정값이나 사건 연결이 참값에서 벗어날 수 있는 알려진 범위와 원인이다. 시계 오차 ±20 ms와 지표 수집주기 60 s를 가진 증거를 1 ms 단위의 정확한 선후관계처럼 쓰지 않는다.

하나의 사용자 요청을 사건 사슬로 만든다

정규화 비교시각      위치/증거             사건                         연결키
10:00:00.000         클라이언트 로그         클릭                         trace=7
10:00:00.010         클라이언트 패킷         DNS 질의                     id=31,name=S
10:00:00.040         클라이언트 패킷         DNS 응답                     id=31,name=S
10:00:00.050         경계 포착              TCP SYN                      A:p→B:443
10:00:00.090         경계 포착              TCP 연결 수립                 A:p↔B:443
10:00:00.150         서버 로그              요청 수락                     trace=7
10:00:03.150         서버 로그              응답 준비                     trace=7
10:00:03.160         클라이언트 패킷         응답 첫 바이트                순서번호 범위

불확실성: 클라이언트 ±2 ms, 서버 오프셋 +15±5 ms, 지표 버킷 60 s

이 예에서는 DNS와 TCP 수립은 짧고 서버 수락부터 응답 준비까지 약 3초다. 그래서 네트워크 전체 3초보다 서버 내부 체류 후보가 강하다. 다만 서버 시계 오프셋과 중계 서버(proxy)의 대기 여부를 확인하고, 같은 구간의 CPU·데이터베이스·서버 작업자 대기열 지표로 가설을 검증한다. 시간상 함께 나타난 지표만으로 인과를 확정하지 않는다.

위 표는 이미 정규화한 비교시각이므로 서버의 +15ms를 다시 빼지 않는다. 예를 들어 서버 원본 기록 10:00:00.165에서 기준시계보다 빠른 추정 오프셋 15ms를 한 번 빼면 표의 요청 수락 10:00:00.150이 된다. 응답 준비의 원본 10:00:03.165도 같은 방법으로 10:00:03.150이 된다. 오프셋 추정의 ±5ms는 변환 후 남는 불확실성이지 또 뺄 보정값이 아니다.

서로 다른 시계의 사건을 빼면, 예를 들어 서버 응답 준비와 클라이언트 첫 바이트 사이 명목상 10ms에는 최악 경계 합 ±(5+2)=±7ms가 붙어 3~17ms 범위가 된다. 이는 단순 경계합이지 확률적 신뢰구간이 아니며 로그 생성·포착 위치 차이가 있으면 실제 전송지연과도 다를 수 있다. 반면 같은 서버 시계의 .165→3.165 간격은 일정한 +15ms 오프셋이 상쇄되어 3초다. 구간 중 시계 보정·드리프트·기록 지연이 변하면 그 오차는 상쇄되지 않으므로 단조시계와 계측경계를 확인한다.

오차 범위가 0을 가로지르면 사건 순서도 아직 확정하지 못한다. 같은 오차 조건에서 두 시각의 명목 차이가 4ms라면 경계는 4±7ms, 즉 −3~11ms다. 음수 하한은 물리적으로 음의 전송지연이 발생했다는 뜻이 아니라, 시계·계측 오차가 그 정도 차이보다 커서 선후관계를 분리하지 못했다는 뜻이다. 하한을 임의로 0으로 바꿔 정확도가 높아진 것처럼 보고하지 말고 원래 범위와 계측 위치를 남긴다. 앞 도식의 10ms 차이와는 다른 수치를 대입한 연습 사례다.

직접 풀어 보기 — 자체 조건 변경

오프셋의 부호를 스스로 확인하는 연습도 하자. 서버가 이번에는 기준보다 10ms 느리고, 원본 수락 시각이 10:00:00.140이라면 오프셋은 −10ms다. 비교시각을 계산하고, 이미 정규화된 값에 다시 적용해도 되는지 설명한다.

상관 전에 네 가지를 정규화한다

1. 시각: 원본 값·시간대·시계 원천·오프셋·정확도와 수집지연을 보존한다.
2. 식별자: 주소변환(NAT)·중계 서버 전후의 주소·포트와 요청 식별자의 생성·전파·재사용 범위를 표시한다.
3. 단위·집계: 바이트/비트, 초/밀리초, 누적 계수/초당 비율, 평균/백분위와 버킷을 맞춘다.
4. 위치·방향: 클라이언트→서버, 유입→유출과 인터페이스·인스턴스·프로세스를 표시한다.

정규화 뒤에도 연결은 후보일 수 있다. 강한 직접키, 여러 필드 조합, 시간만 근접처럼 연결 강도를 표시하고 서로 맞지 않는 반증을 삭제하지 않는다.

4. TCP 흐름 진단: seq/ack를 시간과 양 끝 지표에 연결한다

TCP 흐름 진단은 연결의 수립·데이터 진행·손실복구·흐름제어·종료를 seq/ack, 플래그, 시간과 종단 상태로 재구성해 어느 방향과 구간에서 진행이 막혔는지 판단하는 일이다. 패킷에 보이는 수신 Window와 송신기 내부 cwnd를 구분하고, 재전송 표시를 실제 순서범위·ACK 진행과 대조한다.

한쪽 포착만으로 누가 버렸는가를 확정하기 어렵다. 송신 지점에는 있는 순서범위가 수신 지점에 없다면 두 지점 사이의 손실 후보가 되고, 수신 지점에는 있는데 응용 로그가 없다면 호스트 전송계층 이후·응용 경계를 본다. 양쪽 포착의 시계와 캡처 drop을 먼저 검증한다.

송신자의 RTO는 모호하지 않은 RTT 표본에서 평활 RTT와 변동을 추정하고 타임아웃에는 backoff하지만, 재전송된 세그먼트의 ACK는 어느 전송을 확인했는지 모호해 그대로 RTT 표본으로 쓰지 않는다. 다만 TCP 타임스탬프 옵션으로 ACK가 확인한 전송 인스턴스의 모호함을 제거할 수 있다면 재전송의 RTT 표본도 사용할 수 있다. 단순히 옵션이 보인다는 사실만으로 모든 ACK의 모호함이 제거됐다고 단정하지 않는다. Reno 기준은 내부 cwnd·ssthresh의 slow start, congestion avoidance와 fast retransmit/recovery를 사용하고 CUBIC은 마지막 혼잡사건 뒤 시간에 따른 곡선으로 윈도를 조절한다. 어느 알고리즘도 패킷에 정확한 cwnd를 싣지 않으며, 모든 연결이 CUBIC을 쓴다고 가정하지 않는다. 구체 작동원리는 TCP·UDP·DNS·HTTP·TLS 프로토콜 분석을 참조하고 이 절에서는 관측한 패턴과 호스트 내부지표를 분리한다.

패턴은 원인이 아니라 다음 검증을 고르는 단서다

중복 ACK 세 번 뒤 빠른 재전송, RTO 뒤 재전송 같은 동작은 앞 절에서 배운 상태규칙으로 확인한다. cwnd와 ssthresh는 캡처에 직접 없으므로 확인되지 않은 전송량(flight size)의 패턴만으로 정확한 내부값을 단정하지 않는다.

재전송을 두 지점에서 대조한다

예시

송신 호스트 포착 A에는 seq 1001~2000이 t1에 있고, 수신 서버 앞 포착 B에는 그 범위가 없다. A에서 뒤 범위가 전송된 뒤 같은 ACK가 반복되고, RTO 전 빠른 재전송으로 1001~2000이 다시 나가 B와 서버에 도착했다고 하자. 같은 시각 중간 장치의 출력 대기열 폐기 계수가 증가했다.

이 증거는 A와 B 사이에서 해당 범위가 첫 시도에 관찰되지 않았고, 손실복구와 장치 폐기 증가가 시간상 맞는다는 강한 구간 손실 후보를 만든다. 그러나 A의 캡처 중복·B의 캡처 누락·두 시계 오차를 확인해야 한다. 큐 클래스(queue class)는 장치가 같은 스케줄링·폐기 정책으로 다루는 트래픽 묶음이다. 해당 인터페이스와 큐 클래스의 부하·대기열·폐기가 함께 증가했음을 확인한 뒤에만 구간 손실 후보를 혼잡 가설로 승격한다.

반대로 B에도 첫 전송이 있는데 서버 응용이 읽지 못하고 Window가 줄었다면 네트워크 중간 손실보다 수신 호스트·응용 소비 경계가 우선이다. 같은 재전송이라도 위치 대조가 원인범위를 바꾼다.

전방 패킷이 안 보일 때 역방향 누적 ACK도 대조한다. 같은 TCP 연결에서 수신자가 이전에는 1001을 기다렸는데 재전송 전에 유효한 ACK 2001을 보냈다면, 그때까지 2000번 바이트까지 연속으로 받았다는 증거다. 관측점 B의 전방 캡처에 그 바이트가 안 보인다는 이유만으로 수신자 미도착이나 손실을 확정할 수는 없다. 필터·캡처 누락·비대칭 경로·오프로딩과 그 연결의 전송 이력을 다시 확인한다. 누적 ACK는 바이트 수신 증거이며, 응용이 읽고 업무 처리를 완료했다는 증거는 아니다.

5. 실패통제와 재현 가능한 절차

분석 자체가 만드는 오류를 먼저 막는다

개인정보·인증정보·업무 데이터가 패킷과 로그에 들어갈 수 있다. 수집범위·권한·마스킹·보존기간과 접근기록을 먼저 정하고 검수자료에는 원본 민감정보를 노출하지 않는다.

열 단계로 증상에서 검증된 경계까지 간다

1. 증상·영향 정의: 사용자·기능·시작/종료·빈도·정상 기준을 적는다.
2. 경로·가설 지도: DNS→연결→TLS→응용→데이터베이스와 가능한 병목·실패경계를 그린다.
3. 측정 계약: 지연 시작/끝, 손실 기다림, 표본·구간·방향과 성공조건을 정한다.
4. 증거 계획: 필요한 양지점 패킷, 로그, 지표와 권한·민감정보 통제를 정한다.
5. 품질 검증: 시계·캡처 누락·필터·집계주기·로그 누락을 확인한다.
6. 대화·사건 분리: 프로토콜·주소·포트·식별자·순서번호·추적값과 위치로 후보를 묶는다.
7. 공통 시간축 구성: 원본시각과 오프셋·불확실성을 보존하며 단계시간을 계산한다.
8. 마지막 정상/최초 이상: 패킷 상태와 로그·지표 변화를 경계별로 놓는다.
9. 가설 검증·반증: 대안 원인과 기대증거를 정해 추가 포착·로그·시험으로 확인한다.
10. 조치·재시험: 복구 뒤 같은 측정계약으로 전후를 비교하고 증거·한계를 보존한다.

다른 절과 연결해 읽을 범위

이 절은 네트워크 분석, 단방향 지연·손실 측정, 패킷·로그·지표 증거의 한계와 상관, TCP 흐름 진단을 설명한다. TCP·UDP·DNS·HTTP·TLS 메시지와 상태의 정식 설명은 프로토콜 분석이고, Ethernet·IPv6의 전달경계는 앞 절의 참조모델과 캡슐화 설명을 사용한다.

SNMP는 manager/agent와 engine 보안·접근통제의 관리구조까지만 사용한다. MIB·SMI·PDU 세부와 현대 telemetry 제품 비교는 별도 근거와 설명이 필요하다. 용량·경로·QoS 설계는 네트워크 설계와 통신시스템, 사고대응 조직·절차는 정보보안의 사고대응에서 이어진다.

네트워크 분석에서 확인할 학습 내용

측정 정의에서 진단·반증·재시험까지 다음 연결을 스스로 설명해 본다.

• 정의: 네트워크 분석, 단방향 지연·손실, 혼잡, 증거 상관과 TCP 흐름 진단의 정식 정의를 둔다.
• 작동원리: 서비스 경로, 공통 시간축, 두 지점 seq/ack 대조와 패킷·로그·지표 연결을 설명한다.
• 비교: 지연/손실/혼잡, 패킷/로그/지표, TCP 관찰패턴을 같은 축에서 분리한다.
• 실패조건: 시계·집계·캡처 누락·오프로딩·단일지점·상관/인과 혼동을 통제한다.
• 절차: network-analysis-ten-step-procedure가 측정계약부터 반증·재시험까지 재현 가능하게 만든다.
• 연습(practice)·답안 전환: 아래 기출 공백을 보완하는 10점·25점 문제의 목차·도식·모범답안으로 논점을 추적한다.

앞의 계층·전달경계와 프로토콜 필드·상태를 바탕으로 관찰 증거를 연결한다. 프로토콜의 기대 동작과 서비스 원인 진단을 구별한다.

6. 기출 공백과 답안 전환

감사한 15문항 중 S03 direct는 0건이다

패킷·로그·지표 상관 진단은 감사한 15개 문항 중 패킷·로그·지표를 한 시간축에서 상관해 진단하라고 직접 요구한 문항이 없다는 신규공백 후보다. 관련 문항을 억지로 direct로 바꾸지 않는다.

AI가 공식 원문 이미지를 재감사했지만 독립 사람 승인은 0이다. 직접 기출이 없다는 것은 공식 범위가 불필요하다는 뜻이 아니라, 2027 범위를 위해 현재형 연습문제를 새로 만들어야 한다는 뜻이다.

시험에서는 어떻게 묻는가: 10점

다음은 패킷·로그·지표를 함께 연습하는 자체 제작 문제다.

단방향 지연, RTT와 단방향 패킷 손실의 측정 정의를 설명하고, 패킷 측정의 불확실성과 오판 방지방안을 제시하시오.

용어 정의에 시작·끝·표본·기다림·시계가 들어가야 한다. RTT를 반으로 나누어 단방향 지연이라고 쓰거나 미관찰을 곧 네트워크 폐기라고 단정하지 않는다.

시험에서는 어떻게 묻는가: 25점

다음도 신규공백을 위한 자체 제작 문제다.

간헐적으로 응답시간이 증가하는 HTTPS 서비스의 원인을 패킷·로그·지표 상관분석으로 진단하시오. 지연·손실·혼잡과 TCP 수신측 병목을 구분하는 절차, 도식, 증거 한계와 재검증방안을 포함하시오.

Wireshark로 본다에서 끝내지 않고 측정계약, 증거 품질, 공통 시간축, 마지막 정상/최초 이상, 반증과 전후 재시험까지 답한다.

근거와 현행성

단방향 지연의 정의·오차·통계는 RFC 7679 §§3.2–3.4, 3.6–3.8와 4–5를, 단방향 손실의 정의·방법 불확실성·손실률은 RFC 7680 §§2.2–2.4, 2.6–2.8, 3과 4.1을 확인했다. 네트워크 혼잡의 용어 경계와 일정 구간의 도착률이 출력능력을 넘을 때 지연·폐기가 생길 수 있다는 문맥은 현행 RFC 9522 §§1.4, 2.2를 사용했다. TCP 흐름의 필드·상태 경계는 RFC 9293 §§3.1, 3.3.2, 3.4, 3.5–3.8, 3.8.1–3.8.2와 3.8.6 중 본문 교육범위만, RTO는 RFC 6298 §§2–3, 5, 혼잡제어 동작은 RFC 5681 §§2, 3.1–3.2와 RFC 9438 §§3–4, 4.3–4.6, 4.8, 4.10의 본문 교육범위만 사용했다.

로그의 originator·relay·collector, 메시지 구조와 한계는 RFC 5424 §§4–5, 6–6.4, 8과 8.3–8.8을 사용했다. SNMP 관리구조는 RFC 3411 §§1.2, 3.1.1–3.1.3.2, 3.3, 4.4와 4.6만 사용했으며 PDU·MIB·SMI 세부를 포함하지 않았다. 캡처/디스플레이 필터, Follow Stream, Expert Information, TCP 추론, timestamp, 재조립과 checksum offload는 Wireshark User’s Guide 4.7.3 §§4.10, 6.4, 7.2, 7.4, 7.5, 7.6, 7.6.3, 7.8.1–7.8.3과 7.10.1–7.10.3을 버전 고정 도구 사례로 확인했다.

본문의 증거 상관 절차는 패킷·로그·지표에 관한 위 공식 자료의 정의와 관측 한계를 넘지 않도록 교재가 자체 구성한 제한적 종합이다. 어느 하나의 표준이 이 상관 절차 전체를 정의한다고 주장하지 않는다. 모든 표·타임라인·패킷 예시와 문제도 교재를 위해 독자적으로 구성했다. 실제 패킷 화면·운영 로그·표준 그림을 복제하지 않았고, 도구 라이선스가 실제 트래픽의 개인정보·기밀정보 권리를 허가하는 것으로 보지 않는다. 기준 확인일은 2026-09-01이며 rolling 도구 문서는 새 버전 또는 2026-12-01에 재검토한다. 기술·출제·기출·권리에 대한 사람 승인 수는 0이고 상태는 candidate / human-validation-pending다.

30초 정리

1. 네트워크 분석은 패킷·로그·지표를 서비스 경로와 공통 시간축에 놓아 마지막 정상과 최초 이상을 찾는다.
2. 단방향 지연은 두 지점 시계, RTT는 양방향·상대처리, 손실은 기다림 안의 미관찰이므로 측정계약과 불확실성이 필요하다.
3. 지연·손실·혼잡은 동의어가 아니며 대기열·폐기·RTT·재전송과 부하가 함께 움직이는지 본다.
4. TCP 진단은 seq/ack·재전송·rwnd를 읽되 cwnd는 패킷에 직접 없고 양지점·호스트 지표로 검증한다.
5. 실제 증거와 측정계약을 연습하려면 패킷–로그–지표를 한 사건에 연결하고 결론의 확인 한계를 남긴다.

다시 읽을 때는 측정계약→증거품질→시간·식별자 정규화→마지막 정상/최초 이상→반증→동일조건 재시험을 한 줄로 떠올린다.

직접 연습: 관측 숫자와 주장 사이의 조건을 점검한다.