프로그래밍 메모장

가끔 공부하다보면 anycast란 내용이 보이길래 요약겸 정리해논다.

Anycast

Anycast는 각각 동일한 IP 주소가 할당된 엔드포인트 그룹에 여러 라우팅 경로를 제공하는 기술 - microsoft

??? 이렇게 말하면 무슨 말인지 감이 잡히지 않는다.

보통 우리가 알고 있는 IP는 '고유한' 주소이고, Unicast IP이다. 

우선 unicast가 뭔지 알고 넘어가야 될꺼 같다.

참고)

유니캐스트 (Unicast) - 1 : 1 

유니캐스트는 정보를 전송하기 위한 프레임에 자신의 MAC 주소와 목적지의 MAC 주소를 첨부하여 전송

브로드캐스트 (Broadcast) 1 : N

브로드캐스트 방식은 로컬 네트워크에 연결되어 있는 모든 시스템에게 프레임을 보내는 방식

멀티캐스트(Multicast) 1: N (특정 그룹)

멀티캐스트는 네트워크에 연결되어 있는 시스템 중 일부에게만 정보를 전송하는 것으로 특정 그룹에 속해 있는 시스템에게만 한 번에 정보를 전송할 수 있는 방법

라우터가 멀티캐스트를 지원해야만 사용 가능하다는 단점

멀티캐스트 전송이 지원되면 송신자는 여러 수신자에게 한 번에 메시지가 전송되도록 하여

데이터의 중복 전송으로 인한 네트워크 자원 낭비를 최소화할 수 있게 된다.

멀티캐스트 전송을 위해서는 헤더에 수신자의 주소 대신 수신자들이 참여하고 있는 그룹 주소를 표시하여 패킷을 전송한다.

Anycast란?

Anycast IP는 서로 다른 호스트끼리 동일한 IP 주소를 가질 수 있는 개념이다.

링크 계층(L2)에서 맥 주소를 보고 데이터를 전달할때는 충돌이 일어나면 사용이 불가능하지만

라우터(L3)에서는 네트워크 라우팅 알고리즘(BGP)을 통해 가장 가까운곳으로 판단되는 쪽으로 사용 가능한 식으로 구현되어 있다. 

anycast는 주로 DNS 서비스에 많이 활용되고 있다는데 지역별로 DNS 서버를 분산하고, 항상 네트워크 경로상 가까운 DNS 서버가 응답하게 된다.

왜 이런 구조를 사용하냐면 root DNS에 하위 DNS 서버들이 계층적으로 쌓여있는 기존 구조에서는 네트워크 DNS DDos 공격이나 웜 공격등으로 root DNS가 마비되게 되면 전 세계 DNS가 마비되게 된다. 그래서 DNS를 적절히 분산 구성해 분산 처리 및 가까운 거리로 인한 네트워크 지연 감소 등 여러 이유로 사용하고 있다고 한다.

가장 유명한 예시로는 구글의 public DNS IP 8.8.8.8 이 anycast로 구성되어 있고,

전세계 국가에 분산되어 있다고 한다. 

장점

- L4/L7 로드밸런싱 장비 대신 쓰기 가능?(라우팅+서버)

- 사용자와 네트워크 적으로 가장 가까운 곳으로 안내

- L4/L7 이 대규모 트래픽 처리가 힘든데 서버로 바로 트래픽을 보내니 대규모 트래픽 처리에 용이

- 회선문제로 장애시 자동으로 다른곳으로 우회(회선 이중화 비용 절감)

- 오픈소스 -> 가격 X!

단점

- 네트워크 적으로 가장 가까운곳 !== 지리적으로 가까운곳

ISP 마다 라우팅 정책이 다르므로 제어가 힘들다.

- 라우터에서 라우팅만 하기 때문에 L4/L7에선 가능한? 서버의 상태 체크(죽었나 살았나)가 안된다는 단점

reference 

https://docs.microsoft.com/ko-kr/windows-server/networking/dns/deploy/anycast

https://tech.kakao.com/2014/05/29/anycast/

프로세스를 새로 생성할때 fork 함수를 이용할 수 있습니다.

fork 함수를 호출한 프로세스는 부모 프로세스가 되고

새롭게 생성되는 프로세스는 자식 프로세스가 됩니다.

두 프로세스는 다른 pid를 가지고 독립적이게 동작합니다.

Copy On Write

