TCP/IP

0. 패킷 통신 규약 중 가장 보편적으로 쓰이는  TCP/IP

패킷 통신이 무엇인지, 패킷통신의 배경은 해당 링크를 참고! 

1. TCP/IP는 프로토콜의 집합이다.

 그렇다면, 프로토콜은 뭐지? 프로토콜은 규칙 및 약속이라고 생각하면 된다. 만약 우리가 다른 나라사람과 대화를 해야한다면, 우리는 언어가 다르기 때문에 소통의 어려움이 있을 수 있다. 때문에 어떻게 대화를 시작할지, 어떤 언어로 대화를 할지, 언제 대화를 끝낼지와 같은 약속이 필요하다. 이를 다시 네트워크로 빗대어 보면 다른 OS와 컴퓨터, 네트워크 기기가 서로 어떻게 파일(데이터)을 주고 받을지에 대한 약속이라고 한다.

 

 프로토콜에는 여러가지가 있다. 데이터를 어떻게 보낼지, 데이터를 목적지까지 최적의 경로를 보내는 방법 등 인터넷과 관련된 프로토콜들을 모은 것이 TCP/IP라고 부르기도 한다. 물론 이안에 TCP프로토콜과 IP프로토콜이 있긴 하지만, 대표적인 패킷 통신을 통상적으로 TCP/IP라 한다.

 

TCP 프로토콜은 신뢰성 있고 무결성을 보장하는 연결을 통해 데이터를 안전하게 전달해주는 전송 프로토콜이고, IP 프로토콜은 패킷들을 가장 효율적인 방법으로 최종 목적지로 전송하기 위해 필요한 프로토콜이다.

 

2. 계층으로 관리하는 TCP/IP

TCP/IP는 왜 계층화되어 있을까? 단순하게 보면 이렇게 모듈화하는 것은 사양을 변경할 때, 해당하는 계층만 바꾸면 되기 때문이다. 그렇다면 무슨 계층으로 이루어져 있을까?

1. 응용/애플리케이션 계층은 TCP/IP 를 사용하는 애플리케이션이 사용하는 프로토콜에 필요한 정보를 헤더로 담는다. 예를 들어 HTTP 통신이면 HTTP 헤더를 붙이게 되는 것이다.
2. 전송/트랜스포트 계층은 해당 패킷의 송신지, 수신지 각각의 포트번호 정보를 담게 되어 수신 호스트에 도착했을 때 어떤 소켓에 데이터를 갖다줄 지에 대한 정보를 담게 된다. (여기서 전송 프로토콜로 UDP를 사용할 수도 있다. 이에 관해선 이 포스팅에서 다루지 않겠다.)
3. 인터넷/네트워크 계층은 해당 패킷의 송신지, 수신지 각각의 IP 주소 정보를 담게 되어 네트워크의 모든 라우터들이 이를 참조하여 가장 효율적인 경로로 패킷을 라우팅해주게 된다.
4. 네트워크 인터페이스/링크 계층은 비교적 물리적인 정보를 담게 된다. 송신지 및 수신지의 MAC 주소를 담아 이더넷 카드를 통해 해당 패킷을 내보낸다.

 

3. HTTP와 관계가 깊은 프로토콜은 IP/TCP/DNS

3-1. 배송을 담당하는 IP

IP프로토콜은 요약하면, 배송에만 특화된 프로토콜이다. 어떻게 하면 가장 최적의 경로로 패킷들을 목적지까지 보낼 수 있을까에 해당하는 프로토콜! 따라서 여기에서 중요한 요소는 IP주소와 MAC(media Access Control Address)주소이다. 왜냐면 목적지까지의 주소와 목적지까지 가는 중간 노드들의 라우터 정보를 알아야하니까!

 

 MAC주소는 각 네트워크 카드에 할당된 고유의 주소이고, IP주소는 각 노드에 부여된 주소이다. 따라서 해당 프로토콜에서는 ARP(Address Resolution Protocol)이라는 프로토콜을 사용하여 IP주소를 보고 목적지까지 최적의 경로로 MAC주소를 안내한다. 택배 시스템과 매우 흡사하다. 사실 중간 과정은 그리 중요하지 않다. 나한테 잘 오면 되는 것이고, 네트워크도 마찬가지로 IP프로토콜에서는 최적의 경로를 탐색하여 최적의 경로 MAC주소들에 보내어 최종 목적지인 IP주소로 보내기만 하는 구간이다. 

 

