인덱스

인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조로, 내부 데이터 구조는 트리 구조로 되어 있다.

책의 저자들은 책의 맨 앞 또는 맨 뒤에 색인을 추가하는데, 이는 마치 데이터베이스의 index와 같다

데이터베이스에서도 테이블의 모든 데이터를 검색하면 시간이 오래 걸리기 때문에 데이터와 데이터의 위치를 포함한 자료구조를 생성하여 빠르게 조회할 수 있도록 돕고 있다

인덱스를 활용하면, 데이터를 조회하는 SELECT 외에도 UPDATE나 DELETE의 성능이 함께 향상된다

이유는 해당 연산을 수행하려면 해당 대상을 조회해야만 작업을 할 수 있기 때문이다

UPDATE USER SET NAME='SUBIN' where NAME='KIM';

만약 index를 사용하지 않은 컬럼을 조회해야 하는 상황이라면,

전체를 탐색하는 Full Scan(전체를 비교하여 탐색)을 수행하기 때문에 처리 속도가 떨어진다.

인덱스의 관리

DBMS는 index를 항상 최신의 정렬된 상태로 유지해야 원하는 값을 빠르게 탐색할 수 있다

그렇기 때문에 인덱스가 적용된 컬럼에 INSERT,UPDATE, DELETE가 수행된다면

각각 다음과 같은 연산을 추가적으로 해주어야 하며 그에 따른 오버헤드가 발생한다

• INSERT : 새로운 데이터에 대한 인덱스를 추가함
• UPDATE : 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업을 진행함
• DELETE : 기존의 인덱스를 사용하지 않음 처리하고, 갱신된 데이터에 대해 인덱스를 추가함

인덱스의 장단점

장점

• 테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있다
• 전반적인 시스템의 부하를 줄일 수 있다

단점

• 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간이 필요하다
• 인덱스를 관리하기 위해 추가 작업이 필요하다
• 인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과가 발생할 수 있다

만약 CREATE, DELETE, UPDATE가 빈번한 속성에 인덱스를 걸게 되면 인덱스의 크기가 비대해져서 성능이 오히려 저하되는 역효과가 발생할 수 있다. 이유 중 하나는 DELETE 와 UPDATE 연산 때문이다

앞서 설명한대로, UPDATE와 DELETE는 기존의 인덱스를 삭제하지 않고, 사용하지 않음 처리를 한다

만약 어떤 테이블에 UPDATE와 DELETE가 빈번하게 발생된다면 실제 데이터는 10만건이지만 인덱스는 훨씬 많이 존재하게 되어, SQL문 처리시 비대해진 인덱스에 의해 오히려 성능이 떨어지게 될 것이다

인덱스를 사용하면 좋은 경우

• 규모가 작지 않은 테이블
• INSERT, UPDATE, DELETE가 자주 발생하지 않는 컬럼
• JOIN이나 WHERE 또는 ORDER BY에 자주 사용되는 컬럼
• 데이터의 중복도가 낮은 컬럼
• 기타 등등

인덱스를 사용하는 것만큼이나 생성된 인덱스를 관리해주는 것도 중요하다

그러므로 사용되지 않는 인덱스는 바로 제거해주어야 한다

인덱스의 자료구조

인덱스를 구현하기 위해서는 다양한 자료구조를 사용할 수 있는데, 가장 대표적인 해시 테이블과 B+Tree에 대해 알아보도록 하자

해시 테이블(Hash Table)

해시 테이블은 (Key, Value)로 데이터를 저장하는 자료구조 중 하나로 빠른 데이터 검색이 필요할 때 유용하다

해시 테이블은 Key 값을 이용해 고유한 index를 생성하여 그 index에 저장된 값

을 꺼내오는 구조이다

해시 테이블 기반의 DB 인덱스는 (데이터 = 컬럼의 값, 데이터의 위치)를 (Key, Value)로 사용하여 컬럼의 값으로 생성된 해시를 통해 인덱스를 구현한다

