HTTP 기본

HTTP(HyperText Transfer Protocol)

HyperText : HTML. 문서간의 링크를 통해 이동할 수 있는 마크업언어.

HTTP는 HTML 텍스트 메세지를 전송하는 용도로 시작되었으나 지금은 다른 거의 모든것들을 HTTP로 전송한다. 이미지,음성,영상 뿐만아니라 *JSON, *XML, 서버간의 데이터를 주고받을때에도 HTTP를 사용한다.

 

*Json

JavaScript Object Notation라는 의미의 축약어로 데이터를 저장하거나 전송할 때 많이 사용되는 경량의 DATA 교환 형식

 

*XML

EXtensible Markup Language의 약자로 HTML과 매우 비슷한 문자 기반의 마크업 언어이다.

그러나 XML은 HTML처럼 데이터를 보여주는 목적이 아닌, 데이터를 저장하고 전달할 목적으로만 만들어졌다.

 

Json과 XML은 추후에 따로 공부예정.

 

HTTP의 버전

• HTTP/0.9 1991년
• HTTP/1.0 1996년
• HTTP/1.1 1997년
  • TCP 사용. (TCP 프로토콜 위에서 동작)
  • 현재 가장 많이 사용하는 버전이다.
    HTTP/1.1 스펙에 거의 모든 기능이 들어있고, 이후는 성능 개선에 초점을 뒀다.
  • RCF2068(1997) → RFC2616(1999) → RFC7230~7235(2014)
    1991년에 한번, 2014년에 한번 총 2번 개정되었다.
    2014 버전이 신규스펙이기때문에 7230 이후 버전으로 봐야하나, 현재 2616 버전 자료를 가장 많이 찾아볼 수 있다. (신규버전은 발전이 더딤)
• HTTP/2 2015년
  이전 버전보다 성능이 개선되었고 TCP 를 사용한다. (TCP 프로토콜 위에서 동작)
• HTTP/3 진행중
  이전 버전보다 성능이 개선되었고 TCP 대신 UDP를 사용한다.

HTTP기본

클라이언트 - 서버구조

클라이언트가 HTTP 요청 메세지를 서버에 보내고, 서버는 클라이언트에게 메세지를 받아 요청에 대한 결과를 만들어 HTTP 응답 메세지를 클라이언트에게 보낸다. 서버는 클라이언트에게 요청이 올 때 까지 대기하고, 클라이언트는 응답을 받을 때 까지 대기한다. 어쩌면 '이건 원래 그런거 아닌가?'라고 생각할 수 있지만 HTTP가 나오면서 이런구조의 서비스가 가능해졌다. 

 

클라이언트 - 서버 구조가 의도하는 것은 클라이언트는 가져와서 보여주는 것에 집중하고 서버는 필요한 저장 및 연산을 하는 것에 집중하는 것으로 역할을 나눠 가져서 독립적으로 발전하면서도 사용자 경험을 증대(서비스의 향상)시킬 수 있도록 하는 것이다.

 

stateless

HTTP는 무상태 프로토콜을 지향한다. 서버는 클라이언트의 상태를 보존하지 않는다.

 

Stateful

Statelsess

상태유지가 더 편리하다고 생각할 수 있지만, 점원이 중간에 바뀌었을때를 생각해보면 달라진다. 무상태일경우 중간에 점원이 바뀌더라고 문제없이 서비스를 받을 수 있다. 이러한 설계는 클라이언트/서버 아키텍쳐에서는 스케일아웃이 용이한 구조가 된다.

 

비연결성

HTTP는 기본적으로 연결을 유지하지않는다. 초단위의 빠른 속도로 응답하기 때문에 한시간동안 수천명이 서비스를 사용해도 실제서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적다. 통신하지않을때 연결을 끊으면 서버 자원을 매우 효율적으로 사용할 수 있다.

 

물론, 이 방식으로 통신을 하면 TCP/IP를 새로 연결해야하는 단점이 있는데 이전 TCP/IP 공부했을 당시 TCP의 특징으로 설명했던 연결시 맺는 3 way handshake를 매번해줘야한다.(시간추가는 덤이다.)

또한 웹 브라우저로 사이트를 요청하면 HTML 뿐만아니라 자바스크립트,css, 이미지 등 다른 수많은 자원도 함께 다운로드 된다. 이 수많은 자원들을 다운받을때마다 연결을 끊고 새로 맺어야하기때문에 비효율적이다.

 

비연결 한계 극복

HTTP는 기본적으로 지속 연결(Persistent Connentions)을 사용한다. HTTP2와 HTTP3에서는 지속 연결에 대한 부분이 더욱 최적화되었다.

HTTP/2 와 HTTP/3 에서는 지속연결을 더 빠르게 발전시켰다. 특히 HTTP/3는 UDP 프로토콜을 사용하여 연결 시간도 더 짧게 단축시켰다.

 

(21.12.28)

HTTP 메서드 종류와 특징

 

