1. 쿠키 (cookie)

• 서버에서 생성되어 클라이언트 측에 저장되는 <이름, 값> 쌍 형태의 데이터
• 쿠키 만료 기간과 같은 추가적 속성값도 가질 수 있음
• HTTP의 스테이트리스한 특성을 보완하기 위한 대표적 수단
• atuhorization, shopping carts, recommendation, user session state(Web e-mail)등에 사용될 수 있음

1.1.  응답 메시지

서버가 클라이언트에게 쿠키를 전송할 때는 응답 메시지의 Set-Cookie가 활용됨

Set-Cookie: 이름=값
Set-Cookie: 이름=값; 속성1
Set-Cookie: 이름=값; 속성1; 속성2

• 도메인과 경로, 유효기간, 보안 등이 대표적인 쿠키 속성값
  • 'domain=example.net' : 쿠키를 사용할 도메인을 example.net으로 제한
  • 'path=/lectures' : 쿠키를 사용할 경로를 /lectures로 제한
  • 'Expires=요일, DD-MM-YY HH:MM:SS GMT' ( 'Expires=Fri, 23 Aug 2024 09:00:00 GMT' ) : 명시된 유효기간이 지나면 해당 쿠키는 삭제 되어 전달되지 않음
  • 'Max-Age=3000000' : 초 단위 유효기간 
  • 'Secure' : HTTP의 더 안전한 방식인 HTTPS를 통해서만 쿠키를 송수신하도록 하는 속성
  • 'HttpOnly': 자바스크립트를 통한 쿠키의 접근을 제한, 오직 HTTP 송수신을 통해서만 쿠키에 접근

1.2. 요청 메시지

클라이언트는 Cookie 헤더로 전달받은 쿠키를 서버에 전송

Cookie: 이름=값; 이름=값;

• 특정 서버로부터 쿠키를 전달받았다면 다음부터 해당 서버에 요청을 보낼 때 전달받은 쿠키를 자동으로 전송

1.3. 쿠키와 보안

• 쿠키는 사이트가 나에 대해 너무 많은 정보를 알게 함.
• third party persistent cookies(tracking cookie): 여러 웹사이트에 걸쳐 사용자의 활동을 추적할 수 있게 해주는 쿠키

2. 캐시

• 응답 받은 자원의 사본을 임시 저장하여 불필요한 대역폭 낭비와 응답 지연을 방지하는 기술
• 목표: satisfy client request without involving origin server
• browser는 모든 HTTP request를 캐시에 보내고 object가 cache에 있으면 cache가 object를 반환하고, 없으면 cache가 origin server에 요청해 object를 받은 후 client에 반환해줌 (web cache는 origin server에게는 client, requesting client에게는 server)
• 캐시는 주로 ISP(대학, 회사, residential ISPs)에 의해 운영됨
• 전용 캐시: 클라이언트에 저장
• 공용 캐시: 클라이언트와 서버 사이에 위치한 중간 서버에 저장

2.1. 캐시 사용 이유

2.2. 캐시 유효 기간

• 대부분의 캐시된 데이터에는 유효기간이 설정되어 있음.
  • 유효기간 부여 방법 (응답 메시지)
    • Expires: Fri, 23 Aug 2024 09:00:00 GMT
    • Cache-Control: max-age=1200
  • 클라이언트는 응답받은 자원을 임시 저장하여 이용하다가 유효기간이 만료되면 다시 서버에 자원을 요청해야 함
• 유효기간이 부여되는 이유는?
  • 클라이언트가 캐시를 참조하는 사이 서버의 원본 데이터가 변경되어 원본 데이터와 캐시된 사본 데이터 간의 일관성이 깨질 수 있음
  • 유효기간을 설정하고 만료된 자원을 재요청함으로써 캐시 신선도를 검사할 수 있고, 원본 데이터가 변경되었을 때 해당 자원을 다시 응답받음으로써 캐시 신선도를 높게 유지할 수 있음
    • 캐시 신선도(cache freshness) : 캐시된 사본 데이터가 서버의 원본 데이터와 얼마나 유사한지의 정도
