2023년 05월 19일 TIL [#]

 

 

---

오늘의 학습 계획

_drf 복습: 1주차 정독, 2주차 따라치기

---

기록하고 싶은 학습내용

_HTTP 는 HTML을 가지고 통신하기 위해 정해둔 통신규약이다. HTTP 가 후에 보안 부분이 강화되어 HTTPS가 생겼으며, 웹브라우저에서 F12 버튼을 누르면 나오는 DEV 툴에서 HTTP 메시지를 확인할 수 있다. HTTP 메시지는 헤드와 바디로 구성되어 있는데, 헤드는 받은 REQUEST 요청의 URL, 메서드 종류, STATUS 코드, 아이피 어드레스, 정책 등이 들어가고, 바디에는 리퀘스트할 때 추가적으로 입력한 값이 들어간다. 따라서 GET 요청에는 바디가 없고, POST, PUT 요청에 바디가 들어간다. 웹브라우저의 흐름은 1.DNS 조회 2. HTTP 요청 메시지 작성 3.SOCKET 라이브러리 통해 전달 4. TCP/IP 작성되고 이 안에 HTTP 메시지 포함.

HTTP = HYPERTEXT TRANSFER PROTOCOL 팀버너스리 개발

HTML 전송용으로 나왔으나, 현재는 이미지, 영상, 음성, 파일, JSON, XML 등 모든 데이터 형태를 전송

 

_클라이언트와 서버는 태초에는 나뉘어 있지 않았으나 웹이 발전하면서 점차 나누게 되었다.

클라이언트는 USER INTERFACE, 서버는 데이터와 비즈니스로직들

나누면 좋은 점은, 각각 기존에 쓰던 도구를 다른 도구로 교체해도 프론트나 백을 통째로 갈지 않아도 된다.

티비, 모바일, 핸드폰 등 다양한 모든 것이 클라이언트가 될 수 있다.

서버의 트래픽 폭주 시, 클라이언트는 그대로 두고 서버만 독립적으로 진화시키면 된다.

 

_HTTP에서 STATEFUL 스타일과 STATELESS 스타일.

 

STATELESS 무상태 프로토콜.

햄버거주문 시 점원이 계속 바뀌는 스타일.

 

무상태: 이전까지의 맥락이 기억되지 않음. 매번 통째로 다시 설명해야함.

상태: 맥락 속에 지금이 있음.

 

무상태 STATELESS 의 장점은 응답서버를 쉽게 바꿀 수 있다는 것.

점원 한명을 질질 붙잡고 있지 않아도 되므로 리소스 사용이 훨씬 효율적임.

매번 처음부터 설명해야하는 점은 번거롭다.

 

그런데

DJANGO 할 때 쿠키세션방식 로그인 > 이건 상태가 있는 거다.

서버가 우리가 누구인지 기억을 하고 있는 것.

HTTP 자체는 무상태가 원칙이지만!

로그인 기능 유지를 위해선 최소한으론 허용한 것이라는 말씀~

 

HTTP는 무상태에 비연결성이다.

연결을 유지해놓고 있지 않음.

연결을 유지해놓고 있으면 클라이언트가 많아지면 서버가 터짐

연결을 유지하지 않으므로써 자원을 최소한으로 사용하며 아낌.

 

_HTTP 메시지의 생김새

1.요청메시지

_REQUEST LINE

_HEADER

_A BLANK LINE

_BODY

 

2.응답메시지

_STATUS LINE

_HEADER

_A BLANK LINE

_BODY

 

_리소스: 웹상에서 존재하는 어떠한 존재. 예를 들어 회원.

그 회원의 정체가 URL/URI 에 적히는거고, 그가 하는 행위는 VIEW에 함수들에서 정의됨.

그래서 URL/URI 을 적는 바른 방법은

회원 목록 조회: /members   (GET)

회원 등록: /members   (POST)

회원 조회: /members/<int:id>   (GET)

회원 수정: /members/<int:id>   (PUT)

회원 삭제: /members/<int:id>   (DELETE)

 

_이렇게 리소스와 행위를 분리하는 것이 RESTFUL 한 API 이다.

 

_수정하기에는 PUT 도 쓸 수 있고 PATCH도 쓸 수 있다.

PUT은 덮어쓰기 느낌.

없으면 만들고, 있으면 덮어 쓴다.

 

PATCH는  부분만 변경하는 느낌.

 

물론 메소드를 정한다고해서 기술적으로 기능이 제한받는 건 아닌데,

이렇게 구분해서 쓴다.

 

_멱등 (idempotent) : 수학용어.

연산을 처리할 때, 연산을 여러번 적용하더라도 결과값이 달라지지 않는 성질.

GET, PUT, DELETE 요청은 멱등이기 때문에 사용자가 입력반응이 없으면 시간초과 시 자동으로 실행되게 설정해도 되지만, POST 요청은 멱등이 아니기 때문에, 반복 요청하면 계속 중복 데이터가 업로드 된다. 그래서 POST 는 타임아웃 시 자동 갱신되게 해놓으면 안된다.

 

_status code

200 ok 201 created 202 요청은접수됐다. 204 요청은접수되었으나응답에따로돌려줄것이없는기능일때

300 리다이렉트 302 GET요청 으로 바꾸어 리다이렉트 307 기존요청 그대로 리다이렉트하며 바디내용 유지

400 클라이언트에러.요청내용검토요망. 401 인증(로그인)이안됨 403 권한(관리자권한 등)이 없다 404 리소스가 없다(그런URL은없다)

500 서버에러. 서버쪽에서 뭔가 로직이 잘못 작성되어 있음. 복구 후 재시도 시 다시 작동 됨. 500 서버 내부 문제. 503 서버 일시 과부하.

 

_헤더 구성요소

authorization(로그인인증) 정보 역시 헤더에 들어있다.

 

_쿠키: 브라우져 자체에 있는 저장공간. F12에서 application 들어가면 storage 중에 쿠키가 있다.

거기서 나오는 http:// 어쩌구 url들에 요청이 가해지면, 눈에는 안보이지만 무조건 쿠키가 포함된 채로 요청이 가해진다.

HTTP 방식이 STATELESS여서 모든 요청이나 링크에 사용자 정보를 새롭게 보내야해서 단점이 있었는데, 이걸 보완하기 위해 도입된 방식이 쿠키다.

쿠키는 서버에서 만들어서 RESPONSE 할 때 클라에게 보내줄 수 있다.

쿠키를 가지고 뭘하느냐? 쿠키-세션 방식 로그인에 쓰거나, 광고정보를 트래킹 하는데 쓴다.

쿠키는 항상 서버에 전달되므로 트래픽이 추가 유발되니 최소한의 정보만 쿠키에 넣자.

 

_캐시: 이미지파일 로딩 같은거, 똑같은 요청이 들어오면 로딩 필요없이 바로 처리해주는 기능.

Cache-control : 이거에서

max-age 캐시 유효기간 설정

no-cache 서버에 검증하고 사용. 캐시 생성하지 않음??

no-store 민감한 정보이니 최대한 빨리 삭제

 

 

 

---

와... 이제 강의가 쏙쏙 들어온다. 이해가 돼요 어머니!!

---