Spring & SpringBoot
HTTP 웹 기본 지식 (1) - 인터넷 네트워크, 웹 브라우저 요청 흐름, HTTP 기초
유자바
2024. 8. 23. 00:21
1. 인터넷 네트워크
IP (Internet Protocol)
- 역할: 패킷(Packet)이라는 통신 단위로 지정한 IP 주소에 데이터를 전달하는 역할을 수행한다.
- 과정
- 클라이언트는 패킷(출발지 IP, 목적지 IP, 데이터, 그 외)을 꾸려 인터넷에 전달한다.
- 패킷은 인터넷상의 노드를 거쳐 목적지 IP를 가진 서버에 도달한다.
- 서버가 패킷을 잘 전달받으면 패킷(출발지 IP, 목적지 IP, 상태, 그 외)을 클라이언트에게 전달한다.
- 패킷은 인터넷 상의 노드를 거쳐 클라이언트에게 전달되는데 이때 클라이언트에서 서버까지의 도달했던 경로와 다른 경로로 클라이언트에게까지 전달될 수 있다.
- 한계
- 비연결성: 패킷을 받을 대상 서버가 서비스 불능 상태여도 패킷을 전송한다.
- 비신뢰성
- 패킷 소실: 클라이언트가 서버로 인터넷을 통해 패킷을 전송했는데, 중간에 있는 노드에서 패킷이 소실될 가능성이 있다.
- 패킷 전달 순서 문제: 여러 패킷을 한 번에 전송할 때, 전송했던 순서와 다르게 서버에 도착할 가능성이 있다.
해당 문제를 해결하기 위해 나온 것이 TCP, UDP 개념이다.
TCP, UDP를 알아보기 전 인터넷 프로토콜 스택의 4 계층을 먼저 살펴보겠다.
인터넷 프로토콜 스택
애플리케이션 계층 | HTTP, FTP | 어떤 데이터를 주거나 받기 위한 서비스를 정의하는 계층 |
전송 계층 | TCP, UDP | 데이터 전송의 신뢰성을 보장하기 위한 계층 |
인터넷 계층 | IP | 패킷이 어떤 라우터를 거쳐 전달되는지 결정하는 계층 |
네트워크 인터페이스 계층 | Ethernet | 인접한 노드로 패킷을 보내기 위한 역할을 하는 계층으로 프레임(frame)이라고 하는 패킷을 만들어 인터넷망에 전송 |
출처: [네트워크] 프로토콜 스택(protocol stack)이란?
TCP (Transmission Control Protocol)
- 역할: 데이터 전송 시 신뢰성을 보장하기 위해 약속해놓은 규범
- 특징
- 3-way handshake
- 클라이언트와 서버는 SYN, SYN+ACK, ACK 과정을 거쳐 연결을 확인한다.
- 가상 연결이 완료되었음을 확인하면 데이터를 전송하기 시작한다.
- 데이터 전달 보증
- 클라이언트가 서버에 데이터를 전송했을 때 서버는 데이터를 잘 받았음을 응답한다.
- 만약 서버에서 응답이 없다면 데이터가 제대로 전송되지 않은 것이다.
- 순서 보장
- 클라이언트에서 서버로 데이터가 전송되었을 때, 서버 내부적으로 패킷에 포함된 순서 정보를 통해 패킷 순서를 추적하고 패킷의 순서가 잘못되었으면 해당 패킷부터 다시 보내라고 클라이언트에 요청한다.
- 예를 들어 클라이언트는 패킷1, 패킷2, 패킷3 순서로 전송했지만, 서버에 패킷1, 패킷3, 패킷2 순서로 전달되었으면 서버는 클라이언트에게 패킷2부터 다시 보내달라는 요청을 하게 된다.
- 3-way handshake
UDP (User Datagram Protocol)
- 역할: TCP와 마찬가지로 데이터 전송 시 신뢰성을 보장하기 위해 약속해놓은 규범
- 특징
- 3-way handshake 기능이 없다.
- 데이터 전달 보증이 없다.
- 순서 보장이 되지 않는다.
- PORT(패킷 구분을 위함)와 체크섬(메시지 검증)만 추가되어 있다.
- 최근 각광받고 있다.
- 장점
- 3-way handshake를 하지 않아 전송 속도가 빠르다.
- 원하는대로 최적화가 가능
PORT
- 역할: 같은 IP 내에서 프로세스를 구분할 때 사용한다.
- 특징
- 0 ~ 65535가 할당 가능한 포트 번호이다.
- 0 ~ 1023은 잘 알려진 포트 번호로 사용하지 않는 것이 좋다.
- FTP-20,21 | TELNET-23 | HTTP-80 | HTTPS-443
DNS (Domain Name System)
- 역할: IP는 변경될 수 있고, 기억하기 어렵기 때문에 도메인 명을 붙여 IP 대신 사용한다.
Summary
- 복잡한 인터넷망에서 메시지를 보내기 위해선 인터넷 프로토콜인 IP가 있어야 한다.
- 하지만 메시지가 잘 도착했는지 확인할 때 IP만으로는 한계가 있어 TCP를 사용해 패킷 소실 문제나 패킷 순서 문제를 일으키지 않도록 보장받는다.
- UDP는 거의 IP와 같은 통신 규범인데 Port 정보를 추가해 같은 IP 내에서 프로세스를 구분할 수 있게 도와준다.
- IP는 변하기 쉽고 외우기 어려워 DNS를 통해 사용하기 용이하도록 했다.
2. URI와 웹 브라우저 요청 흐름
URI (Uniform Resource Identifier)
URI는 URL(Locator)과 URN(Name)을 포괄하는 개념이다.
- URL 전체 문법
- scheme://[userinfo@]host[:port][/path][?query][#fragment]
- scheme: 주로 프로토콜을 작성하고 우리는 http나 https를 사용한다.
- [userinfo@]: URL에 사용자 정보를 포함해서 인증할 때 사용하는데 거의 사용하지 않는다;
- host: 도메인명이나 IP주소를 작성한다. ex) www.google.com
- [:port]: 접속 포트를 작성하는 부분이나 생략하는 것이 일반적이다.
- [/path]: 리소스의 경로를 작성하는 부분이다. ex) /members, /search, /home/file1.jpg
- [?query]: key=value 형태로 ?로 시작하고 &으로 key=value를 추가할 수 있다. 쿼리 파라미터, 쿼리 스트링으로 불린다. ex) ?key1=value1&key2=value2
- [#fragment]: html 내부 북마크 등에 사용하는 것으로 서버에 전송하는 정보는 아니다.
- scheme://[userinfo@]host[:port][/path][?query][#fragment]
웹 브라우저 요청 흐름
1. 웹 브라우저가 인터넷에 https://www.google.com/search?q=hello&hl=ko 요청한다.
2. DNS 서버 조회한다.
2. 요청을 하려는 웹 브라우처는 HTTP 요청 메시지를 생성한다.
GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com
3. HTTP 요청 메시지는 인터넷 프로토콜 4 계층을 거쳐 해당 메시지에 출발지IP, 목적지IP, 그 외의 것들이 붙어 패킷으로 생성된다.
출발지 IP, PORT 목적지 IP, PORT 전송 데이터(이게 HTTP 요청 메시지) 그 외
4. 웹 브라우저는 해당 패킷을 서버에 전송한다.
5. 서버는 HTTP 응답 메시지를 웹 브라우저에 전달한다.
HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Length: 3423 <html> <body>...</body> </html>
6. 웹 브라우저에는 HTML이 렌더링 된다. 성공!
3. HTTP
모든 것이 HTTP
- HTTP: HyperText Transfer Protocol
- 초기에는 HTML을 전송하는 프로토콜이었는데 현재는 모든 형태의 데이터를 전송할 때 사용함
- HTTP 역사
- HTTP/1.1 1997년: 가장 많이 사용하고 우리에게 가장 중요한 버전
- HTTP/3 진행 중: TCP 대신 UDP 사용, 성능 개선 위주
- 기반 프로토콜
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
- HTTP 특징
- 클라이언트 서버 구조로 이뤄져 있음
- 무상태 프로토콜(Stateless), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
클라이언트 서버 구조
- 클라이언트와 서버를 분리하는 것이 중요함
- 비즈니스 로직과 데이터는 서버에, 클라이언트는 UI 사용성에 집중하면 양쪽이 독립적으로 진화할 수 있어 효율적임
- Request Response 구조
- 클라이언트: 서버에 요청을 보내고, 응답을 기다림
- 서버: 요청에 대한 결과를 만들어서 클라이언트에 응답을 보냄
무상태 프로토콜 (Stateless)
Stateful, Stateless 차이
- Stateful: 서버는 클라이언트의 이전 상태를 기억하고 있어 항상 같은 서버로 유지되어야 함 (상태 유지)
- Stateless: 서버는 클라이언트의 이전 상태를 기억 못 하지만, 클라이언트는 서버에 필요한 정보를 모두 제공해 줌 (무상태)
👉🏻 무상태는 응답 서버를 쉽게 바꿀 수 있고, 이는 즉 무한한 서버 증설이 가능(스케일 아웃에 유리)하다는 뜻이다.
- Stateless
- 실무에서의 한계
- 모든 것을 무상태로 설계할 수 있지만, 그렇지 못한 경우도 있음
- 로그인이 필요 없는 단순한 서비스 소개 화면은 무상태 프로토콜 사용이 가능함
- 로그인이 필요한 서비스의 경우, 로그인했다는 상태를 서버에 유지해야 하고, 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지함 -> 상태 유지는 최소한으로 사용해야 하고, 꼭 써야 하는 경우라면 어쩔 수 없이 사용해야 함
- Stateful보다 Stateless가 한 번에 많은 데이터를 전송함
- 실무에서의 한계
비연결성(connectionless)
- 연결을 유지하는 모델
- 연결을 유지하는 동안 리소스가 낭비되는 문제가 발생
- 연결을 유지하지 않는 모델
- TCP/IP로 연결을 하고 요청과 응답이 끝나면 연결을 끊어 서버 유지 자원을 최소한으로 줄일 수 있음
- 특징
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 1시간 동안 수천 명이 서비스를 사용해도 수천 명을 동시에 연결하고 있지 않기 때문에 서버가 실제로 처리하는 요청은 수십 개 이하로 매우 적음
- 서버 자원을 효율적으로 유지 가능함
- 한계와 극복
- 3 way handshake를 통해 TCP/IP 연결을 새로 맺어야 해 연결할 때 시간이 추가됨
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드됨
- 지금은 HTTP 지속 연결(persistent connection)로 문제를 해결함
- Stateless를 기억하자! 티켓팅과 같이 같은 시간에 동시에 몰려오는 대용량 트래픽을 최대한 stateless하게 설계하는 것이 중요함!
HTTP 메시지 구조
- 1️⃣ start-line (시작 라인) = request-line / status-line
- request-line
- request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
- GET /search?q=hello&hl=ko HTTP/1.1
- method
- 종류: GET, POST, PUT, DELETE
- 서버가 수행해야 할 동작 지정
- request-target (요청 대상)
- absolute-path[?query] (절대경로[?쿼리])
- 절대경로 / 로 시작하는 경로
- HTTP-version
- method
- status-line
- status-line = HTTP-version SP status-code SP reason-phrase CRLF
- HTTP/1.1 200 OK
- HTTP-version
- status-code
- 200: 성공
- 400: 클라이언트 요청 오류
- 500: 서버 내부 오류
- reason-phrase: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
- request-line
- 2️⃣ header (헤더)
- header-field = field-name: OWS field-value OWS(띄어쓰기 허용)
- ex)
- Host: www.google.com
- 3️⃣ empty line (공백 라인, CRLF)
- 4️⃣ message body
- 실제 전송할 데이터
HTTP 정리
1. HTTP 메시지에 모든 것을 넣어 전송한다.
2. HTTP 역사 HTTP/1.1을 기준으로 학습한다.
3. 클라이언트 서버 구조이다.
4. 무상태 프로토콜이다.
5. HTTP 메시지 구조
6. HTTP는 단순하고, 확장 가능하다.
7. 지금은 HTTP의 시대이다.
다음 글은 HTTP에 대해 더 자세히 정리해서 가져오겠습니다!
마지막은 웃긴 짤 투척할게요
해당 포스팅은 김영한님의 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 바탕으로 작성했습니다.