목차
트랜스포트 계층
각기 다른 호스트에서 동작하는 애플리케이션 프로세스 간의 논리적 통신을 제공

트랜스포트 계층의 역할
트랜스포트 계층 세그먼트 -> 트랜스포트 계층 패킷
송신 - 트랜스포트 계층 패킷 + 계층 헤더 -> 세그먼트의 캡슐화 (네트워크 계층)
수신 - 네트워크 계층에서 데이터그램으로부터 트랜스포트 계층 세그먼트 추출 -> 트랜스포트 계층으로 세그먼트 이동
두개의 트랜스포트 프로토콜 존재
-> UDP, TCP
트랜스포트 계층과 네트워크 계층 사이의 관계
트랜스포트 계층은 프로토콜 스택에서 네트워크 계층 바로 상위 존재
트랜스포트 계층 프로토콜 - 각기 다른 호스트 내부 동작 프로세스들의 논리적 통신 제공
네트워크 계층 프로토콜 - 호스트들 사이의 논리적 통신을 제공
간단한 예
- 애플리케이션 메시지: 봉투 안의 편지
- 프로세스: 사촌 형제
- 호스트: 집
- 트랜스포트 계층 프로토콜: 앤과 빌
- 네트워크 계층 프로토콜: 우편 서비스
인터넷 트랜스포트 계층 서비스의 개요
UDP - 비신뢰적이고 비연결형인 서비스를 요청한 애플리케이션에게 제공
TCP - 네트워크 신뢰적이고 연결지향형 서비스를 요청한 애플리케이션에게 제공
->TCP, UDP 트랜스포트 계층 패킷을 데이터그램으로 통합
IP
인터넷의 네트워크 계층 프로토콜은 인터넷 프로토콜(IP)라는 이름을 가진다.
IP서비스 모델은 최선형 전달 서비스이다. 즉 세그먼트의 전달을 노력하지만 어떤 것도 보장하지 않는다.
보장하지 않는 것에는 순서, 무결성 등이 있다. 비신뢰적인 서비스라고 불린다.
UDP와 TCP의 기본적인 기능
1. 종단 시스템 사이의 전달 서비스를 두 프로세스간의 전달 서비스로 확장하는 것
트랜스포트 계층 다중화와 역다중화라고 부른다.
2. UDP와 TCP는 헤더에 오류 검출 필드를 포함함으로써 검사를 제공한다.
UDP는 IP와 같은 비신뢰적인 서비스로 전송된 데이터가 손상되지 않고 목적지 프로세스에 도착한다는 것을
보장하지 않는다.
TCP는 신뢰적인 데이터 전송을 제공하고 혼잡제어를 사용한다.
혼잡제어란 TCP 연결이 과도한 양의 트래픽으로 모든 통신하는 호스트들 사이의 스위치와 링크를
혼잡하게 하는 것을 방지하는 것을 말한다.
이런 것들을 제공하는 만큼 프로토콜은 복잡할 수 밖에 없다.
다중화와 역다중화
호스트의 트랜스포트 계층 -> 중간 매개자인 소켓
수신 측 호스트에 하나 이상의 소켓이 있을 수 있으므로 각각의 소켓은 식별자를 가짐
식별자는 UDP인지 TCP인지에 따라 다르다.
다중화의 뜻
하나의 회선 또는 전송로를 분할하여 다수의 개별적으로 독립된 신호를 동시에 송수신할 수 있는 다수의 통신로(채널)를 구성하는 기술.
역다중화: 트랜스포트 계층 세그먼트 데이터 -> 올바른 소켓
다중화: 세그먼트들을 헤더 정보로 캡슐화(데이터그램) -> 네트워크 계층
트랜스포트 계층 다중화의 요구사항
소켓: 유일한 식별자 (포트번호 할당 받음)
세그먼트: 세그먼트가 전달될 적절한 소켓을 가리키는 특별한 필드를 갖음
ex) 출발지 포트 번호 필드, 목적지 포트 번호 필드

