HTTP

HTTP

• HyperText Transfer Protocol
• 웹 상에서 데이터를 주고받기 위한 어플리케이션 레이어 프로토콜이다.
• 처음에는 HTML 문서를 주고받기 위해 설계되었으나, 현재는 이미지, 동영상, 파일, API 등 많은 종류의 리소스를 주고받을 때 사용한다.

HTTP의 역사

• HTTP/0.9
  • 초기 버전으로 따로 버전 번호가 없었지만, 뒤의 버전들과 구분하기 위해 붙여진 이름이다.
  • 버전 번호가 없었기 때문에 스타트 라인에 따로 버전 정보가 명시되지 않았다.
  • GET 메서드만 지원하였다.
  • HTTP 메시지에 헤더가 없었다.
  • 상태 코드가 없었다. 그 때문에 문서 내에 해당 파일의 문제에 대한 설명을 같이 담기도 했다.
• HTTP/1.0
  • HTTP 메시지에 버전 정보가 들어가기 시작했다.
  • POST, PUT, DELETE 등 메서드가 추가되었다.
  • HTTP 메시지에 헤더가 생겨났다.
  • 응답 메시지에 상태 코드가 생겼다.
• HTTP/1.1
  • 현재 사용하는 기능들이 대부분 자리잡은 버전이다.
  • 가장 많이 사용된다.
  • 뒤의 공부할 내용의 대부분이다.
• HTTP/2.0, HTTP/3.0
  • HTTP/1.1에서 성능 개선 정도의 버전업.
  • HTTP/3.0의 경우 다른 버전이 TCP를 사용하는 것과 달리 UDP를 사용한다.

HTTP의 특징

• 클라이언트 - 서버 프로토콜이다.
  • 클라이언트의 request와 서버의 response를 교환하여 통신한다.
  • 클라이언트와 서버 사이에 0개 이상의 프록시가 있다.
• HTTP는 Stateless 프로토콜이다. (상태를 유지하지 않는다.)
  • 서버와 클라이언트는 이전에 보낸 request나 response를 전혀 기억하지 못한다.
  • 새로운 request가 보내질 때 마다 새로운 response가 생성된다. (많은 데이터를 빠르고 확실하게 처리하는 범위성을 위한 설계)
  • 상태 유지가 필요한 경우에 HTTP를 보안하기 위해 쿠키(Cookie)라는 기술을 사용한다.
• HTTP 메시지를 통해 통신을 한다.
  • 리소스를 HTTP 메시지의 body에 담아 보낸다.
  • 리소스를 request URI에 query string으로 보내기도 한다.
  • HTTP 메서드에 따라 동작이 다르다.
• 비 연결성 통신을 한다.
  • 비 연결성이란, 서버와 클라이언트가 통신이 필요할 때, 연결을 하고 한 번의 통신이 끝나면 바로 연결을 종료한다.
  • 초기에는 문제가 없었으나, 점점 리소스의 크기가 커지기 시작했다. (이미지, 영상 등)
  • 이미지 등의 리소스들은 여러 번의 통신을 필요로 하고, TCP 연결과 종료의 과정이 부담이 되었다.
  • HTTP는 지속 연결을 통해 이를 해결한다.
• HTTP 메시지를 통해 통신을 한다.
  • request와 response 둘 다 HTTP 메시지를 서로 송수신한다.
  • HTTP 메시지는 request와 response의 모양이 조금씩 다르다.

HTTP 메시지

• 스타트 라인 (start line)
  • 리퀘스트 라인 (request line)
    • request에 사용하는 메소드와 리퀘스트 URI, 사용하는 HTTP의 버전이 포함된다.
    • ex) GET /members/find?name=bogeun&age=20 HTTP/1.1
    • ex) POST /members/create HTTP/2.0
  • 상태 라인 (status line)
    • response의 결과를 나타내는 상태 코드와 설명, 사용하는 HTTP의 버전이 포함된다.
    • ex) HTTP/1.1 200 OK
    • ex) HTTP/3.0 404 Not found
• 헤더 필드 (header)
  • HTTP 메시지에 부가적인 정보(조건, 속성 등)들을 담는다.
  • 대소문자를 구분하지 않으며, Key : Value의 쌍으로 기입한다.
• 공백 라인 (empty line)
  • 헤더와 메시지 바디를 구분하기 위한 공백 라인
• 메시지 바디 (message body)
  • 전송하는 컨텐츠(Representation의 body)를 담기 위한 필드
  • payload라고도 한다.

HTTP Status Code

• 클라이언트가 서버에 request를 보내고 그 request의 처리 후 결과의 상태를 알려주는게 상태 코드(status code)이다.
• 상태 코드를 통해 클라이언트가 response를 받은 후의 행동을 결정할 수 있다.
• 상태 코드는 response 메시지의 최상단에 기입되며, 세 자리의 수로 나타낸다.
• 세 자리 수에서 가장 첫 번째 숫자는 response의 클래스를 나타내며, 나머지는 따로 분류가 없다.

상태 코드 클래스

• 1XX
  • Informational
  • 리퀘스트를 받아들여 처리중
• 2XX
  • Success
  • 리퀘스트가 정상적으로 처리됨
• 3XX
  • Redirection
  • 리퀘스트를 완료하기 위해서 추가 동작이 필요함
• 4XX
  • Client Error
  • 서버에서 클라이언트의 리퀘스트를 이해하지 못함
