서버 과부하

서버가 리소스를 소진하여 들어오는 요청을 처리하지 못할 때 발생한다.

이 때 서버는 사용자의 웹요청을 처리하지 못해 응답없음이 뜨게 된다.

해결방법

모니터링을 통한 자원 할당

서버가 응답없음이 뜨는 것은 여러가지 이유가 있지만 그 중 하나가 바로 자원의 한계점 도달 이다.

보통 서버의 CPU 사용량이 80-90%에 도달하거나 메모리가 부족해 계속해서 스와핑이 발생하면 과부화 상태가 됩니다.

스와핑에 대해

가상 메모리는 존재하는데 실제 메모리인 RAM 에는 현재 없는 데이터 or 코드에 접근하는 경우 -> 페이지 폴트 발생

스와핑 : 메모리에서 당장 사용하지 않는 영역을 하드디스크로 옮기고 하드디스크의 일부를 메모리처럼 불러와 쓰는 것

마치 페이지 폴트가 발생하지 않은 것처럼 만든다.

이를 모니터링을 통한 자원의 적절한 할당으로 해결할 수 있다.

자원에 속하는 것들

• CPU
• 메모리
• 대역폭

AWS 오토스케일링

AWS 오토스케일링이란 인스턴스가 있을 때 사용자가 몰리게 돼서 서비스 이용 불가능 상태 발생하기 이전에 cloud watch가 계속해서 모니터링하여 서버 대수를 늘려주는 방법입니다.

AWS Auto Scaling은 애플리케이션을 자동으로 모니터링하고 자원의 용량을 자동으로 조정한다.

netdata를 이용한 모니터링

만약 AWS를 사용하지 않는다고 했을 때 무료 모니터링 서비스도 있다.

https://github.com/netdata/netdata 이를 기반으로 지속적인 모니터링, 그리고 이를 기반으로 자원할당을 해서 해결할 수도 있다.

위와 같은 화면은 slack 과 연동해 임계치를 기반으로 알림 서비스 또한 구축 가능하다.

모니터링 하는 이유

모니터링을 왜 할까?

먼저 서버과부화로 인해 서버 중지에 대한 대처를 할 수 있다.

1. 어떤 페이지에 어떤트래픽이 얼마나 발생했느냐.
2. 어떤 네트워크에서 병목현상이 일어났냐.

등을 모니터링에서는 알려준다.

또한 모니터링을 하면 활용도가 낮은 페이지, 높은 페이지를 파악할 수 있어 나중에 서비스 개선에도 도움이 된다.

즉, 해결하기 위한 문제점을 파악하기 위해 모니터링은 필수

또 일부 서비스는 모니터링한 결과물을 알려주면서 서비스의 중단 등의 여부를 사용자에게 알려주기도 한다.

ex) cloudflare -> https://www.cloudflarestatus.com/

로드밸런서

앞서 설명한 AWS 오토스케일링은 빠르긴 하나 구성에 시간이 걸리기 때문에 앞단에 로드밸런서를 통해 트래픽을 분산해야 한다.

또한, 로드밸런서는 한 서버에 장애가 발생하면 로드 밸런서는 트래픽을 다른 기능 서버로 리디렉션하여 시스템 중단을 방지할 수도 있다.

블랙스완 프로토콜

블랙스완 : 예측할 수 없는 사고

중요한 것은 이러한 블랙스완은 매번 일어나기 때문에 이에 따라 대비를 해야 한다.

구글의 블랙스완이 발생 시 수칙

1. 영향을 받은 시스템과 각 시스템의 상대적 위험 수준을 확인

• 체계적으로 데이터를 수집하고 원인에 대한 가설을 수립한 후 이를 테스팅

2. 잠재적으로 영향을 받을 수 있는 내부의 모든 팀에 연락
3. 최대한 빨리 취약점에 영향을 받는 모든 시스템을 업데이트
4. 복원계획을 포함한 우리의 대응 과정을 파트너와 고객 등 외부에 전달

서킷 브레이커

서비스 장애를 감지하고 연쇄적으로 생기는 에러를 방지하는 기법

서비스와 서비스 사이에 서킷브레이커 계층을 두고 미리 설정해놓은 timeout 임계값에 도달하면 서킷브레이커가 그 이후의 추가 호출에 무조건 에러를 반환

만약 서비스 A, B, C가 있고 결제 서비스라고 했을 때 A는 개인정보, B는 장바구니, C는 미리 결정해둔 카드 정보들을 관리. 그리고 A, B, C 끼리 HTTP로 통신한다고 하자.

만약 스레드가 100개 중 98개는 A에 요청, 나머지 2개는 각각 B, C에 요청한다고 하자.

근데 A가 고장나버린다면.. 기다리는 동안 B와 C에 대해서도 스레드가 차단될 수도 있다.

이것을 스레드 차단이라고 한다.

혹은

• A <-> B
• B <-> C

가 연결돼 있는데 A가 고장나버리면 B가 멈추게 되고, 연쇄적으로 C도 멈추게 된다.

이것을 계단식 에러라고 한다.

이럴 때를 대비해서 서비스 사이에 서킷 브레이커를 두고 에러를 방지하는 것이다.

에러가 고쳐질 때까지 기다리는게 뭐가 어때서? 라고 생각한다면.

사용자 입장에서 응답을 오래 기다려야 하는 것은 좋은 UX가 아니다. 성공인지 실패인지는 중요하지 않다. 중요한 것은 사용자가 기다리지 않아야 한다는 점이다.

동작과정

이렇게 정상적으로 작동하던 서비스가 있다고 가정했을 때

아래 사진처럼 Supplier Microservice 가 고장나게 된다면 바로 에러를 반환한다.

서킷브레이커는 closed, open, half_open 의 상태값을 가진다.

• closed[정상] : 네트워크 요청의 실패율이 임계치보다 낮음
• open[에러] : 임계치이상의 상태를 말합니다. 요청을 서비스로 전송하지 않고 바로 오류를 반환합니다. 이를 fail fast라고 한다.
• half_open[확인중] : open 상태에서 일정 timeout으로 설정된 시간이 지나면 장애가 해결되었는지 확인하기 위해 half_open 상태로 전환됩니다. 여기서 요청을 전송하여 응답을 확인. 장애가 풀리는지를 확인해서 성공하면 closed, 실패하면 다시 open으로 변경

장점

연속적인 에러 발생을 막아주며 일부서비스가 종료되더라도 다른 서비스들은 이상없이 동작하게 만들 수 있으며 사용자 경험을 높여준다.

이미 서킷브레이커는 구현된 라이브러리가 있는데, Netflix의 Hystrix 그리고 Resilience4j 가 대표적이다.

https://github.com/Netflix/Hystrix https://github.com/resilience4j/resilience4j

컨텐츠 관리

불필요한 컨텐츠 제거

인프런의 장애 복구 사례를 예를 들어보자. -> 불필요한 쿼리 등을 제거한다.

https://tech.inflab.com/202201-event-postmortem/

사용하지 않는 컬럼들도 가져온다든지 그런 것들을 제거해서 컨텐츠의 크기를 줄이거나 할 수 있다.

CDN을 통한 컨텐츠 제공

CDN을 통해 사용자 가까이, 그리고 분산된 대규모 서버 네트워크를 기반으로 컨텐츠를 제공해서 메인 서버에 대한 부하를 줄인다.

MainServer 에서 사용자가 원하면 데이터를 줄텐데 변하지 않는 Image, js, css, html 과 같은 정적 자원들은 MainServer가 주는 것이 CDN을 통해 주므로 비용을 줄일 수 있다.

ex) cpu의 10%를 해당 장적 자원들을 제공하는데 사용하고 있었다면 해당 비용을 줄일 수 있다.

컨텐츠 캐싱

네트워크 트래픽을 해결하는 가장 좋은 방법은 해당 트래픽이 발생하지 않도록 하는 것이다.

브라우저 캐시(쿠키, 로컬저장소, 세션저장소)를 통해 해당 요청에 관한 항목을 캐시에서 응답을 읽어 네트워크 요청에 관한 비용을 모두 제거한다.

컨텐츠 압축

텍스트 기반 리소스는 gzip 또는 Brotli를 통해 압축해야 한다. 압축하면 70% 정도까지 압축할 수 있습니다. 다만 압축했기 때문에 압축을 풀기위해 서버에서 자원(CPU)를 사용하는 양까지 고려해야 한다.

보통은 압축하면 좋다.

컨텐츠의 우하한 저하 (미리 준비된 응답하기)

시스템의 과도한 부하를 줄이기 위해 제공하는 컨텐츠 및 기능을 일시적으로 줄이는 전략이다.

예를 들어 정적 텍스트 페이지를 제공하거나, 검색을 비활성화하거나 더 적은 수의 검색 결과를 반환하거나, 필수적이지 않은 기능을 비활성화한다.

중요한 일이 생겼을 때 뉴스와 같은 홈페이지는 이미지, 영상, 지도와 같은 것들을 삭제하고 내용 전달에 중점을 두고 경량화된 컨텐츠를 제공한다.

일본 NHK 웹의 정상 화면의 경우

서울 대피 당시 화면의 경우

세션기반 인증방식

HTTP의 특징 중 하나는 상태없음(stateless) 하다라는 것인데

즉, HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보 등을 유지하지 않는 특징이 있다. (이전부터 CS 공부하면서 아는 내용)

그럼 로그인 상태는 어떻게 유지하는걸까?

• 세션 : 서버와 클라이언트의 연결이 활성화된 상태를 의미합니다.
• 세션ID : 웹 서버 또는 DB에 저장되는 클라이언트에 대한 유니크한 ID

세션기반 로그인 과정

1. 처음 로그인 >> 세션ID가 생성됨 >> 서버에서 세션ID를 쿠키로 설정해서 클라이언트에 전달
2. 클라이언트가 서버에 요청을 보낼 때 해당 세션ID를 쿠키로 담아서 전에 로그인했던 아이디인지 확인
3. 로그인을 유지

다른 페이지를 넘어가더라도 쿠키에 있는 세션ID를 보고 해당 ID가 이미 유효하기 때문에 로그인 상태가 유지되는 것이다.

단점

1. 사용자의 상태에 관한 데이터를 서버에 저장했을 때 로그인 중인 유저의 수가 늘어난다면?
   • 서버의 메모리 과부화가 일어날 수 있다.
2. DB 중 RDBMS에 저장한다면, 직렬화 및 역직렬화에 관한 오버헤드가 발생

MySQL 같은 곳에 저장한다면 (아마 VARCHAR 형태로 저장될 것)

이 때 직렬화와 역직렬화에 대한 단점을 굳이 꼽아볼 수 있다.

토큰기반 인증방식

acceess 토큰, refresh 토큰, JWT 토큰에 대해서는 들어봤을 것이다.

토큰기반 인증방식에 대해 알아보자.

토큰기반 인증방식은 state를 모두 토큰 자체만으로 처리하며 토큰을 처리하는 한 서버를 두고 다른 컨텐츠를 제공하는 서버는 모두 stateless하게 만들자는 이론이 담긴 방식이다.

왜 토큰을 관리하는 서버는 따로 두어야 할까?

이는 여러 개의 서버를 운용한다라고 했을 때

• 토큰기반 인증 + A도메인을 처리하는 서버로 구축할 경우

A도메인에서 에러가 발생이 되면, 인증에 관한 기능이 마비되고 이는 B, C, D 등의 도메인 기능이 연쇄적으로 마비될 수 있기 때문이다.

토큰은 주로 JWT 토큰이 활용된다.

1. 인증로직 >> JWT 토큰 생성(access 토큰, refresh 토큰)
2. 사용자가 이후에 access 토큰을 HTTP Header - Authorization 또는 HTTP Header

• Cookie에 담아 인증이 필요한 서버에 요청해 원하는 컨텐츠를 가져온다.

JWT

JWT는 JSON Web Token을 의미하며 헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩되며 메시지 인증, 암호화에 사용됩니다.

Header

• 토큰 유형과 서명 알고리즘, base64URI로 인코딩 됩니다.

Payload

• 데이터, 토큰 발급자, 토큰 유효기간, base64URI로 인코딩 됩니다.

Signature

• (인코딩된 header + payload) + 비밀키를 기반으로 헤더에 명시된 알고리즘으로 다시 생성한 서명값.

https://jwt.io/

여기로 가서 보면 Header랑 Payload 를 base64UrlEncode 하고

비밀키 기반으로 서명 알고리즘을 통해 만들어진다. 그것을 왼쪽에서 확인 가능할 것이다.

장점

1. 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증저장소가 필요 X
2. 다른 유형의 토큰과 비교했을 때 경량화되어있습니다. SAML(Security Assertion Markup Language Tokens)이란 토큰이 있지만 이에 비해 훨씬 경량화되어 있음.
3. 디코딩했을 때 JSON이 나오기 때문에 JSON을 기반으로 쉽게 직렬화, 역직렬화가 가능하다.

단점

1. 토큰이 비대해질 경우 당연히 서버과부화에 영향을 줄 수 있다.
2. 토큰을 탈취당할 경우 디코딩했을 때 데이터를 볼 수 있다.

Access 토큰, Refresh 토큰

access토큰의 수명은 짧게, refresh토큰의 수명은 길게 한다.

refresh토큰은 access토큰이 만료되었을 때 다시 access 토큰을 얻기 위해 사용되는 토큰이다.

이를 통해 access토큰이 만료될 때마다 인증에 관한 비용이 줄어들게 된다.

로그인을 하게 되면 access 토큰과 refresh 토큰 두개를 얻는데

access 토큰이 만료되거나 사용자가 새로고침을 할 때 refresh 토큰을 기반으로 새로운 access token을 얻는다.

왜 나눠서 할까?

access 토큰 : 인증용 토큰이다.

해커가 access 토큰을 탈취해 로그인한다면? -> 안 되기 때문에 만료기한을 적게 해야 한다.

만료기한이 지나면 이후에는 사용 못하기 때문에 해커도 탈취해서 사용하기 힘들다.

refresh 토큰 : 갱신용 토큰

access 토큰이 짧은 만큼 refresh 토큰은 갱신 기간을 둬서 갱신 가능하게끔 해주는 것이다.

주의할 점

이렇게 access토큰을 얻었다면 그 이후에 요청을 할 때는 HTTP Header - Authorization 또는 HTTP Header - Cookie에 담아 요청을 하게 되는데 이 때 다음과 같은 규칙을 지키는 것이 좋다.

• Bearer <token> 으로 "Bearer " (띄어쓰기 포함) 을 앞에 둬서 토큰기반인증방식이라는 것을 알려줘야 한다.
• https를 사용해야 한다.
• 쿠키에 저장한다면 sameSite: 'Strict'을 써야 한다.
• 수명이 짧은 access token을 발급해야 한다.
• url에 토큰을 전달하지 말아야 한다.

토큰을 탈취당하는 것을 대비하는 방법

1. 먼저 Access Token의 수명을 짧게 설정하여 탈취된 토큰의 유효 기간을 최소화. 짧은 수명의 Access Token을 사용하고, 필요할 때만 Refresh Token을 통해 새로운 Access Token을 발급
2. Refresh Token을 사용하여 민감한 작업을 수행하려고 할 때 추가적인 사용자 인증 단계를 요구한다.

• 예를 들어, IP주소, 디바이스 정보등을 이용하거나 google authentifactor를 이용한 2단계 인증을 사용한다.

3. 쿠키에 HttpOnly 및 Secure 을 걸어서 관리

세션 스토리지는 로컬 스토리지와 굉장히 유사하다.

웹 스토리지 객체로 브라우저 내에 { key : value } 형태로 오리진에 종속되어 저장되는 데이터

• 하나의 키, 하나의 값 저장
• 최대 저장 용량은 5MB

로컬스토리지와 차이점

• 동일한 오리진이어도 브라우저의 각 탭마다 독립적으로 저장된다.

즉, 다른 탭에서 세션 스토리지에 저장된 데이터에 접근할 수 없다.

• 사용자가 브라우저에서 탭을 닫으면 데이터가 만료된다.

사용법

• 설정 : sessionStorage.setItem(key, value);
• 탐색 : sessionStorage.getItem(key);
• 제거 : sessionStorage.removeItem(key);
• 전체제거 : sessionStorage.clear()

위와 같이 Console 창에 했을 때

해당 탭의 Session storage 에 저장된 것을 볼 수 있지만

다른 탭에서는 없는걸 볼 수 있다.

그런 차이가 있다.

보통 세션스토리지보다 로컬스토리지를 많이 쓴다.

쿠키

브라우저에 저장된 데이터 조각

클라이언트에서 먼저 설정할 수도 있고, 서버에서 먼저 설정할 수도 있다.

거의 보통은 서버에서 먼저 설정해서 쿠키를 만드는게 일반적이다.

1. 서버에서 응답헤더로 Set-Cookie 로 설정해서 쿠키를 보낸다.
2. 클라이언트에서 요청헤더 Cookie 에 설정돼 자동으로 서버에 전달되게 돼 브라우저에 저장되게 한다.

참고 : HTTP 헤더를 통해 Client or Server 가 HTTP 요청, 응답할 때 추가 정보를 전달할 수 있다.

클라이언트와 서버 둘 다 조작이 가능하지만 보통 서버에서 만료기한 등을 설정 및 컨트롤한다.

저장용량은 최대 4KB

• 로그인
• 장바구니
• 사용자 커스터마이징
• 사용자 행동분석 (주로 개인화된 광고에 활용되는 것)

