Chapter1. 인터넷 네트워크

Date: 2021.12.26 Updated: 2021.12.26

카테고리: Network

태그: HTTP CS

인프런에 있는 김영한님의 모든 개발자를 위한 HTTP웹 기본 지식 강의를 듣고 정리한 내용입니다.
중간에 등장하는 ppt 내용들은 모두 강의자료를 캡처한 것입니다.

✈️ IP(Internet Protocol)

인터넷은 어떻게 통신할까?

ch1 1

내가 매일 사용하는 youtube를 예로 들어보자. youtube의 본 서버는 어디에 있을까? 궁금해서 방금 찾아보니 전기료가 싸거나, 온도가 낮거나(발열량이 많다고 함)한 여러 나라에 도시만한 데이터 센터들이 있다고 한다. 심지어 유튜브는 거의 모든 나라 통신사에 캐시서버를 가지고 있다고 한다.

ch1 2

아무튼 내 pc를 서버에 다이렉트로 연결하는 것이 가장 확실한 인터넷 통신 방법일 것이다. 하지만 인생은 실전이다. 실제로는 광케이블을 통해 바다를 건너기도 하고, 위성을 통해 지구 반대편에 건너가기도 한다. 이렇듯 여러 중간서버(노드)들을 거쳐 origin 서버에 도착하는 구조이다.

따라서 중간에 길을 잃지 않기 위해서는 내가 원하는 목적지의 정확한 주소가 필요한데 이를 IP주소라고 한다.

IP 역할

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

ch1 3

패킷이란 쉽게 말해 데이터를 택배 박스에 포장하고 송장번호를 붙이는 것이다. IP패킷에는 전송 데이터가 들어있고 그 외에 출발지 IP, 목적지 IP 등의 데이터가 포함되어있다.

IP 프로토콜의 한계

비연결성
비신뢰성
프로그램 구분

비연결성
비연결성이란 내가 데이터를 보낼 서버가 패킷을 받을 수 있는 상태인지, 서비스 불능 상태인지 모르는 상황에서 일단 패킷을 전송한다는 것이다. 가계는 문을 닫았는데 계속 주문 요청을 넣는 꼴이다.

비신뢰성
비신뢰성이란 내가 보낸 데이터가 정삭적으로 잘 도착하는지에 대한 확신이 없다는 것이다. 예를 들어 내 통장에서 돈이 빠져나갔는데 중간에 데이터가 소실되어 상대방에게 돈이 가지 않는 대참사가 발생할 수 있다. 또한 데이터의 양이 많은 경우 여러개의 패킷에 나누어 보내는데 이때에도 문제가 발생할 수 있다. 예를 들어 서버에서 데이터를 패킷1, 패킷2, 패킷3의 순서로 나누어 보냈는데 내가 패킷1, 패킷3, 패킷2의 순서로 받은 경우이다. (패킷들이 서로 다른 노드들을 타고 올 수 있다.) 패킷1, 패킷3, 패킷2의 순서로 렌더링한 결과는 완전히 망가진 데이터이기 때문에 문제가 발생한다.

프로그램 구분
만약 내가 유튜브로 노래를 들으면서 웹 브라우저를 사용하고 있다고 가정하자. 웹 브라우저 서버가 보낸 데이터가 내 IP주소로 잘 도착 했지만, 이 데이터는 웹 브라우저 애플리케이션으로 가야할지, 노래 애플리케이션으로 가야할지 모르는 문제가 발생한다.

✈️ TCP, UDP

위에서 언급한 IP 프로토콜의 한계를 극복하기 위해 TCP(Transmission Control Protocol) - 전송 제어 프로토콜 개념이 생겨났다.

TCP 특징

연결지향 : TCP 3 way handshake
데이터 전달 보증
순서 보장
프로그램 구분

ch1 5

