3장 네트워크 계층
ⓐ Overview
한 Segment를 서로 다른 클라이언트의 응용계층끼리 주고받는데에는 다음과 같은 절차를 따른다.
1. 응용계층은 소켓을 만들어 전송계층으로 데이터를 보낸다.
2. 전송계층은 헤더를 붙이고 네트워크 계층으로 보낸다.
3. 2번 과정처럼 각 계층마다 헤더를 붙이고, 물리적네트워크 계층에 다다르면 전송한다.
4. 전송받은 클라이언트는 헤더를 통해 세그먼트를 분류하면서 윗계층으로 보낸다.
5. 소켓을 통해 응용계층으로 전달되고 세그먼트의 값을 사용한다.
웹에서 사용되는 전송 프로토콜은 대표적으로 TCP, UDP가 있다.
TCP는 Transmission Constrol Protocol의 약어로, Reliable, In-order하며 혼잡제어, 흐름제어, 연결유지의 기능이 있다.
UDP는 User Datagram Protocol의 약어로 Unreliable, un-order하며 추가기능이 없다고 생각하면된다.
두 프로토콜 모두 제공하지 않는 기능으로는 Delay 개런티 ( 몇 초안에 반드시 전달 ), Bandwidth 개런티 ( 몇 패킷을 반드시 전달) 같은 것이 있다. 이런 내용은 프로토콜만으로 할 수 있는 기능이 아니기 때문에...
ⓑ Multi-Plexing, DeMultiPlexing
네트워크를 통해 전송된 세그먼트가 헤더를 통해 어느 응용계층으로 전달되는지의 과정을 디멀티플렉싱이라고 한다.
디멀티플렉싱은 각 세그먼트의 송신자,수신자의 IP, Port라는 4가지의 정보를 이용해 진행된다.
ⓒ UDP ( User Datagram Protocol )
UDP는 No Frills(추가 기능이 없다), Bare Bones(뼈만 있다) 라는 특징을 갖는 프로토콜이다.
전송과정중에 세그먼트가 Loss되거나 Out-Of-Order될 수는 있지만, 그것을 해결할 방법은 기본적인 UDP에는 없다.
또한, UDP는 Connection-less하기 때문에 송수신자간 Handshaking이 없으며, 각 UDP 세그먼트는 독립적으로 통신된다.
연결과정이 없기 때문에 RTT가 절약되고, 단순한 구조이므로 헤더가 작고, 혼잡제어가 없으므로 일반적으로 빠르게 보내질 수 있다.
위와 같은 특징으로 인해 UDP는 멀티미디어 스트리밍, DNS, SNMP, HTTP/3 (QUIC) 등에서 주로 사용된다.
HTTP/3같은 경우는 UDP 기반으로 응용계층에서 Reliable한 기능을 추가한 케이스이다.
UDP는 위에서 말한바와 같이 Loss되거나 Out-of-order된 세그먼트들에 대한 내용은 없지만,
전송된 세그먼트가 Corrupted됬는지 여부를 확인하기 위한 Checksum은 존재한다.
UDP 세그먼트는 Source Port / Dest Port / Length / Checksum / Paylod로 구성되며,
Checksum은 UDP 세그먼트를 16bit integer로 해석한 뒤 모두 더하고 1의 보수를 취한 값이다.
그러므로 만약 데이터가 정상적으로 수신됬다면, 수신자가 세그먼트를 16bit integer로 모두 더한값과 Checksum값을 더하면 1111....이 나오게 될 것이다. 이를 통해 오류를 검출할 수 있다.
ⓓ Reliable data transfer의 원리
응용계층이 전송계층으로 데이터를 전송할때는 Reliable Channel을 통해 전송한다.
그러나 네트워크 계층은 Unreliable하기 때문에,
Sender와 Receiver의 전송계층에서 이 데이터들을 Reliable하게 재구성한다.
그렇기 때문에, Reliable하게 만드는 작업의 난이도는 네트워크 계층의 상태에 의존한다.
주로 사용될 함수 용어에 대해 미리 설명해보자면 다음과 같다.
rdt_send : sender의 응용계층이 전송계층으로 데이터를 보낸다.
udt_send : sender의 전송계층이 네트워크 계층으로 데이터를 보낸다.
rdt_rcv : receiver의 네트워크 계층이 데이터를 수신해 전송계층으로 보낸다.
deliver_data : receiver의 전송계층이 데이터를 해석해 응용계층으로 보낸다.
rdt는 양방향 전송이 가능하지만 설명 편의상 단방향으로 설명하겠다.
rdt1.0 : Sender와 Receiver가 신뢰적인 채널에서 통신한다.
신뢰성 있는 채널이기 때문에 오류가 날 확률도 Loss가 날 확률도 없다.
그렇기 때문에 말그대로 서로 주고받기만 하면 된다.
rdt2.0 : 비트 에러가 발생할 수 있는 경우
환경이 좀 더 열악해져서 비트 에러가 발생할 수 있게 됬다.
그렇기 때문에 수신한 데이터에 에러가 있는지 검출할 필요가 있고, 이를 수정할 수 있어야 한다.
이를 위해 Receiver는 명시적으로 Sender에게 ACK패킷과 NAK패킷을 보내 자신의 상태를 알린다.
ACK (Acknowledge) : 성공적으로 수신함
NAK (Negative Acknowledge) : 수신에 실패함
Sender는 패킷을 보낸 뒤, Receiver가 위와 같은 응답을 보내지기를 대기하며,
이와 같은 방식을 Stop and Wait이라고한다.
Sender와 Receiver는 상대방의 상태를 알 수 있는 방법이 없으므로 이렇게 통신으로 상태를 알려야한다.
그런데, ACK/NAK패킷에 비트에러가 발생할 경우는 어떻게 해야할까?
안전하게 두번씩 보내면 되겠지만, 중복 데이터 수신으로 인한 문제가 발생할 수 있다.
rdt 2.1 : Sequence Number를 이용해 중복 데이터 수신 문제를 해결한다.
Sender는 보내는 패킷에 Sequence Number를 헤더에 작성한다.
Seq 0과 Seq 1을 번갈아가면서 전송하면서 Receiver는 0다음에는 1, 1다음에는 0만 수신한다.
만약, 0다음에 다시 또 0이온다면 그 데이터는 무시한다.
rdt2.2 : 그렇다면 NAK가 필요할까?
0을 수신하면 ACK 0을 리턴하고, 다음 데이터는 1이 오기를 기다린다.
하지만 다음 데이터도 0이오면 NAK를 보내고 다시 1을 기다린다.
근데 그렇다면 NAK를 보낼 필요 없이 다시 ACK 0을 리턴해도 똑같은게 아닐까?
라는 발상에서 NAK대신 ACK 패킷에 number를 담기 시작하였고, NAK-Free하게 되었다.
rdt 3.0 : 근데 만약 통신중에 비트에러 뿐만아니라 그 Segment채로 loss되버리면 어떻게 하는가?
Sender는 ACK를 일정 시간동안만 기다리고, Timeout이 발생하면 다시 보낸다.
물론 RTT가 길어서 응답세그먼트가 돌아오는중에 Timeout이 발생하여 중복전송이 일어날 수 있지만,
Seq #를 이용해 중복된 데이터는 알아서 무시할 것이다.
근데, Segment 송수신 과정에서 Stop and Wait과정을 이용하면 너무나 비 효율적이다.
회선 Utilization을 계산해보면 (L/R)/(RTT+(L/R))이다.
여기서 L은 파일의 크기, R은 회선의 대역폭이다.
회선의 대역폭이 크면 클수록, 파일이 작으면 작을수록 낭비가 커진다.
그래서 Pipelining을 통해 한번에 많은 패킷을 송수신해 회선 사용 효율을 늘리기로 했고,
이를 관리하는 방법이 Go-Back-N(GBN)과 Selective Repeat(SR)이다.
Go-Back-N은 Cumulative ACK라는 기법을 사용하는데,
순서대로 데이터를 받다가 어디를 뛰게 되면 무시하는 방식이다.
예를 들어, pkt0 pkt1 pkt3이렇게 전송받으면 pkt1과 pkt3은 둘다 ACK1을 반환하게된다.
그러다가 pkt2가 timeout되어 전송되면 ACK2부터 다시 진행한다.
Selective Repeat은 GBN과 달리 뛰어서 받은 정보도 보관해둔다.
그리고 pkt2가 수신되면 기존에 저장해둔 pkt3의 정보를 가져와서 ACK3부터 진행한다.
단순히 설명만보면 SR이 좀더 효율적으로 보이지만, GBN이 더 효율적일수도 있다.
왜냐하면 GBN은 마지막으로 정상적으로 수신한 위치가 어디인지의 정보만 기억하면 되지만,
SR은 내가 놓친 위치, 뛰어넘어서 받은 정보의 위치, 그 정보 와 같이 기억해야될 정보가 훨씬 많다.
이 뒤에 TCP랑 Flow control까지 시험범위인데, 너무 졸려서 오래 자버린 나머지 시험시간이 다되버려서 이만..