3.4 신뢰적인 데이터 전송의 원리

이 절에서는 일반적인 상황에서의 신뢰적인 데이터 전송 문제 다룬다. 이는 신뢰적인 데이터 전송을 구현하는 문제가 트랜스포트 계층뿐만 아니라 링크 계층, 앱 계층에서도 발생할 수 있는 문제이기 때문이다. 이 문제는 정말 중요하다. 네트워킹에서 근본적으로 중요한 문제중 최상위가 이 문제가 선택될것이다. 다음절에서야 TCP를 설명하며, 특히 TCP가 지금 설명하려는 많은 원리를 이용한다.

다음 그림은 신뢰적인 데이터 전송 연구의 프레임워크.

상위 계층 객체에게 제공되는 서비스 추상화는 데이터가 전송될 수 있는 신뢰적인 채널의 추상화다. 신뢰적인 채널에서는 전송된 데이터가 손상(0이 1이되거나 1이 0이 되거나)되거나 손실되지 않는다. 그리고 전송된 순서 그대로 전달된다.

이런 서비스 추상화를 구현하는 것이 신뢰적인 데이터 전송 프로토콜의 의무다. 이 작업은 신뢰적인 전송 프로토콜의 ‘아래에 있는’ 계층이 신뢰적이지 않을 수 있어 어려워 진다. 그 예로, TCP는 비신뢰적인 종단 간의 네트워크 계층(IP)의 바로 상위에 구현된 신뢰적인 데이터 전송 프로토콜이다.

rdt는 신뢰적인 데이터 전송(reliable data transfer). 21페이지에서 이 절에서 가정하는 요소를 설명해준다. 이 절에서는 단방향 데이터 전송인 경우인 송신측으로부터 수신측까지의 데이터 전송만을 고려한다. udt 비신뢰적인 데이터 전송(unreliable data transfer).

3.4.1 신뢰적인 데이터 전송 프로토콜의 구축

완전히 신뢰적인 데이터 전송 프로토콜에 도달하기 위해 조금씩 더 복잡해진는 일련의 프로토콜들을 알아보자.

완벽하게 신뢰적인 채널상에서의 신뢰적인 데이터 전송: rdt 1.0

먼저, 하위 채널이 완전히 신뢰적인 가장 간단한 경우를 고려한다. 프로토콜 자체는 단순하며 rdt 1.0 이라 부르겠다. rdt 1.0 송신자와 수신자에 대한 유한상태 머신(finite state machine, FSM)정리는 그림 3.9에 있다. (a)에서 FSM은 송신자의 동작을 정의, (b)의 FSM은 수신자의 동작을 정의한다. 송신자에 대해 그리고 수신자에 대해 분리된 FSM이 있다는 것을 유의. 그림에서는 각각 하나의 상태만 가지고있다. FSM 설명의 화살표는 한 상태로 부터 다른 상태로의 전이를 의미. 전이를 일으키는 이벤트는 변화를 표기하는 가로선 위에 나타낸다. 그리고 이벤트가 발생했을 때 취해지는 액션은 가로선 아래에 나타난다. 이벤트 발생 시 어떠한 행동도 취해지지 않거나 어떠한 이벤트 없이 행동이 취해질 때, 동작이나 이벤트가 없음을 명시하기 위해 각각 가로선 아래나 위에 기호 A를 사용한다. FSM의 초기 상태는 점선 화살표로 표신됨. 그림 3.9에서는 FSM이 각각 한 상태만 나타내지만, 앞으로는 여러 상태를 갖고있는 FSM을 볼 것이며, 따라서 FSM 의 초기 상태를 확인하는 것은 중요하다.

rdt의 송신 측은 rdt_send(data) 이벤트의 의해 상위 계층으로 부터 데이터를 받아들이고 데이터를 포함한 패킷을 생성한다.(make_pkt(data)의해). 그리고 난 후 패킷을 채널로 송신한다. 실제로 rdt_send(data) 이벤트는 상위 계층 애플리케이션의 프로시저 호출(예: rdt_send())에 의해 발생한다.

