“OSI 7계층이 왜 필요한지, TCP/IP랑 뭐가 다른지
설명 없이도 흐름으로 말할 수 있는 상태 만들기”

1. 네트워크가 뭔지 알아보자!

네트워크는 왜 필요한가?
왜 그냥 한 덩어리로 만들지 않고 계층으로 나눴을까?

네트워크란
서로 다른 컴퓨터가 데이터를 주고받는 구조
컴퓨터들이 통신 기술을 이용해서 그물망처럼 연결된 통신 이용 형태를 의미한다.

계층을 나누는 이유
계층화는 문제 분리와 책임 분리를 위한 설계
한 단계에 문제가 생겨도 다른 단계는 그대로 유지할 수 있다

네트워크를 한 문장으로 말하면, 서로 다른 컴퓨터들이 데이터를 주고받을 수 있도록 만든 구조다.
여기서 중요한 건 ‘데이터’ 자체가 아니라, 그 데이터를 어떻게 안전하고 효율적으로 주고받느냐를 정한 규칙과 구조다.

예를 들어 내가 내 노트북에서 어떤 웹사이트에 접속한다고 해보자.
브라우저에서 주소를 입력하는 순간, 컴퓨터는 “이 요청을 어떻게 보내야 하지?”를 스스로 결정해야 한다.
그런데 이 과정을 한 덩어리의 거대한 프로그램으로 만들면, 문제가 생겼을 때 어디서 잘못됐는지 알 수가 없다.

그래서 네트워크는 역할을 나눠서 설계한다. 이걸 계층화라고 부른다.

왜 굳이 계층으로 나눴을까?

가장 중요한 이유는 문제 분리와 책임 분리다.

예를 들어 인터넷이 갑자기 느려졌다고 하자.
이게 서버 문제인지, 내 컴퓨터 문제인지, 와이파이 문제인지, 케이블 문제인지 바로 구분할 수 있어야 한다.
계층이 나뉘어 있으면, “아 이건 네트워크 장비 문제구나”, “아 이건 애플리케이션 문제구나” 하고 범위를 좁힐 수 있다.

또 하나 중요한 이유는 유연성이다.
아래쪽 통신 방식이 바뀌어도, 위쪽 프로그램은 그대로 쓸 수 있어야 한다.
와이파이든, 유선이든, 5G든 상관없이 브라우저는 똑같이 HTTP 요청을 보낸다.
이게 가능한 이유가 바로 계층 구조 덕분이다.

데이터는 한 번에 안 간다 — 패킷

네트워크에서 데이터는 한 덩어리로 통째로 이동하지 않는다.
항상 잘게 쪼개서 이동한다. 이 조각 하나하나를 패킷(packet)이라고 부른다.

왜 굳이 쪼갤까?

만약 큰 데이터를 한 번에 보냈는데 중간에 하나라도 오류가 나면, 전부 다시 보내야 한다.
반대로 패킷으로 쪼개면, 중간에 몇 개만 손실돼도 그 부분만 다시 보내면 된다. 이건 네트워크를 훨씬 안정적으로 만든다.

캡슐화(Encapsulation)의 개념

패킷을 보낼 때, 데이터는 그냥 던져지지 않는다.
위에서 아래로 내려가면서 점점 포장이 추가된다.

비유하자면 이렇다.

편지 내용 작성 (실제 데이터)
봉투에 넣기 (어디서 어디로)
택배 박스에 넣기 (배송 규칙)
트럭에 실기 (물리적 전달)

네트워크도 마찬가지다. 사용자가 만든 데이터는 TCP 정보가 붙고, IP 정보가 붙고, MAC 주소 정보가 붙고,
마지막에는 전기 신호로 변환된다. 이 과정을 캡슐화라고 한다.

중요한 포인트는

“각 계층은 자기 헤더만 추가한다”
는 것이다.

자기 일만 하고 다음 계층에 넘긴다.

네트워크는 그냥 데이터를 보내는 기술이 아니다.
문제가 생겨도 관리 가능하도록 만든 구조다.

