[Django 심화] HTTP와 웹의 동작 방식

옛날엔 post요청 등 변경사항이 생기면 새로고침이 되어 html css js 다 새로 가져오는 방식(서버에서 render 해줌)
> 동영상을 보다 댓글을 달았을 때 동영상이 처음으로 돌아가는 불편함이 있음
AJAX(비동기 자바스크립트) 기술을 사용하여 일부분의 데이터만 보내주고 업데이트하는 방식으로 변경되었음
> 댓글을 등록해도 동영상에 지장을 주지않음

프론트엔드 프레임워크

:사용자가 웹, 앱 서비스에 접속하면 보이는 화면에 대한 개발을 위해 코딩을 할 때 이를 도와주는 도구를 제공해주는 것

1. ANGULAR(앵귤러): https://angular.kr Angular

2. React(리엑트): https://reactjs.org React

3. Vue.js(뷰): https://vuejs.org Vue.js - The Progressive JavaScript Framework | Vue.js (vuejs.org)

프론트엔드와 백엔드를 git 레포지토리에 따로 저장하므로
rander, context 방식이 아닌 다른 방식으로 통신시켜주어야하는데 DRF가 그 과정을 편안하게 해줌

포스트맨 설치 - Request와 Response 살펴보기

포스트맨의 역할

: 다양한 HTTP 요청들을 보낼 수 있음

포스트맨 설치법

1. 포스트맨 사이트 접속 (참고자료)

2. Product > Get started free 클릭

3. 내 컴퓨터의 맞는 버전을 다운로드(알아서 맞는 버전이 보이긴함)

4. 실행 후 로그인

5. 워크스페이스 만들기(프로젝트별로!)

포스트맨 써보기

: 요청들을 미리 관리할 수 있음

: 주소를 입력했을 때 보이는 화면은 간단해보이지만 사실 많은 것들이 왔다갔다 했다는 것을 확인 할 수 있음

1. Collection 만들기 (종류별로 만들때!)

2. collection명 입력하기(원하는대로!)

3. 실제 request 만들기

4. request 명 입력

5. 네이버 주소로 GET요청 보내기

6. Response가 돌아옴

HTTP - 웹의 요청 흐름 살펴보기

HTTP ( hypertext transter protocol)

: 웹 서버와 사용자의 인터넷 브라우져 사이에 문서를 전송하기 위해 사용되는 통신 규약

hypertext: 서로 연결된 문자 데이터 파일 -> html

transter: 이동, 전송

protocol: 데이터를 원활히 주고 받기 위해 정해 놓은 약속

구조를 정한다는 것으로 우편을 예시로 들면 이해가 쉽다.

우편을 보낼 때에도 위쪽엔 보내는 사람 아래쪽에는 받는 사람을 적는다는 규칙 등 이 있고,

이와 같은 규칙들을 어기면 우편을 주고받는 것에 어려움이 생기게 된다.

예시와 같이 html에도 어떤식으로 보낼 지에 대한 규칙이 있다.

html 등 이미지, 영상, 파일 등 을 전송하기 위한 약속

(네트워크 관련 공부이다! 하지만 여기서 다 다룰 수는 없고 따로 공부가 필요함)

지금은 이런 개념이 있구나~ 하는 정도로만 알아두기!

웹브라우저 흐름

1. DNS 조회

DNS (Domain name system)

: 도메인 네임 ex)naver.com 을 검색하여 ip주소를 몰라도 검색 할 수 있음

핸드폰 주소록과 비슷한 개념, 번호를 외우고 있지 않아도 이름을 검색하여 전화 할 수 있음
ex) 도메인 네임=저장명(이름) / ip주소=핸드폰번호

* 터미널에 nslookup <도메인> 을 검색했을 때 나오는 ip주소를 입력해도 같은 사이트가 검색 된다.

2. HTTP 요청 메시지 작성

3. Socket 라이브러리를 통해서 전달

4. TCP/IP 작성되고 이 안에 HTTP 메시지가 포함

프로토콜 계층

: 어플리케이션 > Socket Library > TCP > IP > LAN > 인터넷

IP (Internet Protocol)

* 지정한 IP주소로 전송

* 출발지 IP와 목적지 IP를 작성

* 송신하면 노드들을 거쳐서 송신이 된다.

한계(문제가 생기는 경우)
* 받을 대상이 없을 수도 있다.
* 중간에 패킷이 손실되거나 순서대로 오지 않을 수 있다.
* 같은 IP를 사용하는 어플리케이션이 여러개라면 문제가 생긴다.

TCP

: IP를 TCP로 보완한다.

* 출발지 port와 목적지 port 정보

* 전송제어와 순서

* 검증 정보 등이 실린다.