수신측에서 rdt는 rdt_rcv(packet) 이벤트에 의해 하위 채널로부터 패킷을 수신하고, 패킷으로 부터 (extract(packet, data)의해) 데이터를 추출하고 데이터를 상위 계층으로 전달한다.(deliver_data(data)). rdt_rcv(packet) 이벤트는 하위 계층 프로토콜로 부터 프로시저 호출(예: rdt_rcv())에 의해 발생한다.

이런 간단한 프로토콜에서는 데이터 단위와 패킷의 차이점이 없다. 또한 모든 패킷 흐름은 송신자로부터 수신자 까지다. 즉, 완전히 신뢰적인 채널에서는 오류가 생길 수 없으므로 수신 측이 송신 측에게 어떤 피드백을 제공할 필요도 없다. 또한 수신자는 송신자가 데이터를 송신하자마자 데이터를 수신할 수 있다 가정했음을 유념. 따라서 수신자가 송신자에게 천천히 보내라는 것을 요청할 필요가 없다.

이 파트 무슨내용이냐?

네, 이 내용을 아주 쉽게 풀어서 설명해 드릴게요. 컴퓨터 용어에 익숙하지 않아도 이해할 수 있도록 비유를 들어보겠습니다.

한 줄 요약

“rdt 1.0”은 ‘절대 사고가 나지 않는 완벽한 택배 시스템’을 이용할 때, 우리가 어떻게 물건을 보내고 받는지에 대한 가장 기본적인 설명서입니다.

자세한 설명 (택배 비유)

컴퓨터가 데이터를 주고받는 걸, 우리가 택배를 보내고 받는 과정이라고 생각해 볼게요.

1. 핵심 가정: 완벽한 택배 시스템

책에서 말하는 **“완벽하게 신뢰적인 채널”**은 이런 뜻입니다.

내가 보낸 택배는 절대 분실되지 않아요.
택배 상자가 절대 찌그러지거나 내용물이 망가지지 않아요.
내가 1번, 2번, 3번 순서로 보냈다면, 받는 사람도 반드시 1, 2, 3 순서로 받아요.

현실에는 이런 택배 시스템이 없겠죠? 하지만 컴퓨터 네트워크를 공부할 때, 가장 이상적이고 단순한 상황부터 시작하는 거예요. 이게 바로 rdt 1.0입니다.

2. FSM (유한상태 머신)은 뭔가요?

어려운 단어 같지만, 사실은 그냥 “행동 설명서” 또는 **“상황별 매뉴얼”**이라고 생각하면 됩니다.

예를 들어 자판기 FSM을 볼까요?

상태 1: “돈 기다리는 중”
- 이벤트: 동전을 넣는다.
- 행동: “돈 받은 상태”로 바뀐다.
상태 2: “돈 받은 상태”
- 이벤트: 음료수 버튼을 누른다.
- 행동: 음료수를 내보내고, “돈 기다리는 중” 상태로 돌아간다.

이처럼 ‘어떤 상태’에서 ‘무슨 일’이 생기면 ‘어떤 행동’을 한다고 정의해 놓은 그림이 바로 FSM입니다.

3. rdt 1.0의 행동 설명서 (FSM)

책에 나온 그림은 이 완벽한 택배 시스템을 이용하는 **보내는 사람(송신자)**과 **받는 사람(수신자)**의 행동 설명서입니다.

(a) 보내는 사람 (송신자)의 행동 설명서

상태: 보내는 사람은 걱정이 없어요. 택배 시스템이 완벽하니까요. 그래서 상태가 딱 하나뿐입니다: “보낼 준비 완료 상태”
설명서 내용:
1. (이벤트) 윗사람(예: 쇼핑몰 사장님)이 “이 물건(data) 좀 보내줘!”라고 요청합니다. (rdt_send(data))
2. (행동)
  - 물건을 택배 상자(packet)에 예쁘게 포장합니다. (make_pkt(data))
  - 그 상자를 완벽한 택배 시스템에 맡깁니다. (udt_send(packet))
