Skip to content

Latest commit

 

History

History
438 lines (318 loc) · 48.5 KB

Network.md

File metadata and controls

438 lines (318 loc) · 48.5 KB
Raw

Network

📖 Contents

API란

  • Application Programming Interface의 약자로, 데이터를 주고받을 때 사용하는 하나의 인터페이스, 우리가 만든 기능과 함수를 다른 사람들도 사용할 수 있게 해주는 인터페이스이다. front-end가 back-end에 요청을 할 때, 즉 클라이언트가 서버에게 요청할 때 특정 규칙에 맞게 요청해야 하는데 이러한 사용 규칙을 제공하는 것을 API라고 한다. 웹 서버 따로 API 서버를 따로 구축할 수 있다.

  • 옛날에는 template 파일을 랜더링하는 개발이었지만, 요즘에는 API 개발이 중심

    • 랜더링 방식에서 JSON 형태의 응답으로 바뀐 이유는, 다양한 처리가 가능하기 때문. 데이터만 보내면 효율적이고 웹이나 앱, OPEN api 등 다양하게 활용될 수 있다.

  • REST API

    • REST는 Representational State Transfer의 약자로, 응용프로그램(클라이언트)들이 시스템에 있는 자원(데이터)을 쉽게 사용하기 위해 시스템이 URL로 자원을 정의하고, Method로 행위를 정의하는 것이라고 볼 수 있다.
    • RESTful한 API가 되려면, Request에는 URL, Method가 있어야 하고 / Response에는 Data type, Status code가 있어야 한다.
POST, GET         /users
GET, PUT, DELETE  /users/1

  • /company/1/mem-bers 이러한 url 케이스와 / ?name=AAA__AA 이러한 파라미터 케이스

    • 파라미터는 DB 필드명과 비슷하게 설정
    • url에는 - 그냥 바를 사용하고 파라미터는 _ 언더바를 사용

  • 쿼리 파라미터는 옵셔널하다, 즉 파라미터가 없어도 되는 경우에 쿼리 파라미터를 사용한다.

    • id가 꼭 필요한 경우에는 url에 id/로 추가
    • id가 꼭 필요하지 않는 경우에는 url에 ?id=1 이렇게 쿼리 파라미터로 추가

  • Response의 예시

    • Response(data=data, status=200)
    • 대부분 JSON형태로 응답

  • URL 유형

    • https://.../api/users/1 => 이건 우리 API 서버라고 명확하게 해주는 것
    • https://.../users/1 => 이렇게 하면 일반 사용자가 들어가는 페이지 url를 의미
    • https://.../api/v1/users/1 => API 서버의 version 1를 의미
    • https://.../api/open/v1/.. => Open API 서버를 의미

  • 아예 물리적으로 레포지토리로 2개로 구분하여 웹 서버와 API 서버를 구분할 수도 있다.

    • 그런데 그렇게되면 관리해야 되는게 2개로 늘어나게 된다.
    • 그래서 보통은 규모가 크지 않는 이상 하나의 서버에서 웹도 제공하고 API도 제공한다.

open API

  • 누군가가 back-end를 만들어놓고 여기에 주소와 사용 규칙을 공개한 것을 의미.
  • 그래서 우리는 이 back-end의 사용규칙과 주소만 알면, front-end만 만들어도 얼마든지 요청하고 데이터를 가져와서 사용할 수 있다. 우리가 규칙에 맞게 전송하기만 하면, 지도 / 결제 / 채팅 등 다양한 기능들을 사용할 수 있다.
    • ex) 우리가 카카오 책 검색 open API 서버 주소로 어떤 책에 대한 정보를 요청하면 -> API 서버에서는 자체 DB를 뒤져서 우리가 원하는 정보를 다시 전달해준다.
  • 이러한 요청과 응답은 정해진 API 형식에 맞춰서 전달해야 한다. 이러한 형식이 작성된 문서를 API 가이드라고 한다. 요즘에는 거의 모든 API에서 JSON형태로 정보가 전달된다.

API를 통해 받은 JSON

  • API를 통해 받은 JSON 데이터를 실제 HTML 파일에 출력하려면 -> JSON 데이터를 JavaScript로 접근해야 한다.

  • 해당 JSON 데이터를 JavaScript로 console에 표시할 수 있다.

    • 그리고 Jquery를 이용해 -> html의 특정 element에 어떤 요소를 넣어줄 수 있다.
    • <script></script> 이렇게 JavaScript 코드 사이에 HTML 특정 element를 설정하고 해당 데이터를 보여줄 수 있다.

  • 참고 자료

API서버

  • API 서버에서의 요청 - 응답 통신은 일반적인 요청 - 응답과는 다른 의미가 된다.

    • API 서버에서는 브라우저에서 /posts/create/와 같이 요청을 하는 것은 "비동기식 요청" 을 위해서이다.
    • 일반적인 요청을 동기식 요청이라고 한다. 즉, 어떤 프로세스가 시작하면 이 프로세스가 끝날때까지 기다리는게 동기식 프로세스 및 요청이다. 반면에, 비동기식 요청은 버튼을 클릭했을 때 전체 페이지를 요청하고 로딩하는 것이 아니라, 일부분만 다시 그리기 위해 html 화면이 다 그려진 상태에서 일부분만 요청하는 것을 의미한다. 즉, 이미 실행되고 있는 프로세스가 종료되지 않아도 새로운 요청 및 프로세스 시작이 가능하다.
    • 이러한 비동기식 요청을 하기 위해서는 브라우저에서 특별하게 ajax 요청을 해야 한다. 즉, ajax 통신을 해야 한다.
    • 그리고 이렇게 ajax 요청에 대해서는 JSON 형태의 데이터로 응답을 해줘야 한다. django에서는 딕셔너리의 형태로 데이터를 보내줘야 하는 것이다. 즉, html 파일인 template을 응답하는 게 아니라, JSON 형태로 데이터를 응답해줘야 한다.
    • 이렇게 응답해주면, Ajax 모듈이 해당 응답을 받아서 key / value 데이터를 뽑아서 화면에 뿌려줄 수 있는 것이다.
    • 이 때, django에서는 DRF(Django REST Framework) 라이브러리가 있어야 이러한 요청을 받아서 JSON 형태의 데이터를 응답해줄 수 있다. DRF가 없는 django에서는 template만 응답으로 줄 수 밖에 없다. 그래서 django에서는 API 서버를 구축하기 위해 DRF를 사용하는 것이다.

  • 관련 개념으로는, 뷰나 리액트의 싱글페이지 어플리케이션이라는 개념이 있다.