계층은 역할 분리를 위해 존재한다
데이터는 패킷으로 쪼개서 보낸다
위에서 아래로 내려가며 포장이 추가된다 (캡슐화)

2. OSI 7 계층 구조 이해하기

OSI 7계층을 한 문장으로 요약하면 이렇다.

“사람이 이해하는 데이터가, 기계가 이해하는 신호로 변해가는 과정”

그래서 위에서 아래로 갈수록 점점 추상적 개념이 사라지고,
아래로 갈수록 현실적인 하드웨어와 가까워진다.

7계층은 ‘사용자 세계’의 출발점이다

(응용 계층 - Application Layer)

7계층(Application)은 우리가 직접 만지는 영역이다.
브라우저에서 URL을 입력하고, 앱에서 버튼을 누르면
“요청”이라는 의미 있는 데이터가 만들어진다.

이 단계에서는

전기 신호는 관심 없고
케이블이 뭔지도 신경 안 쓰고
그냥 “요청을 보낸다”라는 의미만 중요하다.

그래서 HTTP, FTP, SMTP 같은 사람이 이해하는 규칙 (프로토콜)이 여기에 있다.

6계층과 5계층은 ‘중간 정리 구간’이다

6계층은 표현계층 - presentation Layer (데이터를 네트워크에서 전송할 수 있는 형태로 변환)

5계층은 세션계층 - Session Layer (데이터 교환을 위한 논리적 연결을 설정하고 유지, 통신 세션을 설정)

7계층에서 만들어진 데이터는 아직 그대로 보낼 수 없다.
그래서 중간에서 정리 작업이 들어간다.

6계층(Presentation)은 데이터의 형식을 담당한다.
문자를 어떻게 표현할지, 압축할지, 암호화할지 같은 문제다.
HTTPS의 암호화 개념이 여기와 연결된다.

5계층(Session)은 연결을 논리적으로 관리한다.
누가 먼저 말했고, 연결이 살아있는지 같은 흐름을 다룬다.
다만 현실에서는 이 역할 대부분을 TCP가 대신한다.

그래서 TCP/IP 모델에서는 7·6·5계층이 하나로 묶인다.

4계층이 전송을 맡는다 (진짜 중요)

4계층은 전송계층 - Transport Layer

포트 번호를 사용해서 통신한다.

4계층(Transport)은 OSI 모델의 중심 축이다.
위쪽은 “의미 있는 데이터”, 아래쪽은 “네트워크 전달”인데
이 둘을 연결하는 지점이 바로 4계층이다.

여기서 처음으로
“어디까지 잘 갔는지”, “중간에 빠진 건 없는지”를 신경 쓴다.

TCP와 UDP가 여기 있다.

TCP는 “느려도 정확하게”
UDP는 “빠르지만 보장은 안 함”

그래서 웹, API, 데이터 전송은 대부분 TCP 위에서 돌아간다.

3계층부터는 ‘주소와 길 찾기’다

3계층(Network)은 목적지를 결정한다.
여기서 IP 주소가 등장한다.

이 단계에서는
“이 데이터가 서울에서 부산으로 가야 한다” 정도만 알면 된다.
어떤 케이블을 타는지는 관심 없다.

라우터가 이 계층에서 동작한다.

2계층과 1계층은 ‘현실 세계’

2계층(Data Link)은 같은 네트워크 안에서의 전달이다.
여기서 MAC 주소가 등장하고, 스위치가 동작한다.

3계층이 “어디로 갈지”라면
2계층은 “바로 옆에 누구에게 줄지”다.

1계층(Physical)은 가장 밑바닥이다.
전기 신호, 빛, 전파 같은 물리적 전달 그 자체다.

여기엔 의미도, 주소도 없다.
그냥 “신호가 흐르느냐”만 있다.

중간 경계선이 중요한 이유

OSI 7계층을 보면 중간에 선이 그어져 있다.

