DJANGO 심화

강의 주차별 내용

• http와 웹의 동작 방식
• drf tutorial
• 회원기능(쿠키,세션이 아닌 토큰 방식)
• 인스타그램 기능 클론(글 댓글 좋아요 팔로우)
• 테스트코드 작성해보기(수정사항들을 매번 수동으로 테스트x, 자동화)

 

http와 웹의 동작 방식

drf 소개

postman

http

 

여태까지 썼던 장고는 mvt 방식, 장고 템플릿 문법

 

불편한 점 > 댓글 작성이나 글 작성시마다 웹페이지가 새로고침이 된다.

 

ajax 등으로 해당 부분만 업데이트 하고, 서버에서도 그 부분의 데이터만 보내줌

 

 

여태까지 쓰던 방식은 올드한 방식이고,

앞으로 강의에서 templates는 더 이상 작성하지 않을 것(아마)

그럼 어떤식으로 프론트 - 백이 통신할 것인가? postman

 

웹의 흐름

클라이언트 ↔ 서버

 

request를 보내면 response

어떻게 보낼지 약속 = 프로토콜

HTTP = Hypertext Transfer Protocol

 

웹 브라우저 흐름

1. dns 조회 
    -  Domain Name System 
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
• SYN을 통해 연결, ACK를 통해 승인

최적화를 통해 요즘은 3단계에서 데이터 송신을 한다.

 

 

UDP - User Datagram Protocol

• 기능이 거의 없고
• TCP 기능들이 없다.
• IP와 유사한데 포트와 체크섬만 추가됐다.
• 어플리케이션에서 추가작업이 필요하다.
• 원하는 기능들을 추가해서 만들 수 있는 하얀 도화지 같은 프로토콜이다.

 

Port

• 한 컴퓨터에서 게임 화상통화 웹브라우저를 다 켤 수 있다.
• 포트는 같은 IP내에서 프로세스 구분을 해줄 수가 있다.
• 0~65535
• 0~1023은 잘 알려진 포트로 사용하지 않는게 좋다.

 

URL와 웹브라우저 요청 흐름

URN - Uniform Resource Identifier

URI vs URL vs URN

• URI는 locator, name 또는 둘다 추가로 분류될 수가 있다.
• URI라는 개념 아래에 URL과 URN이 존재한다.
• URN은 거의 쓰지 않는다

 

URI

• Uniform : 리소스 식별을 위한 통일 방식
• Resource : 리소스
• Identifier : 식별자
• 포트 생략시 http는 80 https는 443
• 리소스 경로는 계층적 구조로 이루어져 있다.
• fragment : 페이지 내에서 위치

https가 http에 비해 발전된 안전한 방식이다.

 

클라이언트 서버 구조

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

 

무상태 프로토콜 - stateless (↔ stateful - 상태유지)

• 서버가 클라이언트 상태를 보존하지 않는다.
• 한 점원이냐 매번 다른 점원이냐
• 중간에 다른 점원으로 바뀐다
• 무상태는 응답서버를 쉽게 바꿀 수 있다.
• 세션 로그인은 상태가 있다. 최소한으로 사용한다는 개념

 

비연결성

• 요청시마다 연결을 유지하면 클라이언트가 연결을 하면 할수록 서버가 터진다.
• 연결 유지를 하지 않으면서 최소한의 자원 사용을 할 수 있다.
• HTTP는 기본적으로 연결을 유지하지 않는다.
• 일반적으로 초단위 이하의 빠른 응답
• 1시간 동안 수천명이 써도 실제 동시처리하는 요청은 몇십개도 안된다.
• 서버 자원을 효율적으로 쓸 수 있다.

 

 

 

HTTP Method 안 좋은 설계 → 좋은 설계

• 회원 목록 조회 /read-member-list → /members
• 회원 조회  /read-member-by-id → /members/{id}
• 회원 등록 /create-member → /members/{id}
• 회원 수정 /update-member → /members/{id}
• 회원 삭제 /delete-member → /members/{id}

가장 중요한 것은 리소스 식별

리소스란?

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

거기에 하는 행위는 메소드로 

 

리소스와 행위를 분리하는 것이 Restful API

리소스 : 회원

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

 

Methods

• Get : 조회
   -  데이터는 쿼리스트링으로 전달
