L7 네트워크 심화 입구

L7 네트워크 심화 입구

분류: Layer 7 - 네트워크 심화

핵심 질문

요청이 느리거나 실패할 때, 어느 계층의 어떤 약속이 깨졌으며 다음 증거는 어디에서 얻어야 하는가?

3줄 요약

• L2가 요청 경로의 기본 지도를 만들었다면, L7은 그 경로가 용량을 탐색하고 신뢰를 세우며 여러 요청을 운반하고 전 세계에 응답을 재사용하는 방식을 다룬다.
• 첫 회독은 TCP 혼잡 제어 → TLS → HTTP/2·3 → DNS/CDN → 네트워크 디버깅 순서로 읽는다.
• 커널 튜닝, 프레임 필드, 패킷 캡처와 운영 명령은 나중에 돌아올 선택 심화다. 처음에는 각 기술이 해결하는 문제와 남기는 경계를 설명하면 충분하다.

1. 정의 — 네트워크 심화에서 무엇이 달라지는가

네트워크 심화는 프로토콜 이름을 더 많이 외우는 단계가 아니다. 이미 연결 가능한 두 끝점 사이에서 얼마나 보낼지, 누구를 믿을지, 여러 요청을 어떻게 겹쳐 보낼지, 응답을 어디에 둘지, 실패 지점을 어떤 증거로 좁힐지 판단하는 단계다.

L2에서는 도메인 이름이 주소로 바뀌고, TCP 또는 UDP가 데이터를 옮기며, Web Server와 프록시가 HTTP 요청을 애플리케이션으로 전달한다는 큰 경로를 배웠다. L7에서는 같은 경로를 다음 다섯 축으로 다시 읽는다.

축	중심 질문	이어지는 문서
용량	수신자와 중간 경로가 감당할 수 있는 전송량을 어떤 신호로 추정하는가	TCP 흐름/혼잡 제어
신뢰	상대가 기대한 서버인지 어떻게 확인하고, 어디서 암호를 푸는가	TLS & HTTPS
병렬성	여러 요청이 한 연결을 공유할 때 어느 위치에서 서로를 막는가	HTTP/2 & HTTP/3
배치·재사용	사용자를 어느 서버로 보내고, 어떤 응답을 가까운 곳에서 다시 쓰는가	DNS 심화 & CDN
증거	겉 증상을 어느 관측 지점의 반증 가능한 가설로 바꾸는가	네트워크 디버깅

첫 회독의 목표는 이 다섯 축을 하나의 요청 경로 위에 놓는 것이다. 알고리즘의 모든 상태, 인증서의 모든 필드, 프레임의 비트 구조를 설명하는 것은 아직 목표가 아니다.

2. 선행 단계의 한계 — 경로를 아는 것만으로는 부족하다

L2의 OSI 모델은 DNS, TCP, TLS, HTTP, 프록시, 애플리케이션을 서로 다른 책임 경계로 나누는 지도를 제공했다. TCP/UDP에서는 연결·순서·재전송의 보장 차이를, DNS에서는 위임된 이름 공간과 TTL 캐시를 배웠다. 이 지식으로 요청이 어디를 지나는지는 설명할 수 있다.

하지만 실제 서비스에서는 경로가 존재한다는 사실만으로 다음 질문에 답하기 어렵다.

• TCP 연결은 성공했는데 장거리 전송 처리량이 왜 링크 속도보다 훨씬 낮은가?
• HTTPS 연결은 암호화되는데 왜 인증서와 호스트명, TLS 종료 위치를 따로 확인해야 하는가?
• HTTP/2로 협상했는데 왜 패킷 하나의 손실이 여러 요청을 함께 멈출 수 있는가?
• DNS 변경이 끝났는데 왜 일부 사용자는 이전 서버로 가고, CDN을 붙였는데도 원본 서버(origin) 부하는 늘어나는가?
• 브라우저에는 같은 Failed to fetch가 보이는데 왜 원인은 DNS, TCP, TLS, 로드밸런서, 앱 중 어디에나 있을 수 있는가?

L2의 지도는 출발점이지만, 용량 추정·신뢰·병렬성·분산 캐시·관측의 동작 원리까지 대신하지는 않는다. L7은 이 빈 부분을 채운다.

3. 등장한 문제 — 한 요청은 여러 독립 약속 위에 있다

