💡 TCP/IP가 보이는 그림책을 정리한 내용입니다.
애플리케이션층의 역할 = 통신 서비스를 실현하는 것
통신 서비스에서 서버와 클라이언트와의 주고받기를 결정한는 ‘애플리케이션 프로토콜’이 있다.
통신 서비스의 실현에 중요한 역할을 하는 것은 프로토콜 뿐만이 아니다. 프로토콜과 조합해서 사용해서 서비스를 보다 편리하게 사용하도록 하는 장치도 존재한다. 예를 들면 전자메일 피로토콜인 SMTP나 POP에는 다음과 같은 원칙이 있다.
- 전자메일로 취급할 수 있는 것은 텍스트뿐이다.
- 전자메일의 제목(Subject)에 사용할 수 잇는 것은 반각 영문자와 숫자뿐이다.
하지만 실제로는 사진이나 음성 파일 등의 바이너리 데이터를 전자 메일에 첨부하거나 제목에 한글을 사용하고 있다. 이런 것을 가능하게 하는 것이 MIME(Multipurpost Internet Mail Extensions)라는 장치이다. MIME는 일반적으로 SMTP나 POP에서는 취급할 수 없는 형식의 정보를 다룰 수 있는 형태로 변환시켜 주고받을 수 있게 한다. MIME가 널리 사용되는 지금은 전자메일의 첨부 파일은 편리한 기능으로 일반적으로 사용되고 있으며, 이에 의해 메일의 용도가 넓어졌다.

TCP/IP의 5계층 중 가장 위에 위치한다.
컴퓨터끼리의 주고받기를 사용자가 이용할 수 있는 ‘통신 서비스’라는 형태로 만드는 것이 이 계층의 역할이다.
애플리케이션층의 역할은 통신 서비스를 실현하는 것이다. 그래서 이 층은 ‘송신측과 수신측’이 아니라 ‘클라이언트와 서버’라는 개념을 갖고있다.