3. 끝! 이제 보내는 사람은 다음 물건을 보낼 준비를 합니다. (다시 “보낼 준비 완료 상태”로 돌아감) (b) 받는 사람 (수신자)의 행동 설명서
상태: 받는 사람도 걱정이 없어요. 택배가 순서대로, 안전하게 오니까요. 그래서 상태가 딱 하나뿐입니다: “받을 준비 완료 상태”
설명서 내용:
1. (이벤트) 완벽한 택배 시스템에서 “택배(packet) 왔어요!” 하고 알려줍니다. (rdt_rcv(packet))
2. (행동)
  - 택배 상자를 열어서 물건(data)을 꺼냅니다. (extract(packet, data))
  - 꺼낸 물건을 기다리던 윗사람(예: 물건 주문한 고객)에게 전달합니다. (deliver_data(data))
3. 끝! 이제 받는 사람은 다음 택배를 받을 준비를 합니다. (다시 “받을 준비 완료 상태”로 돌아감)

왜 이렇게 간단할까요?

피드백(답장)이 필요 없어요: 택배가 100% 도착하니까 받는 사람이 “잘 받았어!”라고 굳이 연락할 필요가 없죠.
오류 검사가 필요 없어요: 내용물이 절대 망가지지 않으니, “이거 혹시 깨진 거 아니야?” 하고 확인할 필요가 없어요.
속도 조절이 필요 없어요: 보내는 사람이 아무리 빨리 보내도 받는 사람은 착착 잘 받는다고 가정하기 때문에, “좀 천천히 보내!”라고 요청할 필요가 없어요.

결론적으로 rdt 1.0은 데이터 전송의 가장 이상적인 ‘유토피아’ 모델입니다. 실제 인터넷은 훨씬 복잡해서 택배가 분실되거나(패킷 손실), 순서가 뒤바뀌는 등 온갖 문제가 생기죠. 앞으로 배우게 될 rdt 2.0, 3.0 등은 이런 현실적인 문제들을 해결하기 위해 점점 더 복잡한 ‘행동 설명서(FSM)‘를 갖게 될 겁니다.

비트 오류가 있는 채널상에서의 신뢰적 데이터 전송: rdt 2.0

하위 모델의 더 실질 모델은 패킷 안의 비트들이 하위 채널에서 손상되는 모델. 그런 비트 오류는 패킷이 전송 또는 전파되거나 버퍼링될 때 물리적 구성요소에서 일반적으로 발생한다. 단 이번에는 전송된 패킷이 모두 순서는 지켜진다고 가정한다.

이런 채널에서 신뢰적 통신을 위한 프로토콜을 설명하기 전에, 어떻게 사람들이 이런 상황을 다루는지 먼저 생각해보자. 우리가 전화 통화 할때를 생각해보자. 일반 시나리오에서 메시지 수신자는 각각 문장을 듣고 이해하고 기록 후 OK라 말할 수 있을것이다. 만일 메시지 수신자가 문장들 똑바로 듣지 못했다면 반복하라고 요청한다. 이러한 메시지 받아쓰기 프로코콜은 긍정 확인 응답(positive acknowledgement, OK)와 부정 확인 응답(negative acknowlegemnt, “그것을 반복해주세요”) 둘 다 사용한다. 컴퓨터 네트워크 설정에서 그러한 재전송을 기반으로 하는 신뢰적 데이터 전송 프토토콜은 자동 재전송 요구(Automatic Repeat reQuest, AQR) 프로토콜로 알려져 있다.

비트 오류를 처리하기 위해 기본적으로 다음과 같은 세가지 부가 프로토콜 기능이 AQR에 요구된다.

