프로토콜 종류

UDP(User Datagram Protocol) : 단순성과 효율성으로 사용되는 신뢰성없는 비연결 전송층 프로토콜
TCP(Transmission Control Protocol) : 신뢰성 있는 연결 지향 프로토콜
SCTP(Stream Control Transmission Protocol) : UDP와 TCP의 특성을 결합한 새로운 전송층 프로토콜

포트 번호

UDP와 TCP를 사용하는데 쓰이는 잘 알려진 포트들이 있다.

UDP

비연결형, 신뢰성 없는 프로토콜이다.
간단하다.

User Datagram

UDP 패킷들을 User Datagram이라 부른다.
헤더는 8바이트며, 4개의 필드로 구성, 각 필드 2바이트
- 발신지 포트 번호(source port number) : 발신지 호스트에서 수행되는 프로세스가 사용하는 포트 번호
- 목적지 포트 번호(destination port number) : 목적지 호스트에서 수행되는 프로세스가 사용하는 포트 번호
- 길이(length) : 헤더와 데이터를 합한 전체 길이
- 검사합(checksum) : 오류 탐지에 사용, 선택적인 필드

UDP Services

UDP에 의해 제공되는 일반적인 서비스가 있다.

프로세스-대-프로세스 통신 : 소켓 주소를 이용하여 프로세스-대프로세스 통신을 제공
비연결 서비스 : 연결 설정 및 연결 종료가 없는 비연결 서비스로서 각 사용자 데이터 그램은 독립된 데이터그램이며 서로 다른 경로로 이동할 수 있다. 단문 메시지, 실시간 응용에 사용
흐름 제어, 오류 제어 없음.(오류를 탐지하는 checksum만 있음)
의사 헤더 (Pseudoheader) : 손상되지 않아야 하는 IP 패킷 헤더의 일부분

UDP Applications

단순 요청-응답 통신이 필요하고 흐름과 오류제어가 필요 없는 프로세스에 적합
내부에 흐름 및 오류제어가 있는 응용에 적합 (예:TFTP)
멀티캐스팅에 적합한 전송 프로토콜
SNMP와 같은 관리 프로세스에 사용
RIP와 같은 경로 갱신 프로토콜에 사용
수신된 메시지 단편간 지연 편차가 적어야 하는 실시간 상호작용 응용에 적합

DNS(Domain name System)

클라이언트가 짧은 요청을 서버에게 전송하고 서버로부터 빠른 응답을 수신 하기를 원하기 때문에 UDP 서비스를 이용한다.
요청과 응답은 각각 하나의 사용자 데이터그램에 들어갈 수 있다.
각각의 방향으로 단지 하나의 메시지만 교환되기 때문에, 비연결형 특징은 문제가 되지 않는다. 클라이언트나 서버는 메시지가 순서에 어긋나게 전달 되는 것을 고민하지 않는다.

실시간 스트림 영상 (Skype)

스트림 영상은 긴 파일로 간주되며, 여러 개의 작은 부분으로 나누어져 각각 실시간으로 전송/방송된다.
전송 계층이 훼손되거나 손실된 프레임을 재전송하게 되면 전체 전송의 동 기가맞지않게된다.시청자는 갑자기 빈화면만 보게 될 것이고 두번째 전송이 도착하기전까지 기다려야 할 것이다. (지연에 민감)
그렇지만 화면의 각각의 조그만 부분이 하나의 단일 사용자 데이터그램으로 전송된다면, 수신 UDP는 훼손되거나 손실된 패킷을 그냥 무시하고 나머 지를 응용 프로그램으로 전달한다. 화면의 일부분이 아주 잠깐 동안 공백이 되겠지만, 대부분의 시청자들은 알아차리지 못한다. (손실에 둔감)

TCP

Transmission Control Protocol (TCP)

프로세스 대 프로세스 통신 : 포트 번호를 이용한 프로세스간 통신 제공
스트림 전송 서비스 : 바이트의 흐름으로 데이터를 전달
연결지향 서비스 : 가상의 연결 설정
신뢰성 서비스

스트림 전송 서비스

TCP는 스트림 기반 프로토콜
바이트 스트림 형태로 데이터 송수신
두 개의 프로세스가 가상의 튜브로 연결
송신 프로세스는 바이트 스트림 생성(쓰기), 수신 프로세스는 바이트 스트림 소비(읽기)

버퍼(buffer)

송/수신이 동일한 속도로 이루어지지 않을 때 버퍼가 필요 (흐름, 오류제어 제공)

세그먼트(segments)

일련의 바이트를 세그먼트라는 패킷으로 그룹화
IP 계층에 전달되어 독립적으로 전송

제공하는 서비스

전이중 통신(양방향 데이터 송수신)
다중화와 역다중화
연결지향 서비스
- 두 TCP간에 가상 연결 설정
- 양방향 데이터 교환
- 연결 종료
신뢰성 서비스
- 확인응답 메커니즘 이용
- Go Back-N, Selective Repeat

