특징
•
www에서 쓰이는 핵심 프로토콜이다.
•
문서의 전송을 위해 사용되며 오늘날 거의 모든 웹 어플리케이션에서 사용되고 있다.
◦
음성, 화상 등 여러 종류의 데이터를 MIME로 정의하여 사용 가능
•
Request / Response 동작에 기반하여 서비스를 제공한다.
•
버전별 특징
1.
HTTP/0.9
•
GET 메소드만 지원, HTTP 헤더가 존재하지 않는다.
2.
HTTP/1.0 : method, header, status code 추가
•
통신 시마다 TCP 연결 수립 과정을 거쳐야하므로 비효율적이었다.
◦
다만 Persistent Connection을 클라이언트가 HTTP 요청 시, 헤더에 추가(connection:keep-alive)하여 보내면 Keep-Alive가 생성된다.
◦
수동으로 처리해주어야 했다.
3.
HTTP/1.1 - 표준 프로토콜
•
커넥션 유지
◦
Persistent Connection을 기본적으로 지원하여 통신이 종료되기 전까지 TCP 세션이 유지된다.
◦
응답이 종료된 후, TCP 연결을 끊어야 하는 경우, Connection Header를 사용한다.
•
호스트 헤더
◦
1.1부터 호스트 헤더를 추가하여 가상 호스팅이 가능해졌다.
•
강력한 인증 절차
◦
proxy-authentication, proxy-authorization 총 2개의 헤더가 추가되었다.
◦
서버에서 클라이언트 인증/인가를 요구하는 www-authentication 헤더는 1.0부터 지원했으나 클라이언트와 서버 사이에 프록시가 위치하는 경우, 프록시가 클라이언트의 인증을 요구할 수 있는 방법이 없었다.
•
Pipelining의 등장
◦
하나의 연결에 여러 요청이 존재할 때, 각 요청을 하나 씩 처리하지 않고 순차적으로 보낸 후, 순차적으로 응답받는 방식으로 지연 시간을 줄이는 방식이다.
◦
완전한 멀티플렉싱이 아닌 응답처리를 미루는 방식으로 각 응답의 처리가 순차적으로 처리되므로 후순위의 응답이 지연될 수 밖에 없었기 때문이다.
4.
HTTP/2.0
•
1.1은 기본적으로 세션 당 하나의 요청/응답을 동기적으로 처리하기 때문에 동시 전송 문제와 다수의 리소스를 처리하기에 속도와 성능 이슈를 가지고 있다.
•
이로 인해 Head of Line Blocking(특정 응답 지연), RTT(Round Trip Time) 증가, 무거운 헤더 구조라는 문제점이 있었고 이를 해결하기 위해 등장했다.
•
Multiplexed Streams
◦
하나의 세션에 여러 개의 메시지를 동시에 주고 받을 수 있는 기능이다.
◦
요청이 세션 상에서 다중화되므로 Head of Line Blocking이 발생하지 않는다.
•
Stream Prioritization
◦
요청 리소스 간 의존 관계를 설정하는 것이다.
•
Header Compression
◦
헤더 정보를 HPACK 압축 방식을 이용하여 압축 전송한다.
◦
요청 작업들 간 헤더가 유사한 경우가 많은 경우 사용하며 전송된 데이터의 중복과 오버헤드가 제거된다.
•
Server Push
◦
서버가 클라이언트 캐시에 데이터를 저장할 수 있게해 HTML 문서 상에 필요한 리소스를 클라이언트의 요청 없이도 보내줄 수 있다.
•
프로토콜 협상 메커니즘
◦
프로토콜 버전이나 형식 자체를 선택할 수 있게 지원한다.
•
기존 1.1은 Body가 문자열로 이루어져 있지만 해당 버전부터는 Bianry Framing Layer라고 하는 공간에 이진 데이터로 전송된다.
5.
HTTP/3.0
•
구글에서 개발한 UDP 기반의 전송 프로토콜인 QUIC를 사용한다.
HTTP 프로토콜
•
요청 구조
•
요청하는 방식을 정의하며 클라이언트의 정보를 담고 있다.
•
응답 구조
◦
사용자가 볼 웹 페이지를 담고 있는 응답 프로토콜 구조다.
•
Request Line은 HTTP 메소드, URI, HTTP 버전이 공백으로 구분되어 이루어져있다.
•
General Headers은 Message Body에서 전송되는 데이터 관련이 없으며 요청과 응답 모두 사용한다.
◦
Date, Pragma(캐시제어) Cache-Control 등이 존재한다.
•
Request Headers는 HTTP 요청에서만 사용하며 자원이나 클라이언트 자체에 대한 정보를 가지고 있다.
◦
Host, User-agent, Accept, Cookie, Authorization 등이 존재한다.
•
Response Header는 위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적인 정보를 가지고 있다.
◦
Server, Age, Referrer-policy, Set-Cookie 등이 존재한다.
•
Entity Hedaers는 Message Body에 대한 자세한 정보를 가지고 있다.
◦
Content-type, Content-Length, Content-Encoding, Allow, ETag 등
•
Message Body는 본문을 담고 있다.
HTTP 메소드
•
GET
◦
리소스를 조회한다. 조회 시, 요청하고 싶은 데이터는 보통 쿼리 스트링을 사용해서 전달한다.
▪
메시지 바디를 사용해서 데이터를 전달할 수는 있지만 서버에서 따로 이에 대한 처리를 해주어야하므로 지원하는 곳이 많지 않으므로 권장하지는 않는다.
◦
조회 시, POST를 사용해도 되지만 GET 메소드는 캐싱이 가능하므로 GET을 사용하는 것이 유리하다.
▪
반대로 캐싱이 아닌 실시간 정보를 확인하고 싶다면 POST로 조회할 수도 있겠다.
•
POST
◦
전달한 데이터를 처리하는 데 사용하는 메소드다. 보통 생성 요청 메소드로 자주 사용된다.
◦
메시디 바디를 통해 서버로 요청 데이터를 전달하면 서버는 요청 데이터를 처리한다.
◦
전달되는 데이터로는 주로 신규 리소스 등록을 위한 데이터나 어떠한 처리를 요청하는 데 필요한 데이터가 있다.
•
PUT
◦
리소스를 대체하는 메소드다. 해당 리소스가 없으면 생성한다.
•
PATCH
◦
리소스를 부분 대체하는 메소드다.
•
DELETE
◦
리소스를 삭제하는 메소드다.
Status Code
•
1XX
◦
요청을 받았으며 프로세스를 처리하고 있다는 것을 의미한다. 거의 사용되지 않는다.
•
2XX
◦
요청을 성공적으로 처리했을 때 사용하는 코드다.
•
3XX
◦
요청 완료를 위해 웹 브라우저에서 추가 작업이 필요한 경우 사용한다. 리다이렉션의 개념이 필요하다.
•
4XX
◦
클라이언트의 오류다. 요청의 문법이 잘못되었거나 API 스펙에 명시된대로 요청하지 않은 경우가 속한다.
•
5XX
◦
서버측의 오류로 서버가 요청을 정상적으로 처리하지 못하는 경우 주로 사용한다.