특징
* 연결지향 TCP 3 way handshake를 통해 연결이 된건지 먼저 확인 한다.
* 데이터 전달을 보증한다.
* 순서를 보장한다.
* 신뢰할 수 있어서 현재 대부분 TCP를 사용한다.

TCP 3 way handshake

클라>서버: SYN
서버>클라: SYN+ACK
클라>서버: ACK최적화를 통해 요즘은 3단계에서 데이터 송신을 한다.
SYN을 통해 연결, ACK를 통해 승인

UDP (User Datagram Protocol)

* 기능이 거의 없고

* TCP기능들이 없다.

* IP와 유사한데 포트와 체크섬만 추가됐다.

* 어플리케이션에서 추가 작업이 필요하다.

* 원하는 기능들을 추가해서 만들 수 있는 하얀 도화지 같은 프로토콜이다.

Port

: 항구

* 한컴퓨터에서 게임 화상통화 웹브라우저를 다 킬 수가 있다.

* 포트는 같은 IP내에서 프로세스 구분을 해줄 수가 있다.

* 0~65535

* 0~1023은 잘 알려진 포트로 사용하지 않는게 좋다.

DNS

* IP는 변경될 수 있다.

* 도메인병을 이용해 주소록처럼 이용

URI (Uniform Resource Identifier) 와 웹 브라우저 요청 흐름

URI vs URL vs URN

* URI는 locator, name 또는 둘다 추가로 분류될 수 있다.

* URI라는 개념아래에 URL과 URN이 존재한다.

* URN은 거의 쓰이지 않는다.

URI

* Uniform: 리소스 식별을 위한 통일 방식

* Resource: 리소스

* Identifier: 식별자

* 포트 생략시 http는 80 https는 443

* 리소스 경로는 계층적 구조로 이루어져있다.

* fragment: 페이지 내에서 위치

--- HTTP는 잘 알아두어야함!! ---

HTTP (HyperText Transfer Protocol)

* 원래는 HTML 전송용으로 나왔으나 현재는 모든 형태를 전송한다.

* 이미지, 음성, 영상, 파일, JSON, XML etc

HTTP버전 확인하는 법

1. 개발자도구

2. Network

3. 새로고침

4. Protocol을 보면 버전 확인 가능

H2 = HTTP 2.0

HTTP 특징

1. 클라이언트 서버 구조

* Request Response 구조

* 클라이언트는 Request를 보내고 Response를 기다리게 된다.

이렇게 분리를 하는것이 왜 중요한가?
* 태초에는 클라이언트와 서버 개념이 분리가 되어 있지 않았다.
* 데이터와 비즈니스 로직을 전부 서버에 넣고
* 클라이언트에는 ui를 다 넣는다.
* 이렇게 함으로써 독립적인 진화를 할 수 있다.
* 클라이언트가 모바일, 티비, 웹 모든것이 될 수 있다.
* 서버 또한 트래픽 폭주시 클라이언트는 그대로 두고 서버만 독립적으로 진화시키면 된다.

2. stateless (무상태 프로토콜)

: 클라이언트 하나당 서버를 하나씩 둘 수는 없으니 클라이언트와 서버를 항시 연결해놓는 것이 아니라,

요청할 때마다 클라이언트가 자신의 모든 정보를 보내줌

식당에 갔을 때 점원한테 주문을 하고 다시 가서 같은 점원에게 추가주문을 하면
그 점원은 내가 어느테이블에 앉아있고 전에 어떤 음식을 주문했는지 알고 있음,
하지만 다른 점원에게 추가주문을 한다면
내가 어느테이블에 앉아있는지 다시 이야기를 해줘야한다고 했을 때,
stateless는 다른 점원에게 말했을 경우이고 statefull이 같은 점원에게 말했을 경우이다.

* 단점)서버가 클라이언트 상태를 보존하지 않는다. (정보를 기억하고 있지않아 매번 다시 얘기해줘야함(다른점원))

* 장점)무상태는 응답서버를 쉽게 바꿀 수 있다.

* 세션로그인은 상태가 있다. 최소한으로만 사용한다는 개념. (쿠키세션으로 로그인하는경우)

3. 비연결성 (stateless와 비슷한 내용)

* 요청시마다 연결을 유지하면 클라이언트가 연결을 하면할 수록 서버가 터진다.

* 연결유지를 하지 않으면서 최소한의 자원 사용을 할 수 있다.

* HTTP는 기본적으로 연결을 유지하지않는다.

* 일반적으로 초단위 이하의 빠른 응답

* 1시간 동안 수천명이 써도 실제 동시처리하는 요청은 몇십개도 안된다.

* 서버 자원을 효율적으로 쓸 수 있다.

HTTP - HTTP 메시지의 구조 살펴보기

포스트맨으로 보기

1. Show raw log 클릭

HTTP Method 좋은 설계

: 리소스식별을 확실하게 하는 것!

