TCP/IP, 3, 4Way HandShaking

인터넷

TCP/IP 설명에 앞서 인터넷이란 무엇인지 간단하게 알아봅니다.

 

인터넷이란?

'전 세계에 걸쳐 파일 전송 등의 데이터 통신 서비스를 받을 수 있는

컴퓨터 네트워크의 시스템'

 

우리는 실생활에서 인터넷에 가입을하고 사용합니다.

통신비용을 지불함으로써 사용할 수 있습니다.

이것은 사업자가 만들어 놓은 네트워크 인프라를 사용하는 것입니다.

왼쪽은 SK 브로드밴드의 자가망 보유현황이고

우측은 해외와 연결된 네트워크 망입니다.

해외와는 바다 밑에 광속케이블을 통해 연결되어 있습니다.

 

이러한 거대한 인프라를 통해 데이터를 디지털 신호로 바꾸어 전달하고,

받은 디지털신호를 다시 데이터로 바꿔가면서 네트워크 통신이 이루어집니다.

OSI 7 Layer 관련 블로그 참조

https://wonuk.tistory.com/132

OSI 7 Layer (계층)

 

네트워크 통신을 위해 미리 정해 놓은 공통된 메뉴얼을

프로토콜 이라고 합니다.

---

TCP/IP

인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 쓰이는 프로토콜의 집합

 

TCP/IP의 계층

TCP/IP는 4가지의 계층이 존재합니다.

Application Layer

특정 서비스를 제공하기 위해 애플리케이션 끼리 정보를 주고 받게 해줍니다.

ex) FTP, HTTP, SSH, Telnet, DNS, SMTP

 

Transport Layer

송신된 데이터를 수신측 애플리케이션에 확실히 전달하게 만들어줍니다.

네트워크 통신을 하는 애플리케이션은 포트번호를 사용합니다.

Transport Layer는 포트번호를 사용해서 애플리케이션을 찾아주는 역할을 합니다.

ex) TCP, UDP, RTP, RTCP

 

Internet Layer

수시 측 까지 데이터를 전달하기 위해 사용합니다.

송신, 수신 측 모두 IP주소를 가지고 있습니다.

인터넷 레이어는 IP주소를 바탕으로 올바른 목적지로 찾아갈 수 있도록 합니다.

ex) IP, ARP, ICMP, RARP, OSPF

 

Network Access Layer

네트워크에 직접 연결된 기기 간 전송을 할 수 있도록 합니다.

물리적 주소인 MAC주소를 사용합니다.

ex) Ethernet, PPP, Token Ring

 

 

---

www.google.com을 웹브라우저에 입력하면

무슨일이 일어나는가?

 

웹브라우저에 www.google.com 을 입력한다는 것은

구글 웹서버의 80포트로 아래와 같은 HTTP Request 메시지를 보내는 것입니다.

해당 요청을 인터넷을 통해 구글서버로 전달하기 위해

우리는 패킷을 만들어야 합니다.

이 패킷에는 각 계층에 필요한 정보들이 담겨야 합니다.

여기서는 각 계층별로 HTTP, TCP, IP, Ethernet 프로토콜을 사용합니다.

패킷의 Application Layer에는 위에서 작성한 HTTP Request가 들어갑니다.

 

그럼 Transport, Internet, Network Access Layer 순으로 

차례대로 어떤 데이터가 들어가는지 알아보겠습니다.

 

TCP 패킷의 헤더

중요하게 볼 것은 SP와 DP입니다.

각각 시작 포트번호와 목적지 포트번호를 말합니다.

 

시작 포트번호는 내 컴퓨터에서 만든 소켓의 포트 번호이기 때문에

당연히 내 컴퓨터는 해당 포트 번호를 알고 있습니다.

목적지 포트번호 또한 80으로 우리는 알고 있습니다.

80는 웹서버의 웰노운 포트 번호입니다.

 

IP 헤더

여기서는 SA와 DA가 중요합니다.

시작 IP주소와 목적지 IP주소를 나타냅니다.

 

내 컴퓨터의 시작 IP주소는 알고있지만

목적지의 IP주소는 아직 모르는 상태입니다.

지금은 www.google.com 이라는 도메인 인 정보만 알고 있습니다.

 

하지만 DNS 프로토콜을 통해서 도메인 정보로 IP주소를 알아 낼수 있습니다.

 

DNS

