[Computer Science][Network] 🌐 HTTP와 HTTPS: 웹 통신의 기본 이해

HTTP(HyperText Transfer Protocol)와 HTTPS(HyperText Transfer Protocol Secure)는 인터넷에서 클라이언트와 서버 간의 자원을 주고받을 때 사용하는 통신 규약입니다. 이 글에서는 HTTP의 기본 개념과 보안 취약점, 이를 보완하는 HTTPS의 통신 흐름에 대해 자세히 알아보겠습니다.

🌍 HTTP란 무엇인가?

HTTP(HyperText Transfer Protocol)는 인터넷 상에서 클라이언트(사용자의 웹 브라우저)와 서버 간에 자원을 주고받기 위해 사용되는 통신 규약입니다. 다음과 같은 특징을 가지고 있습니다:

• 요청-응답(Request-Response) 모델: 사용자가 웹 브라우저에서 URL을 입력하면, 브라우저는 웹 서버에 HTTP 요청을 보내고, 서버는 요청된 웹 페이지나 리소스를 응답으로 반환합니다.
• 무상태성(Stateless): HTTP는 각 요청 간의 연결을 유지하지 않습니다. 즉, 한 번의 요청과 응답이 완료되면 서버와 클라이언트 간의 연결은 끊어지며, 각 요청은 독립적으로 처리됩니다.
• 텍스트 기반: HTTP는 텍스트 형식으로 데이터를 주고받습니다. 요청과 응답은 사람이 읽을 수 있는 형태의 텍스트로 표현되며, 특정 포맷(메서드, URL, 헤더, 바디 등)을 따릅니다.
• 메서드: HTTP는 다양한 요청 메서드를 지원합니다. 예를 들어, GET(리소스 요청), POST(데이터 제출), PUT(리소스 수정), DELETE(리소스 삭제) 등이 있습니다.
• 포트: HTTP는 기본적으로 80번 포트를 사용합니다. 보안이 강화된 버전인 HTTPS는 443번 포트를 사용하며, 데이터를 암호화하여 전송합니다.

HTTP는 데이터를 텍스트로 교환하기 때문에, 네트워크 상에서 누군가 신호를 가로채면 그 내용이 노출될 수 있습니다. 이러한 보안 문제를 해결하기 위해 등장한 것이 HTTPS입니다.

HTTP 헤더

HTTP 헤더는 클라이언트와 서버 간에 데이터를 주고받을 때 사용되는 메타데이터입니다. HTTP 요청(Request) 또는 응답(Response) 메시지에 포함되며, 통신의 성격을 정의하고 데이터를 어떻게 처리할지에 대한 정보를 제공합니다.

• 요청 헤더(Request Header) : 클라이언트가 서버에게 요청 시 추가 정보를 제공하기 위해 사용. User-Agent 헤더는 클라이언트의 브라우저 정보나 운영체제를 서버에 전달합니다.
• 응답 헤더(Response Header) : 서버가 클라이언트에게 응답할 때 추가 정볼를 제공하는데 사용. Content-Type 헤더는 서버가 응답하는 데이터 형식을 명시.
• 캐싱 제어 : Cache-Control는 클라이언트가 서버 응답을 캐시할 수 있는지, 얼마나 오래 캐시할 수 있는지를 결정합니다.
• 보안 제어 : Authorization 헤더는 요청이 인증 정보를 포함하는지 나타내고, Set-Cookie는 서버가 클라이언트에게 쿠키를 설정하라고 지시합니다.

HTTP 메소드

1. GET
   • 설명 : 서버로부터 리소스를 요청(조회, 검색)할 때 사용됩니다. 클라이언트는 서버에 데이터를 보내지 않고, 단순히 데이터를 요청합니다.
   • 특징 :
     • 데이터 전송 방식 : 데이터를 URL의 쿼리 스트링으로 포함시켜 전송합니다. 즉, 클라이언트가 서버에 요청을 보낼 때, 요청할 데이터가 URL에 포함됩니다.
       • 단, URL에 포함되는 데이터의 양이 제한적입니다.
     • 안전성 및 보안 : URL에 데이터를 포함하기 때문에 민감한 정보를 전송하는데 적합하지 않습니다.
     • 안정성 : GET 요청은 서버의 상태를 변경하지 않기 때문에 안전합니다.
     • 아이템포턴스(Idempotence) : 동일한 GET 요청을 여러 번 보내도 결과는 동일합니다.
     • 캐싱 가능 : GET 요청은 캐싱될 수 있어, 동일한 요청을 반복 요청할 경우 서버 부하를 줄이는 데 유용합니다.
   • 사용 사례 :
     • 웹 페이지 로드 시 HTML 문서, 이미지, CSS, JavaScript 등을 서버에서 가져올 때 사용됩니다.
     • 데이터 베이스에서 정보를 조회하는 RESTful API 요청(GET/users).
2. POST
   • 설명 : POST 메서드는 클라이언트가 서버에 데이터를 제출하거나 서버의 리소스를 생성할 때 사용됩니다.(전송, 리소스 생성)
   • 특징 :
     • 데이터 전송 방식 : 데이터를 HTTP 요청의 본문에 포함시켜 전송합니다. URL에는 데이터가 나타나지 않으며, 클라이언트와 서버 간에 데이터가 좀 더 안전하게 전송됩니다.
     • 안전성 및 보안 : 데이터가 본문에 포함되어 전송되므로, URL에 노출되지 않으며, 비교적 보안성이 높습니다. 민감한 데이터를 전송할 때 주로 사용됩니다.
     • 안전하지 않음 : POST 요청은 서버의 상태를 변경할 수 있습니다.
     • 아이템포턴스가 아님 : 동일한 POST 요청을 여러 번 보내면, 중복된 리소스가 생성될 수 있습니다.
     • 캐싱 불가능 : 일반적으로 POST 요청은 캐싱되지 않고 서버에서 항상 새롭게 처리됩니다.
   • 사용 사례 :
     • 웹 폼 제출, 예를 들어 회원가입, 로그인 등의 데이터를 서버에 전송할 때 사용됩니다.
     • 데이터베이스에 새로운 항목을 추가하는 RESTful API 요청(POST/users)
3. PUT
   • 설명 : PUT 메서드는 서버의 리소스를 생성하거나 완전히 대체할 때 사용됩니다. 특정 리소스를 생성하거나 업데이트하기 위해 사용됩니다.
   • 특징 :
     • 아이템포턴스 : 동일한 PUT 요청을 여러 번 보내더라도 결과는 동일합니다. 예를 들어, 동일한 파일을 여러 번 업로드하면, 파일이 덮어쓰여지며 결과는 변하지 않습니다.
   • 사용 사례 :
     • 특정 리소스의 데이터를 업데이트할 때 사용됩니다. 예를 들어 RESTful API에서 사용자의 정보를 업데이트할 때(예: PUT /users/123)