통신 서비스에 대한 서버와 크라이언트의 주고받기를 정하는 프로토콜이 있다. 이것을 애플리케이션 프로토콜(application protocol)이라고 한다.
애플리케이션 프로토콜은 서비스를 실현할 때 어떻게 주고받으면 효율적일까를 고려하여 만들어졌다. 그래서 전자메일이나 WWW 등 서비스의 수만큼 애플리케이션 프로토콜이 존재한다.
애플리케이션층에서 추가되는 헤더를 애플리케이션 헤더라고한다. 여기에는 서비스를 실현하기 위해 가장 중요한 ‘요청과 응답’에 관한 정보가 들어있다. (프로토콜에 따라 헤더를 사용하지 않는 경우도 있다.)
아래 층(트랜스포트층)으로 가면 헤더와 데이터가 하나로 묶여버리므로, 데이터가 사용자가 해석할 수 있는 형태로 되어 있는 것은 애플리케이션층뿐이다. 트랜스포트층으로 가면서 캡슐화되어 데이터 자체는 해석할 수 없다.
애플리케이션 헤더에 무엇을 어떻게 쓸지는 프로토콜에 따라 다르다. 또 사람이 읽을 수 있는 언어(텍스트 기반)으로 쓰는 경우와 컴퓨터가 처리하기 쉬운 언어(바이너리 기발)로 쓰는 경우가 있다.
텍스트 기반으로 된 헤더에는 기본적으로 영문자와 숫자만 쓸 수 있다. 텍스트 기반이므로 사용자도 정보를 얻을 수 있다.
바이너리 기반으로 된 헤더는 사용자는 읽을 수 없지만 컴퓨터 처리는 빨라진다.
클라이언트가 서버에 서비스를 요청할 때 구체적인 데이터를 주고받지 않고 어떤 연락만 취할 때는 데이터 부분이 비어 있는 상태로 헤더만 보낸다.
HTTP 프로토콜은 하나의 요청에 대해 하나의 응답을 반환하는 간단한 프로토콜이다. 실제로 페이지를 구성하고 있는 파일 수만큼 이 작업을 반복한다.
HTTP 프로토콜에서는 ‘요청(request)’과 ‘응답(response)’이라는 두 종류의 패킷을 사용하여 텍스트 형식으로 주고받기를 수행한다.
요청 패킷
클라이언트가 서버에게 보내는 패킷
응답 패킷
서버가 클라이언트에게 보내는 패킷
HTTP 프로토콜은 원래 요청된 데이터를 반환하는 것만을 목적으로 만들어졌다. 때문에 한 번의 요청과 응답으로 통신은 완결되고, 과거 수행한 통신과 관련을 맺게되는 경우는 없다.
이렇게 한 번에 끝나는 프로토콜을 무상태 프로토콜(stateless protocol)이라고한다. 온라인 쇼핑 등 무상태로는 완전히 처리할 수 없는 서비스가 증가하고있다. 상품을 선택하는 페이지에서 상품을 선택했는데 중간에 다른 사용자가 끼어들어도 서버는 알지 못한다. 사용자에게는 계속되어 보이는 작업이라도 서버는 그런 인식이 없다. 때문에 중간에 끼어든 사용자가 있음에도 상품을 구입하는 페이지로 넘어갈 수 있다. 이러면 순서가 엉망이 되버린다.
HTTP 프로토콜의 주고받기에 관한 정보를 클라이언트측에 저장해두면 어떨까? 그리고 다음 통신때 그 정보를 서버에게 제시하면 서버는 사용자를 지정하고 이전 통신과 이어진 통신으로 취급할 수 있을 것이다. 이때 주고받는 정보를 쿠키(Cookie)라고 한다.
쿠키는 HTTP 프로토콜의 정규 장치가 아니다. 쿠키는 보통 CGI(Common Gateway Interface) 등 클라이언트로부터 요청에 맞게 웹 페이지를 작성하는 장치와 함께 사용한다.
예를 들어. 쇼핑몰에서 1000월짜리 연필과 500원짜리 지우개를 샀다고 가정해보자. 이때 CGI 프로그램은 클라이언트로부터 받은 정보(1000+500)를 사용하여 웹 페이지를 작성한다. 만든 웹 페이지에 쿠키를 붙여서 1500원으로 반환한다.
일반 웹 페이지의 주고받기와 CGI를 사용한 웹 페이지의 주고받기는 어떤 점이 다를까?
✅ 일반 웹 페이지의 경우
서버가 응답 패킷을 준비한다. 서버는 미리 저장하고 있는 웹 페이지를 반환할 뿐이다.✅ CGI를 사용한 경우
서버로부터 요청 받아서 CGI 프로그램이 응답 패킷을 준비한다. 이 때 쿠키를 사용하는 경우는 헤더 부분에 쿠키와 클라이언트에서 쿠키를 저장하기 위한 명령을 써넣는다. 여기에 써넣은 정보를 기초로 클라이언트는 쿠키를 저장한다.
클라이언트와 서버간에 쿠키를 어떻게 주고받는지 살펴보자.
클라이언트에서 서버로 요청을 보내면 서버는 응답 패킷의 응답 헤더에 쿠키의 저장을 의뢰하는 명령(set-Cookie: Number=0001)을 써 넣는다. 그러면 응답을 받아서 클라이언트에게 넘기고, 클라이언트는 부여된 쿠키를 저장한다.
다시 동일한 웹 사이트를 요청할 때는 요청 패킷의 요청 헤더에 이전에 서버로부터 부여된 쿠키를 써 넣는다. CGI 프로그램이 쿠키를 보고 사용자를 지정하여 처리한 웹 페이지를 작성한다. CGI에서 지정한 내용을 서버에 넘긴다. 서버는 클라이언트에서 넘긴다. 쿠키는 유효기간이 있으며, 기간이 지난 쿠키는 클라이언트에 의해 자동으로 삭제된다. 유효기간의 설정은 쿠기 제작자가 하지만, 설정하지 않은 경우레는 브라우저가 닫힐 때로 제한된다.
그러면 클라이언트는 이전 통신을 근거로 웹 페이지가 표시된다.
메일러를 사용하여 작성한 메일은 실제로는 텍스트 데이터로 만들어져 보내집니다.

