네트워크 인프라 (4) 서버 이해를 위한 최소한의 기반 지식

 

 

1. Series / Parallel

 

1-1. 직렬 / 병렬이란

 

병렬 처리는 "다수의 사람이 동시에 다수의 일을 하는 것"과 동일한 의미이다.

대규모 웹 서비스의 경우 방대한 사용자 요청이 밀려오기 때문에 병렬화가 필수적이다.

그러나 모든 부분에서 병렬 처리가 가능한 것은 아니며, 결국 직렬 처리가 필요한 부분이 있는데 이런 부분에서 병목 현상이 생긴다.

이런 직렬화가 필요한 구간은 CPU의 코어 개수가 늘어나도 의미가 없으며, 클럭 주파수 자체를 높이는 수 밖에 없다.

 

즉, 병렬화라는 동시에 여러가지 작업을 수행하는 것으로 처리 속도가 빨라지는 것은 아니지만 단위 시간당 처리량을 늘릴 수 있다.

또한 병렬 처리에서는 합류점, 직렬화 구간, 분기점이 병목 지점이 될 수 있다.

병렬화할 때는 일을 분담해서 처리한 후 다시 집약할 때 오버헤드가 걸린다, 따라서 오버헤드를 감안하더라도 효과가 있을 경우에 병렬화를 한다.

(실제 프로그래밍에서도 "사람 기준에는" 복잡한 재귀연산조차 병렬 처리가 오히려 더 오랜 시간이 걸린다.)

 

 

1-2. 네트워크 인프라에서의 사용

 

(1) 웹 서버

: httpd라는 프로세스가 복수로 존재하며 요청을 병렬 처리한다.

기본적으로 멀티프로세스인 것은 동일하나 멀티쓰레드까지 사용하는 경우도 있다.

(2) AP 서버

: (자바의 경우) JVM이 하나의 프로세스에서 복수의 스레드를 이용해 병렬 처리한다.

(3) DB 서버

: 클라이언트를 요청하는 서버 프로세스, Storage나 Disk에서 쓰기 처리하는 프로세스를 병렬로 I/O한다.

 

 

1-3. 장단점

 

(1) 직렬 

- 구조가 간단하여 설계나 구현 난이도가 낮다.

- 복수 리소스를 효율적으로 이용할 수 없다.

 

(2) 병렬

- 복수 리소스를 유용하게 이용할 수 있으며 직렬에 비해 동일 시간당 처리할 수 있는 데이터 양이 증가한다.

- 이중화하여 일부 코어에 장애가 발생해도 나머지 코어로 작업을 계속할 수 있다.

- 처리 분기 및 합류를 위한 오버헤드가 발생한다, 배타적 제어 등을 고려해야 하고 구조가 복잡해서 설계나 구현 난이도가 높다.

- 병렬화가 유효한 부분을 파악해서 병렬화하지 않으면 의미가 없다. 오버헤드나 구조 복잡화 등의 단점을 고려하여 이를 넘어서는 이점을 취할 수 있을 경우에만 병렬처리한다.

 

 

 

 

 

 

 

 

2. Synchronous / Async

 

 

2-1. 동기 / 비동기

 

(1) 동기 : 요청이 완벽하게 끝났는지 확인해야 이후 작업이 실행된다.

(2) 비동기 : 요청 후 다른 작업을 수행할 수 있으나 수행 여부 확인을 위해 별도 작업이 필요하다.

 

2-2. 네트워크 인프라에서의 사용

 

(1) AJAX를 통한 비동기 통신

: 키보드 입력 도중 자동완성 등

 

(2) DBMS

: DBMS는 프로세스, 스레드를 복수 사용하여 병렬 동기로 작동하는 방식과 병렬 비동기 방식이 있다.

비동기 방식의 경우 SQL 쓰기 의뢰 후 처리를 확인하지 않고 계속해서 다음 작업을 진행한다.

단, I/O가 별도로 SQL 처리가 끝난 것을 확인한다.

 

2-3. 장단점

 

(1) 동기

- 요청 완료 여부를 쉽게 확인할 수 있어 구조가 간단하고 구현 난이도가 낮다.

- 요청 처리가 끝나는 시점까지 기다려야해서 대기 시간을 활용할 수 없다.

 

(2) 비동기

- 요청에 대한 처리가 진행되고 있는 동안 시간을 효율적으로 사용해서 병렬처리가 가능하다.

