HTTP/1.1 동작 방식

• HTTP/1.1는 기본적으로 Connection당 하나의 요청을 처리 하도록 설계
• 동시 전송이 불가능하고 요청과 응답이 순차적으로 이뤄짐
• HTTP 문서 안에 포함된 다수의 리소스 (Images, CSS, Script)를 처리하려면 요청할 리소스 개수에 비례해서 Latency(대기 시간)는 길어짐

HTTP/1.1 단점

HOL (Head Of Line) Blocking - 특정 응답의 지연

• HTTP의 HOL Blocking
• TCP의 HOL Blocking

  - HTTP/1.1의 connection당 하나의 요청 처리를 개선할 수 있는 기법 중 pipelining이 존재 

- Connection을 통해서 다수개의 파일을 요청/응답 받을 수 있는 기법

예 ) 하나의 TCP연결에서 3개의 이미지( a.png, b.png, c.png )를 얻으려고 하는 경우 HTTP의 요청 순서.

| --- a.png --- |

            | --- b.png --- |

                        | --- c.png --- |

순서대로 첫번째 이미지를 요청하고 응답 받고 다음 이미지를 요청하게 되는데 만약 첫번째 이미지를 요청하고 응답이 지연되면 아래 그림과 같이 두, 세번째 이미지는 당연히 첫번째 이미지의 응답 처리가 완료되기 전까지 대기하게 되며 이와 같은 현상을 HTTP의 HOB (Head of Line Blocking) 이라 부르며 pipelining의 큰 문제점 중 하나이다.

| ------------------------------- a.png ------------------ |

                                                                                       | -b.png- |

                                                                                                 | --c.png-- |

RTT( Round Trip Time ) 증가

• 일반적으로 하나의 connection에 하나의 요청을 처리
• 그렇기 때문에 매 요청별로 connection을 만들게 되고 TCP상에서 동작하는 HTTP의 특성상 3-way Handshake 가 반복적으로 일어나고 또한 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 저하 시킴

SPDY 등장

• HTTP/1.1 단점을 근본적으로 해결되지 않음
• 구글은 더 빠른 Web을 실현하기 위해 throughput 관점이 아닌 Latency 관점에서 HTTP를 고속화한 SPDY(스피디) 라 불리는 새로운 프로토콜을 구현
• SPDY는 HTTP를 대치하는 프로토콜이 아니고 HTTP를 통한 전송을 재 정의하는 형태로 구현 

SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고 이는 HTTP/2 초안의 참고 규격이 됨

HTTP/2 등장

• HTTP가 유선 상에서 표현 방법을 대치 하는 것
• 성능에 초점
• 최종 사용자가 대기 시간, 네트워크 및 서버 리소스 사용을 인식
• 하나는 브라우저에서 웹 사이트로의 단일 연결을 허용하는 것

HTTP/2 주요 특징

Multiplexed Streams

• 한 커넥션으로 동시에 여러 개의 메세지를 주고 받을 있으며, 응답은 순서에 상관없이 stream으로 주고 받음
• HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선

Stream Prioritization

클라이언트가 요청한 HTML문서 안에 CSS파일 1개와 Image파일 2개가 존재하고 이를 클라이언트가 각각 요청하고 난 후 Image파일보다 CSS파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어지는 문제가 발생하는데 HTTP/2의 경우 리소스간 의존관계(우선순위)를 설정하여 이런 문제를 해결

Server Push

• 서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 보내줄 수 있음
• 클라이언트(브라우저)가 HTML문서를 요청하고 해당 HTML에 여러 개의 리소스(CSS, Image...) 가 포함되어 있는 경우 HTTP/1.1에서 클라이언트는 요청한 HTML문서를 수신한 후  HTML문서를 해석하면서 필요한 리소스를 재 요청하는 반면 HTTP/2에서는 Server Push기법을 통해서 클라이언트가 요청하지 않은 (HTML문서에 포함된 리소스) 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화 해서 성능 향상을 이끌어 냄
• PUSH_PROMISE 라고 부르며 PUSH_PROMISE를 통해서 서버가 전송한 리소스에 대해선 클라이언트는 요청을 않음

Header Compression

HTTP/2는 Header 정보를 압축하기 위해 Header Table과 Huffman Encoding 기법을 사용하여 처리하는데 이를 HPACK 압축방식이라 부르며 별도의 명세서(RFC 7531)로 관리.