Web이란

  • 정확한 의미의 '인터넷'은 수많은 컴퓨터들이 연결되어서 데이터를 주고받을 수 있는 네트워크, 공간을 의미

  • 우리가 편하게 사용하고 있는 무선 인터넷이나 WiFi와 같은 것들도 궁극적으로는 유선으로 연결되어 있음

  • 그래서 수없이 많은 컴퓨터가 네트워크로 연결되어 있고, 그 네트워크 안에 또다른 네트워크가 존재하기 때문에 우리는 이것을 '인터넷'이라고 부른다.

  • 우리가 인터넷을 사용한다는 것은, 우리가 이 네트워크에 컴퓨터로 접속해서 각종 텍스트나 이미지, 동영상 등의 데이터를 서로 주고 받는 것을 의미. 그것을 하나의 페이지로 주고받는 경우를 '웹 페이지'라고 볼 수 있다.

  • 이 인터넷 내에서 데이터를 주고받는 방법 중 하나가 바로 '웹 서비스' 이다. 따라서 엄밀히 말하면 인터넷과 웹은 같은 의미로 볼 수 없다.

웹사이트에서 url 요청 시 Headers

  • 브라우저에서 url를 입력하거나, 어떤 버튼을 눌러 정보를 요청할 때, 구글을 예를 들면, 자바스크립트가 구글 서버에게 요청을 보내게 된다.

  • GET 메소드로 url과 파라미터를 보내준다. 또한, 크롬 등 브라우저가 해당 서버에게 정보들을 보내준다. 접속한 사람의 언어, 접속한 디바이스(삼성, 애플..) 등 이러한 정보들을 "headers" : {....} 이렇게 담겨서 보내준다. 해당 브라우저가 어떤 버전인지도 나온다.

  • 만약 인증방식이 토큰이라면 -> 토큰도 headers에 담겨져 있다. ex) headers[‘Auth’] = token 이렇게 담긴다.

    • 토큰을 유저한테만 발급하는 게 아니라, 기기별로 발급한다.
    • 모든 기기는 고유번호가 있어서 넷플릭스나 유튜브는 기기를 맥 2대 이상 접근하면 딴 곳에서 사용중이라고 나온다. 디바이스 마다 각자 토큰을 발급해놓게 되는 것이다.
    • ex) 유튜브는 10초마다 API가 요청된다. 스트리밍은 다음 1분 30초 보고 다음 1분 30초 보고 이렇게 되고 로딩 바가 처음부터 채워지지 않는다. 그래서 활성화된 API를 찾을 수 있고 같은 계정이지만 다른 기기가 있다면 이 사람이 몇 개의 디바이스가 있는지 알 수 있다.

DNS 그리고 DNS 서버란

  • IP주소와 도메인명을 서로 교환해주는 장치를 DNS(Domain Name System)라고 한다.
  • DNS는 일반적으로 도메인을 IP로 전환하여 IP 네트워크에 통신해서 목적지 IP를 찾아가는 과정을 의미한다. 즉, 도메인과 대응된 IP 주소를 알려준다.

