Rest API 설계 검색하다가, HTTP/3가 베타 중(?)이라는 소식에 정리해보는 페이지입니다. 

HTTP/3

HTTP/3 : HTTP(Hypertext Transfer Protocol)의 세번째 메이저 버전으로,
HTTP/1, HTTP/2 와 다르게 UDP 기반의 프로토콜(QUIC(Quick UDP Internet Connection))사용하여 통신하는 프로토콜

TCP(HTTP/1,2) vs UDP

TCP : 신뢰성이 높고 느리며 (느린 이유는 3 way Handshake를 사용하기 때문)

UDP : 신뢰성이 낮고 빠르다

 # 신뢰성 : 전송되는 데이터 패킷들의 순서, 패킷 유실 여부 등을 검사하여 송신 측이 보낸 모든 데이터가 수신 측에 온전하게 전달될 수 있느냐 ? 를 의미한다.

TCP는 클라-서버간의 통신에서 신뢰성을 가지기 위해 노력하지만 결국, 레이턴시가 발생할 수 밖에 없다.(TCP 표준)

레이턴시를 줄이기 위해서는 TCP 표준에서 벗어나는 부분을 조작해서 회선 대역폭을 늘린다 하여도 , 

전송해야하는 데이터의 크기도 점점 커지고 빛의 속도보다 빠르게 전송은 불가능하여 결국에는 한계에 도달하게 된다.

QUIC

TCP 의 레이턴시 한계를 극복하고자 구글이 개발한 UDP 기반의 프로토콜로 

TCP 핸드쉐이크 과정을 최적화하는 것에 초점을 두었다. 

UDP 는 데이터그램 방식의 프로토콜로 

각각의 패킷 간의 순서가 존재하지 않는 독립적인 패킷을 사용하며, 

패킷의 목적지만 정해져있다면 중간 경로는 무시하기 때문에 종단 간의 연결 설정이 필요없다. (= 핸드쉐이크가 없다)

그래서 왜 QUIC은 UDP를 선택했을까?

물론, TCP를 사용하다가 UDP로 바로 갈아탄다고 해도, 모든 이슈가 해결되지는 않지만 

UDP의 커스텀 기능 이용을 통한다면 기존 TCP가 가지고 있는 기능을 모두 구현할 수 있다.

데이터 전송 자체에만 초점이 맞추어 있기 때문에 출발지, 도착지, 패킷 길이, 체크섬(옵션) 만 존재(위 그림)

즉, 어떻게 개발자가 구현하냐에 따라
TCP와 비슷한 수준의 기능을 가질 수 있으며 핸드쉐이크를 사용하지 않을 수 있다는 의미와 같다. 

HTTP/3가 UDP를 사용하여, 기존 프로토콜보다 개선된 점 

1. 연결 설정 시 레이턴시 감소

클라이언트 보낸 요청 -> 서버 처리 -> 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라 하는데, 

위에서 설명한 내용과 같이 QUIC은 첫 연결 설정에서 1RTT만 소요된다. (아래 그림 참조)

즉, 클라이언트가 서버에 신호를 주고 서버에서 응답만 받으면 바로 본 통신이 가능하다는 말과 같다. 