- 요청에 대한 처리를 확인하는 과정이 추가되며 구조가 복잡하여 구현 난이도가 상대적으로 높다.

- 요청이 끝나지 않은 상태에서 다음 처리를 진행해도 문제가 없는지, 요청 처리를 확인해야하는지 등 고려해야할 부분이 많아진다.

 

 

 

 

 

3. Queue

 

 

3-1. 큐란 ?

 

선입선출(First In First Out, FIFO) 형태의 자료구조로 대기열이 필요할 때 주로 사용한다.

하드웨어 운영체제 DB 어플리케이션 등 대기열이 필요한 곳에는 두루두루 사용되며 성능 튜닝시 중요한 역할을 담당한다.

 

3-2. 네트워크 인프라에서의 사용처?

 

(1) CPU 처리를 기다리는 프로세스와 스레드의 대기열

(2) Disk, Storage 등 I/O처리 대기열 (단, DBWR LGWR의 대기열은 따로 존재한다.)

(3) 네트워크 요청 대기열

 

3-3. 특성

 

(1) 선두부터 순서대로 처리된다.

(2) 여러 처리가 동시에 진행되는 경우 순서 유지를 위해 자주 사용된다.

(3) 성능 문제 발생 시 행렬 길이를 정보로 사용할 수 있다.

(4) 비동기 작업 시 작업을 요청할 대기열이 밀렸어도 큐에 예약하고 하던 작업을 계속할 수 있다.

 

 

 

 

 

4. 배타적 제어

 

 

4-1. 배타적 제어란?

 

자원 사용 시 다른 스레드/프로세스의 침범을 배제하는 것으로 병렬 처리 시 데이터 정합성을 위해 배타적 제어를 사용한다.

 

4-2. 네트워크 인프라에서의 사용처?

 

(1)DBMS

: 기본적으로는 여러 프로세스가 병렬로 작업을 처리하나 특정 프로세스가 공유 데이터를 변경하는 중에는 다른 프로세스가 해당 데이터를 읽거나 쓸 수 없도록 제어한다.

이 경우에는 매우 짧은 시간만 락을 유지하는 latch가 있어서 cpu는 spin lock 상태로 대기한다.

물론 작업에 따라 sleep lock, adaptive lock 방식도 사용할 수 있다.

대개 대기 시간이 길지 않기 때문에 cpu가 계속해서 락을 체크하는 busy-waiting 방식을 주로 사용한다.

 

(2) 리눅스 커널

: 뮤텍스의 경우에는 병렬 처리를 직렬화하여 동시에 하나의 cpu만 커널 코드를 실행할 수 있다.

 

4-3. 배타적 제어 사용 여부에 따른 차이

 

(1) 사용 시

: 공유 데이터의 일관성을 유지할 수 있다.

병렬 처리가 불가하여 해당 부분에서 병목 현상이 발생한다.

필요 이상으로 배타적 제어시 코어가 여러개 있어도 아무 의미 없는 상태가 될 수 있다.

 

(2) 미사용 시

: 더 빠르게 처리할 수 있다.

데이터 정합성이 망가질 수 있다.

 

 

 

 

 

 

5. Stateful / Stateless

 

 

 

 

5-1. 상태 저장/ 상태 비저장

 

(1) 상태 저장 :

세분화된 제어가 가능하나 구조가 복잡하다. (예 : SSH )

이전 정보를 가져와 복잡한 처리가 가능하다.

시스템 복잡성이 커지며 그에 따른 예외 처리가 필요하다.

 

(2) 상태 비저장

: 고기능은 아니나 단순하다. (예 : HTTP)

과거 정보를 가져올 수 없어 복잡한 처리가 어렵다.

성능과 안정성에 유리하다.

 

5-2. 네트워크 인프라에서의 사용처?

 

(1) 컴퓨터(서버) 내부는 거의 모든 부분에서 상태 저장 방식으로 작동한다.

CPU 또한 코어마다 일정 간격으로 저장-대기를 반복한다.

 

(2) HTTP 통신은 대표적인 Stateless 방식이지만 세션을 통해 상태를 일부 저장할 수 있다.

 

5-3. 결론

 

네트워크는 다수의 사용자가 요청을 전송하기 때문에 리소스 부하를 적게 일으키는 무상태 방식이 적절하다.

 

 

 

 

 

 