위와 같은 것들에 사용된다.

클라이언트에서도 설정가능한 쿠키 (권장 X)

클라이언트에서 자바스크립트 - document.cookie를 통해 쿠키를 설정할 수 있고 보낼 때도 이런 식으로 header - Cookie에 값을 정해서 보낼 수도 있다.

하지만 이를 권장 X

axios.get(url, {
    headers: {
        Cookie: "cookie1=value; cookie2=value; cookie3=value;"
    }
}).then

이렇게 되면 쿠키에 대한 제어권을 클라이언트에게 두게 되는데, 쿠키에는 보통 민감한 정보들이 담길 수도 있기 때문에 이 제어권에 관한 것을 클라이언트가 아닌 서버가 가지고 있게 해야 한다.

세션 쿠키

Expires 또는 Max-Age 속성을 지정하지 않은 것을 말한다.

브라우저가 종료되면 쿠키도 사라진다.

영구 쿠키

Expires 또는 Max-Age 속성을 지정해서 특정 날짜 또는 일정 기간이 지나면 삭제되게 만든 쿠키로, 브라우저를 닫을 때 만료되지 않는다.

문법

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict

secure

쿠키에 이 옵션을 추가하면 https로만 쿠키를 주고받을 수 있게 하는 옵션이다.

하지만 Chrome v89 및 Firefox v75이상부터 localhost에서는 이 사양을 무시합니다.

즉, Chrome v89 및 Firefox v75이상의 localhost에서는 secure 옵션을 걸어도 http로 쿠키를 주고받을 수 있어 쉽게 테스팅이 가능

httponly

공격자가 쿠키를 자바스크립트로 빼낼 수 없게 만든다. (document.cookie로 접근 불가)

samesite

요청이 동일한 도메인에서 시작된 경우에만 쿠키가 애플리케이션으로 전송되도록 허용

실습

const http = require('http');
const hostname = '127.0.0.1';
const port = 3000;
const server = http.createServer((req, res) => {
    res.setHeader('Content-Type', 'text/plain; charset=utf-8');
    res.setHeader('Set-Cookie', ['cookie1 = httponlycookie; httponly', 'cookie2 = securecookie; Secure']);
    res.end('end\n');
});
server.listen(port, hostname, () => {
    console.log(`Server running at http://${hostname}:${port}/`);
});

http 서버, 호스트명은 localhost, 포트는 3000

res.setHeader('Content-Type', 'text/plain; charset=utf-8'); 라고 하는 형태로 보내지만

쿠키는 res.setHeader('Set-Cookie', ['cookie1 = httponlycookie; httponly', 'cookie2 = securecookie; Secure']); 이렇게 만든다.

js 파일에서 만든 뒤 node script.js 로 실행하면 3000번 포트에 서버가 구동된걸 볼 수 있고,

개발자 도구의 Application -> Cookies 를 보면 들어간 것도 볼 수 있을 것이다.

1. httponly와 secure 에도 차이가 있는걸 볼 수 있을 것이다.

내가 https가 아닌 http인데 secure가 보이는 이유? -> 크롬 89 이상과 firefox 75 이상이기 때문일 것이다.

• 테스트할 때만 로컬에서 볼 수 있게 한시적으로 허용해준다.

2. document.cookie 를 검색해보면 'cookie2 : securecookie 만 나오는 것을 볼 수 있을 것이다.

httponly는 나오지 않기 때문이다. (조금 더 안전해진다.)

즉, 쿠키의 시큐어코딩에 대해 알아보자.

쿠키 - 세션으로 로그인을 처리한다면 다음과 같은 시큐어 코딩을 해야 한다.

1. cookie에 세션ID를 담을 때 이 세션ID기반으로 클라이언트의 개인정보를 유추할 수 없게 해야 한다.
2. 자바스크립트로는 파악할 수 없게 http only 옵션을 걸고, https로만 쿠키를 주고받을 수 있게 secure 옵션을 걸어야 한다.
3. 일정시간의 세션 타임아웃을 걸어야 한다.

사례

세션 타임아웃 사례 : upbit의 세션타임아웃으로 공격자의 접근을 차단할 수 있다.

-> 로그인 해두고 뭐 자리를 비웠을 때 타임아웃이 된 후에는 공격자가 접근할 수 없게끔 하는 것이다.

쿠키 허용 관련 알림창 사례

서비스 운용시 쿠키를 사용한다면 쿠키허용관련 알림창을 만들어야 한다. 방문 기록을 추적할 때 쿠키가 사용되기 때문이다. 이는 사용자의 데이터 간접수집에 해당하며 거기에 해당하는 KISA 지침을 준수해야 하기 때문.

로컬스토리지, 세션스토리지, 쿠키의 공통점 차이점

이전 로컬스토리지에 이어서 봤던 웹브라우저의 캐시들의 공통점, 차이점을 알아보자.

공통점

1. 브라우저에 캐싱을 함으로써 서버에 대한 요청을 줄여 서버부하를 방지할 수 있다.
2. 캐싱으로 인해 다운로드 하는 컨텐츠가 줄어들어 웹사이트의 컨텐츠를 더 빨리 다운로드가 가능합니다.
3. 사이트 기본 설정 커스터마이징(색상, 글꼴 크기 등)을 저장하거나 로그인 상태를 유지할 때 사용될 수 있습니다

차이점

-> 쿠키, 로컬스토리지는 오리진이 같은 여러 탭을 닫아도 유지가 된다.

위 링크에서도 아주 간단하게 웹 브라우저의 캐시를 알아봤었는데 이번엔 사용법도 같이 알아보고자 한다.

로컬스토리지

Web Storage 객체로 브라우저 내에 키:값 형태로 origin 에 종속돼 저장되는 데이터이다.

• 키:값 형태이므로 하나의 키에는 오로지 하나의 값만 저장된다.
  • 추가로 넣고 싶다면 배열 형태로 넣는 수밖에 없다.
• 웹 브라우저에서 데이터를 수동으로 삭제하지 않는 한 로컬 저장소에 저장되며, 만료 날짜가 없다.
  • 창이나 탭을 닫는다고 만료되는 것이 아니다.
• 최대 용량은 5MB 이다.
• 로그인을 유지하기 위한 값, 사용자의 행위를 기억할 때 사용된다.
  • 예를 들면 1, 2, 3번 총 3개의 탭이 있을 때 2번 탭에서 한 행위는 기억된다.
    • ex) 네이버 쇼핑에서 필터링을 걸어두는 행위 -> 새로고침해도 유지됨
• 데이터는 자동으로 서버로 전송되지 않는다.

추가로 작성할 개념인 쿠키는 자동 전송되니까 차이를 알아두자.

사용법

• 설정 : localStorage.setItem(key, value);
• key에 해당하는 value가져오기 : localStorage.getItem(key);
• 제거 : localStorage.removeItem(key);
• 전체제거 : localStorage.clear()

개발자 도구 -> console

개발자 도구 -> application

이런 형태로 설정도 가능하고 제거도 가능하다.

로컬스토리지와 오리진

위의 개념에서 로컬스토리지는 키:값 형태로 origin 에 종속돼 저장되는 데이터라고 했는데 오리진이란?

오리진은 https://www.naver.com 을 예시를 들어 설명하면

1. https: -> protocol
2. www.naver.com -> hostname
3. 443 포트가 있지만 생략돼 있다. -> port

참고) https://www.naver.com:443 해도 똑같이 naver가 되는 것을 알 수 있다. -> https 의 기본 포트 번호이기 때문.

위에서 말한 protocol, hostname, port 를 묶어서 오리진이라고 한다.

벨로그를 예를 들면 해당 페이지는

https://velog.io 까지가 오리진 물음표 이후의 id=983888e3-bb05-4eb6-9aab-b93f4c09a7c5 부분은 query String 이다.

그래서 같은 오리진이 같다면 로컬 스토리지에 저장되기 때문에 필터링을 걸어둔 "행위"가 기억되는 것이다.

그래서 로그인 유지할 때도 사용한다.

• 토큰 기반 방식
• 세션 기반 방식

2가지가 있는데 토큰 먼저 알아보자.

토큰 기반 방식

1. 사용자 아이디 패스워드 입력 -> 서버에 로그인 요청
2. 서버가 DB를 통해 로그인 성공 시 token (반환)
3. 이 token 은 LocalStorage에 저장된다.
4. 이 저장된 token을 보통 header-authorization 이라는 header에 담아서 보내면 로그인이 유지될 수 있는 것이다.

활용 사례 : 캐싱

로그인 유지뿐 아닌 추가로 더 알아보자.

우리가 이전에 입력했던 것들을 입력하지 않아도 자동완성으로 저장돼 있는 경우가 있다.

이것으로 다시 입력할 필요 없이 수고를 덜 수 있다. => UX가 좋아진다(개선된다)

텍스트 창을 만든 뒤에 script 에

<body>
    <div>
        <input type="text" id="field" />
        <input type="button" class="button-62" value="검색" id="save" />
        <input type="button" class="button-62" value="조회" id="read" />
        <input type="button" class="button-62" value="삭제" id="clear" />
    </div>
</body>
<script>
    window.onload = async () => {
        const field = document.getElementById("field"),
            save = document.getElementById("save"),
            read = document.getElementById("read"),
            clear = document.getElementById("clear")

        save.addEventListener("click", e => localStorage.setItem("입력값", field.value))
        read.addEventListener("click", e => alert(window.localStorage["입력값"]))
        clear.addEventListener("click", e => {
            window.localStorage.clear()
            field.value = ""
        })
        if (window.localStorage["입력값"]) {
            field.value = window.localStorage["입력값"]
        }
    }
</script>

이런 식으로 해서 자동완성에도 사용 가능하다.

비선형 자료구조 : 일렬로 나열하지 않고 자료 순서, 관계가 복잡한 구조

그래프

그래프 : 정점 (vertex) 와 간선 (edge)로 이루어진 자료구조

가중치

가중치 : 정점과 간선 사이에 드는 비용

그럼 그래프에 속하는 것 중 하나인 트리에 대해 알아보자.

트리

• 루트 노드 : 가장 위에 있는 노드
• 내부 노드 : 루트 노드와 리프 노드를 제외한 노드
• 리프 노드 : 자식 노드가 없는 노드

깊이 : 루트 노드 ~ 특정 노드까지 최단 거리로 갔을 때의 거리

• 각 노드마다 트리의 깊이가 다르다.

레벨 : 보통 '깊이'와 같은 의미를 가진다.

• 1번 노드가 0레벨 => 2번, 3번 노드는 1레벨

높이 : 루트 노드 ~ 리프 노드까지의 거리 중 가장 긴 거리

서브트리 : 트리 내의 하위 집합 (부분 집합)

이진 트리

이진 트리 : 자식 노드의 수가 2개 이하인 트리

이진 트리의 종류

• 정이진 트리 (full binary tree): 자식 노드가 0 또는 2개인 이진 트리를 의미한다.

• 완전 이진 트리 (complete binary tree): 왼쪽에서부터 채워져 있는 이진 트리를 의미한다.

  • 마지막 레벨을 제외하고는 모든 레벨이 완전히 채워져 있으며, 마지막 레벨의 경우 왼쪽부터 채워져 있다.

• 변질 이진 트리 (degenerate binary tree): 자식 노드가 하나밖에 없는 이진 트리를 의미한다.

• 포화 이진 트리 (perfect binary tree): 모든 노드가 꽉 차 있는 이진 트리를 의미한다.

• 균형 이진 트리 (balanced binary tree): 왼쪽과 오른쪽 노드의 높이 차이가 1 이하인 이진 트리를 의미한다.

  • map, set을 구성하는 레드 블랙 트리는 균형 이진 트리 중 하나입니다.

이진 탐색 트리 (BST, Binary Search Tree)

이진 탐색 트리 : 노드의 오른쪽 하위 트리에는 '노드 값보다 큰 값'만 들어 있고, 왼쪽 하위 트리에는 '노드 값보다 작은 값'만 들어 있는 트리

그래서 검색할 때 용이하다

요소에 접근 시 평균적으로는 $O(logn)$ 소요, 최악의 경우에는 $O(n)$ 소요하며, 삽입 순서에 따라 구조가 선형적일 수 있다.

AVL 트리 (Adelson-Velsky and Landis tree)

AVL 트리 : 선형적인 트리가 되는 최악의 경우를 방지하고, 스스로 균형을 잡는 이진 탐색 트리

두 자식 서브트리의 높이 => 항상 최대 1만큼 차이난다는 특징이 있다.

삽입, 삭제 시마다 균형을 맞추기 위해 트리의 일부를 왼쪽 또는 오른쪽으로 회전시킨다.

• 탐색, 삽입, 삭제 => $O(logn)$ 소요

레드 블랙 트리

레드 블랙 트리 : 균형 이진 탐색 트리로 탐색, 삽입, 삭제 모두 시간 복잡도가 $O(logn)$

각 노드에 빨간색 또는 검은색의 색을 저장하는 추가 비트를 저장하고 이는 곧 삽입, 삭제 중 트리가 균형을 유지하는데 사용된다.

힙, 우선순위 큐

힙과 우선순위 큐에 대해서는 정리된 것을 보자.

자료구조 - 힙 heap (Java)

우선순위 큐

우선순위 큐에 대해서는 아래로 내려보면 정리를 해뒀다.

맵, 해시 테이블

Hash, HashTable

맵 : 특정 순서에 따라 키에 매핑된 값의 조합 (키-값) 으로 구성된 자료구조

• 레드 블랙 트리 자료구조 기반으로 형성된다.
• 삽입 시 자동으로 정렬된다.
• 해시 테이블 구현 시 사용한다.
  • unordered_map : 정렬 보장 X
  • map : 정렬 보장 O

map<string, int> 형태로 구현하며 아래와 같은 기능들이 있는데

• clear() : 맵에 있는 모든 요소 삭제
• size() : map의 크기 구함
• erase() : 해당 키와 키에 매핑된 값 삭제

Java에서의 HashMap 메서드도 위 링크에 정리를 해놨다.

해시 테이블 : 무한에 가까운 데이터를 유한한 개수의 해시 값으로 매핑한 테이블 unordered_map으로 구현

삽입, 삭제, 탐색 => 평균적으로 $O(1)$ 소요

셋 (set)

Set : 특정 순서에 따라 고유한 요소 저장하는 컨테이너

중복되는 요소 없이 unique 값만 저장한다.

요소가 일렬로 나열돼 있는 자료구조로

• 연결 리스트
• 배열
• 벡터
• 스택
• 큐

에 대해 알아보자.

연결 리스트

이전에 Java의 컬렉션을 정리하면서 리스트 관련은 정리한 것이 있다.

Java - Collection (List - ArrayList)

Java - Collection (List - LinkedList)

연결 리스트

• 싱글 연결 리스트 : next 포인터만 가지는 것
• 이중 연결 리스트 : next, prev 포인터를 가지는 것
• 원형 이중 연결 리스트 : 이중 연결 리스트와 같은데 추가로 마지막 노드의 next 포인터가 헤드 노드를 가리키는 것

연결 리스트의 함수

• push_front(): 앞에서부터 요소 추가
• push_back(): 뒤에서부터 요소 추가
• insert(): 중간에 요소 추가

배열

같은 타입의 변수, 지정된 크기, 인접한 메모리 위치에 있는 데이터를 모아둔 집합이다. 중복을 허용하며 순서가 있다.

정적 배열을 기반으로 알아보자. 우선 배열의 접근에는 $O(1)$의 복잡도를 가지고 랜덤 접근이 가능하다. 삽입과 삭제에는 $O(n)$이 걸린다.

그래서 추가/삭제 시에는 연결 리스트를 사용하고, 접근(참조)을 하는 것은 배열이 좋다. 그런 이유는 아래 비교에서 알아보자.

랜덤 접근 (random access) 순차적인 데이터가 있을 때 임의의 인덱스에 해당하는 데이터에 접근할 수 있는 기능

순차적 접근 저장된 순서대로 데이터를 접근해야 함

배열, 연결 리스트 비교

• 배열은 인덱스 번호만 알아도 해당 값을 얻을 수 있다.
• 연결 리스트는 순차 접근이 불가능하여 찾고자 하는 해당 위치까지 탐색을 해야 한다.

즉, 배열은 참조나 탐색하기엔 연결리스트보다 빠르다. 하지만 삽입, 삭제에서는 연결리스트에서는 next, prev 선만 변경하면 가능하기 때문에 연결리스트를 선택하는 것이 좋다.

벡터

벡터 : 동적으로 요소 할당 가능한 동적 배열이다.

• 파일 시점에 요소의 개수를 모른다면 벡터 사용해야 한다.
• 중복 허용, 순서 있음, 랜덤 접근 가능

탐색하는 것과 맨 뒤의 요소에 삽입/삭제하는 것에는 $O(1)$이 걸리고 그렇지 않은 요소에 삽입/삭제 하는 것은 $O(n)$의 시간이 걸린다.

2의 제곱승 + 1 (3, 5, 9 ...) 일 때마다 크기를 2배로 늘리는 것을 알 수 있다.

벡터의 함수

• push_back(): 뒤에서부터 요소 추가
• pop_back(): 맨 뒤부터 요소 삭제
• erase(): 요소 삭제
• find(): 요소 탐색
• clear(): 배열 초기화

스택, 큐

스택과 큐는 이전에 정리했던 것을 봐도 충분할 것이다.

스택, 큐

다음은 비선형 자료 구조에 대해 알아보자.

