이석복 네트워크 (9)복습, UDP&DNS, network layer

===

http://ocw.hanyang.ac.kr/?course=8467 

컴퓨터네트워크_9회차

 

===

Chapter 1: Computer Network and Internet

인터넷은 서킷x 패킷o 기반의 통신. 데이터가 패킷이라는 독립적인 단위로 나뉘어진 후

네트워크 코어에 있는 라우터들이 패킷을 독립적인 단위로 인식해서 패킷별로 처리한다

 

===

문제는 

일순간에 라우터가 처리할 수 있는 용량보다 더 많은 패킷이 들어오면 문제가 생긴다

이때 생기는 현상, 임시 공간에 패킷을 둔다. 그 기다리는 시간 자체가 딜레이

라우터 안에 있는 버퍼(=큐) 에서 생기는 딜레이가 실제 인터넷상에서 발생하는 딜레이의 큰 요소

큐 공간도 모자라면 패킷드랍, 이게 현재 인터넷에서 발생하는 로스의 거의 대부분

 

===

라우터가 처음 패킷을 받았을 때 하는일

헤더정보 보기

어느목적지를 향해 준비해나갈지

패킷에 에러가 있는지

이 프로세싱하는 시간이 필요 = 프로세싱 딜레이

 

큐잉딜레이

 

큐에서 기다리다가 패킷이 링크로 뿜어내질때까지 걸리는 시간이 트랜스미션딜레이

 

링크로 올라와서 다음 라우터까지 걸리는 시간 = 빛의 속도 : 프로파게이션 딜레이

 

===

Chapter 2: Application layer

- HTTP

- DNS

- Socket

 

===

HTTP 프로토콜은 메시지 종류가 request, response뿐

서버는 단순히 요청된 파일을 전달 = stateless protocol

 

===

HTTP는 App layer protocol -> tr layer의 서비스를 받아야해.

HTTP는 TCP를 사용한다. 그래서 reliable한 전송이 가능

 

HTTP가 TCP를 사용하는 2가지 방식으로 나눠서 생각해볼 수 있다

- 한번 연결한 TCP connection을 계속 사용할건지 : Persistent HTTP  --HTTP에선 default로 이걸 사용하고 있다

- 매번 request할 때마다 다른  TCP connection 사용할건지 : Nonpersistent HTTP

TCP connection을 재사용하느냐 안하느냐의 차이

 

===

persistent HTTP사용하면서 pipelining 안할 때 딜레이 얼마나?(스피커)

K

L

R

d

 

제일 처음에 TCP conneciton 만든다 3way handshake,

SYN

SYN ACK

세번째는 메시지를 포함해서 HTTP request가 되는 것. 데이터를 포함한 ACK

세개 똑같으니까 *3(스피커)

그 다음 네번째 HTTP response

다섯번째부터 파이프 라인 아니니까 그냥 n번(스피커)

 

===

Chapter 3 Transport layer

TCP/UDP

 

===

UDP 필드 4개, 뭔가 이걸로 일을 하긴 해. 이걸로 어떤 서비스를 app layer한테 제공하는지

- 멀티/디멀티플렉싱

- 에러체크

 

DNS가 UDP를 사용하는 프로토콜

왜 DNS디자인하는 사람이 UDP 쓰는걸로 결정했을까? 생각해보기

▽일반 질의 UDP, 특정한 상황에 TCP. UDP는 도메인네임을 ip로 변경만 해서 정보를 기록하거나 유지할 필요가 없어서 신속성을 위해 UDP를 쓰는게 낫다고 한다

 

===

TCP의 Reliable Data Transfer

언더라인 네트워크 자체가 Unreliable하기 때문에 이걸 제공한다

- 패킷에러

- 패킷로스

두가지뿐

 

===

패킷에러를 해결하는데 필요한 메커니즘

에러탐지

에러가 났으니 피드백

재전송

재전송하기 때문에 구분을 위해 sequence number(이전 시간에 했다)

 

===

패킷로스를 위한 메커니즘

- timeout

 

===

실제적으로 우리가 인터넷에서 현실적으로 사용하려면 파이프라인 방식. 앞에것 피드백을 받지 않은 상황에서도 쏟아붓기

파이프 라인 방식으로 reliable data tranfer해야하고, 그렇게 할 수 있는 어프로치 gobackN, selective repeat 얘네 둘은 실제 구현된 프로토콜이 아니라 우리한테 방향을 제시해주는 어프로치

 

실제로 TCP는 섞어쓴다

 

===

gobackN : 단순,

receiver 할일없다 순서 바뀌어서 온거 트래킹해서 저장할 필요 없고 하나만 기다리면돼

sender 입장에서도 타이머가 하나

단점은 하나 유실되면 윈도우 안의 모든 패킷을 재전송

 

===

selective repeat은 유실된 패킷만 재전송, 하지만 구현자체가 복잡해

지능적인 리시버, 저장공간 많아야

센더도 패킷마다 timer를 갖고 있어야해

 

===

TCP는

point-to-point, 딱 두개의 소켓이 통신

reliable, in-order byte stream

pipelined

send&receive buffers(양쪽에 각각 센더 리시버 버퍼 두개)

...

 

===

TCP에서

seq

ack

의미

 

cumulative ACK

 

===

