dev-joon.log https://velog.io/ 한줄씩 완성해가는 개발 공부 Mon, 22 Nov 2021 08:58:08 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed Copyright (C) 2019. dev-joon.log. All rights reserved. <![CDATA[토큰과 JWT(JSON Web Token)]]> https://velog.io/@dev-joon/%ED%86%A0%ED%81%B0%EA%B3%BC-JWTJSON-Web-Token https://velog.io/@dev-joon/%ED%86%A0%ED%81%B0%EA%B3%BC-JWTJSON-Web-Token Mon, 22 Nov 2021 08:58:08 GMT 참고 https://jwt.io/ https://velopert.com/2389 https://covenant.tistory.com/201 https://www.youtube.com/watch?v=1QiOXWEbqYQ

이전 포스트 https://velog.io/@dev-joon/%EC%9D%B8%EC%A6%9DAuthentication%EA%B3%BC-%EC%9D%B8%EA%B0%80Authorization 에서는 인증과 인가, 세션과 쿠키와 그 장단점들을 살펴보았다. 이번에는 그 단점들의 Stateless 와 Stateful의 충돌을 없애기 위한 방법인 Token 기반 시스템을 살펴보자.

Token을 이용한 방법

토큰 기반 시스템의 존재이유는 바로 서버의 무상태성(Stateless)를 유지하기 위함이다. 상태정보를 저장하지 않으면, 서버는 클라이언트에서 들어오는 요청만으로 작업을 처리하기에 클라이언트와 서버의 연결고리가 없다. 이는 서버의 확장성(Scalability)를 높이는 효과를 가져온다.

  • 토큰 기반 시스템의 작동 원리
    1. 유저가 ID와 password로 로그인(인증)을 한다.
    2. 서버측에서 해당 유저정보를 조회하여 검증한다.
    3. 검증이 되었다면, 서버측에서 유저에게 signed Token을 발급한다. (signed = normally issued token by signature)
    4. 클라이언트는 전달받은 signed Token을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 HTTP Request Header에 포함하여 서버에 전달한다.
    5. 서버는 토큰을 검증하고, 요청에 응답한다.

장점

무상태성(Stateless)의 유지와 확장성(Scalability) 토큰을 클라이언트측에서 보관하기 때문에 서버의 입장에서는 무상태성을 유지할 수 있으며, 위에서 언급한 것과 같이 서버를 확장하기가 용이해진다. 또한 세션을 만약 서버측에 저장하고 있고, 서버를 여러대로 분산하여 요청을 처리하고 있다면, 세션DB를 따로 만든다던가 아니면 해당 요청을 세션ID가 위치한 서버로만 보낼 수 있도록 하는 등의 설정이 불필요해진다.

보안 사용자 정보를 클라이언트나 서버나 세션DB에 저장하지 않기 때문에 쿠키의 취약점으로 인해 발생하는 보안적인 문제가 사라진다.

Extensibility(확장성) 이 확장성은 Scalability와는 다른 확장성을 의미한다. Scalability는 서버의 확장이지만, Extensibility는 로그인(인증) 정보가 사용되는 분야의 확장을 의미한다. 토큰을 사용한다면, 다른 서비스에서도 한 서비스에서 설정된 권한을 공유할 수 있다. OAuth로 예시를 들자면, 요즘 어플에 회원가입을 할 때 구글이나 카카오계정으로 로그인하기 기능같은 것들이 이에 해당한다고 볼 수 있다.

단점

데이터 증가에 따른 네트워크 부하 모든 요청에 대해 토큰이 전송되므로 토큰에 담기는 정보량에 따라 네트워크 부하가 증가한다. 탈취 토큰 자체에 모든 자체적인 정보를 담고 있기에 JWT가 만료시간 전에 탈취당할 시 서버에서 할 수 있는 조치가 없다. Payload Base64 Encoding Payload 자체가 암호화 된것이 아닌 Base64로 인코딩된 것이기 때문에 중간에 토큰을 탈취하여 디코딩하면 데이터를 볼 수 있다. 따라서 민감한 데이터는 Payload에 넣으면 안된다. Stateless JWT는 상태라는 것이 없기 때문에 한번 만들어지면 임의로 삭제하는 것이 불가능하다. 이를 위해 만료시간은 필수적으로 넣어주어야 한다.

JSON Web Token(JWT)

JWT란?

  • JSON Web Token (JWT) 은 웹표준 (RFC 7519) 으로서 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 (self-contained) 방식으로 정보를 안전성 있게 전달해준다.
  • 수많은 프로그래밍 언어 (C, Java, Python, C++, R, C#, PHP, JavaScript등등)에서 지원된다.
  • JWT Token은 해당 토큰에 대한 기본정보, 전달 할 정보, 그리고 토큰의 검증되었음을 증명하는 signature를 포함하고 있다.
  • HTTP Header에 넣는 방식으로도, URL의 Parameter로도 전달될 수 있기에 손쉽게 전달이 가능하다는 장점이 있다.
  • 단점으로는 해독하기가 굉장히 쉽기 때문에, JWT내에는 민감한 정보(유저 비밀번호등...)을 담으면 안된다.
  • Secret Key로 암호화/복호화하기에 Secret Key 보관에 신경을 써야한다.

JWT의 구성

  • Header(헤더), Payload(내용), Signature(서명)
    • Base64(Header).Base64(Payload).Base64(Signature)
    • .을 구분자로 하여 3가지 문자열로 구성된다.
    • Header와 Payload는 디코딩을 하면 평문으로 해독이 가능하다. 하지만 Signature부분은 복호화할 수 없다.

헤더(Header)

typ: Type of the Token: JWT alg: Hashing Algorithem (ex. HMAC SHA256, RSA) 토큰을 검증할 때 사용되는 Signature 부분에서 알고리즘이 사용된다.

내용(Payload)

  • name/value 쌍으로 이루어져 있으며, 내용(Payload)에 위치한 속성들을 Claim이라고 부른다.
  • 클레임의 종류
    • 등록된(Registered) 클레임
    • 공개(Public) 클레임
    • 비공개(Private) 클레임

Registered Claim

서비스에 필요한 정보가 아닌, 토큰에 대한 정보를 담기 위해 이름이 이미 정해진 클레임이다. Registered Claim의 사용은 모두 선택적으로 할 수 있다. iss: 토큰 발급자 (issuer) sub: 토큰 제목 (subject) aud: 토큰 대상자 (audience) exp: 토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어 있어야 한다. nbf: Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념이다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다. iat: 토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단 할 수 있다.. jti: JWT의 고유 식별자 - 주로 중복적인 처리를 방지하기 위하여 사용되며, 일회용 토큰(Access Token) 등에 사용된다.

Public Claim

사용자 정의 클레임으로 공개용 정보를 위해 사용된다. 충돌 방지를 위해 URI 포맷으로 사용한다.

Private Claim

등록된 클레임도 아니며, 공개 클래임도 아닌 서버와 클라이언트 사이에 임의로 지정한 정보를 저장하기 위해 만들어진 사용자 지정 클레임이다.

Signature(서명)

Header와 Payload는 암호화를 한 것이 아닌, 단순히 JSON 문자열을 base64로 인코딩한 것에 불과하기에 누구나 디코딩을 한다면 헤더와 페이로드의 내용을 볼 수 있다. 따라서 해커가 JWT를 탈취하여 수정한 후 서버로 보내는 등의 경우를 방지하기 위해 있는 것이 바로 Signature부분이다.

서명은 헤더의 (인코딩 값 + 정보의 인코딩 값)에 Secret Key로 Hash를 하여 생성한다.

그리고 이 모든 Header.Payload.Signature을 .중간자로 합쳐주면 JWT가 생성이된다.

Access Token / Refresh Token

Access Token이란

  • 리소스에 직접 접근할 수 있도록 하는 정보만 지닌다.

  • Refresh Token에 비해 짧은 만료 기간을 가진다.

  • 주로 세션에 담아 관리한다.

    Refresh Token

    해커가 토큰을 탈취할 경우, JWT의 토큰 만료시간을 짧게 지정하여 남용을 방지하는 조치를 취할 수 있지만, 이는 본래의 사용자 또한 사용할 수 없게 되는 부작용을 초래한다. 이를 방지하기 위해 만들어진 것이 바로 Refresh Token이라는 개념이다.

  • 새로운 Access Token을 발급하기 위한 정보를 지닌다.

  • 클라이언트가 Access Token이 없거나 만료될 시, Refresh Token을 통해 Auth Server에 요청하여 새로운 Access Token을 발급받을 수 있다.

  • Access Token에 비해 긴 만료 기간을 갖는다.

  • 외부에 노출되지 않도록 DB에서 관리한다.

과정

  1. 유저가 ID와 password를 입력하여 서버에 로그인 인증을 요청한다.
  2. 서버는 유저로부터 받은 정보를 확인 후, 헤더와 페이로드를 서버에 저장된 Secret Key를 지정된 알고리즘으로 돌려서 나온 값을 Access Token(JWT)와 Refresh Token로 발급한다.
  3. 클라이언트는 JWT가 요구된 API를 요청할 때(장바구니 등등) Authorization header에 Access Token을 담아서 요청한다.
  4. 서버는 JWT 토큰의 Signature를 체크하여 이상을 확인한다. 그 후 응답한다.
  5. Access Token의 시간이 만료되면 클라이언트는 Refresh Token을 이용하여 새로운 Access Token을 발급받는다.
]]> <![CDATA[인증(Authentication)과 인가(Authorization)]]> https://velog.io/@dev-joon/%EC%9D%B8%EC%A6%9DAuthentication%EA%B3%BC-%EC%9D%B8%EA%B0%80Authorization https://velog.io/@dev-joon/%EC%9D%B8%EC%A6%9DAuthentication%EA%B3%BC-%EC%9D%B8%EA%B0%80Authorization Mon, 22 Nov 2021 07:55:57 GMT 참고

https://bcho.tistory.com/955 https://interconnection.tistory.com/74 https://cjh5414.github.io/cookie-and-session/ https://velopert.com/2350

