데이터 망 CH2. Application Layer

Alpha, Orderly·2023년 3월 6일

데이터망

데이터 망

목록 보기

2/8

프로토콜 개발
- IUT : Implementation Under Test
- Conformance Test : 적합성 테스트, 를 통해 확인.

이들을 처리하기 위해 Protocol Engineer가 있다.

Network app

여러가지 단말기(End systems)에서 작동함
네트워크 통해 작동
network-core device는 user application을 실행하지 않는다

Client-Server Paradigm

Server

항상 켜져있음
IP주소 유지됨
데이터센터에 위치하기도 함

Clients

서버와 통신
간헐적으로 연결될수도 있음
IP주소가 바뀔수 있음
상호간 직접통신을 하지 않음

Peer-Peer Architecture

항시 켜져있는 서버가 없음
임의의 단말기들이 직접 통신
피어가 다른 피어에게 서비스를 요청하고 제공받음.
피어들은 간헐적인 연결상태와 변하는 IP 주소를 가짐
예시 : P2P 파일공유 (BitTorrent)

Process Communicating

Process

Host에서 실행되는 프로그램
Host 내부에서 두개의 프로세스가 inter-process communication을 통해 소통 가능하다.
Host가 다른 두개의 프로세스에 대해선 메시지 교환을 통해 서로 소통 가능하다.

- client process : 소통을 시작하는 프로세스

- server process : 소통을 기다리는 프로세스

P2P 어플리케이션의 경우에서 client process와 server process가 둘 다 존재한다!

BSD

DARPA 프로젝트의 일환인 TCP/IP를 BSD에서 구현하기 시작하면서 인터넷이 급성장

Sockets

프로세스는 메시지를 소켓을 활용해 송수신한다.
소켓 통신
1. 송신 프로세스는 메시지를 보낸다
2. 송신 프로세스는 수신 프로세스의 소켓에 메시지를 보내기위해 수신측의 transport infrastructure에 의존한다.
3. 양 끝단에 소켓이 관여한다.
4. 송수신 간 사용하는 Transport layer의 방식이 같아야 한다 Ex. UDP, TCP

Addressing process

메시지를 주고 받기 위해선 식별자(identifier) 가 필요하다.
host device들은 고유한 32비트 길이의 IP주소를 가진다.
- 한 호스트에서 여러 프로세스가 동작하기에, IP주소만으로 프로세스를 식별하는것은 불가능하다.
식별자는 IP주소와 포트번호를 포함한다
- IP주소 : Host 식별
- 포트번호 : Process 식별
포트번호의 대표적 예시는 다음과 같다.
- HTTP : 80 + TCP
- Mail server: 25

Application Protocol Defines

1. Type of messages exchanged

Request / Response

2. Message syntax < 문법 >

what fields in messages and how fields are delineated(묘사)

어떤 필드가 메시지에 있고, 어떻게 묘사되는지

3. Message semantics < 의미 >

meaning of information in field

필드에 있는 메시지의 뜻

4. Rules

When and How processes send and respond to messages

언제 / 어떻게 프로세스가 메시지를 송신하고 수신하는지

- OPEN PROTOCOLS

RFC에 기술되어 모두가 접근 가능하다.
상호운용(interoperability)이 가능해진다.
예시 : HTTP, SMTP

- PROPRIETARY(사유) PROTOCOLS

동작 원리를 확인할수 없다.
예시 : Skype, Zoom

Application에 필요한 Transport 계층의 service

1. Data integrity

파일 전송, 전자 상거래 등은 100% 신뢰 가능한 데이터 전송을 필요로 한다.
몇몇 프로세스는 패킷 손실도 감당 가능하다.

2. Timing

게임과 같은 프로세스는 낮은 지연을 필요로 한다.

3. Throughput

몇몇 프로세스는 최소로 요구하는 처리량이 있다.
몇몇 프로세스는 주어진 처리량을 모두 사용한다.

4. Security

Encryption
Data integrity

TCP service

Reliable protocol between sending / receiving process

Flow control
- Sender won't overwhelm receiver
- 수신자가 오버플로우로 인해 패킷 손실이 일어나지 않도록 한다.
Congestion Control
- Throttle sender when network overloaded
- 네트워크 과부하시 송신 속도를 저하시킨다.
Connection Oriented
- setup required between client and server processes
- 연결 시작시 클라이언트와 서버간 절차가 요구된다.

TCP가 제공하지 않는것

Timing
Minimum throughput guarantee
Security

UDP service

