모든 것이 HTTP
1. HTTP는 HyperText Transfer Protocol의 약자이다.
즉 html 문서를 전송하는 프로토콜로 시작되었는데, 현재는 이미지, 음성, 영상, 파일, JSON, XML 등 거의 모든 형태의 데이터를 HTTP 프로토콜에 담아 전송한다. 서버 간에 데이터를 주고받을 때에도 사용한다!
TCP 위에서 HTTP 프로토콜이 동작하긴 하지만, TCP로 직접 연결해서 사용하는 경우는 게임 서버 등 특수한 경우가 아니면 없다. (심지어 모바일 게임은 HTTP로 통신하는 구조로 개발하기도 한다.)
2. HTTP 역사
- HTTP/0.9 : GET 메소드만 지원 (HTTP 헤더 없음)
- HTTP/1.0 : 메소드, 헤더 추가
- HTTP/1.1 : 현재 가장 많이 사용하는 버전
(1.1 스펙에 대부분의 기능이 다 들어있고, 2~3은 성능 개선에 초점이 맞춰져있다.) - HTTP/2 : 성능 개선
- HTTP/3 : 성능 개선 (TCP 대신 UDP 사용)
3. HTTP/1.1, HTTP/2 는 TCP를 사용하고 HTTP/3은 UDP를 사용한다.
TCP는 안정적이지만 3way-handshake를 진행해야하기 때문에 시간이 많이 소요된다. 따라서 TCP 대신 UDP 프로토콜 위에 애플리케이션 레벨에서 성능을 최적화하도록 설계해서 나온게 HTTP/3이다.
개발자도구 > Network 에서 Protocol을 확인해보면 h2, h3가 HTTP/2, HTTP/3에 해당한다. 사용이 점점 증가하고 있음을 확인할 수 있다.
클라이언트 서버 구조
HTTP는 클라이언트 서버 구조로 되어있다. 클라이언트가 HTTP메세지를 통해 서버에 요청을 보내고, 클라이언트는 서버로부터 응답이 올 때까지 기다린다. 서버가 요청에 대한 결과를 만들어 응답하면, 응답 결과를 열어서 클라이언트가 동작하는 단순한 구조이다.
클라이언트와 서버를 개념적으로 분리하여, 서버는 비즈니스 로직과 데이터에 집중하고, 클라이언트는 UI를 그리는 부분에 집중하면 각각 독립적으로 진화할 수 있다.
무상태(Stateless)
HTTP는 무상태(Stateless) 프로토콜을 지향한다는 특징이 있다. 서버가 클라이언트의 상태를 보존하지 않는다는 뜻이다.
| Stateful (상태 유지) | Stateless (무상태) |
| Client : A는 얼마인가요? Server : 100원입니다. Client : 3개 주세요. Server : 300원입니다. (A 라는 상태 유지O) |
Client : A는 얼마인가요? Server : 100원입니다. Client : 3개 주세요. Server : 무엇을 3개 드릴까요? (A 라는 상태 유지X) |
상태 유지에서는 Server가 중간에 다른 Server로 변경되면 장애가 발생한다. 혹은 계속 통신하던 서버가 장애나서 죽어버리면, 다른 서버에서 처음부터 진행해야한다.
무상태에서는 Client가 요청할 때 데이터가 많아지지만, Server가 변경되어도 문제없이 응답할 수 있다. 백엔드 개발 측면에서는 갑자기 클라이언트 요청이 증가하더라도, 간단하게 서버를 증설하면 된다고 이해할 수 있다. (scale out에 유리하다.)
로그인 정보를 유지시켜야하는 경우 등 상태를 유지해야하는 경우도 분명히 있다. 이때는 쿠키, 세션을 조합하여 상태 유지하는 기능을 쓴다. 하지만 정말 어쩔 수 없는 경우에 한해서만 상태 유지를 하도록 한다.
비연결성(connectionless)
TCP/IP의 경우에는 연결을 유지하는게 기본적이다. TCP/IP 소켓을 연결한 다음 요청/응답을 주고받으면 연결이 유지된다. 다른 클라이언트가 요청/응답을 주고받을 때에도 연결이 유지되고 있다. 이는 서버 자원이 계속 소모되고있음을 의미한다.
HTTP는 기본적으로 연결을 유지하지 않는 모델이다. TCP/IP로 연결한 뒤 요청/응답을 주고받으면 연결을 바로 끊어버린다. 서버가 유지하는 자원을 최소한으로 줄이기 때문에, 수천명이 서비스를 사용하더라도 실제 동시에 처리하는 요청은 매우 적다. 하지만 요청할 때마다 TCP/IP 연결을 새로 맺어야하고, 그 말은 곧 3way handshake하는 시간이 계속 추가되어 속도가 느려진다는 단점이 있다.
그래서 HTTP는 Persistent Connection이라는 지속 연결을 기본적으로 쓴다. 하나의 자원을 요청하고 응답받기 전 후로 연결/종료를 반복하면 너무 비효율적이니, 클라이언트와 서버를 한번 연결한 뒤 여러 자원들에 대해 모두 요청하고 응답받은 후 연결을 종료시킨다.
HTTP/2, HTTP/3에서는 이 속도를 더 빠르게 최적화시켰고, HTTP/3은 UDP 프로토콜을 사용하여 연결 시간 자체를 줄였다.
HTTP 메시지
http 메시지는 아래와 같은 구조를 갖는다.
| start-line (시작 라인) header (헤더) empty line (공백 라인/CRLF) *필수 message body |
요청 메시지 예시 (요청 메시지도 body 본문을 가질 수 있음)
| GET /search?q=hello&hl=ko HTTP/1.1 Host: www.google.com |
응담 메시지 예시
| HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Length: 3423 <html> <body>...</body> </html> |
1. 시작 라인
요청 메시지에서는 request-line 이라고 하고, 응답 메시지에서는 status-line 이라고 한다.
1) request-line
- 구조 : method SP request-target SP HTTP-version CRLF
- SP : 공백
- CRLF : 엔터
- HTTP 메소드 GET /search?q=hello&hl=ko HTTP/1.1
- 종류 : GET(리소스 조회), POST(요청 내역 처리), PUT, DELETE
- 서버가 수행해야 할 동작을 지정한다.
- 요청 대상 GET /search?q=hello&hl=ko HTTP/1.1
- absolute-path[?query] 형태로, 보통 절대 경로와 쿼리를 합쳐서 작성한다.
- 절대 경로는 "/" 로 시작하는 경로를 말한다.
- HTTP 버전 GET /search?q=hello&hl=ko HTTP/1.1
2) status-line
- 구조 : HTTP-verison SP status-code SP reason-phrase CRLF
- HTTP 버전 HTTP/1.1 200 OK
- HTTP 상태 코드 HTTP/1.1 200 OK
- 200 : 성공
- 400 : 클라이언트 요청 오류
- 500 : 서버 내부 오류
- 이유 문구 HTTP/1.1 200 OK
2. HTTP 헤더
- 구조 : field-name ":" OWS field-value OWS
- OWS : 띄어쓰기 허용
- field-name과 : 사이에 띄어쓰기 없어야한다.
- field-name은 대소문자를 구분하지 않는다.
- 메시지 바디의 형태(XML, HTML..), 압축 여부, 인증 정보, 요청 클라이언트의 웹 브라우저 정보, 캐시 등 HTTP 전송에 필요한 모든 부가 정보(메타 데이터)가 다 들어있다.
- 표준 헤더 필드 외에 임의의 헤더도 사용 가능하다. 약속한 클라이언트와 서버 간에 데이터를 전송할 수 있다.
3. 메시지 바디
- 실제로 전송할 데이터가 들어간다.
- HTML 문서, 이미지, 영상, JSON 등 바이트로 표현할 수 있는 모든 데이터를 전송할 수 있다.
이 포스팅은 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 수강하며 작성되었습니다.
모든 개발자를 위한 HTTP 웹 기본 지식 | 김영한 - 인프런
김영한 | 실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., [사진] 📣 확인해주세요!본 강의는 자바 스프링 완전 정복 시리즈의 세 번째 강의입니다. 우아한형제들 최연
www.inflearn.com
'IT 지식' 카테고리의 다른 글
| [HTTP] HTTP 메서드 활용 (0) | 2024.04.04 |
|---|---|
| [HTTP] HTTP 메서드 (0) | 2024.04.02 |
| [HTTP] URI와 웹 브라우저 요청 흐름 (0) | 2024.03.31 |
| [HTTP] 인터넷 네트워크 (0) | 2024.03.26 |
| 크롬 개발자 도구 (0) | 2024.03.06 |