로그인 서비스를 구현하려고 애쓰던 와중 쿠키,세션,JWT,OAuth등을 공부하기 전에, 알아야할 기본 지식인 인증과 인가에 대해 먼저 알아보자.

인증(Authentication)

로그인을 예시로 들자면 인증은 userId, password와 같은 정보로 해당 웹 서비스의 회원인지 아닌지를 '입증'하는 과정이다. ** 즉, 식별 가능한 정보들로 서비스에 등록된 유저의 신원을 입증하는 과정이다.** 이는 서비스 뿐만이 아닌 API 또한 마찬가지로, API를 호출하는 대상 (그것이 단말이 되었건, 다른 서버이건, 또는 사용자이던간에)을 확인하는 절차가 필요하다. 이를 API인증이라고 한다.

인가(Authorization)

반면에 인가는 인증을 바탕으로 한다. 어떠한 리소스에 대해 어느 사용자가 그 리소스를 요청(request)했을 때, 해당 사용자가 그 리소스를 사용할 권한이 있는지를 체크하는 과정이다. 따라서 인가란 인증된 사용자에 대한 자원(resource) 접근 권한을 확인하는 작업이다.

인증과 권한 부여(인가)의 방법

인증과 인가는 자원을 적절하고 유효한 사용자에게 전달하거나 공개하기 위한 조치이며, 이를 구현하기 위한 방법은 크게 5가지가 있다. (로그인을 예시로 든다.)

*1. 인증(로그인) 하기 -Request Header를 이용한 방법 2. 인증(로그인) 유지하기 - Browser를 이용한 방법 3. 안전하게 인증하기(로그인) - Server를 이용한 방법 4. 효율적으로 인증하기(로그인) - Token을 이용한 방법 5. 다른 채널을 통해 인증하기(로그인) - OAuth를 이용한 방법 *

배경지식

먼저 위의 5가지 방법들을 살펴보기 전에, 앞서 https://velog.io/@dev-joon/HTTP%EC%99%80-HTTPS HTTP관련 포스트에서 알아보았던 HTTP의 무상태성(stateless) 특성에 대해 알고 넘어가야 한다. 이 위의 5가지 인증과 권한 부여가 애초에 필요한 이유이자 배경이 바로 이 특성이기 때문. HTTP의 무상태성은 비연결성에서 파생된 특성으로, 클라이언트와 서버가 요청과 응답을 한번 마치고 나면, 맺었던 연결을 그 어떠한 기억없이 끊는 특성에서 비롯된 특성이다. 따라서 서버는 같은 클라이언트가 연속으로 요청을 보내도, 같은 클라이언트라는 인식이나 기억이 없이 응답을 보낸다. 이는 로그인과 완전히 상반되는 개념으로, 적어도 '로그인'이라는 기능에 있어서 도움이 되지 않는 특성이다. 따라서 이를 극복하기 위해 도입된 개념들이 바로 인증(Authentication)과 인가(Authorization)이며 그를 구현하기 위한 방법이 바로 위의 5가지 방법이다.

Request Header를 이용한 방법(HTTP Basic Auth)

가장 기본적이고 단순한 형태의 인증 방식으로 사용자 ID와 password를 HTTP Request Header에 Base64 Encoding 형태로 넣어서 인증을 요청하는 방식이다. 이 인코딩은 브라우저가 처리한다. 클라이언트의 브라우저가 Base64를 통해 인코딩형태로 Request Header에 넣어 요청을 하면, 서버에서는 이를 디코딩해서 DB에 접근하여 확인하고 OK를 보내는 형식으로 진행이 된다.

단점

하지만, 이런식으로 인증(로그인)을 하면 몇가지 문제점이 생긴다.

  1. 만약 중간에 해커가 데이터 패킷을 가로채서 이 헤더를 Base64로 디코딩을 한다면 사용자의 ID와 password가 그대로 노출된다. 따라서 이 방식을 사용하려면 네트워크 레벨의 암호화를 사용하는 것이 권장된다. 주로 HTTP의 네트워크 레벨 암호화는 HTTPS 기반의 보안 프로토콜이 이용되며, SSL을 통해 해커들이 중간에 이 네트워크 통신을 감청할 수 없도록 해준다.

  2. 로그인한 상태에서 어떠한 새로운 Request(새로운 글을 쓴다던가, 수정을 한다던가)를 할때마다 매번 인증해야한다.

첫번째 문제점을 해결하기 위해 나온 인증 프로토콜이 Digest access Authentication이라는 프로토콜이다.

Digest access Authentication

참고 : https://en.wikipedia.org/wiki/Digest_access_authentication 좀 복잡하기 때문에 다음에 제대로 살펴보자

두번째 문제점: 매번 인증해야 함에 대한 해결책은 한번 로그인(인증)을 할 경우, 어떠한 방식에 의해 그 사용자에 대한 인증(Authentication)이 유지되면 된다. 그리고 이를 위한 방법이 바로 쿠키이다.

먼저 쿠키가 무엇인지에 대해 알아보자.

쿠키란?

  • 브라우저 로컬 스토리지에 저장되는, Key:Value로 구성되며 String으로 이루어진 작은 데이터 파일이다.
  • 하나당 최대 4KB의 크기로 저장되며, 클라이언트에 300개까지 쿠키저장이 가능하다.
  • 쿠키의 구성 요소:
    • 이름: 각 쿠키의 식별 시 필요한 이름
    • 값: 쿠키의 이름과 관련된 값
    • 유효시간: 쿠키의 유지시간
    • 도메인: 쿠키를 전송할 도메인
    • 경로: 쿠키를 전송할 요청 경로
  • 쿠키의 동작 방식
    1. 클라이언트가 페이지를 Request하면 서버에서 쿠키를 생성한다.
    2. 서버가 응답할 때 쿠키에 저장할 정보를 Response Header의 Set-Cookie로 함께 전달한다.
    3. 브라우저가 종료되더라도 쿠키 만료 기간이 유효하다면 클라이언트에서 보관하고 있는다.
      • 만약 브라우저가 종료도더라도 쿠키를 유지하고 싶다면 Permanant를 이용하면 된다. Permanant는 쿠키 생성 시 Expires나 Max-Age옵션으로 추가하면 이용 가능하다.
      • Expires: 쿠키가 만료될 날짜 지정
      • Max-Age: 현재시간 기준, 얼마나 오래 유지시킬 것인지 지정
    4. 클라이언트가 요청을 할 경우 HTTP Request Header에 Cookie: key=value로 쿠키를 함께 보낸다.

용도

쿠키의 존재로 여러 페이지를 이동하거나 서버에 새로운 요청을 할 때마다 매번 로그인(인증)을 하지 않고 유저 정보를 유지할 수 있다. 대표적인 사용처로는 1. ID 저장, 로그인 상태 유지 2. 광고 7일간 다시 보지 않기 3. 최근 검색 상품 추천 4. 쇼핑몰의 장바구니 기능 등이 있다.

단점

다만 이런 식으로 인증을 하고 유지할 경우, 클라이언트에게 편리함을 제공해주지만, 해커들에게도 매우 편리하게 유저 정보를 제공하게 된다. 해커들이 쿠키만 탈취하면 유저 정보를 쉽게 빼낼 수 있기 때문이다.

Server를 이용한 방법(Session)

이렇듯 서버에 비해 상대적으로 보안적인 부분에서 취약한 클라이언트를 보완하기 위해 Session을 활용하여 서버의 도움을 받는다.

세션이란 무엇인지 알아보자.

세션이란?

  • 쿠키를 기반으로 하지만, 유저 정보를 로컬 스토리지와 브라우저에 저장하는 쿠키와 달리, 세션은 서버에서 관리한다. 따라서 보안적인 측면에서 일반적인 쿠키보다 우수하다.
  • 서버는 클라이언트들을 식별하기 위해 세션 ID를 각각 부여하며 웹 브라우저가 서버에 접속해서 종료할 때까지 인증상태를 유지한다.
  • 접속시간에 제한을 두어 일정 시간동안 응답이 없을 시, 정보가 삭제되도록 설정이 가능하다.
  • 클라이언트가 요청을 보내면, 해당 서버가 클라이언트에게 식별 ID를 부여하는데 이를 세션ID라고 한다.

  • 세션의 동작 방식
    1. 클라이언트가 서버 요청시 세션 ID를 부여받는다.
    2. 해당 세션 ID에 대해 클라이언트는 쿠키로 저장하여 보관하고 있는다. Set-Cookie: SESSIONID==blahblahblah
    3. 클라이언트의 요청 시, 쿠키에 저장된 세션 ID를 같이 전달하여 요청한다.
    4. 서버는 쿠키에 저장된 세션 ID를 전달 받아 해당 ID를 통해 클라이언트 정보를 가져와서 사용하여 요청을 처리후, 클라이언트에게 응답한다.

      단점

  • 여러 서버를 지닌 웹 서비스의 경우, 세션 ID 관리면에서 문제가 생긴다. 세션ID는 각각의 서버에서 개별적으로 관리하는 정보이기에 세션만을 관리하는 세션 스토리지 서버가 따로 필요하다.
    • 유저 정보를 클라이언트가 아닌 서버에서 관리하기에 보안 면에서 뛰어나지만, 사용자가 많아지면 서버 메모리를 많이 차지하여 서버 과부하와 성능 저하의 원인이 될 수 있다. 또한 유저가 너무 많을 경우, 세션 스토리지가 감당을 못하고 터질 수도 있다. 이는 모든 정보를 세션을 활용하여 서버에 저장하는 것이 아닌, 일부 가벼운 정보의 경우 쿠키를 활용하게 되는 이유가 된다.

쿠키와 세션의 차이점

