HTTP & HTTPS

HTTP란 무엇인가?

HTTP(Hypertext Transfer Protocol)는 웹 상에서 클라이언트와 서버 간 데이터를 교환하기 위한 규칙이자 프로토콜입니다.
HTTP는 신뢰할 수 있는 전송 프로토콜(TCP) 위에서 동작하며, 클라이언트-서버 모델을 따릅니다. HTTP의 확장성 덕분에 현재는 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오, JSON 등 다양한 데이터 포맷을 지원합니다.

OSI 7계층에서 HTTP의 위치

HTTP는 애플리케이션 계층(OSI 7계층의 7층)에 위치합니다. OSI 모델에서 각 계층은 특정 역할을 담당하며, HTTP는 데이터를 직접 전달하는 것이 아니라 하위 계층을 통해 전송되기 때문에 네트워크의 상세 동작을 이해하려면 하위 계층인 전송 계층(TCP/IP 4계층의 전송 계층)도 함께 고려해야 합니다.

• 애플리케이션 계층: HTTP, FTP, SMTP 등 여러 애플리케이션 간 데이터 송수신 방식 정의.
• 전송 계층: 데이터 전송을 책임지는 계층으로, HTTP는 TCP(Transmission Control Protocol) 기반으로 작동하여 신뢰성 있는 연결을 지원합니다.
• 인터넷 계층: IP를 통해 패킷이 목적지까지 라우팅되는 경로를 결정합니다.
• 네트워크 액세스 계층: 물리적인 전송을 처리하여 하드웨어 수준에서 데이터를 전달합니다.

이러한 네트워크의 계층적인 구조 덕분에 데이터를 전송하는 과정에서 라우터를 거치는 과정 등의 내용은 생략하고 애플리케이션 계층인 HTTP에서는 호스트간의 데이터 전달만 신경쓰면 됩니다

---

HTTP 특징

• 간단함 : HTTP는 사람이 읽을 수 있으며 간단하게 고안되어 HTTP 메시지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽고 초심자의 진입장벽을 낮췄습니다.
• 확장 가능 : 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 간단한 합의만 한다면, 언제든지 새로운 기능을 추가할 수 있습니다.
• Stateless : HTTP는 stateless(무상태)를 지향합니다. 기본적으로 stateless를 지향하지만 필요한 경우 상태를 저장하기도 합니다.(세션)
  HTTP는 요청과 응답으로 이루어집니다. 클라이언트가 요청을 하고 서버에서 받은 응답을 통해 웹을 구성합니다.

---

HTTP 메시지 구조

HTTP 메시지는 요청(Request) 메시지와 응답(Response) 메시지로 나누어집니다. 메시지의 구조는 시작 줄, 헤더, 바디로 구성되어 있으며, 각 부분이 역할과 기능을 담당합니다.

요청 메시지(Request Message) 구성

1. 시작 줄(Request Line): 메서드(Method), 요청 대상(URL Path), 프로토콜 버전(HTTP Version)이 포함됩니다. 예: GET /index.html HTTP/1.1.
   • Method: 요청의 목적을 정의하며, 주로 사용되는 메서드는 아래와 같습니다.
     • GET: 리소스 요청. 주로 웹 페이지나 이미지 데이터를 서버에서 가져올 때 사용합니다.
     • POST: 서버로 데이터를 제출하며, 주로 폼 제출이나 데이터 전송에 활용합니다.
     • PUT: 리소스를 수정하거나 새로 생성할 때 사용합니다.
     • DELETE: 서버에서 특정 리소스를 삭제합니다.
     • 그 외에도 HEAD, OPTIONS, PATCH 등이 있으며 각각 특정 목적에 맞게 사용됩니다.
2. 헤더(Headers): 요청에 관한 추가 정보를 전달합니다. 주요 헤더 필드는 다음과 같습니다.
   • Host: 서버의 도메인 이름과 포트를 지정하여 대상 서버를 설정합니다.
   • User-Agent: 클라이언트 애플리케이션 정보(브라우저 종류 및 버전)를 포함하여 서버가 응답을 최적화할 수 있습니다.
   • Accept: 클라이언트가 원하는 미디어 타입(MIME)을 명시합니다.
   • Authorization: 인증 정보 포함으로 보안 설정 시 유용합니다.
   • Cookie: 사용자가 저장한 세션 정보 등을 서버에 전달합니다.
