이 사진에서 보이듯 Keys들이 보이지? John Smith, Lisa Smith, Sam Doe 글자 수가 제멋대로(가변)인 이름(Keys)들이 해시 함수를 거치고 나면, 고정되고, 유일한 숫자(해시 값)으로 반환되게 돼.
이 알고리즘의 장점은 무슨 값들을 해시 함수에 넣든, 고정된 길이에 중복되지 않는 값들을 가져올 수 있다는 점이야. 만약 네가 비밀번호를 키 값을 해시 값으로 바꾸어 가지고 있다면, 다른 그 누구도 너의 원래 비밀번호를 알 수 없어. 단 하나의 비트 값만 달라져도, 해시 값의 대부분이 바뀔 수 있거든. 이러한 비밀스러움 덕분에 비밀 번호가 맞는 지 확인할 때와 같이 보안, 로그인 등에 주로 사용돼.
물론 뚫릴 가능성도 없지는 않아. 복권 1등에 당첨되는 확률이 우스울 정도로 아주 아주 아주 작은 확률로 말이야. 지금 소개할 SHA1은 그래. 이 SHA1은 다른 SHA들보다 유명해서, TLS, SSL, PGP, SSH, IPSec과 같이 많은 보안 프로토콜과 프로그램에서 사용되었어. 하지만 이 친구는 지금도 보기 드물고, 앞으로도 보기 드물꺼야. 해시 충돌이 발견되어, 사라져가고 있어. 해시 충돌이란 각 각의 키 값에서 동일한 해시 값이 나오는 것을 말해 .
이러한 문제 덕분에, SHA2인 SHA-256/224, SHA-512/384와 같이. 이러한 해시 충돌을 최대한 방지하기 위한 해시 알고리즘들이 나왔어. 여기서 256/224, 512/384의 차이는 해시 길이의 차이인데, SHA-256보다 SHA-512를 비교하면 SHA-512가 더 안전해. 왜냐하면 해시 값의 길이가 길수록 더욱 안전해지거든, SHA-256의 경우의 수는 2^256인데 반해, SHA-512는 2^512만큼 경우의 수를 가지고 있어.
데이터베이스 엔진이란? 데이터베이스 관리 시스템 즉 DBMS에서 데이터베이스에 대해 삽입, 추출 그리고 업데이트와 삭제를 하는 데 사용하는 기본 소프트웨어 컴포넌트야 ! 데이터베이스 엔진은 DB에서 어떠한 방식으로 저장하고 접근할 지에 대한 기능을 제공해주는데, 데이터베이스 엔진은 크게 2가지로 서버 엔진과 스토리지 엔진으로 나뉘게 돼!
서버 엔진은 사용자가 질의했을때, Query Parsing과, 스토리지 엔진에 데이터를 요청하는 작업을 수행하며,
스토리지 엔진 은 물리적 저장장치에서 데이터를 읽어오는 역할을 담당해.
MySQL은 다중 데이터베이스 엔진을 지원하는데, 눈여겨봐야할 MyISAM과 InnoDB는 스토리지 엔진에 속해.
여러 개의 데이터베이스 엔진이 똑같으면 하나만 쓰면 되는데, 여러 가지가 있다는 것은 각 각 엔진마다 특징들이 있다는 소리 ! 그렇기에 MyISAM과 InnoDB도 각각의 개성을 가지고 있어.
MyISAM의 가장 큰 특징은 데이터 모델 디자인이 단순하기에 InnoDB보다 빠른 읽기 속도, 그 중 select 작업이 상당히 빨라. 그리고 Full-text 인덱싱이 가능해 검색한 내용에 대해 복합 검색이 가능해 !
하지만 Table-Level Lock, 즉 테이블 단위로 로킹을 하기 때문에, insert, update, delete 속도가 느리며, 트랜잭션의 지원이 없어, InnoDB에 비해 참조 무결성 제한과 동시성 보장에 대해 약한 면을 가지고 있어.
InnoDB의 장점은 트랜잭션과 외래 키 지원 그리고 행 단위로 로킹을 할 수 있다는 점이야. MyISAM과 달리 데이터 무결성 보장, Commit, Roll back, 동시성 제어를 지원해 !
하지만 MyISAM보다 더 많은 기능을 제공하기에 보다 데이터 저장 비율이 낮고, 데이터 로딩 속도가 느리며, 시스템 자원을 많이 소비하지. MyISAM에서 사용하는 Full-text 인덱싱을 사용할 수 없어.
이 둘의 비교는 MyISAM은 가볍고 빠르며, 쓰기보단 select같은 읽기 작업에 최적화 되어있고, InnoDB는 무겁고 느리지만 다양한 기능이 있어, update, inserte, delete 등 쓰기 작업과 트랜잭션 처리에 최적화 되어 있어.
간단한 게시판을 만들 때 필요한 데이터베이스 엔진을 고를 때, 무엇을 고른다면 나는 MyISAM을 고를 것 같아.
내가 만든 간단한 게시판의 경우는 질의문의 5~60 %가 select문이고, 게시판 내용의 속성이 text로 되어있기 때문이야.
하지만 많은 인원이 사용하고, 많은 인원이 사용하는 프로젝트에서는 InnoDB를 이용하는 게 더 적절하다고 생각해. 트랜잭션 처리에 이상이 생길 확률이 줄어들 수 있으니깐
Java Virtual Machine, Java Byte Code를 실행하는 주체이라고 정의되어 있어. 그 외에도 블라 블라 블라...
"Java Virtual Machine은 또 뭐고, Byte Code는 또 뭐야?", "지금 껏 많이 들어왔으니깐, 그냥 진보된 기술들 중 하나인 거는 알겠어 그래서 뭐?" 이거 니 생각보다 대단한 물건이야. 자바 이전의 언어들은 왜 이런 생각을 안했는 지 바보같다고 느껴질 정도야.
가비지 컬렉션
자바 가상 머신, 즉 JVM은 굉장히 신기해. 나는 특히 JVM 중 가비지 컬렉션이 좋아. 매력있거든, 작년에 C로 자료구조를 공부할 때, 수동으로 메모리를 관리했을 때는 미치는 줄 알았는데, 가비지 컬렉션은 필요없는 건 알아서 버려줘, 메모리 누수 걱정 따윈 없애버리지. 난 가비지 컬렉션 없으면 못 살 정도야!
플랫폼독립성보장
JVM은 운영 체제든 하드웨어든 종류 무관하게 동일하게 동작하게 해줘. C 계열의 언어나 맥의 스위프트와 달리 운영 체제에 종속적이거나, CPU에 연연하지 않는 게 차가운 도시인 같고, 쿨해. JVM과 바이너리 코드만 있다면 맥이든, 리눅스든, 윈도우든 어디에서든 프로그램을 만들고, 실행할 수 있지. 읽고, 검증하고, 실행하지. 아래 사진을 봐바.
나는 이클립스를 쓰지 않고, 메모장으로 자바 프로그래밍을 했었어. 이클립스같은 IDE를 사용하며 잘 모르겠지만. 자바 파일은 이렇게 구동해
19시즌의 나는 이렇게 공부했어, powershell을 키고, javac trash.java를 한 후 바이트 코드인 trash.class를 만들었지. 클래스 마다 하나 씩 나오니, 꽤 양이 많은 코드에는 여러 개의 class 파일이 나왔어. 이러한 과정들이, 플랫폼의 독립성을 보장한다니, 놀랍지 않아?
JVM의 특징은 이 외에도 여러 가지가 있지. 심볼릭레퍼런스를 사용해 클래스와인터페이스를심볼릭레퍼런스를통해참조하고, 심볼릭 레퍼런스란 참고하는 클래스의 특정 메모리 주소를 참조 관계로 구성한 것이 아닌 참조하는 대상의 이름만을 지칭한 것을 의미해. 또한 네트워크 바이트 순서는 32bit의 RISC CPU와 64bit인 x86 CPU는 각 각 상위 바이트, 하위 바이트부터 적재를 시작해, 이같은 차이에 JVM은 빅 엔디안 즉 상위 바이트부터 적재를 하는 방식을 채택했지.
잡설은 각설하고, 메인 클래스 파일을 실행시킨 다면, JVM의 클래스 로더가 반겨줘, 클래스 로더는 런타임 데이터 영억에 데이터들을 적재하고, 실행엔진이 자바 바이트 코드를 실행시키는 구조였지. 여기서 클래스 로더와 런타인 데이터 영역이 중요해, 내가 멘탈이 나갔던 문제였거든.
먼저 클래스 로더부터, 클래스 로더는 총 4가지로 BootStrap ClassLoader, Extention ClassLoader, System ClassLoader, User-Defined Class Loader가있어.
이중 첫 번째인 BootStrap ClassLoader는 네이티브 코드로 구현되어있으며, JVM이 실행될 때 가장 먼저 실행되는 클래스 로더야. 네이티브 코드(컴퓨터에 입력하면 바로 동작하는 코드)를 사용했기에, 실행 속도가 제일 빠르지. 그래서 자바 실행에 필요한 기본적인 클래스를 로딩하는 역할을 맡고 있어.
두 번째인 Extention ClassLoader은 다양한 보안 확장 기능을 로딩하며, 별도로 클래스 패스에 지정되지 않아도 로딩해.
세 번째는 System ClassLoader, ClassPath에 정의 되어 있거나, -cp, -classpath에 지정된 클래스들이 로딩되며, 사용자가 지정한 $CLASSPATH의 클래스들을 로드하는 역할이야.
마지막 User-Defined Class Loader은 Jar 또는 War로 압축된 ClassPath의 Binary Code를 사용자가 직접 사용하는 클래스 로더야.
런타임 데이터 영역은 자바의 메모리 영역이야. 총 6가지로 구성되어 있어.
첫 번째는 PC 레지스터, CPU 안의 PC 레지스터 처럼, JVM 수행하고 있는 명령의 주소를 갖고 있어.
두 번째는 JVM Stack, 스레드가 시작될 때 스레드마다 하나 식 생성돼. Stack은 자료구조에서 배우듯 pop과 push 기능으로만 작동하지.
세 번째는 Native Method Stack이야 JVM Stack과 비슷하지만 Java Native Interface을 통해 호출되는 C 계열의 코드만을 수행하기 위한 스택이지.
네 번째, Method Area는 JVM이 시작될 때마다 생성돼. JVM이 읽어들인 클래스나 인터페이스의 정보 중 일부(필드와메서드정보, Static변수,메서드의바이트코드 등등)를 보관하는 역할을 하고 있어, Method Area 덕분에, static이나 전역 변수 등이 Method Area로 올라가, 어느 쓰레드에서든 전역 변수 값에 접근할 수 있어.
다섯 번째는 Runtime Constant Pool은 각클래스와인터페이스의상수뿐만아니라,메서드와필드에대한모든레퍼런스까지담고있는테이블이야. JVM은 어떤 메서드나 필드를 참조할 때 Runtime Constant Pool을 통해 실제 메모리상 주소를 찾아 참조해.
마지막 Heap은 인스터스나 객체를 저장하는 가비지 컬렉션 대상이야. 단 하나의 Heap 영역이며, Object 타입은 전부 heap에 생성돼.
컨트롤러를 구현하면서, @RequestMapping의 매개변수 method가 무슨 역할을 하는 지 궁금했다.
먼저 @RequestMapping이 무엇을 위해 사용하는 지 검색해본 결과,DefaultAnnotationHandlerMapping에서 컨트롤러를 선택할 때 대표적으로 사용하는 애노테이션임을 알 수 있었다. @RequestMapping은 메서드 단위까지 세분화해 컨트롤러에 매핑할 수 있으며, url뿐 아니라 매개변수, 헤더 등 많은 곳에 사용할 수 있다는 것을 알게 되었다.
value를 통해 url의 패턴을 지정할 수 있으며, method를 통해 똑같은 url을 받아도, 다른 메소드에 매핑해줄 수 있다는 것을 알게 되었다.
그 중 GET, POST, PUT, DELETE, OPTIONS, TRACE 총 7가지의 http의 메소드가 있다는 것을 알게 되었는데, GET과 POST 메소드를 공부했다.
GET과 POST 메소드 둘 다 서버에 요청을 하는 메소드인 것을 알게 되었다. 다만 차이점이 있는데 POST 방식을 사용할 경우, 패킷 안에 숨겨져 url에 전송하는 값을 노출하지 않지만(HTTP패킷의 바디에 포함), GET 방식은 전송하는 값을 url에 노출하는 것(HTTP패킷의 헤더에 포함) 또한 알게 되었다.
또한 GET 방식은 컴퓨터 구조에서 배웠던 캐시 방식을 사용하는 데, GET 메소드의 요청은 다시 요청을 할 때를 대비해 데이터를 저장시켜 놓아, POST 방식보다 더 빠르게 응답할 수 있다는 점을 알게 되었다.
