Tech Log 🛠️

1. 쿠키 인증 방식

쿠키란 서버가 클라이언트의 브라우저에 key value 형태로 저장해놓는 작은 기록파일이다.
쿠키를 이용하여서 간단한 로그인을 구현할 수 있다.
 

쿠키 로그인 인증 방식
 

 
클라이언트에서는 로그인이 필요한 요청을 할때마다 다음과 같이 쿠키에 id, pw 정보를 담아서 전송한다.
위와 같은 작업을 수행하기 위에서는 이미 브라우저에서 로그인이 진행된 후 유저 정보가 쿠키에 들어있어야한다.
 
하지만 쿠키 인증 방식은 여러 문제가 있다.
1. 쿠키값 유효성 검증이 힘들다. (조작 가능성이 있다.)
2. 중간에 탈취해서 id,pw 정보를 확인할 수 있다.
3. 서버에서 매번 인증을 수행해야한다.
4. 브라우저마다 쿠키 형식이 통일되어 있지 않아서 브라우저 간 공유가 어렵다.
 
따라서 쿠키만 이용한 인증 방식의 한계를 보완하기 위해 세션을 사용한 인증 방식이 나오게 되었다.
 

2. 세션 인증 방식

세션은 사용자의 연결을 하나의 상태(세션)으로 유지시키는 기술을 말한다.
 

세션 로그인 인증 방식

쿠키는 매번 id,pw 같은 민감 정보를 전송해야했다면, 세션은 서버의 세션 저장소에 세션 정보를 저장함으로써 보완을 강화했다.
클라이언트는 인증이 필요한 요청을 필요할 때 쿠키에 세션 인증 정보를 함께 보내고 서버는 이를 세션 저장소의 내용과 비교해서 인증 여부를 판단한다.
(마치 매표소에서 티켓의 절반을 떼서 손님이랑 나눠가지는 원리와 비슷하다.)
이렇게 함으로써 인증 요청 시에 민감 정보를 네트워크 상에 노출 시키는 것을 예방할 수 있다.
 
하지만 세션 방식도 여러가지 문제를 안고 있다.
1. 서버가 재부팅되면 세션 저장소가 초기화된다.
2. 스케일 아웃 방식의 확장이 어렵다. -> 모든 서버에 세션 정보를 동기화 시켜야한다.
3. 사용자의 수가 많아지면 관리해야하는 세션 정보가 많아져서 서버의 부담이 된다. -> 무상태(stateless) 위반
4. 세션 인증 정보 탈취의 위험이 있다.
 

3. JWT 인증 방식 

JWT(Json Web Token) 방식은 토큰 기반의 인증 방식이다. 이 방식을 통해 그 동안의 인증 방식에서 나왔던 문제들을 어느정도 개선할 수 있다.
 

JWT 로그인 인증 방식

JWT 토큰 구조는 크게 3가지로 구분된다.
 
header
키값, 토큰 유형, 암호화 알고리즘 같은 정보들을 담고 있다.
 
payload
클레임(claim)이라고 하는 유저의 토큰 인증 정보를 key/value 형태로 담고 있다.
JWT 스펙에서는 표준 claim 목록을 다음과 같이 정의하고 있다. (권장 사항일 뿐 꼭 지킬 필요는 없을 것 같다)
 
iss (Issuer, 토큰 발급자): . 누가 토큰을 발급(생성)했는지
sub (Subject, 토큰 주제): 주제에 대한 설명을 나타냅니다.
aud (Audience, 토큰 수신자): 누구에게 토큰이 전달되는 가
exp (Expiration, 만료 시간): 언제 토큰이 만료되는지
nbf (Not Before): 정의된 시간 이후에 토큰이 활성
iat (Issued At, 토큰 발급 시간): 언제 토큰이 발급되었는지
jti (JWT ID, 토큰 식별자): 토큰의 고유 식별자
 
signature
JWT에서 가장 민감한 부분이다. 해당 값으로 토큰의 유효성을 판별하며 이때 사용되는 시크릿 값을 유출시키지 않는 것이 매우 중요하다.
시크니처는 헤더+페이로드+시크릿 값을 암호화 알고리즘으로 암호화하여서 만들어진다.
따라서 시크릿 값이 조금이라도 다르다면 토큰 내용은 완전 변하게 되어서 인증이 불가능해진다.
 
여기서 주의할 점은 헤더와 페이로드는 암호화가 아닌 base64 방식으로 인코딩 되는 방식이기 때문에 제3자도 토큰만으로도 해당 값들을 열람할 수 있다. 따라서 식별자를 제외한 민감한 정보들을 최대한 넣지 말아야한다!
 
JWT는 클라이언트에게 토큰을 주는 방식이기 때문에 만약 토큰이 탈취 당한다면 서버에서 딱히 할 수 있는 것이 없다.
이 점을 보완하기 위해 리프레시 토큰을 이용해서 기존 토큰의 유효 시간을 짧게 가져가고 새로운 토큰을 지속해서 발급해주는 방식을 사용하기도 한다.

하지만 일정 시간 동안은 탈취된 토큰이 사용될 수 있는 것이기 때문에 근본적인 해결법은 아니다. 그래서 은행 같이 보안에 굉장히 민감한 곳에서는 여러 외부 프로그램을 사용해서 보안을 강화한다.
 

1. 로드 밸런서란?

어플리케이션은 여러 사용자의 요청들을 동시에 처리하고 안정적인 서비스를 제공해주어야한다. 

물론 한 대의 서버로 성능을 계속 키워서 어느 정도는 커버(Scale-up)할 수 있겠지만, 이 방식은 얼마 안가서 한계를 만나게 된다.

따라서 여러 대의 서버를 둬서 요청 부하를 분산하도록 하는 것(Scale-out)이 로드 밸런싱이고 이 역할을 하는게 로드 밸런서이다.

로드 밸런서는 사용자와 서버 사이에 위치하며 모든 리소스 서버가 최적의 성능을 내도록 부하를 분산한다.

2. 로드 밸런싱 사용의 이점

가용성

서버 장애 또는 부하로 인한 딜레이를 로드 밸런싱을 통해 사전에 방지함으로써 어플리케이션의 가용성을 증가시킨다.

다음과 같은 작업을 간편하게 수행할 수 있다.

• 애플리케이션 가동 중지 없이 애플리케이션 서버 유지 관리 또는 업그레이드 실행
• 백업 사이트에 자동 재해 복구 제공
• 상태 확인을 수행하고 가동 중지를 유발할 수 있는 문제 방지

확장성

어플리케이션의 규모나 트래픽이 증가하더라도 로드 밸런싱을 통해 트래픽들을 지능적으로 여러 서버에 분산할 수 있다.

따라서 확장이 용이해진다.

• 한 서버에서 트래픽 병목 현상 방지
• 필요한 경우 다른 서버를 추가하거나 제거할 수 있도록 애플리케이션 트래픽을 예측
• 안심하고 조정할 수 있도록 시스템에 중복성을 추가

보안성

디도스같은 악성 트래픽 공격을 로드 밸런싱을 통해 피해를 최소화 할 수 있다.

악성 트래픽을 여러 서버로 분산시키거나 방화벽을 통해 사전 차단한다.

• 트래픽 모니터링 및 악성 콘텐츠 차단
• 공격 트래픽을 여러 백엔드 서버로 자동으로 리디렉션하여 영향 최소화
• 추가 보안을 위해 네트워크 방화벽 그룹을 통해 트래픽 라우팅

성능 향상

지능적인 부하 분산을 통해 어플리케이션 응답 성능을 향상시킨다.

• 서버 간에 로드를 균등하게 배포하여 애플리케이션 성능 향상
• 클라이언트 요청을 지리적으로 더 가까운 서버로 리디렉션하여 지연 시간 단축
• 물리적 및 가상 컴퓨팅 리소스의 신뢰성 및 성능 보장

참고 : https://aws.amazon.com/what-is/load-balancing/?nc1=h_ls

3. 로드 밸런서의 종류

부하 분산에는 L4 , L7 로드 밸런서가 가장 많이 사용된다.

여기서 L4는 OSI7 계층의 통신 계층, L7은 어플리케이션 계층이다.

따라서 다른 말로 네트워크 로드 밸런서 , 어플리케이션 로드 밸런서라고도 한다.

L4 로드 밸런서

전송 계층의 IP, PORT 같은 정보들을 사용하여 부하를 분산한다.

패킷이나 쿠키같은 데이터들을 분석할 필요없이 비교적 단순하게 작동하기 때문에 L7 로드 밸런서에 비해 빠르고 가볍다는 장점이 있다.

*Client IP와 서버사이에 서버로 들어오는 트래픽은 로드 밸런서를 통하고 나가는 트래픽은 Client IP와 직접 통신한다.

L7 로드 밸런서

애플리케이션 계층(HTTP, FTP, SMTP)에서 로드를 분산하기 때문에 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. ex) 결제 서버, 회원 가입 서버

L7 로드 밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있다.

하지만 기능이 많은 대신 그만큼 자원 소모가 크다는 단점이 있다.

