.jpg)
서버 개발을 위한 기초 상식
Table of Content
1. 네트워크
네트워크란?
•
네트워크는 여러대의 컴퓨터 또는 장비가 서로 연결되어서 정보를 주고 받을 수 있게 도와주는 기술
•
컴퓨터, 라우터, 스위치, 허브 등 각종 관련 장비들이 역할을 수행하고 정보를 주고받음
기본적인 네트워크에 대해 알아야 하는 이유?
•
우리는 사용자가 요청을 했을 때 해당 요청에 대한 응답을 수행하는 프로그램 즉, 서버를 개발하고자 함
•
따라서 사용자의 요청에서 시작하여 우리가 만든 서버에 도착하고 다시 사용자에게 까지 되돌아가는 흐름을 잘 파악할 필요가 있음
2. Client와 Server
Client와 Server
•
Client(브라우저 등)에서 Server에 정보를 요청하는 과정을 간략하게 표현한 모델
•
사용자는 브라우저(=Client)를 이용하여 서버(Server)에 정보(Data)를 요청(Request)하고 응답(Response)을 받음
◦
경우에 따라 서버가 다른 외부 API 서버에 요청을 보내고 그 응답을 클라이언트에 전달하는 클라이언트의 역할을 할 수 있음(대표 예시 소셜 로그인 등 외부 API 활용하는 경우)
•
사용자의 요청이 서버에 도달하기 위해서는 해당 서버의 정보가 필요함
◦
여기서 필요한 서버의 정보 = IP 주소
IP 주소란?
•
192.168.0.123과 같은 숫자
•
거대한 네트워크망에서 각 컴퓨터를 식별하기 위한 위치 주소이며 위와 같이 숫자로 표현 됨
•
서로 정보를 주고 받기 위해서는 IP 주소외에도 아래와 같은 추가적인 정보가 필요함
◦
게이트웨이 : 라우터(공유기 등)의 주소로, 외부 네트워크와의 통신을 담당
◦
서브넷 마스크 : 네트워크 식별자와 호스트 식별자를 구분하는 정보 (ex: 255.255.255.0)
◦
네트워크 식별자 : (ex: IP 주소의 첫 세 자리, 192.168.0)
◦
호스트 식별자 : (ex: IP 주소의 마지막 자리, 123)
◦
포트 번호: 특정 애플리케이션이나 서비스에 대한 통신 경로를 지정하는 숫자
▪
예: 웹 서버의 경우 일반적으로 포트 80(HTTP), 443(HTTPS) 사용.
•
위 정보를 토대로 네트워크 프로토콜(규칙)을 이용하여 데이터 송/수신
IP주소의 쉬운 예시
•
IP 주소를 현실 주소라는 이름에 맞게 쉽게 이해할 수 있도록 비교
택배 | 네트워크 | |
주소(IP) | 서울시 **구 **로 ***** | 192.168.0.123 |
받는 사람(포트) | Meta | 3000 |
•
우리가 택배를 받기 위해서는 택배를 받을 실제 주소와 받는 사람 이름 등 정보가 필요함
•
마찬가지로 네트워크에서도 정보를 요청 받고 전달하려면 주소에 해당하는 IP 와 받는 사람에 해당하는 port번호를 알려줘야 함
◦
요청 주소 ⇒ 192.168.0.123:3000
◦
개발과정에서 요청의 목적지 서버가 본인 컴퓨터 자체라면,
▪
요청 주소 ⇒ localhost:3000 으로 대체 가능
공인 IP, 사설 IP? 추가 지식
•
공인 IP 주소와 사설 IP 주소라는 구분이 있음
•
사실 위에 작성된 192.168.0.*** 형식은 사설 IP 주소의 일반적인 형식
•
사설 IP는?
◦
→ 공유기에서 쉽게 볼 수 있는 IP 주소의 형태
◦
홈 네트워크와 같이 라우터가 기준이며, 라우터가 발급한 가상의 IP주소
▪
따라서 내부 IP 주소라고도 불리우며 생활에서는 공유기에서 연결된 나의 컴퓨터, 노트북, 프린터 등 더하여 해당 공유기가 무선 Wifi를 제공한다면 이것과 연결된 스마트폰, 태블릿 등이 포함 될 수 있음
▪
해당 기기들의 IP 주소는 일반적으로 아래와 같은 형식으로 나타남
•
10.0.0.0 ~ 10.255.255.255
•
172.16.0.0 ~ 172.31.255.255
•
192.168.0.0 ~ 192.168.255.255
◦
→ IPTIME의 공유기는 192.168.0.1 인 것이 대표적인 예시이며 이것이 이 네트워크의 게이트웨이로 볼 수 있음
▪
각 기기가 연결 될 때, 동적(자동) 또는 정적(수동)으로 IP 주소가 발급됨
•
공인 IP는 위와 같은 라우터가 실제 인터넷에 연결되어 있는 통신사 등 인터넷 서비스가 직접적으로 연결된 IP 주소를 말함
◦
따라서 외부 IP 주소라고도 불리움
◦
해당 IP 주소는 인터넷 서비스 공급 업체(ISP, 일반적으로 통신사)를 통해 발급되며, 이 업체는 글로벌 인터넷 인프라에 연결되어 있어 인터넷을 사용자에게 제공하는 역할
◦
공유기를 통해 해당 메인의 인터넷 연결이 각 내부 IP로 분배되어 연결된 기기들이 인터넷을 사용 할 수 있는 것
◦
공인 IP 주소 확인
▪
공인 IP 주소는 일반적으로 공개하지 않는 것이 좋음
▪
하지만 서버는 웹 호스팅 등 외부 사용자들이 이용 할 수 있도록 특정 상황에서는 외부에서 접근할 수 있어야 하므로 공개되기도 함
•
프론트엔드 서버는 사용자와 직접 상호작용을 위해 외부에 노출되는 것이 일반적이지만, 백엔드 서버는 보안과 데이터 보호를 위해 외부에 노출되지 않도록 은닉, 권한 제어를 하는 편
▪
하지만 직접적으로 IP주소를 접근 하지 못하도록 권한을 제어하거나, 도메인 이름이 IP주소를 대신하여 사용 될 수 있도록 변환(DNS해석)되는 방식이 활용 됨
3. Web Server와 Web Application Server
Web Server, WAS?
•
Web Server : 클라이언트로부터 HTTP의 요청을 받아들여 정적인 콘텐츠를 사용자에게 전달해주는 역할
•
WAS(Web Application Server) : 게시물을 조회하거나 정렬하는 것 처럼 다양한 로직들을 수행하는 프로그램을 동작시키는 동적인 역할
구분의 이유와 현대의 통합
•
초창기 웹 개발은 웹서버가 동적 처리(WAS의 역할 일부)를 수행하는 방식으로 개발 됨
•
웹 애플리케이션의 복잡성이 증가하면서 웹 서버와 WAS가 분리되었고, 각자의 역할에 특화하여 성능, 보안, 확장성 측면에서 이점을 확보
•
현대의 프레임워크들은 이러한 분리된 구조의 장점을 유지하면서도, 개발 편의성과 생산성을 높이기 위해 웹 서버와 WAS의 기능을 통합하는 방향으로 발전
◦
→ Spring Boot의 내장 Tomcat, NestJS의 내장 Express와 같은 사례
◦
이러한 통합은 개발 효율을 증가시키고, 과도한 서버 설정 및 관리를 간소화 시킴
4. 요청과 응답의 흐름
ClientServer의 요청 흐름
Server의 요청 흐름
1.
특정 사이트의 주소를 입력하는 순간 = 웹 브라우저가 해당 URL 주소로 웹 서버에 홈페이지를 요청하는 것
a.
(브라우저는 먼저 DNS 조회를 통해 해당 웹 사이트의 IP 주소를 찾게 됨, IP 주소로 서버에 요청하는데 HTTP(HyperText Transfer Protocol)를 통해 요청과 데이터가 전송)
b.
Web Server는 HTTP 메시지를 확인(요청과 응답의 관문 같은 역할)
2.
요청에서 필요한 추가 데이터가 있을 경우 WAS에 전달
3.
WAS는 필요한 데이터를 내부 로직, 동적 처리, 데이터베이스 연동 등을 통해 데이터 가공을 수행
4.
WAS는 데이터 처리 결과를 웹 서버에 전달
5.
Web Server는 WAS로 부터 반환 된 데이터를 활용하여 HTML, CSS, Image 등의 정적 페이지를 구성하고 이 결과를 클라이언트 측 웹 브라우저에 응답
5. API, Restful API
Interface?
•
일반적인 소프트웨어 공학적인 의미와 프로그래밍 언어적 의미의 혼동
◦
소프트웨어 공학 또는 일반적인 의미 :
▪
서로 다른 두 개의 시스템이나 장치 간의 정보나 신호를 주고받는 접점이나 경계면
▪
예를 들어, 컴퓨터와 주변 장치(프린터, 스캐너 등) 간의 연결 지점이나 소프트웨어 간의 통신 방식 등
▪
API, UI/UX에서 사용되는 인터페이스는 이 의미가 적합함
◦
프로그래밍 언어적 의미 :
▪
클래스가 구현해야 하는 멤버(필드 또는 메서드)의 집합을 정의하는 일종의 계약(contract)
•
공통으로 연결부, 매개체라는 의미로 해석하면 위 의미의 차이를 좁힐 수 있다.
API(application programming interface)
•
API는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙
•
개발자는 다른 애플리케이션들이 서로 통신할 수 있도록 API를 표시하거나 생성해야 함
API는 하나의 “약속", “개발자의 애플리케이션 사용 설명서”
•
약속한 방식의 API 요청을 수행하면 정해진 결과물을 반환하는 것을 정의 함
•
핵심 요소는 다음과 같다.
◦
Endpoint
◦
HTTP Method
◦
요청과 응답 데이터 형태
◦
Status Code
◦
Parameter(QueryString, PathVariable)
REST, RESTful API
•
REST(Representational State Transfer) : API 작동 방식에 대한 조건을 부과하는 소프트웨어 아키텍처
•
REST 아키텍처 개념에서 강조하는 API에서 지켜야 할 규칙, 지침 일부
◦
자원(리소스)을 중심으로 설계, URI(Uniform Resource Identifier)로 식별
▪
ex) /users, /products
◦
HTTP Method 매칭
▪
GET: 자원 조회
▪
POST: 자원 생성
▪
PUT: 자원 업데이트
▪
DELETE: 자원 삭제
◦
클라이언트와 서버의 역할 구분
▪
클라이언트는 서버로부터 자원의 표현을 요청하고, 서버는 해당 표현을 반환
◦
인터페이스 일관성 확보
▪
자원 식별, 표현, 메시지 전송 방식 등을 표준화
▪
API를 쉽게 이해할 수 있도록 구성, 표현
RESTful API
•
REST 설계 규칙을 따라 설계하고 지향하는 API를 RESTful API라 함
•
REST 아키텍처는 이러한 규칙들을 통해 클라이언트와 서버 간의 상호작용을 효율적이고 유연하게 만들며, 웹 서비스의 확장성과 유지보수성을 높일 수 있음
6. HTTP
6.1 HTTP
HTTP?
•
Protocol
◦
프로토콜은 컴퓨터나 전자 기기 간에 원활하게 통신(메시지를 주고 받는)할 수 있도록 지키기로 약속한 규칙의 집합
•
HTTP(HyperText Transfer Protocol)란?
◦
데이터를 주고 받는 양식을 정의한 "통신 규약"중 하나가 HTTP 이다.
◦
매우 범용적인 양식을 포함하고 있어 있어 전 세계에서 제일 널리 쓰이는 통신 규약
◦
여기서 말하는 통신 규약이란, 컴퓨터끼리 데이터를 주고 받을 때 정해둔 약속을 의미
약속을 정해둔 이유
•
제가 여러분에게 한국어로 말을 걸면 여러분이 제 말을 한국어로 바로 이해할 수 있지만, 갑자기 제가 중국어나 불어로 말한다면 알아듣지 못하겠죠?
•
→ 컴퓨터 끼리 데이터를 주고 받을 때 정해진 규칙없이 매번 요청하는 방식이 다르다면 소통에 큰 문제가 발생
•
현재 이용되는 대부분의 웹 서버가 HTTP를 기반으로 정해준 규칙에 맞게 데이터 송/수신 하고 있음
•
또한, 모든 브라우저는 HTTP 프로토콜을 기본으로 지원하고 있기 때문에 각종 브라우저로 동일한 서비스를 이용 할 수 있는 이유
6.2 HTTP Method
HTTP Method
•
데이터를 주고 받는 양식을 정의한 "통신 규약“(프로토콜)중 하나가 HTTP라면,
•
좀 더 자세히, 주어진 리소스에 수행하길 원하는 행동, 서버가 수행해야 할 동작을 지정하는 요청을 보내는 방법은 HTTP Method로 정의
◦
HTTP Method의 종류는 총 9가지가 있다. 이 중 주로 쓰이는 메소드는 5가지로 다음과 같다.
▪
GET :리소스 조회 -> READ
▪
POST:요청 데이터 처리, 주로 등록에 사용 -> CREATE
▪
PUT :리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성 -> UPDATE
▪
DELETE :리소스 삭제 -> DELETE
▪
PATCH :리소스 부분 변경 (PUT이 전체 변경, PATCH는 일부 변경)
▪
HEAD : GET과 동일하지만 메시지 부분(body 부분)을 제외하고, 상태 줄과 헤더만 반환
▪
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
▪
CONNECT : 대상 자원으로 식별되는 서버에 대한 양방향 연결 터널을 설정
▪
TRACE : 내가보낸 통신이 어느지점에서 에러가 났는지 추적 하기 위해서 사용하는 메소드
6.3 HTTP 통신 방법
HTTP의 통신 방법
•
HTTP에서는 언제나 Request, Response라는 개념이 존재
•
서버와 브라우저의 관계로 가볍게 말해보면 아래와 같이 동작합니다.
1.
브라우저는 서버에게 자신이 원하는 페이지(URL 등의 정보)를 요청(Request)
2.
서버는 브라우저가 원하는 페이지가 있는지 확인하고, 있다면 해당 페이지에 대한 데이터를 실어 응답(Response)해줍니다. 없다면 없는 페이지에 대한 데이터를 반환.
3.
브라우저는 서버에게 전달 받은 데이터를 기반으로 브라우저에 페이지를 그려줌
브라우져를 통해 HTTP의 동작을 직접 확인하기
1.
2.
브라우저에서 F12를 누르면 개발자 도구를 열 수 있음
3.
네트워크 탭 이동
4.
이 상태에서 새로고침
•
이것이 브라우저가 지금 페이지를 보여주기 위해 서버에서 받아온 데이터 목록
•
웹 개발을 진행하면서 문제가 생겼을 때 문제에 대한 분석을 위해 개발자 도구와 네트워크 탭, 콘솔 탭의 오류 메시지를 활용
5.
6.
Headers 탭은 General / Response / Request 헤더로 구분 (주로 요청 정보를 볼 수 있는 탭)
•
General 부분
◦
요청(Request)과 응답(Response)의 추가 데이터(메타 데이터) 요약으로 볼 수 있음
▪
요청 목적지인 URL
▪
요청 방식 HTTP Method
▪
▪
요청을 수신한 서버의 IP주소
▪
요청을 보낸 페이지에 대한 응답 제한 정책
•
Request Header 부분
◦
요청(Request)과 함께 전송되는 추가 데이터 및 환경 정보 상세
•
Response Headers 부분
◦
응답(Response)과 함께 도착한 추가 데이터 및 환경 정보 상세
7.
Response 탭 선택
•
데이터, 추가데이터?
•
위에서 개발자 도구 설명에서 데이터, 추가데이터와 같은 표현에 대한 설명
◦
Headers 탭에서는 “추가 데이터” / Response 탭에서는 “데이터”
•
HTTP에는 크게 다음과 같은 구성 요소가 존재한다.
1.
Method (요청 방식)
•
GET: 이름 그대로 어떤 리소스를 얻을 때 사용
◦
브라우저의 주소창에 URL을 입력하면 GET 메서드를 사용해서 서버에 요청을 보냅니다.
•
POST: 웹 서버에 데이터를 게시할 때 사용하는게 일반적
◦
ex: 회원가입, 게시글 작성, 댓글 작성 등
•
2.
Header (추가 데이터. 메타 데이터)
•
브라우저가 어떤 페이지를 원하는지
•
요청 받은 페이지를 찾았는지
•
요청 받은 데이터를 성공적으로 찾았는지
•
어떤 형식으로 데이터를 보낼지 등
GET / HTTP/1.1
# GET 메서드를 사용하여
# 해당 페이지의 root경로(=www.danawa.com/) 리소스를
# HTTP/1.1 프로토콜로 요청하는 것을 의미
...
Plain Text
복사
•
이러한 사례 외에도 아주 다양한 의사 표현을 위한 데이터를 모두 Header 필드를 사용
•
위에서 설명 된 요청 방식인 HTTP Method 도 헤더에 포함되어 서버로 보내짐
3.
Payload (데이터. 실제 데이터)
•
클라이언트(브라우저)가 요청을 할 때에도 Payload를 보낼 수 있음
"GET Method를 제외하곤 모두 Payload를 보낼 수 있다" 는게 일반적인 규칙
→ GET Method는 일반적으로 URL의 Query String, Path Variable을 통해 데이터를 전송하기 때문
→ GET Method에서 URL 길이에 제한이 있어 큰 데이터 전송이 불가능 + 보안의 문제.. 따라서 회원가입, 글작성, 수정 등은 POST, PUT 등으로 하는 것
•
서버가 응답을 보낼 때에는 항상 Payload를 보낼 수 있음.
◦
HTTP의 Payload를 통해 대표적으로 아래와 같은 데이터들을 요청하고 응답 받을 수 있다.
◦
HTML 응답 데이터 예시
<!DOCTYPE html>
<html>
<head>
<title><%= title %></title>
</head>
<body>
<h1>Hello, <%= message %>!!</h1>
</body>
</html>
HTML
복사
◦
JSON 응답 데이터 예시
{
"name":"Meta",
"age": 20
}
JSON
복사
6.4 HTTP Status Code
HTTP Status Code
•
HTTP 상태 코드(Status Code)를 통해 브라우저와 서버간의 요청, 응답 과정에서 발생할 수 있는 상황들을 표현
◦
HTTP 상태 코드는 3자리 숫자 구성
◦
첫 번째 자리 숫자는 상태 코드의 분류를 나타내는 용도로 사용되며, 나머지 두 자리는 세부적인 정보를 표현
1xx (Informational)
2xx (Successful)
3xx (Redirection)
4xx (Client Error)
5xx (Server Error)
Related Posts
Search
