Hello World

Temp

EnterKey — Tue, 21 Jun 2022 23:58:51 +0900

임시 글

스프링 관련 번역글 모음

EnterKey — Sun, 16 Aug 2020 21:50:33 +0900

사우가 올린 공식 개발 레퍼런스인데 퀄리티가 괜찮아서 링크 공유합니다.
스프링 배치 4.2 레퍼런스
원문 : https://docs.spring.io/spring-batch/docs/4.2.x/reference/html/index-single.html

스프링 웹 리액티브 스택 5.2.6.RELEASE 레퍼런스
원문 : https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html

리액터 코어 3.3.7.RELEASE 레퍼런스
원문 : https://projectreactor.io/docs/core/release/reference/

객체 검증의 종결자 @Valid

EnterKey — Fri, 10 Feb 2017 17:55:21 +0900

스프링 MVC에서 지원하는 @Valid를 통한 데이터 검증은 정말 놀랍다. 특히 브라우저에서 클라이언트가 입력자료를 넘겨줄 때 이 자료를 검증할 수 있는 모델을 매우 손쉽게 만들 수 있다는 점이다. @Valid는 스프링이 만든 기술은 아니며 최근 JSR-303이란 이름으로 채택된 서블릿 2.3 표준스펙 중 하나인데 매번 그렇듯 스프링은 이 새로운 표준을 확장하고 쉽게 사용할 수 있도록 스프링만의 방식으로 재편성해주었다.

@Valid가 간소화 될 수 있었던 배경을 이해하고 응용할 수 있게끔 학습하는게 중요하겠지만 먼저 @Valid가 얼마나 대단한지 보여주기 위해 맛보기로 간단한 @Valid 예제를 살펴보고자 한다. 먼저 자바빈 객체를 하나 만들어보자.

public class User {

@Size(min=5, max=50) private String id;
@Size(min=5, max=50) private String password;
@Pattern(regexp="^[_0-9a-zA-Z-]+@[0-9a-zA-Z]+(.[_0-9a-zA-Z-]+)*$")
private String email;

… get/set 생략 …
}

그리고 이 JSP파일을 처리할 수 있는 컨트롤러를 하나 만들어 보자. 최초에 문서를 불러들이는 Get과 송신을 위해 필요한 Post, 2가지가 필요하다. 그리고 세션으로 상태유지를 할 수 있게끔 해당 요소를 @SessionAttributes로 공유해주는 것까지 해주도록 하자.

이 몇줄의 코드를 설명시키기 위해 토비의 스프링에서 무려 200쪽이 넘는 공간을 할애하여 설명하고 있으므로 여기서는 가급적 자세한 설명을 생략하도록 하겠다. (생략의 가장 중대한 이유는 필자도 잘 모른다는 사실이지만 그것은 중요치 않다.... :D) 먼저 @ModelAttribute User user와 같은 형태로 클라이언트의 요청을 커맨트 패턴으로 받는다. 그리고 이 모델에 검증을 하기 위해 위의 예제와 같이 @valid라는 검증 어노테이션을 붙인다. 그리고.... 더 해야 할 일은...... 없다.

짜잔! 이것은 기본적인 검증 모델 설계가 끝난 셈이다. 믿지 않겠지만 진짜다. 스프링 MVC는 이와같은 간단한 어노테이션만으로도 검증모델을 유지하며 검증 결과를 BindingResult 객체로 전달해주는 역할을 담당한다. 먼저 자바빈 객체를 살펴보며 @Valid가 무엇인지 부터 알아보자.

@Valid는 그동안 논란이 되왔던, 검증모델이 프리젠테이션 계층에 위치해야 되는지, 서비스 계층에 위치해야 하는지에 대한 논란을 어느 정도 통일시켜주는 표준기술이다. 그러나 역설적으로 @Valid는 그동안의 논란을 뒤집고 검증모델을 프리젠테이션 계층도, 서비스 계층도 아닌 도메인 계층에 삽입할 수 있게 하였다. 즉 @Valid는 아예 원천적으로 등록 오류를 피하기 위해 객체 자체에 검증모델 주입하는 방식을 채택하고 있다.

@Valid에는 기본적으로 14개의 검증 어노테이션을 제공한다.

@AssertFalse : false 값만 통과 가능
@AssertTrue : true 값만 통과 가능
@DecimalMax(value=) : 지정된 값 이하의 실수만 통과 가능
@DecimalMin(value=) : 지정된 값 이상의 실수만 통과 가능
@Digits(integer=,fraction=) : 대상 수가 지정된 정수와 소수 자리수보다 적을 경우 통과 가능
@Future : 대상 날짜가 현재보다 미래일 경우만 통과 가능
@Past : 대상 날짜가 현재보다 과거일 경우만 통과 가능
@Max(value) : 지정된 값보다 아래일 경우만 통과 가능
@Min(value) : 지정된 값보다 이상일 경우만 통과 가능
@NotNull : null 값이 아닐 경우만 통과 가능
@Null : null일 겨우만 통과 가능
@Pattern(regex=, flag=) : 해당 정규식을 만족할 경우만 통과 가능
@Size(min=, max=) : 문자열 또는 배열이 지정된 값 사이일 경우 통과 가능
@Valid : 대상 객체의 확인 조건을 만족할 경우 통과 가능

기본 객체는 대부분의 경우 위의 14가지 어노테이션으로도 통과가 가능하겠지만 생성객체나 좀 더 엄격한 규칙을 위해서는 직접 검증 어노테이션을 구현할 수도 있다. 직접 어노테이션을 구현하는 부분은 다음에 다뤄보기로 하고 지금은 위의 예제가 어떤 방식으로 동작하는 지에 좀 더 집중하도록 하겠다.

이제 위와 같은 어노테이션을 도메인 모델에 적용시켰다면 마지막으로 스프링은 @Valid를 컨트롤러에 적용시킴으로써 깜찍한 마법을 부려준다. 위의 예제에서 @ModelAttributes @Valid User user는 위의 어노테이션 설명에서도 보았듯이 대상 객체에 정의 되있는 확인 조건을 만족시키는 역할을 담당한다. 스프링 MVC는 이런 조건을 만족시키지 못할 경우 내부 컨트롤러에 의해 자동적으로 bindingResult 객체에 담겨저 컨트롤러로 돌아오게 된다.

즉 위의 예제는 /join URL을 Post방식으로 호출할 경우 자연스럽게 @ModelAttribute가 해당 파라미터들을 User객체로 캡슐화 시킴과 동시에 내부에 규약되있는 객체 검을을 @Valid가 발동되면서 오류가 있을 경우 오류 정보를 함께 전송한다. 그리고 마지막으로 스프링 컨테이너에 의해 오류정보는 bindingResult 객체로 분류되면서 끝이 난다.

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
<form:form modelAttribute="user" autocomplete="off">
<h4><strong>회원가입</strong></h4>
<div class="clearfix">
<div class="left">
<form:label path="id">아이디</form:label>
</div>
<div class="left">
<form:input path="id"/>
<form:errors path="id" />
</div>
</div>
<div class="clearfix">
<div class="left">
<form:label path="password">비밀번호</form:label>
</div>
<div class="left">
<form:input path="password"/>
<form:errors path="password" />
</div>
</div>
<div class="clearfix">
<div class="left">
<form:label path="email">이메일</form:label>
</div>
<div class="left">
<form:input path="email"/>
<form:errors path="email" />
</div>
</div>
<div class="clearfix">
<div class="left"></div>
<div class="left"></div>
</div>
<input type="submit" value="업로드" />
</form:form>

아래는 위의 JSP코드와 컨트롤러를 이용하여 만든 예제 회원가입 폼이다.