쿠키(Cookie)와 세션(Session)은 목적이 같으며, 동작원리 또한 매우 유사하다. 세션이 쿠키를 기반으로 하기 때문이다. 다만 그 둘의 가장 큰 차이점이라고 한다면, 유저의 정보가 저장되는 위치이다. 쿠키는 브라우저의 로컬 스토리지에 정보를 저장하며, 세션은 서버의 자원을 빌려 서버에 저장한다. 따라서 보안 면에서 세션이 더 우수하며, 요청 속도 면에서는 세션이 서버의 처리를 요하기에 쿠키가 세션보다 우수하다. 만료 시간, 유효 시간의 관점에서 보자면, 쿠키는 파일로 저장되기에 브라우저를 종료해도 계속해서 정보가 남아있을 수 있다. 하지만, 세션은 만료시간을 지정해도 브라우저가 종료되는 즉시 삭제된다.

각각의 문제점

위에서 언급한 5가지 해결책 중, 1,2,3의 세가지 해결책을 통해 사용자의 정보를 각각 브라우저(Cookie), 서버(Session), DB(Session DB)에게 맡겨 인증을 하고 인증을 유지해보았다. 하지만 각각에게는 보안의 문제점, 서버 과부하의 문제점 등 또 다른 문제점들이 발생하였고, 이 세가지 해결책은 서버, 클라이언트, 세션 저장소가 사용자가 정보를 지니고 있다는 점에서 HTTP의 무상태성(Stateless)이라는 기초적인 통신 기반을 상태성(Stateful)으로 바꾸는, 두가지의 패러다임이 충돌하는 현상이 발생한다.

확장성의 문제 여기서 확장이란, 단순하게 서버의 사양을 업그레이드하는 것 뿐이 아닌, 더 많은 트래픽을 감당하기 위해 여러개의 프로세스를 돌린다던가, 여러 대의 서버 컴퓨터를 추가하는 것을 의미한다.

CORS(Cross-Origin Resource Sharing)의 문제 쿠키는 설계상, 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기에 여러 도메인에서 관리하기가 매우 번거롭다.

![](https://images.velog.io/images/dev-joon/post/90537681-9e24-4c8e-9cd8-fd390b236304/image.p 우리는 위에서 왼쪽에 위치한 클라이언트와 오른쪽에 위치한 서버에게 각각 사용자 정보를 맡겨보고, 그에 따르는 문제점이 발생함을 알았다. 그렇다면, 정보의 흐름에 해당하는 화살표에 정보를 맡겨보는 것은 어떨까? 정보의 흐름이란 요청과 응답을 의미한다. 요청과 응답에 사용자의 상태를 담아보는 시도를 해보자. 이는 다음 포스트에서 정리를 해보자.

]]> <![CDATA[SQL(Structured Query Language)]]> https://velog.io/@dev-joon/SQLStructured-Query-Language https://velog.io/@dev-joon/SQLStructured-Query-Language Wed, 27 Oct 2021 17:19:57 GMT 참고

https://velog.io/@ygh7687/SQL-%EB%AC%B8%EB%B2%95-%EC%A0%95%EB%A6%AC MySQL cheatsheat https://devhints.io/mysql

Structured Query Language

: 구조화된 질의 언어 => '질의'. 질문하다라는 뜻으로, 정리하자면 SQL이란 데이터베이스에게 원하는 데이터에 관하여 효과적으로 질문하기 위해 구조화되고 규격화된 '언어'이다. RDBMS(Relational Database Management System)에서 데이터를 관리하기 위해 설계된 언어로, ANSI SQL을 표준으로 지정한다.

특징

  1. SQL은 대소문자를 가리지 않는다.
  2. SQL의 명령은 반드시 세미콜론(;)으로 끝난다.
  3. 고유값은 따옴표("")로 감싸준다.
  4. SQL에서 객체(Object)는 백틱 `` 으로 감싸준다.
  5. 한줄 주석은 문장 앞에 --을 붙여서 사용하며, 여러줄은 /**/로 감싸서 사용한다.
  6. SQL의 문법은 크게 DDL(Data Definition Language), DML(Data Manipulation Language), DCL(Data Control Language)로 나뉜다.

문법

DDL(Data Definition Language, 데이터 정의 언어)

: 테이블이나 관계의 구조를 생성하는데 사용된다.

  • CREATE : 데이터베이스 및 객체 생성
  • ALTER : 기존에 존재하는 데이터베이스 객체 변경
  • DROP : 데이터베이스 및 객체를 제거
  • TRUNCATE
  • RENAME : 데이터베이스 및 객체 이름 변경

DML(Data Manipulation Language, 데이터 조작 언어)

: 데이터를 추가/수정/삭제하기 위한, 데이터 관리를 위한 언어이다. (CRUD를 위한 문법이다.)

  • INSERT : 데이터 입력
  • SELECT : 데이터 선택
  • UPDATE : 기존에 존재하는 데이터 변경
  • DELETE : 데이터 삭제

DCL(Data Control Language, 데이터 제어 언어)

: 사용자 관리 및 사용자 별로 데이터를 관리하고 접근하는 권한을 다루기 위한 언어 (보안을 위한 문법이다.)

  • GRANT : 특정 데이터베이스 객체 소유자가 다른 사용자에게 객체에 대한 접근 권한 범위와 해당 접근 범위 내에서 수행할 수 있는 연산을 지정
  • REVOKE : GRANT로 부여된 일련의 권한을 회수
]]> <![CDATA[DB란?]]> https://velog.io/@dev-joon/DB%EB%9E%80 https://velog.io/@dev-joon/DB%EB%9E%80 Wed, 27 Oct 2021 17:05:23 GMT 참고

DB란? https://noahlogs.tistory.com/36 RDBMS http://tcpschool.com/mysql/mysql_intro_relationalDB 생활코딩DB강의 https://opentutorials.org/course/3161/19531

Data & Information

데이터(data)는 현실의 사건이나 사물의 특징을 관찰하거나 측정하여 기술하는 가공되지 않은 사실이나 값이다. 이는 자료라고 부르기도 한다.

반면 정보(information)은 의미 있고 쓸모 있는 내용으로 가공하여 체계적으로 조직한 데이터를 말한다.

데이터 -> (가공) -> 정보

데이터베이스(DB or Database)란?

실생활에서 데이터들은 다양한 형태로 쓰인다. 대학교에서는 수강 신청과 관련된 학생 데이터들이 있고, 이 학생들의 점수 데이터는 학기말마다 성적으로 가공되어 데이터로 저장된다. 무신사와 같은 쇼핑 어플리케이션에서는 상품 판매자와 구매자, 그리고 상품에 관련된 데이터를 저장하고 이 데이터는 추후 마케팅의 기초 자료로 쓰인다. 이러한 데이터들은 그저 무더기로 쌓여 있지 않으며, 인간이 무언가를 기억하듯이 추상적이고 감각적으로 저장되어 있지 않다. 그렇다면, 우리가 현재 실생활에서 쓰고 있으며, 앞으로 설계를 하더라도 데이터베이스로 기능하기 위해 필요한 '정의'의 모습은 어떨까?

"어떠한 특정한 조직에서 여러 명의 사용자 또는 응용 시스템들이 공유하고, 동시에 접근하여 사용할 수 있도록 구조적으로 통합하여 저장한 운영 데이터의 집합"

조금 복잡하고, 여러가지가 한번에 압축이 되어있으니 한번 풀어서 생각해보자.

  1. 공유 데이터(Shared Data) 데이터베이스의 데이터는 어떠한 하나의 프로그램이나 시스템을 위한 데이터들이 아니다. 그 데이터들이 필요한 조직 내의 사용자나 시스템들, 또는 프로그램들이 데이터의 통합적인 관리를 위해 공동으로 유지하며 이용하기 위한 데이터들이다.

  2. 통합된 데이터(Integrated Data) 데이터베이스는 통합된 데이터의 성질을 띈다. 이 '통합된 데이터'란, 여러 군데에 분산되어 있는 데이터를 통합하여 데이터의 중복을 최소화(minimal redundancy)하기 위한 개념이다. 이러한 데이터의 통합관리는 데이터들의 일관성 유지와 데이터 관리 비용 감소등의 장점이 있다.

데이터베이스의 특징

  1. DB는 질의(Query)에 대해 실시간 처리(real-time processing)으로 응답할 수 있다.
  2. 데이터베이스는 CRUD(Create, Read, Update, Delete)에 의해 지속적으로 변하며(continuous evolution), 그 속에서도 정확한 데이터를 유지할 수 있다.
  3. 여러 사용자가 자신이 원하는 데이터를 동시 공유(concurrent sharing)할 수 있다.
  4. 데이터의 레코드 위치나 주소가 아니라, 원하는 데이터의 내용에 따라 참조(content reference)할 수 있다.

데이터베이스의 본질

CRUD

Create

Read

Update

Delete

이상 위의 네가지야말로 DB의 본질이라 할 수 있다. Database란 결국 의미를 부여한 가치 있는 정보들을 관리하기 위한 논리적/물리적 장치이다. 이 정보들을 관리하기 위해서는 정보를 생성하고, 읽고, 갱신하고 삭제할 수 있는 기능이 필수적이다. 따라서 어떠한 데이터베이스를 사용하던 (MySQL, Postgres MariaDB...)등등 이 4가지 기능은 세부적인 사항은 다를지언정 무조건 구현이 되어 있다. 따라서 나는 이 위의 4가지 기능이 결국 데이터베이스라는 것의 본질이라고 생각한다.

DBMS(DataBase Management System)

기존의 데이터를 관리하던 파일 시스템(file system)의 데이터 종속성과 데이터 중복성 문제를 해결하기 위해 고안된 데이터관리시스템이다. 정의는

사용자 또는 응용 프로그램과 데이터베이스의 사이에 위치하여 데이터베이스를 공유할 수 있도록 관리해 주는 소프트웨어이다.

서버에 저장된 대량의 데이터를 관리하며, 사용자가 원하는 정보를 효과적으로 질의(Query)할 수 있는 기능을 제공한다. 사용자 및 응용 프로그램은 DBMS를 통해서만 DB를 사용할 수 있도록 설계되었으며,

이는 DBMS가 DB의 생성, 접근방법, 처리절차, 보안, 물리적 구조 등에 대한 모든 책임을 지고 있다는 의미이다.

대표적인 DBMS로는 오라클(Oracle), MySQL, MSSQL, MariaDB 등이 있다.