출발지 IP주소와 포트번호가 다르더라도 목적지 IP주소와 목적지 포트 번호를 가지면
2개의 세그먼트는 같은 프로세스로 감
-> 출발지 포트 번호는 회신 주소의 역할을 하여 B세그먼트가 A세그먼트로 다시 보내기 원할때 이용
TCP(연결지향형 다중화와 역다중화)
- TCP의 소켓은 4개 요소의 집합을 가짐 (출발지 IP주소, 출발지 포트 번호, 목적지 IP주소, 목적지 포트 번호)
- 역다중화를 위해서 4개의 값 모두를 사용
- 특히 UDP와 다른 점은 도착지가 같아도 출발지가 다르면 다른 소켓으로 향한다.
- TCP서버 애플리케이션은 환영 소켓을 가짐
- 서버 호스트는 동시에 존재하는 많은 TCP 소켓의 지원이 가능하다.
핸드셰이크란?
두 호스트가 서로 연결할 때에 필요한 정보들을 주고받는 일련의 과정들
UDP(비연결형 트랜스포트)
UDP는 세그먼트의 데이터를 송신하기 전에 송신 트랜스포트 계층 개체들과 수신 트랜스포트 계층 사이에
핸드셰이크를 사용하지 않는다.
DNS는 전형적인 UDP를 사용하는 애플리케이션 계층 프로토콜의 예
많은 애플리케이션 개발자가 UDP를 선호하는 이유
1. 더 정교한 제어: TCP는 혼잡 제어 매커니즘으로 인해 송신자가 제한됨 따라사 재전송이 요구됨에 따라
최소 전송률을 지키지 못할 수도 있다.
2.연결 설정이 없음: 핸드 셰이킹으로 인한 지연이 없다. (크롬 브라우저는 QUIC프로토콜로 기본 트랜스포트
프로토콜로 UDP를 사용한다.)
3. 연결 상태가 없음: TCP는 종단 시스템에서 연결 상태를 유지한다. 이에 반해 UDP는 연결 상태를 유지하지 않아
좀 더 많은 액티브 클라이언트를 수용할 수 있다.
UDP 세그먼트 구조
데이터 필드 + 헤더필드 + 체크섬 + 길이
체크섬은 세그먼트에 오류가 발생했는지를 검사하기 위해 수신호스트가 사용
UDP 체크섬
오류 검출을 위한 것으로 세그먼트가 출발지에서 목적지로 이동했을 때 비트에 대한
변경사항이 있는지를 검사
링크 계층 프로토콜이 오류검사를 하는데도 제공하는 이유는 출발지와 목적지 사이의 모든 링크가
오류 검사를 제공한다는 보장이 없기 때문
종단과 종단의 원칙
어떤 기능이 종단 기반으로 구현되어야 하므로 하위 레벨에 있는 기능들은 상위 레벨에서 제공하는
비용과 비교했을 때 중복되거나 거의 가치가 없을 수 있다.
UDP는 오류 검사를 제공하지만 오류를 회복하기 위한 어떠한 일도 하지 않는다. 일부 UDP구현에서는
손상된 세그먼트를 그냥 넘겨버리거나 경고와 함께 손상된 세그먼트를 애플리케이션에게 넘겨주기도 한다.
신뢰적인 데이터 전송의 원리
신뢰적인 데이터 전송 문제: 트랜스포트 계층뿐만 아니라 링크 계층과 애플리케이션 계층에서도 발생 가능
TCP는 비신뢰적인 종단 간의 네트워크 계층(IP)의 바로 상위에 구현된 신뢰적인 데이터 전송 프로토콜

rdt1.0(완벽하게 신뢰적인 채널상에서의 신뢰적인 데이터 전송)
유한 상태 머신(FSM)으로 단일 상태를 가짐
모든 패킷의 흐름은 송신자로부터 수신자 까지(단방향 통신)
신뢰적인 채널에서는 오류가 생길 수 없기 때문에 수신 측이 어떤 피드백도 제공 x
rdt2.0(비트 오류가 있는 채널상에서의 신뢰적인 데이터 전송)
긍정 확인 응답 + 부정 확인 응답
신뢰적인 데이터 전송 프로토콜 = 자동 재전송 요구 프로토콜
ARQ프로토콜 요구사항(비트 오류 처리를 위함)
1. 오류 검출: 인터넷 체크섬 필드
송신자로부터 수신자에게 전송되는 추가적인 비트들
2.수신자 피드백: 긍정 확인응답(ACK) + 부정 확인응답(NAK)
재전송: 수신자에서 오류를 가지고 수신된 패킷은 송신자에 의해 재전송
송신측은 두개의 상태를 가진다.
ACK또는 NAK를 기다리는 상태에서는 상위 계층으로부터 데이터 전달을 받을 수 없다.
-> 전송 후 대기 프로토콜