TCP 3 way handshake란 데이터를 전송하기 전에 서버가 정상적으로 작동하는지 확인을 하는 것이다. 데이터를 보내는 클라이언트가 먼저 접속 요청(SYN)을 보내면 서버가 요청을 수락(ACK)하는 동시에 클라이언트에게 접속 요청(SYN)한다. 그럼 다시 클라이언트가 서버에게 요청 수락(ACK)을 보내고 이제 클라이언트가 서버와 연결되었다는 것을 확신할 수 있다. 이렇듯 3번 핑퐁하기 때문에 3 way handshake라고 하나 보다.

데이터 전달 보장
TCP/IP 패킷의 경우 데이터를 전송받으면 잘 받았다는 응답 메시지를 다시 보내준다. 따라서 중간에 패킷이 유실되었는지 잘 도착했는지 확인할 수 있다.

순서 보장
만약 클라이언트가 패킷1, 패킷2, 패킷3 순서로 전송했는데 서버가 패킷1, 패킷3, 패킷2 순서로 받았다고 해보자. TCP 패킷에는 순서 정보가 들어있으므로 서버는 순서를 잘못 받았다는 것을 알 수 있고, 클라이언트에게 패킷2 부터 다시 보내라는 요청을 하게 된다.

프로그램 구분
하나의 IP 내에서 애플리케이션들을 구분하기 위해 PORT라는 개념이 존재한다. 비유하자면 IP는 몇 동인지, PORT는 몇 호인지를 나타낸다고 할 수 있다. 자주 사용하는 몇 개의 PORT를 제외하고는 자유롭게 할당이 가능하다. ( 0 ~ 65535 : 할당 가능, 0 ~ 1023 : 잘 알려진 포트라 쓰지 않는 것을 추천)

인터넷 프로토콜 계층

ch1 4

지금까지의 내용을 잠깐 정리해보면, 내가 서버에 보내고 싶은 데이터가 있을 때 데이터 위에 부가적인 세팅이 필요하다. 우선 애플리케이션 단계에서 한 번 포장을 하고(ex.SOCKET), OS 단계에서 두 번(TCP, IP), 하드웨어 단계에서 마지막 포장을 한다. 이런 복잡한 작업들이 끝나고 나면 신뢰할 수 있는 프로토콜이 만들어진다. (생각보다 복잡해서 살짝 놀랐다. 역시 세상에 공짜는 없나보다.)

우리가 배운 TCP 세그먼트에는 PORT 정보, 전송 제어, 순서, 검증 정보… 등의 정보들이 담겨있다. (IP 패킷 안에 들어있어서 TCP 세그먼트라 하나 보다.)

UDP

패킷이 조금 무거워 보인다.
“완벽하지 않아도 좋으니까 나는 가볍고 빠른 통신을 원해!” 하는 사람들을 위해 TCP 대신 사용할 수 있는 UDP가 존재한다.

UDP(User Datagram Protocol) - 사용자 데이터그램 프로토콜 UDP의 특징은 PORT와 체크섬(중복체크) 정도의 기능만 포함하고 있다. 따라서 애플리케이션 단계에서 추가적인 작업이 필요하지만 3 way handshake 같은 번거로운 절차도 필요 없고, TCP보다 가볍다. 하얀 도화지 위에 내가 원하는 기능을 추가하면 되는 것이다.

✈️ DNS

Domain Name System란 IP 대신 도메인 주소를 사용하는 시스템이다. 구글에 접속할 때 도메인 주소(google.com)가 아닌 뭔지도 모를 구글의 IP로 접속한다고 생각해보라. 아주 고마운 시스템이다. 뿐만 아니라 구글 회사가 이전했다고 가정해보자. 바뀐게 하나도 없는데 IP 주소가 변경되어 시스템을 뜯어 고쳐야 하는 상황이 발생할 수 있다. 따라서 변경될 수 있는 IP 주소가 아닌 도메인 주소를 사용하는 것이 합리적이다.

ch1 6

그림과 같이 서버와 통신하기 전에 DNS 서버에서 IP 주소를 받아오는 식이다.

맨 위로 이동하기

등딱지빌런