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