수신 측 FSM은 단일 상태를 가짐
수신된 패킷이 손상되었는지 여부에 따라 ACK 또는 NAK로 응답

-> 치명적인 결함 존재
ACK 또는 NAK 패킷의 손상 가능성 여부
여기서 생기는 문제
1. 프로토콜이 ACK또는 NAK 패킷으로부터 복구 되는가
2. ACK 또는 NAK가 손상되면 전송된 부분 올바른 수신 여부 파악 가능성
rdt2.1
해결책
데이터 패킷에 새로운 필드를 추가하고 순서 번호를 삽입
-> 데이터 패킷에 송신자가 번호를 붙이는 것
이에따라 rdt2.1은 rdt2.0에 비해 두배 더 많은 상태를 가짐


rdt2.2
NAK를 송신하는 것 대신에 최근에 정확하게 수신된 패킷에 대해 ACK를 송신
rdt2.1 과 rdt2.2의 미묘한 차이는 수신자가 반드시 ACK 메세지에 의해 확인 응답되는 패킷의
순서번호를 포함해야 한다는 점이다.
그리고 송신자는 수신된 ACK 메세지에 의해 확인 응답된 패킷의 순서 번호를 반드시 검사해야만 한다.

rdt 3.0(비트 오류와 손실 있는 채널상에서의 신뢰적인 데이터 전송)
송신자는 데이터 패킷이 손실되었는지 ACK가 손실되었는지, 패킷 또는 ACK가 단순히 지나치게 지연된 것인지 알지 못함
카운트다운 타이머 -> 재전송 메커니즘 구현
1. 매 패킷 송신된 시간에 타이머를 시작함
2. 타이머 인터럽트에 반응함
3. 타이머를 멈춤

순서 번호가 0과 1이 번갈아 일어나므로 얼터네이팅 비트 프로토콜이라고도 부름
파이프라이닝된 신뢰적인 데이터 전송 프로토콜
rdt3.0은 전송 후 대기 프로토콜이 형편없는 송신자 이용률을 가짐
이용률: 송신자가 채널을 통해 실제로 분주하게 비트를 전송하는 데만 걸린 시간
-> 수식 계산은 책 참고
해결 방안
전송 후 대기 방식으로 동작하는 대신 송신자에게 확인 응답을 기다리지 않고 여러 패킷을 전송하도록 허용
-> 파이프라이닝 기술

데이터 전송 프로토콜에서 다음과 같은 중요성
1. 순서 번호가 커져야 한다. ACK(확인 응답 안된 패킷)이 여럿 있을 수 있기 때문
2. 프로토콜의 송신 측과 수신 측은 패킷 하나 이상을 버퍼링 해야 한다.
최소한 송신자는 전송되었으나 확인 응답 되지 않은 패킷을 버퍼링해야 한다.
3. 파이프 라인 오류 회복의 두가지 기본적인 접근 방법으로는 GBN과 SR 등이 있다.
GBN(GO-BACK-N 방식)
파이프라인에서 확인 응답이 안 된 패킷의 최대 허용 수 N보다 크지 말아야 함
N을 윈도 크기라고 부르면 GBN 프로토콜은 슬라이딩 윈도 프로토콜이라고 부른다.
N = 사용가능하지만 응답 안됨 + 전송 후 응답 안됨

