컴퓨터 네트워크 - 전송층 프로토콜

24-1   INTRODUCTION

 

이전 장에서 전송 계층의 기본 원리를 논의한 후 이 장에서는 인터넷의 전송 프로토콜에 중점을 둡니다.

그림 24.1은 TCP / IP 프로토콜 제품군에서이 세 가지 프로토콜의 위치를 ​​보여줍니다.

 

그림 24.1

TCP / IP 프로토콜 제품군에서 전송 계층 프로토콜의 위치

서비스

각 프로토콜은 다른 유형의 서비스를 제공하며 적절하게 사용해야합니다.

 

UDP:

오류제어가 응용층 프로세서에 의해 제공되는 응용에서 단순성과 효율성으로 사용되는 신뢰성 없는 비연결 프로토콜

 

TCP:

신뢰성이 중요한 응용에 사용될 수 있는 연결형 프로토콜

 

SCTP:

UDP와 TCP의 특성을 결합한 프로토콜

 

포트넘버

이전 장에서 설명했듯이 전송 계층 프로토콜에는 일반적으로 몇 가지 책임이 있습니다.

하나는 프로세스 간 통신을 만드는 것입니다.

이러한 프로토콜은 포트 번호를 사용하여이를 수행합니다.

포트 번호는 전송 계층에서 엔드-투-엔드 주소를 제공하고 IP 주소가 네트워크 계층에서와 같이

이 계층에서 다중화 및 역 다중화을 허용합니다.

표 24.1은이 장에서 논의한 세 가지 프로토콜 모두에 대한 공통 포트 번호를 제공합니다.

 

표 24.1

 

 

UDP

UDP (User Datagram Protocol)는 연결이없고 신뢰할 수없는 전송 프로토콜입니다.

UDP가 그렇게 강력하지 않다면 왜 프로세스가 그것을 사용하고 싶어할까요?

단점은 몇 가지 장점이 있습니다.

UDP는 최소한의 오버 헤드를 사용하는 매우 간단한 프로토콜입니다.

 

User Datagram

사용자 데이터 그램이라고하는 UDP 패킷에는 각각 2 바이트 (16 비트)의 4 개 필드로 구성된 8 바이트의 고정 크기 헤더가 있습니다.

그림 24.2는 사용자 데이터 그램의 형식을 보여줍니다.

처음 두 필드는 소스 및 대상 포트 번호를 정의합니다.

세 번째 필드는 사용자 데이터 그램의 총 길이, 헤더 + 데이터를 정의합니다.

16 비트는 총 길이를 0-65,535 바이트로 정의 할 수 있습니다.

그러나 UDP 사용자 데이터 그램은 총 길이가 65,535 바이트 인 IP 데이터 그램에 저장되므로 총 길이는 짧아야합니다. 마지막 필드는 선택적 체크섬을 전달할 수 있습니다 (나중에 설명).

 

 

 

다음은 16 진수 형식의 UDP 헤더 내용입니다.

CB84000D001C001C

 

a. 소스 포트 번호는 무엇입니까?

(CB84)16  or 52100

 

b. 대상 포트 번호는 무엇입니까?

(000D)16  or 13

 

c. 사용자 데이터 그램의 총 길이는 얼마입니까?

(001C)16 = 28 bytes

 

d. 데이터 길이는 얼마입니까?

28 − 8 = 20 bytes

 

e. 패킷이 클라이언트에서 서버로 전달됩니까?

13 (well-known port)  client to a server

 

f. 클라이언트 프로세스는 무엇입니까?

the Daytime

 

UDP Services

앞에서 우리는 전송 계층 프로토콜이 제공하는 일반 서비스에 대해 논의했습니다.

이 섹션에서는 일반적인 서비스 중 UDP가 제공하는 부분을 설명합니다.

 

그림 24.3 : 체크섬 계산을위한 의사 헤더

문제 24.2

다음과 같은 가상 상황 중 하나에서 체크섬에 어떤 값이 전송됩니까?

a. 발신자가 체크섬을 포함하지 않기로 결정합니다.

b. 발신자가 체크섬을 포함하기로 결정했지만 합계 값은 모두 1입니다.

c. 발신자가 체크섬을 포함하기로 결정했지만 합계 값은 모두 0입니다.

 

해답:

 

a. 체크섬 필드에 대해 전송 된 값은 모두 0으로, 체크섬이 계산되지 않았 음을 나타냅니다.

b. 발신자가 합계를 보완하면 결과는 모두 0입니다. 발신자는 전송하기 전에 결과를 다시 보완합니다. 체크섬에 전송 된 값은 모두 1입니다. 두 번째 보완 작업은 사례 a와의 혼동을 피하기 위해 필요합니다.