4. DELETE
   • 설명 : DELETE 메서드는 서버의 리소스를 삭제할 때 사용됩니다.
   • 특징 :
     • 아이템포턴스 : 동일한 DELETE 요청을 여러 번 보내더라도 결과는 동일합니다. 삭제할 리소스가 없으면 단순히 아무런 효과가 없게 됩니다.
   • 사용 사례 :
     • 데이터베이스에서 특정 항목을 삭제하는 RESTful API 요청(예:DELETE /users/123)
     • 파일이나 리소스를 서버에서 삭제할 때.
5. PATCH
   • 설명 : PATCH 메서드는 리소스의 일부를 업데이트할 때 사용됩니다. PUT과 달리 전체 리소스가 아닌 부분적인 업데이트를 수행합니다.
   • 특징 :
     • 아이템포턴스 : 동일한 PATCH 요청을 여러 번 보내더라도 결과는 동일합니다.
   • 사용 사례 ;
     • 특정 리소스의 일부 속성만 변경할 때 사용됩니다. 예를 들어, 사용자의 이메일 주소를 변경하는 경우(PATCH /users/123).
6. HEAD
   • 설명 : GET 요청과 유사하지만, 응답 본문을 포함하지 않습니다. 리소스의 헤더 정보만 요청할 때 사용됩니다.
   • 특징
     • 안전성 및 아이템포턴스 : GET과 동일하게 동작하지만, 응답 본문이 없습니다.
   • 사용 사례
     • 리소스의 메타데이터(예: 파일 크기, 수정 날짜)를 확인할 때.
     • 링크의 유효성이나 리소스의 존재 여부를 검사할 때
7. TRACE
   • 설명 : TRACE 메서드는 클라이언트가 요청이 서버까지 도달하는 경로를 추적할 때 사용됩니다.
   • 특징
     • 보안상 이유로 거의 사용되지 않음 : 보안 위협(예: XXS 공격) 때문에 대부분의 서버와 클라이언트에서 TRACE 요청을 비활성화합니다.
   • 사용 사례 :
     • 네트워크 디버깅용으로 사용되지만, 실무에서는 거의 사용되지 않습니다.

HTTP 상태 코드(HTTP Status Code)

HTTP 상태 코드는 웹 서버가 클라이언트의 요청에 응답할 때, 그 요청이 어떻게 처리되었는지를 나타내는 3자리 숫자입니다. 이 코드는 요청의 결과를 요약해주며, 클라이언트가 다음 행동을 결정하는데 도움을 줍니다. HTTP 상태 코드는 5개의 범주로 나눌 수 있으며, 각 범주는 특정 유형의 응답을 나타냅니다.

1xx (정보 응답, Informational Responses)

• 100 Continue : 클라이언트가 서버에 요청을 보냈을 때, 서버가 요청의 첫 번째 부분을 받고, 나머지 요청을 이어서 보내도 된다는 신호를 나타냅니다.
• 101 Switching Protocols : 서버가 클라이언트의 요청에 따라 프로토콜을 변경하고 있다는 응답입니다. 예를들어, HTTP에서 WebSocket으로 전환하는 경우에 사용됩니다.

2xx (성공, Successful Responses)

• 200 OK : 요청이 성공적으로 처리되었음을 나타냅니다. 주로 GET, POST 요청이 성공적으로 완료되었을 때 사용됩니다.
• 201 Created : 요청이 성공적으로 처리되었고, 새로운 리소스가 생성되었음을 나타냅니다. 주로 POST 요청에서 사용됩니다.
• 204 No Content : 요청은 성공적으로 처리되었지만, 응답 본문에 보내줄 데이터가 없음을 나타냅니다. 예를 들어, 삭제 요청이 성공했을 때, 사용될 수 있습니다.

3xx (리다이렉션, Redirection Responses)

• 301 Moved Permanently : 요청한 리소스가 영구적으로 다른 URI로 이동되었음을 나타냅니다. 브라우저는 이 응답을 받아 새 URL로 자동 리다이렉트합니다.
• 302 Found : 요청한 리소스가 일시적으로 다른 URI로 이동되었음을 나타냅니다. 원래의 URL이 나중에 사용될 가능성이 있음을 의미합니다.
• 304 Not Modified : 클라이언트의 캐시된 데이터가 여전히 유효함을 나타내며, 서버가 새 데이터를 보내지 ㅇ낳고 캐시를 사용하도록 지시합니다.

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

• 400 Bad Request : 클라이언트의 요청이 잘못되었거나, 서버가 이해할 수 없는 형식임을 나타냅니다.
• 401 Unauthorized : 인증이 필요하며, 클라이언트가 유효한 인증 자격 증명을 제공하지 않았음을 나타냅니다.
• 403 Forbidden : 서버가 요청을 이해했지만, 클라이언트가 요청한 리소스에 접근할 권한이 없음을 나타냅니다.
• 404 Not Found : 요청한 리소스를 서버에서 찾을 수 없음을 나타냅니다. 이 코드는 잘못된 URL로 접근했을 때 자주 발생합니다.

5xx (서버 오류, Server Error Responses)

• 500 Internal Server Error : 서버에서 요청을 처리하는 동안 오류가 발생했음을 나타냅니다. 서버 측 문제로 인한 실패입니다.
• 502 Bad Gateway : 서버가 게이트웨이 또는 프록시 역할을 할 때, 상위 서버로부터 잘못된 응답을 받았음을 나타냅니다.
• 503 Service Unavailable : 서버가 일시적으로 요청을 처리할 수 없음을 나타냅니다. 서버가 과부하 상태이거나 유지보수 중 일 때 발생할 수 있습니다.

URL과 URI의 차이점

• URL (Uniform Resource Locator)과 URI (Uniform Resource Identifier)는 웹 주소를 나타내는 개념이지만, 약간의 차이가 있습니다. 모든 URL은 URI의 하위 개념이지만, 모든 URI가 URL인 것은 아닙니다.

1. URI (Uniform Resource Identifier)

• 정의 : URI는 인터넷에서 리소스를 식별하는 데 사용되는 문자열입니다. URI는 리소스를 고유하게 식별하거나위치를 지정할 수 있습니다.
• 종류 :
  • URL (Uniform Resources Locator) : 리소스의 위치를 명시합니다. 예: http://www.example.com
  • URN (Uniform Resources Name) : 리소스를 이름으로 식별합니다. 예: urn:isbn:0451450523 (책의 ISBN 번호)
• 특징 :
  • URI는 리소스를 식별하기 위한 광범위한 개념입니다. URL과 URN이 URI의 두 가지 주요 하위 집합입니다.
  • URI는 특정 리소스에 접근하기 위한 방법을 반드시 포함하지 않을 수 있습니다.

2. URL(Unifrom Resource Locator)