6. Variable Length/ Fixed Length

 

 

 

6-1. 가변 길이/ 고정 길이

 

(1) 고정 길이형

: 컴퓨터 내부의 저장장치는 고정 길이의 저장 공간이 모여 있는 형태로, 고정 길이는 틀이 정해져있어서 남는 공간과 관계 없이 무조건 일정 용량을 사용하는 것을 의미한다. 용량을 비효율적으로 사용하나 규칙적으로 정리되어 액세스가 빠르다.

(2) 가변 길이형

:공간을 필요한 만큼만 사용할 수 있으나 데이터가 일정하지 않고 따로 떨어져 있어서 액세스하기 힘들어 성능면에서 불안정하다.

 

6-2. 네트워크 인프라에서의 사용처?

 

이더넷의 MTU(패킷 최대 크기)가 1500바이트이며 TCP/IP헤더가 40바이트이기 때문에 MSS(최대 TCP 세그먼트 사이즈)는 1460바이트이다.

따라서 Tcp/IP 데이터 전송 시 1460바이트의 세그먼트로 분할되며, 남은 크기는 따로 전송된다.

 

 

 

 

 

 

7. Array/ Linked List

 

 

 

7-1. 배열과 연결 리스트

 

(1) 배열은 데이터를 빈틈 없이 순서대로 나열한 구조로 위치가 정해져 있기 때문에 탐색이 빠르다.

(2) 연결리스트는 데이터를 각 노드로 연결한 것으로 탐색이 느리지만 데이터 추가 삭제가 빠르다.

 

7-2. 네트워크 인프라에서의 사용처

 

(1) DB 서버에서 SQL을 캐싱할 때 사용하는 해시테이블 구조에서 Key는 Array, Value는 Linked List가 사용된다.

(2) 이외 큐, 스택 등의 구현에도 사용

 

 

 

 

 

8. Hash/ Tree

 

 

 

 

8-1. 해시/ 트리

 

필요한 데이터를 빠르게 찾기 위해 미리 데이터를 정리해두는 알고리즘이다.

 

8-2. 네트워크 인프라에서의 사용처

 

(1) 인덱스

: 인덱스가 없는 경우 디스크 테이블의 모든 블록을 스캔한다.

인덱스가 있는 경우 B트리 인덱스를 활용하여 필요한 데이터 블록만 찾아서 스캔한다.

단, 테이블의 데이터를 모두 취득해야하는 경우 테이블 블록 뿐 아니라 인덱스 블록까지 스캔해야해서 오히려 디스크I/O가 증가한다.

인덱스를 사용하지 않는 스캔의 경우 1회 I/O로 가능한 큰 크기의 데이터를 읽으나 인덱스의 경우 각 인덱스 블록을 읽으며 테이블을 하나씩 읽기 때문에 액세스 블록 수가 늘어남과 동시에 I/O횟수도 늘어나서 더 느려질 수 있다.

 

(2) B트리

: 트리구조 계층이 깊어지지 않도록하여 Disk I/O를 최소화한다.

단, 인메모리 DB의 경우 T트리 인덱스를 활용한다.

 

(3) 해시

: 단순 Key 검색은 해시가 압도적으로 빠르나 범위 검색에 약하다.

일부 DBMS에서는 해시를 인덱스로 사용하며, 이외에 캐시에 사용한다.

 

 

 

 

 

9. Cache

 

 

9-1. 캐시

 

사용 빈도가 높은 데이터를 고속 액세스할 수 있는 위치에 보관하는 것이다.

Cpu의 L1, L2, L3 cache, mmu cache, buffer cache등 다야안 곳에 활용된다.

데이터 재사용 시 효율을 증가시키는 것이 목적이다.

 

9-2. 네트워크 인프라에서의 사용처

 

(1) 브라우저

: 캐시를 통해 접속했던 페이지의 서버에 대한 요청을 줄이고 고속화한다.

 

(2) CDN

: 웹 서버와 클라이언트 사이에 캐시 서버를 둔다.

(물리적으로 가까운 위치에 캐시 서버를 두어 접속 속도를 빠르게 함.)

 

9-3. 결론

 

(1) 캐시에 적합한 대상

- 참조 빈도가 높은 데이터.

- 해당 데이터가 손실되어도 문제가 없어야 한다.

 

(2) 부적합한 대상

