WebMaster

Request Response 구조 클라이언트는 서버에 요청을 보내고, 응답을 대기 서버가 요청에 대한 결과를 만들어서 응답 클라이언트와 서버를 개념적으로 분리시켰다 비즈니스 로직과 데이터는 서버에 다 저장한다 클라이언트는 사용성과 UI에 집중한다. 서버 - 클라이언트가 독립적으로 진화할 수가 있다.

모든 것이 HTTP HTTP 메시지에 모든 것을 전송 HTML, TEXT IMAGE, 음성, 영상, 파일 JSON, XML (API) 거의 모든 형태의 데이터 전송 가능 서버 간에 데이터를 주고받을 1 때도 대부분 HTTP 사용 지금은 HTTP 시대! HTTP 역사 HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더 X HTTP/1.0 1996년: 메서드, 헤더 추가 HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전 RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014) HTTP/2 2015년: 성능 개선 HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선 기반 프로토콜 TCP: HTTP/1.1, HTTP/2 UD..

DNS 조회 , Port 확인 http 메시지 전송 수많은 노드를 걸쳐 목적지 서버로 도착할 것이다 Http 응답 메시지를 생성해 주어 클라이언트에 응답을 전송한다.

URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다 URI Uniform: 리소스 식별하는 통일된 방식 Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음) Identifier: 다른 항목과 구분하는데 필요한 정보 URL, URN URL - Locator: 리소스가 있는 위치를 지정 URN - Name: 리소스에 이름을 부여 위치는 변할 수 있지만, 이름은 변하지 않는다. urn:isbn:8960777331 (어떤 책의 isbn URN) URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않음 앞으로 URI를 URL과 같은 의미로 이야기하겠음 URL 문법 scheme://[userinfo@]host[:port][/path][?query][..

IP는 기억하기 어렵다. IP는 변경될 수 있다. DNS : 도메인 네임 서비스 전화번호부 도메인 명을 IP 주소로 변환 마치 전화번호부 가 있듯이 사용할 수가 있다.

TCP/IP 패킷 정보에 출발지, 목적지 port가 존재한다. 이를 통해 구분하면 된다. 아파트 - 동 으로 비유해서 생각하면 좋다 0 ~ 65535 할당 가능 0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음 FTP - 20, 21 TELNET - 23 HTTP - 80 HTTPS - 443

TCP IP 계층에서 알 수 없던 정보를 TCP 계층에서 알 수 있다. TCP 특징 : 전송 제어 프로토콜 연결 지향연결 지향 - TCP 3 way handshake (가상 연결) 논리적으로 연결이 되었다고 판단하는 것이다(가상연결) 데이터 전달 보증 순서 보장 TCP 정보에 순서 정보가 있기 때문에 가능한 것이다. 신뢰할 수 있는 프로토콜 현재는 대부분 TCP 사용 UDP 사용자 데이터그램 프로토콜(User Datagram Protocol) 하얀 도화지에 비유(기능이 거의 없음) 연결지향 - TCP 3 way handshake X 데이터 전달 보증 X 순서 보장 X 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름 정리 IP와 거의 같다. +PORT +체크섬 정도만 추가 애플리케이션에서 추가 작업..

어떠한 규칙으로 서버와 통신해야 할까? IP 주소를 부여받아야 한다. IP : 인터넷 프로토콜 역할 지정한 IP 주소에 데이터 전달 패킷이라는 통신 단위로 데이터 전달 IP 프로토콜의 한계 비연결성 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 비신뢰성 중간에 패킷이 사라지면? 패킷이 순서대로 안 오면? 프로그램 구분 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

여기가 핵심이다. proxyMode = ScopedProxyMode.TARGET_CLASS를 추가해주자. 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택 적용 대상이 인터페이스면 INTERFACES 를 선택 이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관없이 가짜 프락시 클래스를 다른 빈에 미리 주입해 둘 수 있다. CGLIB라는 라이브러리로 내 클래스를 상속받은 가짜 프락시 객체를 만들어서 주입한다. @Scope의 proxyMode = ScopedProxyMode.TARGET_CLASS)를 설정하면 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프락시 객체를 생성한다. 결과..

첫 번째 해결방안은 앞서 배운 Provider를 사용하는 것이다 ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있다. ObjectProvider.getObject()를 호출하시는 시점에는 HTTP 요청이 진행 중이므로 request scope 빈의 생성이 정상 처리된다. ObjectProvider.getObject() 를 LogDemoController , LogDemoService에서 각각 한 번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환된다! 이 정도에서 끝내도 될 것 같지만… 개발자들의 코드 몇자를 더 줄이려는 욕심은 끝이 없다.