위의 코드를 적용시키기 위해서는 Spring에서 제공하는 form 태그를 이해해야 하는데 스프링 폼은 나중에 깊게 다루기로 하고 일단 기본적으로 이 스프링 폼을 통해 에러객체와 폼객체를 완벽하게 분리시켰다는 사실만 기억하자.

<form:errors>는 컨트롤러에서 전달받은 에러 객체를 컨트롤하는 역할을 담당하는데 현재 별도의 에러 메시지 설정이 없으므로 기본 에러가 표시된다. 만약 에러메시지를 바꾸고 싶다면 도메인 객체에 삽입한 검증 모델에 message라는 값을 더해주면 된다.

@Size(min=5, max=50, message="5자에서 50자 사이의 값만 가능합니다") private String id;

또 하나의 방법은 messages.properties를 이용하여 이런 에러메시지를 관리하는 방법인데 이 방법은 좀 더 스프링 검증 모델을 완벽히 습득한 뒤에 작성하도록 하겠다. 생각같아선 가급적 @Valid에 대해 완벽하게 다루고 싶었지만 생각보다 복잡한 방식으로 이루어지고 있는데다 확장포인트를 잡기가 어려워 여기서 대략적인 설명만 달아놓을 수 밖에 없었다.

이 문서는 기본적인 설명만을 다루고 있으므로 예제나 방식을 실제 서비스에 적용할 때는 좀 더 많은 관련 문서를 참고해 보고 자신만의 설계 모델을 구축해야 할 것이다.

출처: http://springmvc.egloos.com/509029

쿠키와 세션에 대해 알아보자

EnterKey — Tue, 24 Jan 2017 11:07:45 +0900

많이 들어봤고 실제로 업무를 하면서도 많이 사용하는데 그에 비해 이해도는 많이 떨어지는 것중 하나가 세션, 쿠키 인것같다. (적어도 나에게는..) 실제로 이번에 회사에서 발생한 이슈의 원인이 세션 데이터가 지워저서 발생한 이슈 였는데, 이 원인을 다른사람들과 얘기하다보니, 이해도가 부족하여 제대로된 원인분석이 되지 않는것 같았다.

그래서 이번기회에 세션과 쿠키에 대해 정리를 한번 해보려고 한다.

세션과 쿠키

필요성

세션과 쿠키에 대해 이야기 하기 전에 HTTP의 특성을 몇가지 살펴보자.

HTTP는 요청과 응답을 주고받을때 지속적으로 연결되어 있지 않고, 요청과 응답을 주고받는 순간에만 잠깐 연결되고 끊어진다. 이로인해서 서버와 클라이언트는 현재의 Request에서만 서로를 인지할 수 있다. 이런 HTTP의 특성으로 클라이언트와 서버는 서로 다른 요청간에 정보를 공유할 수 없게된다.

