복습을 위한

데이터베이스 커넥션을 획득할 때는 다음과 같은 복잡한 과정을 거친다. 1. 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다. 2. DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP 연결 을 위한 네트워크 동작이 발생한다. 3. DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달한다. 4. DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다. 5. DB는 커넥션 생성이 완료되었다는 응답을 보낸다. 6. DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다. 이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 많이 소모되는 일이다. DB는 물론이고..

SQL Mapper인 JdbcTemplate과 MyBatis나 ORM기술인 JPA나 결국 내부에서는JDBC를 사용한다. JDBC가 어떻게 동작하는지 알아보자. 대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다. java.sql.Connection - 연결 java.sql.Statement - SQL을 담은 내용 (구현할 땐 상속받은 PreparedStatement 권장(바인딩가능, 기능 더많음, 보안강화) java.sql.ResultSet - SQL 요청 응답 자바는 이렇게 표준 인터페이스를 정의해두었다. 이제부터 개발자는 이 표준 인터페이스만 사용해서 개발하면 된다. 그런데 인터페이스만 있다고해서 기능이 동작하지는 않는다. 이 JDBC 인터페이스를 각각의 DB 벤더(회사)에서 자신 의 ..

일반적으로 사용하는 HTML Form을 통한 파일 업로드를 이해하려면 먼저 폼을 전송하는 다음 두 가지 방식의 차이를 이해해야 한다. HTML 폼 전송 방식 application/x-www-form-urlencoded multipart/form-data 첫번째 방식으로는 바이너리 데이터인 파일을 전송하기 어렵다. 또한 파일을 전송할 때 이름, 나이, 첨부파일 이런 식으로 문자와 바이너리타입을 동시에 전송해야하는 상황을 처리하지못한다. 그래서 이러한 경우 HTTP에서 제공하는 multipart/form-data전송방식을 써야한다. 다른 종류의 여러 파일과 폼의 내용을 함께 전송할 수 있다. 폼의 입력 결과로 생성된 HTTP 메시지를 보면 각각의 전송 항목이 구분이 되어있다. multipart/form-da..

스프링 프로젝트를 하다가 이 오류가 떠서 하루종일 고생했다. 서버실행은 잘되는데 테스트가 안된다!!!!!!!!!!!!!!!!!!!!!테스트 인식자체가 안되고 저 오류만 계속 뜬다.!!!!!!!!!!!!!!!!!!! Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain 은 일반적으로 Gradle과 관련된 문제를 나타낸다. 이 메시지는 Gradle에서 어떤 클래스를 찾거나 로드하지 못했다는 것을 나타낸다. 결론은 버전문제였다. 처음에 난 스프링 Spring Initializr에서 스프링부트3.2.2버전으로 프로젝트를 생성했는데 강의하고 버전이 달라서 build.gradle에서 다시 버전을 수정했다..

Cache-Control에는 확실하게 캐시 무효화 응답을 할 수 있는 것들이 있다. 어?캐시를 적용안하면 캐시안되는게 아닌가요? 할 수도 있는데 아니다. 캐시를 적용안해도 웹브라우저에서 Get요청인 경우 임의로 캐시를 해버리기도 한다. 그래서 정말 이 페이지는 캐시가 되면 안된다고 하면 위 헤더들을 넣어줘야한다. 통장잔고 이런 것들은 계속 갱신이 될 것이니 캐시를 하면 안될 것이다. Pragma는 과거 브라우져에서 요청이 올 수도 있으므로 같이 확실히 넣어주는게 좋다. no cache지시어는 조건부요청 검증헤더를 통해 항상 원서버에 검증하고 사용해야한다는 뜻이다. no store지시어는 데이터에 민감한 정보가 있으므로 저장하면 안된다는 의미이다. 일단 이 두개를 조합해야하고 must-revalidate는..

클라이언트에서 진짜 애플리케이션에서 원소스를 제공하는 원서버로 직접접근할 경우 시간이 꽤 걸릴 것이다. 그림을 보면 한국의 여러클라이언트의 사람들이 미국원서버의 데이터를 얻기위해 모두 각각 500ms씩 기다려야 할 것이다. 그래서 프록시 캐시 서를 도입한다. 미국에 있는 원서버입장에서는 한국에 있는 사용자들의 응답이 느린 것을 고려하여 한국의 어딘가에 프록시 캐시 서버를 놓아두고 dns서버를 변경을 해두어 원서버로 요청이오면 미국에 있는 원서버로 직접접근하는 것이 아니라 프록시 캐시서버를 거쳐서 오도록한다. 그럼 클라이언트입장에서 응답시간이 아주 빠를 것이다 . 한국에 있으니.. 유투브를 볼 때 저어엉말 비주류 외국컨텐츠를 볼 때 로딩 속도가 아주느리다. 반면 똑같은 외국컨텐츠인데도 사람들이 많이보는 유..

Cache-Control:max-age헤더는 캐시 유효시간을 지정한다. 초단위까지 가능하다. 보통 아주 길게 잡는다. no-cache는 데이터는 캐시를 해도되는데 검증헤더를 통해 항상 조건부요청을 해서 서버에게 로컬에 있는 캐시데이터가 바뀌었는지 안바뀌었는지 검증을하고 사용하라는 뜻이다. no-store는 데이터에 민감한 정보가 있으므로 저장하면 안된다는 뜻이다. Pragma:no-cache도 Cache-Control: no-cache처럼 동작을 하지만 HTTP1.0하위호환이라 지금은 잘 사용하지않는다. Expires는 캐시만료일을 정확한 날짜로 지정한다. 지금은 더 유연한 Cache-Control:max-age를 사용하며 권장된다. 만약 함께 쓰인다면 Expires는 무시된다. • If-Match, I..

전 시간에 봤듯이 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터를 검증 헤더라고 한다. 전 시간에 본 Last -Modified 말고 ETag라는 것이 있다. 이것은 If -None-Match와 함께 사용된다. 다시 요청한 데이터가 바뀌었으면 200ok, 그대로 써도 된다면 304Not Modifeid이다. 이 시간으로 부터 변경이 일어났냐????????? 클라이언트가 이렇게 if modified since로 묻는다. 변경이 일어나지않았으면 요청이 실패하는 것이니 304Not Modified라고 서버는 응답하고 변경안됐으니 그냥 쓰세요!!하고 말하는 거다. 하지만 데이터가 변경되었다면 서버는 어 맞아 변경되었네!!다시 새로운거 가져가!하고 200ok와 함께 새로운 데이터를 내려준다. 근데 방금 살펴..

캐시유효시간이 초과해서 서버에 다시 요청했을 때 서버의 데이터가 바뀐 상태일 수도 있고 아닌 상태일 수도 있다. 바뀌었다면 당연히 다시 새로운데이터를 받아야겠지만 안바뀌었는데 굳이 다시 다운받아야하나..??유효시간이 지났다고해도?? 재사용할 수가 있다!! 단 당연한말이지만 클라이언트에있는 데이터와 서버데이터가 같아야하고 그것을 증명해야만한다!!! 그래서 검증헤더라는 것이 들어간다! 다시 처음으로 돌아가서 별사진 데이터를 요청한다. 이번에는 서버가 캐시정보와 함께 last modified라는 정보도 함께 응답해준다. 이건 해당 데이터가 마지막에 수정된 시간이다. 최종수정시간이다. 클라이언트는 응답결과를 캐시에 저장하고 60초가 유효하다는 것도 인지하고 있다. 여기서 데이터 최종수정시간정보를 더 더해준다. ..

캐시 기본 동작에 대해 알아보자 캐시가 없을 때이다. 클라이언트에서 star사진을 요청해서 서버에서 응답을 내려준다. 용량1.1m의 별사진이 응답되고 웹브라우져에서 별사진이 나타난다. 또 다시 똑같은 사진을 요청한다면 서버도 또 똑같은 별사진을 응답해줄것이다. 다시 웹브라우져에 별사진이 나타난다. 너무 당연한 얘기다. 캐시를 사용하지않으면 데이터가 변경되지않아도 예시와 같이 계속 네트워크를 통해서 데이터를 다운받아야한다. 이제 캐시를 적용해보자. 이젠 사진과함께 캐시정를 내려준다. 서버는 cache control을 통해 캐시가 유효한 시간을 내려준다. 웹브라우저는 내부의 캐시 저장소에 응답결과를 저장한다. 두번째 요청 때는 그럼 일단 캐시를 뒤진다. 그럼 유효시간을 검증하고 유효하다면 캐시저장소에서 캐시..