3-2 신뢰성을 담당하는 TCP

TCP는 신뢰성있는 바이트 스트림 서비스를 제공한다. 라고 할 수 있다. 그럼 어떻게 신뢰성을 확보하고 바이트 스트림 서비스는 무엇인지 알아보자! 

•  바이트 스트림 서비스, 보내는 데이터를 작게 분해하여(세그먼트) 보내는 곳의 주소와 받는 곳의 주소를 포트번호로 작성하여 목적지로 보냄
•  잘 보냈는지 '쓰리웨이 핸드쉐이킹' 방법으로 확인한다.

 여기서 '쓰리웨이 핸드쉐이킹'이라는 방법은 송신측과 수신측에서 우리는 정보를 주고 받는데, 이게 잘 갔는지 보낸건지 확인하는 절차이다.

 네트워크에서는 TCP레이어에서 이를 관리하는데, 'SYN', 'ACK'라는 플래그를 사용해서 정보를 잘 보냈는지 받았는지 확인할 수 있다.

 

 1. 먼저 송신측에서 'SYN' (나 이제 정보(패킷) 보낼게!)플래그를 보낸다.

 2. 수신측에서 해당 패킷을 잘 받았으면,  'SYN', 'ACK'(오! 맞게 잘왔어! 땡큐~)플래그를 보낸다.

 3. 다시 송신측에서 마지막으로 'SYN'(감사합니다. 다음에 또 저희 매장을 이용해주세요~)플래그로 확인했다고 말한다.

 

이렇게 세번의 악수(확인)을 통해 우리는 정보가 잘 갔는지 TCP 프로토콜을 통해 신뢰성있게 정보를 공유할 수 있다.

 

3-3. 이름 해결을 담당하는 DNS

 사실 IP주소는 그렇게 인간에게 친숙하진 않는다. 물론 인간에게 친숙하지 않을 수록 컴퓨터에겐 친숙한 언어인 것이다. 우리가 너 블로그 주소 뭐냐고 물을때, 영어와 같이 사람들이 알기 쉽게 작성이 되어있다. 하지만 컴퓨터는 알아듣지 못한다. 그렇기 때문에 DNS 시스템으로 인간에게 친숙한 도메인 주소를 IP주소로 바꿔주고 반대로 IP주소를 도메인 주소를 바꿔주는 역할을 한다. 그렇기 때문에 DNS도 HTTP와 같이 맨처음 단계(응용 프로토콜)에서 정보를 제공!

 

 

4. 실제 우리가 크롬에 'www.google.com'을 칠 때,어떻게 네트워크가 이루어지는지 상상해보자!

데이터 캡슐화 과정, 송신 -> 수신

1. 애플리케이션 계층에서 DNS에서 해당 주소를 IP주소로 바꿔주고, 이 외에도 해당 계층에서 필요한 정보들과 HTTP헤더를 다음 계층으로 토스!

 

2. TCP계층에서는 받은 정보들을 세그멘트, 작게 분해하여 송신지와 수신지의 포트번호를 붙여 보내고, 수신지에는 정보를 넘긴다라는 'ACK'플래그와 함께 정보를 보낸다. 

 

3. IP주소는 이렇고... OK! 그럼 이 각각의 패킷들을 어떻게 최적의 경로로 보낼까? 음 이렇게 보내는게 가장 빠르겠군! 최적의 경로로 각 패킷들을 수신지로 보내는 경로(MAC주소)를 지정해주는 역할은 IP 프로토콜에서!

 

4. 이제 MAC주소만 알면 위에서 설정한 경로대로 보낼 수 있겠군. ARP(IP주소를 MAC주소로 바꿔주는 주소해석)프로토콜을 이용해서 MAC주소 까지 확인! 그럼 이제 전기 신호로 패킷들을 바깥 세상으로 뿌리자!

 

5. 해당 정보들이 목적지 IP로 도착하면, 위 과정들의 역순으로 역캡슐화가 이루어지고! 리퀘스트에 해당하는 리스폰스를 사용자에게 보낸다!

 

해당 과정들이 반복되면서, 네트워크는 정보를 주고 받는다! 참고로 TCP는 연결지향 프로토콜인데, 이와 반대되는 비연결지향 프로토콜인 UDP가 있다. 이 부분도 다음 시간에 각각의 장단점을 비교하며 블로그 정리를 해보자!