Internet Protocol 의 약자로 우리가 사용하고 있는 인터넷의 개인 주소라고 생각하면 된다.
IP에는 IPv4와 IPv6 두 가지 유형이 있는데, IPv4의 확장성과 용량면에서 한계를 해결하기 위해 IPv6가 등장하였다.
주소공간은 IPv4 - 32비트에서 IPv6 - 128 비트로 확장되었으며 인터넷 사용의 폭증을 수용하기 위해 IPv6로의 전환은 필수적이다.
my ip address
온라인 검색 -> 통신사가 제공하고 있는 나의 ip주소 확인이 가능하다.
Terminal -> ipconfig
공유기에 의하여 할당받고 있는 ip주소. 통신사 -> 공유기에 의해서 여러 갈래로 그 주소가 분배되고 분배된 주소 중 내가 할당 받은 주소가 보여지는 IPv4주소이다.
HTTP / HTTPS
둘다 프로토콜 (데이터 교환방식을 정의하는 체계) 을 의미하며 http와 같은 경우 인터넷 초기에 모든 웹사이트에서 기본적으로 사용되었던 프로토콜이다. 현재는 https가 권장되고, 또한 주로 사용되고 있는데 약자에서 알수 있듯이 (Hypertext Transfer Protocol Secure) https 프로토콜은 SSL을 사용함으로써 서버와 브라우저 사이에 암호화된 연결을 만들 수 있게 도와준다.
SSL
SSL(Secure Sockets Layer)은암호화기반 인터넷 보안프로토콜이다. 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해 Netscape가 1995년 처음으로 개발되었으며 TLS 암호화의 전신이라고 할 수 있다.
이미지 참고 https://www.cloudflare.com/ko-kr/learning/ssl/what-is-ssl/
DNS (Domain Name System)
Amazon Route 53과 같은 DNS 서비스는 전 세계에 배포된 서비스로서, www.example.com과 같이 사람이 읽을 수 있는 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 한다. 인터넷의 DNS 시스템은 이름과 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능을 한다. 도메인은 서비스를 제공하는 CloudFlare나 cafe24 와 같은 기업에서 구매가 가능하다.
2. AWS EC2
Amazon Elastic Compute Cloud (Amazon EC2)는 500개가 넘는 인스턴스, 그리고 최신 프로세서, 스토리지, 네트워킹, 운영 체제 및 구매 모델의 옵션과 함께 워크로드의 요구 사항에 가장 잘 부합할 수 있도록 가장 포괄적이고 심층적인 컴퓨팅 플랫폼을 제공한다.
AWS EC2에서 인스턴스를 발급 받는 방법과 생성한 인스턴스에 tomcat을 설치하는 방법은 youtube나 google에 서칭해보면 매우 잘 나온다. 보면서 따라하기만 하면 된다. 인스턴스 생성과 tomcat을 설치한 이후,
(1) Tomcat Folder
인스턴스 내에 설치한 톰캣의 경로를 확인한다. 나의 경우 설치가 어디 되어있는지 opt와 var 폴더를 헤메다가 var>lib 폴더 내에 설치가 되어있는 것을 확인하였다. AWS terminal의 경우 해당 repo로 들어가기 위해서는 gitbash와 다르게 /(슬래시)를 명령어에 포함시켜주어야 한다. 윈도우가 아닌 리눅스 환경임을 기억하자.
cd /opt > ls
cd /var > ls
cd ./var /lib > ls > tomcat9 찾음
톰캣이 설치된 위치를 먼저 찾자
(2) Tomcat 설정 변경
var/lib/tomcat9/conf$ sudo nano tomcat-users.xml
sudo nano tomcat-users.xml :
- sudo는 명령어를 실행할때 사용하는 리눅스 용어
- nano는 linux 내의 에디터를 말한다. vim 에디터도 존재한다.
- tomcat-users.xml은 말그대로 파일 이름.
tomcat9 폴더에서cd conf해주면 xml이 위치한 폴더로 들어갈 수 있다. 다음에 해당 sudo 명령어를 입력해서 xml을 열어주자. 나는 설정 몇 가지를 변경해주었다.
tomcat 실행하는 김에 password와 username 변경해준다.
포트넘버도 8080에서 임의로 바꿔주었다.
나는 tomcat 설치하는 시점에 username과 password 설정을 건드리지 않았기 때문에 Id/Pwd 를 이때 변경해주었다.
변경한 후에는 ctrl + o 눌러서 저장하는 것 잊지말자.
(3) Tomcat start
중요한 걸 빼먹을 뻔 했다.
톰캣 구동을 시켜줘야한다. ctrl + x 키로 저장한 xml을 닫아주고 ctrl + c 키로 명령어 창을 띄워준다.
구동은 sudo systemctl start tomcat9 ( tomcat 버전 다르면 해당 버전으로...)
톰캣 끄는 명령어는 sudo systemctl stop tomcat9
중요한 것이 한 가지 더 있는데, tomcat9를 구동시키거나 꺼준 이후에는 sudo systemctl status tomcat9 로 구동 상태를 확인해주어야 한다.
왜냐하면
Linux는 ui가 매우 불친절하기 때문이다... 아니 ui가 없다...
(4)IP + Tomcat port #
instance ip주소 + : instsance에서 tomcat 설정한 port 번호를 주소창에 입력하면 아래와 같이 tomcat이 성공적으로 구동되고 있음을 알려주는 화면이 나온다. (나의 경우 8080이 아닌 ex- 6452 port를 설정해주었기 때문에 151.621.6542 : 6452를 주소창에 입력해주었다.
발급받은 instance의 ip / + 하이픈 뒤에는 임의로 설정해준 port number
(5) war파일 배포.
it works 라는 문구를 확인하면 tomcat이 정상적으로 구동되고 있는 것이다. 해당 화면에서 manager webapp을 클릭하여
하기 페이지로 넘어간다.
해당 이미지에서는 잘리긴 했는데, war File을 upload 할 수 있는 스페이스가 아래 더 있다.
STS 또는 Eclipse에서 파일을 export 해야한다. localhost:8080으로 프로젝트가 문제 없이 돌아가는 지 확인하고 나면
File -> export -> war 순서대로 프로젝트를 export 해주면 된다.
이때 주의 할 점은, localhost에서 가장 처음으로 띄워졌던 화면의 주소가 localhost8080/Test01 라고 한다면 war file의 파일명도 Test01로 변경해주어야 한다는 점이다.
Spring MVC 모델에서 어노테이션은 주로 Controller에 잡히게 된다. 프로그램이 실행되면 xml과 dispatcher 그리고 handler mapping을 거쳐 controller로 가게되는데, 어떠한 service를 제공할 것인지 Client Request를 구분하고 이를 제공하기 위해 실제 Service 파일과 DAO등에 접근 실행을 하는 곳이 바로 '컨트롤러'이다.
(정의가 틀렸다면 수정하겠습니다)
때문에 annotation 태그들은 대부분 컨트롤러에 모여있으며, dispatcher는 폴더를 뒤져 이를 읽어낸다.
실제로 dispatcher.xml 에 작성된 코드이다. @component 태그를 모두 스캔하여 해당 매서드를 활성화 하는 것인데, scanning 할 위치는 base-package 이하로 한다.
@PostMapping(value="write")
@ResponseBody
public void write(@ModelAttribute UserDTO userDTO) {
userService.write(userDTO);
}
@PostMapping(value="checkId")
@ResponseBody
public String checkId(@RequestParam String id) {
return userService.checkId(id);
}
@GetMapping(value="list")
public String list() {
return "/user/list";
}
여기서 헷갈 릴 수 있는 것은, 우리가 XML을 통해서 IoC Container를 생성하지만 파일 상에 확인할 수 없듯이, dispatcher와 핸들러 또한 마찬가지라는 것이다. dispatcher와 mapper는 우리 눈에 보이지 않지만 Spring 내부에서 돌고 있다.
아래 이미지가 설명에 가장 적당할 것같다.
이미지 출처. https://yoonbing9.tistory.com/80
정리해보면,
(1) 우리가 생성한 dispatcher는 http//:~ /user/form(jsp) 라는 사용자의 https 요청을 받고 user 앞의 /를 통해 요청받은 파일의 위치를 인식한다.
(2) 가상에 생성된 handler는 어떠한 Controller 객체가 요청받은 내용을 수행 할 지 user 이하의 '/' 를 통해 정보를 받아오며 (아래 캡쳐의 user/upload, Mapping 작업을 수행한다.
(3) Controller 이하 작업 시작.
(4) (5) (6)의 내용은 추후에 다시 정리하고, 일단 controller에 도달하기까지의 내용이다.
직접 선언하는게 아니라 spring 내부적으로작동한다
/user/upload중에 upload는 mapper가 찾는것이 아니라 dispatcher가 찾는거고 HandlerMapping은 @어노테이션을 이하 value 값으로 찾는다.
@PostMapping(value="upload")
@ResponseBody
public void upload(@RequestParam MultipartFile img) {
//가상폴더
String filePath = "D:\\Spring\\workspace\\chapter06_SpringWebMaven\\WebContent\\storage";
String fileName = img.getOriginalFilename();
File file = new File(filePath, fileName); //파일 생성
@annotation
@Configuration: 빈 설정을 담당할 클래스를 설정한다. 이 클래스 안에서@Bean어노테이션이 동봉된 메소드를 선언하면, 그 메소드를 통해 스프링 빈을 정의하고 생명주기를 설정하게 된다. 자바 기반의 config가 싫다면 XML 쓰면 된다.
@Component: 빈을 선언하는 클래스를 작성하기 위해 넣는 어노테이션이며@ComponentScan의 주요 스캔 대상이다.
@Service: @Component어노테이션의 차이점을 알려면캡슐화개념에 대한 이해가 필요하다. 이 말은 즉슨, 보통 이 어노테이션을 달은 클래스에는 '비즈니스 레이어' 로직에 맞게 짜기 때문에 보통 별도의 데이터를 가지고 있지 않을 것이다. 이건 아주 올바른 사용 케이스이다. 이 어노테이션을 단 클래스는. 그저 업무 메소드만 정의하면 된다. 다른 빈에서 가져와 처리를 하고 결과를 제공하는 그저 비즈니스 로직만 정의하면 된다.
@Autowired: 이 어노테이션은 필드, 메소드, 생성자에다가 넣을 수 있다. 아는 그대로다. 스프링 빈을 가져오는 가장 기본적인 방법이다. 해당 클래스에 맞는 빈을 가져오는데, 만약 하나만 있으면 이름을 아무렇게나 해도 가져오고, 만약 2개 이상이면 시그니처 명칭에 맞는 빈을 가져온다. 오류가 있을 시NoUniqueBeanDefinitionException예외가 발생한다.
@Bean:@Configuration선언한 빈 설정 클래스에 빈 선언을 담당하는 어노테이션으로, 메소드에만 넣을 수 있다. 보통은 메소드 이름이 곧 빈 이름으로 탄생한다.
@Primary:@Configuration선언한 빈 설정 클래스에 빈 선언을 담당하면서,기본빈 요소를 정의할 때 사용한다. 만약 같은 클래스로 여러 개의 빈을 설정했을 때, 이 어노테이션을 추가로 달면,@Autowired어노테이션을 통해 빈을 주입 시 이 어노테이션을 가진 빈을 우선적으로 가져온다고 보면 된다.
@Value: 생성자,setter따위의 메소드, 필드 등에다가 스프링에서 설정한값을 주입할 수 있다.
MVC annotation
@ResponseBody: 컨트롤러 메소드 리턴값에 이 어노테이션을 선언함으로써 스프링은 해당 응답 객체를 클라이언트가 요구하는 요청 내용 유형(Content-Type)에 따라 응답하도록 도와주는 어노테이션이다. 보통은 Jackson 모듈에 의해json유형으로 응답하며, 클라이언트가xml응답을 요청하면xml응답을 해주기도 한다.
@RestController: 이 어노테이션을 달면, 모든 컨트롤러 메소드는@ResponseBody어노테이션이 달린 반환 값을 달고 다니게 된다. 주로 REST API 설계 시 필수 어노테이션이라 보면 된다. 물론ModelAndView처럼 특수한 유형은 스프링이 평소 그대로 처리하여 응답해준다.
@RequestMapping(method = RequestMethod.GET, value = "/path"): 메소드에 달면, 해당 메소드는 이 어노테이션이 설정한 경로를 호출했을 때 메소드가 설정한 응답값을 받게 되며, 컨트롤러 클래스에 달면, 클래스에 설정한 경로를 기준삼아 각 메소드는 클래스 경로의 하위 경로로 추가되어 경로가 잡히게 된다. 또한method설정으로GET만 받거나,POST로 받는 등 특정 HTTP 메소드에만 응답 가능하도록 설정할 수 있으며,GET의 경우@GetMapping같이 메소드 별칭 어노테이션이 있으니 이걸 활용해도 된다. 거기에다가consumes속성으로 요청 값에 대한 유형을 한정지을 수 있으며,produces속성을 통해 응답 유형을 강제할 수 있다. 이들 둘이 설정 시 지정 타입 안맞으면400 Bad Request응답을 뱉도록 스프링에서 설정되어 있다.
@RequestParam(value="name", defaultValue="World"): 컨트롤러 메소드 인자에서 요청값을 받을 때, 요청 주소(URL)에?뒤로 시작하는 질의 문자열,POST전송 시 요청받을 키/값, 등을 받을 수 있으며,required속성으로 필수 여부를 지정할 수 있고,defaultValue속성을 통해 요청이 없을 경우 대체 기본값을 설정할 수 있다. 만약required = true일 경우 해당 파라미터 없이 호출하면400 Bad Request응답을 반환하도록 설정되어 있다.