메소드	용도	정의	특징
GET	데이터 조회	서버에 전달하고 싶은 데이터를 query(parameter, query string)을 통해 전달한다	메시지 바디를 통해 데이터를 전달할 수도 있지만 지원하지 않는 곳도 존재하기 때문에 권장❌
POST	다양한 요청 처리	BODY에 리소스 데이터를 전달	GET 방식 사용시 전달해야할 데이터가 많다면 POST를 사용하여 BODY에 조회할 데이터를 전달할 수 있지만 POST로 조회시 캐싱하기에 어려운 문제가 있기 때문에 권장하지 않는다.(기술적으로 캐싱은 가능하다.)
PUT	데이터 추가 또는 덮어쓰기	요청한 데이터가 없다면 추가하고 있으면 덮어쓰기 한다.	POST와 PUT은 다르다. POST를 계속 요청하면 데이터가 계속 생성되지만 PUT은 여러번 요청하더라도 결과는 같다.(멱등성)  또한, PUT은 POST와 다르게 클라이언트가 리소스의 위치를 알고 URI를 지정해 주어야 한다.
PATCH	데이터 수정	전달한 데이터로 수정한다.	지원하지 않는 경우도 있어 이런 경우 POST로 대체하여 사용한다.
DELETE	데이터 삭제	특정 리소스의 삭제를 요청하는 데 사용한다.	-

HTTP 메서드 속성

안전 Safe

호출해도 리소스를 변경하지 않는 특성

 

멱등성 Idempotent

동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것

외부 요인으로 중간에 리소스가 변경되는 것을 고려하지 않고 해당 요청을 기준으로 고려한다

올바르게 구현한 GET, PUT, DELETE 메소드는 멱등성을 지녀야 한다.

(POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.)

ex) 

• DELETE /members/100 → 200
• DELETE /members/100 → 404
• DELETE를 여러 번 호출하면 응답 코드는 달라질 수 있지만, 100번 member가 삭제된 것은 동일

멱등성이 보장된다면 서버가 TIMEOUT등으로 응답을 못줬을 시에 길게 생각할 것 없이 다시 같은 요청을 해도 된다고 판단할 수 있는 것이다. 하지만, 멱등성이 보장되지 않는다면 서버가 TIMEOUT등으로 응답을 못줬다고 해도 실제로 해당 서버 내에서 아직 처리중일 수도 있는 등 같은 요청을 두 번 보내고 그 요청들이 모두 데이터에 영향을 준다면 두번 요청하는 행위 자체가 데이터의 정합성을 깨트릴 수 있는 위험한 행위가 된다.

 

 

캐시 가능 Cacheable

응답 결과를 서버에 캐시 해서 사용해도 되는 메소드

GET, HEAD, POST, PATCH가 가능하지만 실무에서는 구현이 어렵기 때문에 GET, HEAD 정도만 캐시 하여 사용

 

HTTP 상태코드

더 자세한 사항은 여기를 참고해주세요.

 

2xx (Successful) - 클라이언트의 요청을 성공적으로 처리

• 200 OK
• 201 Created
• 202 Accepted
• 204 No Content

 

3xx (Redirection) - 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

 

4xx (Client Error) - 클라이언트 오류

• 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 오류의 원인이 클라이언트에 있음
• 중요! 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실 패함

 

5xx (Server Error) - 서버 오류

• 서버 문제로 오류 발생
• 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구가 되거나 등등)

 

HTTP 응답과 요청 메시지

 

HTTP 헤더

HTTP는 메세지본문을 통해서 표현데이터를 전달한다고 볼수있는데, 헤더의 역할은 표현 데이터를 해석할 수 있는 정보 제공하는 것이다. 즉, 본문해석을 위한 메타데이터인 것이다.

 

협상

서버가 응답을 할 때 클라이언트가 보낸 협상헤더를 참고하여 응답에 반영하는 용도로 사용된다.

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어

 

표현

• Content-Type: 표현 데이터의 형식에 대한 정보(text/html; charset=utf-8, application/json, image/png)
• Content-Encoding: 표현 데이터의 압축 방식(gzip, deflate, identity)
• Content-Language: 표현 데이터의 자연 언어(ko, en)
• Content-Length: 표현 데이터의 길이

일반

• From: 유저 에이전트의 이메일 정보
• Referer: 이전 웹 페이지 주소(유입 경로 분석을 위해 사용하며 referrer의 오타인데 초기 배포시 이미 브라우저들이 이를 따라서 오타를 그대로 사용)
• User-Agent: 유저 에이전트 애플리케이션 정보(브라우저 정보이며 서버 입장에서 장애 분석 등을 위해 통계목적으로 사용)
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보(중간에 거치는 proxy말고 정말 end point)
• Date: 메시지가 생성된 날짜

• Host: 요청한(요청을 해달라고 부탁하는) 호스트 정보(도메인)(필수값)
• Location: 페이지 리다이렉션에 사용될 url(201에 사용된 Location 값은 생성된 리소스의 URI)
• Allow: 허용 가능한 HTTP 메서드(예시: GET, HEAD, PUT)
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

• Authorization: 클라이언트 인증 정보를 서버에 전달(예시: Basic xxxxx, Bearer xxxxx)
• WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의(401 Unauthorized 응답과 함께 사용)

 

 

 

 

참고

https://fistkim101.github.io/infra/2021-03-15-%EA%B9%80%EC%98%81%ED%95%9C-HTTP.html#%ED%98%91%EC%83%81

https://fistkim101.github.io/infra/2021-03-15-%EA%B9%80%EC%98%81%ED%95%9C-HTTP.html

https://velog.io/@jaeh0on/모든-개발자를-위한-HTTP-웹-기본-지식-by-김영한-3.-HTTP기본1