[컴퓨터 네트워킹]3장 트랜스포트 계층 - 2

3장 트랜스포트 계층

3.5 연결지향형 트랜스포트: TCP

3.5.1 TCP 연결

TCP 특징

연결지향형(connection-oriented)

전이중(full-duples) 서비스

점대점(point-to-point) : 1대1 통신

부정 확인 응답 (NAK) 사용 x

타임 아웃 시 확인 응답이 안 된 가장 작은 순서 번호를 가진 세그먼트를 재전송

TCP 단일 타이머 사용

 

세 방향 핸드셰이크(three-way handshake) : TCP 연결 설정 절차

1. 클라이언트가 먼저 특별한 TCP 세그먼트를 보낸다.

2. 서버는 두 번째 특별한 TCP 세그먼트로 응답한다.

+처음 2개의 세그먼트에는 "페이로드"(애플리케이션 계층 데이터)가 없다.

3. 세 번째 세그먼트는 페이로드를 포함할 수 있다.

 

추가자료

[네트워크] 3-way / 4-way Handshake 란?

 

TCP 데이터 송신

최대 세그먼트 크기(maximum segment size, MSS) : 세그먼트에서의 애플리케이션 계층 데이터에 대한 최대 크기

최대 전송 단위(maximum transmission unit, MTU) : 로컬 송신 호스트에 의해 전송될 수 있는 가장 큰 링크 계층 프레임의 길이

TCP 송신과 수신버퍼

 

3.5.2 TCP 세그먼트 구조

source port & destination port :  UDP처럼 다중화와 역다중화를 하는데 사용하는 헤더 필드

 

sequence number & acknowledgment number : 신뢰적인 데이터 전송서비스 구현에 사용되는 필드

 

data offset(header length) : 32비트 워드 단위로 TCP 헤더의 길이를 나타낸다.

 

window size(receive window) : 흐름제어에 사용되며 수신자가 받아들이려는 바이트의 크기를 나타내는데 사용된다.

 

urgent pointer (urgent data pointer) :  긴급 데이터의 마지막 바이트 위치를 가르키는 필드

 

flag field : 6개의 control flag 가 존재, 논리적인 TCP 연결회선 제어 및 데이터 관리를 위해 사용됨

- URG(urgent) : urgent pointer 필드 값이 채워져있음을 알리며 순서에 상관업이 먼저 송신된다.

 

- ACK(acknowledgement) : 확인응답 필드에 확인 응답 번호 값이 셋팅됨을 알림

* 1로 셋팅되면, 확인번호 유효

* 0로 셋팅되면, 확인번호 미포함

 

- PSH(push) : 버퍼링된 데이터를 가능한 빨리 상위 계층 응용프로그램에 즉시 전달할 것

* 수신 측은 버퍼가 찰 때까지 기다리지 않고 수신 즉시 버퍼링된 데이터를 응용프로그램에 전달

 

- RST(reset) [강제 연결 초기화 용도] : 연결확립(estableshed)된 회선에 강제 리셋 요청

* 반 개방 또는 연결 문제 등의 상황 처리를 위한 특별한 초기화용 제어비트

 

- SYN(synchronize) [연결 시작, 회선개설 용도] : TCP 연결 설정 초기화를 위한 순서번호의 동기화

* 연결 요청 : SYN=1, ACK=0 (SYN 세그먼트)

* 연결 허락 : SYN=1, ACK=1 (SYN+ACK 세그먼트)

* 연결 설정 : ACK=1 (ACK 세그먼트)

=> 즉, 송수신 간에 순서번호의 동기화

 

- FIN(finish) [연결해제, 회선종결 용도] : 송신기가 데이터 보내기를 끝마침

* 종결 요청 : FIN = 1 (FIN 세그먼트)

* 종결 응답 : FIN = 1, ACK = 1 (FIN+ACK 세그먼트)

 

+ CWR & ECE 비트 : 명시적 혼합 표시에 사용

 

3.5.3 왕복시간(RTT) 예측과 타임아웃

왕복시간 예측

