[7주차] IP + HTTP & HTTPS + TLS/SSL + 쿠키 & 세션

• IP
• HTTP & HTTPS
• HTTP 응답 코드
• SSL과 TLS의 차이점
• DNS에 대한 설명
• 쿠키 & 세션
• www.github.com을 브라우저에 입력하고 엔터를 쳤을 때, 네트워크 상 어떤 일이 일어나는지 최대한 자세하게 설명해 주세요.

---

🔵 IP

IP 주소의 개념과 기능

IP 주소는 인터넷에 연결된 각 기기를 구별하기 위해 사용되는 고유한 번호이다.

IP는 프로토콜 그 자체이고 IP주소는 IP통신을 하기 위해 각 기기들을 구분하는 고유번호라고 이해하면 된다.

IP 주소는 네트워크 내에서 특정 기기를 찾아 데이터를 전송할 수 있도록 도와주며, 기기들이 서로 통신할 때 필수적인 요소이다.

IP 주소는 32비트 숫자로 구성되며, 보통 점 표기법으로 작성된다(예: 73.227.130.85). 점 사이의 숫자를 옥텟(8비트)이라고 한다.

IP 주소 클래스

IP 주소를 과거에는 클래스 기반 방식으로 분류했으며, 현재는 CIDR 방식이 쓰인다.

클래스	시작 주소 범위	네트워크/호스트 비트	개수 용도
A	0.0.0.0 ~ 127.255.255.255	8비트 네트워크 / 24비트 호스트	대규모 (기업용)
B	128.0.0.0 ~ 191.255.255.255	16비트 네트워크 / 16비트 호스트	중규모
C	192.0.0.0 ~ 223.255.255.255	24비트 네트워크 / 8비트 호스트	소규모
D	224.0.0.0 ~ 239.255.255.255	멀티캐스트용
E	240.0.0.0 ~ 255.255.255.255	실험용, 예약됨

CIDR

고정된 IP 클래스 대신, 가변 길이의 서브넷 마스크를 사용할 수 있게 만든 IP 주소 표기 방식이다.

과거 클래스 기반에서는 IP 자원의 비효율적 사용이 발생하였으며, CIDR 도입 이후에 필요에 따라 네트워크 크기를 세분화하여 할당 가능하게 되었다.

예) 192.168.10.0/24

192.168.10.0 -> 네트워크 주소

/24 -> 앞 24비트는 **네트워크 식별**, 나머지 8비트는 **호스트 식별**

IPv4과 IPv6의 차이점

IP 주소는 IPv4와 IPv6 두 가지 버전이 있다.

IPv4: 32비트로 구성된 IP 주소로, 대략 43억 개의 고유한 주소를 생성할 수 있다. IPv4 주소는 4개의 0~255 사이의 숫자로 이루어져 있으며, 각 숫자는 점(.)으로 구분된다.

예) 192.168.0.1

IPv6: 128비트로 구성된 IP 주소로, 거의 무한한 수의 고유한 주소를 생성할 수 있다. IPv6 주소는 8개의 4자리 16진수로 이루어져 있으며, 각 16진수는 콜론(:)으로 구분된다.

예) 2001:0db8:85a3:0000:0000:8a2e:0370:7334

기본적으로 IP주소라고 하면 IPv4를 이야기하는데 자리 수의 한계로 인해 IPv4는 더이상 할당되지 않고 있다.

IP 주소와 MAC 주소의 차이

항목	MAC 주소	IP 주소
레이어	OSI 2계층 (데이터 링크 계층)	OSI 3계층 (네트워크 계층)
식별 위치	동일 네트워크 내 장치 식별	인터넷 상의 장치를 전 세계적으로 식별
주소 형식	12자리 16진수 (예: 00-14-22-01-23-45)	IPv4: 32비트 (예: 192.168.0.1), IPv6: 128비트 (예: 2001:0db8::1)
변경 가능성	변경할 수 없음 ( 제조시 장치에 하드코딩 됨 )	네트워크 설정을 통해 변경 가능
주소 유형	물리적 주소	논리 주소
할당 방식	제조시 장치에 하드코딩 됨	소프트웨어 구성을 통해 장치에 할당됨

IP 주소 = 집 주소

• 인터넷상에서 어느 네트워크(집)에 위치했는지를 나타내는 주소이다.
• 예를 들어, 택배를 보낼 때 집 주소만 있으면 그 집까지는 도착할 수 있는 것처럼, IP 주소는 데이터가 목적지 네트워크까지 가는 데 사용된다.

MAC 주소 = 집 안의 특정 사람(기기)을 가리키는 이름표

• 네트워크 안에서 특정 장치를 식별하는 고유한 주소이다.
• 집 안에 여러 사람이 있을 때, 택배 기사가 수신자 이름을 보고 그 사람에게 전달하듯, MAC 주소는 로컬 네트워크 내에서 누구한테 보낼지를 결정한다.

