CS 스터디 7주차

HTTP와 HTTPS 의 차이는 무엇인가요?

HTTP(HyperText Transfer Protocol)와 HTTPS(HyperText Transfer Protocol Secure)는 인터넷에서 데이터를 전송하는 데 사용되는 프로토콜입니다. 그러나 두 프로토콜은 데이터 전송 중 보안과 관련된 중요한 차이점이 있습니다.

• 보안
  HTTP: 암호화되지 않은 텍스트 기반 프로토콜로, 데이터가 평문으로 전송됩니다. 이는 해커가 데이터를 도청하거나 변조할 수 있는 보안 취약점을 남깁니다.
  HTTPS: SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 통신을 암호화합니다. 따라서 데이터는 암호화되어 전송되므로 도청이나 데이터 변조를 어렵게 만듭니다. HTTPS는 인증서를 사용하여 서버의 신원을 확인하고 클라이언트와 서버 간의 보안 연결을 설정합니다.

• 포트 번호
  HTTP: HTTP는 기본적으로 80번 포트를 사용합니다.
  HTTPS: HTTPS는 기본적으로 443번 포트를 사용합니다.

• 인증서
  HTTP: HTTP는 인증서를 사용하지 않습니다.
  HTTPS: HTTPS는 인증서를 사용하여 웹 사이트의 신원을 확인합니다. 인증서는 신뢰할 수 있는 기관에 의해 발급되며, 웹 브라우저는 인증서를 통해 서버의 신원을 확인하고 사용자에게 안전한 연결임을 보장합니다.

• 검색 엔진 최적화:
  HTTP: HTTP로 운영되는 웹 사이트는 검색 엔진 최적화(SEO)에서 이점을 얻을 수 있습니다.
  HTTPS: HTTPS로 운영되는 웹 사이트는 검색 엔진에서 더 높은 우선 순위를 받을 수 있습니다. 또한, 웹 브라우저에서 보안 경고를 표시하지 않기 때문에 사용자들에게 신뢰성을 제공합니다.

요약하면, HTTP는 암호화되지 않은 프로토콜로 보안이 약하며, HTTPS는 암호화된 프로토콜로 보안이 강화되어 있습니다. HTTPS는 인증서를 사용하여 서버의 신원을 확인하고 데이터의 안전한 전송을 보장합니다. 따라서, 개인 정보, 로그인 정보, 결제 정보 등을 처리해야 하는 경우에는 HTTPS를 사용하는 것이 안전합니다.

HTTPS가 동작하는 방식에 대해서 설명해 주세요.

• 클라이언트 요청:
  클라이언트(일반적으로 웹 브라우저)가 HTTPS를 사용하여 서버에 요청합니다. URL의 시작 부분에 "https://"를 사용하여 암호화된 연결을 나타냅니다.

• 서버 인증:
  서버는 클라이언트에게 인증서를 제공합니다. 인증서는 신뢰할 수 있는 기관(Certificate Authority)에 의해 서버의 신원을 확인하고 서명된 데이터로 구성됩니다. 클라이언트는 이 인증서를 검증하여 서버의 신원을 확인합니다.

• 암호화 키 교환:
  클라이언트는 서버의 공개키를 사용하여 암호화된 세션 키를 생성합니다. 이 세션 키는 데이터를 암호화하고 해독하는 데 사용됩니다.

• 데이터 암호화:
  클라이언트는 생성된 세션 키를 사용하여 요청 데이터를 암호화합니다. 이로 인해 데이터가 전송 중에 도청되어도 해독이 어려워집니다.

• 데이터 전송:
  클라이언트로부터 암호화된 데이터를 서버로 전송합니다. 데이터는 중간에 있는 네트워크 장치에서 도청되어도 암호화되어 있으므로 내용이 보호됩니다.

• 데이터 해독:
  서버는 비밀 세션 키를 사용하여 받은 암호화된 데이터를 해독합니다. 이로써 서버는 클라이언트의 요청을 이해하고 처리할 수 있습니다.

• 응답 암호화:
  서버는 세션 키를 사용하여 응답 데이터를 암호화합니다. 이로써 응답 데이터는 암호화된 상태로 클라이언트에게 전송됩니다.

• 데이터 전송:
  서버로부터 암호화된 응답 데이터가 클라이언트로 전송됩니다. 다시 한번, 데이터는 중간에 있는 네트워크 장치에서 도청되어도 암호화되어 있으므로 내용이 보호됩니다.

• 데이터 해독:
  클라이언트는 비밀 세션 키를 사용하여 받은 암호화된 응답 데이터를 해독합니다. 이로써 클라이언트는 서버로부터 받은 응답을 이해하고 화면에 표시할 수 있습니다.

HTTPS는 암호화된 연결을 통해 데이터의 기밀성과 무결성을 보장하며, 클라이언트와 서버 간의 안전한 통신을 제공합니다.

