[혼공학습단 12기]혼공 네트워크 스터디 4주차 - 전송 계층

저번주에는 혼자 공부하는 네트워크 3주차 스터디를 통해 컴퓨터 네트워크의 네트워크 계층 내용에 대해 알아보았다.

이번 4주차에는 OSI 7계층 기준으로 4계층에 해당하는 전송 계층에 대한 내용을 살펴보도록 하자!

---

<Chapter 04. 전송 계층>

전송 계층 개요 - IP의 한계 그리고 포트

전송 계층 개요

앞서 학습한 네트워크 계층의 IP는 신뢰할 수 없는 통신 + 비연결형 통신을 수행한다는 한계가 존재한다.
네트워크 계층와 응용 계층 사이에 위치한 전송 계층은 신뢰할 수 있는 통신 + 연결형 통신을 가능하게 하여 이러한 IP의 한계를 극복하고, 포트 번호를 통해 응용 계층의 애플리케이션 프로세스들을 식별하는 역할을 수행한다.
그러면 이제부터 전송 계층에 대해서 자세히 알아보자!

신뢰할 수 없는 통신 & 비연결형 통신

네트워크 계층의 핵심 프로토콜인 IP 그리고 IP의 한계

네트워크 계층의 핵심 프로토콜 IP ⇒ IP 단편화 & IP 주소 지정 수행
IP의 한계로는 크게 2가지 특징이 존재한다.
1. 신뢰할 수 없는(비신뢰성) 프로토콜
2. 비연결형 프로토콜
이를 달리 말하면, IP를 통한 패킷의 전달은 신뢰성이 없는 통신이며, 연결을 수립하는 과정이 없는 통신이다.
이는 전송 계층이 존재하는 이유와도 직결된다!

신뢰할 수 없는 통신 & 비연결형 통신

[신뢰할 수 없는 통신]
- IP 프로토콜이 패킷이 수신지까지 제대로 전송되었다는 보장을 하지 않음
- 통신 과정에서 패킷의 데이터가 손상 혹은 중복된 패킷이 전송되었어도 이를 확인하지 않고 재전송도 하지 않으며 순서대로 패킷이 도착하는 것도 보장하지 않음
- 이러한 전송 특성은 다른 말로 최선형 전달이라고도 부름

[비연결형 통신]
- 비연결형 통신은 송수신 호스트 간에 사전 연결 수립 작업을 거치치 않음을 의미함

IP가 위와 같은 한계가 있음에도 사용하는 이유

- 제일 핵심적인 이유는 '성능' 때문
- 패킷이 잘 전송되었는지 일일이 확인 + 호스트 간의 연결 수립 작업은 대체로 패킷의 빠른 송수신과는 반대되는 작업이다.
- 실시간 영상 통화처럼 1~2개의 패킷 손실은 감수하더라도 빠른 전송이 필요한 경우가 존재함

IP의 한계를 보완하자! 전송 계층

전송 계층이 IP의 한계를 보완하는 방법

전송 계층이 IP의 한계를 보완하는 방법은 크게 다음과 같다.
1. 전송 계층은 연결형 통신을 가능하게 한다.
2. 전송 계층은 신뢰성 있는 통신을 가능하게 한다.

[1. 전송 계층은 연결형 통신을 가능하게 한다]
- 연결형 통신을 지원하는 대표 전송 프로토콜에는 TCP가 존재함
- 전송 계층의 연결형 프로토콜인 TCP는 두 호스트가 정보를 주고받기 전, 가상의 회선을 설정하듯이 연결을 수립함
- 송수신하는 동안에는 연결을 유지하고, 송수신이 끝나면 연결을 종료할 수 있음

[2. 전송 계층은 신뢰성 있는 통신을 가능하게 한다]
- TCP는 패킷이 수신지까지 올바른 순서대로 확실히 전달되는 것을 보장하기 위해 재전송을 통한 오류 제어 & 흐름 제어 & 혼잡 제어 등 다양한 기능들을 제공함

연결형 통신 + 신뢰성 있는 통신이 그 반대에 비해 과연 무조건 좋은가

연결형 통신과 신뢰성 있는 통신이 그렇지 않은 통신에 비해 무조건 좋은 것은 아니다.
가끔은 높은 성능을 위해 신뢰할 수 없으며 비연결형 통신을 지원하는 프로토콜이 필요할 수 있다.
그렇기 때문에 전송 계층에는 TCP 뿐만 아니라 UDP라는 프로토콜도 존재한다!
UDP는 신뢰할 수 없는 통신 + 비연결형 통신을 가능하게 하는 전송 계층의 프로토콜로, TCP보다는 비교적 빠른 전송이 가능하다.

