47. 내일배움캠프 - 36일차 TIL

---

 

TIL

📌
오늘 한 일

장고 심화 1주 차 ~ 2주 차 듣기
로그인 회원가입 기능 구현
자바스크립트 공부

 

오늘부터 장고 심화 강의가 들어가는 날이다.

아직 장고도 못하는 나인데 잘할 수 있을 까라는 걱정과 함께

강의를 듣기 시작했다.

1주차 강의는 개념 설명 위주로 되어 있었다. 그래서 부담 없이 들었다.

2주 차부터 프로젝트 세팅과  DRF에 대해서 배우는 것 같다 아직 초반이라

뭘 하진 않음 ㅎㅎㅎ

강의를 들으면서 좋았던 점은 튜터님께서 들으면서 타이핑하지 말고 

듣고 타이핑하는 시간을 주시는게 너무 좋았다. 

한번 듣고 스스로 생각하며 타이핑을 하니 어떤 부분에서 미흡한지 알 수 있어서

좋았음 그래서 그부분 돌려서 다시 보고 다시 타이핑하고 이런 식으로 진행했다.

그리고 팀 회의에서 로그인, 회원가입 코드 리뷰를 내일까지 해오자 했다.

아직 미흡하지만 거북이반에서 배운 것을 토대로 기존에 쓰여있는 코드를 참고하며 구현했다.

모르는 건 팀원 분과 튜터님한테 여쭤봤다. 정상적으로 구현된 걸 확인해보니 좀 좋았음

 

 

 

장고 심화 day1

 

웹브라우저 흐름
1. DNS 조회 ex)www.naver.com
2. HTTP 요청 메시지 작성
3. Socket 라이브러리를 통해서 전달
4. TCP/IP 작성되고 이 안에 HTTP 메시지가 포함

프로토콜 계층
어플리케이션 > Socket Library > TCP > IP > LAN > 인터넷

Internet Protocol
지정한 IP주소로 전송
출발지 IP와 목적지 IP를 작성
송신하면 노드들을 거쳐서 송신이 된다
한계: 
받을 대상이 없을 수도 있다
중간에 패킷이 손실되거나 순서대로 오지 않을 수 있다.
같은 IP를 사용하는 어플리케이션이 여러 개라면 문제가 생긴다.

TCP
IP를 TCP로 보완한다.
출발지 port와 목적지 port정보
전송 제어와 순서
검증 정보 등이 실린다
특징:
연결 지향 TCP 3 way handshake를 통해 연결이 된 지를 먼저 확인한다.
데이터 전달을 보증한다.
순서를 보장한다
신뢰할 수 있어서 현재 대부분 TCP를 사용한다.

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

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

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

====여기부터 HTTP====
HTTP(HyperText Transfer Protocol)(중요)
원래는 HTML 전송용으로 나왔으나 현재는 모든 형태를 전송한다
이미지, 음성, 영성, 파일, JSON, XML etc

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

무상태 프로토콜 (stateless)
- 서버가 클라이언트 상태를 보존하지 않는다
- 한점원(statefull)이냐 매번 다른 점원(stateless)이냐
- 중간에 다른 점원으로 바뀐다고 생각해야 한다
- 무상태는 응답 서버를 쉽게 바꿀 수 있다.
- 세션 로그인은 상태가 있다. 최소한으로만 사용한다는 개념

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

Put: 대체, 혹은 생성
- 파일 붙여 넣기와 동일. 없으면 만들고 있으면 덮어쓴다
- 포스트와 차이점은 풋은 클라이언트가 URL를 지정해서 보낸다
Patch : 부분변경
Head : Get과 동일하지만 상태줄과 헤더만 반환

데이터 전송
쿼리 파라미터
- 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
           -파일을 같이 보낼 때 써야한다. 바이너리 데이터 보낼때 사용
           - 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

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