이런 HTTP의 특성을 Connectionless와 Sateless 라고 한다. (참고 : https://www.tutorialspoint.com/http/http_overview.htm)

하지만 우리는 로그인상태, 장바구니정보 등 서버에서는 클라이언트의 상태를 저장하고 있을 필요가 있으며, 서버는 이런 상태를 쿠키와 세션을 이용해 저장한다.

이제 쿠키와 세션이 왜 필요한지 알았으니, 이게 뭔지 알아보자.

쿠키

앞서 말했듯 쿠키와 세션은 서버에서 클라이언트의 상태를 저장하는 수단이다. (지금부터는 상태와 데이터 라는 말을 같이 쓰겠다.) 세션과 다른점은 쿠키는 항상 클라이언트에 데이터를 저장한다는 점이다. 그런데, 서버에서 클라이언트의 상태를 저장하기 위한 수단이라면서 클라이언트에 저장하면, 서버에서는 그 데이터를 어떻게 확인한다는 걸까? 이 부분은 쿠키의 동작을 보면 이해할 수 있다.

쿠키의 동작

위 그림은 서버(www.test.com)와 클라이언트의 HTTP Request, Response를 헤더와 함께 간단히 표현한 그림이다.

Request #1 을 보면, 헤더에는 쿠키에 관련된 값이 없다.
서버에서는 응답을 보내기 전, 쿠키에 ‘id’ 라는 키로 ‘mingook’ 이라는 값을 설정했다.
Response #1 에는 Set-Cookie 라는 헤더에 설정한 쿠키값이 담겨서 클라이언트로 내려간다. 이때 ‘domain’이라는 값이 생겼다. (config로 설정하기도, 직접 입력하기도 한다.)
클라이언트에서는 Set-Cookie 헤더의 값을 표와 같이 저장한다.
다시 요청을 보낼때, 클라이언트는 쿠키의 domain을 확인하고 해당 domain으로 요청을 보낼경우 cookie 헤더에 값을 설정하여 요청을 보낸다.

위와 같은 과정을 통해서, 서버가 클라이언트에 저장한 쿠키는 다시 서버로 돌아와서 제 역할을 할 수 있게 된다.

하지만 쿠키는 클라이언트에 저장되기 때문에 보안에 취약하다는 단점이 있다. 지금 당장 크롬의 개발자도구만 실행시켜도 쿠키에 저장된 값을 확인할 수 있다. 이런 단점을 보완해 주는게 세션이다.

세션

많은 사람들이 쿠키와 세션의 차이점으로 쿠키는 클라이언트에 세션은 서버에 저장되고 이로인해서 보안적인 측면에서 세션이 유리하다고 알고 있을것이다. 나도 이번에 다시 세션과 쿠키를 공부하기전까지는, ‘쿠키는 클라이언트에, 세션은 서버에 저장되는 값’ 정도로 이해하고 있었다.

하지만 세션은 쿠키에 저장되기도 한다. 즉, 클라이언트에 저장되기도 한다는 말이다. PHP 프레임워크 중 하나인 코드이그나이터가 디폴트로 세션을 쿠키에 저장하는데, 이런점으로 보아 ‘세션은 클라이언트의 상태를 서버에 저장하는 것’ 이라는 말은 100% 맞다고 할 순 없을 것 같다. 저장한다기 보다 서버에서 클라이언트의 상태를 유지하는 수단 이라는 말이 좀 더 맞을 것 같다. 추가로, 세션을 쿠키에 저장하게 되면 앞서 말한데로 보안적 이슈가 있기때문에, 반드시 암호화를 해줘야 한다. (암호화를 하더라도.. 서버에 있는게 더 안전하니까, 왠만하면 서버에 저장하는게 좋을 것 같다.)

세션을 저장하는 방법

세션을 저장하는 방법은 여러가지가 있는데 대충 다음과 같은 방법이 있는 것 같다.

메모리
파일
데이터베이스
쿠키

메모리, 파일, 데이터베이스는 서버에, 쿠키는 클라이언트에 세션을 저장하는 방법이다.

만약, 부하분산을 위해 한 도메인에 여러대의 서버를 운영하고 있다면, 데이터베이스나 쿠키를 이용해야 한다. 메모리나 파일은 물리적으로 서버간에 나누어저 있기 때문에, 세션이 유지될 수 없다. 단, 쿠키는 위에 말했듯 보안상 좋지 않으니 DB를 이용하는게 좋겠다.

세션의 동작

이제 마지막이다~! 세션의 동작원리를 살펴보자.
1. Request #1 요청이 들어왔다.
2. 서버에서는 세션을 시작하고, 세션에 ‘id’ = ‘mingook’ 이라는 값을 설정했다.
3. Response #1 에서의 Set-Cookie헤더를 잘 보자. 쿠키때와는 다르게 이번에는 session_id가 내려간다. (세션아이디의 key는 컨테이너마다 다를 수 있다.)
4. 이제 클라이언트에서는 .test.com 도메인으로의 요청에는 session_id를 쿠키에 담아 전송한다.
5. 서버에서는 session_id를 가지고 해당 클라이언트의 세션을 찾아서 필요한 값을 조회한다. 즉, session_id는 서버가 클라이언트를 구분할 수 있게 해주는 key가 된다.

위의 예시는 세션을 서버에 저장할 경우이고, 쿠키에 세션을 저장하는 경우는 약간다르다. 서버에 저장되어있는 ‘id’=’mingook’ 이라는 값이 모두 세션쿠키에 저장될 것이다. (이부분은 궁금하면 직접 구현해보자.)

끝!

출처: https://cinabrosite.wordpress.com/2017/01/24/cookie_session/

Cross Domain API

EnterKey — Tue, 24 Jan 2017 10:59:39 +0900

최근 개발하고 있는 서비스는 API 서버들은 특정 기능만을 제공하고 화면에서의 기능은 대부분 React를 이용하여 Client Side에서 처리하고 있습니다. 이런 구성을 마이크로서비스 아키텍처라고 부를 수도 있을텐데 이번 글의 주제는 마이크로 서비스 아키텍처에 대한 이야기는 아니고 이런 구성시에 API 서버쪽 설정과 관련한 몇가지 삽질한 것에 대한 내용입니다. 웹이나 API 서버 개발을 계속 해오신 분들은 잘 아는 내용이겠지만 저처럼 간만에 하시는 분들을 위한 글입니다.

[그림] 시스템 기본 구성

위 그림의 시스템 구성에 대해서는 나중에 다른 글로 소개하도록 하겠습니다.

CORS 이슈

위와 같은 시스템 구성에서 첫번째 만나는 문제는 HTTP를 이용하여 API 서버로 GET, POST와 같은 요청을 보낼때 그 페이지를 받은 도메인(여기서는 web.popit.kr)과 API를 서비스하는 서버의 도메인(member.popit.kr 또는 shop.popit.kr)이 다르기 때문에 다음과 같은 에러가 발생한다는 것입니다.

1
2
3
XMLHttpRequest cannot load http://membership.popit.kr/api/v1/login. 
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://web.popit.kr' is therefore not allowed access.

이 에러 메시지의 의미는 페이지 내에서 Ajax 호출 시 다른 도메인의 URL을 호출했다는 의미입니다. 다음 문서에 보면 브라우저에서 다른 도메인으로 요청을 보낼때에 대한 규약이 잘 설명되어 있습니다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS

요약하자면 CORS(Cross-Origin Resource Sharing)라고 하여 도메인이 다른 서버에 대한 호출에 대한 정의 입니다. 브라우저는 다른 도메인으로 Ajax 등의 호출을 보내기 전에 다음과 같은 순서로 동작합니다.

“preflight” 확인 요청을 OPTIONS method로 전송
- 요청 시 Http Header의 속성으로 “Origin”에 자신의 도메인을 전송
이 요청을 받은 서버는 정상적인 요청인지 확인하여, 정상적인 요청이면 Response에 허용 가능한 도메인(Access-Control-Allow-Origin), Method(Access-Control-Allow-Methods), Header 속성(Access-Control-Allow-Headers) 등을 설정하여 응답
OPTIONS 요청에 대해 수신을 받은 브라우저는 Header의 “Access-Control-Allow-*” 정보를 이용하여 요청을 보낼 수 있는지 판단하여 권한이 없는 경우 위와 같은 에러 처리를 하고 요청을 보낼 수 있으면 요청 전송

위와 같은 흐름에서 브라우저가 1, 3번은 처리를 자동으로 하기 때문에 개발자나 시스템 운영자는 2번에 대한 설정을 해야만 합니다. 2번을 해결하기 위해서는 서버측에서는 다음 두가지 설정을 해야 합니다.

API로 공개되는 모든 URL에 대해 OPTIONS Routes 설정 및 Http Response 설정
API URL에 대한 Http Response 설정

이를 위해 Spring을 사용하는 경우라면 Controller나 Method에 “@CrossOrigin” 어노테이션 추가만 하면 됩니다. 필자의 환경은 주로 Rails 인데 “rack-cors” gem을 사용할 수도 있지만 다음과 같이 자체 해결하였습니다.

OPTIONS Routes 설정
모든 API 요청에 대해 OPTIONS Route 설정을 위해서 routes.rb 파일에 match 를 이용하여 모든 URL에 대해 base_controller의 cors_preflight_check acrtion을 사용

routes.rb
Ruby
1
2
3
4
5
6
7
8
namespace :api, defaults: {format:'json'} do
  namespace :v1 do
    post "members/signup" => "members#signup"
    get "members/signin" => "members#signin"
 
  end
  match "*all" => "base#cors_preflight_check", via: [:options]
end

controllers/api/base_controller.rb
Ruby
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
module Api
  class BaseController < ApplicationController
    before_action :cors_preflight_check
    after_action :cors_set_access_control_headers
 
    def cors_preflight_check
      if request.method == :options
        headers['Access-Control-Allow-Origin'] = request.headers['Origin'] || '*'
        headers['Access-Control-Allow-Methods'] = 'POST, PUT, GET, OPTIONS'
        headers['Access-Control-Allow-Headers'] = '*'
        headers['Access-Control-Max-Age'] = '1728000'
        head :ok
      end
    end
  end
end

API 요청 처리에 대한 Http Response 처리
클라이언트와 약속된 Http Header의 Attribute에 대한 허용 옵션 등을 추가

controllers/api/base_contorller.rb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
module Api
  class BaseController < ApplicationController
    before_action :cors_preflight_check
    after_action :cors_set_access_control_headers
 
    def cors_preflight_check
      if request.method == :options
        headers['Access-Control-Allow-Origin'] = request.headers['Origin'] || '*'
        headers['Access-Control-Allow-Methods'] = 'POST, PUT, GET, OPTIONS'
        headers['Access-Control-Allow-Headers'] = '*'
        headers['Access-Control-Max-Age'] = '1728000'
        head :ok
      end
    end
 
    def cors_set_access_control_headers
      headers['Access-Control-Allow-Origin'] = '*'
      headers['Access-Control-Allow-Methods'] = 'POST, PUT, DELETE, GET, PATCH, OPTIONS'
      headers['Access-Control-Request-Method'] = '*'
      headers['Access-Control-Allow-Headers'] = 'Origin, X-Requested-With, Content-Type, Accept, Authorization, Secrete_Token'
    end
  end
end

Spring의 “@CrossOrigin”이나 Rails의 rack-cors gem을 이용하면 간단하게 해결되겠지만, 이런것을 사용할 수 없는 상황에서는 동작하는 기본 원리와 무엇을 처리해야 하는지 알고 있어야 문제를 해결할 수 있을 것 같아서 자체 설정으로 해결해 보았습니다.

422 Unprocessable Entity 에러

여기까지 해결하고 잘 동작할 것이라 생각했는데 또 문제가 되는 것이 하나 있습니다. 원래는 CORS 문제 발생 전에 이 문제부터 먼저 겪게 됩니다. Rails로 서버를 실행하고 다른 도메인에 의해 가져온 html에서 Rails 서버로 API를 호출하게 되면 브라우저에서 다음과 같은 에러 메시지가 나타납니다.

1
2
3
4
5
OPTIONS http://membership.popit.kr/api/v1/login 422 (Unprocessable Entity)
XMLHttpRequest cannot load http://membership.popit.kr/api/v1/login. 
Response to preflight request doesn't pass access control check: 
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://web.popit.kr' is therefore not allowed access. The response had HTTP status code 422.

OPTIONS 가 전송되는 것은 앞에서 설명드린 CORS 관련 이슈이고, “422 Unprocessable Entity 메시지는 또 다른 이유때문에 발생하는 에러 입니다. Rails 서버 측에는 다음과 같은 에러 로그가 나타납니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
Started OPTIONS "/api/v1/members/login" for ::1 at 2017-01-22 15:32:07 +0800
Processing by Api::BaseController#cors_preflight_check as JSON
Can't verify CSRF token authenticity.
Completed 422 Unprocessable Entity in 1ms (ActiveRecord: 0.0ms)
 
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
 
actionpack (5.0.1) lib/action_controller/metal/request_forgery_protection.rb:195:in `handle_unverified_request'
actionpack (5.0.1) lib/action_controller/metal/request_forgery_protection.rb:223:in `handle_unverified_request'
actionpack (5.0.1) lib/action_controller/metal/request_forgery_protection.rb:218:in `verify_authenticity_token'
activesupport (5.0.1) lib/active_support/callbacks.rb:382:in `block in make_lambda'
activesupport (5.0.1) lib/active_support/callbacks.rb:169:in `block (2 levels) in halting'
actionpack (5.0.1) lib/abstract_controller/callbacks.rb:12:in `block (2 levels) in <module:Callbacks>'

Rails 서버는 CSRF(Cross Site Request Forgery)에 대한 처리를 위해 모든 Request에 대해 서버에서 Token을 발급하고 그 Token을 세션에 저장한 다음 Client로 부터 오는 GET method가 아닌 요청에 대해 해당 Token을 비교하여 다른 경우 위와 같이 CSRF 오류를 발생시킵니다. Rails 서버에서 Render된 HTML이라면 다음과 같은 코드를 삽입하고 Ajax 호출 시 Header에 해당 메타 정보에 있는 값을 추가해주면 되지만 도메인이 다른 경우라면 이렇게 사용할 수 없습니다.

<%= csrf_meta_tags %>

CSRF에 대한 자세한 내용은 아래 링크를 참고하세요.

http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

도메인이 다른 경우에는 이렇게 Token을 비교해서 에러 처리하는 부분을 skip 하도록 구성해야 하는데 ‘controllers/api/base_controller.rb’에 다음과 같이 설정하여 CSRF 문제를 해결할 수 있습니다.

1
2
3
4
5
6
7
module Api
  class BaseController < ApplicationController
    # skip_before_action :verify_authenticity_token
    protect_from_forgery with: :null_session
    ...
  end
end

인터넷에서 검색해보면 주석처리된 “verify_authenticity_token”을 skip 하라는 대답도 있는데 이것은 모든 경우에 대해 skip 하는 것이고 “protect_from_forgery” 옵션으로 주어진 상황(여기서는 null_session)에 대해서 CSRF 보호 처리를 하라는 것이기 때문에 이것이 더 안전하다고 생각되어 이것으로 적용하였습니다.

이것은 문제의 완벽한 해결이라기 보다 회피라고 할 수 있는데 이렇게 회피하는 경우라 할지라도 서비스 운영 시에는 Cross Domain API 호출에 대한 CSRF 문제 해결 방법을 찾아내서 적용해야 할 것입니다. 저도 아직 해결은 못했고 고민 중에 있습니다. 해결 방법을 아시는 분은 알려주시면 감사하겠습니다.

HTTP Request Header에서 사용자 정의 Attribute 가져오기(Rails)

이렇게 웹 페이지에서 서로 다른 서버로 호출하는 경우 인증을 위해서는 HTTP Request Header에 인증을 위한 Token을 추가해서 요청을 보내는 경우가 많습니다. 이 경우 사용자 정의된 Key를 사용하게 되는데 흔히 다음과 같이 사용합니다.

JavaScript
1
2
3
4
5
6
$.ajax({
    headers: {
      'security-token': localStorage.getItem("security-token")
    },
    url: myUrl
});

물론 위와 같이 인증을 위한 속성인 경우 ‘Authorization’ 와 같이 이미 정의된 key를 사용할 수 있지만 기존 많은 화면이 위와 같이 사용자 정의 key를사용하고 있어 어쩔수 없이 사용자 정의 속성을 이용해야 했습니다. 이런 상태에서 한참을 삽질했는데 내용은 다음과 같습니다.

Client에서 전송된 HTTP Request의 Header에 있는 속성 값을 읽기 위해서는 일반적으로 다음과 같이 합니다.

token = request.headers[‘security-token’]

이런 구현에서는 무조건 nil 이 반환됩니다. 반면 다음과 같은 속성은 잘 가져 옵니다.

referer = request.headers[‘Referer’]

한참을 검색한 결과 다음 Link로 가는 문서를 찾았는데 2004년 만들어진 CGI(Common Gateway Interface) 에 대한 표준 스펙입니다.

https://tools.ietf.org/html/rfc3875#section-4.1.18

여기 보면

사용자 정의 Meta Variable은 반드시 대문자를 사용해야 하고, “HTTP_”로 시작하도록 처리되어야 하면 “-” 는 “_”로 변환되어야 한다.

라고 나와 있습니다.

즉 ‘security-token’과 같은 경우라면 ‘HTTP_SECURITY_TOKEN’으로 처리되어야 한다는 것입니다. Rails는 이 조건을 무조건 따르고 있기 때문에 서버 측에서 HTTP Request Header의 사용자 정의 속성의 키는 HTTP_<upper_case(user_defined_attribute_key)> 형태로 변환하여 Controller로 보내게됩니다. 즉 위와 같은 상황에서는 다음과 같이 처리해야 합니다.

token = request.headers[‘HTTP_SECURITY_TOKEN’]

‘Referer’의 속성은 정상적으로 잘 가져오는 이유도 여기에 있습니다.

마치며

아키텍처가 진화하고 보안에 대한 위협 다양한 위협이 존재하는 상황에서 Cross Domain에 대한 처리는 더 많아지고 있습니다. 이런 환경에서의 시스템도 그에 맞게 적절한 보안 구성이 필요하게 되었습니다. Cross Domain에서 정상적인 요청과 비정상적인 요청에 대한 판별 방법에 대해서 더 많이 고민해봐야 겠습니다.

출처: http://www.popit.kr/corss-domain-api-%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%84%B1/

MySQL 중복 키 관리 방법 (INSERT 시 중복 키 관리 방법 (INSERT IGNORE, REPLACE INTO, ON DUPLICATE UPDATE)

EnterKey — Mon, 23 Jan 2017 19:05:40 +0900

안내

본 문서는 블로그의 운영자인 본인이 Stackoverflow에 올린 답변을 정리한 글입니다. Stackoverflow에 올린 답변 중 한국에 있는 다른 개발자들에게도 도움이 될만한 Q&A를 보기 쉽게 정리했습니다. 가능한 경우는 SQLFiddle에 샘플 데이터도 같이 올려서 실습도 해 볼 수 있도록 하였습니다. 또한 전체 Q&A를 묶어서 PDF 파일로도 배포하고 있습니다. 방문해 주시는 많은 분들에게 도움이 되었으면 좋겠습니다.

Stackoverflow URL

http://stackoverflow.com/questions/20342518/on-duplicate-key-update-value-inserting-same-values-twice/20342598

질문

다음과 같이 INSERT 구문을 사용 중이다.

INSERT INTO person VALUES(NULL, 15, 'James', 'Barkely')
    ON DUPLICATE KEY UPDATE academy_id = VALUES(academy_id);

중복된 값을 여러 번 INSERT한 뒤에 SELECT를 해 보면 중복된 값이 저장되어 있다.

mysql> SELECT * FROM person;
+----+------------+------------+-----------+
| id | academy_id | first_name | last_name |
+----+------------+------------+-----------+
|  1 |         15 | James      | Barkely   |
|  2 |         15 | Cynthia    | Smith     |
|  3 |         15 | James      | Barkely   |
|  4 |         15 | Cynthia    | Smith     |
|  5 |         15 | James      | Barkely   |
+----+------------+------------+-----------+
5 rows in set (0.00 sec)

무엇이 잘못된 것인가?

답변

중복 키 관리를 위해서는 중복 방지를 할 컬럼이 PRIMARY KEY이거나 UNIQUE INDEX이어야 한다. 질문자의 경우 first_name과 last_name의 조합을 이용하여 중복 관리를 하려는 것 같다. 따라서다음과 같이 last_name, last_name을 PRIMARY KEY로 설정하거나,

ALTER TABLE person ADD PRIMARY KEY (first_name, last_name) UNIQUE INDEX를 추가해야 한다.

ALTER TABLE person ADD UNIQUE INDEX (first_name, last_name)

INSERT 시 중복 키 관리를 위한 방법에는 다음과 같이 3가지가 있다.

INSERT IGNORE
REPLACE INTO …
INSERT INTO … ON DUPLICATE UPDATE

중복 키 관리는 본 책의 앞 부분에서 잠시 언급되었는데 각각의 특징을 좀 더 자세히 알아보도록 하자.

앞의 person 테이블을 다음과 같이 생성한 뒤에 테스트를 진행하였다.

CREATE TABLE person
(
  id INT NOT NULL AUTO_INCREMENT,
  academy_id INT,
  first_name VARCHAR(20),
  last_name VARCHAR(20),
  PRIMARY KEY (id),
  UNIQUE INDEX (first_name, last_name)
);

INSERT IGNORE

`INSERT IGNORE`는 중복 키 에러가 발생했을 때 신규로 입력되는 레코드를 무시하는 단순한 방법이다. 다음의 예를 보면 중복 키 에러가 발생했을 때 INSERT 구문 자체는 오류가 발생하지 않고, 대신'0 row affected'가 출력된 것을 볼 수 있다.

mysql> INSERT IGNORE INTO person VALUES (NULL, 15, 'James', 'Barkely');
Query OK, 1 row affected (0.00 sec)
 
mysql> INSERT IGNORE INTO person VALUES (NULL, 15, 'Cynthia', 'Smith');
Query OK, 1 row affected (0.00 sec)
 
mysql> INSERT IGNORE INTO person VALUES (NULL, 15, 'James', 'Barkely');
Query OK, 0 rows affected (0.00 sec)
 
mysql> INSERT IGNORE INTO person VALUES (NULL, 15, 'Cynthia', 'Smith');
Query OK, 0 rows affected (0.00 sec)
 
mysql> INSERT IGNORE INTO person VALUES (NULL, 15, 'James', 'Barkely');
Query OK, 0 rows affected (0.00 sec)

당연히 SELECT의 결과는 2건만 존재한다.

mysql> SELECT * FROM person;
+----+------------+------------+-----------+
| id | academy_id | first_name | last_name |
+----+------------+------------+-----------+
|  1 |         15 | James      | Barkely   |
|  2 |         15 | Cynthia    | Smith     |
+----+------------+------------+-----------+
2 rows in set (0.00 sec)

AUTO_INCREMENT 컬럼의 값이 1, 2인 것에 주목하라

REPLACE INTO

"REPLACE INTO"는 "INSERT INTO" 구문에서 INSERT를 REPLACE로 바꾼 구문이다. 사용 방법은 "INSERT INTO"와 완벽히 동일하다.

mysql> REPLACE INTO person VALUES (NULL, 15, 'James', 'Barkely');
Query OK, 1 row affected (0.00 sec)
 
mysql> REPLACE INTO person VALUES (NULL, 15, 'Cynthia', 'Smith');
Query OK, 1 row affected (0.00 sec)
 
mysql> REPLACE INTO person VALUES (NULL, 15, 'James', 'Barkely');
Query OK, 2 rows affected (0.00 sec)
 
mysql> REPLACE INTO person VALUES (NULL, 15, 'Cynthia', 'Smith');
Query OK, 2 rows affected (0.00 sec)
 
mysql> REPLACE INTO person VALUES (NULL, 15, 'James', 'Barkely');
Query OK, 2 rows affected (0.00 sec)

REPLACE INTO의 결과는 INSERT IGNORE와 다르게 중복 키 오류 발생 시 ‘2 rows affected’가 출력되었다. SELECT 결과는 다음과 같다.

mysql> SELECT * FROM person;
+----+------------+------------+-----------+
| id | academy_id | first_name | last_name |
+----+------------+------------+-----------+
|  4 |         15 | Cynthia    | Smith     |
|  5 |         15 | James      | Barkely   |
+----+------------+------------+-----------+
2 rows in set (0.00 sec)

id가 4, 5로 변하였다. 이를 ‘2 rows affected’와 함께 종합적으로 판단한다면 “REPLACE INTO”는 중복 키 오류 발생 시 기존 레코드를 삭제하고 새로운 레코드를 입력한 것이다. 그래서 ‘2 rows affected’가 출력되었다. 1건은 DELETE, 1건은 INSERT로 보면 되고, 새로운 레코드가 입력되면서 AUTO_INCREMENT 컬럼의 값이 매번 새롭게 발급되었다.

AUTO_INCREMENT는 흔히 레코드를 식별할 수 있는 id로 사용되는데 이 값이 변경될 수 있으므로 “REPLACE INTO”는 그다지 좋은 방법이 아니다.

ON DUPLICATE UPDATE

ON DUPLICATE UPDATE는 중복 키 오류 발생 시 사용자가 원하는 값을 직접 설정할 수 있다는 장점이 있다. 우선 기본적인 사용 방법을 보자.

mysql> INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely')
    ->     ON DUPLICATE KEY UPDATE academy_id = VALUES(academy_id);
Query OK, 1 row affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'Cynthia', 'Smith')
    ->     ON DUPLICATE KEY UPDATE academy_id = VALUES(academy_id);
Query OK, 1 row affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely')
    ->     ON DUPLICATE KEY UPDATE academy_id = VALUES(academy_id);
Query OK, 0 rows affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'Cynthia', 'Smith')
    ->     ON DUPLICATE KEY UPDATE academy_id = VALUES(academy_id);
