최소 지원 브라우저 버전 

 

 

 

 

Overview

 

  • HTTP/2 프로토콜은 클라이언트와 서버간 연결(on the wire)에서 HTTP가 어떻게 표현되는지로 대체됨
  • 프로토콜의 초점은 성능
    -     사용자(end-user)의 지연시간(latency) 및 네트워크와 서버 자원의 사용을 감지
  • connection을 한 번 맺으면 최대한 길게 사용할 것을 권고

    연결 수가 적다는 것은 HTTPS 배포의 성능을 개선하는데 특히 중요. 연결 수가 적으면 비용이 많이 발생하는 TLS 핸드셰이크가 줄어들고, 세션 재사용이 더 향상되며, 필요한 클라이언트 및 서버 리소스가 감소

  • 서버가 HTTP2 프로토콜을 지원할 경우 101 switching protocol 을 응답 받으며 연결되며, 지원하지 않을 경우 연결하기 위한 특정 header(Connection and Upgrade)는 무시하고 HTTP 1.x 프로토콜로 FALL BACK 해야 한다.



Stream, Message, Frame

- http2의 기본 구성 요소는 Stream, Message, Frame 이다.

 

 

 

  • 스트림: 구성된 연결 내에서 전달되는 바이트의 양방향 흐름이며, 하나 이상의 메시지가 전달될 수 있다.
  • 메시지: 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스
  • 프레임: HTTP/2에서 통신의 최소 단위이며 각 최소 단위에는 최소 하나의 프레임 헤더가 포함된다. 이 프레임 헤더는 최소한 프레임을 통해 스트림을 식별한다.


Binary Framing

Http Header와 Body가 Headers Frame, DATA frame으로 변경

 

- Frame은 String 데이터가 Binary로 Framing 된다. 프로토콜은 다음과 같다.

 

 

 

Protocol 

 

  • 모든 프레임은 9 바이트 헤더로 시작한다.(Length + type + flags)
  • Length :  payload의 길이를 나타내고 unsigned 24bit integer이다. 수신자가 SETTINGS_MAX_FRAME_SIZE에서 2^14(16,384)보다 큰 값을 설정하지 않았다면 이보다 큰 값이 보내질 수 없다.
  • Type : 프레임의 형식
  • Flags : 8 비트, 특정 유형의 bool flag. 플래그들은 프래임의 타입에 따라 의미가 달라진다. 특정 프레임 타입에서 의미가 없는 플래그는 무시되어야 하고, 돌려 보낼떄 0으로 unset되어 보내져야한다.
  • R: 1비트 는 항상 0으로 예약된다.
  • Stream Identifier : 스트림의 식별자

 

Type 

DATA(0) - Used to transport HTTP message bodies

HEADERS(1) - Used to communicate header fields for a stream

PRIORITY(2) - Used to communicate sender-advised priority of a stream

RST_STREAM(3) - Used to signal termination of a stream

SETTINGS(4) - Used to communicate configuration parameters for the connection

PUSH_PROMISE(5) - Used to signal a promise to serve the referenced resource

PING(6) - Used to measure the roundtrip time and perform "liveness" checks

GOAWAY(7) - Used to inform the peer to stop creating streams for current connection

WINDOW_UPDATE(8) - Used to implement flow stream and connection flow control : 흐름 제어

CONTINUATION(9) - Used to continue a sequence of header block fragments

 

 

 

 

 

 

 

 

 

 

Http2는 이외에도 Server push, multiplexing 스트림 우선순위 지정 등 눈여겨 봐야 할 여러가지 특징이 있다. 결론적으로 http2는 http의 느리고 header packet의 중복 전송 등의 단점을 극복할 수 있는 프로토콜이다. 만일 리소스가 많지 않은 서버의 경우 http2는 비효율적일 수 있다. 

 

 

http2 기반 서버 / 클라이언트 구현 예제 샘플 : https://github.com/chulman/netty-http2

 

 

 

 

https://tools.ietf.org/html/rfc7540

 

RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)

[Docs] [txt|pdf] [draft-ietf-http...] [Tracker] [Diff1] [Diff2] [IPR] [Errata] PROPOSED STANDARD Errata Exist Internet Engineering Task Force (IETF) M. Belshe Request for Comments: 7540 BitGo Category: Standards Track R. Peon ISSN: 2070-1721 Google, Inc M.

tools.ietf.org