API 설계 예시 (중요)
회원관리 - 컬렉션 기반
- GET/members > 회원 목록
- POST/members > 회원 등록
- GET/members/{id} > 회원 조회
- PATCH,PUT,POST/members/{id} > 회원 수정
- DELETE/members/{id} > 회원 삭제


HTTP 상태 코드

2xx
요청 정상 처리
- 200 ok
- 201 Created
           -Header에 Location을 추가해서 새로운 리소스의 URL을 알려줄 수 있다
- 202 Accepted
           -요청은 접수했다
- 204 No Content
           -save 버튼을 눌러서 저장만 하고 화면 변화가 필요 없을 때
보통 200이랑 201만 사용

3xx
추가 행동 필요
- 웹브라우저는 3xx의 헤더에 Location이 있으면 자동으로 리다이렉트 한다.
- 영구 리다이렉 : 영구 이동. 메소드와 바디가 바뀌는 301과 안 바뀌는 308이 있다
- 일시 리다이렉: 일시적 변경. 주문완료 후 주문내역으로 이동
         - 302 : 리다이렉트시 메소드는 GET으로 본문은 제거
         - 307 : 리다이렉트시 메소드와 본문 유지
         - PRG(Post/Redirect/Get)
                    -Post 주문 후 새로고침 시 중복 주문이 가능하다
                    -주문 완료 시 302를 줘서 리다이렉트 시키면 새 로고 침해도 결과 화면만 다시 요청한다.

4xx
클라이언트 에러
- 잘못된 문법. 오류의 원인이 클라이언트에 있다
- 400: 요청 내용을 다시 검토해야 한다. API스펙이 맞는지를 확실히 해야 한다
- 401 : 인증이 안됨
- 인증 vs 권한 : 인증은 로그인이 안됐다. 권한은 내가 운영자가 아니다. Authentication vs Authorization
- 오류는 Unauthorized로 사용. 이름이 아쉽다.
- 403 : 권한이 없다
- 404 : 리소스가 없다. 또는 숨기고 있다.

5xx 
서버 에러
복구 후 재시도 시 성공 가능
500 : 서버 내부 문제
503 : 서버가 일시 과부하

HTTP 헤더
- field-name(key)는 대소문자 구분이 없다
            -content-type = Content-type
                (key)                  (value)
-HTTP 전송에 필요한 모든 부가정보
            -메시지 바디의 내용
            -메시지 바디의 크기
            -압축
            -인증
            -요청 클라이언트
            -캐시관리
- 헤더에는 바디의 데이터를 해석할 수 있는 정보를 제공한다.


-Content-Type : 형식
           -text/html;charset-utf-8
           -application/json
           -image/png
-Content-Encoding : 압축방식. 압축해서 보내준 경우
           -gzip
           -deflate
           -identity:압축안했다는 뜻
-Content-Language:영어 한국어
           -ko
           -en
           -en-US
-Content-Length : 길이
           -바이트 단위
           -Transfer-Encoding 사용 시 Content Length는 사용하면 안 됨

쿠키
HTTP는 무상태 연결이기에 상태를 매번 보내줘야 한다
모든 요청과 링크에 사용자 정보를 포함해야 한다는 단점이 있다
이를 해결하기 위해 쿠키가 도입됐다.

 

---

 

실수
User.object.create_user(email=email, username=username, password=password)
object라고 써서 오류가 났음

해결
User.objects.create_user(email=email, username=username, password=password)

remind

from django.contrib import auth
# auth에 있는 것들을 전부 임포트 해옴
auth.login(request, user) 이런 식으로 사용

from django.contrib.auth import authenticate, login
#auth에 있는 authenticate와 login만 임포트 해 옴
login(request, user) 이런 식으로 사용

user = authenticate(request, username=username,password=password)
#authenticate함수를 사용해서 암호화된 비밀번호와 현재 입력된 비밀번호가 일치하는지 그게 사용자와 맞는지까지 확인해줌  유효하면 True 유효하지 않으면 False