예시)
* 회원 목록 조회 / members
* 회원 조회 / members/{id}
* 회원 등록 / members
* 회원 수정 / members/{id}
* 회원 삭제 / members/{id}

HTTP Method 안 좋은 설계

:각각 url주소를 다 만들어주는 것!!

예시)
* /read-member-list
* /read-member-by-id
* /create-member
* /update-member
* /delete-member

리소스

: 회원이라는 개념자체가 리소스이며 이것이 URI에 매핑 되는 것이다.

: 거기에 하는 행위는 메소드로 하는 것이다.

Restful API

: 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스

: 리소스와 행위를 분리하는 것

* 리소스: 회원

* 행위: 조회, 등록, 삭제, 변경

HTTP 메소드의 종류 (자주쓰는것)

Get: 조회

* 데이터는 쿼리스트링(주소창에 ?= = = = 형식)으로 전달

(get은 body가 없기 때문에 주소창을 통해 데이터를 전달함)

Post: 등록

* 메시지 body를 통해 서버로 요청 데이터 전달, 처리한다.

(회원가입, 로그인 등을 할 때 / 단순히 데이터를 전달한다기보단 디비에 조작이 일어나는 것을 의미)

* 혹은 프로세스를 처리해야 하는 경우 (배달시작 버튼처럼 데이터가 없더라도 프로세스의 상태가 변경되는 경우) POST /orders/{orderId}/start-delivery 이렇게 해야될 수도 있다.

* 새로운 리소스가 생성되지 않을 수도 있음

* JSON으로 조회 데이터 넘기고 싶은데 GET 메서드 쓰기 힘든 경우에도 쓴다.

* GET은 캐싱을 할 수 있어서 가능한 경우는 GET을 쓴다

Put: 대체, 혹은 생성

* 파일 붙여넣기와 동일. 없으면 만들고 있으면 덮어쓴다.

* 포스트와 차이점은 풋은 클라이언트가 URI를 지정해서 보낸다.

* 부분 데이터로 보내지 못하고 전체 데이터를 다 보내야한다.

Patch: 부분 변경

* 부분 데이터만 보낼 수 있다는 것이 put과의 차이점이다.

Head: Get과 동일하지만 상태줄과 헤더만 반환

Delete: 리소스 삭제

메소드의 속성은 좀더 심화부분이다! 나중에 공부해보자

데이터 전송 할 때

쿼리파라미터로 보내는 경우

* GET

* 주로 검색, 정렬 필터

메시지 바디로 보내는 경우

* POST,PUT,PATCH

* 회원가입, 상품주문, 리소스 등록 변경

데이터 전송하는 방식 2가지

1. HTML Form을 통한 데이터 전송

* 회원가입, 주문, 데이터변경

* HTML Form은 Get, Post만 지원한다.

* Content-Type: application/x-www-form-urlencoded

* username-kwon$age=20 식으로 바디에 데이터 쿼리파라미터처럼 실린다.

* 전송 데이터는 url encoding처리 된다.

2. HTML API를 통한 데이터 전송

* 회원가입, 주문, 데이터 변경

* 서버 to 서버, 앱 클라이언트, 웹 클라이언트 (ajax)

* Content-type:application/json

* Form대신 JS를 이용한 통신

* Post, Put, Patch 도 메시지 바디로 데이터 전송 가능

API 설계 예시 **!!!이 구조가 중요함!!!***

회원관리 - 컬렉션 기반

* GET /memgers > 회원 목록

* POST /memgers > 회원 등록

* GET /memgers/{id} > 회원 조회

* PATCH,PUT,POST /memgers/{id} > 회원 수정

* DELETE /memgers/{id} > 회원 삭제

특징
* 클라이언트는 등록될 리소스의 URI를 모른다.
(= 회원등록 후에 id가 생기기 때문에 회원 등록을 할때 클라이언트는 id를 모른다는 의미)
* 서버가 리소스의 URL를 생성한다.
* /members가 컬렉션이 된다.

HTTP 상태 코드 (숫자마다 무슨뜻인지 약속을 한것임)

Informational responses (100 – 199)

: 요청이 수신되어 처리중 (거의 사용되지 않음)

Successful responses (200 – 299)

: 요청 정상처리 (보통 그냥 200이랑 201만 쓴다, 개발팀끼리 협의.)

* 200 OK

* 201 Created - 헤더에 Location을 추가해서 새로운 리소스의 URI를 알려줄 수 있다.

* 202 Accepted - 요청은 접수했다

* 204 No Content - save 버튼을 눌러서 저장만하고 화면변화가 필요없을 때

Redirection messages (300 – 399)

: 추가행동필요

* 웹브라우저는 3xx의 헤더에 Location이 있으면 자동으로 리다이렉트 한다.

