6주차 웹, 네트워크

학습 목표

인터넷과 웹의 차이를 설명할 수 있다.
IP 주소, 포트, 소켓이 어떤 역할을 하는지 이해한다.
HTTP 요청과 응답의 구조를 설명할 수 있다.
HTTPS가 HTTP와 무엇이 다른지 이해한다.
쿠키와 세션의 차이, 사용 목적, 보안 설정을 설명할 수 있다.

네트워크, 인터넷, 웹

네트워크

네트워크는 여러 컴퓨터와 장치를 연결해 데이터를 주고받는 통신망이다. 스마트폰과 무선 이어폰을 연결하는 작은 네트워크부터 국가와 대륙을 연결하는 광역 네트워크까지 모두 네트워크에 포함된다. OSI 7계층 모델

PAN (Personal Area Network): 개인 주변의 장치를 연결하는 네트워크
- 예: 스마트폰, 블루투스 이어폰, 스마트워치
LAN (Local Area Network): 가정, 학교, 사무실 등 제한된 공간을 연결하는 근거리 네트워크
- 예: 같은 건물의 컴퓨터와 프린터
MAN (Metropolitan Area Network): 도시와 같이 LAN보다 넓은 지역을 연결하는 네트워크
WAN (Wide Area Network): 멀리 떨어진 LAN들을 연결하는 광역 네트워크
- 예: 인터넷

인터넷과 웹

인터넷은 서로 다른 네트워크들이 연결된 거대한 네트워크다. 반면 웹(World Wide Web, WWW)은 인터넷 위에서 동작하는 여러 서비스 중 하나다.

인터넷: 컴퓨터와 네트워크를 연결하는 기반 시설
웹: 인터넷을 통해 문서, 이미지, 영상 등의 정보를 주고받는 서비스
웹 브라우저: 사용자의 요청을 보내고 서버의 응답을 화면에 표시하는 프로그램
웹 서버: 브라우저의 요청을 받아 필요한 문서나 데이터를 응답하는 프로그램 또는 시스템 웹 외에도 이메일, 파일 전송, 온라인 게임 등 다양한 서비스가 인터넷 위에서 동작한다.

IP 주소와 포트

IP 주소

IP 주소는 네트워크에서 장치를 식별하기 위한 주소다. IPv4는 32비트 주소이며, 일반적으로 192.168.0.1처럼 네 개의 10진수로 표현한다. IPv6는 주소 부족 문제를 해결하기 위해 도입된 128비트 주소 체계다.

공인 IP: 인터넷에서 장치를 식별하기 위해 사용되는 주소
사설 IP: 공유기 내부와 같은 사설 네트워크에서 사용하는 주소
- 예: 192.168.0.0/16, 10.0.0.0/8
루프백 주소: 자기 자신을 가리키는 주소
- 대표적으로 127.0.0.1
0.0.0.0: 서버가 모든 네트워크 인터페이스에서 들어오는 요청을 받도록 바인딩할 때 사용하는 특별한 주소 사설 IP를 가진 장치가 인터넷과 통신할 수 있는 이유는 공유기의 NAT(Network Address Translation)가 내부 주소와 공인 주소를 변환해 주기 때문이다.

포트 번호

IP 주소가 통신할 장치를 식별한다면, 포트 번호는 그 장치에서 통신할 프로그램 또는 프로세스를 식별한다. 하나의 컴퓨터에서 웹 서버, 데이터베이스, SSH 서버 등이 동시에 실행될 수 있는 이유도 포트로 통신 대상을 구분하기 때문이다.

HTTP: 일반적으로 80번
HTTPS: 일반적으로 443번
개발용 Spring Boot 서버: 흔히 8080번 포트 번호는 서비스의 기본값일 뿐, 반드시 해당 번호만 사용해야 하는 것은 아니다.

소켓(Socket)

소켓은 네트워크 통신의 끝점(endpoint)을 표현하는 개념이며, 프로그램이 TCP 또는 UDP 통신을 사용할 수 있도록 제공되는 API이기도 하다. 통신 대상은 일반적으로 다음 정보로 구분한다. IP 주소 + 포트 번호 + 프로토콜

TCP와 UDP

