학교
[컴퓨터 네트워크] Chapter2. Application Layer (Part 1) - (3)
[13] 조건부 GET
1) 목표
: 캐시에 최신 캐시 버전이 있는 경우 object를 전송하지 않는다. (웹 캐싱 효율성을 높이기 위한 HTTP 메커니즘)
object 전송 지연 없음
낮은 링크 사용률
2) 캐시 동작
: HTTP 요청에 캐시된 사본의 날짜를 지정한다.
if-modified-since : <date>헤더 사용
3) 서버 동작
: 캐시된 사본이 최신일 경우 응답에 객체가 포함되지 않는다.
4) 두 가지 경우
(1) date 이전에 수정되지 않은 객체

: 서버는 304 Not Modified 응답
(2) date 이후에 수정된 객체

: 서버는 200 OK 응답과 함께 새로운 객체 전송
[14] HTTP/2
1) 주요 목표
: 다중 객체 HTTP 요청 지연 감소
2) HTTP1.1의 한계
단일 TCP 연결을 통해 여러 개의 파이프라인 GET을 도입했다. (순차적으로 진행한다는 의미)
서버는 GET 요청에 순서대로 응답한다. (FCFS : 선착순 스케줄링)
[문제점] FCFS를 사용하면, 작은 객체는 큰 객체 뒤에서 전송을 기다려야 할 수도 있다. (HOL(Head of Line) 차단)
손실 복구(손실된 TCP 세그먼트 재전송)로 인해 object 전송이 지연된다.
3) HTTP/2 개선사항
서버에서 클라이언트로 객체를 전송할 때 유연성을 높인다.
메소드, 상태 코드, 대부분의 헤더 필드가 HTTP 1.1에서는 변경되지 않았다.
클라이언트가 지정한 객체 우선순위에 따라 요청된 객체의 전송 순서(반드시 FCFS일 필요 없음)
요청되지 않은 객체를 클라이언트에 푸시한다.
객체를 프레임으로 나누고, HOL 차단을 완화하기 위해 프레임을 예약한다.
[14-2] mitigating HOL blocking (차단 완화)
1) HTTP 1.1
: 클라이언트가 1개의 큰 객체 (예 : 비디오 파일, 3개의 작은 객체)를 요청하는 경우 (지연시키는 문제)

요청된 순서대로 전달되는 객체입니다: O2, O3, O4는 O2 뒤에 대기합니다.
2) HTTP/2
: 프레임으로 분할된 객체, 프레임 전송 인터리빙하여 전송

O2, O3, O4는 빠르게 전송, O1은 약간 지연된다.
[14-3] HTTP/2 to HTTP3의 변화
1) 목표
: 다중 객체 HTTP 요청의 지연 추가 감소
2) 단일 TCP 연결을 통한 HTTP/2의 한계
패킷 손실로부터 복구는 여전히 모든 객체 전송을 지연시킨다.
HTTP 1.1에서와 마찬가지로 브라우저는 여러 병렬 TCP 연결을 열어 지연을 줄이고, 전체 처리량을 늘리려는 인센티브가 있다.
[TCP 연결의 보안 문제] 바닐라 TCP 연결에 대한 보안이 없음
3) HTTP/3의 개선
: UDP를 통한 보안, 객체 별 오류 및 혼잡 제어 (더 많은 파이프라이닝) 추가 (향상된 보안 및 성능)
전송 계층의 HTTP/3에 대해 자세히 알아보기
OUIC (Quick UDP Internet Connection)
3. E-mail, SMTP, IMAP
[1] E-mail