이때 Linux에서는 자식 프로세스를 생성하면 같은 메모리 공간을 공유하게 됩니다. 

부모 프로세스에서 페이지 바로 C를 수정한다면 자식 프로세스에도 영향을 끼칠것입니다.

그래서 직접 변경 대신 페이지 C를 복사해서 수정(Copy on write)하는 방식으로 작동합니다.

#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<string.h>
#include<fcntl.h>

int statofLoc; // get child process's state when child process is done
int childPid;

char **command; //get parsed words, command[0] is command,  
                //others option

void fatal_error(char* errorCommand) // to record error and exit
{
  perror(errorCommand);
  exit(-1);
}

childPid = fork();

if(childPid == 0){ // child
			
   if(execvp(command[0], command)<0)
  {
    fatal_error("unknown command");
    //if this function is actived,
    //something is wrong
  }
}
else if(childPid < 0) //error
{
  fatal_error("pid ERROR");
}
else //parent
{
  waitpid(childPid, &statofLoc, WUNTRACED);
  //wait till child process is done.
}

wait(혹은 waitpid) 함수를 이용하면 부모 프로세스는 자식 프로세스가 종료될때까지 기다릴 수 있습니다.

wait는 다음과 같이 작동합니다.

1. 자식 프로세스가 동작 중이면 호출 차단이 차단되기 때문에 상태를 얻어올 때까지 대기

2. wait() 함수 호출자가 시그널을 받을 때까지 대기

3. 자식 프로세스가 종료된 상태라면 즉시 호출이 반환되어 상태를 얻음, 이 때 wait() 함수는 자식 프로세스의 프로세스 ID를 반환
4. 자식 프로세스가 없다면 호출이 즉시 반환되며, 에러값을 반환

고아 프로세스  

부모가 먼저 자식 프로세스보다 먼저 종료되면 자식 프로세스는 고아 프로세스가 됩니다.

만약 부모가 먼저 종료되면 커널은 부모 프로세스가 누구의 부모인지 확인하고 자식 프로세스들의 부모 프로세스 ID

(ppid)들을 전부 1(init process)로 바꿔줍니다.

리눅스에서 백그라운드에서 돌아가는 데몬 프로세스를 생성하는 방법으로 해당 방식을 이용합니다.

1. fork후 부모 종료(ppid 가 1로 변경)

2. setsid로 고아 프로세스를 세션 리더로 생성

3. etc...

고아 프로세스가 종료되면 init process가 wait를 호출해 좀비 프로세스가 되는것을 방지합니다.

좀비 프로세스

자식 프로세스가 종료되었지만 자식 프로세스의 종료상태를 회수하지 않았을때 자식 프로세스를 좀비 프로세스라 합니다.

자식 프로세스가 exit 시스템콜을 호출하면 프로세스에 대한 메모리 & 리소스가 해제되 다른 프로세스에서 사용 가능합니다.

그런데 자식 프로세스의 정보를 알고 싶어할 수 있기 때문에 부모 프로세스의 wait system call 호출 이전까지는 최소한의 정보를 가지는 상태로 남아 있습니다. 

wait로 정말로 제거되기 이전 상태를 좀비 프로세스라고 부릅니다. 

그럼 fork를 어디에 쓰나요..? 보통 멀티테스킹을 위해 많이 쓰입니다.

대표적인 예시로는 shell에서

터미널에서 fork 해 자식 프로세스를 만든 다음

자식 프로세스에서 명령어를 파싱하고, exec system call을 해 명령을 처리합니다.

다만 cd(change directory)의 경우 자식 프로세스가 아니라 부모 프로세스(터미널) 자체가 움직여야 하기 때문에

cd는 예외적으로 fork를 하지않고 직접 처리합니다.

reference

COW

https://openwiki.kr/tech/copy-on-write

https://codetravel.tistory.com/30?category=993122 

데몬 프로세스

https://kukuta.tistory.com/386

엄청 헷갈리는 개념이라 메모해두려고 한다.

URI (Uniform Resource Identifiter - 통합 자원 식별자)

웹 기술에서 사용하는 논리적 or 물리적 리소스를 식별하는 고유한 문자열 시퀀스

주소보다는 '식별자'의 개념

URL (Uniform Resource Locator)

네트워크 상에서 웹 리소스에 대한 참조

흔히 웹 주소라고 한다.

우리가 주로 쓰는 주소가 URL