특성

번호화 시스템 (Numbering System) : 각 방향으로 전송되는 데이터 바이트는 TCP에 의해서번호가 매겨진다. 번호는 임의로 생성된 값에서 시작한다.
- 바이트 번호- 모든 데이터에 바이트 단위로 번호 부여
- 송신 순서 번호 – 세그먼트에 있는 첫 번째 바이트에 순서번호 할당
- 확인 응답 번호 – 자신이 수신하기를 기대하는 다음 바이트 번호
흐름 제어 (Flow Control)
오류 제어 (Error Control)
혼잡 제어 (Congestion Control)

Control field

제어(control) : 제어 또는 플래그 비트

TCP 연결 상태

연결 설정

전이중 모드 연결 : Three-way handshake
클라이언트와 서버 응용 프로그램간 연결

서버부터 시작(수동 개방(passive open))
클라이언트부터 시작(능동 개방(active open))
- 클라이언트는 SYN 플래그가 1로 설정된 SYN 세그먼트 전송 – 서버는 SYN와 ACK 플래그가 1로 설정된 세그먼트 전송
- 단순한 ACK 세그먼트 전송
동시개방

데이터 전송

데이터 전송과 확인응답을 동시에 전송(piggyback)
Pushing(밀어넣기) 데이터 :
- Push 비트를 설정하여 push 동작 요구
- 윈도우가 다 찰 때까지 기다리지 않는다는 것
- 즉시 응답을 요구하는 대화형 통신을 하는 응용에 적합
Urgent (긴급) 데이터 : 특수한 처리가 필요한 데이터
- URG비트를 설정, 긴급을 알림
- 세그먼트의 시작부분에 긴급 데이터를 삽입하고 나머지 세그먼트 는 정상적인 데이터를 포함.
- 긴급 지시자(Urgent Pointer) 필드는 긴급 데이터의 종료 지점과 정상 데이터의 시작 지점을 정의

연결 종료

절반-닫기(half-close)

한쪽에서는 데이터를 수신하면서 데이터 전송 종료 가능
어느 쪽이든 요청 가능
서버가 모든 데이터를 수신한 후에 처리를 시작하는 경우 발생 (예:정렬(sort))

State Transition Diagram

연결 설정, 데이터 전송, 연결 종료 등의 연결 동안 일어나는 이벤트들을 다이어그램으로 표현한 것.

TCP의 windows

TCP에서 데이터 전송에 각 방향마다 2개의 windows를 사용한다.(send window, receive window)

rwnd (수신 윈도우 크기)

TCP flow control

생산/소비 속도에 따라 흐름제어가 요구됨.
수신측 윈도우에 따라 송신측 윈도우 사이즈 조절됨 (흐름제어)

윈도우 축소 문제

피드백의 전송을 연기로 해결

Silly Window Syndrome

송신측 신드롬

송신 TCP가 한 번에 한 바이트씩 데이터를 천천히 발생시킬 때의 문제
- 적은 수의 데이터를 포함하는 세그먼트의 전송으로 동작의 효율이 감소
- 1바이트 데이터 + 40바이트 헤더(TCP20,IP20) +. 데이터 링크 및 물리계 층의 오버헤드

해결 : Nagle 알고리즘

첫 번째 1 바이트는 세그먼트로 전송
확인응답을 수신하거나 충분한 세그먼트를 구성할 수 있도록 출력 버퍼 에 데이터 저장을 기다린다.이 두 가지 경우 중 하나가 발생하면 2 번째 세그먼트 전송
2번째단계반복

수신측 신드롬

응용 프로그램이 한번에 1 바이트씩 소비할 경우
- 수신 버퍼가 4Kbyte일 때, 송신측으로부터 4Kbyte 데이터를 수신하여 버퍼에 저장하면, 송신측에 윈도우 크기를 0으로 설정 통보 => 송신측은 전송을 멈춤
- 응용 프로세스가 1byte씩 읽어가면 송신측에 1byte 윈도우 크기를 통보
- 송신측은 1byte 세그먼트 전송 => 어리석은윈도우문제재발생

해결

Clack 해결 방법

데이터가 도착하자마자 확인응답을 전송하지만, 수신 버퍼에 최대 크기의 세그먼트를 수용할 공간이 있거나 수신버퍼의 반 이상 비어있기 전까지 윈도우 크기를 0으로 통보

지연된 확인 응답 (Delayed acknowledgement)

수신 버퍼에 충분한 공간이 생길 때까지 확인 응답을 지연 (최대 500ms)

장점 : 수신측에서 각 세그먼트에 대한 확인응답을 전송할 필요가 없음

TCP Error Control

확인 응답 전송

확인 응답 유형

