Transport Layer

multiplexing / demultipexing

• multiplexing은 sender쪽에서 보낸 여러 곳의 tcp 소켓에서 보내진 데이터를 세그먼트로 합쳐준다음 내려가는 것
• demultiplexing은 receiver쪽에서 세그먼트를 열어서 알맞은 소켓 번호로 데이터를 보내주는 것
  • udp demux : dst ip, dst port
    • udp는 연결 유지가 아니기 때문에, demultiplexing에서는 필요 없고 패킷 처리 이후 응답 보낼 때만 src ip, port가 필요하게 됨
    • src IP와 src Port는 UDP Demux 과정에서 고려되지 않습니다. 이로 인해, 송신자가 여러 개라도 동일한 dst IP와 dst Port로 데이터가 들어오면, 해당 데이터를 모두 같은 소켓에서 처리
  • tcp demux : src ip, src port, dst ip, dst port
    • 우선 tcp는 connection-oriented라서 서버 소켓 한개당 클라이언트 소켓 하나랑 연결되는 것 그래서 같은 src ip에서 온 값이 dst ip, dst port가 같으면 결국 src port로 확인한 다음, connect 되기 때문임
    • tcp는 각 소켓들이 각각 연결된 ip, port가 다름

segment란?

data + header(source port, destination port) 값

UDP header

1. source port(16bit = 6만몇개), dest port, length, checksum
   1. checksum : transport layer에서 확인했을 때, 뭔가 오류가 있으면 application layer로 올리기 전에 패킷 삭제

TCP header

1. reliable한 프로토콜을 유지하려 하지만, 계층이 내려가면 네트워크 상태나 회선 상태로 패킷이 유실되는 문제가 발생. 따라서 신뢰성을 위해 패킷의 오류, 손실 등을 확인하려함. 패킷 하나씩 보내고 문제 있는지 확인하는 답장 보내고를 반복하는 것임
2. error detection : 에러가 있는지 감지하고, Feedback: 패킷을 다시보내달라고 할지, 패킷 손실이 없는지 메세지를 보내줘야 함
   1. ack : 응 응
   2. naks : 뭐라고?

tcp 신뢰성 매커니즘

• rdt 2.0
  • 피드백을 줘서 패킷 상황을 나타내기
    • 피드백 주는데 오류가 나면 어떡함?
    • feedback 메세지에 대해서도 checksum 필요
    • feedback에러가 있을 때, 그냥 새로운 패킷을 보내서 다시함
      • 근데 새로운 패킷인지, 오류 나서 다시 한번 보낸 패킷인지 어캐 앎?
        • seq # 를 부여해서 seq 확인해서 패킷 판단 0,1
• 패킷 에러
  • Error detection, feedback, sequence
• 패킷 로스
  • Timer