3. 본문(Body): 메시지 본문으로, 주로 POST와 PUT에서 전송할 데이터를 포함합니다. JSON, XML, HTML 폼 데이터 등 다양한 형태로 데이터를 포함할 수 있습니다.

응답 메시지(Response Message) 구성

1. 상태 줄(Status Line): 상태 코드(Status Code), 상태 메시지, 프로토콜 버전이 포함됩니다. 예: HTTP/1.1 200 OK.
   • 상태 코드: 서버의 응답 상태를 나타내며 주로 다음과 같습니다.
     • 200 OK: 요청 성공.
     • 301 Moved Permanently: 영구적인 리다이렉트.
     • 404 Not Found: 요청한 리소스를 찾을 수 없음.
     • 500 Internal Server Error: 서버 내부 오류.
     • 글 마지막에 상태 코드 정리 참고
2. 헤더(Headers): 응답에 대한 메타데이터가 포함됩니다.
   • Content-Type: 응답 본문의 MIME 타입을 지정합니다.
   • Content-Length: 본문의 크기를 바이트 단위로 명시합니다.
   • Set-Cookie: 클라이언트 측에 쿠키를 저장하여 세션이나 사용자 정보를 유지할 수 있게 합니다.
   • Cache-Control: 캐시 관련 지침을 통해, 응답 데이터를 캐싱할 수 있도록 지정합니다.
3. 본문(Body): HTML, JSON, 이미지 등 실제 응답 데이터가 들어갑니다.

---

HTTP의 헤더

HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해줍니다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론 ':' 다음에 오는 값(줄 바꿈 없이)으로 이루어져있습니다. 값 앞에 붙은 빈 문자열은 무시됩니다.

1. 인증 관련 헤더

• Authorization: 사용자 인증 정보를 포함하며, 클라이언트가 서버에 인증 요청을 할 때 사용됩니다.
  • 예: Authorization: Basic
• WWW-Authenticate: 서버가 클라이언트에게 인증 정보를 요구할 때 사용하는 헤더입니다.
  • 예: WWW-Authenticate: Bearer realm="example"

2. 캐싱 관련 헤더

• Cache-Control: 응답의 캐싱 동작을 제어합니다. 다양한 지시어를 사용할 수 있습니다.
  • 예: Cache-Control: public, max-age=3600 (모든 사용자에게 캐시 가능)
• Expires: 자원의 만료 날짜를 설정합니다. 이 날짜가 지나면 캐시된 자원은 더 이상 유효하지 않습니다.
  • 예: Expires: Fri, 01 Dec 2024 16:00:00 GMT
• ETag: 리소스의 특정 버전을 식별하는 고유값으로, 조건부 요청 시 사용됩니다.
  • 예: ETag: "abc123"
• Last-Modified: 마지막 수정 날짜를 나타내며, 클라이언트는 이 정보를 통해 조건부 요청을 할 수 있습니다.
  • 예: Last-Modified: Wed, 21 Oct 2024 07:28:00 GMT

3. CORS 관련 헤더

• Access-Control-Allow-Origin: 특정 출처에서 요청을 허용하는 헤더입니다.
  • 예: Access-Control-Allow-Origin: * (모든 출처 허용)
• Access-Control-Allow-Methods: 허용되는 HTTP 메서드를 지정합니다.
  • 예: Access-Control-Allow-Methods: GET, POST

4. 쿠키 관련 헤더

• Set-Cookie: 서버가 클라이언트에게 쿠키를 설정할 때 사용합니다. 클라이언트는 이후 요청에 이 쿠키를 포함하여 서버에 전송합니다.
  • 예: Set-Cookie: sessionId=abc123; HttpOnly; Secure; Path=/
