노릇노릇 식빵굽는 이야기

260517 오늘은 시험 보는 날이다시험이 아침에 있어서 매우매우 일찍 일어났다.해 안떴을 때 일어나는건 참 오랜만이구만 언제나 그렇지만 시험 보는거보다 가는길이 더 힘들다흑흑 시작 한시간 전에 도착하니 사람들도 없고 차도 없어서 휑-하다문득 술먹고 밤을 새고 아침 첫 차타고 집가는 느낌이 들었다그땐 어떻게 밤새고 놀았지 허허지금은 1시만 되어도 눈이 감긴다... 회상타임 끝. - 시험 보는 중 - 시험 끝!시험은 준비한 것보다 훨씬 쉽게 나왔다그렇지만 상대평가이기 때문에 오히려 걱정이네제발 3배수 안에 들게해주세요ㅠ 머리썼으니 배고프니까 밥먹으러 가야겠다같이 먹을 친구랑 만나기 위해 고속터미널역으로 향했다 여기 위치에 찍힌 곳으로 가보니 덩그러니 건물만 있어서 당황했다혹시나 해서 주위를 ..

260501 오늘은 파티룸 잡고 하루 놀기로 했다근데 갑자기 뜬끔없이 파티룸을 가냐고 할 수 있지만... 사실 처음엔 글램핑이 땡겨서 카라반을 가고자 했지만언제나 그렇듯 회의를 하다가 정신차려보면노래방에 갑자기 꽃혀서... 결국 파티룸으로 결정되었다아하하 감성적인 글램핑은 나중에 찾는 것으로 하고아무튼 출발. 장보기 전에 당구 치시죠.생각보다 낮에 사람이 많아서 당구 자리가 없다. 큰일일세겨우 세번째 당구장에 와서야 마지막 자리 사수했다 휴 근데 실력들 보니 그냥 안치고 장보러가는게 나았을수도...아차차 장보러 도착이케아같이 대형 창고매장은 정말 오랜만에 왔다뭔가 신나서 맛있는거 잔뜩 골랐단 말이지 하하하 파인애플을 담았는데 어떤 아주머니께서 어디서 가져왔냐고 물어보셨다우리가 집은게 너무 ..

* 캐시가 없을 때 요청하는 경우- 데이터가 변경되지 않아도, 계속 네트워크를 통해서 데이터를 다운받아야 함- 인터넷 네트워크 --> 매우 느리고 비쌈- Browser 로딩 속도가 느림- 사용자도 느리기 때문에 답답함을 느낌 * 캐시 적용- 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨 (캐시 저장소에서 데이터 사용)- 네트워크 사용량을 줄여서 비용 절감- Browser 로딩 속도가 빠름- 사용자는 빠르게 사용 가능하기 때문에 편함 * 캐시 시간 초과- 유효시간이 초과하는 경우, Server 통해서 데이터를 다시 조회하고 캐시를 갱신해야함- 유효시간 이후에는 네트워크 다운로드 발생 ㄴ 서버의 기존 데이터와 캐시 저장소에 있는 데이터가 같은 경우 - 다시 다운로드 할 필요가 없음 ..

- 기본 형식 : header-field = field-name ":" OWS field-value OWS (OWS : 띄워쓰기)- field-name은 대소문자 구분이 없음 * 용도- HTTP 전송에 필요한 모든 부가 정보를 포함함 ex) message body 내용, message body 크기, 압축, 인증, 요청 Client, Server 정보, 캐시 관리 정보 등등- 표준 헤더가 많으며, 필요한 경우 임의의 header 추가 가능 ex) helloworld: hi * RFC2616 : 과거에 사용되었던 header- 분류 방식ㄴ General Header : message 전체에 적용되는 정보 ex) Connection : closeㄴ Request Header ex..

state code : 응답에서 Client가 보낸 요청의 처리 상태를 알려주는 기능Client는 아래처럼 상위 상태코드로 해석해서 처리하면 됨추후에 새로운 상태 코드가 추가되어도, Client는 변경하지 않아도 됨*** 1xx : Informational. 요청이 수신되어 처리중 --> 현재는 거의 사용되지 않음*** 2xx : Successful. 요청 정상 처리 - 200 : OK ㄴ Client 요청을 성공적으로 처리 완료 - 201 : Created ㄴ Client 요청으로 서버에서 새로운 resource 생성 ㄴ 생성된 resource는 응답의 Location Header 필드로 식별 ex) Location : /members/100 - 202 : Accept..