오류 검출: 첫째, 비트 오류 발생시 수신자가 검출할 수 있는 기능이 필요하다. 앞 절에서 설명한 UDP는 이런 목적을 위해 인터넷 체크섬 필드를 사용한다. 6장에서 오류 검출과 복구 기술을 설명하니 참고. 이런 기술은 수신자가 패킷 브트 오류를 검출하고 복구할 수 있게 해준다.현 시점에서는 단지 이런 기술이 송신자로 부터 수신자에 전송되는 추가적인(본문말고도 신뢰를 위해 쓰이는 추가 데이터들) 비트들이 요구된다는 것만 알면된다. 이런 비트들은 rdt 2.0 데이터 패킷의 패킷 체크섬 필드로 모일것이다.
수신자 피드백: 송신자, 수신자가 일반적으로 수천 킬로 떨어진 각기 다른 시스템에서 동작하므로, 송신자가 수신자의 상태를 알기 위한 유일한 방법은 수신자가 송신자에게 피드백을 제공하는 것이다. 메시지 명령 시나리오에서 긍정 확인응답(ACK)와 부정 확인응답(NAK)은 그런 피드백의 예. rdt 2.0 프로토콜은 수신자로부터 송신자 쪽으로 ACK, NAK 패킷들을 전송할 것이다. 원칙적으로 이러한 패킷은 단지 한 비트 길이면 된다. 예를 들면, 0은 NAK을 가리킬 수 있고 1은 ACK를 가리킬 수 있다.
재전송: 수신자에서 오류를 가지고 수신된 패킷은 송신자에 의해 재전송 된다. 밑의 그림 3.10은 오류 검출, 긍정 확인응답 그리고 부정 확인응답들을 채택하는 데이터 전송 프로토콜 rdt 2.0의 FSM을 보여준다.

rdt 2.0의 송신 측은 2개의 상태를 가진다. 가장 왼쪽 상태에서 송신 측 프로토콜은 상위 계층으로 부터 데이터가 전달되기를 기다린다. rdt_send(data) 이벤트가 발생하면, 송신자는 패킷 체크섬(예: DUP 경우를 살펴본 3.3.2 처럼)과 함께 전송될 데이터를 포함하는 패킷(sndpkt)을 생성하고, 그 패킷을 udt_send(sndpkt) 동작을 통해 전송할 것이다. 가장 우측 상태에서 송신자 프로토콜은 수신자로 부터의 ACK or NAK 패킷을 기다린다. 만약 ACK 패킷이 수신된다면(rdt_rcv(rcvpkt) && isACK(rcvpkt)는 이 이벤트에 대응), 송신자는 가장 최근에 전송된 패킷이 정확히 수신되었음을 알게 된다. 그래서 프로토콜은 상위 계층으로부터 데이터를 기다리는 상태로 돌아간다. 만약 NAK이 수신되면 프로토콜은 마지막 패킷을 재전송하고 데이터 패킷에 대한 응답으로 수신자에 의해 응답하는 ACK or NAK을 기다린다. 송신자가 ACK or NAK을 기다리는 상태에 있을 때, 상위 계층으로 부터 더 이상 데이터 전달 못 받는것 유의. 즉, rdt_send() 이벤트는 발생할 수 없다. 이는 오직 송신자가 ACK을 수신하고 이 상태를 떠난 후 발생할 것. 그러므로 송신자는 수신자가 현재의 패킷을 정확히 수신했음을 확인하기 전까지 새로운 데이터를 전달하지 않을것이다. 이런 행동때문에 rdt 2.0 같은 프로토콜은 전송 후 대기(stop and wait) 프로토콜로 알려져있다.

rdt 2.0에 대한 수신자 측 FSM은 아직 단일 상태 가진다. 패킷이 도착시, 수신자는 패캣의 손실 유무에 따라 ACR or NAK으로 응답한다. 그림 3.10에서 rdt_rcv(rcvpkt) && corrupt(rcvpkt)는 패캣이 수신되고 오류가 검출되는 이벤트에 대응됨.

