프로찍먹러

프로토콜

• 통신에 참여하는 주체간에 데이터를 주고받는 과정을 정의한 규칙
• 효율성, 호환성을 위해 정해놓은 규칙으로, 다수의 벤더와 관련 제품군 등장 및 이용 가능

OSI 7계층과 TCP/IP 프로토콜

두 모델의 공통점

• 두 호스트 사이에서 이루어지는 네트워킹을 계층구조로 나눈것임
• 각 계층에서 일어나는 일들을 모듈화 가능

두 모델의 차이점

• OSI의 7,6,5층을 TCPIP에서는 한 층으로 퉁침
• 이 측면에서는 OSI가 문제해결과 성능개선이 더 좋음

https://velog.io/@sj_dev_js/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-OSI-7%EA%B3%84%EC%B8%B5%EC%9D%84-%EC%99%9C-%EB%B0%B0%EC%9A%B8%EA%B9%8C

1계층 : 물리계층

• 상위계층(2계층)에서 받은 비트 스트림을 상대방의 물리계층으로 보내는 기능
• 단지 데이터만 전달함
• 전송단위(PDU)는 비트
• 프로토콜: Modem, Cable, Fiber, RS-232C
• 장비: 통신 케이블, 허브(리피터)

리피터란?

• 전선(케이블)이 길수록 전기신호가 약해지는데 이를 증폭해줌
• 지금은 네트워크 장비에 기본적으로 리피터기능이 탑재돼있기에 따로 리피터를 사용하지 않는다고함

허브란?

• 컴퓨터 신호를 여러개의 다른 선으로 분산시키는 장치를 총칭함
• 리피터는 1대1 연결만 가능
• 허브는 다대다로 연결 가능
• 얘도 리피터와 마찬가지로 전기신호의 증폭을 위해 사용
• CSMA/CD 방식을 적용하기에 여러 장비에서 동시에 데이터를 전송하지는 못함 (A장비에서 데이터 전송중일때 B도 전송하면 충돌발생)
• 특정 포트로만 데이터를 전송할수없고 모든 포트에 데이터를 전송하게 되기에 과도한 트래픽, 충돌 발생 -> 스위칭 허브 사용(레이어2에서 사용)

2계층 : 데이터링크 계층

• 네트워크 기기들 사이에서 데이터를 전송하는 역할
• 프레임이라는 단위
• 3계층에서 내려준 패킷을 받아 헤더와 테일에 각각 주소와 제어정보를 추가함
• 1계층을 통해 송수신되는 데이터의 전송 오류를 감지하여 재전송도 해줌
• 맥주소를 가지고 통신
• 맥주소란 컴퓨터의 물리적인 주소
• ip주소가 시작점과 끝점의 주소라면 맥주소는 중간중간지점들의 주소
• ex) 서울에서 부산으로 편지를 보낸다면 ip주소는 서울, 부산이 되고 맥주소는 서울우체국, 부산우체국1 등등이 된다
• 프로토콜 : 이더넷, MAC, PPP, ATM, LAN, Wifi
• 장비: 브릿지, 스위치

브릿지란?

• 네트워크 세그먼트를 연결해주는 장치
• 스위치가 나오기 전까지 브릿지가 주로 사용됐다고 함
• LAN과 LAN을 연결하거나 컴퓨터 그룹(세그먼트)를 연결해주는 기능
• 브릿지의 다섯가지 기능
  • Learning : A라는 호스트가 데이터를 주면 A의 맥주소를 브릿지의 맥주소 테이블에 저장
  • Flooding : 목적지 정보가 맥주소 테이블에 없다면 모든 포트로 데이터 전파
  • Forwarding : 목적지 정보가 맥주소 테이블에 있다면 해당 포트로 전송, 없다면 플로딩
  • Filtering : 브릿지를 건너지 못하게 막는 기능
  • Aging : 맥주소 테이블 데이터를 자동으로 삭제하는 일종의 TTL

스위치란?

