1. 웹 소켓 업그레이드 요청

1 GET /ws HTTP/1.1 2 Host: server.example.com 3 Upgrade: websocket 4 Connection: Upgrade 5 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 6 Origin: http://localhost:8080 7 Sec-WebSocket-Protocol: ws 8 Sec-WebSocket-Version: 13




 |Upgrade|
- 반드시
 " websocket" 이라는 값을 가진다.
-
만약 이 값이 없거나 다른 값이면 cross-protocol attack 이라고 간주하고 WebSocket 접속과정을 중지한다.


 |Connection|
- 반드시
 "Upgrade " 라는 값을 가진다.

만약 이 값이 없거나 다른 값이면 cross-protocol attack 이라고 간주하고 WebSocket 접속과정을 중지한다.


|Host|
-
클라이언트가 WebSocket으로 접속을 시도하는 hostname. 만약 한 서버에서 여러 host를 서비스하고 있을 경우 각 host에 따라 다른 처리를 하기 위해 필요하다.

- 만약 이 값이 없거나 서버에서 서비스하고 있는 hostname이 아닐 경우 cross-protocol attack 이나 DNS rebiding attack 이라고 간주한다.


|Origin|
- WebSocket
접속을 요청한 페이지의 scheme, hostname, port(만약 기본포트가 아닐 경우에만 포함). WebSocket 서버에서 요청 페이지에 따라 다른 처리방식을 각각 결정하기 위해 필요한 정보이다.


|Sec-WebSocket-Protocol|

- 클라이언트가 요청하는 여러 서브프로토콜을 의미한다. 공백문자로 구분되며 순서에 따라 우선권이 부여된다. 서버에서 여러 프로토콜 혹은 프로토콜 버전을 나눠서 서비스할 경우 필요한 정보이다.


|Sec-WebSocket-Key1| |Sec-WebSocket-Key2|


- 서버의 handshake 를 위한 정보를 계산하기 위해 필요한 값이다

-  UUID 32byte 값을 Base64 인코딩을 통해 변환한다.

- 매직키로 불린다.





2. 웹 소켓 업그레이드 응답

1 HTTP/1.1 101 Switching Protocols 2 Upgrade: websocket 3 Connection: Upgrade 4 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 5 Sec-WebSocket-Protocol: chat


- 요청에 성공하면 101 응답인 Switching Protocols 값을 받는다.

- 필수 요청 헤더 값(Upgrade, COnnection) 에 대한 정보를 리턴한다.


- Sec-WebSocket-Accept 에 요청 매직키를 포함하여 리턴한다.


Sec-WebSocket-Accept 검증 값 만들기  


1) Sec-WebSocket-Key 값 디코딩해서 검증한다.

2) GUID(258EAFA5-E914-47DA-95CA-C5AB0DC85B11)를 붙여서 문자열을 만든다.

3) GUID가 붙은 Key를 SHA1 HASHING -> Binaray 형식으로 만든다.

4) Binary SHA1 Hashing 된 Key 값을 다시 Base64 Encoding 을 거친다.



자바 소켓으로 websocket 프로토콜 구현 테스트



WebSocket Framing Data




1. FIN : 1 bit , 뒤에 오는 데이터가 더 있는지 확인하기 위한 패킷.(긴데이터를쪼개서보낼때사용)


2. RSV : 3bit , 체크하지 않음


3. OPCODE : Frame의 종류, 2바이트


continue = 0x0
text = 0x1
binary = 0x2
close: 0x8
Ping: 0x9
Pong: 0xA


  1. MASK : 1bit, 클라이언트가 서버로 보낼때는 항상 1의 값.

  2. payload len :크기가 126보다 적으면 payload length가 값을 나타낸다.

    126 이면 뒤에 따라오는 16 bits가  값이고 length는 길이를 의미. 0 ~ 0xFFFF(65536) 값 가능.

    127 이상이면, 64 bits Payload data length. 0 ~ 0xFFFFFFFFFFFFFFFF

  3.  Masking-key : 4 bytes, MASK가 1값이면 표시하고 아니면 표시하지 않는다.

  4. Payload Data :  연결이 설정된 경우, 사용자 지정 확장 데이터가 포함





구축시 주의사항

  1. HOL Blocking (Head-of-Line Blocking)

- 네트워크 상황에서 같은 큐의 앞선 데이터의 지연이 발생한 경우
 ex) 하나의 데이터는 네트워크 상황에서 여러번 쪼개서 보내질 수 있는데, 앞서 보낸 데이터가 문제가 있을 경우 뒤에 있는 데이터는 지연이 발생 혹은 탈락할 요소가 있다.

