나노플레이데이즈사전
전체 사전

네트워크 사전

주소창에 shop.example.com을 적으면 DNS가 IP를 찾고, 핸드셰이크로 TCP·TLS 약속을 맺고, HTTP로 파일을 받습니다. 그 사이 NAT가 주소를 바꿔 적고, 로드 밸런서가 서버를 고르고, CDN이 가까운 사본을 줍니다. 데이터가 상자 사이를 지나는 작동 구성도와 직접 움직여 보는 예시로 각 개념이 무엇을 바꾸는지 봅니다.

작동 구성도: 주소 하나를 열 때 데이터가 지나가는 길

개념마다 데이터 조각이 어느 상자를 지나 오가는지 따라가 보세요. 번호를 누르면 그 단계로 갑니다.

사람은 shop.example.com이라는 이름을 적지만 컴퓨터는 IP 주소로만 찾아갑니다. 리졸버가 DNS 서버들에 차례로 물어 IP를 알아 오고, 정해진 시간(TTL) 동안 기억합니다.

1이름 묻기요청 · 보냄

브라우저 → 리졸버

브라우저가 먼저 자기 기억(캐시)을 보고, 없으면 리졸버에게 'shop.example.com의 IP가 뭐야?'라고 묻습니다.

1 / 9
  • 요청 · 보냄
  • 약속 · 확인
  • 중계 · 다시 보냄
  • 응답 · 받음
  • 미리 이어 둔 연결
모든 단계를 글로 보기

DNS 이름 → IP

  1. 이름 묻기 (브라우저 → 리졸버) 브라우저가 먼저 자기 기억(캐시)을 보고, 없으면 리졸버에게 'shop.example.com의 IP가 뭐야?'라고 묻습니다.
  2. 루트 서버에 묻기 (리졸버 → 루트 서버) 리졸버도 모르면 이름의 맨 끝부터 물어 갑니다. 루트 서버는 IP를 모르지만 '.com은 저 서버가 안다'고 알려 줍니다.
  3. .com 담당 위치 받기 (루트 서버 → 리졸버) 루트 서버가 .com을 맡은 TLD 서버 주소를 돌려줍니다.
  4. TLD 서버에 묻기 (리졸버 → TLD 서버) 리졸버가 .com 담당 서버에 다시 묻습니다.
  5. example.com 담당 위치 받기 (TLD 서버 → 리졸버) TLD 서버는 'example.com은 이 권한 서버가 안다'고 알려 줍니다. 도메인을 산 곳에서 정한 네임서버입니다.
  6. 권한 서버에 묻기 (리졸버 → 권한 서버) 드디어 답을 아는 서버에 shop.example.com을 묻습니다.
  7. IP와 TTL 받기 (권한 서버 → 리졸버) '93.184.215.14, TTL 300초.' 이 답을 300초 동안 기억해도 된다는 뜻입니다.
  8. 답 전달 + 기억 (리졸버 → 브라우저) 리졸버와 브라우저가 IP를 TTL 동안 기억합니다. 그동안 다시 접속하면 2~7단계를 건너뛰어 바로 답을 얻습니다. IP를 바꾸면 TTL이 지나야 모두에게 퍼지는 이유입니다.
  9. IP로 접속 (브라우저 → 웹 서버) 이제 IP 93.184.215.14로 웹 서버에 연결합니다. DNS는 길을 알려 줄 뿐, 페이지 내용은 웹 서버가 줍니다.

TCP vs UDP 빠짐없이 vs 빠르게

  1. TCP: 번호 붙여 보내기 (보내는 쪽 → 받는 쪽) 조각 1·2·3·4에 번호를 붙여 보냅니다. 그런데 3번이 도중에 사라졌습니다.
  2. ACK: '2번까지 받았어' (받는 쪽 → 보내는 쪽) 받는 쪽은 받은 번호를 알려 줍니다(ACK). 4번은 받았지만 3번이 없으니 4번을 쥔 채 기다립니다.
  3. 3번만 다시 보내기 (보내는 쪽 → 받는 쪽) 보내는 쪽이 빠진 3번을 다시 보냅니다. 그만큼 기다린 시간이 늘어납니다.
  4. 순서대로 넘기기 (받는 쪽 → 웹페이지) 1·2·3·4가 다 모이면 순서대로 웹페이지에 넘깁니다. 글자 하나 빠져도 안 되는 웹·결제·파일은 TCP를 씁니다.
  5. UDP: 그냥 보내기 (보내는 쪽 → 받는 쪽) 번호 확인도, 받았다는 답장도 없이 연달아 보냅니다. 3번이 사라져도 보내는 쪽은 모릅니다.
  6. 빠진 건 두고 바로 쓰기 (받는 쪽 → 영상 통화) 온 1·2·4를 바로 재생합니다. 영상 통화·게임은 늦게 온 옛 화면보다 지금 화면이 중요해서 UDP를 씁니다. 화면이 잠깐 깨져도 멈추지 않는 이유입니다.