7 6 5  ← 사용자 관점
---------
4      ← 핵심 연결
---------
3 2 1  ← 네트워크 관점

이 구조를 이해하면 중요한 깨달음이 생긴다.

“위쪽 문제는 애플리케이션이 해결하고
아래쪽 문제는 네트워크가 해결한다”

그래서 서버 개발자나 백엔드가 4계층 위를 특히 잘 알아야 한다.

처음 (7계층)

[편지 내용]

아직 아무 정보도 없음.
그냥 “하고 싶은 말”만 있음.

4계층 (전송 계층) — 첫 번째 헤더

[전송 헤더 | 편지 내용]

전송 헤더에는 이런 정보가 들어간다

출발지 포트
도착지 포트
순서 번호
재전송 필요 여부

3계층 (네트워크 계층)

[IP 헤더 | 전송 헤더 | 편지 내용]

IP 헤더에는

출발지 IP
목적지 IP

2계층 (데이터 링크 계층)

[MAC 헤더 | IP 헤더 | 전송 헤더 | 편지 내용 | MAC 트레일러]

출발지 MAC
목적지 MAC
오류 검사용 정보

1계층 (물리 계층)

010101010101...

이제 의미는 사라지고
순수한 비트(전기 신호)만 흐른다.

수신할 때는 반대로 일어난다

보낼 때

데이터 → 헤더 추가 → 헤더 추가 → 헤더 추가

받을 때

헤더 제거 → 헤더 제거 → 헤더 제거 → 데이터

이걸 디캡슐화(decapsulation)라고 한다.

OSI 7계층은 외우는 게 아니라 방향을 이해하는 모델이다.

위 → 의미, 사용자
아래 → 전달, 물리
4계층 → 둘을 잇는 핵심

3. 상위 계층은 무슨 역할을 하는지

상위 계층 (7·6·5)

사용자가 만든 의미있는 데이터가 네트워크로 내려가기 전 단계

7계층(Application) — “사람의 요청이 처음 만들어지는 곳”

7계층은 사용자와 가장 가까운 계층이다.
여기서 중요한 건,

7계층은 ‘프로그램’이 아니라 ‘프로토콜’이라는 점

브라우저 자체가 7계층이 아니라, 브라우저가 사용하는 규칙(HTTP)이 7계층이다.

HTTP를 예로 들어보자

브라우저에 주소를 치고 Enter를 누르면, 컴퓨터는 이런 요청을 만든다.

GET /login HTTP/1.1 Host: example.com

IP도 모르고
포트도 신경 안 쓰고
네트워크 경로도 모름

“이 리소스를 달라”는 의미

이게 바로 7계층의 역할

7계층의 핵심 역할 요약

사용자가 이해하는 요청/응답
데이터의 의미를 정의
HTTP, FTP, SMTP, DNS 등

7계층은 전송을 책임지지 않는다
“뭘 보낼지”만 정의한다

6계층(Presentation) — “데이터를 정리하는 계층”

6계층은 잘 안 보이지만, 개념적으로 엄청 중요하다.

여기서 하는 일은 딱 세 가지다.

인코딩 (문자 형식)
압축
암호화

HTTPS가 여기랑 연결되는 이유

HTTPS를 떠올려보자.

사용자는 그냥 HTTP 요청을 보낸 것처럼 느끼지만
실제로는 중간에서 암호화가 된다

이 “암호화라는 개념”이 바로 6계층이다.

TLS는 구현상 TCP 위에서 동작
개념적으로는 6계층 역할

그래서 면접에서
“HTTPS는 몇 계층이냐?”
라고 물으면 이렇게 말하면 좋다

“HTTP는 7계층이고,
HTTPS는 7계층 프로토콜에 6계층의 암호화 개념이 결합된 형태입니다.”

5계층(Session) — “대화의 흐름을 관리하는 계층”

5계층은 이름 그대로 세션을 다룬다.

세션이란?

“둘이 대화를 하고 있다는 논리적인 상태”

예로 설명하면

로그인 유지
연결이 끊겼는지 확인
중간에 다시 이어서 말할 수 있는지