image

  • 일반적인 DNS의 작동방식은 위와 같다. 출처는 다음과 같다.

  • 웹사이트의 데이터가 저장되어 있는 호스팅 서버는 인터넷 회선이 연결된 컴퓨터/장치이고 IP 주소가 할당되어 있다. 그래서 이 주소가 실제 웹사이트 주소라고 할 수 있다.(ex. AWS의 EC2 서버)

    • DNS 서버(즉, 네임서버)는 이러한 IP 주소를 특정 도메인 주소와 같다는 기록을 저장해두고 인터넷 사용자들이 도메인 주소를 검색했을 때 => IP 주소로 연결되도록 해주는 것이다.

  • DNS 서버의 기본적인 IP 연결 과정
    • ex) 한 사용자가 브라우저에서 naver.com를 검색했다면, 먼저 DNS 서버로 도메인 주소가 전달이 된다. 그리고 DNS 서버 내부에서 도메인 주소를 토대로 "naver.com = 12.123.123.123" 이라는 항목을 찾아내고 다시 브라우저에게 12.123.123.123의 IP 주소를 갖고 있는 호스팅 서버(해당 웹사이트 데이터가 저장된곳)로 가라고 지시하는 것이다. 그러면 브라우저가 다시 해당 IP 주소로 접속해서 웹사이트가 보이게 된다.

  • DNS 서버 종류 구분
    • DNS 서버가 초고성능으로 세상에 단 하나만 있다면 위 내용 그대로 이해하면 되겠지만, 그렇게 간단하지않다. 세상에 도메인 수가 엄청 많기 때문에 DNS 서버 종류를 계층화해서 단계적으로 처리하게 된다.
    • 도메인의 총 관리는 ICANN에서 하기 때문에, DNS 서버도 최상위 도메인에서 개인 도메인의 서브 도메인까지 도메인 이름의 분류와 마찬가지로 디렉토리/계층 형태로 구분된다. ICANN은 모든 인터넷 도메인과 DNS 서비스를 관리하는 기구이다.
    • Root DNS Server : ICANN이 직접 관리하는 서버로, TLD DNS 서버 IP들을 저장해두고 안내하는 역할을 한다.
    • TLD(최상위 도메인, Top-Level Domain) DNS Server : 도메인 등록 기관(Registry)이 관리하는 서버로, Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 한다. 어떤 도메인 묶음이 어떤 Authoritative DNS Server에 속하는지 아는 이유는 도메인 판매 업체(Registrar)의 DNS 설정이 변경되면 도메인 등록 기관(Registry)으로 전달이 되기 때문이다.
      • 도메인 등록 기관 : .com / .net / .kr 등
    • Authoritative DNS Server : 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버이다. 그래서 권한의 의미인 Authoritative가 붙는 것이다. 일반적으로 도메인/호스팅 업체의 ‘네임서버’를 말하지만, 개인 DNS 서버 구축을 한 경우에도 여기에 해당한다.
    • Recursive DNS Server : 인터넷 사용자가 가장 먼저 접근하는 DNS 서버이다. 위 3개의 DNS 서버를 매번 거친다면 효율이 좋지 않기 때문에, 한 번 거친 후 얻은 데이터를 일정 기간(TTL/Time to Live) 동안 캐시라는 형태로 저장해 두는 서버이다. 직접 도메인과 IP 주소의 관계를 기록/저장/변경하지는 않고 캐시만을 보관하기 때문에, Authoritative와 비교되는 의미로 반복의 Recursive가 붙는다. 대표적인게 KT/LG/SK와 같은 ISP(통신사) DNS 서버가 있고, 브라우저 우회 용도로 많이 쓰는 구글 DNS, 클라우드플레어와 같은 Public DNS 서버가 있다.
    • 기본적으로 브라우저는 캐시가 저장된 Recursive 서버를 사용하고, 실제 네임서버를 설정하는 곳은 Authoritative 서버라는 점만 주의해서 이해하자. 나머지 두 서버는 컨트롤할 수 있는 영역도 아니고 언급되는 경우도 적으니 전반적인 이해를 위해서만 알고 있자.

  • DNS 서버의 자세한 IP 연결 과정

    • ex) 브라우저에서 naver.com을 검색하고 사용하고 있는 통신사인 KT DNS 서버에게 도메인 주소에 해당하는 IP 주소를 요청(브라우저 기본 DNS 설정이 통신사 DNS 서버이기 때문)
    • 통신사 DNS 서버에선 캐시 데이터가 없다는 걸 확인하고 루트 DNS 서버에게 어디로 가야 하는지 요청(캐시가 있다면 바로 Authoritative 서버에게 요청)
    • 루트 서버는 TLD DNS 서버 주소만 관리하기 때문에, xxx.com 도메인을 보고는 COM 최상위 도메인을 관리하는 TLD DNS 서버 주소를 안내
    • 통신사 DNS 서버는 COM 서버에게 어디로 가야 하는지 다시 요청
    • COM 서버는 가비아 DNS 서버에서 해당 도메인이 관리되고 있는 걸 확인하고 안내
    • 통신사 DNS 서버는 가비아 서버에게 또 다시 요청
    • 가비아 서버는 “naver.com = 12.123.123.123”이라는 정보를 확인하고 이 IP를 알려준다. 동시에 ISP 서버는 해당 정보를 캐시로 기록
    • 통신사 DNS 서버는 브라우저에게 12.123.123.123라는 IP 주소를 안내
    • 브라우저는 12.123.123.123라는 IP 주소를 갖고 있는 호스팅 서버에게 웹사이트를 출력하라고 요청
    • 이제 마지막으로 우리가 보는 웹사이트 화면이 출력

  • 참고 자료

AWS Route53이란

  • Route53이란, AWS에서 제공하는 DNS이다.

  • AWS Route53에서는 DNS 레코더 정보를 도메인 등록 대행기관(ex. 가비아)의 네임서버 정보로 입력한다. 이렇게하면 Authoritative DNS 서버의 역할을 AWS Route53이 대신 해주는 의미가 된다.

    • 그러면 이후에 도메인과 관련된 모든 작업을 AWS 내부에서만 수행할 수 있게 된다.

  • Route 53의 특징

    • Public Host zone과 Private Host zone이 존재한다. Public Host zone은 일반 네임서버로 글로벌하게 동작하고, Private Host zone은 AWS내에서만 동작한다.
    • 도메인 자체에 ALIAS(별칭)를 줄 수 있다.
    • 특정 포트에 대한 모니터링이 가능하다.
    • NS 타입 : DNS 서버 타입으로 4개의 DNS 서버를 확인할 수 있다. 이렇게 DNS 서버가 4개나 있는 이유는 서버가 1개 죽으면 우리의 서비스를 들어갈 수 없고, 서비스가 죽는것과 마찬가지이기 때문에 4개를 AWS에서 지정해준다. 이 DNS 서버를 통해 사용자가 요청을 했을 때 ip 정보를 반환해주게 된다.
    • A 타입 : A 타입은 Address의 약자이다. domain name에 하나의 IP Address가 있음을 의미한다. 즉, 하나의 도메인에 해당하는 IP 주소의 값을 가지고 있다. A 타입 생성 시, Value에는 우리의 도메인의 ip를 입력하고, 유형은 IPv4로 선택하면 된다.
    • TTL(Time To Leave) : 타입별로 설정할 수 있는 요소로 캐시가 살아있는 시간을 의미한다. 연산이나 복잡한 절차를 저장해두었다가 다음에 다시 요청이 올때 이 저장된 결과값을 가지고오면 훨씬 더 빠르게 가지고 올 수 있다. DNS를 입력했을때 그 결과 ip를 어딘가에 저장해두었다가 바로 그 ip를 반환해주게 된다.

  • 참고자료

HTTPS와 HTTP

  • HTTP는 Hyper Text Transfer Protocol의 약자로 서버와 클라이언트간에 데이터를 주고 받는 프로토콜을 의미한다. 80번 포트를 사용하고 있으며 텍스트, 이미지,영상, JSON 등등 거의 모든 형태의 데이터를 전송할 수 있다. 다만, HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이기 때문에, HTTP로 비밀번호나 주민등록번호 등을 주고 받으면 제3자가 정보를 조회할 수 있는 문제점이 있다.

  • HTTPS는 Hyper Text Transfer Protocol Secure의 약자로 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 443번 포트를 사용하고 있고 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원한다.

    • HTTPS는 SSL(Secure Sockets Layer) 이라는 보안계층 위에 HTTP를 얹어서 보안이 보장된 통신을 하는 프로토콜로 이러한 통신 방식을 SSL 암호화 통신이라고 한다. 이 SSL 암호화 통신은 공개키 암호화 방식의 알고리즘으로 구현된다.
    • 공개키 암호화 방식에는 공개키와 개인키 두 종류의 키가 존재한다. 공개키는 모두에게 공개가능한 키 / 개인키는 나만 가지고 알고 있어야 하는 키라고 생각하면 된다. 한쪽 키로 데이터를 암호화 했다면 오직 다른쪽 키로만 복호화를 할 수 있다. 개인키는 보통 서버를 운영하는 회사가 가지고 공개키는 CA(Certificate Authority)라는 인증받은 기업들에서 관리하게 된다.
    • CA는 서버 운영 기업이 넘겨준 공개키를 인증서 발급자, CA의 이름 등과 함께 묶어서 CA가 가지고 있는 개인키로 암호화해서 SSL인증서로 발급한다.
      • 그리고 클라이언트에서 요청을 하면 서버는 클라이언트에게 SSL 인증서를 보낸다.
      • 브라우저(클라이언트)는 대표적인 CA들의 리스트와 그들의 공개키를 보유하고 있다. 만약 인증서에 적힌 CA의 이름과 브라우저가 소유하고 있는 CA 이름이 같다면 CA의 공개키로 SSL 인증서를 복호화한다.
      • 이제 SSL내부에 들어있던 서버의 공개키를 가지고 요청을 암호화해서 서버에게 보낸다.
      • 서버측은 가지고 있는 개인키로 요청을 복호화하여 해석하고 응답은 다시 암호화 해서 보내게 된다. 이 과정을 통해 보안성이 강한 통신을 할 수 있게 된다.

  • 관련 블로그