TLS 잠그고 확인

  1. ClientHello (브라우저 → 쇼핑몰 서버) 브라우저가 쓸 수 있는 암호 방식 목록과 키를 만들 재료(키 공유 값)를 보냅니다. 아직 잠그기 전이지만 비밀은 담겨 있지 않습니다.
  2. ServerHello + 인증서 (쇼핑몰 서버 → 브라우저) 서버가 암호 방식을 고르고 자기 키 재료와 인증 기관이 서명한 인증서를 보냅니다. 양쪽은 오간 재료로 같은 세션 키를 각자 계산합니다. 키 자체는 오가지 않습니다.
  3. 인증서 확인 + Finished (브라우저 → 쇼핑몰 서버) 브라우저는 미리 들어 있는 인증 기관 목록으로 서명과 도메인 이름을 확인합니다. 가짜 서버면 여기서 '안전하지 않음' 경고가 뜹니다. 맞으면 Finished를 보내 준비를 끝냅니다.
  4. 잠근 요청 (브라우저 → 쇼핑몰 서버) 'GET /cart'와 로그인 쿠키가 세션 키로 잠겨 갑니다. 엿보는 사람에게는 '8f3a91c2…' 같은 알 수 없는 글자만 보입니다.
  5. 잠근 응답 (쇼핑몰 서버 → 브라우저) 장바구니 내용도 잠겨서 돌아옵니다. 누가 중간에 한 글자라도 바꾸면 풀 때 바로 들통납니다.

HTTP/2 vs 3 한 줄 vs 따로따로

  1. 세 파일을 한 연결에 섞기 (서버 → TCP 연결 1개) HTTP/2는 HTML·CSS·이미지를 스트림으로 나눠 TCP 연결 하나에 번갈아 싣습니다(멀티플렉싱). 연결을 여러 개 열던 HTTP/1.1보다 빠릅니다.
  2. 조각 하나 유실 → 셋 다 멈춤 (TCP 연결 1개 → 브라우저) CSS 조각 하나가 사라지면 TCP는 순서를 지키려고 뒤에 온 HTML·이미지 조각까지 쥐고 다시 올 때까지 기다립니다. 이를 줄 앞 막힘(head-of-line blocking)이라고 합니다.
  3. 세 파일을 QUIC 스트림으로 (서버 → QUIC 연결) HTTP/3는 TCP 대신 UDP 위의 QUIC을 씁니다. 스트림마다 순서를 따로 지키고, 연결 준비에 TLS 1.3을 묶어 왕복이 한 번 줄어듭니다.
  4. 잃은 CSS만 기다림 (QUIC 연결 → 브라우저) HTML과 이미지는 먼저 도착해 그려지고, CSS 스트림만 다시 받을 때까지 기다립니다. 손실이 잦은 휴대폰 망에서 차이가 커집니다.

로드 밸런서 나눠 맡기기

  1. 한 주소로 받기 (사용자들 → L7 밸런서) 모두 shop.example.com 하나로 접속합니다. 밸런서가 TLS를 풀고 요청 경로와 헤더를 읽습니다. L7은 HTTP 내용을 보는 층이라는 뜻입니다.
  2. /api/cart → API 서버 (L7 밸런서 → API 서버) 경로가 /api로 시작하면 API 서버 무리로 보냅니다. 같은 서버가 여러 대면 차례대로(라운드 로빈) 또는 가장 덜 바쁜 곳(최소 연결)을 고릅니다.
  3. /img/shoe.jpg → 이미지 서버 (L7 밸런서 → 이미지 서버) 이미지는 이미지 서버로 보냅니다. IP와 포트만 보는 L4 밸런서는 이렇게 경로로 나누지 못합니다.
  4. /video → 영상 서버 (L7 밸런서 → 영상 서버) 영상 요청은 영상 서버로 갑니다. 밸런서는 몇 초마다 서버 상태를 확인(health check)해 응답 없는 서버를 빼고 보냅니다.
  5. 응답 받기 (API 서버 → L7 밸런서) API 서버가 장바구니 내용을 밸런서에 돌려줍니다.
  6. 사용자에게 돌려주기 (L7 밸런서 → 사용자들) 사용자는 서버가 몇 대인지, 어느 서버가 답했는지 모릅니다. 서버 한 대가 죽어도 나머지가 받아 사이트가 멈추지 않습니다.