자료구조란, 효율적으로 데이터를 관리하고 수정, 삭제, 탐색, 저장할 수 있는 데이터 집합이다.

복잡도

시간 복잡도

시간 복잡도 : 입력 크기에 대해 어떠한 알고리즘이 실행되는데 걸리는 시간 주요 로직의 반복 횟수를 중점으로 측정된다. 보통 빅오 표기법으로 표현

빅오 표기법

빅오 표기법 : 입력 범위 n을 기준으로 해서 로직이 몇 번 반복되는지 나타내는 것

입력 크기가 커질 수록 연산량이 가장 많이 커지는 항 (ex. $n^2$ 항) 과 달리 다른 것은 연산량의 증가가 미미하기 때문에 그것만 신경쓰면 된다.

시간 복잡도가 존재하는 이유 시간 복잡도를 더욱 효율적인 코드로 개선할 수 있는 척도로 이용 소요 시간: $O(n^2)$ > $O(n)$ > $O(1)$

즉, $O(n^2)$ 보다는 $O(n)$, $O(n)$보다도 $O(1)$을 지향해야 한다.

자료구조에서의 시간 복잡도

거의 평균 시간 복잡도와 최악의 시간 복잡도를 고려하면서 쓴다.

1) 평균 시간 복잡도

2) 최악의 시간 복잡도

MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.

아래에서 할 예시들은 트랜잭션 번호를 생략해두고 진행했다.

Repeatable Read 에서는 다른 트랜잭션 격리수준인 Read Uncommitted 나 Read Committed 에서와 달리 Non-Repeatable Read *현상이 발생하지 않는다. *

Non-Repeatable Read : 하나의 트랜잭션에서 같은 값을 두 번 select 했을 때 각각 다른 값이 읽히는 현상

이게 무슨 소리냐면

• 똑같은 레코드를 2번 조회하는 트랜잭션 A
• 해당 레코드를 수정하고 커밋하는 트랜잭션 B

1. 트랜잭션 A의 1번째 조회가 진행
2. 트랜잭션 B가 해당 레코드 수정 -> 커밋
3. 트랜잭션 A의 2번째 조회가 진행 == 데이터가 변경돼 Non-Repeatable Read 발생

위 순서대로 진행이 된다면 데이터가 변경돼 Non-Repeatable Read 발생한다는 것이다.

그럼 문득 "하나의 트랜잭션에서 같은 데이터의 조회를 2번 할 일이 없다면?" 이라고 생각이 들 수도 있다.

MySQL InnoDB 스토리지 엔진의 기본 트랜잭션 격리수준으로 Repeatable Read 을 설정한 이유가 뭘까?

위 사진은 MySQL docs에서 Repeatable Read를 정의한 내용으로

첫 줄의 "Consistent reads within the same transaction read the snapshot established by the first read."

= 동일한 트랜잭션 내에서의 일관된 조회는 첫 번째 조회에 의해 설정된 스냅샷을 읽는다. 는 뜻이다.

스냅샷 : "일관된 조회를 위해 특정 격리 수준에서 사용되는 것으로서 다른 트랜잭션에 의해 변경 사항이 커밋되더라도 동일하게 유지되는 특정 시간의 데이터 표현"

이번엔 다른 형태의 트랜잭션을 가정을 들어 설명하겠다.

• 각자 다른 테이블에 대해 1번씩 조회하는 트랜잭션 C
• C가 2번째로 조회하는 테이블의 레코드를 수정 후 커밋하는 트랜잭션 D

1. 트랜잭션 C의 1번째 테이블의 특정 레코드 조회가 진행
2. 트랜잭션 D가 2번째 테이블의 특정 레코드 수정 -> 커밋
3. 트랜잭션 C의 2번째 테이블의 해당 레코드 조회가 진행

위 과정을 겪으면 어떻게 될까?

1. C는 한 트랜잭션에서 1, 2번째 조회를 하기 때문에 D가 수정하기 전의 2번째 테이블 속 레코드를 읽기
2. C는 2번째 조회 시 D가 수정한 레코드의 데이터로 읽기

정답은 바로 1번이다. 말이 길어져서 간단히 그림으로 설명하면

이렇게 plan을 C 중간에 수정하고 커밋하더라도 before이었던 레코드가 그대로 출력된다는 뜻이다.

트랜잭션 격리수준이 Repeatable Read 라면 한 트랜잭션 내에서 동일한 select 를 2번 이상 시도해도 동일한 결과가 반환된다.

다른 테이블 데이터 역시 최초 조회(first read) 시점에서의 데이터가 마치 스냅샷(snapshot)처럼 유지되어 있던 것이다.

그렇게 할 수 있는 이유는

일관된 조회 : 조회한 시점을 기준으로 쿼리 결과를 표시하는 스냅샷 정보를 사용하는 것

2번째 줄의 If queried ~ 로 시작하는 문구를 보면 "조회된 데이터(queried data)가 다른 트랜잭션에 의해 변경되었다면 본래 데이터는 undo log 의 내용을 통해 재구성된다." 라는 뜻인데

트랜잭션 C는 D가 수정한 데이터의 원본 데이터가 undo log 에 들어갔고 이 undo log 로부터 해당 데이터를 가져왔다는 것을 알 수 있다.

언두 로그 : 활성 트랜잭션에 의해 수정된 데이터의 복사본을 보관하는 저장 영역

즉, 수정하기 전 원본 데이터가 저장되는 영역

대신 Phantom Read 라고 하는 현상이 발생하기도 한다.

Phantom Read

Phantom Read : 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때 해당 조회 결과가 다른 경우

• Phantom Read와 Non-Repeatable Read의 차이??

• Non-Repeatable Read는 1개의 Row의 데이터의 값이 변경되는 것이며 (Update 또는 Delete)
• Phantom Read는 다수의 건을 요청하는 것에 대해서 데이터의 값이 변경되는 것

  즉, Non-Repeatable Read는 위에서 봤다시피 1개의 Row의 데이터를 2번 조회하는 트랜잭션 내에서 다른 트랜잭션에 의해 update나 delete로 하나의 데이터가 변경됐을 때 언두 로그로 인해 변경되기 전의 데이터를 조회할 수 있다는 것이다.

Phantom Read를 예를 들어 설명하면

• member라는 테이블을 select로 다 조회하는 트랜잭션 E

  select * from member

E는 위와 같은 쿼리문이 2번 사용되는 트랜잭션이라고 생각하면 된다.

• member라는 테이블에 Insert와 같이 데이터를 하나 추가 후 commit 하는 트랜잭션 F

  INSERT INTO member (member_id, member_name) 
  VALUES (70, 'Jehun')

  commit

1. E에서 1번째 select => Jehun이라는 멤버가 추가되기 전 데이터들이 조회
2. F에서 Insert 후 commit => member 테이블에 Jehun 추가
3. E에서 2번째 select => Jehun이라는 멤버가 추가된 후 데이터들이 조회 => 이 때 Phantom Read가 발생하는 것이다.

기존에 Real MySQL 8.0 책을 정리했을 때 언두 로그를 활용한 Repeatable Read에 대해서 잘 몰랐는데 이제 어느 정도 이해가 된 것 같다.

트랜잭션과 무결성파트의 격리성에 대해 다뤄볼까 한다.

여러 개의 격리 수준이 있는데 내용이 어려워서 직접 정리를 하면서 봐야 알 수 있지 않을까 싶어서 해본다.

격리성 : 트랜잭션 수행 시 서로 끼어들지 못하는 것

여러 개의 병렬 트랜잭션은 서로 격리돼 순차적으로 실행되는 것처럼 작동돼야 한다.

그리고 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 한다.

순차적으로 접근할 수 있게 하면 쉽겠지만 성능이 별로기 때문에 여러 개의 격리 수준으로 나눠 격리성을 보장한다.

• READ UNCOMMITED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

순서가 위로 갈수록 동시성이 강하면서 / 격리성은 약해진다.

SERIALIZABLE

가장 엄격한 격리 수준이다. SERIALIZABLE에서 여러 트랜잭션이 동일한 레코드에 동시 접근 불가, 어떠한 데이터 부정합 문제도 발생 X 하지만 트랜잭션이 순차적으로 처리되어야 하므로 동시 처리 성능이 매우 떨어진다.

MySQL에서 SELECT FOR SHARE/UPDATE는 대상 레코드에 각각 읽기/쓰기 잠금을 거는 것이다. 하지만 순수한 SELECT 작업은 아무런 레코드 잠금 없이 실행된다.

• 잠금 없는 일관된 읽기(Non-locking consistent read) : 순수한 SELECT 문을 통한 잠금 없는 읽기를 의미하는 것

그럼에도 SERIALIZABLE는 순수한 SELECT 작업에서도 대상 레코드에 넥스트 키 락을 읽기 잠금(공유락, Shared Lock)으로 건다.

따라서 한 트랜잭션에서 넥스트 키 락이 걸린 레코드를 다른 트랜잭션에서는 절대 추가/수정/삭제할 수 없다.

참고로, 스프링이 제공하는 트랜잭션 AOP 기능은 개발자가 별도로 트랜잭션 격리수준을 설정하지 않을 경우 데이터소스의 기본 트랜잭션 격리수준을 따르게 된다.

즉, 따로 격리수준을 설정하면 SERIALIZABLE 로도 격리수준 설정이 가능하다.

설정하지 않고 MySQL InnoDB 스토리지 엔진 기반의 테이블을 사용한다면 Repeatable Read 격리 수준을 따르게 된다.

동시성 이슈

그럼 동시성 이슈(Lost Update)를 해결하기 위해서 SERIALIZABLE를 적용해야 할까?

동시성 이슈에 대한 대표적인 사례인 '재고 이슈'를 보면

ex) 어느 하나의 재고에 대해 n개가 있는데 변경 작업(재고 1 감소)을 시도하는 A 트랜잭션이 종료되기 전 B 트랜잭션이 실행된다면?

• SERIALIZABLE 적용 전

A 트랜잭션에서 n개 -> n - 1개로 줄이는 과정에서 B 트랜잭션이 시도돼 n개로 알고 있지만 실제로는 A에서 재고 변경이 일어나면서 n - 1개가 된 상태일 때.

트랜잭션 A 와 트랜잭션 B 가 거의 동시에 처리될 때, 트랜잭션 B 의 변경작업이 유실(Lost Update)되는 이슈가 발생한다는 것을 예측할 수 있다.

• SERIALIZABLE 적용 후

SELECT 작업 시 공유 잠금을 사용하고 있는 것을 볼 수 있다.

한 트랜잭션에서 특정 레코드에 공유 잠금을 걸었다면 -> 다른 트랜잭션에서는 해당 레코드를 조회하거나 공유 잠금을 걸 수는 있으나, 쓰기 잠금이나 변경 작업은 할 수 없게 된다. (Lock waiting)

그래서 트랜잭션 A 가 해당하는 레코드에 대해 공유 잠금을 동반한 읽기를 하면, 트랜잭션 B 역시 해당 레코드에 대해 공유 잠금을 동반한 읽기를 할 수는 있다.

하지만 변경을 하게 된다면?

트랜잭션 B 가 건 공유 잠금 때문에 Lock waiting 에 빠지게 되며, 트랜잭션 B 역시 변경 작업 수행 시 앞서 트랜잭션 A 가 건 공유 잠금 때문에 Lock waiting 에 빠지게 된다. 즉, 데드락(Dead-lock)이 발생하게 된다.

MySQL의 InnoDB 스토리지 엔진의 경우, 내부적으로 잠금이 교착 상태에 빠지지 않았는지 체크하기 위해 잠금 대기 목록(Wait for list)을 관리한다.

이 때, 별도의 데드락 감지 스레드가 주기적으로 해당 잠금 대기 목록을 검사해 교착 상태에 빠진 트랜잭션들을 찾아서 그 중 하나(또는 여러개)를 강제로 종료한다.

어느 트랜잭션을 먼저 강제 종료할 것인지를 판단하는 기준은 트랜잭션의 언두 로그 양인데, 적은 언두 로그 양을 가진 트랜잭션을 우선적으로 롤백시킨다.

결론적으로, 트랜잭션 격리수준을 Serializable 로 했을 때, 데드락을 발생시키고 다른 트랜잭션을 롤백시킴으로써 Lost Update 를 방지할 수는 있게 된다.

데드락을 발생시키고 다른 트랜잭션을 롤백시킴으로써 Lost Update 를 방지하는 것이 동시성 이슈를 해결하는 좋은 방안일까?

예시로 들었던 동시성 이슈의 근본적 원인은 어떤 트랜잭션이 작업 중인 레코드에 대해 다른 트랜잭션에서도 동시 조회를 허용했기 때문이며,

Serializable로 하더라도 다른 트랜잭션에서 공유 잠금이 걸린 레코드를 조회할 수 있기에 이 데이터를 기반으로 Update 하는 행위 자체는 여전히 가능한 것이다.

이미 한 트랜잭션에서 조회, 수정하는 절차를 하고 있다면 그 해당하는 재고 데이터는 불확실한 상황이기 때문에 다른 트랜잭션이 접근을 하게 해서는 안 되는 것이다.

-> 해당 데이터를 읽고 그 다음 작업들까지 수행할 수 있기 때문에 불필요한 서버 리소스를 낭비하는 것

추가로 데드락으로 인해 롤백되어 희생되는 트랜잭션(= victim)이 발생하는 것도 서버 입장에서 데드락으로 인해 해당 트랜잭션이 롤백되었을 때 발생하는 예외를 별도로 처리해주어야 하기 때문에 고민거리이다.

동시성 이슈 해결책

배타 잠금(exclusive lock) : 공유 잠금과 마찬가지로 SELECT 작업 시 사용하는 것

• 공유 잠금과 달리 배타 잠금이 걸린 레코드에는 다른 트랜잭션에서 쓰기 작업뿐만 아니라 조회 작업도 허용하지 않는다.
• 추가로, 공유 잠금과 배타 잠금을 걸 수도 없다.

사진은 배타 잠금을 적용한 이후의 상황이다.

트랜잭션 격리수준을 Serializable 로 적용했을 때와 달리

트랜잭션 B는 불필요한 작업을 수행하지 않으며, 데드락을 유도하지 않아 둘 중 한 트랜잭션이 롤백될 일도 없다.

즉, 서버 리소스를 보다 효율적으로 사용할 수 있게 되는 것

공유 잠금이나 배타 잠금은 MySQL 수준에서 제공하는 잠금 기능으로 비관적 락(Pessimistic lock)이라고도 부른다.

다음은 Repeatable Read에 대해 정리해보겠다.

CPU 스케줄러는 CPU 스케줄링 알고리즘에 따라 프로세스에서 해야 하는 일을 스레드 단위로 CPU에 할당한다.

CPU 스케줄링 알고리즘이 어떤 프로그램에 CPU 소유권을 줄지 결정하는데

• CPU 이용률은 높게

• 주어진 시간에 많은 일을 하게
• 준비 큐에 있는 프로세스는 적게
• 응답 시간은 짧게

비선점형 방식

프로세스 스스로 CPU 소유권을 포기하는 방식이며, 강제로 프로세스를 중지하지 않는다. 컨텍스트 스위칭으로 인한 부하가 적다.

FCFS

FCFS는 First Come, First Served 로 가장 먼저 온 것을 가장 먼저 처리하는 알고리즘

단점

• 길게 수행되는 프로세스 때문에 준비 큐에서 오래 기다리는 현상 (Convoy effect)이 발생하기도 한다.

SJF

SJF는 Shortest Job First로 실행 시간이 가장 짧은 것을 가장 먼저 실행하는 알고리즘

장점

• 평균 대기 시간이 가장 짧은 알고리즘

단점

• 긴 시간을 가진 프로세스가 실행되는 않는 현상 (Starvation)이 발생하기도 한다.

위와 같은 장점이 있기도 하지만, 실제로는 실행 시간을 알 수 없어 과거에 실행했던 시간을 토대로 추측해서 사용한다.

우선순위

기존 SJF 스케줄링의 경우 긴 시간을 가진 프로세스가 실행되지 않는 현상이 있었다.

오래된 작업일수록 우선 순위를 높이는 방식을 통해 위에 알고리즘에 단점을 보완한 방식

선점형 방식

이는 현대 운영체제가 쓰는 방식

지금 사용하고 있는 프로세스를 알고리즘에 의해 중단 시켜 버리고, 강제로 다른 프로세스에 CPU 소유권을 할당하는 방식

라운드 로빈, SRF, 다단계 큐와 같은 것들이 있다. 알아보자.

라운드 로빈

이는 현대 컴퓨터가 쓰고 있는 스케줄링인 우선순위 스케줄링의 일종

각 프로세스는 동일한 할당 시간을 주고 그 시간 안에 끝나지 못하면 다시 준비 큐 뒤로 가는 알고리즘

시간 할당량을 q 라고 했을 때 N개의 프로세스가 운영된다고 하면 (N-1) * q 시간이 지났을 때 자신의 차례가 된다.

할당 시간 q가 너무 크면 FCFS가 되고, 짧으면 컨텍스트 스위칭이 잦아지면서 오버헤드 -> 비용이 커진다.

일반적으로 전체 작업 시간은 길어지지만 평균 응답 시간은 짧아진다는 특징이 있다.

로드밸런서에서 트래픽 분산 알고리즘으로도 쓰인다.

SRF

SJK는 실행 시간이 더 짧은게 들어와도 기존 작업을 모두 수행하고 그 다음 짧은 작업을 이어간다.

