스프링부트

redirect 처리하기

• redirect 란? 요청에 대한 처리 후 응답할 때 새로운 URI와 응답코드(3xx)를 주어서 클라이언트가 새로운 URI로 요청하도록 만드는 것을 말함

@Controller
@RequestMapping("/users")
public class UserController {
	private Users users = new Users();
	
	@GetMapping
	public String show(Model model) {
		model.addAttribute("users", users.get());
		return "/users/list";
	}
	
	
	@PostMapping
	public String create(User user) {
		users.add(user);
		return "redirect:/users";
	}
}

• POST /users 에 대한 처리 후 redirect 응답 : 아래는 이에 대한 리스폰스 메세지
  • 클라이언트(웹브라우저)는 Location으로 재요청함(이전 요청과는 전혀 다른 요청 - HTTP는 단발성 요청에 불과함)

HTTP/1.1 302
Content-Language: ko-KR
Content-Length: 0
Date: Mon, 14 May 2018 15:59:34 GMT
Location: http://localhost:8080/users

• redirect 처리를 왜할까? POST 요청을 받고 난 뒤 중복 요청을 하지못하도록 클라이언트가 아예 새로운 요청을 하게 응답코드와 URI 리턴
  • redirect를 하지않을 경우 submit한 데이터가 그대 브라우저 캐시되어 재전송(submit)가능함 : 중복 데이터(요청) 생성됨
  • 3xx : 리퀘스트 요청완료를 위해 리다이렉트가 필요함을 클라이언트에 알리는 응답코드

네트워크

IP, 포트번호 : 요청을 보내기위해 필요한 정보

• IP : 네트워크에 접속된 컴퓨터에 부여된 식별 번호
• 도메인네임 : 32비트, 255.255.255.255로 이뤄진 IP를 통째로 외우지않고도 같은 값으로 인식해서 사용가능
  • 식별가능한 이유는 DNS(Domain Name System)Server에 의해서 가능함 : 도메인을 IP로 변경해달라 요청하면 등록된 값 중 찾아서 IP로 변환해줌
• 포트 : IP + 포트로 사용할 때 호스트(IP)의 어떤 응용프로그램에 대한 요청인지 구분해줄 때 사용
  • 웹서버프로그램 : 80
  • SSH : 22
  • 1 ~ 1024번까지 관리자 권한 번호 : 약속되어진 번호, 프로그램을 변경하려면 관리자 권한 필요
  • 서버에서 같은 IP에 대한 요청이 들어왔을 때 응답 포인트를 포트로 식별함

요청 명령을 받고, 웹브라우저는 프로토콜에 맞춰 리퀘스트 메세지를 작성한다

• 요청 명령 : 사용자로부터 URL을 입력받고 서버에 요청 명령을 받았을 때 규약에 의해 메세지를 작성하고, 요청을 위임한다
• URL 입력 방법

1. 주소 검색창 직접 입력
2. 하이퍼링크
3. form 태그 submit 버튼

• 프로토콜(규약) : 원활한 통신을 하기위해 어떤 데이터를 어느 순서로 보낼 것인지 약속한 것, 웹어플리케이션에서는 HTTP를 사용함
• HTTP(프로토콜) : Hyper Text Transfer Protocol, 하이퍼링크(A문서 -> B문서 이동이 가능한 텍스트)가 있는 문서를 주고 받기위한 프로토콜
• 리퀘스트 메세지 작성하기 : 가장 중요한 것 - 무엇을(URI - 액세스대상), 어떻게(HTTP 메소드) 등

/* HTTP Request Message */

GET / HTTP/1.1
Host: www.naver.com:443
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36

• 첫번째 라인 : 리퀘스트 라인

1. HTTP 메소드 : 어떤 처리를 할 것인지, 주로 GET / POST를 사용하고, 요즘은 PUT / DELETE 까지 HTTP 메소드를 활용하는 추세
2. URI : 액세스 대상, "/" 인 경우 서버프로그램과의 약속에 의해 주로 인덱스 페이지 응답받음, 액세스 대상에는 리소스와 액션 요청이 있음
3. HTTP 버젼

• 공백 라인 전 까지 : 리퀘스트 헤더 - 요청 부수적인 정보
• 공백 라인 다음 라인 : 리퀘스트 바디

1. GET 경우 : URI로 요청 액세스 정보 전달하기때문에 생략
2. POST 경우 : URI로 액션 요청만, 실제 정보는 리퀘스트 바디에 있음(바이너리 데이터)

요청을 받은 서버프로그램은 적절한 처리 후 응답 메세지를 응답한다

• 리퀘스트 메세지에서 필요한 내용을 추출하여 적절한 처리를 함 : 기본적으로 URI와 HTTP 메소드를 활용해서 적절한 처리 메소드를 동작시킴
• springboot로 구현 : URI(“/users”)와 HTTP 메소드(GET)을 맵핑한 처리 메소드(컨트롤러 - 액션)

/* Springboot */
@Controller
@RequestMapping("/users")
public class UserController {
   
   @GetMapping
   public class getUsers() {
   
   }
}

• 처리 후 응답에 대한 정보를 리퀘스트 메세지와 비슷한 리스폰스 메세지를 작성함

HTTP/1.1 200
cache-control: no-cache, no-store, must-revalidate
content-encoding: gzip
content-length: 28522
content-type: text/html; charset=UTF-8
date: Mon, 14 May 2018 14:45:01 GMT
p3p: CP="CAO DSP CURa ADMa TAIa PSAa OUR LAW STP PHY ONL UNI PUR FIN COM NAV INT DEM STA PRE"
pragma: no-cache
referrer-policy: unsafe-url
server: NWS
status: 200
strict-transport-security: max-age=31536000; preload
vary: Accept-Encoding
x-frame-options: SAMEORIGIN

• 첫번째 라인 : 리스폰스 라인 - HTTP 버젼, 응답코드(처리가 어떻게 되었는지)

• 공백라인 전까지 : 리스폰스 헤더
• 공백라인 다음 : 리스폰스 바디, 요청 처리 후 클라이언트에 보낼 데이터가 있을 때 바디에 실어서 보냄

리눅스

데몬(서비스)

• 언제 사용될지 모르기때문에(요청 시점 모름) 항상 켜져 있는 프로그램(온 메모리)
• /etc/init.d 에 위치해있음
• service 명령어를 통해 데몬 제어를 할 수 있음
• 부팅되었을 때도 켜져있어야 할 필요가 있음 : /etc/rc3.d 에 위치 - 프로그램 링크 걸어두기(이름 컨벤션도 있음)

알고리즘

Dynamic Programming(DP)

• 1번 연산한 것은 다시 연산하지않고 꺼내쓰겠다는 것 : 효율적으로
• 아래 파생되는 연산도 중복으로 하지않고 결과만 꺼내다쓸 수 있어서 훨씬 효율적
• 점화식 패턴을 찾는게 중요 : 연습만이 살 길….