TTL이란

TTL: Time To Live의 약자로 해당 패킷의 생존 시간을 의미한다.

IP 패킷 내부에 있는 값으로서, 그 패킷이 네트워크에 너무 오래 있어서 버려져야 하는지의 여부를 라우터에게 알려주는 역할을 한다.

패킷들은 여러가지 이유로 적당한 시간 내에 지정한 장소에 배달되지 못할 수가 있다.

예를 들어 부정확한 라우팅 테이블의 결합은 패킷을 끝없이 순환하도록 만들 수 있다. 그래서 일정 시간이 지나면 그 패킷을 버릴건지 혹은 재전송할 것인지를 결정하도록 하기 위해서 TTL이 사용된다.

각 라우터는 TTL 패킷이 날라올 때 TTL Value를 1씩 감소시킨다. TTL 값이 0이 되었을 때 라우터는 그것을 감지하여 해당 패킷을 버리고 ICMP 메세지를 발신지 host에게 보내게 된다.

IPv4에서 수행하는 Checksum과 TCP에서 수행하는 Checksum 차이점

항목	IPv4 Checksum	TCP Checksum
검사 범위	IP 헤더만 검사	TCP 헤더 + 데이터(페이로드) + 의사 헤더까지 검사
목적	IP 헤더의 무결성 확인 (라우팅 정보 보호)	전체 TCP 세그먼트의 무결성 확인(데이터 손상 방지)
위치	IPv4 헤더 내에 존재	TCP 헤더 내에 존재
손상 시 처리	패킷은 폐기됨, 상위 계층에 전달되지 않음	손상된 TCP 세그먼트는 수신 측에서 재전송 요청 등 처리 가능

• IP 체크섬은 패킷이 제대로 전달될 수 있게 IP 경로 자체를 보호
• TCP 체크섬은 실제 데이터를 온전하게 받기 위해 데이터 자체를 보호

---

🔵 HTTP & HTTPS

HTTP의 Stateless 특성

stateless 란 서버가 클라이언트의 이전 요청 상태를 저장하지 않는다는 특성을 의미합니다.

• 각 HTTP 요청은 독립적이며, 이전 요청의 정보를 기억하지 않는다.
• 예를 들어 로그인 후 다른 요청을 보내더라도, 서버는 사용자가 로그인했다는 상태를 기억하지 않는다.
• 그래서 세션, 쿠키, 토큰 등을 활용해 상태를 클라이언트 측에서 저장하고 요청마다 보내는 방식으로 상태를 유지한다.

장점: 서버가 상태를 저장할 필요가 없으므로 확장성과 단순성이 높아짐

단점: 매 요청마다 인증 정보 등을 반복적으로 포함해야 함

HTTPS에서 공개키와 대칭키의 차이

구분	공개키 암호화 방식	대칭키 암호화 방식
키 종류	공개키(암호화용), 개인키(복호화용)	하나의 동일한 키를 암복호화에 사용
속도	느림	빠름
보안 방식	키쌍을 이용해 안전하게 키를 교환	미리 안전하게 키를 주고받아야 함
사용 목적	주로 키 교환에 사용됨	실제 데이터 내용 암호화에 사용

HTTPS Handshake 과정에서는 인증서를 사용하는 이유

1. 신뢰할 수 있는 서버인지 확인하기 위해서 클라이언트는 서버가 제공한 인증서(Certificate) 를 통해 이 서버가 진짜 github.com인지 판단합니다.

2. 인증서에 포함되는 정보

• 도메인 이름
• 서버의 공개키
• 인증 기관(CA)이 서명한 전자서명

3. 클라이언트는 이 인증서가 신뢰할 수 있는 기관(CA) 에 의해 서명되었는지를 검증하고,서버의 공개키가 진짜임을 확인한다.

4. 검증이 성공하면, 대칭키 교환에 사용할 암호키를 안전하게 서버로 전송할 수 있댜.

---

🔵 HTTP 응답 코드

GET과 POST의 차이점

항목	GET	POST
목적	데이터 조회	데이터 생성/전송
요청 데이터	URL의 쿼리 스트링에 포함	HTTP Body에 포함
길이 제한	있음 (URL 길이 제한 존재)	없음
캐싱	가능 (브라우저/프록시 등 캐싱 활용 가능)	일반적으로 캐싱하지 않음
멱등성	O (여러 번 요청해도 결과 동일)	X (여러 번 요청하면 데이터 중복 생성 가능)
보안	낮음 (URL에 민감 정보 노출 우려)	상대적으로 높음 (Body에 숨겨짐)

POST와 PUT, PATCH의 차이점

항목	POST	PUT	PATCH
목적	리소스 생성	리소스 전체 수정 or 생성	리소스 일부 수정
멱등성	X (여러 번 호출 시 중복 생성 가능)	O (여러 번 호출해도 동일 결과)	일반적으로 멱등성 보장 안됨
사용 예시	새로운 게시글 작성	게시글 전체 내용 수정	게시글의 일부 내용만 수정
요청 데이터	필드 전체 포함 필요 없음	전체 필드 필요	수정할 필드만 포함