rdt 2.0은 잘 작동하는거 같지만 실제로는 치명적인 결함이 있다. 특별히 여기서는 ACK or NAK 패킷이 손실될 가능성은 고려않았다. 불행히도 이런 사소한 실수는 간단치 않다. 최소한 그런 오류 검출을 위해 ACK,NAK 패킷에 대한 체크섬 비트를 추가할 필요가있다. 좀 더 어려운 문제는 어떻게 프로토콜이 ACK or NAK 패킷 오류로부터 복구가 되는가이다. 여기서 어려운 점은 만약 ACK or NAK가 손상된다면, 송신자는 수신자가 전송된 데이터의 마지막 부분을 올바르게 수신햇는가를 알 수 가없다.

손상된 ACK or NAK을 처리하기위한 세 가지 가능성을 고려해보자.

한 메시지가 가다가 손상됨. 받은 호스트는 이걸 못알아 먹으니 ‘뭐라고했어?‘라고 질문을 다시 함. 그런데 여기서 또 이 ‘뭐라고했어?‘가 손상되면 이거 받는 호스가 또 ‘뭐라고했어?‘라함. 무한 루프임
이번에는 송신자가 검출뿐만 아니라 비트 오류로부터 회복할 수 있도록 충분한 체크섬 비트를 추가하는 시나리오 생각해보자. 이 방식은 패킷이 손상될 순 있으나 손실되지는 않는 채널의 경우에 즉각적을 문제를 해결할 수 있다.
세번째 접근은 송신자가 왜곡된 ACK or NAK 패킷을 수신할 때 현재 데이터 패킷을 단순히 다시 송신하는 것. 그러나 이 방식은 서로간의 채널로 중복 패킷을 전송한다. 중복 패킷의 가장 근본적으로 어려운 점은 마지막으로 전송된 ACK or NAK가 송신자에게 정확하게 수신됐는지를 알 수 없다는 것. 그러므로 도착하는 패킷이 새로운 데이터를 포함하고 있는지 아니면 재전송인지 사전에 알 수 없다. 이런 새로운 문제의 간단한 해결책은 데이터 패킷에 새로운 필드를 추가하고 그 필드 안에 순서 번호(sequence number)을 삽입하는 방식으로 패킷에 송신자가 번호를 붙이는 것. 수신자는 수신된 패키이 재전송인지 결정할 때는 이 순서 번호를 확인하면된다. 일반적으로 패킷을 손실하지 않는 채널을 여기선 가정하고 있으므로, ACK, NAK 패킷 자체는 확인 중인 패킷의 순서 번호를 나타낼 필요는 없다.(?) 송신자는 수신된 ACK, NACK 패킷(왜곡인지 아닌지)이 가장 최근에 전송된 데이터 패킷에 대한 응답으로 발생한 것임을 안다.

위 그림 3.11, 3.12 는 rdt 2.0의 수정버전인 rdt 2.1에 대한 FSM을 나타낸다. rdt 2.1 송신자와 수신자 FSM은 전보다 두 배 많은 상태를 가지고있다. 이는 프로토콜 상태가 현재 송신자에 의해 전송되고 있거나, 수신자가 기다리고 있는 패킷이 순서 번호 0 또는 1을 가져야하는지를 반영해야하기 때문. 0번 패킷이 송신되고 있거나 기다리고 있는 상태에서의 동작은 1번 패킷이 송신되고 있거나 기다리는 상태의 미러 이미지다. 즉, 단시 순서 번호 차이만 있을 뿐.

rdt 2.1은 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함한다. 순서가 바뀐 패킷이 수신되면, 수신자는 이미 전에 수신한 패킷에 대한 확인응답을 전송한다. 손상된 패킷이 오면, 수신자는 부정 확인응답을 전송한다. NAK 송신 대신 가장 최근에 정확하게 수신된 패킷에 대해 ACK을 송신함으로써 NAK을 송신한 것과 같은 효과 얻을 수 있다.