*Client IP와 서버사이에 들어오고 나가는 트래픽이 모두 로드 밸런서와 통신한다.

4. 로드 밸런서 알고리즘

대표적인 알고리즘 딱 3개개만!

라운드 로빈(Round Robin)

요청 받은 순서대로 로드 밸런싱 서버에 할당한다. 

서버들의 성능이 비슷하고 처리 시간이 짧은 경우 유리하다.

가중 라운드 로빈(Weighted Round Robin)

서버간 성능이 다른 경우 서버에 가중치를 부여하여서 부하를 분산한다.

최소 연결 방식(Least Connection)

연결 상태가 가장 적은 서버에 우선적으로 부하를 분산한다. 

세션이 자주 길어지거나 분배된 트래픽들이 일정하지 않을 경우 유리하다.

DNS 라운드 로빈

로드 밸런서를 활용하지 않고 로드 밸런싱을 하는 방법이다. 

DNS 라운드 로빈 방식을 사용하면 네임서버는 사용자가 입력한 도메인에 해당하는 여러 IP 정보들을 응답한다.

클라이언트는 여러 IP 정보중에서 하나를 선택할 수 있으며, 결론적으로 여러 IP로 트래픽이 분산된다.

이 방식은 웹 서버들이 지리적으로 분산되어 있어 부하 분산이 어렵거나 가벼운 구현 방식이 필요할 때 적합하다.

하지만 캐싱으로 인해서 특정 IP에 트래픽이 몰릴 수 있고, 헬스 체크를 하지 못해서 요청한 IP로 연결이 거부될 수 있다는 단점이 있다.

1. DNS란?

도메인은 인터넷에서 사용하는 주소로 비유할 수 있다.

원래 숫자로 된 긴 IP 주소를 사용하지만 실제로 사람들이 이 주소를 기억하기는 어렵다. 그래서 인터넷 상에서 주어진 위치를 쉽게 찾기 위해서 도메인이 개발되었고, 자연스레 도메인을 IP 주소로 변환해주는 도메인 네임 시스템(Domain Name System, 이하 DNS)이 개발되었다.

DNS를 통하여 사용자들은 도메인 이름만 가지고도 쉽게 웹 사이트에 접속할 수 있게 해주며, 설령 주소가 바뀐다고 한들 도메인 이름을 바뀌지 않는다.

이러한 DNS 시스템은 세계적으로 일관된 규칙을 가지며 계층 구조를 가지는 분산 데이터베이스 구조이다.

2. DNS 구성 요소

도메인 네임 스페이스

DNS는 거대한 분산 네이밍 시스템이며, 도메인 네임 스페이스는 이러한 DNS가 저장/관리하는 계층적 구조이다.

최상위에 루트 서버가 존재하고 그 아래로 인터넷에 연결된 노드들이 연속해서 이어진 계층 구조이다.

1. 루트 DNS 서버

TLD DNS 서버의 IP주소를 저장하고 안내한다.

DNS 매핑 과정의 첫 단계이다.

2. TLD 서버

도메인 등록 기관이 관리하며 SLD DNS 서버의 IP주소를 저장하고 안내한다. 

호스트 이름의 마지막 부분을 호스팅한다.

ex) example.com 의 "com"

3. SLD 서버(권한 있는 네임 서버)

실제 개인 도메인과 IP 주소의 관계가 기록된다.

네임 서버 쿼리의 종착점이다. 권한있는 이름 서버가 요청한 레코드에 대한 액세스 권한이 있다면, 요청한 호스트 이름의 IP 주소를 초기 요청을 한 DNS 리커서에게 돌려 보낸다.

4. Resolver , Recursive ,Recurser

쿼리를 통해 IP 주소를 알아낸다.

네임 서버

문자열로 표현된 도메인 이름을 실제 컴퓨터가 통신할 때 쓰는 IP 주소로 변환 시킬 때 사용한다.

네임 서버는 도메인 네임 스페이스의 트리 구조에 대한 정보를 가지고 있다.

리졸버 

DNS 클라이언트의 요청을 네임 서버로 전달하고 네임 서버로부터 정보를 받아 클라이언트에게 제공한다.

먼저 하나의 네임 서버에게 요청을 전달하고 해당 네임 서버에 정보가 없으면 다른 네임 서버에게 요청을 보낸다.

리졸버의 모든 기능을 클라이언트에 구현하는 것은 무리가 있으므로 주로 DNS 서버에서 구현하고, 클라이언트는 단순한 리졸버 기능(리졸버 루틴)만 구현하게끔 한다.

4. 쿼리

재귀적 쿼리(질의)

일반적인 네임 서버 방식이며, 클라이언트(리커서, 리졸버)에게 최종 결과값을 반환한다.

반복적 쿼리(질의)

자신이 직접 관리하지 않는 질의 요청이 올 경우 질의 응답이 가능한 NS 목록을 응답한다.

Root 네임 서버는 무조건 반복적 방식이고 TLD는 일부만 반복적 방식을 사용한다.

5. DNS 동작 방식

1. 사용자가 브라우저에 주소를 입력한다.

2. 브라우저는 DNS 서버에 요청하기 전에 캐시를 확인하여 정보를 찾는다.

3. 만약 정보를 찾기 못하였다면 root 서버에 반복적 질의를 보낸다.

도메인에 대한 정보를 저장하는 최상위 도메인(TLD) DNS 서버(예: .com 또는 .net)의 주소로 확인자에 응답한다.

ex) example.com을 검색할 경우의 요청은 .com TLD 서버를 응답 받음

4. SLD 네임 서버로부터 최종적으로 IP 주소를 응답받는다.

5. 브라우저는 응답 받은 IP 정보로 요청을 전송하고 웹 페이지를 띄울 수 있다.

6. 해당 도메인에 해당하는 정보는 일정 시간 캐싱된다.

HTTP 란

HTTP는 서로 다른 클라이언트와 서버 간 통신을 위한 기초적인 통신 규칙 세트 또는 프로토콜이다. 

사용자가 웹 서비스에 접속하면 클라이언트는 80번 포트를 통해 웹 서버에 HTTP 요청을 보내고 응답을 받는다. 이렇게 함으로써 데이터를 일반 텍스트로 교환할 수 있다.

예를 들어, 사용자가 HTTP의 요청 종류인 GET을 보내면 서버는 그에 맞는 응답 및 상태 코드를 보낸다. 상태 코드 예시는 다음과 같다.

200 - OK(정상)
400 - Bad request(잘못된 요청)
404 - Resource not found(리소스를 찾을 수 없음)

HTTP는 TCP/IP 위에서 작동하는 무상태(stateless) 프로토콜이며 다음과 같은 구조를 가진다.

하지만 HTTP는 평문 데이터를 전송하기에 제 3자가 그 데이터를 조회할 수 있다는 보안 이슈가 있다.

HTTP REQUEST 방식 종류

HTTP 버전 별 차이

HTTP/1.0

기본적으로 연결의 수명이 짧으며 HTTP 요청당 TCP hand-shake가 발생해서 각각 연결을 처리한다.

이로 인해 서버의 오버헤드가 발생하고 *RTT가 늘어나는 문제가 있었다.

RTT(Round Trip Time) : 어떤 메세지가 두 장치 사이를 왕복하는 데 걸린 시간

HTTP/1.1

1.0 버전의 단점을 보완한 프로토콜이다. 크게 3가지의 개선점이 있다.

1. keep alive default

요청할 때마다 TCP 연결을 하는 것이 아닌 keep alive 옵션을 기본 옵션을 함으로써 계속해서 데이터를 받을 수 있다.

2. 호스트 헤더

1.1 버전부터 서버는 여러 대의 호스트를 가질 수 있으며 항상 호스트를 헤더에 포함에서 요청을 보내야한다.

3. Persistent Connection (대역폭 최적화)

지정한 time out 시간 내에 기존 connection을 재사용할 수 있다. 

기존에는 파일을 다운로드 받다가 끊기면 처음부터 받아야했지만, 1.1 버전부터 이어서 다시 다운로드 받을 수 있다.

이외에도 요청을 최소화하기 위한 여러 기술들을 도입했다.

1. 이미지 스프라이트

하나의 이미지만 다운받고 여러 개의 이미지를 다운받은 듯한 효과를 낸다.

2. 코드 압축

3. Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩해서 이미지 서버에 대한 HTTP 요청을 줄인다.

하지만 파일 크기가 더 커진다는 단점이 있다.

HTTP/1.1의 문제점 : HOL

그러나 HTTP/1.1 은 HOL(Head Of Line Blocking)이라는 고질적인 문제가 있었다.

HTTP/1.1부터는 여러 요청을 보내고 순서대로 응답을 받는 파이프라이닝이 가능해졌는데 이로 인해 치명적인 문제가 생겼다.

예를 들어 파이프라인으로 인해 1번 요청에 문제가 생기면 그 뒤에 요청이 줄줄이 지연되는 것이다.

