본문 바로가기
_TIL

20240828. TIL

by SILTEA 2024. 8. 28.

 

일주일간의 미니 프로젝트를 끝내고 다시 일상으로 돌아왔다.
이번주부터는 Node.js와 Express를 배우게 되는데
오늘 첫시간에서는 네트워크의 기초 및 HTTPS의 기본개념
CORS에 대해서 배웠다.
아주 기초적인 통신개념에 대해서는 어릴 때 컴퓨터 자격증을 공부하며
배웠던 개념뿐이라 생소한 용어들과 이론들이 많았다.
그래도 프론트앤드 개발자로서 익숙해져야 할 단어들과 이론들이니
심화이론까지는 아니더라도 기초까지는 익혀두어야겠다고 생각했다.
그럼 가보자고

 

 

💡  네트워크란?

  • 네트워크는 여러 장치나 시스템을 연결하여 정보를 주고받을 수 있게 하는 시스템
    • 인터넷 : 여러 개의 네트워크가 연결 된 것 ≒ 인트라넷 : 내부에서 사용하기 위한 네트워크
    • → 서로 통신이 가능한 단말들의 연결
  • 네트워크의 특성은 물리적 거리에 따라 달라지며, 이는 데이터 전송 속도와 시간에 영향을 준다.

 

LAN (Local Area Network) MAN (Metropolitan Area Network) WAN (Wide Area Network)
네트워크의 가장 작은 단위 중간 단위 네트워크 네트워크의 가장 큰 단위
건물 단위 ⇒ 작은 단위 대도시 = 도시전체 ⇒ 중간 단위 도시간/국가간/대륙간 통신
짧은 대기시간과 빠른 전송속도 중간정도의 특성 오랜시간과 많은 비용
    긴 대기시간과 느린 전송속도
범위
좁음 중간 넓음
구성
단순 중간 복잡
속도
빠름 중간 느림
택배에 비유
직접 배달 국내 택배 국제 택배

 

 

이미지 출처 ❘ https://unstop.com/blog/difference-between-lan-man-and-wan

 

 

 

🔍 네트워크 계층 : OSI 7계층

💡  OSI 7 계층이란?

  • 네트워크 상에서의 데이터 전송과정 (최상위계층에서 최하위계층 순으로 설명, 택배가 전송되는 과정과 매우 흡사)

💡  순서

  • 응용계층 (Application Layer) - 7 계층
  • 표현계층 (Presentation Layer) - 6 계층
  • 세션계층 (Session Layer) - 5 계층
  • 전송계층 (Transport Layer)- 4 계층
  • 네트워크 계층 (Network Layer) - 3 계층
  • 데이터 링크 계층 (Datalink Layer) - 2 계층
  • 물리 계층 (Physical Layer) - 1 계층

✳️ 예시

이미지 출처 ❘ https://videocompton.com/%EC%A0%84%EC%86%A1-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%9D%98-%EB%B3%80%ED%99%94-part-2-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%84%EC%86%A1-%EA%B3%BC%EC%A0%95-osi-7-%EA%B3%84%EC%B8%B5/

 

 

💡 데이터 캡슐화/역캡슐화 란?

  • 데이터를 전송할 때 데이터 본래의 형태로 전송하는 것이 아닌 캡슐화-역캡슐화를 거쳐 전송
  • 데이터 역캡슐화 : 데이터에 헤더를 제거하고 위 계층에 보내며 캡슐화되었던 데이터를 원래 형태로 복원

 

✅ 중요성

  • 데이터의 안전한 전송과 처리를 보장하기 위해
  • 각 계층에서 필요한 정보를 추가하거나 해석할 수 있게 됨 ⇒ 효율적인 네트워크 통신 가능
  • 데이터의 구조화와 모듈화를 촉진하여 네트워크 프로토콜의 유연성과 확장성을 높임

 

🔍 HTTP / HTTPS

 

💡 HTTP란?

  • 네트워크 계층 중 응용계층에 포함
  • 클라이언트-서버 구조 : HTTP는 클라이언트(웹 브라우저)와 서버 간의 통신을 가능하게 합니다. 클라이언트가 요청을 보내면 서버가 응답하는 방식으로 작동
  • 요청과 응답: HTTP 통신은 요청 메시지와 응답 메시지로 구성됩니다. 이를 통해 클라이언트와 서버가 정보를 주고받는다.
    • 클라이언트는 요청 메시지를 정해진 형식에 따라 서버로 보냄 → 요청이 올바르면 서버는 응답 메세지를 보냄
    • ⇒ 헤더의 종류나 헤더의 값이 유효하지 않으면 서버는 응답하지 않는다.

 

✔️ 무상태성 (Stateless)

  • 상태(=서버의 기억)가 없음을 의미
  • HTTP는 각 요청을 독립적으로 처리한다.
  • 서버는 이전 요청의 정보를 기억하지 않으므로,⇒ 서버가 바뀌어도 명령을 하는데 문제가 없게 됨 : 매번 모든 명령/요구사항을 한 번에 전송하므로
  • ⇒ HTTP 서버에 요청이 몰릴 때 서버를 자유롭게 증설이 가능하게 됨 = 확장성
  • → 클라이언트는 필요한 모든 정보를 매 요청마다 포함해야 한다.

 

