: TCP
와 UDP
Multiplexing
(Sender 컴퓨터): 여러 소켓에서 전달받은 메세지를 전송 계층에서 모아서 네트워크 계층으로 전달해주는 것 (어플리케이션 계층 -> 전송 계층)cf. UDP는 Multiplexing/Demultiplexing과 error checking을 해줌
Demultiplexing
(Receiver 컴퓨터): 세그먼트를 받아서 거기에서 메세지를 꺼내서 알맞은 소켓(프로세스)에 전달해주는 것 (전송 계층 -> 어플리케이션 계층)Destination IP + Destination Port Number
Destination IP + Destination Port Number + Source IP + Source Port Number
=> 이 네 가지 중에 하나만 달라도 다른 소켓에 전달됨. 그렇기 때문에 Connection Oriented. 어떤 destination 소켓과 연결된 소켓은 하나밖에 없기 때문.
=> 즉 웹 서버는 TCP를 사용하기 때문에 웹 서버는 각 클라이언트를 위한 소켓을 가짐
: 전송 계층에 의해 전달되는 패킷의 단위
UDP 헤더: Source Port# + Destination port# + 데이터 lenght + checksum
=> 각각이 16bit. 이론상 컴퓨터 내 port number는 0~2^15개 정도 가능.
=> checksum은 전송 중 에러가 생겼는지 판단하기 위해 사용하는 필드. 에러가 있다면 Application 계층으로 올리지 않고 버려버림. (Multiplexing, Demultiplexing, Error Checking은 UDP도 함)
->즉, UDP가 하는 일은 에러 탐지와 multiplexing/demultiplexing
UDP를 사용하는 Application Protocol 예시
: DNS, SNMP
Unreliable한 환경(Channel)에서 Reliable하게 데이터를 전송해줘야함
Unreliable한 환경의 문제점은 1) 패킷 유실
2) 패킷 에러
<에러가 있는 상황 해결
>
-> 에러 검출 (checksum)
-> 피드백 (잘 받았다는 ACK, Negative Acknowledgement(NAK))
-> 재전송
<위 해결 방법의 문제점>
-> 피드백에 에러가 있는 경우 (ACK, NAK에도 checksum이 있어야함)
-> 재전송인지 아닌지 받는 입장에서는 알 수 없음
-> 패킷에 번호를 붙임 (같은 번호가 중복되면 재전송)
-> 번호가 무한대면 header가 너무 커지니까, sequence number를 최소화할 수 있어야 함(단순한 protocol에서는 0,1만으로도 가능)
<에러가 있는 상황의 protocol 정리>
sender
receiver
cf) NAK가 없는 프로토콜도 가능
<유실된 상황의 protocol
>
-> 타이머를 이용해서 일정 시간이 지나면(time-out) 재전송
-> 얼만큼 기다려야 할까? reasonable time( 네트워크 오버헤드(손실이 아닌데도 자꾸 재전송해서) & loss에 대한 늦은 반응이라는 trade off가 있기 때문에 논쟁이 많은 이슈)
ex) ACK loss인 경우
sender가 time out되면 packet(1)을 재전송. 이미 packet(1)은 잘 왔지만 receiver가 ack(1)을 재전송.