HTTP 웹 기본 지식 - 인터넷 네트워크

"인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 작성한 글입니다."

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

HTTP 강의인데 인터넷 네트워크 부터 알아보는 이유? 

결국 웹이나 HTTP 들 모두 인터넷 네트워크 망에 기반해서 동작을 하기 때문에 HTTP 학습을 위해 사전에 기본학습을 해야한다.

 

인터넷 통신

인터넷 상에서 컴퓨터들은 어떻게 통신할까?

인터넷 망들은 절대 단순하지 읺고, 굉장히 복잡하다. 도대체 컴퓨터들은 어떻게 이 복잡한 인터넷 망을 뚫고 정확히 서로에게 통신을 할 수 있을까?

 

인터넷 프로토콜(IP)

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

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

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

- 지정한 IP 주소(IP Address) 에 데이터 전달

- 패킷(Packet) 이라는 통신 단위로 데이터 전달

 

이때 메시지를 그냥 보내는 것이 아니라 IP 패킷이라는 규칙에 맞춰서 보내게 된다.

여기서 IP 패킷의 구성은 다음과 같다.

- 출발지 IP, 목적지 IP, 전송하고자 하는 데이터, 그외 기타 요소 등

위와 같은 구성으로 IP 패킷을 만든 다음, 인터넷 망을 통해 해당 패킷을 전달하기 시작한다.

이때 전달된 IP 패킷에 적혀있는 출발지 IP, 목적지 IP 정보를 보고 IP 프로토콜을 따르고 있는 인터넷 망의 서버들이 현재 전달되고 있는 패킷의 출발지와 도착지를 알게 된다.

이를 통해 인터넷 망 내부에 있는 각 노드끼리 해당 IP 패킷을 주고받다 보면 어느새 전달하고자 했던 목적지에 해당 패킷이 도착하게 된다.

 

그럼 이렇게 전달된 패킷이 잘 전달된 것을 알려주기 위해 OK 메시지를 출발지로 다시 전달해준다면, 기존에 IP 패킷이 전달되었던 과정과 똑같은 방식으로 해당 패킷이 전달된다.

물론 이때 주고 받으면서 거쳐간 노드들은 패킷을 처음 전달할 때와 다시 돌려 받을 때가 서로 다를 수 있다.

(그만큼 인터넷 망이 복잡하다.)

 

 

IP 프로토콜의 한계

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

- 비연결성 : 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷이 전공된다.(처음 패킷을 전달하는 곳에서는 도착 지점의 서버가 패킷을 받을 수 있는 상태인지 아닌지 알 수 없다.)

- 비신뢰성 : 중간에 패킷이 사라지거나 패킷이 순서대로 오지 않을 수도 있다.

(중간에 패킷이 사라져도 처음 패킷을 전달해준 입장에서는 현재 패킷이 사라진 것에 대한 여부를 알 수 없다.)

(처음엔 순서대로 전달되던 패킷들이 인터넷 망을 통해 통신되는 과정에서 무수히 많은 노드를 거쳐가게 되는데, 패킷들이 어떤 노드를 거쳐가느냐에 따라 패킷의 도착 순서가 달라질 수 있다.)

- 프로그램 구분 : 같은 IP 를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우 이를 구분하는데 한계가 있다.

 

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

 

 

TCP 와 UDP

* 인터넷 프로토콜엔 다음과 같은 4계층의 스택이 존재한다.

- 애플리케이션 계층 : HTTP, FTP

- 전송 계층 : TCP, UDP

- 인터넷 계층 : IP

- 네트워크 인터페이스 계층

 

프로토콜 계층의 전체 구조는 대략적으로 다음과 같다.

만약 채팅 프로그램으로 서로 통신을 하고 싶다고 가정해보자.

1. 프로그램을 통해 전달하고자 하는 메시지를 생성하고 socket 라이브러리를 통해서 OS 계층에 전달하고자 하는 데이터를 넘긴다.

2. OS 계층에서 TCP 계층의 경우 전달되는 정보에 TCP 정보를 생성하고, 이후 IP 계층에서는 해당 정보에 IP 와 관련된 정보를 생성시킴 으로서 IP 패킷을 생성한다.

3. 이 IP 패킷은 결국 내부에 IP 와 관련된 정보, TCP 와 관련된 정보, 그리고 실제 생성해서 전달하고자 했던 메시지가 포함되어 있다.

4. 이 데이터들이 LAN 카드를 통해서 전달될 때, 이더넷 프레임(Ethernet frame) 이 포함되서 전달된다.

(여기서 이더넷 프레임에는 맥 주소와 같은 것들이 해당된다.)

 

여기서 OS 계층에서 생성되어 패킷에 포함되는 TCP, IP 정보를 통해 만들어진 TCP/IP 패킷 정보는 다음과 같은 구성으로 이루어진다.

* 포함된 TCP 정보

- 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보

여기서 전송 제어, 순서, 검증 정보와 관련된 데이터들 덕분에 IP 프로토콜 만으로 통신했을 때 해결이 불가능했던 문제들이 해결되게 된다. 

 

* TCP 특징 : 전송 제어 프로토콜(Transmission Control Protocol)

- 연결 지향 : TCP 3 way handshake(가상 연결) :

