WEB CS 기초 - section 1 인터넷 네트워크

* 해당 글은 멋사 부트캠프 CS 기초 추가강의 내용 정리글입니다.

https://bootcamp.likelion.net/school/kdt-backendj-21th

백엔드 부트캠프 21기: Java : 멋사 부트캠프

 

인터넷에서 데이터가 전달되는 과정?

Client -Server 간에서 클라이언트에서 보내는 메세지는 한번에 서버 측으로 보내지지 않는다. 그 과정에서 굉장히 많은 각종 네트워크 디바이스들이 존재하여 요청 경로에 있는 서버에 도착하기 까지 많은 네트워크 노드를 통과해야 하기 때문이다.

도대체 컴퓨터들은 어떻게 이 복잡한 인터넷 망을 뚫고 정확히 서로에게 통신을 할 수 있을까?

 

IP (Internet Protocol)

복잡한 인터넷 망에서 통신을 정상적으로 주고 받으려면 최소한의 규칙이 있어야 한다.

그래서 IP 주소라는 것을 통해 서로 통신하는 것이 가능하다. 이때 통신하려는 두 컴퓨터 모두 IP 주소를 가지고 있어야 한다.

* IP 인터넷 프로토콜의 역할

• 1. 지정한 IP 주소(IP Address) 에 데이터 전달
• 2. 패킷(Packet) 이라는 통신 단위로 데이터 전달
  • 이때 메세지를 그냥 보내는 것이 아니라 IP 패킷이라는 규칙에 맞춰서 보내게 된다.
  • IP 패킷의 구성 : 출발지 IP, 목적지 IP, 전송하고자 하는 데이터, 그외 기타요소 등등
  • 전달되는 IP 패킷에 적혀있는 출발지, 목적지 IP 정보를 보고 IP 프로토콜을 따르고 있는 인터넷 망의 서버들이 현재 전달되고 있는 패킷의 출발지와 도착지를 알게된다.
  • 이를 통해 인터넷 망 내부에 있는 각 노드끼리 해당 IP 패킷을 주고받다 보면 어느새 전달하고자 했던 목적지에 해당 패킷이 도착하게 된다. 

IP 프로토콜의 한계

하지만 이렇게 IP 프로토콜만으로 통신을 주고받는 방식에는 한계가 있다.

• 비 연결성 : 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷이 전송된다
  • 처음 패킷을 전달하는 클라이언트에서는 도착 지점의 서버가 패킷을 받을 수 있는 상태인지 아닌지 알 수 없다.
• 비 신뢰성 : 중간에 패킷이 사라지거나 패킷이 순서대로 오지 않을수도 있다.
  • 중간에 패킷이 사라져도 처음 패킷을 전달해준 클라이언트 입장에서는 현재 패킷이 사라진것에 대한 여부를 알 수 없다.
  • 처음엔 순서대로 전달되던 패킷들이 인터넷 망을 통해 통신되는 과정에서 무수히 많은 노드를 거쳐가게 되는데, 패킷들이 어떤 노드를 거쳐가느냐에 따라 패킷의 도착 순서가 달라질 수 있다.
• 프로그램 구분 : 같은 IP 를 사용하는 서버에서 통신하는 어플리케이션이 둘 이상일 경우 이를 구분하는데 한계가 있다.

이렇게 IP 프로토콜 만으로 통신을 주고받을 경우 겪을 수 있는 한계점을 해결해주는 것이 바로 TCP 프로토콜이다.

TCP 와 UDP

인터넷 프로토콜엔 다음과 같은 4계층이 존재한다. 구체적으로 통신과정이 어떻게 되는지도 한번 확인해보자.

(채팅 프로그램으로 서로 통신을 하는 경우)

• 어플리케이션 계층 : HTTP, FTP
  • 프로그램을 통해 전달하고자 하는 메세지를 생성하고 socket 라이브러리를 통해서 OS 계층(전송계층)에 전달하고자 하는 데이터를 넘긴다.
• 전송 계층 : TCP, UDP
  • OS 계층에서 TCP 계층의 경우 전달되는 정보에 TCP 정보를 생성한다.