Query OK, 0 rows affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely')
    ->     ON DUPLICATE KEY UPDATE academy_id = VALUES(academy_id);
Query OK, 0 rows affected (0.00 sec)

INSERT 결과만 보면 “INSERT IGNORE”와 동일하다.

mysql> SELECT * FROM person;
+----+------------+------------+-----------+
| id | academy_id | first_name | last_name |
+----+------------+------------+-----------+
|  1 |         15 | James      | Barkely   |
|  2 |         15 | Cynthia    | Smith     |
+----+------------+------------+-----------+
2 rows in set (0.00 sec)

SELECT 결과를 보니, 중복 키 오류 발생 시 기존 레코드는 그대로 남아 있는 것 같다. 즉, id 값이 변경되지 않았다. 그렇다면 “ON DUPLICATE UPDATE”는 “INSERT IGNORE” 대비 장점은 없을까?아니다. 복잡하고 어려운 대신에 중복 키 오류 발생 시 사용자가 원하는 행동을 지정할 수 있다는 장점이 있다. 예를 위해 person 테이블 구조를 다음과 같이 변경했다.

CREATE TABLE person
(
  id INT NOT NULL AUTO_INCREMENT,
  academy_id INT,
  first_name VARCHAR(20),
  last_name VARCHAR(20),
  insert_cnt INT,
  PRIMARY KEY (id),
  UNIQUE INDEX (first_name, last_name)
);