• 캐시 데이터의 유효기간이 자나면 반드시 서버로부터 다시 자원을 응답받아야 할까?
  • No! 캐시된 데이터가 여전히 최신 데이터라면 굳이 서버로부터 같은 자원을 응답 받을 필요가 없음
  • -> 원본 자원이 변경된 적 있는지 질의

2.2.1. 원본 자원 변경 여부

• 원본 자원의 변경 여부를 묻는 헤더 (요청 메시지)
  • 'If-Modified-Since: Fri, 23 Aug 2024 09:00:00 GMT' : 특정 시점 이후로 원본 자원에 변경이 있었다면, 그때만 변경된 자원을 메시지 본문으로 응답하도록 서버에 요청하는 헤더
  • Etag(Entity Tag) : 자원의 버전을 식별하기 위한 정보. 자원을 변경할 때 마다 Etag값이 변경됨
    • If-None-Match: "abc" : 명시된 Etag 값("abc")과 일치하는 Etag가 있는지, 없다면 변경된 자원으로 응답하도록 요청하는 헤더
• 서버가 요청받은 자원이 변경된 경우
  • 서버는 상태 코드 200(OK)과 함께 새로운 자원을 반환
• 서버가 요청받은 자원이 변경되지 않은 경우
  • 메시지 본문 없이 304 (Not Modified)를 통해 클라이언트에게 자원이 변경되지 않았음을 알림
  • Last-Modified 헤더로 자원의 마지막 변경 시점을 알릴 수 있음
• 서버가 요청받은 자원이 삭제된 경우
  • 서버는 상태 코드 404(Not Found)를 통해 자원이 존재하지 않음을 알림

도메인 네임과 DNS

DNS(Domain Name System)

• 분산형 계층형 데이터베이스 
  • 왜 분산형인가? 
    • single point of failure : 한 곳에서 서버가 다운되면, 전체가 영향받을 수 있음
    • traffic volume: 하나의 서버가 모든 요청을 처리할 경우 트래픽의 병목 현상과 성능 저하를 초래할 수 있음
    • distant centralized database: 가까운 DNS 서버에서 빠르게 응답을 받을 수 있음
    • maintenance: 전세계의 수많은 도메인 이름을 하나의 중앙 서버에서 관리하는 것은 비효율적이고 복잡
• application layer protocol

Domain Name(도메인 네임) 

• 'https://www.naver.com'과 같은 문자열 형태의 호스트 특정 정보로, 호스트의 IP 주소와 대응됨
  • IP 주소에 비해 기억하기 쉬움
  • IP 주소가 바뀌더라도 바뀐 IP주소에 도메인 네임을 다시 대응하면 됨 
• host aliasing
• mail server aliasing
• load distribution: 다량의 request를 여러 웹서버가 다루도록 알아서 distribute

 Name Server(네임 서버)

• 도메인 네임과 그에 대응하는 IP 주소를 관리하는 서버
• domain name을 관리하는 네임 서버는 DNS 서버라고도 부름
• 호스트는 네임서버에 '특정 도메인 네임을 가진 호스트의 IP 주소가 무엇인지' 질의함으로써 패킷을 주고받고자 하는 호스트의 IP주소를 얻어낼 수 있음 (리졸빙)

도메인 네임의 계층적 구조

• 최상단에 root domain(루트 도메인)이 있고, 그 다음 단계에 최상위 도메인(Top-Level Domain, TLD)이 있음 (ex. com, net, org, kr, jp, cn, us 등)
• 최상위 도메인 하부 도메인은 2단계 도메인(second-level domain), 2단계 도메인의 하부 도메인은 3단계 도메인
• 도메인의 단계는 더 늘어날 수도 있지만, 일반적으로 3~5단계 정도로 구성
• 전체 주소 도메인 네임(FQND): 도메인 네임을 모두 포함하는 도메인 네임 (ex. www.example.com.)

