👉🏻 네트워크
- 컴퓨터 외 세상의 모든 사물이 네트워크로 연결되어있다
- IoT
- 생활 밀착형 가전제품(냉장고, 밥통, 보일러 ...)
🧩 네트워크에 연결되어 있다는 건
- 소형 디바이스로 네트워크에 들어가기만 하면 내가 네트워크에 존재하는 모든 사물을 컨트롤하거나 모니터링할 수 잇다
- IT의 모든 서비스는 네트워크가 연결되어있다는 가정 하에 서비스가 진행된다
- IT 네트워크 분야도 크고 중요한 분야
🧩 웹 프로그래밍과 네트워크
- 네트워크가 연결된 상태에서, 네트워크 안에서 웹서비스 (인터넷)을 사용하게 된다
- 네트워크가 연결되어있지 않으면 인터넷 서비스는 존재하지 않는다
- 네트워크가 사물과 사물(PC와 PC), 클라이언트와 서버가 연결된 것 뿐만 아니라 스마트폰, 생활가전, 클라우드 등 모든 것이 네트워크로 연결
- 네트워크로 연결되어있는 범위 내에서 모든 웹서비스를 가용할 수 있다
👉🏻 클라이언트와 서버
🧩 클라이언트
- 랩탑, PC, 태블릿, 스마트폰... 등의 장치들에 기본 설치되어 구동됨
- 웹서핑, 블로그, SNS 등의 활동
- 디바이스와 소프트웨어를 아울러 말하기도 함
- 브라우저를 통해서 특정 사이트에 들어가 그들이 제공하는 서비스를 받음
- 서버에 접근해서 데이터를 받고 사용하는 곳
- 서버쪽으로 액션을 취해서 서버쪽 데이터를 보거나 컨트롤하기 원한다면 클라이언트다
- 특정 도메인이나 프로토콜을 이용해 서버로 접근
✅ 종류
- 웹 브라우저가 큰 역할
- 여기에 앱도 추가됨
- 명령 프롬프트, 텔넷, SSH 등
🧩 서버
- 서비스가 있는 곳
- 특정 데이터가 모여있는 곳
🧩 서버와 클라이언트의 관계
데이터를 주거니 받거니
✅ 요청(Request)
- 클라이언트가 먼저 요청을 한다
- "오늘의 날씨는 어떤가요?"
- "나는 90년대 노래를 듣고 싶어"
- "오늘의 추천 메뉴는 무엇인가요?"
- "지도에서 내 위치는 어디 있나요?"
- 요청이 들어오면 서버는 그 요청에 맞는 적당한 작업(기능)을 수행
- DB에서 데이터를 가져오거나
- 다른 서버로 위임을 하거나
✅ 응답(Response)
- 모든 작업이 끝나면
- 클라이언트가 요청한 것을 응답해줌
✅ HTTP
- 클라이언트와 서버의 통신이 이루어질 때 가장 많이 사용되는 것이 HTTP 통신이다
👉🏻 HTTP 연결
- 클라이언트가 서버에 데이터를 요청한다
- 서버는 그에 합당한 데이터를 찾아, 가공해서
- 응답을 해준다
- HTTP는 이 관계를 끊어버린다 (연결 해제)
- 클라이언트와 서버는 날씨를 물어본 순간 연결이 된다
- 연결을 맺고 있다가 응답을 해주고 나면
- 연결을 맺었던 고리를 과감하게 끊어버린다
✅ 연결을 끊어버리는 이유?
- 지금은 1:1관계지만,
- 사실 네이버와 클라이언트의 관계는 N:1이다
- 수많은 클라이언트들이 서버에 요청을 보낼 수 있음
- 모든 사람의 연결 고리를 유지하면 서버는 폭발할지도 모른다
- 그래서 HTTP는 한번 요청 - 응답이 이루어지면 그 연결을 순간적으로 끊어버린다
- 요청이 다시 올 경우 다시 연결을 해준다
- 순간적으로 연결을 맺고 끊음을 반복
✅ 쿠기와 세션
- 위 과정만 해도 벌써 연결을 맺고 끊는 과정을 두 번 반복함
- 이 외에도 여러 작업이 필요 (장바구니에 담기, 구매, 쿠폰 적용, 취소 ...)
- 이 사람이 로그인 됐다고 연결되는 순간 연결이 끊어짐
- 각 페이지를 이동할 때 마다 로그인을 해야됨
- 장바구니에 물건들을 담아놔도 연결이 끊겨버리면 물건이 하나도 담기지 않는 것
- 불편
- 연결을 유지하고 싶음
- 이 때 사용하는 것이 쿠키와 세션
- 쿠키: 데이터가 PC에 머문다
- 서버에 접속해서 요청할 때 PC가 유니크한 특정 값을 생성한다
- PC가 생성한 문자열을 서버에 보내준다
- 그 문자열의 key값은 PC와 서버 모두에 있다
- 동일한 key값을 가지고 다시 request를 한다
- 서버에서 key값을 비교하여 연결한 적 있음을 확인한다
- 마치 연결이 과거에서부터 지금까지 유지되는 것 처럼 데이터 흐름을 이어나갈 수 있다
한 번 접속할 때 자동으로 쿠키값 생성, PC와 서버에 모두 두고 비교해서 연결 유지
보안의 문제가 있을 수도 있다
- 세션: 데이터가 서버에 머문다
- 쿠키와 방식은 같으나, PC에서 쿠키 값을 생성하는 것이 아니라
- 서버에서 세션값을 생성한다
- 서로 비교해서 연결을 유지한다
보안상의 이유나 고수준의 방식으로는 세션을 이용한다
👉🏻 HTML 처리 방식
🧩 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 맵핑
- search와 weather 사이에 매핑 규칙을 정해놓는다
- 해당 규칙은 상황에 맞게 바뀔 수 있다
- 해당 형식으로 데이터가 들어오면
- 장고에서 view에 있는 weather 함수를 실행시킨다
- 실행될 함수를 미리 정의
- 규칙에 들어온 값을 넣어준다(?)
- 날씨를 알려줘, 오늘의 날씨를
미리 어떤 기능을 만들어두고 그것과 매핑시킨다
👉🏻 서버 구성
🧩 Client
- 브라우저, 앱 등 ...
🧩 Server
- 서버를 하나로 이용해도 되지만
- 실무에서는 하나로 하는 경우는 없다
- 하드웨어적으로 서버를 분리하면 메모리 효율성이 좋아지고, 퍼포먼스가 좋아진다
- 하지만 비용이 많이 들고 관리하기가 어렵다
✅ 정적 데이터
- 어떤 데이터를 서버쪽으로 요청
- 서버에 있는 (미리 준비된)자원 (글, 음원, 그림)
- 이 모든건 정적인 데이터
- 그때그때 변하지 않음
- 그냥 원래대로 응답하면 됨
✅ 동적 데이터
- 오늘의 날씨처럼 계속 바뀌는 것
- 웹서버가 클라이언트 요청을 받은 다음
- 이걸 애플리케이션 서버로 위임한다
- 웹서버가 애플리케이션 서버한테 "오늘의 날씨 데이터를 가공하거나 가져와서 나에게 알려줘, 내가 클라이언트한테 응답할게"
- 필요하면 DB까지 갔다오는 것
이 외에도 더 많은 서버를 따로 둘 수 있다
출처: https://youtu.be/Cph0s6dT0Ik?si=qKhub2KOD9sQnyG0
'백엔드 > django' 카테고리의 다른 글
[SGC]05_학사관리프로그램 만들기-I (1) | 2024.01.30 |
---|---|
[SGC]04_데이터베이스(ORM) (2) | 2024.01.30 |
[SGC]03_Django 프로젝트 설계 (0) | 2024.01.27 |
[SGC]02_Django설치 및 프로젝트 생성 (0) | 2024.01.26 |
[django다시시작하기] 들어가면서 (1) | 2023.10.11 |