Unreliable data transfer between sending / receiving process

왜 UDP를 사용하는가?

데이터가 매우 신속하게 전달된다, 이는 자연스럽게 좋은 Timing과 Throughput을 가지게 된다.
패킷 손실이 일어나도 별 문제가 없는 동영상 스트리밍과 매우 낮은 지연시간을 요구하는 온라인 게임에서 사용된다.

Securing TCP

Vanilla TCP / UDP

암호화 없음
비밀번호가 평문으로 소켓에 전송되어 평문으로 인터넷을 이동한다.

Transport Layer Security

암호화된 TCP
데이터 무결성
- 중간에 내용을 바꿨는지 확인하는것
End-point authentication
- 네트워크의 End-point를 보호하는 프로세스
- 송신자를 확인하는 절차

Web and HTTP

Web page
- 각각 다른 웹서버에 저장될수 있는 객체(Object)들로 이루어져 있다.
- 객체는 HTML, JPEG, JAVA APPLET, AUDIO 가 될수 있다.
- 웹 페이지는 Base HTML 파일과 여러가지 참조자료를 포함하며 각각 URL 주소를 가진다.
  - URL 예시 : 구글 로고 https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png
HTTP, Hyper Text Transfer Protocol
- Web의 Application-Layer protocol.
- Client
  - 서버에 요청
  - 받아온 웹 객체들을 표시
- Server
  - 웹 요청을 받으면 응답한다.
- HTTP는 TCP를 사용한다.
  1. 80번 포트를 통해 Client가 TCP 접속을 시작한다.
  2. 서버가 TCP 연결을 승인(Accept)한다
  3. Browser(Http client)와 Web server(Http Server)간 HTTP 메시지의 교환이 이루어진다.
  4. TCP 연결이 끊어짐
  - HTTP is "Stateless"
    - 서버는 이전 Client에 대한 요청의 정보를 저장하지 않는다.
State를 보관하는 프로토콜은 복잡하다!
이전 상태가 반드시 유지되어야 한다.
서버/클라이언트가 Crash되면 상태가 불일치 할수도 있고, 이는 복구되어야 한다.

Non-Persistent HTTP

1회의 TCP 연결에 1개의 객체만이 전송된다.

TCP 연결이 열린다.
최대 하나의 객체가 TCP로 전송된다.
TCP 연결이 닫힌다.

Non-persistent HTTP / Response time

RTT : 작은 패킷이 클라이언트에서 서버로 갔다 다시 돌아오는데 걸리는 시간.
- Round Trip Time : 갔다 오는데 걸리는 시간
HTTP Response Time (객체당)
- 1 RTT : TCP 연결을 시작 소요시간
- 1 RTT : HTTP 요청 및 몇 바이트의 HTTP 응답 소요시간
- 객체/파일 전송 소요 시간
- Non-persistent HTTP response time = 2 * RTT + file transmission time

Non-persistent HTTP Issue

Require 2 RTTs per object
- 각각의 TCP 연결마다 OS 오버헤드가 발생.
- 브라우저가 여러개의 병렬 TCP 연결을 열어 병렬 단위로 객체를 불러올수 있다.

Persistent HTTP

1회의 TCP 연결에 여러개의 객체가 전송된다.
응답을 보낸 뒤에도 서버는 연결을 유지한다.
뒤따르는(subsequent) 서버/클라이언트 간 HTTP 메시지는 열린 TCP를 통해 전달된다.
클라이언트는 Referenced object를 만나자 마자 요청을 보낸다.
최소 1RTT 안에 모든 Referenced object를 보낼수 있다.

서버에 TCP 연결이 열린다.
단일 TCP 연결에 여러개의 객체가 클라이언트와 서버간에 전송된다.
TCP 연결이 닫힌다.

HTTP request message

HTTP 메시지에는 두가지 종류가 있다.
- request
- response

HTTP Request Message

ASCII (Human-readable format)로 작성
각 줄은 \r\n을 통해 줄바꿈된다.
첫번째 줄
- 요청의 종류 : GET / POST / PATCH / DELETE
- 요청하는 URL
- HTTP 버전
나머지 줄
- 다른 필요한 정보들 / 헤더

HTTP 요청의 일반적 포맷

메소드 URL 버전

sp - 공백
cr lf - 줄바꿈 \r\n
헤더 필드에서 key value pair 구분은 :를 사용함

다른 종류의 HTTP Request 메시지