해시 테이블의 시간 복잡도는 O(1)이며 매우 빠른 검색을 지원한다

하지만, DB 인덱스에서 해시 테이블이 사용되는 경우는 제한적인데, 해시가 등호 연산에만 특화되었기 때문이다

해시 함수는 값이 1이라도 달라지면 완전히 다른 해시 값을 생성하는데, 이러한 특성에 의해 부등호 연산(>,<)이 자주 사용되는 데이터베이스 검색을 위해서는 해시 테이블이 적합하지 않다

즉, 예를 들면 “나는”으로 시작하는 모든 데이터를 검색하기 위한 쿼리문은 인덱스의 혜택을 전혀 받지 못하게 된다.

이러한 이유로 데이터베이스의 인덱스에서는 B+Tree가 일반적으로 사용된다.

B+Tree

B+Tree는 DB의 인덱스를 위해 자식 노드가 2개 이상인 B-Tree를 개선시킨 자료구조로, 하드 디스크상에 구축하기에 알맞은 데이터 구조를 가지고 있어 DB에서 많이 사용된다.

BTree에 의해 어떻게 탐색이 빨라지는가

BTree에 데이터를 삽입할 때는 일정한 규칙에 따라 삽입할 필요가 있는데, 그 규칙 덕분에 검색할 때 일부 노드를 순회하는 것만으로 자연스럽게 찾고자 하는 데이터에 도달하게 된다

B+Tree는 모든 노드에 데이터를 저장했던 BTree와 다른 특성을 가지고 있다

• 리프노드(데이터 노드)만 인덱스와 함께 데이터를 가지고 있고, 나머지 노드(인덱스 노드)들은 데이터를 위한 인덱스만 갖는다
• 리프노드들은 LinkedList로 연결되어 있다
• 데이터 노드 크기는 인덱스 노드의 크기와 같지 않아도 된다

B+트리는 각 노드 내에 자식 노드로의 포인터만 가지고 있고 포인터 이외에 데이터로서의 실제 값 등은 제일 마지막인 잎 노드에만 가지고 있는 구조로 DB에 데이터를 저장하는데 더 최적화된 데이터 구조이다

데이터베이스의 인덱스 컬럼은 부등호를 이용한 순차 검색 연산이 자주 발생될 수 있다

이러한 이유로 BTree의 리프노드들을 LinkedList로 연결하여 순차검색을 용이하게 하는 등 BTree를 인덱스에 맞게 최적화하였다

비록 B+Tree은 O(log n)의 시간 복잡도를 갖지만 해시 테이블보다 인덱싱에 더욱 적합한 자료구조가 되었다

물론, Best Case에 대해 리프 노드까지 가지 않아도 탐색할 수 있는 BTree에 비해 무조건 리프 노드까지 가야한다는 단점도 있다

인덱스 효과의 예

대규모가 되면 될수록 인덱스를 준비해놓느냐 아니냐에 따라 차이가 나게 된다

개인적인 용도의 작은 애플리케이션 정도라면 인덱스를 전혀 사용하지 않아도 충분한 속도로 동작한다

데이터가 1000건 정도라면 오히려 트리를 먼저 순회하는 오버 헤드가 더 커서 그냥 처음부터 찾아 내려가는 편이 더 빠른 경우일 수도 있다

그러나, 크기가 커지면 인덱스 없이는 시작부터 액세스할 수 없는 상황이므로 인덱스는 중요하다

• MySQL
  • MySQL은 레코드 총 건수를 보고 인덱스를 사용하지 않는 편이 더 빠르다고 판단되면, 사용하지 않는 최적화 작업을 내부에서 어느정도 수행한다
  • MySQL에서는 인덱스를 걸어놓고 있는 컬럼을 대상으로 한 쿼리라도 던지는 SQL에 따라서는 인덱스가 사용되거나 사용되지 않기도 한다
  • MySQL에서 alter table 명령 등으로 명시적으로 인덱스를 추가한 경우 이외에도 Primary Key, UNIQUE 제약을 건 컬럼에도 인덱스를 가지고 있다 (show index 명령으로 인덱스 내용 확인)

