그림으로 배우는 Http&Network Basic 정리 - 1장. 웹과 네트워크 기본에 대해 알아보자

Study Platform📚/그림으로 배우는 Http&Network Basic

그림으로 배우는 Http&Network Basic 정리 - 1장. 웹과 네트워크 기본에 대해 알아보자

쿄코코 2025. 2. 6. 00:33

이 시리즈는 그림으로 배우는 Http&Network Basic 을 읽고 스터디 하면서 정리한 내용입니다.
추가적으로 포함되어 있는 내용은 GPT 를 이용하여서 정리한 내용으로 참고해주시면 감사하겠습니다.

챕터가 이야기 하고 싶은바.
- 웹이라는 세계가 어떤 기술로 구성되어 있는가
- HTTP는 어떻게 탄생했고 성장해 왔는가에 대해서 배워보자.

1-1. 웹은 HTTP로 나타낸다.

즉, 웹은 HTTP라는 약속을 사용한 통신"이다.

웹에서 데이터를 주고받을 때, HTTP라는 정해진 규칙(프로토콜)을 따르는 방식으로 통신이 이루어진다.
HTTP는 클라이언트(브라우저)와 서버 간의 데이터 요청/응답을 위한 약속(규칙)이며, 이 흐름에 따라 웹이 동작한다.
예를 들어, 브라우저가 서버에 요청을 보낼 때는 GET, POST 등의 HTTP 메서드를 사용하고, 서버는 HTTP 응답 코드(200, 404, 500 등) 와 함께 데이터를 반환합니다

1.2. HTTP는 이렇게 태어났고 성장했다

1) 인터넷과 정보 공유의 필요성
CREN(유럽 인자 물리 연구소)에서 팀 버너스 리가 제안한 월드 와이드 웹(World Wide Web, WWW) 프로젝트에서 시작이되었다.
당시 연구자들은 전 세계적으로 연구자료를 공유할 필요가 있었고, 이를 해결하기 위해 WWW 프로젝트가 탄생했다.

2) WWW 프로젝트의 등장
WWW는 당시 하이퍼텍스트를 열람할 수 있는 클라이언트 애플리케이션 명칭이었다.
이 프로젝트에서는 다음과 같은 핵심 개념이 정의되었다.

HTML(HyperText Markup Language) : 문서를 작성하는 마크업 언어
HTTP(HyperText Transfer Language) : 클라이언트와 서버 간 문서를 주고받는 규칙(프로토콜)
URL(Uniform Resource Locator) : 웹 문서의 위치를 나타내주는 주소 체계

3) HTTP 0.9(1990년)
- GET 요청만 지원 → 클라이언트(웹 브라우저)가 GET 요청을 보내면, 서버는 HTML 문서 하나만 반환하는 방식

4) HTTP 1.0(1996년)

헤더(Header) 개념 도입: 요청과 응답에 부가적인 정보를 담을 수 있음
다양한 메서드 지원: GET, POST, HEAD 등의 요청 방식 추가
MIME 타입 지원: 이미지, 동영상, 파일 등 다양한 데이터 전송 가능
비효율적인 TCP 연결 : 요청마다 새로운 TCP 를 연결을 맺기 때문에 속도가 느림.

5) HTTP/1.1(1997년)

Persistent Connection (지속적인 연결): 여러 개의 요청을 같은 TCP 연결에서 처리 가능 → 속도 개선
Chunked Transfer Encoding: 데이터를 조각(chunk) 단위로 전송 가능 → 대용량 데이터 지원
Host 헤더 지원: 여러 개의 웹사이트를 같은 서버에서 운영 가능 (가상 호스팅 지원)

6) HTTP/2.0