브라우저는 OS에게 domain에 대한 ip주소를 알고 싶다고 요청합니다.

그러면 OS에서 DNS서버로 요청을 보내게 됩니다.

그렇다면 여기서 OS는 DNS 서버를 어떻게 알고 있을까요?

DNS 서버 주소는 이미 컴퓨터에 등록이 되어있습니다.

 

맥북의 경우 시스템 환경설정 - 네트워크 에 들어가보면

내 컴퓨터가 알고있는 DNS서버 주소를 볼 수 있습니다.

DNS 또한 HTTP와 같은 Application 계층 프로토콜 입니다.

그리고 DNS는 53번 포트를 사용합니다.

DNS도 HTTP Request와 비슷하게 도메인이 담긴 쿼리를

도메인 서버로 보냅니다.

그러면 도메인 서버가 IP주소를 응답합니다.

 

DNS는 Transport Layer에서 UDP라는 프로토콜을 사용합니다.

UDP는 TCP와 다르게 헤더가 간단합니다.

위 이미지를 보면 포트번호를 제외하면 다른것이 없습니다.

그 이유는 UDP가 비연결지향형 프로토콜이기 때문입니다.

 

여기까지의 작업으로 도메인 이름에 대한 IP주소를 받아오게 되었습니다.

 

Ethernet 프로토콜 헤더

아직 MAC주소를 모르는 상태입니다.

MAC주소를 알아오기 전에

이전까지는 내 컴퓨터의 목표인 구글서버에 대한 정보가 필요했습니다.

그렇다면 MAC주소도 목적지인 구글 웹서버의 MAC주소가 필요할까요?

 

여기서 MAC주소는 구글의 MAC 주소 대신

물리적으로 연결된 우리집 공유기의 MAC주소가 필요합니다.

이 공유기를 통해 다른 네트워크와 연결이 가능하니

게이트웨이 라고 부르기도 합니다.

우리는 이미 게이트웨이에 대한 정보를 알고 있습니다.

netstat 명령어를 통해 확인이 가능합니다.

 

그럼 어떻게 IP주소로 MAC주소를 알 수 있을까요?

 

ARP

IP주소를 MAC주소로 바꾸어주는 주소해석 프로토콜

 

여기까지 모든 정보를 알아냈으니 패킷이 네트워크 세계로 나갈 준비가 되었습니다.

그런데 요청을 보내기전에 한가지 더 봐야할게 있습니다.

바로 TCP가 연결지향형 프로토콜이라는 점입니다.

 

---

3-Way-Handshaking

TCP 프로토콜은 데이터를 전송하기 전에

송신측과 수신측이 서로 연결되는 작업이 필요합니다.

이러한 작업을 3 Way Handshaking이라고 합니다.

 

이것을 수행하기 위해서는 TCP헤더에 표시한 플래그들이 사용됩니다.

이러한 플래그들을 컨트롤 비트라고 부릅니다.

 

3Way Handshaking에서는 SYN과 ACK 플래그가 사용됩니다.

 

1. 클라이언트는 서버에게 접속을 요청하는 SYN패킷을 보냅니다.

2. 서버는 SYN 요청을 받고, 클라이언트에게 요청을 수락한다는 ACK와

   SYN 플래그가 설정된 패킷을 보냅니다.

3. 클라이언트는 서버에게 다시 ACK을 보냅니다.

여기까지 완료되면 연결이 되었다고 여겨지고 데이터를 주고받게 됩니다.

 

이제 3Way Handshaking으로 연결이 성립 되었으니

데이터가 보내질 차례입니다.

 

한가지 더 부가적으로 설명하자면

내가 사용하는 컴퓨터는 Private IP를 사용하고 있습니다.

Private IP는 외부의 네트워크 환경에서 IP주소를 찾지 못합니다.

그래서 공유기를 통해 나갈때 Public IP로 주소를 변환하여 나가야 합니다.

이러한 작업을 NAT(Network Address Translation)이라고 합니다.

 

우리집 공유기를 거쳐 구글 서버에 도착하기 위해

여러 라우터를 거쳐야 합니다.

라우터는 네트워크와 네트워크를 연결해주는 역할을 수행합니다.

이 라우터가 목적지 경로를 찾아 나가는 과정을 

라우팅이라고 표현합니다.

 

라우팅을 거쳐 구글 서버가 연결된 라우터 까지 데이터가 도착하면