장점

  1. 데이터의 중복(redundancy)를 최소화한다.
  2. 데이터를 공유(sharing)할 수 있다.
  3. 데이터의 일관성(consistency)를 유지할 수 있다.
  4. 데이터의 무결성(integrity)를 유지할 수 있다.
  5. 데이터의 보안(security)를 보장할 수 있다.

단점

  1. DBMS는 파일시스템과는 달리 고가의 제품이며, 운영에 필요한 컴퓨터의 자원도 많이 요구된다.
  2. DB가 사용될 때 다수의 사용자가 동시에 접근하기 때문에 보안적인 부분에 많은 주의를 요구한다.
  3. 구조 또한 복잡하기 때문에 장애가 발생했을 때 명확하게 이유나 상태를 파악하기 어려울 때도 있다.
  4. DB는 한 조직의 모든 데이터를 중앙 집중화하는데 필요한 필수적인 자원이다. 다만 이러한 DB의 장점인 응용의 유용함, 실시간 처리, 다수 사용자의 동시 접근 같은 기능이 필요하지 않는다면, DBMS를 사용하지 않는 것이 더 바람직할 수 있다.

RDBMS(Relational Database Management System)

: 관계형 데이터베이스(Relational Database)를 위한 DBMS이다.

Relational Database

: 키(key)와 값(value)로 이루어진 데이터들을 행(row)과 열(column)으로 구성된 테이블 구조로 단순화 시킨 모델이다.

  • 데이터의 종속성을 관계(Relationship)으로 표현하는 것이 가장 큰 특징이며, 행과 열로 구성된 각 테이블들이 다른 테이블들과 관계를 맺고 모여있는 형태이다.

  • 데이터의 분류, 탐색, 정렬 속도가 빠르다.

  • 오랫동안 사용된 모델인만큼 신뢰성이 높고, 어떠한 상황에서도 데이터의 무결성을 보장해준다.

  • 관계(Relationship)을 기반으로 테이블끼리 서로 참조하는 형태이기에, 한눈에 전부 알아보기에는 불편함이 있다. (참조값들을 더 자세히 보고 싶으면 참조테이블을 다시 펼쳐서 살펴야한다.)

  • SQL(Structured Query Language)를 사용하여 데이터를 관리한다. 다음은 생활코딩 강의에서 나온 간략한 SQL구조이다.

마치며

다음에는 SQL이란 무엇인지 한번 알아보고, 또 Relational Database의 용어들을 한번 정리해보자.

]]> <![CDATA[OSI 7 Layer와 TCP/IP 모델에 대하여]]> https://velog.io/@dev-joon/OSI-7-Layer%EB%A5%BC-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90 https://velog.io/@dev-joon/OSI-7-Layer%EB%A5%BC-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90 Fri, 22 Oct 2021 22:46:49 GMT 참고

Youtube의 우아한Tech 강의 히히 https://www.youtube.com/watch?v=1pfTxp25MA8 블로그 https://snyung.com/content/2020-08-31--네트워크-기초-osi-7-계층과-tcp-ip-계층/ https://velog.io/@hidaehyunlee/데이터가-전달되는-원리-OSI-7계층-모델과-TCPIP-모델 https://server-engineer.tistory.com/582

OSI 7 계층이란

: 네트워크에서 통신이 일어나는 과정을 7단계로 계층화하여 나눈 것을 말한다.

  • 7단계로 나눈 이유. 통신이 일어나는 과정을 단계별로 파악하여 특정한 곳에 이상이 생긴다면, 다른 단계의 장비 또는 소프트웨어를 건들이지 않고 이상이 생긴 단계만 고칠 수 있기 때문이다.

OSI 7 Layer는 다음과 같이 나뉜다.

  • 하지만 OSI 7 Layer Model은 참조 모델일 뿐, 실제 사용되는 인터넷 프로토콜은 이 7계층 구조를 완전히 따르지 않는다. (왜? : OSI 모델이 TCP/IP 모델과의 시장 점유율에서 졌기 때문)
  • 근래의 인터넷 프로토콜 스택(Internet Protocol Stack)은 현재 대부분 TCP/IP 모델을 따르며 이 TCP/IP 모델 또한 한번 업데이트 되어 TCP/IP Updated 모델을 이제 주로 쓴다고 한다.

따라서 이번에 살피는 OSI 7 모델과 TCP/IP 모델은 전부 다 살피는 것이 아닌, 근래에 많이 쓰이는 TCP/IP Updated 모델이다. 5계층 과 6계층의 Session Layer와 Presentation Layer는 Application Layer 하나로 뭉뚱그려 살펴볼 것이다.

1계층: Physical Layer

정의

0과 1로 이루어진 데이터 신호를 아날로그 신호로 바꾸어 전선으로 흘려 보내고(encoding) 아날로그 신호가 들어오면 0과 1의 나열로 해석하여(decoding) 물리적으로 연결된 두 대의 컴퓨터가 0과 1의 나열을 주고받을 수 있게 해주는 모듈(module)이다.

깊게 가보자

  • 모든 파일과 프로그램은 0과 1의 나열로 이루어져 있다. 결국, 두 대의 컴퓨터가 서로 통신한다는 것의 의미는 두 대의 컴퓨터가 0과 1로 이루어진 데이터들을 주고 받는다는 의미이다.
  • 그렇게 되기 위해서는 두 대의 컴퓨터를 물리적인 전선으로 연결할 필요가 있다. 두 대의 컴퓨터를 하나의 전선으로 연결한다고 가정할 때, 0과 1로 이루어진 데이터를 전송하는 방법은 한쪽에서 일정 이상의 전압을 가하면 1, 전압을 가하지 않는다면 0으로 해석하기로 이론상 약속할 수 있다.
  • 이론상의 방식을 따른다면, 이런 방식으로 할 경우 x축이 시간, y축이 전압인, 곡선이 아닌 직선과 직각으로 이루어진 sin함수 비스무리한 형태의 전자기파 그래프처럼 통신을 해야한다.
  • 하지만, 수직선과 수평선으로 이루어진 전자기파는 항상 0~무한대[Hz]의 주파수 범위를 가지기에 물리적으로 이러한 형태의 전기신호를 통과 시킬 수 있는 전선은 없다.
  • 따라서 우리는 실제로 전송을 할 수 있는 형태인 아날로그 형태의 전기신호로 두 대의 컴퓨터를 연결해야 한다.
  • 결론은 정의로 돌아온다.*
  1. 0과 1로 이루어진 디지털 데이터들을 아날로그 형태로 바꾸어 전선으로 흘려 보내고,(encoding)
  2. 전선을 통해 들어온 아날로그 신호를 다시 0과 1로 이루어진 디지털 신호로 해석한다.(decoding)
  3. 따라서 Physical Layer라는 것은, 물리적으로 연결된 두 대의 컴퓨터가 전송하는 아날로그 신호를 디지털 신호로 변환하고/재변환을 해줄 수 있게 해주는 모듈(Module)이다.

어디에 구현이 되어 있는가?

PHY칩 위의 사진처럼 1계층 Physical Layer의 모듈은 사실, 하드웨어적으로 구현되어 있다. 즉, 물리적인 회로인 것이다.

위의 1계층 Physical Layer에서는 두 대의 컴퓨터를 전선 하나로 연결했었다. 하지만 만약에, 단순히 두 대의 컴퓨터가 아닌, 여러대의 컴퓨터를 연결하고자 한다면, 우리는 전세계의 수많은 컴퓨터들을 모두 전선으로 연결해야 할까? 그것은 너무나도 비효율적이기에 우리는 적은 수의 전선으로 여러 대의 컴퓨터와 연결을 할 수 있는, 보다 효율적인 방법을 모색해야 한다. 이를 위해 나온 것이 바로 버스 토폴로지(Bus Topology)와 스타 토폴로지(Star Topology)이다.

버스 토폴로지(Bus Topology)

버스 토폴로지는 모든 컴퓨터가 하나의 전선(Bus)에 연결되어 있으므로, 한 대의 컴퓨터가 전기신호로 데이터를 전송하게 된다면, 의도한 컴퓨터 외에 연결되어 있는 다른 모든 컴퓨터들 또한 데이터를 수신하게 된다.

스타 토폴로지(Star Topology)

스타 토폴로지는 버스 토폴로지의 컴퓨터들이 Bus에 접촉하는 부분들을 모두 모아서 하나의 중계장치에 구겨넣은 것과 같은 구조를 지닌다. 이때 구겨넣은 중앙의 중계기 역할을 하는 기계장치를 허브(Hub)라고 부른다. 허브의 역할은 자신이 수신한 신호를 자신에게 연결되어 있는 모든 컴퓨터들에게 전달하는 것이며, 많은 컴퓨터들에게 전달하기에 신호 강도를 유지하기 위해 신호 증폭을 수행한다. 이때, 연결된 모든 컴퓨터들에게 신호를 전달하는 것이 아닌, 원하는 특정한 컴퓨터에게만 신호를 전달할 수 있도록 허브를 개량한 것이 바로 스위치(Switch)이다. 이렇게 하나의 스위치를 중심으로 여러 대의 컴퓨터들이 연결되어 있는 구조를 네트워크라고 칭하자.

그렇다면, 각각 서로 다른 두 개의 네트워크 상에 위치한 두 대의 컴퓨터가 서로 데이터를 교환하고 싶을 때는 어떻게 하면 좋을까? -> 스위치와 스위치를 연결하여 서로 다른 두 개의 네트워크를 연결한다. 이때 이를 가능하게 하는 장비를 라우터(Router)라고 한다. 이때 보통 스위치(Switch)와 라우터(Router)는 서로 결합되어 있으며, 이를 보통 공유기라고 부른다.

  • 수많은 네트워크들을 연결하기 위해, 라우터와 라우터를 연결하며, 필요할 시 상위에 새로운 라우터를 두어 또다시 라우터와 라우터를 연결하여 전세계의 컴퓨터들이 계층구조로 연결된 거대한 네트워크 그물망이 바로 인터넷이다.

