2주차 개념 스터디

HTTP(HyperText Transfer Protocol)

---

WWW(World Wide Web) 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다.

이름 그대로의 뜻으로 해석하면 하이퍼텍스트를 전송하기 위한 프로토콜(원활한 통신을 위한 통신규약)이다. 하이퍼텍스트는 참조를 통해 다른 문서로 접근하게 하는 텍스트이다. 이를 이용하여 문서를 주고받는 것이다.

HTTP는 TCP/IP 프로토콜을 기반으로 서버와 클라이언트 간에 요청과 응답을 주고받는다. HTTP도 프로토콜이고 TCP/IP도 프로토콜인데 뭔가 너무 복잡하다. 네트워크 시스템은 여러 개의 계층으로 이루어져 있고 각 계층에 해당하는 프로토콜이 존재한다. 여기서는 HTTP는 가장 최상위 계층에 속하고 TCP/IP는 그 밑의 계층에 속한다. 발신할 때는 HTTP가 TCP/IP에 데이터를 넘겨주고 수신할 때는 발신한 데이터를 TCP/IP가 받아 HTTP에 넘겨준다고 생각하면 되겠다(실제로는 훨씬 더 복잡한 과정을 거침).

또한 HTTP는 발신자와 수신자 간에 연결을 유지하지 않는다. 즉 데이터를 보낼 때마다 한쪽은 요청하고 다른 쪽은 이를 받아 응답하는 것이다.

HTTP 관련 사항들을 모두 다루기엔 내용이 너무 많기에 몇 가지 키워드를 여기서는 알아보자.

HTTP 1.1/2.0

HTTP에는 버전이 존재한다. HTTP 1.1같은 경우에는 1999년에 출시되어 지금까지도 사용되고 있다. 이 버전의 특징은 한 번의 연결당 하나의 요청과 응답을 처리한다. 그림을 보면 알겠지만 한 번에 여러 개의 리소스를 주고받는 게 불가능하기 때문에 만약 주고받는 html문서에 다수의 리소스(image, css, js, ...)가 있다면 대기시간은 리소스의 양에 비례할 것이다. 관련된 단점으로는 HOL Blocking이 발생할 수 있다. 네트워크 시스템에서는 패킷단위로 데이터가 처리되는데 패킷은 큐에 들어오고 들어온 순서대로 처리된다. HOL Blocking은 요청한 리소스가 많아 많은 패킷이 큐에 쌓이게 되면 계속해서 뒤의 패킷 처리는 지연이 되고 최악의 경우에는 패킷이 드랍되는 것이다. 또한 패킷은 header와 body로 구성되어 있는데 매 요청마다 중복된 헤더 값을 전송하게 되므로 비효율 적이다.

이후에 HTTP 2.0이 세상에 나오게 되었다. 이 버전에서는 HTTP 1.1의 문제점이 개선되었다. Multiplexed Streams로 한번의 연결에 여러 개의 메시지를 주고받을 수 있게 되었고, Stream Prioritization을 통해 리소스간 의존관계에 따라 우선순위를 설정하여 리소스 로드 문제를 해결하였다(ex. CSS파일이 우선되어야 이후 렌더링에 차질이 없음). 그 외에도 HTML 문서상에 필요한 리소스를 클라이언트 요청 없이 보내는 Server Push등의 기능을 지원한다.

요청 메서드

클라이언트가 서버에게 요구하는 것을 요청이라고 한다. 이때 HTTP는 요청 메서드를 정의하여 서버가 수행하길 원하는 행동을 정의한다. 이러한 요청 메서드의 종류는 대표적으로 4가지가 있다.

• GET : 자료를 요청할 때 사용
• POST : 자료의 생성을 요청할 때 사용
• PUT : 자료의 수정을 요청할 때 사용
• DELETE : 자료의 삭제를 요청할 때 사용

응답

서버가 요청에 대한 답변을 하는 것을 응답이라고 한다. 이때 상태코드를상태 코드를 실어서 보내는데 요청이 어떻게 처리되었는지 나타낸다. 오래된 웹페이지에 접속하면 심심찮게 404 NOT FOUND가 표시된 페이지를 볼 수 있는데 이것은 상태 코드를 의미하는 것이었다.

• 1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
• 2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
• 3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
• 4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
• 5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다

HTTPS & HTTP

