백엔드/django

[SGC]01_웹프로그래밍과 Django

묘걍 2024. 1. 26. 18:12

👉🏻 네트워크

  • 컴퓨터 외 세상의 모든 사물이 네트워크로 연결되어있다
  • IoT
    • 생활 밀착형 가전제품(냉장고, 밥통, 보일러 ...)

🧩 네트워크에 연결되어 있다는 건

  • 소형 디바이스로 네트워크에 들어가기만 하면 내가 네트워크에 존재하는 모든 사물을 컨트롤하거나 모니터링할 수 잇다
  • IT의 모든 서비스는 네트워크가 연결되어있다는 가정 하에 서비스가 진행된다
    • IT 네트워크 분야도 크고 중요한 분야

🧩 웹 프로그래밍과 네트워크

  • 네트워크가 연결된 상태에서, 네트워크 안에서 웹서비스 (인터넷)을 사용하게 된다
  • 네트워크가 연결되어있지 않으면 인터넷 서비스는 존재하지 않는다
  • 네트워크가 사물과 사물(PC와 PC), 클라이언트와 서버가 연결된 것 뿐만 아니라 스마트폰, 생활가전, 클라우드 등 모든 것이 네트워크로 연결
    • 네트워크로 연결되어있는 범위 내에서 모든 웹서비스를 가용할 수 있다

 

👉🏻 클라이언트와 서버

🧩 클라이언트

  • 랩탑, PC, 태블릿, 스마트폰... 등의 장치들에 기본 설치되어 구동됨
    • 웹서핑, 블로그, SNS 등의 활동
    • 디바이스와 소프트웨어를 아울러 말하기도 함
  • 브라우저를 통해서 특정 사이트에 들어가 그들이 제공하는 서비스를 받음
  • 서버에 접근해서 데이터를 받고 사용하는 곳
  • 서버쪽으로 액션을 취해서 서버쪽 데이터를 보거나 컨트롤하기 원한다면 클라이언트다
    • 특정 도메인이나 프로토콜을 이용해 서버로 접근

✅ 종류

  • 웹 브라우저가 큰 역할
  • 여기에 앱도 추가됨
  • 명령 프롬프트, 텔넷, SSH 등

 

🧩 서버

  • 서비스가 있는 곳
  • 특정 데이터가 모여있는 곳

🧩 서버와 클라이언트의 관계

출처: SEOUL G-캠프 유튜브

데이터를 주거니 받거니

✅ 요청(Request)

  • 클라이언트가 먼저 요청을 한다
    • "오늘의 날씨는 어떤가요?"
    • "나는 90년대 노래를 듣고 싶어"
    • "오늘의 추천 메뉴는 무엇인가요?"
    • "지도에서 내 위치는 어디 있나요?"
  • 요청이 들어오면 서버는 그 요청에 맞는 적당한 작업(기능)을 수행
    • DB에서 데이터를 가져오거나
    • 다른 서버로 위임을 하거나

✅ 응답(Response)

  • 모든 작업이 끝나면
  • 클라이언트가 요청한 것을 응답해줌

✅ HTTP

  • 클라이언트와 서버의 통신이 이루어질 때 가장 많이 사용되는 것이 HTTP 통신이다

👉🏻 HTTP 연결

출처: SEOUL G-캠프 유튜브

  1. 클라이언트가 서버에 데이터를 요청한다
  2. 서버는 그에 합당한 데이터를 찾아, 가공해서
  3. 응답을 해준다
  4. HTTP는 이 관계를 끊어버린다 (연결 해제)

 

  • 클라이언트와 서버는 날씨를 물어본 순간 연결이 된다
  • 연결을 맺고 있다가 응답을 해주고 나면
  • 연결을 맺었던 고리를 과감하게 끊어버린다

✅ 연결을 끊어버리는 이유?

  • 지금은 1:1관계지만,
  • 사실 네이버와 클라이언트의 관계는 N:1이다

  • 수많은 클라이언트들이 서버에 요청을 보낼 수 있음
  • 모든 사람의 연결 고리를 유지하면 서버는 폭발할지도 모른다
  • 그래서 HTTP는 한번 요청 - 응답이 이루어지면 그 연결을 순간적으로 끊어버린다
  • 요청이 다시 올 경우 다시 연결을 해준다
  • 순간적으로 연결을 맺고 끊음을 반복

✅ 쿠기와 세션

  • 위 과정만 해도 벌써 연결을 맺고 끊는 과정을 두 번 반복함
  • 이 외에도 여러 작업이 필요 (장바구니에 담기, 구매, 쿠폰 적용, 취소 ...)
  • 이 사람이 로그인 됐다고 연결되는 순간 연결이 끊어짐
    • 각 페이지를 이동할 때 마다 로그인을 해야됨
    • 장바구니에 물건들을 담아놔도 연결이 끊겨버리면 물건이 하나도 담기지 않는 것
    • 불편
  • 연결을 유지하고 싶음
  • 이 때 사용하는 것이 쿠키와 세션
  • 쿠키: 데이터가 PC에 머문다

  1. 서버에 접속해서 요청할 때 PC가 유니크한 특정 값을 생성한다
  2. PC가 생성한 문자열을 서버에 보내준다
    • 그 문자열의 key값은 PC와 서버 모두에 있다
  3. 동일한 key값을 가지고 다시 request를 한다
  4. 서버에서 key값을 비교하여 연결한 적 있음을 확인한다
  5. 마치 연결이 과거에서부터 지금까지 유지되는 것 처럼 데이터 흐름을 이어나갈 수 있다