응용 계층과의 연결 다리 - 포트

응용 계층과의 연결 다리 역할을 수행하는 전송 계층

전송 계층은 앞서 살펴본 네트워크 계층의 한계를 극복하는 것이 끝이 아니다.
여기서부터는 응용 계층과의 연결 다리 역할로서의 전송 계층을 살펴본다!
그러기 위해서 포트가 무엇인지부터 차근차근 시작해보도록 하자.

포트의 정의

포트에 대해서 알아보기 위해, 한 가지 상황을 가정해보자.
사진 파일을 구성하는 패킷들이 라우팅 되어 우리의 컴퓨터로 도착한 상황이며, 현재 우리는 컴퓨터로 여러가지 프로그램들을 실행하고 있다. 그러면 이 때 사진 파일 패킷들이 컴퓨터에 도달하고 나면 수신이 그냥 끝날까?
정답은 그렇지 않다. 패킷들은 웹 브라우저 혹은 메신저 프로그램들에 전달되어야 할 수도 있다.
즉, 패킷은 실행 중인 특정 애플리케이션 프로세스까지 정확하게 전달되어야 한다!
이 내용을 다시 정리하면, 수신지 호스트의 주소까지 패킷이 도착했다고 해서 전송이 끝난 것이 아니라, 실행 중인 특정 애플리케이션 프로세스까지 전달되어야 한다.
결국 패킷의 최종 수신 대상은 특정 애플리케이션 프로세스이다.
이 때 패킷이 어떤 애플리케이션 프로세스로 전달되어야 하는지를 나타내는 정보가 바로 포트(Port)이다.

포트의 분류 - 잘 알려진 & 등록된 & 동적 포트

포트의 분류

포트 종류	포트 번호 범위
잘 알려진 포트	0~1023
등록된 포트	1024~49151
동적 포트	49152~65535

전송 계층에서는 포트 번호를 통해 특정 애플리케이션을 식별할 수 있다.
- 전송 계층의 핵심 프로토콜인 TCP & UDP는 모두 포트 번호 필드인 송신지 포트 번호와 수신지 포트 번호를 포함
- 포트 번호는 16비트로 표현 가능 + 사용 가능한 포트의 수는 65536(2^16)개
- 0번부터 65535번까지의 포트 번호는 번호의 범위에 따라 3종류로 나뉨
⇒ 잘 알려진 포트, 등록된 포트, 동적 포트 이렇게 3가지

잘 알려진 포트 번호(0~1023)

잘 알려진 포트 번호	설명
20, 21	FTP
22	SSH
23	TELNET
53	DNS
67, 68	DHCP
80	HTTP
443	HTTPS

- 0번부터 1023번까지의 포트 번호는 잘 알려진 포트로, 시스템 포트라고도 부름
- 범용적으로 사용되는 애플리케이션 프로토콜이 일반적으로 사용하는 '널리 알려진, 유명한' 포트 번호를 의미하며 대표적인 예시는 위와 같음

등록된 포트(1024~49151)

잘 알려진 포트 번호	설명
1194	OpenVPN
1433	Microsoft SQL Server DB
3306	MySQL DB
6379	Redis
8080	HTTP 대체

- 1024번부터 49151번까지의 포트 번호는 등록된 포트
- 잘 알려진 포트에 비해 비해 덜 범용적이나, 흔히 사용되는 애플리케이션 프로토콜에 할당하기 위해 사용됨. 참고로 위 예시를 따로 외울 필요는 없음

동적 포트(49152~65535)

- 49152번부터 65535번까지의 포트 번호는 동적 포트(사설 포트, 임시 포트)라고 부름
- 따로 할당된 애플리케이션 프로토콜이 없고, 특별히 관리되지 않는 포트 번호이므로 자유롭게 사용할 수 있음
- 서버로 동작하는 프로그램은 일반적으로 잘 알려진 포트 + 등록된 포트로 동작하는 경우가 많음. 즉 이미 사전에 암묵적으로 정해진 경우가 많음
- 클라이언트로 동작하는 프로그램은 동적 포트 번호 중에서 임의의 번호가 할당되는 경우가 많음. 대표적인 예시는 웹 브라우저가 존재함!

포트 기반 NAT

NAT 개요

바로 앞에서 포트에 대한 개념을 알아보았다.
포트에 대한 개념을 알고 있다면 네트워크 계층에서 배운 NAT를 좀 더 자세히 이해할 수 있다!
NAT는 IP 주소를 변환하는 기술이며 주로 네트워크 내부에서 사용되는 사설 IP 주소와 네트워크 외부에서 사용되는 공인 IP 주소를 변환하는 데 사용된다.
이러한 변환을 위해 주로 사용되는 것이 NAT 변환 테이블이다! NAT 변환 테이블 부터 차근차근 다시 살펴보자.