첫번째 핸드쉐이크를 거칠 때
연결 설정에 필요한 정보(+(초키화 키(initial Key) 통해 통신 암호화)와 함께 데이터도 함께 보내기 때문에 가능한 일이다.
(TCP+TLS는 데이터 발송 전 신뢰성있는 연결, 암호화에 필요한 모든 정보를 교환하고 유효성 검사 후 데이터 교환)

2. 패킷 손실 감지에 걸리는 시간 단축

패킷 전송 -> 타임 아웃 -> 패킷 재전송 -> ACK 받음 의 통신을 진행하는데

이때 ACK가 어떤 패킷에서 온건지 확인하기 위해 QUIC는 헤더에 별도의 패킷 번호 공간을 부여하였다. 

해당 번호는 패킷의 전송 순서 자체만을 의미하고 매 전송마다 모노토믹하게 패킷 번호가 증가하기 때문에 패킷의 전송 순서를 명확하게 파악할 수 있다.

3. 멀티플렉싱 지원

여러 개의 스트림을 사용하여 그 중 특정 스트림의 패킷이 손실되었다고 하여도 해당 스트림에만 영향을 미치고 타 스트림에 영향을 주지않아 TCP의 단점인 HOLB(Head of Line Blocking)을 방지할 수 있다. (=HTTP/2와 동일)

4. 클라이언트 IP 변동되어도 연결 유지 

Connection ID를 사용하여 서버와 연결을 생성하는데, 

이때 Connection ID는 랜덤한 값일 뿐 클라이언트 IP와 전혀 무관하기 때문에 클라이언트 IP가 변경되어도 기존 연결을 지속적으로 유지할 수 있다. (=새롭게 연결을 생성할때 핸드쉐이크 과정을 생략할 수 있다는 말과 같다)

기존의 HTTP , TCP 방식에서 벗어날 용도로 쓸 수 있지만

grpc와 비교할 필요가 있을 것 같다 (비슷한 용도지 않나?)

하기에 데이터 PM 직군 공고를 모아두었습니다.

우아한 형제들

[업무내용] 

- 데이터 분석을 통해 인사이트를 도출하고, 프로덕트의 중장기적인 방향성을 수립하는 일 

- 프로덕트의 개선을 위한 가설을 수립하고, 실험/평가를 통해 가설을 검증하는 일 
- 운영 상황에 대한 품질수준 목표를 수립하고 모니터링하여
  개선이 필요하거나 풀어야할 문제들을 발굴하고 과제화 하는 일
- 프로덕트실과 사업부서의 협업 과정에서 의견을 조율하고, 다양한 관점을 프로덕트에 담아내는 일

[지원자격]

- 3~8년의 데이터 분석가 경력이 있는 분 
- 데이터 분석을 통해 의미있는 인사이트를 도출해 본 경험이 있는 분 

- SQL을 활용한 데이터 추출 및 R, Excel 등을 활용한 데이터 분석이 능숙한 분
- 프로젝트를 주도적으로 수행해 성과를 낸 경험이 있는 분

[우대사항]

- Tableau, Redash 등의 툴을 활용해 대시보드를 구현해본 경험이 있는 분

- 숫자 기반의 논리적 추론 결과를 바탕으로 사업과 기술 측면에서 효과적으로 소통할 수 있는 분
- 다양한 부서와 협업하며, 이해와 존중을 바탕으로 유연하게 커뮤니케이션이 가능한 분
- 일의 처리과정을 효율화하고, 체계적인 프로세스를 설계해 본 경험이 있는 분
- 업무적 성장을 위해 지속적인 노력을 기울이며, 팀과 함께 성장하고 싶은 분

원티드

주요업무

• 데이터 수집/가공/제공의 전반에 걸친 로드맵 설계 및 관리
• 데이터 관련 요구사항 커뮤니케이션/분석/정리 및 제품/서비스 설계/연동/트러블슈팅
• 수집되는 데이터의 규격화 및 정합성 관리

자격요건

• 원티드의 기업문화, Wanted Way 와 잘 맞는 분 (https://bit.ly/3kT1BFQ)
• 데이터 분석가/데이터 엔지니어/서비스PM 등의 경력 2년 이상
• 웹/앱 제품 사용 중에 발생하는 유저행동 로그를 기획, 생성, 정합성 검증하여 분석에 활용하거나, 분석가에게 제공하는 업무 1년 이상
• Google Tag Manager등을 활용하여 웹/앱 이벤트를 다수 생성하고, 발생한 로그를 분석툴에서 뿐만 아니라 data warehouse에서 조회한 경험
• 현업에서의 데이터 지표 분석 툴 사용 경험 (Google Analytics, Google Tag Manager, Amplitude, Google Optimize, Appsflyer, Braze, Tableu 등)
• 다수의 데이터 소스에서 수집되는 데이터를 join 가능하도록 가공하거나, 플랫폼을 도입한 경험
• SQL 활용 능력 중급 이상
• 개발자 및 business side와의 커뮤니케이션에 문제가 없으신 분

카카오

데이터 프로덕트 PM은 이전에 없던 새로운 역할입니다. 서비스 PM/서비스 기획자/데이터 분석가/그로스 해커 등으로 알려진 역할을 데이터 프로덕트 개발 단계에 따라 수행하게 됩니다.

• 데이터 분석가로서 데이터 탐색, 코어 알고리즘 구현, 성능 평가 및 사후 분석을 수행
• 서비스 기획자로서 데이터 프로덕트의 컨셉과 목적, 사용자 가치를 정의하고 주요 기능을 설계
• 프로젝트 매니저로서 프로덕트 개발에 필요한 자원과 일정을 관리

위의 업무는 개인의 경험과 역량에 따라 1인 혹은 소규모 팀으로 수행하게 되며, 제품 개발을 위해 디자이너/개발자/QA 등 다양한 전문가들과 소통하고 협업하게 됩니다.

◆지원자격

#필수사항

• 데이터 분석가/퍼포먼스 마케터/서비스 PM 등의 직군에서 최소 1년 이상 업무 경력 보유자
• 로그 수준의 데이터를 다루는 업무 최소 1년 이상 경험자 (데이터 분석가/데이터 엔지니어/서비스 개발자/통계학자 등 세부 분야는 무관)

#우대사항

• 통계/알고리즘/위상수학/네트워크 이론 등 숫자를 다루는 학술 연구 경험 보유자
• 신규 서비스 컨셉 도출부터 런칭까지 전체 프로세스 경험 보유자
• Performance marketing/product optimization 등 실험 기반 업무 2년 이상 경험 보유자
• 다양한 형태의 raw data를 다뤄본 경험 보유자

조이시티

조이시티의 게임 서비스를 이용하는 월간 수백만명의 글로벌 유저들을 대상으로

안정적인 클라우드 인프라를 구축하고 운영하고 있으며 

퍼블리싱 플랫폼을 통해 사용자에게 일관성 있는 편리한 기능과 경험을 제공하고 

데이터 플랫폼을 통해 사내 여러 부서들에 빅데이터 분석환경과 솔루션 제공하여 데이터 기반 의사 결정 활동을 지원하고 있습니다.

담당업무
- 게임 구조에 적합한 지표 로그의 설계 및 적용 
- 설계된 로그를 적용 및 활용하는 유관부서와의 커뮤니케이션, 협업 및 문서화 작업
- 적재된 로그 데이터의 품질 관리 
- 데이터 시각화 관련 업무 

- 데이터 pm(지표 로그 설계 , 적용, 품질관리 및 시각화)

- Google Cloud 의 data Product를 활용한 데이터 처리 고도화

- 데이터 기반의 product 백엔드 개발 
자격요건
- 유관 직무 (PM/ 개발/ 기획/ 분석/ 운영/ 데이터 QA/ 데이터 엔지니어) 중 한 가지 이상의 직무에 대한 경험 
- 데이터와 게임 서비스에 대한 관심 및 이해  
- 여러 유관 조직과의 커뮤니케이션을 원활하게 수행하실 수 있으신 분

우대사항
- 동종 업계 경력 또는 유관 학과 전공자 
- SQL 사용 가능자 또는 개발 경험자 
- 업무나 주변 정리를 체계적으로 하는 것을 즐겨 하시는 분

- 로그 처리 & 분석 경험이 있거나 유관 학과 전공 

- 대용량 데이터 처리 경험

카카오 뱅크

latency(지연 속도)

패킷을 전송하는 곳에서부터 전달받는 곳까지 이동하는 데 걸리는 시간

아래 4가지 지연을 합친 것이 레이턴시 

- 전파 지연(propagation delay / 서버-클라이언트 간 총 레이턴시는 총 이동거리 대비 신호가 이동하는 속도)

- 전송 지연(transmission delay / 패킷의 모든 비트를 내보내는 데 필요한 시간)

- 프로세싱 지연(procession delay / 패킷 헤더 처리 시간)

- 큐잉 지연(queuing delay / 패킷이 처리될 때까지 버퍼 안에서 대기하는 시간) 

 latency는 두 네트워크의 거리가 멀 때 높아짐

bandwidth(대역폭)

물리적으로(혹은 논리적으로) 처리할 수 있는 통신 경로의 최대 데이터 양 => 네트워크통해 전송되는 처리량 

- 초당 비트 수(bps)

- 사용자가 많이 접속된 상태에서는 대역폭이 상대적으로 줄어든다.

- 이상적인 전송량 

throughput(처리량, 출력)

지정된 시간 내에 전송된, 혹은 처리된 전체의 유효한 정보량(=처리량)

- 실제로 전달된 전송량 

더 높은 대역폭과 더 낮은 지연 시간 달성하려면(delivering)?

- 대역폭 : 경제적 여건이 허용되는 한 섬유 링크를 추가한다

- 지연 시간 : 빛의 속도보다 빠르게 전달할 수 없으므로 굴절률을 낮추고 더 빠른 라우터를 개발해도 최대 30% 기대/ 전송하는 곳과 받는 곳 사이의 거리를 줄임으로써 속도를 단축시킬 수 있지만 사회적, 소요되는 비용 등을 생각해보면 .. 

따라서 ,애플리케이션의 성능을 향상시키기 위해서는,
가능한 대역폭과 속도 내에서 프로토콜과 네트워킹 코드를 설계하고 최적화하는 것이 최선.

로드밸런싱?

컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은
컴퓨터 자원들에게 작업을 나누는 것을 의미

로드밸런서(=스위치) 종류

• 운영체제 로드밸런서
  - 물리적 프로세서 간에 작업을 스케줄링
• 네트워크 로드밸런서
  - 사용 가능한 백엔드에서 네트워크 작업을 스케줄링

스위치의 분류

L2 : OSI 레이어 2에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비

L3 : OSI 레이어 3에 속하는 IP주소를 참조하여 스위칭하는 장비

L4 : OSI 레이어 3~4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비
L7 : OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함

로드밸런서 주요 기술

• NAT(Network Address Translation)
  - 사설 ip주소를 공인 IP주소로 변경, 주소변경의 역할
• DSR(Dynamic Source Routing protocol)
  - 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념
• Tunneling
  - 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념
  - 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제

로드밸런싱 Failover

로드밸런서 장애 방지를 위해 이중화 구성 필요

1. vip로 접속을하고 active된 로드벨런서로 연결
2. 장애가 났을경우 standby중인 로드밸런서로 연결
3. 이중화된 로드밸런서에서 Health Check
4. 장애로 여분 로드밸런서가 동작 할 경우 이를 통해 서버 접근

네트워크 로드밸런서 종류

가장 많이 쓰이는 로드밸런서는 아래 2가지

• L4(Transport Layer)
  - Transport Layer(IP+Port) Load Balancing
  - 예시: IP+Port > 213.12.32.123:80, 213.12.32.123:1024
  - TCP/UDP 포트 정보를 분석해 해당 패킷이
    현재 사용하는 서비스 종류(HTTP, FTP, 텔넷, SMTP, POP3, SSL등)별로 PACKET을 처리
  - 장점 : Port기반 스위칭 지원, VIP를 이용하여 여러대를 한대로 묶어 부하분산
  - 주로 Round Robin 방식 사용
• L7(Application Layer)
  - Application Layer(사용자 Request) Load Balancing
  - 예시 : IP+Port+패킷 내용 >
  213.12.32.123:80, 213.12.32.123:1024 + GET/ img/aaa.jpg
  - HTTP, FTP, SMTP Protocol 등의 콘텐츠를 인지하여 원하는 포트로 전달하는 스위치 (콘텐츠 기반 스위칭)
  - 쿠키 기반의 연결 지속성 (클라이언트 IP가 Public IP로 치환되어 전송 -> X-Forwarded-For에 client ip기록)

L4 

동작 방식

1. Clinet(=브라우저) 에서 주소(ex. 111.co.kr) 입력 -> PC Local DNS 서버로 DNS Query -> DNS 서버에서 111.co.kr 관리하는 Authoritative DNS 의 DNS Query, L4의 VIP주소 획득
2. Local DNS가 획득한 VIP 주소를 전송
3. 획득한 DNS를 기반으로 L4 VIP로 http 요청
4. L/B장비는 최적의 서비스 서버를 내부 알고리즘(라운드로빈 등)을 통하여 선별, 요청 전송 ->
   서버 작업 결과를 L/B장비 전송
5. 전달받은 http결과를 L/B장비를 통해 Client에 전송함으로 요청 처리 완료

L4 이슈 

프록시 서버 사용 시 이슈가 발생하며

예를 들면 회사 -> 외부 나갈 시 각 PC의 IP가 아니라 프록시 서버 IP를 갖고 나가기에

여러 사람이 timeout 시간 내에 접속할 경우, 지속적으로 한 서버에만 로드 집중 (외부에서 보면 동일한 사람으로 보임)

=> 해결책 : SSL 이나 타 보안 모듈 이용하여 인증된 특정 사용자에 대해쿠키, DB에 기록 후 해당 사용자에 대해서만 세션 유지 하도록 한다 (단점은 퍼포먼스 저하 및 기타 코스트가 발생)

단점을 해결하기 위해 하기의 L7을 사용. 

L7

동작 방식

aaa.co.kr 접속 -> 서비스 종류(포트별 구분 HTTP, FTP 등) 별로 분기하여 처리 

L4 vs L7

1. 구조 차이 
   • 공통점 : 스위치로 들어온 Packet을 적절한 목적지(주로 네트워크 장비나 클라이언트, 때로는 불필요한 Packet을 Drop시키기도 함)로 전송해줌. 기본적인 기능과 역할은 동일하나 Packet을 분석해 성격과 중요도를 분류하는 Intelligence가 달라서 "적절한 목적지"를 찾아내 해당 Packet을 처리해 주는 능력에 차이가 발생함.
     
     
   • 차이점 
     • L4 : TCP/UDP 포트 정보 분석 통해 해당 패킷 사용하는 서비스 종류에 따라 패킷 처리 
     • L7 : 트래픽 컨텐츠 패턴 분석해 패킷 처리 
2. 기능적 차이 
   * 보다 높은 수준의 Intelligence를 갖춘 스위치일수록 더 정교한 패킷의 부하분산(Load Ballancing)및 Qos기능 가능
   • L7스위치는 다음과 같은 기능을 통해 네트워크 시스템의 보안성 강화가 가능
     1) Dos/SYN Attack에 대한 방어
     2) CodeRed/Nimda등 바이러스 감염 패킷의 필터링
     3) 네트워크 자원의 독점 방지를 통한 네트워크 시스템의 보안성 강화가 가능
     
     