TCP는 패킷 유실에 대처하기 위해 타이머를 사용.

넉넉하게 잡아놔서 그 전에 유실을 잡아보자 해서 나온게 Fast Retransmit : 같은 seq해당하는 ACK 4개 받으면 패킷 유실로 판단. cumulative ACK라서 하나 유실되면 그것만 계속 보내

 

없어도 타이머가 있기 때문에 동작은 한다

 

===

Sample problem

처음에 보내는 패킷의 seq가 300이고 모든 패킷은 100bytes라는거네

 

파일이 완전히 전송될 때까지 패킷이 교환되는 

윈도우 사이즈 1000이라 한꺼번에 6개 다 보내진다

seq 300  --타이머 돌아간다

seq 400

...

 

두번째 패킷 유실됐다고 문제조건

그럼 리시버는

ACK 400

ACK 400

...

 

그 동안 리시버 버퍼에 500 600... 을 저장한다

처음에 A가 ACK 400받으면?윈도우 전진 399까지. 타이머해제, 타이머 다음거에 물린다

그리고 ACK400또오면? 할거없다 399까지 잘받았단소리니까  --왜 재전송이라고 생각했지  ▽ACK를 받아야 다른걸 보내는구나

글고 4번째 받았을 때 3dup -> fast retransmit, seq400 재전송 -> 버퍼에 400 들어온다 -> ACK 900 -> 윈도우 전진

 

===

Congetion Control

3가지 단계를 계속 반복해서 왔다갔다

slow start

linear

...

 

===

y축은 오타. congetion window size (MSS, 1이면 제일 큰 segment 하나 나가는 것)

4면 세그먼트 4개고, 각각 헤더 정보 다 틀리다 파악해봐 seq같은 것. seq는 결국 뭘까? 4개면 1, 2, 3, 4야? 아님  --중복 인지하려고 순서 붙인거잖아

 

===

Chapter 4: network layer

app layer, tr layer관점에서 생각해보면

네트워크는 복잡한 시스템. 이걸 잘 디자인하고 관리하기 위해서 계층화 시켜놓음 차곡차곡

상위계층으로 갈수록 개념적(app layer쪽)

하위계층으로 갈수록 디테일한게 더 보이도록(물리계층쪽)

 

그 계층이 client에도 있고 server에도 있는데

 

HTTP 얘기 할 때는 아래계층 생각 안하고 그냥 request, response만 생각함. 데이터 유실 이런거 생각도 안함. 그땐 밑에 보면 너무 복잡하니까

 

tr을 봤더니 둘 사이에 패킷 유실이 일어날 수 있다는 현실이 등장. segment보내고 피드백 받고 난리를 침. 하지만 역시 이때도 네트워크가 어떻게 생겼고 어떤 경로로 segment가 가는지 얘기 안함. 네트워크 자체가 블랙박스였어

 

이제 netowrk layer보면 안보고 있던게 보인다

->이제 실제로 TCP segment를 어떤 경로로 목적지까지 잘 배송시킬것인가 생각 할 차례

 

network layer에서 그런 일을 하는게 IP. Internet Protocol. 여기서 얘 딱 하나야. 배송에 대한 일을 관장한다

 

===

라우터가 패킷을 목적지까지 배송시켜주는 일에 참여. 그래서 라우터에는 network layer까지 존재하는 스택이 있다

 

===

라우터마다 network까지 올라갔다가 내려온다(그때 헤더분석, 목적지, 에러확인..=프로세싱딜레이)

 

===

라우터에서 하는일은 딱 2가지

- forwarding : 보내는 것

- routing : planning 하는 것

이 두개

 

===

라우터는 패킷이 들어오면 그 패킷을 목적지(헤더에 적혀있다)로 향하는 방향으로 전달한다. 부산이면 이쪽방향! 이런식

가는길이 어떤지 어떻게 아냐면

라우터 안에 테이블(표)이 있다. 특정 목적지로 가기 위해서는 몇번 인터페이스로 내보내라. 되게 단순

목적지가 0111이면 내 output link중에 2번링크로 보내라. 이게 forwarding

- 패킷의 목적지 보고

- 이 표보고(forwarding table)

- 보낸다

 

===

forwarding table을 만들어놔야 forwarding을 하는데, 누가 만들어? 전 세계 라우터가 몇갠데 사람이 못해

이게 바로 라우팅 알고리즘이 하는 일

라우팅 : 포워딩 테이블을 만들어주는 일을 하는 것

포워딩 : 포워딩 테이블을 참조해서 전달

 

근데 포워딩 테이블이 실제로 저렇게 생겼으면(▽IP하나하나 적는것?) 너무 많아서 관리 검색이 안돼 

->우체국에서 사용하는 방식으로 한다. 주소 범위로 관리된다

몇번부터 몇번까지 3번 인터페이스로 나가라.. 이런식

서울 대전 부산 이런식으로

이렇게 생겼어. 몇번부터 몇번까지

 

===

예)

*로 된건 앞의 부분만 동일하면 되다는 것(범위다)

examples 답 :

0

두번째 주소는 1도 맞고 2도 맞다 -> 더 구체적으로 맞는 곳으로 보낸다(longest prefix matching) -> 1로 보낸다

 

서울로 가는건 다 2번으로 보내되, 서울시 송파구면 1번으로 이런식