# 프로토콜 프로젝트: 바이트와 응답 부재를 설명하기

> **실습 기준**: 자신이 소유한 Ubuntu Server 24.04 LTS 또는 Rocky Linux 9 게스트, 오프라인 분석과 제한된 루프백 트래픽
>
> **마지막 업데이트**: 2026년 9월 15일

## 목적과 진입 조건 {#purpose}

전문적인 프로토콜 조사는 애플리케이션의 주장을 특정 교환과 연결하고, 증거로 확인할 수 없는 범위를 밝힙니다.
이 워크북의 결과물은 프로브 대응 원장, HTTP/TCP 증거 묶음, 프로토콜 경계 보고서입니다.
대학 채점 과제의 정답이 아니라 이 과정을 위해 만든 독립적인 연습입니다.

복구와 최종 서비스 진단을 포함한 [입문 8개 장](https://www.atomai.click/kubernetes-docs/llms/ko/networking/beginner/README.md)을 먼저 완료하세요.
주소, 다음 홉, DNS 응답, 수신 대기 소켓, HTTP 상태를 구분할 수 있어야 합니다.
기본적인 Python 읽기, 바이트·16진수 표기, 두 파일 비교도 필요합니다.

증거를 수집하기 전에 다음 기존 문서를 읽으세요.

- [IP·ICMP·traceroute](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part1.md#icmp-traceroute-interpretation): 오류 발신자와 오류가 인용한 패킷을 구분합니다.
- [TCP와 TLS](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part2.md): 전송 계층 전달과 인증을 분리합니다.
- [HTTP/1.1 메시지 구조](https://www.atomai.click/kubernetes-docs/llms/ko/basics/06-network-fundamentals-part3.md#http11-message-structure): 헤더 종결 위치와 콘텐츠 바이트 수를 확인합니다.
- [Linux 네트워크 진단](https://www.atomai.click/kubernetes-docs/llms/ko/networking/07-linux-network-diagnostics.md): 기존의 실행 시간이 제한된 HTTP 도우미와 라우팅 실습 기록을 이해합니다.

## 공개 커리큘럼 연결 {#readings}

자료 접근 여부는 **2026년 9월 15일**에 확인했습니다.
[CS168 Fall 2026 사이트](https://fa26.cs168.io/)는 아직 구성 중입니다.
아래 순서는 접근 가능한 [공식 Summer 2026 아카이브](https://su26.cs168.io/)를 기준으로 하며, 일정은 과거 학기 일정입니다.
명세가 공개되어 있다는 사실이 수강, 모든 녹화 또는 학교 채점기 이용을 보장하지는 않습니다.

| 공개 자료 | 읽는 목적 | 이 장의 독립적인 결과물 |
|---|---|---|
| 아카이브 Intro 1–3, [CS168 교재](https://textbook.cs168.io/)의 계층·헤더·설계 | 역다중화와 최선형 전달 | 각 헤더와 이를 해석하는 구성 요소 표시 |
| [Project 1 안내](https://su26.cs168.io/proj1/guide/), [Project 1A 명세](https://su26.cs168.io/proj1/proj1a/) | TTL을 제한한 UDP 프로브와 인용 패킷 | 프로젝트 A: 응답을 송신 원장에 대응 |
| [Project 1B 명세](https://su26.cs168.io/proj1/proj1b/) | 불완전·무관·중복 응답 | 없는 홉을 만들지 않고 잘못된 증거 제외 |
| 아카이브 Routing 1–7, [Project 2 명세](https://su26.cs168.io/proj2/) | 라우팅 상태와 전달 동작의 차이 | [라우팅 정책과 수렴](https://www.atomai.click/kubernetes-docs/llms/ko/networking/expert/02-routing-policy-convergence.md)으로 연결 |
| 아카이브 Transport 1–4, [Project 3 명세](https://su26.cs168.io/proj3/) | 시퀀스 공간·수신 윈도·재전송·타이머 | 프로젝트 B: 스트림 전달·프레이밍·혼잡 분리 |
| 아카이브 DNS, HTTP/CDN, 종단 간 TLS 읽기 | 이름·보안·애플리케이션 경계 | 프로젝트 C: 경계마다 필요한 증거 선택 |

CS168 Project 3은 **혼잡 제어를 제외한 TCP 일부**를 구현합니다.
혼잡 강의는 별도로 읽어야 하며, 전송 과제 통과가 운영용 혼잡 제어기 검증을 뜻하지 않습니다.
아카이브 준비 안내에는 Python 3.7 테스트 기록과 서로 다른 학기 디렉터리 이름이 섞여 있습니다.
선택적으로 해당 과제를 수행한다면 그 과제의 환경 지침을 따르고 내려받은 정확한 리비전을 기록하세요. 이 워크북의 게스트 Python을 낮추지 않습니다.
교재는 베타라고 명시되어 있으므로 구현 세부사항은 프로토콜 표준과 대조합니다.

선택 심화인 **C++ 기반 CS144**는 바이트 스트림, 소유권, 빌드 도구와 디버깅을 이해한 뒤 진행합니다.
과거 진입 주소 `cs144.github.io`는 확인 시 사용할 수 없었습니다. 확인된 404 주소를 실습 선행 조건으로 삼지 않습니다.
학기를 선택하기 전에 Stanford 공식 강좌 목록과 해당 학기의 지침을 다시 확인하세요.
실제로 접근 가능한 시작 저장소, 라이선스, 컴파일러와 테스트를 기록합니다.
이 워크북은 무료 최신 저장소·채점기 또는 수강 경로를 보장하지 않습니다.
CS144는 완료 필수 조건이 아니며 여기에는 채점 과제 구현 코드를 싣지 않습니다.

## 도구 준비와 증거 규약 {#readiness}

[입문 게스트 도구 준비](https://www.atomai.click/kubernetes-docs/llms/ko/networking/beginner/README.md#guest-tools)로 돌아가세요. 도구 존재 여부는 가정이 아니라 통과 조건입니다.
그 문서의 필요한 패키지만 미리 검토하고 설치하는 절차를 폐기 가능한 게스트 안에서 사용합니다.
Rocky의 기존 `curl-minimal`이 동작하면 해당 공급자를 유지하세요.

| 이 장의 역할 | Ubuntu 패키지·공급자 | Rocky 패키지·공급자 | 필요 여부 |
|---|---|---|---|
| HTTP 클라이언트·버전 확인 | 기존 `curl` | 기존 `curl-minimal` 또는 `curl` | 필수 |
| 제한된 서버·분석 | `python3`, 3.9 이상 | `python3`, 3.9 이상 | 필수 |
| 소켓·주소 관측 | `iproute2` | `iproute` | 필수 |
| 캡처·오프라인 해석 | `tcpdump` | `tcpdump` | 실측 패킷 증거에 필요 |
| 실행 시간 제한·해시 | `coreutils` | `coreutils` | 필수 |
| 이후 선택적 경로 프로브 | `traceroute`; 입문의 `tracepath`는 별개 도구 | `traceroute`; `tracepath`는 `iputils` 제공 | A는 오프라인이므로 불필요 |
| 선택적 DNS 조사 | `bind9-dnsutils` | `bind-utils` | 실제 DNS 질의 불필요 |

게스트의 이 저장소 체크아웃에서 확인합니다.

```bash
command -v python3 curl ip ss timeout sha256sum tcpdump
python3 --version
curl --version
ip -Version
ss -V
tcpdump --version
sha256sum examples/networking/foundations/http_lab.py
```

게스트 배포판, 커널, 저장소 리비전, 도우미 해시, 도구 버전과 curl 기능 목록을 기록합니다.
curl에 HTTP2/HTTP3 기능이 없는 것은 클라이언트 기능 제한이지 서버 장애가 아닙니다.
시작 전에 `ss -ltn 'sport = :18080'`를 확인하고 수신 대기 항목이 있으면 중단하여 다른 빈 포트를 모든 명령에서 일관되게 사용합니다.
관련 없는 수신 대기 프로세스를 종료하지 마세요.

시도마다 `mkdir -m 700 protocol-evidence-01`로 증거 디렉터리를 만듭니다. 이미 있으면 새 이름을 선택하세요.
예시는 저장소 루트에서 이 이름을 사용합니다.
캡처에는 실습용 합성 데이터만 필요하며 자격 증명, 쿠키, 실제 사용자 트래픽은 필요하지 않습니다.
각 자료에 `measured`, `imported`, `synthetic`, `design-only` 중 하나와 시각, 관측자, 네임스페이스, 필터를 표시하세요.
제공된 텍스트 기록은 자신의 게스트에서 측정한 결과가 아닙니다.

## 모든 프로젝트에 적용할 개념 {#concepts}

| 경계 | 불변 조건 또는 구분 | 충분하지 않은 증거 |
|---|---|---|
| IP → 전송 계층 | Protocol/Next Header가 다음 해석기를 선택 | 443번 포트만으로 HTTPS·QUIC 확정 불가 |
| 프로브 → ICMP 오류 | 오류는 원인이 된 패킷을 인용 | 바깥쪽 라우터 주소만으로 프로브 식별 불가 |
| TCP → 애플리케이션 | TCP는 순서 있는 바이트 스트림을 전달 | `send()`·`recv()` 경계는 HTTP 메시지 경계가 아님 |
| 수신자 → 송신자 | 광고 수신 윈도가 수신자 부담을 제한 | 수신 버퍼 할당량은 혼잡 윈도가 아님 |
| 네트워크 → 송신자 | 혼잡 제어가 경로에 가하는 부하를 제한 | 재전송 하나로 혼잡 위치를 특정할 수 없음 |
| 애플리케이션 → 사용자 | HTTP 상태·본문이 작업 결과를 설명 | TCP 연결만으로 요청 작업 성공을 증명할 수 없음 |

스트림 의미와 시퀀스 공간은 [TCP RFC 9293](https://www.rfc-editor.org/rfc/rfc9293.html)을 기준으로 설명합니다.
윈도 기반 설명에서 실제로 전송 중일 수 있는 양은 `cwnd`와 수신 윈도 모두에 제한되며, 이미 전송 중인 바이트도 고려합니다.
페이싱, 애플리케이션이 제공한 데이터, 구현 세부사항 역시 송신을 제한합니다.
순수 ACK는 시퀀스 공간을 소비하지 않고 SYN과 FIN은 각각 한 위치를 소비합니다.

## 프로젝트 A: 프로브 대응 원장 {#probe-project}

**목적:** 무관한 응답을 홉으로 만들지 않으면서 불완전한 경로 관측을 설명합니다.
**환경:** 종이나 로컬 편집기만 사용합니다. 패킷을 보내거나 라우터를 만들지 않습니다.
CS168 traceroute 안내 다음에 [ICMP RFC 792](https://www.rfc-editor.org/rfc/rfc792.html)를 읽으세요.
[라우팅·ICMP 문서](https://www.atomai.click/kubernetes-docs/llms/ko/networking/07-linux-network-diagnostics.md#routing-icmp-lab)의 ICMP Echo 프로브는 CS168의 UDP 방식과 다름을 확인합니다.

다음 독립적인 **합성 송신 원장**을 만드세요. 주소는 문서용이며 실제 프로브 대상이 아닙니다.

```text
run,probe,ttl,src,dst,protocol,sport,dport
paper-01,A,1,192.0.2.10,198.51.100.20,UDP,41000,33451
paper-01,B,2,192.0.2.10,198.51.100.20,UDP,41000,33452
paper-01,C,3,192.0.2.10,198.51.100.20,UDP,41000,33453
```

아래는 해석된 기록으로 취급합니다. **pcap도 실측 시간 기록도 아닙니다.**

| 수신 순서의 기록 | 바깥쪽 응답 | 인용된 원래 패킷 | 대응 결과 |
|---|---|---|---|
| R1 | `192.0.2.1`, ICMP 11/0 | A의 완전한 IPv4 + UDP 헤더 | 직접 작성 |
| R2 | `192.0.2.1`, ICMP 11/0 | R1과 같은 인용 | 직접 작성 |
| R3 | `203.0.113.7`, ICMP 11/0 | B의 튜플이지만 목적지가 `198.51.100.99` | 직접 작성 |
| R4 | `198.51.100.20`, ICMP 3/3 | C의 완전한 IPv4 + UDP 헤더 | 직접 작성 |
| R5 | `203.0.113.8`, ICMP 11/0 | 인용된 IPv4 헤더가 UDP 포트 이전에 끝남 | 직접 작성 |

`record`, `candidate_probe`, `decision`, `reason`, `confidence`, `missing_fields`를 담은 원장을 작성합니다.
대응 성공, 중복, 무관함, 증거 부족을 서로 다른 판정으로 구분하세요.
그림을 이어 붙이려고 B의 응답을 만들어 내지 않습니다.

다음 세 사례도 직접 추가합니다.

1. 같은 포트를 재사용한 이전 실행의 늦은 응답
2. 옵션이 포함되어 길이가 20바이트를 넘는 정상 인용 IPv4 헤더
3. 명시한 관측 마감 시각 이후 도착한 응답

각 사례를 구별할 식별자와 송수신 시간 범위, 인용 데이터만으로 구별할 수 없는 조건을 명시합니다.
ICMP 인용은 애플리케이션 nonce를 포함하기에 짧을 수 있으므로 없는 바이트에 의존하지 않습니다.
ICMP Echo 프로브는 UDP 포트를 만들어 쓰는 대신 인용된 identifier/sequence에 대응합니다.

**예상 관측:** A는 TTL-1 응답 하나를 뒷받침합니다. C와 대응한 Port Unreachable은 해당 UDP 프로브의 목적지 도착을 뒷받침합니다.
**부정 관측:** R2는 새 프로브 결과가 아니고, R3는 B를 충족하지 않으며, R5는 튜플을 유일하게 식별할 수 없습니다.
B와 대응하는 응답이 없으면 뒤의 홉이 응답했더라도 수집 시간 안에서는 미확인입니다.
이는 B 위치의 라우터가 통과하는 애플리케이션 트래픽을 버린다는 증거가 아닙니다.

traceroute RTT에는 응답 경로와 라우터의 응답 처리 동작도 포함됩니다.
프로브 포트를 바꾸면 ECMP 선택이 바뀔 수 있으며, 응답 주소 목록이 하나의 안정된 애플리케이션 경로를 증명하지는 않습니다.
**복구:** 원본 기록을 유지하고 다시 시작할 때는 파생한 임시 원장만 버립니다.
**완료:** 모든 판정에 인용 필드 또는 부족한 특정 필드가 연결되고 추가 세 사례에 거절·불확실성 규칙이 있습니다.

## 프로젝트 B: TCP 스트림 위의 HTTP 경계 {#stream-project}

**목적:** 애플리케이션 길이, TCP 바이트, 관측 세그먼트가 서로 다른 질문에 답함을 보입니다.
**환경:** 소유한 게스트 한 대의 `127.0.0.1:18080`에서 클라이언트와 서버를 실행하며 외부 대상·프록시는 사용하지 않습니다.
캡처만 sudo가 필요하고 서버·클라이언트는 일반 사용자로 실행합니다.
아래 요청을 한 번에 하나씩 수행하며 요청은 최대 10개, 요청 본문은 각각 4096바이트 이하로 제한합니다.

터미널 A의 저장소 루트에서 기존 도우미를 시작합니다.

```bash
python3 examples/networking/foundations/http_lab.py --port 18080 --duration 180
```

수신 대기 상태가 나타나면 터미널 B의 저장소 루트에서 캡처를 시작합니다.

```bash
sudo timeout --signal=INT --kill-after=2s 20s \
  tcpdump -i lo -p -nn -U -s 512 -c 120 -w - \
  'tcp port 18080' > protocol-evidence-01/http.pcap \
  2> protocol-evidence-01/capture.log
```

로그의 “listening on” 줄을 확인한 뒤 터미널 C에서 요청을 보냅니다.
출력 파일은 셸이 자신의 사용자 권한으로 만들고 tcpdump는 pcap 바이트를 표준 출력에 씁니다.
120개 패킷 또는 20초에 종료하며 timeout의 종료 코드 124는 타이머 결과이지 네트워크 장애 증거가 아닙니다.
종료 상태와 최종 캡처 카운터를 보존합니다. 스냅 길이 512바이트로 본문이 잘릴 수 있다는 한계도 기록하세요.

```bash
curl --disable --noproxy '*' --max-time 3 --http1.1 -i \
  http://127.0.0.1:18080/lesson
curl --disable --noproxy '*' --max-time 3 --http1.1 -I \
  http://127.0.0.1:18080/lesson
printf 'phase=one\nphase=two\n' | \
  curl --disable --noproxy '*' --max-time 3 --http1.1 -i \
  --data-binary @- http://127.0.0.1:18080/echo
curl --disable --noproxy '*' --max-time 3 --http1.1 -i \
  http://127.0.0.1:18080/missing
```

echo 입력은 두 LF를 포함한 **20바이트**입니다.
각 응답을 별도로 기록하고 상태, Content-Length, 실제 콘텐츠를 찾으세요.
GET `/lesson`의 콘텐츠는 6바이트이며 HEAD는 같은 표현을 설명하지만 본문을 반환하지 않습니다.
없는 경로는 HTTP 404를 반환해야 합니다. `--fail`이 없으면 curl은 이 HTTP 오류에도 성공 종료할 수 있습니다.
HTTP 통신은 성공했지만 리소스 조회 결과는 실패한 것입니다.

완료된 캡처는 권한 상승 없이 해석합니다.

```bash
tcpdump -nn -tttt -vv -r protocol-evidence-01/http.pcap \
  'tcp port 18080'
sha256sum protocol-evidence-01/http.pcap
```

[tcpdump 매뉴얼](https://www.tcpdump.org/manpages/tcpdump.1.html)을 사용해 플래그, 시퀀스 범위와 캡처 드롭을 설명하세요.
양쪽 주소·포트 쌍으로 연결 하나를 골라 SYN, SYN-ACK, ACK, 데이터 범위와 수집된 종료 동작을 식별합니다.
특정 패킷 수나 요청당 세그먼트 하나를 요구하지 않고 누락된 연결 수립·종료는 수집 한계로 표시합니다.
HTTP 바이트 규칙은 [RFC 9112](https://www.rfc-editor.org/rfc/rfc9112.html)와 [curl 매뉴얼](https://curl.se/docs/manpage.html)을 참고합니다.

**독립 프레이밍 연습, 오프라인:** 부호 없는 2바이트 big-endian 길이 뒤에 해당 길이의 데이터가 오는 해석기를 설계하고 길이를 64바이트로 제한합니다.
합성 입력은 `00 03 63 61 74 00 02 6f 6b`이며 HTTP가 아닌 자신의 프로토콜입니다.
전체가 한 번에 도착, 한 바이트씩 도착, 길이 첫 바이트 뒤에서 분할, 첫 본문 중간에서 분할하는 경우를 추적합니다.
각 전달 후 버퍼 바이트, 필요한 바이트, 출력한 레코드를 적으세요.
본문 중간 EOF와 길이 65를 추가하고 무한 대기·무제한 할당 대신 제한된 실패 동작을 정의합니다.
자신의 오프라인 해석기를 구현해도 되지만 완전한 상태표와 사례만으로도 이 연습을 충족할 수 있습니다.

**독립 윈도 연습, 오프라인:** MSS 1000바이트, `cwnd` 4세그먼트, 수신 윈도 9000바이트, 이미 전송 중인 데이터 3000바이트를 가정합니다.
페이싱을 제외하고 애플리케이션 데이터가 준비되어 있다고 가정하여 `max(0, min(cwnd × MSS, rwnd) − outstanding)`으로 추가 허용량을 계산하세요.
`rwnd`만 3500바이트로 바꾼 경우와 0인 경우를 반복하고 각각 제한하는 측을 식별합니다.
수신 윈도 0이 네트워크 혼잡을 증명하지 않고 재전송 하나가 수신자 자원 소진을 증명하지 않는 이유를 설명하세요.
이는 합성 상태 스냅샷이며 완전한 TCP 송신자 시뮬레이션이나 실측 성능이 아닙니다.

**예상 관측:** 완전한 모든 분할에서 동일한 논리 레코드 두 개가 나오고 HTTP echo는 입력 20바이트를 보존합니다.
**부정 관측:** 불완전한 레코드를 완료 처리하거나 상한을 초과한 프레임을 받아들이면 안 됩니다.
명시한 단순 모델에서 윈도 스냅샷의 추가 허용량은 각각 1000, 500, 0바이트이며 음수는 0으로 제한합니다.
송신 체크섬 오류 표시는 오프로딩 관측의 영향일 수 있으며 캡처 드롭이 곧 경로 손실은 아닙니다.
**복구:** 자신의 포그라운드 도우미만 Ctrl+C로 종료하거나 180초 타이머 만료를 기다립니다. 캡처에는 별도 상한이 있습니다.
수신 대기 필터를 다시 확인합니다. 증거를 보존하고 버리기로 했다면 정확히 지정한 자기 파일·디렉터리만 제거합니다.

## 프로젝트 C: 포트 번호가 아닌 경계 증명 {#boundary-project}

**목적:** 이름, 전송, 보안, 애플리케이션 실패를 구분하는 최소 증거를 설계합니다.
**환경:** 기존의 소유한 추적 자료가 있으면 활용하는 오프라인 보고서입니다. 공개 사이트를 탐사할 필요가 없습니다.

| 사례 | 요청할 증거 | 거절할 잘못된 결론 |
|---|---|---|
| DNS A 레코드 응답 후 TCP 연결 실패 | 해석 결과, 선택 주소, 연결 오류, 종단 캡처 | “DNS 성공이면 서비스도 정상” |
| AAAA는 있으나 게스트에 사용 가능한 IPv6 경로 없음 | 주소 계열별 주소·경로와 클라이언트 선택 | “IPv6 DNS 응답이면 IPv6 연결 가능” |
| TCP 연결 후 TLS 인증서 검증 실패 | 의도한 호스트명, 신뢰·검증 오류, TLS 종단 신원 | “인증서 검증을 끄면 복구 증명” |
| HTTPS가 HTTP/1.1을 협상 | 클라이언트 기능과 협상된 HTTP 버전 | “443 또는 `--http2`이면 HTTP/2” |
| HTTP/2 여러 스트림이 TCP 사용 | 스트림 ID와 연결·전송 손실 증거 | “다중화하면 TCP 선두 지연도 사라짐” |
| HTTP/3로 추정되는 통신 | 종단의 QUIC·버전·애플리케이션 협상 증거 | “UDP/443이면 전부 HTTP/3” |

[HTTP/2 RFC 9113](https://www.rfc-editor.org/rfc/rfc9113.html), [QUIC RFC 9000](https://www.rfc-editor.org/rfc/rfc9000.html), [HTTP/3 RFC 9114](https://www.rfc-editor.org/rfc/rfc9114.html)를 읽으세요.
HTTP/2는 TCP 위에서 애플리케이션 스트림을 다중화하므로 누락된 TCP 바이트가 여러 스트림의 전달을 지연할 수 있습니다.
QUIC은 UDP 위에 스트림, 신뢰성, 혼잡 제어를 제공하고 TLS를 통합하며 HTTP/3는 HTTP를 QUIC에 대응시킵니다.
한 QUIC 스트림의 손실이 다른 스트림의 전달을 막을 필요는 없지만 공유 혼잡 제한과 애플리케이션 의존성은 남습니다.
수동 암호화 패킷 캡처로 HTTP 내용을 일반적으로 읽을 수는 없으며 종단 평문 로그는 다른 관측 지점입니다.

각 사례에 경계 그림, 긍정 검증 한 가지, 부정 검증 한 가지와 다음 관측을 적습니다.
curl의 `--resolve`가 TLS용 URL 호스트명을 유지하면서 주소 조회를 분리할 수 있지만 DNS를 시험하지는 않는 이유를 설명하세요.
`--http3`의 폴백과 `--http3-only`를 구분하고 설계 전에 로컬 지원 여부를 확인합니다.
프로젝트 B의 IPv4 전용 도우미는 클라이언트 플래그를 바꾼다고 IPv6·TLS·HTTP2 서버가 되지 않습니다.

[IPv6 RFC 8200](https://www.rfc-editor.org/rfc/rfc8200.html)과 [ICMPv6 RFC 4443](https://www.rfc-editor.org/rfc/rfc4443.html)으로 프로젝트 A를 문서상 확장하세요.
TTL은 Hop Limit, IPv4 헤더 길이 해석은 IPv6·확장 헤더 해석, IPv4 ICMP 유형은 ICMPv6 유형으로 바뀝니다.
IPv6 라우터는 전달 패킷을 단편화하지 않으며 Packet Too Big 증거의 역할은 Time Exceeded와 다릅니다.
원장에 주소 계열과 범위를 포함합니다. IPv6 이웃 탐색은 ARP가 아닙니다.

**예상 관측:** 인증된 애플리케이션 응답과 도달성·기능 지원을 구분한 보고서가 나옵니다.
**부정 관측:** 도구 미지원과 추적 자료 부재는 이용 불가로 표시하며 원격 프로토콜의 실측 실패로 바꾸지 않습니다.
**복구:** 실행 상태 변경은 없습니다. 가져온 원본 증거와 출처를 유지합니다.

## 완료와 포트폴리오 전달 {#completion}

- [ ] 읽기 URL·학기, 접근 날짜, 게스트·도구 버전, 도우미 리비전·해시를 기록했다.
- [ ] 프로젝트 A의 5개 기록과 추가 3개 사례를 없는 홉을 만들지 않고 설명했다.
- [ ] HTTP 실측 증거에 상태·콘텐츠 길이·TCP 연결 하나·캡처 한계를 보존했다.
- [ ] 프레이밍 불변성과 잘못된 길이·불완전 입력의 부정 사례를 보였다.
- [ ] 수신 흐름 제어와 혼잡 제어를 구분하고 이 작은 부하로 둘을 벤치마크할 수 없는 이유를 설명했다.
- [ ] 경계 사례 6개와 IPv6 확장을 완료했다.
- [ ] 수신 대기·캡처 종료를 확인하고 미완료 관측을 식별했다.
- [ ] [퀴즈](https://www.atomai.click/kubernetes-docs/ko/quizzes/networking/expert/01-protocol-projects-quiz)의 오답이 틀린 이유까지 설명했다.

캡처 권한이 없다면 오프라인 작업을 완료하고 패킷 수집은 미완료로 표시하세요.
가져온 캡처로 분석할 수 있지만 새로 재현한 실험으로 제시할 수는 없습니다.
포트폴리오는 관측과 실패 추론의 증거이며 자격증이나 모든 프로토콜 전문성의 증명이 아닙니다.

[전문가 과정 지도](https://www.atomai.click/kubernetes-docs/llms/ko/networking/expert/README.md)로 돌아가 [라우팅](https://www.atomai.click/kubernetes-docs/llms/ko/networking/expert/02-routing-policy-convergence.md)으로 진행하거나 [Linux 성능](https://www.atomai.click/kubernetes-docs/llms/ko/networking/expert/04-linux-performance.md)에서 호스트 증거를 보강하세요.
증거 규약은 [자동화 종합 실습](https://www.atomai.click/kubernetes-docs/llms/ko/networking/expert/06-automation-capstone.md)으로 전달합니다.