TCP
- 연결을 맺은 뒤 데이터를 주고받는다.
- 데이터의 순서와 전달을 보장하며, 손실된 데이터를 재전송한다.
- 웹, 파일 전송, 데이터베이스 통신 등 신뢰성이 중요한 경우에 많이 사용한다.
UDP
- 연결 설정 없이 데이터를 전송한다.
- TCP보다 단순하고 빠를 수 있지만 순서와 전달을 보장하지 않는다.
- 실시간 스트리밍, 온라인 게임, DNS 등 지연 시간이 중요한 경우에 사용한다. 서버는 특정 IP와 포트를 bind한 뒤 listen하며 클라이언트의 연결을 기다린다. 클라이언트는 서버의 IP와 포트를 사용해 connect한다. 실제 웹 애플리케이션에서는 웹 서버나 애플리케이션 서버가 소켓 처리를 담당하므로 개발자는 주로 HTTP 요청을 처리하는 비즈니스 로직에 집중한다. Spring Boot에서는 다음과 같이 서버의 바인딩 주소와 포트를 설정할 수 있다.

server.address=0.0.0.0
server.port=8080

소켓은 연결과 데이터 전달 환경을 제공하지만, 그 위에서 어떤 형식으로 데이터를 주고받을지는 애플리케이션 프로토콜이 정한다. HTTP는 소켓 위에서 동작하는 대표적인 애플리케이션 계층 프로토콜이다.

HTTP

HTTP(HyperText Transfer Protocol)는 클라이언트와 서버가 웹 리소스를 주고받기 위한 애플리케이션 계층 프로토콜이다. HTTP 요청과 응답 흐름

HTTP의 기본 특징

클라이언트-서버 구조
- 클라이언트가 요청을 보내고 서버가 응답한다.
무상태성(Stateless)
- 각 요청은 독립적으로 처리된다.
- 서버는 기본적으로 이전 요청을 기억하지 않는다.
확장 가능한 메시지 구조
- 메서드, 헤더, 상태 코드, 본문 등을 이용해 다양한 정보를 전달한다. 무상태성 덕분에 서버를 여러 대로 확장하기 쉽지만, 로그인 상태처럼 요청 사이에 유지해야 하는 정보는 쿠키, 세션, 토큰 등의 별도 수단이 필요하다.

HTTP 요청

HTTP 요청은 보통 다음 요소로 구성된다.

메서드: 어떤 작업을 원하는지 표현한다.
URL: 대상 리소스의 위치를 나타낸다.
헤더: 요청에 대한 부가 정보를 전달한다.
본문(Body): 서버에 전달할 데이터를 담는다. 주요 메서드는 다음과 같다.

메서드	의미	특징
GET	리소스 조회	일반적으로 본문 없이 요청하며, 안전한 메서드로 취급한다.
POST	리소스 생성 또는 처리 요청	본문에 데이터를 담아 전송한다.
PUT	리소스 전체 수정	같은 요청을 여러 번 보내도 결과가 같도록 설계하는 경우가 많다.
PATCH	리소스 일부 수정	변경할 필드만 전달한다.
DELETE	리소스 삭제	대상 리소스를 삭제한다.

HTTP 응답

서버 응답은 상태 코드로 처리 결과를 알려준다. HTTP 상태 코드 분류

2xx 성공
- 200 OK: 요청 성공
- 201 Created: 리소스 생성 성공
- 204 No Content: 성공했지만 응답 본문이 없음
3xx 리다이렉션
- 301 Moved Permanently: 영구 이동
- 302 Found: 임시 이동
- 304 Not Modified: 캐시된 리소스를 사용해도 됨
4xx 클라이언트 오류
- 400 Bad Request: 요청 형식이 잘못됨
- 401 Unauthorized: 인증이 필요하거나 인증에 실패함
- 403 Forbidden: 인증은 되었지만 권한이 없음
- 404 Not Found: 리소스를 찾을 수 없음
5xx 서버 오류
- 500 Internal Server Error: 서버 내부 오류
- 502 Bad Gateway: 중간 서버가 잘못된 응답을 받음
- 503 Service Unavailable: 서버가 일시적으로 요청을 처리할 수 없음