- 회피 방법 : 패킷 계산(packet length), header 압축 등

 
   2. CORS (Cross Origin Resource Share)
- 웹 브라우저의 외부 도메인 서버와 통신하기 위한 스펙
- 회피 방법 : 클라이언트는 preflight 요청, 서버는 이에 따른 요청 허용 및 응답 헤더 추가









참조

https://adrenal.tistory.com/16

https://hpbn.co/websocket/
https://tools.ietf.org/html/rfc6455


'Architecture & Protocol' 카테고리의 다른 글

HTTP2 Protocol 분석  (0) 2019.04.16
12 요소 애플리케이션 방법론  (0) 2019.02.21
서비스 지향 아키텍쳐(SOA)  (0) 2018.12.30
마이크로서비스 아키텍처(MSA)  (0) 2018.12.02


django framework


파이썬 기반의 무료 오픈소스 웹 애플리케이션 프레임워크(Open Source Web Application Framework)


- 빠른 개발, 쉬운 구축 (개발 비용감소)


- 확장성, 보안


- 기본적인 admin 기능의 구현



-하지만 좋지 않은 성능




Architecture


- MVC 패턴 기반 MVT 아키텍처






  1. Model : data 구조 혹은 스키마

  2. View : MVC 의 Controller에 해당 

  3. Template : MVC의  view에 해당








Structure








  • sample2 : root project

  • managy.py : django와 상호작용하는 커맨드라인 유틸리티

  • settings.py: 환경 구성

  • urls.py: url선언에 대한 저장. url dispatcher 구성

  • wsgi.py : WSGI 호환 웹서버의 진입점




https://docs.djangoproject.com/ko/1.11/intro/tutorial01/


https://zetawiki.com/wiki/%EC%9E%A5%EA%B3%A0_manage.py_%EB%AA%85%EB%A0%B9%EC%96%B4




'programming > Python' 카테고리의 다른 글

pyenv를 통한 python 개발환경 구성  (0) 2018.12.12
HOST, IP Address 간단하게 활용  (0) 2018.06.16
Python 주요사항 및 특징  (0) 2018.06.13


Maximum Connection


도커 버전 2.0.0.0-mac81 버전에서 테스트 도중 전체 컨테이너의 TCP Connection에 대해  제한이 있었다.


물론 도커 기본 메모리 같은 기타 자원에 의해 연결이 더 제한 될 사항은 있지만 기본적으로 테스트 해 본 결과 1970개의 제한이 있었다.




Library/Group Containers/group.com.docker/ 경로의 setting.json 파일을 통해 도커 기본 설정을 확인할 수 있는데,


vpnKitMaxConnections 키 값으로 connection 제한을 설정할 수 있다.






서비스 지향 아키텍쳐

- 서비스 지향 아키텍쳐는 서비스 지향성을 지원하는 아키텍처 스타일이다. 서비스 지향성이란, 서비스 자체, 서비스 기반의 개발, 서비스의 결과 관점에서 생각하는 방식을 의미
- MSA와 SOA는 자율성을 부여받는다. SOA는 서비스 수준의 추상화를 구현하는 반면, MSA는 환경(개발,배포) 수준까지 추상화를 구현한다.



서비스의 정의 다음과 같다.


  • 특정한 결과물을 생산할 수 있는 반복적인 비지니스 활동의 논리적인 표현이다.
    ex) 자료 제공, 주문 조회, 날씨 데이터 제공
  • 자기 완비적이다.
  • 다른 여러 서비스들의 조합에 의해 구성될 수 있다.
  • 서비스의 사용자에게는 블랙박스처럼 내부가 보이지 않는다.

SOA는 상당히 광범위한 용어이기 때문에, 다양한 방식으로 각각의 그룹 및 조직은 각각의 방법으로 SOA에 접근한다.



그렇다면 MSA와 SOA는 차이점은? 혹은 같은 것인가? 답은 어떻게 SOA를 적용하느냐에 따라 MSA와 비슷할 수 도 있고, 다를 수 도 있다.



1) MSA와 비슷하다.

ex) 서비스 지향 애플리케이션

- 어떤 조직에서는 SOA를 애플리케이션 수준에서 적용하기도 한다. 이런 접근 방식에서 병렬처리, 프로토콜 중개 등 서비스간의 통합 및 데이터 교환을 위해 POJO 서비스를 사용하기도 하는데, 이런 조직에서는 MSA를 SOA의 논리적인 다음 스텝으로 보곤 한다.



2) MSA와 다르다.

ex) 기존 시스템의 현행화 및 서비스 지향 통합

