Study/데이터 통신

TCP / IP

zzoo-ppaamm 2021. 11. 5. 15:43

TCP / IP

목차

  1. 인터넷
  2. TCP / IP 계층
  3. TCP / IP 흐름
  4. 신뢰할 수 있는 TCP

인터넷

데이터 -> 디지털 신호 -> 데이터

TCP / IP

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

TCP / IP의 계층 (ATINA)

  1. Application Layer
  2. Transport Layer
  3. Internet Layer
  4. Network Access Layer

Application Layer

특정 서비스를 제공하기 위해 에플리케이션 끼리 정보를 주고 받을 수 있음

브라우저와 웹서버가 HTTP 요청, 응답을 통해 통신하는 것을 예로 들수 있음.

FTP, HTTP, SSH, Telnet, DNS, SMTP

Transport Layer

송신된 데이터를 수신측 애플리케이션에 확실하게 전달하게 함

네트워크 통신을 사용하는 애플리케이션은 포트 번호를 사용하게 됨

TL은 포트번호를 사용해서 애플리케이션을 찾아주는 역할!

TCP, UDP, RTP, RTCP

Internet Layer

수신 측까지 데이터를 전달하기 위해 사용됨

송신측, 수신측 모두 IP주소를 갖고 있음

IL은 IP주소를 바탕으로 올바른 목적지로 찾아갈 수 있도록 도와주는 역할!!

IP, ARP, ICMP, RARP, OSPF

Network Access Layer

네트워크에 직접 연결된 기기 간의 데이터 전송을 도와줌

여기서는 물리적 주소인 MAC주소를 사용

Ethernet, PPP, Token Ring

TCP / IP의 흐름

"www.google.com을 웹브라우저에 입력하면 무슨 일이 일어날까요?"

= 구글 웹서버의 80포트로 HTTP Request 메시지를 보내는 것

해당 요청을 인터넷을 통해 구글 서버로 전달하기 위해 우리는 패킷을 만들어야한다.
패킷에는 각 계층에 필요한 정보들이 담겨야 한다.

여기서는 각 계층별로 HTTP, TCP, IP, Ethernet을 사용한다고 생각하고, 어떤 데이터가 각 계층에 들어가는지 알아보자

  1. Application Layer
    1. Http Request
  2. Transport Layer
    1. TCP 패킷의 헤더
      1. 중요한 것은 SP와 DP
        시작 포트번호와 목적지 포트번호를 의미
      2. 시작 포트 번호는 내 컴퓨터에서 만든 소켓의 포트번호
      3. 목적지 포트번호는 80(웹서버의 웰노운 포트번호)
  3. Internet Layer
    1. IPv4 헤더
      1. 중요한 것은 SA와 DA
        즉, 시작 IP주소와 목적지 IP주소
      2. 나의 시작 IP주소는 알고있지만
      3. 목적지의 IP주소는 아직 모른다
        도메인 정보(www.google.com)만 알고있다.
      4. 하 지 만, DNS 프로토콜을 통해서 도메인 정보로 IP주소를 알아 낼 수 있다!!
  4. Network Access Layer
    1. Ethernet 프로토콜에 대한 헤더..
      를 만들어야하는데, 아직 MAC 주소를 모름

DNS

  1. 브라우저는 OS에게 도메인에 대한 IP주소를 알고싶다고 요청한다
  2. 그러면 OS에서 DNS서버로 요청 (www.google.com)
  3. DNS서버는 IP주소 반환함 (142.xxx.xxx.xxx)

그런데 OS는 DNS서버를 어떻게 알고 있었나?

DNS 서버 주소는 이미 컴퓨터에 등록이 되어있음
DNS도 HTTP와 같은 애플리케이션 계층(Application Layer) 프로토콜임. 53번 포트를 사용함.

DNS도 HTTP Request와 비슷하게 도메인이 담긴 쿼리를 도메인 서버로 보냄.
그러면 도메인 서버가 IP주소를 응답해줌

DNS는 Transport Layer에서 UDP라는 프로토콜을 사용

UDP

비연결지향형 프로토콜로 TCP와 다르게 헤더가 간단
포트번호 말고 다른게 없음

Network Access Layer

우리의 목적지인 Google 웹서버의 MAC주소가 필요할까?

우리는 구글 MAC주소 대신 물리적으로 연결된 우리집 공유기의 MAC주소가 필요하다!!

이 공유기를 통해 다른 네트워크와 연결이 가능하니 "게이트웨이"라고 부르기도 함
게이트 웨이의 IP는 netsart -rn명령어를 통해 확인 가능

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

ARP 프로토콜을 사용해서.
ARP 프로토콜은 "IP주소를 MAC주소로 바꾸어주는 주소해석 프로토콜"

패킷완성! 그런데 요청을 보내기전에..

TCP에 대해서 알아야한다.

TCP

"연결지향형 프로토콜"