• 브릿지랑 비슷
• 브릿지와의 차이는 -> 스위치는 하드웨어, 브릿지는 소프트웨어 방식이기에 스위치가 속도가 더 빠르다
• 브릿지보다 포트수 많음, 포트별 속도지정이 가능
• 여러모로 브릿지의 상위호환이기에 브릿지대신 스위치 사용한다
• 스위치의 종류
  • L2스위치 : 기본적인 스위치. 데이터링크 계층에서 사용, 맥주소 기반으로 패킷 전달, 가격저렴
  • L3스위치 : L2스위치에 라우팅 기능이 추가됨, IP 정보를 보고 스위칭한다, 기능적으로 라우터와 똑같지만 라우터는 소프트웨어방식이기에 하드웨어 방식인 L3스위치가 더 빠르고 저렴
  • L4스위치 : 4계층 프로토콜인 TCP/UDP를 사용, IP와 포트 기반으로 스위칭, L4스위치에는 로드밸런싱 기능이 있음
  • L7스위치 : L4스위치와 기능,역할이 동일하나, L7스위치에서는 페이로드를 분석하여 패킷 처리. 페이로드를 분석함으로서 Dos, SYN Attack등 네트워크 공격 방어 가능. 가격 비쌈

3계층 : 네트워크 계층

• 데이터그램이 가능 경로를 설정해줌
• 데이터그램이란 네트워킹에서 데이터 전송의 단위, 그냥 데이터로 이해하면 될듯?
• 라우팅 알고리즘을 통해 최적의 경로를 선택
• 데이터를 목적지까지 안전하고 빠르게 전달하는게 중요 -> 이거를 라우팅이라고 한다
• 전송단위 : 패킷
• 프로토콜 : IP, ICMP
• 장비 : 라우터, L3스위치

라우터란?

• 네트워크에서 데이터 전송의 최적 경로를 찾아서 전송해주는 장비
• L3와 기능 비슷, 하지만 소프트웨어 방식이기에 더 비싸고 느리고 초기설정 어려움
• 라우터의 종류
  • 코어라우터, 센터라우터, 엣지라우터, 브로드밴드라우터, 핫스팟라우터, ISP라우터

4계층 : 전송계층

• 발신지 - 목적지간 제어와 에러 관리
• 패킷의 전송이 유효한지 확인하고 재전송을 하는 등 신뢰성있는 통신 보장
• 오류검츨, 흐름제어, 패킷 생성, 전송, 재전송
• 단위 : 세그먼트
• 프로토콜 : TCP, UDP, ARP, RTR
  • 대부분 TCP
  • ACK을 통해 신뢰성있는 전송
  • UDP는 비연결성, 비신뢰성임. 수신자가 잘 받든말든 일단 데이터보냄, 에러나면 어플리케이션에서 알아서 처리해야함, 하지만 빠름, 실시간 서비스에서 적절
• 장비: 게이트웨이, L4스위치

5계층 : 세션계층

• 통신장치간의 상호작용을 설정, 유지, 동기화
• 동시 송수신, 반이중, 전이중
• 네트워크상 양쪽 연결을 관리하고 연결을 지속시켜줌
• TCP/IP 세션을 만들고 없애는 역할

6계층 : 표현계층

• 송신, 수신측 사이에서 데이터 형식을 정해줌(jpg, png등)
• 7계층으로부터 받거나 주는 데이터의 인코딩, 디코딩이 이루어지는 계층
• 프로토콜 : JPG, MPEG, SMB 등

7계층 : 응용계층

• 사용자와 상호작용
• 응용 SW
• 프로토콜 : HTTP, DNS, Telnet, FTP등

참고:

https://youtu.be/8kI5OIrfZtI?si=-gZMcolC217Aht7y

https://backendcode.tistory.com/167

https://heisyoung.tistory.com/52

메모

더보기

계층형 모델 (OSI 7Layer)

- 통신 장비들끼리 호환되도록 표준을 만든것

- 데이터가 전달되기위한 과정을 계층화 (ISO, DoD)

- 7단계중 한 곳에 이상이 생기면 다른 단계의 장비나 소프트웨어를 건들지 않아도 고칠 수 있다

- 복잡도를 줄이고 모듈화를 통한 기술발전, 호환성, 상호독립성

- 이 규칙을 따라야 네트워크 장비로서 다른 장비와 상호작용 가능

 

계층별 PDU(Process Data Unit)

1계층 - 비트

2계층 - 프레임

3계층 - 패킷

4계층 - 세그먼트

 

 

어플리케이션층에서 만들어진 data가

tcp udp 정보를 담은 세그먼트가 되고,

ip정보가 담긴 헤더가 붙은 패킷이 되고,

패킷의 정보에 이더넷 프로토콜의 정보를 담아서 프레임이되고

이 프레임이 전기적 신호로 전달됨

 

인캡슐레이션

