mellowg

🌐 3장. 웹을 구현하는 기술

3.1 웹을 구성하는 구조

3.1.1. 웹과 네트워크

웹(web)은 World Wide Web(WWW)이라는 인터넷에서 제공되는 하이퍼텍스트 시스템이다. 인터넷이라는 표현은 흔히 웹을 가리키지만, 정확히 말해 웹은 인터넷의 한 기능일 뿐이다.

하이퍼텍스트란 문서 안에 다른 문서의 위치 정보를 포함시켜 정보를 서로 연관 지어(하이퍼링크) 참조할 수 있게 만든 문서이다. 이 개념을 인터넷상에서 실현한 것이 웹이다.

웹은 HTML로 대표되는 하이퍼텍스트 언어와 네트워크의 네트워크인 인터넷이 융합되어 탄생하였다.

당초에는 문자 정보만 주고받는 단순한 기술이었지만, 웹 서버에서 동작하는 애플리케이션이나 HTML 언어 자체의 사양이 확장되면서 이용 범위가 확대되었다. 지금은 전자상거래, 온라인 뱅킹, 게임, 동영상 서비스 등 다양한 용도로 활용된다.

3.1.2. 클라이언트와 서버

웹으로 제공되는 서비스 대부분은 서비스를 제공하는 쪽(서버)과 서비스를 받는 쪽(클라이언트)으로 나뉜다. 이를 클라이언트 서버 모델이라고 한다. 서버에 시스템을 설치하고 사용자는 클라이언트에서 서버에 액세스한다.

웹 서비스를 예시로, 서버는 그 역할의 성격상 유지 보수를 해야 하기 때문에 일시적으로 멈출 수 있지만, 기본적으로 언제든지 클라이언트 요구에 대응할 수 있도록 24시간 365일 가동해야 한다.

반면 클라이언트는 서비스를 이용할 때만 동작해야 한다. 사용하지 않을 때는 전원을 끌 수 있으며, 항상 동작하는 것은 아니다. 또 인간이 사용하므로 편의성이나 휴대성 같은 것을 고려해서 만들고 있다.

3.1.3. 웹 서버

웹은 클라이언트 서버 모델을 기반으로 하는 시스템으로, 정보 제공자가 웹 서버를 공개하고 사용자가 웹 브라우저를 통해 웹 서버에 있는 정보에 액세스 하는(브라우징) 형식을 기본으로 한다. 

웹 서버는 정보를 전송하거나 서비스를 제공하려고 365일 계속해서 동작하는 컴퓨터를 의미한다. 아파치(Apache)나 엔진엑스(Nginx)처럼 컴퓨터상에서 웹 서버 기능을 제공하는 구체적인 애플리케이션을 가리켜 웹 서버로 지칭할 때도 있으니 주의해야 한다.

웹 서버의 가장 기본적인 역할은 웹 페이지를 공개하는 것이다. HTML로 작성된 문서를 인터넷에 공개하는 역할을 담당한다. 웹 서버에서 애플리케이션을 실행할 수 있는 CGI(Common Gateway Interface) 기술로 인터넷에서는 정보를 양방향으로 교환하게 되었다. 현재는 서버 사이드 언어나 데이터베이스 등과 연계하여 웹에서 많은 일을 할 수 있게 되었다.

3.1.4. HTTP와 HTTPS

HTTP는 서버와 클라이언트 사이에서 데이터를 주고받는 프로토콜이다. 웹이 처음 만들어질 당시에는 정보 공유를 목적으로 한 시스템이었기 때문에 통신 경로에서 정보를 감출 필요가 없었다. 그러나 이용 범위가 확대되면서 웹 서버에 데이터를 전송할  때는 암호화하여 정보 기밀성을 확보할 필요가 생겼다. 그래서 만들어진 것이 HTTPS 프로토콜이다.

HTTPS는 SSL/TLS 구조로 구현되었다. SSL(Secure Sockets Layers)과 TLS(Transport Layer Security)는 인터넷에서 통신을 암호화하여 제삼자가 통신 내용을 훔쳐보거나 조작할 수 없게 하는 기술이다. 

SSL은 넷스케이프가 개발한 프로토콜이고, TLS는 SSL을 계승하여 IETF라는 표준화 조직의 TLS 워킹 그룹에서 책정한 프로토콜이다. 현재는 SSL 이 아닌 TLS가 사용되고 있어 TLS라고만 표기해도 되지만, 여전히 SSL 지명도가 높기 때문에 SSL/TLS로 병기하거나 그냥 SSL이라고 할 때도 많다.

3.1.5. SSL 인증서

SSL/TLS를 웹 사이트에서 이용하려면 SSL인증서가 필요하다. SSL 인증서란 인증 기관(CA, Certification Authority)이라는 신뢰할 수 있는 제삼자 기관이 이용자(도메인 소유자)에게 발행하는 것이다.

SSL 인증서의 역할

SSL인증서는 다음 세 가지 목적으로 이용한다.

1. 데이터 암호화:
   • SSL 인증서에 포함되는 공개 키를 사용함으로써 암호화 통신을 위한 비밀키를 안전하게 교환할 수 있고, 암호화 통신을 실현할 수 있다.
2. 도메인 소유 증명:
   • SSL 인증서로 해당 도메인은 A가 소유하는 도메인이라는 것을 제삼자인 인증기관에서 보증한다.
3. 데이터 변조 방지:
   • 제삼자 기관이 보증하는 인증서로 암호화된 통신은 변조되지 않고 확실하게 A의 정보임을 보증한다.

인증 기관 신뢰

인증 기관은 인증 기관 운영 규정이라는 문서를 공개하여 보안 정책을 규정하고, 본사를 둔 국가의 정부 등이 이 문서를 인증함으로써 우리는 인증 기관을 신뢰할 수 있다.

인증 레벨에 따른 종류

SSL 인증서는 인증 레벨에 따라 도메인 인증(DV), 기업 인증(OV), EV인증(EV) 세 가지로 나눌 수 있다. 모든 인증서가 SSL/TLS을 이용한 암호화 통신 기능을 제공하지만, 인증서를 발행하는 조직이 실제로 있는지를 증명하는 범위에는 차이가 있다.

• 도메인 인증(DV, Domain Validation)은 도메인에 등록된 등록자를 확인하고 발행하는 인증서이다. 도메인 소유만 확인할 뿐 도메인 및 인증서 소유자를 인증하는 것은 아니다. 발행 속도가 빠르고 가격이 저렴하여 개인 사이트뿐만 아니라, 기업체, 각종 미디어 등에 폭넓게 이용된다. 특히 개인정보나 신용 카드 정보 등 민감한 정보를 주고받지 않고, 검색 엔진 최적화(SEO, Search Engine Optimization) 이유로 항상 SSL을 적용해야 하는 웹 사이트에서 도메인 인증서를 많이 사용한다.
• 기업 인증(OV, Organization Validation)은 도메인과 더불어 웹 사이트를 운영하는 조직의 실재성을 인증하는 인증서이다. 인증서 발행처가 운영 조직의 실재성을 인증하기 때문에 개인 정보나 신용 카드 정보 등 민감한 정보를 주고받는 웹 사이트 등에 이용된다.
• EV 인증(EV, Extrended Validation)은 기업의 실재성과 더불어 소재지를 인증한다. 인증서로 웹 사이트 운영 조직을 확인할 수 있다. 기업의 실재성을 인증한다는 점에서 기업 인증(OV)과 같다고 생각할 수 있다. 그러나 소재지 확인 등 더욱 엄격한 심사를 거치고 시각적으로도 확인할 수 있어 개인 정보나 신용 카드 정보 등 민감한 정보를 주고받는 웹사이트와 온라인 뱅킹 및 금융 기관과 연계되는 핀테크(Fintech) 서비스를 제공하는 웹 사이트 등에 이용된다.

3.1.6. URL과 DNS

URL