HTTP 요청 예시

GET /members/1 HTTP/1.1
Host: example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
{"id":1,"name":"Kim"}

HTTP/1.1에서는 하나의 TCP 연결에서 요청과 응답이 순서대로 처리되는 방식이 기본이었다. HTTP/2는 하나의 연결에서 여러 스트림을 동시에 처리할 수 있도록 개선했고, HTTP/3는 UDP 기반의 QUIC을 사용한다. 다만 이 글의 핵심인 쿠키와 세션은 HTTP 버전과 관계없이 이해할 수 있다.

HTTPS

HTTPS(HTTP Secure)는 HTTP 메시지를 TLS(Transport Layer Security)로 보호해 전송하는 방식이다. HTTPS는 별도의 애플리케이션 프로토콜이라기보다 HTTP를 TLS 위에서 사용하는 구조라고 이해하면 된다. TLS 핸드셰이크 흐름

HTTPS가 제공하는 것

기밀성: 통신 내용을 제3자가 쉽게 읽지 못한다.
무결성: 전송 중 데이터가 변조되었는지 확인할 수 있다.
서버 인증: 인증서를 통해 접속한 서버가 신뢰할 수 있는 서버인지 확인한다.

HTTPS 통신 흐름

브라우저가 서버에 HTTPS 연결을 요청한다.
서버가 인증서와 암호화에 사용할 정보를 전달한다.
브라우저는 인증서의 유효 기간, 발급 기관, 접속한 도메인 등을 검증한다.
클라이언트와 서버가 세션 키를 협의한다.
이후 HTTP 요청과 응답은 협의한 키를 사용해 암호화된다. 실제 TLS 협상 방식은 TLS 버전에 따라 다르지만, 핵심은 공개키 암호화 등을 이용해 안전하게 대칭키를 협의한 뒤 실제 데이터는 대칭키로 빠르게 암호화한다는 점이다. HTTPS를 사용해도 서버 애플리케이션의 취약점, 잘못된 권한 검사, XSS·CSRF 같은 웹 취약점까지 자동으로 해결되지는 않는다. 전송 구간을 보호하는 것과 애플리케이션 자체를 안전하게 만드는 것은 별개의 문제다.

쿠키(Cookie)

쿠키는 서버가 브라우저에 저장하도록 전달하는 작은 데이터 조각이다. 브라우저는 이후 조건에 맞는 요청을 보낼 때 쿠키를 함께 전송한다. Cookie-based session flow 대표적인 용도는 다음과 같다.

로그인 상태 유지
사용자 식별
장바구니 저장
사용자 설정 저장
분석 및 추적

쿠키의 동작

서버가 응답 헤더에 Set-Cookie를 포함해 보낸다.
브라우저가 쿠키를 저장한다.
이후 도메인, 경로 등의 조건에 맞는 요청에 Cookie 헤더를 포함한다.
서버는 쿠키의 값을 읽어 사용한다.

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

이후 브라우저가 보내는 요청은 다음과 같은 형태가 된다.

GET /mypage HTTP/1.1
Host: example.com
Cookie: sessionId=abc123

주요 쿠키 속성

Domain: 쿠키를 전송할 도메인 범위
Path: 쿠키를 전송할 URL 경로 범위
Expires / Max-Age: 쿠키의 만료 시점
Secure: HTTPS 연결에서만 전송
HttpOnly: 자바스크립트의 document.cookie로 읽지 못하게 함
SameSite: 다른 사이트에서 발생한 요청에 쿠키를 보낼지 제어
- Strict: 동일 사이트 요청에만 전송
- Lax: 일부 안전한 교차 사이트 요청에는 전송
- None: 교차 사이트 요청에도 전송하며, 일반적으로 Secure가 필요 쿠키는 브라우저에 저장되므로 민감한 개인정보나 비밀번호 자체를 넣기보다, 의미를 알 수 없는 식별자만 저장하는 것이 안전하다. 또한 쿠키는 요청마다 자동으로 전송될 수 있어 크기를 작게 유지해야 한다.

세션(Session)

세션은 로그인과 같이 여러 HTTP 요청에 걸쳐 유지해야 하는 상태를 서버 측에서 관리하는 방식이다. 일반적인 흐름은 다음과 같다.