* API URI 설계- URI 계층 구조를 활용하여 리소스 식별을 하는 것이 중요하다 ex) 회원 등록, 회원 수정, 회원 조회 등에서 resource는 회원이다. --> 회원 resource를 URI에 mapping해야한다.- URI는 resource만 식별함 - 리소스(명사)와 행위(동사)를 분리해야함 Method * GET : resource 조회- 데이터는 query(parameter, String)를 통해서 전달- message body 사용해서 데이터 전달 가능. but 지원하는 곳이 잘 없어서 권장하지 않음 * POST : 요청 데이터 처리.- message body 통해서 서버로 요청 데이터를 전달함 --> 서버는 요청 데이터 처리 (데이터 처리하는 모든 기능 수행)..

* HTTP : HyperText Transfer Protocol- HTTP 메세지에 거의 모든 형태의 데이터를 전송할 수 있음- 서버 간 데이터를 주고 받을 때도 대부분 HTTP 사용- HTTP/1.1, HTTP/2는 TCP 기반 프로토콜이며, HTTP/3은 UDP 기반 프로토콜이다.ㅏ - 현재 HTTP/1.1을 주로 사용한다 *** HTTP 특징 * 클라이언트 서버 구조- Request Response 구조 1) Client -> Server 요청 보내고 응답 대기. 2) Server -> 요청에 대한 결과를 만들어서 응답 * 무상태 프로토콜(stateless)- Stateful : Server가 Client 상태를 보존하지 못함 --> 중간에 Server가 바뀌는 경우 유지하지 ..

* 인터넷 프로토콜 스택 4계층- 애플리케이션 계층 : HTTP, FTP- 전송 계층 : TCP, UDP- 인터넷 계층 : IP- 네트워크 인터페이스 계층 * 메세지 전송 과정메세지 -> 애플리케이션(Socket 라이브러리) -> OS(TCP 정보 생성) -> OS(IP 패킷 생성) -> 네트워크 인터페이스(LAN 카드) * IP : internet protocol.- IP 주소에 데이터를 전달하기 위해 packet으로 전송- 클라이언트 -> 인터넷 -> 서버 전송 요청 시 출발 IP과 도착 IP를 확인하고 인터넷의 노드를 통해서 데이터 전달- 한계 - 비연결성 : 패킷 받을 대상이 없거나 서버가 불능한 상태여도 패킷을 전송한다 (받는 서버 상태 확인 불가능) - 비신뢰성 : 중간에 패킷이 사..

빈 스코프 : 빈이 존재할 수 있는 범위 - 싱글톤 : 기본 스코프. 스프링 컨테이너의 시작 ~ 종료까지 유지되는 가장 넓은 범위의 스코프 - 빈 조회 시 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈 반환 - 프로토타입 : 빈 생성 ~ 의존관게 주입까지만 관여. 매우 짧은 스코프 - 빈 조회 시 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환 - 프로토타입 빈을 관리할 책임 --> 프로토타입 빈을 받은 클라이언트에 있다 - @Predestory 등 메서드 불가능 - 종료를 직접 입력해야함 (ex : Prototype.destory) Singleton은 같은 주소를 사용하는 반면, Prototype은 새로운 주소를 발급함. - @Scope("singleton" ..

생성자는 필수 정보를 받고 객체를 메모리에 올리는 역할에 집중해야 함- 생성자 : 필수 파라미터를 받아 필드 채우는 가벼운 작업에 집중- 초기화(init) : 외부 시스템과 연결하는 등 무거운 작업 - 생성 이후 별도의 초기화 메서드에서 처리하는 것이 유지보수와 객체지향 설계 측면에서 훨씬 좋다 * 스프링 빈 이벤트 생명주기스프링 컨테이너 생성 --> 스프링 빈 생성 --> 의존관계 주입 --> 초기화 콜백 --> 사용 --> 소멸 전 콜백 --> 스프링 종료- 의존관계 주입의 시점 :객체를 만드는 것(new)과 데이터를 채우는 것(Setter)은 순서가 나뉘어 있음- 초기화 타이밍 : Connect와 같은 무거운 작업은 데이터가 다 채워진 의존관계 주입 완료 후에 일어나야 함- 종료의 필요성 :..