URL(Uniform Resource Locator)은 인터넷상에서 HTML이나 이미지 등 리소스 위치를 특정할 수 있는 서식으로 탄생했다. URL의 기본 서식은 스킴(프로토콜 + ://)과 서버 주소(또는 호스트 이름 + 도메인)에 다음 두 가지를 /로 연결한 것이다.

• 디렉터리 이름
• 파일 이름

DNS

웹 사이트 주소를 http://93.184.216.34/news/index.html처럼 IP 주소로 표기하면 기억하기 어렵다. 호스트 이름과 도메인으로 바꾸어 http://www.example.com/news/index.html로 변경하면 기억하기 쉽고 쓰기도 쉽다. 

하지만 인터넷에서는 반드시 IP주소로 접속할 대상을 지정하므로 www.example.com 이 사실을 조회하는 시스템이 필요하다. 이 시스템이 DNS(Domain Name System)이다.

DNS는 인터넷사의 거대한 분산 데이터베이스라고 할 수 있다. DNS는 콘텐츠 DNS서버와 캐시 DNS 서버 두 가지로 구성된다. 

콘텐츠 DNS 서버는 각 도메인의 바탕이 되는 기본 정보를 가지고 있고, 캐시 DNS 서버는 컴퓨터나 휴대전화 등 클라이언트가 문의하면 콘텐츠 DNS 서버를 찾아 정보를 요청한다. 캐시 DNS 서버는 콘텐츠 DNS 서버의 조회 결과를 바탕으로 클라이언트에 정보를 전달한다.

3.2. 도메인

도메인이란 인터넷상 주소로, 글로벌 IP주소를 가진 서버가 어디에 있는지 판단하는 정보로 이용된다. 글로벌 IP 주소가 있는 서버는 일반적으로 웹 사이트를 가리킨다. 

3.2.1. 도메인 관리 기관

도메인을 전 세계적으로 관리하는 곳은 ICANN이라는 비영리 단체이다. 그 밖에도 도메인을 다루는 조직으로 레지스트리와 레지스트가 있다.

레지스트리는 도메인 관리 기관으로, 각 도메인 정보의 데이터베이스를 관리한다. 레지스트리에 따라서 관리하는 도메인이 달라진다.

레지스트라는 도메인 중개 등록 업체로, 레지스트리가 관리하는 데이터베이스에 직접 도메인 정보를 등록할 수 있다. 도메인을 이용하려면 도메인 이름의 소유자가 누구인지, 어느 DNS 서버에서 관리되는지 같은 정보를 레지스트리 데이터베이스에 기록해야 한다. 이용자가 신청한 정보는 레지스트라를 경유하여 레지스트리의 데이터베이스에 기록된다.

도메인은 레지스트라가 판매하는 것 말고도 레지스트라의 대리점이 판매하는 예도 있다. 국내외로 많은 도메인 판매업자가 있는데 레지스트라가 직접 판매하기도 하고, 레지스트라에서 도메인을 도매로 받아 판매하는 대리점도 있다.

레지스트라는 레지트스리가 관리하는 데이터베이스에 직접 액세스 할 수 있지만, 대리점은 레지스트리가 관리하는 데이터베이스에 액세스할 수 없고 레지스트라를 통해서만 정보를 등록해야 한다.

3.2.2. 도메인 종류

도메인은 크게 두 종류로 나뉜다. gTLD(generic Top Level Domain)와 ccTLD(country code Top Level Domain)이다. 둘 다 ICANN이 관리하지만, 도메인 등록 업무 및 데이터베이스 관리 같은 실제 운영 업무는 레지스트리에 위임한다.

gTLD

gTLD는 전 세계에 등록이 개방된. com,. net,. org와 등록 제한이 있는. edu,. gov,. int,. mil 이렇게 일곱 가지 종류로 시작되었다. 2000년에. biz,. info,. name,. pro,. aero,. coop,. museum 일곱 가지 종류가 추가되었고, 2003년에는. asia,. cat,. jobs,. mobi,. post,. tel,. travel,. xxx가 추가되었다.

2012년부터는 새롭게 창설하는 gTLD 수에 제한을 두지 않고 기술적, 재무적 요건을 충족하는 조직이라면 신청이 가능해져 지금은 매우 많은 gTLD가 존재한다.

일반 이용자도 신청할 수 있는 gTLD 이외에 특정 기업이 전용으로 보유한 gTLD도 있다.

gTLD는 베리사인(Verisign)등의 회사가 레지스트리가 된다.

국내 ICANN인증 레지스트라로는 가비아, 예스닉, 후이즈 등이 있다.

ccTLD(국가 코드 최상위 도메인)

ccTLD는. kr,. us,. uk,. tv 등 전 세계에 200가지 이상이 있으며, 원칙적으로 그 나라에 사는 사람을 대상으로 한다. 하지만 어디까지나 원칙이며, 운영은 각국 네트워크 정보 센처(NIC)에 위임하여 다른 나라 사람에게도 도메인을 개방할 수 있다.

대한민국의 ccTLD는. kr이며, 한국인터넷진흥원(KISA)이 레지스트리로서 운영하고 있다.

. kr의 레지스트라는 가비아, 아이네임즈, 후이즈 등이 있다.

3.2.3. DNS 전환

시스템 전환 작업이나 서버 교체 등 IP 주소가 변경되는 사례는 많이 있다. 이때 DNS 설정도 함께 변경해야 한다.

www.example.com의 IP 주소가 203.0.113.1인 상태가 198.51.1090.1인 상태로 변경해야 하는 경우를 생각해 보자.

원본이 되는 정보는 콘텐츠 DNS 서버가 가지고 있지만, 인터넷상에 여러 개 존재하는 DNS 서버에도 복사된 정보가 있다. (가지고 있지 않은 경우도 있다.) 그리고 캐시 DNS 서버는 한 번 문의한 DNS 정보를 캐시로 보관해 둔다.

캐시 DNS 서버에서 캐시가 사라지고 새로운 정보를 다시 취득할 때 시차가 생긴다. DNS 정보는 스위치처럼 바로 전환할 수 있는 것은 아니고, 새로운 정보가 구석구석 도달하기까지 시간이 걸린다. 원래대로 되돌릴 때도 동일하기 때문에 서버 전환에 실패하고 다시 되돌릴 때도 마찬가지로 시차가 발생한다.

3.3. HTTP와 웹 기술

3.3.1. HTTP

HTTP는 웹 브라우저와 웹 서버 간의 상호 작용을 지원하는 프로토콜이다. HTTP는 데이터를 요청하는 HTTP 요청과 그에 응답하여 데이터를 보내는 HTTP 응답이라는 두 가지 상호 작용을 반복하여 웹 페이지를 표시한다.

HTTP 요청에는 하고 싶은 처리를 나타내는 메서드 이름과 대상 이름이 포함된다.

• GET: 리소스를 가져오도록 웹 서버에 요청
• POST: 웹 서버에 데이터를 송신
• PUT: 웹 서버에 파일을 업로드

HTTP 응답에는 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리 결과인 메시지가 포함된다.

3.3.2. 쿠키와 세션

세션은 웹 사이트를 방문해서 수행하는 일련의 행동이다. HTTP는 데이터를 요청하고 전송하는 상태 비저장 프로토콜이다. 사용자의 '상태'의 관한 정보를 알기 위해 사용하는 것이 쿠키(Cookie)이다. 쿠키란 웹 사이트를 열람한 사용자 정보를 클라이언트가 보관하고, 두 번째 액세스부터는 그 정보를 클라이언트가 서버로 보낸다. 이렇게 하면 다시 방문할 때 사용자를 식별할 수 있어 사용자의 브라우징 특성에 맞는 광고를 제공하거나 사이트 기능에 대한 설정을 저장하여 웹 사이트의 편의성을 높일 수 있다.

세션을 실현하려면 웹 사이트에 접속할 때 세션 ID라는 고유 ID가 할당되어야 한다. 세션 ID를 이용하여 사용자가 누구인지 식별하고, 제품을 추가하는 등의 정보는 세션 ID에 대응하는 세션 변수에 기록된다. 쿠키에 세션 정보를 기록하고, 실제 값(세션 변수 정보)은 서버 측에서 관리하는 방법이 널리 이용된다.

3.3.3. 인증

인증은 컴퓨터나 시스템을 사용할 때 필요한 본인 확인 절차이다. 시스템을 사용할 때 제삼자가 마음대로 사용하거나 제삼자에게 보이지 않도록 하는 인증이라는 메커니즘이 필요하다.

웹에서 인증은 개인 정보를 바탕으로 서비스를 이용하는 것이다. ID와 암호로 인증하는 것이 대부분이지만, 최근에는 다요소 인증(MFA) 이라고 하는 ID와 암호 이외에 일시적으로 발행되는 일회용 패스워드(one-time password)를 입력하는 인증 방식도 있다. 인증 요소를 늘리면 보안이 강화된다. 일회용 패스워드에는 휴대전화 SMS 전송, 전용 일회용 패스워드 생성 소프트웨어 사용, 물리적 하드웨어 토큰 기계에 표시된 암호 등 여러 종류가 있다. 

특정 서비스의 자격 증명을 사용하여 다른 서비스에 로그인할 수 있는 위임 인증 메커니즘도 있다. 이 방식에서 사용되는 기술이 OAuth이다.

기업 시스템의 예

한때 기업의 사내 시스템은 시스템마다 ID와 암호 데이터베이스를 가지고 있는 것이 대부분이었다. 그러나 최근에는 Active Directory나 LDAP라는 인증 기반과 연계되어 ID와 암호 하나만 있으면 사내의 어떤 시스템에도 로그인할 수 있다. 물론 시스템마다 권한에 따라 접근을 제한할 필요가 있다.

3.3.4. 새로운 기술: HTTP/2, Ajax, Web API

HTTP/2

HTTP/2는 HTTP의 새로운 규격이다. HTTP의 메이저 버전업으로 기획된 프로토콜로, 그 기반은 구글이 중심이 되어 개발한 SPDY 프로토콜이다.

HTTP/1.1 에서는 동시에 복수의 요청을 보낼 수 있지만, '요청 하나에 응답 하나'라는 기본 구조는 그대로이다. 그래서 HTML 파일 하나와 이미지 파일 여러 개로 구성된 웹 페이지를 표시할 때도 파일 하나마다 GET 요청을 보내야 한다. 이를 포함하여 HTTP/1.1 사양에는 아래와 같은 문제점이 있었다.

• 한 번에 파일 하나밖에 가져올 수 없다: JS, CSS, 이미지 파일 등 많은 리소스를 이용하는 HTML을 로딩하는 데 시간이 걸린다. 
• 프로토콜이 텍스트 기반이다: 텍스트 파일(프로그램에서 다룰 수 있는 데이터로 변환)에 시간이 걸린다.
• 파일을 가져올 때마다 거의 같은 HTTP 헤더를 송수신한다: 같은 내용을 송수신하는 만큼 오버헤드가 커진다.

이런 문제점을 받아들여 HTTP/2는 HTTP와 호환성을 유지하면서 새로운 전송 수단을 제공하여 기존 문제점을 해결하고 좀 더 적은 통신량으로 더 신속하게 주고받을 수 있도록 설계되었다.

HTTP/2는 커넥션 하나로 복수 콘텐츠를 병렬로 전송할 수 있어, HTTP/1.1 보다 효율이 높은 프로토콜이 되었다.

HTTP/2로 웹 콘텐츠를 전달하려면 SSL/TLS가 꼭 필요하다고 할 수 있다.

Ajax

웹의 편의성을 높인 것으로 알려진 Ajax라고 하는 프로그래밍 기법이 있다.

Ajax는 이미 읽은 웹 페이지에서 다시 HTTP 요청을 보내 웹 페이지 전환 없이 데이터를 송수신할 수 있는 기능을 제공하는 XMLHttpRequest 기술을 사용한다. 

또 XMLHttpRequest로 비동기 통신은 구현할 수 있지만 서버 측에서 푸시 통신을 하는 등 양방향 통신은 어려웠는데, 이를 해결하기 위해 웹소켓(Websocket)이라는 기술도 탄생했다.

Web API

최근에는 각사의 웹 애플리케이션 기능이 Web API로 제공된다. Web API는 사용자 조작과 상관없이 어떤 웹 애플리케이션에서 다른 웹 애플리케이션을 조작할 수 있는 인터페이스이다.

🌐 2장. 네트워크를 실현하는 기술

2.1 TCP/IP의 기본

2.1.1. TCP/IP

TCP/IP는 인터넷 프로토콜 스위트라고도 하며, 다른 컴퓨터 벤더나 운영 체제, 서로 다른 회선끼리 통신할 수 있게 하는 통신 프로토콜 세트이다. 인터넷 여명기에 정의되어 현재까지 표준으로 사용하는 TCP(Transmission Control Protocol)와 IP(Internet Protocol)를 따서 TCP/IP라고 한다.

즉, TCP/IP는 TCP와 IP만 가리키는 것이 아니라, 수많은 인터넷 통신 프로토콜 세트를 의미한다. TCP와 IP이외에도 UDP나 ICMP 등 다른 프로토콜도 TCP/IP에 포함된다.

예전에는 TCP/IP 이외에도 다양한 프로토콜이 있었지만, 현재는 대부분 TCP/IP를 사용한다.

TCP/IP 에서 다루는 범위는 역할에 따라 4개의 계층으로 나뉘며, 이를 TCP/IP 4계층 모델이라고 한다. 데이터 송수신에 필요한 작업을 각 층에서 분담해서 처리하는 이미지이다. 데이터 송수신에 필요한 작업을 각 층에서 분담해서 처리하는 이미지이다. TCP/IP에 포함된 프로토콜을 계층별로 나누면 아래와 같다.

• 응용계층 - HTTP, DNS 등 - 애플리케이션에 맞추어서 통신한다.
• 전송계층 - TCP, UDP - IP와 애플리케이션을 중개해서 송신된 데이터를 확실하게 전달한다.
• 인터넷 계층 - IP, ICMP, ARP 등 - 네트워크 주소를 기반으로 수신 측 컴퓨터까지 데이터를 전송한다.
• 네트워크 접근 계층 - 이더넷, 무선 랜(Wi-Fi) 등 - 컴퓨터를 물리적으로 네트워크에 연결해서 기기 간에 전송할 수 있게 한다.

2.1.2. OSI 참조 모델

또 하나 알아 둘 프로토콜 계층 모델은 OSI 참조 모델(Oepn System Interconnection reference model)이다. 이것은 TCP/IP 4계층 모델처럼 컴퓨터가 가져야만 하는 통신 기능을 계층 구조로 나눈 모델이자 벤더 간에 상호 통신할 수 있는 네트워크 모델로, 통일 규격이다. 

OSI 참조 모델은 통신 프로토콜을 7개의 계층으로 나누어 정의한다.

• 응용계층 - HTTP, DNS 등
• 표현계층 - HTTP, DNS 등
• 세션계층 - HTTP, DNS 등
• 전송계층 - TCP, UDP
• 네트워크계층 - IP
• 데이터링크 계층 - 이더넷
• 물리 계층 - 이더넷

OSI 참조 모델의 각 층을 실제 네트워크 세계와 연결하면 이더넷이 물리 계층과 데이터 링크 계층에 해당한다. TCP/IP의 IP는 네트워크 계층, TCP, UDP는 전송 계층에 해당하ㅗ, 컴퓨터상에서 움직이는 프로그램은 세션 계층, 표현 계층, 응용 계층에 걸치듯이 존재한다.

앞서 말한 TCP/IP 4계층 모델은 OSI 참조 모델과 별개로 만들어졌으며, 완벽하게 대칭은 아니다.

OSI 참조 모델에서 '층' 이라는 요소가 네트워크 세계에서 실제로 어떻게 사용되는지 알아보자.

예를 들어 1장에서 소개한 스위치(네트워크 스위치)를 예로 들어 설명하겠다.

스위치는 랜 케이블을 모으는 장치로, 조건에 맞게 통신을 중계한다. 어떤 계층의 정보를 바탕으로 중계하느냐에 따라 명칭이 달라진다. 이더넷 범위에서 처리하는 것은 L2 스위치, 라우팅이 가능한 것은 L3 스위치라고 한다.

마찬가지로 TCP로 분배할 수 있는 것은 L4 스위치, 응용 프로그램 레벨에서 배분할 수 있는 것은 L7 스위치라고 한다.

L2 스위치, L3 스위피, L4스위치, L7 스위치는 각자 기능에 따라 분류된 네트워크 장비이다.

2.1.3. 주소

통신에서 주소(address) 란 '통신 상대를 특정하는 식별 정보'이다. 주소가 있기에 비로소 원하는 상대방과 통신할 수 있다.

IP 주소

IP 주소는 TCP/IP에서 컴퓨터를 식별하려고 할당되는 번호이다. xxx.xxx.xxx.xxx 형식으로 표기쇤 숫자를 본 적 있을 것이다. 컴퓨터나 휴대전화, 태블릿 등은 물론이고 서버, 라우터, 스위치 등 네트워크 장비에도 각각 IP 주소가 할당된다.

덧붙여 IP 주소에는 프라이빗 IP 주소와 글로벌 IP주소가 있다. 랜 내부에서 사용되는 것이 프라이빗 IP 주소, 인터넷에서 사용되는 것이 글로벌 IP 주소이다.

MAC 주소

IP 주소만 있다고 컴퓨터끼리 통신할 수 있는 것이 아니다. 컴퓨터나 라우터 등 네트워크 기기에 처음부터 할당된 번호인 MAC 주소를 IP 주소와 조합해야 비로소 컴퓨터끼리 통신할 수 있다.

이더넷에서는 하드웨어끼리 통신 상대를 특정하고자 MAC 주소를 사용하고, TCP/IP에서는 통신 상대를 특정하고자 IP주소를 사용하기 때문이다.

주소를 이용한 통신 흐름과 ARP

같은 네트워크에 속한 컴퓨터끼리 통신할 때는 우선 IP 패킷을 보내고 싶은 상대의 MAC 주소를 조사하고, 그 MAC 주소로 패킷을 보내는 흐름이 된다.

IP 패킷을 보내고 싶은 상대의 MAC 주소를 조사할 때 이용하는 것이 ARP(Address Resolution Protocol) 이다. ARP란 IP주소에 대응하는 MAC 주소를 알아내려고 네트워크 전체에 패킷을 보내면(ARP Request), 자신을 찾는 것을 안 컴퓨터가 응답(ARP reply)함으로써 MAC 주소와 IP주소를 연결하여 통신할 수 있게 하는 일련의 시스템을 의미한다.

ARP 요청처럼 '네트워크 전체에 패킷을 보내는 것'을 브로드캐스트라고 한다. 브로드캐스트는 각 발신자가 그룹의 모든 수신자에게 메시지를 전송하는 통신 방법이다.

반면에 다른 네트워크에 속한 컴퓨터와 통신하면 네트워크 사이에 라우터 또는 L3 스위치가 끼어든다.

자신과 다른 네트워크의 IP 주소와 통신할 때 컴퓨터는 미리 지정된 기본 게이트웨이라는 IP 주소로 통신을 보낸다. 기본 게이트웨이는 다른 네트워크로 데이터를 전송하는 방법을 알고 있으며 일반적으로 라우터가 그 역할을 수행한다.

이때 ARP를 사용해서 조사하는 것은 목적지(다른 네트워크)의 IP 주소에 대응하는 MAC 주소가 아니라 기본 게이트웨이에 대응하는 MAC 주소이다.

IPv4와 IPv6

현재 사용되는 IP 주소는 IPv4(IP version 4)와 IPv6(IP version 6)로 두 종류가 있다.
IPv4는 예정부터 사용되었고, 지금도 메인으로 사용된다. 인터넷이 보급되면서 IPv4 주소가 부족해졌고, 이 문제를 극복하고자 새롭게 도입된 것이 IPv6이다. 하지만 IPv6가 등장하고 수년이 지났음에도 아직도 메인으로 사용하고 있지 않다.
가장 큰 이유는 IPv4 주소가 아직도 여전히 쓸 만하다는 데 있다. '쉽게 손에 넣을 수 있는 상황'이 바뀌지 않는 한 현재 상태에도 큰 변화가 없을 것이다.

2.1.4. 패킷

통신할 때 데이터를 교환하는 방법에는 회선 교환과 패킷 교환 두 종류가 있다. 데이터를 보내고 받는 모습을 교환이라고 상상하면 이해하기 더 쉽다.

회선교환이란 전화에 가까운 이미지로 데이터를 교환하는 동안 계속해서 회선을 점유하는 방식을 의미한다. 전화는 기본적으로 일대일로 주고받는 것이고, 통화하는 동안에는 다른 상대와 전화할 수 없다. 그러나 컴퓨터 네트워크에서는 여러 상대와 동시에 데이터를 주고받는 경우가 있어 이런 방식은 효율적이지 않다. 

그래서 생겨난 방식이 패킷 교환 이다. 패킷 교환은 주고받는 데이터를 '패킷'이라고 하는 작은 덩어리로 나누고, 회선을 공용해서 복수의 통신을 내보내는 방식이다. 패킷에는 실제로 소포의 운송장퍼럼 화물 이외에도 받는 곳이나 보낸 곳 등의 정보가 부가된다. 운송장에 해당하는 것을 헤더, 화물에 해당하는 것(작게 나눈 데이터)을 페이로드라고한다. 헤더에는 받는 곳이나 보내는 곳 이외에 소분한 데이터 순서 등도 기록된다. 이렇게 함으로써 데이터를 작게 분할하여 전송하더라도 도착한 곳에서 원래대로 복원할 수 있다.

2.2. IP 주소 구조

2.2.1. IP 주소 분석

새 집에 이사왔을 때 인터넷 회선을 설치하고 가정용 라우터(공유기)를 사서 컴퓨터를 연결한다. 컴퓨터를 라우터에 연결하자마자 인터넷을 사용할 수 있다. 컴퓨터가 출하되었을 때는 MAC 주소만 있고 IP주소는 없는 상태이다. 컴퓨터를 라우터에 연결해야 비로소 라우터에서 IP주소를 받아온다.

이렇게 라우터에서 IP 주소를 자동으로 할당받는 기술을 DHCP(Dynamic Host Configuration Protocol)라고 한다.

DHCP에서는 네 단계 흐름에 따라 통신하여 네트워크 설정을 가져온다.

• DHCP Discover: DHCP 클라이언트가 DHCP 서버를 찾고자 네트워크에 통신을 하는 것
• DHCP Offer: DHCP 서버가 DHCP 클라이언트에 설정을 제안하는 통신을 하는 것
• DHCP Request: DHCP 클라이언트가 DHCP 서버에 제안된 설정의 세부사항을 요청하는 통신을 하는 것
• DHCK ACK: DHCP 서버가 DHCP 클라이언트에 설정의 세부 사항을 지정하는 통신을 하는 것

그림넣기

일반적으로 회사에서 인터넷(네트워크)을 사용할 수 있게 하는 것은 정보 시스템 부서 사람들이다. 또 서버가 네트워크에 연결되도록 준비하는 사람을 네트워크 엔지니어라고 한다. 최근에는 네트워크 엔지니어와 서버 엔지니어를 한꺼번에 인프라 엔지니어라고도 부른다.

SRE(Stie Reliability Engineering)라고 소프트웨어 엔지니어가 시스템 운용을 설계하는 방식이 퍼지기도 해서, 소프트웨어 엔지니어가 인프라를 담당하는 사례도 있다. 

네트워크 엔지니어는 회사의 각 거점끼리 통신할 수 있도록 IP주소를 할당한다. IP주소는 원래 처음부터 할당된 것이 아니고, 네트워크를 설계해서 구현하는 것이다. 최근에는 클라우드를 활용하여 프로그래머가 시스템을 구축할 수도 있게 되었다. 이때 필요한 것이 바로 네트워크 기초 지식이다.

서브넷 마스크

IPv4 주소는 xxx.xxx.xxx.xxx 형식으로 표기한다. 인간이 보기 쉽게 10진수로 표기하지만, 그 실체는 8자리 2진수 4개이다. 또 IP주소는 네트워크부와 호스트부로 나뉜다. 네트워크부는 어떤 네트워크를 나타내는 정보이며, 호스트부는 그 네트워크 안의 컴퓨터를 특정하는 정보이다. 이 두부분으로 IP주소가 구성된다.

IPv4 주소에서 네트워크부가 어디부터 어디까지인지 나타내는 것이 넷마스크(서브넷 마스크)이다. 넷마스크와 서브넷 마스크는 엄밀하게는 의미가 조금 다르다. 그러나 현장에서는 거의 구별 없이 동일하게 사용한다. 

이 장에서 지금부터 등장하는 주소는 다음 네 가지이다. 

• IP주소: 192.168.1.1
• 서브넷 마스크: 255.255.255.0
• 네트워크 주소: 192.168.1.0
• 브로드캐스트 주소: 192.168.1.255

서브넷 마스크의 255.255.255.0을 2진수로 나타내면 11111111.11111111.11111111.00000000 이다. 이 경우 2진수로 나타낸 서브넷 마스크에서 1 부분은 네트워크부, 0 부분은 호스트부가 된다.

서브넷 마스크를 다시 10진수로 치환하면 255.255.255가 네트워크부이고, 끝에 0이 호스브투에 해당한다. 8자리의 2진수 덩어리를 옥텟이라고 하는데, IPv4주소는 옥텟 4개로 되어 있다. 각각을 1옥텟, 2옥텟, 3옥텟, 4옥텟이라고 한다.

이 경우에는 1옥텟에서 3옥텟까지 네트워크부, 4옥텟은 호스트부라고 할 수 있다.

2.2.2. IP주소의 할당과 관리

IP주소는 처음부터 있는 것이 아니라 따로 할당해서 사용한다. 호스트부를 바꾸어 '1은 컴퓨터, 2는 서버, 3은 프린터...' 식으로 IP주소를 할당한다.

호스트부는 2진수 8자리이므로 10진수로 말하면 0~255의 네트워크 호스트부로 사용할 수 있다고 생각할지도 모른다. 하지만 실제로는 할당할 수 없는 숫자가 있다. 

그것은 바로 호스트부의 시작 숫자(0)와 마지막 숫자(255)이다. 호스트부가 모두 0으로 된 것을 네트워크 주소라고 하며, 그 네트워크 자체를 나타낸다.

한편 호스트부를 모두 1로 한 것은 브로드캐스트 주소이며, 로컬 네트워크 전체에 통신을 보낼 때 사용한다. 앞서 소개한 ARP는 브로드캐스트 주소를 사용하여 네트워크 전체에 통신을 보낸다.

즉 호스트부의 처음 1개와 마지막 1개 주소는 컴퓨터 등 기기에 할당할 수 없다. IP주소로 사용자가 사용할 수 있는 IP주소 개수는 256에서 네트워크 주소와 브로드캐스트 주소 2개를 뺀 254개이다.

실제로 라우터 등 네트워크 기기에도 IP주소가 필요하므로 컴퓨터나 프린터 등 기기에 할당할 수 있는 IP주소는 더 줄어든다.

네트워크에 접속하는 기기가 많아지면 IP주소를 별도로 관리해야 한다. 자주 사용되는 고전적인 방식은 마이크로소프트의 엑셀처럼 표 계산 소프트웨어를 이용하여 표 형식으로 관리하는 방식이다. 또 표 형식이 아닌 웹 애플리케이션으로 IP 주소 정보를 관리하거나 네트워크에서 자동으로 IP주소 이용 상황 등을 조사하고 관리하는 툴도 있다. (IPAM)

클래스 및 가변 길이 서브넷 마스크

IP주소는 네트워크부 길이에 따라 클래스가 나뉩니다. 주요 클래스는 아래와 같은 A, B, C 세 가지 유형이다.

• 클래스 A(/8) 11111111 00000000 00000000 00000000
• 클래스 B(/16) 11111111 11111111 00000000 00000000
• 클래스 C(/24) 11111111 11111111 11111111 00000000

그러나 서브넷 마스크가 반드시 클래스를 따라야 하는 것은 아니다. 클래스의 서브넷 마스크 길이를 변경하여 네트워크 크기를 바꾼 것을 가변 길이 서브넷 마스크라고 한다.

예를 들어 회사 네트워크 관리자가 되었다고 가정했을 때, 사내 랜을 구축할 경우 192.168.0.0/24인 네트워크 세그먼트 4를 랜에 할당했다. 이후 회사가 성장하면서 직원 수가 늘어나고 컴퓨터 대수가 증가했으면, 휴대전화나 태블릿 등으로 와이파이를 통해 랜에 접속하는 등 IP 주소가 모자라기 시작한다. 그래서 최소한으로 작업할 수 있는 IP 주소를 늘리는 방법으로 서브넷 마스크를 변경해보기로 한다.

네트워크 192.168.0.0의 서브넷 마스크를 255.255.255.0에서 255.255.254.0으로 변경했다. 호스트부가 넓어져 그만큼 할당할 수 있는 IP 주소도 늘어났다. 호스트부가 너무 크면 ARP등으로 브로드캐스트 통신량이 증가하므로 필요한 만큼 적절한 크기로 설정해야 한다.

2.2.3. 데이터가 바르게 전송되는 메커니즘

다른 네트워크에 속한 컴퓨터와 통신할 때 일어나는 메커니즘.

• 네트워크 A에 속한 컴퓨터 A
• 네트워크 B에 속한 컴퓨터 B
• 네트워크 C에 속한 컴퓨터 C

이렇게 3대의 컴퓨터가 있다고 가정한다. 컴퓨터 A에서 컴퓨터 B와 컴퓨터 C로 통신할 때는 어떻게 동작할까? 

컴퓨터 A에서 컴퓨터 B로 통신할 때의 흐름을 살펴보자.

컴퓨터 A는 컴퓨터 B에 데이터를 보내고 싶지만, 서로 다른 네트워크에 속해 있기 때문에 직접적으로 데이터를 보낼 수 없다. 그래서 라우터라는 네트워크 기기가 개입하게 된다.

컴퓨터 A가 컴퓨터 B에 데이터를 보낼 때 어떤 라우터로 보내야 할지 모르는 경우, 컴퓨터 A는 기본게이트웨이라고 하는 라우터로 데이터를 송신한다. 기본 게이트웨이란 '규정 수신처'를 의미하며, 전송할 라우터가 정해져 있지 않은 경우에는 반드시 이곳으로 보낸다고 규칙으로 정해 놓았다.

컴퓨터 A의 기본 게이트웨이는 라우터(1)이라고 가정하면, 네트워크 A와 네트워크 B에 모두 소속되어 있으므로 컴퓨터A로부터 통신을 컴퓨터 B로 전송할 수 있다. 라우터가 수행하는 작업을 라우팅이라고 한다.

이번에는 컴퓨터 A에서 컴퓨터 C로 통신할 때 움직임을 살펴보자. 이때 컴퓨터 A는 네트워크 C(컴퓨터 C)로 데이터를 보낼 때 라우터 (2)로 보낸다는 것을 알고 있다. 그 정보는 라우팅 테이블이라는 것에 기록되어 있다.

라우팅 테이블에는 네트워크로의 통신을 어느 라우터로 전달해야 하는지 기록되어 있다. 라우팅 테이블에 따라 기본 게이트웨이로 보내거나 직접 대상 라우터로 보낼 수 있는 구조로 되어 있다.

컴퓨터 A는 라우터 (2)에 데이터를 전송하고, 라우터 (2)는 컴퓨터 C에 데이터를 전송한다.

라우터에서 라우터로 전송

라우터도 자신이 속해 있지 않거나 보낼 곳을 모르는 네트워크와 통신해야 할 상황에 놓일 수 있다. 라우터에도 기본 게이트웨이(라우터의 경우는 기본 라우트라고 부르지만, 거의 의미가 같음)가 있다. 기본 라우터로 통신을 전송하면 기본 라우터가 다시 전송처를 찾는 방식으로 버킷 릴레이를 반복하여 네트워크가 성립된다.

내 PC IP주소와, MAC주소 확인하기

1. Windows

- ipconfig /all

2. MacOS

- ifconfig

2.3. 네트워크 프로토콜

2.3.1. 네트워크 계층

L2 스위치

MAC 주소에 따라 데이터를 전송하는 것이 L2 스위치이다. L2 스위치가 등장하기 전에는 리피터라는 장치가 기기와 기기의 접속을 담당했다. 그러나 리피터는 모든 포트에 같은 데이터를 보내고 목적지와 일치하는 컴퓨터가 데이터를 받는 방식으로 동작하기 때문에 쓸데없는 데이터를 많이 전송한다. L2 스위치는 목적지의 MAC주소를 기억하므로 해당 포트에만 데이터를 보낼 수 있어 더욱 효율적으로 통신할 수 있다.

L3 스위치(와 라우터)

L3 스위치(와 라우터)는 L2 스위치에 다른 네트워크를 연결하는 기능이 추가되었다. 라우터에도 다른 네트워크를 연결하는 기능이 있어 그 점에서는 L3스위치와 라우터를 같다고 할 수도 있지만, 세세한 부분에서 차이가 있다.

L3스위치는 포트가 많다는 특징이 있다. 포트란 랜 케이블을 꽂는 구멍을 의미하며, L2 스위치에서 발전한 L3 스위치는 기기와 기기를 접속하는 역할도 담당하기에 일반적으로 라우터보다 많은 포트를 탑재하고 있다.

라우터의 특징

1. 다양한 회선을 수용할 수 있다.
   • 라우터는 전화회선이나 이더넷, 광 회선 등 다양한 회선을 수용할 수 있다.
2. L3스위치보다 보안 측면에서 강하는 점이 있다.
   • L3스위치도 허용할 통신과 차단할 통신을 설정하는 패킷 필터 기능이 있지만, 송수신의 일관성 검사나 위조 방지 같은 패킷 체크 기능은 라우터가 더 뛰어 나다.

L4 스위치, L7 스위치

L4스위치, L7스위치는 로드 밸런서라고도 한다. 로드 밸런싱은 시스템에 대한 요청을 여러 서버에 분산해서 통신량의 균형을 조절하는 기술이다. L4 스위치는 TCP 헤더 등 프로토콜 헤더의 내용을 해석하고 지정된 알고리즘에 근거하여 데이터를 분산해서 전송한다. 주요 배분 방식으로는 라운드 로빈(round robin)과 최소 연결(least connection)이 있다. 라운드 로빈은 분산처 A, B, C에 A->B->C->A-> ... 처럼 순서대로 할당하는 방식이다. 최소 연결은 분산처 A,B,C 중 가장 커넥션이 적은 곳(처리 여유가 있는 곳)으로 데이터를 분산하는 기술로, 각 분산처의 부하를 평준화하는 방식이다.

L7 스위치는 거기에 더해 응용 계층의 내용까지 분석하여 데이터를 분산해서 전송한다. 특정 사용자와 서버의 연결을 유지하는 기능은 L7스위치가 실현한다. 시스템에 따라서는 복수의 서버가 준비되어 있는데, 특정 사용자와 통신을 일정 기간 계속 유지할 필요가 있을 때가 있다. 

예를 들어 웹 사이트에서 쇼핑할 때 등이 있다. 이 경우 다른 서버에 연결되어 불일치가 발생하지 않도록 하는 것이 L7 스위치의 역할 중 하나이다.

2.3.2. TCP와 UDP

TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 IP의 상위인 OSI 참조 모델 4계층에서 동작하는 프로토콜로, 3계층에서 동작하는 IP와 5~7계층에서 동작하는 애플리케이션(HTTP 등)을 중개한다.

TCP와 UDP는 중개하는 역할은 같지만, 각각 다른 특성이 있다. TCP에는 신뢰할 수 있는 통신을 실현하는 기능이 구현되어 있고, UDP에는 신뢰성 확보를 위한 기능이 없는 대신 TCP보다 처리가 빠르다. 

데이터의 일관성이 중요한 애플리케이션은 TCP로, 고속성이나 실시간성을 요구하는 애플리케이션은 UDP로 구분해서 사용한다.

포트 번호

TCP/UDP 모두 포트 번호가 있다. 포트 번호는 통신하는 대상 컴퓨터의 애플리케이션을 특정하는 번호이다.

예를 들어 한 서버에서 웹 서버와 메일 서버를 동시에 실행 중이라고 한다면, 이 경우 IP 주소만으로는 웹 서버로 가는 통신인지 메일 서버로 가는 통신인지 판별할 수 없다. 그래서 목적지 포트 번호를 이용해서 판별하는 것이다.

포트 번호로는 0~65535의 숫자가 사용되며, 세 종류로 분류된다.

잘 알려진 포트 번호(0~1023) 중 자주 사용되는 것을 아래 정리했다.

일반적으로는 잘 알려진 포트 번호를 사용한다. 그러나 서버 측에서 다른 번호를 설정하여 사용할 수도 있다. 보안성의 이유 등으로 SSH 포트 번호를 잘 알려진 포트 번호 22에서 다른 번호로 변경하는 것을 자주 볼 수 있다.

SSH는 네트워크를 통해 서버에 로그인하여 명령어를 실행할 수 있는 편리한 프로토콜이지만, 서버를 탈취할 수도 있기 때문에 종종 공격 대상이 된다. 그래서 공격받을 가능성을 줄이고, 이 서버가 보안 대책이 끝난 것을 과시하기 위해서라도 포트 번호를 22번에서 다른 번호로 변경한다.

동적 포트 번호는 출발지 접속 포트 번호로 이용된다. 예를 들어 컴퓨터에서 웹 브라우저를 2개 실행하여 같은 웹 사이트를 열 때, 출발지 포트 식별 기능이 없으면 올바르게 통신할 수 없다. 이 경우 웹 브라우저 A의 HTTP 접속과 웹 브라우저 B의 HTTP 접속에 각각 다른 출발ㅈ 포트 번호를 할당하여 구별할 수 있다.

2.3.3. ICMP

ICMP(Internet Control Message Protocol)는 TCP/IP가 구현된 컴퓨터 및 네트워크 기기 사이에서 통신 상태를 확인할 때 이용하는 프로토콜이다. OSI 참조 모델 3계층에서 동작하는 프로토콜이며, 계층은 IP와 동일하지만 IP 위에서 동작하는 프로토콜이다. 연결확인 등에 이용되는 ping이나 tracert 명령어 등이 ICMP 프로토콜을 사용하는 프로그램이다.

2.3.4. NAT

NAT(Network Address Translation)는 IP주소를 변환하는 기술이다. 

IP주소에는 프라이빗 IP와 글로벌 IP가 있다. 그중 랜 내에서 사용되는 것이 프라이빗 IP주소이고, 인터넷에서 사용된느 것이 글로벌 IP 주소이다.

여기에서 프라이빗 IP 주소를 가진 컴퓨터로 인터넷상의 글로벌 IP 주소를 가진 서버에 접속한다고 가정한다. 이때 프라이빗 IP 주소인 채로는 인터넷상에서 라우팅할 수 없다. 라우터가 프라이빗 IP 주소를 글로벌 IP 주소로 변환해주어야만 데이터를 전송할 수 있다. 이 기술이 NAT이다.

2.3.5. 프라이빗 IP 주소에 사용할 수 있는 IP 주소

프라이빗 IP주소로 사용할 수 있는 IP 주소는 세 가지 클래스로 정해져 있다. 이런 주소는 글로벌 IP 주소로 사용되지 않으며, 랜 내에서만 사용된다.

• 클래스 A - 10.0.0.0/8
• 클래스 B - 172.16.0.0/12
• 클래스 C - 192.168.0.0/16

클래스 B 프라이빗 IP 주소와 클래스 C 프라이빗 IP 주소는 각 클래스의 서브넷 마스크의 비트 길이보다 짧고 더 큰 네트워크로 할당되어 있지만, 이용할 때는 이 범위에서 다시 /16 이나 /24로 분할한다. 물론 가변 길이 서브넷 마스크로 /23이나 /28처럼 변칙적으로 분할해서 이용할 수도 있다.

2.3.6. CIDR

CIDR(Classless Inter-Domain Routing)은 쉽게 말해 목적지 여러 개를 모은 것이다. 

예를 들어 192.168.0.0/24 ~ 192.168.255.0/24 합계인 256개의 네트워크 세그먼트가 있다고 가정한다. 이것을 라우팅 테이블에 한 줄씩 쓰려면 총 256줄을 써야 한다. 

여기에서 호스트부를 확장해서 192.168.0.0/16 으로 하면 192.168.0.0/24 ~ 192.168.255.0/24의 합계 256개 네트워크 세그먼트 전체를 나타낸 것과 같아진다. 이렇게 라우팅을 모아서 쓰는 것을 라우팅 집약이라고도 한다.

2.3.7. 정적 라우팅과 동적 라우팅

라우터에는 라우팅 테이블이 있다. 라우팅 테이블에는 네트워크로의 통신을 어떤 라우터로 전달하면 좋은지 기록된다. 라우팅 테이블 정보를 관리하는 방법에는 정적 라우팅(static routing)과 동적 라우팅(dynamic routing) 두 가지가 있다.

정적 라우팅

라우팅 테이블을 수동으로 관리하는 기술이다.

정적 라우팅에서는 네트워크를 구축할 때는 물론, 네트워크 구성을 변경할 때 사람이 직접 모든 라우팅 테이블을 서렂ㅇ한다.

동적 라우팅

정적 라우팅에 대해 라우터끼리 정기적 또는 필요에 따라 네트워크 접속 경로에 관한 정보를 교환하고, 이를 바탕으로 라우팅 테이블을 자동으로 설정하는 방법이다.

동적 라우팅으로 정보를 교환하는 방식을 라우팅 프로토콜이라고 하며, 이것도 몇 가지 종류가 있다.

자동이라고 해도 설정만 하면 끝나는 것이 아니라 도입이나 운용할 때 어느정도 손이 간다.

Chapter1. HTTP 동작원리

가. HTML(Hypertext Markup Language)

HTML은 웹 문서를 작성하는 표준 마크업(Markup Language)이다. HTML은 여러 태그로 구성되어 있는데 이러한 태그를 사용해서 개발자가 원하는 형태의 문서 / 그림을 구성할 수 있다. HTML에서 사용하는 명령어를 태그(Tag)라고 하며, 괄호 '<', '>'를 사용하여 태그를 구성한다.

아래의 예제 코드를 통해 HTML의 구조를 살펴보자. HTML 문서는 최상위 태그로 <html>을 사용한다. 하위에는 문서를 정의하는 데이터를 포함하는 <head>태그와 문서의 내용을 작성하는 <body>태그가 올 수 있다. 

HTML 파일의 확장자는 *.html 또는 *.htm을 사용한다. html 또는 htm파일을 웹 브라우저에서 로딩하면 웹 페이지를 확인할 수 있다.

<html>
	<head>
    	문서를 정의하는 데이터가 위치함
    </head>
    <body>
    	문서에 표시되는 내용이 위치함
   	</body>
</html>

나. HTTP (Hypertext Transfer Protocol)

HTTP는 웹 서버와 클라이언트(웹 브라우저) 간에 문서 / 데이터를 교환하기 위한 통신 규약(프로토콜)을 의미한다. 즉, HTML 문서와 같은 자원(리소스)을 처리하는 프로토콜(protocol)로 웹 서버와 클라이언트 간 데이터 교환의 기초가 된다. 다른 말로는 요청(Request) 및 응답(Response) 프로토콜로 표현이 가능하다.

예를 들어, 사용자가 웹 브라우저를 통해 인터넷에 접속하면 HTTP를 이용해서 데이터를 요청하고, 웹 서버는 사용자의 요청을 받아서 처리한 정보를 응답한다. HTTP에 대한 보다 세부적인 내용은 IETF사트에서 확인할 수 있다. HTTP 특징에 대해 간략히 살펴보면 다음과 같다.

1) 비연결지향 (Connectionless)