복수의 칼럼이 인덱스 작용의 대상이 되는 경우 하나의 칼럼만 인덱스로 사용될 것이다

select * from entry where url like ‘~~~’ order by timestamp

url, timestamp 가 모두 index 걸려있을 때, 하나만 인덱스를 사용하고 나머지는 사용하지 않게 된다.

위의 경우 두개 모두 index로 태우려고 할 경우 (url, timestamp)를 쌍으로 한 복합 인덱스를 사용해야 한다

explain 명령에서 속도에 유의하라

자신이 SQL 수반하는 프로그램을 개발할 때 속도에 신경 쓰고자 할 때는 explain 명령으로 자신이 던지려고 하는 SQL에 제대로 인덱스가 작용하는지 여부를 확인하면서 개발하면 좋다

인덱스 작용법이라는 의미에서는 Extra 열도 중요하다

• where 이외에 Using filesord, Using temporary가 나올 경우가 있다.
  • 각각 레코드 정렬에 외부(외부 파일을 사용한 정렬)이나 임시 테이블이 필요하다는 의미다
  • 그다지 틀이 좋은 쿼리라고 할 수 없으므로 가능한 나오지 않도록 쿼리나 인덱스를 튜닝해갈 필요가 있다.

explain 명령 자체의 결과는 실제로 SQL을 던졌을 때의 평가가 아니기때문에 explain 명령어가 빠르다고 빠른 쿼리는 아니다

💡 왜 파일 정렬이나 임시 테이블을 사용하지 않는 편이 좋은가

• 임시 테이블은 내부 임시테이블 크기가 커서 디스크에 생성되면 성능 이슈가 발생하며, 임시테이블을 사용한 정렬이 FileSort에 해당되는데 이는 레코드가 많아질수록 쿼리의 응답 속도가 현저히 떨어지게 된다

마무리

인덱스에 대해 간단히 핵심만 다루고 있지만, PK, Index에 대해 자세히 알고 있는 것이 중요하다

더 알아보기

임시 테이블(Using Temporary)

MySQL 엔진이 스토리지 엔진으로부터 받아온 레코드를 정렬하거나 그룹핑 할 때는 내부적인 임시 테이블을 사용한다

MySQL 엔진이 사용하는 임시 테이블은 처음에는 메모리에 생성됐다가 테이블의 크기가 커지면 디스크로 옮겨진다

원본 테이블의 스토리지 엔진과 관계없이 임시 테이블이 메모리를 사용할 때는 MEMORY 스토리지 엔진을 사용하며,

디스크에 저장될 때는 MyISAM 스토리지 엔진을 이용한다

임시 테이블이 필요한 경우

• ORDER BY와 GROUP BY에 명시된 칼럼이 다른 쿼리
• ORDER BY나 GROUP BY에 명시된 칼럼이 조인의 순서상 첫번째 테이블이 아닌 쿼리
• DISTINCT와 ORDER BY가 동시에 존재하는 경우 또는 DISTINCT가 인덱스로 처리되지 못하는 쿼리
• UNION이나 UNION DISTICT가 사용된 쿼리
• UNION ALL이 사용된 쿼리
• 쿼리의 실행 계획에서 select_type이 DERIVED인 쿼리

해당 6가지 중 1~3번째 경우에는 Extra 칼럼에 “Using Temporary”가 표시되며, 4~6번째 경우에는 Extra 칼럼에 “Using Temporary”가 표시되지 않지만 임시테이블이 사용된다

주의 사항

내부 임시 테이블이 크기가 커서 디스크에 생성되면 성능 이슈가 발생한다

내부 임시 테이블이 디스크에 생성되었는지 여부를 파악하려면 아래의 명령어로 가능하다