URL은 URI의 서브셋이다.

URI - 식별자

URL - 위치

URN (Uniform resource name)

URI의 특정 포맷중 하나로 이름으로 리소스를 특정하는 URI 

프로토콜을 제외하고 리소스의 name 을 가리키는데 사용

URN에는 접근 방법 & 위치가 표기 X

참고) URL 구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

scheme : 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용

user와 password : (서버에 있는) 데이터에 접근하기 위한 사용자의 이름과 비밀번호

host와 port : 접근할 대상(서버)의 호스트명과 포트번호

path : 접근할 대상(서버)의 경로에 대한 상세 정보

query : 접근할 대상에 전달하는 추가적인 정보 (파라미터)

fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보

reference

https://www.charlezz.com/?p=44767 

https://mygumi.tistory.com/139

개인적으로 DB 내용은 어렵기도 하고 안쓰고 있으면 자꾸 까먹는거 같습니다.

이 블로그의 주 목적이기도 하고 메모용으로 간단하게 글을 써보려 합니다.

*틀린게 있으면 피드백 주시면 감사하겠습니다!

index란?

 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조

1000페이지의 책이 있다고 쳐봅시다. 특정 키워드를 찾고 싶은데 1쪽부터 1000쪽까지 전부 순회하며 찾으려면 매우 큰 시간 낭비일것입니다.

그래서 책에는 키워드를 빨리 찾기 위해서 보통 맨뒤에 색인이 있습니다.

데이터베이스에서도 인덱스는 책의 색인과 비슷한 역할을 한다고 보면 좋습니다.

(보통 Index는 PK에 기본적으로 걸려있습니다.)

Index의 구조

Balanced Tree인 B+(B) tree를 많이 사용합니다.

왜 tree 형태냐면 하드 디스크에서 데이터를 가져올때 섹터 단위(block 단위)로 가져오게 되는데 데이터를 효율적으로 관리하기 위해서 포인터로 참조하는 트리 형태를 띄게 됩니다.

*  b tree는 모든 노드에 key와 데이터를 가지지만 B+ tree는

branch node에서는 leaf node에 대한 key를 가지고, leaf node에만 데이터를 가집니다. 

Index의 장점

- 테이블 조회 속도 & 성능 향상

- 시스템 부하 감소

Index의 단점

- 인덱스를 사용하기 위해 대략 10%의 추가 저장공간이 필요하다

- 잘못 사용할 경우 성능 저하

- index 관리를 위해 추가 작업 필요 

보통 create, update, delete는 빈번하게 일어나지 않고 조회(select)만 자주 일어나는 속성에 사용하는게 좋습니다

-> DELETE, UPDATE 시 인덱스를 '사용하지 않음' 처리 

빈번하게 DELETE, UPDATE가 일어난다면 인덱스의 크기가 매우 커져서 오히려 성능이 줄어든다.

* select문에서 like '%문자' 같이 %를 앞에 넣어서 사용하는 경우 index를 타지않아서

검색 구현시 형태소 분석이나 elasticsearch를 사용하는것을 권장한다고 합니다

사용하면 좋은경우 

- 규모가 매우 큰 테이블

- INSERT, UPDATE, DELETE가 빈번하지 않은 컬럼

- 자주 SELECT문(특히 join, where, order by)에 쓰이는 컬럼

- 데이터의 중복도가 낮은(=cardinality가 높은) 테이블

- 데이터 분포도 10~15%(1/해당 컬럼의 distinct 데이터 개수 * 100)인 칼럼

Cardinality란?

전체 행에 대한 특정 컬럼의 중복 수치를 나타내는 지표입니다

-> 중복도 낮다 = 카다널리티 높다.

-> 중복도 높다 = 카다널리티 낮다.

중복도는 어떤 절대적인 수치가 아니라 '상대'적인 수치입니다.

id가 distanct값이 4개이므로 가장 카다널리티가 높습니다.

name은 distant 값이 3개이므로 id보다는 카다널리티가 낮고, location보다는 카다널리티가 높습니다.

location은 distant 값이 2개이므로 가장 카다널리티가 낮습니다.

인덱스를 걸때 중복이 최대한 없어야 데이터가 많이 걸러질것입니다. (중복이 많을수록 full scan에 가까워짐)

그래서 카다널리티가 높은 컬럼을 인덱스 우선순위로 추천한다고 합니다. 

Clustered Index 