---

🔵 SSL과 TLS의 차이점

항목	SSL (Secure Sockets Layer)	TLS (Transport Layer Security)
개발 시기	1990년대 중반 개발	SSL의 후속 프로토콜, 1999년부터 등장
최신 버전	SSL 3.0 (더 이상 사용하지 않음)	TLS 1.3 (2020년 기준 최신)
보안성	여러 보안 취약점 존재	보안 강화 (키 교환, 암호화 알고리즘 등 개선)
호환성	구형 시스템에 사용	최신 웹 브라우저와 시스템에서 표준 사용
사용 여부	비권장 (Deprecated)	표준 보안 프로토콜로 사용 중

현재는 "TLS"가 올바른 명칭이며, 관행적으로 SSL이라고 부르기도 하지만 실질적으로는 TLS 사용 중이다.

---

🔵 DNS에 대한 설명

DNS란?

• Domain Name System의 약자
• 사용자가 도메인 주소 (예: www.github.com)를 입력하면 해당 도메인에 매핑된 IP 주소를 찾아주는 주소 해석 시스템

계층 및 프로토콜

항목	설명
계층	애플리케이션 계층 (OSI 7계층 기준)
프로토콜	주로 UDP 53번 포트 사용 (빠른 응답)
예외	데이터 길이가 길거나 보안 DNS는 TCP 사용

---

🔵 쿠키 & 세션

쿠키와 세션의 차이점

항목	쿠키	세션
저장 위치	클라이언트(브라우저)	서버
보안성	상대적으로 낮음 (조작 가능)	상대적으로 높음 (서버에서 관리)
만료 설정	클라이언트가 직접 만료 시간 설정 가능	서버 설정에 따라 결정
용량 제한	약 4KB	제한 없음 (서버 메모리에 의존)
식별 방식	클라이언트가 요청 시 자동으로 쿠키 전송	세션 ID를 쿠키로 전달하여 서버가 식별

세션 기반 로그인 과정

1. 클라이언트가 로그인 요청
2. 서버가 로그인 정보 확인 후 세션 생성
3. 세션 ID를 쿠키에 담아 클라이언트에 전달
4. 이후 요청마다 클라이언트는 세션 ID를 전송
5. 서버는 해당 세션 ID로 로그인 사용자를 식별

서버가 여러 대일 때 세션 관리 방법

• 세션 클러스터링: 서버 간 세션 정보를 동기화
• 세션 스토리지 사용: Redis, Memcached 등의 인메모리 DB 활용
• JWT 사용: 세션 없이 토큰 기반 인증 (Stateless 방식)

Stateless vs Connectionless

항목	Stateless	Connectionless
정의	이전 상태를 서버가 저장하지 않음	연결 없이 개별 패킷 전송
예시	HTTP	UDP
특징	요청마다 독립적, 서버 확장성 용이	빠르지만 신뢰성 낮음

HTTP가 Stateless 구조인 이유

• 확장성과 단순성 확보
• 서버는 클라이언트의 상태를 기억하지 않기 때문에 요청 처리 시 독립성 보장
• 캐싱, 로드 밸런싱, 서버 분산 처리에 유리

---

🔵 www.github.com을 브라우저에 입력하고 엔터를 쳤을 때, 네트워크 상 어떤 일이 일어나는지 최대한 자세하게 설명해 주세요

1. 브라우저 캐시 확인

   • 먼저 이전에 저장된 캐시 기록이 있는지 확인한다.

2. DNS 조회

   • github.com 도메인에 해당하는 IP 주소를 찾기 위해 DNS 질의를 수행한다.
   • 브라우저 → OS → DNS Resolver → Root → TLD → Authoritative → IP 응답

3. TCP 연결 (3-way Handshake)

   • 클라이언트는 서버와의 연결을 위해 TCP 3-way handshake 수행한다.
   • SYN → SYN-ACK → ACK

4. TLS Handshake (HTTPS의 경우)

   • 서버 인증서를 전달하고 공개키를 교환한다.
   • 세션키 생성 후 대칭키 방식으로 통신을 시작한다.

5. HTTP 요청 전송

   • 브라우저는 GET 방식으로 / 요청을 보낸다.
   • ex) GET / HTTP/1.1

6. 서버 응답

   • 서버는 HTML, CSS, JS 등의 데이터를 응답한다.
   • HTTP 응답 코드와 함께 콘텐츠를 전송한다.

7. 브라우저 렌더링

   • HTML 파싱 → DOM 트리 구성
   • CSSOM, JS 파싱 → 렌더링 트리 완성 → 페이지 렌더링

8. 추가 리소스 요청

   • 이미지, JS, CSS 등 외부 리소스 추가 요청 발생 (병렬 처리)