하지만 SRF(Shortest Remaining Time First)는 중간에 더 짧은 작업이 들어오면 수행하던 프로세스를 중지하고 해당 프로세스를 수행하는 알고리즘

다단계 큐

우선순위에 따른 준비 큐를 여러 개 사용하고, 큐마다 라운드 로빈이나 FCFS 등 다른 스케줄링 알고리즘을 적용한 것

큐 간의 프로세스 이동이 안되므로 스케줄링 부담이 적지만 유연성이 그만큼 떨어진다.

스레드 : 프로세스 내 작업의 흐름

프로그램이 메모리에 올라가면 인스턴스화된 것이 프로세스이다. 운영체제의 CPU 스케줄러에 따라 CPU가 프로세스를 실행한다.

프로세스와 컴파일 과정

컴파일(Compile) : 소스코드를 컴퓨터가 이해할 수 있는 기계어로 번역하여 실행할 수 있는 파일을 만드는 작업

위는 프로그램 컴파일 과정 사진이다.

• 전처리

  • 소스 코드의 주석 제거, #include 등 헤더 파일을 병합하여 매크로를 치환

• 컴파일러

  • 오류 처리, 코드 최적화 작업, 어셈블리어로 변환

• 어셈블러

  • 어셈블리어를 목적 코드로 변환

• 링커

  • 프로그램 내에 있는 라이브러리 함수 또는 다른 파일들과 목적 코드로 결합하여 실행 파일을 만듦
  • 실행 파일의 확장자는 .exe또는 .out

프로세스의 상태

생성(create)

프로세스가 생성된 상태를 의미하며, fork() 또는 exec() 함수를 통해 생성 -> 이 때 PCB가 할당된다.

PCB(Process Control Block)?

• 프로세스의 메타데이터들이 저장되어 관리되는 영역
• 프로세스의 중요한 정보를 포함하고 있기 때문에 일반 사용자가 접근하지 못하도록 커널 스택의 가장 앞부분에서 관리됨
• 프로세스 스케줄링 상태, 프로세스 ID 정보등을 관리

PCB에 대해서는 아래에서 더 다룰 것이다.

대기(ready)

메모리 공간이 충분하면 메모리를 할당 받고, 아니면 아닌 상태로 대기하고 있으며 CPU 스케줄러부터 CPU 소유권이 넘어오기를 기다리는 상태

대기 중단(ready suspended)

메모리 부족으로 일시 중단된 상태

실행(running)

CPU 소유권과 메모리를 할당받고 인스트럭션을 수행 중인 상태

중단(blocked)

어떤 이벤트가 발생한 이후 기다리며 프로세스가 차단된 상태 ex) 프린트 인쇄 버튼을 눌렀을 때 프로세스가 잠깐 멈추는 현상

일시중단(blocked suspended)

중단된 상태에서 프로세스가 실행되려고 했지만 메모리 부족으로 일시 중단된 상태

종료(terminated)

메모리와 CPU 소유권을 모두 놓고 종료되는 상태

프로세스의 메모리 구조

프로세스의 메모리 구조 사진이다.

스택, 힙

스택과 힙은 동적 할당이 되며, 동적 할당이란 런타임 단계에서 메모리를 할당받는 것을 말한다.

• 스택 : 지역 변수, 매개 변수, 실행되는 함수에 의해 늘거나 줄어드는 메모리 영역이다. 함수가 호출될 때마다 호출될 때의 환경 등 특정 정보가 스택에 게속해서 저장된다.

• 힙 : 동적으로 할당되는 변수들을 담는다. 동적으로 관리되는 자료 구조의 경우 힙 영역을 사용한다. 예를 들어 vector는 내부적으로 힙 영역을 사용한다.

데이터 영역과 코드 영역

데이터 영역과 코드 영역은 정적 할당되는 영역이다. 정적 할당 은 컴파일 단계에서 메모리를 할당하는 것을 말한다. 여기서 데이터 영역은 BBS segment와 Data segment, code/text segment로 나뉘어서 저장하게 된다.

• BBS segment 는 전역 변수 또는 static, const로 선언되어 있고, 0으로 초기화 또는 초기화가 어떤 값으로도 되어 있지 않은 변수들이 이 메모리 영역에 할당된다.

• Data segment 는 전역 변수 또는 static, const로 선언되어 있고 0이 아닌 값으로 초기화된 변수를 이 메모리에 할당한다.

• code segment 는 프로그램의 코드가 들어간다.

PCB

위에서 일부 작성했던 PCB에 대해서 더 다뤄보자.

PCB(Process Control Block)?

• 프로세스의 메타데이터들이 저장되어 관리되는 영역
• 프로세스의 중요한 정보를 포함하고 있기 때문에 일반 사용자가 접근하지 못하도록 커널 스택의 가장 앞부분에서 관리됨
• 프로세스 스케줄링 상태, 프로세스 ID 정보등을 관리

PCB의 구조

• 프로세스 스케줄링 상태: '준비','일시중단'등 프로세스가 CPU에 대한 소유권을 얻은 이후의 상태
• 프로세스 ID: 프로세스 ID, 해당 프로세스의 자식 프로세스 ID
• 프로세스 권한: 컴퓨터 자원 또는 I/O 디바이스에 대한 권한 정보
• 프로그램 카운터: 프로세스에서 실행해야 할 다음 명령어의 주소에 대한 포인터
• CPU 레지스터: 프로세스를 실행하기 위해 저장해야 할 레지스터에 대한 정보
• CPU 스케줄링 정보: CPU 스케줄러에 의해 중단된 시간 등에 대한 정보
• 계정 정보: 프로세스 실행에 사용된 CPU 사용량, 실행한 유저의 정보
• I/O 상태 정보: 프로세스에 할당된 I/O 디바이스 목록

컨텍스트 스위칭

PCB를 기반으로 프로세스의 상태를 저장하고 로드시키는 과정으로, PCB를 교환하는 과정이라고 보면 된다.

한 프로세스에 할당된 시간이 끝나거나 인터럽트에 의해 발생한다.

컴퓨터는 여러 프로그램을 동시에 실행하는 것이 아니라 단 한 개만을 실행하고 있다.

• 이 또한 현대는 멀티코어의 CPU기 때문에 지금이랑은 다르다.

싱글코어라고 생각하고 보자.

싱글코어일 때도 우리가 여러 개가 동시에 돌아간다고 생각하고 있는 이유는 이 컨텍스트 스위칭이 매우 빠르게 실행되고 있기 때문이다.

A프로세스가 실행하다 멈추고 A의 PCB를 저장하고 B프로세스를 로드하여 실행한다.

그리고 B PCB에 저장하고 A PCB를 다시 불러오는 방식이다. 이때 컨텍스트 스위칭이 일어날 때 대기하는 유효기간이 발생한다.

이뿐만 아니라 더 드는 비용이 있는데, 바로 캐시미스이다. -> 프로세스가 가지고 있는 메모리 주소가 그대로 있으면 잘못된 주소 변환이 생기므로 캐시클리어 과정을 겪게 되는데, 이때 캐시미스 가 발생한다.

멀티프로세싱

프로세스를 여러 개 수행하는 것

장점

• 하나 이상의 일을 병렬로 처리할 수 있다.
• 특정 프로세스의 메모리, 프로세스 중 문제가 생겨도 다른 프로세스로 처리 가능해 신뢰성이 높다.

웹 브라우저

1. 브라우저 프로세스: 주소 표시줄, 북마크 막대, 뒤로 가기 버튼, 앞으로 가기 버튼 등을 담당하며 네트워크 요청이나 파일 접근 같은 권한을 담당한다.
2. 렌더러 프로세스: 웹 사이트가 '보이는' 부분의 모든 것을 제어한다.
3. 플러그인 프로세스: 웹 사이트에서 사용하는 플러그인을 제어한다.
4. GPU 프로세스: GPU를 이용해서 화면을 그리는 부분을 제어한다.

IPC

프로세스끼리 데이터를 주고 받고, 공유 데이터를 관리하는 매커니즘

멀티프로세스는 IPC가 가능하다.

ex) 클라이언트와 서버 클라이언트 : 데이터를 요청 서버 : 클라이언트 요청에 응답

종류들에 대해서도 알아보자.

• 공유 메모리
• 파일
• 소켓
• 익명 파이프
• 명명 파이프
• 메시지 큐

메모리를 완전히 공유하는 스레드보다는 속도가 떨어지는데 스레드에 대해서도 이후에 알아보자.

공유 메모리

여러 프로세스가 동일한 메모리 블록에 대한 접근 권한이 부여돼 프로세스가 공유된 메모리에서 서로 통신하는 방식

장점 메모리 자체를 공유하기 때문에 불필요한 데이터 복사의 오버헤드가 발생하지 않아 가장 빠르다.

장점에 의한 고려사항 같은 메모리 영역을 공유하기 때문에 동기화 작업이 필요하다.

파일

디스크에 저장된 데이터 또는 파일 서버에서 제공한 데이터를 말한다.

소켓

동일한 컴퓨터의 다른 프로세스나 네트워크의 다른 컴퓨터로 네트워크 인터페이스를 통해 전송하는 데이터를 의미한다.

예시로는 TCP, UDP가 있다.

익명 파이프

프로세스 간에 FIFO 방식으로 읽히는 임시 공간인 파이프를 기반으로 데이터를 주고 받으며, 단방향 방식 의 읽기 전용, 쓰기 전용 파이프를 만들어서 작동하는 방식

명명된 파이프

파이프 서버와 하나 이상의 파이프 클라이언트 간의 통신을 위한 명명된 단방향 or 양방향 파이프

클라이언트/서버 통신을 위한 별도의 파이프를 제공하며, 여러 파이프를 동시에 사용할 수 있다.

이를 통해 컴퓨터의 프로세스끼리 또는 다른 네트워크 상의 컴퓨터와도 통신을 할 수 있다.

메시지 큐

메시지를 큐에 형태로 관리하는 것을 의미한다.

커널의 전역변수 형태 등 커널에서 전역적으로 관리된다.

장점

• 매우 직관적이며, 간단하다.
• 다른 코드의 수정 없이 단지 몇 줄의 코드를 추가시켜 간단하게 접근할 수 있다

스레드와 멀티스레딩

스레드

프로세스의 실행 가능한 가장 작은 단위

프로세스는 여러 스레드를 가질 수 있다.

프로세스와 스레드의 차이점 프로세스는 코드, 데이터, 스택, 힙 영역을 각각 생성 스레드는 코드, 데이터 힙 영역을 서로 공유한다. 그 외의 영역은 각각 생성된다.

멀티스레딩

이는 프로세스 내 작업을 여러 개의 스레드, 멀티 스레드로 처리하는 기법을 말한다.

장점

• 스레드끼리 자원을 서로 공유하기 때문에 효율성이 높다.
• 동시성도 큰 장점이 있다.

단점 한 스레드가 문제가 생기면 다른 스레드도 영향을 끼친다는 단점이 있다.

동시성이란? : 서로 독립적인 작업들을 작은 단위로 나누고 동시에 실행되는 것처럼 보여주는 것

공유 자원과 임계 영역

공유 자원

시스템 안에서 각 프로세스, 스레드가 함께 접근할 수 있는 모니터, 프린터, 메모리, 파일, 데이터 등의 자원이나 변수 등을 의미

이 공유 자원을 두 개 이상의 프로세스가 동시에 읽거나 쓰이는 상황을 경쟁 상태 라고 한다.

이 때문에 접근의 타이밍이나 순서 등이 결과값에 영향을 준다.

예시 사진

임계 영역

둘 이상의 프로세스, 스레드가 공유 자원에 접근할 때 순서 등의 이유로 결과가 달라지는 코드 영역

이를 해결하기 위해선 크게 뮤텍스, 세마포어, 모니터 세 가지가 있다.

이 방법 모두 상호 배제, 한정 대기, 융통성이라는 조건을 만족하며

위 3가지 방법에 토대가 되는 메커니즘은 잠금(lock) 이다.

ex) 화장실 사용 시 문 잠그고 사용한 뒤 나오면 다음 사람이 사용하는 것

• 상호배제 : 한 프로세스가 임계 영역에 들어갔을 때 다른 프로세스는 들어갈 수 없다.
• 한정 대기 : 특정 프로세스가 영원히 임계 영역에 들어가지 못하면 안 된다.
• 융통성 : 한 프로세스가 다른 프로세스의 일을 방해해서는 안 된다.

뮤텍스

프로세스나 스레드가 공유 자원을 lock()을 통해 잠금 설정하고 사용한 후에는 unlock()을 통해 잠금 해제하는 방식

세마포어

일반화된 뮤텍스로, 간단한 정수 값과 두 가지 함수 wait 함수, signal 함수로 공유 자원에 대한 접근을 처리한다.

wait()는 자신의 차례가 올때까지 기다리는 함수이며, signal()은 다음 프로세스 순서로 넘겨주는 함수를 말한다.

공유 자원에 접근하려면, 세마포어에서 wait()를 수행하고 공유 자원을 해제하면 signal() 작업을 수행한다.

세마포어의 종류

• 바이너리 세미포어 0과 1의 두가지 값만 가질 수 있는 세마포어이다. 이는 신호 메커니즘으로 신호를 기반으로 일어난다.

• 카운팅 세마포어 이는 여러 개의 값을 가질 수 있는 세마포어이다. 여러 자원에 대한 접근을 제어하는데 사용된다.

모니터

둘 이상의 스레드나 프로세스가 공유 자원에 안전하게 접근할 수 있도록 공유자원을 숨기고, 해당 접근에 대해 인터페이스만을 제공한다.

모니터와 세마포어의 차이점

• 모니터는 세마포어보다 구현하기 쉽고, 상호 배제는 자동
• 세마포어는 상호 배제를 명시적으로 구현해야 한다.

교착 상태

교착 상태 : 두 개 이상의 프로세스들이 서로가 가진 자원을 기다리며 중단된 상태

원인

• 상호 배제 : 한 프로세스가 자원을 독점하고 있으며 다른 프로세스는 접근이 불가능하다.
• 점유 대기 : 특정 프로세스가 점유한 자원을 다른 프로세스가 요청하는 상태
• 비선점 : 다른 프로세스의 자원을 강제적으로 가져올 수 없다.
• 환형 대기 : 프로세스 A는 프로세스 B의 자원을 요구하고, 프로세스 B는 프로세스 A의 자원을 요구하는 등 서로가 서로의 자원을 요구하는 상황

해결방법

1. 자원을 할당할 때 애초에 조건이 성립되지 않도록 설계한다.
2. 교착 상태 가능성이 없을 때만 자원 할당되며, 프로세스당 요청할 자원들의 최대치를 통해 자원 할당 가능 여부를 파악하는 은행원 알고리즘 을 쓴다.

은행원 알고리즘 총 자원의 양과 현재 할당한 양을 기준으로 안정 또는 불안정 상태로 나누고 안정 상태로 가도록 자원을 할당하는 알고리즘

3. 교착 상태가 발생하면 사이클이 있는지 찾아보고 이에 관련된 프로세스를 한 개씩 지운다.
4. 교착 상태는 매우 드물게 일어나고 비용이 크기 때문에 현대 운영체제에서는 사용자가 작업을 종료하는 방법을 채택했다.

CPU는 메모리에 올라와 있는 프로그램의 명령어를 실행할 뿐이며, 메모리 계층과 메모리 관리에 대해 알아보자.

메모리 계층

• 레지스터 : CPU 안에 있는 가장 작은 메모리
  • 휘발성
  • 속도 가장 빠름
  • 용량 가장 작음
• 캐시 : L1, L2 캐시를 지칭한다.
  • 휘발성
  • 속도 빠름
  • 용량 작음
• 주기억장치 (RAM)
  • 휘발성
  • 속도 보통
  • 용량 보통
• 보조기억장치 (HDD, SSD)
  • 비휘발성
  • 속도 낮음
  • 용량 큼

캐시

데이터를 미리 복사해놓는 임시 저장소로 빠른 장치와 느린 장치의 속도 차이에 따른 병목 현상을 줄이기 위한 메모리이다.

메모리와 CPU의 속도 차이가 너무 커 중간에 레지스터 계층을 둬 속도 차이를 해결하는데, 이 때 속도 차이를 해결하기 위해서 계층과 계층 사이에 있는 것을 캐싱 계층이라고 한다.

ex) 캐시 메모리 <-> 보조기억장치 사이에 있는 주기억장치 : 보조기억장치의 캐싱 계층

지역성의 원리

캐싱 계층을 두는 것이 아닌 직접 캐시를 설정할 때 : 자주 사용하는 데이터를 기반으로 캐시를 설정해야 한다.

자주 사용하는 데이터라는 개념의 근거? : 지역성

• 시간 지역성
• 공간 지역성

시간 지역성

최근 사용한 데이터에 다시 접근하려는 특성

ex) for 반복문으로 이루어진 코드 안의 변수 i 에 계속 접근하게 될텐데 반복하면서 최근에 사용한 i에 계속 접근해 +1 시켜서 반복하는 것을 생각해볼 수 있다.

공간 지역성

최근 접근한 데이터를 이루고 있는 공간이나 그 가까운 공간에 접근하는 특성

캐시히트와 캐시미스

캐시히트 : 캐시에서 원하는 데이터를 찾는 것 캐시미스 : 캐시에 원하는 데이터가 없어 주 메모리에서 찾아오는 것

캐시히트를 하게 되면 해당 데이터를 제어장치를 거쳐 가져오게 된다.

