1. Principels of Network Application
1) Network Application Architectures
Client Server paradigm
Server
- always on host (서버는 항상 켜진 상태여야 한다.)
- permanent IP address (고정된 IP 주소: 클라이언트가 접근해야 함)
- 주로 규모가 큰 데이터 센터에 존재한다.
Client
- 서버와 연결 & 통신해 사용한다.
- intermittently connect (간헐적 접속, 접속하고 싶을 때 접속)
- dynaminc IP address (IP주소는 바뀌어도 상관 X, 클라이언트가 항상 먼저 요청)
- 클라이언트끼리는 서로 통신하지 않는다.
2) Processes Communicating
process: 호스트 내에서 실행중인 프로그램
- 동일한 호스트 내에서 프로세스 간 통신 : inter-process communication(OS에서 정의) 통신
- 다른 호스트에서 프로세스 간 통신 : message 교환하여 통신
Client & Server
- client process (ex. 브라우저): 통신을 시작하는 프로세스
- server process (ex. 웹서버): 연결을 기다리는 프로세스
- P2P process : 클라이언트 프로세스와 서버 프로세스
Sockets
- 프로세스가 메세지를 주고받을 때, 소켓을 통해 보낸다.
- 소켓은 문(door)과 유사하다.
- sending 프로세스가 메시지를 문 밖으로 밀어낸다.
- sending 프로세스는 receiving 프로세스에게 소켓으로 메시지를 전달하기 위해 문의 반대편에 있는 전송 인프라에 의존한다.
- 소켓은 호스트 내의 애플리케이션 계층과 전송 계층 사이의 인터페이스이다.
- 응용프로그램과 네트워크 사이의 API(application programming interface)라고도 한다.
Addressing Process
프로세스에는 식별자(identifier)가 필요하다.
- IP address: 호스트에 있는 unique한 식별자
- port number: 호스트 내 프로세스를 구분하기 위한 식별자
→ IP주소로는 프로세스를 찾아가기 충분하지 않다. 호스트는 여러가지 프로세스를 돌릴 수 있음
3) Transport Services Available to Applications
- data integrity (reliable data transfer) 데이터 무결성 (신뢰할 수 있는 데이터 전송)
- 에러 X, 중복 X, 순서대로
- 오디오 라디오 동영상 같은 경우는 참을 수 있다.(loss-tolerant application)
- timing
- delay를 적게, 효율적이기 위해서.
- time sensetive application
- throughput (처리량)
- 처리량이 어느 수준 이하이면 의미가 없다.
- 효율적이기 위해서 최소 처리량을 요구한다.
- 상관없으면 elastic하다고 한다. (유연성)
- security (보안)
4) Transport Services Provided by the Internet
인터넷에는 두 개의 전송 서비스가 있다.
- TCP service
- reliable transport: 신뢰성 있는 전송 (에러 있으면 재전송)
- flow control(흐름 제어): (sender receiver 사이에서) receiver가 초과하는 내용을 보내지 않는다.
- congetion control(혼잡 제어): 네트워크 상황에서 라우터에 쌓이지 않도록, Throttle sender when network overloaded (네트워크 과부하 시 sender 조절한다).
- does not provide: 시간 X, 최소 처리량 보장 X, 보안 X
- connection-oriented(연결 지향): 클라이언트와 서버 사이에 setup(3 way hand shacking)이 필요하다. (<->전화 connection service)
- UDP service
- unreliabel data transfer: 전송 신뢰성 없음
- does not provide: 신뢰성 X, flow control X, congetion control X, 시간 X, 최소 처리량 보장 X, 보안 X
- 그럼에도 사용되는 이유: 에러 시 전송 속도 TCP 보다 빠름, 기본적인 기능
- Securing TCP
- 바닐라 TCP & UDP 소켓
- TLS (Transport Layer Security) 전송 계층 보안
- application layer에 구현되어있다.
- TLS socket API
2. The Web & HTTP
1) HTTP overview
웹페이지는 각각 다른 웹서버에 담길 수 있도록 object로 구성(html, 자바스크립트, 이미지 등) 되어있다.
웹페이지는 기본 HTML파일(참조된 object를 포함)로 구성되며, 주소는 url로 표현한다.
http (hypertext transfer protocol)
- 웹의 응용 계층 프로토콜이다.
- client/ server model
- http는 TCP를 사용한다. - 데이터 loss X
- 브라우저(클라)는 서버에게 TCP 커넥션을 요청한다.
- 서버는 클라로부터 온 TCP 커넥션을 받아들인다.
- 브라우저(클라) 웹 서버(서버) 사이에 메세지를 교환한다.
- TCP 커넥션을 닫는다.
- 원래는 3 way hand shacking을 하는데 합해서 보낼 수 있음.
- piggy backing - 데이터 프레임에 확인 응답 프레임을 합해서 보내는 것
- http는 stateless - 서버가 상태(과거 클라이언트의 요청 정보)를 저장하지 않는다.
- 프로토콜이 상태를 저장하는 것은 매우 복잡하다. (overhead)
2) Non-Persistent & Persistent Connections
비-지속적 연결 상태, 지속적 연결 상태
RTT(round trip time)
패킷이 목적지에 도달하고 나서 해당 패킷에 대한 응답이 출발지로 다시 돌아오기까지의 시간, RTT는 패킷 왕복 시간
3) HTTP Message Format
Request Message Format 요청 메세지 포맷
- POST method
- 웹 페이지에는 종종 form input이 포함된다.
- HTTP POST 요청 메시지의 엔터티 본문에서 클라이언트에서 서버로 보내는 사용자를 입력한다.
- HEAD method
- 지정된 URL이 HTTP GET 메서드로 요청된 경우 반환될 헤더(만)를 요청한다.
- GET method
- HTTP GET 요청 메시지의 URL 필드에 사용자 데이터 포함('?' 뒤):
- PUT method
- 새로운 파일(object)을 서버에 업로드한다.
- 지정된 URL에 존재하는 파일을 POST HTTP 요청 메시지의 엔터티 본문에 있는 내용으로 완전히 대체.
Response Message Format 응답 메세지 포맷
status code
| 200 | OK • 요청 성공, 이 메시지의 뒷부분에 있는 요청된 개체 |
| 301 | Moved Permanently • 요청된 개체 이동, 이 메시지의 뒷부분에 지정된 새 위치(위치: 필드) |
| 400 | Bad Request • 요청 메시지가 서버에서 이해되지 않음 |
| 404 | Not Found • 이 서버에서 요청한 문서를 찾을 수 없음 |
| 505 | HTTP Version Not Supported |
4) User Server Interaction Cookies (쿠키)
HTTP GET/ reponse interaction은 stateless(무상태)이다.
- 웹 "트랜잭션"을 완료하기 위한 HTTP 메시지의 다단계 교환에 대한 개념 없음
- 클라이언트/서버가 multi-step exchange의 "상태"를 추적할 필요가 없다.
- 모든 HTTP 요청은 서로 독립적.
- 클라이언트/서버가 부분적으로 완료되었지만 완전히 완료되지 않은 트랜잭션에서 "복구"할 필요가 없다. (원래 자리부터 다시 시작)
웹 사이트와 클라이언트 브라우저는 쿠키를 사용하여 트랜잭션 간에 일부 상태를 유지.
- cookie header line of HTTP response message
- cookie header line in next HTTP request message
- cookie file kept on user’s host, managed by user’s browser
- back-end database at Web site
5) Web Caching (proxy servers)
goal: 원본 서버까지 가지 않고(원본 서버 없이도), 클라이언트 요청 충족
web cach는 클라이언트와 서버의 일을 둘 다 한다.
캐시에 개체가 있는 경우: 캐시가 개체를 클라이언트에 반환.
캐시에 개체가 없는 경우: 캐시가 원본 서버에서 객체를 요청하고, 수신된 객체를 캐시한 다음 클라이언트로 객체를 반환.
왜 웹 캐싱인가?
- 클라이언트 요청에 대한 응답 시간 단축 • 캐시가 클라이언트에 더 가깝다. (디스크 캐시)
- 기관의 액세스 링크에서 트래픽 감소 = 바깥으로 나가는 트래픽을 줄인다. <안에서 처리>
- 인터넷은 캐시 밀도가 높다.
- “poor" 콘텐츠 제공 업체(대역폭 작은 서비스)가 콘텐츠를 보다 효과적으로 전달할 수 있도록 한다.
Caching example
condiitional GET
캐시가 업데이트 상태인지 확인해서 delay를 줄인다.
6) HTTP/2
| HTTP 1.1 | HTTP/2 |
| multiple, pipelined GETS 요청하고 기다리지 않고 계속 연속 요청한다. | 서버가 클라이언트에게 보낼 때, flexibility up! 유연성을 갖자. |
| FCFS(First Come Firste Served) 순서대로 전송 loss recovery가 전송 시간을 늘린다. | 우선 순위대로 전송 (not necessarily FCFS) 서버가 먼저 전송 (요청하기 전에) |
| HOL blocking이 발생한다. | HOL blocking을 막기 위해 obj를 프레임으로 쪼갠다. (interleaving) |
3. Electronic Mail in the Internet
Email의 3가지 major component
- user agent
- 메일 리더 프로그램
- 메세지 작성, 편집, 읽기
- ex. outlook, iphone mail (우리가 쓰는 거: 웹 메일)
- mail server
- mailbox: 메세지 받는 곳
- messaging queue: 메세지 보내는 곳
- SMTP: 메일 서버 사이에 메세지를 보내는 프로토콜
Email-RFC
- 직접 전송: 송신 서버(클라이언트 역할)를 수신 서버로
- 안정적 전송을 위해 TCP를 사용, 클라이언트에서 서버로 메세지를 전송(port 25)
- 3단계 전송 (악수 - 3way handshaking, 메시지 전송, 종료)
- 명령/응답 상호작용(예: HTTP) / 명령: ASCII 텍스트/ 응답: 상태 코드 및 구문
- 메시지는 7비트 ASCI여야 한다.
1) SMTP
HTTP & SMTP
HTTP: pull
SMTP: push
4. DNS-The Internet’s Directiory Service
hostname: 호스트 식별자
ip adress: 아이피주소 데이터그램 주소 지정에 사용
1) Services Provided by DNS
- distributed database implemented in a hierachay of DNS server 분산 데이터베이스는 여러 DNS 서버들로 계층적으로 구현된다.
- 응용계층 프로토콜 - 호스트와 네임서버들은 resolve name 하기 위해 소통한다.
- 응용 계층 프로토콜로 구현된 핵심 인터넷 기능<HTTP, SMTP>
- 네트워크 엣지의 복잡성
+) resolve name (이름 변환): IP → 이름, 이름 → IP
- host aliasing
- canonical(실제 이름), alias names(별칭)
- mail server aliasing
- load distribution 한 쪽으로 몰림 방지
- 웹서버를 복제한다, 많은 IP주소들이 한 이름으로 연결되어있다
2) Overview of How DNS works
왜 DNS를 분산시키는가? - 카카오의 사례를 보면 알 수 있다
- 하나의 서버의 실패로 모든 인터넷이 연결 중단
- 트래픽이 너무 커졌을 때 효과적이다
- DNS 서버는 원격이다. DNS를 모아두면 멀리있는 곳은 딜레이가 발생할 수 있음
- 유지 보수. 하나의 서버에 집중되면 커지고 관리하기 힘들어진다.
1. Root DNS servers → 보호해야함
이름을 확인할 수 없는 name server에 의한 공식적인 최후의 연락 수단.
보통은 TLD에서 확인
- 엄청나게 중요한 인터넷 기능
- Root DNS server이 없으면 인터넷이 작동할 수 없다.
- DNSSEC – 보안 제공(인증 및 메시지 무결성)
- ICANN(Internet Corporation for Assigned Names and Numbers) 루트 DNS 도메인을 관리합니다.
2. Top-level domain (TLD) servers (최상위 도메인 서버)
- .com, .org, .net, .edu, .aero, .jobs, .museums 및 모든 최상위 국가 도메인(예: .cn, .uk, .fr, .ca, .jp)을 담당합니다.
- Network Solutions(권한을 주는 기구): .com, .net TLD에 대한 권한 있는 레지스트리
- Educause: .edu TLD
3. Authoritative DNS servers (권한 있는 DNS servers)
- 조직의 자체 DNS 서버(ex. 숙명 서버), 조직의 호스트에게 IP 매핑에 대한 authoritative hostname 제공
- 조직 또는 서비스 제공자가 유지 관리할 수 있습니다. (기관 or ISP)
4. Local DNS server (웹 프록시 서버와 비슷함)
엄격하게 계층 구조에 속하지 않는다.
- 각 ISP(주거 ISP, 기업, 대학)는 로컬 DNS 서버를 하나씩 가진다.
- "default name server”라고도 함
- 호스트가 DNS 쿼리를 생성하면 쿼리가 로컬 DNS 서버로 전송됩니다.
- 최근 이름-주소 변환 쌍의 로컬 캐시가 있다(오래되었을 수도)
- 프록시 역할을 하여 쿼리를 계층 구조로 전달
Iterated query (반복형 쿼리)
Recursive query (재귀형 쿼리)
DNS caching
(모든) 네임 서버가 매핑을 학습하면 매핑을 캐시한다.
- 일정 시간(TTL) 후 캐시 항목 시간 초과(사라짐)
- TLD 서버는 일반적으로 local name 서버에 캐시된다.
- Root name 서버는 자주 방문 X
캐시된 항목이 오래되었을 수 있음(최선의 이름 & 주소로 변환!)
- name host가 IP 주소를 변경하면, 모든 TTL이 만료될 때까지 인터넷 전체에 알려지지 않을 수 있다.
3) DNS Records
DNS: distributed database 는 resource records (RR)를 저장.
- RR format: (name, value, type, ttl)
| type = A | type = CNAME | type = NS | type = MX | |
| name | 호스트 네임 | 도메인 네임 | 별칭 (aliasing name) | 도메인 네임 (별칭) |
| value | IP 주소 | 이 도메인에 대한 authoritative name server의 hostname <도메인 네임의 네임 서버> |
정규 이름 (canonical name) |
메일 서버 네임 |
'CS > 컴퓨터 네트워크' 카테고리의 다른 글
| Chap 2: Application Layer (2) (0) | 2023.03.09 |
|---|---|
| Chap 1: Computer Networks & Internet (0) | 2023.03.09 |