비트 오류를 갖는 채널을 위한 NAK 없는 신뢰적인 데이터 전송 프로토콜은 그림 3.13과 그림 3.14에서 나타내는 rdt 2.2다. rdt 2.1 과 rdt 2.2의 미묘한 차이는 수신자가 반드시 ACK 메시지에 의해 확인 응답되는 패킷의 순서 번호를 포함해야 한다는 점이다.(이건 수신자 FSM의 make_pkt()에 ACK, 0 or ACK, 1인 인수 넣어 수행). 그리고 송신자는 수신된 ACK 메시지에 의해 확인응답된 패킷의 순서 번호를 반드시 검사해야만한다.(이것은 송신자 FSM의 isACK()에 0또는 1인 인수 넣어 수행한다)

비트 오류와 손실 있는 채널상에서의 신뢰적 데이터 전송: rdt 3.0

비트 손상 외에도 하위 채널이 패킷을 손실하는 경우를 생각해보자. 다음과 같은 두 가지 부가 내용을 프로토콜이 다루어야한다. 어떻게 패킷 손실을 검출할 것인가, 그리고 손실이 발생했을 때 어떤 행동을 할 것인가이다. 체크섬, 순서 번호, ACK 패킷, 재전송의 사용(이미 rdt2.2에서 개발된 기술임)은 후자의 관심사에 답할 수 있게해준다. 이제 첫 번째 관심사를 해결하려면 새로운 매커니즘을 프로토콜에 추가해야한다.

패킷 손실을 다룰 때는 다양한 접근이 가능하다. 여기선 송신자에게 손실된 패킷의 검출과 회복 책임을 부여할 것이다. 송신자가 데이터 패킷을 전송하고 패킷 또는 수신자가준 ACK를 손실했다 가정하자. 어느 경우에서나 송신자에게는 수신자로부터 어떠한 응답도 없다. 만약 송신자가 패킷을 잃어버렸다고 확신할 정도로 충분한 시간을 기다릴 수 있다면, 데이터 패시은 간단히 재전송될 수 있다.

그러나 송신자가 어떤 패킷을 손실했다는것을 확인하기 위해 얼마나 오래 기다려야되나? 송신자는 적어도 송수신자간의 왕복 시간 지연에 수신 측에서 패킷을 처리하는데 필요한 시간을 더한 만큼 기다린다. 많은 네트워크에서는 이 최악의 최대 지연 시간은 예측도 어렵다. 더욱이, 이상적으로는 프로토콜이 패킷 손실을 가능한 빨리 복구해야한다. 최악의 지연을 기다린다는것은 오류 복구가 시작될 때까지 오래 기다려야 한다는 뜻이 된다. 실제 상황에서 채택한 접근 방식은 송신자가 패킷 손실이 일어났다는 보장은 없지만 손실이 일어낫을 만한 그런 시간을 현명하게 선택하는 것이다. 만일 ACK 가 이 시간안에 오지 않는다면 패킷은 재전송된다. 이것은 중복 데이터 패킷을 만들 가능성을 포함한다. 다행히 프로토콜 rdt 2.2 에는 이미 패킷이 중복되었을 경우를 처리하기 위한 충분한 기능(수서 번호)이 있다.

송신자 관점에서 재전송은 만병통치약과 같다. 송신자는 패킷이 손실되었는지, ACK가 손실되었는지, 지나치게 지연되는 것인지 모른다. 이런 모든 경우에 행동은 재전송할 뿐이다. 시간 기반의 재전송 매커니즘을 구현하기 위해, 주어진 시간이 지난 후 송신자를 인터럽트할 수 있는 카운트다운 타이머가 필요하다. 그러므로 송신자는 다음처럼 동작해야한다.