캐시히트는 비교적 위치가 가깝고 CPU 내부 버스를 기반으로 작동해 빠르다.

하지만, 캐시미스가 발생하면 시스템 버스를 기반으로 작동해 느리다.

캐시미스의 종류

1. 컴펄서리 미스(Compulsory Miss) : 처음으로 접근하는 데이터 때문에 발생하는 미스 어떤 데이터가 처음 캐시에 로드될 때 발생

2. 캐피시티 미스(Capacity Miss) : 캐시의 크기가 작아서 발생하는 미스 캐시에 데이터가 너무 많이 들어가면 오래된 데이터가 제거되고, 나중에 다시 그 데이터가 필요하면 미스가 발생

3. 컨플릭트 미스(Conflict Miss) : 캐시 라인에 여러 데이터가 매핑되어 충돌이 발생할 때 생기는 미스 이는 주로 캐시의 매핑 정책과 관련

캐시매핑

캐시매핑 : 캐시가 히트되기 위해 매핑하는 방법

1. 직접 매핑 : 메모리의 특정 블록은 특정 캐시라인에만 매핑할 수 있는 것
2. 연관 매핑 : 순서를 일치시키지 않고 관련 있는 캐시와 메모리를 매핑하는 것 메모리의 컨텐츠가 캐시의 어느 위치에도 올라갈 수 있는 방법이다.
3. 집합 연관 매핑 : 직접 매핑과 연관 매핑을 합쳐 놓은 것으로, 집합을 나누고 각 집합에 직접 매핑을 사용하는 것

캐시 매핑 방식에 대해서 잘 정리해두신 분을 보고 참고하려는 목적으로 링크를 남기고자 한다..

캐시 매핑 분류

다음은 웹 브라우저의 캐시를 알아보자.

쿠키

만료기한이 있는 키-값 저장소다.

이전에 쿠키를 사용했을 때 same site 옵션을 strict 방식으로 사용해야지만 다른 도메인에서 요청했을 때 자동 전송이 되지 않게 제한을 걸 수 있었다.

4KB까지 저장 가능하며, 위에서 말한 것처럼 만료기한도 설정 가능하다.

그리고 document cookie로 쿠키를 볼 수 없게 httponly 옵션 또한 걸어둬야 한다.

보통 서버에서 만료기한을 설정한다.

로컬 스토리지

만료기한이 없는 키-값 저장소다.

5MB까지 저장 가능하며, 웹 브라우저를 닫아도 유지된다.

그리고 HTML5를 지원하지 않는 웹 브라우저라면 사용 불가능, 클라이언트에서만 수정 가능하다.

세션 스토리지

만료기한이 없는 키-값 저장소다.

탭 단위로 세션 스토리지를 생성하고, 탭을 닫을 때 데이터가 삭제된다.

로컬 스토리지와 마찬가지로 5MB까지 저장 가능하고 HTML5를 지원하지 않는 웹 브라우저라면 사용 불가능, 클라이언트에서만 수정 가능하다.

데이터베이스의 캐싱 계층

메인 데이터베이스 위에 redis를 활용해 캐싱 계층으로 활용하기도 한다.

로그인 기능을 할 때 주로 사용했었다.

1. 데이터를 레디스에 쓴다. 2 - 1. 앱은 redis로부터 데이터가 있다면(캐시히트) 읽어온다. 2 - 2. 없다면 (캐시미스) 메인 데이터베이스로부터 가져온다.

메모리 관리

OS의 대표적인 할 일인 메모리 관리에 대해 알아보자.

가상 메모리

실제로 이용 가능한 메모리 자원을 추상화 해 이를 사용하는 사용자들에게 매우 큰 메모리로 보이게 만드는 것

가상 메모리에는 가상 주소와 실제 주소가 매핑돼 있고, 프로세스의 주소 정보가 있는 페이지 테이블로 관리된다.

가상 주소는 메모리관리장치(MMU)에 의해 실제 주소로 변환돼 그로 인해 사용자는 실제 주소를 의식할 필요 없이 프로그램을 구축할 수 있다.

이 때 속도 향상을 위해서는 TLB를 사용하는데

TLB : 메모리와 CPU 사이에 있는 주소 변환을 위한 캐시 페이지 테이블에 있는 리스트를 보관하여 CPU가 페이지 테이블까지 가지 않도록 해 속도를 향상시킬 수 있다.

스와핑

가상 메모리는 존재하는데 실제 메모리인 RAM 에는 현재 없는 데이터 or 코드에 접근하는 경우 -> 페이지 폴트 발생

스와핑 : 메모리에서 당장 사용하지 않는 영역을 하드디스크로 옮기고 하드디스크의 일부를 메모리처럼 불러와 쓰는 것

마치 페이지 폴트가 발생하지 않은 것처럼 만든다.

페이지 폴트

프로세스의 주소 공간에는 존재하지만 RAM에는 없는 데이터에 접근했을 경우에 발생

위 스와핑, 페이지 폴트는 아래 과정으로 이루어진다.

1. 어떤 명령어가 유효한 가상 주소에 접근했는데 페이지가 없을 때

-> 트랩 발생 -> OS가 알게 된다. 2. OS는 실제 디스크로부터 사용하지 않은 프레임을 찾는다. 3. 해당 프레임을 실제 메모리에 가져와서 페이지 교체 알고리즘을 기반으로 특정 페이지와 교체한다.

• 이 때 스와핑이 발생
  4. 페이지 테이블을 갱신시킨 후 해당 명령어를 다시 시작

• 페이지 : 가상 메모리를 사용하는 최소 크기 단위
• 프레임 : 실제 메모리를 사용하는 최소 크기 단위

스레싱

스레싱 (thrashing) : 메모리의 페이지 폴트율이 높은 것

스레싱은 메모리에 너무 많은 프로세스가 동시에 올라가게 되면 스와핑이 많이 일어나서 발생한다.

페이지 폴트가 일어나면 CPU 이용률이 낮아짐 -> 이용률이 낮아지면 컴퓨터는 CPU 가용성을 더 높이기 위해 더 많은 프로세스를 메모리에 올림 -> 악순환.. (= 스레싱)

해결방법

1. 메모리 늘리기
2. HDD 사용 시 -> SSD로 바꾸기
3. 작업 세트
4. PFF

작업 세트부터 알아보자.

작업 세트

작업 세트 : 지역성 (프로세스의 과거 사용 이력)을 통해 결정된 페이지 집합을 만들어 미리 메모리에 로드하는 것

미리 메모리에 로드하면 좋은 점

• 탐색에 비용 줄이기
• 스와핑 줄이기

PFF

PFF (Page Fault Frequency) : 페이지 폴트 빈도를 조절하는 방법으로 상한선, 하한선을 만드는 방법

상한선에 도달하면 프레임을 늘리고, 하한선에 도달하면 줄이는 방식이다.

메모리 할당

메모리에 프로그램을 할당할 때는 시작 메모리 위치, 메모리 할당 크기를 기반으로 할당한다.

이것을 연속 할당, 불연속 할당으로 나눈다.

연속 할당

메모리에 연속적으로 공간을 할당하는 것

위와 같이 순차적으로 공간에 할당할 수 있다.

방식이 2가지가 있는데

1. 고정 분할 방식 : 메모리를 미리 나누어 관리하는 방식

   • 메모리가 미리 나눠져 있어 융통성이 없고, 내부 단편화가 발생한다.

2. 가변 분할 방식 : 매 시점 프로그램의 크기에 맞게 메모리를 분할해 사용하는 방식

   • 외부 단편화 발생

가변 분할 방식의 종류

• 최초 적합 (first fit) : 위쪽 or 아래쪽부터 시작해 홀을 찾으면 바로 할당
• 최적 적합 (best fit) : 프로세스의 크기 이상인 공간 중 가장 작은 홀부터 할당
• 최악 적합 (worst fit) : 프로세스의 크기와 가장 많이 차이나는 홀에 할당

내부 단편화 : 메모리를 나눈 크기보다 프로그램이 작아 들어가지 못하는 공간이 많이 발생하는 현상

외부 단편화 : 메모리를 나눈 크기보다 프로그램이 커서 들어가지 못하는 공간이 많이 발생하는 현상

홀 : 할당할 수 있는 비어 있는 메모리 공간

불연속 할당

현대 운영체제가 쓰는 방법으로 페이징 기법이 있다.

추가로 세그멘테이션, 페이지드 세그멘테이션 기법들도 있다.

페이징

페이징 기법 : 메모리를 동일한 크기의 페이지로 나누고 프로그램마다 페이지 테이블을 둬 메모리에 프로그램을 할당하는 것

세그멘테이션

세그멘테이션 : 페이지 단위가 아닌 의미 단위인 세그먼트로 나누는 방식이다.

프로세스를 이루는 메모리는 아래 4개 영역으로 나뉜다.

• 코드 영역
• 데이터 영역
• 스택 영역
• 힙 영역

세그먼트로 나눈다는 것은 위의 영역에서도 코드와 데이터로 나누거나, 코드 내의 작은 함수와 같은 것들을 세그먼트로 놓고 나눌 수도 있다.

공유와 보안 측면에서 장점 / 홀 크기가 균일하지 않다는 단점

페이지드 세그멘테이션

페이지드 세그멘테이션 : 의미 단위인 세그먼트로 나누는 방식으로, 세그멘테이션과는 임의의 길이가 아닌 동일한 크기의 페이지 단위로 나누는 것에 차이가 있다.

페이지 교체 알고리즘

메모리는 한정돼 있어 스와핑이 많이 일어나는데, 많이 일어나지 않기 위해 설계되는 페이지 교체 알고리즘이 있다.

이러한 알고리즘에 따라 스와핑이 생기는 것이다.

FIFO (First In First Out)

가장 먼저 온 페이지를 교체 영역에 가장 먼저 놓는 방법

LRU (Least Recently Used)

참조가 가장 오래된 페이지를 바꾼다. 오래된 것을 파악하기 위해 각 페이지마다 계수기, 스택을 두어야 하는 문제점이 있다.

NUR(Not Used Recently)

LRU에서 발전한 알고리즘이다.

clock 알고리즘 이라고 하며 먼저 0과 1을 가진 비트를 둔다. 1은 최근에 참조되었고, 0은 참조되지 않음을 의미한다. 시계 방향으로 돌면서 0을 찾고 0을 찾은 순간 해당 프로세스를 교체하고, 해당 부분을 1로 바꾸는 알고리즘이다.

LFU(Least Frequently Used)

가장 참조 횟수가 적은 페이지를 교체한다. 즉, 많이 사용하지 않은 것을 교체한다.

운영체제 (OS, Operating System) 은 간단하게 사용자가 컴퓨터를 쉽게 다루게 해주는 인터페이스로 한정된 메모리, 자원을 효율적으로 분배하는 것이다.

비슷한 것으로 펌웨어 (firmware) 라는 것이 있는데 펌웨어는 소프트웨어를 추가로 설치할 수 없다는 차이가 있다.

운영체제와 컴퓨터

• 하드웨어와 소프트웨어를 관리하는 운영체제
• CPU, 메모리 등으로 이루어진 컴퓨터

위 2가지를 알아보자.

운영체제 역할과 구조

운영체제의 역할

운영체제의 역할을 알아보자.

1. CPU 스케줄링, 프로세스 관리 : CPU 소유권을 어떤 프로세스에 할당할 지, 프로세스의 생성과 삭제, 자원 할당 및 반환 관리
2. 메모리 관리 : 한정된 메모리를 어떤 프로세스에 얼만큼 할당해야 하는지 관리
3. 디스크 파일 관리 : 어떠한 방법으로 디스크 파일을 보관할 지 관리
4. I/O 디바이스 관리 : I/O 디바이스 (마우스, 키보드와 같은) 와 컴퓨터 간 데이터 주고 받는 것 관리

운영체제의 구조

사진과 같이 맨 위에 소프트웨어 ~ 맨 아래에 하드웨어가 있는 구조인데, 중간에 표시한 부분이 운영체제 부분이다.

GUI가 없고 CUI만 있는 리눅스 서버도 있긴 하다.

GUI (Graphical User Interface) : 아이콘을 마우스로 클릭하는 것 같이 명령어를 입력해서 상호작용하는 것이 아닌 단순한 동작으로 컴퓨터와 상호작용할 수 있는 사용자 인터페이스의 형태

드라이버 : 하드웨어를 제어하기 위한 소프트웨어

CUI : 명령어로 처리하는 인터페이스

시스템 호출 (시스템 콜)

운영체제가 커널에 접근하기 위한 인터페이스

소프트웨어가 운영체제의 서비스를 받기 위해 커널 함수를 호출할 때 사용한다.

소프트웨어가 I/O 요청으로 트랙을 발동하면 올바른 I/O 요청인지 확인 후 유저 모드였던 시스템 콜이 커널 모드로 변환돼 요청에 맞춰 파일 시스템에 영향을 준다.

참고 링크

ex) fs.readFile()라는 파일 시스템 파일을 읽는 함수가 있다면 커널 모드로 읽고 유저 모드로 돌아가 소프트웨어의 로직 수행

이 과정으로 컴퓨터 자원에 직접 접근하는 것을 차단할 수도 있고, 프로그램을 다른 프로그램으로부터 보호할 수 있다.

프로세스 or 스레드에서 OS로 어떠한 요청을 한다면 시스템 콜 인터페이스와 커널을 거쳐 운영체제에 전달된다.

시스템 콜은 하나의 추상화 계층이기 때문에 아래와 같은 장점이 있다.

장점 유저 프로그램은 시스템 콜을 기반으로 커널과 분리가 된다. 즉, 유저 프로그램은 복잡한 파일 시스템, 프로세스 생성 등과 같은 내부 동작을 신경 쓸 필요 없다. 또, OS의 관리 하에 프로그램이 운영되기 때문에 시스템의 안정성, 보안이 강화된다.

ex) 공격자가 만든 카메라 앱 프로그램이 아무 제약 없이 커널에 접근할 수 있다면, 카메라와 관련된 메모리가 오염돼 사용자의 의도와 관계 없이 카메라가 켜지거나 사생활 노출이 될 수 있다.

그래서 유저 모드에서 시스템 콜로만 커널 모드에 진입할 수 있게 한 것이다.

쉽게 이야기하면 아래와 같다.

• 네트워크 통신이나 DB같은 낮은 단계의 영역 처리에 대한 부분을 많이 신경쓰지 않고 프로그램 구현할 수 있다.

modebit

시스템 콜은 작동될 때 modebit 를 참고해서 유저 모드와 커널 모드를 구분한다.

0은 커널 모드, 1은 유저 모드로 무조건 이 플래그 변수로 작동해야 한다.

유저 모드를 기반으로 프로그램이 작동되면 공격자가 악의적인 행위를 할 수 있게 된다.

ex) 카메라를 키는 프로그램을 예시로 든 사진이다.

컴퓨터(하드웨어) 의 요소

CPU

CPU (Central Processing Unit) : 산술논리연산장치, 제어장치, 레지스터로 구성된 장치

CPU는 인터럽트에 의해 메모리에 존재하는 명령어를 해석해서 실행하는 역할을 한다.

관리자의 역할을 하는 운영체제의 커널이 프로그램을 메모리에 올려 프로세스로 만들면 CPU가 처리한다.

산술논리연산장치

산술논리연산장치 (Arithmetic Logic Unit) : 덧셈, 뺄셈 같은 산술 연산과 배타적 논리합, 논리곱 같은 논리 연산을 계산하는 디지털 회로다.

제어장치 (CU)

제어장치 (Control Unit) : 프로세스 조작을 지시하는 부품 I/O 장치 간 통신을 제어하고 명령어를 읽고 해석하며 데이터 처리를 위한 순서를 결정

레지스터

레지스터 : CPU 안에 있는 매우 빠른 임시 기억 장치 연산 속도가 메모리보다 월등히 빠르며, CPU에 자체적으로 데이터를 저장할 방법이 없어 레지스터를 거쳐 데이터를 전달한다.

CPU 연산 처리

위 장치들을 통해 연산하는 예시는 아래와 같다.

참고 링크

1. 제어장치가 메모리와 레지스터에 계산할 값을 로드한다.
2. 제어장치가 레지스터에 있는 값을 계산하라고 산술논리연산장치에 명령하면
3. 제어장치가 계산된 값을 다시 레지스터 -> 메모리로 계산한 값을 저장한다.

인터럽트

어떤 신호가 왔을 때 CPU를 잠깐 정지시키는 것을 말한다.

인터럽트가 발생하면 인터럽트 핸들러 함수가 모여있는 인터럽트 벡터로 가서 핸들러 함수를 실행한다.

물론 인터럽트 간에는 우선순위가 있어서 그것에 따라 실행되고, 하드웨어/소프트웨어 인터럽트 2가지가 있다.

인터럽트 핸들러 함수 : 인터럽트가 발생할 때 이를 핸들링하기 위한 함수

하드웨어 인터럽트

키보드를 연결하거나 마우스를 연결하는 것처럼 I/O 디바이스에서 발생하는 인터럽트

ex) 마우스 클릭, 디스크에서 파일 읽기/쓰기 작업이 완료됐을 때 발동

소프트웨어 인터럽트

트랩이라고도 하며 프로세스 오류 등으로 프로세스가 시스템콜을 호출할 때 발동한다.

하드웨어 인터럽트보다 우선순위가 높다.

DMA 컨트롤러

I/O 디바이스가 메모리에 직접 접근할 수 있도록 하는 하드웨어 장치를 뜻한다.

