back to the 0

MVC 진행 과정 클라이언트가 url을 요청하면, 웹 브라우저에서 스프링으로 request가 보내진다. Dispatcher Servlet이 request를 받으면, Handler Mapping을 통해 해당 url을 담당하는 Controller를 탐색 후 찾아낸다. 찾아낸 Controller로 request를 보내주고, 보내주기 위해 필요한 Model을 구성한다. Model에서는 페이지 처리에 필요한 정보들을 Database에 접근하여 쿼리문을 통해 가져온다. 데이터를 통해 얻은 Model 정보를 Controller에게 response 해주면, Controller는 이를 받아 Model을 완성시켜 Dispatcher Servlet에게 전달해준다. Dispatcher Servlet은 View Resolver..

-Dispatcher-Servlet 서블릿 컨테이너에서 HTTP 프로토콜을 통해 들어오는 모든 요청을 제일 앞에서 처리해주는 프론트 컨트롤러 따라서 서버가 받기 전에, 공통처리 작업을 디스패처 서블릿이 처리해주고 적절한 세부 컨트롤러로 작업을 위임 디스패처 서블릿이 처리하는 url 패턴을 지정해줘야 하는데, 일반적으로는 .mvc와 같은 패턴으로 처리하라고 미리 지정해줍니다. 디스패처 서블릿으로 인해 web.xml이 가진 역할이 상당히 축소되었습니다. 기존에는 모든 서블릿을 url 매핑 활용을 위해 모두 web.xml에 등록해 주었지만, 디스패처 서블릿은 그 전에 모든 요청을 핸들링해주면서 작업을 편리하게 할 수 있도록 도와줍니다. 또한 이 서블릿을 통해 MVC를 사용할 수 있기 때문에 웹 개발 시 큰 장..

페이징 -페이지 단위의 논리-물리 주소 관리 기법. 논리 주소 공간이 하나의 연속적인 물리 메모리 공간에 들어가야하는 제약을 해결하기 위한 기법 -논리 주소 공간과 물리 주소 공간을 분리해야함(주소의 동적 재배치 허용), 변환을 위한 MMU 필요 특징 : 외부 단편화를 없앨 수 있음. 페이지가 클수록 내부 단편화도 커짐 세그먼테이션 -사용자/프로그래머 관점의 메모리 관리 기법 -페이징 기법은 같은 크기의 페이지를 갖는 것 과는 다르게 논리적 단위(세그먼트)로 나누므로 미리 분할하는 것이 아니고 메모리 사용할 시점에 할당됨

교착상태(DeadLock)란? -프로세스가 자원을 얻지 못해 다음 처리를 하지 못하는 상태 -시스템적으로 한정된 자원을 여러 곳에서 사용하려고 할 때 발생하는 문제 교착상태의 4가지 조건 상호배제 : 프로세스들이 필요로 하는 자원에 대해 배타적 통제권을 요구함 점유대기 : 프로세스가 할당된 자원을 가진 상태에서 다른 자원 기다림 비선점 : 프로세스가 어떤 자원의 사용을 끝날 때까지 그 자원을 뺏을 수 없음 순환대기 : 각 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 갖고 있음 -이 4가지 조건 중 하나라도 만족하지 않으면 교착상태는 발생하지 않음 (순환대기는 점유대기와 비선점을 모두 만족해야만 성립합. 따라서 4가지가 서로 독립적이진 않음) 교착상태 해결 방법 4가지 -예방 -회피 -무시 -발견

클라이언트 사이드 vs 서버사이드 소셜로그인을 구현하는 방법은 크게 두 가지다. 하나는 클라이언트 사이드에서 플랫폼과 정보를 주고 받는 것이고, 다른 하나는 서버사이드에서 정보를 주고 받는 것이다. 클라이언트 사이드는 1) 클라이언트에서 정보를 플랫폼에 발송 2) 플랫폼에서 클라이언트로 토큰 발송 3) 클라이언트에서 서버로 토큰 전달 4) 서버에서 토큰을 가지고, 플랫폼에 유저 정보를 요청 5) 유저 정보와 서버에서 생성한 자체 토큰을 클라이언트로 전달하는 과정으로 진행된다. 서버 사이드는 1) 클라이언트에서 정보를 플랫폼에 발송 2) 플랫폼에서 서버로 토큰 발송 3) 서버에서 토큰을 가지고 플랫폼에 정보 요청 4) 유저 정보와 서버에서 생성한 자체 토큰을 클라이언트로 전달하는 과정으로 진행된다. 클라이..