1) 세 가지 주요 구성 요소
사용자 에이전트 (이메일 클라이언트)
메일 서버
간단한 메일 전송 프로토콜 : SMTP
2) 사용자 에이전트
일명 '메일 리더'라고 부른다.
메일 메세지를 작성, 편집, 읽기를 제공
예 : Outlook, iPhone 메일 클라이언트
서버에 저장된 발신, 수신 메세지
3) 메일 서버
사용자에 대한 수신 메시지가 들어 있는 사서함
발신 (전송 예정) 메일 메시지의 메시지 대기열을 관리
4) SMTP 프로토콜
: 이메일 메세지를 보내기 위한 메일 간의 SMTP 프로토콜
클라이언트 : 보내는 메일 서버
서버 : 수신 메일 서버
[2] Email : the RFC (5321)
SMTP는 TCP를 사용하여 클라이언트 (연결을 시작하는 메일 서버)에서 서버 (포트 25)로 이메일 메세지를 안정적으로 전송한다.
직접 전송 : 보내는 서버 (클라이언트처럼 작동)가 받는 서버로 전송한다.
3단계 전송
핸드 셰이킹 (인사말)
메시지 전송
연결 종료
명령/응답 상호 작용 (HTTP와 같은)
명령 : ASCII 텍스트
응답 : 상태 코드 및 문구
메시지는 7비트 ASCII이어야 한다.
[3] 시나리오 : Alice가 Bob에게 이메일을 전송
1) 과정
엘리스가 UA(User Agent)를 사용하여 이메일 메세지를 "bob@someschool.edu"로 작성한다.
엘리스의 UA가 메일 서버로 메시지를 전송하고, 메시지는 메ㅇ지 큐에 배치된다.
SMTP의 클라이언트 측이 bob의 메일 서버와 TCP 연결을 한다.
SMTP 클라이언트가 TCP 연결을 통해 엘리스의 메시지를 보낸다.
Bob의 메일 서버가 Bob의 메일함에 메시지를 배치한다.
Bob이 자신의 UA를 호출하여 메시지를 읽는다. (Asynchronzation)
[4] SMTP interaction 예시

[5] SMTP : 관찰 결과 마무리
1) HTTP와 비교
HTTP : pull (client pull object from server)
SMTP : push (server push data)
둘다 ASCII 명령/응답 신호 작용, 상태 코드가 있다.
HTTP : 각 객체가 자체 응답 메세지로 캡슐화된다.
SMTP : 여러 객체가 여러 부분으로 구성된 메세지로 전송된다.
SMTP는 영구 연결을 사용한다.
SMTP는 메시지 (헤더 및 본문) 7 비트 ASCII이어야 한다.
SMTP 서버는 CRLF.CRLF를 사용하여 메세지 끝을 확인한다.
[6] Mail 메세지 포맷

1) SMTP
: 이메일 메시지 교환을 위한 프로토콜로, RFC 5321에 정의되어 있습니다(HTTP와 유사).
2) RFC 5322
: 이메일 메시지 자체에 대한 구문을 정의합니다(HTML과 같은).
header lines
: 이메일 메시지 본문 영역에서 SMTP 메일 형식:, RCPT TO 명령과는 다른 구문을 정의합니다!from:
to:
subject
body : message, 오직 ASCII 문자열
[7] 메일 접근 프로토콜

SMTP: 수신자의 서버로 이메일 메시지 전달/저장
메일 액세스 프로토콜: 서버에서 검색
(1) POP3: 우체국 프로토콜 - 버전 3 [RFC 1939]: 매우 간단한 메일 액세스 프로토콜로, 다소 제한적이다. (간단한 다운로드 중심 프로토콜)
간단하다.
local delivery로 his email을 서버로부터 다운로드 가능하다.
(2) IMAP: 인터넷 메일 액세스 프로토콜 [RFC 3501]: 서버에 저장된 메시지, IMAP은 서버에 저장된 메시지의 검색, 삭제, 폴더를 제공한다. (서버 기반 관리 기능이 있는 고급 프로토콜)
(3) HTTP: gmail, Hotmail, Yahoo!Mail 등은 이메일 메시지 검색을 위해 SMTP(전송), IMAP(또는 POP) 위에 웹 기반 인터페이스를 제공한다. (웹메일 서비스에서 사용)
[8] Exercise

: Bob은 자신의 G메일 계정에 Outlook(즉, 이메일 사용자 에이전트 프로그램)을 사용하려고 합니다. 하지만 Outlook을 설정하는 방법을 모릅니다. 그는 오른쪽 그림과 같이 수신/발신 메일 서버를 설정하는 방법에 대해 문의했습니다. 아래 주소 중에서 가능한 각 메일 서버 주소를 찾아보세요.
1) inap.gmail.com
2) snmp.gmail.com3) pop.gmail.com -> Incoming
4) p2p.gmail.com5) smtp.gmail.coms -> Outgoing