- 기업에서는 기존의 각각의 서비스들을 통합해왔으며, 오라클의 ESB(엔터프라이즈 서비스 버스)와 같은 시스템에 의존해왔다. ESB를 통해, 각 서비스를 통제 혹은 유연성을 제공할 수 있기에 MSA와는 다르다고 볼 수 있다.




'Architecture & Protocol' 카테고리의 다른 글

HTTP2 Protocol 분석  (0) 2019.04.16
12 요소 애플리케이션 방법론  (0) 2019.02.21
Websocket Protocol 분석  (0) 2019.01.28
마이크로서비스 아키텍처(MSA)  (0) 2018.12.02


MacOS 기준 설치

$ brew install pyenv

$ brew upgrade pyenv





path 설정 - 설치시 나오는 문구로 설정

$ vi ~/.bash_profile




>> if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi



=> 설치 시 나오는 문구를 적용하면 된다.






pyenv를 통한 설치 가능 리스트


$ pyenv install --list





virtualenv 설치 및 설정 - 설치시 나오는 문구로 설정

$ brew install pyenv-virtualenv



$ vi ~/.bash_profile



>> if which pyenv-virtualenv-init > /dev/null; then eval "$(pyenv virtualenv-init -)"; fi




! virtaulenv 는 프로젝트마다 가상환경을 구성할 수 있는 가상환경을 제공한다.





virtualenv 목록


$ pyenv virtualenvs





virtualenv 만들기


$ pyenv install 3.6.5

$ pyenv virtualenv 3.6.5 python-3.6.5


--> pyenv virtualenv [version] [naming]






virtualenv 시작 및 종료


$ pyenv activate python-3.6.5 << 시작

$ pyenv deactivate                 << 종료





alias를 통한 시작 및 종료

$ vi ~/.bash_profile


>> alials p3on='pyenv activate python-3.6.5'

>> alias poff='pyenv deactivate'


$ p3on


$ poff






Jupyter Notebook & Bpython pip install

$ p3on

$ pip install --upgrade pip

$ pip install bpython


$ bpython                     << 실행


$ pip install jupyter


$ jupyter notebook            << 실행




'programming > Python' 카테고리의 다른 글

django framework overview  (0) 2019.01.28
HOST, IP Address 간단하게 활용  (0) 2018.06.16
Python 주요사항 및 특징  (0) 2018.06.13

Netty를 통해 JVM 옵션을 여러가지 설정 할 수 있지만 핵심이라고 생각하는 4가지만 정리하였다.



1) 메모리 leak 검출


java -Dio.netty.leakDetection.level=advanced ...


 DISABLED

  메모리 릭 감지를 비활성화

 SIMPLE

  디폴트 설정이며 버퍼의 1%의 누출이 있는지 나타낸다.

 ADVANCED

  누출된 버퍼의 액세스 위치를 나타낸다.

 PARANOID

  모든 단일 버퍼라는 점을 제외하면 advanced와 동일. 

  leak 검출 시 빌드가 실패 될 수 있다.







2)  DirectBuffer 선호 여부 


java -Dio.netty.noPreferDirect=true ...


noPreferDirect 옵션은 netty는 ByteBufAllocator.buffer(..) 메소드가 호출 될 때, direct buffer는 선호되지 않는다고 개발자에게 알려준다. 그렇다고 해서 . ByteBufAllocator.directBuffer(...)가 직접적으로 directBuffer를 호출할 때 Direct Buffer가 사용되지 않는 것은 아니다. 여전히 사용 중이다.






3) ByteBuf allocator의 풀링 타입


java -Dio.netty.allocator.type=unpooled ...


풀링 여부에는 pooled / unpooled 가 존재한다. 여기서 말하는 풀은 DBCP의 Connection Pool  혹은 Thread Excutor의 Thread Pool과 같은 맥락이다.


즉, ByteBuf의 레퍼런스 카운트와 같은 자원관리를 Pool이 관리할 것이냐 아니면 unpooled 함으로 써 ByteBufAllocator에서 직접 얻어 올 것이냐로 나뉠 수 있다.






4) sun.misc.Unsafe의 사용을 중지하도록 허용


java -Dio.netty.tryUnsafe=false ...


Java 9 이상에서 sun.misc.unsafe 기능이 활성화 됨에 따라 NETTY에서 WARN 및 ERROR를 발생할 만한 요소가 있는데, unsafe 옵션을 비활성화 함으로써 사용을 중지 할 수 있다.


https://github.com/netty/netty/issues/272












MSA(Micro Service Architecture)


마이크로 서비스는 복잡한 시스템을 여러 개의 서비스로 분할 하여 대규모의 비지니스 서비스를 처리하는 아키텍처 스타일이나 패턴이다.

즉, 비지니스 요건에 대응하여 진화된 아키텍쳐 패턴인 것이다.