SHOW SESSION STATUS LIKE 'Create_tmp%';

해당 쿼리의 결과로 생성된 임시 테이블의 상태를 파악할 수 있다

만약 처리해야하는 레코드 건수가 100만 건이라고 가정한다면, 해당 건의 데이터 디스크에 저장된다면 큰 부하가 발생하게 되므로 각별히 주의를 기울여야 한다

드라이빙 테이블 정렬(Using Filesort)

MySQL의 정렬 처리는 크게 2가지로 나뉜다

• index를 이용한 정렬
• File sort(”Using filesort”)

인덱스를 사용할 수 있는 경우

1. ORDER BY에 명시된 칼럼이 제일 먼저 읽는 테이블에 속해야 한다
2. ORDER BY절의 순서가 인덱스와 일치해야한다
3. WHERE 절에 첫 번째 읽는 테이블에 대한 조건이 있다면, ORDER BY절도 같은 인덱스를 사용할 수 있어야 한다

인덱스를 사용하는 정렬은 완벽한 조건을 요구하는 만큼 처리가 빠르다

인덱스의 값이 정렬되어 있기때문에 해당 인덱스를 읽기만 하면 된다

MySQL은 인덱스를 통해 정렬할 수 없다면 FileSort를 사용한다

위에서의 임시 테이블을 사용한 정렬도 FileSort에 해당한다

FileSort는 레코드가 많아질수록 쿼리의 응답 속도가 현저히 떨어지게 된다

File Sort를 사용하는 경우

1. 드라이빙 테이블만 정렬 (”Using filesort”)
2. 임시 테이블을 이용한 정렬 (”Using temporary, Using filesort”)

드라이빙 테이블만 정렬된다는 방식은 조회하는 테이블 중 먼저 액세스되는 테이블만 SortBuffer에서 정렬해서 나머지 테이블과 조합하는 방식이다.

이 경우 SortBuffer로 테이블을 하나 옮겨서 정렬하는 작업이 필요하지만 임시 테이블을 이용하는 방법보다는 낫다

드라이빙 테이블만 정렬하는 방법을 사용할 수 없다면 임시 테이블을 사용해야 한다

임시 테이블을 이용한 정렬은 2개 이상의 테이블을 조인해서 그 결과를 전부 임시 테이블에 넣어서 정렬하는 방식이다

임시 테이블을 이용한 정렬은 모든 테이블의 결과를 임시 테이블에 넣고 정렬을 수행하므로 가장 느리다

특히, 레코드가 많아지면 임시 테이블이 디스크에 저장되면서, 대규모 서비스에서 치명적인 I/O 부하가 발생한다

이 경우 Application Layer나 Presentation Layer에서 정렬을 해서 뷰에 노출하는 것을 고려할 수 있다

🍀 참조

SQL - Using Temporary, Using Filesort 정리 (+ 임시 테이블, 파일 정렬)

동시성

어떤 두 사건이 같은 시간에 일어나는 것

대부분의 웹 서버는 여러 개의 요청을 동시에 수행할 수 있고, 이는 작성한 코드가 동시에 수행될 수 있다.

프로그래밍을 하다 보면 이러한 동시성 처리가 필요한 경우가 있다.

하지만 동시성과 병렬성이 혼돈되어 사용되는 경우가 있어 한 번 정리해볼까한다.

동시성 vs 병렬성

그림은 싱글 코어와 멀티 코어에서 동작하는 모습을 비교하는 그림이다.

싱글 코어에서는 2개의 작업을 동시에 실행되는 것처럼 보이기 위해 번갈아 가면서 작업을 수행한다. 

이때, 다른 작업으로 바꾸어 실행할 때 내부적으로 Context switch가 일어난다

자세한 문맥교환은 다른 페이지에서 다루도록 하겠다.

그렇다면 우리가 동시성 이슈를 해결해야하는 이유는 무엇일까 ?

