-
이석복 네트워크 (4)reliable(seq, ack, timer)Network/Network 2022. 7. 28. 18:52
===
http://ocw.hanyang.ac.kr/?course=8475
컴퓨터네트워크_4회차
애플리케이션계층2 (Application Layer) DNS학습 (Domain name service)
ocw.hanyang.ac.kr
===
각 레이어는 상위 레이어에게 서비스를 제공, 하위레이어로부터 서비스를 제공받는다
tr에는 현재 TCP/UDP가 자리잡고 있다
얘네는 기본적으로 상위레이어한테 멀티플렉싱, 에러체킹은해줘야해(UDP)
- 결국은 애플리케이션 프로세스끼리의 의사소통인데, 많은 프로세스 중에 하나로 올려줘야하는 멀티플렉싱
- tr을 사용해서 전달한 메시지는 에러가 있을 경우 위로 안올려보내
TCP는 좀 더 많은 기능이 있다
---
오늘 할것은 TCP보단 TCP에서 필요한
reliable 한 data transfer가 어떻게 이뤄지는지, 어떤 메커니즘이 필요한지, 원리는 뭔지
===
아래계층들은 unreliable해
패킷에러 or 패킷로스 이 두개뿐, 이 두가지 상황만 잘 처리하면 reliable
===
머릿속으로 reliable한 data transfer protocol을 한번 디자인해보자(RDT라고 이름 짓자)
일단 단순하게
한번에 패킷 하나씩만 보내고 리시버가 받았는지 100% 확신하고 다음 패킷보내고, 이런식의 신뢰성을 줄 것
이 동작을 finite state machines(FSM) 로 설명하고 있는 그림 : 각 스테이트가 있고, 이벤트가 발생하면 이러한 액션을 취하고 화살표가 있는 다음 스테이트로 이동
===
단순한 상황을 가정하고 점진적으로 프로토콜을 개선할 것 RDTv1.0 같이
가정 : 언더라인 네트워크 채널(아래계층)이 완벽하게 reliable
이때 메카니즘은 어때야 할까? 하는 그림
그냥 할게 없잖아 완벽한데 보내면 다 간다
이제 현실적인 상황을 하나씩 집어넣는다
===
packet errors
언더라인 채널이 패킷에러가 발생가능하면 우린 어떻게 신뢰성을 줄 수 있을까?
에러가 났는지 안났는지 판단해야한다
보내는 패킷에 checksum을 헤더에 담아서 보내면 받는 사람이 판단할 수 있다
리시버가 에러가 있는걸 확인했으면?
잘받았다 or 다시 보내달라든지 피드백 요청을 해야해
메시지를 받을 때마다 피드백을 줘야해! 해줘야 알아
ACK / NACK
전화통화할 때랑 똑같다, 이때도 에러발생가능한 상황
누가 말하면 듣는사람은 알게모르게 계속 어 어 정말? 어 뭐라고? 이러고있어
이게 ACKs든 NAKs든 계속 피드백을 주고 있는 것
이거 안주면서 말하는 사람 없다. 누가 말하면 아무말없이 계속 듣고 있으면 듣고있어? 한다 예의야
어 어 받으면 계속 얘기하고
뭐라고?(▽피드백) 하면 방금 했던말 반복하는 것 Retransmission(▽처음 보냈던 것 재전송)
∴ 에러가 있는 상황에서 필요한 메커니즘은 Error detection, Feedback, Retransmission
===
굳이 이걸 다 이해했지만 FSM으로 나타내본거래
수업시간에 이걸 하면 오히려 혼란스러울 수 있으니 복습하세요 방금 얘기했던거에요
센더는 보내고, ACK면 진행, NAK면 다시 보내고
리시버는 온거 에러체크하고 피드백보내주는 것
===
만약 피드백에 에러가 있으면? 잘받아서 ACK줬는데 이 피드백이 에러야
그럼 센더는 받고 이게 ACK인지 NAK인지 몰라
그럼 이제 피드백 패킷에도 checksum이 있어야 한다
근데 에러야
에러면 그럼 센더는 리시버가 ACK를 보냈는지 NAK를 보냈는지 판단이 안돼
어떤 상황인지 모르기 때문에 안받았다고 가정하고 그냥 다시 보내는게 해결책이래
그럼 리시버 입장에선 중복된 패킷인지 새로운 패킷인지 알길이 없어 -> potato potato 이렇게 오면 potato의 중복인지 potato potato 라는 걸 보낸건지 몰라
어떻게 해결해?
구분하라고 패킷에 번호를 붙이기 시작해. 이때 나오는게 sequence number
그럼 패킷에 번호가 같다는 걸 보고 중복이라는걸 안다
=>보냈는데 피드백이 온게 에러면 그냥 다시 보내는 게 해결책인데, 그럼 중복으로 보내지잖아. 받는 애가 어떻게 알아 중복인지 실제 내용이 반복인지, 그거 구분하려고 seq를 붙인다
===
피드백에 에러가 발생할 수 있으니 시퀀스 넘버를 모든 패킷에 붙인다
===
직관적으로 sequence number는 0부터 메기면 되는데, 직관적으로 편하긴한데
패킷의 헤더에 들어간단 말이야, 필드로 적힐텐데
0번부터 적어놓으면 무한대야, 필드크기가 커져
헤더는 메시지의 부가적인건데 커지면 안 좋아. 편지 보내는데 편지봉투에 빼곡하게 써있으면? 최소화 돼야해
지금 프로토콜 상황에서 sequence number 몇개가지고 충분할까?
0, 1 갖고 돌려쓰면 된다
0 보내고 받았으면 그 다음에 1, 받았으면 그 다음에 0
1bit면 충분하다
ACK가 에러남
받아보니까 에러네 하고 재전송, 0으로 또 보냄.(잘 받았는지 아닌지 모르니까)
리시버는 1번 기다리고 있어서 0번 와서 안받고 버리고 ACK, 그래야 새로운걸 보내지 ▽잘 받았는데 ACK가 error났던 상황
===
써머리
무조건 ACK보내야하는데 만약에 에러가 있을 경우에 NAK
===
이러면 완벽한데 좀 복잡해, NAK를 없앤 ACK만을 사용한 프로토콜도 가능하다
리시버는 NAK없이 무조건 받으면 ACK보내기
대신 ACK라는 피드백 안에 시퀀스 넘버를 적는다. 가장 마지막으로 내가 제대로 받은 번호
보낸게 에러면? 받긴 받았으니까 ACK는 보내야 하는데 마지막으로 잘 받은 번호를 또 보내면 된다(NAK대신)
이때 센더는 1번 보냈는데 0번 왔으니까 아 안갔구나 하고 안다
저기의 ACK(0)는 사실 NAK과 같은것
무조건 ACK를 사용하되 그 안에 들어가는 sequence number가 가장 마지막에 제대로 받은걸 보내면 된다
===
이제 여기(에러)에 loss까지 해서 reliable이 되면 완전체
지금까지 한거에 loss대비한 메커니즘을 붙이면 된다
메시지 보냈는데 유실되면 어떻게 돼?
sender입장 : 몰라.
야 오늘 저녁 같이 먹을래?
침묵.. 긴장 고조...
침묵을 못견딘 그는 내말 못들었어?라고 한다
우리 마음속에 알게 모르게 타이머가 있는 것
센더는 패킷을 보낼 때마다 타이머를 실행시켜서 시간동안 아무말 없으면 유실된거라고 판단한다
타이머의 시간은 얼마로 맞춰? "reasonable" 적당히
trade off가 있는데 타이머가 짧으면 유실이 일어났을 때 리액션이 빨라. 단점은 오래걸려서 멀리돌아올뿐인데 성급한걸수도 있어 중복된 패킷을 보내서 네트워크에 오버로드를 준다. 리시버가 잘 처리는 해 시퀀스넘버는 같잖아
반대는 반대로 효과가 난다
TCP얘기할 때 자세히 한다
===
최종 3.0
(a)00 11 00
(b)보면 안다
===
(c)리시버가 detect duplicate, ACK 1
(d)성급한 timeout, 일단 rdt3.0은 완벽하게 동작한다. 그 다음에 이걸 보고 이 이후에 어떻게 될지 생각해보기. 복습하면서 여러가지 상황 혼자 해보래
===
결국 unreliable네트워크 때문에 이런걸 하는것
unreliable네트워크에서 일어나는 일은
- 패킷에러
- 패킷로스
이 두개를 극복하기 위해 메커니즘을 하나씩 집어넣어야 하는데
패킷 에러를 위한게 저 그림의 4개(▽피드백이 ACK)
패킷 로스를 위한게 Timeout
이런 메커니즘이 코드안에 담겨 있고
이런 정보들이 패킷의 TCP헤더부분에 필드로 담겨간다
TCP가 기능이 이것만 있는게 아니라 헤더가 더 많고 각각 의미가 다 있다
===
지금까지 했던 RDT는 한번의 하나의 패킷밖에 못보낸다. 하나 보내고 도착한거 확인했으면 다시 보내고 이게 전제였다.
패킷보내고 갔다 오는 동안 네트워크가 아무것도 안하는거야. 이걸 실제로 사용할 수 있나? 그렇지 않다 성능 이슈
utilization : 전체 시간 중에서 sender가 네트워크를 사용하는 비율이 크면 클 수록 좋은데 너무 비효율적이다
RDT는 신뢰성 있는 통신을 제공하지만 성능은 굉장히 안좋다
y축이 시간의 흐름
전체 시간 분에 L / R (t = 0부터 t = L / R) = 0.00027
16차선 고속도로가 뚫려있는데 차 한대씩 보내는것
'Network > Network' 카테고리의 다른 글