멀티플렉싱(Multiplexing) : 하나의 연결에서 여러개의 요청과 응답을 동시에 처리할 수 있다. HTTP/1.1에서는 하나의 요청이 끝나야 다음 요청을 보낼 수 있었지만, HTTP/2.0에서는 병렬로 처리가 가능하다.
헤더 압축(HPACK), 중복 헤더 : HTTP 헤더를 효율적으로 압축하여 네트워크의 대역폭을 절약하였다. HTTP/1.1에서는 요청마다 헤더가 중복 전송하였지만, HTTP/2는 변화가 없는 헤더는 재사용하고 변경된 부분만 전송한다.
서버푸시(Server Push) : 클라이언트가 요청하기 전에 서버가 필요한 리소스를 미리 보내준다. 예를 들어서 웹페이지를 요청하면 CSS,JS 파일을 서버가 먼저 클라이언트에 푸시한다.
스트림 우선순위(Stream Priroritization) : 클라이언트가 리소스의 중요도를 지정하여 우선적으로 받을 수있다.
단일 연결 유지 : HTTP/1.1에서는 여러개의 TCP 연결이 필요했지만, HTTP/2는 하나의 TCP 연결만 유지하면서 여러 요청을 처리한다.
이진프레이밍 : 기존 HTTP/1.1의 텍스트 기반 프로토콜이 아닌, 이진 방식으로 데이터를 전송하여 속도와 안정성이 증가하였다.

=> HTTP/2는 하나의 TCP 연결을 유지하지하면서 여러개의 요청을 동시에 처리(멀티플레싱) 한다. 즉, 하나의 TCP 연결에서 여러개의 데이터 스트림(요청/응답)이 동시에 전송될 수있다. 그렇기에 여러거 요청을 하나의 TCP 연결에서 처리하므로, 한 요청의 패킷이 손실되면, 다른 모든 요청도 영향을 받을 수 있다.(Head-of-Line Blocking 문제)
=> 이문제를 HTTP/3(QUIC) 사용해 해결했다.

6) HTTP/3(QUIC)

TCP -> UDP 기반(QUIC) : HTTP/3는 TCP 대신 UDP기반의 QUIC 프로토콜을 사용하였다.
0-RTT (Zero Round Trip Time) : TCP 는 연결을 맺을 때 3-way handshake(3번 왕복)이 필요했지만, QUIC 은 0-RTT 핸드셰이크를 지원하면서 기존 연결이 있으면 바로 데이터 전송을 시작하였다. 즉, 재연결 시 거의 즉시 데이터 전송이 가능해졌다.
TLS 1.3 통합(보안 강화) : HTTP/2에서는 TLS 가 별도로 적용되었지만, HTTP/3에서는 QUIC에 내장되어 보안 연결을 더 빠르고 강력하게 제공하였다.
모바일 네트워크 환경 최적화 : TCP 기반의 HTTP/2는 wifi에서 LTE로 전환 시 연결이 끊어졌지만, QUIC 기반의 HTTP/3.0은 IP가 바뀌어도 연결을 유지 할 수 있어 모바일 환경에서는 더 안정적이다.

=> 기본적으로 HTTP/2.0을 사용하고, HTTP/3은 선택적으로 적용하는 경우가 많다.
(참고) UDP는 연결 상태를 확인하지 않고 데이터를 주고 받기 때문에 공격자가 DDoS 공격을 할 수 있다.
특히, UDP는 작은 요청으로 큰 트래픽을 발생시켜서 서버를 마비를 시킬 수도 있다. 그렇기에 기업이나 ISP는 이러한 UDP 기반 공격을 막기 위해 UDP 443 기본적으로 차단하는 경우가 많은데 이렇게 되면 HTTP/3 트래픽이 차단된다.

구글에서 F12에서 프로토콜 확인하면 http/3.0을 사용하는 것을 볼 수 있다.

1.3. 네트워크의 기본은 TCP/IP

1️⃣ 좁은 의미: TCP와 IP 두 개의 프로토콜만을 가리킬 때
2️⃣ 넓은 의미: IP를 사용하는 모든 네트워크 관련 프로토콜을 포함하는 "프로토콜 집합(Protocol Suite)"

TCP/IP는 계층(Layer)별로 분리되어 있기 때문에, 특정 계층만 수정해도 전체 시스템을 바꾸지 않아도 된다.

🔹 예시 1: 네트워크 인터페이스(물리적 전송) 변경