NAT 변환 테이블

네트워크 외부	네트워크 내부
1.2.3.4	192.168.0.5
1.2.3.5	192.168.0.6
…	…

NAT 변환 테이블에는 변환의 대상이 되는 IP 주소 쌍이 명시되어 있다.
1가지 예시를 들어 이를 이해해보도록 하자!
1. 네트워크 내부에 192.168.0.5라는 사설 IP 주소를 가진 호스트가 존재하는데, 여기서 수신지 주소가 10.11.12.13인 네트워크 외부의 호스트에게 패킷을 전송한다고 가정하자.
2. 패킷이 NAT 기능을 갖춘 라우터를 거쳐 네트워크 외부로 나가게 되면 패킷의 송신지 주소는 네트워크 외부에서 사용되는 공인 IP 주소인 1.2.3.4가 된다.
3. 반대의 경우에는 수신지 주소가 1.2.3.4인 패킷이 네트워크 외부에서 네트워크 내부로 전송된다고 가정하자.
4. 이 경우 패킷의 수신지 주소는 NAT 라우터를 거쳐 192.168.0.5가 된다.

NAT를 통해 모든 사설 IP를 변환하게 되면…

- NAT 테이블을 보면 사설 IP 주소 하나당 공인 IP 주소 하나가 대응된 셈
- 수없이 많은 사설 IP 주소가 존재할 것인데, 이를 다 변환하기에는 무리
- 사설 IP 주소와 공인 IP 주소가 일대일로 대응되면 네트워크 내부에서 사용되는 사설 IP 주소의 수만큼 공인 IP 주소가 필요함
- 이러한 이슈가 있기 때문에 오늘날 활용되는 NAT는 IP 주소를 일대일로 대응하지 않음
오늘날 NAT 기술은 대부분 다수의 사설 IP 주소를 그보다 적은 수의 공인 IP 주소로 변환하는데, 이 때 포트가 활용
된다! 포트를 활용한 NAT 기술로 NAPT라는 것이 존재한다.

NAPT(Network Address Port Translation)

네트워크 외부	네트워크 내부
1.2.3.4:6200	192.168.0.5:1025
1.2.3.4:6201	192.168.0.6:1026
…	…

NAPT(Network Address Port Translation) : 포트 기반의 NAT, APT라고도 부름
- NAPT는 포트를 활용해 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유할 수 있게 함 
- NAPT는 위 테이블과 같이 변환할 IP 주소 쌍과 함께 포트 번호도 기록 및 변환함
- 1.2.3.4라는 같은 공인 IP 주소더라도 포트 번호 6200번으로 변환되느냐 6201번으로 변환되느냐에 따라 내부 IP 주소를 구분지을 수 있음
- 네트워크 외부에서 사용할 IP 주소가 같더라도 포트 번호가 다르면 네트워크 내부의 호스트를 특정할 수 있기 때문에 다수의 사설 IP 주소를 그보다 훨씬 적은 수의 공인 IP주소로 변환할 수 있게 됨!

TCP & UDP

TCP & UDP 개요

TCP 통신 단계를 크게 3단계로 나누면 아래와 같다.
1. 연결 수립
2. 데이터 송수신 - 재전송을 통한 오류 제어 & 흐름 제어 & 혼잡 제어
3. 연결 종료
- TCP는 통신하기 전에 연결을 수립하고 통신이 끝나면 연결을 종료함
- TCP는 데이터 송수신 과정에서 오류 제어 & 흐름 제어 & 혼잡 제어 등의 기능을 제공함
- 우선 여기서는 1번과 3번을 알아보고 2번은 따로 알아볼 예정

TCP 연결 수립과 종료

TCP 연결 수립 : 3-way handshake

- TCP의 연결 수립은 3-way handshake를 통해 이루어진다.
- 3-way handshake는 3개의 단계로 이루어진 TCP의 연결 수립 과정을 의미한다.
- 호스트 A, B가 3-way handshake를 한다고 가정하면, 아래와 같은 3단계를 거친다.

액티브 오픈 & 패시브 오픈

액티브 오픈 : 처음 연결을 시작하는 호스트의 연결 수립 과정(주로 클라이언트)
패시브 오픈 : 연결 요청을 받고 나서 요청에 따라 연결을 수립해주는 과정(주로 서버)

TCP 연결 종료 : 4-way handshake