진행했던 프로젝트가 실제 적용될 수 있는 사례와 유사하니 이로 예시를 들어보겠다.

수량이 마지막 1개가 남아있는 시점에서 동시에 두 명의 유저가 요청을 하게 되었을 때 동시성 이슈가 해결되지 않을 경우, 둘 모두 성공하여 수량은 1개인데, 가져야 하는 사람이 2명인 난감한 상황이 펼쳐지게 된다. 이와 같은 상황에서 둘 모두 성공하는 것이 아니라 한 명만이 성공해야 하기때문에 동시성 이슈를 해결해야 한다.

위와 같은 상황을 경쟁 조건(race condition)이라고 한다.

경쟁 조건

여러 프로세스 및 스레드가 동시에 동일한 데이터(공유 데이터)를 조작할 때 타이밍이나 접근 순서에 따라 예상했던 결과가 달라질 수 있는 상황을 의미한다.

동시성 이슈의 문제점

• 공유 데이터에 대해 예상 결과가 다르지만 오류가 발생하지 않는다.
• 코드를 작성할 때는 로컬에서 개발하기때문에 파악하기 힘들다.
• 비정형적으로 발생하기때문에 디버깅이 힘들 수 있다.

동시성 이슈를 해결하면서 주의사항

뮤텍스, 세마포어, Lock 과 같은 경우 상호 배제만 해결해주기때문에 교착상태와 기아상태를 발생할 수 있다.

기아상태 (Starvation)

특정 프로세스의 우선 순위가 낮아서 원하는 자원을 계속 할당 받지 못하는 상태를 말한다.

교착상태

교착상태(Dead Lock)은 둘 이상의 프로세스들이 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며 무한정 기다리는 현상을 의미한다.

기아상태와 교착상태의 차이

교착상태는 프로세스가 자원을 얻지 못해 다음 처리를 하지 못하는 상태를 말하고,

기아상태는 프로세스가 원하는 자원을 계속 할당 받지 못하는 상태이다.

즉, 교착 상태는 여러 프로세스가 동일한 자원 점유를 원할 때 발생하고,

기아 상태는 여러 프로세스가 자원을 점유하기 위해 경쟁할 때 특정 프로세스는 영원히 자원 할당을 받지 못하는 것이다.

교착 상태 발생 조건

주로 멀티 프로그래밍 환경에서 한정된 자원을 얻기 위해 서로 경쟁하는 상황에서 발생한다.

교착상태가 발생하기 위해서는 다음의 4가지 조건이 충족되어야 하는데, 이 네가지 조건 중 하나라도 충족되지 않으면 교착상태가 발생하지 않는다.

• 상호 배제(Mutual Exclusion)

자원은 한 번에 한 프로세스만이 사용할 수 있어야 한다.

상호 배제 기법에는 뮤텍스, 세마포어 등이 있다.

이 방법들은 상호 배제만 해결해주기 때문에 데드락과 기아상태가 발생할 수 있다.

• 뮤텍스
  • Key에 해당하는 어떤 오브젝트가 있으며 이 오브젝트를 소유한 (스레드, 프로세스) 만이 공유자원에 접근할 수 있다.
  • 임계영역을 가진 스레드들의 실행 시간이 서로 겹치지 않고 각각 단독으로 실행되도록 하는 기술
  • 뮤텍스 객체는 제어되는 섹션에 하나의 스레드만 허용하기때문에 해당 섹션에 접근하려는 다른 스레드들을 강제적으로 막음으로써 첫 번째 스레드가 해당 섹션을 빠져나올 때까지 기다리도록 한다
