해당 포스팅은 2022학년도 동계 겨울방학 중 수강했던 "Linux 운영체제의 이해와 활용" 특강을 듣고 정리한 내용입니다.
1. 웹 서버(Web server), WAS(Web Application Server)
1-1. 웹 서버의 정의
- 웹 서버는 HTTP 프로토콜을 기반으로 웹 브라우저(웹 클라이언트)에서 특정 요청 시, 해당 요청에 대한 적절한 응답(정적 컨텐츠, Static content)을 제공할 수 있는 프로그램(소프트웨어)과 하드웨어를 가리키는 용어입니다.
- 큰 의미에서 서버(Server)는 인터넷이나 네트워크를 통해 연결된 다른 컴퓨터에게 자신의 기능이나 서비스, 데이터를 제공하는 컴퓨터 또는 동일한 기능을 수행하는 소프트웨어를 의미합니다.
1-2. 정적 컨텐츠(Static content), 동적 컨텐츠(Dynamic content)
(1) 정적 컨텐츠(Static content)
- 모든 웹 기반 응용 프로그램들은 컨텐츠를 포함하고 있습니다. 해당 컨텐츠 중 어떤 클라이언트가 어느 시점에 요청을 하던 관계없이 동일한 결과를 브라우저에 *렌더링해 주는 것을 의미합니다. HTML, CSS, JavaScript으로 작성된 이미 만들어진 결과물을 보여주는 것을 말합니다.
* 렌더링(Rendering) : 서버로부터 요청해서 받은 내용을 웹 브라우저에 표시해주는 것
(2) 동적 컨텐츠(Dynamic content)
- 동적 컨텐츠의 경우 어떤 클라이언트가, 특정 시점에 어떠한 요청을 했는지에 따라 각각 다른 결과물들이 렌더링되어야 하며 이러한 결과물들을 동적 컨텐츠라고 합니다. 쉽게 말해 클라이언트가 요청한 내용들에 따라 이에 알맞는 다양한 결과물들을 동적 컨텐츠라고 부를 수 있습니다.
1-4. WAS(Web Application Server), 웹 컨테이너(Web container)
(1) WAS(Web Application Server)
- 위에서 언급된 웹 서버로부터 들어오는 여러 가지 동적인 요청을 처리하는 서버를 의미합니다.
- 초창기 웹과 달리 시간이 지나면서 사용자의 수가 기하급수적으로 늘어남에 따라, 웹 서비스가 고도화되고 복잡해졌으며 고도화된 기능들에 맞추어 적절한 데이터를 제공해야 하는 정교한 비즈니스 로직을 요구하게 되었고 웹 서버 하나에서 이렇게 디테일한 요소까지 모두 제어할 수 없었기에 별도의 서버가 필요했고 이를 WAS(Web Application Server)라고 부르게 되었습니다.
- WAS는 웹 응용 프로그램과 서버 환경을 구성하여 동작시키는 기능을 제공하는 소프트웨어 프레임워크이며 사용자의 요청으로부터 동적 컨텐츠를 제공하기 위한 역할을 수행하며 이에 대한 결과물인 정적 컨텐츠를 반환하는 웹 서버와 구별되어 부르기도 합니다.
- 웹 서버와 웹 컨테이너를 모두 포함하는 관계로 볼 수 있습니다.
(2) 웹 컨테이너(Web container)
- 클라이언트에 요청에 맞게 가공된 동적 데이터들을 처리하여 정적인 데이터로 생성해주는 소프트웨어 모듈을 의미합니다.
- 예를 들어, 위와 같이 네이버(www.naver.com)에 접속한다고 가정해보면 최초 네이버 메인 페이지만을 보여주는 것은 미리 메인화면에 맞게 만들어진 정적 요소를 사용자에게 전달하는 것이기에 웹 서버에서 바로 처리가 가능하지만, 로그인하는 과정까지 한 번 생각해 보겠습니다.
- 위의 이미지처럼 사용자가 직접 아이디와 패스워드를 입력하여 로그인을 요청했다면, 특정 사용자가 로그인하는 화면까지 미리 정적 파일로 만들어놓을 수 없으니 이제 웹 컨테이너에서 이 부분을 처리할 차례입니다.
- 웹 서버가 사용자의 로그인 요청을 받고, 웹 컨테이너로 직접 로그인이 가능한지 추가적인 요청을 보냅니다. 이에 따라 웹 컨테이너에선 DB에 직접 접속하여 유저의 아이디와 패스워드가 존재하는지 확인 후, 로그인이 가능한 유저임을 확인하였습니다.
- 이에 따라 로그인 성공 페이지를 동적으로 생성하고 해당 결과를 웹 서버로 전달합니다.
- 전달받은 응답(로그인 성공)을 정적 파일로 변환하여 클라이언트 측으로 렌더링합니다.
1-5. 웹 서버와 WAS
- 지금까지 설명된 내용을 토대로, 단순 정적 응답만이 아닌 시시각각 변화하는 사용자의 요청에 대한 비즈니스 로직을 처리하고 이 결과값을 사용자의 웹 브라우저로 렌더링해야 하므로 WAS는 웹 서비스를 운영하는데 있어 반드시 필요합니다.
- 이를 통해 웹 서버와 WAS의 기능을 모두 수행하도록 하여 최적의 서버 환경을 구성할 수 있도록 해야 하고 웹 서버와 WAS를 각각 분리하여 운영함에 따라 아래와 같은 이점을 얻을 수 있게 되었습니다.
(1) 웹 서버의 기능과 WAS 기능을 분리, 이를 통한 서버 부하 방지
- WAS는 단순히 정적 페이지만 반환하는 것이 아닌, 사용자의 다양한 요청에 따라 많은 작업들을 처리해야 하므로 단순한 정적 컨텐츠의 렌더링은 웹 서버에서만 담당하고, 비즈니스 로직의 처리는 WAS의 웹 컨테이너에서 처리할 수 있도록 함으로써 서버의 부담을 줄이고 수행 속도를 증가시킬 수 있게 됩니다.
(2) 여러 대의 WAS 운용이 가능합니다.
(3) 여러 웹 애플리케이션 서비스를 구축할 수 있습니다.
2. HTTP(HyperText Transfer Protocol), Cookie, Session JWT(JSON Web Token)
2-1. HTTP의 정의
- HTTP는 웹 상에서 정보를 교환할 수 있는 프로토콜이며, HTML 문서를 주고받는데 사용되는 프로토콜 체계입니다 이때 TCP, UDP를 주로 사용하여 통신하게 됩니다.
2-2. HTTP의 성질 : Stateless, Connectionless
(1) HTTP 프로토콜은 일반적으로 Stateless 상태를 유지합니다.
- Stateless 상태는 서버가 클라이언트의 상태를 보존하지 않는 성질을 의미합니다.
(2) Stateless 상태를 유지할 수 있기 때문에 중간에 서버에 장애가 발생해도 다른 서버로 연결하기 때문에 별도로 문제가 발생하지 않습니다.
(3) 단, 상태를 보존하지 않기 때문에 전송해야 하는 데이터의 양이 많아집니다.
(4) HTTP 프로토콜은 Connectionless 상태를 가지고 있습니다.
- Connectionless란, 서버와 클라이언트가 요청과 응답을 한 번 주고받게 되면 이후 연결을 끊어버리는 특징을 의미합니다.
- 클라이언트가 Request를 서버로 보내면 이에 대한 Response를 보내고 연결을 종료합니다.
2-3. 인증(Authentication), 인가(Authorization)
(1) 인증(Authentication)
- 특정 서비스에 대해 일정한 권한이 주어짐을 인증해야 하는 것으로, 특정 서비스에 대한 개체(사용자)의 신원을 확인하는 것을 의미합니다.
(2) 인가(Authorization)
- 인증이 완료된 후, 특정 서비스의 어떤 리소스에 접근할 수 있는지, 어떠한 동작을 수행할 수 있는지에 대해 검증하는 것을 의미합니다.
2-4. 쿠키(Cookie), 세션(Session), JWT(JSON Web Token)
- HTTP를 사용하는 웹 응용 프로그램들은 HTTP 프로토콜의 Stateless, Connectionless 특성상, 프로토콜의 기능을 확장해서 사용자 정보를 저장하는데 이때 Cookie, Session JWT를 이용하여 사용자 인증에 대한 정보를 저장할 수 있게 됩니다.
(1) 쿠키(Cookie)
- Key, Value 형태의 문자열로 브라우저에 저장되어 사용자를 인식하거나 데이터를 저장하는 역할을 수행합니다.
- 브라우저가 종료되어도 쿠키의 유효 기간에 따라 클라이언트의 로컬에 저장되어 인증 정보가 유지됩니다.
- 사용 예시)
- 아이디, 비밀번호 저장 팝업
- 쇼핑몰 사이트의 경우 로그인 없이도 장바구니에 담기
- 자동 팝업창에서 오늘 하루 보이지 않음 등 설정하기 등...
(2) 세션(Session)
- 일정 시간 동안 동일한 사용자로부터 들어오는 일련의 요청들을 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 것을 말하며, 사용자가 웹 서버에 접속해있는 상태를 하나의 단위로 보고 이것을 세션(Session)이라고 합니다.
- 일정 시간은 사용자가 웹 브라우저에 접속 후 브라우저 연결을 종료할 때까지를 의미합니다.
- 접속하는 각 클라이언트에게 고유한 Session ID를 부여합니다.
- 클라이언트 접속 요청에 대해 Request Header에 Session ID가 존재하는지 확인하고 존재하지 않는다면, Session ID를 발급합니다. 클라이언트는 Session ID를 쿠키에 저장하여 매 요청 시마다 Session ID를 이용해 자신이 인증된 사용자라는 것을 확인하며 서비스를 이용할 수 있고 서버는 해당 Session ID를 따로 저장하여 매 접속하는 클라이언트마다 서버 본인이 가지고 있는 Session ID와 클라이언트의 Session ID를 비교하여 인증 여부를 확인합니다.
- 사용 예시)
- 웹 페이지 로그인 후, 해당 웹 페이지에서 특정 작업을 수행 시에도 로그인 상태가 유지되는 것
(3) 쿠키와 세션의 차이
- 쿠키는 별도의 인증 데이터들을 클라이언트 로컬에 직접 저장하여 서버의 자원을 사용하지 않아 속도가 빠르지만 보안에 취약하다는 단점을 가지고 있습니다.
- 세션은 쿠키를 기반으로 하고 있지만 여러 인증 데이터들이 서버에 저장되어 클라이언트의 요청 시마다 별도의 처리 과정으로 인해 서버의 자원을 소모하게 되고 클라이언트의 수가 기하급수적으로 늘어나는 서비스에 대해선 서버의 자원 소모가 극심해지면서 서버의 처리 속도가 느려질 수 있는 단점을 가지고 있지만 보안 측면에선 쿠키보다 우수합니다.
(4) JWT(JSON Web Token)
- 인증(Authentication)에 필요한 정보들을 암호화시킨 JSON 형태의 토큰을 의미하며 서버 세션 인증 방식의 단점(Stateful한 인증 방식으로, 서버의 확장성 및 이용자 수 증가에 따른 서버 부하 유지 어려움)을 극복하기 위한 JWT 토큰 인증 방식에 사용됩니다.
- JWT 기반 인증의 경우 JWT 토큰을 HTTP 헤더에 실어서 서버가 클라이언트를 식별하는 인증 방식입니다.
- 인증된 클라이언트에게 토큰을 직접 발급하고, 로그인과 같은 인증 작업 시 요청 헤더에 토큰을 직접 실어서 보내고 서버는 해당 토큰에 포함된 사용자 정보를 확인하여 인증, 인가를 처리하는 방식입니다.
- 서버 세션 방식에선 사용자의 요청에 따라 타임아웃 기간이 계속 연장되지만 토큰 인증 방식은 설계된 토큰 유효 기간에 따라 타임 아웃 시간이 각각 달라지며 연장이 불가능하고, 타임 아웃 이후에는 Token 재발급이 필요하다는 특징이 있습니다.
3. HTTP 요청과 응답 (HTTP Request & Response)
3-1. 개요
- HTTP는 웹 상에서 HTML 문서를 주고받기 위해 만들어진 통신 규약입니다.
프론트엔드 서버 ↔ 클라이언트 간의 통신
백엔드 서버 ↔ 프론트엔드 서버 간의 통신
- 위의 모든 통신 상황에서 HTTP라는 통신 프로토콜을 이용해 웹 상에서 모든 데이터를 주고받을 수 있게 됩니다.
- 클라이언트가 서버 측으로 HTTP Request(요청)을 보내면 서버는 이에 맞는 HTTP Response(응답)를 클라이언트 측으로 보냅니다.
3-2. HTTP Request(요청)의 구조
(1) Starter line - 3가지 요소로 구성됩니다.
- HTTP Method : Request의 의도를 담고있는 메서드입니다. (GET, POST, PUT, DELETE 존재)
- Request target : Request가 전송되는 목표 주소입니다.
- HTTP Version : HTTP 버전에 따라 포맷이 달라질 수 있기 때문에 버전을 명시하는 부분입니다.
(2) Headers
- Request에 대한 추가 정보를 담고있는 부분입니다.
- Request message, Body 부분의 총 길이 등 정보가 Key : Value 형태로 구성되어 있습니다.
(3) Body
- HTTP Request가 전송하는 데이터를 직접 담고있는 부분입니다.
3-3. HTTP Response(응답)의 구조
(1) Status line - 3가지 요소로 구성되며, HTTP Response의 상태를 간략하게 표시해주는 영역입니다.
- HTTP Version
- Status code
- Status text
(2) Headers
- HTTP Reponse의 Headers와 유사합니다.
- 단 이 부분에선 HTTP Response에서만 사용되는 데이터들이 담겨있습니다.
(3) Body
- HTTP Response에 대한 정보를 담고있는 영역입니다.
- 단, 데이터 전송이 필요하지 않은 Request에 대해선 해당 Body 부분이 존재하지 않을 수 있습니다.
======================================================================
해당 포스팅에 대해 내용 추가가 필요하다고 생각되면 기존 포스팅 내용에 다른 내용이 추가될 수 있습니다.
개인적으로 공부하며 정리한 내용이기에 오타나 틀린 부분이 있을 수 있습니다.
이에 대해 지적해 주시면 감사하겠습니다.
'컴퓨터 과학(Computer Science) > Linux' 카테고리의 다른 글
| [Linux] - 암호화 개념과 해시 함수(Hash function), 대칭키 암호화, 공개키 암호화 방식, SSL (0) | 2023.01.05 |
|---|---|
| [Linux] - 리눅스 파이프 명령과 리다이렉션, 디렉토리 구조, TCP/IP 네트워크, 정보 보안의 뜻 (0) | 2023.01.04 |
| [Linux] - 리눅스 개요, Virtual Box 환경 구성, SSH로 Linux에 접속하기 (0) | 2022.12.29 |
댓글