이런 ‘대화의 맥락’을 관리한다.

그런데 왜 현실에서는 잘 안 보일까?

이유는 간단하다.

TCP가 대부분의 일을 대신하고 있기 때문이다.

그래서

OSI에선 5계층이 존재하지만
TCP/IP 모델에서는 7·6·5를 통째로 Application으로 묶는다

그래서 실무에서는 TCP/애플리케이션이 흡수

브라우저에서 요청 하나를 만들면

7계층
- “이 리소스를 요청한다” (HTTP 의미 생성)
6계층
- 암호화 / 형식 정리
5계층
- 대화 상태 관리

그 다음에야 비로소 4계층(TCP) 으로 내려간다

상위 계층은 ‘의미를 만드는 영역’이다.
아직 네트워크 전송은 시작도 안 했다.

4. 4계층(Transport Layer)

“IP만으로는 왜 부족한가?”

먼저 결론부터

IP 주소만 있으면 네트워크가 될 것 같지만, 실제로는 절대 안 된다.

이유는 간단하다.

IP는 ‘컴퓨터’까지만 찾는다
4계층은 ‘프로그램’까지 연결한다

이 차이가 4계층의 존재 이유다.

IP만 쓰면 생기는 문제

상황을 하나 상상해보자.

크롬 브라우저
슬랙
터미널에서 curl

이 세 개가 같은 서버(IP)로 요청을 보낸다.

서버 입장에서는

“이 패킷은 어느 프로그램에서 온 거지?”

를 구분할 방법이 없다.

IP에는 프로그램 정보가 없기 때문이다.

여기서 등장하는 게 포트(port)다.

포트 번호 = 프로그램의 주소

4계층은 이렇게 말한다.

“IP는 건물 주소고,
포트는 건물 안의 방 번호다.”

서버 IP: 203.0.113.10
HTTP 포트: 80
HTTPS 포트: 443

그래서 실제 연결은 항상 이렇게 된다.

[출발 IP : 출발 PORT] → [목적지 IP : 목적지 PORT]

이 조합을 소켓(socket)이라고 부른다.

TCP와 UDP의 진짜 차이

4계층에는 대표적으로 두 가지가 있다.

차이를 한 문장으로 요약하면 이거다.

TCP는 “전화”
UDP는 “확성기”

TCP — 정확함이 최우선

TCP는 데이터를 보내기 전에 연결부터 확인한다.

이게 바로 3-way handshake다.

1️⃣ 나랑 연결할래? (SYN)
2️⃣ 응, 연결 가능해 (SYN + ACK)
3️⃣ 오케이, 시작하자 (ACK)

상대가 살아있는지
받을 준비가 됐는지
중간에 끊기진 않았는지

신뢰성 확보가 중심.

TCP가 해주는 일들

순서 보장
손실 시 재전송
흐름 제어
혼잡 제어

그래서

HTTP / HTTPS
API
DB 통신

거의 다 TCP 위에서 돌아간다.

UDP — 빠름이 최우선

UDP는 말 그대로:

“보내고 끝”

연결 없음
재전송 없음
순서 보장 없음

대신:

빠름
지연 적음

그래서:

스트리밍
게임
실시간 음성

약간 손실돼도 괜찮은 서비스에서 사용

왜 4계층이 중심인지

OSI 구조 다시 떠올려보자.

7 6 5  ← 의미
---------
4      ← 허리
---------
3 2 1  ← 전달

4계층은

위쪽의 “의미 있는 데이터”를
아래쪽의 “패킷 전달”에 맞게 연결한다

즉,

사람의 요청을
네트워크가 처리 가능한 형태로 바꾸는 마지막 단계

실무에서 4계층이 튀어나오는 순간들

이제 네가 겪었던 것들이랑 바로 연결된다.

포트 충돌 에러
Connection timeout
Read timeout
WebSocket 연결 문제
SSE 끊김
Load Balancer L4 / L7 차이

