HTTP(HyperText Transfer Protocol)는 클라이언트(웹 브라우저)와 서버 간 특정 컨텐츠에 대한 요청(Request)과 응답(Response)이 이루어질 때, 서로가 알아 들을 수 있는 메시지의 형식에 대한 약속이라 할 수 있다.
HTTP는 HTML, 텍스트, 이미지, 음성, JSON 등 다양한 데이터 포맷을 전달할 수 있으며, 요청과 응답에는 URL 경로, 각종 메서드, 상태코드와 헤더 등 미리 정해놓은 몇가지 정보가 포함되어 전달된다.
🤔개념
특징
무상태(stateless)
만약 stateful하면 서버는 클라이언트의 정보를 계속 가지고 있을 필요가 있다. 반면 무상태는 서버가 클라이언트의 이전 상태를 보존하지 않는다. 따라서 서버의 변경사항이 발생하면 클라이언트의 정보를 지속할 수 없다.
TCP의 keep-alive 옵션
정상적 연결 종료가 아닌 한쪽 시스템이 다운되어 연결이 끊긴 경우를 찾아낸다. 다운(down)되지 않은 다른 한쪽 peer는 TCP 세션을 유지하고 있는다(Listening). 이때, TCP keep-alive 패킷이 사용된다.
비연결성(connectionless)
- 한 번의 요청-응답이 끝나면 연결이 종료된다. 즉, 클라이언트의 요청에 따른 TCP/IP 연결을 계속 유지하지 않는다.
HTTP의 역사
HTTP/0.9 버전은 헤더와 상태코드 없었으며, 아래와 같은 형태를 띄었다.
GET /mypage.htmlHTTP/1.0 버전부터는 POST, HEAD 메서드와 상태코드가 추가되었으며, Content-Type을 명시할 수 있게 된다.
HTTP/1.1
1997년에 개정된 이후 오늘날까지도 널리 쓰이고 있는 버전이다.
- Persistent connection(지속적 연결): 지정한 시간 동안 HTTP 연결을 유지하는 것을 의미한다. 이를 통해 새로운 연결 성립(TCP 3-way handshake)을 위한 시간 소요가 단축되었고, 여러 요청이 하나의 커넥션 연결 시간동안 이루어진다. 이는 전체 네트워크 사용 시간이 줄어드는 결과를 가져왔다.
- Pipeline(파이프라인): 하나의 커넥션에서 응답을 기다리지 않고, 순차적인 여러 요청을 연속적으로 보내 순서에 맞추어 응답을 받는 방식이다. 이는 각 응답에 대한 대기 시간 이 감소하는 결과를 가져왔다.
- Head-of-line Blocking: 웹 생태계 확장되면서 한 파이프라인 내에서의 대규모 처리로 인해 데이터 전송이 정체되는 경우가 생겼다. TCP 기반이기 때문에 전송 순서를 보장하기 위해서는 이후 모든 작업들이 지연되는 현상은 불가피했다.
Domain Sharding(도메인 단위의 요청 분리)를 사용하는 등의 임시 방편을 사용하곤 했다.
- 청크 단위의 전송 ⇒ 응답을 한꺼번에 받기 위한 대기 불필요
- Cache-Control, ETag를 통한 캐싱
HTTP/2
HTTP/1.1까지는 한 번에 하나의 요청과 응답만 처리했다. 즉, 여러 요청을 동시에 보내기 위해 여러 연결을 만들어야 한다. 따라서 웹 페이지 내 이미지와 파일과 같은 리소스가 많으면 로딩 속도가 느려지는 단점이 존재한다. 이를 해결하고자 ‘멀티플렉싱’ 개념과 함께 HTTP/2가 2015년에 도입되었다. 이 버전은 기존 HTTP/1.X 버전의 성능 향상에 초점을 둔 프로토콜로, 표준의 대처가 아닌 확장의 개념을 띄고 있다.
- Binary Framing Layer: 버전 1의 요청 형식을 헤더와 데이터 프레임으로 나누고 이를 단순 텍스트 형식에서 바이너리 포맷 형식으로 전환하였다. 당연하게도 바이너리를 사용함으로써 파싱과 전송 속도가 향상되었고, 오류 발생 가능성이 줄어드는 결과를 가져왔다.
- Multiplexing: 하나의 TCP 연결 위에서 스트림 단위의 양방향 송수신이 가능해졌다.
- Stream Prioritization: 리소스간 전송 우선 순위를 설정 가능해졌다.
- Server Push: 클라이언트에서 요청하지 않은 리소스를 서버가 스스로의 판단 하에 전송할 수 있게 되었다.
- HPACK Compression: HTTP/1.1까지는 연속된 요청의 헤더가 중복되더라도 이에 대한 별도 처리가 이루어지지 않아 비효율적이었다. HTTP/2에서는 이 문제를 해결하고자 HPACK 압축을 통한 헤더 전송량을 감소시켰다.
HTTP/3
HTTP/2의 등장으로 응답 속도가 개선되긴 했지만, 여전히 HTTP는 TCP 기반의 통신 방식을 채택하고 있었다. 따라서 TCP의 전송 순서 보장의 특성으로 인해 전송 유실이 일어나면 재전송이 발생했고, 이로 인한 지연 문제가 여전히 남아있었다. 즉, TCP로 인한 Head-of-line Blocking은 근본적으로 해결되지 못하고 있었다.
이러한 문제를 해결하기 위해서 구글은 2012년 QUIC이라는 새로운 전송 계층 프로토콜을 선보였다. QUIC에서는 이전 버전과 달리 UDP로 통신 전 연결 확립을 수행한다. 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송하며, 연결 성공 시 설정을 캐싱하여 다음 연결 때 바로 연결 성립을 가능하게 해준다. TCP와 UDP의 차이에서도 짐작할 수 있듯이 다른 데이터의 상황에 영향을 받지 않고 전송이 지속되게 해준다.
QUIC은 연결을 지속하는 TCP와 달리 그렇지 않은 UDP를 사용하므로 네트워크 환경이 자주 바뀌는 모바일 환경에 유용하게 동작한다. 또한 QUIC는 연결 셋업 도중 TLS 핸드세이크 수행을 하여 TLS가 기본 적용되었다.
| 버전 | 1.1 | 2 | 3 |
|---|---|---|---|
| 방식 | 순차 처리 | 한 연결에 여러 작업 동시 처리 | 특정 전송 과정의 문제 발생이 다른 전송 과정에 영향 미치지 않음 |
| 전송 프로토콜 | TCP 기반 | TCP 기반 | UDP 기반 |
| 비유 | 줄 서서 기다리기 | 한 트럭에 여러 상자 실어 보내기 | 개별 상자 문제 상관 없이 보내기 |
HTTP Header
전송에 필요한 모든 부가 정보를 담는다. 콜론(:)으로 서로 구분되는 키-값 쌍 형태로 설정되며, HTTP 요청의 경우 일반 헤더, 요청 헤더, 응답 헤더의 3가지 헤더가 자동으로 생긴다.
- 종류
- General(일반 헤더): 요청한 URL, 요청 메서드, Referrer Policy(해당 자원을 요청할 때 해당 자원의 출처를 나타내는 URL 노출 여부를 설정) 등을 포함한다. 요청과 응답 모두에 적용되지만 본문의 데이터와는 관련이 없다.
- Response Header(응답 헤더): 서버에서 설정하는 헤더로, 서버의 소프트웨어 정보 등이 담긴다. 대부분의 서버는 일반적으로 해커가 서버의 소프트웨어 정보를 알기 어렵게 하기 위해 서버 정보를 숨긴다.
- Request Header(요청 헤더): 클라이언트에서 설정하는 헤더로, 메서드, 클라이언트 OS, 브라우저 정보 등이 담긴다.
HTTP Method
Http 메서드는 웹 브라우저와 웹 서버가 어떤 방식으로 통신할 것인가에 대한 표시로 주요 메서드에는 GET, POST, PUT, PATCH, DELETE 등이 있다.
REST와 같이 요청의 명확한 의미를 주기 위해서 DELETE, PUT 등의 추가적인 메서드를 도입된 메서드도 존재한다.
GET
리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
- 특징
- 요청하는 데이터가 HTTP Request Message의 Header 부분에 url 이 담겨서 전송
- 클라이언트가 서버로 요청하면서 같이 보낸 데이터는 parameter로 넘겨진다.
- 서버의 값이나 상태 등을 변경하지 않는다.
- 사용자 입력값을 서버로 보낼 수 있는 form 태그 작성를 작성하는 경우
ex) 링크 클릭, 검색포털에서 검색 클릭
POST
POST를 통해 특정 URI를 요청하면 리소스를 생성하거나, 기존 리소스에 데이터를 추가한다.
- 특징
- HTTP Request Message의 Body 부분에 데이터가 담겨서 전송된다.
- 항상 리소스를 생성하는 것은 아니다.
- 서버의 값이나 상태를 변경한다.
- 사용자 입력값을 서버로 보낼 수 있는 form 태그를 작성하는 경우
PUT
리소스를 완전히 대체하고, 해당 리소스가 없으면 생성한다.
- 특징
- POST와 달리 서버에 저장된 데이터에 있는 속성을 제외하고 보내면 해당 속성은 삭제된 채로 서버에 저장된다. 즉, 리소스를 완전히 대체하는 것이다.
- POST와 달리 리소스의 주소를 정확히 알고 있어야 한다.
PATCH
리소스의 일부분만 변경한다.
DELETE
리소스를 삭제한다.
특성
| 특성 | 설명 | 종류 |
|---|---|---|
| 안전성 | 원본 서버의 상태 변경을 요청하지 않는 특성 | GET |
| 멱등성 | 첫 번째 작업을 수행한 뒤 여러 차례 적용해도 결과를 변경하지 않는 특성 | GET, PUT, DELETE |
| 캐시 가능성 | 응답 결과를 캐싱해서 효율적으로 사용할 수 있는지에 관한 특성 | GET, POST, PATCH |
HTTP Status code
Status Code(상태코드)란 웹서버의 Response Message의 첫 번째 줄(status)에 포함되는 내용으로 1xx(Informational), 2xx(Success), 3xx(Redirection), 4xx(Client errors), 5xx(Server errors)가 있다.
REST API 제대로 알고 사용하기 : NHN Cloud Meetup
1xx (정보)
요청을 받았으며, 프로세스를 계속 처리 중임을 의미한다.
2xx (성공)
요청을 성공적으로 처리했음을 의미한다.
| Code | Text | Description |
|---|---|---|
| 200 | OK | 요청 성공 |
| 201 | Created | 요청이 성공하여 새로운 리소스가 생성 (주로 POST 및 일부 PUT 요청 이후에 반환) |
| 202 | Accepted | 요청을 수신했지만, 아직 처리가 완료되지 않았음을 의미 |
| 204 | No Content | 요청을 성공했지만, 응답 페이로드 본문에 보낼 데이터가 없음을 의미 |
3xx (리다이렉션)
요청 완료를 위해 웹 브라우저에서 추가 작업이 필요함을 의미한다. URL 리다이렉션 혹은 URL 포워딩은 페이지 단위의 실제 리소스, 폼 혹은 전체 웹 애플리케이션이 다른 URL에 위치하고 있는 상태에서 링크를 존속시키는 기술이다.
HTTP에서 리다이렉션은 요청에 대해 특별한 응답(리다이렉트)을 전송함으로써 촉발되며, HTTP 리다이렉트는 3xx 상태 코드를 지닌 응답이다. 리다이렉트 응답을 수신한 브라우저는, 제공된 새로운 URL을 사용하여 그것을 즉시 로드한다.
- 목적: 사이트 유지나 다운 시 클라이언트를 일시적으로 리다이렉트시키기 위함이다.
- 영속적인 리다이렉션: 원래 URL이 더 이상 사용되지 않아야 하고, 새로운 URL을 더 선호해야 함을 시사한다.
Code Text Method handling Typical use case 301 Moved Permanently GET methods unchanged. Others may or may not be changed to GET. 웹사이트 개편 308 Permanent Redirect Method and body not changed. Reorganization of a website, with non-GET links/operations. - 일시적인 리다이렉션: 종종 요청된 리소스가 표준적인 location으로부터 접근할 수 없을 수 있으나, 다른 곳으로부터는 접근할 수 있을 때 사용된다.
Code Text Method handling Typical use case 302 Found GET methods unchanged. Others may or may not be changed to GET. The Web page is temporarily unavailable for unforeseen reasons. 303 See Other GET methods unchanged. Others changed to GET (body lost). Used to redirect after a PUT or a POST, so that refreshing the result page doesn't re-trigger the operation. 307 Temporary Redirect Method and body not changed The Web page is temporarily unavailable for unforeseen reasons. Better than 302 when non-GET operations are available on the site.
4xx (클라이언트 오류)
요청 문법 오류나 요청을 처리할 수 없음을 의미한다.
| Code | Text | Description |
|---|---|---|
| 400 | Bad Request | 잘못된 문법이나 메시지를 요청해서 서버가 이해할 수 없음 |
| 401 | Unauthorized | 클라이언트의 해당 리소스에 대한 인증(로그인 등) 필요 |
| 403 | Forbidden | 서버가 요청을 이해했지만 승인 거부 |
| 인증(로그인)은 완료됐지만 접근 권한(인가)이 불충분한 경우 | ||
| 404 | Not Found | 요청 리소스를 찾을 수 없음 |
5xx (서버 오류)
서버가 정상적으로 요청을 처리할 수 없음을 의미한다.
| Code | Text | Description |
|---|---|---|
| 500 | Internal Server Error | 서버 내부 문제로 오류 발생 |
| 502 | Bad Gateway | 서버 간의 유효하지 않은 응답을 받은 경우 |
| 503 | Service Unavailable | 일시적인 서버 측 리소스 처리 불가 상태, 유지보수를 위한 중단 / 서버 과부하 |
참고자료
[JSP] HTTP 요청 메서드(GET과 POST)(자막있음)
HTTP 버전별 특징 #평비 #팟캐스트 #개발자교양
[10분 테코톡] 🧃쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC
HTTP-1.수업소개
[10분 테코톡] 호티의 Http Method
