일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 멋사 서류평가
- 멋쟁이사자처럼11기
- 백엔드
- 멋사 10기
- 멋쟁이사자처럼10기
- 멋사 면접
- 멋쟁이 사자처럼
- 멋사 서류
- 멋사 합격
- 멋사10기
- 코딩동아리
- ㅏㄴ
- 알림봇
- 크롤링
- 멋사12
- IT동아리
- discord
- API
- 멋사
- 기사 제목 크롤링
- 파이썬
- 멋쟁이사자처럼
- 멋사11기
- 깃허브
- 멋쟁이사자처럼대학
- 파이썬 크롤링
- django
- 디스코드봇
- 웹동아리
- 멋쟁이사자처럼 서류
- Today
- Total
ACHO.pk devlog
[Django] HTTP 본문
HTTP의 특징(통신 프로토콜을 이용해서 클라이언트와 서버가 통신한다)
<작업 프로세스의 순서>
- 서버에 요청, 연결_request 단계
- 요청에 따른 작업(서버)
- 클라이언트에 응답_response 단계
- 연결 해제
HTTP의 특징 중 핵심
클라이언트가 요청한 후 서버가 응답을 하고나면 연결을 끊는다. 즉, 한 번 요청에 한 번 응답 이후에 연결을 끊는다.
클라이언트와 서버의 관계는 1:1이지만 크게 보면 하나의 서버에 여러 개의 클라이언트가 연결된다. N : 1의 관계를 갖는 것이다. 만약 연결을 해제하지 않고 모든 연결 관계를 유지한다면 서버에 부담이 갈 것이다. 따라서 http는 요청과 응답 후에 연결을 해제하는 것이다.
연결 유지
연결 유지를 하기 위해서는 쿠키 또는 세션을 이용한다. (데이터가 pc에 머물면 쿠키, 서버에 머물면 세션이다.)
pc와 서버(쇼핑몰) 이를 예시로 들어보자.
메인 화면 요청 ↔ 메인 화면 응답, 티셔츠 검색 요청 ↔ 티셔츠에 대한 응답 등 로그인, 장바구니, 쿠폰 등 수많은 리퀘스트 리스폰스가 이루어진다. HTTP의 특성상 사용자가 로그인을 한 후 로그인 성공 응답이 오면, 연결이 끊긴다는 말이다. 즉, 페이지 이동이 있을 때마다 로그인을 해야한다는 뜻이다. 데이터가 초기화되지 않고 연결을 유지하기 위해 쿠키와 세션을 이용하는 것이다. 쿠키와 세션의 방식은 똑같은데 데이터가 어디에 머무는지에 따라 다르다!
·쿠키
서버에 접속해서 응답을 요청하고 응답이 오면, pc가 특정한 값을 생성해서 서버에 보낸다. 데이터가 특정한 값의 key 값이 pc와 서버에 존재한다.
다시 동일한 key 값을 가지고 리퀘스트를 한다. 이전에 연결했던 key 값임을 인지하고, 과거에서부터 현재까지 데이터를 유지했던 것처럼 데이터 흐름을 이어나갈 수 있다. 한 번 접속할 때 자동으로 쿠키 값을 생성하고 이를 pc와 서버가 가지고 있다가 통신할 때 비교해가며 연결을 유지하는 방식이 쿠키 방식이다. pc에 데이터가 저장되기 때문에 보안에 문제가 있을 수도 있다.
·세션
세션 방식도 쿠키 방식과 비슷하지만 pc에서 쿠키값을 생성하는 것이 아닌 서버에서 세션값을 생성한다. 이 값을 비교해서 연결을 유지하는 것이 세션 방식이다. 보안상의 문제로 인해 세션을 이용하는 것이 바람직하다.
HTTP 처리 방식
client - server - DB
클라이언트와 서버의 관계는 리퀘스트와 리스폰스하는 관계이며, 이때 사용하는 통신 방식이 HTTP이다.
서버에서 DB에 데이터를 가져올 필요가 있다. 서버도 DB에 요청하고 DB에서 데이터를 리스폰스 받는 과정이 있다.
·클라이언트 - 서버
POST : 데이터를 입력할 때(게시판에 글을 쓰거나 댓글을 달 때)
GET : 어떠한 데이터가 필요할 때, 데이터를 얻을 때
PUT : 기존에 서버에 있는 데이터를 수정할 때(댓글 수정할 때)
DELETE : 삭제할 때
이 외에도 HEAD, OPTION, TRACE, CONNECT가 있다. HTML의 form 태그에서는 POST와 GET 방식만 지원한다.
·서버 - 데이터베이스
create_ 생성 : 데이터베이스에 입력할 때
read_조회 : 데이터베이스를 읽을 때
update_수정 : 데이터베이스를 수정할 때
delete _삭제 : 삭제할 때
POST와 GET 방식(클라이언트 -> request -> 서버)
POST : 요청 메시지에 데이터를 담기 때문에 보안에 강하다. django에서 주로 사용한다.
GET : url에 데이터가 노출되기 때문에 보안에 취약하다. 데이터 길이에 제한이 있다.
URL
·URL의 기본 형태
https://search.naver.com/search.naver?query=food
프로토콜/도메인(호스트)/경로/쿼리
"경로?쿼리" 부분을 간단하게 표현한 것이 URL 맵핑 스트링이다.
·REST URL 형태
https://search.naver.com/search/today/food
프로토콜/도메인(호스트)/URL 맵핑 스트링
이를 django (urls.py) 에서는 url맵핑이라고 하는데 예를 들어,,
view.food(request, today) 는 view의 food함수를 호출한다고 생각하면 된다.
서버 구성
클라이언트(pc 브라우저 등..) → 웹서버 → 애플리케이션 서버 → DB
웹서버와 애플리케이션 서버 외에도 메일 서버, 이미지 서버 등 많은 서버가 있다. 하드웨어적으로 서버를 분리하면 메모리의 효율성이 좋아지지만,, 비용이 많이 발생한다.
클라이언트가 서버 쪽으로 어떠한 데이터를 요청한다.
1. 서버에 있는 "이미 준비되어 있는 자원" 즉 정적인 데이터를 요청했을 경우 웹서버에서 응답을 하면 된다.
2. 클라이언트가 네이버 날씨와 같이 달라지는 동적인 데이터를 요청했을 경우 웹서버가 클라이언트 요청을 받은 후 애플리케이션 서버에 넘긴다. 필요할 경우 데이터베이스도 관여한다.
·웹서버
주로 정적인 데이터 요청 처리
동적인 데이처 요청 시 애플리케이션 서버에 전달
·애플리케이션 서버
주로 동적인 데이터 요청 처리
DB 연동
'프레임워크 > Django' 카테고리의 다른 글
[Django] 데이터베이스(ORM) + 레코드(데이터) 다루기 (0) | 2022.12.28 |
---|---|
[Django] MVT/MVC 패턴과 django framework flow (0) | 2022.12.27 |