쿠키와 세션

  • 쿠키와 세션을 사용해서 인증을 하는 이유
    • 일반적인 HTTP 프로토콜의 경우, Stateless 프로토콜로 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 그래서 Stateful 경우를 유지하기 위해 쿠키와 세션을 이용한다. 서버는 클라이언트가 누구인지 계속 인증할 필요 없이 쿠키와 세션을 이용하면 된다.

  • 쿠키 : 클라이언트에 저장하는 이름, 값, 만료일(저장기간), 경로 정보로 구성되어있는 사용자의 기록 정보 파일이다. 즉, 방문자의 정보를 방문자 컴퓨터의 메모리에 저장하는 것이다. 클라이언트가 페이지를 요청하면 웹 서버에서 쿠키를 생성해준다. 그래서 동일 사이트 재방문 시, 클라이언트의 PC에 해당 쿠키가 있는 경우 요청 페이지와 함께 쿠키를 전송해서 로그인을 유지할 수 있다. ex) ID나 비밀번호를 저장하거나 방문한 사이트를 저장하는 데 사용

  • 세션 : 일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다. 여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다. 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.

  • 동작 순서

    • HTTP Session 동작 순서 : 클라이언트(사용자)가 서버로 접속(http 요청)을 시도 --> 서버(웹)는 접근한 클라이언트의 request-header field인 cookie를 확인해 클라이언트가 해당 session-id를 보내왔는지 확인 --> 만약 클라이언트로부터 발송된 session-id가 없다면, 서버는 session-id를 생성해 클라이언트에게 response-header field인 set-cookie 값으로 session-id(임의의 긴 문자열)를 발행(응답) --> 클라이언트는 재접속 시, 이 쿠키를 이용해 session-id 값을 서버에 전달하고 서버에서 해당 값을 확인해서 상태를 유지시켜 준다.

  • 즉, 처음 로그인을 하면 서버 측에서 해당 로그인 정보로 세션을 생성한다. 그리고 클라이언트에게 세션의 ID를 응답으로 보낸다. 클라이언트는 응답으로 받은 세션 ID를 쿠키 저장소에 보관한다. 이후 클라이언트는 요청을 보낼때마다 세션 ID를 쿠키에서 꺼내와 HTTP 헤더에 넣어 보내고, 서버는 세션 ID를 바탕으로 저장된 세션을 탐색해 요청을 보낸 유저가 맞는지 확인, 인증하게 된다. 이게 세션 & 쿠키 방식의 인증이다. 그래서 로그인을 할 때 마다 ID와 PW를 보내지 않고 => 로그인 후 발급되는 세션 ID를 보냄으로 인증을 대체하게 된다. 이렇게 하게 되면 HTTP 요청이 가로채졌을 때 ID와 PW가 노출되지 않는다. 하지만, 세션 ID가 노출될 수는 있어 누군가가 이 세션 ID를 HTTP 헤더에 넣어 유저인척 할 수 있다.


  • 쿠키와 세션의 차이

    • 쿠키와 세션의 차이점은 크게 상태 정보의 저장 위치이다. 쿠키는 '클라이언트(=로컬 PC)'에 저장하고, 세션은 '서버'에 저장한다.
    • 쿠키도 만료기간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지될 수 있다. 또한 만료기간을 따로 지정해 쿠키를 삭제할 때까지 유지할 수도 있다. 반면에 세션도 만료기간을 정할 수 있지만, 브라우저가 종료되면 만료기간에 상관없이 삭제된다.
    • 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 session-id만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높다.

  • 참고 자료