• Cookie: 클라이언트가 서버에 요청할 때 포함되는 쿠키 정보를 담고 있습니다.
  • 예: Cookie: sessionId=abc123

5. 제어 관련 헤더

• Content-Type: 서버가 전송하는 데이터의 MIME 타입을 정의합니다.
  • 예: Content-Type: application/json
• Content-Length: 응답의 바이트 길이를 명시합니다. 클라이언트는 이를 통해 수신할 데이터의 크기를 예측할 수 있습니다.
  • 예: Content-Length: 348
• Location: 리다이렉션 응답에서 새 위치를 알려주는 헤더입니다.
  • 예: Location: https://example.com/new-location
• Retry-After: 클라이언트에게 요청을 다시 시도할 수 있는 시간을 알려줍니다.
  • 예: Retry-After: 3600 (1시간 후 다시 시도)

6. 보안 관련 헤더

• Strict-Transport-Security (HSTS): 클라이언트가 서버와의 연결을 HTTPS로 강제할 때 사용됩니다. 특정 시간 동안 HTTP 요청을 HTTPS로 전환합니다.
  • 예: Strict-Transport-Security: max-age=31536000; includeSubDomains
• X-Content-Type-Options: 브라우저가 MIME 타입을 확인하여 잘못된 해석을 방지하도록 지시합니다.
  • 예: X-Content-Type-Options: nosniff
• Content-Security-Policy (CSP): 웹 페이지에서 허용되는 콘텐츠 출처를 명시하여 XSS 공격을 방어합니다.
  • 예: Content-Security-Policy: default-src 'self';

7. 기타 주요 헤더

• User-Agent: 클라이언트의 정보(브라우저 종류 및 버전, 운영 체제 등)를 포함합니다.
  • 예: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3
• Accept: 클라이언트가 수용할 수 있는 콘텐츠 유형을 서버에 알리는 헤더입니다.
  • 예: Accept: application/json
• Accept-Encoding: 클라이언트가 수용할 수 있는 콘텐츠 인코딩 형식을 서버에 알립니다.
  • 예: Accept-Encoding: gzip, deflate

---

HTTP의 버전별 특징

http는 팀 버너스 리가 www(WorldWideWeb)를 만들면서 함께 고안된 하이퍼텍스트 문서를 교환하기 위한 간단한 프로토콜인 '하이퍼텍스트 전송 프로토콜'입니다. 이때 초기에 0.9버전에서 현재까지 많이 발전해 왔습니다.

HTTP/0.9

이후 버전과 구분하기 위해 나중에 0.9로 불리게 됐습니다.

요청

응답

• 위 사진처럼 요청은 GET 메서드가 유일했고, 그 당시 하나의 서버에서 하나의 도메인만 제공하는게 일반적이었기 때문에 전체 URL은 필요하지 않았습니다.
• 응답도 html 파일 내용 자체로 유일했습니다.
• 매우 제한적입니다.

HTTP/1.0

1.0 버전에서는 헤더가 추가되고 확장성을 가지게 되었습니다.

• 비연결성(Connectionless): 요청을 처리할 때마다 연결을 새로 맺고 끊는 방식입니다.
• 헤더: 헤더 개념이 도입되어 메타데이터 전송이 가능해졌고, 프로토콜이 극도로 유연하고 확장성이 높아졌습니다.
  (Content-Type 덕분에, 일반 HTML 파일들 외에 다른 문서들을 전송할 수 있게 되었습니다.)
• 상태코드: 응답 앞에 상태 코드가 붙어 요청에 대한 성공과 실패를 알 수 있게 되었습니다.

요청 & 응답

HTTP/1.1

1.0 버전이 나오고 이후 표준화 작업을 통해 첫번째 표준화 버전인 1.1버전이 나오게 되었습니다. (1997년 초)
1.1 버전에서는 모호함을 명확하게 하고, 많은 개선사항을 도입했습니다.

