HTTP 란?
목적
이번엔 웹에서 사용하는 대표적인 통신 프로토콜, HTTP 를 다뤄보도록 하자.
HTTP(HyperText Transfer Protocol) 란?
딱딱한 표현으로 해보자면, 웹에서 동작하는 클라이언트 - 서버 모델의 프로토콜이다.
또한, 전송 계층 프로토콜로는 TCP 를 사용하고 네트워크 계층 프로토콜로는 IP 를 사용한다.
(딱딱한 표현들은 조만간 다른 게시글로 다루어볼 예정이고, 클라이언트 - 서버 모델은 지금 ‘서버’를 떠올렸을 때 연상되는 구조를 떠올리면 된다)
간단히 이야기 하자면, 웹에서 데이터를 주고 받기 위해 사용하는 통신 방법이다.
기본적으로 클라이언트가 서버에게 요청을 보내면, 서버는 그 요청에 대해 적절한 응답을 보내주는 구조다.
HyperText Transfer Protocol 의 약자인 것 처럼, 처음엔 HTML 파일 전송을 위해 탄생했고 이후 웹이 장악한 이후엔 지금처럼 발전했다.
HTTP 의 특징
HTTP 통신의 대표적인 특징이 두 가지 있는데, 다음과 같다.
- 무상태성(Stateless)
- 비연결성(Connectionless)
무상태성(Stateless)
HTTP는 요청(request) 와 그에 대한 응답(response)이 존재하는 구조로 동작한다. 이때 ‘무상태성’의 경우, 이 구조에서 서버가 처리한 이전 요청이 그 다음에 처리하는 요청과 전혀 상관이 없다는 것이다.
다시 말해, 클라이언트가 요청 A 와 요청 B 를 2개 전송할 때, 요청 A 가 처리 되어야만 요청 B 처리가 가능한 상황은 만들어지지 않는다. 클라이언트는 필요한 요청을 보내고, 서버는 그 요청을 처리해줄 뿐이다.
하지만, 특정 경우(권한 인증 등)에서는 이 무상태성이 걸림돌이 되는 경우가 있었다. 예를 든다면, 로그인을 해야만 사용이 가능하도록 제한을 두는 경우가 있겠다.
이때 사용자하는 매 동작마다 로그인을 요구한다면, 아마 사용자들이 분노에 미쳐버릴 것이다. 그래서 세션 / 쿠키 / 토큰 등의 인증 방식이 등장했다.
비연결성(Connectionless)
‘비연결성’은 요청을 주고 받는 상황 이외엔 어떤 연결도 되어있지 않다는 의미다.
클라이언트가 서버에게 요청을 보내고, 서버가 그에 따라 응답을 보내고 나면 더 이상의 연결은 없다.
클라이언트가 필요하면 요청을 또 다시 보내야하는 것이다.
하지만, 이 역시 문제가 존재했다. 웹이 방대해지면서, 클라이언트와 서버가 공유하는 데이터 또한 많아졌다.
웹 페이지 하나를 조회하는 데도, 여러 개의 파일(html / css / js / 이미지 / 영상 등의 리소스)을 다운로드 할 필요가 있었기 때문이다.
하지만, 비연결성 때문에 하나의 파일을 받으면 TCP/IP 를 통한 연결이 몇 번이나 열렸다 닫혀야했다.
만일 전화 통화를 하는 중인데 한 마디하고 끊은 다음, 다시 전화를 걸어 다음 한 마디를 하고, 이를 매 통화마다 반복해야한다면 통화를 하는 메리트가 없을 지도 모른다.
그래서 HTTP 1.1 부터는 한 번의 전화 통화만으로도 모든 대화를 끝낼 수 있게 개선한 것이다. (요청 전송 시 Connection header 사용함)
이어서 HTTP 2.0 에선 멀티플렉싱, HTTP 3.0 는 TCP 가 아니라 UDP 방식을 이용해 개선했다.
HTTP 요청 / 응답
HTTP 요청과 응답이 어떻게 생겨먹었는지 한 번 알아보자.
요청 / 응답에 따라 들어가는 내용이 조금씩 다르기 때문이다.
HTTP 요청
1
2
3
4
5
<요청라인>
<헤더>
<공백라인>
<본문(필요시)>
- 요청라인: 메소드 종류(GET/POST…), 요청 URL, 사용하는 HTTP 버전 명시.
- 헤더(Header): 요청하는 데이터 타입, 인증 정보 등.
- 공백라인: 헤더가 끝났음을 알림.
- 본문(Body): POST/PUT 요청일 때 전송하는 실제 데이터(예: 폼 데이터, JSON 등).
간단한 요청 메시지 예시를 살펴보자.
1
2
3
4
5
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
앞서 말한 HTTP 구조를 대입해보자.
첫 번째 줄엔, GET /index.html HTTP/1.1 가 있다. HTTP 1.1 버전을 사용해서, /index.html 경로에, GET 요청을 보낸 것이다.
이 다음 줄 부터는 헤더가 시작된다.
요청의 도착지 도메인 정보를 표시하는 Host 헤더, 요청을 보내는 이의 접속 환경(브라우저)를 표시하는 User-Agent 헤더, 응답으로 받을 데이터를 표시하는 Accept 헤더로 이루어져 있다.
물론, 이외에도 정말 다양한 헤더가 존재하는데 여기에서는 다루지 않겠다.
마지막 줄의 공백도 당연히 의도적이다. 본문이 없더라도, 헤더가 끝나는 것은 표기해준다.
HTTP 응답
1
2
3
4
5
<응답라인>
<헤더>
<공백라인>
<본문(필요시)>
- 응답라인: HTTP 버전, 상태코드(200, 404 등), 상태 메시지.
- 헤더: 서버 정보, 컨텐츠 유형/길이 등.
- 공백라인: 헤더가 끝났음을 알림.
- 본문: 요청 결과 데이터 데이터(HTML, JSON 등).
응답도 유사한 구조지만, 담기는 내용이 조금 다르니 참고하자.
이번엔 본문(body) 내용이 담기는 POST 요청을 예시로 살펴보자.
1
2
3
4
5
6
7
POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
username=kim&password=1234
위 예시는 로그인 시 보내는 요청을 가정하고 만들어 보았다.
앞서 설명한 내용은 제외하고, Content-Type 과 Content-Length 헤더를 살펴보자.
Content-Type 헤더는 본문(body) 내용이 어떤 형식의 데이터인지 알려준다.
예시에서 사용한 형식의 경우, key-value 쌍의 데이터를(username=kim, password=1234) 여러 가지(& 를 사용해 연결) 보낼 때 사용하는 유형이다.
다음으로 Content-Length 헤더는 본문의 길이를 알려주는 역할이다. 그리고, 헤더가 끝난 뒤엔 공백으로 구분해주고 본문에 데이터를 담아 보낸다.
이것이 HTTP 요청 / 응답의 구조가 되겠다.
HTTP 메서드
HTTP 에 대해 어느정도 알아보았으니, 사용하는 메서드 종류도 간단히 짚고 넘어가자.
- GET : 존재하는 자원에 대한 요청
- POST : 새로운 자원을 생성
- PUT : 존재하는 자원에 대한 변경 (자원 전체를 갱신)
- PATCH : 존재하는 자원에 대한 변경 (자원 일부를 교체)
- DELETE : 존재하는 자원에 대한 삭제
- OPTIONS : 웹 서버에 지원되는 메서드의 종류를 확인할 경우 사용
이와 관련해서 REST API 설계 원칙을 알아두면 좋은데, 이는 다른 게시글로 다뤄보겠다.
HTTP 상태코드
HTTP 상태코드는 3자리 숫자로 이루어진 형태다.
아마 404 Not Found 는 종종 본 적이 있을 텐데, 그게 바로 이 상태 코드를 통해 표시해주는 것이다.
각각 뜻하는 의미가 다르지만 자세한 내용은 REST API 내용과 다뤄보겠다.
일단 첫 번째 숫자가 의미하는 내용만 이해해보자.
- 1xx : Informational - 요청 정보를 처리 중
- 2xx : Success - 요청을 정상적으로 처리함
- 3xx : Redirection - 요청을 완료하기 위해 추가 동작이 필요함
- 4xx : Client Error - 클라이언트의 요청 오류
- 5xx : Server Error - 서버 측 오류
마무리
HTTP 에 대해 간단히 알아보았다.
꼼꼼히 알아가려면 보다 많은 내용을 다뤄야해 살짝 지치긴 하지만…. 차근차근히 정복해나가도록 하자.