GBN 송신자의 세가지 타입 이벤트 반응
상위로부터의 호출: 윈도가 가득 찼는지 N개의 확인 응답되지 않은 패킷이 있는지 확인
만약 윈도가 가득 차 있을 시 데이터를 상위 계층으로 반환 (상위 계층은 나중에 다시 시도)
윈도가 가득 차 있지 않으면 동기화 메커니즘 사용
ACK의 수신: GBN 프로토콜에서 순서 번호 n을 가진 패킷에 대한 확인 응답은 누적 확인응답으로 인식
타임아웃 이벤트: 타임 아웃이 발생한다면 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 모든 패킷
다시 송신, 확인응답 안 된 패킷이 없다면 타이머 중지
GBN 수신자
수신자는 순서가 잘못된 패킷들을 버림
수신자는 잘못된 패킷에 대한 버퍼링을 할 필요가 없음
-> 즉 수신자가 유지해야 하는 것은 다음 순서 패킷의 순서 번호
SR(Selective Repeat 선택적 반복)
채널 오류의 확률이 증가할수록 파이프라인은 불필요한 재전송 데이터로 채워짐
이에 GBN방식을 해결하기 위해 오류가 발생한 패킷을 수신했다고 의심되는 패킷만을 송신자가 다시 전송
슬라이딩 윈도우와 패킷 전송:
- 송신자는 여러 패킷을 한 번에 전송합니다. 이때, 특정 윈도우 크기 내의 패킷만 전송할 수 있습니다.
- 송신자는 각 패킷을 보내고 ACK가 올 때까지 패킷을 버퍼에 유지합니다.
개별 ACK 처리:
- 수신자는 윈도우 내의 패킷을 순서에 관계없이 수신할 수 있습니다.
- 예를 들어, 첫 번째 패킷이 손실되고, 두 번째와 세 번째 패킷이 정상적으로 도착한 경우, 수신자는 두 번째와 세 번째 패킷에 대한 ACK를 송신자에게 보냅니다.
- 송신자는 수신된 ACK에 따라 정상적으로 수신된 패킷을 버퍼에서 제거합니다.
재전송:
- 송신자는 ACK가 도착하지 않은 패킷만 재전송합니다.
- 예를 들어, 첫 번째 패킷이 손실된 경우 송신자는 첫 번째 패킷만 재전송하고, 이미 ACK를 받은 두 번째, 세 번째 패킷은 재전송하지 않습니다.
수신 측의 버퍼링:
- SR 방식에서는 수신자가 윈도우 내의 각 패킷을 개별적으로 저장할 수 있는 버퍼가 필요합니다.
- 예를 들어, 첫 번째 패킷이 손실되고 두 번째와 세 번째 패킷이 먼저 도착한 경우, 수신자는 이 패킷들을 일단 버퍼에 저장하고 첫 번째 패킷을 기다립니다.
- 손실된 첫 번째 패킷이 재전송되어 도착하면, 수신자는 버퍼에 저장된 순서에 맞게 패킷을 조합하여 상위 계층에 전달합니다.
SR 방식의 장단점
- 장점: 손실된 패킷만 선택적으로 재전송하므로, 네트워크 대역폭이 효율적으로 사용됩니다.
- 단점: 수신 측에서 각 패킷을 개별적으로 저장할 수 있는 버퍼가 필요하고, 윈도우 내의 패킷을 순서에 맞게 정렬하여 상위 계층으로 전달해야 하므로 구현이 복잡합니다.
연결지향형 트랜스포트 TCP
TCP 연결
두 프로세스가 먼저 핸드셰이크를 해야 하므로 연결지향형
TCP연결은 교환 네트워크에서와 같은 종단간의 TDM이나 FDM이 아님
중간 라우터들은 TCP연결을 전혀 감지x 즉 연결은 보지 못하고 데이터그램만 봄
전이중 서비스 제공 - TCP 연결이 있다면 A ->B B->A 둘다 흐를 수 있음
점대점 - 한 송신자가 여러 수신자에게 데이터 전송하는 멀티캐스팅 불가능
클라이언트 프로세스 - 연결 초기화 프로세스
서버 프로세스 - 다른 프로세스
세 방향 핸드셰이크 -> 두 호스트 사이에 3개의 세그먼트가 보내짐
준비된 버퍼중의 하나인 송신 버퍼로 데이터를 보냄
최대 세그먼트 크기(MSS) - 세그먼트에 모아 담을 수 있는 최대 데이터의 양
-> 주의 헤더를 포함하는 TCP 세그먼트의 최대 크기가 아니라 세그먼트에 있는 애플리케이션 계층 데이터에 대한 최대 크기
보통 MSS는 로컬 송신 호스트에 의해 전송될 수 있는 가장 큰 링크 계층 프레임의 길이인
MTU(최대 전송 단위)에 의해 결정된다.

TCP 세그먼트 구조