네임 서버의 계층적 구조

• 네임 서버는 여러 개가 존재하며, 전 세계 여러곳에 위치함. 네임 서버는 분산되어 관리됨
• 도메인 네임 시스템(DNS): 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계
• 도메인 네임을 통해 IP 주소를 알아내는 과정
  • 호스트는 가장 먼저 로컬 네임 서버에게 도메인 네임을 질의

Local DNS name server

• 계층 구조에 속하지 않음
• 각 ISP(residential ISP, 회사, 대학)은 각각 하나의 Local DNS name server를 가지고 있음
• Default Name server(기본 네임 서버)라고도 불리며, 사용자가 도메인 이름을 입력하면 가장 먼저 쿼리가 보내지는 서버
• 프록시 역할: Local DNS name server는 사용자를 대신해 프록시 역할을 하여, DNS 쿼리를 상위 DNS 서버에 전달하는 역할을 함. 

DNS Name Resolution

 Iterated query

• Local DNS server에서 모든 도메인 네임 요청을 처리한다.

1. host가 local DNS server에 DNS 서비스 요청을 한다.
2.  local DNS server가 도메인 네임을 가지고 있지 않아 root DNS server에 물어본다.
3. root DNS server도 갖고 있지 않아 TLD DNS server 정보를 알려준다.
4. TLD server에게 정보를 묻는다.
5. TLD server도 정보가 없어 authoritative DNS server를 알려준다
6. authoritative DNS server에 접속한다.
7. 도메인 네임에 대한 IP주소를 얻는다.

Recursive query

Authoritative DNS server: 특정 도메인에 대해 최종적인 IP주소 정보를 제공하는 DNS 서버. 해당 도메인에 대한 정확한 매핑 정보를 가지고 있음. 조직이나 외부 제공자를 통해 운영될 수 있음.

DNS Caching

• DNS 서버는 한번 도메인-주소 매핑 정보를 학습하면 캐시에 저장. 동일한 요청에 대해 더 빠르게 응답할 수 있게 하여 성능을 향상.
• 캐시된 항목들은 일정시간(TTL)이 지나면 자동으로 만료됨. TTL이 만료되면 해당 캐시 항목은 삭제됨
  • TTL: Time To Leave
• TLD 서버에 대한 정보는 로컬 DNS 서버에 자주 캐시됨. 덕분에 Root DNS 서버는 자주 방문되지 않음
• out of date 문제 발생할 수 있음
  • 도메인의 호스트가 IP 주소를 변경했을 때, 모든 TTL이 만료될 때까지 전 세계적으로 그 변경 사항이 알려지지 않을 수 있음
  • IETF(Internet Engineering Task Force)에서 갱신 및 알림 메커니즘(update/notify mechanisms)이 제안

DNS records

Resource Records(RR)

• DNS 데이터베이스의 각 레코드
• RR format: (name, value, type, ttl)

유형

• type = A
  • name = hostname
  • value = IP address
• type = NS
  • name = domain
  • value = hostname of authoritative name server
• type = CNAME
  • name = alias name
  • value = canonical(real) name
• type = MX
  • name = domain
  • value = name of mailserver

DNS message format

• DNS query와 reply message 모두 같은 message format
• message header
  • identification: 16bit 숫자. 같은 숫자로 query에 reply
  • flags
    • Query or Reply(QR) : 쿼리인지 응답인지 구분
    • Recursion Desired(RD): 재귀적 응답을 원하는지
    • Recursion Available(RA): 재귀적 쿼리를 지원하는지
    • Reply is Authoritative Answer(AA): 응답이 권한이 있는 서버에서 온 것인지

DNS에 레코드 삽입하는 과정

• "Network Utopia(NU)"가 DNS에 레코드를 삽입하는 과정을 예시로 설명

