3. HTTP의 기본
오늘날,
HTTP (HyperText Transfer Protocol)
오늘날, HTTP 메세지에 단순한 Text 뿐만 아니라, 사진, 영상, 파일, JSON 등 거의 모든 형태의 데이터를 포함할 수 있다.
서버간의 데이터를 주고 받을때도, 대부분 HTTP를 사용한다.
● HTTP의 역사
| 버전 | 연도 | 특징 |
| HTTP/0.9 | 1991 | GET 메서드만 지원, HTTP Header X |
| HTTP/1.0 | 1996 | 여러 메서드 및 HTTP Header 추가 |
| HTTP/1.1 | 1997 | 오늘날, 가장 많이 사용되고 있는 버전 RFC2068(1997) -> RFC2616(1999) -> RFC7230~7235(2014) |
| HTTP/2 | 2015 | 성능 개선 |
| HTTP/3 | 진행중 | UDP 사용 및 성능 개선 |
오늘날에는, HTTP/1.1 버전을 많이 사용하고 있으며, HTTP/2와 HTTP/3 버전도 점점 증가하는 추세이다.
1.1과 2 버전은 TCP를 사용하는 반면, 3버전은 UDP를 사용한다는 특징이 있다.
HTTP의 특징
● 클라이언트 서버 구조
HTTP는 Request, Response 구조로 구성되어 있다.
클라이언트는 서버에 요청을 보내고, 응답이 올 때까지 대기한다.
서버는 클라이언트의 요청에 맞는 결과를 만들어서 응답한다.
※ 과거에는 서버와 클라이언트가 하나로 이루어져 있었다.
오늘날, 서버는 비즈니스 로직, 클라이언트는 UI를 담당하게 되면서 각 분야가 독립적으로 진화할 수 있게 되었다.
● 무상태(Stateless) 프로토콜
무상태란, 서버가 클라이언트의 상태를 보존하지 않는다는 것을 의미한다.
예를 들어, 사칙연산을 계산해주는 서버가 있다고 해보자.
상태유지(Stateful)인 경우에는 아래와 같이 동작한다.
클라이언트 : 1+1은 뭔가요 ?
서버 : 2 입니다.
클라이언트 : 그럼 거기다가 2를 곱해주세요
서버 : 4 입니다.
서버에서 클라이언트의 상태(결과값)를 저장하고 있고, 이후 요청이 들어오면 이에 맞게 동작하게 된다.
무상태(Stateless)인 경우에는 위와 다르게 동작한다.
클라이언트 : 1+1은 뭔가요 ?
서버 : 2 입니다.
클라이언트 : 그럼 거기다가 2를 곱해주세요
서버 : ???? (뭐에다가 2를 곱하라는 거지 ?)
서버는 클라이언트의 상태를 저장하고 있지 않기 때문에, 올바르게 동작할 수 없다.
이러한 무상태 환경에서는 아래와 같이 요청해야 정상적으로 동작할 수 있다.
클라이언트 : 1+1은 뭔가요 ?
서버 : 2 입니다.
클라이언트 : 2에다가 2를 곱해주세요
서버 : 4 입니다.
즉, 무상태 환경에서는 클라이언트가 서버에 요청을 할 때, 자신의 상태를 나타낼 수 있어야 한다.
상태 유지 환경에서는 서버와 클라이언트가 1:1로 유지되어야 하기 때문에, 중간에 서버가 끊기거나 클라이언트 요청이 증가할 경우 문제가 발생할 수 있다.
하지만, 무상태 환경에서는 응답 서버를 쉽게 바꿀 수 있기 때문에, 중간에 서버가 끊기더라도 문제가 발생하지 않는다.
또한, Scale Out(수평 확장)이라는 같은 기능을하는 서버 확장에 매우 유리하다는 장점이 있다.
이론적으로는 반드시 무상태로 설계하는 것이 좋지만, 현실적으로 모든 것을 무상태로 설계할 수 는 없다.
특정 웹 사이트에 로그인하여, 상태를 유지해야하는 경우가 있기 때문이다.
일반적으로는 쿠키와 세션을 사용하여 상태를 유지한다.
● 비 연결성 (Connectionless)
여러 클라이언트가 서버와 연결을 유지하고 있을 경우, 서버의 자원이 낭비된다.
HTTP는 기본적으로 연결을 유지하지 않는 모델이며, 일반적으로 초 단위 이하의 빠른 속도로 처리된다.
비 연결성으로 연결되어있기 때문에, 서버의 자원을 매우 효율적으로 사용할 수 있다.
비 연결성의 한계 및 극복
1. TCP/IP 연결을 매번 새로 맺어야 한다.
3 way handshake로 인해, 시간이 오래 걸린다.
2. 웹 브라우저로 사이트를 요청하면, 단순히 HTML 뿐만 아니라 여러 데이터(이미지 등)가 함께 다운로드 된다.
지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
기존에는, 요청에 대한 응답을 보내면 연결이 끊어졌다.
하지만, 한계 2와 같이, HTML 파일 내에서 여러 데이터를 받아야 하는 경우가 빈번하며, 매번 서버 - 클라이언트간의 연결을 맺고 끊는 것은 엄청난 성능 저하로 이어지게 된다.
개발 로직마다 다르긴 하지만, 일반적으로 응답 HTML 메세지가 처리될 때까지 일시적으로 연결을 유지하는 지속 연결을 사용하여 위의 단점들을 해결하게 되었다.
● HTTP 메세지
HTTP 메세지는 아래와 같은 구조로 이루어져 있다
| start-line : 시작 라인 |
| header : 헤더 |
| empty line : 공백 라인(CRLF) |
| message body |
● start-line(요청 메세지)
start-line은 request-line과 status-line으로 구분되어 있고, 요청 메세지에서는 request-line으로만 구성되어있다.
request-line = method SP request-target SP HTTP-version CRLF
※SP = 스페이스 바, CRLF = Enter
● method
서버가 수행해야 할 동작을 지정해주는 것으로, GET, POST, PUT, DELETE 등이 있다.
GET - Resource 조회
POST - 요청 내역 처리
＊HTTP 메서드에 대해서는 이후에 자세히 다룰 예정이다.
● request-target
절대 경로 및 Query문을 사용한다.
● start-line (응답 메세지)
start-line은 request-line과 status-line으로 구분되어 있고, 응답 메세지에서는 status-line으로만 구성되어있다.
status-line = HTTP-version SP status-code SP reason-phrase CRLF
● status-code
요청 성공, 실패를 나타내는 코드이다.
200 : 성공
400 : 클라이언트 요청 오류
500 : 서버 내부 오류
● HTTP 헤더
HTTP 전송에 필요한 모든 부가 정보를 포함하고 있다.
ex) Message body의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보 등
header-field = filed-name":" OWS field-value OWS
※OWS = 띄어쓰기 허용
filed-name은 대소문자 구분이 없다.
● HTTP Message body
실제 전송할 데이터가 존재하는 영역으로써, HTML 문서, 이미지 등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.