1. 어플리케이션 계층 : 사용자가 직접 사용하는 프로토콜 제공
TCP/IP 4계층에선 어플리케이션 사용자가 실제로 네트워크를 사용하기 위한 서비스 프로토콜을 제공한다. 웹 통신을 위한 HTTP, 메일 송수신을 위한 SMTP, 파일 서비스를 위한 FTP, 원격으로 서버 컴퓨터를 조작하기 위한 Telnet 및 SSH가 그 예시이다.
어플리케이션의 목적이 무궁무진한만큼 어플리케이션 프로토콜 역시 무궁무진할 수 있는데, 오늘 날 SNS 등을 포함한 대부분의 네트워크 통신은 이미 널리 보급된 HTTP(S) 프로토콜을 이용하고 있다.
사용자가 보내고자 하는 데이터가 4계층을 통과하면, 4계층 프로토콜에 맞는 헤더가 붙은 데이터가 3계층인 트랜스포트 계층으로 이동한다. 대표적으로 HTTP 헤더가 있다.
2. HTTP : 웹 통신을 위해 사용하는 프로토콜
'Hyper Text Transfer Protocol'의 약자로, 어플리케이션 계층의 가장 대표적인 프로토콜이다. 기본적으로 클라이언트와 서버간 웹 페이지 요청 응답을 위해 사용된다.
# 요청(request) / 응답(response) 구조
- 클라이언트가 웹 브라우저에 URL을 입력하여 특정 웹 페이지를 웹 서버에 요청한다.
- 이 과정을 "클라이언트의 HTTP 요청(request)"이라고 한다.
- 웹 서버는 클라이언트의 URL 요청에 맞는 HTML 응답 페이지를 구성하여 클라이언트에 응답한다.
- 이 과정을 "서버의 HTTP 응답(response)"이라고 한다.
HTTP 프로토콜에서 요청과 응답을 하는데 사용되는 데이터를 HTTP 메세지라고 부른다. 통신하고자 하는 데이터가 HTTP 프로토콜에서 사용되는 헤더로 감싸진 모양이다. 이 메세지는 어떻게 구성되어 있을까?
# HTTP 메세지 구성
- 요청 라인 : 요청 메세지의 첫째줄에 존재한다. HTTP 메소드(GET, POST, DELETE, PUT 등)와 목적지 호스트의 URL, 그리고 HTTP 버전이 공백으로 구분되어 있다.
- 상태 라인 : 응답 메세지의 첫째줄에 존재한다. HTTP 버전, 상태 코드와 응답 메세지가 공백으로 구분되어 있다. 상태 코드엔 사용자 요청에 따른 서버의 응답 상태를 알린다. 요청에 대한 응답이 잘 내려졌을 경우, 일반적으로 "200 OK" 코드를 반환한다. 상태 코드는 3개 길이의 숫자로 표현되며, 가장 앞 숫자에 따라 개략적으로 다음과 같은 의미를 가진다.
- 2XX : 요청이 성공함을 알림
- 3XX : 경로 전환이 필요함을 알림
- 4XX : 사용자 요청이 잘못되었음을 알림 (존재하지 않거나 제한된 페이지에 접근)
- 5XX : 서버 내의 오류가 발생했음을 알림
- General Header : 요청과 응답 메세지 모두에 들어있는 헤더 정보. body가 담고있는 Content type, length, language 등의 정보가 들어있다.
- Request Header : 요청 메세지의 헤더에 포함된 정보. 일반적으로 다음의 정보들이 줄마다 기록되어있다.
- Referer : 클라이언트가 현재 페이지 이전에 존재했던 페이지의 URL
- Host : 요청에 사용된 도메인 정보. 한 서버가 여러 개의 도메인을 처리하고 있을 수 있으므로, 헤더의 이 항목을 통해 어떤 도메인 요청인지 명시해야함
- Accept : 응답으로 받고자 하는 데이터 type
- origin : 특정 서버로 POST 요청을 보냈을 때, 해당 요청을 보낸 주소. CORS 에러 처리시에 사용
- Response Header : 응답 메세지의 헤더에 포함된 정보.
- Server : 응답을 보내는 서버의 소프트웨어 정보(Apache, NGINX 사양 등)
- Date : 응답 메세지 발행 시간
- CRLF : HTTP 헤더와 본문(body)를 구분해주기 위한 빈 줄
- Body : 실제 HTTP 프로토콜을 통해 교환하고자 하는 데이터가 존재한다. 요청 메세지의 경우, POST 메소드를 통해 서버에 어떤 데이터를 보내려고 할 경우 해당 데이터로 채워져있고, 웹 페이지를 응답하는 일반적인 서버 응답의 경우 HTML 파일이 존재한다.
더 자세한 헤더 정보는 위키피디아를 참조할 수 있도록 하자.
# HTTP Method
RESTful API에서 http method가 중요한 것으로 작용한다. REST란, 간단하게 말하면 사용하고자 하는 리소스를 URL에 표현하고, 자원에 대한 행위를 HTTP 메소드로 표현하는 것이다. 이를 통해 사용하는 리소스의 직관적 이해와 사용이 가능하다.
- GET : 클라이언트가 단순히 서버에 있는 리소스를 요청할 때 사용하는 메소드. query parameter을 통한 검색도 GET 메소드를 사용한다.
- POST : 로그인 폼을 제출하는 등 서버에 데이터를 업로드할 때 사용하는 메소드. HTTP 요청 메세지의 body에 해당 데이터가 위치한다.
- PUT / PATCH : 서버에 존재하는 데이터의 수정을 목적으로 하는 요청에 사용되는 메소드. PATCH는 데이터의 일부분, PUT은 데이터의 대부분을 수정한다는 작은 차이가 있다.
- DELETE : 서버에 존재하는 데이터를 지우는 요청에 사용되는 메소드.
# Stateless & Connectionless
HTTP 프로토콜은 기본적으로 무상태성(stateless)을 가진다. 한 번 request-response를 통해 메세지 교환이 끝난 뒤에는 연결을 끊는 무연결성(connectionless)도 가지고 있다. 웹 페이지를 응답받는 과정이 끝나면 서버와 클라이언트는 서로를 모르는 상태로 돌아가는 것이다. 내가 10초 전에 네이버 페이지에 접속했다고 가정하자. 바로 뒤 네이버한테 "나 방금 너한테 접속한 부추인데 나를 모르는거냐?!" 호통쳐도 네이버는 아무것도 알지 못한다. 때문에 서버에 요청을 보낼 땐 요청에 필요한 정보를 모두 담아야 한다. (물론 keep-alive를 통해 기존의 연결을 재활용하는 경우도 있지만 여기선 넘어가자)
무상태성과 무연결성엔 다음과 같은 장점이 있다.
- 스케일 아웃이 용이하다 : 서버로 사용자 요청이 몰렸을 때 추가 서버를 도입할 수 있는데, 서버가 사용자 상태를 갖는다면 새로운 서버에 이 정보를 복사하는 과정이 번거로울 수 있다.
- 로드 밸런싱이 쉽다 : 비슷한 내용으로, 사용자가 요청 메세지를 보내는 서버를 다른 서버로 옮겼을 때 기존에 사용하던 연결 정보가 필요 없다.
- 최소한의 리소스를 사용하여 자원을 절약한다 : HTTP를 통해 한 번 요청과 응답을 주고 받으면 대부분의 경우 추가적인 데이터 교환이 필요하지 않다. 요청-응답 라이프사이클이 끝나면 연결을 끊고 정보를 지워 서버 리소스 사용을 최소화할 수 있다.
그러나 웹 서비스를 이용하다 보면 서버가 요청자의 상태를 알아야 하는 상황이 온다. 사용자가 장바구니에 무언가를 담았다거나, 사용자의 로그인 정보를 유지한다든가 하는 경우가 그 예시이다. 이럴 땐 어떻게 해야할까?
# Cookie & Session
몇 가지의 방법이 있지만 가장 널리 사용되고 이해가 쉬운 쿠키&세션 방식이다. 쿠키와 세션의 동작은 다음 한 문장으로 정리된다.
쿠키로 세션을 유지한다!
쿠키는 클라이언트(브라우저)가 가진 정보, 세션은 서버가 가진 정보이다.
- 클라이언트가 서버에 처음 요청 메세지를 보낸다.
- 서버는 응답 메세지 헤더의 Set-Cookie 항목을 통해 클라이언트에게 쿠키를 보낸다. 쿠키엔 서버가 클라이언트를 식별할 수 있는 정보가 담겨있다.
- 클라이언트는 받은 쿠키를 다음 요청 메세지에 포함시켜 사용한다.
- 이제 서버는 클라이언트의 쿠키 정보를 통해 사용자를 식별하고, 그에 맞는 서비스를 제공할 수 있다.
쿠키에는 보통 세션ID를 담고있다. 전술했듯 세션은 서버가 가진 정보인데, 쿠키에 있는 세션ID를 통해 클라이언트마다 다른 세션 공간을 만들고 이를 클라이언트에 제공하는 것이다.
쿠키는 클라이언트 브라우저에 저장된 정보인만큼 보안에 취약하다. 특정 쿠키를 발행한 도메인에만 해당 쿠키를 보내거나, 만료일자를 정하는 등의 방법으로 나름대로 보안을 유지하고 있지만 가장 확실한 것은 쿠키에 중요한 정보를 저장하지 않는 것이다.
3. Telnet, SSH : 원격 컴퓨터 제어 프로토콜
EC2를 이용해 클라우드 컴퓨팅을 하거나, 원격으로 서버 컴퓨터를 제어하기 위해 통신이 필요할 때가 있다. 아니 사실 대부분이다. 이 때 사용하는 것이 Telnet이나 SSH 등의 프로토콜이다. 원격지의 컴퓨터를 명령어로 제어하기 위해 사용한다고 이해하면 될 것 같다.
putty를 통해 원격 서버의 IP주소를 입력하여 해당 서버에 접속한 뒤 서버 프로그램을 설치한 경험이 있다. 이때 ssh 프로토콜을 사용했을거라 생각하니 새롭다.
# Telnet과 SSH의 차이
- 기본적으로 하는 일은 동일하다. 원격으로 컴퓨터에 접속해 명령어를 입력할 수 있도록 한다.
- Telnet은 23번, ssh는 22번 포트를 사용한다. 통신을 하기 위해선 목적지 원격 컴퓨터에 Telnet / ssh 서버가 시작되어야 한다.
- Telnet은 평문 통신으로 보안에 취약하다. 명령어를 통해 컴퓨터를 제어하는 상황에서 보안이 보장되지 않는다는 것은 치명적이다. 따라서 현재는 SecureSHell의 약자인 SSH 프로토콜을 사용하길 권장하고, 그래야 한다.
- ssh는 암호문으로 된 메세지를 공개 키 암호화 방식으로 통신하기 때문에 통신 내용을 갈취당하더라도 보안에 안전하다.
REFERENCE
명쾌한 설명과 풍부한 그림으로 배우는 TCP/IP 쉽게, 더 쉽게 - 리브로웍스 지음, 신상재 옮김
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
https://velog.io/@wngud4950/HTTP%EC%99%80-HTTP-Header