• Persistent Connection (연결 유지): Keep-Alive라는 옵션을 통해, 하나의 TCP 연결을 통해 여러 요청을 처리하여 성능을 개선했습니다. (연결 재사용)
• Pipelining: 클라이언트가 여러 요청을 빠르게 순차적으로 전송할 수 있도록 하였습니다. 첫번째 요청에 대한 응답이 완전히 전송되기 전에 두번째 요청 전송을 가능케 하여, 통신 지연 시간이 단축되었습니다. (하지만 대부분의 브라우저가 지원하지 않아 제한적으로 사용되었습니다.)
• 캐시 제어 및 조건부 요청: Cache-Control, ETag, If-Modified-Since 등의 헤더를 통해 클라이언트가 서버 자원의 최신 상태를 파악할 수 있게 되었습니다.
• Chunked Transfer Encoding: Content-Length 없이 데이터를 분할하여 전송할 수 있는 기능을 제공하여 큰 파일 전송 시 유용했습니다.
• Host 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 서버 배치가 가능해졌습니다.

요청 & 응답

1.1 버전이 발표된 후에도 15년 넘게 확장이 이어졌습니다.

1.1 보안 전송

• 보안 전송을 위한 HTTP가 사용되었는데 기존 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, TCP/IP 스택 위에 추가적인 암호화된 전송 계층인 SSL을 만들어냈습니다. SSL은 서버와 클라이언트 간에 교환되는 메시지의 신뢰성을 암호화하고 보장했습니다.

1.2 복잡한 애플리케이션

• WebDAV(웹 분산 작성 및 버전 관리) 등장 : 사용자가 웹을 통해 파일을 추가하거나 편집할 수 있게 하려는 프로토콜입니다. 처음 HTTP는 단순히 웹페이지(HTML)를 가져오는 읽기 전용 프로토콜이는데, Tim Berners-Lee는 인터넷을 통해 정보를 공유하는 분산 시스템을 꿈꿨고, 사람들이 직접 문서를 추가하거나 수정할 수 있는 구조로 웹을 설계하고자 했습니다. 그래서 HTTP를 확장해서 WebDAV를 만들었습니다(1996).
• HTTP의 새로운 사용 방식인 REST API의 등장 : REST는 기존의 HTTP 메서드(GET, POST, PUT, DELETE 등)를 활용해서 특정 URI에 접근하고 데이터를 조회 및 수정할 수 있도록 하는 방식입니다. REST의 핵심은 특정 URI를 통해 필요한 데이터를 가져오거나 업데이트할 수 있는 구조를 제공합니다.
• 상호작용 가능한 API : 서버가 클라이언트(보통 웹 브라우저)로 실시간으로 데이터를 푸시하는 방식인 서버 전송 이벤트(Server-Sent Events)와 기존 HTTP 연결을 업그레이드해서 만든 새로운 프로토콜 웹소켓(WebSockets)이 등장. 웹소켓을 통해 서버와 클라이언트가 양방향으로 데이터를 주고받을 수 있는 실시간 통신이 가능해졌습니다.

문제점

• 헤드-오브-라인 블로킹(Head-of-Line Blocking): 앞 요청이 완료될 때까지 뒤 요청이 대기해야 해서, 특정 요청이 오래 걸리면 전체 응답 속도에 영향을 줍니다.

파이프라이닝을 통해 클라이언트에서는 응답을 기다리지 않고 새로운 요청을 보낼 수 있도록 하였지만, 서버에서는 여전히 순차적인 응답을 보장했어야 했습니다. 이 문제 해결을 위해 다중 연결 사용을 고려해보았지만, 이는 성능을 저하시키는 문제가 있었습니다.

HTTP/2

HTTP 2버전은 더 나은 성능을 위한 프로토콜이라고 할 수 있습니다. 많은 데이터 요청과 복잡해진 페이지로 인해 HTTP/1.1 연결에 복잡성과 오버헤드가 많이 발생했고, 이를 개선하기 위해 등장했습니다.