TCP/IP는 네트워크 인터페이스 계층이 분리되어 있기 때문에, Wi-Fi로 바뀌어도 응용 계층(웹, 이메일)에는 영향을 주지 않음.

🔹 예시 2: IP 주소 체계 변경 (IPv4 → IPv6)

인터넷 계층에서 IP 프로토콜만 변경하면 되므로, 웹사이트(HTTP)나 이메일(SMTP) 같은 상위 계층은 그대로 사용 가능.

🔹 예시 3: 웹 통신 방식 변경 (HTTP → HTTPS)

전송 계층(TCP) 이하에서는 변경 없이, 응용 계층(HTTP)만 HTTPS로 변경하면 됨

계층	주요 프로토콜	역할
4️⃣ -Application Layer	HTTP,FTP,SMTP,DNS	사용자가 직접 사용하는 서비스 제공
3️⃣-Transport Layer	TCP, UDP	신뢰성 있는 데이터 전송 TCP: 데이터 재전송 기능으로 신뢰성 있는 통신 제공 (ex. 이메일, 파일 다운로드) UDP : 빠른 전송이 필요하지만 신뢰성이 낮음 (ex. 웹 회의, 동영상 스트리밍) (ex. 웹회의, 동영상 사이트의 영상)
2️⃣-Network Layer or Internet Layer	IP, ICMP, ARP	패킷을 목적지까지 전달 (라우팅) 「IP」를 이용해, ICMP는 에러 리포트나 진단 기능으로, ARP는 IP 주소로부터 MAC 주소를 요구하기 때문에 등의 보좌적인 프로토콜
1️⃣-Link Layer or Network Interface Layer	Ethernet, Wi-Fi, PPP	물리적인 데이터 전송

ex. "www.naver.com"
1️⃣ 링크 계층 (Link Layer)

네트워크 인터페이스 카드(NIC)가 데이터를 **전기 신호(Wi-Fi, 유선)**로 변환하여 전송
물리적인 전송을 담당

2️⃣ 네트워크 계층 (Network Layer)

패킷에 발신자(내 컴퓨터) & 수신자(네이버 서버) IP 주소 추가
목적지까지 최적의 경로(라우팅)를 결정

3️⃣ 전송 계층 (Transport Layer)

TCP 프로토콜이 데이터를 패킷 단위로 분할
패킷의 순서 정보 & 오류 검사 정보를 추가

4️⃣ 응용 계층 (Application Layer)

DNS 서버에 네이버의 IP 주소(223.130.195.200) 조회
HTTP 프로토콜이 GET 요청 생성하여 네이버 서버로 전송

--캡슐레이션
1. 애플리케이션 계층 (L7, HTTP)
   ┌───────────────────────────────────────┐
   │ GET /index.html HTTP/1.1              │
   │ Host: example.com                      │
   │ User-Agent: Mozilla/5.0                │
   └───────────────────────────────────────┘
                ↓ 캡슐화 (Encapsulation)
2. 전송 계층 (L4, TCP)
   ┌──────────────┬────────────────────────┐
   │ TCP Header   │ HTTP Request Data       │
   └──────────────┴────────────────────────┘
                ↓ 캡슐화
3. 네트워크 계층 (L3, IP)
   ┌──────────┬──────────────┬────────────────────────┐
   │ IP Header│ TCP Header   │ HTTP Request Data       │
   └──────────┴──────────────┴────────────────────────┘
                ↓ 캡슐화
4. 데이터 링크 계층 (L2, Ethernet)
   ┌───────────────┬──────────┬──────────────┬────────────────────────┐
   │ Ethernet Header │ IP Header │ TCP Header  │ HTTP Request Data       │
   └───────────────┴──────────┴──────────────┴────────────────────────┘


--언캡슐레이션
1. 데이터 링크 계층 (L2, Ethernet)
   ┌───────────────┬──────────┬──────────────┬────────────────────────┐
   │ Ethernet Header │ IP Header │ TCP Header  │ HTTP Request Data       │
   └───────────────┴──────────┴──────────────┴────────────────────────┘
                ↓ 언캡슐화 (Decapsulation) - Ethernet Header 제거