클라이언트가 HTTP 요청(request)을 서버로 보내면, 서버는 클라이언트 요청에 맞는 응답(response)을 보내고 접속을 끝는다. 즉, 클라이언트와 서버가 계속해서 연결되어 있는 상태가 아니라는 것이다.

2) 상태정보 유지안함(Stateless)

클라이언트와 서버와의 통신이 끝나면 상태 정보는 유지하지 않는 것이다. 클라이언트의 요청을 독립적인 트랜잭션으로 보기 때문에 서버는 이전에 클라이언트의 요청을 항상 해석해야 한다.

이러한 구조적인 한계로 인해 서버는 쿠키와 세션을 사용해서 클라이언트를 식별하게 된다. 예를 들어, 우리가 네이버 웹 사이트를 이용할 때 로그인을 한 번 해두면 별도의 재 인증 과정 없이 메일 / 블로그 /카페를 사용할 수 있는 것이다. (세션 타임아웃이라는 설정으로 일정 시간이 지나면 자동 로그아웃이 되도록 설정할 수 있다.)

나-1) 쿠키(Cookie)와 세션(Session)

쿠키(Cookie)는 클라이언트에 저장되는 키와 값들의 작은 데이터 조각을 의미하며, 이름 / 값 / 만료 날짜 / 경로 등의 정보가 포함되어 있다. 일정 시간동안 데이터를 저장할 수 있으며, 클라이언트의 상태 정보를 로컬에 저장하고 참조한다. 쿠키는 아래와 같은 원리로 생성 및 사용된다.