• Post : 등록
   -  메시지 바디를 통해 서버로 요청 데이터 전달
   -  데이터를 처리
   -  프로세스를 처리해야 하는경우 
   -  새로운 리소스가 생성되지 않을 수도 있다.
   -  JSON으로 조회 데이터 넘기고 싶은데 GET 메서드 쓰기 힘든 경우에도 사용
   -  GET은 캐싱을 할 수 있어서 가능한 경우 GET 사용
• Put : 대체, 혹은 생성
   -  파일 붙여넣기와 동일. 없으면 만들고 있으면 덮어쓴다.
   -  타이틀만 수정해도 컨텐츠 데이터까지 모두 보내야한다.(Patch는 바꾸고 싶은 부분)
   -  포스트와 차이점은 PUT은 클라이언트가 URI를 지정해서 보낸다.
• Patch : 부분 변경
• Head : Get과 동일하지만 상태줄과 헤더만 반환
• Delete : 삭제

 

쿼리스트링

주소창으로 ?와 =형식으로 전달 되는 것이 쿼리스트링.

각 인자는 &로 구분한다.

?type=post&returnURL=https%3A%2F%2Fcodemte.tistory.com%2F79

 

 

메소드의 속성

• 안전: 리소스가 변경이 되냐 안되냐
• 멱등 : 몇번하든 결과가 같다. GET/PUT/DELETE는 결과가 같다. POST는 중복돼서 발생할 수 없어진다.
  멱등 여부에 따라서 timeout시에 재요청을 해도 되냐가 결정된다.
• 캐시가능 : GET, HEAD 정도

 

데이터 전송

쿼리 파라미터

• GET
• 주로 검색, 정렬 필터

메시지 바디

• POST, PUT, PATCH
• 회원가입, 상품주문, 리소스 등록 변경

HTML Form을 통한 데이터 전송

• 회원가입, 주문, 데이터 변경
• HTML Form은 Get, Post만 지원한다.
• Content-Type: application/x-www-form-urlencoded
   -  username-kwon&age=20 식으로 바디에 데이터 쿼리 파라미터처럼 실린다.
   -  전송 데이터는 url encoding 처리된다.
• Content-Type: multipart/form-data
   -  파일을 같이 보낼 때 써야한다. 바이너리 데이터 보낼 때 사용
   -  다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

HTML API 통한 데이터 전송

• 회원가입, 주문 데이터 변경
• 서버 to 서버, 앱 클라이언트, 웹 클라이언트(ajax)
• Content-Type:application/json
• Form대신 JS를 이용한 통신
• Post, Put, Patch도 메시지 바디로 데이터 전송 가능

API 설계 예시

회원 관리 - 컬렉션 기반

• 회원 목록  GET  /members
• 회원 조회  POST /members/{id}
• 회원 등록  GET /members
• 회원 수정  PATCH, PUT, POST /members/{id}
• 회원 삭제  DELET /members/{id}

 

특징

• 클라이언트는 등록될 리소스의 URI를 모른다.
• 서버가 리소스의 URI를 생성한다.
• /members 가 컬렉션이 된다.

 

파일 관리 시스템

PUT 기반 등록

GET /files	파일 목록
GET /files{filename}	파일 조회
PUT /files{filename}	파일 등록
DELETE /files{filename}	파일 삭제
POST /files	파일 대량 들

 

 HTTP 상태 코드(세부내용은 검색해서 찾아보)

100-199	요청이 수신되어 처리
200-299	요청 정상 처리
300-399	리다이렉션
400-499	클라이언트 에러
500-599	서버 에러

 

HTTP Header

• field-name(key)는 대소문자 구분이 없다.
   -  content-type = Content-Type
• HTTP 전송에 필요한 모든 부가정보
   -  메시지 바디의 내용
   -  메시지 바디의 크기
   -  압축
   -  인증
   -  요청 클라이언트
   -  캐시 관리
• 표준 헤더가 너무 많고 필요 시 임의의 헤더도 추가 가능하다
  HTTP headers - HTTP | MDN (mozilla.org)
• 헤더에는 바디의 데이터를 해석할 수 있는 정보를 제공한다.

표현 - 리소스가 html인지 xml인지 json인지

• Content-Type : 형식
   - text/html;charset=utf-8
   - application/json
   - image/png
• Content-Encoding : 압축 방식
   - gzip
   - deflate
   - identity : 압축 안했다는 뜻
• Content-Language : 언어
   - ko
   - en
   - en-US
• Content-Length : 길이
   - 바이트 단위
   - Transer-Encoding 사용시 Content Length는 사용하면 안됨

컨텐트 협상 (Content Negotiation)

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

