- TCP가 지원하는 reliable은 어떻게 보장될 수 있을까?
- 사실 Network layer 이하 계층은 unreliable하다. 물리적인 문제, 시스템 문제 등으로 인하여 데이터의 loss나 error가 발생할 수 있다.
- 지금부터 데이터의 loss or error가 발생했을 때 문제를 해결 가능한 전송 방식을 설계해 보겠음
- 메시지의 요청이나 응답이 와야만 다음 요청을 보낸다고 가정.
Version 1
- underlying channel is perfectly reliable: no packet errors, no packet loss
- reliable transfer을 위해 해야 할 게 없음. 이미 완벽
Version 2
- channel with packet errors & no loss
- error detection을 위해 checksum bits가 필요
- error가 발생한 것에 대한 feedback 필요
- ACKs(Acknowledgements): receiver explicitly tells sender that packet received correctly
- NAKs(Negative ack-); receiver explicitly tells sender that packet had errors.
- Retransmission: sender retransmits packet on recepit of NAK
Version 3
- 여기에 더하여 ACK, NAK 전송이 error일 때를 고려해야 함
- 위 메커니즘 만으로는 error가 발생하여 sender가 재요청을 한 것을 식별하지 못 함, error가 나서 재요청을 한 것인지, 아니면 한 번 더 요청한 것인지 알 수가 없다.(예를 들어 암구호를 전송하는데 AA를 보낸 건지, 에러가 나서 A를 다시 보낸 건지 알 수가 없다.)
 |  |
- sender는 sequence # 를 붙여서 요청을 보낸다.
- receiver는 만약 이전에 요청된 packet과 sequence #가 동일하면 해당 패킷은 discard하고 응답한다.
- 이전 packet 정보에 대해서 저장하고 있기 때문에 구별이 가능하며, 동일 패킷을 또 처리할 필요가 없으므로 discard함
Version 4
- NAK-free protocol
- 오직 ACK만을 사용해서 동일한 메커니즘을 만들 수 있음
- Instead of NAK, receiver sends ACK for last correctly received packet(Receiver must explicitly include seq # of pkt being ACKed
- sender는 마지막으로 요청한 packet과 응답으로 온 packet에 seq # 비교하여 중복되었다면 이를 NAK로 판단하고 retransmit
Version 5
- channel with "loss" & packet erros
- packet을 보냈는데 손실되어 응답이 돌아오지 않는 경우는 어떻게 판단?
- timer를 두면 됨
- sender waits "reasonable" amout of time for ACK
- 하지만 packet 전송이 단순히 지연됐을 때랑 구분할 수가 없음
- 지연된 경우에는 중복된 요청을 보낸 것인지만 이는 seq # 를 이용해서 이미 해결할 수 있는 문제임
- 지금은 packet을 전송하고, 응답이 오면, 이후 재전송하는 요청-응답이 한 번씩 묶어서 이루어진다고 가정했음
- 하지만 현실에서는 여러 packet을 쏟아내듯 요청하고, 응답도 하나씩 오는 것이 아님
- 이를 어떻게 처리할 것인가, 다음 시간에
Hello World