위의 메일을 전달하기 위해 클라이언트와 서버는 자세한 연락을 취한다. 이때 클라이언트에서 서버로의 호출을 명령(command), 서버에서 클라이언트의 호출을 응답(response)라고한다.
명령과 응답은 ‘헤더 + 데이터’라는 형태를 취하지 않고 단독으로 트랜스포트 층에 전달된다.
애플리케이션층에서 명령 또는 응답이 트랜스포트층으로 넘어가면 트랜스포트층의 헤더가 붙어서 세그먼트가 된다.
APOP(Authenticated Post Office Protocol)
POP 사용자 인증시 비밀번호를 암호화하는 프로토콜IMAP4(Internet Message Access Protocol)
SMTP와 POP의 기능을 합친 프로토콜
메일을 서버 상에서 관리하는 것이 특징이다.
어디서든 메일을 읽을 수 있다, 메일 크기가 커도 클라이언트에게 부담이 가지 않는다는 것이 장점이다.
SMTP 프로토콜에서 명령은 4문자 알파벳으로, 응답은 3자리 숫자로 나타낸다.
TCP 통신이 연결되면, TCP 통신을 연결한 상대를 호출한다.
200 "서비스가 준비되었습니다."
호출이 완료되면 서버가 클라이언트에게 용건을 물어본다.
205 "용건을 말하세요"
클라이언트가 서버에게 메시지를 맡긴다.
클라이언트 "엔벨롭을 보고 보낸이와 받는이를 알립니다."
MAIL FROM:<gabsoon@ank.co.kr>
👇🏻
서버 "엔벨롭에 받은 메일을 써넣습니다."
205 "알겠습니다"
👇🏻
클라이언트 "이 수신인에게 전달해주세요"
RCPT TO:<gabsoon-k@cyber.co.kr>
👇🏻
서버 "엔벨롭에 받은 수신인을 써넣습니다."
205 "알겠습니다"
👇🏻
클라이언트 " 이제 메시지 송신을 시작합니다."
DATA
👇🏻
서버
354 "알겠습니다. 메시지를 주세요."
👇🏻
클라이언트
메시지를 보냅니다.
👇🏻
서버 "'개행+피리어드'로 메시지가 끝났습니다. 송신자에게 받았다고 알립니다."
250 "받았습니다"
메시지 전송을 끝낸 후 통신을 해제한다.
클라이언트 "통신을 끊읍시다."
QUIT
👇🏻
서버
221 "그래요"
👇🏻
TCP 통신 해제
서버간에 메일을 전송하는 경우 메일을 보내는 측이 클라이언트, 받는 측이 서버이다.
클라이언트 -SMTP→ 서버(클라이언트) 받을 때는 서버지만 전송할 때는 클라이언트가 된다. -SMTP→ 서버
MAT (Mail Transfer Agent)
전자메일 서비스에서는 메일 서버에 해당하는 프로그램MUA (Mail User Agent)
메일 클라이언트에 해당하는 프로그램
메일 서버로부터 자기앞으로 온 전자메일을 받을 때 사용하는 것이 POP 프로토콜이다. 현재는 POP3(version3)가 주류를 이루고있다.
POP3 프로토콜에서 명령은 원칙적으로 4문자의 알파벳으로, 응답은 +OK 또는 -ERR로 나타낸다
TCP 통신이 연결되면, 서버는 TCP 통신을 연결한 상대를 호출한다.
+OK QPOP mail.cyber.co.jp "누구세요?"
클라이언트는 서버에 user가 누군지 대답한다.
USER gabsoon-k "전 gabsoon-k예요"
서버는 클라이언트에게 해당 사용자의 비밀번호 입력을 요구한다.
+OK password required for gabsoon-k "비밀번호를 입력하세요"
클라이언트는 서버에게 비밀번호를 보낸다.
PASS xxxxxxx
서버는 클라이언트에게 사용자가 인증됐음을 알리고 메일 박스의 상태를 알려준다.
+OK gabsoon-k has 3 message (3000octet) "알겠습니다."
클라이언트가 서버에게 메일 박스의 상태를 확인한다.
STAT "메일 박스의 상태는?"
서버는 클라이언트에게 메일 박스의 상태를 알려준다.
+OK 3 3000 "3통 3000옥텟(=바이트)입니다."
클라이언트는 서버에게 목록을 보여달라고 요청한다.
LIST "목록을 보여주세요"
서버는 클라이언트에게 목록을 보여준다.
+OK 3 message (3000octets)
1 1000
2 1000
3 1000
.
클라이언트는 메일 목록에서 1를 달라고 요청한다.
RETR 1 "1을 주세요"
서버는 클라이언트가 1 번호의 복사본을 건내준다.
+OK 1000 octets
From: <gabsoon#ank.co.kr>
To: <gabsoon-k@cyber.co.kr>
Subject: Good Morning
클라이언트는 받은 메일을 삭제요청한다.
DELE 1 "1을 버려주세요"
서버는 1의 원래 데이터에 삭제 표시를 붙인다. 통신이 끝난 후 삭제된다.
+OK message 1 has been deleted "삭제했어요"
메일 수만큼 메일 받는 위의 과정을 반복한다.
클라이언트가 서버에게 통신을 끊어달라고 요청하면, 서버는 통신을 끊고 알려준다.
클라이언트
QUIT "통신을 끊읍시다."
서버
+OK pop server at mail.cyber.co.kr "끊었어요"
컴퓨터 안에서는 문자 코드라는 특수한 수치를 사용해 문자를 나타낸다. 전자 메일처럼 주고받는 통신 서비스에서는 문자 그 자체가 아니라 문자 코드를 주고받는다.
인코딩
일반적으로 사람이 이해하는 언어를 컴퓨터가 이해하는 언어(문자 코드)로 변환하는 것디코딩
컴퓨터가 이해하는 언어를 다시 사림이 이해하는 언어로 바꿔주는 것
아래 표는 대부분의 통신 서비스에서 사용되고 있는 문자 코드인 US-ASCII 문자표이다.
7비트를 사용하여 128개의 문자(로마자, 숫자, 기호, 제어 문자)를 나타낼 수 있다.