자주 가는 사이트 주소를 확인해보면 https로 시작하는 경우도 있고 http로 시작하는 경우도 있다. HTTPS의 S는 'secure'을 의미한다. 즉 HTTP에 보안 기능을 추가한 것이다. HTTPS에서는 TSL handshake라는 과정을 별도로 거치게 되는데 이 과정에서 서버와 클라이언트 인증서를 검증하고 클라이언트 키를 교환한다. 쉽게 말해 암호화를 위한 준비를 하는 것이다. 이후 패킷을 주고받게 되면 패킷을 열어보았을 때 해당 패킷이 기존에 어떤 정보를 담고 있었는지 확인할 수 없게 된다. 즉 해커가 악의적인 목적으로 패킷을 가로채도 그 유의미한 정보를 얻을 수 없게 되는 것이다.

서버 & 클라이언트

클라이언트/서버는 두 개의 컴퓨터 프로그램 사이에 이루어지는 역할 관계를 나타내는 것이다. 클라이언트는 다른 프로그램에게 서비스를 요청하는 프로그램이며, 서버는 그 요청에 대해 응답을 해주는 프로그램이다.

두 지점 간 데이터를 주고받음에 있어서 정보를 요청하는 쪽은 클라이언트, 정보를 제공하는 쪽을 서버라고 한다. 온라인게임을 예로 들면 우리가 게임을 실행시킬 때, 이는 클라이언트를 실행시키는 것이다. 이 게임 클라이언트는 게임 서버와 정보를 주고받으면서 우리에게 게임이라는 서비스를 제공하는 것이다.

현재 진행 중인 스터디에서 다루고 있는 웹 또한 W3에서 동작하는 서비스이다. 즉 서비스 사용자를 client, 서비스 제공자를 server라고 할 수 있겠다.

Cookie & Session

위에서 HTTP는 '연결을 유지하지 않는다'라고 했다(현재는 연결을 유지 or 재활용하는 기능이 존재). 그리고 서버는 클라이언트의 상태 정보를 가지고 있지 않다. 하지만 포털에서 자동 로그인이 된다던가, 쇼핑몰 장바구니 정보가 계속 유지되는 경우를 볼 수 있다. 이는 바로 쿠키나 세션을 이용하기에 가능하다. 이것들을 이용하여 클라이언트의 정보를 유지할 수 있다. 이 둘의 가장 큰 차이점은 상태 정보를 어디에 저장하는가이다. 쿠키는 '클라이언트'에 저장하고 세션은 '서버'에 저장한다. 세션이 보안에 있어서 유리하지만 사용자가 많으면 서버의 자원이 크게 소모되기 때문에 쿠키와 병행하여 사용한다.

Prettier & ESLint

과제를 하다가 다른 사람이 작성한 코드를 볼 때, 같은 내용이지만 코드의 형태는 다르다. 본인은 아직까지 다른 사람들과 협업을 해본 적이 없으나 각자의 스타일대로 코드를 작성하게 되면 서로 코드를 이해하는데 어려움을 겪을 것 같다. 때문에 프로젝트 유지보수에 투자되는 소요를 최소화하기 위해 통일된 코드 작성법이 요구된다. 이것이 Prettier과 ESLint의 도입 배경이다.

ESlint는 javascript의 스타일 가이드를 따르지 않거나 문제가 있는 안티 패턴들을 찾아 일관된 코드 스타일을 작성하게 한다. Prettier는 개발자들에게 일관적인 코딩 스타일을 유지할 수 있게 도와주는 툴이다. 비슷해 보이나 ESlint는 문법 에러를 잡거나 더 좋은 문법 사용을 위해 에러 표기를 강제하는 툴이지만, Prettier는 코드 퀄리티가 아닌 스타일을 교정해준다.

Web Server

위에서 서버에 대해 간단히 언급했다. 서버의 종류는 여러 가지인데 여기서는 그중 하나인 웹서버에 대해 알아보자. 웹 서버는 하드웨어적 측면과 소프트웨어적 측면을 가지고 있다. 전자부터 살펴보면, HTML, CSS, JS 등 웹사이트를 구성하는 여러 파일들이 존재하는데 서버는 이것드을 저장하고 인터넷을 이용해 클라이언트에게 전달한다. 후자는 사용자가 호스트 파일에 접근하는 방법을 관리하고 클라이언트 요청을 처리하고 응답한다.