• 멀티플렉싱: 하나의 TCP 연결에서 여러 요청과 응답을 동시에 전송할 수 있어 페이지 로딩 성능이 크게 개선되었습니다.
• 헤더 압축: 헤더 데이터를 압축하는 HPACK 알고리즘을 통해 데이터 전송량을 줄였습니다.
• 서버 푸시: 서버가 클라이언트의 요청 없이도 클라이언트가 필요할 리소스를 푸시할 수 있습니다. 예를 들어, HTML을 요청하면 관련 CSS와 JS 파일도 함께 전송할 수 있습니다.
• Binary Framing: 텍스트 기반이 아닌 이진 프레이밍 방식으로 데이터를 전송해 빠르고 효율적입니다.

2버전 전까지는 텍스트 기반이었던 것과 달리, 프레이밍 방식으로 데이터를 전송하도록 하였고, 그 덕분에 동일한 연결을 통해 병렬 요청을 수행(멀티플렉싱)할 수 있어, HTTP/1.x 프로토콜의 제약을 없애주었습니다.

HTTP/3

• UDP 기반 QUIC 프로토콜: 기존 HTTP가 TCP 위에서 동작하던 것과 달리 UDP를 기반으로 한 QUIC(Quick UDP Internet Connections) 프로토콜을 사용해 연결 성립 시간을 단축하고 패킷 손실에도 빠르게 대처합니다.
• 멀티플렉싱 개선: HTTP/2에서 하나의 스트림에 문제가 생기면 전체 연결에 영향을 주었으나, HTTP/3는 개별 스트림에서 문제가 발생해도 나머지 스트림에 영향을 주지 않습니다.

QUIC는 HTTP 연결에 대해서 훨씬 낮은 대기 시간을 제공하도록 설계되었습니다. HTTP/2와 마찬가지로, 다중화 프로토콜이지만, HTTP/2는 단일 TCP 연결을 통해 실행되어 TCP 계층에서 처리되는 패킷 손실 감지 및 재전송이 모든 스트림을 차단할 수 있습니다. QUIC는 UDP를 통해 여러 스트림을 실행하고 각 스트림에 대해 독립적으로 패킷 손실 감지 및 재전송을 구현하므로, 오류가 발생하면 해당 패킷에 데이터가 있는 스트림만 차단됩니다.

HTTP와 HTTPS의 차이

HTTPS란 무엇인가?

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 SSL(최신 버전에서는 TLS)을 추가하여 통신의 보안성을 강화한 프로토콜입니다. HTTPS는 HTTP와 달리 데이터를 암호화하여 안전하게 전송할 수 있어 민감한 정보 보호에 필수적입니다.

HTTPS 특징

• 암호화: HTTPS는 암호화된 통신을 지원하여 데이터를 안전하게 전송합니다.
• 포트 번호: HTTPS는 기본적으로 443번 포트를 사용합니다.
• 인증: HTTPS는 디지털 인증서를 통해 웹 서버의 신원을 인증합니다.
• 데이터 무결성: 메시지 인증코드(MAC)를 사용하여 데이터 무결성 제공하고, 중간자 공격(Man-in-the-middle Attack)을 방지합니다.

TLS 핸드셰이크

• 간단한 동작 방식

  • https 요청을 할 경우 tcp 연결을 맺고, TLS 핸드셰이크 과정을 거칩니다.
  • 클라이언트 헬로 : 클라이언트는 임의의 랜덤 번호와, 가능한 암호화 방식들을 서버에 전달합니다.
  • 서버 헬로 : 서버에서도 임의의 랜덤 번호와 가능한 암호화 방식을 전달하고, 서버의 인증서와 공개키를 전달합니다.
  • 이후 클라이언트에서는 인증서를 통해 신뢰할 수 있는 서버인지 알 수 있게 되고, 클라이언트와 서버의 랜덤 번호를 조합하여 암호화에 사용할 대칭키를 생성합니다. 이 대칭키는 서버의 공개키를 사용하여 암호화하고, 다시 서버에게 전달합니다.
  • 클라이언트와 서버는 대칭키를 나눠 갖게 되었고, 이 대칭키를 사용하여 데이터를 암호화하여 통신합니다.