• 세마포어
  • 멀티 프로그래밍 환경에서 공유된 자원에 대한 접근을 제한하는 방법
  • 현재 공유자원에 접근할 수 있는 스레드, 프로세스의 수를 나타내는 값을 기반으로 한다
  • 세마포어는 공유 리소스에 접근할 수 있는 최대 허용치만큼 동시에 사용자 접근을 할 수 있게 한다.
  • 스레드들은 리소스 접근을 요청할 수 있고, 세마포어에서는 카운트가 하나씩 줄어들게 되며 리소스 사용을 마쳤다는 신호를 보내면, 세마포어 카운트가 하나 늘어나게 된다.
  • 이때 세마포어에서 발생할 수 있는 단점은 DeadLock 교착상태이다
• 모니터

뮤텍스와 세마포어의 차이

• 세마포어는 뮤텍스가 될 수 있지만, 뮤텍스는 세마포어가 될 수 없다.
• 세마포어는 소유할 수 없으며, 뮤텍스는 소유할 수 있고, 소유주가 그에 대한 책임을 가진다.
• 세마포어는 동기화 대상이 여러 개일때 사용하고, 뮤텍스는 동기화 대상이 오로지 하나일 때 사용된다.

• 점유와 대기(Hold and Wait)

최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용하고 있는 자원을 추가로 점유하기 위해 대기하는 프로세스가 있어야 한다.

• 비선점(Non-preemption)

다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 빼앗을 수 없어야 한다.

• 환형 대기(Circular Wait)

서로 다른 공유자원을 사용하기 위해 대기하는 프로세스들이 원형으로 구성되어 있어 자신에게 할당된 자원을 점유하면서 앞이나 뒤에 있는 프로세스의 자원을 요구한다.

교착 상태 해결 방안

• 예방(Prevention)

교착상태가 발생하지 않도록 사전에 시스템을 제어하는 방법으로, 교착상태 발생의 4가지 조건 중에서 어느 하나를 제거한다. 즉, 자원 낭비가 가장 심한 해결 방법이다.

• 상호 배제 부정 : 한 번에 여러 개의 프로세스가 공유 자원을 사용할 수 있도록 한다.
• 점유 및 대기 부정 : 프로세스가 실행되기 전 필요한 모든 자원을 할당하여 프로세스 대기를 없애거나 자원이 점유되지 않은 상태에서만 자원을 요구한다.
• 비선점 부정 : 자원을 점유하고 있는 프로세스가 다른 자원을 요구할 때 점유하고 있는 자원을 반납하고, 요구한 자원을 사용하기 위해 기다린다.
• 환형대기 부정 : 자원을 선형 순서로 분류하여 고유 번호를 할당하고, 각 프로세스는 현재 점유한 자원의 고유 번호보다 앞이나 뒤 어느 한쪽 방향으로만 자원을 요구하도록 한다.

• 회피(Avoidance)

교착상태가 발생할 가능성을 배제하지 않고 교착상태가 발생하면 적절히 피해나가는 방법으로, 주로 은행원 알고리즘(Banker’s Algorithm)이 사용된다.

은행원 알고리즘

1. 은행원 알고리즘은 다익스트라가 제안한 기법으로, 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는데서 유래한 기법이다.
2. 각 프로세스에게 자원을 할당하여 교착상태가 발생하지 않으면 모든 프로세스가 완료될 수 있는 상태를 안전상태, 교착상태가 발생할 수 있는 상태를 불안전 상태라고 한다.
3. 은행은 자원을 할당한 후에도 안정 상태로 남아있는지 검사하여 안정 상태에 있으면 자원을 할당하고 그렇지 않으면 다른 프로세스들이 자원을 해제할 때까지 대기한다.
4. 은행원 알고리즘을 적용하기 위해서는 자원의 양과 사용자(프로세스) 수가 일정해야 한다.
5. 은행원 알고리즘은 프로세스의 모든 요구를 유햔한 시간안에 할당하는 것을 보장한다.

• 탐지(Detection)

시스템에 교착상태가 발생했는지 점검하여 교착상태에 있는 프로세스와 자원을 발견한다.

교착 상태 발견 알고리즘과 자원 할당 그래프등을 사용할 수 있다.

• 복구(Recovery)