사용자가 HTTPS 요청 하나를 보낼 때 시스템은 하나의 거대한 “네트워크 연결”로 움직이지 않는다. 이름 해석, 전송, 보안 채널, HTTP 스트림, 사용자 가까운 CDN 거점인 edge와 origin, 애플리케이션 처리는 서로 다른 약속을 이어 붙인다.

이름을 주소로 해석한다
  → 경로 용량을 추정하며 데이터를 보낸다
  → 서버 신원과 전송 데이터의 무결성을 확인한다
  → 여러 HTTP 요청을 스트림으로 운반한다
  → edge 캐시 또는 origin에서 응답을 만든다
  → 각 경계의 관측값으로 성공과 실패를 판단한다

각 단계는 앞 단계가 성공해도 독립적으로 실패할 수 있다. DNS가 올바른 IP를 줘도 TCP 경로가 혼잡할 수 있고, TCP가 열려도 TLS 인증서 검증은 실패할 수 있다. TLS와 HTTP/2 협상이 끝나도 애플리케이션이 요청을 순차적으로 만들 수 있으며, CDN edge가 가까워도 요청을 같은 캐시 엔트리로 볼지 정하는 기준인 cache key가 지나치게 잘게 나뉘면 모든 요청이 origin까지 간다.

따라서 “네트워크가 느리다”는 문장은 아직 진단이 아니다. L7이 해결하려는 문제는 큰 증상을 어떤 약속이 깨졌는지 확인할 수 있는 작은 질문으로 바꾸는 것이다.

4. 핵심 철학 — 제어하고, 경계를 지키고, 증거로 좁힌다

L7 전체를 관통하는 철학은 세 문장으로 잡을 수 있다.

1. 네트워크는 피드백을 보고 적응한다. TCP는 ACK, 손실, RTT 같은 신호로 전송량을 조절한다. health-aware DNS 라우팅은 상태 변화에 따라 앞으로의 authoritative 응답을 바꿀 수 있다. 클라이언트와 resolver는 기존 캐시의 TTL이 만료되고 새로 조회한 뒤에야 바뀐 응답을 관찰하며, 이미 열린 연결은 DNS가 이동시키지 않는다. CDN 캐시는 hit/miss와 freshness 정책으로 새 요청을 edge에서 처리할지 origin으로 보낼지 결정한다.
2. 최적화는 문제를 없애기보다 위치와 대가를 바꾼다. HOL Blocking은 앞선 작업이 막혀 뒤 작업도 기다리는 현상이다. HTTP/2는 애플리케이션 수준의 HOL Blocking을 줄이지만 TCP 수준의 HOL은 남긴다. HTTP/3는 QUIC 스트림으로 손실의 파급 범위를 줄이지만 UDP 차단과 fallback 경계가 생긴다. CDN은 거리를 줄이지만 freshness와 cache key 책임을 추가한다.
3. 진단은 도구 목록이 아니라 반증 루프다. 어느 관측 지점에서 무엇을 봤고, 그 증거로 어떤 가설을 버렸는지를 말할 수 있어야 한다.

이 철학을 유지하면 “BBR이 최신이다”, “HTTP/3가 더 빠르다”, “CDN을 붙이면 origin이 보호된다” 같은 단정에서 벗어난다. 먼저 현재 병목과 신뢰 경계, fallback, 관측 가능성을 확인한 뒤 기술의 이득을 판단한다.

5. 레이어 사고 모델 — 다섯 질문으로 위치를 잃지 않기

L7 문서를 읽는 동안 다음 질문을 반복한다.

5-1. 제한하는 주체는 누구인가

전송이 느릴 때 수신자의 처리 속도, 중간 경로의 혼잡, 송신 애플리케이션의 데이터 공급을 분리한다. TCP의 rwnd와 cwnd는 이 차이를 보여주는 대표 신호다. 첫 회독에서는 두 값의 세부 계산보다 수신자 보호와 경로 보호가 다른 문제라는 점을 잡는다.

5-2. 신뢰와 암호화는 어디에서 시작하고 끝나는가

TLS는 기밀성만 제공하지 않는다. 무결성과 서버 인증도 함께 제공한다. 동시에 TLS termination이 ALB나 CDN edge에 있으면 그 뒤 구간은 별도 신뢰 경계가 된다. “HTTPS를 쓴다”는 한 문장보다 누가 누구를 인증하고 어느 구간이 보호되는가를 묻는다.

5-3. 막힘은 어느 층의 줄 앞에서 생기는가