ㅇhttps://developers.google.com/web/fundamentals/performance/http2/?hl=ko

 

HTTP/2 소개  |  Web Fundamentals  |  Google Developers

HTTP/2(또는 h2)는 푸시, 다중화 스트림 및 프레임 제어를 웹에 구현하는 바이너리 프로토콜입니다.

developers.google.com

 

저작자표시

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

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

12요소 애플리케이션 방법론

- Heroku가 제시한 12 요소 애플리케이션 방법론은 클라우드 환경에서 운영 가능한 가장 현대적인 애플리케이션에서 기대할 수 있는 특징을 기술한 방법론이다.

1. 단일 코드 베이스

- 애플리케이션은 하나의 코드 베이스만 가져야 한다. 개발/테스트/운영 등 여러 개의 인스턴스를 동일한 코드 베이스 기반으로 구성해야 하며, git/svn 과 같은 형상관리를 이용한다. 이 코드 베이스는 다른 마이크로 서비스와 공유되지 않는다.


2. 의존성 꾸러미(Bundling dependencies)

- 애플리케이션에 필요한 모든 의존성은 애플리케이션과 함께 관리되야한다. maven/gradle 을 통해 pom.xml/.gradle 을 통해 명시적으로 의존성을 관리할 수 있으며 최종 실행 파일은 .jar 혹은 .war 파일에 모두 패키징되어야 한다.


3. 환경설정 외부화(externalizing configuration)

- 모든 환경설정 파라미터를 코드와 분리해서 외부화하라고 권고한다.


4. 후방지원 서비스(backend service)

- URL을 통해 접근가능해야 하며, 모든 서비스는 살아있는 동안 외부의 자원과 의사소통할 수 있어야 한다. 마이크로 서비스 세상에서의 API end-point는 일반적으로 REST를 사용하는 HTTP 기반의 end-point이다. 


5. 빌드, 배포, 운영의 격리

- 빌드/배포/운영 단계를 뚜렷하게 격리하는 것이 좋다. 빌드 -> 배포 -> 운영의 방향은 일방향이며 파이프라인을 모두 통과하여야 한다.


6. 무상태, 비공유 프로세스

- 모든 마이크로 서비스는 무상태 기반으로 설계되어야 하며, 상태를 저장해야 할 경우 DB 혹은 인메모리 캐쉬 같은 후방 지원 서비스에서 처리 해야한다.


7. 서비스를 포트에 바인딩해서 노출

- 12요소 애플리케이션은 standalone 이어야 하기 때문에 포트바인딩을 통해 자율적이고 자기 완비적인 특성을 유지해야 한다.


8. 확장을 위한 동시성

- replication(복제)를 통해 프로세스가 확장될 수 있게 설계 되어야 한다.


9. 폐기 영향 최소화

- 구동 및 종료에 필요한 시간을 최소화 하고, 서버가 종료될 때는 종료에 필요한 작업이 모두 수행되는 우아한 방식으로 종료해야 한다. 특히 자동화된 배포의 시간이 오래 걸리면 자동화에 부정적인 요소가 미칠 우려가 있다. 때문에, lazy loading(지연 로딩) 혹은 크기를 가능한 한 작게 유지하는 것이 중요하다.

10. 개발/운영 환경의 동일

- 개발/ 운영 환경은 동일해야 한다. 그렇지 않으면, 개발에서 일어나지 않았던 비정상적인 상황이 운영에서 발생할 수 있다.


11. 로그 외부화

- 로그 파일은 절대 애플리케이션 영역에 담지 않고, 로그 스트림을 통해 중앙 집중화하는 것이 중요하다.


12. 관리자 프로세스 패키징

- 관리에 필요한 코드 및 태스크 또한 애플리케이션과 함께 패키징되고 포함되어야 한다.



저작자표시

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

HTTP2 Protocol 분석  (0) 2019.04.16
Websocket Protocol 분석  (0) 2019.01.28
서비스 지향 아키텍쳐(SOA)  (0) 2018.12.30
마이크로서비스 아키텍처(MSA)  (0) 2018.12.02



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

서비스 지향 아키텍쳐

- 서비스 지향 아키텍쳐는 서비스 지향성을 지원하는 아키텍처 스타일이다. 서비스 지향성이란, 서비스 자체, 서비스 기반의 개발, 서비스의 결과 관점에서 생각하는 방식을 의미
- 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

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

+ Recent posts

티스토리툴바