• 인터넷 계층 : IP
  • 전송 계층에서 생성된 TCP 정보에 IP 와 관련된 정보를 생성시킴으로서 IP 패킷을 생성한다.
  • 이 IP 패킷에서는 결국 내부에 IP 와 관련된 정보, TCP 와 관련된 정보, 그리고 실제 생성해서 전달하고자 했던 메세지가 포함되게 된다.
  • TCP/IP 패킷정보 구성 : 출발지 PORT 번호, 목적지 PORT 번호, 전송 제어, 순서, 검증 정보 -> 여기서 전송 제어, 순서, 검증 정보와 관련된 데이터들 덕분에 IP 프로토콜 만으로 통신했을 때 해결이 불가능했던 문제들이 해결되게 된다.
• 네트워크 인터페이스 계층 
  • 위의 계층에서 만들어진 데이터들이 LAN 카드를 통해서 전달될 때 이더넷 프레임(Ethernet frame) 이 포함되서 전달된다.
  • 여기서 이더넷 프레임에는 맥 주소(물리 주소)와 같은 것들이 해당된다. 

TCP(Transmission Control Protocol) 의 특징

• 연결 지향 : TCP 3 way handshake (가상 연결)
  • 두 기기간의 연결이 정상적으로 되어 있는지 검증한다. 이 덕분에 IP 프로토콜에서의 비 연결성 문제가 해결된다.
  • 3 way handshake 의 간략한 과정
    1. 클라이언트에서 서버로 접속 요청 메세지 전달(SYN : Synchronize)
    2. 서버측에서 메세지를 전달받았을 경우 접속 요청 수락(ACK : Acknowledge) 메세지와 함께 서버측에서도 접속 요청 메세지를 클라이언트에게 전달(SYN + ACK 전달)
    3. 클라이언트가 서버측으로부터 접속 요청 수락메세지와 함께 접속 요청 메세지를 받았을 경우, 서버측의 접속 요청을 수락하는 메세지(ACK) 를 전달하게 된다.(ACK 전달)
    4. SYN -> 접속 요청, ACK : 요청 수락 (ACK 와 함께 데이터(메세지) 를 전송해주는 것도 가능하다)
  • 위와 같은 연결과정을 거치고 나면 최종적으로 클라이언트와 서버가 정상적으로 연결되고, 그 이후에 데이터를 전송하게 된다.
  • 그런데 여기서 중요한건 TCP 3 way handshake 는 클라이언트와 서버간에 진짜로 연결된 것이 아니라 개념적으로만 연결된 것이다.(물리적으로 연결된 것이 아님, 가상 연결)
  • 실제로는 클라이언트와 서버간에 있는 인터넷 망에서 수많은 노드들이 있는데, 그 노드들은 클라이언트와 서버가 연결이 되어있는지 여부를 알 수 없다.(그냥 연결이 되었다고 생각하자 정도 수준의 논리적 연결)
• 데이터 전달 보증 : 패킷을 보냈는데 중간에 데이터가 누락된 경우, 이를 데이터 출발점에서 알 수 있게된다.
  • TCP/IP 프로토콜로 기기간의 연결을 할 경우 서버측에서 클라이언트에게 데이터를 전송 받으면, 해당 데이터를 잘 받았다는 메세지를 클라이언트 측으로 전달해준다.
  • 이를 통해 클라이언트는 데이터가 서버에 잘 전달 되었는지, 그렇지 않은지 알 수 있게된다.
• 순서 보장 : 인터넷 망의 노드 구조가 복잡함에도 불구하고 전송되는 데이터 패킷의 전달 순서를 보장해준다.
  • TCP/IP 프로토콜로 기기간의 연결을 할 경우 서버 측에서 전달받은 패킷의 순서가 기존과는 다를때, 순서가 잘못된 패킷 부터는 모두 버리고 해당 패킷부터 다시 전달하라고 클라이언트에게 요청한다.
  • 이를 통해 클라이언트 측은 특정 패킷에서부터 순서대로 전달되지 않았다는 것을 알게되고, 이를 통해 잘못된 순서로 도착한 패킷에서부터 다시 서버로 패킷을 전달해주게 된다.
  • 이와 같은 과정을 통해 전달되는 패킷들의 순서가 보장되게 된다.

물론 위와 같은 것들이 그냥 되는것이 아니라, 패킷 내부에 포함되어 있느 전송 제어, 순서, 검증 정보와 같은 데이터들 덕분에 IP 프로토콜만으로 통신할 때와는 달리 신뢰성 있는 통신이 가능해지는 것이다.

위와 같은 특징들로 인해 TCP 는 신뢰할 수 있는 프로토콜이며, 현재는 대부분 TCP 를 사용하고 있다.

 

UDP(User Datagram Protocol) 의 특징