HTTP/1.1의 요청 순서, HTTP/2의 단일 TCP 바이트 스트림, HTTP/3의 QUIC 스트림은 서로 다른 위치의 HOL Blocking을 다룬다. 버전 번호보다 무엇이 함께 멈추고 무엇은 독립적으로 진행되는가를 본다.

5-4. 같은 응답으로 다시 써도 되는가

DNS는 새 조회에 어떤 endpoint를 답할지 결정하고, CDN은 사용자 가까운 edge에서 HTTP 응답을 재사용한다. 둘 다 캐시를 쓰지만 대상과 안전 조건이 다르다. DNS에서는 authoritative 응답, resolver 캐시의 TTL, 새 조회 시점을 구분하고, CDN에서는 cache key·freshness·stale 허용 범위를 묻는다. DNS 응답이 바뀌어도 이미 열린 TCP·QUIC 연결이 새 endpoint로 옮겨지는 것은 아니다.

5-5. 지금 가진 증거는 어느 경계의 시야인가

브라우저, curl, resolver, 로컬 소켓, 로드밸런서 로그, 패킷 캡처는 서로 다른 위치를 본다. 한 지점의 성공을 전체 경로의 성공으로 확대하지 않는다. 예를 들어 네트워크 정책의 ACCEPT는 애플리케이션 처리 성공을 뜻하지 않고, HTTP 200은 브라우저의 CORS 허용을 뜻하지 않는다.

6. 실제 읽기 순서

6-1. 본문별 hard prerequisite

아래 항목은 막혔을 때 고르는 참고 문서가 아니라 각 본문 frontmatter가 선언한 진입 전 필수 선수지식이다. 이 도입부의 frontmatter는 지도를 이해하는 데 필요한 최소 선수만 담으며, 각 본문의 hard prerequisite를 전부 복제하지 않는다.

• TCP 흐름/혼잡 제어 심화: content/topics/L2/tcp-udp-internals.mdx
• TLS & HTTPS: content/topics/L1/web-security-basics.mdx, content/topics/L2/tcp-udp-internals.mdx
• HTTP/2 & HTTP/3: content/topics/L1/http-basics.mdx, content/topics/L2/tcp-udp-internals.mdx, 앞서 읽는 content/topics/L7/tcp-flow-congestion.mdx, content/topics/L7/tls-https.mdx
• DNS 심화 & CDN: content/topics/L2/dns-basics.mdx, content/topics/L2/http-cache.mdx, 앞서 읽는 content/topics/L7/http2-http3.mdx, content/topics/L7/tls-https.mdx. 또한 HTTP 헤더와 Cache-Control의 기본 구조, 공개키·해시·디지털 서명이 무엇을 보장하는지에 대한 기초 감각이 필요하다.
• 네트워크 디버깅: content/topics/L1/http-basics.mdx, content/topics/L2/dns-basics.mdx, content/topics/L2/osi-web-server.mdx, content/topics/L2/tcp-udp-internals.mdx, content/topics/L3/vpc-subnet-sg.mdx, content/topics/L5/docker-basics.mdx, content/topics/L5/kubernetes-basics.mdx, 앞선 content/topics/L7/tcp-flow-congestion.mdx, content/topics/L7/http2-http3.mdx, content/topics/L7/tls-https.mdx, content/topics/L7/dns-cdn.mdx가 모두 필수다.

hard prerequisite가 막히면 해당 문서의 핵심 모델을 먼저 보정한 뒤 L7 본문에 진입한다. 이미 충족한 선수는 다시 완독하지 않고, 정의와 핵심 요약을 확인하는 정도로 넘어가도 된다.

HTTP/2·3에서 WebSocket·gRPC 통신 방식 비교가 필요하면 content/topics/L1/websocket-grpc-basics.mdx를, domain sharding의 이름 조회 비용이 막히면 content/topics/L2/dns-basics.mdx를 선택 참고한다. 두 문서는 HTTP/2·3 첫 회독의 hard prerequisite가 아니다.

L7 첫 회독 순서

1. 1. TCP 흐름/혼잡 제어 심화

   L2의 TCP 연결과 기본 흐름 제어 위에서 rwnd와 cwnd, RTT와 손실을 경로의 피드백 신호로 읽는다. 이후 문서의 지연과 연결 재사용을 이해하는 기준점이다.