RFC 문서 원칙에 따라 요청이 온 순서대로 처리해야 되기 때문에 다음과 같은 문제가 생겼다.

HTTP/2.0

바이너리 포맷 계층

더 작은 프레임으로 메세지를 전송하기 위해 어플리케이션과 통신 계층 사이에 바이너리 포맷 계층을 추가하였다. 

멀티 플렉싱

단일 TCP 연결에서 스트림을 통해 여러 HTTP 요청과 응답을 비동기적으로 받을 수 있다.

기존에는 다중 TCP 연결을 통해서만 병렬 요청이 가능했지만 HTTP/2.0 부터는 리소스를 작은 프레임으로 나누고 스트림으로 프레임을 병렬적으로 전달한다. 이를 통해 HTTP/1.1의 문제인 HOL을 해결할 수 있다.

또한 각각의 프레임은 스트림 id가 있기 때문에 응답 순서와 상관없이 데이터를 조립할 수 있다.

서버 푸시

클라이언트의 별도 요청이 없더라도 서버가 필요할 것 같은 데이터를 미리 응답에 같이 보낼 수 있다.

헤더 압축

무거운 헤더를 최소화하기 위해 중복된 헤더는 한번만 보내고 중복되지 않은 값은 *허프만 인코딩을 통해 압축시킨다.

허프만 인코딩: 문자열을 문자 단위로 쪼개서 빈도가 높은 정보는 적은 비트수를 사용하고, 빈도가 낮은 정보는 비트수를 많이 사용한다.

우선 순위

서버에서 원하는 순서대로 우선순위를 정해서 리소스를 전달할 수 있다.

HTTP/3.0

TCP 연결로 인한 오버헤드 및 RTT 시간 증가의 문제점을 해결한 버전이다.

이 버전부터 UDP 프로토콜 기반의 QUIC(Quick UDP Internet Connections)로 동작하며 이전 버전들의 장점, 특징들은 대부분 가지고 있다.

또한 QUIC는 TLS로 암호화 통신을 구축할 때 hand shake를 통해 서버와의 연결까지 진행함으로써 1-RTT만에 연결을 수립할 수 있다.

기존 UDP는 데이터의 무결성을 보장하지 못하는 프로토콜이었지만, QUIC는 에러를 검출하고 수정할 수 있는 순방향 오류 제어 메커니즘을 가지고 있다.

HTTPS와의 차이점

HTTP의 보안적인 한계를 SSL/TLS를 사용함으로써 해결한 것이 HTTPS이다.

SSL은 서버와 클라이언트 사이에 암호화 된 연결을 만들어주고 데이터들이 도난되는 것을 방지한다.

SSL 인증서는 클라이언트와 서버 간 주고받는 데이터들을 암호화한다. 그렇기 때문에 데이터가 탈취된다 하더라도 암호화 된 상태이기 때문에 제 3자는 알 수 없다.

또한 SSL 외에도 TLS 프로토콜을 통해서도 데이터 무결성을 제공함으로써 보안을 강화한다.

HTTPS는 보안 상의 이점도 있지만 구글이 안전하다고 신뢰하는 사이트라는 반증이기 때문에 검색엔진 최적화(SEO)측면에서도 많은 이점을 얻을 수 있다.

HTTPS의 동작 방식

HTTPS의 가장 큰 특징은 암호화를 한다는 점인데 암호화 방식은 크게 두가지로 분류된다.

암호화를 통해 의도된 송수신자를 제외하고는 데이터 유출을 방지하고 데이터의 무결성을 보장한다.

대칭키 암호화

클라이언트와 서버가 동일한 키를 하나만 사용해서 암호화한다.

키가 노출될 위험이 있지만 연산 속도가 빠르다는 장점이 있다.

ex)

Plaintext + key = ciphertext: hello + 2jd8932kd8 = X5xJCSycg14=

Ciphertext + key = plaintext: X5xJCSycg14= + 2jd8932kd8 = hello

-> 만약 데이터를 전송하는 과정에서 key를 탈취당하면 제 3자가 데이터를 볼 수 있다.

비대칭키 암호화

두 개의 다른 키로 데이터를 암호화하거나 복호화하고 공개키는 누구나 사용할 수 있다.

예를 들어 공개키로 암호화된 데이터는 개인키로만 복호화가 가능하다.

암호화를 개인키로 할것인지 공개키로 할 것인지에 따라 얻는 효과가 달라진다.

공개키 암호화: 개인키로만 복호화할 수 있으므로 해당 데이터는 자신만 확인 가능하다.

대칭키 암호화 방식은 데이터 전송 과정에서 키가 탈취될 위험이 있었지만 공개키 암호화 방식은 공개키가 탈취되도 상관이 없다.

수신측에서는 공개키로 암호화 한 다음에 다시 개인키로 복호화해서 데이터를 확인할 수 있다.

제3자는 개인키를 가지고 있지 않기 때문에 공개키로 암호화된 데이터를 탈취하더라도 데이터를 확인할 수 없다.

개인키 암호화: 모두에게 공개된 공개키로 복호화하므로 인증된 정보임을 신뢰할 수 있다.

A는 원본 데이터와 개인키로 암호화된 데이터를 전송한다. 그러면 B에서는 공개키를 통해 암호화된 데이터를 복호화하고 해당 데이터가 원본 데이터와 일치하면 신뢰할 수 있는 정보임을 인증할 수 있다.

하지만 공개키로 복호화를 하였을 때 원본 데이터와 다르다면 해당 데이터는 A가 아닌 제3자가 암호화한 데이터이므로 신뢰할 수 없다.

TLS Hand Shaking

SSL은 SSL 1.0 부터 시작해서 명칭이 바뀌어 TLS 1.3 버전에 이르렀다.

TLS는 전송 계층에서 제 3자가 메세지를 도청하거나 변조하지 못하게 보안을 제공하는 프로토콜이다.

이 과정에서 비대칭키 암호화와 대칭키 암호화를 모두 사용하여서 빠른 연산 속도와 안정성을 제공한다.

먼저 처음 연결이 진행될때는 안전한 연결을 위해 속도가 다소 느린 비대칭키 암호화를 사용하고, 이후에는 빠른 통신을 위해서 대칭키를 사용한다.

Client : Client Hello

패킷에 TLS Version, Client가 지원하는 암호화 방식(사이퍼슈트), Client Random Data(클라이언트에서 생성한 난수로 대칭키를 만들 때 사용), 임시 *DH변수, SNI(서버명) 를 담아서 보낸다.

DH 매개변수 : DH는 Die-Hellman을 의미하며 Die-Hellman 알고리즘은 서로 공개값 공유,비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘이다. 모든 TLS 통신이 DH 매개변수를 사용하지는 않음

Server Hello, EncryptedExtensions, Certificate, CertificateVerify

서버는 클라이언트로부터 받은 옵션을 확인하고 공개키가 포함된 인증서와, 서버랜덤값, DH 매개변수를 브라우저에 보낸다.

Client : Client Key Exchange

클라이언트가 서버로부터 받은 DH매개변수(혹은 공개키)를 이용하여 세션키를 생성한다.

이렇게 생성된 세션키를 다시 공개키로 암호화해서 서버에 보내면, 서버는 개인키로 복호화를 할 수 있다.

Server & Client : Finished

클라이언트와 서버의 세션키를 기반으로한 대칭 암호화된 통신이 시작된다.

만약 세션키가 생성된 이후 다시 그 사이트에 방문한다면, 미리 만들어놓은 세션키로 통신하기 때문에 인증에 드는 비용은 없다.

TCP - 전송 제어 프로토콜 

TCP 프로토콜은 순서를 보장하고 연결지향적이라는 특징이 있으며 가상 회선 패킷 교환 방식을 사용한다.

IP의 단점이었던 패킷 손실이나 순서 미보장 같은 문제들을 패킷을 제어하여 해결해 준다.

가상 회선 패킷 교환 방식

가상회선 패킷 교환 방식은 각 패킷에 가상회선 식별자가 포함되고 패킷들이 순서대로 도착하는 방식이다.

모든 패킷을 전송하면 가상 회선이 해제된다.

TCP 프로토콜은 연결을 시작할 때 3 way 핸드셰이크 방식을 사용하며 연결을 종료할 때 4way 핸드 셰이크 방식을 사용한다.

3way 핸드셰이크

- SYN : 클라이언트는 서버의 *ISN과 SYN을 보낸다. 

*ISN : TCP 연결의 첫 번째 패킷에 할당된 임의의 시퀀스 번호이다. 지연 전송된 패킷의 포트 번호로 인식하는 상황을 방지하기 위해 임의의 난수를 사용한다. 또한 임의의 난수를 사용함으로써 예측이 힘들게 만들어 보안을 강화시킨다.

- SYN + ACK : 서버는 클라이언트의 SYN을 받고 응답값으로 서버의 ISN과 승인번호로 ISN + 1을 보낸다.

- ACK : 클라이언트는 서버의 승인 번호를 담아서 ACK를 보낸다.