예시) naver.com으로 검색했을 때 http://www.naver.com으로 리다이렉트

* 영구 리다이렉

* 일시 리다이렉

Client error responses (400 – 499) (중요)

: 클라이언트 에러

* 잘못된 문법. 오류의 원인이 클라이언트에 있다.

* 400: 요청 내용을 다시 검토해야한다. API 스펙이 맞는지를 확실히 해야한다.

* 401: 인증이 안됨 - 로그인이 안됐다

* 403: 권한이 없다. - 내가 운영자가 아니다.

* Unauthorized: 오류

* 404: 리소스가 없다. 또는 숨기고 있다. url을 틀렸을 때, 오타, 누락

Server error responses (500 – 599)

: 서버 에러

예시) 최근에 카카오 다운되었을 때

* 복구 후 재시도시 성공 가능하다.

* 500: 서버 내부 문제

* 503: 서버가 일시 과부하

HTTP - HTTP의 다양한 헤더들 살펴보기

* field-name(key)는 대소문자 구분이 없다.

* key값:"Value값"

* HTTP 전송에 필요한 모든 부가정보

* 메시지 바디의 내용 (바디 안에 들어있는게 어떤겁니다~)

* 메시지 바디의 크기

* 압축 (압축한 방식)

* 인증 (인증이 어떻게 되어있는지)

* 요청 클라이언트 (어디에서 요청하는 건지)

* 캐시관리 (캐시 ~해주세요)

* 표준헤더가 너무 많고 필요시 임의의 헤더도 추가 가능하다

* 헤더에는 바디의 데이터를 해석할 수 있는 정보를 제공한다.

표현에 관련된 헤더들

: 리소스에 대한 정보.

html vs xml vs json 중 리소스를 뭘로 표현했는가

* Content-Type: 형식

* Content-Encoding: 압축방식. 압축해서 보내준 경우.

* Content-Language: 영어 한국어

* Content-Length: 길이

Content Negotiation (컨텐트 협상)

: 협상 헤더는 요청시에만 사용된다

* Accept: 클라이언트가 선호하는 미디어 타입 전달

* Accept-Charset : 클라이언트가 선호하는 문자 인코딩

* Accept-Encoding: 클라이언트가 선호하는 압축 인코딩

* Accept-Language: 클라이언트가 선호하는 자연 언어

전송 방식

* 단순 전송

* 압축 전송

* 분할 전송

* 범위 전송

일반 정보

* referer

: 어디에서 왔니?

유입경로 분석용

* user-agent

: 어느 브라우저니?

특정 브라우저에서만 오류가 생기는 것을 파악하기 좋다.

사용자들이 어느 브라우저를 사용하는지 알 수 있다.

* server: 요청을 처리하는 서버의 소프트웨어 정보

특별정보

* Host:요청한 호스트 정보(도메인). 필수값!! (하나의 서버에 여러 IP가 있을 수 있기 때문에)

* Allow: 허용가능한 메서드. 405 리스폰스를 줄때 응답에 포함한다.

* Retry-After: 날짜 혹은 초단위 표기로 다시 요청을 하라고 하나 사용하기는 쉽지 않다.

인증

* Authorization: 클라이언트의 인증정보를 서버에 전달.

* WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

쿠키

: HTTP는 무상태 연결이기에 상태를 매번 보내줘야 한다.

모든 요청과 링크에 사용자 정보를 포함해야한다는 단점이 있는데 이를 해결하기 위해 쿠기가 도입되었다.

Cache

* 캐시가 있으면 같은 요청이 왔을 때 매번 헤더와 바디를 새로 보낼 필요가 없음

검증헤더와 조건부 요청

캐시와 조건부 요청 헤더

라는 것들도 있다 나중에 공부해보자

마무리 정리

체크리스트

프론트엔드와 백엔드의 역할을 이해한다.

HTTP 메시지의 구조를 이해한다.

Request와 Response 메시지의 역할을 이해한다.

HTTP의 상태코드의 역할을 이해한다.

HTTP의 헤더의 역할을 이해한다.

웹의 요청 흐름을 이해한다.

State와 Stateless의 뜻을 이해한다.

Restful한 API 설계를 할 수 있다.

Django Rest Framework 설치 방법

pip install djangorestframework

'Django' 카테고리의 다른 글

[Django] 장고를 이용한 화면 띄우기 (0)	2023.05.24
[Django] 장고 프로젝트 구조 / 세팅 (0)	2023.05.24
[Django] Django(장고) 알아보기 //추가하기 (0)	2023.05.24
[Django] Python의 Web Framework (0)	2023.05.24
[Django] 웹의 동작 순서 및 개념 (0)	2023.05.23

[Django 심화] HTTP와 웹의 동작 방식

웹브라우저 흐름

'Django' 카테고리의 다른 글

관련글

티스토리툴바