2. 네트워크 계층 (L3, IP)
   ┌──────────┬──────────────┬────────────────────────┐
   │ IP Header│ TCP Header   │ HTTP Request Data       │
   └──────────┴──────────────┴────────────────────────┘
                ↓ 언캡슐화 - IP Header 제거
3. 전송 계층 (L4, TCP)
   ┌──────────────┬────────────────────────┐
   │ TCP Header   │ HTTP Request Data       │
   └──────────────┴────────────────────────┘
                ↓ 언캡슐화 - TCP Header 제거
4. 애플리케이션 계층 (L7, HTTP)
   ┌───────────────────────────────────────┐
   │ GET /index.html HTTP/1.1              │
   │ Host: example.com                      │
   │ User-Agent: Mozilla/5.0                │
   └───────────────────────────────────────┘

https://velog.io/@conatuseus/2019-09-10-2009-작성됨-xsk0ds2eqf

1.4. HTTP와 관계가 깊은 프로토콜은 IP/TCP/DNS

1️⃣ IP

역할: 인터넷에서 데이터를 패킷 단위로 목적지까지 전달하는 기능
핵심 요소: IP 주소, MAC 주소
- IP 주소: 각 노드(장치)에 부여된 네트워크 주소
- MAC 주소: 각 네트워크 카드(NIC)에 할당된 고유 주소

💡 ARP (Address Resolution Protocol)의 역할

IP 주소를 MAC 주소로 변환하는 프로토콜
네트워크에서 "이 IP 주소를 가진 장치의 MAC 주소는 무엇인가?"를 물어보는 역할

예제 시나리오: PC가 라우터에 데이터를 보낼 때

PC는 라우터의 IP 주소(192.168.1.1)를 알고 있지만, MAC 주소는 모른다.
PC는 "이 IP 주소(192.168.1.1)를 가진 MAC 주소를 알고 싶어!" 라고 ARP 요청을 보낸다. (브로드캐스트)
라우터가 자신의 MAC 주소를 ARP 응답으로 보낸다.
→ "나는 192.168.1.1이고, 내 MAC 주소는 AA:BB:CC:DD:EE:FF야!"
PC는 이 정보를 캐시(저장)하고, 이후부터는 직접 MAC 주소를 이용해 패킷을 보낸다.

2️⃣ TCP (Transmission Control Protocol)

역할: 데이터 전송의 신뢰성을 보장
특징: 패킷이 손실되지 않고 순서대로 전달되도록 보장

💡 라우팅 과정

IP 패킷은 다음과 같은 경로를 따라 이동함
→ 가까운 라우터 → 중간 라우터 → 최종 목적지 라우터 → 목적지 서버

💡 TCP가 필요한 이유

IP는 패킷을 목적지까지 전달하는 기능은 있지만,
패킷이 도착할지, 중간에 유실될지, 순서가 맞게 도착할지 보장하지 않음.
따라서 TCP가 이를 보완하여 신뢰성을 보장함.

💡 TCP의 핵심 개념
✅ 1) 바이트 스트림 서비스 (Byte Stream Service)
✔ TCP는 데이터를 바이트 스트림 형태로 다룸

바이트 스트림이란?
→ 애플리케이션에서 보낸 데이터를 연속된 바이트 형태로 전송하는 방식
패킷 단위가 아니라 바이트 단위로 전송하므로,
→ 수신 측에서는 올바른 순서로 조립 가능

✔ TCP는 바이트 스트림을 패킷 단위로 나누어 전송

전송 중 손실되거나 순서가 뒤바뀐 패킷을 재전송하여 원래 순서대로 복구

📌 비교: UDP는 바이트 스트림이 아니라 개별 패킷 단위로 처리

✅ 연결전
2) TCP 3-웨이 핸드셰이크 (Three-Way Handshake)
✔ 연결을 안전하게 맺기 위한 3단계 과정
✔ TCP는 신뢰성을 보장해야 하므로 송·수신 측이 연결을 맺기 전에 서로 통신 준비가 완료되었는지 확인하는 과정
✔ 3단계 연결 과정 => 패킷이 유실되거나 네트워크 문제로 인해 불완전한 연결을 방지하기 위해서

