[Network] HTTP에 대해서

HTTP란?

웹 상에서 데이터를 교환하기 위해 사용되는 프로토콜로, 웹 브라우저와 웹 서버 간의 통신에 이용됩니다. 클라이언트가 서버에 요청을 보내고 서버가 그에 대한 응답을 제공하는 방식으로 동작합니다.

• GET: 리소스의 조회를 요청합니다. 주로 웹 페이지나 이미지 등의 데이터를 가져오는 데 사용됩니다.
• POST: 서버에 데이터를 제출하거나 처리를 요청합니다. 주로 폼 데이터의 전송이나 파일 업로드 등에 사용된다. 요청에 body를 포함할 수 있습니다.
• PUT: 리소스의 교체를 요청합니다.
• PATCH: 리소스의 수정을 요청합니다.
• DELETE: 리소스의 삭제를 요청합니다.
• HEAD: 메세지 헤더(문서 정보)를 요청하는 메서드입니다. GET과 유사한 방식이지만, 실제 문서를 요청하는 것이 아니라, 문서 정보를 요청합니다. 서버는 본문(Body)없이 HTTP 헤더 정보만 반환합니다.
• CONNECT: 요청한 리소스에 대해 양방향 연결을 시작하는 메서드로 터널을 열기 위해서 사용될 수 있습니다. (i.e. 원하는 목적지와 TCP 연결을 HTTP 프록시 서버에 요청하는 경우)
• OPTIONS: 주어진 URL 또는 서버에 대해 허용된 통신 옵션을 요청합니다. 서버는 헤더의 Allow 컬럼에 OPTIONS, GET, HEAD, POST 처럼 허용되는 메서드를 포함하여 응답합니다. CORS에서 사전 요청은 OPTIONS 메서드를 통해 전송됩니다.

GET, POST 메서드의 차이

GET이나 POST는 각각 URL의 쿼리 파라미터, 요청의 body를 통해 서버에 추가적인 데이터를 보낼 수 있습니다. 하지만 body에 요청의 내용을 포함하는 것이 보안적으로 더 안전합니다. HTTPS 통신의 경우 요청의 body와 URL에 붙이는 쿼리 파라미터를 둘 다 암호화하지만, 만약 비밀번호 등 민감한 정보를 쿼리 파라미터에 넣을 경우 서버에 로깅되거나 브라우저에 히스토리가 캐싱되는 등 보안적으로 좋지 않은 결과를 부를 수 있습니다.

GET과 POST를 각각 리소스의 조회(값 받아오기), 데이터 제출 혹은 처리 요청이라는 자신의 목적과 특징에 맞게 사용하는 것이 중요합니다.

PUT, PATCH 메서드의 차이

두 메소드 모두 데이터의 업데이트를 위해 사용하지만, PUT 메소드의 경우 데이터를 완전히 교체하고, PATCH 메소드의 경우 데이터를 부분적으로 업데이트합니다.

예를 들어, data라는 리소스의 값이 { a: "foo", b: "bar" }일 때 data 값을 업데이트 하고자 할 경우, PUT 메소드로 { a: "dgx" }라는 값을 전송하면 서버는 data를 { a: "dgx"}로 변경합니다. PATCH 메서드로 같은 값을 전송하면 서버는 data를 { a: "dgx", b: "bar"}로 업데이트할 것이다. (물론 서버가 메서드에 대해 잘 구현되어 있을 경우에!)

Status Code

클라이언트와 서버 간의 통신에서 상태를 표현하기 위해 사용하는 코드입니다.

• 1xx (Informational): 요청이 수신되었고 처리 중인 상태로, 주로 프로토콜 수준의 정보 전달에 사용됩니다.
  • 100 Continue: 클라이언트가 서버로 보낸 요청에 문제가 없으니 다음 요청을 이어서 보내도 됨을 뜻합니다.
• 2xx (Successful): 요청이 성공적으로 처리되었음을 뜻합니다.
  • 200 OK: 클라이언트의 요청이 성공적으로 처리되었음을 뜻합니다.
  • 201 Created: 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됨을 뜻합니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청에 반환됨.
  • 204 No Content: 요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있음을 뜻합니다. (i.e. 리소스가 캐시된 헤더를 새로운 것으로 업데이트)