• 대칭키 & 비대칭키란? : 대칭키는 암호화, 복호화 키가 같은 것을 말하고, 비대칭키는 암호화에 쓰이는 키와 복호화에 쓰이는 키가 다르다. 대표적으로 RSA 알고리즘이 있는데, 비밀키와 공개키로 각각 암호화 & 복호화, 복호화 & 암호화를 하게 되고 개인키는 나만 갖고 있으며 공개키는 누구나 알 수 있도록 공개된 키라고 할 수 있다. 이때 비밀키를 사용하여 데이터를 암호화 하면, 누구나 공개키를 사용해 데이터를 복호화 할 수 있게 되고, 이것은 내가 해당 데이터를 암호화 했다는 것을 인증해준다. 반대로 누군가가 나에게만 비밀 메시지를 보내고 싶다면, 나의 공개키를 사용해 데이터를 암호화 할 수 있고, 이것은 내 비밀키로 나만 복호화 할 수 있기 때문에 보안을 지킬 수 있게 된다. 위에서 데이터를 암호화하는 대칭키를 만들어 서버의 공개키로 암호화하여 보냈는데, 이를 통해 대칭키는 서버만 복호화 할 수 있게 되었고, 안전하게 대칭키를 나눠가질 수 있게 되었다. 암호화에 비대칭키가 아닌 대칭키를 사용한 이유는 대칭키가 복호화 시간이 빠르기 때문이다.

• 인증서 : 클라이언트인 브라우저에서는 인증기관(CA)의 리스트를 내부적으로 가지고 있고, 리스트에 존재하는 인증기관에서 발급한 인증서인지 확인할 수 있다. 그리고 인증서를 해당 인증기관의 공개키를 사용해 복호화를 하고 검증이 된다면 해당 인증기관이 만든 인증서라는 것을 증명할 수 있고, 서버가 인증기관의 인증을 받은 신뢰할 수 있는 서버라는 것을 확인할 수 있다.

HTTP와 TCP가 직접 통신하지 않고 TLS가 통신하는 방식

HTTPS에서는 HTTP와 TCP가 직접 통신하지 않고 TLS 계층이 사이에서 중재 역할을 합니다. HTTPS가 동작하는 방식은 다음과 같습니다.

• 클라이언트-서버 간 TLS 터널링: TLS 계층이 HTTP의 요청과 응답을 암호화해 전송하고, TCP 계층에서 이를 전달합니다. 즉, TLS는 HTTP 데이터를 감싸는 역할을 하여 보안성을 확보합니다.
• 인증과 데이터 무결성: TLS가 암호화 외에도 서버 인증과 데이터의 무결성을 보장하여 데이터가 중간에서 조작되지 않도록 합니다.

이를 통해 HTTPS는 HTTP가 전송하는 모든 데이터를 TLS를 거쳐 암호화하여 전송하고, 이를 복호화하는 구조로 설계되어 안전한 데이터 전송이 가능합니다.

---

응답 상태 코드

상태 코드를 매번 쓰던 것만 쓰다보니 다양하게 쓸 수 있도록 밑에 추가해 놓는다.

1xx: 정보 응답

• 100 Continue: 클라이언트의 요청이 초기 헤더를 수신했으며, 나머지 요청을 계속 보내도 됨을 나타냅니다.
• 101 Switching Protocols: 클라이언트의 요청에 따라 프로토콜 변경을 수행함을 나타냅니다.

2xx: 성공

• 200 OK: 요청이 성공적으로 처리되었음을 나타냅니다.
• 201 Created: 요청이 성공적으로 처리되어 새로운 자원이 생성되었음을 나타냅니다.
• 202 Accepted: 요청이 접수되었으나 아직 처리되지 않았음을 나타냅니다.
• 203 Non-Authoritative Information: 요청이 성공했지만 반환된 정보는 원본 서버의 정보가 아님을 나타냅니다.
• 204 No Content: 요청은 성공적으로 처리되었으나 반환할 내용이 없음을 나타냅니다.
• 205 Reset Content: 요청이 성공적으로 처리되었고, 클라이언트는 현재 문서를 초기화해야 함을 나타냅니다.
• 206 Partial Content: 요청의 일부만 성공적으로 처리되었음을 나타냅니다. 주로 Range 헤더를 사용하는 경우에 해당합니다.

