개요

HyperText Transfer Protocol, 줄여서 HTTP.
현재 웹 생태계에서 돌아가는 모든 응용 어플리케이션의 기본 통신 프로토콜이다.
웹의 탄생 배경에 이 프로토콜이 위치한다고 봐도 좋을 정도이다.

기본적으로는 대학 간 연구 문서를 빠르게 공유하기 위해 탄생했고, 그래서 이름이 텍스트 전송 프로토콜이다.
그 당시 HTML 파일을 네트워크를 통해 전달하기 위한 방법들이 개발되기 시작했는데, 이때 웹 브라우저로 html 파일을 전송할 수 있도록 개발된 것이 http이다.
처음에는 매우 단순한 파일만 주고받는데 그쳤는데, 점차 발전하면서 복잡한 기능을 담을 수 있게 됐다.

특징

대표적인 특징들을 정리한다.

• stateless 하다.
  • 한번의 요청에는 한번의 응답으로 끝을 맺고, 서로의 연결 정보를 저장하지 않는다.
  • 이건 http 기원이 애초에 파일을 주고받기 위한 프로토콜이었기 때문에 그런데, 이를 보완하는 다양한 기술들이 또 등장했다.
  • 대표적으로 세션, 쿠키가 있고, 새로운 프로토콜로서는 WebSocket과 같은 것이 등장했다.
