📡 데이터통신네트워크 4주차

Application Layer

[ 네트워크 앱 만들기 ]

{ 이러한 프로그램을 만들어요 : }

- end systems (끝단말) 에서 작동하는  ( 끝 단말에서는 소프트웨어 개발 필요)

- 네트워크를 통해 의사소통이 가능한

 

{network 중안core devices에서는 소프트웨어를 개발할 필요 없다) }

- core들은 유저 앱을 작동시키지 X

- end system에 있는 앱들이 앱개발에 도움

 

---

[Client-server architecture]

{ Server }

- 항상 켜져있음

- 고정적 IP 주소

ex) 보통 데이터 센터에 존재

{ clients }

- 서버와 컨택하고 의사소통

- IP주소가 유동적임

- 서로 직접적으로 소통하지 않는다!

ex) HTTP, IMAP, FTP

 

---

[ Peer-Peer architecture  P2P ]

- no always-on server

- end systems와 직접적으로 소통

- peer끼리 service를 주고받음

- 모두가 클라이언트이자 서버가 될수 있음

  ➡️ self scalability : 자발적 규모성(커졌다 작아졌다 가능) - 클라이언트 서버 모델과 확연히 다른 차이점

ex) P2P 파일공유

---

[ Process Communicating ]

process : 호스트로 실행되는 프로그램

- 같은 호스트인 경우, 하나의 호스트에서 동시에 동작하는 프로그램이 서로 상호 대화한다 (IPC inter process communication)

- 다른 호스트의 경우, 메시지를 교환하는 방식으로 대화한다

 

{client, servers}

client process : 접속을 먼저 시도하는 프로세스

server process : 접속을 기다리는 프로세스

P2P는 이 두 개를 모두 가지고 있다

 

---

[ Sockets ]

- sockets API : 네트워크를 위해 사용되는 인터페이스

- process 는 socket으로/에게 메시지를 주고받음

---

[ Adressinig process - 주소 지정 ]

-  메시지를 받기 위해서, process는 identifier를 가지고 있어야 함

- host device는 32비트 ip 주소를 가지고 있음

 

 

특정한 프로세스를 찾기위해서 identifier에 IP주소와 port번호가 필요하다 (이 값을 socket pair라 부름)

ex)

HTTP server 포트번호: 80

mail server 포트번호 : 25

일 때,

HTTP 메시지를 웹서버에 보내기위해서는

IP 주소 : 128.XXX

port 번호 : 80

이 필요함

목적하는 포트번호는 80으로 고정됨

---

 

[ 앱 레이어 프로토콜 정의 ]

1. 메시지 교환의 타입들

2. 메시지 문법(format)

3. 메시지의 의미(order)

4. 법칙

 

{ 앱 레이어 프로토콜의 종류 }

<공개 프로토콜>

모든 사람이 접근 가능

상호 운용성이 있다

ex. HTTP, SMTP

 

<비공개 프로토콜>

ex. Skype

---

[ App 에게 필요한 전송 서비스 조건들 ]

{ 데이터 무결성 }

- 날아오다가 비트 에러가 생격서 비트 하나가 0에서 1로 바뀌는 걸 체크하는 특성

- 100% 신뢰할만한 데이터 전송을 요구한다!

{ 시간 제한 조건 }

{ 전송 조건 }

{ 보안 조건 }

---

[ 인터넷 전송 프로토콜 서비스 ]

[ TCP ]

- 신뢰할 수 있는 전송(100% 전송 보장)

- 흐름 제어

- 혼잡 제어

- 연결 지향적 -연결전 승인을 받아야함

TCP는 위 기능 외에는 아무것도 하지 못해요!!

 

[ UDP ]

기능 없음 , 그냥 무작정 전송

 

Q. 그러면 UDP는 왜 존재하는가

A. 빨라서.

---

[ 보안 TCP ]

Vanilla(순정) TCP 와  UDP 소켓들

- no 암호화

 

TLS

- 암호화된 TCP 연결 제공

---

---

 

[ 웹과 HTTP ]

- 웹은 HTTP파일을 가지고 있는 페이지

---

[HTTP]

hypertext protocol

{client/server 모델}

- client : 요청/받음, 그리고 웹 오브젝트를 보여주

- server: 오브젝트를 전송하는 웹서버

 

{ HTTP는 TCP 사용한다 }

1. TCP 연결 초기화, 요청

2. 승낙을 받음

3. HTTP 메시지 교환

4. TCP 연결 끊음

 

HTTP는 과거를 저장하지 않는 특성이 있다! stateless

(stateful인 프로토콜인 경우 매우 복잡)

---

[ HTTP의 버전 ]

{ non-persistent HTTP } 1.0

- 오브젝트를 하나만 받고 연결 끊어 버림

- 따라서 매 데이터를 요청할 때마다 TCP 연결을 새로 해야함

 

non-persistent HTTP의 응답 시간 = 2 * 왕복시간(RTT) + 파일 전송시간

즉, 오브젝트 파일 하나를 받는데 최소한 2개의 RTT시간이 필요

 

{ 고정적 persistent HTTP } 1.1

- 하나의 TCP 연결에 대해 여러 오브젝트를 받는다

- 하나의 오브젝트당 RTT가 하나정도만 필요. - 즉 n-p 보다 2배정도 빨라졌다! 

---

[ HTTP 요청 메시지의 명령어 ]

POST  !

- 데이터를 서버한테 보낼때

GET !

- 웹페이지 에서 어떤 정보를 얻고자 요청할때

HEAD

- 헤더만 요청

PUT

- 파일을 올리거나 교체

 

[HTTP 답장 메시지]

ex)

202 OK

301 Moved Permanently

400 Bad Request

404 not found

505 HTTP Version Not Supported

---

 

[Cookies]

- HTTP는 Stateless 하면서도 쿠키를 저장한다

- 웹사이트와 클라이언트 브라우저는 어떤 상태를 유지하기 위해 쿠키 사용

- 쿠키 아이디를 줌으로써 그 아이디 저장, 쿠키 사용 가능

---

 

{쿠키는 언제 사용되나요

- 승인

- 쇼핑 장바구니

- 추천

 - 웹 이메일

 

but 쿠키는 개인정보에 대한 단점이 이씀 - 그 수업 쿠키로 남의 이메일 로그인하는거

---

[웹 캐시caches - proxy servers]

속도를 더 빠르게 하기 위해서 프록시 서버 사용

ISP에 의해 깔림

{왜? 사용하는가?}

- 응답 시간 줄여줌

- 트래픽 감소

---

 

[HTTP/2 로]

-HTTP1.1 의 문제는 FCFS의 문제가 있었다  - HOL 블로킹의 문제

- HTTP2는 잘라서 해결(framing) - 오브젝트를 작게 잘라서 처리및 전송을 번갈아가면서 함

                   push 라는 기능 추가 (1에서는 텍스트 형태로 HTTP 메시지를 보냈으나 2에서는binary frame으로 인코딩되어 보내는 방식으로 개선)

 

 

[ HTTP2 에서 HTTP3 로 ]

- 보안, 에러 제어, 혼잡제어 (using UDP (QUIC)) 기능 추가