HTTP
HTTP
HTTP(HyperText Transfer Protocol)은 인터넷에서 가장 많이 쓰이는, 기본이라고 할 수 있는 프로토콜이다. 우리가 URL을 사용할 때 가장 앞에 붙는 http가 이 HTTP를 의미한다.
네트워크 통신의 방법으로는 크게 두 가지가 있는데 하나가 저번 포스티에서 봤던 TCP 등을 이용한 Socket방식이고, 나머지 하나가 이 HTTP 통신이다.
HTTP는 하이퍼 텍스트를 주고받기 위한 통신 규약이다. 이전 포스팅에서 공부했던 HTTP 메시지를 통해서 텍스트, 이미지, 음성, JSON등 수많은 종류의 데이터를 전송하는 것이 가능하다. 현재 HTTP 1.1버전을 가장 많이 사용하고 있다.
HTTP의 특징은 다음과 같다.
- 클라이언트-서버 구조
- 무상태(Stateless) 프로토콜
- 비연결성
- HTTP 메시지
- 단순하고 확장이 용이함
클라이언트-서버 구조
HTTP에서는 이전 포스팅에서 보았던 것과 같은 클라이언트-서버 구조로 통신을 하게된다. 사용자인 클라이언트는 서버에 요청을 보내고 응답을 대기한다. 생산자라 할 수 있는 서버는 요청에 대한 결과를 만들어내 응답한다.
이 때 클라이언트는 UI,UX 등 사용자의 이용 편의성에 집중하고, 서버는 비즈니스 로직, 데이터 처리 등의 연산에 집중하게 된다.
무상태(Stateless) 프로토콜
프로토콜이 무상태(Stateless)라는 것은 서버가 클라이언트의 상태를 보존하지 않는다는 것을 의미한다. 즉 모든 서버가 클라이언트의 상태를 알지 못하는 상태이므로 하나의 클라이언트 요청에 여러 개의 응답 서버를 바꿔가며 대응할 수 있는 것이다.
예를 들어 디렉토리의 파일을 요청한다고 가정해보자. A 디렉토리에 있는 파일 B를 요청하는데 두번에 나눠 요청해보겠다.
서버가 상태를 유지한다면, 즉 Stateful 하다면 클라이언트가 A를 요청하고 이후 B를 요청해도 문제 없이 요청을 처리해 줄 것이다. 클라이언트가 이전에 A를 요청한 것을 저장하고 있기 때문이다.
하지만 만약 Stateless한 서버라면 클라이언트가 A를 요청한 후 B를 요청하면 요청을 제대로 수행할 수 없을 것이다. A를 요청한 것을 저장하지 않아 어느 디렉토리의 B인지 모르기 때문이다. 따라서 두 번째 요청에 추가 정보를 넣어 A의 B를 요청해야 한다.
Stateful한 서버에선 하나의 서버가 계속해서 해당 클라이언트를 담당해야 하는 반면, Stateless한 서버에선 A의 요청을 받은 후 B의 요청을 다른 서버가 받아도 아무 문제가 없다는 것을 알 수 있을 것이다.
따라서 중간에 서버가 오류가 발생하더라도 다른 서버로 빠르게 치환하여 요청의 처리가 가능하고, 갑자기 클라이언트의 요청이 폭증하더라도 대규모의 서버를 긴급히 투입할 수 있는 장점이 있다.
모든 서버를 Stateless하게 만들 순 없다. 로그인과 같이 분명 클라이언트의 정보를 저장해야만 하는 경우도 있기 때문이다. 최대한 Stateless하게 만들며 Stateful은 최소한으로 유지하는 것이 중요하다.
비연결성
네트워크엔 연결을 유지하는 모델과 그렇지 않은 모델이 있는데, 이전에 배웠던 Socket을 사용한 TCP/IP 모델은 연결을 유지하는 모델이다. 3-way handshake로 논리적 연결을 성립시킨 후 따로 클라이언트에서 요청이 없더라도 계속해서 연결을 유지한다.
반면에 HTTP는 연결을 유지하지 않는 모델이다. TCP/IP 연결로 요청과 응답을 주고받은 뒤, 연결을 즉시 해제한다. 이와 같이 연결을 유지하지 않는 이유는 많은 사용자가 서비스를 동시에 사용중이더라도 실제로 서버가 동시에 처리하는 요청은 사용자 수에 비해 적기 때문이다. 모든 사용자가 웹페이지에서 버튼을 연속적으로 누르진 않는다는걸 생각하면 된다.
이와 같은 방법은 대신 웹페이지를 새로 요청할 때마다 수많은 데이터들이 함께 다운로드 되는데 그 때마다 3-way handshake를 해야하므로 시간이 오래 걸렸다.
지금은 HTTP 지속 연결로 해당 문제를 극복했는데, 필요한 자원이 있을 때마다 연결을 다시하는 것이 아니라 한 페이지에 필요한 자원을 모두 받을 때까지 연결을 유지하고 있는 것이다.
HTTP 메시지
전에 배웠듯 HTTP 모델에서 클라이언트와 서버는 각자 HTTP 요청 메시지와 HTTP 응답 메시지를 보내며 통신한다.
HTTP 메시지의 구조는 위와 같은데, HTTP 요청 메시지와 HTTP 응답 메시지는 start-line 부분만 차이가 있다. 요청 메시지에서는 start-line에 method request-target HTTP-version의 구조로 된 요청 메시지를 입력한다.
method는 서버가 수행해야 할 동작을, request-target은 absoulte-path[?query]의 구조로 요청 대상을 지정한다. HTTP-version은 말 그대로 버전으로 보통 HTTP/1.1을 적는다.
응답 메시지에서는 start-line에 HTTP-version status-code reason-phrase의 구조로 된 응답 메시지를 입력한다. HTTP-version은 위에서 말했던 것과 같은 버전, status-code는 200=성공, 400=클라이언트 요청 오류 등 미리 의미가 지정된 숫자 코드를 입력한다. reason-phrase는 사람이 이해할 수 있는 짧은 코드 설명이 들어간다.
header에는 HTTP 전송에 필요한 부가정보들이 들어가는데, 메시지 바디의 크기, 인증, 브라우저 정보 등등이 들어간다. 구조는 field-name : field-value(띄어쓰기 허용)과 같이 작성한다.
메시지 바디에는 실제로 전송할 문서,이미지,영상 등의 데이터가 들어간다. byte로 표현할 수 있는 데이터라면 뭐든지 전송할 수 있다.
지금까지 HTTP에 대해 알아보았다. 다음 포스팅에서는 HTTP API의 설계에 대해 알아보겠다.