✔️ 비연결성 (Conectionless)

  • 연결(= 요청과 응답이 오고 가는 통로)이 지속되지 않음을 의미
  • 요청과 응답을 주고받으려면 네트워크망에서 클라이언트와 서버가 연결되어있어야 함→ 통로를 연결하고 있는 것만으로도 네트워크 비용 발생
  • → 연결통로로 데이터를 주고받을 때 네트워크 비용발생
  • HTTP는 요청과 응답을 주고받지 않을 때 연결을 종료한다 : 한 번만 요청과 응답을 주고받는 상황이 발생하여 연속적인 연결상태가 유지되지 않을 수 있음 ⇒ 한번 연결되었을 때 필요한 요청과 응답을 모두 주고받은 후에 끊을 수 있도록 HTTP는 지속연결과 같은 방법을 사용하기도 함
  • ⇒ 비연결성을 통한 비효율을 해결하려 함

  • 지속연결의 한계 : 응답이 오고 난 후 다음요청을 보낼 수 있음 : 요청과 응답이 동기적으로 오고 감 ⇒ 시간지연 발생
  • 파이프라인 : 요청은 순서대로 가고 있는 것으로 보이지만 비동기적으로 보내지고 있음 ⇒ 응답이 동기적으로 들어오고 있음 (⇒ 첫 번째 응답이 오고 나서 두 번째 응답, 그다음 세 번째 응답)
  • 멀티플렉싱 : 요청뿐만 아니라 요청도 비동기적으로 보냄

 

✔️ 확장성 (Scalability)

  • 자유로운 확장 가능
  • 무상태성 덕분에 서버를 쉽게 확장할 수 있습니다. 요청이 몰릴 때 서버를 자유롭게 증설할 수 있어 효율적인 리소스 관리가 가능하다

 

✅ HTTP의 필요성

  • 웹 통신의 표준: HTTP는 웹에서 정보를 주고받는 표준 프로토콜로, 웹 브라우저와 서버 간의 효율적인 통신을 가능하게 한다.
  • 다양한 데이터 전송: HTTP를 통해 텍스트, 이미지, 비디오 등 다양한 형태의 데이터를 전송할 수 있다.
  • 플랫폼 독립성: HTTP는 다양한 플랫폼과 기기에서 사용할 수 있어, 웹의 보편적 접근성을 보장한다.
  • → 이러한 특성들로 인해 HTTP는 현대 웹 통신의 근간이 되며, 효율적이고 확장 가능한 웹 애플리케이션 개발을 가능하게 한다.

 

💡 HTTPS란?

  • Hypertext Transfer Protocol Secure의 약자
  • 웹 기반 응용 프로그램에서 많이 사용되는 프로토콜에 SSL/ TLS라고 하는 암호화 프로토콜 기능을 더함
  • 기존의 HTTP는 데이터에 암호화 작업을 거치지 않기 때문에 해커에게 데이터를 탈취당했을 때 데이터가 그대로 노출될 가능성이 많다.

💡 HTTP VS HTTPS 차이점

  • 보안: HTTPS는 HTTP에 보안 계층(SSL/TLS)을 추가하여 데이터를 암호화한다.
  • ⇒ HTTPS가 HTTP보다 더 안전하다
  • 데이터 전송: HTTP는 데이터를 암호화하지 않고 전송하지만, HTTPS는 데이터를 암호화하여 전송한다.
  • 해킹 위험: HTTP는 데이터가 암호화되지 않아 해킹에 취약하지만, HTTPS는 암호화를 통해 데이터 탈취의 위험을 줄였다.
  • 암호화 방식: HTTPS는 대칭 키와 비대칭 키 방식을 혼합하여 사용합니다. 이를 통해 안전성을 확보하여 데이터 통신 시간을 최적화한다.

✳️ HTTPS 프로토콜이 HTTP 프로토콜보다 안전한 이유는 주고받는 데이터를 암호화하여 통신하기 때문이다.

 

✔️ HTTPS의 주체

  • 클라이언트 : HTTPS 프로토콜로 사이트를 이용하고 싶은 주체
  • 서버 : HTTPS프로토콜로 사이트를 제공하고 싶은 주체
  • 인증 기관(CA=Certipicate Authority) : 안전한 사이트인지 인증해 주는 역할

 

🔍 대칭 키 암호화 방식 VS 비대칭 키 암호화 방식

  • HTTPS는 대칭 키 암호화 방식과 비대칭 키 암호화 방식을 모두 사용
  • 초기 연결 시 비대칭키 방식으로 안전하게 대칭키를 교환한 후, 실제 데이터 통신에는 빠른 대칭키 방식을 사용하여 안전성과 효율성을 모두 확보한다.
  • 인증서 발급 & 검증할 때 ⇒ 비대칭 키 암호화 방식
  • 클라이언트와 서버가 데이터를 주고받을 때 ⇒ 대칭 키 암호화 방식

 

