인터넷 통신

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

클라이언트와 서버가 위와 같이 바로 옆에 붙어있는 경우는 케이블로 연결해서 메시지를 주고 받으면 된다. 하지만 현실은 그렇지 않다!

우리는 멀리 떨어져있는 두 컴퓨터끼리 통신할 때, 인터넷을 통해서 통신한다.

복잡한 인터넷 망을 통과하여 클라이언트에서 보낸 메시지가 서버까지 무사히 도착해야한다. 수많은 중간 노드들을 거쳐서 목적지까지 메시지가 무사히 넘어가기 위해서는 어떠한 방법과 규칙으로 넘어가는 것일까?

IP(인터넷 프로토콜)

복잡한 인터넷망을 통해서 서로 멀리 떨어져있는 컴퓨터끼리 통신하기 위해서는 최소한의 규칙이 있어야한다!

그 규칙이 바로 IP(Internet Protocol)이다.

IP 주소 부여

통신을 하려는 두 컴퓨터들은 각각 IP 주소를 부여받아야한다.

IP 역할

• 지정한 IP주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

IP 패킷 정보

클라이언트에서 서버로 메시지를 보낼 때, 그냥 보내는 것이 아니라 IP Packet이라는 형식에 맞추어서 보낸다.

크게 출발지 IP와 목적지 IP를 적어서 패킷을 만든 후 전송한다.

클라이언트 패킷 전달

• 클라이언트가 IP 패킷을 인터넷 상의 노드에 던진다.
• 인터넷 상의 노드(컴퓨터)들은 모두 IP 프로토콜을 따르기 때문에 해당 패킷의 정보(출발지, 목적지)를 이해할 수 있다.
• 중간 노드들은 목적지 노드가 어디있는지 서로 물어가면서 해당 패킷을 전달한다. (라우팅 과정)

서버 패킷 전달

클라이언트와 동일하다.

IP 프로토콜의 한계

비연결성

• 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송

비신뢰성

• 중간에 패킷이 사라지는 경우
• 패킷이 순서대로 오지 않는 경우
• IP 프로토콜을 이용한 전송은 신뢰할 수 없다.

프로그램 구분

• 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
• IP주소는 host주소이다. 따라서 애플리케이션을 구분할 수 없다.

비연결성

• 대상 서버가 서비스 불능 상태인데 패킷을 전송하는 경우
• IP 프로토콜에서 클라이언트는 대상 서버가 패킷을 받을 수 있는 상태인지 모른다.

비신뢰성

패킷 소실 문제

• 인터넷 상의 중간 노드가 갑자기 꺼져버린다든가 하는 문제로 패킷이 유실될 수 있음

패킷 전달 순서 문제

• 전송하려는 패킷의 용량이 매우 큰 경우 (대략 1500Byte 정도가 넘으면 해당 내용을 끊어서 보낸다.)
• 이러한 경우 전송하려는 패킷들의 순서가 중요하다.
• IP프로토콜에서는 하나의 데이터에 연관된 패킷들이 각각 다른 경로로 전송될 수 있다.
• 따라서 도착하는 순서도 보장되지 않는다.

결론 : IP 프로토콜만으로는 이러한 문제들을 해결할 수 없다!

TCP, UDP

IP 프로토콜에서 발생했던 수많은 문제들(패킷의 순서가 꼬이고, 유실되는 등의 문제)을 TCP 프로토콜이 해결해준다!

인터넷 프로토콜 스택의 4계층

프로토콜 계층

• 우리가 사용하는 애플리케이션들이 애플리케이션 층에 존재
• 그 밑에 OS가 있고,
• 그 밑에 네트워크에 직접 접근하는 LAN 드라이버나 LAN 카드같은 네트워크 인터페이스가 있다.

프로그램이 Hello, world! 메시지를 전송하고 싶은 경우

1. 프로그램이 Hello, world! 메시지 생성
2. SOCKET 라이브러리를 통해 OS계층에 메시지 전달
3. TCP는 Hello, world 메시지에 TCP 정보를 씌운다.
4. TCP 밑의 IP 계층으로 메시지를 넘긴다. 받은 메시지 위에 또 IP와 관련된 데이터들을 씌운다. ➡ IP 패킷이 생성됨
5. 생성된 패킷이 랜카드를 통해서 밖으로 나갈 때 이더넷 프레임으로 감싸져서 나감. (이더넷 프레임은 궁금하면 찾아보기!)

TCP/IP 패킷 정보

• IP 패킷안에 TCP 세그먼트가 들어간다.
• TCP 세그먼트에는 TCP와 관련된 정보들이 들어있다.
• 전송제어, 순서, 검증 정보 등이 들어간다. ➡ IP에서 해결이 안되었던 순서 제어문제 등이 해결된다.

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake (가상 연결)
• 데이터 전달 보증 (패킷 소실 문제 해결)
• 순서 보장 (패킷 순서 문제 해결)

• 신뢰할 수 있는 프로토콜
• 현재 대부분 TCP를 사용

TCP 3 way handshake