1️⃣ 클라이언트 → 서버 (SYN) : 클라이언트가 서버에게 연결 요청(SYN 패킷)을 보냄
2️⃣ 서버 → 클라이언트 (SYN + ACK) : 서버가 연결 요청을 수락하고 SYN + ACK 패킷을 응답
3️⃣ 클라이언트 → 서버 (ACK) : 클라이언트가 마지막으로 ACK 패킷을 보내고 연결 완료

✅ TCP 연결 종료
3) TCP 4-웨이 핸드셰이크 (Four-Way Handshake) => 클라이언트와 서버가 각자 독립적으로 데이터를 다 보내고 종료하기 위해서
✔ 연결 종료 시 4단계 과정 진행

1️⃣ 클라이언트 → 서버 (FIN) : "연결 종료 요청"
2️⃣ 서버 → 클라이언트 (ACK) : "확인"
3️⃣ 서버 → 클라이언트 (FIN) : "나도 종료할게"
4️⃣ 클라이언트 → 서버 (ACK) : "확인" → 연결 종료

✅ 4) TCP 윈도우 크기(Window Size) 와 흐름제어(Flow Control)
✔ 송신 측(데이터 보내는 쪽)이 너무 빠르게 데이터를 보내면, 수신 측(데이터 받는 쪽)이 처리하지 못하고 버퍼가 넘칠 수 있음.
✔ 흐름 제어(Flow Control)는 송신 측이 수신 측의 데이터 처리 속도에 맞춰 전송 속도를 조절하는 기법

🔹Stop and Wait
- 매번 전송한 패킷에 대해 확인 응답(ACK)를 받으면 다음 패킷을 전송하는 방법.(비효율적)

https://velog.io/@yuseogi0218/TCPIP-흐름-제어-혼잡-제어

🔹Sliding Window
✔ 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답(ACK) 없이 패킷을 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어 기법
✔ 송신 측과 수신 측은 ‘윈도우(Window)’라는 개념을 사용하여 데이터를 관리함.
✔ 윈도우 크기(Window Size)는 수신 측이 한 번에 받을 수 있는 최대 데이터 크기를 의미함.
✔ 송신 측은 ACK을 받기 전까지 윈도우 크기만큼 데이터를 보낼 수 있음.
📌 윈도우 크기는 가변적이며, 네트워크 상태와 수신 측의 처리 속도에 따라 조절됨.

1️⃣ 초기 상태 : 수신 측이 윈도우 크기 = 4KB라고 응답.송신 측은 한 번에 4KB까지 데이터 전송 가능.
2️⃣ 데이터 전송 후 ACK 대기 : 송신 측이 4KB 데이터를 전송하고, 수신 측의 응답(ACK)을 기다림.
3️⃣ ACK 수신 및 윈도우 크기 갱신 :
수신 측이 3KB를 처리하고 ACK을 보냄.
동시에 남은 수신 버퍼(윈도우 크기)를 3KB로 업데이트.
송신 측은 새로운 윈도우 크기에 맞춰 추가 데이터 전송.

✅ 5) TCP 혼잡 제어(Flow Control)

1.5. 이름 해결을 담당하는 DNS

DNS는 **도메인 네임 시스템(Domain Name System)**의 약자로, 사람이 이해하기 쉬운 도메인 이름(예: google.com)을 컴퓨터가 이해할 수 있는 IP 주소(예: 142.250.191.46)로 변환하는 시스템이다.

🔹 DNS 필요한 이유
✔ 인터넷에서는 모든 장치가 IP 주소를 사용하여 서로 통신한다.
✔ 하지만 숫자로 된 IP 주소를 직접 외우고 입력하는 것은 불편하기에,
따라서 DNS를 이용해 사람이 친숙한 도메인 이름을 입력하면, 이를 자동으로 해당 IP 주소로 변환해줍니다.

