무상태 프로토콜
"컴퓨팅에서 무상태 프로토콜(stateless protocol)은 어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜로, 통신이 독립적인 쌍의 요청과 응답을 이룰 수 있게 하는 방식이다. 무상태 프로토콜은 서버가 복수의 요청 시간대에 각각의 통신 파트너에 대한 세션 정보나 상태 보관을 요구하지 않는다. 반면, 서버의 내부 상태 유지를 요구하는 프로토콜은 상태 프로토콜(stateful protocol)로 부른다."
(https://ko.wikipedia.org/wiki/%EB%AC%B4%EC%83%81%ED%83%9C_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C)
https://commons.wikimedia.org/wiki/File:Tcp-handshake.svg 에 접속합니다
HTML 파일을 받아옵니다.
해당 링크 안에 이미지로
https://upload.wikimedia.org/wikipedia/commons/9/98/Tcp-handshake.svg 가 들어있습니다.
브라우저는 HTML파일을 읽다가 이 이미지 주소로 서버에 요청을 보냅니다.
이것이 간단한 HTTP 트랜잭션입니다.
이미지를 받아오는 과정을 순서화하면,
1. DNS 조회 후 여기에서 서버의 IP 추출.
2. PORT 정보 조회
3. HTTP 요청 메시지 생성
4. 웹 브라우저는 TCP 3 Way-handshake 방식으로 서버와 커넥션을 생성한다.
5. 웹 브라우저는 서버에 HTTP 요청을 보낸다.
6. 서버는 HTTP 요청을 해석한다.
7. 서버는 요청을 받은 메서드를 찾는다.
8. 찾게되면 이를 200상태코드와 응답 메시지에 동봉하여 클라이언트에게 전송한다.
9. 서버와 클라이언트는 TCP4 Way-handshake 방식으로 커넥션을 종료한다.
브라우저는 서버의 응답결과를 캐시에 저장합니다
이후 재차 요청을 보내기 전에, 브라우저는 캐시의 유효기간이 초과되지 않았다면 네트워크를 거치지 않고 캐시를 통해 데이터를 조회합니다.
이때, 만약 캐시의 시간이 초과됐다면 브라우저는 똑같은 응답을 위한 요청을 재차 보내야만 합니다. 이때, 서버에서 데이터를 바꾼 것이 없다면 똑같은 데이터를 굳이 다시 다운로드 받아야 하나? 하는 의문이 생깁니다.
이때 검증 헤더와 조건부 요청을 이용합니다.
캐시 유효 시간이 초과된 이후, 서버에 다시 요청을 보낼 때, 다음의 두가지 경우의 수가 있습니다.
1. 서버에서 기존 데이터를 변경한 경우
2. 서버에서 기존 데이터를 변경하지 않은 경우
2번의 경우, 서버가 데이터를 변경하지 않았다면 기존 데이터를 재사용 할 수 있겠죠? 다만 이때 서버의 데이터와 클라이언트의 데이터가 같다는 것을 검증할 필요성이 있습니다.
이를 위해서 검증헤더를 사용합니다. 검증 헤더는 캐시 데이터와 서버의 데이터가 같은 지를 검증하는 역할을 합니다.
검증헤더에는 Last-Modified와 ETag가 있습니다.
Last-modified의 경우, 조건부 요청 헤더에 if-modified-since 를 사용합니다.
캐시의 데이터 최종 수정일과, 서버의 데이터 최종 수정일이 다를 경우, 200OK, 같을 경우 304 Not Modified(변한게 없다)의 응답이 옵니다. 304 Not Modified의 경우, 데이터가 바뀌지 않았으므로 HTTP BODY가 오지 않습니다.
ETag 는 if-Not-Match의 조건부 요청 헤더를 사용합니다.
ETag는 캐시용 데이터에 고유한 이름을 달아놓은 것입니다.
ETag는 서버 사이드에서 관리하는 것이기에, 캐시 제어 로직은 서버에서 온전히 가지고 있다고 볼 수 있습니다.
서버는 데이터가 변동됐을 시, 해시를 통해서 ETag를 재 생성합니다(해시 함수에 넣는 값이 동일하면 해싱의 결과도 동일하기에, 이를 통해 데이터의 변동을 표현할 수 있습니다). 사용자는 ETag를 통해서 데이터가 변경됐는지 아닌지를 알 수 있습니다.
개발자도구를 켜서, 네트워크 탭에서 트랜잭션을 확인할 수 있습니다
회색인 경우는 기존 캐시에서 불러왔음을 뜻합니다.
serializer.save() -> serializers.py의 get_or_create에서 문제가 생김
kakao_id를 .get으로 키가 없는 경우 빈 값 들어가도록 처리해주었고, kakao_id 모델 컬럼은 blank=True이므로 kakao_id가 없이 요청을 보내도 문제 없는 것 아닌가?
get_or_create는 다른 기능에서 사용하는 코드라 로직을 변경하기 어려움
해당부분을 주석처리하고 요청 보내면 원하는대로 user object가 만들어지긴 함
kakao_id가 없으면 get_or_create()에서 get을 하기위해 찾아 줄 조건인 kakao_id 자체가 없어지기에 해당 코드는 kakao_id 값이 없이 요청이 들어오면 동작하지 않는 것이 맞음
생각해보니, 핸드폰 로그인에서도 1회 회원가입 이후 회원 정보를 get해와야 하기에 serializer를 나눠서 get_or_create()를 써주자
에러
이미지를 만들려고 할때마다 이 에러가 뜹니다
해결책으로 이 링크 https://dev.to/shriekdj/python-failed-building-wheel-for-backportszoneinfo-on-linux-2mo8
의 tzdata 를 설치했더니( 두번째 해결책)
이젠 다른 에러가 뜹니다
저는 pip freeze > requirements.txt로 pip freeze 항목을 그대로 다 requirements에 옮겨줬는데,
그러다 보니 제가 손수 깐 것이 아닌 장고 등을 설치하면서 깔린 라이브러리 등이 있다고 생각합니다.
그래서 backports.zoneinfo라는 제가 깔지 않은것이 pip freeze에 들어가지 않았나 생각이 들었습니다.
그 부분 requirments.txt에서 지워주고 다시 이미지 만드니 이미지가 만들어집니다.
requirements.txt는 pip로 모듈을 설치할때마다 성실하게 업데이트를 해줘야 한다는 것을 느꼈습니다.
문제는 requirments에 gunicorn 관련 내역이 없어서 이미지로 컨테이너를 실행하려니컨테이너가 실행 안됩니다,
가상환경 키고(구니콘이 있는), pip freeze로 gunicorn부분을 확인한 후 이를 requirements에 복사붙여넣기 해줍니다. 이를 바탕으로 이미지를 다시 만들어줍니다.
이미지를 다시 만들었습니다.
근데 도커콘테이너 실행하려니.
이 에러가 뜹니다.
docker ps -a 로 꺼진 콘테이너 확인해보니
api란 이름의 콘테이너가 꺼진채로 있습니다
이 콘테이너를 지워줍니다.
내 컴퓨터 - ec2 - docker 이렇게 연결되는 것이 아니라 ,
내 컴퓨터 → docker
아마존이 가진 ec2 → docker 이런식으로 별개의 컴퓨터 두개에서 도커로 서버를 돌린다고 생각하면 될듯 싶습니다.
이 명령어로 키면 wecode/projcet 이미지로 api란 이름을 가진 새로운 컨테이너를 만들고 그거로 서버를 여는것과 같습니다
그래서 매번 이름이 안겹치게 새로운 이름을 가진 애들을 열어줬어야 했습니다.
docker run -p 8000:8000 wecode/project:0.1.0
그러고 싶지 않으면 이렇게 —name api 부분을 없애주면 됩니다 , 이러면 새로운 이름의 컨테이너 안 열고 기존 컨테이너를 이용하여 그냥 바로 서버열기 가능합니다.
객체지향 프로그래밍을 하며 지켜야 할 5가지의 원칙을 SOLID 원칙이라 합니다.
A. SRP(Single Responsibility Principle) - 단일 책임의 원칙
클래스는 오직 하나의 기능만 가지며, 클래스의 모든 작업은 그 단일 책임에 종속돼야 합니다.
이에 맞추어 https://github.com/wecode-bootcamp-korea/30-2nd-WantU-backend/tree/main/applications 해당 링크의 applications view를 살펴보겠습니다.
우선 리팩토링 이전의 StatusView 코드입니다.
해당 view는 지원자의 지원 상태와, 그것들의 개수를 데이터베이스에서 가져오는 역할을 하고 있습니다.
34번째 줄에서 application.status.status는db에서 직접적으로 상태값을 가져오는 역할을 합니다.
StatusView는 지원상태를 return 해줄 뿐 아니라, DB에서 직접 상태값들을 가져와 return할 값에 직접적으로 투입하고 있습니다.
하나의 클래스가 여러 기능을 하고 있다고 보여지기에, enum클래스를 따로 만들어주어 상태값을 enum클래스를 통해 불러올 수 있도록 하겠습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | class StatusView(View): @login_decorator def get(self, request): applicant = Applicant.objects.filter(user=request.user).prefetch_related('application_set') if not applicant.exists(): return JsonResponse({'result':"NO valid application"}, status = 404) applications_in_applicant = applicant[0].application_set.all().select_related('status') status_list = [application.status.id for application in applications_in_applicant] result = { "applied" : status_list.count(Status.APPLIED.value), "document_passed" : status_list.count(Status.DOCUMENT_PASSED.value), "accepted" : status_list.count(Status.ACCEPTED.value), "rejection" : status_list.count(Status.REJECTION.value) } result["total"] = len(status_list) return JsonResponse({'result':result}, status = 200) | cs |
B. OCP(Open Close Principle) - 개방폐쇄의 원칙
클래스는 확장에 대해서는 개방적이어야 하고, 변경에 대해서는 폐쇄적이어야 합니다.
클래스의 코드 변경은 이 클래스를 사용하는 모든 시스템에 영향을 미치게 됩니다. 따라서 클래스의 기능을 추가하려면, 기존 기능의 변경이 아닌 새로운 함수의 추가가 이상적입니다.
C. LSP(The Liskov Substitution Principle) - 리스코브 치환의 원칙
부모클래스 T의 서브타입인 자식 클래스 S의 객체는 어떠한 문제도 없이 부모 클래스의 객체를 대체할 수 있습니다.
문제없는 대체를 위해서, 자식 클래스는 부모클래스의 기능을 오버라이드 하지 않아야합니다. 자식 클래스는 부모의 기존 기능을 건드리지 않은 채, 확장만 수행하여야 LSP를 만족하게 됩니다
D. ISP(Interface Segregation Principle) - 인터페이스 분리의 원칙
바꿔 말하면, 인터페이스의 단일 책임 원칙입니다. 구체적인 책임을 지는 여러 인터페이스를 분리하여, 사용하지 않는 인터페이스가 존재하지 않게 해야 됩니다.
E. DIP(Dependency Inversion Principle) - 의존성 역전의 원칙
고차원의 모듈과 클래스는 저차원의 모듈과 클래스에 의존해서는 안됩니다. 고차원, 저차원 모두 구체에 의존적이지 않고, 추상에 의존해야 합니다. 구체는 추상에 의존적입니다.
고차원 모듈 또는 클래스는 저차원 모듈 또는 클래스를 도구로 하여 동작하는 클래스입니다. 추상은 두 클래스를 연결하는 인터페이스이고, 구체는 도구가 동작하는 방법입니다.
자동차가 타이어를 사용할때, 한국타이어, 금호타이어등은 "구체"이고, 단순 "타이어"는 "추상"이라 할 수 있습니다. 자동차라는 고차원 클래스는 타이어라는 추상적 "인터페이스"에 의존하고 있습니다. 이때 타이어들은 모두 인터페이스 입니다.
인터페이스를 통해 고수준 클래스가 저수준 클래스에 의존성을 가지지 않게 할 수 있습니다.
앞서 Enum클래스로 상태값을 분리해준 과정에서, StatusView는 고차원 클래스, Enum을 상속받은 Status는 저차원 클래스라고 생각됩니다.