이 과정이 구축되고 난 뒤에 데이터 전송을 시작하기 때문에, TCP는 신뢰성이 있다고 말할 수 있다.

하지만 모든 통신에서 이 과정을 진행해야 하기 때문에 실시간 처리 같은 속도가 중요시 되는 통신에는 적합하지 않다.

4way 핸드셰이크

- FIN_WAIT_1 : 클라이언트가 연결을 닫으려고 할 때 FIN으로 설정된 세그먼트를 보내면 서버의 응답을 기다리면서 FIN_WAIT_1의 상태가 된다.

- CLOSE_WAIT : 서버는 클라이언트로 ACK라는 승인 세그먼트를 보내고 서버는 CLOSE , 클라이언트는 FIN_WAIT2 상태에 들어간다.

- LAST_ACK : 서버는 ACK를 보내고 일정 시간 이후에 FIN이라는 세그먼트를 보낸다.

- *TIME_WAIT : 일정 시간을 기다린 뒤에 서버로 ACK를 보내서 서버는 CLOSED 상태가 된다. 이후 클라이언트의 연결이 닫히면 클라이언트와 서버의 모든 자원의 연결이 해제된다.

TIME_WAIT : 소켓이 바로 소멸되지 않고 일정 시간 동안 유지되는 상태이며, 지연 패킷이나 연결 오류 등의 문제를 해결하기 위해 존재한다.

2way 핸드셰이크가 없는 이유 : 전송 측 입장에서 자기의 신호가 제대로 전달되었는 지 확인할 수 없다. 이는 TCP의 근본인 양뱡향 연결이 깨져버리게 되고 곧 신뢰성을 보장할 수 없게된다.

TCP 전송 제어

흐름제어

송신 측은 수신 측의 데이터 처리 속도를 파악하고 데이터를 어느 정도로 보내줘야 할지를 제어할 수 있다.

ex) 슬라이딩 윈도우 방식을 사용하여서 동적으로 데이터량을 조절

오류제어

통신 도중에 데이터가 유실되었을 경우에 대해서 대처할 수 있다.

ex) go back n - 데이터가 유실된 시점부터 다시 데이터를 보낸다. 

selective repeat - 유실된 데이터만 선택적으로 보낸다. 

혼잡제어

네트워크 혼잡을 감지하여서 상황에 맞게 송신 측의 데이터 전송량을 조절한다.

ex)

AIMD

- 송신 측이 transmission rate(window size)를 패킷 손실이 일어날 때까지 증가

Slow Start

- Slow Start는 송신 측이 window size를 1부터 패킷 손실이 일어날 때까지 지수승(exponentially)으로 증가

TCP 헤더

TCP 프로토콜은 여러 기능들을 제공해주기 때문에 시퀀스 번호나 ACK 번호같은 다양한 정보들을 헤더에 담고 있다.

TCP의 특징 정리

1. 연결 지향(가상회선 패킷 교환) 방식을 사용한다.

2. 3way , 4way 핸드 셰이크를 통해 연결을 수립하고 해제한다.

3. 신뢰성을 보장하기 위해 여러 전송 제어 기능들을 제공한다.

4. 패킷에 대한 응답을 받아야하기 때문에 상대적으로 속도가 느리다.

UDP - 사용자 데이터그램 프로토콜

데이터그램 단위로 데이터를 전송하는 프로토콜이다. TCP의 고질적인 문제인 속도로 인해서 빠른 처리가 요구되는 현대에 필요성이 대두되었으며 HTTP/3.0에서 표준으로 채택되었다. 

하지만 빠른 속도 대신 전송 제어나 핸드 셰이크(비연결성) 같은 기능들은 제공하지 않는다.

데이터그램 패킷 교환 방식

데이터그램을 사용하여서 데이터의 순서를 신경쓰지 않고 목적지로 라우팅 하는 역할만 수행한다.

이 과정에서 핸드 셰이크나 전송 제어같은 기능도 수행하지 않기 때문에 속도는 더 빨라진 대신 데이터의 무결성은 떨어진다.

UDP 헤더

UDP 프로토콜은 상대적으로 단순하기 때문에 헤더에서도 많은 정보를 담고 있진않다.

checksum 필드를 통해 최소한의 오류 검출은 수행한다.

UDP의 특징 정리

1. 비연결형 프로토콜이며, 데이터그램 패킷 교환 방식을 사용한다.

2. 연결 과정에서 별도의 절차를 거치지 않는다. -> 수신 여부를 확인할 수 없다.

3. 신뢰성이 낮은 대신 속도가 빠르다.

4. 속도가 중요시되는 실시간 서비스에 적합하다.

메모리 계층 구조 

메모리는 다음과 같이 계층 구조로 구성되어있다. 일반적으로 상위 계층으로 갈수록 속도는 빨라지는 대신 가격은 비싸진다.

속도가 빠른 캐시나 레지스터에 모든 프로세스를 저장해놓으면 좋겠지만 그러지 못하는 이유가 경제성 때문이다.

따라서 느린 저장장치에 데이터를 저장해놓고 빠른 장치는 필요할 때마다 데이터를 불러와서 처리하는데, 메모리와 CPU 사이의 속도 차이가 너무 크기 때문에 중간에 레지스터 계층과 캐시 계층을 두어서 관리한다.

캐시

위에서 말했던 것처럼 캐시는 필요한 데이터를 보관하는 임시 저장소이자 병목 현상을 줄이기 위한 메모리이다.

캐시를 통해 CPU의 연산 속도와 메모리 접근 속도의 차이를 완화할 수 있다.

계층적 캐시 메모리

메모리 구조가 그랬던 것 처럼 캐시 메모리 또한 캐시를 계층적으로 관리한다.

일반적으로 L1, L2 캐시는 CPU 코어 내부에 위치하며 L3는 CPU가 아닌 메인보드에 위치한다.

참조 지역성의 원리

필요한 데이터가 캐시에 있는 경우를 캐시 히트라고 하고 없는 경우를 캐시 미스라고 한다. 당연히 캐시 히트가 많이 일어나는 것이 좋은 건데, 적중률을 높이기 위해 지역성의 원리가 사용된다.

*캐시 히트는 CPU 내부 버스를 사용하고 캐시 미스는 시스템 버스를 사용한다. (당연히 CPU 내부 버스가 더 빠르다!)

지역성은 두가지로 구분된다. 예시 코드와 함께 보면 이해가 쉽다.

List<Integer> list = new ArrayList<>();

for(int i=0;i<10;i++) {
	list.add(i);
}

시간 지역성

- CPU는 최근에 사용했던 메모리 공간에 다시 접근하는 경향이 있다.

- 예시 코드에서 변수 i에 대해서 계속해서 접근이 이루어지고 있다.

참조 지역성

- CPU는 최근에 사용했던 메모리 공간 근처를 접근하는 경향이 있다.

- 예시 코드에서 list 공간에 계속해서 접근하고 있다.

캐시 매핑

캐시 메모리는 매우 작고 주 메모리를 크기 때문에 캐시를 어떻게 매핑하느냐가 매우 중요하다. 또한 CPU에서 캐시를 탐색할 때 효율적으로 탐색을 할 수 있어야한다.

직접 매핑

- 메모리가 1~100이 있고 캐시가 1~10이 있다면 1:1~10 , 2: 11:~20 .. 같은 방식으로 저장한다.

- 구현이 간단하고 처리가 빠르지만 충돌(스와핑)이 잦다.

연관 매핑

- 순서와 블록 상관없이 자유롭게 매핑을 할 수 있다.

- 충돌은 덜 일어나지만 모든 블록을 탐색해야하므로 속도가 상대적으로 느리다.

집합 연관 매핑

- 직접 매핑과 연관 매핑의 절충안이다.

- 정해진 장소(직접 매핑) 내에 어느 장소에나(연관 매핑) 매핑이 가능하다.

- 직접 매핑에 비해 저장이 빠르고 연관 매핑보다 검색이 빠르다. 

캐시와 레지스터의 차이

레지스터는 CPU 내에서 연산을 처리하기 위해 데이터를 저장하는 메모리이며, 캐시는 메인 메모리와 CPU 간의 속도 차이를 극복하기 위한 메모리이다.

레지스터는 CPU 내부에 위치해 있으며 캐시는 CPU와는 별도로 존재한다. 

네트워크란

통신 분야에서 단말기 등을 접속하기 위해 사용되는 단말기기, 선로 및 교 환기 등으로 구성되는 전송매체이다.

프로토콜

통일을 위한 상호 간의 규약(약속)이다.

프로토콜의 구성 요소

1. 구문(syntax)

- 데이터를 어떻게 구성할지 , 코딩 방법 , 신호 레벨 등에 대한 정보

- 데이터 포맷(형식), 부호화, 신호 레벨 등

2. 의미(semantic)

- 데이터나 예외에 대해 어떻게 처리할 것인지에 대한 정보

- 특정 패턴을 어떻게 해석하고, 어떤 동작을 할 것인가 결정

3. 타이밍(timing) 