사용자가 로그인 요청을 보낸다.
서버가 사용자를 인증한다.
서버가 세션을 생성하고 서버 저장소에 사용자 정보를 저장한다.
서버가 세션 ID를 쿠키로 내려준다.
브라우저는 이후 요청마다 세션 ID 쿠키를 전송한다.
서버는 세션 ID로 저장된 사용자 정보를 조회한다. 세션 ID 자체에는 보통 사용자의 모든 정보가 들어 있지 않고, 서버 저장소를 찾기 위한 식별자 역할만 한다. 서버는 세션을 메모리, 데이터베이스, Redis 같은 외부 저장소에 보관할 수 있다.

세션의 장단점

장점:

중요한 사용자 상태를 서버가 관리할 수 있다.
클라이언트에 저장되는 정보가 상대적으로 적다.
서버에서 세션을 삭제하거나 만료시켜 로그아웃을 통제하기 쉽다. 단점:
서버가 세션 저장소를 관리해야 한다.
서버가 여러 대라면 세션 공유 전략이 필요하다.
- 세션 저장소 공유
- 세션 고정(Session Affinity)
- 세션 복제
세션 ID가 탈취되면 공격자가 로그인한 사용자처럼 행동할 수 있다.

쿠키와 세션 비교

구분	쿠키	세션
주 저장 위치	브라우저	서버
주요 역할	데이터를 저장하거나 식별자 전달	사용자 상태를 서버에서 관리
전송 방식	조건에 맞는 요청마다 자동 전송	세션 ID를 쿠키 등으로 전송
보안 책임	브라우저에 저장되므로 노출에 주의	세션 ID 탈취와 서버 저장소 보호에 주의
서버 확장	상태가 없거나 작으면 비교적 쉬움	여러 서버가 세션을 공유해야 할 수 있음
만료	쿠키 만료 정책에 따름	서버의 세션 만료 정책에도 영향을 받음

“세션은 쿠키와 반대되는 개념”이라고 이해하면 정확하지 않다. 실무에서 세션 ID를 쿠키에 저장하는 경우가 많기 때문에, 쿠키는 세션을 식별하기 위한 전달 수단으로 함께 사용될 수 있다.

인증, 인가, 상태 유지

인증(Authentication): 사용자가 누구인지 확인하는 과정
인가(Authorization): 인증된 사용자가 어떤 작업을 할 수 있는지 확인하는 과정
상태 유지: 여러 HTTP 요청 사이에서 사용자 정보를 연결하는 과정 예를 들어 로그인은 인증이고, 관리자 페이지 접근 권한 확인은 인가다. 로그인 이후에도 요청마다 사용자를 식별해야 하므로 쿠키와 세션 또는 토큰이 사용된다.

보안 체크리스트

로그인 세션 쿠키에는 Secure, HttpOnly, SameSite 설정을 검토한다.
로그인 성공 시 세션 ID를 새로 발급해 세션 고정 공격을 방지한다.
로그아웃 시 서버의 세션을 만료시키고 필요하면 쿠키도 삭제한다.
세션 ID와 인증 토큰을 URL 쿼리스트링에 넣지 않는다.
HTTPS를 사용해 네트워크 구간에서 쿠키와 인증 정보를 보호한다.
쿠키에 비밀번호나 주민등록번호 같은 민감한 원문 정보를 저장하지 않는다.
HttpOnly는 XSS 자체를 막는 기능이 아니라, 자바스크립트가 쿠키를 직접 읽는 것을 어렵게 하는 설정이다.
SameSite는 CSRF 위험을 줄이는 데 도움을 주지만, 모든 CSRF 방어를 대신하지는 않는다.

핵심 흐름

브라우저
	└─ HTTPS 요청
		├─ 요청 메서드, URL, 헤더, 본문
		└─ Cookie: sessionId=...
웹 서버 / 애플리케이션 서버
	├─ TLS로 보호된 요청 복호화
	├─ 쿠키에서 세션 ID 확인
	├─ 세션 저장소에서 사용자 정보 조회
	├─ 인증·인가 처리
	└─ HTTP 응답 반환