• 정의 : URL은 인터넷 상의 리소스의 위치를 지정하는 URI의 하위 집합입니다. URL은 리소스에 접근하기 위해 경로를 포함하며, 프로토콜(예: http, https), 도메인 이름(예: www.examle.com), 경로(예: /index.html), 포트 번호(예: :80), 쿼리 문자열 등이 포함될 수 있습니다.
• 특징 :
  • URL은 특정 리소스에 접근하기 위해 필요한 경로와 방법을 명시합니다.
  • 예를 들어, https://www.example.com:80/index.html?user=1은 프로토콜, 도메일, 포트, 경로, 쿼리 매개변수를 포함한 URL입니다.

🔐 HTTP의 보안 취약점

1. 도청 가능성

• HTTP는 평문으로 통신하기 때문에 도청이 가능합니다.
• 이를 해결하기 위해 HTTPS를 사용하여 통신 자체를 암호화할 수 있습니다. HTTPS는 SSL/TLS 프로토콜을 추가하여 데이터를 암호화하므로, 제3자가 통신 내용을 도청하더라도 그 내용을 해독할 수 없습니다.
• 암호화된 데이터를 수신자가 복호화하는 과정이 필요합니다.

2. 위장 가능성

• HTTP는 통신 상대를 확인하지 않기 때문에 악의적인 사용자가 중간에서 통신을 가로채거나 자신을 위장하여 사용자를 속일 수 있습니다.
• HTTPS는 SSL/TLS 인증서를 사용하여 서버의 신원을 검증합니다. 이 인증서는 신뢰할 수 있는 기관(CA, 인증 기관)이 발급하며, 사용자는 이 인증서를 통해 통신 상대방이 신뢰할 수 있는 서버인지 확인할 수 있습니다.

3. 변조 가능성

• HTTP는 데이터의 완전성(무결성)을 보장하지 않기 때문에 변조가 가능합니다.
• HTTPS는 메시지 인증 코드(MAC)나 전자 서명 등을 통해 변조를 방지합니다.

🌟 HTTPS란 무엇인가?

HTTPS(HyperText Transfer Protocol Secure)는 인터넷 상에서 정보를 암호화하는 SSL/TLS 프로토콜을 사용해 클라이언트와 서버 간에 자원을 주고받는 통신 규약입니다. HTTPS는 텍스트를 암호화하여 전송하며, 공개키 암호화 방식을 사용합니다.

🔒 HTTPS 통신 흐름

1. 공개키와 개인키 생성: 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 생성합니다.

2. CA 기업과 계약: 신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 공개키 관리를 부탁하며 계약을 체결합니다.

   CA란? : Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업을 의미합니다.

3. 인증서 발급: CA 기업은 해당 기업의 이름, A서버 공개키, 공개키 암호화 방법을 담은 인증서를 생성하고, CA 기업의 개인키로 이를 암호화(서명)하여 A서버에 제공합니다.

4. 인증서 전달: A서버는 암호화된 인증서를 보유하게 되며, 이제 A서버는 자신의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오면, 이 암호화된 인증서를 클라이언트에게 전달합니다.

5. 인증서 확인: 클라이언트가 main.html 파일을 A서버에 요청했을 때, HTTPS 요청이 아닌 경우 CA 기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 됩니다.

   • CA 기업의 공개키는 브라우저가 이미 알고 있습니다. 브라우저는 이 공개키를 사용해 인증서를 해독하고 A서버의 공개키를 얻습니다. 이 과정에서 서명을 확인하여 A서버의 신뢰성을 검증합니다.

6. 대칭키 암호화: 클라이언트는 A서버와 HandShaking 과정에서 주고받은 난수를 조합하여 pre-master-secret-key를 생성한 뒤, A서버의 공개키로 해당 대칭키를 암호화하여 서버로 보냅니다.

7. 대칭키 복호화: A서버는 암호화된 대칭키를 자신의 개인키로 복호화하여 클라이언트와 동일한 대칭키를 획득합니다.

8. master-secret-key 생성: 클라이언트와 서버는 각각 pre-master-secret-key를 사용하여 master-secret-key를 생성합니다. 동일한 키를 사용해 표준화된 방식으로 만들기 때문에 동일한 master-secret-key가 생성됩니다.

9. session-key 생성 및 통신: master-secret-key를 통해 session-key를 생성하고, 이를 이용해 대칭키 방식으로 통신합니다. 이때, 동일한 키를 사용하여 session-key를 생성하기 때문에 키를 주고받는 통신 대신 암호화 후 전달 및 복호화가 이루어집니다.

10. 세션 종료: 각 통신이 종료될 때마다 session-key를 파기합니다.

🚨 HTTPS의 주의점

HTTPS라고 해서 무조건 안전한 것은 아닙니다. 신뢰받은 CA 기업이 아닌 자체 인증서를 발급한 경우, 브라우저에서 "주의 요함", "안전하지 않은 사이트"와 같은 알림을 표시해 주의를 환기시킵니다.

HTTP의 발전 흐름

1. HTTP 0.9

• 기본 개념 : HTTP의 최초 버전으로, 매우 단순한 프로토콜입니다.
• 특징 :
  • 텍스트 기반 : 오직 HTML 파일만 전송 가능.
  • GET 메서드만 지원 : 클라이언트가 서버에 요청한 후, HTML 문서를 수신하고 바로 연결이 종료됨.
  • 헤더 없음 : 상태 코드, 콘텐츠 유형 등의 정보가 없음.
• 한계 : 다른 파일 형식 전송 불가, 매우 제한적 기능.

2. HTTP 1.0

• 기본 개념 : 웹의 상업적 발전과 함께 사용된 버전으로, 현재와 유사한 HTTP 구조를 갖춤.
• 특징 :
  • 헤더 도입 : 요청과 응답에 HTTP 헤더가 추가되어, 상태 코드, 콘텐츠 유형 등을 포함.
  • 다양한 메서드 : GET 외에 POST, HEAD 메서드 도입
  • 단일 연결 : 요청당 하나의 TCP 연결을 사용하고, 응답 후 연결이 종료됨.
• 한계 : 여러 리소스를 요청할 때마다 새로운 연결을 설정해야 하므로 비효율적

3. HTTP 1.1

• 기본 개념 : HTTP의 표준화된 버전으로, 오늘날 가장 널리 사용되는 버전.
• 특징 :
  • 지속 연결(Persistent Connections) : 기본적으로 연결을 유지하여, 하나의 연결에서 여러 요청/응답을 처리 가능.
  • 파이프라이닝(Pipelining) : 응답을 기다리지 않고 여러 요청을 보낼 수 있음(그러나 실사용에서 문제 발생으로 비활성화된 경우가 많음).
  • 호스트 헤더 필드(Host Header Field) : HTTP의 요청 메시지에서 서버의 호스트명(도메인 명 또는 IP 주소)을 지정하는 필드로 하나의 서버가 여러 웹사이트를 호스팅할 때 어떤 웹사이트에 대한 요청인지 서버가 알 수 있게 해주는 역할.
  • 캐싱 및 압축 : 효율적인 데이터 전송을 위해 캐싱과 콘텐츠 압축 지원