- 통신이 이루어질 때 데이터를 주고 받을 속도에 대한 조절과 여러 데이터가 동시에 통신을 해야 할 경우 순서 관리를 위한 기법

- 속도 일치 및 순서 제어

프로토콜의 역할

1. 에러 제어 (Error Control)
     - 전송 중 에러 검출 및 에러 정정
2. 캡슐화 (Encapsulation)
     - 통신계층 상의 각 계층이 자신 만의 특정제어정보(주로 Header)를 추가하는 것
3. 연결 제어 (Connection Control) 또는 세션 관리
     - 연결지향적 통신에서 연결설정,데이터전달,연결종료 절차의 제어
4. 순서 제어 (Sequence Control)
     - 순서 역전, 중복 패킷 발생 등의 방지
5. 흐름 제어 (Flow Control)
     - 보낼 데이터량/전송률의 제한
6. 혼잡 제어 (Congestion Control)
     - 포화/대기 패킷 수의 제한을 위한 제어 기법
7. 동기화 (Synchronization)
     - 송수신 양측 간에 시간 관계(주로,위상)의 일치
8.주소 지정 (Addressing)
     - 호스트/디바이스/프로세스 등을 유일하게 식별할 수 있는 방법을 제공
9. 단편화 및 재조립 (Segmentation and Reassembly, Fragmentation and Reassembly)
     - 데이터 패킷을 전송에 적당한 크기로 분해,조립
10. 데이터의 형식화 (Data Formatting) 등

패킷

패킷 스위칭 방식에서 네트워크를 통해 전송되는 데이터 블록이다.

패킷을 사용하는 이유

데이터를 한번에 보내게 된다면 통신 대역폭을 많이 차지하기 때문에 다른 데이터의 전송이 지연되며 이는 곧 통신의 문제로 이어질 수 있다.

패킷 구조

네트워크 패킷은 헤더(Header), 페이로드(Payload), 트레일러(Trailer) 세 부분으로 구성

1. 헤더

- 패킷 길이, 프로토콜, 보낸/받는 사람의 IP 주소 등이 포함

- 패킷의 주소(송수신 주소) 등 주요 제어 정보들이 포함

2. 페이로드

- 패킷의 본문 (내용 , 데이터)

3. 트레일러 (footer)

- 패킷의 끝에 도달했음을 수신 컴퓨터에 알리는 비트 포함

- 패킷 에러 검출 등에 사용 
- 패킷 꼬리가 없는 경우도 많음

CBN(Curcuit Based Network) vs PBN(Packet Based Network)

CBN

1. 전화망에 사용

2. 연결 지향 (connection-oriented)

3. 자원 점유 -> QoS 보장

PBN

1. 인터넷

2. connection less service

3. 자원 공유 방식 -> QoS 보장x , Best effort

OSI 7 Layer

7계층 - 응용 계층

통신을 위한 어플리케이션 - 카카오톡

GUI로 구성 된 경우가 많다.

주요 프로토콜 - TELNET, FTP, SMTP, HTTP 등

6계층 - 표현 계층

데이터를 어떻게 표현할 지에 대해 결정

Codec(coding+decoding) 관련 인코딩/디코딩, 압축/해제, 암호화/복호화 등의 역할을 수행한다.

ex) avi, mp4, mp3

5계층 - 세션 계층

사용자의 구분. 누구와 통신 할 것인가? 에 대해 결정

Session ID : 누구와 통신 할 것인지를 구분할 수 있도록 알려주는 구분자 (ID)

TCP/IP 통신 연결을 수립/ 유지/중단

4계층 - 전송 계층

어떤 *port로 전송할 것인가? 에 대해 결정

port : process를 특정하기 위한 주소

포트의 종류

0~1023: well-known port. 표준화되어 있는 포트

– 20 FTP, 23 Telnet, 53 DNS, 80 HTTP, 433 HTTPS

1024~49151: registered port. 상업적인 어플리케이션을 개발하는 회사들이 등록하 여 사용하는 포트

49152~65535: dynamic port. 사용자(개발자) 자유롭게 즉흥적으로 할당하여 사용할 수 있는 포트

UDP vs TCP

UDP: TCP 대비 프로토콜이 간결함. 가볍고 빠름. QoS 보장 x

– real-time service: 실시간 비디오

TCP: UDP 대비 프로토콜이 복잡함. 무겁고 느림. UDP 대비 QoS 일부분 보장

– retransmission, timeout 특성을 가지고 흐름제어, 오류제어

– non-real-time service: email 서비스, 문자 서비스

3계층 - 네트워크 계층

End to End 통신을 담당 (source-to-destination)

라우터를 통해 IP를 사용하여 통신한다. (라우팅)

- DNS를 이용하여 도메인 이름으로 IP를 알 수 있다.

주요 프로토콜 - IP, ARP, ICMP, IGMP, RIP, RIP v2, OSPF, IGRP, EIGRP, BGP 등

2계층 - 데이터 링크 계층

스위치를 통해 *MAC 주소를 이용하여 목적지를 찾아간다 (hop by hop , node to node)

MAC : 고유한 하드웨어 주소

주요 프로토콜 : HDLC, X.25, Ethernet, TokenRing, DFFI, FrameRelay 등

1계층 - 물리 계층

디지털 데이터를 아날로그적인 전기적 신호로 변환

데이터를 비트형태로 표현

Topology: 망의 구성

ex) Star, mesh, bus…

TCP/IP Layer

OSI 참조 모델을 기반으로 상업적이고 실무적으로 이용될 수 있도록 단순화된 현실화의 과정에서 채택된 모형이다. 

인터넷이 발전되는 과정에서 대부분 TCP/IP 계층 구조를 사용했기 때문에 지금도 대부분의 통신이 사용하고 있는 프로토콜 구조이다.

TCP/IP 계층은 OSI 7 계층 구조와 달리 4개의 계층을 가지고 있다.

어플리케이션 계층 , 전송 계층 , 인터넷 계층 , 네트워크 인터페이스 계층으로 구성되어 있으며 각각의 계층은 서로 영향을 받지 않도록 설계되었다.

1. 어플리케이션(application) 계층

FTP , HTTP 같은 응용 프로그램이 사용되는 프로토콜 계층이며 실질적으로 사람들에게 서비스를 제공해준다. 

OSI 7 계층의 어플리케이션 계층과 흡사

2. 전송 계층(transport) 계층

송신자와 수신자를 연결해주는 통신 서비스를 제공한다. 

전송 계층에서 사용하는 기술로는 TCP와 UDP가 있으며 어플리케이션 계층과 인터넷 계층 사이에서 중계 역할을 한다.

OSI 7 계층의 전송 계층과 흡사

3. 인터넷 계층

네트워크 패킷을 IP 주소로 지정된 목적지로 전송한다. 

*ARP , IP 같은 기술을 사용하며 데이터의 수신 상태를 보장하지 않는 비연결형 통신을 제공한다.

OSI 7 계층의 네트워크 계층과 흡사

ARP : IP주소에 해당하는 MAC 주소를 매칭시켜주는 프로토콜 , 반대의 개념으로 RARP도 있다.

4. 네트워크 인터페이스 계층

전선 , 광섬유 , 무선 등으로 실질적으로 데이터를 전달한다. -> 장치 간의 신호를 주고 받는 규칙을 정한다.

물리 계층과 데이터링크 계층으로 나누어 보기도 한다. 

물리계층은 무선 LAN이나 유선 LAN을 통해 0과 1로 이루어진 데이터를 전송하고 데이터 링크 계층은 이더넷 프레임을 통해 MAC 주소를 사용하여 전송한다.

계층 간 데이터 송수신 과정

기본적으로 요청 값들이 캡슐화되어서 전달되고 요청 받는 서버가 다시 비캡슐화 과정을 거치면서 데이터가 전송된다.

Encapsulation과 Decapsulation

Encapsulation - 상위 계층의 헤더와 데이터를 하위 계층의 데이터 부분에 포함시키고 해당 계층의 헤더를 삽입한다.

Decapsulation - 하위 계층에서 상위 계층으로 가면서 각 계층의 헤더 부분을 제거한다.

OSI 7 Layer 또는 TCP/IP Layer에서 계층화하는 이유

네트워크를 이루고 있는 구성 요소들을 계층 별로 나누고 표준화함으로써 포트 , 프로토콜의 호환 문제를 해결할 수 있다.

(각 계층끼리만 통신하기 때문)

문제가 발생했을 때 계층들간의 영향을 주지 않기 때문에 문제 생긴 계층의 범위 내에서 원인을 추적해나갈 수 있다. 

또한 각 계층의 장비나 기술의 변경에 대해 유연하다는 장점이 있다.

IP(Internet Protocol)란?

인터넷에서 네트워크의 두 호스트(host) 간에 통신할 때 호스트 주소를 지정하고 전송 계층의(transport layer)의 정보를 패킷으로 분할/조립하며, 패킷을 IP 주소에 따라 목적지에 전송하는 통신 규약이다.