sampltRTT : RTT 셈플은 세그먼트가 송신된 시간(즉 IP에게 넘겨진 시간)으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간까지의 시간 길이

 

estimatedRTT : sampleRTT 값의 평균

* estimatedRTT = (1-a)*estimatedRTT + a*sampleRTT

 

devRTT : RTT 변화율을 의미, sampleRTT가 estimatedRTT로부터 얼마나 많이 벗어나는지에 대한 예측으로 정의

* devRTT = (1-b)*devRTT+b* l sampleRTT - estimatedRTT l

 

재전송 타임아웃 주기의 설정 및 관리

estimatedRTT 보다 낮은 주기 -> 불필요한 재전송 증가

과도하게 큰 주기 설정 -> 즉각적인 재전송 불가

 

TCP 방식

timeoutInterval = estimatedRTT + 4*DevRTT (초기값은 1초로 권고)

 

3.5.4 신뢰적인 데이터 전달

신뢰적인 데이터 전달 서비스란?

프로세스가 자신의 수신버퍼로부터 읽은 데이터 스트림이 손상되지 않았으며 손실이나 중복이 없다는 것과 순서가 유지된다는 것을 보장하는 서비스

 

간소화된 TCP 송신자 FSM

타임 아웃 주기의 두배로 설정

타이머 만료는 주로 네트워크에서의 혼잡에 의해 발생한다. 즉 출발지와 목적지 사이의 경로에서 하나 이상의 라우터 큐에 도착한 많은 패킷은 패킷의 손실이나 오랜 큐 대기의 원인이 된다. 혼잡할 때 출발지에서 지속적으로 패킷의 재전송을 고집하면 혼잡은 악화될 것이다. 

--> 해결 방법으로 타임 아웃시에 주기 간격을 2배로 설정하는 것(혼잡 제어)

 

빠른 재전송

중복 ACK : 송신자가 이미 이저에 받은 확인 응답에 대한 재확인 응답 세그먼트 ACK

빠른 재전송 : 세그먼트 타이머가 초과되기 전에 손실된 세그먼트 재전송

수신자

수신자가 원하는 순서번호가 아닌 더 큰 순서 번호를 받는 경우, 누락된 세그먼트의 간격을 발견할 수 있다.

간격의 원인은 세그먼트가 분실되었거나 수신의 순서가 바뀐 경우이다.

이 때 수신자는 중복 ACK를 생성하여 전송한다.(마지막으로 수신된 순서적인 바이트를 갖는 데이터를 간단하게 다시 수신 확인 응답)

 

송신자

3개의 중복 ACK를 수신하는 경우에는 TCP 세그먼트 타이머가 만료되기 이전에 손실 세그먼트를 재전송

-> 이를 빠른 재전송(fast retransmit)라고 한다.

 

3.5.5 흐름제어

흐름제어 서비스 (flow-control service) : 송신자가 수신자의 버퍼를 오버플로 시키는 것을 방지하기 위해서 수신하는 애플리케이션이 읽는 속도와 송신자가 전송하는 속도르르 같게 하는 서비스

 

수신윈도우(RevWindow)과 수신 버퍼(RcvBuffer)

 

수신 윈도우(receive window, rwnd) 변수 : 수신 측에서 가용한 버퍼 공간이 얼마나 되는지를 송신자에게 알려 주는 데 사용, (전이중 서비스를 제공하므로 수신자, 송신자 모두 해당 변수 사용)

 

문제점  : 수신 버퍼가 가득 찼을 때, 버퍼를 비우더라도 송신자가 해당 정보를 알 수 없어 사실상 연결이 끊킨 상태가 됨

 

해결 방법 : TCP 명세서는 송신자가 수신자의 수신 윈도우가 0일  때, 1바이트 데이터로 세그먼트를 계속해서 전송하도록 요구 -> 수신 버퍼의 정보를 갱신하도록 요구

 

3.5.6 TCP 연결 관리

세 방향 핸드셰이크(three-way handshake) : TCP 연결 설정 절차