여담으로 국가와 국가간의 장거리 네트워크를 연결하기 위해 지어진 시설들이 바로 해저 케이블 같은 것들이다.

정의

같은 네트워크 상에 있는 여러 대의 컴퓨터들이 데이터를 주고 받기 위해서 필요한 모듈(Module)이다. 이때, Framing은 Data Link Layer에 속하는 작업들 중 하나이다.

깊게 가보자

  • 스위치로 연결되어 있는 하나의 네트워크 내에 속한 한 대의 컴퓨터 A에게 나머지 컴퓨터들이 거의 동시에 데이터를 전송했다고 가정해보자.
  • 그렇다면 그 컴퓨터 A가 받은 데이터는 대략 10101011010101010100101010101...이런 식으로 누가 보낸 데이터인지 구분할 수 없게 마구잡이로 연결되어 있을 것이다.
  • 이렇게 뒤섞인 데이터를 구분할 방법이 필요함을 느끼고, 이를 해결하기 위해 생긴 것이 Framing이라는 작업이다.
  • Framing: 송신자가 자신이 송신하는 데이터의 앞 뒤에 특정한 비트열을 붙이는 작업이다. 수신자는 이 비트열을 다른 데이터들과 구분할 수 있는 구분자로써 이용한다. ex) 0101 0101이라는 데이터를 보낼 때, 앞에는 1111을, 뒤에는 0000을 붙이는 식이다.
  • 이러한 방식으로 인해 컴퓨터 A는 순서를 알 수 없게 뒤섞인 데이터 열을 이제 구분할 수 있게된다.

어디에 구현이 되어 있는가?

랜카드 2계층 Data Link Layer 또한, 1계층처럼 하드웨어적으로 구현되어 있다.

3계층: Network Layer

네트워크 계층은 네트워크에서 아주아주 중요한 계층이다. 수많은 네트워크들의 연결로 이루어지는 inter-network 속에서 목적지로 지정한 컴퓨터로 데이터를 전송하기 위해 IP Address를 이용해서 길을 찾고(Routing) 자신 다음의 라우터에게 데이터를 넘겨주는 것(forwarding)이 바로 Network Layer가 담당하는 기능이다.

주소 부여(IP) / 경로 설정(Routing)

조금만 깊게 가보자

라우팅(Routing) 데이터를 목적지까지 안전하고 빠르게 전달하는 기능을 말한다.

  • 수많은 네트워크들로 복잡하게 얽히고 계층화되어 있는 inter-network 속에서 목적한 컴퓨터를 향해 최소한의 경로와 시간으로 경로를 선택하고 주소를 정하고 그 경로에 따라 패킷을 전달해주는 것이 바로 라우팅이다.
  • 네트워크 계층은 사용되는 프로토콜 종류도 다양하고 라우팅하는 기술도 다양하다. 더 많은 것을 알고 싶지만 굉장히 복잡하고 많은 공부량이 예상되므로 라우팅에 대한 자세한 내용은 다음에 공부해보자.
  • IP(Internet Protocol)* 컴퓨터에게 데이터를 전송할 때는, 해당 컴퓨터의 주소를 알고 있어야 한다. 이때 네트워크 상의 주소(IP Address)를 지정해 주는 것이 IP(Internet Protocol)이다.
  • 데이터 패킷은 목적지의 IP Address가 전송하고자 하는 데이터의 헤더에 붙어있는 형식으로 되어 있다. -> 55.109.xxx|Data
  • 이또한 단순하게 이런 식으로 풀어보았지만, 더 자세히 접근하려면 많은 공부량이 예상되므로 이것도 다음으로 미루어본다. (ㅠㅠ 궁금하다...)

어디에 구현이 되어 있는가?

운영체제의 커널에 소프트웨어적으로 구현되어 있다.

4계층: Transport Layer

정의

Port 번호를 사용하여 IP Address로 명시된 목적지 컴퓨터의 최종 도착지인 프로세스(프로그램)에까지 데이터가 도달하도록 하는 모듈(module)이다.

  • 4계층 Transport Layer은 말그래도 통신을 활성화하기 위한 계층이다. 양 끝단의 사용자들이 신뢰성 있는 데이터를 주고 받게 해주는 역할을 한다.

  • 보통 TCP Protocol을 사용하며, Port를 열어서 원하는 프로세스가 데이터를 전송하고 받을 수 있도록 한다.

  • 대표적인 프로토콜은 TCP와 UDP Protocol이 있다.

  • 패킷 생성시 포트 번호를 데이터에 덧붙인다. ex) IP Address|Port Number| Data

    깊게 가보자.

    1, 2, 3계층을 통해 이제 인터넷 상의 모든 컴퓨터가 서로 데이터를 교환하며 통신할 수 있게 되었다. 그러면 이제 받은 데이터를 활용해보자. 전세계로 부터 받은 데이터를 원하는 프로세스(실행중인 프로그램)에게 주기 위해서는 컴퓨터가 어떤 데이터를 어떤 프로세스에게 주어야 하는지 알고 있어야 한다. -> 이를 위해 만들어진 가상의 관문이 바로 포트 번호(Port Number)이다.

  • 포트란?(Port)

      우리는 IP Address를 통해 원하는 서버(컴퓨터)를 찾아낸다. 포트는 IP Address를 통해 찾아낸 서버 내에서 원하는 프로그램으로 연결해주는 가상의 관문이다. 
  포트 번호(Port Number)는 어떠한 프로세스(프로그램)으로 접속할 것인지 컴퓨터에게 알려주는 역할을 한다.
  ![](https://images.velog.io/images/dev-joon/post/409b8fe6-e984-4e10-8322-2b5370b6b342/image.png)

  • 송신자는 데이터를 보낼 때, 데이터를 받을 수신자 컴퓨터에 있는 프로세스의 포트 번호를 붙여서 보낸다. ex) Port: 80|IP Address|Data

  • 따라서 데이터 전송자는 목적지 프로세스의 포트 번호를 알고 있어야 한다. 하지만 각기 원하는 대로 포트 번호를 마구 지정하는 것을 방지하기 위해, 자주 쓰이는 포트 번호들과 임시로 지정하는 범위가 규격화되어 정해져 있다.

  • 포트 번호 규정

    • Well-known port 0 ~ 1023
      의미 그대로 정말 잘 알려진 포트들을 의미한다. 80번의 http, 22 번의 ssh와 같이 자주 사용되는 포트들에 해당한다.

    • Registered port 1024 ~ 49151 특정 용도로 사용하기 위해서 쓰이는 포트들로, 3306 포트의 mySQL, 80번 port 를 대체하기 위한 8080 포트 (웹서버가 2개 이상인 경우) 등이 있다.

    • Dynamic port 49151 ~ 65535 특별히 지정되지 않은 포트들로 자유롭게 사용해도 무방하다.

      어디에 구현이 되어 있는가?

      3계층과 마찬가지로 운영체제의 커널에 소프트웨어적으로 구현이 되어 있다.

5계층: Session Layer + 6계층 Presentation Layer + 7계층: Application Layer => Application Layer

정의

사용자가 필요로 하는 인터페이스와 프로토콜을 제공하는 계층이다. 5계층 Session Layer와 6계층 Prsentation Layer와 7계층 Application Layer에 있는 기능을 결합한다.

  • 사용자가 네트워크의 서비스를 쉽게 사용할 수 있도록 돕는다.
  • 네트워크 기반 응용 프로그램을 개발하는데 이용된다.
  • 사용자 로그인, 네트워크 장치 이름 지정, 메시지 및 이메일 형식 지정, 파일전송 등과 같은 서비스를 제공한다.

대표적인 프로토콜로는

  • HTTP(HyperText Transfer Protocol): HyperMedia 데이터가 전송되는 방식을 정의한 프로토콜
  • FTP(File Transfer Protocol): 클라이언트와 서버 간에 파일을 전송하기 위한 클라이언트/서버 기반 프로토콜
  • SMPT(Simple Mail Transfer Protocol): 이메일을 보내고 받기 위한 프로토콜
  • DNS(Domain Name System): Domain Name <-> IP Address 간의 변환 프로토콜
  • TELNET: 네트워크를 통해 호스트에 원격 로그인을 위한 프로토콜

그 외

** TCP/IP Socket Programming**

  • OS의 Transport Layer에서 제공하는 API를 활용하여 통신가능한 프로그램을 만드는 것을 TCP/IP Socket Programming, 또는 네트워크 프로그래밍이라고 한다.
  • 소켓 프로그래밍 만으로도 클라이언트, 서버 프로그램을 따로따로 만들어서 동작 시킬 수 있다.
  • TCP/IP Sockt Programming을 통해 누구나 자신만의 Application Layer 인코더와 디코더를 만들 수 있다. -> 누구든 자신만의 Application Layer Protocol을 만들 수 있다.

마치며

소프트웨어 아키텍처(Software Architecture) 중에 Layered 아키텍처라는 것이 있다. 그리고 이 Layered Architecture를 따르는 대표적인 예시가 바로 네트워크 시스템이다. -> 네트워크 시스템은 하나의 거대한 소프트웨어이며 OSI 7 Layer는 이 거대한 소프트웨어의 구조를 설명하는 것이다.

독학을 하는 입장에서 잘 이해가 안가고 큰 그림에서 어떠한 부분을 차지하는지 잘 모르겠었던 부분인 OSI 7 Layer이었다. 그러던 와중 유튜브에서 우아한테크 채널의 히히님이 강의하신 OSI 7 Layer 강의를 되었고 내게 너무나도 큰 도움이 되었다. 강의에서 보았던 것, 그외에 내가 찾았던 것들을 정리하고파 이 글을 작성한다.

히히님 감사합니다!

]]> <![CDATA[URL]]> https://velog.io/@dev-joon/URL https://velog.io/@dev-joon/URL Fri, 22 Oct 2021 13:35:49 GMT URL이란?

Uniform Resource Locator : 웹에서 접근가능한 자원의 주소를 일관되게 표시하는 일련의 규칙이다.