NAT 주소 바꿔 적기

  1. 사설 주소로 보냄 (휴대폰 → 공유기 (NAT)) 휴대폰이 보내는 주소 192.168.0.11:50123을 달고 요청을 보냅니다. 이 주소는 집 안에서만 통해서 인터넷으로는 못 나갑니다.
  2. 보내는 주소 바꿔 적기 (공유기 (NAT) → 웹 서버) 공유기가 보내는 주소를 공인 IP 211.0.0.7:40001로 바꾸고, 변환 표에 '40001번 = 휴대폰 50123번'이라고 적습니다.
  3. 다른 기기도 같은 공인 IP로 (노트북 → 공유기 (NAT)) 노트북 요청은 40002번으로 바꿉니다. 서버 눈에는 휴대폰도 노트북도 211.0.0.7 한 집에서 온 요청입니다.
  4. 응답은 공인 IP로 (웹 서버 → 공유기 (NAT)) 서버는 211.0.0.7:40001로 답합니다. 집 안 기기의 사설 주소는 알지 못합니다.
  5. 표를 보고 돌려주기 (공유기 (NAT) → 휴대폰) 40001번은 휴대폰이니 192.168.0.11:50123으로 바꿔 넘깁니다. 밖에서 먼저 들어온 연결은 표에 없어서 버립니다. 집 서버를 열려면 포트 포워딩을 따로 적어야 하는 이유입니다.

웹소켓 열어 두고 양쪽으로

  1. Upgrade 요청 (브라우저 → 채팅 서버) 평범한 HTTP 요청에 'Upgrade: websocket'을 붙여 '이 연결을 웹소켓으로 바꾸자'고 합니다.
  2. 101 프로토콜 전환 (채팅 서버 → 브라우저) 서버가 '101 Switching Protocols'로 답하면, 같은 TCP 연결을 끊지 않고 양쪽 통로로 씁니다.
  3. 메시지 보내기 (브라우저 → 채팅 서버) '안녕'을 보냅니다. 요청마다 헤더를 다시 싣지 않아 몇 바이트짜리 작은 프레임으로 갑니다.
  4. 친구가 답장 (친구 → 채팅 서버) 친구가 '반가워'를 보냅니다. 브라우저는 아무것도 묻지 않았습니다.
  5. 서버가 먼저 보내기 (채팅 서버 → 브라우저) 서버가 열린 통로로 바로 밀어 줍니다(push). HTTP 폴링이라면 몇 초마다 '새 메시지 있어?'를 물어야 하고, 그 사이만큼 늦습니다.

CDN 가까이에 사본

  1. 가까운 엣지로 (서울 사용자 → CDN 엣지) DNS가 사용자와 가까운 엣지 서버의 IP를 알려 줘서 요청이 서울 엣지로 갑니다.
  2. 사본 없음 → 원본에 묻기 (CDN 엣지 → 원본 서버) 처음이라 엣지에 사본이 없습니다(캐시 미스). 엣지가 바다 건너 원본 서버에 받으러 갑니다.
  3. 받아서 보관 (원본 서버 → CDN 엣지) 원본이 보낸 이미지를 엣지가 Cache-Control에 적힌 시간만큼 보관합니다.
  4. 첫 응답 180ms (CDN 엣지 → 서울 사용자) 첫 사용자는 원본까지 다녀온 만큼 기다립니다. 예: 180ms.
  5. 다음 요청 (다른 사용자 → CDN 엣지) 다른 사용자가 같은 이미지를 요청합니다.
  6. 캐시 적중 12ms (CDN 엣지 → 다른 사용자) 엣지에 사본이 있어(캐시 적중) 원본까지 가지 않고 12ms 만에 줍니다. 원본 서버가 받는 요청도 그만큼 줄어듭니다.

지연 vs 대역폭 거리 vs 폭

  1. 작은 요청도 90ms (서울 → 뉴욕 서버) 빛도 광케이블 안에서는 1ms에 약 200km를 갑니다. 서울에서 뉴욕까지는 아무리 작은 요청도 편도 약 90ms가 걸립니다.
  2. 왕복 180ms (뉴욕 서버 → 서울) 답까지 받으면 180ms입니다. 1KB든 10KB든 거의 같고, 회선을 10배 빠르게 사도 줄지 않습니다. 줄이려면 가까이 두거나(CDN) 왕복 수를 줄여야 합니다.
  3. 큰 파일은 대역폭이 정함 (서버 → 내 PC) 100MB는 800Mb라서 100Mbps 회선으로 약 8초가 걸립니다. 회선이 1Gbps면 0.8초로 줄어듭니다. 여기서는 90ms 지연이 거의 보이지 않습니다.