3-way handshake를 통한 연결 수립 후 데이터 송수신이 끝나면, 연결을 종료해야 할 것!
TCP가 연결을 종료하는 과정은 송수신 호스트가 각자 1번씩 FIN, ACK를 주고받으며 이루어진다.

액티브 클로즈 & 패시브 클로즈

액티브 클로즈 : 먼저 연결을 종료하려는 호스트의 연결 종료 과정(주로 클라이언트)
패시브 클로즈 : 연결 종료 요청을 받고 나서 연결 종료를 진행해주는 과정(주로 서버)

TCP 상태

TCP 상태 개요

TCP는 연결형 통신 & 신뢰할 수 있는 통신을 위해 다양한 '상태'를 유지한다.
TCP는 상태를 유지하고 활용한다는 점에서 stateful 프로토콜이라고도 불린다.
상태(state) : 현재 어떤 통신 과정에 있는지를 나타내는 정보
TCP 상태는 크게 아래와 같다.
1. 연결이 수립되지 않은 상태
2. 연결 수립 과정에서 주로 볼 수 있는 상태
3. 연결 종료 과정에서 주로 볼 수 있는 상태

상태 분류	주요 상태
연결이 수립되지 않은 상태	CLOSED, LISTEN
연결 수립 과정에서 주로 볼 수 있는 상태	SYN-SENT, SYN-RECEIVED, ESTABLISHED
연결 종료 과정에서 주로 볼 수 있는 상태	FIN-WAIT-1, CLOSE-WAIT, FIN-WAIT-2, LAST-ACK, TIME-WAIT, CLOSING

연결이 수립되지 않은 상태

연결 수립 과정에서 주로 볼 수 있는 상태

연결 종료 과정에서 주로 볼 수 있는 상태

연결 종료 과정에서 주로 볼 수 있는 상태 - CLOSING

CLOSING 상태는 두 호스트가 동시에 연결을 종료하려 할 때 전이되는 상태이다. 이는 서로가 FIN 세그먼트를 보내고 받은 뒤 각자 그에 대한 ACK 세그먼트를 보냈으나 아직 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못했을 때 접어드는 상태이다. 이 경우 ACK 세그먼트를 수신할 경우 각자 TIME-WAIT 상태로 접어든 뒤 중료하게 된다.

UDP 데이터그램 구조

UDP 데이터그램 개요

UDP : TCP와는 달리 신뢰성은 떨어지나 비교적 빠른 통신이 가능한 비연결형 프로토콜
- 따라서 연결 수립 및 해제, 오류 제어, 혼잡 제어, 흐름 제어 등을 수행하지 않음
- 상태를 유지하지 않는다는 점에서 UDP를 Stateless 프로토콜의 일종이라고 함
- UDP 데이터그램 구조의 경우 기능이 적은 만큼 필드도 단순함
- TCP에 비해 적은 오버헤드로 패킷을 빠르게 처리가능하여 실시간 서비스에 많이 쓰임

UDP 데이터그램 구조

송신지 포트(16비트)	수신지 포트(16비트)
길이(16비트)	체크섬(16비트)

 

송신지 & 수신지 포트	송수신지의 포트 번호
길이	헤더를 포함한 UDP 데이터그램의 바이트
체크섬	데이터그램 전송 과정에서 오류가 발생했는지 검사하기 위한 필드. 수신지는 이 필드의 값을 토대로 데이터그램의 정보가 훼손되었는지 판단하고, 문제가 있다고 판단한 데이터그램은 폐기한다. 데이터그램이 훼손되었는지를 나타내는 정보라는 점에서 ‘수신지까지 잘 도착했는가’를 의미하는 신뢰성 및 비신뢰성과는 관계 없다.

 

---

기본 숙제 - 확인 문제 풀이

확인 문제 04-1 1번(206p)

네트워크 계층의 IP : 비신뢰성 + 비연결형
전송 계층의 TCP & UDP
- TCP : 신뢰성 + 연결형
- UDP : 비신뢰성 + 비연결형

확인 문제 04-2 2번(225p)

TCP 3-way handshake 과정 중 마지막 과정은 다음과 같다.
호스트 B가 전송한 세그먼트에 대한 확인 응답으로 액티브 호스트에서 패시브 호스트로 ACK 세그먼트를 보낸다.

추가 숙제 - 작업 관리자에서 프로세스별 PID 확인 

ctrl + alt + delete 키를 눌러 작업 관리자에 접속할 수 있다.
그리고 여기서 프로세스 바로 아래 공간에 우클릭 - PID를 클릭하면 각 프로세스들의 PID를 확인할 수 있다.
가만 보면 구글 크롬의 각 페이지는 각기 다른 PID, 즉 프로세스들임을 파악할 수 있다.