그런 뒤 다음과 같은 INSERT 구문을 실행하였다.

mysql> INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely', 1)
    ->     ON DUPLICATE KEY UPDATE insert_cnt = insert_cnt + 1;
Query OK, 1 row affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'Cynthia', 'Smith', 1)
    ->     ON DUPLICATE KEY UPDATE insert_cnt = insert_cnt + 1;
Query OK, 1 row affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely', 1)
    ->     ON DUPLICATE KEY UPDATE insert_cnt = insert_cnt + 1;
Query OK, 2 rows affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'Cynthia', 'Smith', 1)
    ->     ON DUPLICATE KEY UPDATE insert_cnt = insert_cnt + 1;
Query OK, 2 rows affected (0.00 sec)
 
mysql>
mysql> INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely', 1)
    ->     ON DUPLICATE KEY UPDATE insert_cnt = insert_cnt + 1;

Query OK, 2 rows affected (0.00 sec) SELECT를 해 보면 insert_cnt에는 해당 중복 값이 몇 번 INSERT 시도가 되었는지 기록되어 있을 것이다.

mysql> SELECT * FROM person;
+----+------------+------------+-----------+------------+
| id | academy_id | first_name | last_name | insert_cnt |
+----+------------+------------+-----------+------------+
|  1 |         15 | James      | Barkely   |          3 |
|  2 |         15 | Cynthia    | Smith     |          2 |
+----+------------+------------+-----------+------------+
2 rows in set (0.00 sec)