1) 클라이언트가 브라우저로 웹 페이지에 접속
2) 서버는 클라이언트가 요청한 웹 페이지를 처리하고 쿠키를 클라이언트에 파일로 저장
3) 클라이언트는 서버에 재요청 시 쿠키정보를 호라용해서 서버에 전달
4) 서버는 클라이언트의 쿠키를 활용하여 상태 정보를 유지할 수 있도록 처리

익스플로러 기준으로 인터넷 옵션 - 일반 - 검색기록 - 설정 - 임시 인터넷 파일 - 파일 보기를 클릭하면 PC에 저장되어 있는 쿠키 파일들을 확인할 수 있다.

세션은 쿠키와 다르게 서버의 메모리에 저장되는 정보이다. 일정 시간동안 웹 브라우저를 통해 들어오는 요청을 하나의 상태로 보고 유지하는 기술이다. 즉 사용자가 웹 브라우저를 통해 사이트에 접속하게 되면 브라우저를 종료할 때까지 로그인 유지와 같은 상태가 지속된다. 세션은 아래와 같은 원리로 생성 및 사용된다.

1) 클라이언트가 서버의 웹 페이지에서 로그인 시도
2) 서버는 클라이언트가 요청한 로그인 정보가 맞을 경우, 서버 메모리에 세션ID를 생성하고 클라이언트의 ID와 매핑된 정보를 저장
3) 클라이언트는 세션ID를 쿠키로 저장
4) 클라이언트가 요청할 때마다 서버는 쿠키정보를 확인하고 세션ID와 매핑되는 ID를 사용자로 인증