- 순서번호 필드,확인 응답 번호 필드 - 32비트로 신뢰적인 데이터 전송 서비스 구현에서 송신자와 수신자 사이에 사용
- 수신 윈도 - 16비트로 흐름 제어에 사용
- 헤더 길이 필드 - 4비트로 TCP헤더의 길이를 나타냄
- 옵션 필드 - 송신자와 수신자의 최대 세그먼트 크기, MSS를 협상
- 플래그 필드 - 6비트로 아래와 같다.
- ACK 비트 - 확인응답 필드에 있는 값의 유용함 판별
- RST, SYN, FIN 비트 - 연결 설정과 해제에 사용
- PSH 비트 - 수신자가 데이터를 상위 계층에 즉시 전달해야 함
- URG 비트 - 송신 측 상위 계층 개체가 긴급으로 표시하는 데이터임을 가르킨다.
순서번호와 확인응답 번호
1. 순서 번호(Sequence Number)
순서 번호는 송신 측이 전송하는 데이터의 위치를 나타내기 위해 사용됩니다.
- 목적: 데이터가 전송 순서대로 도착하지 않거나 일부 패킷이 손실될 수 있기 때문에, 수신 측에서 데이터의 정확한 순서를 보장하기 위함입니다.
- 작동 방식:
- 송신 측은 전송하는 데이터에 순서 번호를 부여합니다.
- 수신 측은 이 순서 번호를 보고 데이터의 순서를 맞추고, 누락된 패킷이 있다면 이를 감지할 수 있습니다.
- 예를 들어, 첫 번째 데이터 패킷의 순서 번호가 1, 두 번째가 2라면, 수신자는 2 이후에 3이 와야 함을 알 수 있습니다. 만약 3이 오지 않으면 그 데이터가 손실되었음을 감지하고 재전송을 요청할 수 있습니다.
2. 확인 응답 번호(Acknowledgment Number)
확인 응답 번호는 수신 측이 송신 측에 데이터를 정상적으로 받았음을 알리기 위해 사용하는 번호입니다.
- 목적: 데이터가 손실 없이 도착했는지 송신 측에 알리기 위해, 수신 측에서 마지막으로 정상적으로 수신한 순서 번호를 송신 측에 알려줍니다.
- 작동 방식:
- 수신 측은 데이터 패킷을 수신하면, 그 패킷에 대한 확인 응답 번호를 송신 측에 전송합니다.
- 이 확인 응답 번호는 수신 측이 다음으로 기대하는 순서 번호를 나타냅니다. 예를 들어, 수신 측이 순서 번호가 1인 패킷을 받았다면, 확인 응답 번호는 2가 되어, 송신 측이 다음 패킷으로 순서 번호가 2인 패킷을 전송해야 함을 알 수 있습니다.
- 만약 특정 패킷이 손실되었다면, 수신 측은 해당 패킷에 대한 확인 응답을 보내지 않으므로, 송신 측은 이 확인 응답 번호가 오지 않음을 통해 재전송할 필요성을 판단할 수 있습니다.
왕복 시간 예측과 타임아웃
왕복 시간 예측
대체로 RTT를 추정하기 위해 SampleRTT의 평균값을 채택
TCP는 SampleRTT값의 평균을 유지 이때 EstimatedRTT는 SampleRTT의 지수적 가중평균!
재전송 타임아웃 주기의 설정과 관리
주기는 EstimatedRTT보다 크거나 같아야 하지만 타임아웃 주기는 EstimatedRTT보다 너무 크면 안됨
신뢰적인 데이터 전송
네트워크 계층은 비신뢰적 - 인터넷 프로토콜은 데이터그램 전달을 보장하지 않고
데이터그램이 순서대로 전달되는 것도 보장 x 또한 데이터의 무결성 보장 x
이에 따라 TCP는 IP의 신뢰적인 데이터 전송 서비스를 제공하는데 타이머 관리는 상당한 오버헤드 요구
-> TCP 타이머 관리 절차에서는 오직 단일 재전송 타이머 사용
결론: TCP는 GBN과 SR 프로토콜의 혼합 방식
'CS > 컴퓨터네트워크' 카테고리의 다른 글
[Cs] 페이지네이션에 대해 자세히 알아보자 (0) | 2025.01.28 |
---|---|
[Cs] Basic 인증과 Bearer 인증에 대해 알아보자 (0) | 2025.01.20 |
[Cs] session과 jwt 토큰에 대해 알아보자 (3) | 2025.01.19 |
[컴퓨터 네트워킹 하향식 접근] 챕터2 (1) | 2024.10.13 |
[컴퓨터 네트워킹 하향식 접근] 챕터1 (3) | 2024.10.09 |