“연결이 안 된다” = 대부분 4계층 문제

5. TCP 3-way / 4-way Handshake

“연결이란 무엇인가?”

TCP에서 말하는 “연결”의 정체

먼저 중요한 오해 하나부터 깨자. TCP 연결은 물리적인 선이 아니다.

TCP에서 말하는 연결이란,

서로 상태(state)를 공유하고 있다는 약속

이다.

“지금 몇 번 데이터까지 받았는지”
“다음엔 뭘 받을 차례인지”
“연결이 살아있는지”

이걸 양쪽이 기억하고 있는 상태가 바로 TCP 연결이다.

왜 연결을 맺어야 할까?

TCP는 약속한다.

순서 보장
손실 시 재전송
중복 제거

이걸 하려면:

누가 누구인지 확실해야 하고
서로 준비됐는지 확인해야 한다

그래서 데이터를 보내기 전에 먼저 “연결 확인”부터 한다.

이게 3-way handshake다.

TCP 3-way Handshake — 연결 시작

“서로 말할 준비 됐는지 확인하는 절차”

단계별로 아주 천천히 보자

SYN — “나랑 연결할래?”

클라이언트 → 서버

SYN

의미:

나 TCP로 통신하고 싶다
내가 보낼 준비 됐다

이때 클라이언트는

연결 상태를 SYN_SENT로 저장

SYN + ACK — “응, 나도 준비됨”

서버 → 클라이언트

SYN + ACK

의미:

네 요청 받았다
나도 연결할 준비 됐다

서버 상태

SYN_RECEIVED

ACK — “오케이, 시작하자”

클라이언트 → 서버

ACK

의미:

확인했다
이제 데이터 주고받자

즉 ,

양쪽 모두 ESTABLISHED

연결 완료

왜 꼭 3번이나 주고받을까?

여기 핵심 질문 나온다.

“2번이면 안 되나?”

답: 안 된다.

이유는:

서로 보낼 준비 / 받을 준비
양쪽 모두 확인해야 하기 때문

3번을 해야:

클라이언트도 서버가 살아있다는 걸 알고
서버도 클라이언트가 살아있다는 걸 안다

쌍방 확인

CP 연결 종료 — 4-way Handshake

연결 종료는 시작보다 더 복잡하다.

이유는 간단하다.

보내는 쪽과 받는 쪽을 따로 닫기 때문

단계별로 보자

FIN — “나 이제 보낼 거 없음”

클라이언트 → 서버

FIN

의미:

난 더 이상 데이터 안 보낸다
하지만 받을 수는 있다

ACK — “알겠어”

서버 → 클라이언트

ACK

여기까지는 반쯤 종료

FIN — “나도 끝”

서버 → 클라이언트

FIN

ACK — “완전히 종료”

클라이언트 → 서버

ACK

연결 완전 종료

TIME_WAIT는 왜 생길까? (중요 )

연결 종료 후, 클라이언트는 바로 사라지지 않는다.

잠깐 기다린다.
이 상태가 TIME_WAIT다.

왜 기다릴까?

마지막 ACK가 유실될 수도 있음
이전 연결의 패킷이 늦게 도착할 수도 있음

기다리지 않으면

엉뚱한 연결에 패킷이 섞일 수 있다

그래서

TIME_WAIT = 안전장치

실무에서 터지는 문제들 연결하기

이제 이게 다 이어진다.

서버에 TIME_WAIT 많음
커넥션 부족
연결 지연
부하 걸리면 새 연결 안 됨

대부분 TCP 연결 관리 문제

“속도 vs 신뢰성, 그리고 왜 중간에 서버가 하나 더 있나”

TCP vs UDP를 다시 한 문장으로

이미 배운 걸 한 번 더 정리하면

TCP는 ‘정확히 전달’이 목표
UDP는 ‘빨리 전달’이 목표

이 차이가 모든 선택의 기준이 된다.

TCP는 왜 느릴까?

TCP는 데이터를 보내기 전에 할 일이 너무 많다.