Web 서버 및 WAS 처리 과정

  • 우리가 웹브라우져에서 들어가고 싶은 웹페이지의 주소를 쳤을때, 그 요청이 서버 컴퓨터로 가지면 해당 서버 컴퓨터의 웹 서버라는 프로그램(소프트웨어)은 서버 컴퓨터에 저장되어 있는 웹페이지 파일 중 요청과 맞는 파일을 골라 다시 우리 웹브라우저로 넘겨준다. 이 때 이 주고받는 과정들은 HTTP 규약에 따라 진행된다. 하지만, 위의 구조로는 우리가 원하는 모든 웹페이지를 받아볼 수 없다.

    • 웹페이지는 "정적 페이지"와 "동적 페이지"로 구분될 수 있다.
    • 정적 페이지는 웹브라우저(클라이언트) 요청에 항상 같은 내용을 표시하는 웹페이지이다. 서버에 이미 저장된 html, css, javascript 파일들로 구성되어있다. 누가 언제 들어가든 항상 똑같은 내용이다.
    • 동적 페이지는 요청하는 클라이언트마다 각각 다른 내용이 표시되는 웹페이지이다. 로그인 정보, 장바구니, 게시판 등 이러한 동적 페이지를 제공하기 위해선 해당 클라이언트에게만 제공되는 정보를 저장한 데이터베이스의 연동이 필요하다.

  • 웹 서버의 경우 -> 정적 페이지만 처리할 수 있다. 그래서 별도의 동적 페이지를 처리해줄 수 있는 소프트웨어 프로그램이 필요하다.

  • 그래서 등장한 것이 CGI(Common Gateway Interface)프로그램으로, C, C++, PERL, PHP, PYTHON 등의 언어로 만들어졌다. 이 프로그램은 DB관련 로직을 처리하고 동적 페이지를 만들어 웹 서버에게 넘겨준다.

    • 이 때, 이 CGI프로그램과 웹서버가 정보를 주고받는 규칙을 정의한 것이 CGI 규격이다.
    • 그러나, 전통적인 CGI방식에서는 동적 처리를 진행할때마다 개별 독립적인 프로세스를 생성하는 방식이어서 요청이 많아질 경우, 프로세스 수가 증가해 서버 컴퓨터의 메모리량이 커지고 시스템 부하 현상이 발생헀다.

  • 위의 이유로 현재는 CGI기술을 사용하지 않고 다른 방법들을 사용한다.

  • 그 다음 등장한 것이 바로 애플리케이션 서버(Web Application Server(WAS))이다. Django 서버를 예로 들 수 있다.

    • 동적 처리를 하는 응용 프로그램들을 따로 실행할 수 있는 서버를 만들어서 사용하는 방식이다.
    • 클라이언트가 동적 페이지를 요청했을 때, 웹 서버는 요청을 받아 애플리케이션 서버에게 처리를 위임한다. 그리고 애플리케이션 서버는 동적 처리를 해주는 프로그램들을 실행시켜 DB로부터 원하는 결과를 처리한 후, 다시 웹 서버에게 넘겨주고 웹 서버는 클라이언트에게 결과를 보여준다.
    • 이렇게 서버를 2개로 구분한 이유는, 서로의 역할 구분하는 것이 더 효율적이기 때문이다.

  • 오늘날 두 서버는 점점 더 전문화되는 방향으로 발전하고 있다. 웹 서버는 정적 페이지 제공 / 캐시 기능 / 프록시 기능 / http/https의 제어에 필요한 기능 / 로드밸런싱 기능 / 포트포워딩 기능 등을 제공한다.
    웹 애플리케이션 서버는 웹 서버와의 연동 규격을 잘 따르기만 하면 임의의 언어 플랫폼을 사용할 수 있어 많은 종류의 서버가 생겨났다. 자바, python 등

    • 이러한 2개의 서버를 하나의 하드웨어에서 사용하는 것 보다 나눠쓰는 것이 메모리 효율이 높아지므로 대규모 사이트의 경우, 각각의 서버를 각각의 하드웨어에 설치해서 사용하기도 한다.

  • 추가로 django의 경우, Django REST Framework를 설치하여 API 서버를 구축할 수 있다. 이러한 API 서버는 운영과 유지보수를 위해 WAS 서버와 따로 분리하여 운영하는 것이 일반적이다.

  • 참고 블로그

Celery 관련 내용

  • Celery란, python으로 작성된 비동기 작업 큐로, 비동기로 작업을 처리해서 응답시간을 줄일 수 있다.

  • Celery는 task(작업)를 Broker에게 전달하면 하나 이상의 Worker가 이를 처리하는 구조이다.

    • 때문에 celery를 사용하기 위해서는 작업 요청을 받을 Broker가 필요하다.
    • 여기서 Broker란, 요청한 작업을 담아두는 큐이고 담아둔 요청을 여러개의 worker에게 적절히 분배한다. 대표적인 Message Broker로 Redis나 RabbitMQ등이 사용된다.

  • 비동기 방식 예시

    • 이러한 비동기 작업의 사례로는, 바로 은행 전산 시스템이 있다.
      • 전국의 은행 지점에서 동시다발적으로 거래가 일어날텐데, 충돌되는 문제를 해결하기 위해 Message Broker를 이용한 비동기 작업 큐를 구축할 수 있다.
      • 모든 은행 지점에서 거래에 대한 전산 입력을 할 때마다 중앙 시스템의 메시지 큐에 순차적으로 작업을 등록시키고, 중앙 시스템은 큐에 등록된 작업을 차례대로 수행하면 충돌의 위험을 많이 줄일 수 있다.
    • 또한, 어떤 서비스에 유저가 회원가입을 할 때마다 안내 이메일을 발송하는 경우에도 비동기 방식으로 진행되는 것으로 Celery가 사용될 수 있다.

  • Celery 동작 구조

  • Celery 예시

wsgi란

  • WSGI는 Web Server Gateway Interface의 약자로, nginx와 같은 web server와 django와 같은 WAS 서버가 서로 소통할 수 있게끔 해주는 인터페이스이다. 대표적으로 gunicorn이라는 프로그램이 있다.

  • django의 runserver는 공식문서에서도 개발 및 테스트가 목적이기 때문에, 배포 환경에서는 보안에 대한 문제가 있어 사용하지 말라고 나와있다. 그래서 배포 환경에서는 wsgi를 통해서 서비스하도록 권장하고 있다.

  • wsgi를 쓴다면 django 등의 웹 프레임워크 기능을 할 수 있게 되는데, 여기에 nginx를 앞에 붙이면 더 좋은 성능을 낼 수 있다.

    • 가장 큰 이유로, nginx는 한 번에 들어오는 많은 요청들을 처리하여 로드 밸런싱 및 캐싱 기능을 해줄 수 있다는 점이다.
    • 몇몇 wsgi는 정적 파일을 지원하지 않기 때문에, nginx가 없다면 정적 파일을 django까지 요청이 도착한 다음에야 처리할 수 있으므로 성능이 저하된다.

  • 관련 블로그

uWSGI와 Gunicorn비교

  • Gunicorn은 uwsgi에 비해 Latency라고 하는 요청과 응답 사이에 경과된 시간인 대기 시간이 더 짧다. 더 빠르게 요청을 처리한다.

    • 그리고 서버의 메모리 요구사항을 의미하는 RAM Usage라고 하는 램 사용량 부분에서도 gunicorn이 uwsgi에 비해 더 낮다.

  • 반면에 uWSGI는 CPU Usage라고 하는 CPU 사용량에서는 gunicorn보다는 낮게 사용된다.

  • 결론적으로 gunicorn의 성능이 대체적으로 좋으나 uwsgi보다는 리소스가 크고, uwsgi는 리소스가 적고 가볍게 사용하기 위한 소프트웨어라고 판단하게 되었다.

    • 지금까지는 팀 및 개인 프로젝트의 규모가 그렇게 크지 않았기 때문에 조금 더 가볍게 사용할 수 있는 uwsgi를 선택해서 진행해봤다.

  • 관련 내용

  • 관련 내용 2