• Accept : 클라이언트가 선호하는 미디어 타입 전달
  구체적인 것이 우선된다.
   - text/plain;format=flowed
   - text/plain
   - text/*
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어
   - 서버에서 다중 언어를 지원
   - 한국어 브라우저를 쓰면 한국어를 선호한다는 것을 알려준다
   - 서버에서 한국어로 보내준다
   - 여러가지 언어에 대한 우선순위가 필요한 경우 quality values(q)를 사용한다.
   - 1이 가장 높고 0이 가장 낮다. 생략시 1
   - accept-language: en;q=0.9,ko;q=0.8

전송 방식

• 단순 전송
   -  Content-Length
• 압축 전송
   -  gzip같은 걸로 서버에서 압축 시 절반 정도로 줄어든다
   -  Content-Encoding : gzip으로 알려줘야 클라이언트에서 알고 푼다
• 분할 전송
   -  Transfer-Encoding : chunked
   -  content length를 보내면 안된다.
   -  용량이 큰걸 분할해서 전송한다.
• 범위 전송
   -  Range 명시로 어디서 어디까지 왔는지

 

일반 정보

• referer : 어디에서 왔니? 유입 경로 분석용
• user-agent : 어느 브라우저니? 특정 브라우저에서만 오류가 생기는 것을 파악하기 좋다.
• server : 요청을 처리하는 서버의 소프트웨어 정보

특별 정보

• Host : 요청한 호스트 정보(도메인)
• Allow : 허용 가능한 메서드. 405 리스폰스를 줄 때 응답에 포함한다.
• Retry-After : 날짜 혹은 초단위 표기로 다시 요청을 하라고 하나 사용하기는 쉽지 않다.

 

인증

• Authorization : 클라이언트의 인증정보를 서버에 전달
   - 인증 방식에 따라 들어가는 값은 상이하다.
• WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
   - 리스폰스 시 401 Unauthorized와 함께 사용. 어떻게 인증정보를 만들지에 대한 정보

쿠키

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

모든 요청과 링크에 사용자 정보를 포함해야 한다는 단점이 있다.

이를 해결하기 위해 쿠키가 도입됐다.

 

• Set-Cookie : response시 서버에서 클라이언트로 쿠키 전달
   -  만료기간 / 경로 / 도메인을 설정해줄 수 있다.
   -  사용처 : 로그인 세션 관리 (쿠키-세션 방식), 광고 정보 트래킹
   -  쿠키는 항상 서버에 전송되다 보니 트래픽이 추가 유발된다. 최소한의 정보만 쓰자.
   -  서버에 전송이 필요없고 웹브라우저에 저장만 하고 싶으면 localStorage를 쓰면 된다.
   -  보안에 민감한 주민번호, 신용카드 번호 등은 저장하지 않는다.
   -  만료일자를 생략하면 브라우저 종료시 삭제
   -  만료일(expires)이나 시간(max age)를 지정할 수 있다.
   -  경로 지정으로 원하는 도메인에만 쿠키를 보낸다.  
• Cookie : 클라이언트가 서버에서 받은 쿠키 저장. 요청시 서버로 전달.

 

HTTP Header(2) - Cache

• 캐시가 없다면 매번 같은 요청이 와도 헤더와 바디를 새로 보내준다.
• 네트워크는 느리고 비싸므로 아껴 써야한다
• 브라우저 캐시가 있다면
• cache-control을 통해서 리스폰스가 캐시의 유효 기간을 설정해준다.
• 응답 결과를 브라우저에 저장해두면 두번째 요청을 캐시에서 받아온다.
• 캐시 유효 기간이 지났다면 다시 서버를 통해 데이터를 조회하고 다운로드한다.

 

검증 헤더와 조건부 요청

• 캐시 유효기간 초과한 경우 둘 중 하나의 상황
  1. 서버에서 기존 데이터가 변경됨
  2. 기존 데이터가 동일함
  
  
• 검증 헤더 Last-modified를 추가해서 데이터에 변경이 있었는지 없었는지 정보를 추가한다.
• 검증 헤더를 보고 캐시의 유효기간만 늘려줄 수 있다.
• if-modified-since를 이용해서 다시 보내줘야 하는지 판단 할 수 있다. 304를 이용해서 캐시데이터를 쓴다.

 

캐시와 조건부 요청 헤더

• Cache-control : max-age
   - 캐시 유효기간
• Cache-control : no -cache
   - 서버에 검증하고 사용
• Cache-control : no-store
   - 민감한 정보로 최대한 빨리 삭제