위 그림처럼 클라이언트가 두번의 요청을 보낸다고 가정하면 HTTP/1.x의 경우 두개의 요청 Header에 중복 값이 존재해도 그냥 중복 전송한다. 하지만 HTTP/2에선 Header에 중복값이 존재하는 경우 Static/Dynamic Header Table 개념을 사용하여 중복 Header를 검출하고 중복된 Header는 index값만 전송하고 중복되지 않은 Header정보의 값은  Huffman Encoding 기법으로 인코딩 처리 하여 전송한다.

참고

https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/

http://americanopeople.tistory.com/115

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

https://kemptechnologies.com/solutions/http2/

아래 아티클을 번역

https://www.spiceworks.com/it-articles/troubleshooting-steps/ 

1 단계 : 문제가 정확히 무엇입니까?

문제의 진상을 파헤치는 것은 때때로 "스무고개 게임"을 하는 것처럼 느껴질 때가 있다. 즉 근본적인 문제를 빨리 발견하고 싶다면 무엇보다도 올바른 질문을 하는 것이 중요하다.

• 다른 사람과 대화하거나 전자 메일을 주고받는 경우 주의 깊게 듣거나 읽고 메모하세요(상대방의 의중 또는 기타). 작업이 완료되면 "예/아니오"로 대답하거나 정량적으로 답변할 수 있는 질문을 진행합니다(예: "이 일이 몇 번이나 발생했습니까?"). 이 접근은 상황을 움직이고 애매한 반응을 줄일 수 있다.
• 무엇을 물어야 할까요? 핵심은 문제의 "누가, 무엇을, 언제"를 찾아내는 것입니다. 이 문제가 한 사람에게만 영향을 미치는지 아니면 많은 사람에게 영향을 미치는지? 컴퓨터나 네트워크에서 중요한 이벤트가 발생한 직후에 발생 했습니까? "이메일을 보낼 수 없습니다."와 같은 일반적인 문구 아래에 자세히 설명하도록 요청할 수 있는 구체적인 질문이 있습니다. PC나 모바일 장치를 사용하고 있습니까? PC 전원이 켜져 있습니까? 전자 메일 클라이언트를 열 수 있습니까? 이메일을 보내거나받을 수 있습니까?
• 일단 여러분이 이 문제에 대해 이해하게 되면, 그 문제에 대한 당신의 이해를 되풀이하여 같은 페이지에 무엇이 잘못되었는지 확인하십시오. 그들이 사용하는 것과 동일한 언어를 사용하고 복잡한 기술 용어를 사용하는 것을 피하는 것은 좋은 생각이다. 이렇게 하는게 이상적으로 문제와 관련된 잠재적인 혼란을 제거하는 데 도움이 됩니다.

이제 문제의 본질에 대한 기본적인 이해를 하셨으니, 해결 방법을 찾을 수 있는 기술적인 세부 사항을 살펴보실 수 있습니다.

2 단계 :  자세한 정보 수집, 변수 제거

많은 경우에서 일반적인 문제로 보고 된 내용(예 : 인터넷이 다운 됨)은 사실 특정 웹 사이트가 오프라인 상태 인 것과 같이 매우 특별한 것입니다. 이것을 알아내는 가장 좋은 방법은 무엇일까요? 적절한 질문을 한 후 다음과 같은 다양한 출처에서 더 많은 정보를 찾아보십시오.

• 에러 메시지 : 사용자가 에러를 보고하거나 우리가 에러를 확인하려고하는 경우, 에러가 발생한 이유에 대해 정확한 이유를 알려줄 수 있습니다. 예를 들어, Windows(윈도우)의 파란 화면은 고장 원인에 대한 적절한 오류 코드를 제공합니다.
• 이벤트 로그 : 존재하고 있습니까, 그렇다면 정확히 어떻게 적혀 있습니까? 에러 메시지 외에도 로그는 타임 스탬프를 제공하므로 정확한 이벤트가 언제 발생했는지에 대한 질문에 대답 할 수 있습니다. Windows 이벤트 뷰어를 확인하면 관련 로그를 찾을 수 있는 첫 단계가 될 수 있습니다.
• 사용자가 문제 해결 프로세스에 도움이 될 수 있는 스크린샷, 비디오 또는 기타 지원 정보를 제공할 수 있습니까?
• 진단 결과: 스템 유틸리티를 실행하여 추가 정보를 얻었습니까? 예를 들어: ping은 해당 서버 또는 웹 사이트에 연결할 수 있는지 원격으로 확인하는 데 도움이 됩니다. 또한 Windows 메모리 진단은 오류가 있는 메모리를 확인할 수 있으며, 리소스 모니터 또는 성능 모니터는 비정상적으로 높은 CPU나 메모리 사용량을 확인할 수 있으며, 디스크 검사로 하드 드라이브에 오류가 있는지 검사할 수 있습니다.
• 모니터링 : 문제가 발생하기 전에 더 많은 단서를 제공하거나 문제를 예측할 수있는 모니터링 툴이 있습니까? Spiceworks와 같은 네트워크 모니터링 솔루션은 다운 될 위험이있는 서버에 대한 (사전)경고를 제공합니다. 또한 네트워크 인벤토리 응용 프로그램은 디스크 공간, 사용 가능한 메모리, 설치된 OS 및 해당 devies에서 실행중인 소프트웨어와 같은 수십 또는 수백 개의 시스템에 대한 중요한 통계를 제공 할 수 있습니다.