Index를 생성할때 데이터 페이지 전체를 물리적으로 재배열 합니다.

테이블 당 한개만 존재합니다.

-> 가장 효율적인 칼럼을 Clustered Index로 지정 

테이블 크기의 3%정도 추천

Non-Clustered Index

군집화 되어있지 않은 인덱스 타입? (순서대로 정렬되있지 않다)

물리적으로 데이터를 배열하지 않고, 별도의 장소에 데이터 페이지가 구성됩니다.

테이블 당 여러개 존재 가능합니다.

Non-clusered index는 clustered Index보다 검색 속도는 느리지만 입력/수정/삭제는 더 빠릅니다.

(clustered Index의 경우 그 반대)

테이블 크기의 20%정도 추천

reference 

index 

https://mangkyu.tistory.com/96

b tree 

https://velog.io/@seanlion/btree

카디널리티

https://itholic.github.io/database-cardinality/

수학적으로 멱등성이란

어떤 집합이 연산 A에 대해 닫혀있을때, 연산 A를 여러번 적용해도 달라지지 않는 성질을 뜻한다.

네트워크 HTTP 에서 멱등성이란

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고,

서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말한다.

다만 서버가 REST API를 잘 따랐다는 전제하에 멱등성 제약이 보장된다.

(ex : 서버가 get으로 CRUD 전체를 다 처리한다던가 restful하지 않게 구현되어 있다면 멱등성 보장 X)

멱등성이 성립하는 기준

멱등성은 요청의 효과를 보고 판단한다.

같은 행위를 여러번 반복하더라도 같은 효과를 가져야한다.

많이 쓰이는 http method중 POST를 제외한 GET, PUT, DELETE 가 멱등성이 보장되고,

그외 method로는 OPTIONS, HEAD 등이 있다.

예를 들어 PUT의 경우

PUT /user/4

라는 요청이 간다면 4번째 유저가 없다면 생성되고, 있다면 update 되는 형식으로 동작할것이다.

그런데 PUT 요청을 여러번 보내더라도 항상 4번 유저는 요청된 값과 똑같은 값으로 갱신하니

같은 상태일 것이다.

DELETE도 비슷한 방식으로 동작하고, GET, OPTIONS, HEAD 같은 경우는 조회(read) 동작만 하므로

항상 서버의 상태는 동일하다고 기대할 수 있다.

다만 PATCH(리소스의 일부만 수정)의 경우 멱등성이 보장이 되지 않는다.

예를 들어

PATCH users/1
{
    $increase: 'age',
    value: 1,
}

같이 increase하고 싶은 변수 이름과 값을 보낸다고 해보자.

그럼 PATCH를 보낼때마다 상태가 변경되니 멱등성을 기대할 수 없다고 볼 수 있다.

안전한 메소드

그럼 안전한 메소드란?

서버의 상태를 아예 변경시키지 않는 메소드를 말한다.

해당 메소드로는 GET, OPTIONS, HEAD 등 read 메소드들이 있다

https://velog.io/@dion/HTTP-%EB%A9%94%EC%86%8C%EB%93%9C%EC%9D%98-%EB%A9%B1%EB%93%B1%EC%84%B1-%EA%B7%B8%EA%B2%8C-%EB%AD%94%EB%8D%B0

https://oen-blog.tistory.com/211

https://developer.mozilla.org/ko/docs/Glossary/Idempotent

폰 노이만 구조

현재와 같은 CPU, 메모리, 프로그램 구조를 갖는 범용 컴퓨터 구조의 확립

• 산술 논리 장치와 프로세서 레지스터를 포함하는 처리 장치
• 명령 레지스터와 프로그램 카운터를 포함하는 컨트롤 유닛
• 데이터와 명령어를 저장하는 메모리
• 외부 대용량 스토리지
• 입출력 매커니즘

장점 

컴퓨터에 작업을 시키려고 할때 하드웨어적으로 재 배치를 할 필요가 없이 소프트웨어만 교체하면 되기 때문에

범용성(general-purpose)이 크게 향상된다.

따라서 현대의 컴퓨터는 거의 다 이 구조를 따르고 있다.

단점

메모리에서 데이터/코드(프로그램)을 가져올때 버스 하나로 한번에 하나만 가져오는 구조이기 때문에 폰 노이만 병목 현상이 일어날 수 있다.