1. 클라이언트가 먼저 특별한 TCP 세그먼트를 보낸다.

* 연결 요청 : SYN=1, ACK=0, seq : client_isn (클라이언트의 최초의 순서번호) (SYN 세그먼트) 

 

2. 서버는 두 번째 특별한 TCP 세그먼트로 응답한다.

* 연결 허락 : SYN=1, ACK=client_isn+1, seq : server_isn (서버의 최초의 순서번호) (SYNACK 세그먼트) 

 

+처음 2개의 세그먼트에는 "페이로드"(애플리케이션 계층 데이터)가 없다.

 

3. 세 번째 세그먼트는 페이로드를 포함할 수 있다.

* 연결 설정 : ACK=server_isn+1, seq : client_isn+1 (ACK 세그먼트)

 

TCP 연결 종료

TCP 연결 종료

출발지 호스트가 SYN 세그먼트를 송신한 이후

CASE 1 : SYNACK 세그먼트 수신 -> 통신 가능을 알리는 ACK 세그먼트 송신

CASE 2 : RST 세그먼트 수신 -> 목표 호스트에 도달하였으나 해당 포트를 가진 애플리케이션이 존재하지 않는다. 따라서 초기화 실행

CASE 3 : 아무런 세그먼트를 받지 못함 -> 목표 호스트에 세그먼트가 도착하지 않음

 

3.6 혼잡제어의 원리

네트워크 혼잡 원인 == 높은 전송률로 데이터를 전송하려는 너무나 많은 출발지

-> 네트워크 혼잡을 일으키는 송신자를 억제하는 메커니즘 필요

 

3.6.1 혼잡의 원인과 비용

시나리오 1 : 2개의 송신자와 무한 버퍼를 갖는 하나의 라우터

+송신자 평균 전송률 : λin (byte/sec) (애플리케이션 계층(메시지) 기준의 전송률)

+수신자 평균 수신률 : λout (byte/sec)

+링크 처리량 : R

+재전송 x

+최대 처리량  : R/2 (두개의 송신자와 수신자가 라우터를 균등하게 나누어 사용하기 때문)

 

혼잡 시나리오 1 : 호스트 전송률의 함수로 보는 처리량과 지연

첫번째 그래프 : 라우터를 경우하여 송신자의 데이터를 수신자가 받기때문에 송신 속도가 라우터의 처리량보다 크더라도 라우터의 처리량을 초과하는 데이터는 버퍼에 쌓이고 라우터가 전송하는 속도가 R/2로 제한되기 때문에 수신자 역시 수신의 속도 역시 R/2로 제한 된다.

 

두번째 그래프 : 큐잉지연에서 La/R < 1 을 통한 지연 그래프를 떠올리자 (1장 큐잉 지연 글 확인)

 

결론 : 혼잡 네트워크의 한 비용, 즉, 패킷 도착률이 링크 용량(R)에 근접함에 따라 큐잉 지연이 커진다.

 

시나리오 2 : 2개의 송신자, 유한 버퍼를 가진 하나의 라우터

λ'in : 제공된 부하(offered load) (패킷 재전송을 포함하는 전송률 : 트랜스포트 계층(세그먼트) 기준의 전송률)

+ 패킷 손실 가능성 추가

+ 각 연결이 신뢰적 (재전송 고려)

그림 설명 : 첫번째 시나리오의 그래프와 달리 λ'in은 재전송된 패킷을 포함한 전송률이기 때문에 중복된 데이터를 포함한 전송률이다. 수신자의 입장에서는 중복된 데이터를 제외한 나머지 최초 전송받은 데이터만이 유의미한 데이터이기 때문에 수신률은 이상적인 R/2의 경우보다 낮아진다. (R/3은 재전송된 R/2에서 유의미한 데이터의 비율)

 

결론 : 혼잡 네트워크의 또 다른 비용, 즉, 송신자는 버퍼 오버플로 때문에 버려진 패킷을 보상하기 위해 재전송을 수행해야한다.

 

+ 송신자 측에서 너무 일찍 타임아웃이 발생하여 패킷이 손실되지 않음에도 재전송된 경우

