01. 인터넷 통신
인터넷 망에서 컴퓨터들은 어떻게 통신할까요??
예를 들어 물리적으로 클라이언트 옆에 서버가 있다면 , 간단하게 케이블을 연결해서 'Hello, world!'라는 메시지를 보내면 통신이 된다. 하지만, 클라이언트와 서버 중간에 인터넷망이 있다면 어떻게 통신이 될까?
예를 들어 클라이언트가 한국에 있고 서버가 미국에 있다면, 한국에 있는 클라이언트가 'Hello, world!'라는 메시지를 미국에 있는 서버로 보내는 과정에서 해저광케이블이나, 인공위성등으로 보내면서 수많은 중간 노드라고 하는 서버들을 거쳐 미국에 있는 서버에게 안전하게 메시지를 보내야한다. 이러한 과정에서 어떤 규칙으로 미국에 있는 서버에 안전하게 도착할 수 있는지 이해를 하기 위해서는 IP 프로토콜을 알아야 한다.
02. IP (인터넷 프로토콜)
인터넷 프로토콜, 즉 IP 의 역할은 다음과 같다.
- 지정한 IP 주소(Address)에 데이터를 전달
- 패킷(Packet)이라는 통신 단위로 데이터를 전달
클라이언트와 서버 모두 IP 주소가 있어야 하고 서버에게 'Hello,world!' 메시지를 보낼 때 최소한의 규칙이 있어야 하는데 패킷이라는 규칙으로 보내야한다.
패킷 단위로 데이터를 전달하게 되는데 , 전송 데이터(보낼 메시지)와 함께 출발지 IP(클라이언트 IP), 목적지 IP(서버 IP)등을 함께 묶어 패킷으로 만든 후 전달한다.
02-1. IP 프로토콜의 한계
- 비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태 - 패킷 전송
- 클라이언트(출발지)에서 패킷을 전송하려고 할때, 대상 서버(목적지)의 상태는 알 수 없다. 그래서 항상 패킷을 보내게 되는 문제가 발생한다.
- 패킷을 받을 대상이 없거나 서비스 불능 상태 - 패킷 전송
- 비신뢰성
- 중간에 패킷이 사라진다면?
- 만약, 인터넷 망의 어떤 중간 노드(서버)가 문제가 생기면, 클라이언트에서 보낸 패킷이 유실되는 문제발생
- 패킷이 순서대로 오지않는다면?
- 패킷의 용량이 매우 클 때, 패킷을 분리해서 보내게 되는데, 이 패킷들이 모두 같은 경로, 즉 같은 노드들을 거쳐서 이동하는 것은 아니기 때문에, 패킷 전달 순서가 보장되지않는 문제가 발생할 수 있다. 즉, 'Hello,world!'라는 문장이 ',world! Hello'가 될 수 있는 것이다.
- 중간에 패킷이 사라진다면?
- 프로그램 구분
- 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면?
03. TCP/UDP
앞선, IP 프로토콜의 한계점을 해결해 주는 것이 바로 TCP 이다.
03-1. 인터넷 프로토콜 스택의 4 계층
애플리케이션 계층 - HTTP, FTP
전송 계층 - TCP, UDP
인터넷 계층 - IP
네트워크 인터페이스 계층
03-2. 프로토콜 계층
채팅 프로그램에서 Hello, world! 라는 메시지를 보내는 상황을 가정한다면, 다음의 순서를 따른다.
- 채팅 프로그램이 Hello, world! 라는 메시지를 생성한다.
- 생성된 메시지를 SOCKET 라이브러리를 통해 OS 계층에 넘긴다.
- OS 계층의 TCP 계층에서 메세지 데이터(Hello, world!)를 포함해 TCP 정보를 생성한다.
- OS 계층의 IP 계층에서 TCP 정보를 포함해 IP 패킷을 생성한다.
- IP 패킷 : (IP 관련정보 + (TCP 관련 정보 + ( 메시지 데이터)))
- TCP 정보가 추가되면서 IP의 한계점이 해결된다.
- TCP 정보 -> 출발지 PORT, 목적지 PORT, 전송 제어, 수서, 검증 정보 등...
- IP 패킷이 LAN 카드를 통해 나갈 때 Ethernet frame 이 포함되어 나간다.
- Ethernet frame -> LAN 카드의 MAC 주소 등 물리적 정보가 포함
03-3. TCP(전송 제어 프로토콜) 특징
- 연결지향 - TCP 3 way handshake(가상연결)
- 먼저 연결을 한 다음 메시지를 보낸다.
- 여기서 말하는 연결은 물리적연결이아닌 논리적연결!
- SYN : 접속 요청 / ACK : 요청 수락
- 1) 클라이언트가 서버에게 접속을 요청하는 SYN을 보냄
- 2) 서버가 SYN을 받았다면 , 서버에서 클라이언트로 접속을 요청하는 SYN과 함께 ACK를 보냄
- 3) 클라이언트가 SYN을 받았으면, 서버로 ACK를 보냄 -> 클라이언트와 서버는 서로 연결되었음을 인식
- 4) 클라이언트가 서버로 데이터를 전송 (요즘은 3번단계에서 ACK와 함께 데이터를 바로 보내기도함)
- SYN : 접속 요청 / ACK : 요청 수락
2. 데이터 전달 보증
- 패킷 손실이 되어 서버가 메시지를 받지 못한 경우, 클라이언트가 알 수 있다.
- 클라이언트가 데이터를 전송하고 서버가 데이터를 받았으면 클라이언트로 응답을 해준다.
3. 순서 보장
- 클라이언트에서 패킷을 보낸 순서대로 서버로 오지 않으면 서버가 클라이언트에 다시 순서대로 패킷이 전송되도록 요청한다.
- 신뢰할 수 있는 프로토콜 -> TCP 정보 안에 전송제어, 순서, 검증정보가 있기 때문
- 현재는 대부분 TCP 사용
03-4. UDP(사용자 데이터그램 프로토콜) 특징
- 3 way handshake X, 데이터 전달 보증 X, 순서 보장 X
- 단순하고 빠르다
- TCP는 데이터 양도 많고 3 way hands 때문에 전송속도가 느린 반면 UDP는 아무것도 없기때문에 상대적으로 전송 속도가 빠르다.
- IP와 거의 유사하다(PORT, checksum 정도만 추가)
- 클라이언트 PC에서 IP가 한 개만 할당되어 있는데, 게임용, 음악용 등 구분하기 위해 PORT를 사용하고 메시지에 대해서 맞는지 검증해주는 체크섬 특징이 있다.
- 애플리케이션에서 추가 작업 필요
04. PORT
클라이언트에서 게임도 하고, 화상통화고하고, 웹 브라우저도 하고 있다면 여러 개의 서버와 통신해야한다. 클라이언트 IP 에서 패킷이 옱텐데 이 패킷이 게임에서 온 패킷인지 화상통화에서 온 패킷인지 웹브라우저에서 온 패킷인지 알 수가 없고 반대로도 마찬가지다. 이런 문제는 어떻게 구분할 수 있을까?
TCP/IP 패킷 정보에 TCP와 UDP에서 출발지 PORT와 목적지 PORT 가 있다. IP는 목적지 서버를 찾는 용도이고 서버 안에서 돌아가는 애플리케이션들을 구분하는 것이 PORT 이다.
- IP -> 목적지 서버를 찾는 용도
- PORT -> 애플리케이션을 구분
위 그림과 같이 같은 IP 내에서 프로세스를 구분하는것이 PORT
- [클라이언트]게임 : 8090 ↔[서버] 게임:11200
- [클라이언트]화상통화 : 21000 ↔[서버] 화상통화 :32202
- [클라이언트]웹 브라우저 : 10010 ↔[서버] 화상통화 :80
다음과 같은 예시처럼 각각 클라이언트와 서버 안에 맞는 PORT 번호를 찾아서 연결하면 된다. 여기서 패킷을 보낼 때 IP 와 PORT를 포함해서 보낸다.
04-1. PORT 번호
- 0 ~ 65535 -> 할당 가능
- 0 ~ 1023 -> 잘 알려진 포트라 사용하지 않는것이 좋음
- FTP : 20, 21 / TELNET : 23 / HTTP: 80 / HTTPS : 443
05. DNS
- IP는 기억하기 어렵다.
- IP는 변경될 수 있다.
- DNS(Domain Name System)
- 도메인 명을 IP 주소로 변환시켜주는 역할
- DNS 사용
[DNS 서버에 도메인 명에 대한 IP 주소를 등록해둔다. ]
- 클라이언트가 DNS 서버에 도메인 명에 대한 IP 를 요청한다.
- DNS 서버는 해당 도메인 명에 대한 IP 주소를 클라이언트에 전달한다.
- 클라이언트는 해당 IP 주소로 서버에 접근한다.
- DNS 를 사용하면 IP 가 기억하기 어렵고, 변경될 수 있는 문제를 해결해준다.
김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 수강하면서 정리한 내용입니다.
'CS > 네트워크' 카테고리의 다른 글
보안 프로토콜 : VPN, IPSec, SSL/TLS (0) | 2024.06.21 |
---|---|
HTTP vs HTTPS 외 프로토콜 종류 (0) | 2024.01.19 |
[모든 개발자를 위한 HTTP 웹 기본지식] 04- Http 메서드 (0) | 2023.10.07 |
[모든 개발자를 위한 HTTP 웹 기본지식] 03- Http 기본 (0) | 2023.10.07 |
[네트워크] 웹풀스택과정 4W_10 _01: Server (0) | 2023.08.08 |