• 5XX
  • Server Error
  • 서버가 리퀘스트를 처리 실패

위의 클래스들만 잘 지켜준다면, 커스텀 상태 코드를 만들어도 된다.

2xx 성공 (Success)

• request가 정상적으로 처리되었음을 나타낸다.

• 200 OK
  • 클라이언트의 request를 서버가 정상적으로 처리함을 나타낸다.
• 201 Created
  • 요청에 성공해서 새로운 리소스가 생성되었음을 나타낸다.
  • 일반적으로 POST나 PUT 요청의 응답으로 발생된다.
• 202 Accepted
  • 요청을 수신했지만, 처리가 완료되지 않았음을 나타낸다.
  • 처리가 될 수도 되지 않을 수도 있는 상황에 사용된다.
  • batch 처리 등에 사용된다.
• 204 No Content
  • 서버가 request의 처리는 성공했지만, 돌려줄 리소스가 없는 상황을 나타낸다.
  • 204 상태의 response는 representation body 없이 돌려보내야 한다.
  • 클라이언트에서 서버에 정보를 보내고, 클라이언트는 새로운 정보를 받을 필요가 없을 때 사용된다.
• 206 Partial Content
  • Range에 의해서 범위가 지정된 request를 받았음을 나타낸다.
  • response에는 Range가 지정된 범위의 representation이 포함된다.

3xx 리다이렉트 (Redirection)

• request가 정상적으로 처리되기 위해 클라이언트 측에서 특별한 처리를 수행해야 하는 경우를 알린다.
• 웹 브라우저는 3xx response에 Location 헤더가 있으면, 자동으로 그 위치로 자동 이동한다.(리다이렉트)
• 리다이렉션에는 종류가 3가지 있다.
  • 영구 리다이렉션
  • 일시 리다이렉션
  • 특수 리다이렉션
• 영구 리다이렉션
  • 기존의 uri가 사용되지 않으며, 새로운 uri로 영구적으로 이동된 경우를 나타낸다.

  • 만약 기존의 uri가 북마크 된 경우에 리다이렉션이 발생하면, 브라우저가 새로운 uri로 북마크를 변경할 수도 있다.

  • 301
    • Moved Permanently
  • 308
    • Permanent Redirect
• 일시 리다이렉션
  • 기존의 uri가 일시적으로 다른 uri를 할당받은 경우를 나타낸다.

  • 기존의 uri가 북마크 된 경우에 리다이렉션이 발생해도 브라우저는 북마크를 변경해선 안된다.

  • 302
    • Found
  • 303
    • See Other
  • 307
    • Temporary Redirect
• 특수 리다이렉션
  • 300 Multiple Choice
    • 요청에 대해 하나 이상의 응답이 가능하다.
    • 클라이언트에서 선택을 해야하는데, 그 방법이 표준화 되어있지 않다.
    • 거의 사용하지 않음.
  • 304 Not Modified
    • 요청된 리소스의 캐시 값이 여전히 사용 가능하다고 알린다.
    • 로컬에 캐시된 복사본으로 리다이렉트 한다.
    • response에 body를 포함시키면 안된다. (캐시를 써야 하므로)
    • 예시로,
      1. 클라이언트가 캐시가 오래되어 새로 보내달라 요청함
      2. 서버가 판단하길 사용해도 괜찮다고 304 발생
      3. 캐시된 곳으로 리다이렉트 된다.

4xx 클라이언트 에러 (Client error)

• 클라이언트가 원인으로 서버가 요청을 수행할 수 없음을 나타낸다.

• 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 아무리 재시도를 해도 결과가 변할 수 없다.

• 400 Bad Request
  • request 구문이 잘못되었음을 나타낸다.
  • 브라우저는 이 에러를 200 OK와 같은 동작으로 처리한다.
  • 예시로, HTTP API 스펙에 맞지 않는 요청일 때, 요청 파라미터가 잘못된 경우 등
• 401 Unauthorized
  • request에 HTTP 인증 정보가 필요하다는 것을 나타낸다.
  • 401 response를 보낼 때는 인증 방법에 대한 설명과 WWW-Authenticate 헤더 필드를 담아 보내야 한다.
• 403 Forbidden
  • 요청된 리소스에 대해 엑세스가 거부된 경우이다.
  • 인증 자격은 있지만, 접근 권한이 없어 거부된 경우이다.
  • response의 메시지 바디에 거부의 이유를 기재한다.
  • 예시로, 일반 회원이 어드민 자격을 필요로 하는 리소스에 접근하는 경우.
• 404 Not Found
  • 요청된 리소스가 서버 상에 없다는 것을 나타낸다.
  • 그 외에도 거부의 이유를 기재하고 싶지 않은 경우에 사용된다.

5xx 서버 에러 (Server error)

• 서버가 원인으로 요청을 제대로 처리할 수 없는 경우를 나타낸다.

• 서버의 문제이므로 같은 요청을 다시 보냈을 때, 결과가 바뀔 수도 있다.

• 500 Internal Server Error
  • 서버에서 request를 처리하는 도중 에러가 발생함을 나타낸다.
  • 백엔드에서 애매한 경우에 그냥 500을 날린다.
• 503 Service Unavailable
  • 서버가 과부하 상태이거나 점검중이라 일시적으로 요청을 처리할 수 없음을 나타낸다.
  • Retry-After 헤더 필드로 얼마뒤에 복귀되는 지 클라이언트에 알릴 수 있다.