• Google Cloud SDK 설치 필수

Cloud Function 

특징

• 클라우드에서 코드를 실행하는 가장 간편한 방법
• 자동 확장, 우수한 가용성, 내결함성
• 프로비저닝, 관리, 패치 또는 업데이트가 필요한 서버 없음
• 코드를 실행하는 만큼만 지불
• 클라우드 서비스 연결 및 확장
• AWS의 Lambda와 유사함
• 과거엔 자바스크립트(Node.js 런타임)만 있었으나, 최근에 Go(1.11), Python(3.7)도 추가됨 : 2019년 7월 6일 기준
• HTTP 함수와 백그라운드 함수로 나뉨
  • 전자는 HTTP를 통해 함수를 직접 호출
  • 후자는 Google Cloud Pub/Sub의 메세지 또는 Google Cloud Storage 버킷의 변경 사항을 통해 Cloud Functions를 간접적으로 호출

용도 

동작 방식

특정 이벤트 (GCP 서비스 및 HTTP 이벤트) 로 실행되어 동작

Cloud Scheduler

특징

• App Engine 트리거, Pub/Sub을 통해 메세지 보내기, Compute Engine에 HTTP 엔드포인트 호출 등 다양하게 가능
• crontab보다 쉽게 사용 가능
• AWS의 클라우드 워치와 유사
• 월 3개의 Job까지 무료(횟수가 아니고 Job의 개수에 비용 부과 : Job이 20번 돌아도 상관 없음)
• 단, 기본적으로 1분에 최대 60개의 Cron이 가능하고 하루 최대 만건의 CronJob 실행이 가능한데 더 필요할 경우 Quota Request를 해두면 됨