이를 해결하기 위해 다양한 방법이 고안되었지만 폰 노이만 구조를 쓴다면 근본적 문제는 해결하진 못했다.

- 하버드 구조의 발명 

- 메모리 계층 구조(L1~L2 캐시, 메인 메모리, 하드디스크 구조)

- 다양한 방식 고안

ex) NUMA(메모리에 접근하는 시간이 메모리와 프로세서간의 상대적인 위치에 따라 달라진다.)

DMA(CPU가 직접 메모리 접근)

하버드 구조

하버드 아키텍처(Harvard architecture)는 명령용 버스와 데이터용 버스로 물리적으로 분할한 컴퓨터 아키텍처

명령용 버스와 데이터용 버스를 분할 -> 폰 노이반 병목 현상을 동시 접근으로 해결하려고 시도

단점 : cost(버스가 2배!)

현대에 이르러서는 CPU의 외부적으로는 폰 노이만 구조를, 내부적으로는 하버드 구조

reference

https://velog.io/@ckstn0777/%EC%BB%B4%ED%93%A8%ED%84%B0-%EA%B5%AC%EC%A1%B0

캐시란?

자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다. 

Cache는 아래와 같은 경우에 사용을 고려하면 좋다.

• 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우(서버의 균일한 API 데이터)
• 반복적으로 동일한 결과를 돌려주는 경우(이미지나 썸네일 등)

캐시는 컴퓨터 구조뿐만 아니라 네트워크, DB등 여러곳에서 자주 사용하는 개념이다.

이글에서는 CPU 내부의 캐시에 대해 간략하게 알아본다.

CPU 캐시 란

cpu의 내부 캐시란 CPU와 메인 저장 장치(하드디스크)간 속도의 모순을 해결하기 위해서 사용하는 것이다.

CPU 는 종종 동일한 데이터를 반복적으로 처리하고, 실행하는데(지역성) 그때마다 메모리에서 받아와 처리한다면 

비교적 느린 하드디스크에서 데이터를 받아올때마다 CPU는 기다리는 오버헤드가 발생하게 된다.

그래서 CPU 내부에 일종의 저장 장소(SRAM)를 가지고 캐싱해놓게 되는데 그것을 캐시라 한다.

L1, L2, L3 캐시 메모리등이 있는데

숫자가 작을수록 작고 비싸고, 빠르고 CPU 내부에서 가장 가까운 곳에 위치해 있다고 보면 된다.

그리고 cache를 제어하는 방식에 대해 간단히 알아보자.

write-Through

CPU가 데이터를 사용하면 캐시에 저장되게 되는데, 데이터가 캐시 됨과 동시에 주기억장치 또는 디스크로 기입되는 방식을 지원하는 구조의 캐시이다. 즉, 캐시와 메모리 둘다에 업데이트를 해버리는 방식이다.

다만 업데이트때마다 직접 하면 cost가 비싸므로 

Write buffer라는 구조를 사용해서 CPU 프로세서가 직접 Write 명령을 수행하지 않아 대기하는 시간을 줄여주는 방식으로 작동한다고 한다. (이건 write Back에도 사용 가능)

write-Back

 데이터를 쓸 때 메모리에는 쓰지 않고 캐시에만 업데이트를 하다가 필요할 때에만 주기억장치나 보조기억장치에 기록하는 방법이다.

그럼 캐싱을 사용하면 안될때는 언제일까?

C언어, Java에서는 volatile 명령어로 캐싱을 사용하지 않고 메인메모리에서 접근해서 가져오도록 사용 가능하다.

volatile int num1 = 10;    // 변수를 최적화에서 제외하여 항상 메모리에 접근하도록 만듦

public class SharedObject {
    public volatile int counter = 0;
}

그럼 이것을 언제 사용할까?

캐시는 지금까지 좋다고 글을 썼는데 왜 캐시를 안쓰고 굳이 메인 메모리에서 값을 가져올까?

그 답은 아래 그림처럼 멀티 CPU 상황일경우 임계영역인 데이터의 동기화를 위해 쓴다고 볼 수 있다.

혹은 임베디드 프로그래밍에서 인터럽트 내부에서 메모리의 어떤 값이 수정되었는데 CPU 내부의 캐시는 수정되지 않았을때를 방지하려고 volatile 예약자를 쓴다. 

읽어보면 좋을 글)

https://blog.naver.com/cjsksk3113/222253156868

reference 