한 번 접속할 때 자동으로 쿠키값 생성, PC와 서버에 모두 두고 비교해서 연결 유지

보안의 문제가 있을 수도 있다

  • 세션: 데이터가 서버에 머문다

  • 쿠키와 방식은 같으나, PC에서 쿠키 값을 생성하는 것이 아니라
  • 서버에서 세션값을 생성한다
  • 서로 비교해서 연결을 유지한다

보안상의 이유나 고수준의 방식으로는 세션을 이용한다

👉🏻 HTML 처리 방식

출처: SEOUL G-캠프 유튜브

🧩 Client - Server

  • Request - Response
  • 통신 방식: HTTP
  • Request방식은 8가지
    • 가장 많이 쓰이는 POST, GET, PUT, DELETE
  • 웹 프로그래밍, 웹 브라우저에서 지원 하는 것 = HTML 문서
    • HTML form태그를 사용
    • 여기서는 POST와 GET만 지원한다

✅ POST

  • 새로운 데이터를 입력하고 싶을 경우
  • CREATE와 관련
  • 새로운 글을 생성
  • 게시판에 글 쓰기
  • 블로그에 댓글 달기

✅ GET

  • 어떤 데이터가 필요할 때, 데이터를 얻기를 원할 때
  • READ와 관련
  • "오늘의 날씨를 알려줘"

✅ PUT

  • 데이터 수정할 때
  • UPDATE와 관련
  • 내가 단 댓글을 수정

✅ DELETE

  • 데이터 삭제
  • DELETE와 관련
  • 내가 작성한 글을 삭제

🧩 Server - DB

  • 특정 데이터를 가져와야할 경우
  • Request - Response

🧩 POST와 GET

✅ GET

  • 내가 요청한 데이터가 URL에 그대로 노출된다

네이버에 접속

날씨를 검색하면

이 데이터가 서버로 날라감 (Request)

도메인이 지저분하게 붙는다

쿼리스트링이라고 함

  • 데이터 길이에 제한이 있다
    • 도메인 뒤에 쿼리스트링으로 붙어나감
  • 상대적으로 보안에 취약하다
    • 브라우저에 데이터가 노출됨

✅ POST

  • GET을 개선한 방식
  • 데이터 요청시 요청 메시지에 데이터를 담는다
    • 도메인에 담는 게 아니라 문서 뒷편 (헤더파일 등, 바디 부분)에 데이터를 담아서 감
  • 상대적으로 보안에 강하다
  • Django에서 주로 사용한다

👉🏻 URL

🧩 URL 기본 형태

✅ 프로토콜

  • 어떤 통신 규약을 이용해서 뒤에 있는 도메인을 서버로 보낼건지 결정
  • http, https, ftp, dhcp, ...

✅ 도메인

  • google, naver ...
  • 여기까지 하면 서버에 진입한 것

✅ 경로

  • 서버 안의 어떤 경로로 들어갈 것인가

✅ 쿼리

  • 해당 경로까지 들어가서 어떤 요청을 할 것인가
  • 요청 구문

 

🧩 REST URL 형태

  • 요즘은 기본 형태를 약간 변형한 REST URL이라는 형태도 있다
  • 구구절절 다 쓰지 않는다

✅ URL 맵핑

  • 모두 자원으로 생각해서 간단하게 만들자

🧩 REST와 Django url 맵핑

 

출처: SEOUL G-캠프 유튜브

  • search와 weather 사이에 매핑 규칙을 정해놓는다
    • 해당 규칙은 상황에 맞게 바뀔 수 있다
  • 해당 형식으로 데이터가 들어오면
  • 장고에서 view에 있는 weather 함수를 실행시킨다
    • 실행될 함수를 미리 정의
  • 규칙에 들어온 값을 넣어준다(?)
  • 날씨를 알려줘, 오늘의 날씨를

미리 어떤 기능을 만들어두고 그것과 매핑시킨다

 

👉🏻 서버 구성

🧩 Client

  • 브라우저, 앱 등 ...

🧩 Server

  • 서버를 하나로 이용해도 되지만
  • 실무에서는 하나로 하는 경우는 없다
  • 하드웨어적으로 서버를 분리하면 메모리 효율성이 좋아지고, 퍼포먼스가 좋아진다
  • 하지만 비용이 많이 들고 관리하기가 어렵다

✅ 정적 데이터

  • 어떤 데이터를 서버쪽으로 요청
    • 서버에 있는 (미리 준비된)자원 (글, 음원, 그림)
  • 이 모든건 정적인 데이터
    • 그때그때 변하지 않음
  • 그냥 원래대로 응답하면 됨

✅ 동적 데이터

  • 오늘의 날씨처럼 계속 바뀌는 것
  • 웹서버가 클라이언트 요청을 받은 다음
  • 이걸 애플리케이션 서버로 위임한다
  • 웹서버가 애플리케이션 서버한테 "오늘의 날씨 데이터를 가공하거나 가져와서 나에게 알려줘, 내가 클라이언트한테 응답할게"
  • 필요하면 DB까지 갔다오는 것

이 외에도 더 많은 서버를 따로 둘 수 있다

 

 

 

 

 

 

출처: https://youtu.be/Cph0s6dT0Ik?si=qKhub2KOD9sQnyG0