데이터 모델링?

주어진 개념으로 부터 논리적인 데이터 모델을 구성하는 작업. 

설계 순서 

1. 요구사항 파악 -> 2. 개념적 데이터 모델 설계 (ERD 작성) -> 3. 논리 모델링 -> 물리 모델링

모델링 3가지 요소

1. 업무가 관여하는 어떤 것(Things)

2. 어떤 것이 가지는 성격(Attributes)

3. 업무가 관여하는 어떤 것 간의 관계(Relationship)

좋은 데이터 모델의 요소 

1. 완전성

2. 중복배제 

3. 업무규칙

4. 데이터 재사용

5. 의사소통

6. 통합성

데이터 모델링 용어

논리 모델링

• 어떤 정보를 객체화 할 것인가에 대한 규정(엔티티, 엔티티타입, 관계 정의)
  • (EX) 업무를 분석하여 그에 대한 데이터 집합/ 관계를 중점적으로 표현하는 것

물리 모델링 

• 실제 DBMS에서 생성될 테이블을 설계.
• 논리 모델링에서 도출된 각 엔티티 관계에 의해 나올 수 있는 테이블을 설계하거나
  • (EX) many to many 관계에서 도출되는 table, super-sub 관계에서 도출되는 테이블 등)
• 관계에 대한 정의 (cascade 등등), index, 컬럼별 데이터 타입 및 제약 조건 등의 속성 정의 하여 정규화 실행