POST Method
- Form input을 포함한 웹페이지가 대다수
- 클라이언트에서 서버로 유저의 입력이 전송될때 HTTP POST Request의 body를 통해 전송된다.
GET Method, For sending data to server
- 클라이언트에서 서버로 유저의 입력이 전송될때 쿼리스트링의 형태로 전송된다.
- 예시 : www.somesite.com/animalsearch?monkeys=banana
HEAD Method
- GET 메소드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
- 헤더만 받기
PUT Method
- 서버에 새로운 파일을 업로드
- URL에 존재하는 파일을 POST HTTP request message의 body에 있는 content로 완전히 바꿔치움

HTTP response message

Response status code

Status code는 Response의 첫번째 줄에 위치한다.
예시
- 200 OK
  - 요청 성공, 요청받은 객체가 메시지에 있다.
- 301 Moved Permanently
  - 요청된 객체는 이동되었다. 새로운 위치가 메시지에 포함된다.
- 400 Bad Request
  - 요청 메시지를 서버가 이해하지 못함
- 404 Not Found
  - 요청된 객체가 서버에 존재하지 않음
- 505 HTTP Version not supported

Maintaining user/server state

HTTP GET <-> Response Interaction is Stateless!

Web Transaction의 완료를 위한 여러단계의 교환(Exchange)에 대한 개념(Notion)이 없음
- client/server가 여러 단계에 대해 상태를 추적할 필요가 없음
- 모든 HTTP 요청은 독립적
- client/server가 일부만 완료된(Partially-completed-but-never-completely-completed) Transaction에 대해 복구 할 필요가 없음

웹 사이트와 클라이언트 브라우저는 cookie를 이용해 Transaction간 상태를 유지함

쿠키는 HTTP 응답 메시지의 헤더에 포함됨.
쿠키는 다음 HTTP 요청 메시지의 헤더에 포함됨
쿠키는 Host에 저장되어 Host Browser에 의해 관리됨
웹사이트 백엔드 데이터베이스에도 쿠키가 있음.

요청시 백엔드 DB에 쿠키 저장과 동시에 응답의 헤더에 쿠키를 담아서 보냄
이후 요청에서는 쿠키가 포함되어 유저를 Identify하는 수단이 됨

쿠키 사용 예시

Authorization / 인증
Shopping cart
Recommendation
User session state

Web Cache

Client 요청을 Origin server 없이 처리하기(satisfy)

사용자가 브라우저를 웹캐시로 가리키게 설정할수 있다.

브라우저가 모든 HTTP 요청을 캐시에 보낸다.
- 캐시에 객체가 있으면, 캐시에서 객체를 보낸다.
- 캐시에 객체가 없으면, Origin server에서 객체를 받아와 캐시에 저장하고 Client에게도 보낸다.

즉, 캐시는 Client임과 동시에 Server 이다

서버는 캐시에게 객체가 캐시할만한 대상인지 응답 헤더에 적을수 있다.

Web cache를 사용하는 이유

Client 요청에 응답시간을 줄일수 있다.
트래픽을 줄일수 있다.
질나쁜 Contents Provider들이 효율적으로 content를 전송할수 있게 한다.

캐시 데이터와 원본 데이터가 다를수 있는 문제를 해결하기 위해

Browser Cache: Conditional GET

브라우저 캐시가 최신버전일때 객체를 보내지 않는다.

Client

브라우저에 캐시된 복사본의 마지막 수정된 시간을 HTTP 요청에 적어둔다.
- if-modified-since

Server

브라우저에 캐시된 복사본이 바뀐게 없으면 응답에 객체를 포함하지 않는다.
- 304 Not Modified
브라우저에 캐시된 복사본이 바뀐게 있으면 응답에 객체를 포함한다.
- 200 OK

HTTP/1

HTTP/1.1

단일 TCP 연결을 통한 Multiple / Pipelined GET
- ACK를 기다리지 않고 요청을 여러개 보낸다.
서버는 in-order / First-come-first-served scheduling 순서로 GET 요청에 응답함
FCFS로 인해 작은 객체는 이전에 전달되고 있는 큰 객체가 전송되기를 기다려야 함. < HOL blocking
- Head Of Line Blocking
Loss recovery stall(지연시키다) object transmission
요청이 여러개 있다.

HTTP/2

여러 객체가 있는 HTTP(Multi-object HTTP) 요청의 지연 감소

HTTP/2