디캡슐레이션

 

 

Encapsulation / Decapsulation

- 어플리케이션에서 만들어진 데이터가 해당 디바이스에서 네트워크를 통해 전달되는 과정

- 각 계층에서 동작하는 프로토콜별로 정보(헤더)가 추가되거나 벗겨지는 과정

 

 

어플리케이션

프레젠테이션

세션

...

 

내려가며 헤더가 붙음 -> 인캡슐레이션

이 헤더를 하나씩 떼어가며 정보를 읽는것 -> 네트워킹

 

 

어플리케이션 - 데이터 생성

- 구글검색

 

트랜스포트 - 세그먼트 생성 (세그먼트 = 포트정보+데이터)

- 디포트 : http이기에 80

- 소스포트

- 데이터

 

네트워크 레이어 - 패킷 생성 (패킷 = 세그먼트 + ip정보)

- dip(dns를 통해서 google.com의 ip를 획득하는 과정)

- 소스ip(내 ip)

- 데이터(세그먼트)

 

데이터링크 레이어 - 프레임 생성 (프레임 = 이더넷헤더 + 세그먼트)

- 이더넷헤더 추가

- dMAC(나와 연결된 같은 네트워크에서 어떤놈이 이 데이터를 받을지) (넥스트 홉)

- 소스MAC(내 기기의 MAC))

- 세그먼트

 

넥스트홉ip를 알아내는 과정을 라우팅이라고 함

라우팅 테이블을 룩업함

 

d는 destination(어디로 보낼지에 대한)

dip는 dns를 통해서 

dMAC은 라우팅과 ARP를 통해서

 

라우터는 dip를 보고 어디로 보내야할지를 결정 - 라우팅 테이블을 통해서

 

 

네트워크에서 출발지 - 목적지로 데이터를 전송할때 사용하는 통신방식

• Unicast
  • 1대1 통신
  • 대부분 이거

• Broadcast
  • 1대 N통신, 동일 네트워크에 존재하는 모든 호스트가 목적지
  • 유니캐스트로 통신하기 전 상대방의 정확한 위치를 알기위해 사용
  • 목적지가 전체이기에 과도하게 사용하면 성능저하

• Multicast
  • 1대 그룹, 하나의 출발지에서 다수의 특정 목적지
  • 사내 방송같이 단방향으로 다수에게 동시에 같은 내용을 전달할때 사용

• Anycast
  • 1대1 통신(동일 그룹 내의 1개 호스트), 다수의 동일 그룹중 가장 가까운 호스트에서 응답
  • 유니캐스트와 동일하지만 애니캐스트는 통신 가능한 다수의 후보군이 있다
  • IPv4에서는 일부기능 구현
  • IPv6에서는 모두 구현 가능

출처:

https://rooftoproom-whale.tistory.com/14

docker의 postgres에서 psql로 접속하려했더니 위와같은 권한에러가 발생했다.

docker compose yml에서 docker-compose up 할 때 

    environment:
      # PostgreSQL 계정 및 패스워드 설정 옵션
      PGUSER: my-user

이처럼 키값을 PSUSER로 설정해줘야한다

원래는 POSTGRES_USER였음

https://stackoverflow.com/questions/60193781/postgres-with-docker-compose-gives-fatal-role-root-does-not-exist-error

docker system prune --all --force

분산락이란?

여러 서버에서 공유된 데이터를 제어하기 위해 사용하는 기술

이 이미지처럼 하나의 자원(상품 재고)에 여러 서버에서 동시에 접근을 한다면 데이터 정합성이 깨질 수 있다.

이때 레디스를 사용해서 잠금(락)을 걸어주어 한번에 하나의 서버에서만 자원에 접근하도록 제한하는것이 분산락이다.

주문서버와 정산서버가 거의 동시에 레디스에 Lock을 시도했지만 주문서버가 성공했고, 주문서버가 상품재고에 요청을 보낼 수 있는 자격이 생긴것이다.

적용 상황

다음 그림과 같이 멀티 인스턴스 환경에서 각 인스턴스마다 DB에 어떤 트랜잭션을 날리는 스케줄러가 동작하고있을 때

READ라면 상관없겠지만 DB의 상태를 변경시키는 트랜잭션을 동시다발적으로 날리면 우리가 예상한 결과와 달라질 것이다.

이 코드처럼 10초마다 디비의 count를 1씩 증가시켜주는 스케줄러가 있다고 해보자.

