출처: https://better-together.tistory.com/134 [변계사 Sam의 테크 스타트업!:티스토리]
https://velog.io/@soo5717/Transport-Layer
전송게층의 역할
3계층이 패킷을 최적의 경로로 전송하지만 수신지 컴퓨터가 인터넷에 존재하는지, 준비가 되었는지, 패킷이 손상되거나 유실되지 앟았는지 같은거는 신경 안쓴다. - P 프로토콜은 통신하는 호스트 간에 패킷을 전달하기 위해 최선의 노력(Best-effort delivery service)을 하지만 패킷의 전송 순서나 완전성을 보장하지 않기 때문에 비신뢰형 서비스(unreliable service)라고도 합니다.
패킷이 전송 과정에서 아무 문제 없이 제대로 수신지 컴퓨터에 도착할 수 있도록 패킷 전송을 제어하는 역할은 전송 계층이 담당합니다.
전송 계층은 네트워크 혼잡 상황에 따라 패킷의 전송량을 조절하여 패킷의 흐름을 제어하고 패킷 전송의 오류를 점검해서 수신지 컴퓨터까지 패킷이 제대로 도착했는지 확인하는 역할을 합니다. 다시 말해 전송 계층은 수신지 컴퓨터까지 신뢰할 수 있는 데이터를 전송하기 위해 필요한 계층입니다.
애플리케이션이라는 최종 목적지까지 데이터 전송을 책임지는 것이 전송 계층의 또 다른 역할입니다. 즉, 전송 계층은 다양한 애플리케이션이 동작하는 컴퓨터 내에서 어떤 애플리케이션이 사용하는 데이터인지 식별하여 수신지 컴퓨터에 도착한 데이터를 수신지 컴퓨터 내의 애플리케이션에 배분하는 역할
Motivation
• 디지털 데이터가 측정 가능한 양으로 표현되고 전송 및 재구성되는 방식(계층 1)
• 전송 매체에 대한 액세스가 제어되고 해당 다음 홉이 지정되는 방법(계층 2)
• 호스트가 논리적 주소를 기반으로 종단 간 주소가 지정되는 방식 및 데이터가 패킷으로 전송되는 방식(계층 3)
Aufgaben der Transportschicht
전송 계층의 주요 작업은 다음과 같습니다.
• 서로 다른 애플리케이션 또는 애플리케이션 인스턴스의 데이터 스트림 다중화,
• 비연결 및 연결 지향 전송 메커니즘 제공 및
• 혼잡 및 흐름 제어 메커니즘.
- 멀티플렉싱:
• 다양한 애플리케이션(브라우저, 채팅, 이메일 등)의 데이터 스트림 분할
• 세그먼트는 독립적인 IP 패킷으로 수신자에게 라우팅됩니다.
• 수신자는 세그먼트를 개별 데이터 스트림에 할당하고 해당 애플리케이션에 전달해야 합니다.
TCP는 데이터를 주고 받을 양단 간에 먼저 연결을 설정하고 설정된 연결을 통해 양방향으로 데이터를 전송하지만, UDP는 연결을 설정하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계를 거치지 않고 단방향으로 정보를 전송한다.
신뢰성 - TCP는 메시지 수신을 확인하지만 UDP는 수신자가 메시지를 수신했는지 확인할 수 없다.
순서 정렬 - TCP에서는 메시지가 보내진 순서를 보장하기 위해 재조립하지만 UDP는 메시지 도착 순서를 예측할 수 없다.
부하 - TCP보다 속도가 일반적으로 빠르고 오버헤드가 적다.
-
Verbindungslos (Best Effort) 비연결
• 세그먼트는 전송 계층의 관점에서 서로 독립적입니다.
• 시퀀스 번호 없음, 재전송 없음, 올바른 순서 보장 없음 -
Verbindungsorientiert 연결형
• 오류 발생 시 재전송
• 개별 세그먼트의 정확한 순서 보장
- 혼잡 및 흐름 제어:
• 혼잡 통제 Congestion control - 임박한 네트워크 과부하에 대한 대응
• 흐름 제어 Flow control - 수신기에 의한 부하 제어
Mutiplexing
전송 계층에서
1. 인코딩된 데이터 스트림은 세그먼트로 분할되고
2. 각 세그먼트에 헤더 추가
이러한 헤더에는 최소한
• 소스 포트 및
• 대상 포트,
발신자 또는 수신자 IP 및 사용된 전송 프로토콜과 함께 발신자 또는 수신자의 애플리케이션을 고유하게 식별합니다.
⇒ 5-튜플 구성
예시.. 
보통 전송계층 포트 번호는 16비트.
운영 체제는 5-튜플(IP 주소, 포트 번호, 프로토콜)을 사용하여 응용 프로그램에 소켓을 제공합니다.
응용 프로그램은 차례로 파일 설명자(정수 값)를 사용하여 소켓의 주소를 지정합니다.
• 연결 지향 소켓은 수신자가 이미 고정되어 있으므로 연결이 설정된 후 매우 쉽게 사용할 수 있습니다(read() 및 write() 시스템 호출을 사용하여 읽기 및 쓰기 가능).
• 연결 없는 소켓에는 보낼 사람 또는 받을 사람에 대한 주소 정보가 필요합니다(sendto() 및 recvfrom()).
Verbindungslose Übertragung 비연결...
전송 프로토콜의 헤더는 최소한
• 소스 및 대상 포트도 포함
• 사용자 데이터의 길이 지정.
이걸로 응용 프로그램이 각 개별 패킷에 대해 전송할 수 있습니다:
• 수신자(IP 주소) 및
• 수신 애플리케이션(프로토콜 및 대상 포트)을 지정합니다.
문제: 세그먼트는 서로 독립적으로 전송되고 전송 계층의 관점에서 상태 비저장이므로 다음이 보장되지 않습니다.
• 세그먼트가 수신자에 도달하고(패킷이 손실될 수 있음)
• 수신자가 올바른 순서로 세그먼트를 수신합니다(패킷은 독립적으로 라우팅됨).
User Datagram Protocol (UDP)
비연결 지향 통신으로 신뢰성이 없으며 순서 없이 데이터를 전송한다.
신뢰성이나 정확성 보다는 효율을 중시한다.
빠른 처리가 필요한 실시간 스트리밍 서비스 등에서 활용된다.
UDP(User Datagram Protocol)는 인터넷에서 가장 일반적으로 사용되는 두 가지 전송 프로토콜 중 하나입니다.
• 보안되지 않은 메시지 지향 전송
• 낮은 오버헤드.
UDP의 장점:
• 낮은 Overhead
• 연결 설정 또는 세그먼트 재전송 및 재정렬로 인한 지연 없음
• 간헐적인 패킷 손실이 허용되는 한 실시간 애플리케이션(Voice over IP, 온라인 게임)에 적합
• 데이터 속도는 흐름 및 혼잡 제어 메커니즘의 영향을 받지 않습니다(장점이 있을 수 있음, 연습 참조).
UDP의 단점:
• 어떤 형태의 서비스 품질도 보장하지 않음(임의로 높은 오류율)
• 데이터그램은 순서 없이 배달될 수 있습니다(예: 대상에 대해 여러 경로를 사용하는 경우).
• Flusskontrolle 흐름 제어 없음(빠른 발신자가 느린 수신자를 압도할 수 있음)
• Staukontrollmechanismen 혼잡 제어 메커니즘 없음(네트워크의 과부하는 높은 손실률로 이어짐)
UDP는 일반적으로 오류의 검사와 수정이 필요 없는 애플리케이션에서 수행할 것으로 가정
Verbindungsorientierte Übertragung 연결전송...
기본 아이디어:
프로토콜 헤더의 시퀀스 번호를 사용하여 선형으로 세그먼트 번호 지정
시퀀스 번호는..
• 성공적으로 전송된 세그먼트 확인,
• 누락된 세그먼트 식별,
• 누락된 세그먼트를 다시 요청하고
• 세그먼트를 올바른 순서로 조립합니다.
문제: 발신자와 수신자는 반드시
• 먼저 동기화(초기 시퀀스 번호 교환) 및
• 보류 상태(현재 시퀀스 번호, 이미 확인된 세그먼트, ... ).
연결 단계:
1. 연결 설정(Handshake)
2. 데이터 전송
3. 단절(해체) Teardown
가정:
• 전체 세그먼트가 항상 확인되고
• 다음 예상 세그먼트가 승인에 지정되었는지 여부
Sliding-window verfahren
TCP의 흐름제어 방식은 Window Slidin
수신자가 한번에 받을 수 있는 메시지의 개수를 제한 - 제한된 이 메시지 개수를 Window의 크기.
TCP는 이 Window 개수를 이용해서 수신자에게 앞으로 보낼 수 있는 메시지의 양을 계산한다. Window 크기가 0이 되면 송신자는 전송을 멈추고 대기
아이디어: 발신자가 확인을 기다릴 필요 없이 마지막으로 확인된 세그먼트 이후에 한 번에 몇 개의 세그먼트를 전송할 수 있는지 발신자에게 알려줍니다.
장점:
• 세그먼트 전송과 확인 수신 사이의 시간을 보다 효율적으로 사용할 수 있습니다.
• 이러한 창 크기를 협상함으로써 수신기는 데이터 속도 → 흐름 제어를 제어할 수 있습니다.
• 데이터 속도는 창 크기의 알고리즘 조정 → 혼잡 제어를 통해 송신기와 수신기 사이의 전송 경로에서 사용 가능한 데이터 속도에 적응할 수 있습니다.
Transmission Control Proocol TCP
Fluss und Staukontolle bie TCP
흐름제어 : 송신자Sender가 메시지를 보내는 속도가 수신자Receiever가 메시지를 처리하는 속도보다 빠를 때, 수신자의 메시지 함은 점점 차게 되고 결국 FULL 상태가 된다. 메시지 함이 꽉찬 상태에서 메시지를 더 받게되면 더 이상 저장할 공간이 없기 때문에 메시지를 버려야 하는 상황이 온다. 이를 '오버플로우Overflow'라 한다. 이러한 오버플로우 현상을 방지하기 위해 송신자와 수신자 사이에 속도를 맞춰주는 것을 흐름제어