매 패킷(첫 번째 또는 재전송 패킷)이 송신된 시간에 타이머를 시작함
타이머 인터럽트에 반응함(적당한 행동 취함)
타이머 멈춤 그림 3.15는 패킷이 손상 혹은 손실될 수 있는 채널에서 데이터를 신뢰적으로 전송하는 프로토콜인 rdt 3.0에 대한 송신자 FSM을 보여준다. 그림 3.16은 프로토콜이 패킷 손실 또는 지연 없이 어떻게 동작하는 지와 손실된 데이터 패킷을 어떻게 처리하는지를 보여준다. 그림 3.16에서 시간은 다이어그램의 위로부터 아래로 움직인다. 즉, 패킷에 대한 수신 시간은 전송 지연과 전파 지연때문에 패킷 전송 시간보다 더 늦다. 그림 3.16(b~d)에서 송신측 꺽쇠는 타이머가 설정된 후 타임아웃된 시간을 가리킨다.

이 프로토콜의 좀 더 세세한 부분은 이 장 후반후의 과제에서 다룸. 패킷의 순서 번호가 0, 1이 번갈아 일어나므로, 프로토콜 rdt 3.0은 때때로 얼터네이팅 비트 프로토콜 (alternating-bit protocol) 이라고도 부른다.

체크섬, 순서 번호, 타이머, 긍정 확인응답, 부정 확인응답 패킷 등은 프로토콜 동작에서 중요한 임무를 수행한다. 이제 신뢰적으로 동작하는 데이터 전송 프로토콜을 갖게 되었다.

3.4.2 파이프라이닝된 신뢰적인 데이터 전송 프로토콜

rdt 3.0은 기능적으로는 정확한 프로토콜. 그러나 오늘날 고속 네트워크에서 누구나 이것의 성능에 만족하는건 아니다. 3.0의 핵심적인 성능 문제는 rdt 3.0이 전송 후 대기(stop-and-wait) 프로토콜 이란 점이다.

이런 전송 후 대기 방식의 성능을 올바르게 인식하기 위해, 그림 3.17 처럼 하나의 호스트는 미국의 서부에 위치하고 다른건 동부에 있는 경우를 고려하자. 이런 두 시스템 사이의 광속 왕복 전파 지연(RTT)는 대략 30ms. 이 두 호스트가 1 Gbps 전송률(R)을 가진 채널로 연결되어 있다고 가정하자. 헤더 필드와 데이터 모두를 포함하여, 패킷당 1,000 바이트의 패킷 크기(L)를 가지고 1 Gbps 링크로 패킷을 실제로 전송하는데 필요한 시간은 다음과 같다.

책 195, 32 참고하기. 계산식이 다수라 노트화 하기 힘들다. 수식으로 파이프라이닝의 필요성 설명

송신자에게 확인 응답을 기다리지 않고 여러 패킷을 전송하도록 허용하는 것 ⇒ 파이프라이닝 기술

파이프라이닝 방식은 신뢰적인 데이터 전송 프로토콜에서 다음과 같은 중요성 가짐.

순서 번호의 범위가 커져야 한다. 왜냐하면 각각의 전송 중인 패킷(재전송을 고려 않음)은 유일한 순서 번호를 가져야 하고 전송 중인 확인응답(ACK)이 안 된 패킷이 여렷 있을지도 모르기 때문
프로토콜의 송신 측과 수신 측은 패킷 하니 이상을 버퍼링 해야한다. 최소한 송신자는 전송되었으나 확인응답되지 않은 패킷을 버러링 해야함.정확하게 수신된 패킷의 버퍼링은 다음에 설명한 것처럼 수신자에게서도 필요하다.
필요한 순서 번호의 범위와 버퍼링 조건은 데이터 전송 프로토콜이 손실 패킷과 손상 패킷 그리고 상당히 지연된 패킷에 대해 응답하는 방식에 달려 있따. 파이프라인 오류 회복의 두 가지 기본적 접근 방법으로 GBN(Go Back N, N 부터 반복)과 SR(Selective Repeat, 선택적 반복) 등이 있다.