• 3xx (Redirection): 클라이언트가 요청을 완료하기 위해 추가 조치를 취해야 함을 뜻합니다. 예를 들어, 리소스가 다른 위치로 이동되었을 때 클라이언트를 해당 위치로 리다이렉트할 수 있습니다.
  • 304 Not Modified: 요청된 리소스를 재전송할 필요가 없음을 뜻합니다. 캐시된 자원으로의 암묵적인 리디렉션입니다. 요청이 조건부로 If-None-Match (en-US) 또는 If-Modified-Since 헤더를 사용할 때 응답됩니다.
  • 307 Temporary Redirect: 리다이렉트 상태 응답 코드를 뜻합니다.. 요청한 리소스가 헤더에 주어진 URL로 임시로 옮겨진 경우입니다.
• 4xx (Client Error): 클라이언트의 요청이 잘못되었거나 서버가 요청을 처리할 수 없음을 의미합니다.
  • 400 Bad Request: 서버가 클라이언트 오류(i.e. 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅)를 감지해 요청을 처리할 수 없거나 하지 않음을 뜻합니다..
  • 404 Not Found: 요청한 리소스를 서버에서 찾을 수 없음을 뜻합니다.
  • 405 Method Not Allowed: 서버가 요청 메서드를 알고 있지만 대상 리소스가 이 메서드를 지원하지 않음을 뜻합니다.
  • 403 Forbidden: 클라이언트 오류 상태 응답 코드는 서버에 요청이 전달되었지만, 권한 때문에 거절됨을 뜻합니다.
• 5xx (Server Error): 서버가 유효한 요청을 처리하지 못했음을 나타냅니다. 예를 들어, 500 Internal Server Error는 서버에서 예상치 못한 내부 오류가 발생했을 때 반환됩니다.
  • 500 Internal Server Error: 서버에서 예상치 못한 내부 오류가 발생함을 뜻합니다.
  • 502 Bad Gateway: 서버가 게이트웨이나 프록시 서버 역할을 하면서 업스트림 서버로부터 유효하지 않은 응답을 받음을 뜻합니다.

HTTPS는?

HTTP는 암호화되지 않은 텍스트 기반 프로토콜로, 데이터가 평문으로 전송됩니다.

HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security 프로토콜을 사용하여 데이터를 암호화하고 웹 사이트의 신원을 확인하는 인증서를 사용합니다. 이 인증서는 웹 서버의 신뢰성과 데이터의 무결성을 보장합니다. 클라이언트는 웹 서버의 인증서를 확인하여 신뢰할 수 있는지 검증하고, 연결의 보안성을 확인할 수 있습니다.

SSL은 클라이언트와 서버간에 Handshake를 통해 인증이 이루어집니다. 또한 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작 여부를 확인합니다.

추가적으로, 검색 엔진은 HTTPS를 사용하는 웹 사이트를 선호하기 때문에 SEO에서도 이점이 있습니다.

SSL / TLS

SSL(Secure Sockets Layer)이란 보안 소켓 계층으로, 웹사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술입니다.

TLS(Transport Layer Security)는 전송 계층 보안으로, TLS은 SSL의 향상된, 더욱 안전한 업데이트 버전이며 명칭만 다르다고 볼 수 있습니다.

Handshake

1. 클라이언트는 서버에 SSL / TLS 연결을 요청하는 Client Hello 메시지를 보냅니다. 클라이언트가 지원하는 SSL / TLS 버전, 암호화 알고리즘 목록 등의 정보를 포함합니다.
2. 서버는 클라이언트의 요청에 응답하여 Server Hello 메시지를 보냅니다. 서버가 선택한 SSL / TLS 버전, 암호화 알고리즘, 디지털 인증서 등의 정보를 포함합니다.
3. 서버는 디지털 인증서를 클라이언트에게 제공하여 클라이언트가 인증서의 유효성과 서버의 신원을 검증할 수 있도록 합니다. 이 인증서는 공개키 암호화를 사용하여 서버의 공개키를 클라이언트와 안전하게 교환하는 역할을 합니다.
4. 클라이언트는 임시 세션 키를 생성하고, 서버의 공개키로 암호화하여 서버에게 전송합니다. 서버는 이를 개인키로 해독하여 세션 키를 얻습니다.
5. 클라이언트와 서버는 상호 동의한 암호화 알고리즘과 세션 키를 사용하여 통신을 암호화합니다. 이후에 이루어지는 통신의 데이터는 모두 암호화됩니다.