결과적으로는 모델링의 각종 이슈를 반영한 ERD를 포워딩 했을때 정확하게 데이터베이스가 생성되는 것을 보통 설계가 끝났다고 표현합니다.

ERD

:Entity Relationship Diagram / 데이터들의 관계 도표

ERD 규칙

- 엔티티(Entity) : 정보가 저장될 수 있는 사람, 장소, 사물, 사건 등 독립적인 존재. 즉, 테이블(학생, 과목, 수강, 사원, 부서)

- 두 개체의 관계 _선

- A 테이블의 PK 를 B테이블이 소유하면 -> A : 부모 / B : 자식

- 실선 : 부모 테이블의 PK를 자식 테이블이 가지고 있으며, 자식 테이블의 PK로 사용 시 

- 점선 : 부모 테이블의 PK를 자식 테이블이 가지고 있으나, 자식 테이블의 PK로 미사용 시

Address 개체에서 address_id가 PK로 설정이 되어있는데 Store 개체가 address_id를 가지려 한다면,

이 때 식별자 관계에서는 FK를 PK로 설정(🔑)을 했고,

비식별자 관계에서는 일반 속성(🔹)으로 가지고 온 것을 확인 가능

참고로, FK를 PK로 지정할 때의 

하나의 예시로 자식 테이블에서 할아버지/할머니 테이블을 참조할 때가 있을 수 있음.

상황에 따라 필요할 수도 있고 필요 없을수도?

- 속성(Attribute) : 엔터티의 성질, 분류, 수량, 상태 특성을 구체적으로 나타내는 세부 항목. 즉, 물리적 모델의 컬럼(열)을 말함.

※관계스키마 : 과목(과목코드, 과목내용, 과목명)