패킷의 IP헤더에 기록된 구글 서버 IP주소를 통해 MAC주소를 얻어와야 합니다.

이때 위에서 설명했던 ARP프로토콜을 사용합니다.

 

ARP는 라우터가 연결된 네트워크에 브로드캐스팅 됩니다.

 

목적지 구글서버가 자신의 IP로 온 ARP 요청을 받고

MAC주소를 응답해줍니다.

여기까지 목적지 구글서버의 MAC주소를 알았으니

데이터가 물리적으로 전달될 수 있습니다.

 

ARP로 IP주소를 통해 MAC주소를 얻고,

목적지 구글서버에 데이터가 도착하게 됩니다.

 

Internet Layer의 IP주소와 Network Access Layer의

MAC주소를 사용해서 올바른 목적지에 도착했으니

Transport Layer부터 설명을 진행하겠습니다.

 

Transport Layer의 목적지 포트번호에는 80번이 적혀 있습니다.

이것을 보고 80번 포트를 사용하고 있는 애플리케이션에게 

데이터를 전달해줘야 하는 것을 알 수 있습니다.

 

Application Layer까지 오게되면

웹서버가 사용될 HTTP Request 데이터를 얻을 수 있게됩니다.

 

이제 서버에서 정상적으로 HTTP Request를 받고 응답을 돌려보냅니다.

 

"/"에 매핑된 GET 요청을 처리해서 적절한 HTML을 응답한다고 가정해봅시다.

실제 크롬 개발자 분석도구를 통해 확인해보면 응답받은 HTML을 확인할 수 있습니다.

 

HTTP요청과 응답과정이 끝나면 연결을 종료해야 합니다.

이 종료하는 과정에서도 TCP의 컨트롤 비트가 사용됩니다.

이 단계에서는 ACK, FIN 플래그가 사용됩니다.

 

4-Hand-Shaking

1. 클라이언트가 서버로 연결을 종료하겠다는 FIN 플래그를 전송합니다.

2. 서버는 클라이언트에게 ACK 메세지를 보내고,

   자신의 통신이 끝날 때 까지 기다립니다.

3. 서버가 통신이 끝나면 클라이언트로 FIN을 보냅니다.

4. 클라이언트는 확인했다는 의미로 서버에게 ACK을 보냅니다.

이 과정을 마치면 연결이 종료됩니다.

이것을 4Way Handshaking 이라고 부릅니다.

 

그런데 서버가 FIN을 보내는 과정에서 한가지 문제가 발생할 수 있습니다.

서버가 FIN을 보내기 전에 보냈던 데이터가 FIN보다 늦게 도착할 경우입니다.

서버로 부터 FIN을 수신했다고 클라이언트가 바로 연결된 소켓을 닫으면

FIN을 보내기전에 보낸 패킷은 클라이언트가 받을 수 없게됩니다.

 

그래서 클라이언트는 서버로부터 FIN 요청을 받더라도

일정시간 동안 소켓을 닫지 않고 아직 도착하지 않은

잉여 패킷을 기다리게 됩니다.

이렇게 4Way Handshaking과정이 완료되어도 소켓을 닫지않고

잉여패킷을 기다리는 상태를 TIME_WAIT이라고 합니다.

---

TCP

TCP는 연결지향형이고 신뢰할 수 있는 프로토콜 입니다.

 

요즘 시대에 우리는 엄청나게 큰 데이터를 서로 주고 받습니다.

이 큰 데이터를 하나의 패킷으로만 주고받기에는 무리가 있습니다.

 

그래서 데이터를 잘게 쪼개서 보내게 되고

많은 패킷을 보내게 됩니다.

그리고 이러한 패킷들은 복잡한 인터넷을 통해 목적지로 이동됩니다.

복잡한 환경에서 데이터들이 유실되지 않거나 

올바른 순서대로 잘 도착할 수 있을까요?

 

바로 그 어려운 것을 신뢰할 수 있는 프로토콜인 TCP가

가능하게 만들어줍니다.

 

TCP는 흐름제어, 오류제어, 혼잡제어를 통해

신뢰성있는 데이터 전송을 보장할 수 있게 해줍니다.

 

흐름제어, 오류제어, 혼잡제어에 대해 이후 포스팅에서 알아보겠습니다.

 

출처

테코톡 유튜브

https://www.youtube.com/watch?v=BEK354TRgZ8