이 외에도 다양한 용도로 활용될 수 있다.

주의해야 할 점은 INSERT 구문에 주어진 값으로 UPDATE하고자 할 때는 항상 “VALUES(column)”과 같이 VALUES()로 감싸야 한다는 점이다. 만약 다음과 같이 VALUES() 없이 사용한다면 기존에존재하는 레코드의 컬럼 값을 의미하게 된다.

INSERT INTO person VALUES (NULL, 15, 'James', 'Barkely')
    ON DUPLICATE KEY UPDATE academy_id = academy_id;

앞과 같이 사용했을 때, 기존 person 테이블에 존재하는 ‘James Barkely’의 academy_id가 13이었다면, INSERT 후에도 academy_id는 여전히 13이다.

요약

INSERT IGNORE
REPLACE INTO …
INSERT INTO … ON DUPLICATE UPDATE

분류	특징
INSERT IGNORE	기존 레코드가 남아 있음 기존 레코드의 AUTO_INCREMENT 값은 변하지 않음
REPLACE INTO	기존 레코드가 삭제되고, 신규 레코드가 INSERT됨 따라서 AUTO_INCREMENT의 값이 변경됨
ON DUPLICATE UPDATE	INSERT IGNORE의 장점 포함함 중복 키 오류 발생 시, 사용자가 UPDATE될 값을 지정할 수 있음

출처: http://jason-heo.github.io/mysql/2014/03/05/manage-dup-key2.html

MySQL 트랜잭션 Isolation Level로 인한 장애 사전 예방 법

EnterKey — Fri, 11 Nov 2016 11:17:55 +0900

Overview

MySQL에서 전체 데이터를 Scan 하는 쿼리를 질의하여 서비스에 큰 영향이 발생할 수 있습니다.

InnoDB 스토리지 엔진의 기본 Isolation Level이 REPEATABLE-READ이기 때문에 발생하는 현상인데, 이것은 세션 변수 일부를 변경하여 문제를 사전에 해결할 수 있습니다.

얼마 전 이와 비슷한 장애가 발생하여 원인 분석 및 해결 방안을 포스팅합니다.

Symptoms

Transaction Isolation Level이 REPEATABLE-READ(MySQL Default) 상태에서 Insert into Select 혹은 Create Table As Select 로 전체 테이블 참조 쿼리 실행 시 참조 테이블에 데이터 변경 작업이 “대기” 상태에 빠지는 현상이 있습니다.

mysql> show variables like 'tx_isolation';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+
1 row in set (0.00 sec)

Insert Into Select

세션1

mysql> insert into activity_test_stat2
    -> select
    ->     act_type,
    ->     to_uid,
    ->     act_time,
    ->     to_user_name,
    ->     before_user_name,
    ->     count(*) cnt
    -> from activity_test
    -> group by act_type, to_uid, act_time,
    ->     to_user_name, before_user_name;

세션2 – 테이블에 데이터 변경

mysql> update activity_test set ACT_TYPE = 105 limit 10;

세션3 - update SQL는 “Updating” 상태

mysql> show processlist\G
************************* 1. row *************************
     Id: 255867
   User: root
   Host: localhost
     db: snsfeed
Command: Query
   Time: 1
  State: Updating
   Info: update activity_test set ACT_TYPE = 105 limit 10
************************* 2. row *************************
     Id: 255962
   User: root
   Host: localhost
     db: snsfeed
Command: Query
   Time: 2
  State: Copying to tmp table
   Info: insert into activity_test_stat2 select act_type,

Delete 작업 시 Update와 같이 대기 현상 또는 Dead Lock 오류 발생합니다.

mysql> delete from activity_test limit 10;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Create Table As Select

세션1

mysql> create table activity_test_stat as
    -> select
    ->     act_type,
    ->     to_uid,
    ->     act_time,
    ->     to_user_name,
    ->     before_user_name,
    ->     count(*) cnt
    -> from activity_test
    -> group by act_type, to_uid, act_time,
    ->     to_user_name, before_user_name;

세션2 – 테이블에 데이터 변경

mysql> update activity_test set ACT_TYPE = 105 limit 10;

세션3 - update SQL는 “Updating” 상태

mysql> show processlist\G
************************* 1. row *************************
     Id: 255867
   User: root
   Host: localhost
     db: snsfeed
Command: Query
   Time: 2
  State: Updating
   Info: update activity_test set ACT_TYPE = 105 limit 10
************************* 2. row *************************
     Id: 255962
   User: root
   Host: localhost
     db: snsfeed
Command: Query
   Time: 4
  State: Copying to tmp table
   Info: create table activity_test_stat as select act_type,

Delete 작업 시 Update와 같이 대기 현상 또는 Dead Lock 오류 발생합니다.

mysql> delete from activity_test limit 10;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Cause

MySQL InnoDB 스토리지 엔진의 기본 Isolation Level이 REPEATABLE-READ로 설정되어 있기 때문에 발생합니다.

REPEATABLE-READ에서는 현재 Select 버전을 보장하기 위해 Snapshot을 이용하는데, 이 경우 해당 데이터에 관해서 암묵적으로 Lock과 비슷한 효과가 나타납니다.

즉, Select 작업이 종료될 때까지 해당 데이터 변경 작업이 불가합니다.

Transaction Isolation Level

READ UNCOMMITTED
다른 트랜잭션이 Commit 전 상태를 볼 수 있음
Binary Log가 자동으로 Row Based로 기록됨 (Statement설정 불가, Mixed 설정 시 자동 변환)
READ-COMMITTED
Commit된 내역을 읽을 수 있는 상태로, 트랜잭션이 다르더라도 특정 타 트랜잭션이 Commit을 수행하면 해당 데이터를 Read할 수 있음
Binary Log가 자동으로 Row Based로 기록됨 (Statement설정 불가, Mixed 설정 시 자동 변환)
REPEATABLE READ
MySQL InnoDB 스토리지 엔진의 Default Isolation Level
Select 시 현재 데이터 버전의 Snapshot을 만들고, 그 Snapshot으로부터 데이터를 조회
동일 트랜잭션 내에서 데이터 일관성을 보장하고 데이터를 다시 읽기 위해서는 트랜잭션을 다시 시작해야 함
SERIALIZABLE
가장 높은 Isolation Level로 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 Shared Lock이 걸림
다른 트랜잭션에서는 해당 영역에 관한 데이터 변경 뿐만 아니라 입력도 불가

Isolation Level에 관한 자세한 정보는 하단 MySQL 매뉴얼을 참조하세요.
http://dev.mysql.com/doc/refman/5.5/en/set-transaction.html