• 기능이 거의 없으며 연결 지향적이지 않다.(TCP 3 way handshake X)
• TCP 와는 달리 데이터의 전달이 보증되지 않고 순서 또한 보증되지 않는다. 그러나 단순하고 빠르다.
• IP 와 거의 비슷하다, PORT 번호와 체크섬(오류 확인용) 정도만 추가되어 있으며 어플리케이션에서의 추가 작업이 필요하다.
• UDP 는 방송, 동영상 등 스트리밍 서비스에 자주 쓰인다. 

그렇다면 왜 UDP 를 사용하는가?

TCP 는 몇가지 단점을 가지고 있다.

• TCP 3 way handshake 를 하려면 시간이 조금 걸린다. 
• 전송하고자하는 패킷에 대한 TCP 정보, IP 정보, 이더넷 프레임 정보들이 모두 포함되면 자연스레 한번에 전달되게 되는 패킷 정보의 크기가 커질뿐더러, 그에 따라 전송 속도도 더 빠르게 만들기 어렵다.

위와 같은 단점들을 보완하고 싶어서 최적화를 하고 싶어도 할 수가없다. TCP 는 이미 추가적으로 손을 대기 힘들다. 인터넷은 이미 TCP 를 기반으로 통신하고 있기 때문이다.

그럼에도 불구하고 더 최적화를 하고 싶다면 TCP 는 내버려두고 UDP 를 활용하면 된다. UDP 는 사실상 아무것도 없기 때문에 그 위에서 원하는 걸 어플리케이션 레벨에서 만들어내면 된다.

 

PORT (포트 번호)

만약 한 클라이언트에서 여러 서버와 연결해야 한다면 어떨까?

IP 프로토콜 만으로 통신한다면 여러 서버와 연결된 상태에서 어떤 데이터 패킷이 왔을 때, 이게 어느 서버에서 온 패킷인지 확인할 수 있는 방법이 없다.

그럼 이걸 어떻게 구분할 수 있을까?

• TCP/IP 패킷 정보에는 (UDP도 마찬가지) 출발지 PORT 와 목적지 PORT 정보가 존재한다.
• 내부에 출발지 PORT 정보와 목적지 PORT 정보가 존재하기 때문에 IP 정보를 통해서 클라이언트와 서버간에 데이터 패킷을 주고받을 때 특정 프로세스 또는 어플리케이션에 전송되어야 하는 데이터가 정확하게 전달될 수 있다.
• IP 는 목적지 서버를 찾는것이고, 서버 안에서 돌아가는 어플리케이션들을 구분하는 것이 PORT 라고 이해하면 된다.

PORT 번호는 다음과 같이 프로세스에 할당 가능하다.

• 0 ~ 65535 : 할당 가능
• 0 ~ 1023 : 잘 알려진 포트(well known port), 사용하지 않는것이 좋다. 
  • 기존 시스템 상 이미 사용되어 지고 있는 포트번호들이다.
• FTP : 20, 21
• TELNET : 23
• HTTP : 80
• HTTPS : 443
  • HTTPS와 HTTP 는 SSL 인증서를 통해 보안 인가를 받은 안전한 통신 경로인가 그렇지 않은가에 따라 나뉜다.

 

DNS(Domain Name Server)

클라이언트와 서버간에는 IP 주소를 통해 통신이 가능하다. 그러나 이런 방식으로 통신을 할 경우 IP 주소가 사람이 쉽게 기억하기 힘든 구조라는 단점이 존재한다.

거기다 IP 주소는 한번 결정되면 다른 값으로 바꿀수 없지는 않기 때문에 계속 하나의 주소값을 가지는 것이 아니라 나중에 변경될 수도 있다.

이러한 문제를 해결해줄 수 있는것이 바로 DNS 이다.

• DNS 는 IP 주소에 대해 일종의 전화번호부 역할을 하며(또는 별명), 도메인 명을 IP 주소로 변환해줄 수 있다.
• DNS 서버에 도메인 명을 등록할 수 있는데, 이때 해당 도메인에 할당시킬 IP 주소를 지정해줄 수 있다.
• 이를 통해 도메인 명을 통해 접속하는 것만으로 DNS 서버에 해당 도메인 명으로 저장된 IP 주소를 통해 연결을 원하는 서버를 찾아갈 수 있는것이다.
• 그 결과 IP 주소를 기억하기 어려운 문제와, IP 주소가 변경될 문제 둘 다 해결이 가능하게 된다.