CPU에 너무 많은 인터럽트 요청이 들어오는데 그로 인한 부하를 DMA 컨트롤러가 막아준다.

• CPU와 DMA 컨트롤러가 동시에 같은 작업을 하는 것도 방지한다.

메모리

전자회로에서 데이터나 상태, 명령어 등을 기록하는 장치

보통 RAM을 메모리라고도 한다.

CPU 가 계산을 한다면, 메모리는 기억을 담당한다.

타이머

특정 프로그램에 시간 제한을 다는 역할

만약 프로그램이 무한 루프에 빠지게 된다면 그 프로그램때문에 컴퓨터 자원을 많이 소모하기 때문에 시간 제한이 필요하다. 그것을 위해 타이머가 존재한다.

디바이스 컨트롤러

컴퓨터와 연결돼 있는 I/O 디바이스들의 작은 CPU라고 보면 된다. 옆에 붙어 있는 로컬 버퍼는 각 디바이스에서 데이터를 임시로 저장하기 위한 작은 메모리 역할이다.

HTTP는 애플리케이션 계층으로서 웹 서비스 통신에 사용된다.

지금은 3버전이며 1.0버전부터 차례대로 알아보자.

HTTP/1.0

설계할 때부터 한 연결 당 1개의 요청을 처리하도록 만들어졌는데

이는 곧 RTT 증가를 불러왔다.

RTT 증가

RTT : 패킷이 목적지에 도달한 뒤 다시 출발지로 돌아올 때까지의 시간 즉, 패킷 왕복 시간

TCP의 3-way handshake 방식으로는 RTT가 계속 일어나게 된다.

1. 클라이언트 - TCP 연결 초기화
2. 클라이언트 - 파일 요청
   • 서버 - 파일 전송
3. 전체 파일 수신

위 3가지 과정 동안 2번의 RTT가 일어나게 된다.

RTT 증가를 해결하는 방법

HTTP/1.0 때는 매번 연결할 때마다 RTT가 증가하기 때문에

• 서버의 부담
• 사용자 응답시간 증가

위 2가지 단점이 있었기에 해결하기 위해

• 이미지 스플리팅
• 코드 압축
• 이미지 Base64 인코딩

3가지 방식을 사용하곤 했다.

이미지 스플리팅

많은 이미지를 다운로드 받는 방식 -> 과부하를 야기

위 문제로 인해 많은 이미지가 합쳐져 있는 하나의 이미지를 다운로드하는 방식으로, 이를 통해 background-image 의 position을 이용해 이미지를 표기하는 방법이다.

장점

• 서버의 요청 수를 줄여 로딩 시간을 단축할 수 있다.
• 스프라이트 이미지 파일만을 관리하기에 관리에 용이하다.

단점

• 스프라이트의 이미지에서 사용하려는 이미지의 정확한 position 값을 알아야 한다.
• 스프라이트 이미지 내에서 특정 이미지를 변경해야 할 때, 단일 파일보다 수정이 번거롭다.

코드 압축

코드를 압축해 개행 문자, 빈칸을 없애서 코드의 크기를 최소화하는 방법이다.

가독성을 위해서는 좋은 방식인지 잘 모르겠다.

이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법

장점

• 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요 없다.

단점

• Base64 문자열로 변환할 경우 37% 정도 크기가 더 커진다..

인코딩 : 정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약을 위해 다른 형태로 변환하는 처리 방식

HTTP/1.1

1.0에서 발전한 것이 1.1이다.

매번 TCP 연결을 하는 것이 아닌, TCP 초기화 이후 keep-alive 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다.

HTTP/1.0과 HTTP/1.1의 비교 사진으로 왼쪽이 1.0, 오른쪽이 1.1이다.

1.1부터는 1번 TCP 3-way handshake가 발생하면 다음부터 발생하지 않는 것을 볼 수 있다.

하지만 이 또한 아래와 같이 단점들이 있다.

• 다수의 리소스를 처리하려면 요청할 리소스 개수에 비례해 대기 시간이 길어진다.
• HOL Blocking
• 무거운 헤더 구조 : HTTP/1.1의 헤더에는 쿠키 등 많은 메타데이터가 들어 있고 압축이 되지 않아 무겁다.

HOL Blocking

HOL Blocking (Head Of Line Blocking) : 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상

만약 image.jpg, styles.css, data.xml 이라는 리소스를 다운로드할 때 순차적으로 받아지긴 하지만, 첫 번째 패킷이 다운로드 시간이 길어지게 된다면 다운로드 시간이 지연되는 상태가 되는데 이 때를 HOL Blocking 현상이라고 한다.

HTTP/2

1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 하여

• 멀티플렉싱
• 헤더 압축
• 서버 푸시
• 요청의 우선순위 처리

위 4가지를 지원하는 프로토콜이다.

멀티플렉싱

여러 개의 스트림을 사용하여 송수신하는 것으로, 하나의 통신 채널을 통해서 둘 이상의 데이터를 전송하는데 사용되는 기술

특정 스트림의 패킷이 손실되었어도 해당 스트림에만 영향을 미치고 나머지 스트림은 정상적으로 동작할 수 있다.

• 스트림 : 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름

헤더 압축

HTTP/2에서는 헤더 압축을 써서 HTTP/1.x에서의 무거운 헤더 구조의 단점을 해결했는데, 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축 형식을 활용했다.

• 허프만 코딩 : 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현해서 전체 데이터의 표현에 필요한 비트양을 줄이는 원리

서버 푸시

HTTP/1.1에서는 파일을 다운로드하려면 클라이언트가 서버에 요청을 해야 한다.

HTTP/2는 클라이언트 요청 없이 서버가 바로 리소스를 푸시할 수 있다.

html에는 css나 js 파일이 포함되기 마련인데, html을 읽으면서 안에 있는 css 파일을 서버에 푸시해 클라이언트에 먼저 줄 수 있다.

HTTPS

HTTP/2는 HTTPS 위에서 동작한다.

HTTPS : 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣어서 신뢰할 수 있는 HTTP 요청을 말한다. -> 통신을 암호화한다.

SSL/TLS

전송 계층에서 보안을 제공하는 프로토콜 클라이언트와 서버가 통신을 할 때 SSL/TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 한다.

SSL(Secure Socket Layer)은 SSL 1.0부터 시작해서 TLS(Transport Layer Security Protocol)로 명칭이 변경되었으나 보통 SSL/TLS이라고 한다.

보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.

• 세션 : 운영체제가 어떤 사용자로부터 자신의 자산 이용을 허락하는 일정한 기간
  • 즉, 사용자는 일정 기간 동안 응용 프로그램, 자원 등을 사용할 수 있다.

HTTP/3

HTTP/3 는 TCP 위에서 돌아갔던 HTTP/2와 다르게 QUIC 라는 계층 위에서 돌아간다.

• 추가로 UDP 기반으로 돌아간다.

참고 링크

장점

• HTTP/2에서 장점이었던 멀티플렉싱
• 초기 연결 설정 시 지연 시간 감소

초기 연결 설정 시 지연 시간 감소

QUIC는 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way handshake 과정을 거치지 않아도 된다.

QUIC는 첫 연결 설정에 1-RTT(Round Trip Time, 왕복 시간)만 소요되고, 클라이언트가 보낸 어떠한 신호에 서버가 응답한다면 바로 통신을 할 수 있다.

Reference

• https://www.informit.com/
• https://babbab2.tistory.com/7

인터넷 계층에 있는 IP 주소에 대해 좀 더 자세히 알아보자.

ARP

IP 주소로부터 MAC 주소를 구하는 IP와 MAC 주소의 다리 역할을 하는 프로토콜

ARP를 통해 가상 주소인 IP 주소를 실제 주소인 MAC 주소로 변환한다.

반대로 RARP를 통해 실제 주소인 MAC 주소를 가상 주소인 IP 주소로 변환하기도 한다.

예시를 들어서 어느 하나의 1번 장치가 있다면,

1. ARP Request 브로드캐스트를 보내서 해당 가상 주소 IP주소에 해당하는 MAC 주소를 찾는다.
2. 해당 주소에 맞는 2번 장치에서 ARP Reply 유니캐스트를 통해 MAC 주소를 반환하는 과정을 거져 IP 주소에 맞는 MAC 주소를 찾게 된다.

브로드캐스트 : 송신 호스트가 전송한 데이터가 네트워크에 연결된 모든 호스트에 전송되는 방식 유니캐스트 : 고유 주소로 식별된 하나의 네트워크 목적에 1:1로 데이터를 전송하는 방식

홉바이홉 통신 (Hop by Hop)

IP 주소를 통해 통신하는 과정

• hop : 건너뛴다는 개념

통신망에서 각 패킷이 여러 개의 라우터를 건너가는 모습을 비유적으로 표현한 것이다.

통신 장치에 있는 라우팅 테이블의 IP를 통해 시작 주소부터 시작해 다음 IP로 계속해서 이동하는 라우팅 과정을 거쳐 패킷이 최종 목적지까지 도달하는 통신을 뜻한다.

라우팅 테이블

송신지에서 수신지까지 도달하기 위해 사용하며 라우터에 들어 있는 목적지 정보들과 해당 목적지로 가기 위한 방법이 들어 있는 리스트

라우팅 테이블에는 게이트웨이와 모든 목적지에 대해 해당 목적지에 도달하기 위해 거쳐야 할 다음 라우터의 정보를 가지고 있다.

게이트웨이

서로 다른 네트워크 간 통신을 가능하게 하는 관문

사용자는 인터넷에 접속하기 위해서 수많은 게이트웨이를 거쳐야 한다.

통신을 가능하게 해준다는 것은 즉, 서로 다른 네트워크 상의 통신 프로토콜을 변환해주는 역할

게이트웨이 확인 방법 라우팅 테이블을 통해 볼 수 있다.

• 라우팅 테이블은 netstat -r 명령어를 실행해 확인 가능 IPv4 경로 테이블, IPv6 경로 테이블이 있는데 이것이 라우팅 테이블이다.

IP 주소 체계

1. IPv4 32비트를 8비트 단위로 점을 찍어서 표기 -> ex) 123.45.67.89

2. IPv6 64비트를 16비트 단위로 점을 찍어서 표기 -> ex) 2001:db8::ff00:12:3456

추세는 IPv6로 가고 있긴 하지만 가장 많이 쓰이는건 IPv4이다.

클래스 기반 할당 방식

네트워크 ID(네트워크 주소)와 호스트 ID(호스트 주소)를 먼저 알아보자.

Network ID, Host ID 하나의 네트워크 주소에는 Network ID와 Host ID 즉, 네트워크 주소와 호스트 주소가 있다.

네트워크 주소란? 인터넷 상에서 모든 host들을 전부하기 힘들기 때문에 한 네트워크의 범위를 지정하여 관리하기 쉽게 만든 것.

호스트 주소란? 호스트를 개별적으로 관리하기 위해 사용하게 된 것.

클래스 기반 할당 방식 A, B, C, D, E 이렇게 다섯개의 클래스로 구분하는 할당 방식을 쓴다.

앞의 부분을 네트워크 주소, 그 뒤를 컴퓨터에 부여하는 호스트 주소로 사용한다.

• 클래스 A, B, C는 일대일 통신으로 사용
• 클래스 D는 멀티캐스트 통신
• 클래스 E는 미래에 사용하기 위한 예비용 클래스로 사용

클래스 A 처음 1바이트(8비트)가 네트워크 주소이며, 나머지 3바이트(24비트)는 호스트 주소이다. 맨 왼쪽에 있는 구분 비트는 0으로 시작하고 네트워크 할당은 0~127 이다.

클래스 B 처음 2바이트(16비트)가 네트워크 주소이며, 나머지 2바이트(16비트)는 호스트 주소이다. 맨 왼쪽에 있는 구분 비트는 10으로 시작하고, 네트워크 할당은 128~191 이다.

클래스 C 처음 3바이트(24비트)가 네트워크 주소이며, 나머지 1바이트(8비트)는 호스트 주소이다. 맨 왼쪽에 있는 구분 비트는 110으로 시작하고, 네트워크 할당은 192~223 이다.

클래스 구분 방법

간단하게 첫번째 Octet으로 구분할 수 있으며, 첫번째 Octet에서 0~255 까지의 숫자를 5개로 나눠서 구분하면 된다.

클래스 A 는 0~255 (총 256개의 절반 128) -> 0부터 시작이므로 127

• (0.0.0.0 ~ 127.255.255.255)

클래스 B 는 128~255 (총 128개의 절반 64) -> 0부터 시작이므로 191

• (128.0.0.0 ~ 191.255.255.255)

클래스 C 는 192~255 (총 64개의 절반 32) -> 0부터 시작이므로 223

• (192.0.0.0 ~ 233.255.255.255)

클래스 D 는 224~255 (총 32개의 절반 16) -> 0부터 시작이므로 239

• (234.0.0.0 ~ 239.255.255.255)

클래스 E 는 240~255 (총 16개) -> 0부터 시작이므로 127

• (240.0.0.0 ~ 255.255.255.255)

네트워크 주소

네트워크 구별 주소 (= 네트워크 주소) 네트워크 구별 주소는 가장 첫번째 주소이며, 네트워크 주소로 사용된다.

⇀ 클래스 A의 120.0.0.0 이라는 네트워크를 부여받은 경우, 120.0.0.0 이 네트워크 구별 주소이다.

호스트 주소 호스트 주소는 첫번째 주소와 마지막 주소를 제외한 나머지 주소를 말하며, 컴퓨터에 부여할 수 있는 주소이다.

⇀ 120.0.0.1 ~ 120.255.255.254 가 해당된다.

브로드캐스트 주소 브로드캐스트 주소는 가장 마지막 주소를 말하며, 네트워크에 속해 있는 모든 컴퓨터에 데이터를 보내는 주소이다.

⇀ 120.255.255.255 가 여기에 속한다.

클래스 기반 할당 방식은 사용하는 주소보다 버리는 주소가 많다는 단점이 있다.

그래서 DHCP, IPv6, NAT 이 나오게 된다.

DHCP

IP 주소 및 기타 통신 매개변수를 자동으로 할당하기 위한 네트워크 관리 프로토콜

이것을 통해 IP 주소를 수동으로 설정할 필요 없이 인터넷에 접속할 때마다 자동으로 IP 주소를 할당할 수 있다.

많은 라우터와 게이트웨이 장비에 DHCP 기능이 있고, 대부분의 가정용 네트워크에서 IP 주소를 할당한다.

NAT (Network Address Translation)

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

IPv4 주소 체계만으로는 수많은 주소들을 모두 감당하지 못한다. 그래서 NAT로 공인 IP 와 사설 IP로 나눠서 많은 주소를 처리한다.

NAT의 단점

• 여러 명이 동시에 인터넷에 접속하기 때문에 실제 접속 호스트 숫자에 따라 접속 속도가 느려질 수 있다.

네트워크 기기

네트워크 기기의 처리 범위

• 애플리케이션 계층 : L7 스위치
• 인터넷 계층 : 라우터, L3 스위치
• 데이터 링크 계층 : L2 스위치, 브릿지
• 물리 계층 : NIC, 리피터, AP

애플리케이션 계층을 처리하는 기기부터 보자.

애플리케이션 계층 처리 기기

L7 스위치

스위치 : 여러 장비를 연결하고 데이터 통신을 중재하며 목적지가 연결된 포트로만 전기 신호를 보내 데이터를 전송하는 통신 네트워크 장비

L7 스위치는 로드밸런서 라고도 한다. 서버의 부하를 분산하는 기기로, 클라이언트로부터 오는 요청들을 분산시켜 여러 서버로 보내는 역할을 한다.

목표 : 시스템이 처리할 수 있는 트래픽 증가

• URL, 서버, 캐시, 쿠키들을 기반으로 트래픽을 분산한다.
• 바이러스나 불필요한 외부 데이터 등을 걸러내는 필터링 기능도 한다.
• 응용 프로그램 수준의 트래픽 모니터링도 가능

장애가 발생한 서버가 있는 경우에는 트래픽 분산 대상에서 제외해야 하는데, 정기적인 헬스 체크 (Health Check)를 이용해 감시하면서 이뤄진다.

전송 계층 처리 기기

L4 스위치

로드밸런서의 특징인 트래픽 분산 등을 할 수 있습니다. 패킷의 IP주소와 Port번호를 참고해서 적절히 트래픽분산을 할 수 있다. 또한 전송계층의 TCP, UDP 등의 헤더를 기반으로 우선순위를 판단해서 분산이 가능합니다. L7스위치와 똑같이 헬스체크가 가능합니다.

L4 스위치와 L7 스위치의 차이 로드밸런서로는 위 2가지가 있는데, L4 스위치는 전송 계층을 처리하는 기기로 스트리밍 관련 서비스에서는 사용할 수 없다. 그리고 메시지 기반이 아닌 IP와 포트를 기반으로 (주로 포트 기반) 트래픽을 분산한다. L7 스위치는 IP, 포트 외 URL, HTTP, 헤더, 쿠키 등을 기반으로 트래픽을 분산한다.

처음에 말했던 것처럼 AWS와 같은 클라우드 서비스에서는 L7 스위치를 이용한 로드밸런싱은 ALB (Application Load Balancer) 컴포넌트

L4 스위치를 이용한 로드밸런싱은 NLB (Network Load Balancer) 컴포넌트

트래픽 분산이기 때문에 로드밸런서를 운용하기 위해서는 2대 이상의 서버가 필수적이다. 에러가 발생해 서버 1대가 다운돼도 서비스는 안정적으로 운용돼야 하기 때문이다.