Solution

Insert into Select 경우 Isolation Level을 READ-COMMITED나 READ-UNCOMMITED로 변경하여 해결할 수 있습니다.
다음과 같이 세션 설정을 변경 후 Create Table As Select, Insert into Select를 수행하면 문제가 없습니다.

mysql> set tx_isolation = 'READ-COMMITTED';

설정 파일에 영구적으로 transaction isolation 변경 적용하고자 한다면 다음과 같이 설정 후 DB를 재시작 합니다.

$ vi /etc/my.cnf
## [mysqld] 설정에 추가
transaction-isolation           = READ-COMMITTED

비슷한 설정으로 다음과 같이 Isolation을 변경할 수 있습니다.

mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

모든 것은 Isolation Level이 REPEATABLE READ 이상인 경우 발생하오니, 주의하여 사용하시기 바랍니다.

(설정 자체가 READ COMMITTED에서는 발생하지 않음)

※ 주의사항 ※
커넥션 풀을 사용하는 경우 변경된 세션 값은 해당 커넥션이 재 시작되기 전까지 유지되므로, 반드시 사용 후 원래 설정 값으로 돌려놓아야 합니다.

Conclusion

조금은 어려운 주제일 수 있습니다. 그러나 유독 MySQL에만 국한되는 내용이 아닌, 트랜잭션을 지원하는 DB 사용 시 반드시 알아야할 사항이라고 생각됩니다.

그러나 MySQL 에만 국한되는 내용이 아닐 뿐더러, 대용량 분석 시스템을 구상 중이라면 반드시 알아야할 사항이라고 생각합니다.^^

출처: http://gywn.net/2012/05/mysql-transaction-isolation-level/

OSI 7 Layer

EnterKey — Mon, 7 Nov 2016 17:59:16 +0900

1. OSI 7 Layer

OSI(Open System Interconnection Reference Model)은 국제표준화기구 - ISO -에서 개발한 모델로 컴퓨터 네트워크 소프트웨어의 개발을 돕기 위해서 7계층으로 나누어 정의한 명세서다. 보통 OSI 7 계층이라고 부른다.

컴퓨터 네트워크는 아래로는 물리/전자기 적인 알고리즘과 이들을 이용해서 통신을 하기 위한 물리적인 장비들 그리고 위로는, 컴퓨터 운영체제와 수많은 네트워크 소프트웨어들이 놓이는 전지구적 규모의 광대하고 복잡한 시스템이다. 인터넷 초창기인 ARPNET시절이라면 전체 네트워크 시스템을 이해하는 사람이 있었을 테지만, 지금은 전체 시스템을 이해하고 응용 소프트웨어를 개발할 수 있는 사람은 없다고 장담할 수 있다.

이런 복잡 거대한 시스템을 유지하기 위해서 네트워크 시스템을 7계층으로 나누기로 했다. 이를테면 추상화 한건데, 각 단계의 개발자는 자기가 맡은 단계만 이해하면 되기 때문에 응용 소프트웨어 개발이 매우 쉬워진다. (이론적으로 그렇다는 얘기가, 실제 개발 단계에서는 자기가 맡은 단계 외의 다른 단계에 대해서도 기본적인 이해는 가지고 있어야 한다.)

다음은 OSI의 계층 구조를 보여준다.

흔히 줄여서 L1, L2 ... L7 이라고 부른다.

1.1. 물리 계층

나는 물리 계층에는 관심이 없기 때문에, 다룰 내용이 없다. wikipedia의 내용으로 대신한다.

물리 계층은 실제 장치들을 연결하기 위해 필요한 전기적, 물리적 세부 사항들을 정의한다. 예를 들어, 핀들의 배치나 전압, 전선의 명세 등이 이 계층에 포함된다. 허브나 리피터가 물리 계층의 장치이다. 기계적 구조와 전기적 특성을 규정한다. 물리 계층에서 수행되는 중요한 일들은 다음과 같다.

물리적인 정보 전달 매개체에 대한 연결의 성립 및 종료. 여러 사용자들 간의 통신 자원을 효율적으로 분배하는 데 관여. 예를 들어, 경쟁 상태의 해소나 흐름 제어 등. 통신 채널을 통해 전송되는 사용자 장치의 디지털 데이터를 이에 상응하는 신호들로 변환, 변조. 이 신호들은 구리선이나 광섬유 선을 통해 전달되는 신호들로, 예를 들어, SCSI가 여기에 속한다 네트워크상에서 데이터 비트를 전송하는 계층으로, 데이터 링크 개체간의 비트 전송을 위한 물리적 연결을 설정, 유지, 해제하기 위한 수단을 제공하며, 물리계층에서 데이터를 교환하는 방식은 회선교환, 메시지 교환, 패킷교환 방식이 있다. 전송 매체는 신호 보내는 방법을 정의한다.

1.2. 데이터 링크 계층

데이터 링크 계층은 물리적인 네트워크 장비를 일대일(Point to Point)로 신뢰성 있는 통신을 보장하기 위한 명세를 정의 한다. 네트워크 장비(NIC카드)들이 일대일로 통신을 하기 위해서는 서로의 물리적 이름을 알고 있어야 한다.

NIC는 출시때 MAC Address를 할당하는데, 이 MAC Address를 이용해서 원하는 NIC으로 데이터를 전송할 수 있다.

MAC Address는 단일 계층 주소 체계다. 따라서 L2 계층에서는 모든 NIC을 하나의 네트워크로 묶어야 한다. 하나의 네트워크는 데이터가 브로드캐스팅되는 영역을 의미한다. 예를 주변 네트워크 상황을 확인하기 위해서 ARP브로드캐스팅을 하면, 모든 NIC로 패킷이 전송되는 걸 의미한다. L2에서는 NIC의 개수가 늘어나면 네트워크 전체의 성능이 떨어질 수 있다. 확장에 한계가 있다

L2가 물리적이로 하나의 계층을 가지는 문제를 극복하기 위해서, VLAN기술을 사용해서 논리적으로 네트워크를 나누는 방법이 있다.

1.3. 네트워크 계층

노드와 노드를 연결해서 네트워크를 구성하기 위한 프로토콜이 정의되어 있는 계층이다. 망(네트워크)를 구성하기 위해서는 전체 네트워크에서 노드가 유일해야 한다. 네트워크에서 노드를 식별하기 위해서 사용하는 대표적인 프로토콜이 IP(Internet Protocol)이다.

네트워크 상에서 노드는 유일한 IP 주소를 부여 받고, 이를 통해서 식별할 수 있다. L3에서 제공하는 프로토콜을 이용해서 네트워크 상의 노드는 다른 노드에 데이터를 전송할 수 있다.

MAC Address와 달리 IP Address는 계층 구조를 가진다. 따라서 대규모의 네트워크를 조직적으로 관리할 수 있다.

1.4. 전송 계층

L3 계층은 노드와 노드사이에 데이터를 전송하는 것만 신경쓴다. 노드와 어떤 방식의 연결을 만들 건지에 대해서는 관여하지 않는다.

인터넷은 패킷 스위칭 방식으로 데이터를 전송하며, 경로가 달라질 수 있다. 따라서 패킷은 처음 순서와 다른 순서로 목적지에 도달할 수 있다. 또한 경로를 따라가면서 데이터에 잡음이 생길 수도 있다.

이 경우 연결 방식을 조정해서 패킷의 순서를 재 조합하거나, 잡음이 생겼는지 확인하고, 잡음이 생긴 패킷에 대한 재 전송 요청등의 일을 할 수 있어야 한다. 대표적인 프로토콜이 UDP와 TCP이다.

OSI는 TP0에서 TP4까지 5가지 class의 연결단계를 제공한다.