2. 2. TLS & HTTPS

   L1 Web Security와 L2 TCP를 먼저 확인한 뒤, TCP 연결 위에 기밀성·무결성·인증을 어떻게 붙이는지 보고 인증서 체인과 TLS 종료 위치로 신뢰 경계를 나눈다.

3. 3. HTTP/2 & HTTP/3

   L1 HTTP, L2 TCP, 앞선 TCP·TLS를 확인한 뒤 HTTP/2 멀티플렉싱과 HTTP/3 QUIC이 서로 다른 HOL Blocking을 다루는 방식을 비교한다. WebSocket/gRPC와 DNS는 비교 지점에서만 선택 참고한다.

4. 4. DNS 심화 & CDN

   L2 DNS·HTTP Cache, 기초 암호학 감각, 앞선 TLS·HTTP/2·3을 확인한 뒤 이름의 신뢰, 트래픽 안내, edge 캐시, origin 보호를 하나의 전달 경로로 본다.

5. 5. 네트워크 디버깅

   L1 HTTP, L2 네트워크 기초, L3 VPC, L5 Docker·Kubernetes와 앞선 L7 문서를 확인한 뒤 사용자 증상을 관측 지점·가설·반증의 루프로 좁힌다.

이 순서는 단순한 난이도 정렬이 아니다. TCP가 전송량과 손실의 언어를 제공하고, TLS가 연결에 신뢰를 더하며, HTTP/2·3이 그 연결 위의 병렬성을 바꾼다. DNS/CDN은 이 메커니즘을 전 세계 endpoint와 캐시 배치로 확장하고, 디버깅은 모든 경계를 거꾸로 추적한다.

7. 첫 회독과 선택 심화의 경계

첫 회독에서 답할 질문

문서	첫 회독 질문
TCP	느린 전송을 수신자 제한, 경로 혼잡, 연결 반복 중 어디에 가까운지 어떤 신호로 나눌 것인가?
TLS	기밀성·무결성·인증은 각각 무엇을 보장하며, TLS는 어느 지점에서 종료되는가?
HTTP/2·3	HTTP/2가 줄인 HOL과 HTTP/3가 줄이려는 HOL은 어디에서 생기며, HTTP/3 실패 시 fallback은 있는가?
DNS/CDN	응답 진위와 질의 프라이버시는 어떻게 다르며, 어떤 응답을 어떤 cache key로 재사용해도 되는가?
디버깅	어느 관측 지점에서 얻은 증거가 어떤 가설을 반증했고, 다음에는 어느 경계를 볼 것인가?

이 질문에 자신의 말로 답할 수 있으면 첫 회독을 계속 진행한다. 약어 하나를 정확히 기억하지 못하거나 계산을 바로 하지 못해도 멈출 필요가 없다.

선택 심화로 미룰 것

선택 심화 영역	지금 미뤄도 되는 내용	돌아올 시점
커널과 혼잡 제어 세부	Reno·CUBIC·BBR 상태 전이, qdisc, 소켓 버퍼와 커널 파라미터 튜닝	실제 처리량·RTT·재전송 기준선으로 병목을 확인했을 때
와이어·프레임 필드	TCP flags 바이트, HTTP/2 frame 필드, HPACK/QPACK 테이블, QUIC packet 내부	패킷이나 프레임 수준 증거가 필요한 구현·장애를 만났을 때
신뢰 체인의 운영 세부	인증서·DNSSEC 키 롤오버, OCSP/CT, 0-RTT replay 정책의 세부 운영	인증서 수명주기나 DNSSEC 검증 실패를 직접 운영할 때
공급자 설정과 edge 코드	Route 53 정책별 설정, CDN behavior, 무효화 API, edge function 배포	실제 트래픽 배치와 cache policy를 설계할 때
운영 명령과 패킷 캡처	curl, dig, openssl, ss, tcpdump, Wireshark, VPC·Kubernetes 관찰 명령의 세부 옵션	반증할 가설과 관측 위치를 먼저 적을 수 있을 때

선택 심화는 중요하지 않아서 미루는 것이 아니다. 먼저 사고 모델을 세운 뒤 세부 도구를 붙여야 출력의 의미를 잘못 확대하지 않기 때문이다. 특히 커널 값을 바꾸거나 넓은 패킷 캡처를 시작하는 일은 첫 회독의 완료 조건이 아니다.

8. 선택 fallback — 막힐 때 돌아갈 곳