🔹 DNS의 포트 번호
DNS는 UDP 53번포트와 TCP 53번 포트를 사용한다.
대부분의 일반적인 조회는 UDP 의 53번 포트를 사용하여 빠르게 데이터를 처리한다.
만약, 응답 크기가 512바이트를 초과하는 응답이 필요한 경우에는 TCP 53번 포트로 전환해서 보낸다.
또, UDP가 차단되거나 실패한 경우에도 TCP 가 사용될 수 있다.

🔹 DNS 동작 과정
1️⃣ END user : 사용자가 www.example.com 입력
2️⃣ DNS Resolver 요청 : 브라우저 캐시와 운영체제(OS) 캐시에 DNS 정보가 없으면, 요청이 ISP의 DNS Resolver로 전달
3️⃣ Root Name Server 질의 : DNS Resolver가 루트 네임서버에 .com 도메인 정보를 요청
4️⃣ TLD Name Server 질의: 루트 네임서버가 .com TLD 네임서버의 위치를 알려주고, Resolver는 TLD 네임서버에 다시 질의
5️⃣ Authoritative Name Server 질의: TLD 네임서버가 권한 네임서버(Route 53 Name Server)로 안내하며, Resolver는 최종적으로 권한 네임서버에 요청
6️⃣ IP 주소 반환: 권한 네임서버가 요청받은 도메인의 IP 주소(192.0.2.44)를 반환
7️⃣ Resolver가 IP 주소 반환: Resolver가 최종적으로 사용자의 브라우저에 IP 주소를 반환
8️⃣ 웹 서버 요청: 브라우저는 반환받은 IP 주소를 사용하여 웹 서버에 연결
9️⃣ 웹 페이지 표시: 웹 서버가 요청받은 페이지 데이터를 반환하고, 사용자는 웹 페이지 사용

1. 사용자 → 브라우저 캐시 확인 → OS 캐시 확인 → ISP의 DNS Resolver
2. Resolver → 루트 네임서버 → TLD 네임서버 → 권한 네임서버
3. 권한 네임서버 → 최종 IP 반환 → 브라우저 → 웹 서버 접속 → 웹 페이지 표시

https://aws.amazon.com/ko/route53/what-is-dns/

🔹 DNS 서버
DNS 서버 분리한 이유
✔ 효율적이고 빠른 데이터 처리
✔ 확장성과 분산 구조로 안정성 보장
✔ 보안 및 관리 책임 분리

재귀적 DNS 서버	사용자의 요청을 받아 최종 IP 주소를 찾음 (ISP 또는 공용 DNS)
루트 네임서버	최상위 DNS 서버, .com, .kr 등의 TLD 네임서버 정보를 제공 (ex .과학섹션은 2층에 있습니다 )
TLD 네임서버	.com, .net, .kr 등 최상위 도메인의 네임서버 정보 제공 (ex. 물리학 코너는 저쪽입니다 )
권한 네임서버	최종 IP 주소 정보를 관리하는 서버 (google.com의 DNS 서버 등) ( ex. 원하시는 책은 저쪽입니다 )

🔹 DNS 캐싱
✔ DNS 응답 속도를 빠르게 하기 위해 캐싱을 사용한다.
✔ 같은 도메인에 대한 요청이 반복될 경우, 이전 조회 결과를 저장하여 불필요한 조회를 줄인다.

방화벽 연결 확인할때.(사이트 접속가능한지 확인할떄)
=> ICMP Echo Request 패킷을 전송하여 응답(Echo Reply)을 받으면 통신이 가능함. ICMP 패킷 차단 여부 확인 가능
웹 사이트가 ping에 응답하는지 확인하려면 명령 프롬프트를 열고 “ping <웹사이트 이름>”을 입력합니다.
예를 들어, google.com의 D 설정을 확인하려면 “ping google.com”을 입력하면 됩니다. 이렇게 하면 웹사이트의 응답 시간과 호스트 이름을 IP 주소로 변환하는 데 걸린 시간에 대한 정보가 반환

1.6. 각각과 HTTP와의 관계