• text 평문으로 데이터를 전송한다.
  • 전달하는 데이터는 전부 텍스트 형식으로, 직접 패킷을 까봐도 사람이 읽기 쉽게 돼있다.
  • 또한 주고 받는 데이터에는 어떠한 암호화도 이뤄지지 않는다.
  • 이것을 보완하고자 나온 게 [[#HTTPS]]인데, 아래 참고.
• TCP 기반
  • 4계층 프로토콜로 TCP를 사용하기에 신뢰성 있게 트래픽을 전달한다.
  • 기본적으로 HTTP 한 요청에 대해 한번에 TCP 연결이 수립된다.

기본적인 특징은 이렇고, HTTP는 잘 알려진 프로토콜 중 하나로서 보통 80번 포트를 이용한다.

구조

HTTP에서는 요청(Request)과 응답(Response), 두 가지 종류의 메시지가 존재한다.
말 그대로 요청은 어떤 데이터를 요구하는 트래픽이고 이에 대해서 반환하는 것이 응답 트래픽이다.

두 메시지 모두 기본 구조 자체는 이런 식으로 생겼다.
먼저 시작점(start line, 응답의 경우 status line 이라고 부른다.)에서 어떤 식으로 보내는 요청인지를 명시한다.
위의 요청은 /test.html 경로로 GET 메서드 요청을 날린다는 것을 의미한다.
이후 헤더에는 이 요청의 추가 정보들이 담겨져있다.
이후 빈칸을 한 번 둔 뒤에 요청의 핵심이 될 만한 어떤 내용을 바디로 담아서 보낸다.
응답 메시지 역시 구조는 똑같다.

재밌는 점 중 하나는 각 구분이 개행문자로 이뤄진다는 것이다.
즉 HTTP의 메시지는 전부 text 형식으로 전송된다.

요청 주소 구조

http://www.naver.com:80/posts?name=dd&content=ff

http 요청을 보낼 때 사용하는 주소는 대충 이런 식으로 생겼다.
이것은 URL이라 부르는데 자세한 건 해당 문서 참고.

메서드(method)

http에서는 이 요청이 무엇을 하려는 동작인지를 프로토콜 단에서 명시적으로 지정하는 것이 가능한데, 이것을 메서드라고 부른다.
같은 경로로 보내는 요청이라도 메서드에 따라서 서버는 다른 요청으로 인식하고 수행할 수 있다는 것이 장점이다.
가령 /test.html이란 경로에 GET으로 요청하면 html 파일을 달라는 요청이지만, POST로 요청을 날린다면 html 파일을 만들어달라는 요청으로 활용하는 것이 가능하다는 말이다.

• 주요 메서드- 흔히 CRUD에 맞춰서 활용되며, 이밖에도 다양한 기능을 구현하는데 기본이 된다.
  • GET - 데이터 조회
  • POST - 데이터 생성, 처리
  • PUT - 데이터 변경, 없으면 생성
  • PATCH - 데이터 부분 변경
  • DELETE - 데이터 삭제
• 기타
  • HEAD - 상태줄과 헤더만 요청
  • OPTIONS - 통신 관련 옵션 요청(CORS에서 활용한다.)
  • CONNECT - 지속 연결 설정

주요 메서드 쪽은 용도가 이렇게 지정돼있지만, 실제로 구현하는 것은 서버를 만드는 사람 마음이다.
게시판 서버를 만들었다고 쳤을 때, 누군가는 get 요청에 대해 게시판 글 생성 로직을 구현할 수도 있는 것이다..
여기에 자잘한 메서드 별 특징이 있기는 하다.
가령 GET, DELETE는 기본 규약 상에서는 바디를 가지지 못한다.

응답 코드

응답이 돌아갈 때 status line에는 요청이 어떻게 수행됐는지에 대한 응답 코드가 담긴다.
100번부터 500번까지 있는데, 첫번째 자리수에 따라 가지는 의미가 조금씩 다르다.

• 1XX - 정보 제공
  • 요청이 처리는 됐고, 추가 작업을 진행 중임을 미리 반환하는 코드
  • 101 - 프로토콜을 전환할 때 사용하는 코드로, WebSocket으로 통신을 전환할 때 응답으로 가는 경우가 많다.
• 2XX - 성공
  • 요청이 성공적으로 수행됐고, 응답을 반환하는 코드
  • 200 - 너무 잘 성공했다!
  • 204 - 성공은 했고, 응답에 바디는 없다.
• 3XX - 리다이렉트
  • 다른 곳으로 다시 요청하라고 응답하는 코드
  • 흔히 HTTP 포트로 요청이 들어오면 HTTPS 포트로 다시 요청하라고 이 코드를 보낸다.
  • 301 - 헤더에 Location을 담을 테니 그쪽으로 다시 요청해라
  • 307 - 위와 같은데, 메서드도 유지하고 앞으로 그쪽으로 요청해라
• 4XX - 클라이언트 에러
  • 요청을 보낸 측의 잘못으로 요청이 수행될 수 없음을 나타내는 코드
  • 400 - 구문 자체가 잘못됐다.
  • 401 - 클라는 인증되지 않았다(권한이 없을 때도 쓰기도 한다).
  • 403 - 클라는 권한이 없어 금지됐다.
  • 404 - 해당 주소에 데이터가 없다.
• 5XX - 서버 에러
  • 서버 측의 이슈로 요청이 수행될 수 없음을 나타내는 코드
  • 500 - 서버가 에러 나서 요청을 수행할 수 없다.
  • 501 - 해당 메서드에 대해 구현된 수행 로직이 없다.
  • 502 - 뒷단에 위치한 백엔드 서버가 응답을 못할 때 앞단의 프록시가 반환하는 응답.
  • 504 - 프록시가 백엔드로부터 기다리다 시간 초과 났다.

이것들도 역시 구현하는 개발자가 입맛대로 지정할 수 있다.
근데 웬만해서 다양한 웹 프레임워크나 브라우저들은 이 의미를 명확하게 지키며 동작하는 경우가 많기 때문에, 가급적 이것들을 지켜주는 것이 좋다.
특히 100번, 300번 코드는 명확하게 지정된 대로만 사용하는 게 좋다.

HTTPS

기본 HTTP는 데이터를 평문으로 전달하기 때문에 중간자가 패킷을 탈취해서 내용을 들여다보기 쉽다.
이를 막기 위해 데이터를 암호화해서 통신하는 방식이 바로 HTTPS로, S는 그냥 Secure을 의미한다.
HTTPS 프로토콜은 암호화를 위해 TLS 프로토콜을 활용한다.
HTTPS의 과정은 TLS#Handshaking Protocol 참고.

HTTP/2

HTTP/2는 기존 HTTP의 한계를 벗어나 조금 더 성능을 향상시키기 위해 등장한 2버전이다.^[1]
원래는 구글에서 SPDY라는 프로토콜을 만든 게 원조였다고 하는데, 이후에 아예 이 기술이 조금 더 표준화돼 HTTP2로 자리매김됐다.
HTTP/1를 업그레이드한 버전이, 최대한 변경점을 위주로 정리한다.^[2]

전송 데이터

기존 HTTP는 데이터를 text로 전송하며, 각 구분점이 개행 문자로 이뤄진다고 했다.
하지만 바이너리로 모든 데이터를 해석하는 컴퓨터 세계에서 사실 text는 그다지 효율적인 방식이 아니다.
그래서 HTTP/2는 데이터를 바이너리 프레임으로 인코딩하여 전송한다.

멀티플렉싱(multiplexing)

여러 스트림을 뚫고 이를 통해 여러 데이터를 병렬적으로, 응답에 상관없이 주고받는 방식을 멀티플렉싱이라고 한다.
기존 HTTP는 하나의 요청을 보내고 응답이 오기전까지 다음 요청을 보낼 수 없었다.
HTTP/2에서는 하나의 TCP 커넥션에서 여러 요청을 병렬적으로 보내고 서버 역시 처리한 순서대로 응답하는 것이 가능하다.
이게 가능한 이유는 HTTP2가 전송에 필요한 개념을 더욱 세분화하여 관리하기 때문이다.

엔보이를 보면 코덱이란 표현이 나오길래 뭔가해서 정리해봤다.

HTTP/3

관련 문서

참고