3 단계 : 문제를 재현하고 근본 원인에 대한 가설을 세웁니다.

이제 기본 배경 정보를 수집했으므로 이제 문제를 직접 해결할 때입니다. 문제를 재현하는 것은 사용자가 보고한 것과 동일한 에러를 재현할 수 있음을 확인하는 것을 의미합니다. 이 작업은 문제가 되는 실제 사이트에서 또는 원격 데스크톱/원격 제어 응용 프로그램을 통해 수행할 수 있습니다. 이러한 옵션을 사용할 수 있습니까? 당신은 유사한 컴퓨터 환경에서 동일한 조건을 비슷하게 만들 수 있을 것입니다.

같은 오류가 발생하면 관찰 한 내용을 바탕으로 근본 원인에 대한 이론을 보다 쉽게 ​​개발할 수 있으며 문제를 해결하기 위한 조치를 취하기 시작할 수 있습니다. 때로는 범인을 (솔루션을 생각해내는 것) 빨리 찾아 낼 수도 있을 겁니다. 가설과 다른 경우에는, 시간이 더 오래 걸릴 것이고, 가지고 있는 여러 지식을 파고들어야 할 수도 있고, 오래된 헬프 데스크 티켓들을 뒤적거리거나, 같은 문제에 직면한 다른 사람들의 해결책을 찾기 위해서 구글을 검색해야 할 수도 있다.

이 단계에서 컴퓨터의 작동 방식에 대한 깊은 이해가 입증될 것입니다. 예를 들어, 컴퓨터 네트워킹에서 네트워크에 대한 7계층 OSI 모델을 이해하는 경우(이 중 하나에 문제가 존재할 수 있음), 네트워킹 문제의 잠재적인 원인을 체계적으로 처리할 수 있는 프레임워크가 있습니다. 연결 문제의 경우 이더넷 케이블이 손상되거나 또는 분리되거나(Layer 1 문제), 네트워크 요청이 수행되지 않거나(Layer 3),  응용 프로그램이 제대로 코드화되지 않을 수 있습니다(Layer 6).

4 단계:발견한 결과를 기반으로 해결 시도

이미 수집한 증거는 근본 원인의 가능성이 있는 부분으로 좁혀갈 수 있고, 문제를 해결 할 수 있는 부분을 지적하고 있어야 한다. 이 시점부터는 초점을 맞추고 실험을 해야 할 단계이다. 문제와 관련된 변경 설정 변경, 문제가 있는 부분 교체, 손상된 파일을 복구, 드라이버와 소프트웨어 업데이트 등을 문제가 해결될 때까지(또는 최소한 가까워질 때까지) 시도해 볼 수 있습니다.

아직도 엉망진창? 모든 것이 정상적으로 작동하면 언제든지 기계를 다시 복원할 수 있습니다. 다시 말하면, 문제가 발생하기 전에 누군가가 데이터 또는 시스템 상태를 백업하는 매우 중요한 단계를 밟았을 때 문제가 발생하기 전의 정상적인 PC로 돌아갈 수 있습니다.

모든 문제는 고유한 눈송이와 유사하지만 문제 있는 시스템 재부팅, DNS 및 DHCP 문제 확인, 장치 관리자 드라이버 문제 확인, 시스템 정리 또는 방화벽 설정 확인 등의 일반적인 문제 해결 단계를 통해 많은 문제를 해결할 수 있습니다. 더 어려운 문제의 경우, 각자의 여러가지의 시도와 Google 검색 결과가 만족스럽지 않을 경우 Spiceworks와 같은 IT 포럼에서 토론을 검색하는 것이 PC 문제를 해결하는 데 매우 유용할 수 있습니다. 아무것도 나타나지 않으면 언제든지 Spiceworks의 수백만 명의 IT 전문가 커뮤니티에 문의할 수 있습니다.