https://itgall.com/hardware/232948

https://mangkyu.tistory.com/69

https://nesoy.github.io/articles/2018-06/Java-volatile

https://blog.naver.com/PostView.nhn?blogId=cjsksk3113&logNo=222282586535 

3-way handshake와 4-way handshake는 TCP 프로토콜에서 연결을 시작/종료할때 쓰는 방식이다.

우선 TCP부터 알아보자.

TCP

TCP란 연결 지향적 프로토콜로 데이터패킷을 주고받을때 신뢰성을 보장한다.

그외 특징으로는

• 흐름 제어, 혼잡 제어, 오류 제어
• UDP보다 느린 대신 OSI 4계층(transport)에서 신뢰성 보장
• 파일을 분할해서 전송(MSS)
• 연결형 서비스로 가상 회선 방식을 제공

신뢰성을 보장하는 방식으로는 패킷을 보낸 후, 수신 확인(ACK)를 받는다.

제한시간내에 ACK가 오지 않는다면 패킷이 네트워크 중간에 손실되었다고 가정하고 다시 보낸다.

따라서 해당 방식때문에 신뢰성을 보장하지만 느리다.

(혼잡제어나 패킷을 보내는 방식은  흥미로운 부분이라 나중 글을 관련 부분으로 더 쓸 예정)

3-way handshake

연결하기 위해 두 장치의 논리적 접속을 성립하기 위해 사용하는 연결 확인 방식이다.

3번의 확인을 거친다고 해서 3 way handshake라 부른다

tmi) 4계층(transport)는 host 프로세스와 guest 프로세스 간 양 호스트 종단의 논리적 통신을 보장하고,

3계층(network)는 host와 guest 간 논리적 통신을 보장한다.

접속 시도시 client는 SYN 패킷을 보내 server에 접속 요청을 보낸다.

서버는 SYN 패킷을 받으면 접속이 가능하다는 의미로 client에세 SYN과 ACK 패킷을 보낸다.

client는 서버에세 SYN+ACK 패킷을 받았다면 이제 통신을 시작했다는 의미로 ACK를 보내고,

통신을 시작한다.

SYN (synchronize sequence numbers) - 연결 확인을 위해 보내는 무작위의 숫자값

ACK (acknowledgements) - Client 혹은 Server로부터 받은 SYN에 1을 더해 SYN을 잘 받았다는 ACK

ISN (Initial sequence numbers) - Client와 Server가 각각 처음으로 생성한 SYN

- SYN의 값에 무작위 수를 사용하는 이유?

• Connection을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용할 가능성이 존재한다. 서버 측에서 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 숫자가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있어 이러한 문제 발생 가능성을 줄이기 위해 ISN을 무작위 난수로 사용하는 것이다.

4-way handshake

4-way handshake는 반대로 가상 회선 연결을 해제할때 주고 받는 확인 작업이다.

4번의 확인과정을 거친다고 하여 4 way handshake라고 부른다.

흔히 client가 close를 요청하고, server가 확인하고 닫는다고 알려져 있는데

서버도 close를 요청할 수 있다.

그래서 먼저 4-way handshake를 요청하는 쪽을 Active Closer, 받는 쪽을 Passive Closer라 한다.

과정을 요약하자면

Active closer가 먼저 서버를 닫고 싶다는 FIN 요청을 보내고 FIN-wait 상태에 들어간다.

그럼 Passive closer는 알았다는 ACK를 보내고, close-wait 상태에 들어간다.

그리고 Passive closer는 통신을 종료할 준비가 완료되면 FIN 을 다시 Active closer에 보낸다.

Active Closer는 FIN을 받았으면 time-wait 과정에 들어가고 ACK를 passive closer에게 보낸다. 

passive closer는 ACK를 받으면 통신을 종료한다.

active closer는 time wait상태에서 대기하다가 통신을 종료한다.

time wait는 

먼저 연결을 끊는 (active closer) 쪽에 생성되는 소켓으로, 혹시 모를 패킷 전송 실패에 대비하기 위하여 존재하는 소켓이다.

time-wait가 없다면 패킷의 손실이 발생하거나 통신자 간 연결 해제가 제대로 이루어지지 않을 수 있다.

읽어보면 좋을 글)

3 way handshake의 과정을 악용한 SYN flooding attack(보안)

https://run-it.tistory.com/51

reference

https://seongonion.tistory.com/74

