인터넷 네트워크
1. 인터넷 : 전 세계 컴퓨터들을 하나로 연결하는 거대한 컴퓨터 통신망

- 클라이언트 바로옆 서버있으면, 인터넷이 필요없이 케이블만 연결하면 됨
- 실제 세계에서는 클라이언트와 서버가 물리적으로 굉장히 떨어져있기때문에
중간에 있는 인터넷이라고 하는 서버 노드들의 집합을 통해서 통신을 하게 됨
이 거대 통신말에서 통신하기 위해서 규칙인 인터넷 프로토콜(통신규약)인 IP 필요
2. 인터넷 프로토콜(IP) : 인터넷 별 고유 주소
- 지정한 IP주소에 '패킷'이라는 통신 단위로 데이터를 전달함
- 패킷 : 패킷은 출발지 IP, 목적지 IP,기타..., 전송데이터 의 정보 담음

한계점 :
(1) 비연결성 : 대상이 없거나 서비스가 정상적이지 않더라도 무조건 패킷을 전송함
(2) 비신뢰성 : 중간에 패킷이 사라질 수도 있고, 패킷을 여러 개 보냈을 때 패킷이 순서대로 전송되지 않을 수도 있음
(3) 프로그램 구분 : 같은 IP에서 서로 다른 애플리케이션들이 통신을 하고 있을 때 이것들은 구분하는데 한계가 있다
위와 같은 문제점들을 해결해주는 것이 TCP 프로토콜
3. TCP/UDP : 전송 제어 프로토콜
| 애플리케이션 계층 | HTTP, FTP |
| 전송 계층 | TCP, UDP |
| 인터넷 계층 | IP |
| 네트워크 인터페이스 계층 | LAN 카드, LAN 드라이버 |
- 애플리케이션 계층을 통해 보내진 데이터는 전송, 인터넷 계층을 거치면서 패킷 정보가 하나씩 씌워짐
- TCP 세그먼트에서는 출발지 PORT, 목적지 PORT, 전송제어, 검증정보와 같은 정보들이 붙게 되는데, 이러한 정보들이 인터넷 프로토콜만으로는 한계를 가졌던 점을 해결해준다.
- IP 패킷까지 덧씌워진 데이터는 네트워크 계층에서 ethernet frame을 통해서 외부로 전송된다.
[응용 계층] HTTP, FTP
↓ (데이터)
[전송 계층] TCP, UDP
↓ (세그먼트: +출발지 PORT, 목적지 PORT, 전송제어, 검증정보) //ip 프로토콜 보완
[네트워크 계층] IP
↓ (패킷: +출발지 IP, 목적지 IP, 상위 계층 데이터)
[데이터 링크 계층] Ethernet, Wi-Fi
↓ (프레임: +MAC 주소, 오류 검출 정보)
[물리 계층] 외부 (LAN 카드, 전선, 전파 비트 전송)
TCP(전송 제어 프로토콜) 특징 (Transmission Control Protocol)
1. 연결지향

3-way handshake
1) 클라이언트 서버에 SYN(연결 요청) 보냄.
2) 서버는 ACK(요청 수락), SYN(연결 요청) 보냄
3) 클라이언트 ACK(요청 수락) 서버에 보내면서 연결 완료됨. (+데이터 전송)
- 최근에는 최적화가 잘되어 있어 3번에서 ACK를 보낼 때 데이터를 같이 전송한다.
2. 데이터 전달 보증

데이터 전송 완료시, 서버 데이터를 받았다는 응답 줌.
3.순서 보장

이 모든 것이 가능한 이유는 TCP/IP 패킷 안에 출발지 IP, 목적지 IP, 전송제어, 순서, 검증 정보 등 모두 들어가져 있기 때문.
그래서 TCP를 신뢰할 수 있는 프로토콜이라고도 함
+ UDP(사용자 데이터그램 프로토콜) 특징
- 연결지향 TCP 3 way handshake X, 데이터 전달 보증 X, 순서 보장X
- 단순, 빠름
- IP와 거의 같지만, PORT와 체크섬이 추가된 것과 같음
- PORT : 여러 패킷을 구분하기 위해 쓰이는 것
- 체크섬 : 전달된 값이 변경되었는지를 검사하는 값
4. PORT