- 데이터 갱신 빈도가 높을 경우 매번 새로 캐싱하기 때문에 캐시에 저장하는 이유가 없다.

일부 DB의 경우 캐시 갱신 후 바로 반환하기 때문에 자주 변경되는 경우에도 의미는 있으나, 안정성을 위해 여러 처리가 있기 때문에 일반적인 캐시보다는 비효율적이다.

- 고용량의 데이터 액세스 시에는 캐시 크기가 커지며 캐시 배치 시간이 오래 걸리기 때문에 효율이 저하된다.

 

(3) 기타

- 데이터가 실제 데이터와 캐시라는 이중 구조로 저장되는 과정에 리소스 소비량이 증가한다. 따라서 의미 없는 데이터를 캐시하는 것은 오히려 성능 저하만 불러올 뿐이다.

- 시스템 가동 직후에는 캐시에 데이터가 없기 때문에 초기에는 리소스 소비량만 증가한다.

- 캐시 계층이 늘어나기 때문에 성능 문제나 데이터 불일치 문제가 발생할 수 있다.

- 캐시 데이터는 언제든 손실될 수 있기 때문에 복구 순서를 설계 시 확립해야 한다.

- 갱신 데이터를 캐시할 때 캐시가 여러 개 있으면 갱신된 데이터를 서로 가져가려는 경쟁 상태가 발생하지 않도록 설계해야 한다.

 

 

 

 

 

 

 

10. Interrupt

 

 

 

10-1. 끼어들기

 

CPU에 급한 일을 먼저 하도록 알리는 역할.

키보드를 입력하거나 하는 동작도 모두 Interrupt에 속한다.

어떤 일이 발생하면 CPU에게 안내하는 이벤트 주도 구조.

 

10-2. 네트워크 인프라에서의 사용처

 

(1) 이더넷 프레임(요청)이 도착하면 Interrupt에 의해 CPU에 통지되고 처리한다.

(2) CPU가 실행 중이던 프로세스 정보는 메모리로 옮겨지고 전송된 데이터가 Kernel모드로 처리된다.

 

10-3. Polling

 

소프트웨어적인 방법으로 CPU가 정기적으로 외부 입력을 확이낳는 방법이 있으나, 폴링 간격이 길어지면 I/O를 금방 확인할 수 없고 간격이 너무 짧아지면 CPU가 낭비된다.

대부분의 경우에서는 Polling보다는 하드웨어적 해결책인 Interrupt를 택한다.

 

 

 

 

 

11. Polling

 

 

11-1. 폴링

 

정기적으로 요청을 확인하는 것으로, 일정 간격을 따라 정기적으로 발생한다.

단순히 반복 확인만 하면 되기 때문에 구현이 쉽고, 요청 시까지 일괄적으로 처리할 수 있는 것이 장점이다.

 

11-2. 네트워크 인프라에서의 사용처

 

NTP(Network Time Protocol)에서 서버에 정기적으로 시간을 요청하며 반환 받아 시간이 다르면 시스템의 시간을 조절한다.

 

11-3. 기타

 

- 적합한 상황

(1) 전처리와 후처리가 연계되지 않는 상황

: 수신자가 메일을 제 때 확인하지 않아도 송신자는 아무 상관이 없다. (시스템상으로 말이다.)

 

(2) 시스템 컴포넌트가 자발적으로 상태를 전달할 수 없는 경우

: 컴포넌트가 자발적으로 Controller에 Interrupt를 요청할 수 없는 경우 Polling 방식으로 체크해야 한다.

 

- 부적합한 상황

(1) 전처리와 후처리가 연계되는 상황

: 키보드 입력 시 매번 입력 상황에 따라 결과가 반환되어야하기 때문에 폴링은 적합하지 않다.

 

(2) 우선순위가 필요한 처리

: Interrupt는 OS가 자체적으로 우선순위를 정해주지만 Polling은 단순히 선착순으로 처리하기 때문에 부적합하다.

 

(3) 짧은 간격의 네트워크 처리

: 네트워크 경유하는 폴링의 간격이 너무 짧을 경우 트래픽과 서버 리소스 소비량이 증가한다.

 

 

 

 

 

12. I/O Buffer

 

 

 

 

12-1. I/O 크기를 고려해야하는 이유

 

1회 I/O에 필요한 크기를 너무 크거나 작게 잡는다면 트래픽이 증가한다.

 

12-2. 네트워크 인프라에서의 사용처

 

