[정보통신공학] Chap 2 - Protocol Architecture, TCP/IP, and Internet-based Applications

01_Protocol Architecture

---

☾ Protocol Architecture

왜 layering을 할까? 복잡한 시스템 다루려면 관련 있는 기능끼리 나누어야 유지보수가 가능하기 때문이다.

 

 

Internet Protocol Stack

자기 layer와 바로 위, 아래 아니면 신경 안 쓴다.

 

 

L5 : application 어플리케이션 네트워킹 도와줌(HTTP, IMAP, SMTP) → message

 

L4 : transport 데이터를 end-to-end로 잘 보냈는지 체크(TCP, UDP) → segment

 

L3 : network source-to-destination이 어떤 루트로 가야하는지 담당(IP) → datagram

 

L2 : link switch-to-switch로 데이터 전송 담당(Ethernet, wifi) → frame

 

L1 : physical 실제 전파, 와이어를 어떻게 보낼 것인지 담당

 

 

Encapsulation

1. 사용자가 message 전송 → message에 오버헤드 붙여서 segment 만듦 → segment에 오버헤드 붙여서 datagram 만듦 → datagram에 오버헤드 붙여서 frame
2. switch로 전송 → link 헤더 참조해서 이동(L2)
3. router로 전송 → network 헤더 참조해서 이동(L3)
4. 목적지 도착 → physical부터 application까지 오버헤드 하나씩 벗겨가면서 데이터 전송

 

 

 

 

02_TCP/IP

---

☾ Internet Protocol Stack

Physical layer

컴퓨터와 네트워크 사이의 physical interface를 담당

전송 매체, 신호의 주변 상황, 전송률을 고려해야 한다.

 

 

Network Access / Data Link layer

홉-to-홉(frame or 맞닿아 있는 디바이스) 간의 데이터 교환과 관련

packet(frame)

 

 

Internet layer

routing을 잘할 수 있게 하는 역할 담당(IP)

datagram(packet)

 

 

Transport / Host-to-Host layer

reliable end-to-end service를 제공(TCP) or unreliable service 제공(UDP)

end point 간의 데이터 전송과 관련

• TCP : 위치 하나하나 추적
• UDP : 빨리 정보 처리. 에러 컨트롤 x

segment

 

 

Application layer

사용자 요청 메시지 or 서버의 응답

특정 IP, port number 필요 → 특정 프로세스 인식 가능

message(byte stream)

 

• TCP/IP 주소 요청

host 연결 위해서는 internet address 필요

process 식별에는 port number 필요

 

 

 

☾ Transmission Control Protocol(TCP)

application 사이의 reliable connection 제공하는 프로토콜

sender와 receiver 사이의 flow control 중요하다.

network 사이의 congestion control 중요하다.

segment가 기본 단위

end-to-end 사이의 segment가 잘 도착했는지 체크

손실 없이 순서대로(no loss, in order)

시간적으로 불리하다.

꼭 연결을 맺고 시작해야 한다.

port number, sequence number, acknowledgement number, checksum 등이 필요

파일 다운로드, 이메일 등에서 사용

→ TCP 보안을 위해 Transport layer security(TLS)로 암호화 제공 → application layer에 적용

 

 

 

☾ User Datagram Protocol(UCP)

전송을 보장하지 않는다.

나에게 온 데이터를 application으로 전달

단순하고 헤더 없다.

연결을 맺지 않아도 된다.

checksum을 포함한다.

port number, segment length, checksum(오류 여부만 확인) 존재

e.g. 실시간 오디오, 비디오, Internet telephony, interactive games

 

 

 

☾ IP

• address 공간

IPv4 : 32bit

IPv6 : 128bit

 

 

 

 

03_Principles of network applications(Application layer)

---

☾ Client-server Paradigm(e.g. HTTP, IMAP, FTP)

• server

서버는 항상 켜있어야 한다.

공용, 불변의 IP 주소를 갖고 있다.

여러 곳에서 서버에 접속할 수 있도록 주로 data center에 존재한다.

무조건 서버 공유한다.

 

• client

서버와 소통한다.

간헐적으로 연결된다.

변동 IP 주소를 갖고 있다.

클라이언트끼리 직접 소통하지 않는다.

 

 

 

☾ Peer-peer Architecture(e.g. P2P)

서버가 항상 켜있지 않는다.

end system 끼리 직접 연결한다.

간헐적으로 연결된다.

self scalability : 모든 단말이 저마다의 서버가 된다.(단말은 요청도 하고 응답도 한다.)

 

 

Process

한 host 내에서 돌아가는 프로그램(유저 어플리케이션)

같은 host 내에서 다른 process 통신 or 다른 host와 통신

• client process : 통신 시작(요청)
• server process : 통신 기다림

 

 

Socket

application layer(L5)와 transport layer(L4) 사이의 연결통로

application은 다른 건 신경 안 쓰고 socket을 통해 메시지를 주고받는다.

Addressing Process에서 메시지 받으려면 IP address + port number가 필요

 

 

IP address

어떤 host인지 알기 위해

network layer에 존재

e.g. 128.119.245.12

 

 

port number

어떤 process(application)인지 알기 위해

transport layer에 존재