3xx: 리다이렉션

• 300 Multiple Choices: 요청에 대해 여러 선택 옵션이 있음을 나타냅니다.
• 301 Moved Permanently: 요청한 자원이 영구적으로 다른 URL로 이동되었음을 나타냅니다.
• 302 Found: 요청한 자원이 임시로 다른 URL로 이동되었음을 나타냅니다.
• 303 See Other: 요청한 자원을 다른 URL에서 확인해야 함을 나타냅니다.
• 304 Not Modified: 클라이언트가 제공한 캐시된 버전이 여전히 유효하다는 것을 나타냅니다.
• 305 Use Proxy: 요청한 자원에 접근하기 위해 프록시를 사용해야 함을 나타냅니다.
• 307 Temporary Redirect: 요청한 자원이 임시로 다른 URL로 이동되었지만, 원래 요청 방법을 사용해야 함을 나타냅니다.
• 308 Permanent Redirect: 요청한 자원이 영구적으로 다른 URL로 이동되었으며, 이후 요청에서도 원래 방법을 사용해야 함을 나타냅니다.

4xx: 클라이언트 오류

• 400 Bad Request: 서버가 요청을 이해할 수 없음을 나타냅니다.
• 401 Unauthorized: 인증이 필요함을 나타내며, 인증 정보가 없거나 잘못되었음을 의미합니다.
• 402 Payment Required: 결제 필요를 나타내지만, 일반적으로 사용되지 않습니다.
• 403 Forbidden: 서버가 요청을 거부했음을 나타냅니다. 권한이 부족함을 의미합니다.
• 404 Not Found: 요청한 자원을 찾을 수 없음을 나타냅니다.
• 405 Method Not Allowed: 요청한 HTTP 메서드가 지원되지 않음을 나타냅니다.
• 406 Not Acceptable: 요청한 리소스가 클라이언트가 요청한 콘텐츠 유형을 제공할 수 없음을 나타냅니다.
• 407 Proxy Authentication Required: 프록시 서버에 대한 인증이 필요함을 나타냅니다.
• 408 Request Timeout: 서버가 클라이언트로부터의 요청을 기다리다가 시간 초과되었음을 나타냅니다.
• 409 Conflict: 요청이 현재 서버 상태와 충돌함을 나타냅니다.
• 410 Gone: 요청한 자원이 영구적으로 삭제되었음을 나타냅니다.
• 411 Length Required: Content-Length 헤더가 필요하다는 것을 나타냅니다.
• 412 Precondition Failed: 요청에 설정된 조건이 실패했음을 나타냅니다.
• 413 Payload Too Large: 요청 데이터가 서버에서 허용하는 최대 크기를 초과했음을 나타냅니다.
• 414 URI Too Long: 요청 URI가 너무 길어서 처리할 수 없음을 나타냅니다.
• 415 Unsupported Media Type: 요청한 콘텐츠 유형이 지원되지 않음을 나타냅니다.
• 416 Range Not Satisfiable: 요청한 범위가 리소스에 존재하지 않음을 나타냅니다.
• 417 Expectation Failed: 요청의 Expect 헤더에 대한 서버의 기대가 충족되지 않음을 나타냅니다.

5xx: 서버 오류

• 500 Internal Server Error: 서버에서 일반적인 오류가 발생했음을 나타냅니다.
• 501 Not Implemented: 서버가 요청한 기능을 지원하지 않음을 나타냅니다.
• 502 Bad Gateway: 게이트웨이 또는 프록시 서버가 잘못된 응답을 받았음을 나타냅니다.
• 503 Service Unavailable: 서버가 일시적으로 과부하 상태이거나 유지 보수 중임을 나타냅니다.
• 504 Gateway Timeout: 게이트웨이 또는 프록시 서버가 응답을 기다리는 동안 시간 초과되었음을 나타냅니다.