HTTPS의 동작 방식

1. 클라이언트(웹 브라우저 등)가 HTTPS로 액세스해야 할 웹 서버에 요청을 보냅니다. HTTPS를 사용하고자 함을 서버에 알리기 위해 HTTPS로 시작하는 URL로) 서버는 클라이언트에게 서버의 디지털 인증서를 보냅니다.
2. 클라이언트는 서버의 인증서를 받아 인증서의 유효성과 서버의 신원을 검증합니다.
3. 클라이언트와 서버는 상호 암호화 알고리즘과 데이터 암호화 및 복호화에 사용할 세션 키를 협상하고, 안전하게 교환합니다.
4. 클라이언트와 서버는 협상된 암호화 알고리즘과 세션 키를 사용하여 통신 데이터를 암호화합니다. 이후, 암호화된 데이터를 전송하고 수신 측에서는 세션 키를 사용하여 데이터를 복호화합니다.

HTTP의 각 버전 별 차이점

• 초기 버전 HTTP: GET 메서드만 존재.
• HTTP/1.0
  • Header: 메타데이터*의 전송이 가능해졌습니다.
  • Versioning: HTTP 요청시 사용된 버전을 명시적으로 알립니다.
  • Status Code가 추가되었습니다.
  • Content-type: HTML 파일이 아닌 JSON 등의 다른 문서도 전달할 수 있습니다.
  • POST와 HEAD 메서드가 추가되었습니다.

* 메타데이터(Metadata)란 데이터에 관한 구조화된 데이터로, 다른 데이터를 설명해 주는 데이터입니다. (i.e. 디지털 카메라가 사진을 찍을 때, 카메라 자체의 정보와 촬영 당시의 시간, 노출, 플래시 사용 여부, 해상도, 사진 크기 등의 메타데이터를 화상 데이터와 같이 저장합니다.)

• HTTP/1.1
  • PUT, PATCH, DELETE, CONNECT, TRACE, OPTIONS 메서드 추가
• HTTP/2.0
  • 한번에 하나의 요청만 보낼 수 있었던 기존 버전과 달리 요청을 보내고 응답을 비동기적으로 수신 받을 수 있습니다.
  • 요청 배치에서 숫자 우선 순위를 설정할 수 있습니다. JS 파일을 응답받기 전에 웹페이지 CSS를 받는 것과 같은 응답을 예상하는 순서를 명시할 수 있습니다.
• HTTP/3.0
  • TCP, TLS가 아닌 QUIC(Quick UDP Intenet Connections) 기반으로 설계되었고, 빠른 핸드 셰이크 프로세스를 가집니다.
  • HTTP/2.0에서 항상 HTTPS를 사용하는 것과 유사하게 항상 암호화된 연결을 만듭니다.

HTTP와 웹 소켓(Web Socket)의 차이점

둘 다 TCP 기반 프로토콜인데, 간단히 설명하면 한 번 데이터를 주고받은 후 연결을 끊는다면 HTTP, 계속 연결을 유지하면 웹 소켓입니다.

HTTP에서의 멱등성

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 합니다. 멱등성 메서드에는 통계 기록 등을 제외하면 어떠한 부수 효과(side effect)도 존재해서는 안된다.

• 멱등성 메서드: GET, DELETE, PUT
• 비 멱등성 메서드: POST, PATCH, CONNECT

동일한 요청을 여러번 보낼 때 상태코드는 변할 수 있지만 서버의 상태가 변하지 않으면 멱등입니다.

PUT은 해당 리소스를 완전히 교체해 버리기 때문에 멱등이지만, PATCH는 (멱등으로 설계할 수도 있지만) 멱등이 아니게 설계할 수 있습니다. (값에 10을 add하는 변경 요청의 경우 등)
POST는 요청 시마다 새로운 자원을 생성할 수 있어서 멱등이 아닙니다. (서버의 상태 변경)
DELETE 역시 멱등인데, 같은 요청을 여러 번 보내더라도 해당 자원은 삭제된 상태 그대로일 것이기 때문입니다.
따라서 가장 마지막 게시글을 삭제하는 API의 경우, DELETE는 멱등성을 가지지 않기 때문에 POST로 구현하는 갓이 스펙 상으로 옳습니다.