나-2) 히든 필드(Hidden Field)

히든 필드는 사용자가 보거나 수정할 수 없도록 개발자가 웹페이지의 폼(Form)을 통해 데이터를 전송한다. 입력된 데이터는 GET 또는 POST 메소드를 통해 웹 서버에 전달된다. 다음은 DVWA File Upload실습페이지에서 최대 파일업로드 사이즈를 100000으로 제한하기 위해 폼의 히든 필드를 사용한 사례이다.

<form enctype=\"miltipart/form-data\" action=\"#\" method=\"POST\">
	<input type=\"hidden\" name=\"MAX_FILE_SIZE\" value=\"100000\" />
</form>

히든 필드는 인증 시에도 세션 관리를 위해 사용한다. 다음은 DVWA의 CSRF 실습에서 "dvwa/includes/ dvwaPage.inc.php" 파일 내 tokenField() 함수를 정의하여 세션토큰 값을 반환 시 히든 필드를 사용한 사례이다.

function tokenField() { # Return a field for the(CSRF) token
	return "<input type="hidden" name="user_token" value="{$_SESSION["session_token"]}" />";
}

이처럼 쿠키와 세션 뿐만 아니라 히든 필드를 통해 로그인에 대한 인증 값을 유지할 수 있다.

다. URI / URL / URN