TCP는 데이터를 전송하기 전에 송신측과 수신측이 서로 연결되는 작업이 필요하다.
이러한 작업을 "3-Way-Handshaking" 이라고 부른다.

3 Way Handshaking을 사용하기 위해서는 TCP 헤더에 표시한 플래그들이 사용됨
(URG, ACK, PSH, RST, SYN, FIN) 이러한 플래그들을 컨트롤 비트라고 부른다.
3 Way Handshaking에서는 SYN이랑 ACK 플래그가 사용

  1. 클라이언트 → 서버 : 접속을 요청하는 SYN 패킷을 보냄(SYN:1)
  2. 클라이언트 ← 서버 : SYN요청을 받고, 요청을 수락한다는 ACK와 SYN 플래그가 설정된 패킷을 보냄
    (ACK:1 SYN:1)
  3. 클라이언트 → 서버 : 다시 ACK를 보냄(ACK:1)
    이제부터 연결이 이루어지고, 데이터가 오가게 됨.
NAT (Network Address Translation)

내가 사용하는 컴퓨터는 private IP를 사용 중
private IP는 외부의 네트워크 환경에서 IP주소를 찾지 못함.
그래서 공유기를 통해 나갈때, public IP 주소를 변환하여 나가는 작업이 필요함

이러한 작업을 NAT라고 한다.

Routing

우리집 공유기를 거치고 나서, 구글 서버에 도착하기 위해 여러 라우터를 거쳐야 한다.,

라우터는 네트워크와 네트워크를 연결해주는 역할을 한다.

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

ARP

라우팅을 거쳐 구글 서버가 연결된 라우터까지 데이터가 도착하면, 패킷의 IP헤더에 기록된 구글 서버 IP주소를 통해 MAC주소를 얻어와야한다.

이 때, 이전에 설명했던 ARP 프로토콜을 사용함
ARP는 라우터가 연결된 네트워크에 브로드캐스팅된다.

목적지 구글서버가 자신의 IP로 온 ARP 요청을 받고, MAC주소를 응답해줌.

이제 목적지 구글서버의 MAC주소를 알았으니, 데이터가 물리적으로 전달 가능

ARP로 IP주소를 통해 MAC주소를 얻고, 목적지 구글 서버에 데이터가 도착!!!!! 했습니다 !!!

구글 서버에서 패킷을 까보면

IL(Internet Layer)의 IP주소와
NAL(Network Access Layer)의 MAC주소를 사용해서 올바른 목적지에 도착했으니
TL(Transport Layer) 부터 설명해줄게

TL의 목적지 포트번호에는 80이 적혀있었지?
이것을 보고 80번 포트를 사용하고있는 애플리케이션에게 데이터를 전달해줘야하는 것을 알수 있지?

AL까지오면 웹 서버가 사용될 HTTP Request 데이터를 얻을수 있게 된다.

서버에서 HTTP Request를 정상적으로 받고 응답(HTML)을 돌려보내준다. (다시 라우터를 거쳐서 라우팅)
"/"에 매핑된 GET요청을 처리해서 적절한 HTML을 응답해준다.

HTTP 요청과 응답 과정이 끝나면

연결을 종료해야한다.

여기서도 TCP 컨트롤 비트가 사용된다.
ACK와 FIN 플래그

  1. 클라이언트 → 서버 : 연결을 종료하겠다는 FIN 패킷을 보냄(FIN:1)

  2. 클라이언트 ← 서버 : ACK메시지 보내고, 서버는 자신의 통신이 끝날 때까지 기다림 (ACK:1)

  3. 클라이언트 ← 서버 : 서버가 통신이 끝나면, FIN 패킷을 보냄 (FIN:1)

  4. 클라이언트 → 서버 : 확인했다는 의미로 ACK를 보냄 (ACK:1)
    연결 종료 완료!

    This is "4-Way-Handshaking"

그런데!! 서버가 FIN을 보내는 과정(3.)에서 한가지 문제가 발생할 수 있음!!

바로 서버가 FIN을 보내기전에, 보냈던 데이터가 FIN보다 늦게 도착할 경우가 그렇다.

서버로부터 FIN을 수신했다고해서 클라이언트가 바로바로 연결된 소켓을 닫아버리면 FIN을 보내기전에 보낸 패킷은 클라이언트가 영영 보낼수 없게 됨.

그래서 클라이언트는 서버로부터 FIN요청을 받더라도 일정시간동안 소켓을 닫지 않고, 혹시나 아직 도착하지 않은 잉여 패킷을 기다린다.

이 상태를 "TIME_WAIT"이라고 한다.

신뢰 할 수 있는 TCP

엄청나게 큰 데이터를 한 개의 패킷이 아닌 잘게 쪼개서 여러개의 패킷으로 보낸다.

이러한 패킷들이 유실되지않고, 올바른 순서대로 도착할 수 있을까?

TCP가 가능하게 해준다.

  1. 흐름제어

  2. 오류제어

  3. 혼잡제어

따로 TCP에 대해서 공부해보자!