HTTP, 프로토콜,API

hyo·2022년 3월 17일

API http 서버 클라이언트 프로토콜

HTTP

목록 보기

2/9

클라이언트와 서버의 통신

클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다.
요청이 있어야만 응답이 온다.

클라이언트-서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스를 전달 하지 않는다.

프로토콜(Protocol)

클라이언트와 서버간의 통신을 알아보기 전에 프로토콜(protocol)이라는 개념을 이해해본다.

프로토콜은 통신규약, 즉 약속이다.
손님이 주문을 받는 사람에게 대뜸 찾아가 외계어로 주문을 할 수 없듯, 주문을 하기 위해서는 지켜야하는 약속이 몇 가지 존재한다.

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화(응답 && 요청)를 나눈다.
HTTP를 이용해 주고받는 메시지는 HTTP 메시지 라고 부른다.

제대로 된 통신을 위해서는 규약(약속)을 지켜야만 한다.

- 프로토콜의 기능

분할 및 재조립 : 덩어리가 큰 데이터를 전송하는것은 비효율적이기 때문에 데이터를 분해하여 전송한다. 그리고 분해된 데이터를 받아 다시 조립하여 사용한다.
분해된 각각의 데이터를 패킷 이라 부른다.
캡슐화(Encapsulation) : 데이터는 그냥 전송하는것이 아닌 포장을 해야한다. 데이터를 전송할 수 있도록 포장! 필요한 정보를 헤더에 포함시킴!
ex -> 박스안에 부품들을 포장하고 내용물을 박스바깥에 적어서 정보제공!
연결 제어(Flow Control) : 데이터 전송의 시간과 양을 조절
동기화(Synchronization) : 송수신간 데이터를 주고받는 시점과 그 상태를 일치시키기위해 동기화라는 기법을 사용함
순서제어(sequence Control)패킷 전송을 효율적으로 관리하기 위해 패킷에 번호를 붙여 관리
오류제어(Error Control) : 전송과정에서 발생한 문제의 관리방법

이 밖에도 주소 설정 , 다중화 , 전송서비스 등 여러가지 기능을 갖을 수 있다.

각 프로토콜의 특성과 필요에 따라 기능들을 골라서 갖는다.

- 프로토콜의 구성요소

Syntax(형식) - 데이터를 어떻게 구성할 것인가? 어떻게 해석할 것인가?

Semeantic(의미) - 데이터를 어떻게 제어할 것인가? 오류는 어떻게 처리할 것인가?

timing(순서) - 통신하는 속도와 속도의 조절, 데이터 전송의 순서관리

- 프로토콜의 종류

그렇다면 왜이렇게 많은 프로토콜이 존재하는것일까??
데이터 통신에서는 주고받아야할 데이터의 형태, 지켜야할 수준, 우선순위 등이 다른 여러상황이 존재하고
각상황에 적합한 프로토콜이 필요하기 때문이다!

외울필요는 없지만 알아두면 좋을 프로토콜의 종류를 한번 적어보자.

OSI 7 Layers ->

HTTP : 웹에서 HTML, JSON 등의 정보를 주고받는 프로토콜
HTTPS : HTTP에서 보안이 강화된 프로토콜
FTP : 파일 전송 프로토콜
SMTP : 메일을 전송하기 위한 프로토콜
SSH : CLI 환경의 원격 컴퓨터에 접속하기 위한 프로토콜
RDP : Windows 계열의 원격 컴퓨터에 접속하기 위한 프로토콜
WebSocket : 실시간 통신, Push 등을 지원하는 프로토콜

Layer 4 (4계층) ->
TCP : HTTP, FTP 통신의 등의 근간이 되는 인터넷 프로토콜이며, 데이터전송의 신뢰성 보장(데이터 전송과정에서 데이터가 손실되는 것 방지) -> 그래서 TCP는 이메일이나 파일전송 등의 신뢰성이 필수인 데이터전송에서 사용된다.

UDP : (양방향의 TCP와는 다르게)단방향으로 작동하는 훨씬 더 단순 하고 빠르지만, 신뢰성이 낮은 인터넷 프로토콜 -> 신뢰성보다 속도를 중시하므로 실시간스트리밍, 전화에서 사용된다.

이렇게 필요에 따라 프로토콜을 선택하여 사용할 수 있다!!

면접에서 종종 묻는 경우가 있으니 알아두자!

API

컴퓨터세계에서는 "내 입맛에 맞게 알아서 음식 만들어와!" 라는 요청은 허용되지 않는다.
0과 1로 변환될 수 있는 요청을 원할 뿐이다.
정확한 주문 방법을 따라 요청해야한다.

하지만 우리는 서버가 어떻게 구성되어있는지 알 방법이없다.
코드를 직접 짠 사람도 아니기때문에 주문방법을 알리가 없다.

이에 대한 정답이 바로 API(Application Programming Interface)이다.
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(Interface)를 제공해 줘야 한다.

이것을 API 라고 한다.

서버에는 마치 식당에서 메뉴판을 제공하듯, 리소스를 잘 활용할 수 있도록 API(메뉴판)를 제공해야 한다.

API의 약자중 Interface의 사전적 의미는 "의사소통이 가능" 하도록 만들어진 "접점"을 의미한다.
API는 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스이다.

쉽게 스타벅스를 예를 들어 생각해보면,
메뉴판과 같은 역할을 한다고 볼 수 있다.

클라이언트가 스타벅스가 제공하는 자원의 종류(카페라떼,아메리카노 등)을 모른다고 가정할 경우, 엉뚱한 메뉴를 시키지않도록 도와주어야 한다. ex -> 스타벅스에서 피자를 시키지않도록!
스타벅스가 메뉴판에 아메리카노, 카페라떼 등등 적어둔 메뉴판을 설계해두었기 때문에 손님은 이에 맞게 적절한 요청을 할수 있다.

마찬가지로 서버가 리소스 전달을 위한 메뉴판, 즉 API를 구축해두어야 클라이언트가 이를 활용할 수 있다.

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 된다.