Nginx와 Gunicorn 둘 중 하나만 사용해도 될까

  • 클라이언트로부터 오는 HTTP 요청을 파이썬 스크립트가 요구하는 데이터 형식으로 변환하고 응답을 돌려줄 때도 파이썬 데이터를 HTTP 형식으로 바꿔주는 작업이 필요한데, 이 때 파이썬 앱 서버가 동작하는 기본적인 방식이 CGI, Common Gateway Interface이다. 그런데 CGI는 한 가지 문제점이 있었는데, 바로 요청이 들어올 때마다 파이썬 스크립트를 처음부터 실행한다는 것이다.

    • 그래서 이러한 문제점을 보완한 것이 WSGI(Web Server Gateway Interface)이고 웹 서버가 클라이언트의 요청을 받아서 스크립트에 전달해주면 스크립트는 스크립트 전체를 실행시키는 게 아니라 필요한 로직 하나만 실행한 후 결과를 응답해주는 식으로 동작함으로써 동적인 콘텐츠에 대한 요청에 빠르게 응답할 수 있게 해주는 것이다.

  • 즉, WSGI는 별도의 프레임워크 같은 게 아니라, 동적인 데이터에 대응하기 위해서 웹 서버와 파이썬 웹 앱이 어떻게 서로 동작해야 하는지에 대한 내용을 담고 있는 specification이다.

  • Nginx가 필요한 이유 -> 정적인 파일 요청을 처리하고 reverse proxy server, load balancer 등의 역할을 수행하기 위해서

    • reverse 프록시는 nginx 웹서버의 기능 중 하나로 클라이언트로부터 서버가 어떤 프로그램 , 어떤 포트로 돌고 있는지 서버의 정보를 감추는 것을 의미한다. 그래서 보안적인 측면을 강화해준다.

  • Gunicorn이 필요한 이유 -> 웹 앱에 HTTP 요청을 전달하고 응답을 되돌려주는 일을 할 WSGI server의 역할을 하기 위해서

  • Gunicorn만 써도 된다 -> Gunicorn이 WSGI middleware로서 웹 서버의 역할을 수행하기 때문에 Gunicorn만 써도 된다. 다만, Nginx가 제공하는 추가적인 혜택을 받지 못할 뿐이다.

  • Nginx만 써도 된다 -> Flask나 Django 같은 프레임워크는 WSGI interface를 이미 어느 정도 구현해놓았기 때문에 프레임워크를 사용한다면 Nginx만 써도 된다. 다만 session, cookie, routing, authentication 등의 기능을 수행해주는 middleware의 역할이 사라지기 때문에 이 부분은 자기가 하드 코딩해야 한다.

  • 관련 블로그

인바운드와 아웃바운드 규칙

  • AWS 이용 관련
  • 인바운드 규칙 : 인터넷을 포함한 외부 네트워크에서 EC2 인스턴스 또는 RDS로 향하는 정책
  • 아웃바운드 규칙 : EC2 인스턴스 또는 RDS에서 인터넷을 포함한 외부 네트워크로 향하는 정책

SSH란

  • 원격지 호스트 컴퓨터에 접속하기 위해 사용되는 인터넷 프로토콜 / 기본포트는 22번

    • 기존의 유닉스 시스템 셸에 원격 접속하기 위해 사용하던 텔넷은 암호화가 이루어지지 않아 계정 정보가 탈취될 위험이 높았으나, 여기에 암호화 기능을 추가하여 1995년에 SSH 프로토콜이 탄생
    • SSH는 암호화 기법을 사용하기 때문에, 통신이 노출된다고 하더라도 이해할 수 없는 암호화된 문자로 보이게 된다.

  • SSH 키

    • 서버에 접속할때 비밀번호 대신 key를 제출하는 방식
    • 우리가 AWS를 사용할 때 -> 이 SSH 규칙으로 터미널을 통해서 우리가 만든 가상 server에 접근할 수 있음

  • 관련 블로그

IPv4와 IPv6

  • IPv4 : Internet Protocol version 4의 약자로, 전 세계적으로 사용된 첫번째 인터넷 프로토콜이다. 32비트 방식으로, 4개로 나눠진 최대 12자리 번호로 되어있다.

    • ex) 123.123.123.123

  • IPv6 : Internet protocol version 6의 약자로, IPv4 주소의 고갈문제를 해결하기 위해서 128비트를 채택하여 2의 128승의 개수만큼 주소를 만들 수 있는 프로토콜을 의미. 아직 완전히 적용되지는 않았음.

OSI 7계층