TP0 : Simple Class, 에러 복구와 같은 어떠한 기능도 제공하지 않는다.
TP1 : Basic error recovery class
TP2 : Multiplexing class
TP3 : Error recovery and multiplexing class
TP4 : error detection and recovery class

Connecection oriented network인 TCP는 위의 모든 클래스를 만족하는 프로토콜이다.

1.5. 세션 계층

세션 계층은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다. 동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex)의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다. 이 계층은 TCP/IP 세션을 만들고 없애는 책임을 진다.

통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다룬다. L4의 TCP의 세션관리 부분과 겹치는데, 보통 소프트웨어 개발자는 세션 계층을 신경쓰지 않는다.

1.6. 표현 계층

유저영역에서 처리해야할 데이터의 형식상의 차이를 대신 처리해준다. MIME 인코딩이나 암호화등에 관련된 동작이 이루어진다. EBCDIC로 인코딩 된 데이터를 ASCII로 바꿔주는 등의 일을 한다.

1.7. 응용 계층

일반적인 응용 소프트웨어들이 사용하는 계층으로, 인터넷 소프트웨어 개발자로서는 가장 많이 신경쓰는 계층이다. 이 계층에는 HTTP, FTP, TELNET, SSH 등의 표준 애플리케이션 프로토콜과 함께, 직접 개발한 프로토콜들이 위치하는 계층이다.

2. 관련문서

Socket API

출처: http://www.joinc.co.kr/w/Site/TCP_IP/OSI7Layer

Java Deep Copy, Shallow Copy

EnterKey — Thu, 3 Nov 2016 11:55:44 +0900

1. Deep copy (깊은 복사)

- 같은 내용의 새로운 객체를 생성, 원본의 변화에 복사본이 영향을 받지 않는다.

2. Shallow copy(얕은 복사)

- 참조변수만 복사, 원본의 변화에 복사본이 영향을 받는다.

import java.util.Arrays;
 
public class CopyTest {
    public static void main(String[] args) {
        int[] data = { 0, 1, 2, 3, 4, 5 };
        int[] sCopy = null;
        int[] dCopy = null;
 
        sCopy = shallowCopy(data);
        dCopy = deepCopy(data);
 
        System.out.println("Original : " + Arrays.toString(data));
        System.out.println("Shallow : " + Arrays.toString(sCopy));
        System.out.println("Deep : " + Arrays.toString(dCopy));
        System.out.println();
 
        data[0] = 5;
        System.out.println("Original : " + Arrays.toString(data));
        System.out.println("Shallow : " + Arrays.toString(sCopy));
        System.out.println("Deep : " + Arrays.toString(dCopy));
        System.out.println();
    } // main
 
    public static int[] shallowCopy(int[] arr) {
        return arr;
    } // shallowCopy
 
    public static int[] deepCopy(int[] arr) {
        if (arr == null)
            return null;
        int[] result = new int[arr.length];
        System.arraycopy(arr, 0, result, 0, arr.length);
        return result;
    } // deepCopy
     
} // CopyTest
 
/*
 * 결과 
 * 
 * Original : [0, 1, 2, 3, 4, 5]
 * Shallow : [0, 1, 2, 3, 4, 5]
 * Deep : [0, 1, 2, 3, 4, 5]
 * 
 * Original : [5, 1, 2, 3, 4, 5]
 * Shallow : [5, 1, 2, 3, 4, 5]
 * Deep : [0, 1, 2, 3, 4, 5]
 */

출처: http://gangzzang.tistory.com/entry/Java-Deep-Copy-Shallow-Copy

Java에서 객체의 초기화 순서

EnterKey — Thu, 3 Nov 2016 11:53:57 +0900

자바는 Static block -> Instance block -> 생성자 순으로 초기화가 된다.

먼저 아래와 같은 코드를 실행해 보자.

public class TestClass {

public static void main (String[] args) {

System.out.println("---------------------------");

Parent father = new Parent("father");

System.out.println("---------------------------");

}

class Parent {

public String myName = "Parent";

static {

System.out.println ("This is first message of Parent class!");

}

public Parent() {

System.out.println (myName + ": This is third message! I'm a default constructor of Parent class!");

}

public Parent(String name) {

myName = name;

System.out.println (myName + ": This is third message! I'm a constructor of Parent class!");

}

{

System.out.println (myName + ": This is second message!");

}

그럼 하기와 같은 결과를 얻을 수 있다.

---------------------------

This is first message of Parent class!

Parent: This is second message!

father: This is third message! I'm a constructor of Parent class!

---------------------------

public class TestClass {

public static void main (String[] args) {

System.out.println("---------------------------");

Parent father = new Parent("father");

Parent mother = new Parent("mother");

System.out.println("---------------------------");

}

class Parent {

public String myName = "Parent";

static {

System.out.println ("This is first message of Parent class!");

}

public Parent() {

System.out.println (myName + ": This is third message! I'm a default constructor of Parent class!");

}

public Parent(String name) {

myName = name;

System.out.println (myName + ": This is third message! I'm a constructor of Parent class!");

}

{

System.out.println (myName + ": This is second message!");

}

위 와 같이 한 줄을 추가하여 실행하면 아래와 같은 결과를 얻을 수 있다.

---------------------------

This is first message of Parent class!

Parent: This is second message!

father: This is third message! I'm a constructor of Parent class!

Parent: This is second message!

mother: This is third message! I'm a constructor of Parent class!

---------------------------

여기서 보면 static { } 으로 둘러 싸인 구문은 객체 생성시 최초 1회만 수행이 되고, 그 뒤에는 수행이 되지 않는 걸 알 수 있다. 그러나 { } 로 둘러싸인 instance block은 객체가 생성 될 때마다 실행 되며 생성자 보다 먼저 생성되는 걸 알 수 있다.

class Child extends Parent {

public String myName = "Child";

static {

System.out.println ("This is first message of Child class!");

}

public Child(String name) {

myName = name;

System.out.println (myName + ": This is third message! I'm a constructor of Child class!");

}

{

System.out.println (this.myName + ": This is second message of Child class!");

}

위 와 같이 Parent class를 상속받는 Child 클래스를 만들고, 아래와 같이 객체를 생성해 보자

public class TestClass {

public static void main (String[] args) {

System.out.println("---------------------------");

Child son = new Child("son");

System.out.println("---------------------------");

}

그럼 하기와 같은 결과가 나온다.

---------------------------

This is first message of Parent class!

This is first message of Child class!

Parent: This is second message!

Parent: This is third message! I'm a default constructor of Parent class!

Child: This is second message of Child class!

son: This is third message! I'm a constructor of Child class!

---------------------------

위 결과를 보면 알 수 있듯이,
부모 클래스의 static block -> 자식 클래스의 static block -> 부모 클래스의 instance block
-> 부모 클래스의 생성자 -> 자식 클래스의 instance block -> 자식클래스의 생성자 순으로 실행 되는 것을 알 수 있다.

마지막으로 아래와 같이 실행을 하면,

public class TestClass {

public static void main (String[] args) {

System.out.println("---------------------------");

Parent father = new Parent("father");

Parent mother = new Parent("mother");

Child son = new Child("son");

System.out.println("---------------------------");

}

하기와 같이 실행 된다. 천천히 살펴보면 앞에서 설명한 내용에서 벗어나지 않는다.

---------------------------

This is first message of Parent class!

Parent: This is second message!

father: This is third message! I'm a constructor of Parent class!

Parent: This is second message!

mother: This is third message! I'm a constructor of Parent class!

This is first message of Child class!

Parent: This is second message!

Parent: This is third message! I'm a default constructor of Parent class!

Child: This is second message of Child class!

son: This is third message! I'm a constructor of Child class!

---------------------------

출처: http://chobocho.tistory.com/2461062