송신측에서는 패킷에 목적지 주소를 표기하고 각각의 라우터들은 해당 목적지를 확인하고 라우팅 테이블을 참조하여 다음 라우터로 라우팅시킨다. 최종적으로는 목적지까지 패킷을 전송한다.

이렇게 패킷이 여러 개의 라우터를 건너가는 것을 hop-by-hop 통신이라고 한다.

IP 주소란?

IP주소란 네트워크에 연결되어 있는 디바이스의 네트워크상 주소(식별자)이다.

IPV4 vs IPV6

IPv4 체계 주소의 고갈과 확장성 면에서의 한계로 인해 나온 새로운 주소 체계이다. IPv4는 클래스 기반의 할당 방식을 사용했는데 이 방식은 사용하는 주소보다 버리는 주소가 많은단점이 있었고 확장성에 한계가 있었다.

따라서 더 많은 주소를 가질 수 있고 차세대 멀티 미디어 환경에도 용이한 IPv6가 나오게 되었다.

IPv4는 32비트를 8비트 단위로 점을 찍어서 표현한다. ex) 123.45.67.89

IPv6는 64비트를 16비트 단위로 점을 찍어 표기한다. ex) 2001:db8:ff00:42:8329

아직까지는 여전히 IPv4가 가장 많이 쓰이는 주소 체계이다.

IPv64와 IPv6의 차이점 비교

IPv4의 주소 부족현상을 해결하기 위한 방법

DHCP

- 주소를 수동으로 할당할 필요 없이 인터넷에 접속할 때마다 IP주소를 자동으로 할당 받는다. (plug & play)

NAT

- 패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP 정보를 수정하여 다른 주소로 매핑한다.

IPv4 체계로는 많은 주소들을 감당하지 못했었는데 이를 해결하기 위해 공인 IP와 사설 IP로 나누어서 주소를 처리하게 되었다.

NAT를 통해 하나의 공인 IP로 사용자들은 각각의 다른 IP를 가진것처럼 인터넷을 이용할 수 있다. (공유기에서 주로 사용된다.)

CISC란?

CISC(Complex Instruction Set Computer)란 많은 수의 다양하고 중복되는 명령어 집합이다.

*명령어 집합:CPU가 이해할 수 있는 명령어들의 모음

사용자가 이해할 수 있는(고급 언어) 하나에 각기 다른 기계 명령어를 대입 시킴으로써 명령어수가 많고 가변 길이를 가진다.

명령어 수가 많고 상대적으로 적은 수의 명령어로도 프로그램을 실행할 수 있다. (메모리 사용이 적다.)

CISC의 명령이의 길이가 고정되어 있지 않은 이유는 각각의 명령어가 프로세싱 성능을 극대화하도 록 설계되었기 때문이다.

하지만 명령어의 수가 많다고 하더라고 실제로는 쓰이는 명령어들만 주로 쓰이고 명령어를 사용해서 메모리 파이프라이닝이 불리하다는 단점이 있다. 또한 상대적으로 많은 전력을 소모한다.

특징

1. 강력한 기능을 수행하는 다양한 명령어들이 있다.

2. 상대적으로 메모리를 적게 소비한다.

4. 가변 길이 명령어를 사용한다.

5. 명령어가 실행되는 데 하나 이상의 클럭 주기를 가진다.

6. 다양한 주소 지정 방식을 사용한다.

7. 컴파일 과정이 쉽고 호한성이 좋다.

단점

1. 명령어 실행 시간이 파이프라인을 만들기에 불리하다.

2. 상대적으로 많은 전력을 소비한다.

RISC란?

RISC(Reduced Instruction Set Computer)란 축소된 명령어의 집합이다.

CISC와는 여러 차이점이 있는데 대표적으로 명령어의 수가 100개 미만으로 줄어들었다. 인식 가능한 명령어의 수를 줄임으로써 속도를 향상시키지만 프로그램을 실행 시키는데 더 많은 명령어가 필요하다.

RISC는 신속한 프로세싱을 달성하기 위한 파이프라인 프로세싱의 일환으로서 고정길이 명령어를 사용하며,CISC와 달리 클럭 주기당 하나의 명령어를 실행한다. 단일 사이클의 명령어를 실행함으로써 명령어 실행 과정을 파이프라인으로 구현할 수 있다. 

특징

1. 모든 데이터 처리는 레지스터에서 수행되며 load-store 구조를 사용하여 메모리 접근을 최소화하였다.

2. 단순한 고정 길이 방식의 명령어를 사용한다.

3. 적은 주소 지정 방식을 사용한다.

단점 

1. 컴파일러의 최적화 과정이 복잡하다.

2. 명령어가 고정되어 있어서 코드 효율이 낮다.

3. 파이프라인 해저드에 대한 조치가 필요하다.

결론

둘 다 장단점을 보유하고 있어서 어느 쪽이 성능 면에서 우세하다고 볼 수는 없다. 

또한 오늘날의 몇몇 CISC MCU는 RISC의 장점을 일 부 공유하고 있으며, 몇몇 RISC MCU는 CISC의 장점 을 일부 공유하고 있기 때문에 각자의 상황에 맞는 선택이 필요하다.

커널이란?

커널이란 운영체제 내부에서 자원들을 관리하고 추상화 해준다. 이 덕분에 사용자는 내부 하드웨어에 직접 접근하지 않고도 간편하게 프로그램을 실행할 수 있다. 여기서 자원은 CPU, 메모리 , 입출력 장치 같은 것들을 나타낸다.

또한 커널은 자원을 관리하기 위한 여러 관리자들이 있다.

1. 테스트 관리자 : 물리적 자원인 CPU를 추상 자원인 테스크로 제공한다.
2. 메모리 관리자 : 물리적 자원인 메모리를 추상 자원인 페이지나 세그먼트로 제공한다.
3. 파일 시스템 관리자 : 물리적 자원인 디스크를 추상 자원인 파일로 제공한다.
4. 네트워크 관리자 : 물리적 자원인 네트워크 장치를 추상 자원인 소켓으로 제공한다.
5. 디바이스 드라이버 관리자 : 각종 외부 장치(프린터, GPU 등)에 대한 접근을 제공한다.

커널의 동작 방식

커널은 Memory Resident 한 프로그램이다. 일반적으로 프로그램들은 디스크에 상주해있는데, 커널은 메모리에서 여러 명령들을 처리한다. 

하지만 커널은 사용자의 명령을 직접적으로 받지 않고 쉘이란 프로그램을 통해서 명령을 전달받는다. 즉 쉘을 통해서 커널에게 명령을 내릴 수 있는 것이다.

쉘의 역할

프로그램들이 언제 메모리에 로딩되고 해제되는지 관리해주는 프로그램이다. 여러 프로그램들의 메모리를 관리해주며 커널의 중간다리 역할을 수행하기도 한다.

일반적으로 운영체제가 부팅되면 Memory Resident한 특성을 가지는 커널이 먼저 메모리에 올라온다.

그 후 유저가 터미널을 실행하면 쉘이 메모리에 올라오고 유저가 입력한 커맨드에 맞는 잡(job)을 메모리에 올린다.

이런 과정으로 유저는 프로그램을 내부적인 구조를 신경쓰지 않고 실행시킬 수 있는 것이다.

하지만 이런 리눅스 환경은 신경써야 할 점이 하나 있다. 바로 멀티유저 시스템이라는 점이다.

윈도우는 개인pc용 운영체제여서 보안에 대한 부담이 리눅스에 비해 적을 수 있지만, 여러 사용자가 이용하는 리눅스는 보안을 특별히 더 신경써야한다.

만약 유저A가 유저B의 파일에 맘대로 접근할 수 있다면 어떨까? 이는 심각한 문제를 초래할 수 있다. 

따라서 운영체제는 커널모드와 유저모드를 나누어서 입출력 작업 같이 자원에 접근하는 일들은 커널에서 담당하도록 하였다.

이때 커널에게 해당 작업을 요청하는 것을 시스템 콜이라고 한다.

유저 모드에서 시스템 콜이나 인터럽트가 발생하게 되면 커널 모드로 진입한다.

시스템 콜의 종류는 다음과 같은 역할들을 수행한다.

프로세스/스레드 관련 처리

파일 I/O 관련 처리

소켓 관련 처리

디바이스 관련 처리

프로세스 통신 관련 처리

물론 모든 커맨드에 대해서 시스템 콜이 커널로 명령을 전달해주면 이는 무용지물일 것이다. 그래서 해당 명령이 적합한 명령인지를 판단하는 바이너리 비트를 CPU에 두는데, 이를 mode bit라고 한다. 1이면 커널모드 0이면 유저모드라고 알려져있다.

커널모드에서는 모든 자원에 대한 접근이 가능한데 이때 I/O 같은 작업들을 수행하고 시스템 콜의 리턴값으로 해당 작업에 대한 결과를 받는다. 그리고 해당 작업이 종료되면 다시 유저모드로 돌아가서 프로그램을 실행한다. 이 작업이 한번만 진행되는 건 아니고 프로그램이 실행되면서 수없이 커널모드와 유저모드를 왔다갔다한다.