HTTP 1.0과 1.1의 2.0와 그 특징에 대해서 설명해 주세요.

HTTP 1.0:

HTTP 1.0은 초기 버전으로, 1996년에 도입되었습니다.
각각의 요청마다 새로운 TCP 연결을 설정하고, 요청이 완료되면 연결을 닫는 방식을 사용합니다.
간단하고 직관적인 프로토콜로, 기본 요청과 응답 구조를 가지고 있습니다.
지속적인 연결(Persistent Connection)을 지원하지 않아 매 요청마다 연결을 설정해야 하므로 오버헤드가 발생할 수 있습니다.
캐싱 기능이 제한적이어서 동일한 자원에 대한 반복적인 요청이 발생할 수 있습니다.

HTTP 1.1:

HTTP 1.1은 1997년에 도입되었고, 현재까지 가장 널리 사용되는 버전입니다.
재사용 가능한 연결(Keep-Alive) 기능을 도입하여, 단일 연결에서 여러 요청과 응답을 처리할 수 있습니다.
파이프라이닝(Pipelining)을 지원하여 여러 요청을 동시에 보낼 수 있어 처리 속도를 향상시킵니다.
가상 호스팅(Virtual Hosting)을 지원하여 하나의 서버에서 여러 도메인을 호스팅할 수 있습니다.
캐싱 기능이 개선되어 캐시 제어와 조건부 요청 등을 통해 효율성을 높였습니다.

HTTP 2.0:
HTTP 2.0은 2015년에 도입되었습니다.
이전 버전과 비교하여 성능과 효율성을 크게 개선했습니다.
이진 프레이밍(Binary Framing) 방식을 도입하여 헤더와 데이터를 압축하고 병렬로 전송할 수 있습니다.
서버 푸시(Server Push) 기능을 지원하여 클라이언트의 요청 없이 필요한 리소스를 미리 전송할 수 있습니다.
헤더 압축 기능을 통해 헤더 크기를 최소화하고 네트워크 대역폭을 절약합니다.
멀티플렉싱(Multiplexing)을 지원하여 여러 요청과 응답을 동시에 처리하며, 응답의 우선순위를 설정할 수 있습니다.
전송 오류 복구 기능을 강화하여 신뢰성을 높였습니다.
HTTP 2.0은 이전 버전들과 비교하여 성능과 효율성을 향상시키는 다양한 기능을 제공하므로, 현재 웹 서비스에서 널리 사용되고 있습니다.

keep-alive 헤더에 대해서 설명해 주세요.

Keep-Alive 헤더는 HTTP 요청과 응답에서 사용되는 옵션 중 하나입니다. 이 헤더를 통해 클라이언트와 서버 사이의 TCP 연결을 재사용할 수 있습니다. 일반적으로 Keep-Alive 헤더는 HTTP 1.1 버전부터 지원됩니다.

HTTP 1.0에서는 매 요청마다 새로운 TCP 연결을 설정하고 요청이 완료되면 연결을 닫았습니다. 이로 인해 많은 네트워크 오버헤드가 발생하고, 요청마다 새로운 연결을 설정해야 했습니다.

하지만 Keep-Alive 헤더를 사용하면 단일 연결을 통해 여러 요청과 응답을 처리할 수 있습니다. 클라이언트는 Keep-Alive 헤더를 요청에 포함시켜 서버에 연결을 유지하도록 요청할 수 있고, 서버는 응답에 Keep-Alive 헤더를 포함시켜 연결을 유지하도록 알려줄 수 있습니다.

Keep-Alive 헤더에는 다음과 같은 정보가 포함될 수 있습니다:

Connection: Keep-Alive (클라이언트 요청에서 사용): 클라이언트가 서버에게 연결을 유지하도록 요청합니다.
Connection: close (서버 응답에서 사용): 서버가 연결을 닫으라고 클라이언트에게 알려줍니다.
Keep-Alive 헤더를 사용하면 다음과 같은 이점이 있습니다:

매 요청마다 TCP 연결을 설정할 필요가 없어지므로 네트워크 오버헤드가 감소합니다.
연결의 재사용으로 인해 요청의 응답 시간이 단축될 수 있습니다.
클라이언트와 서버 사이의 상태 유지가 가능해집니다.
TCP 연결의 유휴 시간을 조절할 수 있어서 네트워크 리소스를 효율적으로 사용할 수 있습니다.
Keep-Alive 헤더는 HTTP 요청과 응답에서 연결을 유지하고 재사용할 수 있는 기능을 제공하여 웹 페이지의 로딩 시간을 개선하고, 네트워크 리소스를 효율적으로 활용할 수 있도록 도와줍니다.

HTTP GET과 POST의 차이는 무엇인가요?

HTTP GET과 POST는 HTTP 프로토콜에서 사용되는 두 가지 주요한 메서드(Method)입니다. 이 두 메서드는 다음과 같은 차이점이 있습니다:

• 목적
  GET: GET 메서드는 서버로부터 데이터를 요청하기 위해 사용됩니다. 주로 정보의 조회나 검색과 같은 목적으로 사용됩니다. GET 요청은 서버에서 데이터를 읽어오는 용도로 사용됩니다.
  POST: POST 메서드는 서버에 데이터를 제출하기 위해 사용됩니다. 주로 사용자 입력 데이터를 서버로 보내거나, 서버에 새로운 데이터를 생성하기 위해 사용됩니다. POST 요청은 서버에 데이터를 전송하여 처리하는 용도로 사용됩니다.

• 데이터 전송
  GET: GET 메서드는 데이터를 URL의 쿼리 문자열(Query String)에 포함하여 전송합니다. 데이터는 URL 뒤에 ?를 사용하여 key-value 쌍의 형태로 전달됩니다. 예를 들어, https://example.com/search?keyword=apple과 같이 전달됩니다. 데이터의 길이에 제한이 있고, 보안이 취약할 수 있습니다.
  POST: POST 메서드는 요청의 body에 데이터를 포함하여 전송합니다. 데이터는 헤더와 별도의 body 섹션에 포함되어 전달되며, 사용자에게 노출되지 않습니다. 데이터의 길이에 제한이 없고, 보안적인 측면에서 GET보다 안전합니다.

• 캐싱
  GET: GET 요청은 캐싱이 가능합니다. 동일한 GET 요청을 반복해서 보낼 경우, 이전에 받은 응답을 캐시에서 가져올 수 있습니다. 따라서 GET 요청은 동일한 데이터를 반복해서 요청해도 일관된 결과를 얻을 수 있습니다.
  POST: POST 요청은 기본적으로 캐싱되지 않습니다. 매번 서버로 요청을 전송하며, 서버는 매번 새로운 데이터를 처리합니다.

• 보안
  GET: GET 요청은 URL에 데이터가 노출되기 때문에 보안에 취약합니다. URL은 브라우저 히스토리나 서버 로그 등에 저장될 수 있습니다. 따라서 GET 요청으로 민감한 정보를 전송하는 것은 적절하지 않습니다.
  POST: POST 요청은 데이터가 URL에 노출되지 않기 때문에 GET보다 보안적으로 안전합니다. 데이터는 요청의 body에 포함되어 전송되므로 외부에서 쉽게 탈취하기 어렵습니다.
  GET과 POST는 각각 다른 목적과 데이터 전송 방식을 가지고 있습니다. GET은 데이터를 조회하고 검색하는 용도로 사용되며, POST는 데이터를 제출하고 처리하는 용도로 사용됩니다. 이에 따라 데이터 전송 방식, 캐싱 기능, 보안 등에서 차이가 있습니다.

쿠키와 세션에 대해서 설명해 주세요.

쿠키와 세션은 웹 애플리케이션에서 상태 유지(Stateful)를 위해 사용되는 메커니즘입니다. 이 둘은 클라이언트와 서버 간의 상태 정보를 저장하고 전달하는 방식에 차이가 있습니다.

쿠키(Cookie):

쿠키는 클라이언트의 웹 브라우저에 저장되는 작은 데이터 조각입니다.
서버에서 클라이언트로 쿠키를 보내고, 클라이언트는 이를 브라우저에 저장합니다.
클라이언트가 동일한 서버에 재요청할 때마다 쿠키는 요청과 함께 서버로 전송됩니다.
주로 사용자 식별, 선호 설정, 장바구니 등을 유지하기 위해 사용됩니다.
클라이언트에서 쿠키를 제거하거나 만료시킬 때까지 지속됩니다.
세션(Session):

세션은 서버 측에서 관리되는 데이터 구조입니다.
클라이언트가 서버에 접속하면 서버는 고유한 세션 ID를 생성하고 클라이언트에게 제공합니다.
세션 ID는 일반적으로 쿠키를 사용하여 클라이언트에 저장됩니다. 하지만 URL 매개변수를 통해 전달되기도 합니다.
클라이언트는 요청을 보낼 때마다 세션 ID를 서버로 전달하여 세션을 식별합니다.
서버는 클라이언트의 세션 ID를 사용하여 세션 데이터를 찾고, 필요한 정보를 유지하고 공유합니다.
세션은 서버 측에서 유지되기 때문에 쿠키보다 보안적으로 안전합니다. 클라이언트에는 세션 데이터가 직접 저장되지 않습니다.
일반적으로 세션은 클라이언트가 브라우저를 종료하거나 세션 유효기간이 만료될 때까지 지속됩니다.
요약하면, 쿠키는 클라이언트 측에서 저장되는 데이터로서, 클라이언트와 서버 간의 상태 유지에 사용됩니다. 세션은 서버 측에서 관리되는 데이터로서, 클라이언트를 식별하고 클라이언트의 상태를 유지하기 위해 사용됩니다. 쿠키는 클라이언트에서 제어되며, 세션은 서버에서 제어됩니다.