한 커넥션에 여러개의 메세지를 동시에 주고 받을 수 있음
Server에서 Client로 객체를 보낼때 유연성을 증대시킴
- Method, status code,등은 HTTP1.1에서 변하지 않음
- 요청된 객체의 전송 순서는 client-specified object priority를 기반으로 함.
- 객체를 프레임으로 나누어 보내 HOL blocking을 완화(mitigate) 함.
여전히 패킷 손실의 복구 과정은 모든 객체 전송을 지연시킴
기본 TCP 연결에 보안이 없음
ASCII를 사용하지 않고 Binary를 사용한다.
- HTTP/1.1 버전의 클라이언트는 HTTP/2 버전의 서버와 통신이 불가능하다는 뜻이다.

여러개의 TCP 연결을 만들어 받아오는 시간을 줄일수 있다.

HTTP/3

보안 추가
UDP를 통한 오브젝트별 에러처리(Per object Error Control) 및 혼잡처리(Congestion Control)

E-Mail

Major component

User agent
Mail server
SMTP : Simple Mail Transfer Protocol

1. User agent

"Mail reader"
메일 작성/수정/읽기
나가거나 들어오는 메시지는 서버에 저장된다.
예시 : Outlook

2. Mail server

유저에게 온 메시지를 보관하는 Mailbox
보내질 메시지들을 위한 Message Queue

3. SMTP

TCP 25번 포트를 활용 믿을수 있는 이메일 전송
- Client처럼 작동하는 sending server가 receiving server에 보낸다.
1. SMTP Handshaking / Greeting
2. SMTP transter of messages
3. SMTP closure
Command/Response 상호작용 < HTTP와 유사 >
- command : ASCII 문자열
- response : 상태코드, 문구

    예시
    C: HELO relay.example.org
    S: 250 Hello relay.example.org, I am glad to meet you

사용 예시

메시지를 보내는 Sending server의 Message queue에 받는다.
TCP 연결을 이용해 Sending server에서 Receiving server로 연결 및 메시지가 전달된다.
Receiving server는 받는 사람의 메일박스에 메시지를 보관한다.
메시지 박스에서 받은 메일을 확인할수 있다.

telnet

telnet 25 - 25번 포트에 동작하는 프로그램과 연결 가능하다.

직접 SMTP 클라이언트 사용 가능하다.

메일 메시지 형식

헤더
- 보낼 사람 / To
- 보낸 사람 / From
- 제목 / Subject
내용 : 메시지, ASCII 문자만 가능.

메일접근 프로토콜, 메일 받는법

SMTP가 수신서버에 이메일을 전송 및 보관한다.

메일 접근 프로토콜 : 서버에서 받아오기
- IMAP, Internet Mail Access Protocol
  - 메시지가 서버에 저장되며 IMAP을 통해 서버에 저장된 메시지들을 가져오고, 삭제할수 있다.
- HTTP
  - gmail 등이 제공하는 웹-인터페이스. SMTP로 전송및 IMAP/POP으로 가져오는 작업을 수행한다.
- POP3

HTTP와 SMTP 비교

HTTP

클라이언트가 가져온다.
각각의 객체가 응답 메시지에 포함되어 있다.

SMTP

클라이언트가 보낸다.
여러개의 객체가 Multipart message로 보내진다.

BOTH

ASCII command와 response interaction, status code가 있음.

DNS

DOMAIN NAME SYSTEM, Connect IP and DOMAIN

개요

여러 name server의 계층으로 구현(Implemented)된 분산 데이터베이스(Distributed Database)
- name server : 도메인이름을 인터넷상의 주소(IP주소)로 변환시켜 원하는 컴퓨터를 찾아갈 수 있도록 합니다
Application Layer 프로토콜이며, Core internet function이다.

기능

hostname을 ip로 번역
host aliasing
- 별칭 호스트네임(alias)으로 정식 호스트네임(canonical)을 찾을수 있게 함
mail server aliasing
- 전자메일 주소를 기억하기 쉽게 축약한다.
load distribution
- 여러 중복된 서버 사이에 부하 분산용으로 사용됨.
- 여러 IP주소가 하나의 hostname과 연결되어 있으며, DNS 질의시 이중 하나를 응답함.

DNS 중앙화 하지 않는 이유

한곳이 오류나면 인터넷이 망가진다.
트래픽을 분산하기 위해
지리적 거리차이로 인한 일부 지역의 Propagation delay가 길어진다.
유지관리의 어려움, 너무 자주 갱신이 필요해진다.

DNS 분산 계층

client가 www.amazon.com의 IP주소를 원할경우