두 기기간의 연결이 정상적으로 되어 있는지 검증한다. 이 덕분에 IP 프로토콜에서의 비연결성 문제가 해결된다.

- 데이터 전달 보증 :

패킷을 보냈는데 중간에 데이터가 누락된 경우, 이를 데이터 출발점에서 알 수 있게 된다.

- 순서 보장 :

인터넷 망의 노드 구조가 복잡함에도 불구하고 전송되는 데이터 패킷의 전달 순서를 보장해준다.

 

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

 

* TCP 3 way handshake

TCP/IP 프로토콜로 기기간의 연결을 할 경우 다음과 같은 과정을 거치게 된다.

1. 클라이언트에서 서버로 접속 요청(SYN - Synchronize) 라는 메시지를 보낸다(SYN 전달)

2. 위의 메시지를 전달받았을 경우 접속 요청 수락(ACK - Acknowledge) 메시지와 함께 서버측에서도 접속 요청(SYN) 메시지를 클라이언트에게 보낸다.(SYN + ACK 전달)

3. 클라이언트가 서버 측으로부터 접속 요청 수락 메시지와 함께 접속 요청 메시지를 받았을 경우, 서버측의 접속 요청을 수락하는 메시지(ACK) 를 전달하게 된다.(ACK 전달)

- SYN : 접속 요청

- ACK : 요청 수락

+ 참고 : ACK 와 함께 데이터(메시지)를 전송해주는 것이 가능하다.

 

위와 같은 연결과정을 거치고 나면 최종적으로 클라이언트와 서버가 정상적으로 연결되고, 그 이후에 데이터를 전송하게 된다.

그런데 여기서 중요한 건 TCP 3 way handshake 는 클라이언트와 서버간에 진짜로 연결된 것이 아니다. 개념적으로만 연결된 것이다. (물리적으로 연결되지 않았다. - 가상 연결)

실제로는 클라이언트와 서버 간에 있는 인터넷 망에서 수많은 노드들이 있는데, 그 노드들은 클라이언트와 서버가 연결이 되어있는지 여부를 알 수 없다.(그냥 연결이 되었다고 생각하자, 정도 수준의 논리적 연결이다.)

 

* 데이터 전달 보증

- TCP/IP 프로토콜로 기기간의 연결을 할 경우 서버측에서 클라이언트에게 데이터를 전송 받으면, 해당 데이터를 잘 받았다는 메시지를 클라이언트 측으로 전달해준다.

이를 통해 클라이언트는 데이터가 서버에 잘 전달 되었는지, 그렇지 않은지 알 수 있게 된다.

 

* 순서 보장

- TCP/IP 프로토콜로 기기간의 연결을 할 경우 서버측에서 전달받은 패킷의 순서가 기존과는 다를때, 순서가 잘못된 패킷 부터는 모두 버리고, 해당 패킷부터 다시 전달하라고 클라이언트에게 요청한다. 이를 통해 클라이언트 측은 특정 패킷에서부터 순서대로 전달되지 않았다는 것을 알게 되고, 이를 통해 잘못된 순서로 도착한 패킷에서 부터 다시 서버로 패킷을 전달해주게 된다.

이와 같은 과정을 통해 전달되는 패킷들의 순서가 보장되게 된다.

 

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

 

* UDP 특징 : 사용자 데이터그램 프로토콜(User Datagram Protocol)

- 하얀 도화지에 비유될 정도로 기능이 거의 없다.

- 연결 지향적이지 않다(TCP 3 way handshake X)

- 데이터의 전달이 보증되지 않고, 순서 또한 보장되지 않는다.

- 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다.

정리 :

- IP 와 거의 같다. PORT, 체크섬 정도만 추가되어 있다.

- 애플리케이션에서 추가 작업이 필요하다.

 

여기서 PORT 의 역할은 하나의 IP 에서 여러 애플리케이션을 실행할 때 각각의 애플리케이션을 통해 인터넷 망에서 데이터를 주고 받을 경우, 각 패킷이 어느 애플리케이션과 통신하고 있는지 명확하게 구분하는 것이다.

 

* 그렇다면 UDP 는 IP 프로토콜과 크게 다를바가 없는데 왜 UDP 를 사용할까?

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

 

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

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

 

 

PORT 와 DNS

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

* 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

 

* DNS(Doman Name System)

DNS 에 대해서도 간단하게 알아보자.

지금까지는 IP 주소를 통해 통신하는 것을 알아보았다. 그런데 이런 방식으로 통신을 할 때의 문제점이 IP 주소의 경우 쉽게 기억하기 어렵다는 것이다.

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

 

이런 문제를 해소해줄 수 있는것이 DNS 이다.

DNS 는 IP 주소에 대해 일종의 전화번호부 역할을 하며(또는 별명), 도메인 명을 IP 주소로 변환해줄 수 있다.

DNS 서버에 도메인 명을 등록할 수 있는데, 이때 해당 도메인에 할당시킬 IP 주소를 지정해 줄 수 있다.

이를 통해 도메인 명을 통해 접속하는 것만으로 DNS 서버에 해당 도메인 명으로 저장된 IP 주소를 통해 연결을 원하는 서버를 찾아갈 수 있는것이다.

그 결과 IP 주소를 기억하기 어려운 문제와, IP 주소가 변경될 문제 둘 다 해결이 가능하다.