3-way handshake
순서 번호 관리
손실 시 재전송
흐름 제어
혼잡 제어

즉, TCP는 항상 이렇게 생각한다.

“혹시 빠진 건 없나?”
“상대가 지금 받을 수 있나?”
“너무 많이 보내면 안 되겠지?”

그래서 안정적이지만 느리다.

UDP는 왜 빠를까?

UDP는 반대로 이렇게 말한다.

“일단 보낸다.
받았는지는 네가 알아서 해라.”

연결 없음
상태 없음
재전송 없음

그래서:

지연이 거의 없음
손실이 나도 신경 안 씀

대신 애플리케이션이 책임을 져야 한다

현실 서비스에 대입해보자

웹 / API / DB

데이터 하나라도 틀리면 ❌
순서 어긋나면 ❌

TCP

스트리밍 / 실시간 음성

한두 프레임 손실은 괜찮음
대신 끊기면 ❌

UDP

게임

위치 정보 조금 틀려도 OK
지연은 치명적

UDP

중요한 깨달음

UDP는 무책임한 게 아니라,
책임을 ‘위로’ 넘기는 프로토콜이다.

여기서 등장하는 Load Balancer

이제 질문 하나 던져보자.

“서버 한 대로는 요청을 다 못 받으면 어떻게 하지?”

그래서 Load Balancer(LB)가 등장한다.

L4 Load Balancer — 연결만 본다

L4는 Transport Layer 기준이다.

즉, 얘가 보는 정보는 딱 이것뿐이다.

IP
Port
TCP/UDP

내용은 절대 안 본다

L4 LB의 특징

빠름
단순함
TCP 연결 단위로 분산

예:

클라이언트 → LB → 서버 A (TCP 연결) 클라이언트 → LB → 서버 B (TCP 연결)

그래서:

DB
게임 서버
TCP 기반 서비스

에서 많이 쓴다.

L7 Load Balancer — 내용을 본다

L7은 Application Layer 기준이다.

여기서는:

HTTP 헤더
URL
쿠키
메서드

전부 본다.

L7 LB의 특징

느리지만 똑똑함
요청 내용을 기준으로 분기 가능

예:

/api → 서버 A /image → 서버 B

또는:

로그인 유저
특정 헤더
특정 도메인

왜 L7은 TCP 위에서만 가능한가?

중요한 포인트 하나.

“UDP에서는 L7 LB가 왜 어렵지?”

이유:

UDP는 연결 상태가 없음
요청이라는 개념이 없음

L7은:

HTTP 요청 단위
세션 / 쿠키

전부 TCP 연결 기반이다.

실무에서 겪는 문제들이 다 연결된다

이제 네가 봤던 에러들 다시 떠올려보자.

L7 LB에서 timeout
SSE 끊김
WebSocket 연결 유지 문제
대용량 트래픽에서 TCP 포화

다 4계층 + LB 설계 문제

HTTP 요청 하나가 실제로 서버까지 가는 전체 흐름

(브라우저 → 서버 → 응답)

브라우저에 https://example.com/login 입력

사용자가 행동한다 (아직 네트워크 아님)

브라우저 주소창에 URL을 치고 Enter를 누른다.
이 순간까지는 네트워크가 시작도 안 됐다.

브라우저는 먼저 이렇게 생각한다.

“이 요청을 어디로 보내야 하지?”

DNS 조회 — “이 도메인의 IP가 뭐야?” (7계층)

example.com은 사람이 읽기 쉬운 이름일 뿐이다.
네트워크는 IP 주소만 이해한다.

그래서 브라우저는 DNS 서버에 묻는다.

example.com → ?

DNS 서버가 답한다.

example.com → 93.184.216.34

이제야 목적지(IP)를 알게 됐다.

여기까지는 아직 HTTP 요청도 안 보냄

TCP 연결 시작 — 3-way handshake (4계층)

이제 서버 IP를 알았으니,
브라우저는 바로 HTTP를 보내지 않는다.

먼저 이렇게 묻는다.