누적 확인 응답 (ACK)
- 순서에 맞지 않게 저장되거나 수신된 모든 세그먼트들을 무시하고 수신하고자 하는 다음 바이트를 통보한다.
- 수신측에서 세그먼트가 폐기되거나 손실 혹은 중복 수신되었을 때 이에 대한 어떤 피드백도 제공하지 않음
- 긍정 누적 확인 응답 (Positive cumulative acknowledgement)
선택 확인 응답 (SACK)
- ACK를 대치하는 것이 아니라 송신측에게 부가 정보를 제공
- 순서에 맞지 않게 들어온 데이터 블록과 중복 세그먼트 블록을 알려줌.
- TCP 헤더에는 이러한 유형의 정보를 추가 할 수 없어 헤더 끝에 옵션의 형태로 구현

세그먼트 재전송

RTO 이후의 재전송
- 송신 TCP는 연결마다 하나의 재전송 타임아웃(RTO,Retransmission time-out) 유지
- 타임 아웃이 발생하면 송신 버퍼의 세그먼트를 재전송하고 타이머를 재구동
- RTO의 값은 가변적이며 세그먼트의 RTT기반으로 업데이트된다.
3개의 중복 ACK 세그먼트 이후에 재전송
- 하나의 세그먼트에 대해 3개의 확인 응답(ACK)이 수신되면 타임 아웃을 기다리지 않고 해당 세그먼트를 즉시 재전송.
- 인터넷의 처리율 향상을 위해 송신측에서 타임아웃을 기다리지않고 해당 세그먼트를 빠른 재전송 (fast retransmission)

TCP Congestion Control

혼잡 윈도우(cwnd)

중간 네트워크의 혼잡을 고려한 윈도우

실제 윈도우 크기

minimum (rwnd, cwnd)

혼잡 감지

타임 아웃 (높은 혼잡)과 3개의 중복 ACK (낮은 혼잡)

혼잡 정책 : 혼잡 윈도우의 변화

혼잡에 대처하는 방법

느린 시작 (Slow Start): 지수 증가 (Exponential Increase)
- 혼잡 윈도우 크기를 임계치 전까지 지수적으로 증가
혼잡 회피 (Congestion Avoidance): 가산 증가 (Additive Increase)
- 혼잡 윈도우 크기를 임계치 도달 후 가산적으로 증가
혼잡 감지 (Congestion Detection): 지수 감소 (Multiplicative Decrease)

혼잡 제어

타이머종료 (높은 혼잡 가능성)
1. 임계치(ssthresh)값을 현재 윈도우 크기의 절반으로 조정
2. cwnd를 하나의 세그먼트로 조정 (처음부터 다시 시작)
3. 다시 slow start 단계를 시작
세 개의 Ack를 수신 (낮은 혼잡 가능성) => Fast Recovery
1. 임계치값을 현재 윈도우 크기의 절반으로 조정
2. cwnd를 임계치 값으로 조정
3. 혼잡회피(Congestionavoidance)단계를 시작

정책

TCP 버전마다 정책이 다르다.

Taho TCP
- 혼잡 제어 정책에 Slow Start와 Congestion avoidance 알고리즘만 사용
- 타임아웃과 3개의 중복 ACK를 같이 처리
Reno TCP
- Fast recovery 추가 => Slow start와 Congestion avoidance의 중간형태

Reno TCP가 오늘날 가장 일반적 => 초기의 느린 시작 상태가 지난 후 혼잡 윈도 크기가 가산 증가, 지수 감소 패턴을 따르게 됨.

TCP Timer

retransmission: 한 세그먼트에 대한 확인응답을 기다리는 시간인 재전송 타임아웃(RTO) 값 설정
Karn 알고리즘
- 전송된 세그먼트에 대해 확인 응답되지 않아 재전송된 경우
- 송신측은 이전 세그먼트에 대한 확인응답인지 재전송에 대한 확인 응답인지 여부 판단이 애매하다
- RTT 값은 재전송 없이 확인응답한 경우만 갱신한다
persistence: 윈도우 크기가 0 인 경우를 처리하기 위한 타이머
keepalive
- 두 TCP 간에 설정된 연결이 오랫동안 휴지(idle) 상태에 있는 것을 방지하기 위한 타이머, 시간-종료 : 2 시간
- 2 시간이 지나도록 세그먼트를 수신하지 못하면 75초 간격으로 10개의 프로브(probe) 전송
- 응답이 없으면 다운으로 간주하고 연결 종료
TIME-WAIT
- 연결 종료 동안에 사용
- 2MSL (Maximum Segment Life-time, 최대 세그먼트 생존 시간)
  - 하나의 FIN 세그먼트가 없어지고 또 다른 FIN이 도착하는데 걸리는 충분한 시간 (최대 2분)
  - 한 연결이 종료되고 새로운 연결이 설정될 때 기다리는 충분한 시간

김땡땡's blog

김땡땡

전송층 인터넷 프로토콜, UDP, TCP