1. URI(Uniform Resource Identifier)

URI는 인터넷에 존재하는 리소스를 고유하게 식별하고 위치를 지정하는 표기법(규약)이다. URI는 URL과 URN을 모두 포함하는 개념이다.

2. URL(Uniform Resource Locator)

URL은 인터넷 상 가용한 자원에 대해 문자(열)로 표현하는 것을 의미한다. 일반적으로 웹의 경우에 클라이언트가 서버로 HTTP 프로토콜을 통해 접속하기 위한 경로로 이해할 수 있다. 

<scheme>:<scheme-specific-part>

scheme은 프로토콜의 종류를 의미하며, 프로토콜에 따라 URL 표기 방식이 달라진다.

예를 들어 FTP의 경우 "ftp://id:pass@host:port/path"의 형태로 표현이 가능하다.

웹의 경우 "http://host:port/path?query"와 같이 표현이 가능하다.

HTTP의 경우 웹 브라우저의 주소가 URL이라고 생각하면 된다. 

3. URN(Uniform Resource Name)

URN은 지속적이면서 특정 위치의 독립적인 자원을 가리키는 지시자이다.

라. HTTP 메시지

1. 요청(Request) 메시지

클라이언트와 서버는 HTTP 프로토콜을 사용하는데 데이터를 패킷 단위로 나눠서 통신을 한다. 다음은 BurpSuite를 통해 DVWA의 Blind SQL Injectionn 공격 패킷을 캡쳐한 내용이다. 요청(Request) 메시지는 크게 (1) Request Line, (2) Reqeust Headers, (3) Message Body로 구성되어 있다.

1-가) Reqeust Line

Request Line은 HTTP 메소드, 클라이언트가 요청하는 Request URI, HTTP 버전으로 구성되어 있다. HTTP 메소드는 키워드 또는 메시지와 같은 개념으로 클라이언트가 웹서버에게 사용자 요청을 하기 위해 요청 목적이나 종류를 알리는 수단을 의미한다.

메소드 종류에는 GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS, CONNECT 등이 있다.

POST > Method

/dvwa/vulnerabilities/sqli_blind/ > Request URI

HTTP/1.1 > HTTP 버전

1-나) Request Headers

HTTP에서 Header는 General, Request, Entity의 3가지로 구분한다.

General Header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더

Request Header: 패치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더

Entity Header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더

Request Header는 클라이언트 요청 및 클라이언트 자체에 대한 추가 정보를 웹 서버에 전달할 수 있게 한다. 요청 패킷의 주요 Request Header 내용은 다음과 같다.

• Host: 클라이언트가 요청한 서버 정보
• User-Agent: 클라이언트 브라우저의 이름, 버전
• Accept: 클라이언트가 허용할 수 있는 파일 형식(MIME_TYPE)
• Referrer:  현재 페이지가 어떤 웹 페이지에서 요청되었는지에 대한 정보
• Accept-Encoding: 클라이언트가 인식할 수 있는 인코딩 형식
• Accept-Language: 클라이언트가 익신할 수 있는 언어

1-다) Message Body

HTTP 메소드가 POST인 경우 HTTP Body 영역에 데이터를 넣어서 전송한다. GET 메소드는 URL에 데이터를 실어서 전달하기 때문에 HTTP Body 영역에는 아무것도 존재하지 않게 된다.

2. 응답(Response) 메시지

응답(Response) 메시지 또한 요청(Request)과 유사한 구조를 가지고 있으며 크게 (1) Status Line, (2) Response Header, (3) Message Body로 구성되어 ㅣㅇㅆ다.

2-가) Status Line

Status Line은 HTTP 버전(HTTP Version), 상태 코드(Status Code), 이유 구문(Reason Phase) 3가지로 구성되어 있다.

HTTP 버전은 현재까지 1.0, 1.1, 2.0으로 구분된다. 

Status Code는 3자리의 정수로 구성된 결과 코드이며, HTTP 요청에 대한 응답의 결과가 모두 코드로 사전에 정의되어 있다.

이유 구문은 사용자가 이해할 수 있도록 상태 코드에 대한 간단한 설명이 기술되어 있다.

2-나) Response Header

Response Header는 서버가 Status Line에 없는 응답에 대한 추가적인 정보를 전달한다. 즉, Request-URI에 의해 식별되는 추가적으로 접근을 하고자 하는 자원과 서버에 대한 정보를 제공한다. 

Accept-Ranges: bytes

서버가 자원에 대해 범위 요청을 수락할 수 있는데, 바이트(bytes) 단위의 범위 요청을 수락한다.

ETag: "307-55c9d62936140-gzip"

ETag는 요청한 변화에 대한 Entity 태그의 현재 값을 제공하며, HTTP 컨텐츠 변경 유무를 검사하는데 사용한다. Entity-tag는 다음과 같이 요청된 값을 고유 형태로 표시한다.