📌 최종 요약 (단계별 역할 포함)
1️⃣ URL 입력 : 브라우저가 HTTP 요청을 생성
2️⃣ DNS 조회 : 도메인(hack.jp) → IP(192.168.10.20) 변환
3️⃣ TCP 연결 : TCP 3-way Handshake로 연결 구축
4️⃣ TCP 데이터 쪼개기 : HTTP 요청을 여러 개의 패킷으로 나눔
5️⃣ IP 패킷 전달 : 패킷을 목적지로 보냄
6️⃣ 라우터 : IP 주소 기반으로 최적의 경로를 찾아 패킷 전달
7️⃣ 서버 도착 → TCP 재조립: 패킷을 원래의 HTTP 요청으로 복원

1.7 URI와 URL

✔ URI(Unidform Resource Indentifier,통합자원 식별자)는 리소스를 식별하는 모든 문자열을 의미
✔ URL과 URN을 포함하는 개념으로, 웹 주소뿐만 아니라 고유 식별자도 포함됨.
✔ URI = 어떤 리소스를 가리키는 모든 문자열
✔ URL = 리소스의 위치를 나타내는 문자열
✔ URN = 리소스의 고유한 이름 (위치 정보 없음)

https://velog.io/@octoberjin11/Network-URI와-URL의-차이점

🔹 URI, URL, URN 비교 예시

예제	URI	URL	URN	설명
https://www.example.com/index.html	✅	✅	❌	웹페이지의 위치 (URL)
ftp://files.example.com/download.zip	✅	✅	❌	파일 다운로드 주소 (URL)
urn:isbn:978-3-16-148410-0	✅	❌	✅	ISBN 코드 (URN)
urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8	✅	❌	✅	UUID (URN, 고유 식별자)
mailto:user@example.com	✅	❌	❌	이메일 주소 (URL도 URN도 아님)
tel:+1-800-555-0199	✅	❌	❌	전화번호 (위치 X, 고유 식별자 X)
sms:+1-800-555-0199	✅	❌	❌	문자 전송 (위치 X, 고유 식별자 X)
data:text/plain;base64,SGVsbG8gd29ybGQ=	✅	❌	❌	인라인 데이터 (위치 X, 고유 이름 X)

🔹 URL 포맷

구성 요소	의미	예시
Scheme (스키마, 프로토콜)	프로토콜 (어떤 방식으로 접근할지)	http://, https://, ftp://, file://
UserInfo (사용자 정보, 선택적)	사용자 인증 정보 (아이디, 비밀번호) 보안 문제로 인해, HTTP URL에서는 거의 사용되지 않음	✔ user:password@ 부분이 사용자 인증 정보
Host (호스트, 도메인 or IP)	요청을 보낼 대상 서버	✔ 도메인 사용 → www.google.com ✔ IP 주소 사용 → 192.168.1.1 ✔ 로컬 서버 사용 → localhost www.google.com, 192.168.1.1
Port (포트 번호, 선택적)	서비스가 실행되는 네트워크 포트	✔ HTTP 기본 포트 → :80 (생략 가능) ✔ HTTPS 기본 포트 → :443 (생략 가능) ✔ 사용자 지정 포트 → :8080, :3000 등
Path (경로)	서버 내 리소스 위치	✔ /index.html → 홈페이지 ✔ /images/logo.png → 특정 이미지 파일
Query String (쿼리 문자열, 선택적)	추가적인 데이터 전달 (?key=value 형식)	✔ ?q=chatgpt → 검색어 전달 ✔ ?id=123&category=books → 상품 ID와 카테고리 전달
Fragment (프래그먼트, 선택적)	문서 내 특정 위치 지정	✔ #section1 → 페이지 내 section1으로 이동 ✔ #heading → 특정 제목으로 이동

🔹 HTTPS가 해결하는 보안 문제

✔ HTTPS(HyperText Transfer Protocol Secure)는 HTTP + 보안(SSL/TLS) 기능이 추가된 버전
✔ SSL/TLS(보안 프로토콜)을 사용하여 데이터를 암호화하고, 인증 및 무결성을 보장