> For the complete documentation index, see [llms.txt](https://minhee0327.gitbook.io/mini-til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://minhee0327.gitbook.io/mini-til/network/tcp-and-ip-basic/04_.md).

# 04 애플리케이션 계층

* 애플리케이션 계층의 역할
  * TCP/IP 5계층 중 가장 위에 위치한 것
  * 컴퓨터끼리의 주고받기를 **사용자가 이용할 수 있는 '통신 서비스' 형태로 만드**는 역할
  * 통신 서비스 실현
  * application protoccol: 서버와 클라이언트가 주고 받기로 정한 프로토콜
* 애플리케이션 헤더
  * 어플리케이션 계층에서 추가된 헤더
  * 서비스를 실현하기 위한 '요청과 응답'에 대한 정보를 담고 있음.
  * 아래 계층으로 가면 헤더와 데이터가 하나로 묶이기 때문에 사용자가 해석할 수 있는 형태로 되어있는 계층은 application 계층밖에 없음.
  * 애플리케이션 헤더에 무엇을 어떻게 쓸지는 프로토콜마다 다름.
    * 텍스트 기반, 바이너리 기반 ..
  * 클라이언트가 서버에 서비스를 요청할 때, 구체적인 데이터를 주고받지 않고 연락만 취할때는 데이터는 빈채로 보낸다.
* HTTP 프로토콜
  * WWW 서비스 지탱하는 프로토콜
  * 하나의 요청에 대해 하나의 응답을 반환하는 간단한 프로토콜
  * '요청', '응답' 두종류의 패킷을 사용하여 텍스트 형식으로 주고받음.
    * 요청패킷
      * 메소드(GET, POST, PUT, DELETE, ...)
      * 요청헤더(Accept, 문자코드, 처리가능한파일종류, 언어 등)
      * 공백줄: 헤더와 본문의 경계
      * 본문: 요청에 필요한 데이터가 들어간다. (메소드가 GET이면 비어있음.)
    * 응답패킷
      * 상태줄: 클라이언트 요청에 대한 결과 (정상처리되면 200번대 숫자)
      * 응답헤더: 클라이언트에게 전달할 데이터와 관련된 정보
      * 공백줄: 헤더와 본문 경계
      * 본문: 클라이언트에게 전달할 데이터 들어있음
* 통신을 유지하는 구조
  * 상태 비보존형 프로토콜: 한번 수행으로 끝
    * HTTP 프로토콜은 1회 완결 \[통신연결-요청-응답-통신해제]
    * 요청 데이터를 반환하는 것만 주 목적으로 만들어짐.
    * 과거 수행한 통신과는 관련 없음.
  * 쿠키
    * 클라이언트 측에 HTTP 프로토콜의 주고받기 정보를 저장해두면,  

      다음 통신때, 해당 정보를 서버에 제시하여 사용자를 지정해서 이전 회에 이어진 통신으로 취급.
    * HTTP의 정규 장치는 아님
    * CGI(Common Gateway Interface)등 클라이언트로부터 요청에 맞게 웹 페이지 작성하는 장치와 사용
      * 처음 사이트 방문했을 때
        * \[클라이언트] =>요청 =>\[서버] => \[CGI프로그램] =>(응답패킷의 응답헤더에 쿠키 저장의뢰 명령을 넣어서 보냄) =>\[서버]=>응답 => \[클라이언트: 쿠키저장]
      * 다시 동일한 웹사이트 요청시
        * 요청패킷의 요청 헤더에 이전 서버에 부여받은 쿠키정보를 넣음
        * CGI프로그램에서 쿠키를 보고 사용자 지정하여 처리한 웹페이지 작성
        * 이전 통신을 근거로 웹페이지 표시
        * 쿠키에는 유효기간이 있음.(기간이 지난 쿠키는 자동 삭제됨, 유효기간 설정은 쿠키제작사가 하지만, 설정이 없는 경우 브라우저가 닫힐때까지로 제한)
* SSL/TLS
  * 인터넷 상에 주고받는 데이터 안정성을 높임.
  * SSL(secure sockets layer)
    * 인터넷상에서 데이터 통신을 암호화하는 프로토콜
  * TLS(Transport Layer Security)
    * SSL을 바탕으로 표준화한 것
  * 확인방법: 주소창에 열쇠마크와 url의 https로 시작 시, SSL/TLS로 보호받는 것 확인 가능
  * [SSL/TLS 구조 참고](https://howhttps.works/ko/the-keys/)
* 전자메일 주고받기
  * 메일러를 사용해 작성한 메일은 텍스트 데이터로 만들어져 보내짐
    * 엔벨롭: 보내는 이와 받는이의 주소(SMTP에서 사용)
    * 메일헤더: 서버로 전달되는 클라이언트의 정보 (메일, 제목, 날짜 등)
    * 공백(빈줄): 헤더와 메세지 경계
    * 메일본문
  * 명령(command)과 응답 (response)
    * \[헤더+데이터] 형태를 취하지 않고 단독으로 트랜스포트계층에 전달.
    * 주로 사용되는 프로토콜종류 : SMTP, POP, APOP, IMAP4
      * APOP: POP 사용자 인증시 암호화
      * IMAP4: SMTP+POP의 기능합친 프로토콜, 어디서든 읽고, 메일크기가 커도 클라이언트에 부담가지 않음.
* [SMTP프로토콜](https://m.blog.naver.com/PostView.nhn?blogId=netpathyblog\&logNo=70126634738\&proxyReferer=https:%2F%2Fwww.google.com%2F)
* [POP프로토콜(그림만 참조)](https://www.codeproject.com/Articles/404066/Understanding-the-Insides-of-the-POP3-Mail-Protoco)
* 문자코드
  * '문자'그 자체를 통신서비스에서 주고받는 것은 아님
  * 문자 그 자체가 아닌, 문자 코드를 주고받는다.
  * 일반적으로 인코딩(컴퓨터가 이해하는 언어로 변환), 디코딩(사람이 이해하는 언어로 바꾸는 것)을 거친다.
  * 대부분의 통신서비스에서 문자코드로 US-ASCII문자표를 사용.
  * 한국어 문자코드, 한글 완성형코드(EUC-KR)
* MIME
  * Multipurpos Internet Mail Extension
  * 전자메일의 제약사항을 보완하는 장치
    * 제약사항1: 제목에 한글 사용이 불가능 했음
    * 제약사항2: 텍스트(문자)만 보낼 수 있었음
  * MIME중에서도 BASE64 방식이 많이 사용됨.

    \-