• 한계 : 파이프라이닝의 비효율성과 HOLB(Head-of-Line Blocking) 문제로 인해 다수의 리소스 요청 시 성능 저하 가능.
• HOLB : HTTP 1.1에서 파이프라이닝을 사용할 때, 클라이언트가 여러 요청을 순차적으로 보내면, 첫 번째 요청의 응답이 지연될 경우 뒤따르는 모든 요청의 응답도 함께 지연.

4. HTTP 2.0

• 기본 개념 : HTTP 1.1의 성능 문제를 해결하기 위해 등장, 웹 성능을 대폭 향상시킴
• 특징 :
  • 이진 프레이밍(Binary Framing) : 데이터를 이진 형식으로 전송하여, 효율적인 데이터 전송과 처리.
  • 멀티플렉싱(Multiplexing) : 하나의 연결에서 여러 요청/응답을 병렬로 처리하여 HOLB 문제 해결
  • 헤더 압축 : 헤더 정보를 압축하여 네트워크 부하 감소(HPACK)
  • 서버 푸시(Server Push) : 서버가 클라이언트의 요청 없이도 관련 리소스를 미리 전송 가능
  • 한계 : TCP 기반이므로 여전히 TCP의 제약(TCP 연결 설정 비용, 혼잡 제어 등)이 존재

5. HTTP 3.0

• 기본 개념 : QUIC(Quick UDP Internet Protocol) 프로토콜을 기반으로 하는 최신 HTTP 버전, 기존의 TCP 기반 문제를 극복.
• 특징 :
  • QUIC 프로토콜 : TCP 대신 UDP 기반 QUIC을 사용, 더 빠른 연결 설정과 데이터 전송.
  • 스트림 독립성 : 각 스트림이 독립적으로 처리되어, HOLB 문제를 완전히 해결.
  • 내장된 보안 : TLS 1.3을 기본으로 통합하여, 빠르고 안전한 연결 제공.
• 한계 : 아직 널리 채택되지 않았으며, 일부 네트워크 환경에서 호환성 문제가 있을 수 있음.

QUIC(Quick UDP Internet Protocol)

QUIC(Quick UDP Internet Connections) 는 구글이 개발한 전송 계층 프로토콜로, 기존의 TCP(Transmission Control Protocol)의 문제를 해결하고, HTTP/3의 기반이 되는 새로운 프로토콜입니다. QUIC은 전송 계층에서 동작하며, 주로 웹 브라우징의 속도와 보안을 향상시키기 위해 설계되었습니다.

QUIC의 주요 특징

1. UDP 기반:

   • QUIC은 TCP 대신 UDP(User Datagram Protocol) 위에서 동작합니다. UDP는 연결 설정을 필요로 하지 않는 단순한 전송 프로토콜로, TCP보다 훨씬 더 빠르게 데이터를 전송할 수 있습니다. QUIC은 UDP의 장점을 활용하면서, TCP의 기능과 보안성을 추가하여 더 나은 성능을 제공합니다.

2. 빠른 연결 설정:

   • TCP는 연결 설정을 위해 3-way 핸드셰이크를 필요로 하며, TLS(Transport Layer Security)를 추가하면 이 과정이 더 복잡해집니다.반면 QUIC은 연결 설정이 필요하지 않은 UDP를 사용하기 때문에 연결 설정과 TLS 핸드셰이크를 하나의 단계로 통합하여, 한 번의 왕복(Round-Trip Time, RTT) 만에 연결을 설정할 수 있습니다. 이는 특히 처음 연결할 때의 지연을 크게 줄입니다.

3. 내장된 보안:

   • QUIC은 TLS 1.3을 프로토콜 자체에 내장하여, 데이터 전송의 기밀성과 무결성을 보장합니다. 이로 인해 별도의 보안 계층이 필요하지 않으며, 보안 설정이 간소화됩니다.

4. 스트림 독립성:

   • QUIC은 여러 개의 스트림을 단일 연결에서 독립적으로 전송할 수 있습니다. TCP에서는 하나의 패킷이 손실되면 전체 연결이 지연되는 HOLB(Head-of-Line Blocking) 문제가 발생하는데, QUIC은 UDP 위에서 구현되었기 때문에 이러한 문제가 없습니다. 각 스트림은 다른 스트림의 손실이나 지연에 영향을 받지 않고 독립적으로 처리됩니다.

5. 연결 유지 기능:

   • IP 주소와 포트 번호에 강하게 의존하여 네트워크를 변경하면 연결이 끊기고, 새 연결을 설정해야 하는 TCP와는 다르게 QUIC은 네트워크가 변경되더라도(예: Wi-Fi에서 LTE로 전환) 연결을 유지할 수 있습니다. 이는 모바일 환경에서 특히 유용하며, 연결이 끊어지지 않고 지속적으로 데이터를 전송할 수 있게 합니다.

6. 손실 복구:

   • QUIC은 TCP의 혼잡 제어나 패킷 손실 복구 알고리즘을 개선하여, 패킷 손실이 발생했을 때 더 효율적으로 데이터를 복구합니다. 이를 통해 네트워크 혼잡 상황에서도 안정적인 성능을 유지합니다.

7. 프로토콜 확장성과 업데이트:

   • TCP는 대부분 운영체제의 커널에서 구현되어 있어, 프로토콜 개선이나 업데이트가 어렵습니다. 반면, QUIC은 UDP를 기반으로 하며 사용자 공간(user space)에서 구현되므로, 프로토콜의 개선이나 확장이 상대적으로 쉽고 빠릅니다. 이를 통해 새로운 기능을 빠르게 도입하고, 변화하는 요구에 맞춰 프로토콜을 진화시킬 수 있습니다.

QUIC의 단점 및 도전 과제

• UDP 기반의 한계: 일부 네트워크 방화벽이나 중간 장치에서 UDP 트래픽을 제한할 수 있습니다. 이는 QUIC이 이러한 환경에서 잘 작동하지 않을 수 있다는 의미입니다.
• 새로운 프로토콜: QUIC은 비교적 새로운 프로토콜이므로, 모든 네트워크 장비와 소프트웨어가 이를 완전히 지원하지 않을 수 있습니다.

HTTP에서의 바이너리 데이터의 전송 방식

1. MIME 타입을 통한 바이너리 데이터 전송

• MIME(Multipurpose Internet Mail Extensions)는 데이터를 전송할 때, 데이터의 형식과 내용을 명확히 정의하는데 사용됩니다. HTTP 요청이나 응답시에 바이너리 데이터를 전송할 때, Content-Type 헤더에 MIME 타입을 명시합니다. 이를 통해 서버와 클라이언트는 전송되는 데이터의 유형을 이해하고, 이를 적절히 처리할 수 있습니다.