학생(이름, 학번, 주소, 전공, 취미)

     (1) 속성유형

     - 단순 속성(Simple Attribute)  : 더 이상 작은 구성원소로 분해 할 수 없는 속성

     - 복합 속성(Composite Attribute) : 몇 개의 기본적인 단순 속성으로 분해 할 수 있는 속성

     - 다중 값 속성(Multivate Attribute) : 다중 값 속성은 한 엔터티에 대해서 여러 개의 값을 갖는 것으로써, 취미 속성

     - 유도된 애트리뷰트(Derived Attribute) : 실제 값이 저장되어 있는 것이 아니라 저장된 값으로부터 계산해서                                                                    얻은 결과 값을 사용하는 애트리뷰트를 말한다.

     (2) 주 식별자 / 비 식별자

     - 주 식별자 : 식별 할 수 있는 유일한(Primary Key) 제약 조건을 갖는속성

       ERD에서 실별자는 속성에 밑줄을 그어서 표현

     예제) ERD

※ 관계스키마 : 사원(사원번호(PK), 이름, 주소, 주민번호)

취미

부서(부서코드(PK), 부서명)

     (3) 관계 (Relation)

     - 엔터티 사이의 연관성을 표현하는 개념

     - 두 개의 엔터티 타입 사이의 업무적인 연관성을 논리적으로 표현

     - ERD에서 엔터티들 사이에 관계

     - 타입은 마름모를 사용하여 표현한 후 그 관계에 연관된 엔터티에 선으로 연결하여 표시

     예제) ERD

      - 소속 관계

    - 수강 관계

     (4) 유형

     1. 카디날리티(Cardinality) : 관계의 대응 엔터티 수라고도 함

     2. 카디날리티 표현방법 : 일대일(1:1), 일대다(1:N), 다대다(N:M)

- 두 개체의 관계 - 선의 끝Cardinality

Cardinality(차수)는 한 개체에서 발생할 수 있는 발생 횟수를 정의하며,

다른 개체에서 발생할 수 있는 발생 횟수와 연관.

1대1관계, 1대N관계, N대N 관계가 있음.

✔️  One-to-One Cardinality

1:1 관계에서는 아래와 같이 표기합니다.

One-to-One Cardinality

✔️  One-to-Many Cardinality

1:N 관계에서는 아래와 같이 표기합니다.

✔️  Many-to-Many Cardinality

N:M 관계에서는 아래와 같이 표기합니다.

Many-to-Many Cardinality

필수참여 조건

'|' 표시가 있는 곳은 반드시 있어야 하는 개체, 'O' 표시가 있다면 없어도 되는 개체

inventory 개체가 없어도 store 개체는 있을 수 있고, store 개체가 없다면 inventory 개체도 있을 수 없음.

개발 진행 중 권한 업무를 위해 필요한 업무 지식이 있어 정리합니다. 

LDAP ( Lightweight Directory Access Protocol ) ?

• 정의 : 네트워크 상에서 어떠한 정보(전화번호, 주소, 조직, 파일, 프린터등 하드웨어 위치, 계정 등등)를 쉽게 찾아 볼 수 있게 하는 소프트웨어 프로토콜
  
  
• 계층구조를 갖는 데이터를 네트워크를 통해서 교환할 수 있게 하는 프로토콜로,
  이는 인증을 위한 중앙 저장소의 프로토콜로 사용하는 것
  
  
• 프로토콜은 표준이기에,
  각 어플리케이션 벤더들이 이를 기반으로 인증 기능(이러한 서비스를 디렉토리 서비스) 구현 
  
• 모든 데이터 항목은 LDAP 서버에 의해 색인화됨 
  
  
• 저장된 정보가 매우 드물게 업데이트되고, 빠른 검색이 필수라면 LDAP 서버가 이상적
  
  
• LDAP 인증 아키텍처 / 구성요소 
  • 인증 옵션
    1. Simple 옵션
       • Anonymous 인증 : client에게 anonymous 상태로 LDAP 에게 전달함
       • Unauthenticated 인증 : 오직 logging 목적으로 client에 대한 접근권한을 주지 않음.
       • Name/Password 인증 : 자격을 기반으로 서버에 대한 접근 권한을 부여함.  (간단하지만, 기밀성 보호가 없는 인증에는 적합하지 않음..)
    2. SASL(Simple Authentication and Security Layer) 옵션
       • LDAP 서버를 다른 인증 매커니즘 (ex) kerberos)와 연계 

AD ( Active Directory ) ?

• 정의 : 다양한 표준화 프로토콜을 사용하여 다양한 네트워크 관련 서비스 제공하는 DB 기반 시스템
  모든 정보와 구성 정보를 중앙 데이터베이스에 저장하여 사용하며, 관리자가 AD를 통해 정책 할당, SW 배포 및 업데이트 쉽게 수행
  
  