1. 도메인 등록: NU는 DNS 등록 기관(예: Network Solutions)을 통해 nu.com이라는 도메인을 등록
2. TLD 서버에 레코드 삽입: 등록 기관은 .com TLD 서버에 두 개의 리소스 레코드(RR)를 삽입
   1. NS 레코드: (nu.com, dns1.nu.com, NS)
   2. A 레코드: (dns1.nu.com, 21.21.21.2, A)
3. 권한 있는 서버 생성
   1. NU는 IP 주소가 21.21.21.2인 권한 있는 DNS 서버를 로컬에서 설정
4. A 레코드 및 MX 레코드 추가
   1. A 레코드 추가: NU는 'www.nu.com'에 대한 A 레코드를 생성하여 이 도메인이 특정 IP 주소(21.21.21.2)와 매핑되도록 함
   2. MX 레코드 추가: NU는 nu.com에 대한 MX 레코드를 생성하여 이 도메인으로 수신되는 이메일을 처리할 메일 서버를 정의

자원(Object)과 URI/URL

• 자원: 네트워크 상의 메시지를 통해 주고받는 최종 대상. 즉, 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때 송수신하는 대상 (ex. HTML 파일, 이미지 파일, 동영상 파일 등)

URI (Uniform Resource Identifier)

• 웹상에서 자원을 식별하기 위한 정보. 자원을(Resource)을 식별(Identifier)하는 통일된 방식(Uniform)
• URN (Uniform Resource Name): 이름으로 자원을 식별하는 방식
• URL (Uniform Resource Locator): 위치로 자원을 식별하는 방식

URL의 구조

1. scheme

