서브넷이 등장하기 이전,. 초기의 네트워크는 모든 장치가 하나의 네트워크로 이루어져 있었습니다 네트워크가 커질수록 네트워크 관리하기가 까다로워졌습니다. 이를 해결하기 위해 서브넷이란 개념이 등장하였고, 서브넷을 활용해 네트워크를 논리적으로 분할하여 효과적으로 관리할 수 있게 되었습니다.
이 글에서는 서브넷의 개념과 서브넷을 어떻게 활용하는지에 다루고자 합니다.
들어가기 앞서
서브넷의 개념에 대해 알고 싶다면, IP 주소에 대해 알아야 합니다.
IP 주소(IP Address)란?
IP(Internet Protocol)은 네트워크에서 장치들이 서로 통신을 할 수 있게 하는 프로토콜입니다.
각 장치는 고유한 IP 주소를 할당받아, IP주소를 통해 호스트를 구분하여 데이터를 주고받습니다. 네트워크 주소와 호스트 주소로 구성되어 있으며, 일반적으로 32비트로 구성된 IPv4와 128비트로 구성된 IPv6 두 가지 버전을 가지고 있습니다.
IP 주소는 A, B, C, D, E 클래스로 나누며, 이에 따라 네트워크 ID와 호스트 ID를 구분합니다.
A클래스는 8비트의 네트워크 ID와 24비트의 호스트 ID로 구별되며, 첫 옥텟은 0~127(2^7 - 1), 호스트 ID는 2^24 - 2 만큼 가질 수 있습니다.
B클래스는 16비트의 네트워크 ID와 16비트의 호스트 ID로 구별되며, 첫 옥텟은 128~191(2^6 - 1), 호스트 ID는 2^16 - 2 만큼 가질 수 있습니다.
C클래스는 24비트의 네트워크 ID와 8비트의 호스트 ID로 구별되며, 첫 옥텟은 192~223(2^5 - 1), 호스트 ID는 2^8 - 2 만큼 갖을 수 있습니다.
예시로 192.168.1.1의 IPv4 주소를 기준으로 설명할 때, 첫 옥텟이 192이므로 C클래스 이며, 네트워크 영역은 192.168.0.0이며 호스트 영역은 1입니다.
서브넷 개념
서브넷(Subnet)은 하나의 큰 네트워크를 여러 개의 작은 네트워크로 논리적 분할하는 기술입니다.
서브넷은 IP 주소에서 네트워크 영역을 부분적으로 나눈 부분 네트워크로 표현할 수 있습니다. 네트워크를 나누기 위한 방법인 서브넷팅과 서브넷팅을 하기 위해 사용하는 서브넷 마스크이 있습니다.
IP 주소가 구성되는 방식을 통해 인터넷 라우터는 대상의 네트워크를 찾을 수 있습니다. 그러나 클래스 A 네트워크에는 수많은 연결된 장치가 있을 수 있으며 라우터가 대상의 장치를 찾는 데 시간이 걸릴 수 있습니다.
서브넷은 IP 주소를 장치 범위 내에서 사용하도록 좁혀, 빠르고 간단하게 대상의 장치를 찾을 수 있습니다.
IP 주소는 네트워크 및 장치 주소를 나타내는 것으로 제한하므로 IP 주소를 사용하여 IP 패킷이 이동해야 하는 서브넷을 나타낼 수는 없습니다. 네트워크 내의 라우터는 서브넷 마스크라는 것을 사용하여 데이터를 하위 네트워크로 정렬합니다.
서브넷과 관련된 개념
서브넷 마스크는 IP 주소에서 네트워크 ID와 호스트 ID를 분리하는 역할을 합니다.
CIDR(Classless Inter-Domain Routing)은 IP주소 할당 방법 중 하나로,IP 주소와 함께서브넷 마스크를 사용하여 IP 주소 공간을 세밀하게 사용하기 위해 도입되었습니다. ex) 192.168.1.0/24
서브넷의 예시와 필요성
예시로, 당신이 ISP를 운영하고 있습니다. A라는 회사가 IP 주소 100여 개를 요청했습니다. 서브넷이 없다면 당신은 C 클래스의 IP 주소 하나를 A 회사에게 할당해야 합니다. ex) 192.168.1.x. 네트워크 주소와 브로드캐스트 주소를 제외한 192.168.1.1부터 192.168.1.255까지 100여 개만 필요한 A회사에게 모두 할당해야합니다.
이를 해결하기 위해서는 서브넷의 개념을 도입해야합니다. 위의 사례를 예시로 192.168.1.x에 100여 개 호스트를 할당하기 위해서는 서브넷 마스크를 지정해야 합니다.
192는 C클래스임으로 24개의 네트워크 ID를 지정해야 하며, 100여 개의 호스트를 등록하고자 한다면 0 또는 1의 네트워크 ID를 추가할 수 있습니다. 만약 0부터 127번까지 A회사에 할당하고자 한다면 24개의 네트워크 ID를 구성해야 하며, 128부터 255까지 할당하고자 한다면 25개의 네트워크 ID를 구성해야 합니다. 이때 24 개의 네트워크 ID를 구성할 경우 0은 네트워크 주소, 127은 브로드캐스트 주소로 총 128 - 2개의 주소를 할당할 수 있습니다.
서브넷을 이용해 각 클래스로 나눠진 네트워크를 서비스의 규모에 맞게 유연하게 분할하여 낭비되는 IP 주소를 최소화하며, 브로드 캐스팅에 사용되는 디바이스의 수를 최소화해 성능의 저하를 예방할 수 있습니다.
서브넷 마스크의 원리와 설명
간단하게 설명하자면 서브넷팅은 서브넷 마스크의 bit 수를 증가시킵니다. 네트워크 ID의 비트 수를 추가할 때마다 네트워크 ID 수는 2배가 증가하고, 호스트 수는 2배 감소합니다.
192.168.1.0/24을 기준으로 할당 가능한 호스트 ID의 수는 2^8 - 2 = 254개를 할당할 수 있습니다.
192.168.1.0은 IPv4이며 C클래스임으로, 서브넷 마스크는 1111 1111. 1111 1111. 1111 1111. 0000 0000.으로 나타낼 수 있습니다. 네트워크 ID는 24개이며, 호스트 ID는 8개입니다. 호스트 ID의 8비트를 사용하여 192.168.1.1부터 192.168.1.254까지 호스트 ID를 할당할 수 있습니다.
만약 192.168.1.0/25로 서브넷 마스크를 변경하게 된다면, 1111 1111. 1111 1111. 1111 1111. 1000 0000.으로 나타낼 수 있습니다.네트워크 ID는 25개이며, 호스트 ID는 7개입니다. 호스트 ID의 7비트를 사용하여 192.168.1.129부터 192.168.1.254까지 호스트 ID를 할당할 수 있습니다.
결론
서브넷은 네트워크를 효율적으로 관리하고 확장 가능한 구조로 만드는 데 중요한 역할을 합니다. IP 주소를 효율적으로 할당하고 네트워크 트래픽을 관리할 수 있으며, 보안을 강화하고 네트워크 성능을 최적화하는 데 도움이 됩니다.. 서브넷을 사용하면 다양한 네트워크 환경에 대응할 수 있으며, 복잡한 네트워크 구조를 구축할 수 있습니다.
서브넷은 네트워크 관리와 보안에 있어서 중요한 요소입니다. 적절한 서브넷 구성은 네트워크 성능을 향상하고 확장성을 높이는 데 도움 됩니다.
나의 경우에는 " 개발 실력만 있으면 충분하지 " 라는 착각이었다. IT에는 수 많은 분야가 있다.
새로운 이론이 정립되고 여러 파생 분야가 나뉘어도, 토대의 학문들과 유기적으로 연결된다.
개념과 원리를 모르고 무작정 갖다 사용하게 된다면 문제가 발생할 때, 누군가에게 의존해야 한다.
가령 나는 리눅스에 대해 얄팍한 지식을 갖고, 여러 서비스들을 호스팅했다. -
배포 중 문제가 생길 때는 그 문제에 대한 응급 처치만 했다.
돌이켜보면 그동안 가벼운 문제만 생긴 것은 천운이다.
만약 응급 처치들이 꼬이고 꼬여, 배포가 불가능한 상황까지 오게 되었다면?
그로 인해 수 많은 이용자와 회사의 피해를 생각하면 아찔하다.
위태로운 줄 위를, 단순한 나무 다리로만 생각하고 있었다.
이제서야 네트워크, 리눅스, 운영 체제에 대해 중요성을 느끼게 되었다.
서버를 배포할 때, 가장 중요하다고 생각하는 것은 어떻게 어디로 데이터를 전달하는 지이다.
AMAZON, MS, NAVER 등 간단한 인터페이스 조작을 통해서 공인 IP를 등록하고, 쉽게 서비스를 배포해주기에 간과하는 부분이지만 사설 서버를 다루게 된다면, 대기업이 해주었던 일들을 직접 해야만 한다.
네트워크는 어떻게 데이터를 전달하는 지 뿐만 아니라 데이터 교환 방법, 가용성, 신뢰성, 보안성 등 굉장한 큰 범위를 다루게 된다.
네트워크(Network)란?
컴퓨터나 다른 장치들이 상호 연결되어 데이터를 주고받을 수 있는 구조다. 네트워크는 자원 공유, 통신, 연결성, 자동화를 하기 위해 탄생
패킷(Packet)이란?
데이터 통신에서 정보를 전송하는 데 사용하는 단위다. 네트워크를 통해 데이터를 주고 받을 때 데이터는 패킷으로 분할되어 전송하며, 수신자는 패킷을 조합하여 데이터를 받는 다. 각 각 암호화 복호화로 통칭한다. 패킷은 헤더와 페이로드 또는 헤드와 페이로드, 트레일러로 구성되어 있다.
헤더 : 송신자와 수신자의 주소, 데이터 유형, 전송 순서, 오류 검출 코드 등이 포함한다.
페이로드 : 실제 전송되는 데이터이다.
트레일러 : 오류 검출을 위한 코드나 체크섬을 포함한다. 패킷의 오류 검출 코드와의 차이는 위치이며 헤더의 오류 검출 코드는 헤더 부분의 오류 감지, 트레일러의 오류검출 코드는 전체 패킷의 오류를 감지해 무결성을 보장한다.
OSI(Open Systems Interconnection) 7계층이란?
컴퓨터 네트워크의 설계와 통신을 나타내기 위한 참조 모델, 통신 과정을 단계별로 분리하여 복잡성을 줄이고, 계층 간 인터페이스의 상호작용을 편하게 나타낼 수 있다.
물리 계층
데이터를 전송하는 데 케이블이나 전기같은 물리적 성질과 연결 방식, 전송 속도같은 비물리적 성질을 다룬다. 데이터를 전기적 신호를 변환, 물리적인 매체로 전송한다. 주로 이더넷, USB, WI-FI 등의 인터페이스 등이 여기에 구성되어 있다.
전송률 : 실제 단위 시간 당 전달되는 데이터 양, bps로 표시
대역폭 : 물리적을 네트워크에서 전달 가능한 최대 데이터 양을 의미, bps로 표시
bps : 초당 비트 단위
데이터 링크 계층
인접한 네트워크 장치 간의 직접적인 통신을 다룬다.프레임으로 데이터를 분할하고, 오류 검출 및 수정, 논리적인 주소 할당, 흐름 제어, 접근 제어 등의 기능을 수행한다.
프레이밍 : 데이터를 프레임이라는 작은 단위로 나누어 전송
프레임 : 데이터 링크 계층에서 사용되는 데이터의 전송 단위, 패킷 앞에 프레임 시작 신호(Frame Start Delimiter, FSD)라는 비트 패턴을 추가
MAC(Media Access Control) : 네트워크 인터페이스 카드에 할당된 고유한 식별번호로 네트워크 장치들이 서로 식별하고 통신할 때 사용
CRC(Cyclic Redundancy Check) : 순환중복 검사로 불리며 송신시 데이터의 비트열에 대해 다항식 연산을 수행해 체크섬을 생성, 수신시 체크섬을 계산후 비교해 데이터 무결성을 보호
네트워크 계층
패킷의 경로 선택, 여러 네트워크 간의 통신을 다룬다. 라우팅 알고리즘을 사용하여 데이터 패킷을 전송하고, 서브넷 관리 및 주소 할당을 수행한다.
IP(Internet Protocol) : 컴퓨터와 네트워크 장치를 식별해 네트워크 데이터를 주고 받는 데 사용되는 주요 프로토콜
IP주소 : 컴퓨터와 네트워크 장치를 식별, 주소를 32비트를 10진수로 표현하는 IPv4와 128비트를 16진수로 표현하는 IPv6 버전이 존재
DHCP(Dynamic Host Configuration Protocol) : 네트워크에 연결된 장치에 IP 주소 및 서브넷 마스크, 기본 게이트웨이, DNS 서버 주소 등 기타 네트워크 구성 정보를 할당하는 프로토콜 서브넷 마스크(Subnet Mask) : IP주소를 네트워크 ID와 호스트 ID로 식별, 255.255.255.0 기준으로 255.255.255는 네트워크 ID, .0은 호스트 ID
기본 게이트웨이(Default Gateway): : 다른 네트워크나 인터넷으로 가는 경로를 제공, 주로 라우터를 사용
DNS 서버 주소(DNS Server Address) : IP주소를 도메인 이름으로 변환하거나 그의 반대를 할 때 사용 (구글 DNS서버 8.8.8.8, 8.8.4.4)
IP Suite : IP를 포함한 TCP, UDP, ICMP 등의 여러 프로토콜과 서비스의 집합 라우터(Router) : 네트워크에서 데이터를 전송하는 장치(공유기 등), 외부 네트워크와 내부 네트워크를 연결 (내부 네트워크 192.168.x.x, 특수 네트워크를 제외한 나머지는 외부 네트워크)
라우팅 : 패킷을 받아 목적지로 전달하기 위한 최적 경로를 결정, 다익스트라나 벨만 포드 알고리즘 사용
서브넷 : 큰 네트워크를 더 작은 네트워크로 나눔. 서브넷 마스크를 이용하여 서브넷 ID와 호스트 ID 분할
전송 계층
종단간 통신을 제어, 데이터의 신뢰성을 다룬다. 데이터의 분할과 재조립, 흐름 제어, 오류 복구, 연결 관리 등을 담당한다.
TCP : 신뢰성 있는 데이터 전송을 보장하는 연결 지향적인 프로토콜로, 데이터의 분할과 재조립, 흐름 제어, 오류 복구, 연결 설정 및 해제 등을 담당. 데이터의 손실이 용인되지 않는 경우에 주로 사용됩니다.
UDP : 비연결형 프로토콜로, 연결 설정 과정이 없으며 데이터 전송만을 담당. 데이터의 신뢰성은 보장하지 않지만, 전송 속도가 빠르며 영상 전송 등 일부에서 사용
세션 계층
통신의 세션을 관리, 양 끝단 간의 상호 작용의 동기화를 다룬다.데이터의 동기화와 동시성 제어, 오류 복구 및 회복을 수행한다. 양 종점에서 통신의 동기화를 유지
세션 :
동기화
동시성제어
표현 계층
데이터의 형식을 변환 및 압축, 데이터 암호화와 복호화를 다룬다. 이 계층은 데이터의 구문 분석, 형식 변환, 암호화와 복호화를 수행에 데이터 교환을 지원한다.
MIME
응용 계층
응용 프로그램의 인터페이스를 다룬다. 사용자 인터페이스, 데이터 처리, 데이터 전송에 관한 응용 프로그램 및 서비스에 대한 접근을 지원한다.
아주 간단한 모델링을 하면서도, 여러 가지 고민을 했었다. 이게 맞는 걸까? 아니야 이게 맞는 걸꺼야 라는 생각을 여러번 했었다.
매우 간단한 데이터베이스 모델링 사진이다.
이런 간단한 테이블을 짜면서 고민했던 점은 아래와 같다.
1. Int와 INT UNSIGNED의 표현 범위는 똑같은데, PK에서만큼은 왜 INT UNSIGNED을 주로 쓸까?
2. 왜 컬럼 명을 camel case가 아닌 snake case로 사용하는 걸까?
3. 댓글과 댓글 본문의 길이 수에 차이를 둬야하는 데, 이 때 도메인 본문과 댓글 본문을 대등한 관계에 둬야하는 지, 아니면 댓글 본문을 본문의 자식 도메인으로 둬야하는 지
4. 댓글은 검색 기능을 구현할 생각이 없는데, TEXT나 LONGTEXT 등으로 사용해도 되지 않을까?
5. 수정일시 같은 경우는 수정이 발생할 때만 데이터를 얻을 수 있다. 또한 DATETIME같은 경우, default 값을 정하기 어렵다. 그렇다면 수정일시를 NULL 처리하는 것이 맞을까, 아니면 생성일시와 같이 NOT NULL로 처리하는 게 맞을까?
6. 댓글과 조회수도 이벤트가 발생해야, 데이터를 받을 수 있는데, NULL로 지정하면 안될까?
7. 비밀번호는 왜 CHAR 타입으로 선언해야할까?
8. 이 테이블이 1, 2, 3 정규형과 BCNF 정규형에 통과할 수 있을까?
9. 컬럼명은 대문자로 해야할까 소문자로 해야할까?
이러한 의구심이 들었고, 나는 이렇게 생각했다.
1.
문제 없이 잘 작동은 된다.
물론 PK의 데이터 타입을 INT로 설정해, 음수가 나올 수도 있다. 전혀 문제 되지 않는다. 다만 편의성에서 문제가 생길 수 있다. 이 문제에 대해 나는 이런 가정을 상상했다. 오래되고, 사람들이 자주 이용하는 사이트의 데이터 베이스의 기본키가 INT로 되어있다면. INT의 표현 범위 65,535 중 절반만 사용할 수 있을 것이다. 주로 게시판은 시퀸스를 이용해 늘려나가니깐. 물론 음수로도 사용할 수 있다. 가정의 수는 이렇게 생각해봤다.
1. -32768 부터 증가 -> 처음부터 숫자의 자리수가 크다.
2. 0부터 32767만큼 증가 후, -32768에서 증가
3. 32767에서 -32768로 감소
이 외에도 여러 가지 경우의 수를 생각해봤는데, INT로 표현한다 해서 얻을만한 장점은 크지 않다고 생각한다. 무엇보다 INT UNSIGNED를 데이터 타입으로 둔다면 일관적이다.
2. 이 부분은 굉장히 의구심이 든다. JAVA에서는 camel case를 주로 사용하는데 db에서는 snake_case를 주로 사용해, jdbc를 사용할 때 문제가 발생할 수 있다. 왜 통일을 안하는 지 너무 궁금하다.
3, 이 부분은 아직까지도 고민 중이다. 그 이유는 자식 도메인이라는 개념을 구체적으로 알지 못해서인데, 그냥 도메인이든 자식 도메인이든 이 둘의 차이점을 느끼지 못했다. 다만 나는 본문의 하위 도메인으로 댓글본문을 추가했다.
4. 생각해보면 TEXT로 지정해둬도 나쁠 것 같지 않다고 생각한다. TEXT와 char의 차이점은 TEXT 필드는 기본 값을 가질 수 없으며, MySQL은 TEXT 열의 처음 n개의 문자만 인덱싱 할 수 있다는 점인데. 댓글은 기본값을 가질 필요가 없으며, 댓글 안의 단어들을 검색할 것이 아니니, 검색 기능이 없는 부분에서 만큼은 취향 차이라고 생각한다.
5. 내 생각은 이렇다
처음 insert될 시, 수정일시를 넣을 필요는 없음
수정이 끝난 후, 그때서야 값을 받을 수 있음.
default값을 줄 수 없기에, 비어있음 그러므로 수정일시는 not null이 되어야한다고 생각한다.
6. 위의 문제와 연관되어 고민해봤는데, INT 타입은 default를 지정해줄 수 있으며, 0으로 기본값을 지정해준다면 NOT NULL을 지정할 수 있다.
7. 비밀번호의 보안을 위해, 해시 함수를 사용한다. 주로 사용되는 것은 SHA 계열의 해시 함수인데, 해시 함수는 고정된 길이의 숫자와 문자의 조합으로 반환된다. 내가 SHA-256을 사용한다면 64만큼의 문자열로 반환하니. 고정길이인 CHAR 타입으로 받는 것이 좋다고 생각한다.
8. 1 정규형인 중복 애트리뷰트가 없으므로 통과, 기본키가 일반 애트리뷰트에 대해 이행 함수 종속성 없으며 반대로 일반 애트리뷰트가 기본키에 대해 이행 함수 종속성을 띄지 않으니 2, 3 정규형도 통과이다. 마지막으로 일반 애트리뷰트가 기본키에 대해 영향을 주지 않으니 BCNF도 통과했다고 생각한다.
9. 이 부분은 정말 모르겠다. 국내에서는 컬럼명을 대문자로 쓰는 추세지만 해외에서는 소문자도 많이 쓰인다고 봤다. 정말 취향에 관한 부분인 것 같다.
이 사진에서 보이듯 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를 이용하는 게 더 적절하다고 생각해. 트랜잭션 처리에 이상이 생길 확률이 줄어들 수 있으니깐
비밀글에 한해서만 닉네임, 제목, 내용과 함께 비밀번호를 입력하고, 비밀번호를 통해 열람 가능해야함
에디터는 네이버 에디터를 이용
파일 첨부는 n개지만 총 파일의 용량이 100MB를 넘어서선 안됨.
댓글 기능 (대댓글은 x)
페이징 (10개 단위로 게시글 출력)
검색 조건은 제목, 내용, 제목과 내용
글 삭제 가능해야함
JAVA는 1.8, Tomcat은 8~9 사이, DB는 mariadb 10.x 사용
현재 나는 에디터와 페이징에 약간의 에러 그리고 파일 첨부는 구현하지 못했지만 나머지 기능들은 구현했다.
지금까지의 프로젝트의 구조는 아래와 같다.
웹 프로그래밍을 배우지 않았고, java script, html을 1월 4일 때 처음 접했기 때문에, 우선은 프로젝트를 위해 필요한 지식만 jsp를 만들어보면서 배우게 되었다.
이번 프로젝트를 통해 스프링을 이용해 MVC 방식으로 게시판을 완성하는 것에 목표를 두었다.
프로젝트에 소개를 하자면 main 파일은 크게 4가지로 구성되어있다. 변수를 가진 board와 board의 컨트롤러, service와 dao로 구성 되어있다. 그리고 views는 8가지의 뷰가 존재하지만 실제 사용하는 뷰는 content, index, inseartBoard, listPage, searchListPage, secretPage 총 6가지로 구성되어있다.
컨트롤러는 총 11가지의 기능을 @RequestMapping을 통해 servie에게 요청하고, dao에서 수행한 뒤 돌아와 jsp 파일에 데이터를 넘겨주게 된다.
가장 처음 구현했던 건 게시글 목록을 구현했다.
주소에서 list를 받으면 service.getBoardList에게 Board의 객체를 준 뒤, List<Board>의 객체를 받아오게 된다. 이를 model에 넣어 listPage.jsp로 보내게 된다.
아직 마이바티스를 잘 다루지 못하기 때문에 JDBC를 이용했다. connection을 통해 내 DB의 주소, 아이디, 비밀번호를 입력해 연결한 뒤, Statment 또는 PreparedStatement로 sql를 질의하게 된다. 하나의 데이터를 가져오기 위해 질의한다면 if (rs.next())를, 여러 개의 데이터를 가져오기 위해 질의한다면 while(rs.next())를 사용했다. 이러한 정보를 Board의 객체인 t로 받아, List<Board>에 넣은 후 반환했다. 이 정보를 약간의 가공 후, jsp 파일로 넘겨주는 간단한 방식으로 게시판을 만들었다.
쿠키와 세션을 먼저 얘기하기 전, 한 가지 알아야할 게 있어. HTTP 통신에 대해 먼저 알아야 해 !
HTTP이란?
HTTP는 클라이언트-서버 프로토콜이야. HTTP는 클라이언트와 서버 사이를 연결을 맡고있지.
브라우저를 통해 웹 사이트를 돌아다닐 때, 우리는 웹 사이트를 방문하기 위해 서버에게 요청을 해. 서버는 요청을 받은 뒤 허락한다는 응답을 보내게 돼. 이렇게 간단하고, 대단해보여도 여러가지 문제점이 발생할 수 있어.
클라이언트와 서버간의 응답이 끝난 후, 다른 웹 페이지를 방문했다가 다시 돌아오게 된다면 정보에 손실이 발생하거나, 불편한 점 등이 발생할 수 있어. 왜냐하면 이미 했던 프로토콜을 다시 한 번 진행하며, 아까 내가 했던 일들이 사라지기 때문이야.
그렇기에 우리는 쿠키와 세션이라는 기능을 이용해 이러한 문제점을 해결하지 ! 쿠키와 세션에 대해 알려줄게 !
쿠키란 HTTP의 일종으로, 사용자가 웹 사이트를 방문할 때, 사이트의 서버에서 내 컴퓨터로 저장되는 txt형식의 작은 기록 정보 파일을 말해.
쿠키는 웹 사이트를 방문할 때마다 수시로 정보가 바뀌고, 전역 변수로 설정되어, 사이트 모든 페이지에서 읽을 수 있지 ! 이 덕분에 우리는 방문했던 사이트를 좀 더 빠르게 이용할 수 있게 되었어.
세션은 쿠키와 비슷한 목적이지만 반대의 방식을 사용하고 있어. 쿠키는 서버가 내 컴퓨터로 작은 파일을 저장했다면, 세션은 사용자가 브라우저를 종료하기 전까지, 서버가 클라이언트의 요청을 유지하게 만드는 기술이야. 사용자가 브라우저에 접속해, 서버로 요청을 하면, 자동 생성되고 서버의 메모리에 저장해 !
쿠키와 세션의 차이점을 정리해볼까?
저장위치를 기준으로, 쿠키는 로컬에 저장하지만 세션은 로컬과 서버에!
보안을 기준으로, 쿠키는 탈취 및 변조가 가능하지만 세션은 서버에 저장되어있기 때문에 상대전으로 안전!
JSP의 디렉티브는 클라이언트의 요청에 JSP 페이지가 실행될 때 필요한 정보를 JSP 컨테이너에게 알려주는 역할이야. 3가지의 디렉티브 중 include디렉티브는 여러 개의JSP 페이지에서 공통적으로 포함하는 내용을 별도의 파일로 저장한 뒤, 필요 시에 JSP 페이지 내에 삽입할 수 있는 기능을 제공해 줘.
<%@ include file= "파일" %>
하지만 include액션 태그는 디렉티브와 약간 달라. 액션 태그는 페이지와 페이지 사이의 제어를 이동과 같은 동작을 지시하는 태그야. 그 중 include액션 태그는 다른 페이지의 실행 결과를 현재 사용하는 페이지에 포함할 수도 있어.
<jsp:include page="파일" flush="true" />
이 둘의 공통점은 include 디렉티브와 include 액션 태그 모두 요청을 해, 다른 파일을 가져올 수 있어.
이 둘의 차이점은 컴파일 방식에서부터 차이가 나. include 디렉티브는 정적 방식으로 include 파일과 함께 컴파일 되지만, include 액션 태그는 동적 방식으로 include 페이지와 별개로 컴파일 돼. 그리고 목적에서 차이점을 보여, include 디렉티브는공통으로 사용되는 변수를 저장해 사용하기 위한 목적으로 이용되지만 include액션 태그는 화면의 레이아웃 중 일부를 모듈화할 때 사용돼. 이외에도 처리시간, 기능, 데이터 전달방법에서 약간씩 차이점이 있어. 자세한 건 아래의 표를 참고하면 좋을 것 같아.
부모와 자식 클래스에 꼭 필요한 부분인 변수와 메소드만을 가졌지만, 적어도 하나 이상 abstract, 즉 추상 메소드가 존재하고 있어.
예시를 들어볼까? 부모 클래스인 Mammalia(포유동물)은 자식 클래스인 Human, Dog, Lion을 가지고 있다고 가정하자.
포유동물은 성대를 가지고 있기에, 모두 울부짖을 수 있어. 그렇다면 이 공통점은 소리낸다 라는 공통적인 행동이 있어.
하지만 포유동물은 어떻게 소리를 내는 지 몰라, 그래도 우리의 목적을 달성해야만 해.
다행이도, 우리는 사람, 개, 사자가 모두 어떻게 소리를 내는 지 알고 있지.
그렇다면 Mammalia 클래스의 소리낸다 라는 메소드를 추상처리하고, Human, Dog, Lion 클래스는 각 각 '아', '왈 왈', '어흥' 이라는 기능을 각 각 오버라이딩하면 돼 !
이번엔 인터페이스를 설명해보자 !
인터페이스는 클래스들이 구현해야 하는 동작을 지정하는데 사용되는 추상 자료형이야.
인터페이스? 추상 클래스와 정말 비슷해, 인터페이스로 작성되는 대부분의 메소드는 추상 메소드이기 때문이야.
?? : 그렇다면 인터페이스랑 추상 클래스는 무슨 차이에요?
추상 클래스랑 비슷해, 다만 목적은 아주 약간 달라. 추상 클래스의 목적은 서브 클래스에서 구현할 수밖에 없는 기능만을 추상 메소드로 선언해 구현하려 하지만 인터페이스의 목적은 클래스의 목적에 따라 인터페이스의 모든 추상 메소드를 만들도록 하는 거야.
예시를 들어보자 !
인터페이스가 없다면 어떤 일이 실세계에서 펼쳐질까 ?
동일한 규격이 없어! A 공장은 볼트를 만들고, B 공장은 너트를 만들어도, 서로 사용할 수 없어. 규격이 맞지 않아 너트가 들어가지 않거나, 너무 커서 쉽게 빠져 버리게 될꺼야.
이 추상 클래스와 인터페이스는 서로 비슷하면서 다른 점도 많아.
추상 클래스와 인터페이스는 둘 다 객체를 생성할 수 없어. 그리고 상속을 위한 슈퍼 클래스로만 사용 가능해.
그리고 클래스의 다형성을 실현하기 위한 목적이지.
하지만 차이점도 있지. 추상 클래스는 추상 메소드와 일반 메소드 그리고 상수와 변수로 구성되었어.
인터페이스는 상수와 추상 메소드로 구성되어있지만 default 메소드, static 메소드도 구현 가능해. 여기서 니가 꼭 기억해야할 내용은 이거야.
추상 클래스는 단일 상속이지만 인터페이스는 다중 상속이 가능하다는 점, 꼭 기억해야해!!!
내가 이번 추상 클래스와 인터페이스를 공부하면서 이런 고민을 하게 되었어.
나는 어떤 상황일 때, 추상화를 사용하고, 인터페이스를 사용하지?
내 생각은 이래, 부모 클래스와 가까운 클래스에는 인터페이스 구현은 선택사항인 것 같아.
추상 메소드를 인터페이스로 하든, 추상 클래스로 하든 큰 상관은 없으니깐.
하지만 부모 클래스와 먼 자식 클래스 사이에서는 인터페이스를 사용할꺼야.
예를 들어보자. 부모 클래스 통신 장비에서 여러 자식 클래스를 거쳤다는 가정을 하자. 통신 장비와는 먼 무전기와 스마트폰이라는 자식 객체가 있을 때, 무전기와 스마트폰의 공통점은 통신하다() 라는 메소드 뿐이야. 하지만 무전기도 와이파이를 사용했으면 좋겠고, 스마트폰은 위성통신을 할 수 있었으면 좋겠다고 생각이 든다면. 인터페이스를 통해 와이파이(), 위성통신()을 스마트폰과 무전기에 주입할 수 있겠지.
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에 생성돼.