c. 이 상황은 합의 계산에 포함 된 모든 항의 값이 모두 0임을 암시하기 때문에 발생하지 않습니다. 의사 헤더의 일부 필드에는 0이 아닌 값이 있습니다.

 

UDP Applications

UDP가 신뢰할 수있는 전송 계층 프로토콜에 대해 앞에서 언급 한

기준을 거의 충족시키지 않지만 일부 응용 프로그램에는 UDP가 선호됩니다.

그 이유는 일부 서비스가 수용 할 수 없거나 바람직하지 않은 부작용을 가질 수 있기 때문입니다.

응용 프로그램 디자이너는 때때로 최적을 얻기 위해 타협해야합니다.

예를 들어, 일상 생활에서 운송 업체가 패키지를 1 일 배달하는 데 3 일 배달보다

비용이 많이 든다는 것을 모두 알고 있습니다.

고속 및 저비용은 모두 소포 배송에 바람직한 특징이지만 서로 상충됩니다.

 

UDP Applications - Example 24.3

DNS (26 장 참조)와 같은 클라이언트-서버 응용 프로그램은 클라이언트가

서버에 짧은 요청을 보내고 빠른 응답을 받아야하기 때문에 UDP 서비스를 사용합니다.

요청 및 응답은 각각 하나의 사용자 데이터 그램에 맞을 수 있습니다.

각 방향으로 하나의 메시지 만 교환되므로 연결없는 기능은 문제가되지 않습니다.

클라이언트 나 서버는 메시지가 순서대로 전달되지 않을까 걱정하지 않습니다.

 

UDP Applications - Example 24.4

전자 메일에 사용되는 SMTP와 같은 클라이언트 서버 응용 프로그램 (26 장 참조)은 사용자가

멀티미디어 (이미지, 오디오 또는 비디오를 포함 할 수있는) 긴 전자 메일 메시지를 보낼 수 있기 때문에 UDP 서비스를 사용할 수 없습니다. ).

응용 프로그램이 UDP를 사용하고 메시지가 단일 사용자 데이터 그램에 맞지 않으면

응용 프로그램에서 메시지를 다른 사용자 데이터 그램으로 분할해야합니다.

여기서 비 연결 서비스는 문제를 일으킬 수 있습니다. 사용자 데이터 그램이 도착하여

수신기 애플리케이션으로 순서없이 전달 될 수있다.

수신자 애플리케이션이 조각을 다시 정렬하지 못할 수 있습니다.

이는 비 연결 서비스가 긴 메시지를 보내는 응용 프로그램에 불리하다는 것을 의미합니다.

 

UDP Applications - Example 25.5

인터넷에서 매우 큰 텍스트 파일을 다운로드한다고 가정합니다.

안정적인 서비스를 제공하는 전송 계층을 사용해야합니다.

파일을 열 때 파일의 일부가 누락되거나 손상되는 것을 원하지 않습니다.

부품 배송 사이에 발생하는 지연은 우리에게 가장 큰 관심사가 아닙니다.

전체 파일이 구성 될 때까지 기다렸다가 파일을 봅니다.

이 경우 UDP는 적합한 전송 계층이 아닙니다.

 

UDP Applications - Example 25.5

Skype와 같은 실시간 대화 형 응용 프로그램을 사용한다고 가정합니다.

오디오와 비디오는 프레임으로 나뉘어 하나씩 전송됩니다.

전송 계층이 손상되거나 손실 된 프레임을 재전송해야하는 경우 전체 전송의 동기화가 손실 될 수 있습니다. 시청자가 갑자기 빈 화면을보고 두 번째 전송이 도착할 때까지 기다려야합니다.

이것은 참을 수 없습니다.

그러나 화면의 각 작은 부분이 하나의 단일 사용자 데이터 그램을 사용하여 전송되면

수신 UDP는 손상되거나 손실 된 패킷을 쉽게 무시하고 나머지는 응용 프로그램으로 전달할 수 있습니다. 화면의 해당 부분은 매우 짧은 시간 동안 비어 있으며 대부분의 시청자에게는 눈치 채지 못합니다.

 

TCP 

TCP (Transmission Control Protocol)는 연결 지향적이고 안정적인 프로토콜입니다.

TCP는 연결 설정 서비스, 데이터 전송 및 연결 해제 단계를 명시 적으로 정의하여 연결 지향 서비스를 제공합니다. TCP는 GBN과 SR 프로토콜의 조합을 사용하여 안정성을 제공합니다.

 

Stream delivery 스트림 배달

 

Sending and receiving buffers 버퍼 송수신

 

TCP segments TCP 세그먼트

 

문제 24.7:

TCP 연결이 5,000 바이트의 파일을 전송한다고 가정하십시오.

첫 번째 바이트는 10,001입니다.

