L2 네트워킹 입구
L2 네트워킹 입구
섹션 제목: “L2 네트워킹 입구”분류: Layer 2 - 네트워킹
핵심 질문
섹션 제목: “핵심 질문”사용자의 요청이 서버 응답으로 돌아오기까지 어디를 지나며, 실패하거나 느려졌을 때 어느 경계부터 확인해야 하는가?
3줄 요약
섹션 제목: “3줄 요약”- L2의 목표는 프로토콜 이름을 외우는 것이 아니라 요청 경로를 이름 해석, 연결, 서버 앞단, 응답 재사용의 문제로 나누는 것이다.
- 첫 회독의 핵심 경로는
OSI 모델 & Web Server → TCP/UDP → DNS → HTTP Cache다. - 혼잡 제어와 경로 용량, 큰 패킷, HTTP/3 전송, AWS 서브넷 정책은 첫 회독의 입장 조건이 아니다. 핵심 경로를 설명할 수 있게 된 뒤 선택 심화로 돌아온다.
1. 이 레이어는 무엇을 가능하게 하나
섹션 제목: “1. 이 레이어는 무엇을 가능하게 하나”L2는 “API가 안 된다”거나 “사이트가 느리다”는 큰 증상을 더 작은 질문으로 바꾸는 레이어다. 도메인이 주소로 해석됐는지, 목적지 포트까지 연결됐는지, Web Server나 프록시가 요청을 애플리케이션에 전달했는지, 응답이 캐시에서 재사용됐는지를 구분하면 원인 후보가 줄어든다.
이 구분은 플랫폼 업무의 판단 순서를 바꾼다. 애플리케이션 로그가 없을 때 코드부터 고치지 않고 요청이 앱에 도착했는지 묻게 되고, 502와 timeout을 같은 실패로 묶지 않게 된다. DNS 변경이 일부 사용자에게만 늦게 보이거나, 캐시 hit가 성능을 높이면서도 오래된 응답과 데이터 누출을 만들 수 있다는 양면도 함께 보게 된다.
첫 회독의 완료 기준은 네트워크를 직접 튜닝하는 것이 아니다. 요청 하나의 경로를 그린 뒤, 각 증상을 어느 경계의 질문으로 바꿀지 설명하는 것이면 충분하다.
2. 이미 알고 있는 것에서 출발하기
섹션 제목: “2. 이미 알고 있는 것에서 출발하기”출발점은 L1에서 본 HTTP 요청과 응답이다. URL에는 연결할 이름이 있고, 요청은 메서드와 헤더를 싣고, 응답은 상태 코드와 헤더를 돌려준다. L2에서는 그 HTTP 메시지가 오가기 전후에 필요한 경로를 연다.
도메인 이름 해석 → 전송 연결 → 서버 앞단과 애플리케이션 → HTTP 응답 → 캐시 재사용이 화살표를 먼저 붙잡으면 새 용어가 한꺼번에 나와도 위치를 잃지 않는다. OSI는 이 경로를 나누는 진단 지도이고, TCP/UDP는 데이터를 옮길 때의 보장과 비용을 정한다. DNS는 연결할 주소를 찾으며, HTTP Cache는 이미 받은 응답을 언제 다시 써도 되는지 정한다.
2.5 선행 단계의 한계 — HTTP 표면에서 네트워크 경로로
섹션 제목: “2.5 선행 단계의 한계 — HTTP 표면에서 네트워크 경로로”L1의 HTTP는 요청과 응답이 어떤 의미를 갖는지 설명한다. 메서드, 상태 코드, 헤더를 읽으면 클라이언트와 서버가 어떤 약속을 주고받았는지는 알 수 있다. 하지만 응답 자체가 오지 않거나 일부 사용자에게만 느리게 도착하면 HTTP 메시지만으로는 원인을 충분히 좁힐 수 없다.
이 한계는 HTTP 아래와 주변의 경로를 열어야 해결된다. L2는 먼저 OSI 모델과 Web Server로 요청이 멈출 수 있는 경계를 나누고, TCP/UDP로 전송이 제공하는 보장과 실패 신호를 본다. 그 위에서 DNS는 연결할 주소를 찾는 과정과 변경 전파 시간을 설명하고, HTTP Cache는 이미 받은 응답을 재사용할 때의 시간과 공유 경계를 설명한다.
따라서 L2가 더하는 것은 프로토콜 목록이 아니라 HTTP 표면의 증상을 경로·책임·시간의 문제로 되짚는 방법이다. L1에서 읽은 요청과 응답이 출발점이고, WebSocket/gRPC나 Web Security의 세부 내용은 L2 입장 조건이 아니다.
3. 새로 배워야 하는 사고 모델
섹션 제목: “3. 새로 배워야 하는 사고 모델”L2에서는 세 가지 질문을 반복한다.
| 사고 모델 | 먼저 물을 질문 | 이 질문이 막는 오해 |
|---|---|---|
| 경로 | 요청은 지금 어느 단계까지 도달했는가? | 모든 실패를 애플리케이션 오류로 보는 것 |
| 책임 | 이름, 연결, 프록시, 응답 정책 중 누가 무엇을 보장하는가? | DNS, TCP, HTTP, 캐시의 역할을 섞는 것 |
| 시간 | handshake, RTT, timeout, TTL 가운데 무엇이 기다림을 만들었는가? | 느림을 서버 처리 시간 하나로만 설명하는 것 |
계층은 정답표가 아니라 가설을 줄이는 순서다. HTTP 상태 코드가 왔다면 적어도 어떤 L7 주체가 응답을 만들었다. 반대로 도메인 해석부터 실패했다면 애플리케이션 로직은 아직 후보가 아니다. 캐시된 응답이 보인다면 Origin의 현재 상태와 사용자가 받은 상태가 다를 수 있다.
이 레이어를 읽는 동안 세부 메커니즘보다 먼저 “어디까지 성공했는가”, “다음 책임자는 누구인가”, “어떤 시간 경계가 만료됐는가”를 묻는다.
4. 들어가기 전 최소 선수지식
섹션 제목: “4. 들어가기 전 최소 선수지식”- HTTP 요청과 응답이 무엇인지, URL·메서드·상태 코드·헤더가 서로 다른 역할을 한다는 정도면 충분하다. 헷갈리면
content/topics/L1/http-basics.mdx로 돌아간다. - 도메인 이름은 결국 통신 가능한 주소로 바뀌고, IP 주소와 포트가 목적지를 식별한다는 문장을 받아들일 수 있으면 된다. 구체적인 해석과 연결 과정은 L2에서 배운다.
- timeout은 “상대가 아무 일도 하지 않았다”는 증거가 아니라, 정해진 시간 안에 기대한 응답을 받지 못했다는 신호라고 이해하면 된다.
content/topics/L1/websocket-grpc-basics.mdx와 content/topics/L1/web-security-basics.mdx는 최소 선수 문서가 아니다. 지속 연결이나 TLS 보안 경계를 더 확인해야 할 때만 참고한다. 서브넷 계산, 패킷 캡처, 커널 파라미터, AWS 네트워크 설정 경험도 입장 조건이 아니다. 그런 세부사항이 핵심 흐름을 가리기 시작하면 선택 심화로 미루고 다음 문서로 이동한다.
5. 핵심 경로와 선택 심화
섹션 제목: “5. 핵심 경로와 선택 심화”L2 첫 회독 순서
- 1. OSI 모델 & Web Server
요청 경로를 DNS, 연결, TLS, HTTP, 프록시, 앱 경계로 나누는 지도를 먼저 얻는다.
- 2. TCP/UDP Internals
그 경로에서 연결, 순서, 재전송을 누가 책임지는지 보고 신뢰성과 지연의 선택 기준을 잡는다.
- 3. DNS Basics
TCP/UDP를 직접 선수로 삼아 이름이 주소로 해석되고 위임과 TTL 캐시가 전파 시간을 만드는 과정을 본다.
- 4. HTTP Cache
HTTP Basics와 OSI/Web Server에서 바로 갈라지는 분기다. 브라우저와 CDN이 어떤 응답을 언제 재사용할지 판단한다.
네 문서는 하나의 요청을 서로 다른 위치에서 본다. prerequisite graph는 완전한 직선이 아니다. HTTP Basics → OSI/Web Server → TCP/UDP → DNS가 이름과 연결을 이해하는 축이고, HTTP Cache는 HTTP Basics + OSI/Web Server에서 갈라진다. Timeline에서는 요청 전후의 전체 경로를 한 번에 완성하기 위해 HTTP Cache를 마지막에 배치했다.
첫 회독에서 붙잡을 것
섹션 제목: “첫 회독에서 붙잡을 것”- OSI 계층 번호 암기보다 DNS, 연결, TLS, HTTP, 프록시, 앱 중 어디까지 성공했는지 구분한다.
- TCP의 연결·순서·재전송과 UDP가 그 책임을 상위 프로토콜에 넘긴다는 차이를 설명한다.
- DNS가 위임된 이름 공간을 따라가고 TTL 동안 답을 캐시한다는 흐름을 설명한다.
- HTTP 캐시에서 freshness, validation, cache key, shared/private 경계를 구분한다.
선택 심화로 미룰 것
섹션 제목: “선택 심화로 미룰 것”아래 표는 심화를 지금 배우라는 목록이 아니라, 뒤 문서에서 약어를 다시 만났을 때 위치를 잃지 않게 하는 지도다.
| 주제 | 첫 정의와 첫 회독 기준 | 다시 볼 문서 |
|---|---|---|
| BBR(Bottleneck Bandwidth and Round-trip propagation time) | 병목 대역폭과 최소 RTT를 추정해 전송 속도를 조절하는 TCP 혼잡 제어 알고리즘이다. 첫 회독에서는 “혼잡을 감지해 전송량을 조절한다”까지만 잡는다. | content/topics/L7/tcp-flow-congestion.mdx |
| BDP(Bandwidth-Delay Product, 대역폭-지연 곱) | 대역폭과 RTT를 곱해 경로를 가득 채우는 데 필요한 in-flight 데이터량을 가늠하는 값이다. 계산과 버퍼·윈도 선택은 미룬다. | content/topics/L7/tcp-flow-congestion.mdx |
| PMTUD(Path MTU Discovery, 경로 MTU 탐색) | 출발지부터 목적지까지 조각화 없이 보낼 수 있는 최대 패킷 크기를 찾는 절차다. 첫 회독에서는 작은 요청은 되는데 큰 응답만 멈추면 MTU 경로를 의심한다. | content/topics/L2/tcp-udp-internals.mdx, 이후 content/topics/L7/network-debugging.mdx |
| QUIC | UDP 위에 암호화와 연결·스트림 제어를 구성하고 HTTP/3가 사용하는 전송 프로토콜이다. TCP와의 세부 성능 비교는 미룬다. | content/topics/L7/http2-http3.mdx |
| AWS NACL(Network Access Control List) | VPC Subnet 경계의 stateless allow/deny 목록이다. 응답 경로도 별도 규칙이 필요하다는 위치만 잡고, L2 핵심 경로와 분리한다. | content/topics/L3/vpc-subnet-sg.mdx → content/topics/L3/network-security.mdx |
이 주제들을 건너뛰어도 L2 첫 회독은 완료할 수 있다. 먼저 네 핵심 문서로 요청 경로와 책임 경계를 설명한 뒤, 실제로 처리량·큰 패킷·HTTP/3·AWS 네트워크 정책 문제가 생겼을 때 돌아온다. NACL은 VPC 기초에서 Subnet·Route Table·Security Group의 위치를 먼저 잡고, Network Security에서 SG를 기본 방어선으로 둘 때와 NACL의 stateless deny가 필요한 때를 비교하는 순서로 읽는다.
6. 어렵게 느껴지는 지점과 돌아갈 곳
섹션 제목: “6. 어렵게 느껴지는 지점과 돌아갈 곳”| 막히는 느낌 | 보통 부족한 전제 | 돌아갈 문서 |
|---|---|---|
| URL, 상태 코드, 헤더가 아직 섞인다 | HTTP 요청·응답의 기본 구조 | content/topics/L1/http-basics.mdx |
| 프록시, Web Server, 앱 서버의 위치가 헷갈린다 | 요청 앞단의 책임 경계 | content/topics/L2/osi-web-server.mdx |
| 연결, handshake, timeout, reset이 한꺼번에 어렵다 | 전송 계층의 연결과 실패 신호 | content/topics/L2/tcp-udp-internals.mdx |
| 도메인을 바꿨는데 일부 사용자만 예전 주소를 본다 | DNS 위임과 TTL 캐시 | content/topics/L2/dns-basics.mdx |
no-cache, no-store, CDN hit가 같은 말처럼 보인다 | HTTP 응답의 저장·재검증·공유 범위 | content/topics/L2/http-cache.mdx |
| TLS 인증서와 안전한 전송 경계를 더 알고 싶다 | 서버 인증·기밀성·무결성의 역할 | 선택 참고: content/topics/L1/web-security-basics.mdx |
| Security Group, Route Table, NACL이 L2 개념처럼 몰려온다 | AWS 가상 네트워크의 경로와 정책 | content/topics/L3/vpc-subnet-sg.mdx → content/topics/L3/network-security.mdx |
돌아갈 때는 문서 전체를 다시 끝내려 하지 않아도 된다. 지금 막힌 용어의 정의와 요청 경로에서의 위치를 확인한 뒤 L2 핵심 경로로 복귀한다.
7. 들을 준비가 된 상태
섹션 제목: “7. 들을 준비가 된 상태”L2 readiness check
- HTTP 요청이 도메인 해석, 전송 연결, 서버 앞단을 거쳐 애플리케이션에 도착한다는 큰 흐름을 말할 수 있다.
- 상태 코드가 온 경우와 연결 자체가 실패한 경우를 같은 문제로 단정하지 않는다.
- TCP와 UDP의 차이를 단순히 느림과 빠름이 아니라 보장하는 책임의 차이로 배울 준비가 되어 있다.
- DNS와 HTTP 캐시가 모두 캐시를 쓰지만 서로 다른 대상과 시간 경계를 다룬다는 점을 구분할 수 있다.
- BBR, BDP, PMTUD, QUIC, AWS NACL을 몰라도 핵심 네 문서를 먼저 읽어도 된다는 기준을 안다.
- AWS NACL이 필요해지면 L3 VPC 기초를 거쳐 Network Security의 SG/NACL 선택 기준으로 이동한다는 경로를 안다.
- 막히는 증상에 따라 L1 HTTP, 해당 L2 문서, L3 VPC·보안, L7 네트워크 심화 중 돌아갈 곳을 고를 수 있다.
8. 이 레이어의 핵심 한 문장
섹션 제목: “8. 이 레이어의 핵심 한 문장”네트워킹은 보이지 않는 요청 경로를 이름, 연결, 서버, 응답 재사용의 책임 경계로 나누고, 실패 신호를 가장 가까운 경계의 질문으로 바꾸는 기술이다.