image

  • OSI 7계층이란, 국제표준기구 ISO가 발표한 네트워크 모델이다.

  • 발표 이전에 상황을 보면, A라는 회사가 있고 네트워크 장비들끼리 통신하고 있을 때 다른 규격들을 사용하고 있는 다른 네트워크 통신 절차를 사용하고 있는 회사 B와 통신하려보니 원할하지 않았다. 그래서 1984년 iso에서 OSI모델이라는 것을 발표하게 되었다. 총 7계층으로 나눠져있다.

  • 7계층 : 어플리케이션 계층으로 직접적인 응용 서비스를 수행한 계층이다. 즉 우리가 사용하고 있는 HTTP, FTP, SMTP와 같은 프로토콜들이 속한 계층이다.

  • 6계층 : 프레젠테이션 계층으로 데이터의 변환, 데이터의 압축, 그리고 데이터 암호화가 이루어진다. 서로 다른 통신 기기간에 다른 인코딩을 사용할수 있기 때문에 해당 계층에서 데이터 변환이 이루어진다.

  • 5계층 : 세션 계층으로 세션을 열고 닫고를 제공하는 매커니즘의 계층이다. 세션은 응용프로그램간의 연결 및 유지가 될 수 있도록 해준다. 세션 도커는 체크포인트라는 것을 통해 동기화를 시켜준다.

    • 컴퓨터 a에서 b로 100MB의 데이터를 전송한다고 했을 때 체크포인트를 5mb마다 설정한다고 가정하면, 우리가 48mb 데이터를 전송하는 도중에 연결이 끊기게 되었을 때, 체크포인트 덕분에 45mb부터 다시 세션을 재개할 수 있게 된다.

  • 4계층 : 전송 계층으로 서로 다른 두 네트워크간의 전송을 담당하는 계층이다. 세그멘테이션, 흐름제어 그리고 오류제어등을 제공한다.

    • 세그멘테이션은 상위 계층의 데이터를 받아서 세그먼트라는 단위로 나누는 것을 의미한다. 한 컴퓨터에서 다른 컴퓨터로 100mb의 비디오를 전송한다고 가정할 때, 사용자가 세그멘테이션을 사용하지 않으면 이 100MB 비디오가 모두 로딩되고 나서야 비디오를 볼 수 있게 된다. 하지만 세그먼트 단위로 나누게 되면 비디오 일부분을 볼 수 있게 된다.
    • 흐름제어는 서로 다른 데이터전송량이 있을 때 다른 기기에서 전송량을 낮추는 방식을 의미한다.
    • 오류제어는 우리가 보낸 데이터가 정확히 오류 손실이 없는지, 만약 오류가 있다면 해당 데이터를 다시 보내주는 것이다.

  • 3계층 : 네트워크 계층으로 IP나 라우터장비가 속한 계층이다. 데이터의 전송을 담당하는 계층이다. 라우터는 네트워크 계층의 하드웨어이며, 호스트에다가 IP 번호를 부여하고 해당 도착지 IP까지 최적의 경로를 찾아주는 기능 제공한다. 이걸 라우팅이라고 한다. 즉 서로 다른 두 네트워크간의 전송을 담당한다.

  • 2계층 : 데이터링크 계층으로 동일한 네트워크 내에서 전송을 담당한다. 여기에도 오류제어와 흐름제어가 있다.

    • 데이터링크 계층의 데이터 단위를 Frame이라고 한다. 10개의 프레임이 있다고 가정할 때 그 중 2개의 프레임에 오류가 났을 때, 데이터링크 계층에서는 이 데이터 조각들을 그냥 버려버린다.

  • 1계층 : 물리 계층으로 0101110 이런 비트 단위들을 전기 신호로 변환해주고 전송하는 역할을 한다.

  • 현재 우리가 사용하고 있는 네트워크 모델은 OSI 모델이 아닌, TCP/IP 모델을 사용하고 있다. 현재로서는 OSI 모델은 단지 네트워크를 묘사해주기 위한 모델이다.

    • 우리가 사용하고 있는 TCP/IP 모델을 잘 살펴보면 OSI 모델의 5계층 6계층에 해당하는 세션 게층과 프레젠테이션 계층이 어플리케이션 계층으로 통합 되어있다는 것을 볼 수 있다.

  • ex) 컴퓨터 A에서 컴퓨터 B로 데이터를 보내는 상황

    • 우리는 평소 데이터를 보낼 때, HTTPS 프로토콜을 이용해서 보내게 된다. 그래서 이미 7계층인 어플리케이션 계층을 사용한 것이다. 전체적으로 상위계층에서 하위계층으로 데이터를 내려 받으면서 계층별 헤더를 붙이고 B로 보내게 되는 것이다. B에서는 해당 캡슐화된 데이터들을 다시 디캡슐레이션을 하면서 데이터를 얻는 방식이다.
    • 다시 컴퓨터 A에서 TCP/IP 모델을 기준으로 보면, 6계층 프레젠테이션 계층과 5계층 세션 계층은 건너뛰고 이 데이터를 4계층인 트랜스포트 계층으로 보낸다.
      • 이 계층에서는 먼저 TCP를 사용할 것인지 아니면 UDP를 사용할 것인지 정해야 한다. TCP는 우리가 보낸 데이터를 손실이 되었는지를 확인하고 데이터의 순서도 보장하기 때문에 조금더 신뢰적이다. 반면에 UDP는 일단 데이터를 보내고나면 그에 대한 책임을 지지 않는다. 그렇기 때문에 신뢰도는 떨어지지만 그만큼 속도가 빠르고 연속적이기 때문에 스트리밍 같은 서비스에서 많이 사용된다.
      • 트랜스포트 헤더에는 TCP인지 UDP인지에 대한 정보와 출발지와 도착지에 대한 포트 정보를 헤더에 넣어서 뒤에 붙인후 캡슐화해준다. 이에 결과물을 세그먼트라고 부른다. 이 세그먼트를 네트워크 계층으로 다시 보내준다.
    • 3계층 네트워크 계층에서는 출발지와 도착지에 대한 IP 정보를 헤더를 만들어서 세그먼트에 붙인다. 그리고 캡술화를 시키고 이를 패킷(Packet)이라고 부른다. 이 패킷을 다시 동일하게 하위 계층인 데이터링크 계층으로 보내게 된다.
    • 2계층 데이터링크 계층에서는 출발지의 Mac address와 맥주소와 가장 가까운 라우터의 Mac 주소를 넣게 된다.
      • 특이하게도 데이터링크 계층에서는 트레일러라는 정보도 붙게 된다. 이건 오류제어를 위한 정보이다. 이 데이터를 캡슐화시킨 것을 Frame이라고 한다. Frame을 다시 물리계층으로 내려 보낸다.
    • 1계층 물리계층에서는 전기신호로 바꾼 다음에 데이터를 전송하게 된다.

  • 그럼 이제 반대로 B에서는 하위계층부터 상위계층으로 올라가면서 디캡슐레이션을 하면서 결과적으로는 데이터를 받아올 수 있게 된다.