인터넷 계층을 처리하는 기기

라우터

라우터는 여러 개의 네트워크를 연결, 분할, 구분하는 역할이다.

라우팅 : 하나 이상의 네트워크에서 경로를 선택하는 프로세스

다른 네트워크에 존재하는 장치끼리 서로 데이터를 주고 받을 때 패킷 소모를 최소화, 경로를 최적화 해서 최소 경로로 패킷을 Forwarding 하는 라우팅을 하는 장비이다.

L3 스위치

L2 스위치의 기능 + 라우팅 기능을 갖춘 장비를 말하는데, 데이터 링크 계층 기기를 설명할 때 L2 스위치 기능을 작성하겠다.

라우팅 테이블을 참조해서 IP 패킷에 IP 주소를 담아보낸다.

그래서 L3 스위치는 라우터라고 해도 무방하다.

라우터는 소프트웨어 기반의 라우팅하는 것과 하드웨어 기반의 라우팅하는 것으로 나눠진다면,

하드웨어 기반의 라우팅을 하는 것이 L3 스위치 담당이다.

TCP계층에서는 데이터 링크 계층 + 물리 계층 = 링크계층 이라고 했지만

네트워크 개념으로 다룰 때는 나눌 수 있다.

링크 계층

• 데이터 링크 계층은 이더넷 프레임을 통해 에러 확인, 흐름 제어, 접근 제어를 담당하는 계층을 말한다.
• 물리 계층은 무선 LAN과 유선 LAN을 통해 0과 1로 이루어진 데이터를 보내는 계층을 말한다.

데이터 링크 계층을 처리하는 기기

L2 스위치

장치들의 MAC 주소를 MAC 주소 테이블을 통해 관리하며, 인터넷계층에서 받은 패킷을 기반으로 이더넷프레임을 만들어 목적지 MAC주소로 패킷을 보내주는 역할

-> 즉, 연결된 장치로부터 패킷이 왔을 때 패킷 전송을 담당한다.

L3 스위치는 라우팅 테이블을 참조해서 IP 패킷에 IP 주소를 담아보낸다고 위에 작성했었다. L2 스위치는 Mac 주소 테이블을 참조해서 Mac 주소를 담당하여 이더넷

IP 주소는 이해 불가능하기 때문에 IP 주소 기반 라우팅은 불가능하다.

패킷의 MAC 주소를 읽어 스위칭하는 역할만 한다.

만약에 MAC 주소 테이블이 없다면 -> 전체 포트에 전달 후 MAC 주소 테이블의 주소는 일정 시간 이후 삭제하는 기능도 있다.

브릿지 (Bridge)

2개의 근거리 통신망인 LAN을 상호 접속할 수 있도록 하는 통신망 연결 장치로 통신망의 범위를 확장하고 서로다른 LAN을 기반으로 하나의 통신망을 구축할 때 쓰인다.

포트와 포트 사이의 다리 역할을 하고, 장치에서 받아온 MAC 주소를 MAC 주소 테이블로 관리한다.

물리 계층을 처리하는 기기

NIC

LAN 카드라고 하는 NIC (네트워크 인터페이스 카드) 는 2대 이상의 컴퓨터 네트워크를 구성하는 데 사용한다.

네트워크와 빠른 속도로 데이터를 송수신할 수 있도록 컴퓨터 내에 설치하는 확장 카드다.

각각 LAN 카드에는 주민등록번호와 같은 고유의 식별번호인 MAC 주소가 있다.

리피터 (repeater)

들어오는 약해진 신호 정도를 증폭해 다른 쪽으로 전달하는 장치를 말한다.

신호를 증폭하기에 패킷이 더 멀리 갈 수 있다.

광케이블이 보급되면서는 잘 쓰이지 않는 장치다.

AP (Access Point)

패킷을 복사하는 기기로 유선 LAN을 연결한 후 다른 장치에서 무선 LAN 기술 (와이파이) 을 사용해 무선 네트워크 연결을 할 수 있다.

인터텟 프로토콜 스위트 : 인터넷에서 컴퓨터들이 서로 정보를 주고받는 데 쓰이는 프로토콜의 집합이다.

TCP/IP 4계층 모델 or OSI 7계층 모델로 설명한다. TCP/IP 4계층을 보자.

2 - 5. 계층 구조

위와 같이 비교할 수 있다.

애플리케이션 계층부터 보자.

애플리케이션 계층

FTP, HTTP, SSH, SMTP, DNS 등 응용 프로그램이 사용되는 프로토콜 계층이다.

• FTP : 장치와 장치 간의 파일을 전송하는 데 사용되는 표준 통신 프로토콜
• HTTP : World Wide Web (www) 을 위한 데이터 통신의 기초이자 웹 사이트를 이용하는 데 쓰는 프로토콜
• SSH : 보안되지 않은 네트워크에서 안전하게 서비스 운영을 하기 위해 사용하는 암호화 네트워크 프로토콜
• SMTP : 이메일 전송과 같이 전자 메일 전송을 위한 인터넷 표준 통신 프로토콜
• DNS : 도메인 이름과 IP 주소를 매핑해주는 서버. IP 주소가 바뀌어도 도메인 주소로 서비스할 수 있다.

전송 계층

송신자와 수신자를 연결하는 통신 서비스를 제공한다. 연결 지향 데이터 스트림 지원, 신뢰성, 흐름 제어를 제공할 수 있다.

• 애플리케이션 계층과 인터넷 계층 사이의 데이터가 전달될 때 중계 역할을 한다.

TCP, UDP, QUIC 가 있다.

• TCP : 패킷 사이의 순서를 보장하고 연결 지향 프로토콜을 사용해 연결하기 때문에 신뢰성을 구축해 수신 여부를 확인할 수 있다. 가상회선 패킷 교환 방식을 사용한다.
• UDP : 순서를 보장하지 않고 수신 여부도 확인하지 않는다. 단순히 데이터만 주는 데이터그램 패킷 교환 방식을 사용한다.

가상회선 패킷 교환 방식과 데이터그램 패킷 교환 방식 을 알아보자.

가상회선 패킷 교환 방식

각 패킷에는 가상회선 식별자가 포함돼 모든 패킷을 전송하면 가상회선이 해제되고 패킷들은 전송된 순서대로 도착한다.

데이터그램 패킷 교환 방식

패킷이 독립적으로 이동해 최적의 경로를 선택해서 간다. 하나의 메시지에서 분할된 여러 패킷은 서로 다른 경로로 전송될 수 있어서 보낸 메시지의 순서가 다르게 도착할 수 있다.

TCP 연결 성립 과정

TCP는 신뢰성을 확보할 때 3-way handshake 라는 작업을 진행한다.

1. SYN 단계 : 클라이언트는 서버에 클라이언트의 ISN을 담아 보낸다.
   • ISN : 새로운 TCP 연결의 첫 번째 패킷에 할당된 임의의 시퀀스 번호
2. SYN + ACK 단계 : 서버는 클라이언트의 SYN을 수신하고 서버의 ISN을 보내며 승인번호로는 ISN + 1 값을 보낸다.
3. ACK 단계 : 그 승인번호를 클라이언트가 담아 ACK 서버에 보낸다.

• SYN : 연결 요청 플래그
• ACK : 응답 플래그
• ISN : 초기 네트워크 연결할 때 할당된 32비트 고유 시퀀스 번호

TCP는 3-way handshake 로 인해 신뢰성이 있는 계층으로 볼 수 있다.

TCP 연결 해제 과정

연결을 해제할 때는 4-way handshake 과정을 진행한다.

1. 클라이언트가 연결을 닫으려고 할 때 FIN 으로 설정된 세그먼트를 보낸다.

   • 클라이언트는 FIN_WAIT_1 상태로 들어가 서버의 응답을 기다린다.

2. 서버는 클라이언트로 ACK라는 승인 세그먼트를 보낸다.

   • 서버도 CLOSE_WAIT 상태로 들어간다.
   • 클라이언트가 세그먼트를 받으면 FIN_WAIT_2 상태로 들어간다.

3. 서버는 ACK를 보내고 일정 시간이 지난 뒤 클라이언트에 FIN이라는 세그먼트를 보낸다.

4. 클라이언트는 TIME_WAIT 상태가 되고 다시 서버로 ACK를 보내 서버는 CLOSED 상태가 된다. 이후 클라이언트는 어느 정도의 시간을 대기한 뒤 연결이 닫히고 모든 자원의 연결이 해제된다.

어느 정도의 시간을 대기한 뒤에 닫는 이유?

1. 지연 패킷이 발생할 경우를 대비하기 위해
   • 그냥 연결을 닫앗다가 패킷이 뒤늦게 도착해 처리하지 못하면 데이터 무결성 문제가 발생한다.
2. 두 장치가 연결이 닫혔는지 확인하기 위해
   • LAST_ACK 상태에서 닫히게 되면 다시 새로운 연결을 하려고 할 때 장치는 줄곧 LAST_ACK로 돼 있어 접속 오류가 생긴다.

데이터 무결성 : 데이터의 정확성과 일관성을 유지하고 보증하는 것

인터넷 계층

장치로부터 받은 네트워크 패킷을 IP 주소로 지정된 목적지로 전송하기 위해 사용하는 계층

IP, ARP, ICMP 등이 있고 패킷을 수신해야 할 상대의 주소를 지정해 데이터를 전달한다.

상대방이 제대로 수신했는지에 대해서는 보장하지 않는 비연결형이라는 특징을 가지고 있다.

링크 계층 (네트워크 접근 계층)

전선, 광섬유, 무선 등으로 실질적으로 데이터를 전달하며 장치 간 신호를 주고 받는 규칙을 정하는 계층

링크 계층을 물리 계층 / 데이터 링크 계층 으로 나누기도 한다.

• 물리 계층 : 무선 LAN 과 유선 LAN을 통해 0 과 1로 이루어진 데이터를 보내는 계층
• 데이터 링크 계층 : 이더넷 프레임을 통해 에러 확인, 흐름 제어, 접근 제어를 담당하는 계층

이더넷 프레임 : 데이터 링크 계층은 이더넷 프레임을 통해 데이터의 에러를 검출하고 캡슐화해 아래 구조를 갖는다.

• Preamble : 이더넷 프레임이 시작임을 알리는 것
• SFD : 다음 바이트부터 MAC 주소 필드가 시작됨을 알리는 것
• DMAC, SMAC : 수신, 송신 MAC 주소를 말하는 것
• EtherType : 데이터 계층 위의 계층인 IP 프로토콜을 정의한다.
  • IPv4 or IPv6
• Payload : 전달받은 데이터
• CRC : 에러 확인 비트

MAC 주소 : 컴퓨터, 노트북 등 각 장치에는 네트워크에 연결하기 위한 장치 (LAN 카드)가 있는데 구별하기 위한 식별번호를 말한다.

다음 게시글은 네트워크 계층 별 장치들에 대해서 알아볼 것이고, 유선 LAN 관련해서 알아보자.

유선 LAN

전이중화(full duplex) 통신 : 양쪽 장치가 동시에 송수신할 수 있는 방식

동축케이블, 광케이블 등을 기반으로 만들어진유선 LAN을 이루는 이더넷은 IEEE802.3 이라는 프로토콜을 따르며 전이중화 통신을 쓴다.

IEEE802.3 : 이더넷프레임은 어떤 구조를 기반으로 할 것인지, 케이블의 최대 전송량, 어떤 케이블만이 가능하도록 할 것인지 등을 정한 규칙

그럼 전이중화 통신에 대해서도 알아보자.

전이중화 통신

송신로, 수신로로 나눠서 데이터를 주고 받으며 현대의 고속 이더넷은 이 방식으로 통신한다.

반이중화 통신 중 CSMA/CD

반이중화 통신 : 양쪽 장치가 통신은 가능하지만, 동시에는 불가능해 한 번에 한 방향만 통신할 수 있는 방식을 말한다.

이전에는 유선 LAN에다가 반이중화 통신 중 하나인 CSMA/CD 방식을 사용했다.

CSMA/CD : 회선을 사용하는지를 파악한 후 사용하지 않는다면 데이터를 보내고 충돌이 발생한다면 일정 시간 이후 재전송하는 방식

이전에는 송신로, 수신로가 따로 있던 전이중화 방식이 아닌, 하나의 회선으로 주고 받았다.

그럼 양쪽에서 데이터를 보내게 되면 충돌이 발생할 것이고 그것을 예방하기 위해 사용하는 방식이 CSMA/CD 방식인 것이다.

케이블

트위스트페어케이블

• 쉴드 처리를 한 케이블 : STP
• 안 한 케이블 : UTP

이 UTP 케이블이 바로 LAN 선이다.

광섬유 케이블

레이저를 이용해 통신하며 보통 100Gbps의 데이터를 전송하는 케이블

빛의 굴절률이 높은 부분을 코어, 낮은 부분을 클래딩 이렇게 다른 밀도를 가지는 유리나 플라스틱 섬유를 기반으로 제작한다.

한 번 들어간 빛이 내부에서 계속해서 반사하며 전진하여 반대편 끝까지 가는 원리를 이용한 것이다.

무선 LAN

유선 LAN은 IEEE802.3 표준 규격을 따랐다면, 무선 LAN 은 IEEE802.11 표준규격을 따르며, 반이중화 통신을 따랐다.

반이중화 통신

반이중화 통신(half duplex) : 양쪽 장치는 서로 통신할 수 있지만, 동시에는 통신할 수 없으며 한 번에 한 방향만 통신할 수 있는 방식

CSMA/CA

CSMA/CD 와 다르다.

장치에서 데이터를 보내기 전에 일련의 과정을 기반으로 사전에 가능한 한 충돌을 방지하는 방식

1. 사용중인 채널이 있다면 다른 채널을 감지하다가 유후 상태인 채널을 발견한다.
2. 프레임 간 공간 시간인 IFS(InterFrame Space)시간만큼 기다린다.

• IFS는 프레임의 우선순위를 정의할 때도 사용된다.
• IFS가 낮으면 우선순위가 높다.

3. 프레임을 보내기전 $0$ ~ $2^k - 1$ 사이에서 결정된 랜덤상수를 기반으로 결정된 시간만큼 기다린 뒤 프레임을 보낸다. 프레임을 보낸 뒤 제대로 송신이 되었고 ACK 세그먼트를 받았다면 끝. 그러나 받지 못했다면, $k = k + 1$ 을 하며 이 과정을 반복 반복하다 $k$가 정해진 $Kmax$ 보다 더 커진다면 해당 프레임전송은 버린다. (abort)

대표 기술

Wifi

와이파이는 전자기기들이 무선 LAN 신호에 연결할 수 있게 하는 기술

근거리 무선망이라고 하면 틀린 개념이다. 근거리 무선망에 속하는 것

• 블루투스
• 지그비

주파수, 2.4GHz, 5GHz의 차이

간단하게 말하면 2.4GHz 는 장애물이 많은 곳에서 좋다. (속도는 조금 느리다.) 5GHz 는 뻥 뚫린 곳에서 좋다. (속도가 2.4GHz 보다 빠르기 때문에)

네트워크 : 컴퓨터 등 장치들이 통신 기술을 통해 구축하는 연결망을 지칭하는 용어

2. 네트워크의 기초

네트워크 : 노드 <-> 링크가 서로 연결돼 있거나, 연결돼 리소스를 공유하는 집합

• 노드 : 서버, 라우터, 스위치 등 네트워크 장치들
• 링크 : 유선 or 무선 연결 방식

2 - 1. 처리량, 지연 시간

좋은 네트워크의 개념

• 많은 처리량을 처리 가능
• 지연 시간이 짧음
• 장애 빈도 낮음
• 좋은 보안을 갖춤

처리량

처리량 링크 내에서 성공적으로 전달된 데이터의 양 얼마만큼의 트래픽을 처리했는지 나타낸다.

처리량의 단위 -> bps(bits per second) : 초당 전송 or 수신되는 bit 수

트래픽, 처리량 의미 차이

• 트래핑이 많아짐 => "흐르는 데이터가 많아졌다."
• 처리량이 많아짐 => "처리되는 트래픽이 많아졌다."

대역폭 : 주어진 시간 동안 네트워크 연결을 통해 흐를 수 있는 최대 bit 수

지연 시간

요청이 처리되는 시간을 의미한다.

지연 시간에 영향을 주는 것

• 매체 타입 (무선, 유선)
• 패킷 크기
• 라우터의 패킷 처리 시간

2 - 2. 네트워크 토폴로지, 병목 현상

네트워크 토폴로지 : 노드와 링크가 어떻게 배치돼 있는지에 대한 방식이자 연결 형태

트리 토폴로지

'계층형 토폴로지' 라고도 하며 트리 형태로 배치한 네트워크 구조

• 노드의 추가, 삭제가 쉽다
• 특정 노드에 트래픽이 집중될 때 하위 노드에 영향을 줄 수 있다.

버스 토폴로지

중앙 통신 회선 하나에 여러 개의 노드가 연결돼 공유하는 네트워크 구성 근거리 통신망 (LAN)에서 사용한다.

장점

• 설치 비용이 적다
• 신뢰성이 우수하다.
• 중앙 통신 회선에 노드 추가, 삭제가 쉽다.

단점

• 스푸핑이 가능한 문제점이 있다.

스푸핑 : LAN 상에서 송신부의 패킷을 송신과 관련 없는 다른 호스트에 가지 않도록 하는 스위칭 기능을 속이거나 마비시켜 특정 노드에 해당 패킷이 오도록 처리하는 것이다.