클라이언트가 root dns 서버에 질의한다. >> .com DNS 서버를 찾는다.
클라이언트가 .com dns 서버에 질의한다. >> amazon.com DNS 서버를 찾는다.
클라이언트가 amazon.com 서버에 질의한다. >> www.amazon.com의 IP주소를 찾는다.

ROOT Name server

루트 존의 레코드의 요청에 직접 응답하고 적절한 최상위 도메인(TLD)에 대해 권한이 있는 네임 서버 목록을 반환한다.
모든 DNS 질의의 시작점
직접 IP를 확인해주진 않는다.
DNSSEC : 보안 기능 제공 (인증절차, 메시지 무결성)
ICANN (Internet Coporation for Assigned Names and Numbers)가 관리한다.

TOP Level domain

도메인의 Top level을 관리한다
- 예시 : .com, .org, 등등

Authoritative DNS servers

Authoritative : 권위 있는
단체가 소유하는 DNS 서버, 단체의 hostname을 ip로 매핑해준다.
단체 혹은 서비스 제공자가 관리한다.

Local DNS name server

host가 DNS query를 할때, 로컬 DNS서버로 보낸다.
로컬 DNS서버가 답변을 보낸다.
DNS 계층과는 관계가 없다.
일종의 캐시서버로 작동하게 되며, 찾지 못했을시 DNS 계층으로 보낸다.
- Iterated query
- 로컬 DNS에 물어본후 없으면 로컬에서 루트, 로컬에서 TLD, 로컬에서 Authoritative로 물어봐 결과를 알려준다.

- Recursive query
- 로컬 DNS에 물어본 후 없으면 루트 -> TLD -> Authoritative로 가는건 같은데
루트 DNS서버가 TLD에 질의하고, TLD가 Authoritative에 질의를 하며 응답또한 왔던길을 반대로 돌아간다.

DNS 보안

DDOS

서버에 트래픽 폭탄을 던진다
- 트래픽 필터링
- 로컬 DNS가 TLD서버를 캐시 해놓아 우회 가능.
TLD 서버 공격
- 위험함

Spoofing

DNS 질의를 훔쳐가 거짓 응답을 보낸다.
- DNS 캐시가 오염될수 있다.
- 이를 방지하기 위해 DNSSEC 사용

P2P Architecture

항상 켜져있는 서버가 없다.
임의로 단말기들이 직접 통신한다.
Peer가 Peer에게 요청하고 서비스를 응답한다.
Peer들은 IP가 계속 바뀔수 있고 연결이 유지되지 않을수 있다.

BitTorrent

피어끼리 논리적 네트워크를 생성한다.
파일을 256Kb 청크로 분리해 P2P방식으로 전달한다.
Tracker가 참여중인 Peer들을 추적한다.
Peer가 토렌트에 참여
- 트래커를 통해 피어의 리스트를 받아옴
- 처음에는 아무것도 없지만, 다른 피어로부터 청크 받아나감
다운로드 하면서 동시에 다른 피어에게 청크를 전송함
피어는 청크를 교환하는 피어를 바꿀수도 있음
다운로드 완료시 업로드를 중단하거나 업로드를 유지할수 있음
Tit for Tat
- 자신에게 제일 빠르게 보내주는 4명의 피어를 골라 제일 빠르게 청크를 보내준다.
- 30초마다 세로 선정해서 보내준다.
DHT
- 찾고자하는 파일에 hash function을 돌리면 뭔가 나오는데, 이를 주소로 매핑해서 알아봄

Video Streaming / Content distribution

비디오 스트리밍은 막대한 트래픽 유발
분할된 Application-level Infrastructure 활용함.

VIDEO

일정 간격으로 연속되는 이미지 < 픽셀의 배열 > 들
코딩
- 이미지 안에서의 반복성을 이용해 이미지를 인코딩해 크기를 줄임
- 현재 이미지의 크기를 줄이거나 < Spatial >, 다음 이미지와의 유사성 < Temporal > 을 이용해 줄일수 있다.
CBR, Constant Bit Rate : 영상 인코딩 정도 고정
VBR, Variable Bit Rate : 영상의 Spatial 혹은 Temporal한 정도의 차이를 확인해 인코딩 정도를 변화시킨다.

Challenge

Continuous Playout constraint

서버와 클라이언트 간 대역폭이 계속 바뀐다.
원래 시간대로 재생하기 위해선 Jitter(네트워크 딜레이)로 인해 클라이언트에 버퍼가 필요하다.
- Jitter : 패킷별 지연의 변동 < 최대 지연 시간 - 최소 지연 시간 >
버퍼가 없을시 순간적으로 지연시간이 확 늘어나면 동영상이 끊길수 있다.