한 장치(100.100.100.1)에서 여러 웹브라우저로 한 웹서버(200.200.200.3)에 접속한다면,
서버쪽에선 출발지 IP가 같기때문에 어떤 탭으로 어떤 데이터를 보내야 할지 패킷 구분 어려움
➡︎ TCP/IP, UDP/IP 패킷에는 "출발지 PORT"와 "목적지 PORT"가 추가해 "IP + PORT" 조합 사용해 패킷 구분
- IP : 목적지 서버를 찾는 것
- PORT : 서버에서 돌아가는 애플리케이션 구분하는 것
| 출발지 IP | 출발지 PORT | 목적지 IP | 목적지 PORT | |
| 게임 | 100.100.100.1 | 8090 | 200.200.200.2 | 11220 |
| 웹 브라우저 창1 | 100.100.100.1 | 10010 | 200.200.200.3 | 80 |
| 웹 브라우저 창2 | 100.100.100.1 | 10011 | 200.200.200.3 | 80 |
클라이언트 서버로 패킷 보낼때, "IP + PORT" 조합으로 보냄
서버도 클라이언트에 응답 보낼때, "출발지 IP + 출발지 PORT"로 구분해 보냄
PORT 번호
| 0 ~ 1023 | 0 ~ 65535 | FTP | TELNET | HTTP | HTTPS |
| 사용x | 할당 가능 | 20, 21 | 23 | 80 | 443 |
5. DNS(Domain Name System)
IP주소 외우기 어렵고 변경될수도 있음 → 접근 힘듬(물어봐야함) → 이름 넣자(도메인)
- IP는 변경될 수 있고 기억하기 어렵기에, DNS를 이용해서 IP 주소를 저장
- DNS 서버에 원하는 IP 주소를 도메인 명과 함께 저장
- 클라이언트는 도메인 명을 DNS 서버에 요청하면 응답으로 IP 주소가 오게되고, 그 IP 주소를 이용해서 원하는 서버를 찾음

HTTP(HyperText Transfer Protocol)
1. HTTP 기본
초기 문서 전달위한 고안 프로토골 -> 현재 모든것을 HTTP프로토골에 담아 보냄
- HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML 모든 형태 데이터 전송 가능
- 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용
역사
- HTTP/1.1 (1997) : 가장 많이 사용, 가장 중요한 버전 (RFC2068 -> RFC2616 -> RFC7230 ~ 7235)
- HTTP/2 (2015) : 성능 개선
- HTTP/3 (진행중) : TCP 대신에 UDP 사용, 성능 개선
기반 프로토골
- TCP : HTTP/1.1, HTTP/2
- UDP : HTTP/3 (HTTP/3는 UDP 프로토콜을 기반으로 개발됨)
- 현재 HTTP/1.1 주로 사용 (HTTP/2, HTTP/3도 점점 증가 추세)
특징
- 클라이언트 - 서버 구조 동작, 무상태 프로토콜(스테이스리스), 비연결성, HTTP 메시지. 단순함, 확장 가능
2. 클라언트 서버 구조

Request Response 구조
클라이언트 서버에 요청을 보내고, 대기 서버가 요청에 대한 결과를 만들어서 응답
(클라이언트가 보낸 요청을 분석해 응답 보냄)
3. 무상태 프로토콜, 스테이스리스(Stateless)
Stateful vs Stateless
Stateful(상태 유지)

서버가 클라이언트 이전 요청 모두 알고 있음.
서버가 여러 대일 때, 항상 같은 서버와 통신이 유지되어야 함.
한 대의 서버가 죽어버리면 대응 어려움.
하나의 서버에서 바뀌는 정보가 있다면 다른 모든 서버에게 미리 알려줘야 함
Stateless(상태 유지x)

서버가 클라이언트의 이전 요청 모름.
서버가 여러 대일 때, 아무 서버와 통신을 해도 무방
한 대의 서버가 죽더라도 다른 서버로 대응이 쉽게 가능
한계 : 모든 것을 무상태로 설계 가능x, 데이터를 너무 많이 사용
(1) 무상태의 예시 : 로그인이 필요 없는 단순한 서비스 소개 화면
(2) 상태 유지 예시 : 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
무상태 유지를 최대한 사용,상태 유지는 최소한으로 사용
4. 비연결성
소켓 통신 : 기본적 연결 유지(Stateful)해서 사용(TCP 기반,빠른 통신 가능) → 클라이언트 늘어날수록 서버의 과부하 가능
HTTP : 기본이 연결을 유지하지 않는 모델(stateless)(요청/응답 후 연결 종료) → TCP/IP 연결을 새로 맺어야 시간 늘어남 → Keep-Alive(지속연결) 기능으로 한 번 연결 후 연결 유지 가능
![]() |
![]() |
+)Stateless와 동시 트래픽 처리
- 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽에 상태 기억하지 않는Stateless가 독립처리,서버 부하 분산,빠른 대응가능
- ex) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록 -> 수만명 동시 요청
5. HTTP 메시지