이 파트 너무 길다; TCP 하기 전에 진빠질듯. 술술 읽고 넘어가자

1. 파이프라이닝 (Pipelining) 기법

무엇인가? 이전 요청의 응답을 기다리지 않고 여러 요청을 연속적으로 보내는 기법입니다. 네트워크 지연 시간을 효율적으로 활용하여 처리량을 높이는 데 목적이 있습니다.
- **개념적 이해
  - HTTP/1.1 파이프라이닝: 이론적으로는 가능했지만, 실제로는 Head-of-Line Blocking(HOLB) 문제 등으로 잘 사용되지 않았습니다.
  - HTTP/2 멀티플렉싱: HTTP/2는 여러 요청/응답 스트림을 하나의 TCP 연결 위에서 동시에 주고받을 수 있도록 하여 사실상 파이프라이닝의 개념을 훨씬 더 발전시켜 적용한 것입니다. 백엔드 개발자는 HTTP/2가 어떻게 성능을 개선하는지 이해하는 데 이 개념이 큰 도움이 됩니다.
  - 데이터베이스 배치 처리: 여러 SQL 쿼리를 한 번에 묶어서 보내거나, 메시지 큐에 여러 메시지를 한 번에 전송하는 것 등도 넓은 의미에서 파이프라이닝 개념이 적용된 성능 최적화 기법이라고 볼 수 있습니다.
- 결론: 직접 구현할 일은 없지만, 성능 최적화와 관련된 여러 기술(HTTP/2, DB 배치 등)의 배경 원리를 이해하는 데 핵심적인 개념.

2. GBN (Go-Back-N) 및 SR (Selective Repeat)

무엇인가? 이들은 ‘신뢰성 있는 데이터 전송’을 위한 프로토콜의 한 종류입니다. 즉, 네트워크가 불안정하여 패킷이 손실되거나 순서가 뒤바뀌는 상황에서도 데이터를 올바르게 주고받기 위한 방법들입니다.
- GBN: 손실된 패킷 이후의 모든 패킷을 다시 보내는 방식 (비효율적이지만 구현이 간단)
- SR: 손실된 패킷만 선택적으로 다시 보내는 방식 (효율적이지만 구현이 복잡)
중요성:
- 직접적인 구현은 없습니다. 여러분이 백엔드 애플리케이션을 개발할 때 GBN이나 SR 알고리즘을 직접 짤 일은 거의 없습니다. 이들은 주로 TCP와 같은 하위 계층 프로토콜 내부에 구현되어 있습니다.
- TCP 이해를 위한 기초: TCP는 GBN과 SR의 개념을 조합하여 신뢰성 있는 데이터 전송을 구현합니다. 특히 TCP의 ‘슬라이딩 윈도우’, ‘재전송 메커니즘’, ‘흐름 제어’, ‘혼잡 제어’ 등을 이해하는 데 GBN과 SR은 필수적인 배경 지식입니다. GBN/SR을 통해 왜 TCP가 특정 방식으로 동작하는지, 어떤 문제를 해결하는지 명확하게 이해할 수 있습니다.
- 네트워크 문제 진단: 만약 네트워크 문제(패킷 손실, 높은 지연 시간 등)로 인해 백엔드 서비스의 성능이 저하될 때, GBN/SR과 같은 신뢰성 프로토콜의 작동 원리를 이해하고 있다면 Wireshark 같은 툴을 사용하여 패킷 캡처를 분석하고 문제의 원인(예: 잦은 재전송)을 파악하는 데 큰 도움이 됩니다.
- 결론: TCP의 동작 원리를 깊이 있게 이해하고, 나아가 네트워크 문제를 진단하는 데 매우 중요한 개념적 토대를 제공합니다.

3.4.3 GBN

읽기만! 노트화는 보류

3.4.4 SR