2. 멀티파트 폼 데이터(multipart/form-data)

• 클라이언트가 서버로 파일을 업로드할 때 주로 사용됩니다. multipart/form-data 형식은 바이너리 데이터와 텍스트 데이터를 함께 전송할 수 있는 방식으로, 파일 업로드 시 HTTP POST 요청의 본문에 바이너리 데이터를 포함합니다.

3. Base64 인코딩

• 바이너리 데이터를 텍스트 형식으로 변환하는 방식입니다. 주로 텍스트 기반의 데이터 전송에서 바이너리 데이터를 포함해야 할 때 사용됩니다. 예를 들어 JSON이나 XML로 바이너리 데이터를 포함해 전송할 때 사용되며, 인코딩으로 인해 데이터 크기가 약간 증가하지만 네트워크 전송의 안전성을 높입니다.

4. HTTPS를 통한 보안 전송

• HTTPS는 HTTP에 SSL/TLS 암호화 계층을 추가한 프로토콜로, 바이너리 데이터를 포함한 모든 전송 데이터를 암호화하여 전송합니다. 이는 데이터가 전송 중에 도청이나 변조되는 것을 방지하여, 안전한 통신을 보장합니다.

---

HTTP와 소켓 통신 비교

1. 소켓 통신

소켓 통신은 네트워크 상의 두 노드 간에 직접적인 연결을 설정하여 데이터를 송수신하는 저수준의 방식입니다.

• 효율성
  • 소켓 통신은 데이터를 전송할 때 직접적이고 빠른 통신을 가능하게 합니다. 불필요한 헤더나 프로토콜 레빌의 추가 처리가 없기 때문에, 네트워크 자원을 효율적으로 사용할 수 있습니다.
  • 실시간 애플리케이션(예: 온라인 게임, VolP)에서 자주 사용되며, 이는 빠른 응답 시간과 낮은 지연을 요구하는 경우에 매우 유리합니다.
• 유연성
  • 소켓 통신은 네트워크 통신의 세부사항을 더 많이 제어할 수 있습니다. 데이터 형식, 프로토콜, 전송 방식 등을 직접 설계할 수 있기 때문에, 특정 요구사항에 맞게 커스터마이징할 수 있습니다.
• 복잡성
  • 소켓 통신은 저수준의 네트워크 프로그래밍을 요구합니다. 개발자가 연결 관리, 데이터 흐름 제어, 오류 처리 등을 직접 구현해야 하므로, 복잡성이 높아질 수 있습니다.

2. HTTP

HTTP는 웹에서 표준으로 사용되는 고수준의 프로토콜로, 클라이언트와 서버 간의 요청과 응답을 관리합니다.

• 표준화 및 호환성
  • HTTP는 전 세계적으로 표준화된 프로토콜이기 때문에, 웹 브라우저, 서버, API 등 다양한 플랫폼에서 광범위하게 지원됩니다. 이는 다른 시스템과의 호환성을 보장하고 인터넷 기반의 애플리케이션을 개발할 때 필수적입니다.
  • RESTful API와 같은 웹 서비스는 HTTP를 기반으로 설계되어 있으며, 이를 통해 애플리케이션 간의 상호 운용성을 크게 향상시킵니다.
• **보안 (HTTPS)
  • HTTPS는 HTTP에 SSL/TLS 암호화를 추가하여, 데이터 전송의 기밀성과 무결성을 보장합니다. 이를 통해 사용자는 인터넷을 통해 안전하게 데이터를주고받을 수 있습니다.
  • 보안이 중요한 애플리케이션(예: 온라인 쇼핑, 금융 서비스)에서는 HTTPS가 필수적입니다.
• 캐싱 및 프록시 지원
  • HTTP는 캐싱 메커니즘을 통해 서버 부하를 줄이고, 클라이언트의 응답 속도를 향상시킬 수 있습니다. 이를 통해 네트워크 트래픽을 줄이고, 애플리케이션의 성능을 최적화할 수 있습니다.
  • 또한, HTTP는 프록시 서버를 통한 중계와 로드 밸런싱을 지원하여, 대규모 애플리케이션에서 유리하게 사용됩니다.
• 구현 용이성
  • HTTP는 고수준의 추상화를 제공하여 개발자들이 쉽게 사용할 수 있습니다. 많은 프로그래밍 언어와 프레임워크가 HTTP 지원 라이브러리를 제공하며, 복잡한 네트워크 관리 없이 간단한 요청/응답 모델을 구현할 수 있습니다.

---

쿠키, 세션, 토큰의 차이

쿠키, 세션, 그리고 토큰은 웹 어플리케이션에서 클라이언트와 서버 간의 상태 정보를 유지하거나 사용자를 인증하는 데 사용되는 세 가지 주요 개념입니다.

1. 쿠키 (Cookie)

• 정의
  • 쿠키는 웹 브라우저에 의해 사용자의 로컬 장치에 저장되는 작은 데이터 파일입니다. 쿠키는 주로 사용자 식별 정보, 세션 ID, 사용자 설정 등을 저장하는 데 사용됩니다.
• 특징
  • 저장 위치 : 클라이언트 측(사용자의 브라우저)에서 관리되며, 서버가 쿠키를 생성하고, 클라이언트가 이를 저장합니다.
  • 데이터 수명 : 쿠키는 만료 기간을 설정할 수 있습니다. 만료 기간이 지나면 쿠키는 자동으로 삭제됩니다. 영구 쿠키와 세션 쿠키로 구분됩니다.
  • 사용 사례 : 자동 로그인, 사용자 설정 유지(예: 다크 모드 설정), 방문자 추적 등
  • 보안 : 쿠키 자체는 안전하지 않으며, 민감한 정보를 저장하면 도청이나 조작의 위험이 있습니다. HTTPS를 사용하여 전송하는 것이 일반적입니다.

2. 세션 (Session)

• 정의
  • 세션은 서버에서 사용자별로 관리되는 일시적인 데이터 저장소입니다. 세션은 주로 사용자의 로그인 상태와 같은 중요한 정보를 서버에 저장하여 관리합니다.
• 특징
  • 저장 위치 : 서버 측에서 관리되며, 클라이언트는 세션 ID만을 브라우저의 쿠키나 URL 파라미터로 저장합니다.
  • 데이터 수명 : 세션은 사용자가 웹 브라우저를 닫거나, 서버가 세션을 만료시키기 전까지 유지됩니다. 서버 자원을 사용하므로, 세션의 만료 기간이 짧게 설정되는 경우가 많습니다.
  • 사용 사례 : 사용자 인증 상태 유지, 장바구니 정보 저장, 사용자 맞춤형 정보 관리 등
  • 보안 : 세션 데이터는 서버에 저장되기 때문에 상대적으로 안전하지만, 세션 ID가 유출되면 세션 하이재킹 공격이 발생할 수 있습니다.

3. 토큰 (Token)

