Transfort 계층의 가장 기본적인 목적은? Process to Process logical communication
•
해당 기능을 제공하기 위해서 transfort 계층에서 제공하는 가장 기본적인 기능은 Multiplexing/De-Multiplexing
•
보내는 측에서는 여러 소켓에서 오는 메세지를 받아야하고
•
받는 측에서는 네트워크를 통해서 오는 메세지를 목적시 소켓으로 배달해줘야함
Connection-oriented demux (커넥션 지향 디멀티플렉싱)
Connection-oriented는 서버에 여러 어플리케이션들이 있음
•
각 애플리케이션들은 도어소켓을 열고있고, 클라이언트가 접속하면 별도의 소켓을 열어서 소통
•
Receiver에서 demux를 하기 위해 4가지 정보가 다 필요함
◦
source IP address
◦
source port number (특정 클라이언트를 위한 포트)
◦
dest IP address
◦
dest port number (도어소켓 포트번호)
•
서버쪽 어플리케이션은 자식 proccess를 fork해서 해당 포트만을 담당하도록 함
◦
혹은 threaded server를 통해서 이용할 수 도 있음
UPD: User Datagram Protocol
•
connectionless한 transfort
◦
no handshaking
◦
각 UDP 세그먼트를 독립적으로 주고받음
•
네트워크계층에서 post delivery 이외의 추가적 기능을 제공하지 않음
•
best effort 서비스를 제공함
◦
best effort = 증권사가 팔 수 있는 한도(매도한도)까지 증권발행을 하는 형식. (출처: 네이버 백과사전)
◦
네트워크가 중간에 데이터가 소실되어도 UPD는 파악이 안되고 알려주지도 않음
◦
최선의 서비스를 제공
•
UDP를 이용하는 어플리케이션
◦
멀티미디어 스트리밍 어플리케이션 (유실에 관대함, 지연에 예민함)
◦
DNS
◦
SNMP (네트워크 관리 프로토콜)
▪
네트워트 토폴로지 같이 그룹에 묶인 여러 장치들이 중앙의 장치에게 정기적으로 자신의 상태를 REPORT함
•
reliable transfer over UDP = 신뢰성 있게 UDP 보내기
◦
아이러니 하게도 데이터의 무결성이 매우 중요한 어플리케이션의 경우 UDP를 이용하는 경우가 있음
▪
어플리케이션 스스로가 신뢰도를 체크하기 위해서
▪
에러가 발생했을때 리커버 할수있는 방법을 가지고있기 때문에
UDP: segment header
UDP의 장점은 아래와 같음
•
커넥션이 없기 때문에 오버헤드가 적음
•
단순함 = sender나 receiver에 대한 커넥션 정보가 없음
•
UDP 세그먼트의 헤더 사이즈가 작음
◦
UDP는 멀티플렉싱/디멀티플렉싱만 하기때문에 그 정보만 있으면 됨
•
혼잡도를 컨트롤하지 않음 = 때문에 어플리케이션이 생성하는 속도로 데이터를 내보낼 수 있게됨
UDP checksum
•
Sending UDP는 헤더를 포함한 세그먼트를 16bit integer 의 연속으로 인지함 ⇒ 이걸 다 더함
◦
이걸 checksum 필드에 넣어주게 됨
•
Recevier 측도 동일한 방법으로 더함 그게 Sender측 checksum과 일치하는지 확인함
◦
일치하면 데이터에 문제가 생기지 않았다고 가정할 수 있음
◦
일치하지 않으면? 오는동안 데이터 변형이 발생됨
▪
아예 다르면 슬그머니 드랍함
•
아주 단순한 방식의 checksum 방식이기 때문에 모든 에러를 검출할 수는 없음
principles of reliable data transfer
•
Checksum
◦
Recevier가 세그먼트를 받았을 때 오류를 판단할 수 있어야 한다
•
Acknowledgement
◦
일반적으로 Sender에게 패킷을 잘 받았다는것을 알려주기 위함
◦
해당 응답은 individual 혹은 cumulative일 수도 있음
•
Negative acknowledgement
◦
Sender에게 어떤 패킷이 잘못됬다 라는것을 알려주기 위함
◦
통하지 않을 수도 있음 = Recevier가 일단 패킷을 받는 경우엔 동작하지만 drop될 경우 받을 수 없음
•
Timer
◦
Sender측에서 데이터를 보냈는데 Ack/Nack이 오지 않을 경우 네트워크에서 drop되었다 생각하고 재전송을 함
◦
근데 불필요한 재전송이 발생할 수도 있음 = Recevier는 잘 받고 Ack/Nack을 보냈는데도 응답이 없어질 수도 있음
•
Sequence number
◦
타이머가 보낸걸 또 보낼수도 있기 때문에 시퀀스 넘버가 필요함
•
Window, pipelining
◦
센더와 리시버 사이의 파이프가 있다고 가정 다만 한개의 파이프 라인을 통해서 패킷을 주고받을 경우에 하나를 보내고 하나를 받고 하면 파이프에 하나의 패킷만이 왔다갔다함
◦
파이프의 효율성을 높이기 위한 작업이 파이프라이닝
◦
Ack을 받지않은 상태에서 집어넣을 수 있는 최대 데이터량을 윈도우라 함
Connection-oriented transport: TCP
Reliable, in-order byte stream
•
TCP는 자신이 전송하는 데이터를 byte stream으로 봄
•
TCP는 일단 어플레이션에서 내려오는 데이터를 자신의 버퍼에 담음
◦
해당 버퍼에서 데이터를 뽑을때 순서/혼잡도에 맞게 데이터를 뽑아옴
◦
유저의 메세지 바운더리는 인식하지 않고 바이트의 연속으로 인식함
Point to Point transfer
Sender와 Receiver가 각각 하나씩 존재
•
단 멀티캐스팅의 경우 Recevier가 여럿일 수 있음
Full duplex data
TCP 커넥션 클라이언트 프로세스와 서버프로세스를 위해 TCP커넥션을 맺으면 동일한 커넥션을 통해서 양방향 통신이 가능
Pipelined
TCP는 파이프의 효율을 높히고 작업량을 높히기 위해 윈도우를 설정 함
TCP Segment structure
•
UPD와 마찬가지로 크게 헤더와 페이로드로 나누어짐
•
header에서 options를 제외한 나머지 헤더는 모두 고정
◦
TCP의 총 헤더 길이는 가변적임!
◦
때문에 header length 필드가 필요함
•
고정헤더의 길이는 20byte 크기를 가짐 (32 bit * 5 line)
•
process to precess 를 제공하기 위한 source/dest port를 가짐
•
receive window는 flow control을 위한 필드임
◦
리시버가 받을 수 있는 버퍼사이즈임
•
U, A, P, R, S, F = 6개의 flag 비트
◦
A(Acknowledgement와 연관된 필드) = Acknowledgement에 너에대한 정보가 포함되었다는 의미
◦
connection estab
▪
R(커넥션 리셋)
▪
S(커넥션을 맺자는 요청을 보낼때)
▪
F(커넥션을 끝낼때)
◦
U, P ⇒ 두 플레그는 실제로는 활용되지 않고 잇음
▪
P : Push data now
•
데이터를 내려보내며 소켓 인터페이스에게 해당 데이터를 푸시해달라고 요청이 가능하게 하는 필드
⇒ 그러면 모든 버퍼에 있는 데이터와 지금온 데이터 모두를 즉시 내보내야 한다.
⇒ 해당 필드가 활성화 되어오면 리시버는 자신의 모든 버퍼를 플러쉬함
▪
U : Urgent data
•
소켓 인터페이스에 Urgent 한 데이터라는걸 표시해주는 플래그
•
P와 마찬가지로 모든 버퍼를 쏴버림
•
Urgent data pointer 필드에 Urgent한 데이터가 어디있는지 표시해서 보내줌
TCP seq, numbers, ACKs
•
sequence numbers
◦
세그먼트 페이로드에 실려있는 첫번째 바이트의 번호
•
acknowledgements
◦
누적 ACK을 사용함
◦
다음에 받을 seq를 기대한다!는 의미
TCP round trip time, timeout
Timer는 RTT와 관련이 깊음
•
RTT를 너무 짧게 잡으면? ACK이 오는 중임에도 불구하고 데이터를 다시 보냄
•
RTT를 너무 길게 잡으면? 타이머가 너무 늦게 알아게됨
•
ACK이 들어올때마다 round trip time의 샘플을 구하게 됨 ⇒ 다음번 RTT의 시간을 예측
◦
샘플 하나로는 예상하지 못함
◦
때문에 평균을 내는데, 이때 재전송된 RTT의 시간은 빼고 구함
•
평균을 이용함에도 불구하고 실제와 차이가 많이남
◦
EstimatedRTT에 Safety margin을 더함
safety margin을 구하는 식
