📚 정의
HTTP란 서버와 클라이언트 사이에 데이터를 주고 받기 위한 프로토콜이다.
HTTP는 인터넷에서 하이퍼텍스트(HTML, image, video 등)를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 요청을 주고 받는다.
초기에는 하이퍼미디어 문서를 주로 전송했지만, 최근에는 Plain Text, JSON, XML 등 다양한 형태의 정보도 전송한다.
또한, 웹 브라우저와 웹 서버 간의 통신을 위해 디자인되었지만 모바일 애플리케이션 및 IoT 등과의 통신과 같이 다른 목적으로도 쓰이고 있다.
HTTP는 애플리케이션 계층의 프로토콜로 TCP/IP 위에서 작동한다.
📚 작동
클라이언트 (Client)
서버에 리소스 전송을 요청할 수 있는 클라이언트 소프트웨어(웹 브라우저, 모바일 애플리케이션 등)가 설치된 컴퓨터
서버 (Server)
클라이언트의 요청에 응답할 수 있는 소프트웨어(아파치, NginX 등)가 설치된 컴퓨터
과정
- 클라이언트가 보고 싶은 정보를 서버에게 HTTP를 통해 요청한다.
- 서버는 요청에 따른 처리 후 알맞는 응답 메시지 및 정보를 클라이언트에게 전달한다.
- 응답 메시지 중 바디(Body) 내용이 클라이언트가 설정한 클라이언트의 사용처에 도달한다.
📚 특징
비연결성 (Connectionless)
비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질이다.
장점
HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다.
만약 서버에서 다수의 클라이언트와 연결을 유지해야 한다면 많은 리소스가 발생하게 된다.
따라서 비연결적인 특징을 통해 연결을 유지하기 위한 리소스를 줄여 더 많은 연결이 가능하도록 한다.
단점
서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결과 해제하는 과정을 거쳐야하므로 오버헤드가 발생할 수 있다.
KeepAlive
비연결성의 단점에 대한 해결책으로 오버헤드를 줄이기 위해 HTTP의 KeepAlive 속성을 사용할 수 있다.
KeepAlive는 지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 패킷을 주기적으로 보내 반응이 없으면 접속을 끊는다.
하지만, 주기적으로 클라이언트의 상태를 확인한다는 것 또한 메모리를 많이 사용하므로 완벽한 해결책은 아니다.
무상태 (Stateless)
Connectionless로 인해 서버와 클라이언트가 연결을 끊으면 상태 정보를 유지하지 않기 때문에 서버가 클라이언트를 식별할 수 없는 것을 의미한다.
무상태로 인해 사용자는 매번 인증을 해야하기 때문에 접근성이 떨어진다. 이에 대한 해결책으로는 쿠키, 세션, 토큰(JWT, OAuth) 등이 있다.
📚 HTTP Method
클라이언트가 서버로 요청을 할 때, 어떠한 목적을 갖는 행위인지 HTTP 메서드에 명시한다.
GET
특정 리소스를 조회한다. (READ)
HEAD
GET과 같지만, 서버는 응답으로 응답코드와 헤더만 반환한다.
클라이언트가 서버에 리소스가 있는지 확인하거나 메타 데이터를 읽으려고 할 때 사용한다.
PUT
변경 가능한 특정 리소스를 변경한다. (UPDATE)
PATCH
특정 리소스의 일부분만 변경한다.
POST
새로운 리소스를 생성한다. (CREATE)
DELETE
특정 리소스를 삭제한다.
Request Body가 아닌 URI 경로에 삭제하려는 리소스의 ID를 전달한다.
TRACE
클라이언트와 서버 사이의 모든 HTTP 요청과 응답에 대한 메시지의 이상 유무를 파악한다.
서버는 응답 메시지의 본문에 자신이 받은 요청 메시지를 넣어 응답하며, 주로 진단이나 테스트를 위해 사용한다.
하지만, TRACE 메소드를 이용하면 서버에 전송한 문자열을 그대로 보내주기 때문에 쿠키값이 노출되는 위험이 있다.
OPTIONS
클라이언트가 서버의 특정 리소스에 대해 수행 가능한 메소드를 알아보기 위해 사용한다.
CORS에 사용한다.
멱등성 (Idempotent)
멱등은 같은 작업을 반복해도 같은 결과가 나오는 경우를 의미한다.
POST / PUT
POST는 동일한 리소스를 여러번 POST할 경우 서버 리소스에 변화가 생기기 때문에 멱등하지 않다.
PUT은 실행할 때마다 동일한 리소스를 수정하기 때문에 서버 리소스에 변화가 생기지 않아 멱등하다.
PUT / PATCH
데이터 상에서 사용자의 나이가 20살인 경우, 1월 1일이 지나 1살을 늘려야 하는 상황이다.
PUT을 통해 나이를 21살로 수정할 경우, 여러 번 요청해도 21살이므로 멱등하다.
PATCH를 통해 나이를 21살로 수정할 경우, PUT과 마찬가지로 여러 번 요청해도 21살이므로 멱등하다.
하지만, 21살로 수정하는 것이 아닌 1살을 증가하는 방식으로 요청할 경우 여러 번 요청하면 멱등하지 않다.
따라서 PATCH는 어떻게 구현하느냐에 따라 멱등 할 수도, 멱등하지 않을 수도 있다.
📚 응답 코드
클라이언트가 요청하면 서버는 요청의 결과와 응답 코드를 함께 보낸다.
1XX : 정보 (Information)
- 정보 교환
- 100, 101
2XX : 성공 (Success)
- 데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음
- 200 : OK, 요청이 성공적으로 수행됨
3XX : 방향 변경 (Redirection)
- 자료의 위치가 변경되었음
- 301 : Moved Permanently, 요청한 리소스에는 새로운 URI가 지정되었음
4XX : 클라이언트 오류 (Client Error)
- 클라이언트 측 오류
- 400 : Bad Request, 사용자의 요청 구문이 잘못됨
- 401 : Unauthorized, 인증이 필요한 요청
- 403 : Forbidden, 접근 금지
- 404 : Not Found, 요청한 리소스가 서버에 없음
- 405 : Method Not Allowed, 허용되지 않은 HTTP Method 사용
5XX : 서버 오류 (Server Error)
- 서버 측 오류
- 500 : Internal Server Error, 서버에서 클라이언트의 요청 처리 중 오류 발생
📚 HTTP Message
요청 (Request)
응답 (Response)
📚 HTTP Packet
HTTP 프로토콜 상에서 클라이언트와 서버는 데이터를 패킷 단위로 쪼개서 통신한다.
데이터 전송 단위인 패킷에는 요청/응답에 대한 메시지가 담겨있다.
- Host : 요청을 한 서버의 Host
- Accept : 클라이언트가 허용할 수 있는 파일 형식
- Accept-Language : 클라이언트가 인식할 수 있는 언어
- Accept-Encoding : 클라이언트가 인식할 수 있는 인코딩
- User-Agent : 클라이언트 소프트웨어의 이름과 버전
[참고]