(1) DBMS

: I/O의 크기와 DB의 처리 단위(Block)을 배수로 설정해주어야 효율적인 처리가 가능하다.

만약 DB의 처리 단위가 8kb인데 I/O는 5kb라면? 16kb를 읽기 위해 20kb를 읽어와야 한다.

 

(2) TCP/ IP

: 클라이언트 - 서버, 혹은 서버 - 서버간의 패킷 교환 시 MTU(최대 패킷 크기)가 같다면 문제 없으나, 경로 도중 만나는 라우터의 MTU가 작다면 송신 중 더 분할하여 오버헤드가 발생한다.

만약 MTU를 튜닝하거나 소켓 버퍼를 크게 만들고 싶을 경우 모든 통로를 균일하게 유지해야 한다.

 

 

 

 

 

 

 

13. Journaling

 

 

13-1. 저널링

 

트랜잭션 혹은 갱신되는 데이터의 변경 이력을 남겨 시스템 장애 발생 시 처리를 돕는다.

데이터 자체가 아닌 트랜잭션 내용을 기록하는 것으로, 데이터의 정합성이 확인된 이후에는 필요가 없으며 트랜잭션 Rollback, Rollfoward에 사용된다.

데이터 복제에 비해 적은 리소스로 데이터를 보호할 수 있다.

 

13-2. 네트워크 인프라에서의 사용처

 

- RDBMS (DB는 각 시스템마다 작동에 차이가 있다.)

(1) SQL을 해석하고 처리한다.

(2) 변경한 블록을 데이터 파일에서 읽어서 버퍼 캐시를 갱신한다.

(3) 변경 내용을 로그 버퍼에 기록한다.

(4) 커밋 실행 시점에 버퍼를 로그 파일에 기록하고 기록이 끝났음을 프로세스에 통지한다.

(5) 로그를 덮어쓰고, 변경된 데이터는 캐시가 가득 차면 출력된다. (디스크에 기록된다는 의미이다.)

 

13-3. 기타

 

(1) 적합한 경우

: 데이터 갱신이 발생하는 모든 시스템.

 

(2) 부적합한 경우

: 데이터 안정성보다 성능이 중요한 경우, 저널링으로 인한 오버헤드가 발생하여 적합하지 않을 수 있다.

데이터 변경 시 저널과 실제 데이터 두 곳에서 I/O가 발생하기 때문.

 

(3) 주의점

: 저널 데이터는 메모리 버퍼에 저장되는데, 이 정보가 디스크에 기록되지 않으면 장애 시 기록을 잃을 수 있다.

다만 저널 저장 빈도수가 늘어나면 성능은 저하된다.

트랜잭션 단위로 정합성을 보장하기 때문에 트랜잭션 도중 장애가 발생하면 종료되지 않은 트랜잭션은 파괴된다.

따라서 트랜잭션이 길어질수록 서비스 장애가 일어날 확률이 높아진다.

 

(4) 대안 : 그림자 페이징(Shadow Paging)

: 변경 정보를 실시간으로 작성하는 것이 아니라 파일 갱신을 별도의 페이징 영역에서 하다가 모두 완료되면 데이터베이스에 즉시 반영한다. 반드시 모든 과정이 반영되거나, 아예 반영되지 않거나 둘 중 하나이기 때문에 더욱 안정적이며 별도의 로그 처리가 없어 부하가 낮다.

그러나 페이지 테이블에 대한 추가적인 관리가 필요하고 별도의 높은 용량을 필요로한다.

 

 

 

 

 

 

 

 

14. Replication

 

 

 

 

14-1. 복제?

 

말 그대로 데이터를 복사하는 것으장애 시 데이터 손실을 예방할 수 있으며, 복제를 이용한 부하 분산이 가능하다.

또한 복제 데이터를 캐시처럼 사용할 수 있다.

 

14-2. 네트워크 인프라에서의 사용처

 

MYSQL의 경우

(1) 데이터 변경 SQL을 바이너리 로그에 기록

(2) 마스터 DB(메인)의 IO 쓰레드가 바이너리 로그를 취득하여 릴레이 로그로 저장

(3) SQL 쓰레드가 릴레이 로그를 참조하여 DB에 SQL을 반영

(4) 복사 DB는 일부 지연이 있을 수 있으나 읽기 전용으로 액세스할 수 있으며, 메인 DB는 읽기/쓰기 모두 가능하다.

 