• 정의 : 토큰은 주로 사용자 인증을 위해 사용되는 암호화된 문자열입니다. JWT(JSon Web Token)와 같은 토큰은 사용자인증 및 권한 부여를 위해 널리 사용됩니다.
• 특징
  • 저장 위치 : 일반적으로 클라이언트 측(브라우저의 로컬 스토리지 또는 세션 스토리지)에 저장되지만, 서버에 저장할 수도 있습니다.
  • 데이터 수명 : 토큰에는 유효 기간이 있으며, 만료되면 클라이언트는 새로운 토큰을 받아야 합니다.
  • 사용 사례 : API 인증, OAuth 인증, 마이크로서비스 간의 통신 등
  • 보안 : 토큰은 일반적으로 서명되거나 암호화되어 있어, 클라이언트 측에서 민감한 정보를 안전하게 관리할 수 있습니다. 하지만 토큰 자체가 유출되면 보안 위험이 발생할 수 있습니다.

세션 기반 인증 vs 토큰 기반 인증

1. 세션 기반 인증

   • 정의 : 세션 기반 인증은 사용자가 로그인하면 서버가 사용자에 대한 세션을 생성하고, 클라이언트에 세션 ID를 발급하여 세션 ID를 통해 사용자를 식별하는 방식입니다.
   • 작동 방식 :
     • 사용자가 로그인하면 서버는 고유한 세션 ID를 생성하고, 이를 서버 측의 세션 저장소에 저장합니다.
     • 클라이언트는 이 세션 ID를 쿠키에 저장하여 서버에 요청을 보낼 때마다 함께 전송합니다.
     • 서버는 요청에서 받은 세션 ID를 확인하고 저장된 세션 정보와 대조하여 사용자를 인증합니다.
   • 특징 :
     • 서버에 상태 저장 : 세션은 서버 측에 저장되며 서버는 세션 상태를 유지해야 합니다. 따라서 서버는 모든 사용자에 대한 세션 정보를 유지해야 하며, 이는 서버 메모리나 데이터베이스 자원을 소모합니다.
     • 보안성 : 세션 ID가 클라이언트의 쿠기에 저장되기 때문에, 쿠키의 보안 설정이 중요합니다. 세션 하이재킹 공격이 발생할 수 있으므로, 보안을 강화하는 다양한 기법이 필요합니다.
     • 스케일링 문제 : 세션 기반 인증은 서버에 상태를 저장하기 때문에, 여러 대의 서버를 사용하는 경우 세션 동기화 문제를 해결해야 합니다.
   • 세션 기반 인증이 적합한 경우
     • 단일 서버에서의 애플리케이션 : 세션 기반 인증은 서버가 세션 상태를 유지하기 때문에, 하나의 서버에서 모든 요청을 처리하는 소규모 애플리케이션에 적합합니다. 세션 데이터를 서버 메모리에 저장하거나 데이터베이스에 관리할 수 있습니다.
     • 높은 보안 요구 사항이 있는 애플리케이션 : 세션 기반 인증은 모든 인증 정보를 서버에 저장하기 때문에, 민감한 데이터를 다루는 애플리케이션에서 유리합니다. 서버가 모든 세션 데이터를 관리하므로, 클라이언트 측의 보안에 대한 의존도가 줄어듭니다.
     • 짧은 사용자 세션 : 세션 기반 인증은 사용자가 로그아웃하거나 세션이 만료되면 세션을 종료하는 방식으로 작동합니다. 짧은 세션 지속 시간이 필요한 애플리케이션에서는 세션 기반 인증이 효율적일 수 있습니다.

2. 토큰 기반 인증

   • 정의 : 토큰 기반 인증은 사용자가 로그인하면 서버가 암호화된 토큰(JWT등)을 생성하여 클라이언트에 전달하고, 이후 클라이언트가 서버에 요청할 때 이 토큰을 사용해 인증하는 방식입니다.
   • 작동 방식 :
     • 사용자가 로그인하면 서버는 사용자의 정보를 포함한 JWT(JSON Web Token)와 같은 토큰을 생성합니다.
     • 클라이언트는 이 토큰을 로컬 저장소나 쿠키에 저장하고, 이후 요청 시 헤더에 포함하여 서버에 전송합니다.
     • 서버는 토큰을 받아 검증하고, 토큰에 포함된 정보를 바탕으로 사용자를 인증합니다. 서버는 상태를 저장하지 않고 토큰 자체를 검증하여 인증을 수행합니다.
   • 특징 :
     • 무상태 : 서버는 사용자의 상태를 저장하지 않습니다. 토큰 자체가 모든 인증 정보를 포함하고 있기 때문에, 서버 확장성이 뛰어납니다. 이는 클라우드 환경이나 마이크로서비스 아키텍처에서 유리합니다.
     • 보안성 : 토큰은 일반적으로 서명되거나 암호화되어 있어, 클라이언트에서 변경할 수 없으며, 유효성을 검증할 수 있습니다. 그러나 토큰이 유출되면 문제가 될 수 있으므로, 토크느이 수명 관리와 보안에 유의해야 합니다.
     • 확장성 : 토큰 기반 인증은 서버 간 상태를 공유할 필요가 없기 때문에, 여러 서버에서 동일한 인증 방식으로 확장할 수 있습니다.
   • 토큰 기반 인증이 적합한 경우
     • 분산 시스템 또는 마이크로서비스 아키텍처 : 토큰 기반 인증은 서버가 상태를 유지하지 않는 무상태 인증 방식이므로, 여러 서버 간에 상태를 동기화할 필요가 없습니다. 이는 마이크로서비스 아키텍처나 클라우드 환경에서 특히 유리합니다. 서버 확장이 용이하고, 로드 밸런싱에도 적합합니다.
     • API 중심 애플리케이션 : 토큰 기반 인증은 클라이언트가 서버로부터 JWT와 같은 토큰을 받아 요청에 포함시켜 인증하는 방식이므로, API를 통해 여러 클라이언트가 통신할 때 적합합니다. 토큰은 클라이언트가 직접 관리하므로, 서버의 부담이 줄어들고 다양한 클라이언트 간의 호환성이 높아집니다.
     • 확장성 및 성능이 중요한 경우 : 토큰 기반 인증은 서버가 상태를 유지할 필요가 없기 때문에, 서버의 자원 소모를 줄이고 확장성이 높은 시스템을 구현할 수 있습니다. 이는 대규모 사용자 기반을 가진 서비스나 고성능이 요구되는 애플리케이션에 적합합니다.
     • 단기 인증과 로그아웃 불필요한 시스템 : 특정 작업이나 짧은 시간 동안만 인증이 필요한 시스템에서 토큰 기반 인증이 적합합니다. 예를 들어, 인증 후 일정 시간이 지나면 토큰이 자동으로 만료되므로, 추가적인 로그아웃 처리가 필요하지 ㅇ낳습니다.

---

