14 Jun 2022

1장 HTTP 개관

1.1

HTTP를 이용하여 웹서버로부터 대량의 정보를 빠르고/간편하고/정확하게 클라이언트의 브라우저로 옮긴다.

• 웹 트래픽 : 웹 트래픽(web traffic)은 웹 사이트에 방문한 사람들이 데이터를 주고받은 양이다. 이는 인터넷 트래픽의 큰 부분이다. 이는 방문자 수와 방문 페이지 수에 따라 결정된다. 사이트들은 오고가는 트래픽을 감시하면서 사이트의 어느 부분이나 페이지가 유명한지, 또 특정 국가의 사람들이 어느 페이지를 가장 많이 보는지 등을 파악한다. 위키백과.

1.2 웹 클라이언트와 서버

• 웹 콘탠츠는 웹서버에 존재. 이때 웹 서버는 HTTP프로토콜로 의사소통하며 콘탠츠를 제공한다.
• 기본적으로 웹 클라이언트가 HTTP요청을 보내면, 서버가 HTTP응답으로 돌려준다.

1.3 리소스

• 클라이언트가 소모하는 리소스는 웹서버에 의해 관리되고 제공된다.
• 이 리소스의 요소들을 웹 콘탠츠라고 한다.
• 리소스는 파일, 문서, 동영상부터 서버가 제공하는 서비스(검색엔진 등) 폭 넓은 범위를 지칭한다.

1.3.1 미디어타입

• HTTP를 사용하여 전송되는 객체(리소스)는 MIME타입이라는 데이터 포맷 라벨이 붙여진다.
• MIME포멧을 이용해 전송된 데이터를 다룰수 있는지, 다룰수 있다면 어떻게 다룰지 정한다.
• jpeg타입의 이미지를 보낸다고 HTTP에 표기할 때, MIME타입은 다음과 같은 문자열로 전송된다.

  ...
  Content-type: image/jpeg
  ...
  

1.3.2 URI(uniform resource identifier, 통합 자원 식별자)

• 웹서버에서 관리되는 리소스는 각자의 이름(경로 등)을 가지고 있기 때문에, 클라이언트는 특정 리소소를 지목하여 요청할 수 있다.
• 이러한 서버에 저장된 리소스의 이름은 URI로 불린다.

  URI(정확히는 URL)의 예시
  http://joes-hardware.com/specials/saw-blade.gif
  http:// -> http프로토콜을 사용하여
  joes-hardware.com -> joes-hardware.com의 80포트로 접속하고
  specials/saw-blade.gif -> specials/saw-blade.gif을 요청하라.
  

• 위와 같은 명령을 브라우저에 입력하면, 브라우저는 URI를 해석하여 일련의 동작을 수행하고 결과를 표시한다.
• URI의 종류는 URL과 URN이 있다.

1.3.3 URL(uniform resource locator, 통합 자원 지시자)

• URL는 URI의 가장 흔한 형태이며, 일반적으로 URI는 URL을 지칭한다.
• 위의 예시처럼, 특정 서버의 한 리소스의 구체적인 위치를 서술한다.
• URL은 리소스가 정확히 어디에 있고, 어떻게 접근할 수 있는지 분명히 알려준다.

  URL의 예시
  http://joes-hardware.com/specials/saw-blade.gif
  http:// -> 스킴, 리소스에 접근하기 위해 사용할 프로토콜을 명시.
  joes-hardware.com -> 서버의 ip주소나 도메인(DNS필요)
  specials/saw-blade.gif -> 서버의 리소스의 구체적 위치.
  

1.3.4 URN(uniform resource name, 유니폼 리소스 이름)

• URN은 리소스의 위치에 영향을 받지 않는 이름이다.
• 구체적 디렉토리에 위치한 파일을 지명하는 URL과 달리, URN은 서버가 이름을 인식하여 전송되는 리소스이다.

URI URL URI

이미지 참고

내용도 좋은거 같음. 참고.

참고 : https://stackoverflow.com/a/44483937

1.4 트랜젝션

• 서버와 클라이어트관의 일련의 요청과 응답.
• 일반적으로 클라이언트가 요청하면, 서버는 클라이언트에게 적합한 응답을 한다.
• 트랜젝션은 HTTP가 요구하는 구조를 따르는 데이터(메세지)로 이루어진다.

1.4.1 메서드

• 클라이언트가 보내는 요청 메세지의 요소 중 하나이며, 요청 메세지 당 하나의 메서드를 가진다.
• 서버에게 어떤 동작을 요구하는지 명시한다.
• POST Method(C), GET Method(R), PUT Method(U), DELETE Method(D)

1.4.2 상태코드

• 클라이언트에게 요청에 대한 결과 여부를 나타내는 3자리 숫자이다.
• 상태코드를 통해서 응답 처리를 수행하며 사유 구절도 추가할 수 있지만, 부가적이다.

1.4.3 웹 페이지는 여러 객체로 이루어질 수 있다.

• 웹 페이지를표시할 때, 하나의 서버에서 제공하는 리소스만 가져오는게 아니다.
• 이 글만 봐도 이미지의 상당수는 URI를 통해서 표시하며, 각기 다른 서버에 저장된거다.

1.5 메시지

• 시작줄 : 무엇을 요청할지(클->서), 어떻게 처리되었는지(서->클)
• 헤더 : 0개 이상. 이름:값형태로 개행 단위로 구분된다. 마지막 다음에는 빈 줄이 온다.
• 본문 : 이진데이터(이미지, 비디오…)나 텍스트 등 어떠한 종류의 데이터든 들어갈 수 있음.

1.6 TCP 커넥션

…

1.8 웹의 구성요소

1.8.1 프록시