아래 문서는 본문 진입 전에 반드시 충족해야 하는 hard prerequisite 목록을 대신하지 않는다. 본문을 읽기 시작한 뒤 특정 개념에서 막혔을 때 필요한 지점만 보정하고 돌아오는 선택 fallback이다.

막히는 느낌	보통 부족한 전제	돌아갈 문서
DNS, TCP, TLS, HTTP, 프록시의 순서가 다시 섞인다	요청 경로를 나누는 OSI 진단 지도	content/topics/L2/osi-web-server.mdx
handshake, ACK, 재전송, 흐름 제어가 한꺼번에 어렵다	TCP 연결과 기본 Sliding Window	content/topics/L2/tcp-udp-internals.mdx
recursive·authoritative resolver, 위임, TTL 관계가 흐려진다	DNS가 위임 트리를 캐시하며 걷는 모델	content/topics/L2/dns-basics.mdx
freshness, validation, cache key, shared cache가 섞인다	HTTP 캐시의 저장·재검증·공유 경계	content/topics/L2/http-cache.mdx
상태 코드, 헤더, 연결 재사용의 HTTP 의미가 약하다	HTTP 요청·응답의 기본 계약	content/topics/L1/http-basics.mdx
TLS가 애플리케이션 보안 전체를 해결하는 것처럼 느껴진다	신뢰 경계와 다층 방어	content/topics/L1/web-security-basics.mdx의 1~2.5절
Security Group, NACL, route, Flow Logs의 위치가 헷갈린다	AWS 가상 네트워크의 경로와 정책	content/topics/L3/vpc-subnet-sg.mdx
Pod 내부와 호스트의 소켓·DNS·인터페이스가 왜 다른지 모르겠다	컨테이너 격리와 Kubernetes Service 경계	content/topics/L5/docker-basics.mdx → content/topics/L5/kubernetes-basics.mdx

돌아갈 때는 선수 문서를 처음부터 다시 끝내려 하지 않아도 된다. 지금 막힌 개념의 정의, 요청 경로에서의 위치, 그 문서의 핵심 요약을 확인한 뒤 L7의 질문으로 복귀한다.

9. 준비 상태

L7 readiness check

• 요청이 DNS 이름 해석, TCP 또는 UDP 전송, TLS, HTTP, 프록시와 애플리케이션 경계를 지난다는 큰 흐름을 말할 수 있다.
• TCP가 연결·순서·재전송을 제공하고 UDP는 그 책임을 상위 프로토콜에 더 많이 넘긴다는 차이를 설명할 수 있다.
• DNS가 위임된 이름 공간을 따라 답을 찾고 TTL 동안 캐시한다는 점을 안다.
• HTTP 상태 코드가 온 경우와 연결 또는 TLS 검증 자체가 실패한 경우를 같은 원인으로 단정하지 않는다.
• 첫 회독에서는 병목·신뢰·HOL·cache key·관측 지점의 질문을 우선하고, 커널·프레임 필드·운영 명령은 미뤄도 된다는 기준을 안다.
• 각 L7 본문에 들어가기 전에 그 문서의 hard prerequisite를 확인하고, 선택 fallback과 구분할 수 있다.
• 막히면 L2 OSI, TCP/UDP, DNS 문서 중 어느 곳으로 돌아갈지 고를 수 있다.

이 항목을 완벽히 설명할 필요는 없다. 요청 경로를 대략 그릴 수 있고, 모르는 지점을 어느 선수 문서에서 보정할지 알면 L7을 시작할 준비가 된 상태다.

10. Lineage 흐름 — 경로 지도에서 증거 기반 진단으로

L1 HTTP
  요청과 응답의 의미를 배운다
  →
L2 OSI · TCP/UDP · DNS · HTTP Cache
  요청 경로, 전송 책임, 이름 해석, 응답 재사용의 기본 경계를 배운다
  →
L7 TCP 혼잡 제어 · TLS · HTTP/2·3 · DNS/CDN
  용량 피드백, 신뢰, 스트림 병렬성, 전 세계 배치와 캐시의 trade-off를 배운다
  →
L7 네트워크 디버깅
  사용자 증상을 관측 지점, 가설, 반증으로 바꿔 실패 경계를 좁힌다

L7의 핵심은 더 낮은 수준으로 무조건 내려가는 것이 아니다. 기초 경로만으로 구분하기 어려웠던 병목·신뢰·전송 실패를 계층별 신호와 경계로 설명하고, 필요한 깊이까지만 내려가 증거로 판단하는 것이다.