각 URL에는 브라우저가 적절한 서버에 접속하여 원하는 리소스를 요청하기 위해 필요한 정보가 표시되며, 사용자는 브라우저에게 원하는 문서의 URL을 제공하고 브라우저로 하여금 문서를 받아와서 화면에 표시하도록 지시한다.

Protocol or Scheme

http는 프로토콜을 의미한다. URL의 앞부분은 브라우저가 어떠한 프로토콜로 통신을 할 것인지를 나타낸다. 흔히 쓰이는 http외에도 ftp와 같은 다른 프로토콜 또한 사용할 수 있다.

Domain Name

프로토콜 다음으로 오는 부분은 도메인 이름이다. 위 예시에서는 www.example.com이 이에 해당되며, 이는 찾고자 하는 리소스가 위치한 웹서버가 어디에 있는, 어떤 웹서버인지를 명시하기 위함이다. 따라서 도메인 이름 대신에 IP address를 직접 사용하는 것도 가능하지만, 이는 사람이 기억하기에는 복잡하고 길기 때문에 Domain name을 사용한다.

IP 주소와 URL은 엄연히 다르다.

IP 주소는 네트워크에 접속하는 모든 컴퓨터에게 Internet Protocol에 의해 부여된, 네트워크 상의 고유 식별 주소이다. 반면, URL은 브라우저, 즉 클라이언트가 네트워크 상의 특정 리소스에 접근하고자 할 때, 사용하는 일관된(Uniform) 자원의(Resource) 위치(Locator)를 표시하는 일련의 규칙이다. 일반적으로 브라우저 상의 창에 URL대신 IP주소를 입력하여 원하는 웹 사이트로 이동이 가능한 이유는 IP 주소들이 각각 DNS상에서 Domain Name으로 대응되어 치환 입력되기 때문이다.

Port

예시에 나와있는 :80은 포트를 의미한다. 통상적으로 표준 HTTP를 사용하여 접근을 시도한다면, 포트 번호는 생략가능하다.(HTTPS 포함, HTTP: 80번 포트, HTTPS: 443번 포트) 그 외의 프로토콜이라면 포트 번호는 필수적으로 입력해야 한다.

Path

예시에 있는 /path/to/myfile.html은 리소스가 저장되어 있는 웹서버에서의 자원의 경로이다.

Query

?key1=value1&key2=value2는 웹서버에 제공된 추가적인 파라미터이다. 한 쌍의 키/값으로 이루어져 있으며 각각이 쌍은 &로 구분된다. 웹서버는 클라이언트가 요청한 리소스를 반환하기 전에 이 파라미터들을 이용해서 추가 작업(검색 등등)을 할 수 있다.

]]> <![CDATA[HTTP Status Code와 Request Method와의 접목]]> https://velog.io/@dev-joon/HTTP-Status-Code-%EC%A0%95%EB%A6%AC https://velog.io/@dev-joon/HTTP-Status-Code-%EC%A0%95%EB%A6%AC Fri, 22 Oct 2021 12:22:23 GMT 참고

https://developer.mozilla.org/ko/docs/Web/HTTP/Status https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

HTTP Status Code

서버는 클라이언트와 HTTP로 데이터를 주고 받을 때, 응답 헤더에 상태코드(Status Code)를 같이 보낸다. 이 HTTPS Status Code는 특정한 HTTP요청이 성공적으로 수행되고 완료되었는지를 클라이언트에게 알려준다.

HTTP Status Code는 HTTP 표준으로 정의되어 있어, 각기 다른 브라우저나 서버단에서도 항상 동일한 형식과 의미를 지닌다.

응답은 3자리 숫자로 이루어져 있으며, 맨 앞자리 숫자 1~5에 따라서 각각 정보(Informational), 성공(Successful), 리다이렉트(Redirection), 클라이언트 에러(Client Error), 서버 에러(Server Error)로 응답코드의 그룹이 나뉘어진다.

1xx(정보)

: 요청을 받았으며 프로세스를 계속 진행합니다.

  • 100: Continue

    • 클라이언트가 어떤 것을 요청했을 때 아직까지는 요청이 상태가 괜찮다는 것을 알려준다.

  • 102: Processing

    • 서버가 요청을 수신하였고, 처리중이므로 아직 제대로 된 응답을 줄 수 없음을 나타낸다.

      2xx(성공)

  • : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.*

  • 200: OK

    • 요청이 성공적으로 완료되었음을 알린다. 성공의 의미는 HTTP 메소드에 따라 달라진다.

  • 201: Created

    • 요청이 성공적이었으며, 그 결과로 새로운 리소스가 생성되었음을 알려준다.

  • 204: No Content

    • 요청을 문제없이 처리했지만, 클라이언트가 요청한 데이터가 없음을 알려준다.

      3xx(리다이렉션)

  • : 요청 완료를 위해 추가 작업 조치가 필요합니다.*

  • 301: Moved Permanently

    • 클라이언트가 요청한 리소스는 다른 곳으로 이전하였으니 다른 URL을 이용하도록 Redirect.

  • 302: Found

    • 클라이언트가 요청한 리소스는 임시로 다른 곳으로 이전하였음을 알린다.

  • 303: See Other

    • 302와 유사하지만, 오직 GET 요청에서만 사용할 수 있는 응답 코드.

  • 307: Temporary Redirect

    • 임시적인 리다이렉트. 302 Found와 동일한 의미이지만 사용자 에이전트가 사용된 HTTP 메소드를 변경하지 말아야한다. 예를 들면 POST로 첫 요청이 전송되었다면, 그 다음 요청도 POST여야 한다.

  • 308: Permanent Redirect

    • 영구적인 리다이렉트. 301 Moved Permanently와 동일한 의미를 지니며, 307 Temporary Redirect와 마찬가지로 클라이언트가 이전 메소드와 동일한 메소드를 사용해야 한다.

      4xx(클라이언트 오류)

  • : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.*

  • 400: Bad Request

    • 클라이언트측의 잘못된 문법(query 혹은 API)으로 인해 서버가 요청을 이해할 수 없음을 나타낸다.

  • 401: Unauthorized

    • 비록 HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미한다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 한다.
    • 대표적인 예시로 회원제인 사이트에서 로그인을 하지 않고, 로그인이 필요한 리소스에 접속을 요청할 때를 들 수 있다.

  • 403: Forbidden

    • 클라이언트가 요청한 리소스에 접근할 권한이 없음을 나타낸다. 401 Unauthorized와 다른 점은, 서버는 클라이언트가 누구인지 알고 있다는 점이다.
    • 인증된 사용자이다. 예시로 회원제 사이트에서 로그인을 했음에도 권한이 주어지지 않은 리소스에 접근을 요청할 때이다.

  • 404: Not Found

    • 웹에서 가장 자주 보이기에 가장 유명한 코드이다. 클라이언트가 요청한 리소스를 서버가 찾을 수 없음을 나타낸다.
    • 브라우저에서는 알려지지 않은 URL을 의미한다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있으며, 또 서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있다.

  • 405: Method Not Allowed

    • 해당 URL에 한해서, 쓰거나 삭제하는 기능이 허용되지 않음을 나타낸다.

  • 409: Conflict

    • 클라이언트가 만들고자 하는 리소스가 이미 존재하거나, 충돌이 날 때 사용한다.

      5xx(서버 오류)

  • : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.*

  • 최대한 피해야하는 오류이다.

  • 500: Internal Server Eror

    • 서버 내부에서 어떠한 문제가 발생해서 해당 요청을 처리할 수 없을 때 사용된다.

  • 502: Bad Gateway

    • 중간에 있는 서버가 클라이언트의 요청을 받아 처리해야할 때, 어떻게 처리하는지 모를 때를 나타낸다.

  • 503: Service Unavailable

    • 서버가 아직 준비가 되지 않았을 때, 이 URL의 특정한 요청을 처리할 준비가 되지 않았을 때를 나타낸다.
    • 주 원인은 보통 유지보수를 위해 작동을 중단하거나, 서버에 과부하가 걸렸을 때이다.

Request Methods

GET : get POST : create PUT : replace DELETE : delete PATCH : replace partially HEAD : get without body (get header only) OPTIONS : all supported methods for URL TRACE : echoes the received request

분류

  • 서버에 있는 데이터를 읽기만 하고, 변경하지 않는 Method
    • GET, HEAD, OPTIONS, TRACE
    • 수많은 사용자가 요청을 해도 데이터는 변경되지 않는다.
  • 서버에 있는 데이터를 쓰고, 변경하는 Method
    • POST, PUT, DELETE, PATCH
    • 데이터가 변경되기에 메소드 처리에 대해 조심해야 할듯 하다.

MDN 사이트에서 Request Method 페이지의 아무 메소드나 선택해서 들어가보면 해당 표가 나온다. 이 테이블에서 Safe와 Idempotent에 대해 살펴보자면,

Safe

MDN의 해석을 보자

An HTTP method is safe if it doesn't alter the state of the server. In other words, a method is safe if it leads to a read-only operation. Several common HTTP methods are safe: GET, HEAD, or OPTIONS. All safe methods are also idempotent, but not all idempotent methods are safe. For example, PUT and DELETE are both idempotent but unsafe.

메소드가 서버의 상태를 변경하지 않으면, 그 메소드는 Safe하다고 한다. 그러니까, Request Method가 서버의 데이터를 변경하지 않는, 읽기 전용 상태를 유지하게 한다면, 그 메소드는 Safe하다는 것이다.

GET, HEAD, OPTION이 대표적인 Safe 메소드이다.

모든 Safe 메소드는 Idempotent하지만, 모든 Idempoent한 메소드는 Safe하지 않다고 한다.

Idempotent

한국어로 번역하면 멱등의, 멱등원이다. (뭔소리여?) 그냥 MDN 사이트에 나온 영어로 알아보자.

An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state. In other words, an idempotent method should not have any side-effects (except for keeping statistics). Implemented correctly, the GET, HEAD, PUT, and DELETE methods are idempotent, but not the POST method. All safe methods are also idempotent.