세션 기반 인증의 단점

1. 서버 측 상태 유지로 인한 자원 소모

• 세션 관리 : 세션 기반 인증에서는 서버가 각 사용자의 상태를 세션으로 유지합니다. 이를 위해 서버는 세션 ID와 관련된 데이터를 저장해야 하며, 사용자가 많아질수록 서버의 메모리나 데이터베이스를 많이 소모하게 됩니다.
• 자원 부족 : 많은 사용자에게 서비스하는 대규모 애플리케이션에서는 세션 데이터가 급격히 증가하여 서버 자원이 부족해질 수 있습니다.

2. 서버 확장성 문제

• 세션 동기화 : 여러 서버를 사용하는 분산 환경에서는 세션 동기화가 필요하빈다. 사용자가 다른 서버로 리디렉션될 경우, 각 서버가 동일한 세션 정보를 공유해야 합니다. 이를 해결하기 위해 세션 스토리지를 중앙화하거나 세션을 공유하는 메커니즘이 필요하지만, 이는 추가적인 복잡성과 비용을 발생시킬 수 있습니다.

• 로드 밸런싱의 제약 : 로드 밸런싱을 통해 서버 간의 부하를 분산시키는 경우, 특정 서버에 세션이 고정(sticky)되면 부하 분산이 제대로 이루어지지 않을 수 있습니다.

3. 보안 문제

• 세션 하이재킹 : 클라이언트 측에서 세션 ID가 유출되면, 공격자는 해당 세션을 도용하여 불법적인 엑세스를 할 수 있습니다. 세션 기반 인증에서는 이와 같은 공격에 대비한 추가적인 보안조치가 필요합니다.

• 세션 만료 : 세션이 만료되기 전에 사용자가 로그아웃을 하지 않으면, 사용자의 세션이 남아 있을 수 있어 보안 취약점이 될 수 있습니다.

4. 복잡한 관리

• 세션 만료와 로그아웃 처리 : 사용자가 로그아웃하거나 세션이 만료되면, 서버에서 해당 세션을 올바르게 삭제해야 합니다. 이 과정이 제대로 관리되지 않으면, 잔여 세션 데이터가 서버에 남아 자원을 불필요하게 소모할 수 있습니다.

• 세션 관리 복잡성 : 다수의 사용자가 동시 접속하는 환경에서는 세션 관리가 복잡해질 수 있으며, 세션 데이터를 안전하게 저장하고 관리하기 위한 추가적인 인프라가 필요합니다.

---

JWT (JSON Web Token)란?

JWT (JSON Web Token)는 주로 사용자 인증과 정보 교환을 위해 사용되는 개방형 표준입니다. JWT는 JSON 객체를 사용하여, 클라이언트와 서버 간에 정보(Claims)를 안전하게 전송하기 위해 설계된 암호화된 토큰입니다. JWT는 주로 웹 애플리케이션에서 세션 관리를 대체하거나, API 인증 및 권한 부여를 위한 방법으로 사용됩니다.

JWT의 구조

1. Header
   • 헤더는 토큰 타입(JWT)과 사용할 서명 알고리즘을 지정합니다.
2. Payload
   • 페이로드는 클레임이라고 하는 정보 조각을 포함합니다. 이 클레임은 사용자 정보, 만료 시간, 발행자 등의 데이터를 포함시킬 수 있습니다.
3. Signature
   • 서명은 헤더와 페이로드를 기반으로 생성되며, 비밀 키를 사용하여 특정 알고리즘으로 서명됩니다. 이는 토큰의 무결성을 확인하는 데 사용됩니다.

JWT의 장점

1. 무상태(Stateful) 및 분산 시스템에서의 사용
   • JWT는 클라이언트 측에서 정보를 저장하고 서버에 해당 정보를 전달하기 때문에, 서버가 사용자 상태를 유지하지 않아도 됩니다. 이는 세션을 서버 측에 저장하지 않는 분산 시스템에서 특히 유용합니다.
   • 예를 들어, 사용자가 여러 서버에 접속하는 환경(마이크로서비스 아키텍처)에서 JWT는 세션 관리를 간소화할 수 있습니다.
2. 보안성
   • JWT는 서명(Signature)을 통해 무결성을 보장합니다. 서명된 JWT는 클라이언트에서 임의로 변경할 수 없으며, 서버에서 서명을 검증하여 위변조를 방지할 수 있습니다.
   • JWT는 암호화된 상태로 전송될 수 있어, 민감한 정보를 안전하게 전송할 수 있습니다. 다만, 민감한 데이터는 가능한 한 토큰에 포함하지 않는 것이 좋습니다.
3. 확장성
   • JWT는 확장성이 뛰어나며, 필요에 따라 다양한 클레임을 추가하여 사용자의 권한이나 역할 등을 포함할 수 있습니다.
   • 클라이언트와 서버 간의 통신뿐만 아니라, 서버 간의 통신에도 사용될 수 있습니다.
4. 편리성
   • JWT는 표준 포맷으로 정의되어 있어, 다양한 플랫폼에서 쉽게 사용하고 검증할 수 있습니다. 많은 프로그래밍 언어와 프레임워크에서 JWT를 지원하는 라이브러리를 제공하여 구현이 용이합니다.
   • JWT는 URL에 포함될 수 있으며, 쿠키나 HTTP 헤더에서도 쉽게 사용할 수 있습니다.
5. 자체 포함(Self-Contained)
   • JWT는 사용자의 모든 인증 정보를 자체적으로 포함하므로, 서버는 추가적인 상태 정보를 유지할 필요가 없습니다. 서버는 토큰을 검증하는 것만으로 사용자를 인증할 수 있습니다.

사용 예시

• API 인증 : 클라이언트가 서버에 요청을 보낼 때, JWT를 HTTP 헤더에 포함시켜 서버가 사용자를 인증하고 요청을 처리합니다.
• Single Sign-On (SSO) : JWT는 여러 애플리케이션 간에 인증 상태를 공유하는 데 유용합니다.
  

---

RESTful API

RESTful API는 웹 서비스의 설계 원칙 중 하나인 REST(Representational State Transfer) 아키텍처 스타일을 따르는 API입니다. REST는 클라이언트와 서버 간의 통신을 간단하고 확장 가능하게 만들기 위한 설계 원칙이며, 웹에서 데이터를 주고받을 때 널리 사용됩니다.

REST의 기본 원칙

1. 클라이언트-서버 구조
   • 클라이언트와 서버는 명확히 분리되어야 하며, 클라이언트는 요청을 보내고 서버는 요청에 대한 응답을 합니다. 이 구조는 각각의 독립성을 보장하여 확장성과 유지보수를 용이하게 합니다.
2. 무상태(Stateless)
   • 모든 요청은 독립적이며, 서버는 요청 간의 상태를 유지하지 않습니다. 각 요청은 필요한 모든 정보를 포함하고 있어야 하며, 서버는 요청을 받고 응답을 보낼 뿐, 이전 요청의 상태를 기억하지 않습니다.
