[네트워크] IP와 TCP/UDP, TCP/IP 정리
IP(인터넷 프로토콜)
클라이언트와 서버 사이에 존재하는 인터넷은 수많은 노드로 이루어져 있는데, 이러한 노드들을 지나 정확하게 서버에 도착할 수 있도록 하는 것이 바로 IP이다.
- 클라이언트와 서버 각각에 IP주소(100.100.100.1 / 200.200.200.1)를 부여하고 패킷(출발지 IP, 도착지 IP, 전송할 데이터 등이 담겨져 있다) 단위로 데이터를 전달한다.
- 노드끼리 패킷을 전달하며 서버까지 도착하게 된다.
- 서버는 패킷이 도착하면 데이터를 받았다는 통신(패킷)을 다시 클라이언트에게 전달해준다. 이때 2번에서 거쳐간 노드와는 다른 경로로 데이터가 전달될 수 있다(인터넷 망은 복잡하므로)
- 한계
- 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송함 → 서버는 당연히 패킷을 받지 못함
- 비신뢰성: 패킷이 소실되어도 모름, 여러 개의 패킷을 보낸 경우 패킷이 순서대로 오지 않을 수도 있음
- 프로그램 구분: 같은 IP를 사용하는 서버에서 둘 이상의 애플리케이션이 통신되고 있는 경우? → 이를 어떻게 구분할 것인가! =⇒ TCP가 그 해답이 된다!
TCP / UDP: 데이터를 보내기 위해 사용하는 프로토콜
TCP(Transmission Control Protocol, 전송제어 프로토콜)
- 출발지, 목적지에 대한 PORT, 전송 제어, 순서, 검증 정보등이 포함됨
- IP가 아파트라고 한다면 PORT는 상세주소(몇 동 몇 호)
- 위에서 언급한 IP 프로토콜의 문제점(비연결성, 비신뢰성, 프로그램 구분)을 해결할 수 있다. → IP와 TCP를 합쳐 대개 TCP/IP라고 함
- 연결형 서비스로 가상 회선 방식을 제공한다.
- 흐름 제어 및 혼잡 제어
- 흐름제어 (Flow Control)
- 데이터를 송신하는 곳과 수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지
- 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실 될 수 있고 그렇게 되면 불필요한 응답과 데이터 전송이 발생하게 됨
- 해결방법
- Stop and Wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
- Sliding Window (Go Back N ARQ): 수신측에서 설정한 윈도우 크기만큼 발신측에서 확인응답없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법
- 혼잡제어 (Congestion Control)
- 네트워크의 혼잡을 피하기 위해 발신측에서 보내는 데이터의 전송속도를 강제로 줄이는 작업(네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지)
- 혼잡: 네트워크 내에 패킷의 수가 과도하게 증가하는 현상
- 혼잡제어: 혼잡 현상을 방지하거나 제거하는 기능
- 해결 방법
- AIMD(Additive Increase / Multiplicative Decrease): 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법
- 흐름제어 (Flow Control)
- 높은 신뢰성을 보장한다.
- Dupack-based retransmission
- 정상적인 상황에서는 ACK 값이 연속적으로 전송되어야 한다.
- 그러나 ACK값이 중복으로 올 경우 패킷 이상을 감지하고 재전송을 요청한다.
- Timeout-based retransmission
- 일정시간동안 ACK 값이 수신을 못할 경우 재전송을 요청한다.
- Dupack-based retransmission
- UDP보다 속도가 느리다.
- TCP는 신뢰성 확보를 위해서 매번 데이터의 순서를 추적하고 응답을 추적하면서 추가적인 데이터를 전송하고 또한 이런 데이터가 오기를 기다리기 때문에
- 전이중(Full-Duplex), 점대점(Point to Point) 방식
- 전이중(Full-Duplex): 전송이 양방향으로 동시에 일어날 수 있다.
- 점대점(Point to Point): 각 연결이 정확히 2개의 종단점을 가지고 있다.
- 파일 전송과 같은 경우에 사용
- 서버와 클라이언트는 1대1로 연결
- 스트리밍 서비스에 불리하다. (손실된 경우 재전송 요청을 하므로)
- 3-way handshake과정을 통해 연결을 설정하고 4-way handshake를 통해 해제
- 3-way handshake: 실제로 연결된 것은 아니고, 메시지를 주고 받았으니 연결이 됐나보다~라고 생각함(논리적으로 연결 O, 물리적으로 연결 X)
1. SYN(seq=x): 이라는 메시지를 보냄(연결해달라는 메시지)
2. ACK(x+1) + SYN(seq=y): OK라는 메시지를 보내면서 SYN → 나도 연결해달라고 보냄
3. ACK(y+1): OK라는 메시지를 보냄
데이터 전송: 연결을 하고 난 후에 데이터를 전송
SYN(synchronize): 접속 요청 / ACK(acknowledge): 요청 수락
참고: 3. ACK와 함께 데이터 전송 가능 → 요즘엔 최적화가 되어있어서 3. ACK를 보낼 때 같이 데이터도 전송
- 4-way handshake
1. FIN: 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그 전송
2. FIN + ACK: 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다. (이때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다)
3. FIN: 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
4. ACK: 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다. (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다.)
FIN (finish) : 세션을 종료시키는데 사용되며, 더 이상 보낸 데이터가 없음을 나타낸다.
서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
TIME_WAIT 시간이 끝나면 클라이언트도 닫는다 (Closed)
UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)
- PORT + 체크섬(메시지가 제대로 맞는지 검증해주는 데이터) 정도만 추가
- 데이터를 데이터그램(메시지) 단위로 처리하는 프로토콜이다.
- 비연결형, 신뢰성 없는 전송 프로토콜
- 정보를 주고 받을 때 정보를 보내거나 받는다는 신호절차를 거치지 않는다.(연결을 설정하고 해제하는 과정이 존재 X)
- 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송 X → 패킷이 제대로 전송 되었는지, 오류는 없는지 확인 X
- 포트들을 사용하여 IP 프로토콜에 인터페이스 제공
- 서버 소켓과 클라이언트 소켓의 구분이 없다.
- 소켓 대신 IP를 기반으로 데이터를 전송한다.
- 서버와 클라이언트는 1대1, 1대N, N대M 등으로 연결
- 예시
- DNS도메인 네임 시스템(Domain Name System, DNS)
- 도메인 명을 IP 주소로 변환(도메인을 사서 DNS 서버에 등록)
- ex. xxx.xxx.x.x의 IP주소를 google.com으로 이름을 설정하여 google.com을 입력하는 것 만으로도 자동으로 xxx.xxx.x.x의 IP로 이동하게 됨
- IP는 기억하기 어렵다. + IP는 변경될 수 있다.는 문제 모두 해결
- 어떤 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은 DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.
- 도메인 명을 IP 주소로 변환(도메인을 사서 DNS 서버에 등록)
- 실시간 서비스(streaming)
- 신뢰성보다는 연속성, 성능이 중요한 서비스에 주로 쓰임
- DNS도메인 네임 시스템(Domain Name System, DNS)
출처
https://www.inflearn.com/course/http-웹-네트워크/dashboard
https://mangkyu.tistory.com/15
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/
https://github.com/gyoogle/tech-interview-for-developer
https://gpgstudy.com/forum/viewtopic.php?t=24143