이를 해석해보자면, 동일한 요청을 여러번 했을 때, 몇번을 해도, 얼마나 빠르게 하였던 상관없이 서버에게 항상 같은 효과를 지니고, 서버의 상태 또한 동일하게 남을 때 Idempotent하다고 표현한다.

대표적인 Idempotent한 메소드가 GET, HEAD, PUT, DELETE이며, Idempotent 하지 않은 메소드는 대표적으로 Patch, POST가 있다. 그 차이는 요청의 횟수와 상관없이 항상 같은 효과를 지니느냐, 아니느냐, 서버의 상태가 변하느냐, 변하지 않느냐이다.

GET

Status Code

200 : OK | 데이터를 찾았고 보내줄게 401 : Unauthorized | 인증된 사람만(로그인한 사람) 볼 수 있어 403 : Forbidden | 인증되었지만(로그인 했지만) 너는 권한이 없어 404 : Not Found | 요청한 데이터가 없어 405 : Method Not Allowed | GET 메소드는 허용되지 않았어

POST

Status Code

201 : Created | 요청한 것을 만들었어 401 : Unauthorized | 인증된 사람만(로그인한 사람) 볼 수 있어 403 : Forbidden | 인증되었지만(로그인 했지만) 너는 권한이 없어 404 : Not Found | 요청한 경로가 존재하지 않아 409 : Conflict | 만드려고 하는 리소스가 이미 있어서 충돌이 일어났어

PUT, DELETE, PATCH

Status Code

200 : OK 204 : No Content | 콘텐츠가 없어 403 : Forbidden | 인증되었지만(로그인 했지만) 너는 권한이 없어 404 : Not Found | 405 : Method Not Allowed | 해당 메소드는 허용되지 않았어

HEAD, OPTIONS, TRACE

200 : OK 401 : Unauthorized | 인증된 사람만(로그인한 사람) 볼 수 있어 403 : Forbidden | 인증되었지만(로그인 했지만) 너는 권한이 없어 404 : Not Found | 요청한 경로가 존재하지 않아 405 : Method Not Allowed | 해당 메소드는 허용되지 않았어

]]> <![CDATA[HTTP]]> https://velog.io/@dev-joon/HTTP%EC%99%80-HTTPS https://velog.io/@dev-joon/HTTP%EC%99%80-HTTPS Fri, 22 Oct 2021 07:15:31 GMT HTTP란?

먼저 위키피디아에서 제공하는 HTTP의 정의를 살펴보자. https://ko.wikipedia.org/wiki/HTTP

HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는 W3 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다. 주로 TCP를 사용하고 HTTP/3 부터는 UDP를 사용하며, 80번 포트를 사용한다.

이 정의를 나름대로 요약해보면, HyperText Transfer Protocol의 준말로 인터넷 상에서 데이터를 주고 받기 위한 프로토콜(규약, 약속)이다.

본래 네트워크상에서 교환하는 데이터는 주로 한 문서와 다른 문서를 연결하는 하이퍼링크를 포함하는 텍스트 문서의 형식이었는데, 이것의 이름이 HyperText이다. 다만 '주로' 교환하는 데이터 형식이 HTML같은 HyperText였을 뿐, 이론상으로는 JSON, mp4, mp3, 등등 모든 종류의 데이터를 교환할 수 있기 때문에, 기술이 발달하고 예전처럼 데이터 형식으로 문서만을 사용하지는 않는 요즘, 오늘날의 HTTP의 HyperText는 HyperMedia로 해석하는 것이 나을 듯 싶다.

특징

  1. OSI 7 계층 중, Application Layer 계층의 프로토콜로 주로 TCP/IP 위에서 작동한다.

  2. 서버/클라이언트 모델이다

    • HTTP는 클라이언트가 서버에 요청을 하고, 서버는 그에 응답하는 단방향 모델이다.
    • 클라이언트의 요청에 대한 서버의 응답은 요청 처리 결과에 따라 각기 다른 응답코드로 나뉜다. 따라서 응답코드 별로 처리 로직을 짜서 각 상황에 대응할 수 있다.

  3. 전송되는 데이터들을 암/복호화 하지 않기 때문에 보안이 취약하다 -> 제 3자가 데이터를 엿볼 가능성이 있다. 이를 보안하기 위한 것이 바로 HTTPS이다.

  4. 간단하다.

  • 초반 HTTP/1의 경우, 사람이 읽어도 이해가 가능할 정도로 간단하게 고안되었다. HTTP/2에서 binary 코드가 더해짐에 따라 더 복잡해지기는 했지만, 캡슐화를 통해 간결함을 유지하였다.
  1. 확장가능하다.
  • 클라이언트와 서버가 새로운 헤더의 시멘틱(semantic)에 대하여 합의만 한다면, 얼마든지 새로운 기능을 추가하여 확장하는 것이 어렵지 않다.
  1. 비연결성(Connectionless)
  • 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말한다.
  • 장점
    • HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었는데, 만약 서버에서 다수의 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 된다. 따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있다.
    • ⇒ 접속 유지를 최소한으로 하되, 더 많은 유저의 요청을 처리할 수 있다.
  • 단점
    • 서버는 클라이언트를 기억하지 못하므로 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결 시도/해제의 과정을 거쳐야한다.
    • ⇒ 연결/해제에 대한 오버헤드(어떤 처리를 하기 위해 들어가는 간접적인 처리시간/메모리)가 발생한다.
    • KeepAlive
      • Connectionless의 단점(연결/해제 오버헤드)을 해결하기 위해 일시적으로 연결을 유지할 수 있는 옵션
  1. 무상태성(Stateless)
  • Connectionless로 인해 파생된 특징. 연결이 끊어짐에 따라 서버는 클라이언트를 식별하지 못한다.
  • 서버는 클라이언트의 상태를 저장하지 않는다. → 클라이언트가 이전에 했던 요청과 그 다음 요청은 아무런 연관이 없다. 즉, 서버의 응답은 연속된 요청에 대해 각각 독립적으로 반응한다.
  • 장점
    • 서버 확장에 대한 부담이 적다 → 서버가 많아질수록 서버 간에 정보를 공유하기 위한 비용이 비싸지기에 Stateless하게 사용하면 정보 공유를 위한 비용(시간, 메모리)등을 절약할 수 있다.
    • 어느 서버가 요청을 받아도 응답이 빠르게 가능하다.
  • 단점

↔

  • Stateful
    • 서버가 클라이언트의 상태를 저장하는 것을 Stateful이라고 한다.

흐름(Flow)

다음은 MDN사이트에 나와있는 HTTP의 흐름이다.

  1. TCP연결을 연다.

  2. HTTP 메시지를 전송한다.

     ```
 GET / HTTP/1.1
 Host: developer.mozilla.org
 Accept-Language: fr
 ```

  3. 서버에 의해 전송된 응답을 읽는다.

     ```
 HTTP/1.1 200 OK
 Date: Sat, 09 Oct 2010 14:28:02 GMT
 Server: Apache
 Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
 ETag: "51142bc1-7449-479b075b2891b"
 Accept-Ranges: bytes
 Content-Length: 29769
 Content-Type: text/html

 <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
 ```

  4. 연결을 닫거나 다른 요청들을 위해 재사용한다.

HTTP 메세지

  1. 시작 줄(start-line)에는 실행되어야 할 요청, 또은 요청 수행에 대한 성공 또는 실패가 기록되어 있다. 이 줄은 항상 한 줄로 끝난다.
  2. 옵션으로 HTTP 헤더 세트가 들어간다. 여기에는 요청에 대한 설명, 혹은 메시지 본문에 대한 설명이 들어간다.
  3. 요청에 대한 모든 메타 정보가 전송되었음을 알리는 빈 줄(blank line)이 삽입된다.
  4. 요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어간다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시된다.

    요청(Request)

    시작줄(Start line)

  5. HTTP Method HTTP 요청 메서드 - HTTP | MDN
  • GET : 정보를 요청하기 위해서 사용한다. (SELECT)
  • POST : 정보를 밀어넣기 위해서 사용한다. (INSERT)
  • PUT : 정보를 업데이트하기 위해서 사용한다. (UPDATE)
  • DELETE : 정보를 삭제하기 위해서 사용한다. (DELETE)
  • HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.
  • OPTIONS : 웹서버가 지원하는 메서드의 종류를 요청한다.
  • TRACE : 클라이언트의 요청을 그대로 반환한다. 예컨데 echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다.
  1. 요청 타겟. 이는 URL, 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수도 있으며 요청 타겟 포맷은 HTTP 메소드에 따라 달라진다.
  • origin 형식: 끝에 '?'와 쿼리 문자열이 붙는 절대 경로이다. 이는 가장 일반적인 형식이며, GET, POST, HEAD, OPTIONS 메서드와 함께 사용한다.
    POST / HTTP 1.1
    GET /background.png HTTP/1.0
    HEAD /test.html?query=alibaba HTTP/1.1
    OPTIONS /anypage.html HTTP/1.0
  • absolute 형식: 완전한 URL 형식이다. 프록시에 연결하는 경우 대부분 GET과 함께 사용된다.
    GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
  • authority 형식: 도메인 이름 및 옵션 포트(':')로 이루어진 URL의 authority component 이다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용할 수 있다.
    CONNECT developer.mozilla.org:80 HTTP/1.1
  • asterisk 형식: OPTIONS와 함께 별표('*') 하나로 간단하게 서버 전체를 나타낸다.  OPTIONS * HTTP/1.1
  1. HTTP version HTTP/1.0

헤더

HTTP 헤더 - HTTP | MDN

  • General Header(공통 헤더) 요청 및 응답의 메시지 모두에서 사용되지만 컨텐츠에는 적용되지 않는 헤더
  • Request Header(요청 헤더) HTTP 요청에서 사용되지만 메시지의 컨텐츠와 관련이 없는 HTTP 헤더 보통 Fetch될 리소스나 클라이언트 자체에 대한 정보를 포함하여 서버로 보내진다.
  • Entity Header(엔티티 헤더) 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.

본문

요청의 마지막 부분에 들어가며, 모든 요청에 본문이 들어가지는 않는다.

응답(Response)