• 사용자가 네트워크 리소스에 액세스 할 수 있도록 SSO(Single Sign On) 제공
• 서버 간의 디렉터리에 대한 업데이트 쉽게 동기화
• 확장성이 뛰어나기에 소규모 네트워크 ~ 대규모 네트워크 (수천명) 단위에서도 사용되며, 회사에서 응용 프로그ㅡ램에 표준화 된 액세스를 제공하는데도 사용 
• AD는 LDAP(디렉터리 서비스 위한 프로토콜)을 사용할 수 있고, Keroberos(티켓 기반 매커니즘 통해 인증 수행) 을 사용하여 인증할 수 있음.
  
  
  • kerberos 동작 방식 

  • 

    
    
    1. 사용자가 ID/PW 또는 공개키로 로그인을 시도
    2. 클라이언트는 유저 아이디를 인증서버(AS)로 전송
    3. 인증서버(AS)는 중앙저장소(LDAP)에 유저 아이디 확인 후 존재할 경우 다음을 반환
       • 클라이언트 PW 기반으로 암호화한 티켓 발급 서버(TGS)의 세션키
       • 클라이언트 ID, 주소, 유효기간, TGS 세션키를 TGS 비밀키로 암호화한 티켓발급용 티켓(TGT : Ticket Granting Ticket)
    4. 클라이언트는 다음 두 가지를 티켓 발급 서버(TGS)에게 전송
       • 클라이언트 ID, Timestamp를 TGS 세션키로 암호화한 인증자
       • 티켓 발급용 티켓(TGT) (클라이언트는 TGS 비밀키를 모르므로 복호화 및 조작 불가) 
    5. 티켓 발급 서버(TGS)는 인증자(TGS 세션키로 복호화)와 TGT(TGS 비밀키로 복호화)를 복호화 하여 Client ID가 일치할 경우 아래 두 메시지를 반환
       • 티켓발급서버(TGS) 세션키로 암호한 SS 세션키
       • 클라이언트 ID, 주소, 유효기간, SS세션키를 SS 비밀키로 암호화한 티켓
    6. 클라이언트는 다음 두 메시지를 서비스 서버(SS)로 전달
       • 클라이언트 ID, Timestamp를 SS 세션키로 암호화한 인증자
       • 티켓
    7. 서비스 서버(SS)는 Ticket, 인증자를 복호화하여 Client ID가 일치 할 경우 다음 메시지를 반환
       • Timestamp를 SS세션키로 암호화하여 반환
    8. 클라이언트는 전달받은 timestamp와 자신이 인증자에 담아보냈던 timestamp의 값을 확인하여 일치하는 경우 실제 작업을 시작
       
       동작 방식 참고 : https://ldap.or.kr/?p=1291

아마도~ ad로 개발하지 않을까..

TCP / IP 4계층

TCP/IP : 인터넷과 관련된 다양한 프로토콜의 집합 → OSI 7계층을 4계층으로 단순화한 모델의 의미

TCP/ IP 계층 설명

계층을 4단계로 나눈 이유는 각 계층마다 독립성을 보장하기 위함으로, 

문제가 발생했을 때 해당 계층만 확인하면 된다는 말과 같습니다. 

각 계층의 역할은 다음과 같습니다. 

1. 링크 계층
   • 인터넷 계층에서 형성된 패킷을 전기신호 또는 광신호로 바꾸어 전달
2. 인터넷 계층
   • IP( Internet Protocol ) 프로토콜은 인터넷 계층에 존재하며, 링크 계층을 통해 물리적으로 연결된 호스트 사이에서 패킷의 전달 경로를 결정
   • 즉, IP 프로토콜은 라우팅 방법을 정의하는 것인데, 상위 계층인 전송 계층이 데이터 전달의 신뢰성을 책임진다는 가정하에 어떤 경로로 패킷을 전송할 것인가에 초점
3. 전송 계층
   • 인터넷 계층에서 결정한 목적지까지 실제 데이터를 신뢰성 있게 전송하는 역할
   • TCP와 UDP라는 프로토콜이 존재
4. 응용 계층
   • 응용프로그램들 간의 데이터 통신이 이루어지는 계층
   • 메일보내기( SMTP ), 파일 전송( FTP ), 웹에 접속( HTTP ) 

TCP/ IP 패킷 캡슐화 과정

TCP, UDP 프로토콜

TCP 프로토콜

• 연결 지향 프로토콜
• TCP 프로토콜에서는 데이터 송수신을 위해 클라이언트와 서버의 소켓이 연결되어 있어야 하며, 데이터가 유실되면 데이터 재전송을 요청함으로써 신뢰성을 보장
• 즉, 신뢰성 있는 데이터 전송이 가능하다는 장점으로 인해 HTTP, FTP, TELNET 등 대부분의 응용 계층 프로토콜의 전송 계층

UDP 프로토콜

• 비연결 지향 프로토콜입니다.
• 전송한 데이터가 잘 전달이 되었는지 확인하지 않고 단지 데이터만 보낸다는 점이 TCP와의 차이점
• 즉, 신뢰적이지 않으며( 비신뢰성 ), 대신 속도가 빠르다는 장점 존재. → 신뢰성 추가를 위해 헤더에 checksum 존재
•  UDP 프로토콜은 음악이나 동영상 스티리밍(streaming)과 같은 서비스에 적합