핸드셰이크 첫 바이트 전 왕복

  1. SYN (브라우저 → 서버) TCP 연결 약속 시작: '연결해도 돼?'
  2. SYN-ACK (서버 → 브라우저) '좋아, 너도 준비됐어?' 여기까지 왕복 1번(180ms).
  3. ACK + ClientHello (브라우저 → 서버) TCP 확인과 TLS 1.3 시작을 한 번에 실어 보냅니다.
  4. ServerHello … Finished (서버 → 브라우저) 인증서와 키 재료가 돌아옵니다. 왕복 2번(360ms). 옛 TLS 1.2라면 여기서 왕복이 한 번 더 듭니다.
  5. GET / (브라우저 → 서버) 이제야 진짜 요청을 잠가 보냅니다.
  6. 첫 바이트 도착 (서버 → 브라우저) 왕복 3번, 540ms 만에 첫 바이트(TTFB)가 옵니다. HTTP/3(QUIC)는 연결과 암호 약속을 합쳐 2번(360ms), 다시 방문하면 0-RTT로 요청을 바로 실어 1번에 끝낼 수 있습니다.

예시가 화면에 보이면 손가락 표시가 저절로 시연합니다. 직접 눌러 봐도 됩니다.

이름과 길을 찾는 것

이름을 IP로 바꾸고, 집 안 주소를 바깥 주소로 바꾸고, 요청을 알맞은 서버로 보냅니다.

  • DNS

    Domain Name System

    shop.example.com 같은 이름을 컴퓨터가 찾아갈 수 있는 IP 주소로 바꿔 주는 인터넷의 주소록입니다. 답은 TTL 동안 기억해 두고 다시 씁니다.

    브라우저리졸버루트.com권한 서버

    캐시: 비어 있음

    구성도에서 흐름 보기

    찾기를 두 번 눌러 보세요. 두 번째는 기억해 둔 답으로 바로 끝납니다.

    이럴 때도메인을 서버에 연결할 때, 서버를 옮겼는데 일부 사람에게만 새 사이트가 보일 때(TTL이 지나지 않음), 사이트가 'DNS 주소를 찾을 수 없음'으로 열리지 않을 때 이 말을 씁니다.

    다른 이름 · 헷갈리는 이웃
    다르게 부르는 말
    도메인 네임 시스템, 네임서버, DNS 조회, DNS 질의, 리졸버, resolver, TTL, 도메인 연결, nameserver

    헷갈리는 이웃

    • NAT DNS는 이름을 IP로 바꾸고, NAT는 집 안 사설 IP를 바깥 공인 IP로 바꿔 적습니다. 둘 다 '주소 바꾸기'지만 바꾸는 대상이 다릅니다.
    • CDN DNS는 IP를 알려 주는 일만 하고, CDN은 그 IP를 사용자 가까운 엣지 서버로 알려 줘 실제 파일을 가까이서 주게 합니다.
    복사되는 부탁 문장

    shop.example.com을 새 서버(IP 203.0.113.10)로 옮기려고 해. 옮기기 하루 전에 A 레코드 TTL을 300초로 낮추고, 옮긴 뒤 A 레코드를 새 IP로 바꾸고, 전 세계에서 새 IP가 보이는지 확인하는 순서와 각 단계에서 확인할 명령(nslookup·dig)을 적어 줘. 문제가 생기면 이전 IP로 되돌리는 방법도 함께 적어 줘.

  • NAT

    Network Address Translation

    공유기가 집·회사 안 기기들의 사설 주소를 공인 IP 하나로 바꿔 내보내고, 변환 표를 보고 응답을 원래 기기로 돌려주는 방식입니다.

    공유기 변환 표 (공인 IP 211.0.0.7)
    바깥 포트집 안 기기
    비어 있음

    서버가 본 보낸 주소: -

    구성도에서 흐름 보기

    기기 버튼을 눌러 보세요. 서버에는 모두 같은 공인 IP로 보입니다.

    이럴 때집에서 연 서버에 밖에서 접속이 안 될 때(포트 포워딩 필요), 서버 로그에 여러 사람이 같은 IP로 찍힐 때, 화상 통화·게임이 직접 연결되지 않을 때 이 말을 씁니다.

    다른 이름 · 헷갈리는 이웃
    다르게 부르는 말
    네트워크 주소 변환, 주소 변환, 공유기, 사설 IP, 공인 IP, 포트 포워딩, port forwarding, PAT, IP 마스커레이드

    헷갈리는 이웃

    • DNS NAT는 사설 IP ↔ 공인 IP를 바꾸고, DNS는 이름 ↔ IP를 바꿉니다.
    • 로드 밸런서(L7) NAT는 안에서 나가는 요청을 한 주소로 모으고, 로드 밸런서는 밖에서 들어오는 요청을 여러 서버로 나눕니다.
    복사되는 부탁 문장

    집 공유기 안의 PC(192.168.0.20)에서 연 웹 서버(포트 8080)에 밖에서 접속하게 하고 싶어. 공유기 관리 화면에서 포트 포워딩 규칙(바깥 포트 → 안쪽 IP:포트)을 넣는 순서, PC 주소가 바뀌지 않게 고정하는 방법, 밖에서 열렸는지 확인하는 방법을 적어 줘. 꼭 필요한 포트만 열고 관리자 화면 포트는 열지 마.

  • 로드 밸런서(L7)

    Load balancer (Layer 7)

    한 주소로 들어온 요청을 여러 서버에 나눠 보내는 장치입니다. L7은 HTTP 경로·헤더까지 읽고 어느 서버 무리로 보낼지 정합니다.

    API-1 0API-2 0이미지 0영상 0
    구성도에서 흐름 보기

    요청 버튼을 눌러 보세요. 경로를 읽고 서버를 고릅니다.

    이럴 때사용자가 늘어 서버 한 대로 버티지 못할 때, 서버 하나가 죽어도 사이트가 멈추지 않게 할 때, /api와 /img처럼 경로마다 다른 서버로 보내고 싶을 때 씁니다.

    다른 이름 · 헷갈리는 이웃
    다르게 부르는 말
    로드밸런서, 부하 분산, L7 로드 밸런서, L4 로드 밸런서, ALB, 리버스 프록시, reverse proxy, 라운드 로빈, health check, 헬스 체크

    헷갈리는 이웃

    • CDN 로드 밸런서는 같은 지역 서버들에 요청을 나누고, CDN은 세계 곳곳의 엣지에 사본을 둬 가까운 곳에서 줍니다.
    • NAT 로드 밸런서는 들어오는 요청을 나누고, NAT는 나가는 요청의 주소를 하나로 모읍니다.
    복사되는 부탁 문장

    shop.example.com 앞에 L7 로드 밸런서를 두고 싶어. /api/*는 API 서버 2대에 최소 연결 방식으로, /img/*는 이미지 서버로 보내고, 10초마다 /health를 확인해 2번 연속 실패한 서버는 빼는 설정을 적어 줘. 로그인 상태가 서버마다 끊기지 않게 세션을 어디에 둘지도 알려 줘.

연결하고 약속하는 것

데이터를 어떻게 보낼지, 어떻게 잠글지, 첫 글자 전에 몇 번 주고받을지 정합니다.

  • TCP와 UDP

    TCP vs UDP

    데이터 조각을 보내는 두 방식입니다. TCP는 번호를 확인해 빠진 조각을 다시 받아 순서대로 넘기고, UDP는 확인 없이 보내 빠져도 그대로 씁니다.

    3번 조각이 도중에 사라지는 망입니다.

    구성도에서 흐름 보기

    방식을 고르고 보내 보세요. 3번이 사라졌을 때 다르게 처리합니다.

    이럴 때웹·결제·파일처럼 하나도 빠지면 안 되는 일은 TCP, 영상 통화·게임·실시간 방송처럼 늦은 데이터보다 지금 데이터가 중요한 일은 UDP를 쓴다고 말할 때 씁니다.

    다른 이름 · 헷갈리는 이웃
    다르게 부르는 말
    TCP, UDP, 전송 계층, 패킷 손실, 재전송, ACK, 패킷, packet loss, 3-way handshake

    헷갈리는 이웃

    • HTTP/2와 HTTP/3 HTTP/3는 UDP 위에 QUIC을 얹어 TCP처럼 빠짐없이 받되, 파일마다 따로 순서를 지켜 TCP의 줄 앞 막힘을 피합니다.
    • 핸드셰이크 TCP는 보내기 전에 연결 약속(SYN·SYN-ACK·ACK)을 하고, UDP는 약속 없이 바로 보냅니다.
    복사되는 부탁 문장

    우리 앱에 실시간 위치 공유를 넣으려고 해. 위치는 1초마다 보내고 늦게 온 옛 위치는 쓸모없어. TCP(웹소켓)와 UDP(WebRTC 데이터 채널, 순서·재전송 끔) 중 무엇이 맞는지, 손실 5% 망에서 각각 어떻게 보일지 비교하고 고른 쪽의 연결 코드 뼈대를 적어 줘.

  • TLS

    Transport Layer Security

    브라우저와 서버가 인증서로 상대가 진짜인지 확인하고, 둘만 아는 키로 오가는 내용을 잠그는 약속입니다. https의 s가 TLS입니다.

    http://shop.example.com/cart

    브라우저가 보낸 것GET /cart · cookie: session=7f2k

    같은 와이파이에서 엿보는 사람이 보는 것GET /cart · cookie: session=7f2k

    구성도에서 흐름 보기

    TLS를 켜 보세요. 엿보는 사람에게 보이는 글이 바뀝니다.

    이럴 때사이트에 https를 붙일 때, '연결이 안전하지 않음' 경고가 뜰 때, 인증서 만료일을 챙길 때, 공용 와이파이에서 비밀번호가 새지 않는 이유를 설명할 때 씁니다.

    다른 이름 · 헷갈리는 이웃
    다르게 부르는 말
    SSL, SSL/TLS, https, HTTPS, 인증서, SSL 인증서, 암호화 통신, 자물쇠, certificate, CA, 인증 기관

    헷갈리는 이웃

    • 핸드셰이크 TLS는 잠그는 약속 자체이고, 핸드셰이크는 그 약속을 맺느라 첫 바이트 전에 오가는 왕복을 가리킵니다.
    • TCP와 UDP TLS는 TCP 위에서 내용을 잠그고, TCP는 조각이 빠짐없이 순서대로 오게 합니다. 역할이 겹치지 않습니다.
    복사되는 부탁 문장

    shop.example.com과 www.shop.example.com에 무료 인증서(Let's Encrypt)를 붙이고, http로 들어오면 https로 301 이동시키고, 90일 만료 전에 자동 갱신되게 하는 설정을 nginx 기준으로 적어 줘. TLS 1.2 미만은 끄고, 갱신이 실패하면 알림을 받을 방법도 넣어 줘.

  • 핸드셰이크

    Handshake

    실제 데이터를 보내기 전에 연결(TCP)과 암호(TLS) 약속을 맺느라 주고받는 왕복입니다. 왕복 수 × 왕복 시간만큼 첫 바이트가 늦어집니다.

      왕복 한 번 = 180ms(서울 ↔ 뉴욕)

      구성도에서 흐름 보기

      연결 방식을 바꿔 보세요. 첫 바이트까지 왕복 수가 달라집니다.

      이럴 때멀리 있는 서버에서 첫 화면이 유난히 늦을 때, TLS 1.3·HTTP/3로 바꾸면 왜 빨라지는지, 연결을 재사용(keep-alive)하라는 말이 왜 나오는지 설명할 때 씁니다.

      다른 이름 · 헷갈리는 이웃
      다르게 부르는 말
      핸드쉐이크, 악수, 연결 수립, RTT, 왕복 시간, round trip, TTFB, 첫 바이트, 0-RTT, 3-way handshake, TLS 핸드셰이크

      헷갈리는 이웃

      • 지연 시간과 대역폭 핸드셰이크는 왕복 '횟수'이고, 지연 시간은 왕복 한 번에 걸리는 '시간'입니다. 둘을 곱하면 첫 바이트 전 기다림이 됩니다.
      • TLS TLS는 내용을 잠그는 약속이고, 핸드셰이크는 그 약속을 맺는 과정입니다.
      복사되는 부탁 문장

      해외 사용자가 우리 사이트(서버 서울) 첫 화면이 2초 넘게 걸린다고 해. 첫 바이트(TTFB)까지 TCP·TLS 핸드셰이크 왕복이 몇 번인지 브라우저 개발자 도구 Timing 탭에서 확인하는 방법, TLS 1.3·HTTP/3·연결 재사용·CDN으로 왕복을 줄이는 방법을 효과가 큰 순서로 적어 줘.

    1. 웹소켓

      WebSocket

      한 번 연 연결을 계속 열어 두고 브라우저와 서버가 서로 먼저 데이터를 보낼 수 있게 하는 통로입니다.

      아직 메시지 없음

      보낸 요청 0번

      구성도에서 흐름 보기

      친구 메시지를 보내 보세요. 받는 방식에 따라 늦는 시간과 요청 수가 다릅니다.

      이럴 때채팅·실시간 알림·주식 시세·여럿이 함께 편집처럼 서버에서 생긴 일을 바로 화면에 보여야 할 때 씁니다. 몇 초마다 묻는 폴링보다 빠르고 요청이 적습니다.

      다른 이름 · 헷갈리는 이웃
      다르게 부르는 말
      websocket, 웹 소켓, ws, wss, 실시간 통신, 양방향 통신, 서버 푸시, 폴링, polling, 롱 폴링, SSE

      헷갈리는 이웃

      • TCP와 UDP 웹소켓은 TCP 연결 하나를 열어 두고 쓰는 방식이라, TCP처럼 빠짐없이 순서대로 옵니다.
      • HTTP/2와 HTTP/3 HTTP는 브라우저가 물어야 서버가 답하고, 웹소켓은 업그레이드 뒤 서버도 먼저 보낼 수 있습니다. 서버 → 브라우저 한쪽만 필요하면 SSE도 있습니다.
      복사되는 부탁 문장

      주문 상태(접수·포장·배송)가 바뀌면 고객 화면에 바로 뜨게 하고 싶어. 지금은 5초마다 폴링해. 웹소켓(wss)으로 바꾸는 서버·브라우저 코드 뼈대와, 연결이 끊기면 1·2·4초 간격으로 다시 잇고 그동안 놓친 상태를 한 번 받아 오는 방법을 적어 줘. 서버 → 화면 한쪽만 필요하면 SSE가 나은지도 비교해 줘.

    빠르기를 정하는 것

    같은 페이지도 거리·한 번에 흐르는 양·막힘에 따라 늦거나 빨라집니다.

    • HTTP/2와 HTTP/3

      HTTP/2 vs HTTP/3

      웹 파일을 주고받는 규칙의 두 버전입니다. HTTP/2는 TCP 연결 하나에 여러 파일을 섞어 보내고, HTTP/3는 UDP 위 QUIC에서 파일마다 따로 순서를 지킵니다.

      HTML

      CSS

      이미지

      CSS 조각 하나가 도중에 사라지는 망입니다.

      구성도에서 흐름 보기

      버전을 고르고 불러와 보세요. 조각 하나를 잃었을 때 멈추는 범위가 다릅니다.

      이럴 때서버·CDN 설정에서 HTTP/3를 켤지 정할 때, 휴대폰 망에서 페이지가 띄엄띄엄 멈추는 이유를 설명할 때, 개발자 도구 Protocol 칸의 h2·h3를 읽을 때 씁니다.

      다른 이름 · 헷갈리는 이웃
      다르게 부르는 말
      HTTP2, HTTP3, h2, h3, QUIC, 퀵, 멀티플렉싱, multiplexing, 줄 앞 막힘, head-of-line blocking, HOL 블로킹

      헷갈리는 이웃

      • TCP와 UDP HTTP/2는 TCP 위에서, HTTP/3는 UDP 위의 QUIC에서 돕니다. 조각 하나를 잃었을 때 멈추는 범위가 다릅니다.
      • 핸드셰이크 HTTP/3는 연결과 TLS 약속을 한 번에 맺어 첫 바이트 전 왕복이 하나 줄어듭니다.
      복사되는 부탁 문장

      우리 사이트(nginx, CDN 앞단)에 HTTP/3를 켜고 싶어. 서버·CDN에서 켜는 설정, 브라우저가 h3로 붙었는지 개발자 도구 Protocol 칸에서 확인하는 방법, UDP 443이 막힌 망에서 HTTP/2로 자동으로 돌아가는지 확인하는 방법을 적어 줘.

    • CDN

      Content Delivery Network

      세계 곳곳의 엣지 서버에 이미지·스크립트 같은 파일의 사본을 두고, 사용자 가까운 곳에서 주는 전송망입니다.

      서울 사용자CDN 엣지원본(미국)

      엣지 사본: 없음

      구성도에서 흐름 보기

      이미지를 두 번 요청해 보세요. 두 번째는 가까운 엣지가 바로 줍니다.

      이럴 때해외 사용자에게 페이지가 느릴 때, 이미지·영상 트래픽으로 원본 서버가 버거울 때, 파일을 고쳤는데 옛 파일이 보여 캐시를 비워야(퍼지) 할 때 씁니다.

      다른 이름 · 헷갈리는 이웃
      다르게 부르는 말
      콘텐츠 전송 네트워크, 콘텐츠 delivery 네트워크, 엣지, 엣지 서버, edge, 캐시, 캐시 적중, cache hit, 캐시 미스, cache miss, Cache-Control, 오리진

      헷갈리는 이웃

      • 지연 시간과 대역폭 CDN은 거리를 줄여 지연 시간을 줄입니다. 회선 폭(대역폭)을 늘리는 것과는 다른 처방입니다.
      • 로드 밸런서(L7) CDN은 사본을 가까이 두고, 로드 밸런서는 원본 쪽 서버들에 요청을 나눕니다.
      복사되는 부탁 문장

      shop.example.com의 /assets/*(이름에 해시가 붙은 JS·CSS·이미지)는 CDN에서 1년 캐시(Cache-Control: public, max-age=31536000, immutable)하고, HTML은 캐시하지 않게(no-cache) 설정해 줘. 배포 뒤 옛 HTML이 보이면 그 경로만 퍼지하는 방법과, 캐시 적중 여부를 응답 헤더로 확인하는 방법도 적어 줘.

    • 지연 시간과 대역폭

      Latency vs Bandwidth

      지연 시간은 데이터 한 조각이 가는 데 걸리는 시간(거리)이고, 대역폭은 1초에 흘려보낼 수 있는 양(도로 폭)입니다.

      구성도에서 흐름 보기

      크기·거리·회선을 바꿔 보세요. 무엇이 시간을 정하는지 막대가 보여 줍니다.

      이럴 때회선을 빠르게 바꿨는데 웹이 그대로일 때(지연이 원인), 큰 파일 내려받기가 느릴 때(대역폭이 원인), 게임 핑과 인터넷 속도를 구분해 말할 때 씁니다.

      다른 이름 · 헷갈리는 이웃
      다르게 부르는 말
      지연, 레이턴시, latency, 대역폭, bandwidth, 핑, ping, 왕복 시간, RTT, 속도, Mbps, Gbps, 처리량, throughput

      헷갈리는 이웃

      • 핸드셰이크 지연 시간은 왕복 한 번의 시간이고, 핸드셰이크는 그 왕복을 몇 번 하는지입니다.
      • CDN 지연을 줄이려면 가까이 가야(CDN) 하고, 대역폭은 회선을 넓혀야 늘어납니다.
      복사되는 부탁 문장

      우리 페이지 로딩이 느린 원인이 지연인지 대역폭인지 가려 줘. 개발자 도구 Network 탭에서 요청마다 Waiting(TTFB)과 Content Download 시간을 비교하는 방법, 작은 요청이 많아 왕복이 쌓이는 경우와 큰 파일 하나가 오래 걸리는 경우의 처방을 따로 적어 줘.

    이럴 때 씁니다
    • 개발자가 'DNS 전파 중', 'TLS 인증서 만료', 'CDN 캐시 퍼지' 같은 말을 할 때 무슨 일이 일어나는지 알고 싶을 때
    • 사이트가 느리거나 안 열릴 때 원인이 이름 찾기·연결 약속·거리·회선 폭 중 어디인지 짐작하고 싶을 때
    • 서버를 옮기거나 https·HTTP/3·CDN을 붙일 때 AI나 개발자에게 조건을 담아 부탁하고 싶을 때
    • 채팅·실시간 알림처럼 서버가 먼저 보내야 하는 기능에 무엇을 써야 하는지 정하고 싶을 때
    사용법
    1. 맨 위 작동 구성도에서 개념을 고르면 데이터 조각이 상자 사이를 지나며 단계마다 무엇을 하는지 보여 줍니다. 번호·이전·다음으로 따라갑니다.
    2. 분류(이름과 길을 찾는 것, 연결하고 약속하는 것, 빠르기를 정하는 것)에서 용어를 고르거나 사전 첫 화면 검색에 아는 말을 적습니다. 예시는 화면에 들어오면 손가락 표시가 직접 눌러 보여 줍니다.
    3. 헷갈리는 이웃에서 비슷한 개념과의 차이를 보고, 부탁 문장 복사를 눌러 AI나 요청서에 붙여넣습니다.
    꼭 알아둘 점
    • 예시는 실제 네트워크 요청을 보내지 않고 미리 정한 값으로 움직입니다. IP·밀리초·왕복 수는 이해를 돕는 예시값이며 실제 값은 망과 거리에 따라 다릅니다.
    • 모든 예시는 같은 쇼핑몰 주소(shop.example.com)를 여는 이야기입니다. 한 번 접속에 여러 개념이 차례로 함께 쓰입니다.
    • 왕복 시간 180ms는 서울과 뉴욕 사이를 어림한 값입니다.
    자주 묻는 질문
    TCP와 UDP 중 무엇이 더 좋나요?
    좋고 나쁨이 아니라 쓰임이 다릅니다. 하나라도 빠지면 안 되는 웹·결제·파일은 TCP, 늦게 온 데이터가 쓸모없는 영상 통화·게임은 UDP를 씁니다. HTTP/3는 UDP 위에 QUIC을 얹어 빠짐없이 받으면서도 TCP의 줄 앞 막힘을 피합니다.
    지연 시간과 대역폭은 어떻게 다른가요?
    지연 시간은 한 조각이 가는 데 걸리는 시간(거리), 대역폭은 1초에 흘려보낼 수 있는 양(도로 폭)입니다. 작은 요청이 많은 웹은 지연이, 큰 파일 내려받기는 대역폭이 시간을 정합니다. 회선을 빠르게 바꿔도 웹이 그대로라면 지연이 원인입니다.
    SSL과 TLS는 같은 말인가요?
    SSL은 TLS의 옛 이름이자 옛 버전입니다. 지금 쓰는 것은 TLS 1.2·1.3이지만 습관처럼 'SSL 인증서'라고 부릅니다.
    DNS를 바꿨는데 왜 어떤 사람에게는 옛 사이트가 보이나요?
    리졸버와 브라우저가 이전 답을 TTL 동안 기억하기 때문입니다. 옮기기 전에 TTL을 짧게(예: 300초) 낮춰 두면 바꾼 뒤 빨리 퍼집니다.
    CDN이 있으면 로드 밸런서는 필요 없나요?
    역할이 다릅니다. CDN은 이미지·스크립트처럼 같은 파일의 사본을 가까이서 주고, 로드 밸런서는 주문·로그인처럼 매번 원본 서버가 처리해야 하는 요청을 여러 서버에 나눕니다. 큰 서비스는 둘 다 씁니다.
    웹소켓과 폴링은 언제 무엇을 쓰나요?
    몇 분에 한 번 바뀌는 정보면 폴링으로 충분합니다. 채팅·실시간 알림처럼 바로 보여야 하거나 사용자가 많아 묻는 요청이 쌓이면 웹소켓을 씁니다. 서버 → 화면 한쪽만 필요하면 SSE도 있습니다.

    광고