교착상태를 일으킨 프로세스를 종료하거나 교착상태의 프로세스에 할당된 자원을 선점하여 프로세스나 자원을 회복한다.

프로세스 종료

• 교착상태에 있는 프로세스를 종료
• 교착상태에 있는 프로세스들을 하나씩 종료

자원 선점

• 교착상태의 프로세스가 점유하고 있는 자원을 선점하여 다른 프로세스에게 할당하며, 해당 프로세스를 일시 정지시키는 방법이다. 우선순위가 낮은 프로세스, 수행된 정도가 적은 프로세스, 사용되는 자원이 적은 프로세스등을 위주로 해당 프로세스의 자원을 선점한다.

Transport Layer(4 Layer)

• 송신자와 수신자를 연결하는 통신 서비스를 제공하는 계층(데이터 전달 담당)
• 신뢰성 있는 연결을 유지할 수 있도록 도와준다.
  • Endpoint(사용자) 간의 연결을 생성하고, 데이터를 얼마나 보냈는지 얼마나 받았는지, 제대로 받았는지등을 확인한다.
• 데이터를 보내기 위해 사용하는 프로토콜 : TCP , UDP

Network Layer(3 Layer)

• IP(Internet Protocol)이 활용되는 부분
• 한 Endpoint가 다른 Endpoint로 가고자 할 경우, 경로와 목적지를 찾아준다. 이를 Routing이라고 하며 대역이 다른 IP들이 목적지를 향해 제대로 찾아갈 수 있도록 돕는 역할을 한다.

TCP(Transmission Control Protocal)

인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜

일반적으로 TCP와 IP 함께 사용하는데,

IP가 데이터의 배달을 처리한다면, TCP는 패킷을 추적 및 관리하게 된다.

TCP 특징

연속성보다 신뢰성이 있는 전송이 중요할 때 사용하는 프로토콜

• 연결 지향 방식
  • 패킷을 전송하기 위한 논리적 경로를 배정
• 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.
  • 3-way handshaking과정 : 목적지와 수신지를 확실히 하여 정확한 전송을 보장하기 위해 세션을 수립하는 과정을 의미
• 흐름 제어 및 혼잡 제어
  • 흐름 제어송신하는 곳에서 감당되지 않는 많은 데이터를 빠르게 보내 수신하는 곳에서 문제가 발생하는 것을 막는다.
  • 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지하는 것이다.
  • 혼잡 제어정보의 소통량의 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막는다.
  • 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 패킷 오버플로우는 방지하는 것이다.
• 높은 신뢰성을 보장한다.
• UDP보다 속도가 느리다.
  • 연결형 서비스, 3-way handshaking과정, 데이터의 흐름 제어 및 혼잡 제어 기능은 CPU를 사용하기때문에 속도에 영향을 준다.
• 전이중(Full-Duplex),점대점(Point to Point) 방식

예를 들면 파일 전송과 같은 경우 사용된다.

TCP 서버의 특징

• 서버소켓은 연결만을 담당한다.
• 연결과정에서 반환된 클라이언트 소켓은 데이터의 송수신에 사용된다
• 서버와 클라이언트는 1대1로 연결된다.
• 스트림 전송으로 전송 데이터의 크기가 무제한이다.
• 패킷에 대한 응답을 해야하기 때문에(시간 지연, CPU 소모) 성능이 낮다
• Streaming 서비스에 불리하다. (손실된 경우 재전송 요청을 하므로)

TCP/IP

• (참고) Internet Protocol Suite인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 쓰이는 프로토콜의 모음
• 인터넷 프로토콜 슈트중 TCP와 IP가 가장 많이 쓰이기때문에 TCP/IP 프로토콜 슈트라고도 불린다.
• Internet Protocol Suite

패킷 통신 방식의 인터넷 프로토콜 IP와 전송 조절 프로토콜 TCP로 이루어져있다.