예를 들어, 클라이언트가 동일 URL로 재요청을 할 경우 ETag 값을 요청헤더에 포함시켜서 전송하고, 서버는 수신한 ETag 값과 현재 값을 비교하여 유효성을 검사한다. ETag가 동일하면 기존 데이터 변동이 없음을 알리는 HTTP 304를 반환하고, 동일하지 않을 경우 전체 응답을 전송한다. 

Vary: Accept-Encoding

Vary는 클라이언트와 서버 사이의 캐싱을 위해 필요한 필드이다. 클라이언트가 서버에 데이터를 요청 시 중간의 캐시에 저장된 기존 데이터를 반환함으로써 서버의 성능 부하를 줄일 수 있다. 여기서 Vary 는 캐시에 저장된 기존 데이터를 반환할지 여부를 결정하는 역할을 수행한다. 예를 들어, 클라이언트의 요청의 Accept-Encoding이 gzip으로 반영 되어 있다고 가정하자. 서버에서 이를 수신 시 기존 캐쉬에 gzip이 저장되어 있으면 캐쉬에서 Accept-Encoding을 반환하고,그렇지 않을 경우 서버 측에서 처리하게 된다.

마. HTTP 관련 언어 / 기술

1. 자바스크립트(Javascript)

자바스크립트는 웹 페이지와 상호작용할 수 있도록 만들어진 스크립트 언어이다. 

2. CSS(Cascading Style Sheets)

CSS 는 HTML, XML과 같은 문서의 스타일을 꾸미기 위해 사용하는 스타일시트 언어이다. HTML로는 웹 페이지의 뼈대를 만들고, CSS는 문서를 예쁘게 꾸며주는 역할을 한다. 

일반적으로 HTML문서는 LINK 태그를 사용해서 CSS 파일을 읽어들인다. (HTML 문서 뿐만 아니라 PHP/ASP/JSP 등의 서버 사이드 스크립트 언어에서도 CSS를 로드할 수 있다.) LINK 태그는 HTML 내 외부 문서와의 연결을 지정하는 태그이다. 

(1)사용자가 웹 브라우저에서 HTML 파일을 요청하면, (2) HTML 문서는 LINK 태그에 정의되어 있는 CSS 파일을 읽어와서 HTML 문서의 구조를 스타일링하고, (3) 결과를 사용자 웹 브라우저에 보여준다.

3. XML(eXtensible Markup Language)

4. HTML5

5. PHP(Hypertext Preprocessor PHP)

6. ASP(Active Server Page) / ASP.NET

ASP는 마이크로소프트가 인터넷 정보 서비스에서 개발한 언어로, 동적 웹 페이지 생성 용도로 사용하기 위한 서버 사이드 스크립트 언어이다.

7.JSP(Java Server Page)

JSP는 자바(Java)언어를 기반으로 하는 서버 사이드 스크립트 언어이다.

자바 언어를 기반으로 하기 때문에 자바 라이브러리를 가져다 쓸 수 있다. JSP 는 HTML 에 자바 코드를 포함시켜 동적인 웹 페이지를 구성할 수 있다. 

클라이언트가 웹 브라우저에서 JSP를 요청하면 자바 서블릿(Servlet) 파일로 변환되며 웹 애플리케이션 서버에서 동작되면서 필요한 기능들을 처리하여 클라이언트에 응답 값을 반환한다. 

1) 클라이언트가 웹 브라우저로 서버에 Book.jsp 파일을 요청
2) 서버는 JSP 컨테이너에 처리를 요청하고 JSP 컨테이너는 Book.jsp 파일을 찾아서 로드
3) JSP 컨테이너가 Book.jsp 파일을 자바 서블릿(Servlet) 파일인 BookServlet.java 파일로 변환
4) BookServlet.java 파일을 실행 가능한 BookServlet.class 파일로 컴파일
5) 메모리에 BookServlet.class  파일을 적재하고 실행 결과를 서버로 반환
6) 서버는 클라이언트의 웹 브라우저가 인식할 수 있는 페이지를 구성해서 응답

클라이언트가 웹 브라우저에서 JSP 파일을 요청하면 파싱 / 컴파일  로딩 등의 과정을 거쳐서 서버는 클라이언트가 요청한 웹 페이지 결과를 반환한다.

바. 웹 서버 / WAS / DB 의 이해

웹 서버(Web Server)란 사용자가 웹 브라우저 등을 통해 HTTP(S)와 같은 프로토콜로 데이터를 요청했을 때, 데이터를 처리한 다음 사용자에게 결과를 HTML 형태로 응답해주는 역할을 한다. 

웹 서버는 PHP, JSP, ASP와 같은 서버 사이드 언어를 지원하며, 데이터베이스와의 연동을 통해 데이터를 조회하고 수정한다.

웹 서버에서 서버 사이드 언어를 지원할 수 있도록 도와주는 Apache, nginx, Java, WebtoB, IIS 등의 웹 애플리케이션이 필요하다. 

웹 서버는 정적인 데이터를 처리하고 WAS(Web Application Server)는 동적인 데이터를 처리하도록 하는 것이 처리 속도면에서 효율적이. 주로 WEB 서버는 캐시 기능이나 프록시 기능 등 웹 클라이언트와 직접 연관된 일을 처리하고, WAS는 애플리케이션과 관련된 기능 및 데이터베이스와의 통신을 수행한다.

웹 브라우저 <-> 웹 서버 <-> WAS <-> 데이터베이스/애플리케이션

기능적인 목적뿐만 아니라 보안적인 측면에서도 웹 서버와 WAS를 분리하는 것이 좋다.

웹 서버에 웹쉘 업로드 등의 침해가 내부 시스템 영역으로 확장되는 것을 방지할 수 있기 때문이다. 

IT(전산) 필기 시험 대비 데이터베이스 뿌시기👊🏻

1. KEY

Key란? 검색, 정렬시 Tuple을 구분할 수 있는 기준이 되는 Attribute

1. Candidate Key (후보키)

Tuple을 유일하게 식별하기 위해 사용하는 속성들의 부분 집합 (기본키로 사용할 수 있는 속성들)

2가지 조건 만족

• 유일성: Key로 하나의 Tuple을 유일하게 식별할 수 있음.
• 최소성: 꼭 필요한 속성으로만 구성

2. Primary Key (기본키)

후보키 중 선택한 Main Key

특징

• Null값을 가질 수 없음
• 동일한 값이 중복될 수 없음

3. Alternate Key (대체키)

후보키 중 기본키를 제외한 나머지 키 = 보조키

4. Supre Key (슈퍼키)

유일성은 만족하지만, 최소성은 만족하지 못하는 키

5. Foreign Key (외래키)

다른 릴레이션의 기본키를 그대로 참조하는 속성의 집합

2. JOIN

조인이란?

두 개 이상의 테이블이나 데이터베이스를 연결하여 데이터를 검색하는 방법

테이블을 연결하려면, 적어도 하나의 칼럼을 서로 공유하고 있어야 하므로 이를 이용하여 데이터 검색에 활용한다.

JOIN의 종류

1. INNER JOIN
2. LEFT OUTER JOIN
3. RIGHT OUTER JOIN
4. FULL OUTER JOIN
5. CROSS JOIN
6. SELF JOIN

(1) INNER JOIN

교집합으로, 기준 테이블과 join 테이블의 중복된 값을 보여준다.

SELECT 
A.NAME, B.AGE
FROM EX_TABLE A
INNER JOIN JOIN_TABLE B ON A.NO_EMP=B.NO_EMP

(2) LEFT OUTER JOIN

기준 테이블 값과 조인 테이블과 중복된 값을 보여준다.

왼쪽 테이블 기준으로 JOIN을 한다고 생각하면 편하다

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
LEFT OUTER JOIN JOIN_TABLE B ON A.NO_EMP=B.NO_EMP

(3) RIGHT OUTER JOIN

LEFT OUTER JOIN과는 반대로 오른쪽 테이블 기준으로 JOIN하는 것이다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
RIGHT OUTER JOIN JOIN_TABLE B ON A.NO_EMP = B.NO_EMP

(4) FULL OUTER JOIN

합집합을 말한다. A와 B 테이블의 모든 데이터가 검색된다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
FULL OUTER JOIN JOIN_TABLE B ON A.NO_EMP = B.NO_EMP

(5) CROSS JOIN

모든 경우의 수를 전부 표현해주는 방식이다.

A가 3개, B가 4개면 총 3 * 4개의 데이터가 검색된다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A
CROSS JOIN JOIN_TABLE B

(6) SELF JOIN

자기자신과 자기자신을 조인하는 것이다.

하나의 테이블을 여러번 복사해서 조인한다고 생각하면 편하다.

자신이 갖고 있는 칼럼을 다양하게 변형시켜 활용할 때 자주 사용한다.

SELECT
A.NAME, B.AGE
FROM EX_TABLE A, EX_TABLE B

3. SQL Injection

해커에 의해 조작된 SQL 쿼리문이 데이터베이스에 그대로 전달되어 비정상적 명령을 실행시키는 공격 기법

공격 방법

1) 인증 우회

보통 로그인을 할때, 아이디와 비밀번호를 input 창에 입력하게 된다. 예시로 이해해보자.

아이디가 abc, 비밀번호가 만약 1234일 때 쿼리는 아래와 같은 방식으로 전송될 것이다.

SELECT * FROM USER WHERE ID = "abc" AND PASSWORD = "1234";

SQL Injection으로 공격할 때, input 창에 비밀번호를 입력함과 동시에 다른 쿼리문을 함께 입력하는 것이다.

1234; DELETE * USER FROM ID = "1";

보안이 완벽하지 않은 경우, 이처럼 비밀번호가 아이디와 일치해서 True가 되고 뒤에 작성한 DELETE 문도 데이터베이스에 영향을 줄 수도 있게 되는 치명적인 상황이다.

이 밖에도 기본 쿼리문의 WHERE 절에 OR문을 추가하여 "1" = "1"과 같은 true문을 작성하여 무조건 적용되도록 수정한 뒤 DB를 마음대로 조작할 수도 있다.

2) 데이터 노출

시스템에서 발생하는 에러 메시지를 이용해 공격하는 방법이다. 보통 에러는 개발자가 버그를 수정하는 면에서 도움을 받을 수 있는 존재이다. 해커들은 이를 역이용해 악의적인 구문을 삽입하여 에러를 유발시킨다.