인터럽트란

앞서 인터럽트가 발생하였을 때 커널 모드로 진입한다고 하였다. 이 때 인터럽트는 무엇이고 왜 발생할까? 

인터럽트는 시스템에서 발생한 다양한 종류의 이벤트 혹은 그런 이벤트들이 발생했을 때 알려주는 메커니즘이다.

인터럽트들이 발생하면 CPU에서는 인터럽트 처리를 위해 커널 모드로 진입한다.

하드웨어 혹은 프로그램이 인터럽트 라인에 인터럽트를 세팅하면 인터럽트가 발생한다. 이때 인터럽트 벡터를 통해 인터럽트 서비스 루틴을 실행해서 인터럽트를 처리한다.

인터럽트 벡터

인터럽트 서비스 루틴(핸들러)의 주소를 담고 있는 테이블

인터럽트 서비스 루틴

실제 인터럽트를 처리하기 위한 루틴

참고로 프로그램 레벨에서 발생하는 인터럽트는 트랩이라고 불리며 하드웨어 인터럽트보다 우선 순위가 높다.

외부 인터럽트

전원에 문제가 생겼을 때

I/O 작업이 완료되었을 때

타이머 시간이 끝났을 때

내부 인터럽트

0으로 나눴을 때

잘못된 메모리 공간에 접근을 시도할 때

소프트웨어 인터럽트

프로그램 처리 중 명령의 요청에 의해 발생하는 데, 대표적으로 SVC에 의한 call이 있다.

인터럽트는 다음과 같은 우선 순위를 가진다.

1. 전원 이상(Power fail)
2. 기계 착오(Machine Check)
3. 외부 신호(External)
4. 입출력(I/O)
5. 명령어 잘못
6. 프로그램 검사(Program Check)
7. SVC(SuperVisor Call)

시스템 콜 & 인터럽트의 동작 과정(예시)

싱글 코어 환경에서 쓰레드1(t1)과 쓰레드2(t2)가 있다고 가정해보자

t1에서 file read 요청이 들어왔다.

이때 file read에 해당하는 시스템 콜이 호출되며 기존 t1의 상태를 저장하고 커널 모드로 진입한다.

커널모드에 진입한 t1은 해당 file이 read 가능한 상태가 될때까지 waiting 하게 되며 다시 유저 모드로 진입 후 t2가 실행되게 된다.

t1에서 요청한 file이 read 요청을 처리할 준비가 되었다.

이때는 아까와 다르게 시스템 콜이 아닌 인터럽트가 호출된다. 다시 CPU는 t2의 상태를 저장하고 t1을 waiting에서 ready(runnable)로 상태를 바꾼다. 그런 다음 유저모드로 진입 후에 t2를 실행한다.

모종의 이유로 t2의 CPU 점유가 중단되는 일이 생길 것이다.

CPU는 다시 커널 모드로 진입 후에 t2를 ready 상태로 바꾼다. 이제는 t1을 실행 상태로 바꾸고 작업들을 처리하면 된다.

하지만 사용자는 직접적으로 시스템 콜을 호출할 일이 없는데 이는 하이(high) 레벨 언어가 시스템 콜을 호출할 수 있도록 래핑(wrapping)을 통해 제공하기 때문이다. 대표적으로 스레드를 start 할 때 native 코드를 통해서 JNI(Java Native Interface)가 해당 운영체제에 맞는 시스템 콜을 호출해준다.

private native void start0();

0. 만약 인덱스가 없었다면

인덱스 없이 테이블에 대한 탐색을 한다고 가정해보자

num의 값이 27인 행을 찾는 다고 가정했을 때 인덱스가 없다면 , 정렬 되지 않은 데이터를 처음부터 찾아야한다.

이럴 경우 하나의 데이터를 찾기 위해서 최악의 경우 모든 값을 탐색하는 풀 스캔을 해야할 수도있다.

이는 매우 비효율적인 방법이다.

인덱스가 없는 경우 어떤 현상이 일어나는 지 알아보았으니, 그럼 이제 인덱스가 적용 된 경우를 살펴보자

처음 예시와의 차이점은 데이터가 정렬되어 있고 무작정 처음부터 조회하지 않는다.

이 경우 정렬된 데이터들로부터 인덱스를 통해 탐색하므로 효율적인 탐색이 가능해진다.

이제 우리는 인덱스를 통해 효율적인 탐색이 가능해진다는 것을 알았다.

바로 이 인덱스가 오늘 배워볼 주제이다.

어떻게 인덱스를 통해 효율적인 탐색이 가능하고, 어떻게 하면 효율적으로 인덱스를 사용할 수 있을 지 알아보자

1. 인덱스가 필요한 이유

테이블의 검색 성능을 높여주는 자료구조이다.

인덱스를 쓰게 되면 추가적인 쓰기 작업과 저장 공간을 활용하므로 탐색 속도를 높일 수 있다.

예시를 포함해서 지금까지의 설명으로 인덱스의 특징을 정리해볼 수 있다.

• 인덱스의 데이터는 정렬되어 있다.
• 인덱스는 추가적인 저장 공간을 필요로 한다.
• 인덱스를 사용해서 효율적인 탐색이 가능해진다.

여기까지만 들어도 인덱스가 무엇이고 어떤 장점이 있는 지 대략 파악되었을 것이다.

데이터베이스 쪽으로 좀 더 들어가서 구체적으로 왜 필요한 지 알아보자

2. 인덱스의 동작 방식

mySQL의 공식 문서를 보면 다음과 같이 나와있다.

Indexes are used to find rows with specific column values quickly. Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows.

크게 두 가지로 요약할 수 있다.

1. 조건에 맞는 데이터를 빠르게 검색하기 위헤
2. 데이터를 빠르게 정렬하거나 그룹핑 하기 위해

예를 들어,

SELECT * FROM team WHERE name = ‘sehan’;

DELETE FROM logs WHERE datetime < ‘2023-06-16’;

UPDATE employee SET salary = salary * 1.5 WHERE id = 100;