실제 데이터 블록을 전송하지 않고 명령만 복제 DB에 전송하여 전송량을 줄일 수 있으며, 전송량은 트랜잭션 수와 비례한다.

 

14-2. 기타

 

(1) 적합한 경우

: 데이터 손실을 허용하지 않고 장애 시 복구 속도가 빨라야하는 시스템

데이터 참조/ 갱신 부분이 나뉘어져 있으며 참조가 많은 시스템(읽기 요청이 많은 시스템)

 

(2) 부적합한 경우

: 데이터 갱신이 자주 일어나는 경우 복제 대상 데이터가 많아져 오버헤드가 발생한다.

 

(3) 고려할 부분

: 실제 데이터와 복제 데이터를 완전히 일치시키고 싶은 경우 복제 데이터 쓰기 완료 처리를 보장해야하며, 응답 성능이 악화된다.

시스템 유지관리 및 장애 시 설계 및 운영 난이도가 높아진다.

복제 데이터와 실제 데이터 차이가 커지면 차이를 메꾸기 위해 많은 리소스가 필요할 수 있다.

 

 

 

 

 

 

15. Master Database

 

 

 

15-1. 마스터 데이터베이스

 

데이터의 쓰기 권한을 한 쪽에서 모두 소유하고 있으면 마스터 데이터베이스 - 슬레이브 데이터베이스 관계라고 한다.

반대로 동등한 관계를 가지고 있는 경우 Peer To Peer 관계라고 부른다.

 

15-2. 네트워크 인프라에서의 사용처

 

Oracle DB의 경우 여러 물리 서버가 클러스터 구성으로 연결되어있고 모두 대등한 권한을 가지고 있어서 특정 서버가 다운되어도 다른 서버가 역할을 대신할 수 있다.

 

15-3. 장단점

 

(1) 장점

: 관리자가 하나라서 구현이 쉽다.

DB간 처리를 동기화할 필요 없어 처리량이 줄어든다.

 

(2) 단점

: 마스터가 없어지면 관리가 불가능하다.

마스터 DB의 부하가 높아진다.

 

 

 

 

 

 

 

16. Compression

 

 

 

16-1. 압축?

 

파일 내부에서 중복되는 패턴을 인식해서 해당 패턴을 모두 모아서 하나로 줄이는 것이 압축이다.

압축 자체도 리소스가 필요하며 부하가 발생하나 네트워크 경유 데이터 전송 등 I/O 속도가 느린 경우 압촉해서 전송하는 것이 처리 시간에 유리하다.

압축은 가역 압축과 비가역 압축으로 분류되며, 원래 상태로 복구할 수 있는 것을 가역 압축, 원래 상태로 복구할 수 없지만 더 많이 압축할 수 있는 것을 비가역 압축이라고 한다.

음성이나 이미지 파일은 일부 패턴이 사라져도 인간은 알아차릴 수 없기 때문에 최소한의 필요한 정보만 남기고 비가역 압축할 수 있다. 

 

16-2. 네트워크 인프라에서의 사용?

 

(1) Java의 경우 jar 파일로 압축되어 있으며 서버에서 애플리케이션 기동 시 클래스 파일을 클래스 로더가 로드한다.

(2) DB의 경우 deduplication 방식으로 압축한다(중복 내용 제거) 블록의 해시값을 계산해서 이미 기록된 해시값과 같은 데이터는 저장하지 않는 방식이다.

 

 

 

 

 

 

17. Error Detection

 

 

 

 

17-1. 오류 검출

 

통신 중 데이터 파손, 칩의 데이터 파손, 메모리의 데이터 파손, 외부의 악의적인 접근으로 인한 데이터 파손 등을 검출하는 방법.

패리티 비트, CRC, 체크섬 등이 있다.

 

(https://7357.tistory.com/208?category=1077221)

 

17-2. 네트워크 인프라에서의 사용?

 

(1) 서버용 메모리는 개인용 메모리와 달리 ECC 메모리가 존재하여 쓰기 과정에서 패리티 비트를 계산하여 읽을 때 오류 검출 및 수정이 가능하다.

 

(2) Tcp/Ip통신 시 체크섬 및 CRC 오류를 검출하여 패킷의 오류를 감지하고 재전송을 요청한다.

(Tcp/Ip - 체크섬, 이더넷헤더 - CRC)