(비지니스는 일반적으로 도메인 비지니스에 해당하고 해당 내용에 대한 자세한 설명은 http://swiftymind.tistory.com/87?category=707534 참조)


소프트웨어 기술이 발전해오고 비지니스적 요구가 점점 증가 됨에 따라 마이크로서비스 아키텍처로 발전하게 되는 근원이 되었다.


참조:https://spri.kr/posts/view/21785?code=industry_trend


마이크로 서비스는 자신만의 데이터베이스, 비지니스, 표현 계층을 갖는데 이전의 주를 이루었던 SOA(Service Oriented Architecture)에서 와의 가장 큰 차이점은 경계의 구분이다.


예를 들어, 이전의 구조에선 상품 프로세스, 검색프로세스, 주문 프로세스 등 비지니스 계층이 한 데 묶은 채 서비스를 구축했을 것이다. 하지만 마이크로 서비스 아키텍쳐에서는 독립적으로 각각의 서비스가 분리되어 있기 때문에 , 다른 서비스의 비지니스에 영향을 미치지 않는다. 


이러한 측면에서 DevOps와 Cloud는 마이크로 서비스에서 나타나는 2가지 양상이다.

[*devOps : http://dev2ops.org/2010/02/what-is-devops/]


또한 대부분의 마이크로 서비스는 개발 과정에서 운영에 이르기 까지 전 과정을 최대한 자동화한다.




특징 및 장점

- 독립적인

- 느슨하게 결합된

- 소용비용과 전환시간이 낮다.

- 변환이 빠르다.

- 가볍다. (하나의 서비스는 하나의 기능만을 담당)

- 다양한 언어로 구상 가능하다.

- 실험 가능(서비스의 기능이 작기에, 비용이 monolothic에 비해 비용이 크게 들지 않고 기능간의 문제에서 자유롭다)

- 확장 가능(ex - With Hazelcast)

- 여러 버전으로 공존 가능



단점

- 서비스간의 의존성이 생기면 API를 호출하고 통신을 한다. 즉 , 단일 프로세스에 비해 속도에서 차이가 날 수 있다.

- 큰 규모의 프로젝트에서 서비스간의 디버깅이 어렵고 중앙관리 로그 모니터링 등이  없기에 관리가 어렵다.

- 대부분 모놀로틱 아키텍쳐에서는 하나의 데이터베이스를 사용하기에 데이터 트랜잭션에 대한 처리가 어렵지 않다. 하지만, 마이크로서비스에서는 데이터 뿐만 아니라 DB의 종류까지 달라질 수 있기 때문에 대부분의 개발 과정에서 고려해야 할 점이다.







참고

http://guruble.com/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4microservice-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EA%B7%B8%EA%B2%83%EC%9D%B4-%EB%AD%A3%EC%9D%B4-%EC%A4%91%ED%97%8C%EB%94%94/

https://www.redhat.com/ko/topics/microservices


'Architecture & Protocol' 카테고리의 다른 글

HTTP2 Protocol 분석  (0) 2019.04.16
12 요소 애플리케이션 방법론  (0) 2019.02.21
Websocket Protocol 분석  (0) 2019.01.28
서비스 지향 아키텍쳐(SOA)  (0) 2018.12.30

jedis는 사실상 java 기반 응용프로그램 표준 드라이버이고 많이 사용함에도 Spring에서 lettuce를 선호하는 점은 다음과 같다.

여러 쓰레드에서 단일 jedis 인스턴스를 공유하려 할때 jedis쓰레드에 안전하지 않다. 멀티쓰레드환경에서 고려해야할 상황이 따른다.

안전한 방법은 pooling(Thread-pool)과 같은 jedis-pool을 사용하는 것이지만 물리적인 비용의(connection인스턴스를 미리 만들어놓고 대기하는 연결비용의 증가) 증가가 따른다.

반면 lettucenetty 라이브러리 위에서 구축되었고, connection 인스턴스((StatefulRedisConnection))를 여러 쓰레드에서 공유가 가능하다.(Thread-safe)

=> 혼동할 수 있는데, connection 인스턴스의 공유라는 점에서 Thread-safe를 논점을 둔 점이고 Single-Thread레디스에 데이터에 접근할 때는 또다르게 고려해야 할 점이다.



https://github.com/spring-projects/spring-session/issues/789

'Cloud & NoSQL & Middleware > Redis' 카테고리의 다른 글

Redis Library  (2) 2018.11.17
Single Thread  (0) 2018.11.17
SpirngBoot에서 Redis 연동(Jedis)  (0) 2018.08.09
Redis 명령어  (0) 2018.08.04
Redis Pub/Sub Model  (0) 2018.07.01

+ Recent posts