https://tech.kakao.com/2016/04/21/closewait-timewait/

기존 HTTP 프로토콜은 '요청'과 '응답'으로 이루어진 Client-Server Architecture로 구성되어 있다. 

그래서 클라이언트에서 요청을 하게 되면 서버가 응답 하는 방식으로 구성되어 있는데,

기존 정적인 HTML 파일로 구성된 초기 웹 서비스에서는 실시간 양방향 통신을 할 필요가 없으므로

이런 반이중 통신으로 충분히 웹 홈페이지를 만들어나갈 수 있었다.

그런데 웹을 메신저(페이스북 등?)처럼 쓰거나 게임, PWA(웹앱)등 다양한 용도로 사용하기 시작하면서

실시간 양방향 통신 방식이 필요하게 되었는데

pooling, long pooling, streaming 방식은 기존 HTTP 프로토콜 방식에서 양방향 통신(처럼) 작동하려고

노력한 일종의 시도이다.

최근엔 WebSocket이라는 양방향 통신을 제공하는 새로운 프로토콜이 생겼지만

js의 socket.io는 브라우저가 만약 웹 소캣을 지원하지 않으면 pooling, long pooling, streaming 방식으로 자동 치환되서 작동한다고 하니 pooling, long pooling, streaming에 대해 알아놓으면 좋을것 같다.

Pooling 방식

pooling 방식은 가장 간단하다.

주기적으로 서버에 클라이언트가 AJAX request를 보내 발생하는 이벤트를 계속 체크하는 것이다.

주기가 짧아지면 신속하게 받아올 수 있지만, 불필요한 요청/응답 트래픽이 자주 발생한다. 

요청에 대한 서버 부담이 크지 않거나 실시간 메시지 전달이 크게 중요하지 않은 서비스에 적합하다. 

Long Polling 방식 

Long Polling 방식은 실시간 메시지 전달이 중요하지만 서버의 상태 변경이 빈번히 발생하지는 않는 서비스에 적합하다.

Long-Polling 방식은 서버에 요청을 보내고 서버 이벤트가 발생할 때까지 연결을 유지한다. 이 상황에서 이벤트가 발생하면 응답을 받아서 처리하고 그 즉시 또 다른 이벤트를 받기 위해 연결을 맺는 방식이다. 

Long Polling 방식은 보통 서버 응답을 무한정 기다리는 게 아니라 특정 시간이 지나면 해당 요청/응답 트랜잭션을 완료하고 새로이 요청하는 방식으로 구현한다. (이것은 스트리밍 방식도 동일하다)

만약 상태변경이 빈번하고, 그것을 client에 계속 알려주게 된다면 상태 변경 이벤트가 발생할때마다 polling 방식보다 과부하가 더 많이 발생할수도 있다.

streaming 방식

스트리밍 방식은 한 번 요청 후 응답을 완료하지 않고 해당 응답 스트림으로 필요할 때마다 데이터를 전송하는 방식이다.

long polling 방식과 다른 점은 long pooling은 이벤트를 받으면 종료하고 바로 다시 연결을 시도하지만 streaming 방식은 연결을 계속 유지하고 HTTP/1.1 의 Chunked 인코딩 방식을 이용해 이벤트가 발생할때마다 서버에서 클라이언트로 결과를 전송한다.

streaming은 서버의 상태 변경이 매우 잦은 경우 유리하지만 연결을 길게 맺고 있는 경우 연결의 유효성 관리 등의 부담이 발생한다. 

해당 방식들은 설명만 훑어봐도 네트워크로 통신하는데 엄청한 cost가 발생할것이라고 예측할 수 있다.  (유감스럽게도 소켓도 마찬가지다)

로드밸런서나 pub-sub pattern을 사용한 서버의 수평 스케일 확장으로 과부하되는 트래픽을 분산하려고 시도할 수 있다고 까지는 들었다..

같이 읽어보면 좋을 글들)

단방향, 반이중, 전이중 통신

  https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=cashy72&logNo=80013187033 

PWA (웹앱)

https://perfectmoment.tistory.com/1632

Socket.io

https://edu.goorm.io/learn/lecture/557/%ED%95%9C-%EB%88%88%EC%97%90-%EB%81%9D%EB%82%B4%EB%8A%94-node-js/lesson/174379/web-socket%EC%9D%B4%EB%9E%80

reference 

https://d2.naver.com/helloworld/1052