• 프록시 : 클라이언트와 서버 사이에 위치하며, 클라이언트의 모든 HTTP요청을 받아서 서버에 전달한다. 이때, 대부분의 요청을 수정한다.
• 요청와 응답을 필터링하여 전달한다.

  1.8.2 캐시

• 웹캐시와 캐시프락시가 있음.
• 자신을 거쳐가는 문서 중 자주 찾는 문서의 사본을 저장하여, 클라이언트가 요청시 서버 대신 해당 문서를 응답해준다.

  1.8.3 게이트웨이

• 주로 HTTP 트래픽(요청/응답)을 다른 프로토콜로 변환하기 위해 사용
• 게이트웨이는 자신이 서버인것처럼 요청을 다루어서, 진짜 서버와 통신하는 것과 차이가 없다.

  1.8.4 터널

웹서버란? 웹서버의 역할 웹서버는 클라의 요청에 따른 응답(컨텐츠)를 제공하는 프로그램.

• 웹서버 단일로는 정적 컨텐츠를 제공. 즉 미리 작성된 일괄된 페이지를 전달한다.
  • 아파치, 엔진엑스
• WAS는 요청을 처리하고 사용자별로 다른 동적 컨텐츠를 클라에게 제공할 수 있다.
  • 비지니스 로직이나 DB연동 등의 복잡할 연산을 하고 그 결과를 웹서버에게 전달하면, 웹서버는 이를 클라에게 제공한다.
  • 톰켓
• 웹서버는 정적 페이지 및 클라 연결, WAS는 비지니스로직 및 DB처리를 집중적으로 하여 분산적으로 트레픽을

이미지 출처 및 정리 잘 되어있는 페이지

nginx의 역할

• 기본적인 웹서버로서 역할 : HTTP표준에 맞춰, 클라이언트가 요청한 정적 파일을 제공.
• 리버스 프록시 : 클라 요청과 서버의 응답응 중재.
  • 외부로부터 오는 요청을 리버스 프록시 서버에서 받고, 매핑되는 내부 서버로 요청을 전달하여 서버의 존재를 숨길수 있다.
  • 내부 서버에 매핑 할 때 서버 상태에 따라 트래픽(요청)을 분산시킨다.

다른 웹서버와 차별화되는 nginx의 특징

• 고정된 수의 woker process
  • 클라이언트 접속마다 발생하는 문맥교환이나 리소스할당/회수등 오버헤드 감소 시킴.
• Event-driven architecture와 non-blocking I/O를 사용
• 기존의 웹서버들은 커넥션마다 fork나 스레드를 만들어서 요청 처리를 전담 했음. 이로 인해 apache의 c10k problem문제가 발생

nginx의 구조

• https://ssup2.github.io/theory_analysis/Nginx_Architecture/

동작방식 정리 1

master process

• 컨피그 파일 읽기, 포트 바인딩, 자식프로세스(캐시 매니저/로더, 워커)생성
• 하지만 과제에서는 fork불가이므로 마스터 프로세스가 워커 프로세스로 전환? 역할 변환?되어야 할 듯 함.

child processes

• chahe manager : 주기적으로 디스크 캐시 항목정리/크기유지?
• chahe loader : 시작시 실행되어 디스크 기반 캐시를 메모리에 로드.
• woker process : CPU와 1:1 매칭됨. 모든 작업 수행. connect, 컨탠츠를 디스크에 읽고쓰기, 업스트림서버와 통신
  • 워커 프로세스는 리슨 소켓을 멀티플랙싱 함수에 등록하고 대기. -> 소켓 쉐어링

상태머신 공통적으로 nginx에게 요청을 처리하는 방법을 알려주는 일련의 로직?이다.

• HTTP 상태머신을 통해서 워커 스레드가 특정 상태(응답 처리/에러반환…)로 진입하게 만드는듯함.
• 상태머신 스케줄링_블로킹 상태머신 -> 블로킹I/O, 논블로킹I/O를 사용하는걸 말하는듯.

Event Driven Architecture, 비동기 i/o와 스레드풀

• 멀티플랙트 I/O정해진 수의 프로세스(워커)에서 단일스레드 사용.
  • 우리 과제의 경우 메인프로세스에서만 진행…
• 논블로킹 방식으로 비동기적으로 요청 처리.
• file r/w관련 함수들의 경우 처리가 완료될때까지 block된다. 따라서 이러한 동작들을 thread pool에서 관리하여 async하게 처리.
• 참고

스레드풀

• nginx에서는 워커프로세스에서 단일 스레드를 사용하기 때문에, 이벤트 처리가 길어지면(file r/w등) 다른 이벤트 처리가 block된다.
• 이렇게 오래걸리는 동작은 event queue에 넣으면, 스레드 풀의 워커 스레드들이 처리하고, 완료시 메인 루프에(?) 메세지를 보낸다(how??, 비동기이니까 callback을 호출하나?).
• https://ssup2.github.io/theory_analysis/Nginx_Thread_Pool/
• 그럼, select, epoll, kqueue에서 블로킹할때랑 논블로킹 할때랑 어떻게 다른데???? -> 처리 가능한 소켓이 생길때까지 대기하는건 똑같음. read/write할 때 다른 차이 발생.
• 1, 2

cache <- 프록시?

• 백엔드로부터 전송되는 응답을 캐쉬에 저장하고, 동일한 요청이 오는 경우 이를 대신 응답.

웹서버와 웹서비스

• 캐시 : nginx의 경우 캐시서버의 기능도 할 수 있음.
• 상태머신 : 유한개의 상태를 가지고 주어지능 입력에 따라 특정 상태에서 다른 상태로 전이되거나, 출력이 발생하게 하는 장치(로직)

캐시