중앙 통신 회선 하나에 여러 개의 노드가 연결돼 있기 때문에 스위칭 기능을 속이게 되면 스푸핑이 가능해진다.

스타 토폴로지

중앙에 있는 노드에 모두 연결된 네트워크 구성

장점

• 노드를 추가하기 쉽다
• 에러를 탐지하기 쉽다
• 패킷의 충돌 가능성이 적다.
• 장애 노드가 중앙 노드가 아닌 경우 다른 노드에 영향을 끼치는 것이 적다.

단점

• 중앙 노드에 장애 발생 시 전체 네트워크를 사용할 수 없다.
• 설치 비용이 많이 나간다.

링형 토폴로지

각각의 노드가 양 옆의 1개씩 노드들과 연결돼 고리 (반지) 형태로 연속돼 통신하는 망 구성 방식

장점

• 노드의 개수가 증가해도 네트워크 상 손실이 거의 없다.
• 충돌이 발생될 가능성이 적다.
• 노드 고장 발견을 쉽게 찾을 수 있다.

단점

• 네트워크 구성 변경이 어렵다.
• 회선에 장애가 발생 시 전체 네트워크에 영향을 크게 끼칠 수 있다.

메시 토폴로지 (망형 토폴로지)

메시(mesh)는 그물망처럼 돼 있는걸 의미한다.

장점

• 하나의 장치에 장애가 발생해도 여러 개의 경로가 존재해 네트워크를 지속적으로 사용 가능하다.
• 추가로 트래픽 분산 처리도 가능하다.

단점

• 노드의 추가가 어렵다.
• 구축 비용, 운용 비용이 많이 든다.

병목 현상

병목 현상 : 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한을 받는 현상

예시로는 공간이 엄청 넓더라도 만약 출입문의 개수가 적거나 작다면 유동 유동의 흐름에 문제가 생길 수 있다. 서비스에서 이벤트를 열었을 때 트래픽이 많이 생기고, 트래픽을 잘 관리하지 못 하면 병목 현상이 생겨 사용자는 웹 사이트로 들어가지 못하게 된다.

위 병목 현상을 찾을 때 중요한 기준이 될 수 있기 때문에 토폴로지가 중요하다.

2 - 3. 네트워크 분류

1. LAN (Local Area Network) : 규모가 작아서 개인적으로 소유 가능한 규모
2. MAN (Metropolitan Area Network) : 서울시 와 같이 시 규모
3. WAN (Wide Area Network) : 세계 규모

• 규모가 커질 수록 전송 속도는 느려지고, 혼잡스러워진다.

2 - 4. 네트워크 성능 분석 명령어

애플리케이션 코드 상으로 문제가 없는데도 사용자가 서비스로부터 데이터를 못 가져올 때 네트워크 병목 현상일 가능성이 있다.

주된 원인으로는

• 네트워크 대역폭
• 네트워크 토폴로지
• 서버 CPU, 메모리 사용량
• 비효율적인 네트워크 구성

이런 원인들이 있으며 성능 분석을 위해 사용하는 명령어들을 알아보자.

ping

ping (Packet INternet Groper) : 네트워크 상태를 확인하려는 대상 노드를 향해 일정 크기의 패킷을 전송하는 명령어

• 해당 노드의 패킷 수신 상태
• 도달하기까지의 시간
• 네트워크가 잘 연결돼 있는지

위와 같은 데이터를 얻을 수 있다.

ping은 TCP/IP 프로토콜 중 ICMP 프로토콜을 통해 동작한다. 그래서 ICMP 프로토콜을 지원하지 않는 기기를 대상으로는 실행할 수 없거나 네트워크 정책 상 ICMP나 traceroute를 차단하는 경우 테스팅 불가능하다.

-n 12 옵션을 넣어 12번의 패킷을 보내고 12번 받는 것을 볼 수 있다.

명령 프롬프트에서 해볼 수 있다.

netstat

netstat : 접속돼 있는 서비스들의 네트워크 상태를 표시하는 데 사용되는 명령어

네트워크 접속, 라우팅 테이블, 네트워크 프로토콜 등 리스트를 보여준다.

주로 서비스의 포트가 열려 있는지 확인할 때 쓴다.

nslookup

nslookup : DNS에 관련된 내용을 확인하기 위해 쓰는 명령어

특정 도메인에 매핑된 IP를 확인하기 위해 사용한다.

tracert (윈도우), traceroute (리눅스)

tracert : 목적지 노드까지 네트워크 경로를 확인할 때 쓰는 명령어

목적지 노드까지 구간들 중 어느 구간에서 응답 시간이 느려지는지 등을 확인할 수 있다.

네트워크 프로토콜 표준화

네트워크 프로토콜 : 다른 장치들끼리 데이터를 주고받기 위해 설정된 공통된 인터페이스

IEEE 또는 IETF 라는 표준화 단체가 정한다.

IEEE802.3 : 유선 LAN 프로토콜로, 유선으로 LAN을 구축할 때 쓰이는 프로토콜이다. 기업이 다른 장치라도 서로 데이터를 수신할 수 있는 것이다.

예시로는 HTTP가 있는데, HTTP 라는 프로토콜을 통해 노드들은 웹 서비스를 기반으로 데이터를 주고 받을 수 있다.

프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론

간단하게 알아보면 프로그래밍 패러다임은 크게 선언형 / 명령형 2가지로 나눠지며 추가적으로는

• 선언형
  • 함수형
• 명령형
  • 객체지향형
  • 절차지향형

위와 같이 나눠진다.

선언형과 함수형 프로그래밍

선언형 프로그래밍 : '무엇을' 풀어내는가 <- 이것에 집중하는 패러다임

• "프로그램은 함수로 이루어진 것이다" 라는 명제가 담겨있다.

함수형 프로그래밍은 선언형 프로그래밍의 일종이다.

배열 속에서 최댓값을 찾기 위해서는 로직을 구성하는데

const ret = [1, 2, 3, 4, 5, 6, 7]
.reduce((max, num) => num > max ? num : max, 0)
console.log(ret) // 7

reduce()는 '배열'만 받아서 누적한 결과값을 반환하는 순수 함수로,

함수형 프로그래밍은 '순수 함수'들을 블록처럼 쌓아 로직을 구현하고 '고차 함수'를 통해 재사용성을 높인 프로그래밍 패러다임이다.

JavaScript는 함수가 일급 객체이기 때문에 -> 객체지향보다는 함수형 프로그래밍 방식이 선호된다.

순수 함수 : 출력이 입력에만 의존하는 것

고차 함수 : 함수가 함수를 값처럼 매개변수로 받아 로직을 생성할 수 있는 것 일급 객체의 특징 • 변수나 메서드에 함수를 할당할 수 있습니다. • 함수 안에 함수를 매개변수로 담을 수 있습니다. • 함수가 함수를 반환할 수 있습니다.

객체지향 프로그래밍

객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 방식

const ret = [1, 2, 3, 4, 5, 6, 7]
class List {
    constructor(list) {
        this.list = list
        this.mx = list.reduce((max, num) => num > max ? num : max, 0)
    }
    getMax() {
        return this.mx
    }
}
const a = new List(ret)
console.log(a.getMax()) // 7

List 라는 클래스를 만들어 a 라는 객체를 만들 때 최댓값을 추출하는 메서드의 예제이다.

객체지향 프로그래밍 특징

추상화, 캡슐화

상속성

다형성

오버로딩과 오버라이딩에 대해서는 각각 추상화, 캡슐화 / 상속성에 대해 정리할 때 적어뒀으니 참고하면 좋을 것 같다.

객체지향 프로그래밍 설계 원칙

• 단일 책임 원칙

  단일 책임 원칙(SRP, Single Responsibility Principle) :모든 클래스는 각각 하나의 책임만 가져야 하는 원칙

  예를 들어 A라는 로직이 존재한다면 어떠한 클래스는 A에 관한 클래스여야 하고 이를 수정한다고 했을 때도 A와 관련된 수정이어야 한다.

• 개방-폐쇄 원칙

  개방-폐쇄 원칙(OCP, Open Closed Principle)은 유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 하는 원칙

  즉, 기존의 코드 변경은 줄이고, 확장성은 있게끔

• 리스코프 치환 원칙

  리스코프 치환 원칙(LSP, Liskov Substitution Principle)은 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것

  클래스는 상속이 되기 마련이고 부모, 자식이라는 계층 관계가 만들어지는데, 이 때 부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가게 만드는 것이다.

• 인터페이스 분리 원칙

  인터페이스 분리 원칙(ISP, Interface Segregation Principle)은 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙

• 의존 역전 원칙

  의존 역전 원칙(DIP, Dependency Inversion Principle)은 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙

  ex) 타이어를 갈아끼울 수 있는 틀을 만들어 놓은 후 다양한 타이어를 교체할 수 있어야 한다. 즉, 상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립

절차형 프로그래밍

로직이 수행되어야 할 연속적인 계산 과정으로 이루어져 있다.

코드를 구현하기만 하면 되기 때문에 코드의 가독성이 좋으며 실행 속도가 빠른 편이다.

const ret = [1, 2, 3, 4, 5, 6, 7]
let a = 0
for (let i = 0; i < ret.length; i++) {
    a = Math.max(ret[i], a)
}
console.log(a) // 7

객체에 접근하기 전 그 접근에 대한 흐름을 가로채 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴

객체의 속성, 변환 등을 보완하며 보안, 데이터 검증, 캐싱, 로깅에 사용한다.

이 패턴은 프록시 객체, 프록시 서버로 활용된다.

프록시 서버에서의 캐싱 캐시 안에 정보를 담아두고, 캐시 안에 있는 정보를 요구하는 요청에 대해 서버에 요청하지 않고 캐시 안에 있는 데이터를 활용하는 것 -> 이는 곧 트래픽을 줄일 수 있다는 장점으로 이어진다.

프록시 서버

서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램

nginx

첫 번째 예시로는 nginx 가 있다. nginx : 비동기 이벤트 기반의 구조와 다수의 연결을 처리 가능한 웹 서버

주로 Node.js 서버의 앞단 프록시 서버로 활용된다. -> 버퍼 오버플로우 취약점 예방을 위해

익명 사용자의 직접적인 서버로의 접근을 차단하고 간접적으로 한 단계를 더 거침으로써 보안성을 더욱 강화할 수 있어서 사용한다.

• 프록시 서버를 nginx로 둬서 실제 포트를 숨기기
• 정적 자원을 gzip 압축하기
• 메인 서버 앞단에서의 로깅

위와 같은 방식들이 있다.

버퍼 오버플로우 : 버퍼는 보통 데이터가 저장되는 메모리 공간으로 이 공간을 벗어나는 경우를 뜻하는데 사용되지 않아야 할 영역에 데이터가 덮어씌워져 주소, 값을 바꾸는 공격이 발생하게 된다.

CloudFlare

전 세계적으로 분산된 서버가 있고 이를 통해 어떠한 시스템의 콘텐츠 전달을 빠르게 할 수 있는 CDN 서비스으로 추가적인 장점들도 있다.

CDN(Content Delivery Network) 각 사용자가 인터넷에 접속하는 곳과 가까운 곳에서 콘텐츠를 캐싱 또는 배포하는 서버 네트워크 사용자가 웹 서버로부터 콘텐츠를 다운로드하는 시간을 줄일 수 있다.

• HTTPS 구축
• DDOS 방어

사용자, 크롤러, 공격자가 웹 사이트에 접속하게 됐을 때 CloudFlare를 통해 공격자로부터 보호가 가능하다.

HTTPS 구축

서버에서 HTTPS를 구축할 때 인증서를 기반으로 구축 가능한데 CloudFlare를 사용하면 인증서 설치 없이 좀 더 쉽게 가능하다.

DDOS 공격 방어

DDOS : 짧은 기간 동안 네트워크에 많은 요청을 보내 네트워크를 마비시켜 웹 사이트의 가용성을 방해하는 사이버 공격 유형

CloudFlare는 의심스러운 트래픽, 특히 사용자가 접속하는 것이 아닌 시스템을 통해 오는 트래픽을 자동으로 차단해서 DDOS 공격으로부터 보호한다.

CORS - 프론트엔드의 프록시 서버

CORS(Cross-Origin Resource Sharing) : 서버가 웹 브라우저에서 리소스를 로드할 때 다른 오리진을 통해 로드하지 못하게 하는 HTTP 헤더 기반 메커니즘

• 오리진 : 프로토콜과 호스트 이름, 포트의 조합

프론트엔드의 오리진과 백엔드 서버의 오리진이 다르면 (거의 포트번호가 다른 경우로 받아들이면 된다.) CORS 에러가 발생한다.

이 때는 프론트엔드 서버 앞단에 프록시 서버를 둬서 문제를 해결할 수 있다.

요청이 들어왔을 때 해당 API 서버 통신을 매끄럽게 해주기 때문이다.

이터레이터 패턴

이터레이터(iterator)를 사용하여 컬렉션(collection)의 요소들에 접근하는 디자인 패턴

순회할 수 있는 여러 가지 자료형의 구조와 상관없이 (= 다른 객체여도) 이터레이터라는 하나의 인터페이스로 순회가 가능하다.

const map = new Map()
map.set('a', 1)
map.set('b', 2)
map.set('c', 3)

const set = new Set()
set.add(1)
set.add(2)
set.add(3)

for (let a of map) console.log(a)
for (let a of set) console.log(a)

/*
[ 'a', 1 ]
[ 'b', 2 ]
[ 'c', 3 ]
1
2
3
*/

다른 자료 구조인 set과 map임에도 똑같은 for a of b라는 이터레이터 프로토콜을 통해 순회한다.

이터레이터 프로토콜 : iterable 한 객체들을 순회할 때 쓰이는 규칙

itreable 한 객체 : 반복 가능한 객체로, 배열을 일반화한 객체를 뜻한다.

노출모듈 패턴

즉시 실행 함수를 통해 private, public 같은 접근 제어자를 만드는 패턴

JavaScript는 private나 public 같은 접근 제어자가 존재하지 않고 전역 범위에서 스크립트가 실행된다.

그래서 노출모듈 패턴을 통해 private와 public 접근 제어자를 구현하기도 한다.

const revealing = (() => {
    const a = 1
    const b = () => 2
    const public = {
        c : 2, 
        d : () => 3
    }
    return public
})()
console.log(revealing)
console.log(revealing.a)
// { c: 2, d: [Function: d] }
// undefined

a와 b는 다른 모듈에서 사용할 수 있는 변수나 함수인 private 범위여서 다른 모듈에서 접근할 수 없다.

c와 d는 다른 모듈에서 사용할 수 있는 변수나 함수인 public 범위여서 접근 가능하다.

즉시 실행 함수 : 함수를 정의하자마자 바로 호출하는 함수. 초기화 코드, 라이브러리 내 전역 변수의 충돌 방지 등에 사용한다.

MVC 패턴

Spring MVC 패턴의 요청 처리 과정

이전에 MVC 패턴에 배우면서 간단하게 처리 과정에 대해서 정리한 적이 있어 그 글도 함께 보면 좋을 것 같다.

MVC 패턴 : 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴

애플리케이션의 구성 요소를 세 가지 역할로 구분해 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있다.

• 재사용성과 확장성이 용이하다는 장점
• 애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점

용어

1. Model : 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻한다.

사각형 모양의 박스 안에 글자가 들어 있다면 그 사각형 모양의 박스 위치 정보, 글자 내용, 글자 위치, 글자 포맷(utf-8 등)에 관한 정보를 다 가지고 있어야 한다.

View 에서 데이터를 생성 or 수정하면 Controller 를 통해 Model을 생성하거나 갱신한다.

2. View : inputbox, checkbox, textarea 등 사용자 인터페이스 요소로 Model을 기반으로 사용자가 볼 수 있는 화면을 뜻한다.

화면에 표시하는 정보만 가지고 있어야 하고, 변경이 생기면 Controller에 전달해줘야 한다.

3. Controller : 하나 이상의 Model과 View를 잇는 다리 역할. 이벤트와 같은 메인 로직을 담당한다.

Model과 View의 생명주기 관리도 하고 변경이 되는 경우에 각각의 구성 요소에 해석한 내용을 알려준다.

MVP 패턴

MVC 패턴으로부터 파생된 패턴으로, Controller -> Presenter로 교체된 패턴이다.

View 와 Presenter는 1:1 관계로 MVC 패턴보다 더 강한 결합을 지닌 디자인 패턴이다.

MVVM 패턴

MVC의 C에 해당하는 컨트롤러가 뷰모델(view model)로 바뀐 패턴

View Model은 View를 더 추상화한 계층이며 이 패턴은 커맨드와 데이터 바인딩을 가지는 것이 특징이다.

뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있고 단위 테스팅하기 쉽다는 장점이 있다.

예시로는 Vue.js가 있다.

커맨드 : 여러 가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법이다.

데이터 바인딩 : 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법으로, 뷰모델을 변경하면 뷰가 변경된다.

Vue.js

Vue.js는 반응형이 특징인 프런트엔드 프레임워크로, watch와 computed 등으로 쉽게 반응형적인 값들을 구축할 수 있다.

함수를 사용하지 않고 값 대입만으로도 변수가 변경되며 양방향 바인딩, html을 토대로 컴포넌트를 구축할 수 있다는 점이 특징이다.

재사용 가능한 컴포넌트도 정의할 수 있다. 이것을 기반으로 UI를 구축할 수 있다.