pm2를 사용하여 로컬에서 10개의 인스턴스를 실행시켜보면

이렇게 스케줄러가 한 번 실행될때마다 10개의 인스턴스에서 각각 count를 1씩 더하는 쿼리가 발생하게되고 결과적으로 한번에 10씩 count가 더해진다

적용하기

레디스를 추가하여 Lock을 획득한 인스턴스만 쿼리를 발생시키도록 제한해보자

레디스로 분산락은 이렇게 구현하였다.

setLock은 레디스 저장소에 key-value 하나를 추가해주는 것이고 이 동작이 10개의 인스턴스에서 동시에 실행되겠지만 그 중에서 가장 빠른 인스턴스만 성공할 것이고 나머지 9개의 인스턴스는 락에 실패할 것이다. (이미 존재하는 key이기에)

모종의 이유로 delLock()이 동작하지 않을 수 있기에 EX 설정을 하여 자동으로 expire 되도록 내부에 설정해주었다.

NX설정은 이미 key가 존재하면 생성을 막도록 하는 설정이다.

아무튼 10개의 인스턴스에서 락에 성공한 인스턴스만 쿼리를 실행하는 것을 볼 수 있다.

Typeorm 문서에는 save() 메소드를 이렇게 설명한다

• 엔티티가 이미 존재하면 update
• 엔티티가 존재하지 않으면 insert

엔티티가 이미 존재하는지 어떻게 알까?

그렇다.

save() 메소드를 호출하면 select쿼리를 한번 실행시키고 그 뒤에 insert나 update 쿼리를 실행시킨다.

즉, 쿼리가 두번 나간다.

요런 코드를 돌려보자

[1]에서 콘텐츠 엔티티를 저장하고

[2]에서 저장한 엔티티를 조회하여 수정하고

[3]에서 수정한 엔티티를 다시 저장해보자

쿼리는 어떻게 발생할까?

[1]에서는 기존에 없던 저장돼 있지 않던 엔티티이기에 select 쿼리 이후 insert쿼리가 발생한 것을 볼 수 있다.

[3]에서는 해당 엔티티의 pk기준으로 이미 존재하는 엔티티이기에 select 쿼리이후 update 쿼리가 발생한 것을 볼 수 있다.

근데 이제 select 쿼리는 계속 발생한다는 말인데 만약 저장하거나 수정해야 할 데이터가 많다면 각 쿼리마다 select 쿼리가 발생할텐데 상당히 비효율적이 아닐수가 없다.

직접 update() 메소드나 insert() 메소드를 사용하면 이런 문제를 개선할 수 있다.

얌전하게 하나의 쿼리만 발생했다.

물론 save() 메소드가 주는 편리함을 포기하고 사용하는 것이므로 update나 insert를 할 때 디비에 중복되는 데이터가 이미 존재하는지 확인된 상태에서 사용하는것을 권한다. save()는 그냥 무지성으로 사용해도 pk가 겹치는게 아닌 이상 의도한대로 동작은 했는데 update(), insert()는 아니다.

토큰이란 몇몇 공통 규약을 따르는 스마트 컨트랙트다. 공통 함수집합이 있다. transfer()나 balanceOf()같은

ERC20토큰들이 똑같은 함수 집합을 공유하기에 이 토큰들은 똑같은 방식으로 상호작용 가능하다

내가 ERC20 토큰과 상호작용하는 앱을 만들면 모든 ERC20 토큰과 상호작용이 된다.

이것의 한가지 예시로는 거래소가 있다.

ERC20 토큰을 상장할때 실제로는 거래소에서 통신 가능한 또 하나의 스마트 컨트랙을 추가하는 것이다.

ERC20은 교체 가능

ERC721은 교체 불가능

contract SatoshiNakamoto is NickSzabo, HalFinney {
  // 이렇게 다중 상속 가능
}

전송

ERC721 스펙에서는 토큰을 전송할 때 2개의 다른 방식이 있다.

function transfer(address _to, uint256 _tokenId) public;
function approve(address _to, uint256 _tokenId) public;
function takeOwnership(uint256 _tokenId) public;