“너랑 TCP로 통신해도 돼?”

3-way handshake

클라이언트 → 서버 : SYN
서버 → 클라이언트 : SYN + ACK
클라이언트 → 서버 : ACK

이 순간 TCP 연결이 ESTABLISHED

이 단계에서:

포트 번호 사용됨 (443)
“프로그램 ↔ 프로그램” 연결 완료

TLS Handshake — HTTPS의 핵심 (6계층 개념)

이제 TCP 연결은 됐지만,
아직 평문으로 보내면 위험하다.

그래서 HTTPS는 여기서 한 번 더 협상한다.

“어떤 암호 방식 쓸까?”
“서버 너 진짜 맞아?”

이게 TLS Handshake다.

결과:

암호화 키 합의
이후 데이터는 전부 암호화됨

구현은 TCP 위지만,
개념적으로는 6계층 역할

HTTP 요청 생성 (7계층)

이제서야 진짜 HTTP가 등장한다.

브라우저는 이런 요청을 만든다.

GET /login HTTP/1.1
Host: example.com
Cookie: ...

이건 아직 의미만 있는 데이터다.

캡슐화 시작 — 위에서 아래로 포장됨

이 HTTP 데이터가 이제 계층을 타고 내려간다.

4계층 (TCP)

포트 번호
순서 번호
재전송 정보

[TCP 헤더 | HTTP 데이터]

3계층 (IP)

출발지 IP
목적지 IP

[IP 헤더 | TCP 헤더 | HTTP 데이터]

2계층 (MAC)

출발지 MAC
목적지 MAC

[MAC 헤더 | IP | TCP | HTTP | MAC 트레일러]

1계층 (Physical)

전기 신호 / 비트

010101010...

이제 진짜 네트워크로 흘러간다

중간 네트워크를 통과

데이터는 인터넷을 건너간다.

스위치: MAC 기준으로 전달
라우터: IP 기준으로 다음 경로 선택

중간 장비들은:

HTTP 모름
TCP 모름
IP만 보고 전달

서버 도착 → 디캡슐화 (역순)

서버에 도착하면 역순으로 포장을 푼다.

1계층: 신호 수신
2계층: MAC 확인
3계층: IP 확인
4계층: 포트 확인
7계층: HTTP 해석

이 요청은 결국 서버의 특정 포트의 특정 프로세스로 전달된다.

서버 애플리케이션 처리 (7계층)

서버(Spring, Node, Django 등)는:

요청을 해석하고
로직 실행하고
응답을 만든다

예:

HTTP/1.1 200 OK
<html>...</html>

응답도 같은 길로 돌아간다

응답 역시:

HTTP 생성
TCP/IP/MAC 헤더 붙음
네트워크 통과
클라이언트에서 디캡슐화

완전히 같은 경로, 방향만 반대

브라우저가 화면을 그린다

HTML, CSS, JS를 해석해서
네가 보는 로그인 화면이 나온다.

여기까지가 HTTP 요청 하나의 생애 주기다.

“브라우저에서 URL을 입력하면 DNS로 IP를 조회한 뒤
TCP 3-way handshake로 연결을 맺고,
HTTPS의 경우 TLS로 암호화 협상을 한 후
HTTP 요청을 TCP/IP 계층을 통해 캡슐화하여 전송합니다.
서버에서는 이를 역순으로 처리해 응답을 생성하고
동일한 경로로 클라이언트에 반환합니다.”

'CS' 카테고리의 다른 글

[CS \| 실시간 시스템] 병목이 발생하는 이유 (0)	2026.01.22
[CS - 컴퓨터구조] 컴퓨터가 이해하는 정보 (0)	2025.12.18
[CS - 네트워크] API 호출로 보는 네트워크 (0)	2025.12.17
[CS - 컴퓨터구조 ] 컴퓨터 구조 공부, 첫 걸음! (0)	2025.12.17
[DATA STRUCTURES - Graph] Prim Algorithm — “정점 중심” Greedy MST (0)	2025.12.16