SELECT * FROM team T JOIN department D ON [T.id](<http://T.id>) = D.id;

각각의 쿼리에는 조건들이 포함되어 있다.

따라서 해당 쿼리들이 실행되면 조건에 맞는 데이터들을 찾아야한다.

하지만 이 경우 테이블의 데이터가 중간이나 끝에 있다면 풀스캔을 해야하는 상황이 된다.

이를 보완하기 위해 인덱스는 별도의 자료구조 및 작업을 실행하여 테이블 탐색 성능을 향상시켜준다.

즉 테이블의 데이터, 조건들을 빠르게 찾기 위해 필요한 것이 인덱스이다.

또한 인덱스는 조인을 할 때 조인을 하기 위한 조건을 빠르게 찾기 위해 사용되기도 한다.

무조건 Select 에서만 필요한 것이 아닌 조건 탐색을 위해서든 단순 데이터 탐색을 위해서든 인덱스는 사용될 수 있다.

3. 인덱스의 종류

그렇다면 인덱스는 어떻게 동작할까?

인덱스의 자료구조

인덱스를 구현하기 위한 자료구조로는 크게 두가지가 있지만 , 대표적으로 B-tree 와 B+tree 가 있다.

마지막엔 추가로 해시에 대해서도 알아볼 것이다.

B-tree,B+tree 에서 ‘B’의 의미는 정확히 밝혀진 바는 없지만 균형을 맞춘다는 의미에서 Balanced 라는 의미로 통한다.

균형을 맞춤으로써 좀 더 빠른 인덱싱이 가능해진다.

만약 자식노드들이 Balanced 하지 않다면 어떻게 될까?

트리가 편향되어 있는 BST(이진 탐색 트리)모습을 상상해보자

BST는 균형을 맞추지 않기 때문에 위와 같은 모습이 나올 수 있다. 

최악의 경우에는 O(n)의 시간 복잡도가 나오는데 B tree는 트리의 균형을 맞춤으로써 시간 복잡도를 줄여준다.

이는 BST는 최대 2개의 자녀 노드를 가지지만 B tree는 여러개의 자녀노드를 가질 수 있기 때문에 가능하다.

B-Tree

B-tree 는 항상 데이터가 정렬되어 있다는 특징이 있다.

때문에 어떤 데이터를 탐색하더라도 O(logN)의 시간 복잡도를 가진다.

그리고 모든 리프 노드들은 같은 레벨에 있으며 따라서 Balanced 되었다 라고 할 수 있다.

B-tree의 구성을 살펴보자, 노드는 키값과 리프 노드에 대한 포인터로 구성되어 있다.

각 key들의 왼쪽 자식들은 key보다 작은 값 ,오른쪽 값은 key보다 큰 값으로 되어있다.

B-tree 구조의 데이터 탐색 과정을 알아보자

현재 데이터에서 정수 27 데이터를 찾아보려고 한다.

먼저 27은 31보다 작으므로 왼쪽 자식노드로 이동한다.

그 다음 11, 29와 데이터를 비교하게 되는데 이 중간값이라는 것을 알 수 있다.

따라서 가운데에 있는 자식 노드로 탐색을 하게되고 27을 발견하게 되면서 탐색이 끝난다.

이렇게 균형 있는 트리 구조를 통해 특정 데이터를 효율적으로 찾을 수 있다.

하지만 모든 경우에서 베스트인것은 아니다.

선형 탐색(Full scan)의 경우 모든 데이터를 다 탐색하므로 O(n)의 시간 복잡도를 가진다.

이 경우 뒤에서 살펴볼 B+tree 라는 것을 통해서 Full scan시 효율을 개선할 수 있다.

삽입

삽입의 경우 조회 방식과 통일하게 Leaf Node들을 탐색하고 노드 자리가 비어있다면 해당 자리에 노드를 삽입 , 꽉 차 있다면 노드를 분할해서 삽입한다.

예제를 통해 13 데이터를 넣을려고 한다고 가정해보자

탐색의 결과, 12와 14 사이의 값에 배정되었다. 하지만 해당 Leaf Node는 노드가 꽉 찬 상태이다.

따라서 부모 노드에 데이터를 넣어주었다.

이렇게 되면 부모 노드도 꽉 찬 상태가 되므로 중앙값인 11로 데이터를 분할해준다.

부모 노드에 11을 넣으니 또 노드가 꽉 찬 상태가 된다.

그러므로 다시 중앙값인 11로 데이터를 분할해준다.

이렇게 함으로써 삽입 과정이 완료되었다.

B-tree의 특징

1. 모든 자식 들을 같은 레벨에 존재한다.
2. 노드의 key의 수가 k개라면, 자식노드는 k+1 이다.
3. Key들은 항상 정렬된 상태이다.

여기까지가 B- Tree 에 대한 작동 과정이다.

이제 B+ Tree에 대해 알아보자

B + Tree

B- tree와의 가장 큰 차이점은 리프 노드들만 데이터를 가질 수 있다는 점이다.

이는 Full scan 시에 가장 명확한 장점을 가진다.

다시 B-tree 의 Full scan 과정을 생각해보자

B-tree에서는 Full scan을 하기 위해서 모든 브랜치 노드 및 자식 노드들을 탐색했어야했다.

하지만 B+tree에서의 Full scan 은 다르다.

그 이유는 Leaf Node 에만 데이터가 존재하고 이들은 연결 리스트로 연결되어 있기 때문이다.

덕분에 한번의 선형 탐색으로도 Full scan을 완료할 수 있다.

B+tree의 특징

1. 리프 노드를 제외하고 데이터를 담아두지 않기 때문에 메모리를 더 확보함으로써 더 많은 key들을 수용할 수 있다.
2. 풀 스캔 시, B+tree는 리프 노드에 데이터가 모두 있기 때문에 효율적인 탐색이 가능하다.

해시

해시가 인덱스에서 사용되는 것을 알기전에 해시테이블에 대해 알 필요가 있다.

해시 테이블은 key값을 인자로 하는 해시 함수의 결과를 통해 인덱스를 만듦으로써 데이터를 저장하는 자료구조이다.

이 경우 찾고자 하는 데이터의 key값을 해시함수 한번으로 조회할 수 있으므로 O(1)의 시간 복잡도를 가진다.

하지만 해시 자료구조는 인덱스에서 거의 쓰이지 않는데, 그 이유는 등호 방식에만 최적화 되어있기 때문이다.

즉 DB 탐색 시에 주로 사용되는 범위검색이나 정렬에는 취약하다.

이러한 단점 때문에 인덱스에서는 많이 사용되지 않는다.

인덱스의 종류

클러스터 인덱스

클러스터 인덱스는 실제 데이터를 정렬하여 인덱스를 만드는 것이다.

따라서 테이블당 단 하나의 클러스터 인덱스만을 만들 수 있다.

실제 데이터를 통해서 인덱스를 만드는 것이므로 조회 과정에서 매우 빠른 속도를 가진다.

하지만 그 외 삽입 , 삭제 , 수정 같은 경우 클러스터 인덱스의 사용이 적합하지 않다.

(DML이 일어나는 경우 매번 정렬을 유지하기 때문)

따라서 클러스터 인덱스는 테이블의 수정이 빈번하지 않고 조회 위주의 작업을 하게 될 경우 좋은 효율을 가질 수 있다.

실생활에 비유해보면, 영어 단어 책을 예시로 들 수 있다.

영어 단어 책은 항상 A~Z 까지 정렬되있는 데 책 자체가 정렬되어 있는 이것을 클러스터 인덱스로 볼 수 있다 !

논클러스터 인덱스

실제 데이터 테이블을 정렬하지 않고 별도의 공간에 인덱스 페이지를 생성해서 저장하는 방식이다.

따라서 인덱스 페이지를 저장하기 위한 추가적인 메모리 공간이 필요하다.

DB에서 데이터를 저장하는 단위이다.

하나의 페이지는 16kb의 크기를 가진다.

MySQL :: MySQL 8.0 Reference Manual :: 15.11.2 File Space Management

논클러스터 인덱스는 데이터의 조회보다 수정,삭제,삽입 시에 더 좋은 효율을 가진다.

실생활에 비유해보면 ,

책 앞에 색인(인덱스)를 보고 해당 내용이 있는 페이지로 이동하는 것이다 !

따라서 데이터의 조회보단 수시로 데이터의 변경이 일어나는 테이블에서의 사용하는 것이 적합하다.

4. 인덱스 만드는 법

SQL 문을 통해 인덱스를 만들 수가 있다.

이 중에서는 우리가 흔히 쓰는 프라이머리 키를 통한 인덱스 생성도 포함되어있다.

위에서 두가지의 인덱스를 배웠는데 각각 어떻게 만드는 지를 알아보자

클러스터 인덱스

1. 프라이머리 키를 선언하는 경우
2. not null + 유니크 제약 조건을 선언하는 경우

ALTER TABLE member ADD CONSTRAINT id PRIMARY KEY(id); → 클러스터링

ALTER TABLE member ADD CONSTRAINT id UNIQUE NOT NULL; → 클러스터링

논 클러스터 인덱스

1. 유니크 제약 조건을 선언하는 경우
2. 직접 (유니크)인덱스를 생성하는 경우

ALTER TABLE member ADD CONSTRAINT name UNIQUE(name); → 논클러스터링

CREATE INDEX name ON member (name); → 논클러스터링

아니면 테이블을 생성할 때 인덱스를 생성할 수도 있다.

CREATE TABLE member(
id INT PRIMARY KEY,
name varchar(20) not null,
INDEX name_idx (name)
)

이처럼 여러가지 방식으로 DB 인덱스를 생성할 수 있다.

5. 적절한 인덱스 사용

인덱스를 쓰면 빠른 조회가 가능하다는 장점이 있지만 인덱스를 사용하게 될 경우 추가적인 작업이 발생하므로 상황에 따라 사용하는 것이 좋다. 그렇다면 인덱스가 굳이 필요없는 상황은 언제일까?

1. 인덱스의 범위가 너무 넓은 경우이다. 넓다는 것의 기준은 전체 데이터의 15%이상을 조회해야한다는 의미로 보면 적합하다.
2. 이 경우 인덱스를 통한 효과가 미미하기 때문에 인덱스의 사용을 지양한다.
3. 조회보다 삽입,삭제 등 수정 작업이 많을 경우이다. 이 경우도 마찬가지로 인덱스로 인한 효과가 미미하다.(수정 작업 시 where 로 조회하는 경우 제외)
4. 데이터 자체가 적은 경우는 배보다 배꼽이 더 큰 상황이 올 수 있기 때문에 사용을 지양하는 것이 좋다.

6. 언제 쓰면 좋을까?

카디널리티가 높은 데이터를 인덱스로 하면 효과적이다.

여기서 카디너리티란 사전적 의미로 그룹 내 요소의 개수를 의미한다.

그렇다면 카디널리티가 높다는 것은 어떤 걸 의미할까?

정해진 데이터 내에서 그룹 내 요소 개수가 많다는 것은 중복이 적다는 것이다.

중복이 적다는 것은 인덱스로 사용 시 매우 좋은 효율을 낼 수 있다.

예를 들어 중복된 데이터가 많은 성별 , 학년은 카디널리티가 낮으므로(중복이 높음) 인덱스에 적합하지 않다.

반대로 학번 , 고유 ID 등은 카디널리티가 높으므로(중복이 낮음) 인덱스 사용에 적합하다.

7. 결론

인덱스의 동작 방식과 인덱스의 사용 효과에 대해 알아보았다.

인덱스는 적절하게 사용하면 좋은 효율을 낼 수 있지만 상황에 맞지 않는 인덱스 사용은 오히려 역효과를 불러올 수 있다.

때문에 인덱스가 필요한 상황인 지를 잘 판단해 효율적으로 사용할 수 있어야한다.

참고 자료

DB Index 동작원리를 알아보자

클러스터 인덱스 vs 넌클러스터 인덱스 | zinirun

[자료구조] 그림으로 알아보는 B-Tree