5계층 중에서 가장 사용자와 가까운 위치에 있는 계층이며, ‘통신 서비스를 실현하는’ 계층이다. 애플리케이션 계층에는 통신 서비스에서 서버와 클라이언트와의 주고받기를 결정하는 ‘애플리케이션 프로토콜'이 존재한다.
참고로 통신 서비스 실현에 중요한 역할을 하는 프로토콜과 함께 조합하여 사용하는 다양한 구조가 존재한다. 예를 들어 전자메일 프로토콜인 SMTP나 POP에는 다음과 같은 원칙이 있는데,
1) 전자메일로 취급할 수 있는 것은 텍스트뿐이다.
2) 전자메일의 제목(subject)에 사용할 수 있는 것은 반각 영문자와 숫자뿐이다.
그러나 실제로는 다양한 파일을 첨부하거나 제목에 한글을 사용하고 있다. 이는 MIME(Multipurpose Internet Mail Extenstion)라는 구조를 사용하기에 가능하다.
용어 정리
- HTTP(HyperText Transfer Protocol)
인터넷에서 하이퍼텍스트 문서를 전송하기 위해 사용되는 규약이다. “http://www… ”로 되어 있는 것은 www 주소에서 문서 전송을 HTTP 통신 규약으로 처리하라는 것이다.- SMTP(Simple Mail Transfer Protocol)
전자메일을 보낼 때 사용되는 TCP/IP 프로토콜이다.- POP(Post Office Protocol)
메일 서버로부터 전자메일을 받을 때 사용되는 TCP/IP 프로토콜이다.- 메일러(mailer)
전자메일을 주고받을 때 사용하는 애플리케이션 프로그램을 말하며, MAU(Mail User Agent)라고도 한다.- MIME(Multipurpose Internet Mail Extenstion)
인터넷 메일 교환을 위한 멀티미디어 문서 타입을 정의한 것이다. MIME 타입에는 text, application, image, audio, video emd 7개가 존재한다.
애플리케이션 계층의 역할
TCP/IP 5계층 중에서 가장 위에 위치했으며, 컴퓨터끼리의 주고받기를 사용자가 이용할 수 있는 ‘통신 서비스' 형태로 만드는 것이 해당 계층의 역할이다. 즉 컴퓨터끼리의 통신을 실현하기 위해 작동하며 사용자가 해석할 수 있도록 만든다.
통신 서비스를 실현하기 위해서 애플리케이션 계층은 ‘송신측과 수신측'이 아닌 ‘클라이언트와 서버'의 개념을 갖고 있다. 이 때, 서버와 클라이언트가 주고받기로 한 프로토콜을 애플리케이션 프로토콜(application protocol)이라고 한다. 애플리케이션 프로토콜은 ‘서비스를 실현할 때 어떻게 주고받으면 효율적일까'를 고려하여 만들어졌기 때문에 전자메일이나 WWW 등 서비스의 수만큼 애플리케이션 프로토콜이 존재한다.
애플리케이션 헤더
애플리케이션 계층에서 추가되는 헤더를 애플리케이션 헤더라고 하며, 서비스를 실현하기 위해 가장 중요한 ‘요청과 응답'에 관한 정보가 들어 있다(프로토콜에 따라 헤더를 사용하지 않기도 함). 아래 계층으로 가면 헤더와 데이터가 하나로 묶여버리므로, 데이터가 사용자가 해석할 수 있는 형태로 되어있는 것은 해당 계층 뿐이다. 아래 계층에서는 캐슐화되어 있기에 데이터 자체를 해석할 수 없다.
애플리케이션 헤더에 무엇을 어떻게 쓸지는 프로토콜에 따라 다르며, 사람이 읽을 수 있는 언어(텍스트 기반)로 쓰는 경우와 컴퓨터가 처리하기 쉬운 언어(바이너리 기반)로 쓰는 경우가 존재한다. 클라이언트가 서버에 서비스를 요청할 때 구체적인 데이터를 주고받지 않고 연락만 취할 때는 데이터 부분을 빈 상태로 보낸다.
HTTP 프로토콜
HTTP 프로토콜은 하나의 요청에 대해 하나의 응답을 반환하는 간단한 프로토콜이며, 실제로 페이지를 구성하는 파일 수만큼 해당 작업을 반복한다.
ex) home/index.html, home/index.gif를 각각 요청
HTTP 프로토콜에서는 ‘요청(request)’과 ‘응답(response)’라는 두 종류의 패킷을 사용하여 텍스트 형식으로 주고받기를 수행한다.
요청 패킷: 클라이언트가 서버에 보내는 패킷
- 메소드: 요청의 종류이다.(GET, PUT, …)
- 요청 헤더: 서버에 전달하는 클라이언트의 정보(처리 가능한 파일의 종류와 문자 코드, 언어 등)이다. 항목명과 정보는 콜론으로 구분한다.
- 본문: 요청 시 필요한 데이터가 들어간다. 메서드가 GET인 경우에는 비어있다.
응답 패킷: 서버가 클라이언트에 보내는 패킷
- 상태 줄: 클라이언트의 요청에 대한 처리 결과이다. (정상적으로 처리한 경우 200번대의 숫자)
- 응답 헤더: 클라이언트에게 전달할 데이터에 관한 정보이다.
- 본문: 클라이언트에게 전달할 데이터가 들어간다.
통신을 유지하는 구조
HTTP 프로토콜은 1회 완결
HTTP 프로토콜은 원래 ‘요청된 데이터를 반환하는 것'만을 목적으로 만들어졌다. 따라서 한 번의 요청과 응답으로 통신은 완결되고, 과거에 수행한 통신과 관련을 맺게 되는 경우는 없다. 즉, 각각의 통신은 서로 독립적이다. 이렇게 한 번으로 끝나는 프로토콜을 상태 비보존형 프로토콜(stateless protocol)이라고 한다. 사용자에게는 계속되어 보이는 작업이라도 서버에게는 그런 인식이 존재하지 않는다.
쿠키(Cookie)
HTTP 프로토콜의 주고받기에 관한 정보를 클라이언트측에 저장해두고 다음 통신때 그 정보를 서버에게 제시하면 서버는 사용자를 지정하고 이전 회에서 이어진 통신으로 취급할 수 있다. 이때 주고받는 정보를 쿠키(Cookie)라고 한다. 즉 이전 서버로부터 받은 쿠키가 회원증 기능을 한다.
쿠키는 HTTP 프로토콜의 정규 장치가 아니며, 쿠키는 보통 CGI(Common Gateway Interface) 등 클라이언트로부터 요청에 맞게 웹 페이지를 작성하는 장치와 함께 사용한다. 즉 CGI 프로그램에서는 클라이언트로부터 받은 정보를 사용하여 웹 페이지를 작성하고, 만든 웹 페이지에 쿠키를 붙여서 반환한다.
- 일반 웹 페이지의 경우
서버가 응답 패킷을 준비하며, 미리 저장하고 있는 웹 페이지를 반환할 뿐이다. - CGI를 사용한 경우
서버로부터 요청을 받아서 CGI 프로그램이 응답 패킷을 준비한다. 이 때 쿠키를 사용하는 경우는 헤더 부분에 쿠키와 ‘클라이언트에서 쿠키를 저장하기 위한 명령'을 써넣는다. 여기서 써넣은 정보를 기초로 클라이언트는 쿠키를 저장한다.
쿠키 주고 받기
클라이언트에서 서버로 요청을 보내면, CGI 프로그램이 응답 패킷의 응답 헤더에 쿠키의 저장을 의뢰하는 명령을 써넣는다. 해당 패킷을 클라이언트가 응답으로 받으며 부여된 쿠키를 저장한다.
다시 동일한 웹 사이트를 요청할 때는, 클라이언트에서 요청 패킷의 요청 헤더에 이전에 서버로부터 부여된 쿠키를 써 넣는다. 해당 요청이 서버로 전송되고, CGI 프로그램에서는 쿠키를 보고 사용자를 지정하여 처리한 웹 페이지를 작성한다. 클라이언트에서는 해당 페이지를 응답으로 받게되며 이전 통신을 근거로 웹 페이지가 표시된다.
쿠키에는 유효기간이 있으며, 기간이 지난 쿠키는 클라이언트에 의해 자동적으로 삭제된다. 유효기간의 설정은 쿠키 제작자가 하지만, 설정하지 않은 경우에는 ‘브라우저가 닫힐 때'로 제한된다.
SSL/TLS
SSL(Secure Sockets Layer)은 인터넷 상에서 데이터 통신을 암호화하는 프로토콜이다. SSL을 바탕으로 표준화한 것이 TLS(Transport Layer Security)이다. SSL이라는 이름이 널리 보급되어 있어, SSL/TLS라고 병기하는 경우도 많다.
확인 방법
브라우저로 표시한 웹페이지가 SSL/TLS로 보호되는 경우,
- 일반적인 브라우저에서 주소창 등에 열쇠 마크가 표시된다.
- URL이 ‘http’가 아닌 ‘https’로 시작된다.
HTTPS에서는 HTTP와 다른 포트를 사용한다.
SSL/TLS의 구조
1) WWW 클라이언트에서 WWW 서버로 SSL/TLS를 적용한 웹 페이지를 요청한다.
2) WWW 서버에서 증명서를 보내오게 해서 공개키(로그인 전용)와 비밀키(해제 전용)를 준비한다.
- 공개키로 로그인한 것은 비밀키로 해제할 수 있다.
- 키와 증명서의 관리는 인증기관(CA)이 수행한다.
3) ‘공개키’와 인증서를 발행하여 WWW 서버에서 WWW 클라이언트로 보낸다.
4) WWW 클라이언트에서 증명서가 신뢰할 수 있는지 확인한다.
5) WWW 클라이언트에서 열고 닫기가 가능한 ‘공통키'를 만든다.
6) WWW 클라이언트에서 데이터를 ‘공통키'로 암호화하고, ‘공통키’를 ‘공개키'로 암호화한다.
7) WWW 클라이언트에서 WWW 서버로 암호화한 키와 데이터를 송신한다.
8) WWW 서버에서 암호화된 ‘공통키'를 ‘비밀키'로 해제하고, 암호화된 데이터를 ‘공통키'로 해제한다.
9) 이후부터는 ‘공통키'로 암호화하여 주고받기를 한다.
전자메일 주고 받기
메일러를 사용하여 작성한 메일은 실제로는 다음과 같은 텍스트 데이터로 만들어져 보내진다. 메일헤더, 빈줄, 메일 본문이 실제 메시지 부분이다. (메일러에 따라 표시되는 항목 차이 존재)
엔벨롭(envelop)
보내는 이와 받는 이의 주소 등이 들어가며, SMTP에서 사용한다.MAIL FROML: <id@domain.co.kr> RCPT TO: <id-to@domain2.com>
메일 헤더
서버로 전달되는 클라이언트의 정보가 들어간다. 항목명과 정보는 콜론으로 구분하며 중계한 메일 서버는 Recieved 등의 항목을 필요에 맞게 추가한다.From: id@domain.co.kr To: id-to@domain2.com Subject: Mail Example Date: Mon, 15 August 2022 12:00:00:00 GMT ...
빈줄
빈줄로 헤더와 메시지의 경계를 나타낸다.
메일 본문
cf) 메시지 종료 부호는 ‘개행+피리어드(.)’이다.
명령과 응답
메일을 전달하기 위해 클라이언트와 서버는 자세한 연락을 취하는데, 이때 클라이언트에서 서버로의 호출을 명령(command), 서버에서 클라이언트로의 호출을 응답(response)라고 한다. 또 명령과 응답은 ‘헤더 + 데이터'의 형태를 취하지 않고 단독으로 트랜스포트 계층에 전달된다.
cf) 기타 프로토콜
- APOP(Authenticated Post Office Protocol): POP 사용자 인증 시 비밀번호를 암호화하는 프로토콜이다.
- IMAP4(Internet Message Access Protocol): SMTP와 POP의 기능을 합친 프로토콜이다. 메일을 서버 상에서 관리하는 것이 특징으로 어디서든 메일을 읽을 수 있고, 메일 크기가 커도 클라이언트에게 부담이 가지 않는다는 장점이 있다.
SMTP 프로토콜
메일을 수신의 메일 서버까지 전송하는 프로토콜이며, 명령은 ‘4문자 알파벳’으로, 응답은 ‘3자리 숫자'로 나타낸다.
클라이언트 = 메일주소(id@domain.co.kr) ←TCP 통신→ 서버(mail.domain.co.kr)
- 통신 연결
서버에서 TCP 통신을 연결한 상대를 호출한다. - 서비스 준비 - 서버에 메시지를 맡기기
1) 클라이언트에서 엔벨롭을 보고 보낸이와 받는이를 서버측에 알린다.
2) 서버에서는 받은 정보를 엔벨롭에 써넣는다.
3) 클라이언트에서 서버로 메시지까지 송신을 한다. - ‘개행+피리어드'로 메시지 종료 판단 - 통신 해제
서버 간에 메일을 전송하는 경우 메일을 보내는 측이 클라이언트, 받는 측이 서버가 된다.
MTA/MUA
전자메일 서비스에서는 메일 서버에 해당하는 프로그램을 MTA(Mail Transfer Agent), 메일 클라이언에 해당하는 프로그램을 MUA(Mail User Agent)라고 한다.
POP 프로토콜
메일 서버로부터 자기 앞으로 온 전자메일을 받을 때 사용하는 프로토콜이며, POP3가 주류를 이루고 있다. 명령은 원칙적으로 ‘4문자의 알파벳', 응답은 ‘+OK’ 또는 ‘-ERR’로 나타낸다.
클라이언트 = 메일주소(id-to@domain2.com) ←TCP 통신→ 서버(mail.domain2.com)
- 통신 연결 및 사용자 인증
서버에서 TCP 통신을 연결한 상대를 호출한다. - 누구인지와 비밀번호 입력 과정을 포함 - 메일 박스의 상태 확인
메일 박스의 상태와 목록을 확인한다. - 메일 받기
1) 서버에서 클라이언트로 1의 복사본을 건네주고, 클라이언트에서는 서버로 1을 삭제하라는 요청을 보내게 된다.
2) 서버에에서는1의 원래 데이터에 삭제 표시를 붙이고, 추후 통신이 끝난 후 삭제한다.
3) 메일 수만큼 반복한다. - 통신 해제
문자 코드
대부분의 통신 서비스에서 주고받는 정보에는 ‘문자가’ 포함되어 있지만, 문자 그 자체를 주고받는 것은 아니다. 컴퓨터 안에서는 문자 코드라는 특수한 수치를 사용하여 문자를 나타내며 문자를 주고받는 통신 서비스에서는 문자 그 자체가 아닌 문자 코드를 주고받는다.
- 인코딩: 사람이 이해하는 언어를 컴퓨터가 이해하는 언어(문자 코드)로 변환하는 것
- 디코딩: 컴퓨터가 이해하는 언어를 다시 사람이 이해하는 언어로 바꾸는 것
대부분의 통신 서비스에서는 US-ASCII 문자표를 문자 코드로 사용하고 있으며, 7비트를 사용하여 128개의 문자(로마자, 숫자, 기호, 제어 문자)를 나타낼 수 있다. 한국어 문자코드로는 한글 완성형 코드 EUC-KR이 있으며 16비트로 구성되어 있다.
MIME
전자메일에는 다음과 같은 제약이 존재한다.
- 제목(Subject)에는 한글을 사용할 수 없다.
전자메일의 헤더로 사용할 수 있는 문자 코드는 US-ASCII 뿐이므로 헤더 내 정보인 ‘제목(Subject)’에도 US-ASCII로 나타낼 수 있는 문자만 사용할 수 있다. - 테스트(문자)밖에 보낼 수 없다.
그러나 현재에는 위와 같은 제약에 구애 받지 않고 제목에 한글을 사용하거나 첨부파일이라는 형태로 텍스트 이외의 데이터를 보낼 수 있다. 이를 가능하게 하는 장치 중 하나가 MIME(Multipurpose Internet Mail Extension)이다.
MIME는 정해진 원칙에 따라 파일을 US-ASCII 문자열로 인코딩하고 어떻게 인코딩했는지에 대한 정보를 첨부해서 수신인에게 보냄으로써 수신측이 올바른 방법으로 디코딩할 수 있도록 한다.
한글 제목은 인코딩
Subject: =?iso-2022-kr?...
데이터를 디코딩할 때 필요한 정보
MIME=Version: 1.0 X-Mailer: ... Content-Type: multipart/mixed; boundary="--_border_" Content-Transfer-Encoding: 7bit
boundary=“--border_”로 파일의 경계를 가르키는 문자열을 정의한다.
메시지 및 첨부파일 정보
--_border_ Content-Type: text/plain; charset="ISO-2022-KR" Content-Transfer-Encoding: 7bit 안녕하세요 ... ## 메시지 --_border_ Content-Type: Image/Jpeg Content-Transfer-Encoding: base64 ... ## 인코딩한 첨부파일 --_border_-- ## 마지막 경계 . ## 종료 부호파일의 경계를 나타내는 문자열
--_border_과 함께,Content-Type나Content-Transfer-Encoding등으로 파일의 종류나 사용한 인코딩의 종류 등을 표시한다.
위의 정보를 송신측에서 수신측으로 보내게 되고, 수신측이 가리키는 인코딩 방법에 따라 제목과 첨부 파일을 디코딩한다. MIME 중에서 BASE64 방식이 많이 사용되고 있다.
애플리케이션 프로토콜은 두가지로 분류되는데, 하나는 일반 사용자에게도 친숙한 통신 서비스를 제공하는 프로토콜이고(HTTP, SMTP, TELNET 등), 다른 하나는 네트워크 관리자 이외에는 의식할 일이 없는 뒤에서 통신을 지원하는 프로토콜이다.(DNS, NAT, DHCP)
- SNMP(Simple Network Management Protocol)
네트워크의 일괄 관리를 수행하는 프로토콜이다. 접속되어 있는 네트워크 기기의 전원 상태나 문제가 발생하지 않았는지를 확인할 수 있으며, 프린터의 토너 유무까지 조사한다. 관리하는 기기를 SNMP 매니저, 관리 받는 기기를 SNMP 에이전트라고 하며, 각각 전용 소프트웨어를 설치해야 한다. - NTP(Network Time Protocol)
네트워크 상에 있는 기기의 시각 대조를 수행하는 프로토콜이다. 기준이 되는 시각 정보를 관리 및 제공하는 기기를 NTP 서버(또는 타입 서버)라고 하고, NTP 서버로부터 시각 정보를 얻어서 동기화하는 기기를 NTP 클라이언트라고 한다. NTP 서버로부터 시각 정보를 얻으려면 전용 소프트웨어가 필요하다. 시각 동기화 프로토콜에는 이외에도 NTP를 간략화한 SNTP(Simple Network Time Protocol)이 있다.