3. 캐시 가능(Cacheable)
   • 클라이언트는 서버 응답을 캐싱할 수 있습니다. 캐시를 통해 네트워크 트래픽을 줄이고 성능을 향상시킬 수 있습니다. 서버는 응답에 캐싱 가능한지 여부를 명시해야 합니다.
4. 계층화된 시스템(Layered System)
   • 클라이언트는 중간에 여러 계층이 있는지 알 수 없습니다. 이는 로드 밸런서, 프록시 서버, 보안 게이트웨이 등을 포함한 계층화된 시스템 아키텍처를 허용합니다.
5. 인터페이스 일관성(Uniform Interface)
   • RESTful 시스템은 일관된 인터페이스를 제공해야 합니다. 즉, URL은 리소스를 정확히 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)는 해당 리소스에서 수행할 작업을 정의합니다.
6. 코드 온 디맨드(Code on Demand) (선택 사항)
   • 서버는 클라이언트에 코드(예: JavaScript)를 전송하여 클라이언트 측에서 실행할 수 있습니다. 이는 REST에서 선택적인 제약 사항입니다.

RESTful API의 구성 요소

• URI(Uniform Resource Identifier) : 리소스(데이터)를 식별하는 경로
• HTTP 메소드
  • GET / POST / PUT / PATCH / DELETE
• HTTP 상태 코드 : 요청에 대한 서버의 응답 상태를 나타냄. 예를 들어, 200(성공), 404(리소스 없음), 500(서버 오류) 등이 있습니다.

RESTful API의 장점

• 확장성 : 서버와 클라이언트의 역할이 분리되어 있어 확장성이 뛰어납니다.
• 유연성 : RESTful API는 다양한 데이터 형식(JSON, XML 등)을 지원할 수 있으며, 애플리케이션의 다양한 요구를 충족시킬 수 있습니다.
• 표준화된 구조 : 일관된 인터페이스와 구조로 인해, 개발자들이 API를 쉽게 이해하고 사용할 수 있습니다.

---

도메인과 URL의 차이점

도메인(Domain)과 URL(Uniform Resource Locator)은 웹 주소와 관련된 용어이지만, 그 의미와 용도가 다릅니다.

1. 도메인 (Domain)

• 정의 : 도메인은 인터넷에서 웹사이트를 식별하는 이름입니다. 이는 사용자가 웹 브라우저를 통해 특정 웹사이트에 접근할 수 있도록 도와주는 주소 역할을 합니다. 도메인은 일반적으로 사람에게 읽기 쉬운 형태로 표현되며, IP 주소의 대체물로 사용됩니다.

• 구성 :

  • 최상위 도메인(TLD, Top-Level Domain): .com, .org, .net과 같은 도메인의 가장 오른쪽 부분
  • 두 번째 수준 도메인(SLD, Second-Level Domain): example.com에서 example 부분.
  • 서브도메인(Subdomain): blog.example.com에서 blog 부분

• 역할: 도메인은 웹사이트의 주소를 나타내며, 브라우저가 해당 웹 사이트의 IP 주소를 찾을 수 있도록 DNS(도메인 네임 시스템)에서 사용됩니다.

2. URL (Uniform Resource Locator)

• 정의: URL은 웹 브라우저에서 특정 리소스(웹페이지, 이미지, 동영상 등)를 찾을 수 있는 전체 주소입니다. URL은 도메인 이름뿐만 아니라, 프로토콜, 경로, 포트 번호, 쿼리 매개변수 등을 포함합니다.

• 구성 요소 :

  • 프로토콜 : http://와 같이 리소스에 접근하는 데 사용되는 프로토콜.
  • 도메인 이름 : www.example.com와 같이 리소스를 제공하는 서버의 주소
  • 경로(Path): /page1와 같이 서버 내에서 특정 리소스를 가리키는 경로
  • 쿼리 매개변수: ?id=123와 같이 추가적인 데이터를 서버에 전달하기 위한 매개변수

• 역할 : URL은 특정 리소스에 접근하기 위해 사용자가 필요한 모든 정보를 제공하며, 웹 페이지, 이미지, 파일 등 다양한 리소스에 접근할 수 있도록 해줍니다.

---

CORS (Cross-Origin Resource Sharing)

CORS(Cross-Origin Resource Sharing)는 웹 브라우저에서 실행되는 웹 애플리케이션이 다른 도메인(출처)에서 자원을 요청할 수 있도록 허용하는 보안 기능입니다. CORS는 웹 보안 정책인 동일 출처 정책(Same-Origin Policy)의 제약을 완화하기 위해 도입되었습니다.

1. 동일 출처 정책(Same-Origin Policy)

• 정의 : 동일 출처 정책은 웹 브라우저가 보안을 위해, 한 출처에서 로드된 자바스크립트가 다른 출처의 리소스에 접근하는 것을 제한하는 보안 정책입니다. 여기서 출처(Origin)는 도메인, 프로토콜, 그리고 포트 번호를 포함합니다.
• 문제점 : 동일 출처 정책은 보안을 강화하는데, API와 같이 다양한 출처에서 리소스를 요청하는 애플리케이션에서는 제약이 됩니다.

2. CORS의 역할

• CORS는 이러한 동일 출처 정책의 제약을 완화하여, 서버가 특정 출처에서 오는 요청을 허용할 수 있게 해줍니다. CORS는 클라이언트(주로 웹 브라우저)가 다른 출처의 서버에 요청을 보낼 때, 서버가 틀정 헤더(Access-Control-Allow-Origin 등)를 통해 어떤 출처에서의 요청을 허용할지를 명시하게 됩니다.

3. CORS 동작 방식

• 프리플라이트 요청(Preflight Request): 민감한 요청(예: PUT, DELETE, 또는 비표준 헤더를 사용하는 요청)의 경우, 브라우저는 먼저 OPTIONS 메서드를 사용하여 서버가 실제 요청을 허용하는지 확인하는 프리플라이트 요청을 보냅니다.
• 실제 요청(Simple Request): 서버가 CORS를 허용하면, 브라우저는 실제 요청을 보냅니다. 서버는 응답에 Access-Control-Allow-Origin 헤더를 포함하여 요청 출처가 허용되었음을 클라이언트에 알립니다.

4. CORS의 장점과 사용 사례

• 보안 강화 : CORS는 보안을 유지하면서도, 다양한 출처에서 자원을 요청할 수 있도록 합니다. 이는 API 호출, CDN 사용, 그리고 클라우드 스토리지 서비스와의 통합에 필수적입니다.
• REST API : 클라이언트 측

---

이 글을 통해 HTTP와 HTTPS의 기본 개념과 작동 원리, 그리고 HTTPS가 어떻게 보안을 강화하는지에 대해 이해할 수 있기를 바랍니다. 🌐🔐