Client Interactivity

일시정지, 빨리감기, 되돌리기, 구간점프

Network error

패킷 손실, 재전송

DASH, 멀티미디어 스트리밍

Dynamic Adaptive Streaming over Http

DASH 서버

파일을 여러개의 청크로 분리, 각각의 청크를 다른 비율로 인코딩
파일을 여러 CDN에 저장
manifest file : 각각의 청크에 대한 URL

DASH 클라이언트

서버<>클라이언트 간 대역폭을 주기적으로 측정한다.
매니페스트에 따라 한번에 한 청크를 요청함
- 현재 대역폭에 가장 맞는 청크를 요청함
- 시간때마다 다른 비율로 인코딩된 청크를 요청할수 있음
클라이언트가 결정하는 요소
- 언제 청크를 요청할지
- 어떤 비율로 인코딩 된 청크를 가져올지
- 어디에 청크를 요청할지

CDNs / Content Distribution Networks

CDN Node에 Content의 복사본을 저장한다.

종류

Enter deep
- 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축하는 방식. 서버를 사용자와 최대한 가까이 위치시킨다.
Bring Home
- 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하는 방식이다. 클러스터를 IXP에 배치시켜 사용자에게 데이터를 제공한다.

Socket programming

UDP

Unreliable fast datagram
클라이언트와 서버간 "연결"이 없다
- 연결 시작 전 Handshaking 이 없다.
- 그냥 보낸다, 패킷이 사라지거나 순서가 뒤바뀔수 있다.
방식
- 서버 : socket -> bind -> sendto/recvfrom 으로 사용
- 클라이언트 : socket -> bind or not

TCP

Reliable byte stream oriented
서버가 반드시 먼저 시작하여 소켓을 열어두고 있어야 한다.
연결시 새로운 소켓을 생성하여 특정 클라이언트와 소통한다.
네프동일

Alpha, Orderly

만능 컴덕후 겸 번지 팬

이전 포스트

데이터 망 CH1. Introduction

다음 포스트

데이터 망 CH2. Application Layer

데이터 망

Network app

Client-Server Paradigm

Server

Clients

Peer-Peer Architecture

Process Communicating

Process

- client process : 소통을 시작하는 프로세스

- server process : 소통을 기다리는 프로세스

Sockets

Addressing process

Application Protocol Defines

1. Type of messages exchanged

2. Message syntax < 문법 >

3. Message semantics < 의미 >

4. Rules

- OPEN PROTOCOLS

- PROPRIETARY(사유) PROTOCOLS

Application에 필요한 Transport 계층의 service

1. Data integrity

2. Timing

3. Throughput

4. Security

TCP service

UDP service

왜 UDP를 사용하는가?

Securing TCP

Vanilla TCP / UDP

Transport Layer Security

Web and HTTP

State를 보관하는 프로토콜은 복잡하다!

Non-Persistent HTTP

Non-persistent HTTP / Response time

Non-persistent HTTP Issue

Persistent HTTP

HTTP request message

HTTP Request Message

HTTP 요청의 일반적 포맷

메소드 URL 버전

다른 종류의 HTTP Request 메시지

HTTP response message

Response status code

Cookie

Maintaining user/server state

HTTP GET <-> Response Interaction is Stateless!

웹 사이트와 클라이언트 브라우저는 cookie를 이용해 Transaction간 상태를 유지함

쿠키 사용 예시

Web Cache

Client 요청을 Origin server 없이 처리하기(satisfy)

Web cache를 사용하는 이유

캐시 데이터와 원본 데이터가 다를수 있는 문제를 해결하기 위해

Browser Cache: Conditional GET

브라우저 캐시가 최신버전일때 객체를 보내지 않는다.

Client

Server

HTTP/1

HTTP/1.1

HTTP/2

여러 객체가 있는 HTTP(Multi-object HTTP) 요청의 지연 감소

HTTP/2

여러개의 TCP 연결을 만들어 받아오는 시간을 줄일수 있다.

HTTP/3

E-Mail

Major component

1. User agent

2. Mail server

3. SMTP

사용 예시

telnet

메일 메시지 형식

메일접근 프로토콜, 메일 받는법

SMTP가 수신서버에 이메일을 전송 및 보관한다.

HTTP와 SMTP 비교

HTTP

SMTP

BOTH

DNS

DOMAIN NAME SYSTEM, Connect IP and DOMAIN