e.g. 80

Application layer protocol는 메시지 타입(요청, 응답), 메시지 신택스, 메시지 의미, 규칙 등을 정의해야 한다.

앱은 data integrity, timing, throughput, security가 필요하다.

 

 

 

 

04_Web and HTTP

---

URL

www.someschool.edu/someDept/pic.gif

- - - host name - - -  |  - - path name - -

 

 

 

☾ HTTP(HyperText Transfer Protocol)

client와 server가 어떻게 통신해야 하는지 정의한 규약

application layer protocol

client-server 모델에서 사용한다.

딜레이가 있더라도 TCP를 사용한다.

일회성(stateless). 과거 요청, 정보 기억하지 않는다.

client는 port number 80을 사용하여 server와 TCP 연결 시작 → socket 생성 → server는 TCP 승인 → HTTP 메시지 왔다갔다 함 → TCP 연결 종료

 

 

HTTP request message

모든 HTTP request는 독립적

ASCII 코드로 작성되어 있다.

 

 

HTTP request method

POST method : 사용자 form 입력. 사용자 입력을 client에서 server로 전송할 때. HTTP body에 데이터 보냄

GET method : url 데이터를 포함해서 전송할 때. url 필드에서 데이터 보냄

HEAD method : request 메시지의 답변을 body 없이 header만 보낼 때

PUT method : file 업로드할 때

 

 

HTTP response message

 

 

HTTP response status code

200 OK : 성공적으로 응답

301 Moved Permanently : 요청이 이동됨. 서버 위치 달라짐

400 Bad Request : 메시지 오류. 잘못된 요청

404 Not Found : 요청을 찾을 수 없음

505 HTTP Version Not Supported : 버전 지원 안함

 

 

HTTP Cookies

사용자 IP를 사용하여 기록을 저장한다.

사용자, 서버의 state를 유지 및 관리한다.

사이트가 사용자 정보를 얻을 수 있도록 한다.

한 웹사이트뿐만 아니라 여러 웹사이트에서 나에 대한 정보를 포함할 수 있다.

 

• 사용법

1. 웹사이트가 임의의 숫자(cookie)를 header에 담아서 response
2. header에 cookie 담긴 상태로 계속 주고받는다.
3. server에 cookie 정보 담긴다.

 

 

Web caches(proxy servers)

client가 많이 요청하는 데이터를 proxy server(대체 서버)가 중간에서 보내준다

→ response time, traffic 감소

client와 server 역할을 동시에 한다(데이터 요청하는 client에게는 서버 역할을, 기존 server에게는 클라이언트 역할을 함)

 

 

 

 

05_E-mail, SMTP, IMAP

---

☾ E-mail

• 구성요소
  • user agents : 유저 계정. 한 이메일에서 여러 계정 굴림
  • mail servers : 메일을 주고받는 서버
  • SMTP : 이메일 보낼 때의 프로토콜

 

 

user agent

메일을 관리하고 읽음

e.g., outlook

 

 

mail server

사용자의 메일 보관

메시지 queue에서 하나씩

 

 

SMTP

mail server 간의 이메일 보내는 규약

port number 25에서 TCP를 사용한다.

client와 server가 직접 주고받는다.

7bit ASCII 코드를 사용한다.

• client : mail server를 보냄
• server : mail server를 받음

 

• 이메일 보내는 과정

1. 보내는 측의 user agent가 client’s mail server로 데이터를 보낸다.
2. client’s mail server가 server’s mail server로 TCP 연결을 통해 보낸다.
3. 받는 측의 user agent로 데이터가 전송된다.

 

 

HTTP vs SMTP

• HTTP

정보 요청(서비스 pull)

각각의 객체가 각각의 response 메시지

 

• SMTP

정보 전달(서비스 push)

여러 객체가 메시지 받을 수 있음

지속적인 연결 사용

 

 

IMAP, Pop

IMAP : 내 server와 완벽 동기화

Pop : 복제복만 다운로드. 서버와 별도. 단방향. 내가 뭘해도 진짜 내 서버에는 연동 안됨.

 

 

 

 

06_Socket programming with UDP and TCP

---

☾ Socket programming

application layer는 무조건 socket으로 통신

application process & end-end protocol 사이의 통로 역할

• socket type
  • UDP : unreliable datagram
  • TCP : reliable, byte stream-oriented. loss, order 꼬임 없음

 

 

 

☾ UDP

unreliable datagram

client와 server 사이에 연결이 없다.(no handshaking)

서버가 항상 열려있다.

늘 client가 server에게 데이터 요청한다.

IP address, port number를 packet에 붙여서 전달한다.

받는 쪽은 보내는 사람의 IP address, port number를 확인한다.

순서대로 오지 않는다.

loss가 존재한다.

client는 특정 하나의 socket만을 위한 것이 아님

 

 

 

☾ TCP

reliable, in-order

client가 먼저 server 컨택

server는 항상 running

server는 public door(누구나 접속할 수 있는 문)를 만들어 놓는다.(특정 client만을 위한 것이 아님)

컨택이 오면 그 client만을 위한 전용 socket을 생성한다.

client가 socket 만들 때, server TCP랑 연결 시작한다.