즉 예를 들면, 해커는 GET방식으로 동작하는 URL쿼리 스트링을 추가하여 에러를 발생시킨다. 이에 해당하는 오류가 발생하면, 이를 통해 해당 웹앱의 데이터베이스 구조를 유추할 수 있고 해킹에 활용한다. 

방어 방법

1) input 값을 받을 때, 특수문자 여부 검사하기

로그인 전, 검증 로직을 추가하여 미리 설정한 특수문자들이 들어왔을 때 요청을 막아낸다.

2) SQL서버 오류 발생 시, 해당하는 에러 메시지 감추기

view를 활용하여 원본 데이터베이스 테이블에는 접근 권한을 높인다. 일반 사용자는 view로만 접근하여 에러를 볼 수 없도록 만든다.

3) preparestatement 사용하기

preparestatement를 사용하면, 특수문자를 자동으로 escaping해준다. (statement와는 다르게 쿼리문에서 전달인자 값을 ? 로 받는 것) 이를 활용해 서버 측에서 필터링 과정을 통해서 공격을 방어한다.

4. SQL vs NoSQL의 차이

웹 앱을 개발할 때, 데이터베이스를 선택할 때 고민하게 된다.

MySQL과 같은 SQL을 사용할까? 아니면 MongoDB와 같은 NoSQL을 사용할까?

보통 Spring에서 개발할 때는 MySQL을, Node.js에서는 MongoDB를 주로 사용했을 것이다.

하지만 그냥 다순히 프레임워크에 따라 결정하는 것이 아니다. 프로젝트를 진행하기에 앞서 적합한 데이터베이스를 택해야 한다. 차이점을 알아보자.

SQL(관계형 DB)

SQL을 사용하면 RDBMS에서 데이터를 저장, 수정, 삭제 및 검색 할 수 있음.

관계형 데이터베이스에는 핵심적인 두 가지 특징이 있다.

• 데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
• 데이터는 관계를 통해 여러 테이블에 분산된다.

데이터는 테이블에 레코드로 저장되는데, 각 테이블마다 명확하게 정의된 구조가 있다. 해당 구조는 필드의 이름과 데이터 유형으로 정의된다.

따라서 스키마를 준수하지 않은 레코드는 테이블에 추가할 수 없다. 즉, 스키마를 수정하지 않는 이상은 정해진 구조에 맞는 레코드만 추가가 가능한 것이 관계형 데이터베이스의 특징 중 하나이다.

또한, 데이터의 중복을 피하기 위해 "관계"를 이용한다.

하나의 테이블에서 중복 없이 하나의 데이터만 관리하기 때문에 다른 테이블에서 부정확한 데이터를 다룰 위험이 없어지는 장점이 있다.

NoSQL(비관계형 DB)

말그대로 관계형 DB의 반대다.

스키마도 없고, 관계도 없다.

NoSQL에서는 레코드를 문서(documents)라고 부른다.

여기서 SQL과 핵심적인 차이가 있는데, SQL은 정해진 스키마를 따르지 않으면 데이터 추가가 불가능했다. 하지만 NoSQL에서는 다른 구조의 데이터를 같은 컬렉션에 추가가 가능하다.

문서(documents)는 Json과 비슷한 형태를 가지고 있다. 관계형 데이터베이스처럼 여러 테이블에 나누어담지 않고, 관련 데이터를 동일한 '컬렉션'에 넣는다.

따라서 위 사진에 SQL에서 진행한 Orders, Users, Products테이블로 나눈 것을 NoSQL에서는 Orders에 한꺼번에 포함해서 저장하게 된다.

따라서 여러 테이블에 조인할 필요없이 이미 필요한 모든 것을 갖춘 문서를 작성하는 것이 NoSQL이다. (NoSQL에는 조인이라는 개념이 존재하지 않음)

그러면 조인하고 싶을 때 NoSQL은 어떻게 할까?

컬렉션을 통해 데이터를 복제하여 각 컬렉션 일부분에 속하는 데이터를 정확하게 산출하도록 한다.

하지만 이러면 데이터가 중복되어 서로 영향을 줄 위험이 있다. 따라서 조인을 잘 사용하지 않고 자주 변경되지 않는 데이터일 때 NoSQL을 쓰면 상당히 효율적이다.

확장 방법

두 데이터베이스를 비교할 때 중요한 Scaling 개념도 존재한다.

데이터베이스 서버의 확장성은 '수직적' 확장과 '수평적' 확장으로 나누어진다.

운여하는 서버의 사용자가 많아질수록 서버에 부하가 증가하여 많은 용량과 성능을 요구하게 된다. 이를 해결하고자 서버를 추가로 설치하는 방법과 기존의 서버의 성능을 높이는 방법이 있다. 서버를 추가로 설치하는 것을 수평적 확장(Scale-Out), 서버의 성능을 높이는 것을 수직적 확장(Scale-Up)이라고 한다.

• 수직적 확장: 단순히 데이터베이스 서버의 성능을 향상시키는 것 (ex. CPU업그레이드)
• 수평적 확장: 더 많은 서버가 추가되고 데이터베이스가 전체적으로 분산됨을 의미(하나의 데이터베이스에서 작동하지만 여러 호스트에서 작동)

데이터 저장 방식으로 인해 SQL 데이터베이스는 일반적으로 수직적 확장만 지원함

수평적 확장은 NoSQL 데이터베이스에서만 가능

그럼 둘 중에 뭘 선택?

정답은 없다. 둘 다 훌륭한 솔루션이고 어떤 데이터를 다루느냐에 따라 선택을 고려해야 한다.

SQL장점

• 명확하게 정의된 스키마, 데이터 무결성 보장
• 관계는 각 데이터를 중복없이 한번만 저장

SQL단점

• 덜 유연함. 데이터 스키마를 사전에 계획하고 알려야 함. (나중에 수정하기 힘듬)
• 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있음
• 대체로 수직적 확장만 가능함

NoSQL 장점

• 스키마가 없어서 유연함. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가 가능
• 데이터는 애플리케이션이 필요로 하는 형식으로 저장됨. 데이터 읽어오는 속도 빨라짐
• 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청 처리 가능

NoSQL 단점

• 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있음
• 데이터 중복을 계속 업데이트 해야 함
• 데이터가 여러 컬렉션에 중복되어 있기 대문에 수정 시 모든 컬렉션에서 수행해야 함.(SQL에서는 중복 데이터가 없으므로 한번만 수행이 가능)

SQL데이터베이스 사용이 더 좋을 때

• 관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우

NoSQL에서는 여러 컬렉션을 모두 수정해야 하기 때문에 비효율적

• 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

NoSQL데이터베이스 사용이 더 좋을 때

• 정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
• 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
• 데이터베이스를 수평으로 확장해야 하는 경우(막대한 양의 데이터를 다뤄야 하는 경우)

하나의 제시 방법이지 완전한 정답이 정해져 있는 것은 아니다.

SQL을 선택해서 복잡한 JOIN문을 만들지 않도록 설계하여 단점을 없앨 수도 있고

NoSQL을 선택해서 중복 데이터를 줄이는 방법으로 설계해서 단점을 없앨 수도 있다.

5. 정규화 (Normalization)

데이터의 중복을 줄이고, 무결성을 향상시킬 수 있는 정규화에 대해 알아보자

Normalization

가장 큰 목표는 테이블 간 중복된 데이터를 허용하지 않는 것이다.

중복된 데이터를 만들지 않으면, 무결성을 유지할 수 있고, DB저장 용량 또한 효율적으로 관리할 수 있다.

목적

• 데이터의 중복을 없애면서 불필요한 데이터를 최소화시킨다.
• 무결성을 지키고, 이상 현상을 방지한다.
• 테이블 구성을 논리적이고 직관적으로 할 수 있다.
• 데이터베이스 구조 확장이 용이해진다.

정규화에는 여러가지 단계가 있지만 대체적으로 1~3단계 정규화까지의 과정을 거친다.

제 1정규화(1NF)

테이블 컬럼이 원자갑(하나의 값)을 갖도록 테이블을 분리시키는 것을 말하낟.

만족해야 할 조건은 아래와 같다.

• 어떤 릴레이션에 속한 모든 도메인이 원자값으로만 되어 있어야 한다.
• 모든 속성에 반복되는 그룹이 나타나지 않는다.
• 기본키를 사용하여 관련 데이터의 각 집합을 고유하게 식별할 수 있어야 한다.

위 테이블은 전화번호를 여러개 가지고 있어 원자값이 아니다. 따라서 1NF에 맞추기 위해서는 아래와 같이 분리할 수 있다.

제 2정규화(2NF)

테이블의 모든 컬럼이 완전 함수적 종속을 만족해야 한다.

쉽게 말하면, 테이블에서 기본키가 복합키(키1, 키2)로 묶여있을 때, 두 키중 하나의 키만으로 다른 컬럼을 결정지을 수 있으면 안된다.

기본키의 부분집합 키가 결정자가 되어선 안된다는 것

Manufacture과 Model이 키가 되어 Model Full Name을 알 수 있다.

Manufacturer Country는 Manufacturer로 인해 결전된다. (부분 함수 종속)

따라서, Model과 Manufacturer Country는 아무런 연관관계가 없는 상황이다.

결국 완전 함수적 종속을 충족시키지 못하고 있는 테이블이다. 부분 함수 종속을 해결하기 위해 테이블을 아래와 같이 나눠서 2NF를 만족할 수 있다.

제 3정규화(3NF)

2NF가 진행된 테이블에서 이행적 종속을 없애기 위해 테이블을 분리하는 것이다.

이행적 종속: A -> B, B -> C 면 A -> C가 성립된다.

아래 두가지 조건을 만족시켜야 한다.

• 릴레이션이 2NF에 만족하낟.
• 기본키가 아닌 속성들은 기본키에 의존한다.

현재 테이블에서는 Tournament와 Year이 기본키다.

Winner는 이 두 복합키를 통해 결정된다.

하지만 Winner Date of Birth는 기본키가 아닌 Winner에 의해 결정되고 있다.

따라서 이는 3NF를 위반하고 있으므로 아래와 같이 분리해야 한다.