그림 설명 : 위의 그래프 보다 재전송되는 패킷의 경우의 수가 늘었기 때문에 재전송된 패킷의 비율이 증가함을 나타낸다.

 

결론 : 혼잡 네트워크의 또 다른 비용, 즉, 커다란 지연으로 인한 송신자의 불필요한 재전송은 라우터가 패킷의 불필요한 복사본들을 전송하는데 링크 대역폭을 사용하는 원인된다.

 

시나리오 3 : 4개의 송신자와 유한 버퍼를 가지는 라우터, 그리고 멀티홉 경로

*멀티 홉(multi-hop) 네트워크 : 메시지가 송신 노드로부터 직접적으로 최종 목적 노드로 전송되는 것이 아니라 1개 이상의 중간 노드를 경유하는 전송 방식

hop 위키 검색 결과 링크 https://ko.wikipedia.org/wiki/%ED%99%89_(%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC)

hop 네이버 사전 검색 결과 링크

https://en.dict.naver.com/#/entry/enko/d279013c723d43e1b67859f98c06eae9

 

+ 2-홉 경로를 통해 패킷을 전송

+ 각각의 호스트가 안정적인 데이터 전송 서비스를 실행하기 위해 타임아웃/재전송 메커니즘 사용

유한 버퍼와 멀티홉 경로를 가진 시나리오 3의 성능

case 1 : λin 의 극히 작은 값

버퍼 오버플로는 거의 발생하지 않음

혼잡 시나리오1, 2와 같이 처리량은 제공된 부하와 거의 같음

 

case 2 : λin 의 약간 더 큰 값

원래의 데이터가 네트워크로 전송되고 목적지에 전달됨

오버플로가 거의 발생하지 않음

 

=> case1, 2 일 때, λin의 증가는 λout의 증가를 가져온다.

 

시나리오 3 : 송신자 4개, 유한 버퍼를 가진 라우터, 멀티홉 경로

case 3 : λin이 매우 큰 경우

경로 1 : host A -> route A -> route B -> host C

경로 2 : host B -> route B -> route C -> host D

의 두 개의 경로 존재

 

route A -> route B로 전송가능한 전송률은 R(링크 용량)까지 가질 수 있음

-> 경로 1의 경우 route B 로 전송가능한 전송률은 R로 제한됨

 

반면 경로 2의 경우 route B로 전송가능한 전송률은 λ'in에 따름

 

λ'in의 크기가 증가(부하가 증가)할수록 경로 1에서 전송되는 패킷은 route B의 경쟁에서 제한된 속도 이상을 가질 수 없으므로 밀려나게 됨

-> 제공되는 부하가 매우 매우 크다면 경로 1의 처리량은 0가 될 수 있다. 버퍼의 경쟁에서 뒤떨어져서 모든 패킷이 손실되는 경우가 초래된 것

 

결론 : 혼잡 네트워크의 또 다른 비용, 즉, 패킷이 경로 상에서 버려

질 때, 버려지는 지점까지 패킷을 전송하는 데 사용된 상위 라우터에서 사용된 전송 용량은 헛된 것이다.

 

3.6.2 혼잡제어에 대한 접근법

종단 간의 혼잡제어 (end-end congestion control)

- 네트워크 계층에서 혼잡제어를 위한 피드백이나 지원 없음

- 종단 시스템에서 관찰된 패킷 손실 및 지연에 기초하여 혼잡을 추측

- TCP가 사용하는 방법

- TCP에 대한 새로운 제안으로 증가하는 왕복 지연값을 네트워크 혼잡 증가를 나타내는 것으로 사용하는 것

 

네트워크 지원 혼잡 제어 (network-assisted congestion control)

- 라우터가 종단 시스템에게 혼잡 상태에 관한 피드백을 제공

- 링크의 혼잡을 나타내는 단일비트 (SNA, DEC, TCP/IP ECN, ATM)

- 라우터가 송신자에게 자신의 전송률을 전송(ATM ABR)