젠킨스 자동배포/수동배포 - Jenkins란 지속적 통합 및 지속적 배포(CI/CD)를 지원하는 도구, 소프트웨어 개발 및 배포 프로세스를 자동화하고 최적화하는 데 사용된다. 자동 배포 (Automated Deployment): 자동 배포는 CI/CD 파이프라인의 일부로 작동하며, 코드 변경 사항을 자동으로 테스트하고 배포 소스 코드 변경이 주기적,트리거에 따라 자동으로 배포 배포 프로세스는 사람의 개입 없이 자동화되며, 대개 스크립트 또는 도구를 사용하여 정의된다 장점: 속도와 일관성- 빠르고 일관된 배포 프로세스를 통해 소프트웨어 업데이트가 신속하게 이루어지고, 사람의 개입을 줄여 오류 감소 지속적인 배포 가능- 새로운 변경 사항이 항상 배포 가능한 상태로 유지 단점: 복잡성: 자동 배포 파이프라인을..

**STOMP 메시징 프로토콜을 사용한 메시지 전달 과정** 1. **메시지 송신 (SEND)**: 클라이언트는 메시지를 생성하고 이를 발신자(Sender)로서 서버로 보냄 2. **메시지 수신 및 라우팅 (Controller)**: 서버는 @MessageMapping 어노테이션이 적용된 컨트롤러에서 메시지를 수신하며, 메시지의 내용을 분석하고 처리 3. **목적지 설정 (Destination)**: 발신자는 메시지에 목적지(destination)를 지정합니다. 이 목적지는 메시지를 전달할 위치를 나타냅니다. 예를 들어, "/topic/someTopic" 또는 "/app/someApp"과 같은 경로를 사용 4. **메시지 라우팅 (Routing)**: 목적지가 "/topic"으로 설정된 경우, 메시지는 ..

.사용자가 채팅방에 입장하려하면 사진찍는 모달창이 뜬다. 컴포넌트가 마운트 되는순간 카메라 권한을 요구하고 권한이 수락되면 즉시 카메라에 찍히는 영상을 화면에 출력한다. 입장버튼을 누르면 영상을 캡쳐하여 이미지파일로 만든후 axios로 만든 이미지파일을 백엔드 서버로 보낸다 백엔드 서버는 파일을 받아서 네이버 클라우드 얼굴인식 API로 넘긴다. 얼굴인식 API는 받은 파일을 분석하여 결과값을 다시 백엔드 서버로 전송한다. 백엔드 서버는 감정분석 결과값을 처리하여 프론트서버로 전송한다 프론트서버에서는 백엔드서버로부터 받은 감정정보를 통해 사용자를 해당 감정에 맞는 채팅방으로 입장시킨다. 이동할때 컴포넌트가 디스마운트 되는순간 카메라 접속을 끊는다

사용자가 소셜 로그인 요청을 시작 백엔드는 OAuth 인가 요청을 위해 해당 소셜 로그인 제공자의 인가 엔드포인트로 리디렉션 사용자는 소셜 로그인 제공자의 로그인 페이지로 리다이렉트 사용자가 소셜 로그인을 완료하면, 인증 서버로부터 Authorization Code가 응답 백엔드는 Authorization Code를 사용하여 엑세스 토큰을 요청 백엔드는 엑세스 토큰을 획득 엑세스 토큰을 사용하여 유저 데이터를 소셜 로그인 제공자의 리소스 서버에서 요청 획득한 유저 데이터를 DB에 저장하고, JWT 엑세스 토큰을 생성 엑세스 토큰을 프론트엔드 리다이렉트 URI의 쿼리스트링에 담아 리다이렉트 프론트엔드는 토큰을 저장하고, API 요청 시 헤더에 Authroization: Bearer {토큰}을 추가하여 요청..

JSP 파일은 요청이 들어올 때마다 서블릿 코드로 변환되고 컴파일되는데, 수정사항이 발생하면 해당 JSP 파일이 다시 변환되고 컴파일되어 새로운 서블릿 클래스가 생성된다 따라서 서버 재시작 없이도 수정된 내용 반영 가능 서블릿은 웹 애플리케이션 서버가 시작될 때 미리 컴파일되고 클래스로 로딩되는데 서블릿 클래스가 한 번 로딩되면 서버 재시작이나 재컴파일 없이 내용이 변경되지 않는다. 수정사항이 있을 경우 새로운 버전의 서블릿 클래스를 생성하고 서버를 재시작해야만 변경 내용이 적용 결국 컴파일 시점이 달라서 가능한 일