시작라인
-요청메세지 (ex. ➀GET ➁/search?q=hello&hl=ko ➂HTTP/1.1)
➀ HTTP메서드 : GET-리소스 조회, POST -요청 내역 처리, PUT, DELETE 등
➁ 요청대상 : 절대경로 (/)로 시작하는 경로
➂ HTTP버전
-응답메세지 (HTTP/1.1 200 OK)
HTTP 상태 코드 : 요청 성공, 실패를 나타냄
- 200 : 성공
- 400 : 클라이언트 요청 오류
- 500 : 서버 내부 오류
- 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글
HTTP 헤더
HTTP 전송에 필요한 모든 부가정보가 들어감
field-name(필드명,대소구분x): field-value(필드 값, 대소구분o) 형식

-요청메세지 (Host: 요청을 보내는 서버 주소...등)
-응답메세지
Content-Type: 응답 데이터의 형식 (text/html)
Content-Length: 응답 데이터의 크기 (348바이트)
Server: 응답을 처리한 서버 정보 (Apache/2.4.41)
HTTP 바디

실제 전송할 데이터가 들어가 있음.
HTML, JSON, XML, 이미지, 파일 등등 byte 로 표현할 수 있는 모든 데이터 전송 가능
URI와 웹 요청 흐름
1. URI(Uniform Resource Identifier, 통합 자원 식별자)
• URI, URL, URN 세 가지의 차이점?
URI : 리소스를 식별하는 통일된 방식, URL과 URN을 포함하는 개념
URL(Locator) : 리소스의 위치를 포함하는 URI , 프로토콜 + 도메인 + 경로 ex.https://www.naver.com
URN(Name) : 리소스의 고유한 이름을 식별하지만, 위치(URL)는 포함하지 않음(거의 사용x) ex. urn:isbn:0451450523 (책 ISBN 번호)
URL 전체 문법
https://www.google.com/search?q=hello&hl=ko
scheme://[userinfo@]host[:port][/path][?query][#fragment]
- https : 프로토콜
- www.google.com : 호스트명
- 443 : 포트 번호
- /search : 패스
- q=hello&hl=ko : 쿼리 파라미터
(1)URL scheme
- 주로 프로토콜 사용
- 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙 (http, https, ftp 등등)
(2) URL userinfo
- URL에 사용자 정보를 포함해서 인증
- 거의 사용하지 않는다.
(3) URL host
- 호스트명
- 도메인명 또는 IP주소를 직접 사용가능
(4) URL PORT
- 포트(PORT)
- 접속 포트
- 일반적으로 생략, 생략시 http는 80, https는 443
(5) URL path
- 리소스 경로(path), 계층적 구조
- ex) /home/file1.jpg, /members, /members/100, /items/iphone12
(6) URL query
- key=value 형태
- ?로 시작, &로 추가 기능 ?keyA=valueA&keyB=valueB
- query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태
(7) URL fragment
- fragment
- html 내부 북마크 등에 사용
- 서버에 전송하는 정보 아님
2. 웹 브라우저 요청 흐름
https://www.google.com/search?q=hello&hl=ko
1. 도메인(www.google.com) DNS 서버를 조회해서 요청 보낼 서버 IP와 PORT 번호를 조회
2. 클라이언트가 HTTP 요청 메세지 생성
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
3. HTTP 메세지를 SOCKET 라이브러리를 통해 OS 계층 내 TCP/IP 계층에 전달을 한다.
(3-way handshake 를 통해 서버와 연결을 확인하고 데이터 전달함)
![]() |
![]() |
4. TCP/IP 계층에서는 이전의 웹 브라우저에서 전달 받은 데이터를 기반으로 TCP/IP 패킷을 생성
5. 네트워크 인터페이스 계층을 거쳐 서버로 전송된다.
6. 서버는 전달 받은 데이터를 분석하고, HTTP 응답 메세지 생성 후 같은방식으로 패킷만들어 클라이언트에 전달
![]() |
![]() |
![]() |
7. 클라이언트는 응답 패킷을 분석하고, 웹 브라우저가 렌더링해서 화면에 뿌려줌.
'Spring' 카테고리의 다른 글
| [Spring] 웹 애플리케이션 이해 (0) | 2025.03.04 |
|---|---|
| [Spring] HTTP (2) (0) | 2025.03.03 |
| [Spring] 빈 스코프 (0) | 2025.02.27 |
| [Spring] 빈 생명주기 콜백 (0) | 2025.02.26 |
| [Spring] 의존관계 자동 주입 (0) | 2025.02.24 |