통신 서비스에서 사용되는 한국어 문자 코드로는 한글 완성형 코드 EUC-KR이 있다. 이것은 US-ASCII와는 달리 16비트로 구성되어있다. 한글 완성형 코드의 정식 명칭은 ISO-2002-KR 이다
전자메일에서 제목에 한글을 사용하거나 파일을 첨부할 수 있는 것은 MIME가 있기 때문이다.
평소에 아무 생각없이 사용하는 전자메일이지만 두가지 제약이 있다.
제목(Subject)에는 한글을 사용할 수 없다
전자메일의 헤더로 사용할 수 있는 문자 코드는 US-ASCII뿐이다. 헤더에 쓰여지는 정보중 하나인 제목(Subject)에도 US-ASCII로 나타낼 수 있는 문자밖에 사용할 수 없다.텍스트(문자)밖에 보낼 수 없다.
전자메일로는 텍스트밖에 보낼 수 없다.
현재는 이런 제약에 구애받지 않고 제목에 한글을 쓰거나 첨부 파일이라는 형태로 텍스트 이외의 데이터를 보낼 수 있다. 이것을 가능하게 하는 장치 중 하나가 MIME이다.
MIME는 정해진 원칙에 따라 파일을 US-ASCII 문자열로 인코딩하고 어떻게 인코딩 했는지에 대한 정보를 첨부해서 수신인에게 보냄으로써 수신측이 올바른 방법으로 디코딩할 수 있도록 하는 장치이다.
MIME 중에서도 BASE64 방식이 많이 사용되고 있다.
💡 예전에 했던 프로젝트에서 BASE64를 사용해서 Input file의 미리보기를 구현한 적이 있었다.
[React Project] Review Add input file 미리보기 (리뷰쓰기 폼 사진 첨부 미리보기)
MIME의 종류인 BASE64로 첨부파일을 인코딩하여 미리보기로 볼 수 있었구나를 깨달았다.
Q. MIME은 메일 확장자인데, 일반 첨부파일에서도 사용 가능한 이유는 뭔가요?
- TCP/IP의 5계층 중에서 통신 서비스를 실현하는 층은 무엇입니까?
애플리케이션 층
- 데이터를 처리하는 데 필요한 정보(데이터의 수신처, 제어 정보 등)를 담고 있는 것으로, 데이터의 앞에 추가되는 것을 무엇이라고 합니까?
헤더(header)
애플리케이션층에서는 데이터를 트랜스포트층으로 보낼 때 데이터에 서비스를 실현하는데 필요한 요청과 응답에 관한 정보를 붙여서 보냅니다. 이렇게 데이터에 붙여지는 정보를 헤더라고 합니다. (헤더를 사용하지 않는 프로토콜도 있습니다.)
- HTTP 프로토콜의 주고받기에 관한 정보를 클라이언측에 저장해둔 것을 무엇이라고 하나요?
쿠키(Cookie)
HTTP 프로토콜은 통신이 한 번의 요청과 응답으로 끝나버리므로 이전의 정보가 남아있지 않습니다. 주고받기 정보를 쿠키에 저장해두면 다음 통신 때 이전 회에서 이어진 통신으로 처리할 수 있습니다.
- 다음 설명 중 맞는 것에는 O, 틀린 것에서 X
- 데이터를 사용자가 해석할 수 있는 형태로 되어 있는 것은 애플리케이션층뿐이다. (O)
- 애플리케이션층에서 트랜스포트층으로 데이터를 보낼 때는 헤더와 데이터를 하나로 묶어서 보내므로 데이터가 사용자가 해석할 수 있는 형태로 되어 있는 것은 애플리케이션층 뿐이다. 이것을 데이터 캡슐화라고 한다.
- 쿠키에 저장된 데이터는 영구적이다. (X)
- 쿠키는 유효기간이 있다. 설정은 쿠키 제작자가 한다. 기간 설정을 하지 않으면 브라우저가 닫힐 때 삭제된다.
- 사람이 이해하는 언어를 컴퓨터가 이해하는 언어(문자 코드)로 변환하는 것을 디코딩, 컴퓨터가 이해하는 언어를 다시 사람이 이해하는 언어로 바꾸는 것을 인코딩이라고 한다(X)
- 컴퓨터가 이해하는 문자 코드로 변환 = 암호화한다. = 인코딩
- 사람이 이해하는 언어로 변환 = 암호를 해독한다 = 디코딩
- SMTP와 POP만을 사용한 전자메일의 제목에는 모든 영문자와 숫자만 올 수 있다(X)
- 반각 영문자와 숫자만 올 수 있다. 영문자라고 해도 전각은 올 수 없다.
- MIME를 사용하면 이런 제약없이 한글이나 한자, 그림 데이터 등을 사용할 수 있다.
- 전자메일에서 한글을 사용할 수 있게 해주거나 파일을 첨부할 수 있게 해주는 장치는 무엇일까요?
MIME
전자메일을 주고받을때 사용하는 SMTP와 POP에는 텍스트만 취급하며 제목에는 영문자와 숫자만 올 수 있다는 제약이 있습니다. SMTP와 POP에서 취급할 수 없는 형식의 정보를 처리해주는 장치가 MIME입니다. MIME 외에도 프로토콜과 함께 사용해서 서비스를 보다 편리하게 사용할 수 있도록 해주는 장치가 많이 있습니다.