문제가 해결 되었나요? 미래의 문제를 준비하세요

기본적인 기술 문제(네트워크 문제, 드라이버 충돌, 디스크 문제 등)가 무엇이든 간에, 위에 설명된 프로세스는 정보 수집, 문제의 가능한 원인 확인, 문제 발생 시 솔루션을 찾는데 적합합니다. 하지만 여전히 각각의 독특한 사례에 따라 판단을 내려야 할 것입니다.

이런 종류의 시스템을 마련하고, 이전의 컴퓨터 문제를 통해 학습된 지식을 통해 여러분은 더 많은 경험을 쌓을 때 더 효율적으로 컴퓨터 문제를 해결할 수 있을 것입니다. 또한 향후 위기를 사전에 방지하기 위해 유사한 문제에 직면한 모든 사용자가 참조할 수 있도록 문제를 문서화할 수 있습니다.

참고

https://b.luavis.kr/server/linux-performance-analysis

https://www.spiceworks.com/it-articles/troubleshooting-steps/

Container란 무엇인가?

사전적 의미로 컨테이너는 어떤 물체를 격리하는 공간을 뜻합니다. 클라우드에서 컨테이너는 어떤 의미를 가질까요? 컨테이너는 애플리케이션과 애플리케이션을 구동하는 환경을 격리한 공간을 뜻합니다. 컨테이너 기술은 약 10여 년 전에 리눅스에 내장된 기술로 소개되었으며, 현재는 차세대 트렌드 기술로 주목받으며 클라우드 서비스 환경에 적용되고 있습니다.

왜 Container인가?

1)   Virtual Machine과 Container의 차이점

Virtual Machine Server에서는 Hypervisor로 하드웨어를 가상화 하고, 그 위에 Guest OS가 설치된 Virtual Machine들을 구동 시켰다. 반면에 Container Server는 운영체제 레벨에서 CPU, RAM, Disk, Network 등의 자원을 격리하여 Container에 할당하기 때문에 게스트 OS가 따로 필요 없다.

2)   효율성
안정적인 운영을 위해, 1개의 가상머신(VM, Virtual Machine)에 1개의 서비스를 구동하는 것이 권장된다. 이의 경우 가상머신의 모든 자원을 사용하는 것이 아니기 때문에 성능적 오버헤드가 발생한다. 반면 컨테이너의 경우, OS 커널을 공유하기 때문에 자원을 필요한 만큼 효율적으로 사용할 수 있다.

3)   신속성
사용자의 서비스 request traffic이 증가함에 따라, 가상머신이나 컨테이너를 추가적으로 배포한다. 가상머신의 크기는 최소 몇 GB이지만, 컨테이너의 경우 Guest OS가 없어 MB단위의 크기를 가진다. 결과적으로 가상머신은 배포하는데 수 분에서 수십 분의 시간이 소요되지만, 컨테이너는 배포에 소요되는 시간이 수 초에 불과하다.

4)   라이센스 비용 절감
가상화 서버의 경우 가상머신의 개수만큼 Guest OS의 라이센스 비용이 발생한다. 반면에 컨테이너 서버의 경우 Host OS 1대의 라이센스 비용만 발생한다. 만약 서버의 수가 많아진다면 비용의 차이도 기하급수적으로 증가할 것이다.

5)   안정성
가상머신의 경우 정확히 할당된 자원 내에서 가상머신이 운영되기 때문에, 컨테이너에 비해 안정적으로 운영할 수 있다. 반면에 컨테이너들은 OS 커널을 공유하기 때문에, 하나의 컨테이너가 무리하게 자원을 사용하게 될 수 있다. 자원 할당량을 사전에 지정 시켜줄 수 있지만, 만약 이런 상황이 발생하면 컨테이너에 장애가 발생 한다. 이런 컨테이너의 문제는 뒤에 등장할 쿠버네티스 등과 같은 Container 오케스트레이션 툴로 해결할 수 있다.

https://developer.ibm.com/kr/cloud/2018/01/12/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%99%80-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%EB%A5%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/

https://www.backblaze.com/blog/vm-vs-containers/