• 자원에 접근하는 방법
• 일반적으로는 사용할 프로토콜이 명시됨 (ex. http://, https://)

2. authority

• 호스트를 특정할 수 있는 IP 주소나 도메인 네임이 명시됨
• 콜론(:) 뒤에 포트 번호를 명시할 수도 있음

3. path

• 자원이 위치하고 있는 경로가 명시됨
• 슬래시(/)를 기준으로 계층적으로 표현되며, 최상위 경로 또한 슬래시로 표현

4. query

• URL에 대한 매개변수 역할을 하는 문자열
• 쿼리 문자열, 쿼리 파라미터 등으로도 불림
• 자원을 식별하기 위한 추가적인 정보
• ? 키=값 형태, &를 사용하여 여러 쿼리 문자열을 연결할 수 있음 (ex. ?location=seoul&rooms=2&size=100)

5. fragment

• 자원의 일부분, 자원의 한 조각을 가리키기 위한 정보
• 해시 기호(#) 뒤에 오는 문자열
• 특정 섹션이나 리소스를 식별하는 데 사용

URN

• URL은 자원의 위치가 변하면 유효하지않음. 이에 반해 URN은 자원에 고유한 이름을 붙이기 때문에 위치와 무관한게 자원 식별 가능
• URL이 더 많이 사용됨

HTTP의 특징과 메시지 구조

HTTP 메시지 구조

• method: 클라이언트가 서버의 자원에 대해 수행할 작업의 종류

HTTP 메서드와 상태 코드

HTTP 메서드

HTTP 상태코드

HTTP 주요 헤더

요청 메시지에서 주로 활용되는 HTTP 헤더

Host

• 요청을 보낼 호스트가 명시되는 헤더
• 도메인 네임이나 IP주소로 표현되며, 포트 번호가 포함될 수도 있음

User-Agent

• 요청 메시지를 보낸 클라이언트의 프로그램과 관련한 정보가 명시됨
• HTTP요청을 보낸 클라이언트의 접속 수단(ex. 웹 브라우저)을 유추할 수 있음

Referer

• 클라이언트가 요청을 보낼 때 머무르던 URL이 명시됨
• 클라이언트의 유입 경로를 파악할 수 있음

응답 메시지에서 주로 활용되는 HTTP 헤더

Server

• HTTP 응답 메시지를 보내는 서버 호스트와 관련된 정보가 명시됨

Allow

• 처리 가능한 HTTP 헤더 목록을 알리기 위해 사용됨

Location

• 클라이언트에게 자원의 위치를 알려 주기 위해 사용됨
• 주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용됨

요청과 응답 메시지 모두에서 활용되는 HTTP 헤더

Date

• 메시지가 생성된 날짜와 시각에 관련한 정보를 담은 헤더

Content-Length

• 메시지 본문의 바이트 단위 크기를 표현하기 위해 사용

Content-Type, Content-Language, Content-Encoding

• 메시지 본문이 어떻게 표현되었는지와 관련된 표현 헤더
• Content-Type: 본문에서 사용된 미디어 타입
• Content-Language: 메시지 본문에 어떤 자연어가 사용되었는지 (ex. 'ko-Kr', 'en-GB', 'en-US')
• Content-Encoding: 메시지 본문을 압축하거나 반환한 방식 (ex. gzip, compress, br)Connection
• HTTP 메시지를 송신하는 호스트가 어떠한 방식의 연결을 원하는지 명시 (ex. keep-alive, close)

HTTP는 애플리케이션의 다양한 자원을 네트워크를 통해 송수신 하는 프로토콜

HTTP의 특징

1. 요청 응답 기반 프로토콜

• 요청 메시지를 보내는 클라이언트와 이에 대한 응답 메시지를 보내는 서버가 서로 메시지를 주고 받는 구조로 작동
• HTTP 요청 메시지와 HTTP 응답 메시지의 형태는 다름

2. 미디어 독립적 프로토콜

• 다양한 종류의 자원을 주고받을 수 있음 (ex. HTML, JPEG, PNG, PDF 등), 자원의 종류는 미디어 타입(Media type)이라고 부름
• 자원의 특성과 무관하게 자원을 주고받는 인터페이스의 역할만 수행

3. 스테이트리스(Stateless) 프로토콜

• 상태를 유지하지 않는 스테이트리스 프로토콜
• 과거 HTTP 요청을 보낸 클라이언트 관련 정보를 기억하지 않음. 때문에 모든 HTTP요청은 독립적인 요청으로 간주됨.
• 스테이트리스인 이유
  • HTTP서버가 처리해야할 요청 메시지의 수는 수도 없이 많을 수 있음. 이런 상황에서 모든 클라이언트의 상태 정보를 유지하는 것은 큰 부담.
  • 서버는 여러대로 구성될 수도 잇는데, 여러 대로 구성된 서버 모두가 모든 클라이언트의 상태를 유지해야하는 것은 매우 번거롭고 복잡한 작업

 HTTP 서버의 설계 목표

• 확장성: 언제든 쉽게 서버를 추가할 수 있음
• 견고성: 서버 중 하나에 문제가 생기더라도 쉽게 다른 서버로 대체 가능

HTTP Connections

1. none-persistent HTTP(no pipelining)

• HTTP 1.0
• 3-way handshake를 통해 연결한 후, 응답을 받으면 연결을 종료하는 방식
• 추가적인 요청-응답 메시지를 주고받으려면 매번 새롭게 연결을 수립하고 종료해야함.
• 하나의 Object을 얻기위해 2RTT가 소요됨 (transmission time을 무시했을 때)
• 하나의 TCP connection에 최대 한 개의 Object만 보낼 수 있음
• downloading multiple objects requires multiple connections
• 비효율적

RTT: 패킷이 목적지에 도착하고 나서 다시 출발지로 돌아오기까지 걸리는 시간

2. none-persistent HTTP  (pipelining)

• HTTP 1.1
• use parallel TCP connections
• OS가 지원하는 최대 parallel TCP connection 수를 고려해야함
• multiple objects can be sent over single TCP connection
• 10개의 Object를 주고받을 때
  • no pipelining의 경우 1(initiate TCP connection)+1(base htmp file recieved) +10*2(Object 하나를 얻기 위해 필요한 시간) = 22RTT
  •  pipelining의 경우  1(initiate TCP connection)+1(base htmp file recieved)+2(Object 10개를 동시에 ) = 4RTT

no pipelining

3. persistent HTTP (keep-alive)

• HTTP 1.1
• kepp-alive 옵션
• 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수있는 기술
• none-persistent HTTP보다 빠른 속도로 HTTP 요청과 응답을 처리할 수 있음 (3RTT)

네트워크의 기본 구조

• 네트워크: 노드와 간선으로 이루어진 자료구조. 그래프의 형태를 띔.
  • 노드: 네트워크 기기 (서버, 라우터, 스위치 등)
  • 간선: 네트워크 기기 간에 정보를 주고받는 유무선의 통신 매체
• 인터넷: network of networks

Edge

• 네트워크의 가장 자리에 있는 모든 통신 기기 (hosts, servers)
  • hosts: 네트워크를 통해 주고받는 정보를 최초로 송신하고 최종 수신하는 노드
    • client: 통신 기기의 보내진 정보를 사용자(모바일, 컴퓨터 등)에게 보여주는 쪽. 정보를 요청하는 역할
    • server: 클라이언트의 요청을 응답하는 역할

LAN과 WAN

LAN

• 근거리 네트워크
• 가정이나 기업처럼 비교적 가까운 거리를 연결하는 한정된 공간에서의 네트워크

WAN

• 원거리 네트워크
• LAN간의 통신이 이루어지게 함
• ISP가 구축하고 관리 (ex. KT, LG U+, SK 브로드밴드)

패킷 교환 네트워크

• 패킷 단위로 주고받는 정보를 쪼개서 송수신하고 수신지에서 재조립하며 패킷을 주고 받는 것
  • Packet(패킷): 네트워크를 통해 송수신되는 데이터의 단위 (네트워크를 통해 주고 받는 데이터는 여러 데이터로 쪼개져서 송수신 됨)
  • Packet의 구성: payload + header + (trailer)
    • payload: 패킷에서 송수신하고자 하는 데이터 (cf. 택배 물품)
    • header, trailer: 패킷에 추가되는 부가 정보 (cf. 송장)

주소의 개념과 전송 방식

• 주소: packet의 header에 명시되는 정보(ex. IP주소와 MAC주소)
• unicast(유니캐스트): 송신지와 수신지가 일대일로 메시지를 주고받는 방식
• broadcast(브로드캐스트): 네트워크 상의 모든 호스트에게 메시지를 전송하는 방식
  • broadcast domain(브로드캐스트 도메인): 브로드캐스트가 전송되는 범위. 호스트가 같은 브로드캐스트 도메인에 속해있는 경우 같은 LAN에 속해있다고 간주
• multicast(멀티캐스트): 네트워크 내의 동일 그룹에 속한 호스트에게만 전송하는 방식
• anycast(애니캐스트): 네트워크 내의 동일 그룹에 속한 호스트 중 가장 가까운 호스트에게 전송하는 방식

Protocol

• 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계이다. 즉 통신 규약 및 약속.
• Define format, order of messages sent and received and actions taken on message transmission
• 프로토콜마다 목적과 특징이 다름. 각 프로토콜의 목적과 특징을 집중해 살펴보는 것이 좋음.

네트워크 참조 모델

• 통신이 이루어지는 단계를 계층적으로 표현한 것
• 패킷을 송신하는 쪽: 상위 계층 -> 하위 계층 정보 보냄
• 패킷을 수신하는 쪽: 하위 계층 -> 상위 계층 정보 받아들임
• 대표적 네트워크 참조 모델: OSI 모델, TCP/IP 모델

OSI 모델

• ISO(국제 표준화 기구)에서 만든 네트워크 참조 모델. 통신 단계를 7개의 계층으로 나눠 OSI 7계층이라고 부름.

Physical Layer(물리계층)

• 가장 최하위 계층
• 0과 1로 이루어진 신호를 유무선 통신 매체를 통해 운반
• 패킷의 이름: symbol, bit

Data Link Layer(데이터 링크 계층)

• 같은 LAN에 속한 호스트끼리 올바르게 정보를 주고받기 위한 계층
• 같은 네트워크에 속한 호스트를 식별할 수 있는 MAC주소를 사용
• 물리 계층을 통해 주고받는 정보에 오류가 없는지 확인
• 패킷의 이름: frame

Network Layer(네트워크 계층)

• 네트워크 간 통신을 가능하게 하는 계층
• 같은 LAN을 넘어 다른 네트워크와 통신을 주고받기 위해 필요한 계층
• 네트워크간 통신 과정에서 호스트를 식별할 수 있는 IP주소를 사용
• 패킷의 이름: 패킷 또는 데이터그램

Transport Layer(전송 계층)

• 신뢰성 있는 전송을 가능하게 하는 계층 (ex. 송수신된 패킷 유실, 순서 뒤바뀜 등)
• port(포트)라는 정보를 통해 특정 응용 프로그램과의 연결 다리 역할을 수행
• 전송 계층 대표 프로토콜: TCP, UDP
• 패킷의 이름: segment(TCP 기반), datagram(UDP 기반)

Session Layer(세션 계층)

• 세션(응용 프로그램 간의 연결된 상태)을 관리하기 위한 계층
• 응용 프로그램 간의 연결 상태를 유지하거나 새롭게 생성하고, 끊는 역할
• 패킷의 이름: data, message

Presentaion Layer(표현 계층)

• 인코딩과 압축, 암호화와 같은 작업을 수행
• 응용 계층에 포함하여 간주하는 경우가 많음
• 패킷의 이름: data, message

Application Layer(응용 계층)

• 사용자와 가장 밀접하게 맞닿아 여러 네트워크 서비스를 제공하는 계층
• 중ㅇ요한 프로토콜 다수 포함: HTTP, HTTPS, DNS
• 패킷의 이름: data, message

TCP/IP 모델

• OSI 모델이 주로 네트워크의 이론적 기술을 목적으로 사용하는 반면, TCP/IP 모델은 구현과 프로토콜에 중점을 둔 네트워크 참조 모델

Network Access Layer(네트워크 엑세스 계층)=Link Layer(링크 계층)=Network Interface Layer(네트워크 인터페이스 계층)

• 최하위 계층
• OSI 모델의 데이터 링크 계층과 유사

Internet Layer(인터넷 계층)

• OSI 모델의 네트워크 계층과 유사

Transport Layer(전송 계층)

• OSI 모델의 전송 링크 계층과 유사

Application Layer(전송 계층)

• OSI 모델의 세션 계층, 표현 계층, 응용 계층과 유사

캡슐화와 역캡슐화

• 각 계층에서는 어떤 정보를 송신할 때 상위 계층으로부터 내려받은 패킷을 페이로드로 삼아, 각 계층에 포함된 프로토콜의 각기 다른 목적과 특징에 따라 헤더 혹은 트레일러를 덧붙인 다음 하위 계층으로 전달. (상위 계층의 패킷 = 하위 계층의 페이로드)
• 캡슐화: 헤더(및 트레일러)를 추가해 나가는 과정
• 역캡슐화: 캡슐화 과정에서 붙인 헤더(및 트레일러)를 각 계층에서 확인한 뒤 제거하는 과정

처리량과 지연 시간

• 처리량(throughput): 링크 내에서 성공적으로 전달된 데이터의 양. 보통 얼만큼의 트래픽을 처리했는지를 나타냄
  • 트래픽(traffic): 흐르는 데이터
  • 처리량(throughput): 처리되는 트래픽
• 지연 시간(latency): 요청이 처리되는 시간. 어떤 메시지가 두 장치 사이를 왕복하는데 걸린 시간