principle에 대해 이해해야합니다.
1. multiplexing
2. demultiplexing
3. reliable data transfer
4. flow control
5. congestion control
원리들을 이해하고 실재로 internet에 transport layer에 어떻게 적용이 되어 있는가 ?
UDP와 TCP를 제공해줍니다.
transport layer는 application process간에 논리적인 통신을 제공합니다.
app는 일반적으로 다른 hosts에서 실행되어야 합니다. 같은 host에서도 실행할순 있습니다.
하는일
보내는 쪽 : app에서 보내주는 message를 segment로 구분합니다. network layer로 내려줍니다. 그렇게 해서 상대방에게 보내줍니다.
받는 쪽 : segment들을 합치고 message로 만들고 app layer로 보내줍니다.
transport protocol은 end system에서 실행되어야 합니다.
network은 host간에 논리적 통신을 제공합니다.
transport는 process간에 논리적 통신을 제공합니다.
transport layer에서는 network layer에서 제공하는 service를 이용해서 서비스를 제공합니다.
internet에서는 어떤 종류의 transport protocol이 있는가?
인터넷에서는 TCP와 UDP가 있습니다.
TCP reliable, in order delivery
쪼개서 보내다보면 데이터가 사라질수 있는데 TCP는 사라졌을때 복구할수있음, 쪼갰을때 순서를 정렬해서 보내줍니다.
UDP unreliable, unordered delivery
데이터가 사라지면 복구불가능하고 순서가 뒤죽박죽이여도 정렬하지 않고 보냄
이게 없으면 transport layer가 성립되지 않음
transport는 process들로 segment를 받아서 header(추가 정보)을 붙이는 작업 multiplexing
demultiplexing이라는 것은 header을 이용해서 segment를 정확한 socket에 전달하는 작업
필요한 것이 무엇인가?
host가 ip datagram을 받으면 segment에는 source, destination port가 있음
host는 ip address와 port number을 사용하여 정확한 socket으로 segment를 전송합니다.
socket을 구분할수 있어야한다.
두가지로 나눌수 있습니다.
1. connectionless
udp에서 사용 destport가 같으면 항상 그 port를 가지고 있는 socket으로 이동합니다.
다른 source number을 가져도 dest port만 보고 갑니다. 연결이 없이 미리 source와 destination이 서로 연결을 맺여서 destnation port만 같으면 전달이 됩니다.
어디서 오던 destination port num이 같으면 받습니다.
이미지 첨부
TCP에서는 4가지 정보가 있어야합니다.
1. source IP address
2. source port number
3. dest IP address
4. dest port number
미리 연결설정을 해서 surce process와 des process가 정해져있습니다.
하나의 host가 여러개의 tcp socket을 사용할수 있습니다.
각각의 socket은 4가지 정보가 모두 다릅니다.
client하나하나마다 서로다른 socket을 만들어야합니다.
이미지 첨부
port가 같더라도 source ip가 다르기 때문에 사용가능
connectionless:
no handshaking reeiver과 sender간의 handshaking이 없음
각각의 segment가 독립적으로 처리됩니다.
source ip와 des ip가 항상 필요함
사용되는곳
이미지 첨부
flipped bit를 찾아내는 것
checksum은 16bit들을 다 더하고 one's complement를 만드는것
checksum 필드와 자신이 계산한 checksum이 다르면 error가 있고 같으면 에러가 없습니다.
엄청나게 중요합니다.
reliable한 data를 어떻게 제공해 줄것인가?
unreliable한 network layer을 이용하여 reliable channer처러 만듬
reliable data transfer protocol을 사용하여 send와 receive 두곳에서 packet을 검사합니다.
red_sent, udt_send, rdt_rcv, deliver_data함수를 사용합니다.
이미지 첨부
조금씩 복잡한 protocol을 만듭니다.한 방향으로 정상적으로 data transfer이 갈수 있으면 반대방향도 가능합니다.
어떻게 동작하는지를 확인하기 위해서 FSM을 사용합니다.
rdt1.0 reliable channel
bit error도 없고 packet loss도 없을때
체널 자체가 reliable하기에 단순합니다.
rdt2.0
bit error가 발생한 channel
packet이 가긴가는데 bit가 flip되는 경우
checksum을 이용하여 error을 확인해줍니다.
어떻게 error로 부터 recover을 할것인가?
checksum은 에러가 있는지 없는지 여부만 판단.
다시 물어보는 방식으로 에러를 수정
receiver에서 checksum의 error를 계산하고 에러가 있으면 다시 보내달라는 요청을 합니다.(NAKs)
bit error을 감지하고 피드백 합니다.(ACK와 NAK)를 사용해서 피드백합니다.
handling duplicate
ACK/NAK가 왔는데 뭔지 모르겠다 했을때는 retransmit해야한다. duplicate을 예방하기위해
sender는 sequence number을 추가합니다.
sender가 하나를 보내고 receiver에서 잘받을때 까지 반복해서 보내는 것 stop and wait
rdt 2.1
sender는 sequence num을 packet에 포함도이ㅓ 있습니다.
두개의 seq num 0,1을 사용합니다. 하나가 도착한후에 다음것을 보내기 때문에 0,1로도 가능
ack nak를 받았을때 corrupt되었는지도 확이해야합니다.
receiver는 내가 받은 packet이 duplicate인지 확인해야합니다.(중복) receiver는 자기가 보낸 ack와 nak가 sender에 정확히 도착했는지 모르기 때문에
rdt 2.2
rdt 2.1을 바꾼것 똑같은 기능을 하지만 ACK만을 사용합니다.
receiver는 ACK만을 보내는데 ACK를 보낼때 어떤 packet의 ACK인지를 포함해서 보냅니다.
정확하게 seq num을 정확하게 표시합니다.
같은 packet에대한 ack를 여러번 받을수 있습니다.(Duplicate ACK)
rdt 3.0bit가 error
error도 발생하고 loss도 발생하고 있는 상황ㅇ
위의 방법들만으로는 loss를 처리하는데는 불충분합니다.
적절한 시간만큼 sender가 ACK를 기다립니다.
그시간안에 안오면 문제가 생겼다고 판단합니다. 재전송합니다.
타이머를 도입했음 중복은 2.2에서 처리했기에 duplicate를 걱정할 필요는 없음
performance rdt3.0
굉장히 성능이 안좋습니다
stop and wait operation방법을 사용합니다.
이미지 첨부
실제로 보내는 시간
pipeline protocol
inreased utilization
ack가 없이 최대 3개까지 전송할수 있습니다.
ack를 받지않고 전송을 합니다.'
1 .Go-back-N
timer를 사용하다가 타임아웃이 발생하면 아직 받지 못한 파일들도 재전송합니다.
적어도 n개를 표현할수있는 만큼의 bit를 가지고 있어야 합니다,
application에서 n개의 data를 줘서 그만큼만 보냈습니다.
나 가면 usable,
이미지 첨부
2 selective Repeat
N개까지는 쭉 보낼수 있습니다.
rcvr는
패킷 한개마다 time을 설정합니다.