클라이언트 ➡ 서버, 서버 ➡ 클라이언트 양방향으로 연결 설정함으로써 클라이언트도 서버를 믿을 수 있고, 서버도 클라이언트를 믿을 수 있다.

3 way handshake 과정이 끝나면 두 호스트가 연결된 것이다.
먼저 연결을 한 후, 그 다음에 데이터 전송이 일어난다.
따라서 서버에 문제 있어서 메시지 수신 못하는 경우 애초에 데이터 전송을 하지 않는다.

참고로 요즘에는 최적화가 되어서 마지막 3번 ACK를 보낼 때 데이터를 같이 보낸다.

3 way handshaking을 통한 연결은 물리적인 연결이 아니다!
논리적인 가상 연결임, 두 종단 컴퓨터끼리만 SYN, SYN+ACK, ACK를 주고 받은 후 서로 연결되었다고 알고있는 것이지, 중간의 수많은 노드들은 그 사실을 알지 못한다. 이 연결을 위한 전용 랜선이 보장되는 것이 아니다.

데이터 전달 보증

TCP에서는 데이터 전송할 때, 데이터를 수신하면 이를 잘 수신했다는 확인 응답(ACK)을 해준다. 클라이언트 측에서는 해당 응답을 통해서 송신한 데이터가 잘 전송되었는지 확인할 수 있다.

순서보장

서버측에 도착한 패킷이 순서대로 오지 않았다면 해당 패킷부터 재전송 요청한다. (클라이언트가 보낸 패킷의 SEQ 번호 + 1이 ACK로 오지 않았다면 패킷이 순서대로 도착하지 않은 것임)

이런 것들이 가능한 이유!

TCP 세그먼트 헤더안의 전송제어 정보, 순서, 검증 정보 등을 이용하기 때문에 가능한 것이다. (flag비트, seq number, ack number, checksum 등)

따라서 TCP를 신뢰할 수 있는 프로토콜이라고 함

UDP 특징

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

• 하얀 도화지에 비유 (기능이 거의 없음)
• 연결지향 X - TCP 3way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다.
• 정리
  • IP와 거의 같다. + PORT + 체크섬 정도만 추가
  • 애플리케이션에서 추가 작업 필요

그럼 도대체 UDP를 왜 사용하는 것일까? 되는게 없는 IP랑 같은 꼴인데..

TCP는 3 way handshaking을 통한 연결 설정과정에 시간이 걸린다. 뿐만아니라 신뢰성을 보장하기 위해서 TCP 헤더에 들어가는 검증 정보들을 넣으면 데이터의 크기도 커지고, 전송 속도도 더 빠르게 만들기 힘들다.

➡ 추가로 최적화가 힘들다.

내가 이 이상으로 더 최적화하고 싶다면?

TCP는 더이상 손을 못댄다. 이미 인터넷이 TCP기반으로 사용되기 때문에 건드릴 수 없다. 따라서, TCP는 그대로 두고 UDP를 가지고 최적화 할 수 있다. UDP는 아무런 기능이 없기 때문에 UDP위의 애플리케이션 레벨에서 내가 최적화 기능 만들어내면 된다.

인터넷 HTTP 통신에서 TCP 프로토콜이 거의 90% 이상을 점령했다. 이전에는 신뢰성있는 데이터에만 사용하라고 했지만, 이제는 동영상 같은 실시간 스트리밍이 중요한 데이터에도 TCP를 사용한다.

하지만 UDP가 최근에 다시 각광받고있다. HTTP3 스펙에서는 TCP/IP 연결설정에 들어가는 비용까지 다 줄여보자라고해서 더 최적화를 하려한다. 그러면서 UDP프로토콜을 사용한다.

하지만 당장은 기본적으로 TCP 프로토콜을 사용한다고 이해하면 된다.

PORT

한번에 둘 이상 연결해야하는 경우

IP주소만으로는 여러 개의 프로세스를 구분할 수 없다. IP주소로 목적지 host를 찾고, host 컴퓨터안에서 돌아가는 애플리케이션들을 구분하는 Port번호를 이용하여 애플리케이션을 찾는다.

패킷정보

앞으로는 TCP와 IP를 합쳐서 TCP/IP패킷이라고 부를 것

PORT - 같은 IP내에서 프로세스 구분

패킷 정보에 출발지 IP와 Port도 같이 보내기 때문에 서버는 해당 정보를 보고 클라이언트에게 응답한다.

특징

• 0~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP : 20, 21
  • TElNET : 23
  • HTTP : 80
  • HTTPS : 443

DNS

IP는 기억하기 어렵다

IP는 변경될 수 있다

DNS 사용 (Domain Name System)

• 전화번호부 같은 서버 제공
• 도메인 명을 IP주소로 변환
  
• DNS 서버에 도메인 등록 가능 (도메인은 구매해야한다.)
• 클라이언트는 DNS 서버에 도메인 명으로 IP주소 요청
• DNS 서버는 해당 도메인이 가리키는 IP주소 응답
• 클라이언트는 응답받은 IP주소로 서버에 접근

---

해당 게시글은 김영한님의 <모든 개발자를 위한 HTTP 웹 기본지식> 인프런 강의를 듣고 정리한 내용입니다.