1. 첫 번째 방법은 토큰의 소유자가 전송 상대의 address, 전송하고자 하는 _tokenId와 함께 transfer 함수를 호출하는 것.
2. 두 번째 방법은 토큰의 소유자가 먼저 위에서 본 정보들을 가지고 approve를 호출하는 것. 그리고서 컨트랙트에 누가 해당 토큰을 가질 수 있도록 허가를 받았는지 저장한다. 보통 mapping (uint256 => address)를 쓴다. 이후 누군가 takeOwnership을 호출하면, 해당 컨트랙트는 이 msg.sender가 소유자로부터 토큰을 받을 수 있게 허가를 받았는지 확인한다. 그리고 허가를 받았다면 해당 토큰을 그에게 전송한다.

transfer와 takeOwnership 모두 동일한 전송 로직을 가지고 있다.

순서만 반대인 것(전자는 토큰을 보내는 사람이 함수를 호출하고, 후자는 토큰을 받는 사람이 호출하는 것).

safeMath

function add(uint256 a, uint256 b) internal pure returns (uint256) {
  uint256 c = a + b;
  assert(c >= a);
  return c;
}

assert는 조건을 만족하지 않으면 에러를 발생시킨다는 점에서 require와 비슷하다. assert와 require의 차이점은, require는 함수 실행이 실패하면 남은 가스를 사용자에게 되돌려 주지만, assert는 그렇지 않다는 것이다. assert는 일반적으로 코드가 심각하게 잘못 실행될 때 사용하네(like, uint 오버플로우의 경우)

https://cryptozombies.io/ko/course

payable

payable 함수는 이더를 받을 수 있게하는 특별한 함수 유형.

일반적인 웹 서버에서 API 함수를 실행할 때에는, 우리는 함수 호출을 통해서 US 달러를 보낼 수 없다. 물론 비트코인도.

하지만 이더리움에서는, 돈(이더), 데이터(transaction payload), 그리고 컨트랙트 코드 자체 모두 이더리움 위에 존재하기 때문에, 우리가 함수를 실행하는 동시에 컨트랙트에 돈을 지불하는 것이 가능하다.

contract OnlineStore {
  function buySomething() external payable {
    // 함수 실행에 0.001이더가 보내졌는지 확실히 하기 위해 확인:
    require(msg.value == 0.001 ether);
    // 보내졌다면, 함수를 호출한 자에게 디지털 아이템을 전달하기 위한 내용 구성:
    transferThing(msg.sender);
  }
}

여기서, msg.value는 컨트랙트로 이더가 얼마나 보내졌는지 확인하는 방법.

컨트랙트에서 이더를 꺼내는 방법

contract GetPaid is Ownable {
  function withdraw() external onlyOwner {
    owner.transfer(this.balance);
  }
}

this.balance는 컨트랙트에 저장돼있는 전체 잔액을 반환

한 가지 활용법으로는 구매자와 판매자가 존재하는 컨트랙트에서, 판매자의 주소를 storage에 저장하고, 누군가 판매자의 아이템을 구매하면 구매자로부터 받은 요금을 그에게 전달할 수도 있다

seller.transfer(msg.value)

난수

keccak256을 통해 난수를 만들수있지만 이 방법은 정직하지 않은 노드의 공격에 취약하다.

우리가 이더리움에서 컨트랙트의 함수를 실행하게되면 이를 하나의 트랜잭션(transaction)으로서 네트워크의 노드 하나 혹은 여러 노드에 실행을 알리게 된다. 그 후 네트워크의 노드들은 여러 개의 트랜잭션을 모으고, "작업 증명"으로 알려진 계산이 매우 복잡한 수학적 문제를 먼저 풀기 위한 시도를 하게 된다. 그리고서 해당 트랜잭션 그룹을 그들의 작업 증명(PoW)과 함께 블록으로 네트워크에 배포하게 된다.

이것이 우리의 난수 함수를 취약하게 만든다

내가 만약 노드를 실행하고 있다면, 나는 오직 나의 노드에만 트랜잭션을 알리고 이것을 공유하지 않을 수 있다.

우리가 동전 던지기 컨트랙트를 사용한다고 할 때 해보자. 내가 동전을 던져서 당첨이 되지 않았다면 내가 풀고 있는 다음 블록에 해당 트랜잭션을 포함하지 않을 수 있다.  당첨이 된 경우에만 선택적으로 트랜잭션을 다음 블록에 추가시키면 된다.

이 짓을 무한대로 반복할 수 있기에 문제.

개선하는 방법은 oracle(이더리움 외부에서 데이터를 받아오는 안전한 방법 중 하나)을 사용해서 블록체인 밖에서 안전한 난수를 만드는 방법

https://cryptozombies.io/ko/course