TCP 연결 / 해제 

TCP / IP 프로토콜은 OS 안에 라이브러리로 내장되어있고, 

연결을 위한 3 way handshake(클라이언트와 통신하기 전 3번의 악수)와 

종료를 위한 4 way handshake 의 과정들은 OS 에서 알아서 처리

# Socket : 응용 계층이 하위 계층인 TCP/IP 계층의 역할을 몰라도 되도록 TCP/IP 역할을 감춰주는 역할,
                 즉 소켓은 프로그래머가 커널 내부를 몰라도 TCP/IP 사용할 수있도록 하는 프로토콜 인터페이스

TCP 연결 : 3 way handshake

1. 클라이언트에서 서버에 연결 요청하는 SYN 데이터 전송
2. 서버가 SYN을 받으면 ACK+ SYN 를 클라이언트쪽에 포트를 열어달라는 데이터 전송
   • 서버 상태 : LISTEN → SYN_RCV 로 상태 변경
3. 클라이언트에서 서버로부터 해당 데이터를 받으면, 포트를 열고 확인을 위해 서버에 ACK 데이터 전송
   • 클라이언트 상태 : ESTABLISHED 상태로 변동
4. ACK 데이터를 받은 서버 역시 ESTABLISHED 상태로 변경되면서 클라이언트와 서버 연결 

TCP 종료 : 4 way handshake

1. 초기 상태 
   • 클라 : ESTABLISHED
   • 서버 : ESTABLISHED 
2. 클라이언트가 통신을 종료 하자는 FIN 데이터 전송 → 자신의 상태 종료 요청 후 ACK를 기다린다는 의미의 FIN_WAIT_1으로 상태 변동
3. 서버는 확인 후 클라이언트에 ACK 데이터를 보내며 애플리케이션 소켓 닫음
   • 서버 : 자원을 정리하는 데 시간이 소요되므로, CLOSE_WAIT 상태로 변동
   • 클라 : 서버로 부터 응답 올때 까지 기다린다는 FIN_WAIT_2 상태로 변동
4. 애플리케이션에서 소켓을 닫으면, 서버 → 클라이언트로 FIN 데이터 전송
   • 서버 : 클라로부터 받을 마지막 ACK 기다리는 LAST_ACK 상태로 변동
5. 클라이언트는 FIN 데이터 받으면 TIME_WAIT 상태로 변동되며 서버에서 ACK 데이터 보냄
   • 클라 : CLOSED
6. 서버 역시 ACK를 받았기 때문에 CLOSED

해당 과정에서 FIN_WAIT_1, FIN_WAIT_2  의 상태가 시간이 지나면 자동 TIME_OUT 되지만, 너무 그 시간텀이 길어서 많은 수의 소켓이 늘어난다면 

메모리 부족으로 소켓을 오픈하지 못하기 때문에, 

TIME OUT 시간을 적절히 조절할 필요가 있습니다. → 유닉스 환경에서 NDD 명령어 통해 확인 가능 

예시)

-- time_wait 종료 시간 확인

ndd -get /dev/tcp tcp_time_wait_interval



-- time_wait 종료 시간 30초로 설정

ndd -set /dev/tcp tcp_time_wait_interval 30000





-- fin_wait_2 타임 아웃 시간 확인

ndd -get /dev/tcp tcp_fin_wait_2_timeout



-- fin_wait_2 타임 아웃 시간 5분으로 설정

 ndd -set /dev/tcp tcp_fin_wait_2_timeout 300000

IP 확인

리눅스 - nslookup 명령어 사용

질의 방법

자주 사용되는 DNS Record type

-type의미

리눅스 명령어 예시

원하는 도메인 ip 확인 예시

C:Users780-32bit>nslookup simplexi.com

서버: ad-pdc.intra.simplexi.com

Address: 192.168.xx.90

이름: simplexi.com

Address: 222.122.xxx.6



C:Users780-32bit>nslookup www.simplexi.com

서버: ad-pdc.intra.simplexi.com

Address: 192.168.xx.90

이름: www.simplexi.com

Address: 222.122.xxx.6



C:Users780-32bit>nslookup mail.simplexi.com

서버: ad-pdc.intra.simplexi.com

Address: 192.168.xx.90

이름: mail.simplexi.com

Address: 203.231.xxx.10

특정 네임서버 통해서 ip 정보 확인

C:Users780-32bit>nslookup simplexi.com ns.dacom.co.kr

서버: ns.lgdacom.net

Address: 164.124.101.2

권한 없는 응답:

이름: simplexi.com

Address: 222.122.xxx.6



C:Users780-32bit>nslookup mail.simplexi.com kns.kornet.net

서버: kns.kornet.net

Address: 168.126.63.1

권한 없는 응답:

이름: mail.simplexi.com

Address: 203.231.xxx.10