CASSIE'S BLOG

- HTTP 1.1이 우리가 쓰고있는거임

패킷으로 현대정보들을 교환하고 있다. 이 방식을 패킷교환방식이라고 한다. 패킷은 많은 헤더들이 있고 이 계층형 프로토콜에 따라서 덧붙여지고 해석할 때는 때지면서 해석이 된다. 패킷을 보내는 주체를 클라이언트라고하고 패킷을 받는 주체를 서버라고 하겠대 구글, 네이버가 서버-클라이언트 구조를 갖고 있다고함. 역할이 딱 분리되어있다고함. 클라이언트는 요청을 보내기만하고 서버는 응답을 하기만하고 서버가 먼저 클라이언트한테 요청하는 거는 거의없다. 이게 그 토렌트 형식임 명확히 서버라는 주체가 없다. 다 분산되어있어서. 서버-클라이언트 구조에서 좀 확장된 형태 클라이언트가 요청을 하고 클라이언트는 클라이언트삼에게 요청을 보내고 싶은데 클라이언트3에게 요청을 바로 하는 것이 아니라 중간에 무조건 서버를 거치게 되어..

실습 건너뜀 강의 시작하자마자

각 유저마다 요구기능이 다를 수 있어서 복잡할 수 있다.      시나리오를 짜봐야지 어떤 db가 필요하고 어떻게 관리할지 그림이 그려짐 항공권과 항공편은 다른거다. 항공권 왕복이면 두개의 항공편이 있잖아예약과 결제같은 경우에는 이거를 엔티티로 보냐 안보냐도 충분히 논의주제가 될 수도 있다썜의 경우에는 예약과 결제같은 경우는 엔티티로 빼야 관리하기가 편하다고 생각하는 사람 중에 한명이라 함.다섯 개의 후보를 봅아봤다고 함.그래야 모델링을 시작할 수 있다함.  엔티티후보와 엔티티 무조건 똑같지않아도 된다함.  erdcloud.comdraw.io 두개 중에 하나로 그리면 되는데 draw.io를 선호한다고함 -user이 너무 general한 것 같아서 승객으로 따로 뺐다고함 1:1 발견2번째 문장에 여러 개 ..

HAVING으로 그룹화된 것들 조건으로 또 거는 것  관계형 db인 rdb의 관계에서 제일 중요한 것 2가지  rdb에서는 어떤 목적, 상하관계 이런 게 없다. 관계의 선택성 (관계의 중요성), 다중성 이거 밖에 없다.  페어링은 이 관계가 무조건 페어 즉 싱크를 맞추고 있어야하나 이 뜻 임.  동그라미랑 수직에 대해서 여태껏 몰랏네 자식에서 부모 방향으로 읽으면 수직바라서 "자식은 부모를 가져아한다" 가 되는 거임 동그라미같은 경우에는 가질 수 있다니까 0또는 1 이렇게 해석하면 되고수직바 2개면은 오른쪽 수직바는 그냥1이라는 뜻이고 왼쪽의 수직바는 mandatory 필수적인 1이다. one => 에 설명되어있는 뜻  까치발이 many뜻인데 동그라미가 있으면은 동그라미는 가질 수 있고 안 가질 수도 있..

FTP는 상태성 프로토콜이기 때문에 중간에 끝났다 다시 요청 오면은 그 전 이후부터 시행가능함. 쿠키 & 섹션: 서버가 당신의 정보를 갖고있는거임 토큰: 클라이언트정보를 토큰에서 다 갖고있는데 이 토큰은 클라이언트가 들고있음. 왼쪽에서 세션id 받으면 세션 id를 쿠키에 저장한다고 함 서버는 계속 기억하고 있다. key1: 김00 이렇게 생각하는거를 섹션이라고 한다. 내 주문목록 보여줘 요청하는 동시에 쿠키를 같이 준다고함 서버는 메모리에 김00 저장해놨겠지? 세션 id가 들어올 떄 즉 쿠키가 들어올 때 주문목록을 주는거임. 실습있음