데이터가 5 개의 세그먼트 (각각 1,000 바이트를 전송)로 전송되는 경우 각 세그먼트의 시퀀스 번호는 무엇입니까?

 

해답:

 

Segment

TCP의 패킷을 세그먼트라고합니다.

 

TCP segment format

 

 

Control field

URG: 긴급한 포인터가 유효합니다.

ACK: 승인이 유효합니다.

PSH: 푸시 요청

RST: 연결을 재설정하십시오.

SYN: 시퀀스 번호를 동기화하십시오.

FIN: 연결을 종료하십시오.

 

Pseudoheader added to the TCP datagram

 

A TCP Connection

TCP는 연결 지향적입니다.

그런 다음 메시지에 속하는 모든 세그먼트가 이 논리 경로를 통해 전송됩니다.

전체 메시지에 대해 단일 논리 경로를 사용하면 승인 프로세스와 손상되거나 손실 된 프레임의 재전송이 용이 해집니다. 연결없는 프로토콜 인 IP 서비스를 사용하는 TCP가 연결 지향적 인 방법을 궁금해 할 것입니다.

요점은 TCP 연결이 물리적이 아니라 논리적이라는 것입니다.

TCP는 더 높은 수준에서 작동합니다.

TCP는 IP 서비스를 사용하여 개별 세그먼트를 수신자에게 전달하지만 연결 자체를 제어합니다.

 

Connection establishment using three-way handshaking

Data transfer

Connection termination using three-way handshaking

 

Half-close

 

State Transition Diagram

연결 설정, 연결 종료 및 데이터 전송 중에 발생하는 모든 다른 이벤트를 추적하기 위해 TCP는 그림 24.14와 같이 FSM (Finite State Machine)으로 지정됩니다.

 

States for TCP

State	Description
CLOSED	No connection exists 연결이 없습니다.
LISTEN	Passive open received; waiting for SYN 패시브 오픈 수신; SYN을 기다리는 중
SYN-SENT	SYN sent; waiting for ACK SYN 보냄; ACK를 기다리는 중
SYN-RCVD	SYN+ACK sent; waiting for ACK SYN + ACK가 전송되었습니다. ACK를 기다리는 중
ESTABLISHED	Connection established; data transfer in progress 연결이 설정되었습니다. 데이터 전송 진행 중
FIN-WAIT-1	First FIN sent; waiting for ACK FIN-WAIT-1 첫 번째 FIN이 전송되었습니다. ACK를 기다리는 중
FIN-WAIT-2	ACK to first FIN received; waiting for second FIN 첫 번째 FIN에 대한 ACK 수신; 두 번째 FIN 대기 중
CLOSED-WAIT	First FIN received, ACK sent; waiting for application to close 첫 번째 FIN 수신, ACK 전송; 응용 프로그램이 종료되기를 기다리는 중
TIME-WAIT	Second FIN received, ACK sent; waiting for 2MSL time-out 두 번째 FIN 수신, ACK 전송; 2MSL 시간 초과 대기
LAST-ACK	Second FIN sent; waiting for ACK 두 번째 FIN이 전송되었습니다. ACK를 기다리는 중
CLOSING	Both sides decided to close simultaneously 양측은 동시에 폐쇄하기로 결정

 

TIME_WAIT(2MSL wait status)

 

-TIME_WAIT는 TCP의 4-Way Handshaking 과정을 통한 소켓 종료 과정 중의 상태이다.

 

-TIME_WAIT 상태가 되는 조건은 자신이 종료를 위해 FIN패킷을 보내고 그에 대한 응답으로 ACK 패킷을 받는다. 그런 다음 상대방의 FIN 패킷을 받고 그에 대한 응답으로 ACK 패킷을 보내고 TIME_WAIT가 된다.

 

-TIME_WAIT 상태는 2MSL 대기 상태(2MSL wait status)라고도 하는데, 여기서 MSL(Maximum Segment Lifttime)이란 패킷이 폐기되기 전에 네트워크에서 살아있을 수 있는 시간을 말한다.

 

 모든 IP 패킷은 TTL(time-to-live)라는 값을 가지는데 이 값이 0이 되면 해당 패킷은 폐기된다. 모든 라우터는 패킷을 통과시키면서 이 TTL값을 1만큼 감소시킨다.

 

 소켓이 TIME_WAIT 상태가 되면 MSL의 두배만큼의 시간 동안 TIME_WAIT상태를 유지한다. 이로 인해 ACK 패킷이 TTL에 의해 소실되어도 FIN 패킷을 재전송하여 ACK패킷이 재선송될 수 있다. TIME_WAIT상태가 끝나면 소켓은 CLOSED 상태가 된다.

 

Transition diagram with half-close connection termination

Time-line diagram for a common scenario