기본 용어 정리

• 웹 서버: 클라이언트가 서버에 요청을 보내면 이를 받아 정적 콘텐츠를 제공. 클라이언트 요청에 가장 앞에 위치
• WAS: 주로 동적 콘텐츠를 제공하기 위해 만들어진 Web Server Application
• 리버스 프락시: 내부 애플리케이션과 외부 클라이언트 사이에 위치하여 클라이언트 요청을 적절한 서버로 보내준다. 즉 사용자가 서버에 접근 시 한 단계를 거쳐야 하므로 보안적으로 우수하고 cache를 이용하여 속도에도 이점이 있다.

Apache, Nginx / Node.js

위의 3가지 모두 '웹 서버'의 역할이 가능하다. 각각 처리하는 방식에 있어서 차이를 보인다(참고자료). 아직 내가 완벽히 이해하기에는 어려운 내용들이 보인다... 그런데 실제로 서버를 구현할 때 저 중에 한 가지를 고르는 것이 아니고 연동을 해서 사용한다고 한다. 지금 학습하고 있는 node.js를 사용한다고 할 때 apache, nginx를 연동하는데 이때 apache, nginx는 위에서 설명한 리버스 프록시로써 동작하게 할 수 있다.

RDBMS / NoSQL

기본 용어 정리

• Database: 여러 사람에 의해 공유되어 사용될 목적으로 관리되는 데이터 집합
• DBMS(Database Management System): 사용자의 요청을 해석하여 데이터베이스 정보를 관리하는 SW
• SQL(Structured Query Language): 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터를 관리하기 위해 설계된 특수 목적의 프로그래밍 언어
• 스키마: DB를 구성하는 개체, 속성, 관계 및 제약조건 등에 관해 전반적으로 정의한 데이터 집합

RDBMS(Relational Database Management System)

풀네임을 해석하면 '관계형 데이터베이스 관리 시스템'이다. 데이터는 스프레드시트와 유사한 2차원 테이블 형식으로 구성되고 속성과 값을 이용해 데이터를 관리한다. 그리고 각각의 테이블은 서로 관계를 맺는다. 예를 들어 여러 직업들에 관한 정보가 담겨있는 테이블이 있고 또 직업을 포함한 회원들의 정보가 담긴 테이블이 존재한다면 두 테이블은 서로 관계를 맺을 수 있다. 한 회원의 직업 속성을 알아내고 이것을 직업 표에 대입하면 해당 직업에 대해 자세히 알 수 있을 것이다. 그리고 RDBMS는 스키마의 규격에 맞춰서 데이터를 처리해야 한다는 특징이 있다.

NoSQL(Not Only SQL)

데이터의 종류가 점점 복잡 해지고 크기도 증가함에 따라서 NoSQL이 등장하게 된다(RDBMS는 데이터에 제약이 있는 등의 특징 때문에). NoSQL은 RDBMS와 다르게 데이터와 테이블 간 관계를 정의하지 않는다. 즉 정해진 스키마가 없는 것이다. 그래서 데이터 저장을 훨씬 더 자유롭게 할 수 있다. 이로 인해 복잡하거나 용량이 큰 데이터 관리가 가능해진 것이다. NoSQL은 key-value를 이용하여 데이터 입/출력을 수행한다. 회원 목록을 예로 든다면 RDBMS에서는 한 회원은 id, 이름, 직업 등 다양한 속성을 가질 수 있었다. NoSQL에서는 id를 key로 삼는다면 이 key를 이용해 해당하는 value를 찾을 수 있는데 value에는 회원의 이름, 직업 등의 정보가 들어있을 것이다.

####참고자료
Seungho Lee / HTTP1.1 vs HTTP2.0 차이점 간단히 살펴보기 / https://medium.com/@shlee1353/http1-1-vs-http2-0-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EA%B0%84%EB%8B%A8%ED%9E%88-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0-5727b7499b78
서버구축이야기!! / 서버와 클라이언트 그리고 HTTP / https://server-talk.tistory.com/291
99CORN / 쿠키, 세션 특징 및 차이 / https://hahahoho5915.tistory.com/32
프롬의 Devlog / Prettier + Eslint / https://promm.dev/tool/prettier-eslint/
대학내일 / RDBMS와 NoSQL의 차이점 완벽 정리 / https://universitytomorrow.com/26