TCP와 IP

  • TCP/IP란 인터넷과 관련된 다양한 프로토콜의 집합을 의미하며, OSI 7 계층을 4계층으로 단순화한 모델을 의미한다.

    • 이미지 및 내용 참고 블로그
    • TCP/IP는 TCP 프로토콜과 IP 프로토콜이 각각 전송 계층, 인터넷 계층에서 "케이블 규격, IP 주소 지정방법, 통신 대상을 찾는 방법과 그곳에 도달하기 위한 순서 등"을 제어하는 역할을 한다.

  • TCP/IP 4계층에서 각 계층이 하는 역할

    • 응용 계층 : 응용프로그램들 간의 데이터 통신이 이루어지는 계층. 예를 들어, 메일보내기( SMTP ), 파일 전송( FTP ), 웹에 접속( HTTP ) 등이 있으며, 괄호안의 프로토콜은 각각의 통신에 사용되는 프로토콜이다.
    • 전송 계층 : 전송 계층은 인터넷 계층에서 결정한 목적지까지 실제 데이터를 신뢰성 있게 전송하는 역할. 전송 계층에는 TCP와 UDP라는 프로토콜이 존재한다.
      • TCP 프로토콜 : 연결 지향 프로토콜로, 데이터 송수신을 위해 클라이언트와 서버의 소켓이 연결되어 있어야 하며, 데이터가 유실되면 데이터 재전송을 요청함으로써 신뢰성을 보장한다.신뢰성 있는 데이터 전송이 가능하다는 장점으로 인해 HTTP, FTP, TELNET 등 대부분의 응용 계층 프로토콜의 전송 계층으로 사용된다.
      • UDP 프로토콜 : 비연결 지향 프로토콜로, 전송한 데이터가 잘 전달이 되었는지 확인하지 않고 단지 데이터만 보낸다. 즉, 신뢰적이지 않으며 대신 속도가 빠르다는 장점이 있다. 그래서 UDP 프로토콜은 음악이나 동영상 스티리밍(streaming)과 같은 서비스에 적합하다.
    • 인터넷 계층 : IP( Internet Protocol ) 프로토콜은 인터넷 계층에 존재하며, 링크 계층을 통해 물리적으로 연결된 호스트 사이에서 패킷의 전달 경로를 결정한다. 즉, IP 프로토콜은 라우팅 방법을 정의하는 것인데, 상위 계층인 전송 계층이 데이터 전달의 신뢰성을 책임진다는 가정하에 어떤 경로로 패킷을 전송할 것인가에 초점을 둔다.
    • 링크 계층 : 인터넷 계층에서 형성된 패킷을 전기신호 또는 광신호로 바꾸어 전달하는 역할

멱등성이란

  • 멱등성이란, 어떤 reqeust가 날라갔을 때 결과가 언제나 같아야 하는 것을 의미한다. HTTP 메소드 외에도 데이터베이스나 파일에 자원을 읽고 쓰는 등의 컴퓨터가 수행하는 모든 연산에 해당된다.

  • REST Method 중 멱등성을 보장하는 Method

    • 멱등성을 보장하는 Method는 GET, PUT, DELETE는 보장되고 POST는 보장되지 않는다. PATCH는 로직에 따라 다르다.
    • GET 메소드는 단지 리소스를 읽어 오는 행위를 의미하기에 아무리 여러번 수행해도 결과가 변경되지 않는다.
    • PUT 메소드도 마찬가지로 요청에 담긴 리소스로 기존 리소스를 그대로 대체해버리기 때문에 여러번 수행해도 요청에 담긴 리소스가 변하지 않는 이상 연산 결과가 동일하다. 즉, 어떤 리소스를 읽어오거나 대체하는 연산은 멱등성을 보장한다.
    • POST 요청을 반복하게 된다면 데이터들은 계속해서 추가가 될 것이고, 그 때 마다 서버의 응답은 다른 응답을 나타내며, 같은 내용이더라도 서로 다른 데이터이고 id값도 달라지기 때문에 멱등성을 보장하지 않는다.
    • DELETE 요청은 이미 존재하든, 존재하지 않든 그 데이터는 DELETE 요청을 보낸 시점에서 사라지게 되어 우리가 요청한 사항이 동일하게 이루어지고 멱등성을 보장한다.
    • PATCH 메소드는 구현 방법에 따라서 멱등성이 보장될 수도 있고, 혹은 보장되지 않을 수도 있다.
      • 예를 들어, PATCH 메소드에 수정할 리소스의 일부분만 담아서 보내는 경우에는 당연히 멱등성이 보장된다.
      • 만약, API가 호출될 때마다 조회수나 나이가 1씩 증가하는 API 로직을 구성할 경우에는 계속 변하기 때문에 멱등성이 보장되지 않는다.

  • 관련 블로그

  • 관련 블로그 2

웹소켓이란

  • 기존에는 http 프로토콜을 통해 통신을 진행할 때는 오로지 URL을 통한 요청을 보내야 응답을 받을 수 있었다. 연결이 지속적이지 못하고 변경된 데이터를 받기 위해서는 계속 요청을 보내야 하므로 비효율적이라고 볼 수 있다.

  • 이러한 문제를 해결하기 위해서 나온 것이 웹소켓이다. 웹소켓은 서버와 클라이언트 간의 효율적인 양방향 통신을 가능하게 해주는 프로토콜이다.

    • 즉, 브라우저는 서버가 직접 보내는 데이터를 받아들일 수 있고, 사용자가 다른 웹사이트로 이동하지 않아도 최신 데이터가 적용된 웹을 볼 수 있게 되는 등 연결이 끊어지지 않고 실시간으로 서버와 클라이언트가 연결되고 소통할 수 있게 해준다.

  • django에서는 django-channels라는 웹소켓을 사용하기 위한 라이브러리를 통해 실시간 채팅 기능을 구현할 수 있다.

  • 관련 블로그

NAS란

  • Network Attached Storage의 약자로 네트워크로 연결된 하드를 의미.

  • 하드와 인터넷이 결합이되어 서버의 형태로 외부든, 내부든 그 어디에서도 하드에 접속하여 데이터를 보관하고 수정하고, 관리하게 해주는 하나의 서버라고 생각하면 된다.

  • NAS를 구성하기 위해서는, 하드와 이를 서버로 만들어줄 NAS장비와 네트워크(인터넷) 망이 필요하다.

    • NAS는 네트워크망을 통해 내부 또는 외부까지도 공유되어야 하므로 고유한 주소인 IP가 있어야 하고, 컴퓨터도 똑같이 인터넷 선에 연결되어 하드의 자료를 공유할 수 있어야 한다.

  • 관련 블로그