상태줄(Status line)

  1. 프로토콜 버전: 보통 HTTP/1.1 이다
  2. 상태 코드: 요청의 성공 여부를 나타낸다. 200, 404 혹은 302 이다.
  3. 상태 텍스트: 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메시지를 이해할 때 도움이 된다.

예) HTTP/1.1 404 Not Found.

헤더(Header)

요청부분의 헤더와 매우 유사하다.

본문(body)

본문은 응답의 마지막 부분에 들어가며, 모든 응답에 본문이 들어가지는 않는다. 201, 204과 같은 상태 코드를 가진 응답에는 보통 본문이 없다.

]]> <![CDATA[가상 머신에 실행 환경 구축]]> https://velog.io/@dev-joon/%EA%B0%80%EC%83%81-%EB%A8%B8%EC%8B%A0%EC%97%90-%EC%8B%A4%ED%96%89-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95 https://velog.io/@dev-joon/%EA%B0%80%EC%83%81-%EB%A8%B8%EC%8B%A0%EC%97%90-%EC%8B%A4%ED%96%89-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95 Sun, 17 Oct 2021 11:55:03 GMT 주요 학습 내용
  • 가상 머신 위에 개발 환경을 구축하는 방법

    주요 도구와 라이브러리

  • Vagrant/VirtualBox
  • CentOS
  • Node.js
  • git
  • nvm

    가상 머신에 구축하는 이유

  1. 가상환경에서는 다양한 실험을 해볼 수 있고, 문제가 생겨도 쉽게 복구할 수 있다.
  2. 어떠한 무리한 프로그램을 실행 시켜도 호스트 머신 환경에 영향을 미치지 않는다.
    오늘 개발 환경 구축 과정은 상당히 간단하다. VirtualBox(가상환경) 위에 리눅스 RedHat Linux계열 OS인 CentOS를 설치해본다. 다만 OS 설치는 CLI로 논리적인 가상 하드웨어 머신을 생성하고 가상머신에 OS를 설치하고 하는 등, 이러한 작업을 일일이 한다면 매우 귀찮고 시간이 오래 걸리는 작업이기에 나는 Vagrant라는 도구를 이용하여 한번에 설치를 해보려 한다. > - Vagrant : 간소화되고 Template화된 Virtual Machine 관리 서비스라고 볼 수 있다. 설치하고자 하는 운영체제들과 더불어 각각 적절하게 가상화된 하드웨어들을 분배해주고 이를 하나의 Template으로 고정하여 명령 하나로 정해진 머신 이미지를 내려받을 수 있는 서비스이다. https://www.vagrantup.com/를 통해 Vagrant를 다운 받을 수 있으며, https://app.vagrantup.com/boxes/search에서 템플릿화된 Vagrant Boxes들을 확인할 수 있다. ### 과정 #### 1. VirtualBox와 Vagrant를 설치한다. #### 2. Virtual Machine 추가
  3. 터미널을 통해 VM을 생성하고 싶은 폴더로 이동한다. 필자의 경우에는 바탕화면에 따로 폴더를 생성하여 관리하고 싶어 바탕화면에 webCrawler라는 디렉토리를 만들어 이동했다.
  4. 터미널에 다음 명령어를 입력하면 현재 위치한 디렉토리에 Vagrantfile이 생성된다.
  5. vi 에디터로 Vagrantfile을 편집한다. 이 편집은 Vagrant Cloud로부터 자동으로 CentOS Box 파일을 내려받도록 한다.

    3. VM 기동

    VM을 기동하고 상태를 확인한다. 또한 ssh 명령어를 통해 로그인을 시도해본다. 관련 명령어들은 다음과 같다.
    Command Description
    vagrant up VM 시동
    vagrant halt VM 정지
    vagrant suspend VM 휴면
    vagrant resume VM 휴면 취소
    vagrant reload VM 재시동
    vagrant status VM 상태 확인
    vagrant destroy VM 삭제
    vagrant ssh ssh로 VM에 로그인
    #### 4. Node.js 설치
    자바스크립트 언어를 사용하기로 했기에 이를 실행하기 위한 런타임 환경인 Node.js 자바스크립트 엔진을 설치한다.

nvm 설치 -> Shell 재시작 -> 재접속 후 로그인하여 Node.js 0.12.4 version 설치

자세한 사항은 간단하기에 생략한다.

5. git 설치

오픈 소스 코드를 로컬에 받을 수 있고 손쉬운 버전관리를 위해 git도 설치한다.

sudo yum install git

6. Host Machine에서 VM 웹서버에 접근하기 위한 설정

VM은 Host Machine의 하드웨어를 분배받아 존재하는 독립적인 서버이다. 기본적으로는 Host Machine에서 접근할 수 없기에 접근 가능하도록 설정을 해준다. 이는 Vagrant의 configuration 파일은 Vagrantfile을 수정하여 실현한다.

config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.network "private_network", ip: "192.168.33.10"

첫번째 수정으로 VM의 웹 서버의 80번 포트가 호스트 머신의 8080포트에 할당된다. 두번째 수정으로 VM의 IP주소가 이에 할당된다.

7. Host Machine과 VM간의 폴더 공유

Host Machine에서 VM에 접근가능하게 설정을 했으니 두 컴퓨터가 서로 폴더를 공유할 수도 있다. 공유 설정을 마치고 VM을 reload한다. 자세한 사항은 간단하기에 생략한다.

8. Node.js 모듈 설치

Node.js의 모듈을 사용하기 위해선 npm(node package manager)를 이용한다. npm은 Node.js로 만들어진 모듈을 웹에서 받아서 설치하고 관리해주는 프로그램이다. 개발자는 필요한 모듈을 직접 만들어 사용할 수도 있지만, 항상 모든 것을 직접 만드는 것보단 훨씬 똑똑하고 잘하는 다른 개발자들이 만들고 인정한 well-made 모듈을 사용하는 것이 더 효율적이다. 이를 위한 프로그램이 npm이다. 공식 문서에 담긴 명령어를 이용해 npm을 활용한다. https://docs.npmjs.com/ https://www.npmjs.com/

마무리

기본적으로 가상머신에서 개발을 하기 위한 밑바탕을 완성했다. Vagrant와 Virtual Box를 통해 CentOS를 손쉽게 설치하였고, 개발과 공부에 필요한 Node.js, git을 설치하였다. 또한 Host Machine에서 개발하고 VM에서 실행하기 위해 Host Machine에서 VM에 접근할 수 있도록 포트포워딩 설정을 마쳤고, 두 컴퓨터 간의 폴더 공유를 위한 설정도 끝마쳤다. Node.js의 수많은 모듈들을 이용하기 위한 npm(node package manager) 활용도 알아보았다. 개발 환경을 다 갖추었으니, 다음 포스팅에서는 웹에 있는 데이터를 다운받을 수 있는 프로그램을 작성해볼 것이다.

]]> <![CDATA[JavaScript와 Node.js를 이용한 웹 크롤링 공부 시작]]> https://velog.io/@dev-joon/JavaScript%EC%99%80-Node.js%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%9B%B9-%ED%81%AC%EB%A1%A4%EB%A7%81-%EA%B3%B5%EB%B6%80-%EC%8B%9C%EC%9E%91 https://velog.io/@dev-joon/JavaScript%EC%99%80-Node.js%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%9B%B9-%ED%81%AC%EB%A1%A4%EB%A7%81-%EA%B3%B5%EB%B6%80-%EC%8B%9C%EC%9E%91 Sun, 17 Oct 2021 10:55:54 GMT 웹 크롤링 공부의 동기

언어인지학을 전공하시는 어머니께서 웹에서 원하는 단어들을 추출하고 분석할 수 있는 웹 크롤링 프로그램이 필요하다며 도움을 요청하셨다. 안그래도 근래 JavaScript를 공부하는 중이었기에 그동안 배운 JavaScript와 Node.js를 응용해보고, 추가로 데이터 분석 또한 간단하게 맛보고 싶어 JavaScript와 Node.js를 이용해서 이 프로그램을 한번 만들어보고자 한다.
나의 공부법의 근간은 주로 책이다. 이 주제와 알맞는 서적들을 찾다가 "자바스크립트와 Node.js를 이용한 웹 크롤링 테크닉, 쿠지라 히코우즈쿠에 저/이동규 옮김"이라는 책을 찾았고 이 서적을 참고하여 내 첫 사이트 프로젝트를 공부하며 이 과정을 이 블로그에 기록하려 한다.
PS. 혹시나, 혹여나, 정말로 혹시나 나중에라도 누군가 이 포스트를 보게 된다면 나의 험난한 여정은 참고만 하고 책을 구매하여 공부하시는 것을 추천한다. 왜냐하면 나의 여정의 전부가 아닌, 기록으로 남겼으면 하는 내가 보기에 공부가 되었던 내용을 기록할 것이기 때문이다. 책 표지는 아래와 같다.

왜 JavaScript인가?

개인적인 이유로는 필자가 근래 관심을 갖고 공부하는 언어가 JavaScript이기 때문이다. 하지만 이 책의 저자가 말하는 이유는 아래와 같다. 1. 배우기 쉽다 자바스크립트의 기본적인 문법은 매우 간단하기에 배우기 쉽다. 2. 다양한 라이브러리가 준비되어 있다. 다양한 자바스크립트 실행 엔진들이 존재하며(V8등등) 이를 통해 다양한 라이브러리를 사용할 수 있는 환경이 형성되고 있다. 특히나 Node.js같은 경우, 이를 위한 수많은 라이브러리가 있고 그 라이브러리들을 패키지 매니저인 npm(node package manager)를 통해 쉽게 설치하고 관리할 수 있다. 3. 유연성이 높아 코드를 빠르게 작성할 수 있다. 자바스크립트는 언어의 유연성이 매우 높은 것으로 정평이 나 있다. 프로토타입 기반의 객체 지향적인 코드를 작성할 수 있으며, Node.js의 경우는 기능을 모듈 단위로 효율적으로 관리할 수 있다.
그러면 다음 포스팅부터 개발 환경 구축을 시작으로 공부를 시작해보자!

]]>