✔️ 대칭키 암호화 방식

  • 하나의 키만 존재하며, 이 키로 암호화와 복호화를 모두 수행
  • 클라이언트와 서버가 데이터를 주고받을 때 사용 된다.
  • 통신 시간을 최소화하고 효율적인 데이터 교환이 가능하다
  • 키를 안전하게 교환해야 함
  • → 키가 전송 중에 탈취되거나 노출되면 통신 내용이 쉽게 해독되며 보안위험이 발생하기 때문이다.

✔️ 비대칭키 암호화 방식

  • 암호화 키와 복호화 키가 서로 다른 두 개의 키가 존재한다.
  • 주로 인증서 발급 및 검증, 그리고 대칭키를 안전하게 교환하는 데 사용된다.
  • 키 교환이 안전하지만, 연산 과정이 복잡하고 비용이 높아 대칭키처럼 빠르게 데이터를 처리하는데 불리함

💡 대칭키 | 비대칭키 차이점

  • 비대칭키 방식은 보안성이 높지만, 암호화와 복호화 과정이 복잡하고 많은 시간 소요
  • → 클라이언트와 서버 간의 연결이 성립된다면 서로 많은 데이터를 주고받게 될 텐데 이때, 비대칭 키 방식을 이용하게 된다면 많은 시간을 소요하여 암호화/복호화를 진행하여 데이터를 주고받게 된다.
  • 대칭키 방식은 상대적으로 단순하고 빠르지만, 키 교환 과정에서 보안 위험이 있을 수 있습니다.

 

🔍 CORS 개념

 

💡 CORS란?

  • CORS (Cross-Origin Resource Sharing, 교차 출처 리소스 공유)
  • 웹 브라우저에서 보안상의 이유로 실행되는 Same-Origin Policy(SOP)을 우회하기 위한 메커니즘
  • SOP를 우회하여 다른 출처의 리소스를 안전하게 사용할 수 있게 해 준다.
  • CORS는 SOP의 한계를 극복하기 위해 필요합니다. SOP는 보안상 안전하지만, 현대 웹 서비스에서는 다른 출처의 리소스를 사용해야 하는 경우가 많기 때문입니다. 또한, 클라이언트와 서버가 분리되어 있는 경우에도 CORS가 필요하다.

 

✳️ 주요 CORS 헤더 (서버에서)

  • Access-Control-Allow-Origin: 리소스에 접근할 수 있는 출처(도메인)를 지정한다.
  • Access-Control-Allow-Methods: 서버에서 허용할 HTTP 메서드를 지정한다.
    • ex) GET, POST, DELETE, PUT/PATCH
  • Access-Control-Allow-Headers: 서버에서 허용할 HTTP 헤더를 지정한다.
    • 서버에서 특정 HTTP 헤더를 허용하고 싶다면 헤더를 작성해 주면 된다.

 

 

🔍 CORS 작동 방식

💡  작동 순서

  1. 클라이언트(브라우저)가 다른 출처(origin)의 리소스에 대한 요청을 보낸다.
  2. 브라우저는 이 요청이 다른 출처라는 것을 감지하고, CORS 정책을 적용한다.
  3. 브라우저는 서버에 "preflight" 요청을 보냅니다. 이는 OPTIONS 메서드를 사용한 HTTP 요청이다.
  4. 서버는 이 preflight 요청에 대해 허용된 메서드, 헤더, 출처 등을 포함한 CORS 헤더로 응답한다.
  5. 브라우저는 서버의 응답을 확인하고, 요청이 허용되는지 판단한다.
  6. 허용된다면, 브라우저는 원래 요청을 보낸다.
  7. 서버는 요청에 대한 응답을 보내며, 이때도 적절한 CORS 헤더를 포함시킨다.
  8. 브라우저는 최종적으로 이 응답을 클라이언트 애플리케이션에 전달한다.

이 과정에서 주요 CORS 헤더로는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 사용된다.

 

✳️ 예시

  • 요청 및 응답

 

  • CORS 에러

 

 

 

💡 PreFlight Request의 필요성

  • 만약 POST/DELETE와 같이 서버의 데이터를 변경하는 요청이라면 서버는 요청을 수행뒤에 헤더에 응답헤더에 클라이언트/브라우저가 필요로 한 요청이 없다는 데이터를 (ACAO) 브라우저에 보내게 되고 브라우저는 CORS에러를 띄우지만 서버는 이미 POST와 PUT처럼 요청을 수행한 뒤이기 때문에 문제가 발생한다
  • ⇒ 그래서 실제 요청을 보내기 전에 preflight request를 보내어 서버의 응답을 받고 확인한 뒤 실제 요청을 보낸다.

→ Error를 발생시키는 주체 : 브라우저

 

 

참고자료 

 

'_TIL' 카테고리의 다른 글

20240820. TIL  (0) 2024.08.20
20240813. TIL  (0) 2024.08.14
20240812. TIL  (0) 2024.08.13
20240808. TIL  (2) 2024.08.09
20240807. TIL  (3) 2024.08.08

관련글

티스토리툴바