IP는 패킷 전달 여부를 보증하지 않고, 패킷을 보낸 순서와 받는 순서가 다를 수 있다.

TCP는 IP 위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보내는 순서대로 받게 해준다.

HTTP(웹), FTP(원격 터미널 접속), SMTP(전자메일) 등 TCP를 기반으로 한 많은 수의 애플리케이션 프로토콜들이 IP 위에서 동작하기 때문에, 묶어서 TCP/IP로 부르기도 한다.

송신자가 수신자에게 IP 주소를 사용하여 데이터를 전달하고, 그 데이터가 제대로 갔는지, 너무 빠르진 않았는지, 제대로 받았다고 연락은 오는지에 대한 이야기를 하는 것이다

UDP(User Datagram Protocol)

데이터를 데이터그램 단위로 처리하는 프로토콜

데이터 그램이란 독립적인 관계를 지니는 패킷

연결을 위해 할당되는 논리적인 경로가 없기 때문에 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 되는데, 이렇게 다른 경로로 독립적으로 처리하게 되는 프로토콜

UDP 특징

신뢰성보다 연속성이 중요한 서비스에 자주 사용하는 프로토콜

• 비연결형 서비스로 데이터그램 방식을 제공한다
• 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다
• UDP헤더의 CheckSum 필드를 통해 최소한의 오류만 검출한다
• 신뢰성이 낮다
• TCP보다 속도가 빠르다
• 네트워크 부하가 적다

예를 들면 실시간 서비스(streaming)에 사용된다.

UDP 서버의 특징

• UDP에는 연결 자체가 없어서 (connect 함수 불필요) 서버 소켓과 클라이언트 소켓의 구분이 없다
• 소켓 대신 IP를 기반으로 데이터를 전송한다
• 서버와 클라이언트는 1대1, 1대N, N대M등으로 연결될 수 있다
• 데이터그램(메세지)단위로 전송되며 그 크기는 65535바이트로, 크기가 초과하면 잘라서 보낸다
• 흐름 제어가 없어서 패킷이 제대로 전송되었는지, 오류는 없는지 확인할 수 없다.
• 파일 전송과 같은 신뢰성이 필요한 서비스보다 성능이 중요시 되는 경우에 사용된다.

TCP와 UDP의 비교

참고

패킷(Packet)

인터넷 내에서 데이터를 보내기 위한 경로배정(라우팅)을 효율적으로 하기 위해서 데이터를 여러 개의 조각들로 나누어 전송을 하는데 이때, 이 조각을 **패킷**이라고 한다.

TCP는 패킷을 어떻게 추적 및 관리하는가

데이터는 패킷 단위로 나누어 같은 목적지(IP계층)으로 전송된다.

예를 들어 한줄로 서야하는 A,B,C라는 패킷들이 발신지에서 출발하여 수신지로 간다고 해보자.

그런데 A,B,C가 순차적으로 가는 상황에서 B가 길을 잘못 들어서 분실되었다고 해보자. 하지만 목적지에는 A,B,C가 모두 필요한지 모르고 A,C만 보고 다 왔다고 착각할 수 있다.

그렇기 때문에 A,B,C라는 패킷에 1,2,3이라는 번호를 부여하여 패킷의 분실 확인과 같은 처리를 하여 목적지에서 재조립을 한다.

이런 방식으로 TCP는 패킷을 추적하며, 나누어 보내진 데이터를 받아 조립할 수 있다.

Handshake

• 자세히 살펴보기

3-way handshake

TCP/IP 프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정

3way handshake는 양쪽 모두 데이터를 전송할 준비가 되어있다는 것을 보장하고, 실제로 데이터 전달이 시작하기 전에 다른 한쪽이 준비되었다는 것을 알 수 있도록 해준다

4-way handshake

3way handshake가 연결확립을 위해 진행했다면 4way handshake는 세션을 종료하기 위해 수행되는 절차 를 말한다.

TCP 헤더 및 3-way handshake 참고 자료